NextLogic Singapore Blog

So the first public training is over now. I've learned a couple of things. I think this was one of the most difficult trainings I've ever been through – and even though it seems better after getting some distance there was definitely a few things we could have done better. What I really learned here is that even though Ruby on Rails is easy, it may be not so easy and really helps if you have a programming experience.

In any case here are the steps we covered in the first session. The whole point was to just get a basic scaffold running. There was a time I thought it was easy. I don't anymore :-).

1. Install everything - here's one way to do it on Windows - it worked on most of the machines but not all. Things to watch out for: in few cases ruby bin dir wasn't added to the path, in others Mysql wouldn't start yet in others Apache wouldn't start. Most of it were XP machines but I guess there were differences. As pretty much all of our development is done on Linux and MacOS I just have more experience with those platforms.
2. What you will need - 2 command prompt windows, text editor, mysql (or any other database) and browser
3. Create a directory for your applications - on Windows type this:

   cd c:\
   mkdir rails
   cd rails
   

   
   
   
   and here it is for MacOS / Linux:

   cd ~
   mkdir rails
   cd rails
   

   
   
   
   
4. Generate the basic application structure:

   rails test
   

   You should see a bunch of lines getting generated:
   
   As a result you should be able to see the following directory structure generated:
   
5. Change to the generated directory and start the server to see if we're good to go:

   ruby script/server
   

   You should see something like this - confirming that the server has been started:
   
   Now open up a browser and navigate to http://localhost:3000. You should see this page coming up:
   
   To stop the server you can press Ctr+C. To start it again just press arrow up which should repeat the last command (i.e. ruby script/server).

6. From now on we will be using the another command line window. Leave the server running in the first window.

7. Set up the database connection. The database connection parameters are set up in config/database.yml file. On most platforms it should be geneated properly, but on some you may have to add the host: localhost line. At the end it should look something like this
   
   
8. Now we can create a new database. Type this in the second command prompt window:

   			mysql -u root 
   			create database test_development;
   			create database test_test;
   			\q
   		

   You should see something like this:
   
   To verify that everything is okay run rake db:migrate and you shouldn't see any error messages. If you see warning about require_gem being obsolete - it's okay.
9. Now we generate some basic model:

   ruby script/generate model product
   

   
   
   
10. Create a Migration
    I will get to the whole migration concept in some future installments - for now just open up db/migrate/001_create_products.rb and add the following lines:
    

    class CreateProducts < ActiveRecord::Migration
      def self.up
        create_table :products do |t|
          t.column :name, :string
          t.column :description, :text
          t.column :price, :numeric
          t.column :image_url, :string
        end
      end
    
      def self.down
        drop_table :products
      end
    end
    
    

11. Now the hard part - run the migration. Running the migration will make the changes in the database. You will HAVE to have your database as well as database.yml properly set-up, otherwise this won't work.

    rake db:migrate
    

    If everything went well you should see something like this:
    
    
12. Create a controller.

    ruby script/generate controller products
    

    Just like always, you should see some lines informing you about the files being generated. Here are the new files that got generated:
    
    
13. Now just add this line to the generated controller so that it looks like this:

    class ProductsController < ApplicationController
      scaffold :product
    end
    		

14. And here we are :-) Navigate the browser to http://localhost:3000/products/list and you should see this:
    
    Go ahead and click on New and add a new product:
    
    
15. Now we've got the rice (or meat and potatos if you're from that culture) - now just make it look better. We'll add a very basic layout and some basic CSS. Both of them are from the Agile Web Development with Ruby on Rails book examples. You need to create a new file under app/views/layouts/application.rhtml and add the following to it:
    
    
    Get the Style Sheet Here
    And here's the end product:
    
    

And that's all. Easy or not - if you can do this you will be able to do anything. If you were not able to follow or the whole darn thing just wouldn't work - let me know where you had troubles.

It may seem like I have nothing much to do, but I volunteered for yet another cool initiative called code::XtremeApps:: competition. It's hard to say what was the main motivation – if the chance to promote Ruby on Rails or to promote software development as such. Either way – a nice challenge around here. Programmers in Singapore are generally in a very very low standing – possibly somewhere around a construction worker :-). The general position(ing) is that programming is a low level blue collar activity facing the same fate as manufacturing and should be outsourced to India, China and only “high level” jobs like sales and project management should be done here. While there's something to it, it's a little strange when most of the people I interviewed said they didn't really like IT and they'd studied computer science to become managers.

