The HD Edition has a new AI[0] that's much stronger than the old one. It's built by Promiskuitiv and Archon, two well-known AI scripters in the Age of Empires scene :)

[0]: http://steamcommunity.com/app/221380/discussions/1/540744934...

As I understand it, this is a bot AI, and not a unit AI. Am I wrong?

How does the new AI differ from the original one? I don't see it in the change log.

It was random. According to SteamDB[1] it was a caching issue that ended up sending random pages to the wrong people.

Possible explanation from unknown source: https://www.reddit.com/r/Steam/comments/3y7le9/im_logged_in_...

[1]: https://twitter.com/SteamDB/status/680490823226671104

Thanks. Based on that information any privacy-conscious users should simply not use Steam or the Steam website until the bug is fixed. By not using Steam, their pages won't end up in cache and will not be leaked to others.

Yeah, but there's other bugs that do let you do that (pull peoples account info). I've found a plenty of exploitable vulnerabilities on steam but stopped reporting them after their support told me to go post "suggestions" on their forums instead.

Email security@valvesoftware.com; I've reported loads of things there (some serious, some pretty trivial), and they're actually very good about responding to things these days. Steam Support is totally useless, though.

I like this a lot. It's similar to the proposed function bind syntax[1], but a bit more friendly to not-`this`-related use:

    function bindMap(fn) { return this.map(fn) }
    [ 1, 2, 3 ]::bindMap(n => n + 1)
    // standalone use: bindMap.call(arr, fn)

    function pipelineMap(fn) { return arr => arr.map(fn) }
    [ 1, 2, 3 ] |> pipelineMap(n => n + 1)
    // standalone use: pipelineMap(fn)(arr)

(Also nice that it works in a very similar way to decorators, although they won't be interchangeable in most cases, with decorators working on class constructors and property descriptors, instead of just any value.)

Presumably, at most one of these proposals will make it in :)

[1]: https://github.com/zenparsing/es-function-bind

I agree that a "functional" operator that uses `this` as the first argument is weird.

The main goal of all of these proposals is "left to right" composition when working with functions, and functions take parameters.

Messages are sent through plainly first over Twitch's IRC-ish protocol. You can connect to Twitch chat with a simple IRC client, or through the browser. Twitch's own browser chat connects to a WebSocket server that passes IRC commands to the browser, where they are parsed & executed.

Twitch has a few additional IRC-ish commands like CLEARCHAT, which deletes messages by a given user. Most IRC clients don't support this, but Twitch's browser client of course does :) In larger streams spammy messages are usually removed by bots like http://www.nightbot.tv/ or http://twitch.moobot.tv/. That's where the delay comes from: messages have to arrive at the moderator first.

Interestingly, CLEARCHAT can only delete _all_ messages by a given user (as far as I know), so non-offending messages are also removed. This is done by the client, the chat servers only pass "CLEARCHAT #channel_name user_name". (e; it's all messages by a given user, or all messages in the channel if no username is given)

In the Twitch browser client, you can double-click the <message deleted> text to show the original text if you really want to! :)

Reference: https://github.com/justintv/Twitch-API/blob/master/IRC.md

view-source should keep working reasonably. WebAssembly defines a Text Format for exactly that purpose:

https://github.com/WebAssembly/design/blob/master/TextFormat...

`.call` is a method in some Promise libraries (eg. Bluebird). Basically,

    connection.call('collection', 'users')

is a shorthand for:

    connection.then(value => value.collection('users'))

Thanks for clarifying. This is a very neat way of removing what would be an extra level of nesting.

It doesn't look like native promises support this unfortunately: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Another nitpick I have with native promises is that they require an extra level of nesting to get the resolve callback.

    // How it is now
    new Promise(function(resolve, reject) {
        resolve('done');
    });


    // vs. What most libraries implement
    var p = new Promise();
    p.resolve(function() {
        return 'done';
    });

Both parts are incorrect, the native way is `Promise.resolve('done')`. As for .call - native promises let you subclass them. If you have a promise enabled environment you can use generators anyway. I used Q's syntax because that's what OP used.

Regardless - nice comment.

querySelectorAll returns a NodeList instead of a real array, so you can't call things like `.forEach` on the result. `[].slice.call(x)` turns x into an array, so that becomes

    [].slice.call(document.querySelectorAll(...)).forEach(function () {})

Because a lot of array methods are "generic", i.e. operate on array-like objects instead of just arrays, that can be "compacted" to

    [].forEach.call(document.querySelectorAll(...), function () {})

but neither are very nice.

Location: Groningen, Netherlands

Remote: Ok, prefer local

Willing to relocate: _Probably_ not

Technologies: Javascript (Node, Ember, Backbone, ES6 & other new stuff), HTML5/CSS3, PHP, Python, would love to get in touch with new things as well.

Résumé: https://rene.kooi.me/cv.html

Email: rene at kooi dot me

Github: https://github.com/goto-bus-stop

I'm primarily looking for an internship from November 2015-February 2016 or a part-time job next to my Software Engineering study at the Hanze Hogeschool.

