| z, ? | toggle help (this) |
| space, → | next slide |
| shift-space, ← | previous slide |
| d | toggle debug mode |
| ## <ret> | go to slide # |
| c, t | table of contents (vi) |
| f | toggle footer |
| r | reload slides |
| n | toggle notes |
| p | run preshow |
Hi everybody. Tonight I'm going to be talking about Quinto, a old board game that I've been developing on an online version of using Coffeescript and NodeJS with the Express web framework.
This presentation is going to have 3 main parts. First is a discussion of Quinto the game. Second is some pros and cons I've found when developing with Coffeescript compared to Javascript. Third is some pros and cons of developing with NodeJS and Express compared to Ruby and Sinatra or Rails.
Quinto is an old 3M board game that was released in the mid 1960's. There's not a lot of information about it online. I only know about it because I came across it in a thrift store and bought it for a few dollars. The simplest description of it is it is Scrabble with numbers and sums instead of letters and words.
Quinto is played on a 17x17 square board.
Each game is played with 90 tiles, with values on the tiles from 1 to 10.
There are only a few rules in Quinto.
The main rule is that each horizontal or vertical consecutive run of tiles must have the sum of the tiles equal a multiple of 5.
The secondary rule is that no more than 5 tiles may be placed consecutively.
The first move must include a tile in the center square.
All following moves must include a tile that is played adjacent to an existing tile.
At any point, you can pass instead of making a move.
Scoring is like Scrabble, in that you add the sums of all runs you have made or extended.
The game ends when there are no remaining tiles and one player is out of tiles in their rack.
Let's try a quick demo
The app is designed with 4 main parts: game logic, server logic, persistence logic, and client logic, all pure coffeescript files
I originally started developing the game as a command line program, so I worked on the game logic first.
My main design choice was to model the game as a sequence of states, with the last state being the current state of the game. This makes it so you don't have to worry about overwriting any information, on a move or pass, you just append the new state to the list of game states.
The server logic is just a bunch of routes that you can get or post to, and it's not very interesting. It's mostly gluing the game logic to the persistence logic and running commands based on user input.
I'm planning to enable multiple persistence schemes. I chose to do the simplest first, which is a simple directory tree of JSON files. PostgreSQL support is planned next, to make it easy to host on Heroku.
All client logic is in client.coffee. Quinto is designed as a single-page application. When the server starts up, it precompiles the quinto.coffee and client.coffee files into a single javascript file which is referenced in the index.html page.
As you saw in the demo, signup uses a password. We are using bcrypt password hashing, which is much more secure than using a standard cryptographic hash like sha1.
What probably wasn't obvious in the demo is that we are not using sessions or cookies. After logging in, each user is provided an API token, which they must send with all requests. Currently, the token is per user, but it could easily be made per user and per game later. This basically eliminates CSRF attacks.
Other than the initial html page, all server responses are a JSON array. Each entry in the array is an object with an action entry, describing the action to take. The client just does a loop over this array, with each action calling a method.
Currently, the client does simple old fashioned polling every 10 seconds for new data if it is not their turn. That could be switched to long polling or websockets in the future.
Most of the action handler methods just use standard JQuery for the DOM updates, though JQueryUI is also used for drag-drop.
Any questions about Quinto before I move on?
The rest of the presentation is going to be my general thoughts on Coffeescript and NodeJS. Cavaet Audiens is Latin for "Let the listener beware". I only have a few weeks of experience in using Coffeescript/NodeJS, so anything I say could be way off base.
I originally was going to give a single list of pros and cons, but I think that conflates two separate issues. The first issue is comparing coffeescript to javascript.
Let's start off with the pros. Coffeescript has a much nicer syntax than javascript, borrowing from both ruby and python. Unless you hate the idea of signficant indentation, you'll probably like Coffeescript syntax better. I used python before ruby, so it doesn't bother me.
Some nicities are using @ to refer to this.
The -> and => define functions. The difference is that the => changes @ to bind to the current value of this. This is sort of a con as it can get a little confusing, but it's needed in a lot of async code.
One of the biggest gains is not having to worry about using var for all variables and accidentally creating global variables.
Another niceity is list comprehensions, which work similar to the ones in python and simplify array processing.
Finally, another big gain is that everything is an expression, similar to ruby.
The main downside of Coffeescript is debugging code.
Backtraces in coffeescript code have javascript line information, instead of coffeescript line information, making them mostly useless.
You will pretty much have to read the compiled javascript in many cases to figure out your error. This is fairly easy if you are precompiling the coffeescript to serve to a browser (since Firebug/Chrome Inspector tools show the compiled output). However, for debugging server code, it usually requires a separate compilation step.
I think the syntax improvements outweigh the debugging pain, so I'd definitely use Coffeescript over Javascript in the future.
Like Coffeescript vs. Javascript, the choice to use NodeJS and Express compared to Ruby and Sinatra or Rails has some pros and cons.
In general, NodeJS is faster than ruby, and will probably scale farther on the same hardware.
However, that's the smaller of the two main benefits. The primary benefit is you can share code on the client and the server. This is a huge benefit, since otherwise you might have to write the same or similar code twice. In Quinto, it was important that the client have all of the game logic, so you could get an immediate response when planning moves.
- The biggest problem with NodeJS/Express is that you have to write everything in an async manner using nested callback functions, as NodeJS's synchronous IO functions block the entire process. This is incredibly painful, and I'll later conclude it is unnecessary. First, let me enumerate some problems.
With async code, you can't use throw for error handling. In fact, if you throw an exception in an async function on Express, it kills the server immediately.
To work around this, you have to thread the Express error handling function all the way to the lowest levels of the stack.
Because all potentially blocking calls need to take a callback function, you can't really mix IO code freely with Non-IO code.
One example of this is that you can't call IO functions in loops, you need to use recursion instead.
The inability to mix IO and non-IO code is similar to haskell, but without the benefits that haskell gives you like an IO monad that lets you write synchronous-style code.
Your NodeJS async code ends up looking like stair steps, since each IO method takes a separate nested callback.
The fundemental problem with NodeJS's design is that it conflates async with nonblocking. It would be much better if synchronous functions didn't block the whole process, instead just blocking the current coroutine/thread.
Basically, the synchronous functions should behave like the asynchronous functions, but instead of storing a callback function, it should store a continuation of the current state, so that when the IO completes, control returns to the caller of the function.
The reason most thread-based implementations are slow is mostly because they are preemptive instead of cooperative. Preemative handles worse case scenarios better, but is not good for high-performance. However, a cooperative thread approach can be as performant as an async approach, without the pain.
Computer science research done way back in the 70s by Lauer and Needham showed that threads and events are mathematically equivalent.
At the Usenix Conference in 2003, Rob von Behren, Jeremy Condit, and Eric Brewer presented a paper called "Why Events are a Bad Idea".
The paper describes the problems that event-based systems have, and how those problems can be basically fixed by using cooperative threading uses continuations.
As a case in point, the cooperative task
management technique described by [...]
allows users of an event system to write
thread-like code that gets transformed
into continuations around blocking calls.
In many cases, fixing the problems with
events is tantamount to switching to
threads.
The real truth is that async code is only needed when you want something running in parallel. Async code certainly requires nonblocking code, but nonblocking code should not require async code.
I'm guessing that almost all NodeJS async use is for nested callbacks executed in serial, and not for true parallel code.
The real object oriented way to handle parallel async code is to return a future. A future is an object that does the async processing in the background or when accessed, and becomes the result of the async computation when the async code returns.
In ruby, you can do this with lazy.rb or the promise gem, but it probably doesn't perform that well as it is implemented with ruby threads.
Using a language with built in futures would probably be better, and Clojure, IO, and Racket all have support built in.
It's hard to say. Even for a simple application like Quinto, the async stuff is a real pain, so I assume it's only worse in larger applications. I probably would only use NodeJS in the future if I had a real need for sharing code between the client and server.
Any final questions about coffeescript, NodeJS, Express, or Quinto?
Thank you very much for letting me present tonight. I'll be posting the code for quinto and this presentation on GitHub, and probably tweeting about it tomorrow.