Considering this situation I couldn't believe the tremendous response this programming competition received. All our initial estimates were left far far behind – the number of participants for the competition itself, but even more for the accompanying trainings (both Ruby on Rails and Google Gadgets). The training capacity of 120 people was surpassed in less than 48 hours. As for the competition we had to almost double the capacity and as of today there's only a few places left. The training will be this Saturday 01/09/2007 – you can have a look at the agenda here. The training is specifically targeted at the competition participants. Unfortunately, we will have only 1 day and as the competition focus is on innovation and integration we will be mostly covering mostly more advanced topics like AJAX, mash ups and media integration. As such there will be only 3 hours to cover (or discover?) actual RoR framework. I will be doing this training with Choon Keat. It's been a great pleasure working with him as he's not only a great (RoR) programmer but turned out to be very helpful, resourceful and reliable in everything that needed to be done.

The second training is of a very different nature. It's much more in-depth – and much more pragmatic, focused on development of actual business applications rather then competition prototypes. It will be a 2 days training on 15-16/09/2007 and it will provide a much more intimate hands on experience. There's more information here.

The second training has been in the making for around a year now. I started working on it around the time I hit first difficulties when working with Changi Prison and I've been using and improving parts of it on pretty much all my one – to – one trainings. After writing the article about Changi Prison I received a lot of emails asking more about the experience, how it was different from my outside trainings and mostly about my motivation for doing something like that. Strangely enough, I had a strong dejavu experience 2 weeks ago – during the competition launch at SMU. The setting couldn't have been more different – yet somehow it brought back all my memories from my first trainings in prison. When I started my presentation more than 75% of the room (including me :-) was asleep. By the time I finished I don't think there was anybody there that wouldn't want to learn more about RoR or at least try it out. And I guess that is the answer. It's the energy of the people in front of you, their questions and their thirst for more. It's the transformation they go through learning from you and it's the transformation you go through learning from them.

And as much as it is a motivation – it's a responsibility.

This is a problem I've been (surprisingly) fighting with ever since I've been working with Ruby on Rails. Even though the situation has improved tremendously over the past 2 years it's still far from ideal. I am not sure if it's because insufficient demand or the increased complexity compared to hosting HTML or PHP the big hosting companies don't show much interest in Ruby hosting. Sure they list it as one of the options but the offer and support is flaky at best, many times offering only 1 rails application per account or missing ways to restart FCGI processes. Not surprisingly rails developers had to take the matter in their own hands and as a result almost any RoR hosting worth considering was started like that. I am not sure how much long term market sense it makes but looking at waiting time at slice host it really seems to be working for now.

When choosing RoR hosting the main decision you have to make is shared hosting vs. VPS. Shared hosting is usually cheaper and easier to set up but you're sharing the server with many other users and it takes only one bad neighbor to make the whole server unusable. VPS, on the other hand, is slightly more expensive and you have to set up everything your self. That gives you a lot of power and flexibility but you have to be able to configure Linux server (it's really no rocket science – there's plenty of How-To-s on the net – including this blog).

Shared Hosting

A few things to watch out for when choosing shared hosting:

1. FCGI support – most of the hosts offer FCGI (but there are still many that offer only CGI) including an easy way of restarting FCGI processes. You really don't want to open up a support ticket any time you update you application and especially not when you fix a very urgent bug.
2. 24/7 Support – while 24/7 support is claimed to be a standard in hosting industry I am yet to really find the host with this kind of support. That is not to say that the support doesn't matter – it really does and even if not 24/7 you should really test them out first – open up tickets outside of business hours, on public holidays, etc. and see the response time as well as helpfulness and professionalism. Many big hosting companies outsource their support offshore and all you'll get outside the working hours is “I will get a senior technician to look into the problem”. This is especially important if you're not in different timezone.
3. Number of applications you can host under one account. This includes number of domains, number of subdomains as well as number of databases that you can create. You don't have to worry that much about the actual limits of the server here because if you're not going to utilize the resources it doesn't make them available during peak, it just means that somebody else will.
4. DNS management tools / support. This is not so important if you have 1 application but as the number increases you will have to take care of multiple domains and multiple subdomains under each domain. With the standard shared hosting you will usually only get cPanel that lets you maintain only domains/subdomains hosting on the same server. Reseller account should come with WHM that has proper DNS management tool. Of course you have always option to host your DNS elsewhere.
5. Disk space / bandwidth limits. Usually not a problem with U.S. hosting but most of the hosting companies in Asia still offer 100MB accounts.
6. SSH. It's very hard if not impossible to set up your rails application without SSH access and yet I've seen several hosts (mostly in Asia) to offer ruby hosting without SSH. When I asked how to install the application they asked me for step by step instructions :-). I really don't think you want to do that.
7. SVN hosting – not crucial but a very nice bonus. It's beneficial even if you're a sole developer as it makes your repository available online. RailsPlayground.Com even bundles this with Trac.