It's probably too late for you to edit your comment (?) but for those that get an error on the resume link try without https: http://rene.kooi.me/cv.html

Another ASCII art weather (forecast) utility, but in Go: https://github.com/schachmat/wego

Unlike the main post, this is a good use of ASCII art. i.e. to show a drawing/symbol not to make numbers more difficult to parse...

This is much much better. Closer to "beautiful" than the one featured here.

Yeah, it's beautiful if

1) you think mutable variables are beautiful

2) you think stuffing everything into one file is beautiful

3) you think defining functions at the root namespace is beautiful

4) you think consecutive repeated property accesses stuffed into a consecutively repeating boolean check like this are beautiful: if h.Time == "0" || h.Time == "100" || h.Time == "200" || h.Time == "300" || h.Time == "400" || h.Time == "500" || h.Time == "600" || h.Time == "700" || h.Time == "1400" || h.Time == "1500" || h.Time == "1600" || h.Time == "2300"

5) if you think embedding ANSI color codes across all strings instead of centralizing all that ugliness somewhere is beautiful

6) if you think not separating your command-line-handling code from your problem-modeling code is beautiful (see: Hexagonal Architecture http://alistair.cockburn.us/Hexagonal+architecture)

7) If you think having no fucking test suite to speak of, given all that mangled mutating code is beautiful (to me this is the MOST egregious non-beautiful thing in the entire "project")

Then, yes. WeGo is beautiful.

Frankly I'm shocked that what people call "beautiful" can differ that fucking much.

I think the parent was referring to the console display output rather than the code itself.

lol. then I guess I will step off my pedestal and agree. I mean... I think Figlet does a better job than all of these, but anyway

Can anyone explain why a dependency of this app is a "working Go environment"? I thought one of golang's selling points was the fact that it created a simple binary.

As far as I can tell, the Go environment is simply being used as a cheap installer, is that correct?

In my opinion its more like: Go comes with a package-management/install system onboard, and for every 'go install', there's a full copy of working sources which someone, some day, might consider reading and contributing to ..

So I think, at least as a go newbie, that its quite handy that pretty much every tool I might be interested in - because it was written in Go - comes with full sources onboard as a basic, starting-gate, expectation. At least, I am quite happy to be learning Go this way ..

Because he's sharing the source code rather than a compiled binary. It's no different to having make + gcc listed as a dependency for C++ code.

Strictly there is a little hindrance for the non-gopher user because this won't work until they set up a Go workspace, i.e. decided where they want GOPATH to be, set that, and added $GOPATH/bin to PATH to have the executable be runnable.

    $ env -i $(which go) get github.com/schachmat/wego
    package github.com/schachmat/wego: cannot download, $GOPATH not set. For more details see: go help gopath

Indeed, but that's a separate point. The question was why Go was listed as a dependency and my answer was because it's a source code repository.

Also, you left off GOROOT from your Go environment :)

> The question was why Go was listed as a dependency

You may have read it that way but the question was explicitly referring to "working Go environment"

Only because that was the terminology used on the Github readme. He was quoting it verbatim rather than asking what environmental variables needed setting. The reason I think this is because he also went on to say "I thought one of golang's selling points was the fact that it created a simple binary." which relates directly to discussions people make about JIT compiled (eg Python, Javascript, etc) vs AOT compiled (eg C++ and Go).

It's also worth noting that you're only specifically discussing environmental variables, where as a development environment is more than just that. Aside having your build tools in PATH (and lets not forget that gcc and make need this just as much as go does), you need supporting shells for the ./config(ure) scripts, any source libraries for C++ includes, and so forth. So you could equally use the same "working [language] environment" terminology to describe C++ - or in fact any other programming language too.

Which is why I think he was asking why he needed Go installed to begin with.

Alright, well hopefully somebody gleans something from our little thread either way.

So request a binary then. You're basically moaning that an open source project is shipping source code.

And FYI, Go is in quite a few distro repos so you might be able to just:

  apt-get install go-lang
  mkdir -p ~/go/src ~go/bin
  export GOPATH=~/go
  go get github.com/schachmat/wego
  go install github.com/schachmat/wego

However considering this is an open source CLI tool, I don't think it's at all unreasonable to expect he user to do a bit more manual work to compile and run this tool from the command line.

In fact, quite frankly, I find it rather disgusting that someone should share their work and source code like this and have others moan simply because they're too bloody lazy to compile it themselves. I mean seriously guys, this is Hacker News, not PC World Magazine.

It actually does work this way. 'Install Go; go get github.com/me/my-program'. Done.

Wow thanks for sharing.. this is really is beautiful!

That's really mind blowing! Thanks for sharing this.

Thanks, wego is very beautiful and quite useful!

Another false positive anecdote! My parents used to have their ISP's adult content filter enabled. One day I couldn't visit DeviantArt, because it said "Mature Content Filter Enabled" somewhere on the page, and "mature content" triggered the ISP's filter.