2048 in Erlang

- Given you've already compiled, you don't need the `rebar compile skip_deps=true` part to start the app -- that's just to recompile before you boot it, but I guess you knew that already.

- Eventually you get to look in releases, but they're a bit more complex. Look at http://relx.org for an easier way in. Releases will let your system know how to boot apps (so you don't have to `-eval` anything), and lets you pre-configure shell options (`-noshell -detached`) so that you can just boot the server with a `./_rel/bin/my-release` call.

- For information on supervisors and what things like `one_on_one` mean, see http://learnyousomeerlang.com/supervisors

- The naming convention for Erlang functions is `some_function`, not `someFunction`. This makes it easier to visually parse between variables (`SomeVal`) and functions (`some_function`).

- functions like `withinBounds({X, Y})` can be rewritten as `within_bounds({X,Y}) -> (X > 0), (X =< ?SIZE) andalso (Y > 0), (Y =< ?SIZE).` -- no need to pattern match there past the initial tuple. Remove the `_` matching, and just let it crash if something doesn't fit. You'll see it in logs (somewhere) and can fix it later.

- Functions like `getVector(up) -> {-1,0}` could easily be made declarative by using `vector(up) -> {-1,0}` or just `up() -> {-1,0}`.

- Break out large functions more. There's often no reason to have a 100+ lines function in Erlang. If you end up nesting `case` constructs more than two level deeps, start thinking about splitting the functions up and deferring stuff to other function calls. Your code will also be more testable that way, easier to reason about when something goes wrong, and easier to delete and refactor without breaking anything.

Good overview of how to get started with Erlang. Sometimes those that give it a first try are the best ones at writing a getting started guide.

> I'm not exactly sure what one_to_one is, but it works. It makes sense to look through Erlang documentation and find out the definition.

one_for_one just means that if one child of the supervisor dies, it will be restarted. There other choice is all_for_one, which means that if one child crashes, supervisor will restart all its children.

You can nest supervisors and create hierarchies of supervisors and workers and restart them as you need. Each process has an isolated heap (just like OS processes) and it will be neatly cleaned up by the garbage collector.

Essentially, it's what allows application:start(erl2048) to work. The {mod, {erl2048_app, []}} param is what indicates you want to run the code in erl2048_app.erl (though obviously the compiled beam file equivalent) as an application; the application behavior says that starting an application calls the equivalent start/# function.

So basically the order of startup when you call application:start(erl2048) is

Erlang looks for the munged erl2048.app.src, and loads that metadata.

The mod argument specifies a module to start.

The start function in that module is called (as it is expected to adhere to the application behavior). That function should start up the top level supervisor, which in turn is in charge of starting your entire supervisor heirarchy, and by extension, your actual worker processes.