Looking at the list seems like there's quite a few things to watch out for. From what I've used the best seems to be the RailsPlayground.Com. They have a very reasonable reasonable support, very few limits and offer quite interesting packages. The downside is that the servers do get overloaded sometimes and then they kill off your processes. This is really bad as the user will get a Rails Application Error but the Exception Notifier will not generate anything and there won't be anything in the logs. I've had several other issues there – longer HTTP POST will generate application error – again without any trace in logs and I had some intermittent problems with file upload / download. Other then that I would recommend them as most probably the best RoR shared hosting out there.

VPS Hosting

VPS experience a stellar launch to popularity over the past year solving most of the problems of shared hosting for only slightly higher price. It had an easy job replacing dedicated hosting offering roughly the same but for 10 times higher price.

Here are some things to watch out for:

1. 24/7 Support – even though it's all maintained by you and you're much less dependent on support, there still will be times when your VPS doesn't come back after restart or doesn't respond due to some runaway processes.
2. Choice of Linux distributions – many hosts offer a selection of distributions like Ubuntu, Debian, RedHat, etc. You just choose your desired flavor from the menu and it's automatically installed for you. It's really helpful when you have experience with only one Linux flavor or to synchronize your installations when you have multiple servers at several hosting companies.
3. Memory / Price ratio. The only important resource when choosing VPS is memory. Most of them come with sufficient disk space and run on multiprocessor machines but provide only limited memory. Anything below 256MB is not worth considering. You shouldn't pay more then US$ 29 for 256MB and usual price is around US$ 20. Some hosts provide burstable memory which means you can go over your memory limit if nobody else is using it. This can be very helpful during random hit surges or when processing memory extensive tasks. Be very careful as some of the hosts will mercilessly cut off any process that goes about the memory limit causing rails application error without any trace in logs (otherwise great VPSLink.com does that). Another thing to watch out for here is SWAP. While not ideal, it can save your ass during peak requests. Some hosts don't allow any SWAP which will cause your application to crawl when the memory limit is reached.
4. Scalability – check how easy it is to upgrade your account – either to increase memory or to add on another server. When number of users increases, adding another server is many times the only option to scale your application.

One of the best VPS providers is Slice Host providing all of the above for the lowest price on the market. So far, I've experienced only one short downtime. You can choose your Linux distribution, reinstall everything within a few minutes they have no nonsense policies, upgrades in both directions are painless. The only downside is a long waiting list if you're a new user. Another great host is Rose Hosting. They offer burstable memory and used to have very competitive pricing. I couldn't find any way to add another option to add servers to my account.

Some general things to watch out for:

1. cancellation policy. It's very important to read and understand it as most of the hosts have ridiculous cancellation policies – like you have to cancel at least 3 months ahead, or only 10 days before the end of the month or only on Monday, Wednesday and Sunday 3 – 4 am. Also, money back guarantee is much more a dream then reality.
2. Server location. Many people believe believe that the closer the server is to them the faster it is. I've heard many scientific explanations to this, but based on my experience there is usually no difference in access time unless it's on the same subnet (i.e. same provider) which is hardly a case. There is so many other factors (like aggregation, PC speed, last mile connection) that will affect the actual speed that for me it doesn't make any difference in speed for my servers located in the U.S. and servers located in Singapore. The problem with local (Singaporean, Malaysian :-) hosting is that it's several times more expensive, provides several times less resources (like space, bandwidth, memory, etc.) and only 9 – 5 support. I believe this is due to lack of local competition, lack of market awareness and undue local patriotism. Anyways, ...
3. Backup – some hosts provide automatic backup for very reasonable price (e.g. Slice Host offers images for US$ 5). While most of the hosts claim to have auto backup it happened to me several times that it took them 2 days to retrieve this backup. As such you should think of your own back up strategy – one of the ways is to use Amazons AWS. Most of our customers require direct access to back up files and recovery within 30 minutes (this means that no matter what happens we have to be able get back online within 30 minutes). Another issue is frequency of back up – most of the auto back up is daily, which is far too little for any production application. Our standard is hourly backup with possibility to increase this during peak hours.

