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).

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.

[1]: https://www.khanacademy.org/test-prep/sat

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 had a friend in college who used to use this, as well as "...is left as an exercise to the reader" on homework assignments, to my great amusement.

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!

The lua ecosystem is extremely simple to embed in a native application, which, as someone who has had to do it, is something that feels underappreciated. Python and javascript were harder to set up for embedding on the same computer, and all but impossible to cross-compile for iOS. The simplicity of using lua as a scripting language in larger applications makes it a great target for compilation.

MoonScript also gets rid of a lot of the more verbose parts of lua, and replaces them with CoffeeScript-like versions. For example: shorter anonymous function syntax, syntactically significant whitespace, default local variables.

Cool! I was aware that variable reassignment didn't carry over in for loops, but I didn't know that the variables in each iteration were independent.

Keep up the good work!

It's great to see more development of the language! MoonScript is great if you're looking for the niceness of CoffeeScript in an embedded environment (Lua's semantics also behave more sanely than Javascript's). I have roughly 5000 lines of MoonScript powering my side project [1], and it's been a pleasure to write.

Any thoughts of letting the 'do' keyword support coffeescript-style 'do' semantics as well? Invoking a multi-line anonymous function is currently a bit impractical, and allowing do to invoke a single function parameter would make that a lot nicer, and allow for capturing variable's in a closure more easily. Example from the coffeescript docs:

  for filename in list
    do (filename) ->
      fs.readFile filename, (err, contents) ->
        compile filename, contents.toString()

[1] http://www.codingspellbook.com/

I could go on about my opinion on this for a while, but to keep it short [edit, ok, maybe I failed at "short"]:

- If you like programming/CS, then studying CS in college can be fun (once you figure out if you're more into programming or theory you can take more systems or theory courses as appropriate).

- Having a degree will never harm your chances at a company, and can be seen as a legitimizing factor at many [usually larger] companies. If things ever go south, getting a job at a bigger company will be much easier.

- You learn a lot in a short time at university. A lot of this will be the type of things often asked in technical interviews, so it will generally make getting a job in the future easier (the CS interview process can be a little biased toward college type questions rather than industry type questions. Whether the system is broken is another topic). You will learn things in industry too, but if you stay in college you'll still learn them, just later. If you drop out, you might always wonder what topics you're missing out on.

- I don't feel like you're delaying your life by attending university, as that's generally what people expect you to do with the four years after high school, IMO.

As to how useful university has been, I found it very useful. But university, like many things, is what you make of it. It can be useless or very useful or somewhere in-between depending on what you do while there (what classes you take, what projects you work on in your spare time, possibly what clubs you find a fit in).

I've technically been in that situation, and my manager at the time encouraged me to finish my degree. But take this with a grain of salt; I would have finished my degree regardless of what anybody said at that point.

You have a better idea than anyone else of what's best for you, and you should make this decision, if it comes up, at the end of your internship rather than now. But I generally encourage people in CS to get their degree.

If you have any questions related to that, I'd be happy to answer them.

+1 love, love, love the simplicity of the Lua language. If I were teaching introductory programming it would be high on my list of languages to consider.

(I wish its syntax was a little less verbose, but that's why I use http://moonscript.org (like coffeescript for lua) right now, although the compiler has some rough edges and looks like it hasn't received much attention for awhile).