jacktoole1

I had to open things in a new tab (in chrome) to see them (odd, but it worked?)

Edit: Seems to be working now anyways :).

For anyone else running into the same problem, I just copied my HipChat.app in /Applications, and ran the second hipchat next to the first hipchat (you can also change the second hipchat's icon for easy distinguishment). It's not perfect (upon logout/restart it still remembers the preferences for the other instance), but it solved 90% of my hassle.

I've found using hipchat with coworkers to be much nicer than using XMPP with coworkers mostly for it being closer to IRC: there are rooms where most discussion takes place, so you can get to know people by lurking there, and when you need to 1:1 message someone, you probably have some context about who they are, which makes a world of difference to an introverted new hire. The realtime team-wide chat just makes everything feel much more friendly, imho.

I'm sure it's possible to get that setup with XMPP, and it's definitely possible to get an equivalent setup with IRC (which I have an external server running ZNC for), but it's not out of the box, and there is something to be said for having a good configuration set up and working for everyone out of the box.

nice!

similarly,

    var oldPlaceObject = map.placeObject;
    var newPlaceObject = function(x, y, type) {
    	if (type !== 'block') {
        	map.placeObject = oldPlaceObject;
        	map.placeObject(x, y, type);
            map.placeObject = newPlaceObject;
        }
    };
    map.placeObject = newPlaceObject;

was my solution to multiple levels ;).

First, I'm very sorry about that!

Second, wow, a scale factor of 256! Off the top of my head it might be numerical error building up. If that's the case, I'm very sorry. (It's also sometimes possible to get infinitesimally close to the target without technically reaching it mathematically, in which case the interface unfortunately looks like the answer is correct, when it's not.)

All of the puzzles are solvable with dilations of scales only 2 or 1/2.

Thanks for the feedback!

The undo button thing would be a huge improvement; I'll fix that. (Also, if you do two transformations that cancel each other out, it will notice and remove both rather than adding two. So you can actually undo a reflection by clicking the reflector again.)

As some other comments have pointed out, you might have seen the text based dilation, which is used for one of the problems for a specific reason :). The dragging dilation tool is far from perfect, but is a bit closer to what you described.

Maybe more importantly, they would know whether their message was classified as spam (or a pretty good heuristic thereof). A naive bayes classifier for spam relies on the spammer not knowing whether the message was marked as spam or not. Such a classifier isn't difficult to fool if you can test how a given message is classified. (Presumably gmail's spam filter is more advanced these days, but the idea that it is easier to fool if you can tell the result still seems reasonable.)

Like most tests, my personal opinion is that it tests both how well you know the material as well as how familiar you are with the format and content of the test. There is value in the former, and hopefully more access to preparation materials can alleviate some of the variance in the latter.

Thanks! Yes, I agree that full-length tests are important. We're not there yet, but I think we'll improve on that with time (there has been some talk of different styles of how/which/how many questions appear in an exercise for other reasons, and I think this just gives another reason to focus on that in the future).

I don't have any practical experience with angular (but I'd like to, and definitely think its testability is a step in the right direction).

That said, I've found react to be very declarative, especially over the raw jQuery and Backbone I'd used before. Most of the components I write have no state, and render() declares how to render them from any state, without having to worry about how to change things on state changes.

I learned them concurrently, translating lua in Programming in Lua into the equivalent moonscript. It's a pretty strait-forward translation and is definitely doable. I already had experience with a reasonable variety of languages before learning it though, and for people still getting into programming, I think Lua is a simpler and still awesome language.

I don't think it's possible to learn moonscript without learning lua concurrently, since lua makes up so much of the underlying semantics. So I think the choice is either (a) learn lua, or (b) learn lua and moonscript for some nice syntactic sugar.