deoxxa

I've had a lot of success with embedding initial content for a page as JSON in a script tag with a specific ID and a type of "application/json". This way you can rely on the content being there and sidestep the whole timing issue completely. You can potentially speed up your loading time as well, if you have a bunch of things you'd usually fire additional requests off for.

I believe I got this idea from Backbone's documentation [1] originally, but I've seen it mentioned in other places as well.

[1]: http://backbonejs.org/#FAQ-bootstrap

Why do you run ssh on a non-default port?

There are... Just so many open source web applications that aren't written in PHP. So, so many.

I hope this doesn't sound snarky or mean, but you might want to run a spell checker over your posts in the future. Some of the errors stood out strongly enough that they really interrupted the flow of the writing (which was otherwise structured quite nicely.)

I get the feeling it would cost more to hire developers who can wrap their heads around performance sensitivities in JavaScript and WebGL than it would to hire, say, C++ developers who've read the OGRE manual.

Unfortunately, I don't think it was a joke. Such negative, very disappoint.

Yeah, I was really expecting it to end with "so here's what I'm going to do to try to make the situation better," instead of "HA HA DELICIOUS TEARS."

EC2 for some things, dedicated hardware for some others.

Where it sits, however, is only part of the problem!

I use plz[1] and instagit[2] in tandem via post-receive hooks to do the "deployment" bit, along with a service registry (closed-source, written on work time, boo!) like seaport[3] and a proxy based on httppp[4] to route requests to the right application.

---

1. https://github.com/deoxxa/plz

2. https://github.com/deoxxa/instagit

3. https://github.com/substack/seaport

4. https://github.com/deoxxa/httppp

That's already a thing, if I understand what you're asking - see the <keygen> tag.

1kb/s is an absolute surplus in a lot of machine-to-machine applications. With a lot of embedded sensors and such that run over cellular networks, carriage is billed by the kilobyte, to illustrate that point.

I've always found that interesting. Sometimes you look at a dollar and think "where has this been?" - with bitcoin you can answer that question as far back as "who created this money" (to various degrees of pleasure or dismay.)

That makes a lot of sense, I hadn't thought about that.

100% agree with this. I got kicked out of a game because of "network issues" last night and when I logged back in, the city I'd spent a good 40 minutes starting up was nowhere to be found. It did, however, remember that I'd claimed that city.

More surprising again is that they actually have three completely active (as far as I can tell) environments that are just sitting there unused.

I kind of started poking around at the backend protocol this morning. It's all websockets over HTTPS (very trendy stuff) and is hosted on EC2. I'm yet to dig much further than "let's see what this looks like in wireshark", but the behaviour and some of the errors I've observed in-game point to some kind of sync-every-now-and-then architecture. I wouldn't be surprised if it was really easy to do up a custom server for it.

I'm going to keep poking at this thing, so I'll document what I find here: https://gist.github.com/deoxxa/5111644 - feel free to join in!

Clearly you're scamming suckers into being better people and giving to society. I commend you, you monster.

I'm really hoping the irony of linking to a CoffeeScript-generated JavaScript file and using it as an example of properly-written JavaScript was at least part of the joke here.

Very, very rarely. Along with "now you can get your frontend developers to write backend code!", it's one of those oft-cited but spectacularly bad reasons to start using JavaScript for non-client stuff.

In saying this, I use node for a heck of a lot at work, but that's mostly because some of the workflows available (streams and events specifically) are perfectly suited to the programs I write in it; not because it lets jQuery monkeys crank out substandard backend code.

What? That's the complete opposite of what OP was saying.

You don't need github to be online to work with your code or even your repositories so long as you haven't gone and thrown all your digital eggs in the same basket (i.e. as long as you have other remotes or at least local copies of your repositories).

Why was the title changed to say "CapsLockScript"? I can't see it ever referred to as that in the actual documentation.

It's mainly just slow - the whole set of code has to be parsed, processed, validated, run, etc every time it's used.

It's not insecure in this usage (even if it were used on the client), as all the actual code is generated by uglify-js via an AST and it takes care of properly escaping everything.

The only thing I'm really taking from the django system is the syntax and some of the concepts. As far as I know, it's implemented completely differently. Very simple django/jinja2 templates will compile with Ginger, but the functionality is designed to be closer to Twig than anything.

It's definitely evil, when it's used at runtime. In general (non-testing) usage, it would be written out to a file after compilation and there'd be no eval() action at runtime.

That's not an unfair comparison at all - indexing the data in a JSON blob is entirely possible and practical.