tomg

Machinarium is a great game.

I would like to point out, however, that because it is Flash it saves your game state in an LFO. The datastore it uses is the same as Firefox, so if you clear your LFO cookies out of FF you'll delete your Machinarium saved game data.

Those are not bugs, IMO.

A lot of web Javascript would be useless if events didn't bubble, and being able to define invisible click areas is useful in a variety of contexts.

Sucks that a few people are going to be malicious about it but I think the benefits outweigh the drawbacks.

Amazon doesn't do much to filter out counterfeit items, it seems. From personal experience, a non-trivial number of shoe merchants on Amazon sell fakes.

Awesome. Never could get ruby-debug19 to work with my client's rails app anyway.

Short answer: No.

Long answer: They do not.

Great Firewall of America.

> I almost want to learn JS and Node to build a real one. Just to spite the OP.

I've been doing just that for the last couple weekends. You can see the work in progress at: http://okayarcade.com/everybody-shoot-everybody/

Note: The link will eventually die (since it's a really early iteration I quickly published when I saw this HN thread; you can't even shoot anyone else) when I take it back down. Uses ImpactJS, NodeJS, and Socket.IO.

edit: Controls: arrow keys = move;

edit 2: I'll probably be open sourcing the game (at least the non ImpactJS parts) once it's more production ready.

$('#toc').removeClass('sticky');

I keed, I keed...

