I can't believe I used to SSH into my server to restart an app when I can now just run `cap unicorn_APPNAME:restart`
We also used to SSH into our servers and do everything manually. Crazy times.
Seems to work so far -- any reason why I might want to be using a more advanced tool instead?
Of course, when doing releases that affect the database schema, we still have to login to the servers.
[1] https://gist.github.com/4281277 [2] https://github.com/mscdex/ssh2
1. Tests are essential in any project using a dynamic language; but don't write regular unit tests. Instead write a setup script. A script that sets up basic data in the store by calling various APIs. For example, setup your test users POSTing to /users. Whenever you need to go back to a clean database (which is, often) you can run this script. And of course, every time you want to test all the APIs.
2. Automate everything in scripts. Script your compile, test and deploy steps. Script emailing. Script your database backups, tar your image folders.
3. Refactor every time you get a chance. It is like having a bath. You feel like working on your app, code feels fresh.
4. Optionally, try coffeescript. The language often promotes good, declarative programming. Once you get used to the shorthand, you won't go back. Don't discard it after spending a couple of days on it; it might take a little longer depending on your experience level. Another minor benefit, since there is a compile step some typos are picked up by the compiler.
5. One of the big benefits of Node is that you could move things like rendering from server to the client (or the other way round) relatively easily. But still it is cleaner to just have REST services on the server and handle rendering on the client (with say, Backbone).
This will solve the issues you'll run into later such as
* SEO - search engines won't read empty pages (you can get around this with some hacks) * Performance - loading a full page is always much, much faster than loading half a page, downloading javascript, parsing javascript, sending off multiple ajax requests for data, and then finally rendering the first page * Accessibility - a version of your site that works without javascript is not only easy to build, but is easier for machine reading * Development cleanliness - building your site in layers (html / http only, layer on css, layer on more advanced css, layer on javascript) keeps your code from becoming too tightly coupled and is much easier to work with. Plus, this makes it much easier to work with less advanced browsers
It's actually quite simple to do, especially with node, where you can share functions to format data, or even run the same framework on both side if you decouple your code (Backbone's latest change to help abstract Ajax seems like a step in this direction.)
I've tried coffeescript but it didn't catch on with me. Perhaps I didn't give it enough time, but I got the feeling that it could get quite semantically ambiguous at times whereas if you stick to JS' native C-style form, the structure of the code is imperative and easy to follow. I also felt uneasy about what code was actually executing at the other end of the transpiler.
Give it more time, the gains for CS are worth any negatives you can conjure up. do ->, classes, simple for loops, equality, etc.
I also tie the worker PID to each user's session, so they can't spawn an infinite number of workers and cause serious strain on the server -- the server just kills the previous worker and spawns a new one if it's asked to run the function again.
I was actually thinking about opensourcing this, but I guess it's pointless now that domains basically do what I hacked together.
Downside: expensive
