- it might be easier to start your app with `application:ensure_all_started(erl2048)`. If your dependencies are well set in your app file, this will boot all dependencies for you.<p>- 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.<p>- Eventually you get to look in releases, but they're a bit more complex. Look at <a href="http://relx.org" rel="nofollow">http://relx.org</a> 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.<p>- For information on supervisors and what things like `one_on_one` mean, see <a href="http://learnyousomeerlang.com/supervisors" rel="nofollow">http://learnyousomeerlang.com/supervisors</a><p>- 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`).<p>- 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.<p>- Functions like `getVector(up) -> {-1,0}` could easily be made declarative by using `vector(up) -> {-1,0}` or just `up() -> {-1,0}`.<p>- 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.