I am currently looking into DI for javascript objects, as well as phantom.js and jasmine-jquery to start putting together some examples for user journey testing and easier testing of jquery widgets and fixture loading.

With Node.js installed grab the following modules using npm

• coffee-script
• jasmine-node

Easiest way to get tests running type 'node ./spec.js ' at the command line, which is pointing to ./spec/ folder

In my BlogSpec.js file let's start with some basic tests

When you run the spec with : 'node-blog git:(master) ✗ node spec.js' the test should fail

So everything is as expected at this stage, let's start work on getting the basic tests to pass. First off let's create out Blog object

And not let's bring the Blog object into our test and initialise it:

Now let's get the first test to pass, by editing our Blog.js file

Nearly there, only problem is that our second test is failing because we require a title to not be null.

Let's see what the output looks like:

And just because I can, let's rewrite the Blog.js in Coffee Script:

How much terser is that?

The git integration shown in the above screenshot is just is the icing on the cake, seriously worth spending some time on this if you spend any length of time at the Terminal.

I am disappointed that this is turned on by default, not so much for myself as I find the information interesting, but it's always best to ask first, right? I know plenty of people who are very sensitive about this type of information. And apparently I don't venture to far north of the river either.

You will get something like the following:

Then you can start drilling down the folders until you find the exact culprit. In my case a log file had grown to 8 Gig in size.

1. spawn-fcgi: there's a package for it so I just used that :
   PLAIN TEXT
   CODE:

   1. sudo apt-get install spawn-fcgi

2. the stop/start script complained when adding it to the boot/shutdown cycle, but one posted in the comments worked:
   PLAIN TEXT
   CODE:

   1. #!/bin/bash
   2. ### BEGIN INIT INFO
   3. # Provides: php-fastcgi
   4. # Required-Start: $all
   5. # Required-Stop: $all
   6. # Default-Start: 2 3 4 5
   7. # Default-Stop: 0 1 6
   8. # Short-Description: starts the php-fastcgi process
   9. # Description: starts php-fastcgi using start-stop-daemon
   10. ### END INIT INFO
   11. PHP_SCRIPT=/usr/bin/php-fastcgi
   12. FASTCGI_USER=www-data
   13. RETVAL=0
   14. case "$1" in
   15. start)
   16. su - $FASTCGI_USER -c $PHP_SCRIPT
   17. RETVAL=$?
   18. ;;
   19. stop)
   20. killall -9 php5-cgi
   21. RETVAL=$?
   22. ;;
   23. restart)
   24. killall -9 php5-cgi
   25. su - $FASTCGI_USER -c $PHP_SCRIPT
   26. RETVAL=$?
   27. ;;
   28. *)
   29. echo "Usage: php-fastcgi {start|stop|restart}"
   30. exit 1
   31. ;;
   32. esac
   33. exit $RETVAL

3. Next to stop Apache from starting up run:
   PLAIN TEXT
   CODE:

   1. sudo update-rc.d -f apache2 remove

4. On the rewrite front, I needed to add the following to my virtual host configuration to have those seo friendly urls up and running again:
   PLAIN TEXT
   CODE:

   1. try_files $uri $uri/ /index.php;

The first function takes an array of PDF documents and merges them into one. This was handy when different pages for a report had different styling requirements (such a full background colouring bleeding across the margins)

The second function stamps a pdf document over another pdf document at certain position. I needed this for a document that had a table dynamically generated that spanned multiple pages and I wanted the footer to not overlap the table content (I could not figure out how to use a css based solution because of the margins).

Anyway maybe somebody else will find these handy.

Over the course of a few evening I knocked up a working demo using Rails and Tropo, that can dial our AVM using Skype. If you'd like to give it a whirl dial this number using Skype: +990009369991484011, select option 1 and then enter 8633100 followed by the hash (#) key. The resulting text to speech is a little rough, but pretty cool none the less I thought.

If I can I'll post the sample code up to github in the near future.

• Use Git
• Build it using tests (Rspec)
• and conversely take a look at BBD
• Refactor common elements using partials
• Have fun

Heroku came along after the initial build because my server seemed to struggle serving the app using a combination of Apache and Passenger Phusion (looks like I need more RAM...). Overall the experience has simply put been great. Building an app using the Ruby and Rails toolset is just a pleasure. RVM for ruby version management, Bundler for Gem management, autotest for continuous background tests, easy deployment with Git integration. Compared to the CF world I am in [big caveat this might not be true for you], the rails ecosystm is incredibly rich, well documented, functional and fun.

I started off by following the Rails guide over at Rails Tutorial and borrowed the set up to get started. After creating my project, the first thing I got to grips with was getting Git set up. I use both a local repository and a remote one over at Github, Knowing that your code is versioned in two places is quite a comfort and I have since started using it for absolutely everything locally and have pushed a few other projects (terribly old projects that I am a little embarrassed about, but being the sentimental individual didn't want to loose) on to Github.

Then came setting up autotest, having this run in the background with Growl integration gives you instant notification that your tests are passing or failing whenever you save a file. This is so incredibly useful and responsive. I really love the continuous testing nature of this setup.

Given the nature of the site, the coding part was easy-ish and I am sure there are a plenty of things I have done like a noob.

Where all this really comes to shine is during deployment time. I opted for Heroku, it wasn't so much a choice as a case of I'd be stupid not to. The documentation for signing up and getting started is first class (as it is with Github by the way). Once you have your account, created your app and linked it to your git repository, deploying your code is a simple case of typing:

From then on in, you just watch the code being checked out, gem dependency being resolved and your app launching. Knowing that your site is Ok thanks to your tests, the one line deployment command is pure joy.

To give you an indication of how great this setup is, consider that I decided to switch from erb files to Haml. I spent a few hours reading up and converting my erb files over, while having autotest running showing me where things were breaking (due to my lack of knowledge of the new syntax) or working. Then pushing changes into Git. I confess I had also cast my eye over the resulting output (old habits die hard ) and finally running a one line deployment to Heroku. Job done and once again a pleasure and full of confidence about the result.

Where there any downsides? Well not downsides, but hiccups, wrapping my head around RVM and gem management was a bit bewildering especially when some gems were being used unexpectedly, the problem lay with what's between the chair and the keyboard. Some of the RSpec view testing tripped me up. When you decide to test the content of views, eg:

Don't forget to include render_views after your describe statement for the controller, or else your tests will fail and you will be be scratching your head as to why that is the case. :S

There's a lot to take in and it is a little overwhelming when things do not work as intended, but the information to resolve these is out there and with a careful reading of the error messages it does not take very long to figure out.