I finished my first commercial Ruby on Rails application in October 2005 and I've been using it ever since. For most of this time, we've been one of the very very few offering Ruby on Rails in Singapore. Most of our customers are not exactly technical so they wouldn't really care even if we used Cobol :-). What they did care about was the price and delivery time. I don't know why, but writing about advantages of Ruby (and Ruby on Rails) comes very unnatural to me. It feels like saying what everybody knows. At the very minimum, most of the technical people have heard about it – whether they like it or hate it at least the don't go like “You're programming in WHAT???”

The situation seems to be turning even in this part of the world. Thanks to Ruby brigade I met a handful of Ruby on Rails programmers and a few handfuls of wannabes. After almost 2 years in isolation it was really great to see and meet Ruby programmers (other then my own trainees and employees :-). While all this was nice, what really made an impact was ever increasing demand for corporate training. More and more big companies approach me with corporate trainings. The reason is simple...as many are parts of global corporations, many of their internal systems were created elsewhere and now they need a local support. It may come as a shock that MNCs use other systems than just SAP, but it seems to be easier and way cheaper to use a few smaller, independent systems for handling a portion of daily operation.

I started my first Ruby course in April 2005 and for the past 6 months I spent roughly 40% of my time doing training. This has been a major shift for me as only as recently as 1 year back I spent around 90% programming and only 10% on other stuff. I started training in Changi prison and it's almost unbelievable how rewarding this experience has been. I cannot even describe how much the guys have changed. When I walked there the first time I sure saw the potential – around 30 guys doing (or more fighting) with every possible limitation you can think of but still determined to succeed. It may be an old truth that you will appreciate the value of something only after you've lost it but it's really valid. All of the ubiquitous things like Internet connection, access to new books, access to community support (reading the posts or posting questions) – all this is off limits in prison. And yet I didn't find any surviving broken existence in there. So many times I have wished my own employees showed half of the determination, zeal and persistence I could see in there. The more you have, the more you start taking things for granted and the more comfortable you become.

What I felt the guys needed was just better resources and some direction (IT wise). We went through some really tough time – I still remember explaining recursion for the whole Sunday, OOP, TDD and many other things. Well, none of them had any prior formal IT education. But then, maybe it was more to their advantage. Most of the time I find it much harder to work with computer science graduates than with people who never studied IT but have some logical and mathematical thinking. It's surprising how difficult it is to unlearn all the coding cowboy habits as opposed to just starting afresh. This is not to say that OOP or Ruby or design patterns or TDD or agile methodologies or anything else I do is the only way (or that it's correct at all). It's just one of the ways and the one I happened (in reality it took much more then just happen :-) to believe in – but more about that in my other blog posts. Anyway, it's really great to walk in there now. It's completely a different crowd – you see people being able to think, to analyze and to even transform all that into a working product. Sure it's not all wine and roses...but I would really like to see this kind of commitment in many other organizations I worked with.

I realized much of this when talking to people at one of the Ruby Brigade meetings. That's when I realized that I may be running quite a tight ship in regards to development principles – but so far I've really appreciated that nobody on my staff would say things like: “I do tests only when I feel like”, “I've never been into testing much”, “We do bug driven development”, “What's that 'assert' thing mean?” and many others.

To conclude with, I must say that I have always been an extremely fast learner – I've never had problem to learn anything but it's a completely different ball game to teach what you know. One thing is to look at something and understand it and a completely different one is to explain it to somebody else. And I really love it :-). And it finally gives me a reason to start working on my e-learning platform I've been planning since high school.