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.
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.
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).
The College Board is releasing previously-unreleased SAT questions on Khan Academy, with answers and explanations [1]. The College Board announcement emphasized the importance of practice, as well as transparency about preparation materials such as practice tests.
While we don't have an ideal test-like practice environment yet, I hope that we will be able to provide one 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.
I've used moonscript a lot, and don't particularly like the \ syntax. However, you get used to it quickly, and it stops seeming like such a big deal.
It would be hard to have both be '.', because of lua semantics: '.' means "get the property from the table", while ':' in lua and '\' in moonscript mean "get the function from this table, with the first parameter for that function bound to the table itself".
Javascript/Coffeescript can get away with both being '.' because of the horrible mess that is implicit 'this'. All functions have an implicit first parameter, that non-method functions usually ignore, and '.' in javascript does the equivalent of ':' and '\' in moonscript (for functions). I find the lua approach much simpler and cleaner, and think it is actually more approachable than the javascript way, because the difference between '.' and ':' or '\' is conceptually simpler than all the rules behind 'this' in javascript.
Programming in Lua explains ':' in http://www.lua.org/pil/16.html , and probably has a better explanation that I wrote :).
Sure, but isn't it awesome if, instead of being just one unit tests, you can have some critical checks running in every unit test (and when running the code as a whole)?
However, if you're going this route, it might be worth having a second assert macro that can allow you more fine-grained control of enabling/disabling fast asserts vs slow asserts.
While I agree with the overall sentiment of the article, the hypothetical monetization numbers in the last paragraph are just ridiculous. Getting 20% of a free userbase to pay anything is extremely high. ~0.2% to 2% sounds like a more likely number, based on my admittedly cursory knowledge of monetization of apps. $5 a month also sounds a bit high for essentially a photo-sharing service, a yearly charge of ~$20 sounds more likely. However, for users that have passed the "willing to pay anything" barrier, the actual cost might not as big a deal.
This also completely ignores the viral nature of these types of services; people are more likely to use Instagram when their friends are using it. Without being free, it's not clear whether it would have taken off enough to gain 2 million users (or whether it could keep 2 million after the remaining 98 million left).
That said, I'm all for paying for services, and much prefer that model to ads. But just because some of us would prefer that doesn't mean it would have been the right choice for Instagram. It's easy to look back and say "they should have charged users," but we can't be sure we'd be in a place to analyze them if they had.
I've been trying to use something closer to ColinDabritz's second wording: "What am I missing that makes ____ unreasonable?" or "I don't understand why ____ wouldn't work". Phrasing it like this hopefully conveys both that I'm aware that there's a gap in my understanding of the problem, not our solution to the problem, but still elicits a response more directed at my particular understanding. It's also easier for me to formulate what I don't understand as "here's what seems obvious, why is the solution different?" than "I don't understand this particular aspect", since I don't know the part of the solution to ask about.
When I first turned over my copy of the issue, I was holding the magazine by the corner exactly as one would hold a portrait iPad mini. In addition to showing the actual size, I think having it aligned with the edge of the magazine is meant to give the impression of holding an iPad.
Anecdotally, I thought the effect was neat, and spent a few more seconds than I otherwise would have on it.
If you stick to integer math with 64-bit floating point numbers, then everything actually works out pretty reasonably, since all 32-bit ints can be represented exactly as 64-bit floats (doubles). As long as you use floor/ceil/round where appropriate, you get most of the benefits of integer arithmetic, without the type checking (which you lose in a dynamic language anyways).
Some people feel strongly against this, but for dynamically typed language I enjoy its simplicity (for static languages, type systems are meant to enforce constraints on types, so multiple number types can be useful). It has done well in [at least] javascript and lua, and while the former is anything but an example in how to design a programming language, IMHO, the latter may be.
So no, it wouldn't be a bad idea to make all numbers 64-bit floats. It sounds like you might likely be compiling to javascript, in which case using 64-bit floats will mean you have one less problem to deal with while implementing it.
Yep, there's nothing preventing it, although I don't know enough about systems like Corona, Codea, or Moai to know whether you'd miss out on any IDE functionality. I'm currently using moonscript to power my side project on iOS. It's great!
Edit: Seems to be working now anyways :).