Sidenote: A bunch of the code samples I checked out are ripped bit for bit from "JavaScript Patterns" by Stefanov (O'Reilly/Yahoo! Press). I recommend that book to any JS dev along with the famous "Javascript: The Good Parts".

Is the code available somewhere? I'm working on a somewhat similar game concept on an identical stack.

Oh, no, I just meant that most forms with a password field are either log on or sign up forms, which I wouldn't want to bother with preserving locally.

+ Ignore forms with a password field

Interesting... I was unaware that a relatively minor technical difference (browser POST vs. server side GET) mattered so much.

I wonder how Tumblr handles this. Pretty much every Tumblr blog I've stumbled on to contains full size copyrighted images re-hosted by Tumblr.

Nothing on the web should be construed as permanent. Even GOOG, MSFT, and YHOO drop products, change features, etc. It's a risk everyone has to analyse when choosing third-party vendors (GOOG now charges for Maps, for example, and look how many people are revamping their apps to not use them).

Both web and brick/mortar companies can suddenly close shop for a huge amount of reasons, and I have my doubts that "being so talented at what you do that you get bought out" is at the top of too many peoples' worry lists, IMO.

Not who you're replying to, but on my list:

CamelCase vs using-dashes is strictly a developer preference. I happen to agree with the author of the doc about using dashes, but I'm not going to call my preference a "best practice". A "best practice" might be more akin to "if you're working on an already in progress project, don't start doing CamelCase if they're using-dashes, or vice-versa", IMO.

Another controversial one is whether or not to have each style on it's own line, or in the same line. The author prefers a new line for each style because it makes for easier diff-ing in version control. The argument could be made, however, that this style introduces too much whitespace and vastly reduces the number of styles you can view at one time, not to mention increasing the linecount of your stylesheet by at least a factor of 3. Neither is, IMO, a "best practice", it's just a developer preference (IME most devs do agree with this doc, however).

There's some other stuff that really just boils down to how the author prefers to read his CSS, and not really about how to structure it in a proven optimal way. I believe it's hard to argue that those are "best practices", something Wikipedia describes as "consistently shown results superior to those achieved with other means". I would like to see the argument that lining up your -webkit prefixed styles achieves this, for example.

Anyway, IMO, a lot of the recommendations in the doc are good advice, just mixed in with some personal preferences. Like the author wrote though, it is his personal best practices, so in that context I suppose these are Best Practices, only the scope is limited to just the author.

Thanks for this post, it's very informative!

> There also should never be a rule about maximum length

What about hash collisions? Is there a good way to handle that?

"The iPad total package, hardware and software and price, represents the absolute best tablet you can buy."

"I have not yet had a chance to judge the new display myself."

What's the metric for "purely crap"?

Agreed.

I run a niche site used primarily by redditors, and IE usage is around 2%. A tech blog I write has around 4% IE usage.

However, Wikipedia reports about 30% of their users are on IE [1].

IE is on the decline but it can't be dismissed yet [2].

[1] http://en.wikipedia.org/wiki/Usage_share_of_web_browsers

[2] http://upload.wikimedia.org/wikipedia/commons/8/86/Usage_sha...

That's very true, and TBH I'm a bit surprised these banks are allowing that. IME doing frontend code for banks is that they're very strict on third party libs, even ones hosted by the bank itself, right down to only approving certain versions of the lib.

From what I know, PCI compliance is firstly, just a guideline. It's not like OSHA, but IANAL.

I also know there are "levels" of PCI compliance. The highest one, which reputable banks should be following, is very strict AFAIK, and includes provisions for controlling who has access to the physical hardware, encryption levels, etc. The fact that a Linode VPS can be 'rooted' via their management software by a sysadmin working for Linode would, from what I can tell, make them unqualified to be used to store banking transaction & customer data, though perhaps I am wrong.

Oh I don't doubt you. I'm not an expert on this, heck, I wasn't even allowed on to the actual servers (because of said compliance). I don't know the guidelines for login pages or what kind of security third party JS libs are supposed to have (also PCI is not a law, afaik).

What I'm asserting is that the servers that store the actual banking and customer data have very high security standards. It's one thing to store front end website code on a VPS, it's a totally other thing to store your database with customer & bank data on Linode.

The bitcoin breach seems analogous to Bank of America storing your account information on Linode and trusting it as the Real Data. Does that make sense?

In my experience working on a US financial website, a bank would never consider using a VPS like Linode to store actual banking and customer data. It's not even close to Level 1 PCI compliant.

I think disabling third-party cookies (via your browsers preference) would accomplish this (though it's no VM), with the added benefit of not needing to re-log in for each tab/window.

This doesn't, however, block all tracking scripts, as some may get your IP via an embedded 1x1 gif or other request. There's still the issues of super-cookies, or Flash cookies, or scripts that embed a unique image in your cache and then read it out, etc. So for this I recommend AdBlock or Ghostery.

Edit: Here's aseful link on this topic: http://samy.pl/evercookie/

> I assume that owning a business proper would require a ton of forms and licensing. But just doing odd jobs for oneself? I didn't think anything special was required.

You don't need anything at all to do odd jobs under a 1099. I probably should not have said "officially self-employed" as that isn't really a thing. I meant I've gone through the hoops to become a sole-proprietor business.

If you wanted to incorporate you basically just file a few forms and sign on a few lines. It does not involve a great deal of paperwork, and even that can be reduced to signing on a few lines if you use an accountant.

I'm not an expert but the reason that I believe a lot of people in your position (1099-ing it for N years) incorporate is three-fold:

First, liability. Your corp can get sued into bankruptcy but your personal assets are safe. If you're not incorporated someone can sue you directly with more disastrous results. I'm not a lawyer but this is what I'm lead to believe is the case.

Second, tax-wise it can be in your favor to be a corp.

Third, it just keeps everything separate. Having a company account that I can pay myself out of keeps my books clean.

As a chronically self-employed person, I'm curious why you believe it is so difficult to be self employed in the US. The World Bank lists the US as #4 on the Ease of Doing Business list [1].

Anecdotally, I've found it very easy to do the proper paperwork to become officially self-employed. For under a thousand bucks you can even have someone else do it for you if you're so inclined. Another personal example is how a man I met from Italy could not believe that I owned my own one-man business, as such a thing would be nearly impossible in his own country.

[1] http://en.wikipedia.org/wiki/Ease_of_Doing_Business_Index

> Why not start from a language that teaches the basics of the common programming paradigms, such as OOP (Java) or FP (Scheme)?

Because that stuff is boring and it drives away a bunch of people who might really get in to programming if there wasn't a huge gap between "just starting" and "doing anything remotely cool".

I for one would not have become a developer if my first experience with programming was a typical "CS101: Let's spend 3 months learning about loops" class, which unfortunately is many students first introduction. This class alone probably drives away half of the people who were interested in programming enough to take the class in the first place, which I find disturbing.

I spent a bunch of my free time as a kid making (really bad) web pages, (really bad) Javascript, and (really bad) PHP. Did I understand OOP, or how/why it's different than FP? Heck no. It wasn't until years later that I even took a programming course. But by the time I was ready to learn solid programming fundamentals, I'd already been bitten by the programming bug.

If I had to guess, I'd say this class is more about getting people interested in programming than it is intended to teach everything you Should Know. IMO, that's what a beginner course on any heavy material should be anyway.

Yes. I realized recently that a big reason I'd end up eventually drifting away from vim was the inconsistent vim config/plugin options on different machines (work, home, etc). Or worse, starting on a fresh environment and having none of my config/plugins available.

Now I've started to keep my vim config / plugin files in a git repo and deploy them whenever I'm on a new machine. Also as I'm slowly adding new functionality it gets reflected across all environments. I'm hoping this helps this time around.

> Today's professional musicians have to tour constantly to be profitable enough to survive, not to mention constantly churning out new tracks to remain relevant.

I think this is just the nature of the beast, so to speak. Due to the large number of musicians, the very, very low cost of recording a track, and the global, nearly free distribution channel of the Internet, the value of a pre-recorded piece of music is practically $0.

However, going to a show, seeing a real performance, feeling the music, etc etc, is still worth $10 a ticket to me, even for music that isn't particularly good. You can't copy/paste that experience on to someone else's iPod.