Where Ruby leads, others follow…
In response to the question and comments on a recent linked in post discussing the suitability of various web platforms, including Ruby on Rails...
The first big decision
Firstly, whatever you choose, I would suggest using a platform that is Open Source. This means that the stack is effectively commoditised - giving access to a high quality platform that keeps your costs low today and into the future as you scale out and avoid being locked into the release cycle of one particular vendor. A big plus is that anytime you hit a problem, your engineers can drill right down into platform to diagnose and resolve it. This is a formula that's worked for for Google, Groupon, Amazon, Twitter and Facebook to mention a few.
Enter Ruby
I am of the opinion that Ruby and Rails is the likely the best web framework to use to build the vast majority of web applications out there. Since it's release, Rails has lead the way in terms of web development - promoting the Model-View-Controller pattern in a simple, easy-to-use manner as a way of creating web applications. Whilst that pattern has been around for a while Rails really put it on the radar for web apps. Along with it came a shift from unpopular SOAP webservices to a RESTful service architecture. And so too did easy to use AJAX techniques for building richer UI's because Rails bundled the Prototype library with it from an early stage. Rails has since continued to lead by incorporating the latest Javascript technologies into its ecosystem - such as node.js.
Dynamic Language = Dynamic Business
Because of the dynamic nature of the language, its strong use of conventions and the style of Ruby developers, you end up having much less code in your application. This win in terms of a smaller codebase is also true of projects developed using other dynamic languages such as Python. A smaller codebase has the usual touted benefits in terms of rapid development times and a more easily managed codebase. In particular, less boilerplate code.
Using dynamic over static typing means that you have to have to write automated tests to cover your code. Some developers disagree with dynamic typing and say that the compile time checking of a static language is important. In my experience, this is not so. By writing automated tests to cover business cases I've found that I catch a much more important class over of errors - business logic issues - while also covering the code paths for the edge cases that the static compiler would have checked. One of the ways static languages try to provide some of the flexibility of dynamic languages is through generics. This quickly leads to a type of complexity which I have found is much better, and more clearly handled, using a dynamic language. The clarity of the code, the ease of testing and the expressiveness and power of a language like Ruby has firmed up my thinking on this area. As a platform which has baked testing right into the core of its ethos, Ruby and Rails has lead the way in terms of integrating automated test frameworks into the developer's workflow. And a higher level, it has made it possible to bring business stakeholders and development teams together by introducing tools that allow one to express business features in terms that can easily be discussed with, implemented and tested by a developer. Cucumber is probably the best example of this, which like many other Ruby projects has caused a massive stir in the web community.
And the bad news...
So what are the pitfalls. I'd agree that it is harder to find Ruby developers. Whilst many top tech locations have a massive amount of Ruby developers - such as San Fran or London - Ireland doesn't have those numbers. This is partially because we have lagged behind the technology curve a little in the past. But I'm happy to say that this is something that has changed immeasurably over the last couple of years. There is a lot more developer meetings and grassroots activity, predominantly in those with an Open Source slant. This is a good news story not just for Ruby, but for the whole Irish tech sector. And I'm sure that strong confident Irish companies will emerge as a result.
Some companies do decide that certain parts of their solution are best written in a different language. There are some well tried paths to doing this with Ruby. For example, you can use JRuby to easily farm out some parts of your codebase to Java while retaining development agility for the rest of your codebase by keeping it in Ruby. However, needing to do this is very much the exception rather than the norm.
Building services and deployment
You indicated that you will be writing a service rather than a full fledged web application - another option you could consider is using the Ruby-based Sinatra as your web framework instead of Rails - which is a thinner layer, which some people prefer for building services such as github. That said, I would still personally go with Rails as there are more tutorials and guides available - particularly if it is your companies first time working with Ruby.
For deployment, Heroku makes developing and deploying Ruby apps a breeze. It really is an exceptional platform which sits on top of Amazon's AWS. I would recommend taking a serious look at it at http://www.heroku.com before making a decision on which platform to choose.
So, all in all, my long standing impression of Ruby and Rails is that it is web development done right. It has been the leader in pushing forward how developers and businesses develop websites and consigned the sprawling mess that existed before it to history. In the meantime other platforms have tried to copy some of its features, often less elegantly. As the same time Rails has accelerated the rate at which it pushes forward the web - the next release Rails 3.1 is breathtaking in its feature list.
For these reasons I think Ruby is 'the' web development language of the next decade. Whatever you decide, all the best with your venture. There are plenty of excellent platforms out there to choose from so it's a great time to be building the kind of high-scale web applications and services.
Bundler installing gems into the wrong directory – mea culpa
So I spent an hour and a half last night unfairly swearing at the spork gem; and blaming it for everything from world hunger to banking crises! This is because somehow when installing spork I had managed to change the location that bundler installs gems into - strangely enough into a directory called ./spork under my project directory. And I figured the blame landed at the door of the spork gem. Here's what happened just so that you don't get caught out.
Once installed, here's how you start up spork: bundle exec spork
But, at some point, here's what I did by accident: bundle install spork
Fool! Fool! Fool! For those of you that aren't familiar with the 'path' argument to bundler, well, what it does is permanently change your path to the value you specify. So for an hour and a half last night, I had ./spork set as my gem directory. Meaning that my furious efforts to correct the problem were in vain - such as clearing out all the gems and reinstalling, grepping for a config file that could be pointing at ./spork in my project and rvm directories.
What I should have done to fix this problem immediately, was to tell bundler to use my standard rvm directory for gems again
bundle install --system
Ta da!
It's pretty confusing that specifying a path argument once off should cause bundler to change it behaviour on a permanent basis but at least I notice that in the docs it says
The path argument to 'bundle install' is deprecated. It will be removed in version 1.1. Please use 'bundle install --path spork' instead.
So I guess I'm not the only one who's hit this confusing behaviour. Long live the --path option!
Sorry spork, I'm a dork...
Machinist 2 and the undefined method for Sham:Module error
This ain't no Sham marriage! Machinist 2 has done away with the Sham module. But, at time of writing, this isn't immediately obvious from the installation guide. So if you try to horseshoe your Machinist 1 (Sham-based) tests into Machinist 2 then you'll find you get an error like
/home/you/dev/rails/my_project/spec/support/blueprints.rb:5:in `
The solution is to use the new serial_number() method technique instead. For more info on what's in Machinist 2 check out the What's new in Machinist 2 page.
A short post but hopefully it helps someone. Mock on!
Push and pull data between your local MongoDB and Heroku or MongoHQ
Heroku do a great job of providing a free way to host MongoDB. The only slight issue I had was syncing data between my machine and my Heroku apps - in the way I was used to with their Taps plugin which works for Postgres databases. But here's how to do it for MongoDB. Note, I was using it with a Rails 3 and Ruby 1.9.2 app.
Firstly you need to get Pedro Belo's super plugin heroku-mongo-sync . The docs say that the default way to use it is just to do a 'heroku mongo:push' or 'heroku mongo:pull' from inside your app directory on your machine. But this takes the name of your app exactly and assumes that this is the name of your mongo database. Unfortunately, many people like to call their database something else - and even the default is yourappname_development which won't work (it must be 'yourappname' exactly).
A feature allowing you to specify a MONGO_URL shell variable that will let you override this is in the README. Sadly it didn't work for me. But help is at hand - we can just create a new enviroment for syncing and then specify the database we need as the default. Of course you don't have to do this if your database is actually exactly the same as your app already; though the following approach may still serve you well as a workflow
* Pre-requiste, you must have an account setup on MongoHQ for this to work. And see here for how to setup MongoDB on Heroku
* Copy your config/development.rb to config/sync.rb
* Ok, I'm using Mongoid. Here's how I define my db connection to be exactly the same as my app's name in my config/mongoid.yml file
sync:
<<: *defaults
database: yourappname
* Whenver you want to push or pull to Heroku just change the default Rails environment at the top of your config/application.rb file to be 'sync'
require File.expand_path('../boot', __FILE__)
ENV['RAILS_ENV'] = 'sync'
* Now from the command line, you should find 'heroku mongo:push' and 'heroku mongo:pull' work like a dream. Ahoy, me mongols!
Installing Ruby on Rails on MeeGo with SQLite
This post will go through installing Ruby on Rails 2.3.2 on MeeGo - though it should likely work for any version of Rails, including Rails 3 (though the actual Rails commands at the end of this guide will be a little different). Firstly go through the Installing Ruby and Rubygems on MeeGo guide to get at least Ruby 1.8.7 on your system and then carry out the following steps.
PRE-REQUISITES
* The above guide requires you to disable the core repository and then enable the devel and testing repositories. I found that when following the below steps, I would get an error trying to install sqlite3 gem itself - saying that the sqlite3.h header could not be found. I had to run the following commands first
# Update all packages on the system
sudo zypper update
# Then the chrome browser would not work saying
[declan@declan-desktop grr]$ chromium-browser/usr/lib/chromium-browser/chromium-browser: error while loading shared libraries: libicuuc.so.42: cannot open shared object file: No such file or directory
# To fix this, I had to update chromium-browser separately
sudo zypper update chromium
Ok, so onto the actual install steps for Rails and SQLite3...
RAILS INSTALLATION
#Install ruby and sqlite development headers (as we'll be using sqlite as our backend)
sudo zypper install ruby-devel
sudo zypper install sqlite-devel
# Install tools for building C-based gems
sudo zypper install make # Not 100% sure that make is needed
sudo zypper install gcc
# Install sqlite3 gem for ruby
sudo zypper install sqlite3-ruby
# Install Rails
sudo gem install rails -v 2.3.2
# Create a new Rails application
rails grr
# Create a thing (ok, more correctly called a resource) in Rails
cd grr
./script/generate Animal name:string
# Create the database
rake db:migrate
# Fire up the Rails web server
./script/server
# And then browse to your site in the web browser - http://localhost:3000/animals
Hurrah! Everything works! (At least I hope it did!). Happy Rails development!
How to localize model names in ActiveRecord associations via config locales with Ruby on Rails
Argghhh!!! I went bananas for a little while getting my head around this. What are we trying to achieve? Well, say let's we have a model called Consultant which has a many-to-many relationship with Company though a Contract association. The Contract model is basically sitting on topic of a simple join in the database which has consultant_id and and company_id fields.
class Consultant < ActiveRecord::Base
has_many :contracts
has_many :companies, :through => :contracts
accepts_nested_attributes_for :contracts
end
class Company < ActiveRecord::Base
has_many :contracts
has_many :consultants :through => :contracts
end
class Contract < ActiveRecord::Base
belongs_to :consultant
belongs_to :company
validates_uniqueness_of :consultant_id, :scope => :company_id,
:message => "cannot have a contract with the same company more than once"
end
We have a New Consultant page which allows us to associate existing Companies with a Consultant by adding/removing Contracts. A Consultant cannot have a contract with a Company more than once, hence we need a validate_uniqueness_of validation on the Contract association.
But hey, business is booming! We end up needing to reuse the code base for another Rails project. The new project is in the construction domain but it has been decided that the database schema and domain model should remain unchanged. However we are told that as far as the user is concerned they should never see the term Consultant, rather they should see the term Builder. Enter translations!
Though you're not going to put your shoddy Spanish to the test and you failed French before you left school, translations are a handy way to work around this problem. Simply translate the word Consultant into Builder via the config/locales/en.yml file in your Rails project. At the same time we'll also change
- The validation error header that is present when the user submits an invalid record
- The displayed version of the consultant_name to be Builder Name
- The displayed version of the consultant model name to be Builder when arising from errors on the Contract association. The way to do this is not immediately obvious - you have to translate the foreign key field (consultant_id) to Builder for the association
Here's the complete config/locales/en.yml file. Note: Whitespace and indentation is very important.
en:
activerecord:
errors:
messages:
template:
header:
one: "This Builder has just one error but still you gotta fix it..."
other: "This Builder has lots of errors, get your act together..."
attributes:
consultant:
consultant_name: Builder Name # Handles the work of translating this attribute
contract:
consultant_id: Builder # NNB: This the big one! Notice how must translate the foreign key field to Builder for the association!!!
models:
consultant: Builder # This causes the consultant model to be referred to as Builder on the UI
So there you have it. The foreign key is the key, so to speak!
The best guide I encountered on translation was this one by Ian Hecker on Translating ActiveRecord which is a great way to get started. There is also a somewhat overwhelming guide to translations at Rails Internationalization (I18n) API but is comprehensive nonetheless. Also, do look at the en-GB.yml example at Sven Fuchs Locale Examples on GitHub.com which is where I first saw how you can define you locale file as an .rb file or yaml as above. Finally, I came across this entry on how to remove Rails Validation Message Prefixes which I didn't try but I just mention here in case I need it in future.
Developing a simple Match Schedule N900 App for the group stage of World Cup 2010 via Qt on Rails
Today we're going to take a quick look at how to create a N900 app by taking a simple existing Ruby on Rails application and turning it into a Maemo app using Qt on Rails. The main thrust of this blog post is to show how you would tweak the skeleton app generated by the Qt on Rails framework into something that might be useful in the real world. The Match Schedule app is very basic and only shows the upcoming fixtures for the day. But most iPhone apps are simple thin wrappers around a data layer anyway; and this is really only a proof of concept app, so I'd don't feel to guilty about my humble achievement.
When the World Cup kicked off, I really wanted to have a schedule app on my N900 and couldn't find one so hence the motivation. Bear in mind that in 2 days this app will be completely useless as the group stage will be over! Warning: it currently requires a level of technical ability to install this app on N900 as it has no installer. You should check out this related blog post on deploying your Qt on Rails apps on the n900 (Maemo) before tackling this one.
The application (source code) is available for download. Note: I haven't stripped out unnecessary skeleton code from the application, which would exist immediately after generating the Qt application off the Rails codebase. The unnecessary code is related to Create/Edit/Delete functionality which we won't need in our simple Match Schedule viewer. I left it in to show the minimum amount of work needed to tweak the generated app into a useful real world program. All in all (blog posts and stuff aside), it took about an hour to do. If I had to do it again I'd imagine it would take less than half that time.
All the following steps are done on your dev machine. At the end of the guide you'll see how to deploy to your N900.
First we create a Rails app.
rails WorldCup
cd WorldCup
./script/generate scaffold Fixture when:string group:string match:string
rake db:migrate
Then I fired up the web server ./script/server and manually entered the fixtures (stupido! I know!). The 'When' field has the date formatted as '24/6 - 15:00'.
Next up, we turn the Rails app into a Qt app using Qt on Rails. We are still in the WorldCup directory.
./script/plugin install git://github.com/theirishpenguin/qtonrails.git
./script/generate qtify Fixture
This generates the skeleton Qt app. Now let's bend it into shape, starting with the UI. From now on we'll be working in the qtonrails/ plugin directory.
cd vendor/plugins/qtonrails
designer-qt4 app/qdesigns/qmainwindow.ui
Once Qt Designer appears, remove the File menu, Commandlink navigation buttons and Action buttons (by more or less right-clicking on those widgets and deleting)
Then regenerate a Ruby code version of the ui files (every time you change the .ui file using Qt Designer you need to do this)
rbuic4 app/qdesigns/qmainwindow.ui -x -o app/ui_proxies/qmainwindow.ui.rb
./run # or it that doesn't work try: ruby run
Then I got errors 
. Based on these errors, I changed the following..
From app/qpresenters/main_window_presenter.rb I deleted
connect(@ui.viewButton, SIGNAL('clicked()'), self, SLOT('view_clicked()'))
connect(@ui.newButton, SIGNAL('clicked()'), self, SLOT('new_clicked()'))
connect(@ui.editButton, SIGNAL('clicked()'), self, SLOT('edit_clicked()'))
connect(@ui.deleteButton, SIGNAL('clicked()'), self, SLOT('delete_clicked()'))
connect(@ui.fixturesNavLinkButton, SIGNAL('clicked()'), self, SLOT('fixtures_nav_clicked()'))
connect(@ui.actionQuit, SIGNAL('triggered()'), self, SLOT('close()'))
Now let's try again.
./run
Hey it worked! Cool! There's more stuff we could now delete but we won't as we're focusing on doing the bare minimum.
In order to allow a column to be correctly resized and to provide row select behaviour (as opposed to having individual clickable cells), I added the following line just before the end of the initialize() method in app/qpresenters/main_window_presenter.rb
@tableview.resizeColumnsToContents()
@tableview.setSelectionBehavior(Qt::AbstractItemView::SelectRows)
The resizing of columns to fit their contents will probably become the default in a future Qt on Rails release.
Due to silly bug in Qt on Rails that tries to pull an unnecessary KDE library into generated applications (Issue 2 on the GitHub Tracker), we need to remove the line require 'korundum4' from vendor/plugins/qtonrails/app/ui_proxies/qmainwindow.ui.rb and vendor/plugins/qtonrails/app/ui_proxies/fixture_qform.ui.rb
In order to display just today's fixtures, we can change the index action in app/qcontrollers/fixtures_controller.rb (again under the qtonrails/ plugin directory)
def index
accept_current_fixtures_from Fixture.all
end
... and add the private method
def accept_current_fixtures_from(fixtures)
fixtures.reject do |fixture|
dt = fixture.when.split(' - ')[0] # Get date from string
date_args = (dt.split('/') + ["2010"]).reverse.map &:to_i
Date.new(*date_args) < Date.today
end
end
Note: The application source code available has the accept_current_fixtures_from() call commented out. This is because once the World Cup group stage is over in a couple of days the list of fixtures would be empty. I have decided that the value of this app as a useful demo in future outweighs the needs of my users over the next two days . In the source code you can simply add the call back in yourself if you wish.
Finally, we make the grid readonly. Because it was late when I did this, I skipped any fancy meta-programming and simply reopened the QtrTableModel to do so. Add this to config/environment.rb
class QtrTableModel
def flags(index)
return Qt::ItemIsSelectable | super(index)
end
end
Phew! Done! To deploy the app to your N900, read the instructions at deploying your Qt on Rails apps on the n900 (Maemo).
Well, hopefully you've gotten a flavour of how to use Qt on Rails in a simple real world N900 app. If you've any feedback then please get in touch! Until the next time, enjoy the World Cup and I hope your country does well!
Deploying your Qt on Rails apps on the N900 (Maemo)
Qt on Rails is a framework to let you turn your Rails sites in desktop applications and harness the power of Ruby! It's not at production level yet but it's certainly possible to have a good play with it and a bit of a hack! If you're not familiar with Qt on Rails then a good place to start is this blog post covering the v0.1 release. Also, check out the github repo for more info on installing Qt on Rails on your desktop and building an application with it. Here we show you how to deploy Qt on Rails based apps on your N900. One of the goals of Qt on Rails is to provide an easy way for you to develop apps faster for Maemo and, down the road, hopefully MeeGo too!
Note: This blog post may help you figure out how to install any QtRuby application on the N900, not just Qt on Rails apps. Also, this QtRuby Maemo wiki article was particularly useful when I was stumbling along this path!
One thing you will need to install as part of this guide is Easy Debian. Easy Debian greatly expands what you can do with your Maemo device. It basically sticks a full-featured version of Debian on your device. This means 2 things - firstly, for the uber-geeks out there it let's you fire up a Linux desktop on the N900; though it's important to note that your normal Maemo desktop isn't affected by Easy Debian. Secondly, having a full-on Debian available let's you run Linux apps such as Open Office! Sweet! And what rocks is that you can even run these programs without invoking the Easy Debian Linux desktop - in a seamless manner. It's important to note that the user interface to these Easy Debian-based apps behave a differently to a typical native Maemo program; rather they work like a traditional desktop application with a mouse pointer on screen.
- Note: For simplicity, this guide assumes you are installing an application which stores data using sqlite3. Also, the steps here have been tested against the N900 firmware update PR1.2. If you are using an older version of the firmware you may want to consider updating it.
- Firstly, install Easy Debian with the N900's Application Manager
- Install the Easy Debian image via the new Deb Img Install application added to your list of applications
- Note: This is a 1 gig download, but comes with cool stuff like OpenOffice and intergrates pretty seamlessly with your desktop
- Takes an hour or so to download and then extract itself
- Open the Debian Chroot terminal (not the usual N900 terminal), which should now be in your list of applications
- Install rubygems, qtruby and sqlite3 with ruby bindings
- sudo apt-get install rubygems
- sudo apt-get install libqt4-ruby
- apt-get install libsqlite3-ruby
- Install the bits we need need from Rails (without installing documentation)
- sudo gem install activerecord activesupport activeresource --no-ri --no-rdoc
- Zip up your Qt on Rails application and copy to any directory on to the N900. Note that the Qt on Rails application consists of the entire Rails directory directory including the vendor/plugins/qtonrails directory intact and a sqlite3 database already created under the db directory).
If you don't have your own Qt on Rails application to hand then you can create the RadRadio app discussed in the "Make it so, Jim!" section of the v0.1 release blog post
In the Qt on Rails v0.1 release there is a bug that accidentally introduces a dependency on a korundum library, which is not needed in this case. An issue is logged against this in the Qt on Rails Issue Tracker As a workaround, find and remove any occurrences of
require 'korundum4'in files under thevendor/plugins/qtonrails/appdirectory - Once transferred, simply unzip it on your device. Note: If you saved the zip to the Documents folder on your N900, this can be found under /home/user/MyDocs/.documents when poking around the filesystem
- Finally, via the good ol' Debian Chroot terminal, change directory to the vendor/plugins/qtonrails directory of your app and execute
ruby1.8 run - Boom! You should see your Qt on Rails app in all it's glory!
Note there is a bug where you cannot input into a text field when running a Qt on Rails app on the N900 using above technique (seamless mode). As a workaround, open the Qt on Rails app inside of the Debian LXDE desktop (rather than in seamless mode). You can find Debian LXDE in the list of applications on your device. Inside Debian LXDE, open a terminal and run the application as above. Just a quick heads up, sticky keys don't work like you'd expect - you have to hold down the Shift and Fn keys to use them.
Qt on Rails v0.1 released. But is this Ruby-based Qt and KDE app framework doomed?
Ruby has changed the way developers build web applications. Since popularised by the Rails framework, programmers no longer stumble around in the dark with disparate web forms; instead they are able to clearly focus on the business problem and expose a well-modelled domain in a easily testable manner. Traditionally used in data-heavy domains, today's web apps now encroach on the desktop's home turf of rich highly-functional applications - something years ago thought impossible. And most surprisingly, through clever use of patterns and conventions, they've arguably become the easier of the two to develop. Given this, could desktop developers learn from the web app approach? This is in part the motivation behind Qt on Rails - let's use a conventions-based approach to building desktop applications and clients. Let's harness the ease and expressiveness of the Ruby language. And let's have a clean consistent domain model underneath the hood with a comprehensive suite of tests to boot. A grand idea; but right now, it's on course to fail...
Main window listing Disc Jockeys (Click the image to enlarge)
What exactly is Qt on Rails? Well first, let me just make a little guilty admission. This blog post is aimed at Ruby and/or Rails developers first, then Qt/KDE developers second. This is not because I believe one camp is more important than the other. It is because I really want to bring Rails dev's on-board to KDE/Qt development and I see a real need to give them a first-class Qt toolkit; to make desktop apps as brilliant and easy to develop as their web apps. If Qt on Rails ever makes it as far as being a fully mature framework, I hope that a Rails developer using it for the first time will find it a very familiar experience. The directory structure, naming conventions and overall architecture (to date at least) has been chosen to that end. But I hope to do an article focusing on approaching this project from a more on Qt/KDE perspective. So what is Qt on Rails like?
Well, imagine you just wrote a Rails web application. You're finished! Let's say we just built a web app for a fictional company called RAD Radio. We have two important things in our system - Disc Jockeys and Sponsors for the radio shows. So we have this really neat model layer sitting on top of our database. It handles all our business logic and things like validation of data being persisted - let's reuse this... verbatim! This is our line in the sand! Design choice 1, Qt on Rails literally reuses everything from the model layer down already within your Rails application!
If we start from the front end of our proposed desktop application and work backwards, we want to have a Qt app which consists of various different screens, some of which may be on display simultaneously. This is a little different from the web, because generally on the web you can think of having just one screen and this gets blown away on each request (unless AJAX intervenes, but still you get the overall point). In a Qt desktop app we decide that our initial screen is to be "main" window for our application. Clicking on a button may cause a new window to launch, for example, a window to edit a Disc Jockey's details, but the main window will remain there, though not active. This kind of difference (from your typical web behaviour) presents a difficult challenge and will have a big effect on our architecture - for example, it has influenced my decision not to try and reuse anything for the controller layer generated in a Rail's application. Back to our story, we have a main window as our starting point, which you can see in the figure above. It should have a way to navigate between different parts of your application. This is achieved through the big command link buttons at the top of the window. In our web application, each part of our application is based on different sources of data (called resources when using RESTful terminology). Clicking on the Sponsors command link button would cause the grid to be refreshed with Sponsor records. And then clicking on the Disc Jockeys command link button refresh the grid with Disc Jockey records again.
This sounds reasonable so far. A quick side note though; bear in mind this is still early days for Qt on Rails. I'm sure many good KDE and Qt developers may be horrified at the UI decisions made above. I'm not a Qt or KDE expert! This is another big challenge. One of the most crucial areas we need help on is getting feedback on how Qt and KDE applications are generally laid out, what widgets are used for what purposes and so on. In essence, what are the best practice guidelines for HCI in something like KDE and how can we incorporate that into the apps we generate with Qt on Rails.
So we are looking at the main window, which contains a list of Disc Jockeys in a grid - how does this work? Well, first we need to be aware of what Qt is giving us here. The list widget that you see on screen is a Qt widget called a QTableView. It is concerned only with displaying stuff. Underneath that we have a QAbstractTableModel. This holds the data, it does not care about how it will be displayed. Now it's worth pointing out that a QAbstractTableModel has nothing to do with the Rails concept of a model. You see, the Qt folks have used the MVC pattern in their architecture for donkey's years now; and it's important to not confuse the two different uses of the same paradigm. The QAbstractTableModel is an object into which you stick a whole bunch of Rails records that you wish to display in a list. We then plug the QAbstractTableModel into the QTableView widget and that's how your records are displayed. It's also important to note that when a QTableView sees the QAbstractTableModel being plugged in - it has absolutely no idea that the underlying records are of type Disc Jockey. Think of the QAbstractTableModel as an adapter between a collection of records for a particular Rails model and the QTableView widget which will ultimately display them. Probably most importantly, remember that
- A Rail's model equates to one record
- Whereas a QAbstractTableModel equates to many records - it sits on top of a collection of Rails records and allows them to be displayed in something like a QTableView widget
Note: The Qt API is incredible. It's extremely comprehensive! Check it out at http://doc.qt.nokia.com You will want to look at the "C++ Application Development Framework" for the version of Qt you develop with. One big tip to note down - where it talks about something like a QAbstractTableModel in the docs - is that it is referring to the C++ world. In your head just translate this to Qt::TableModel - now you can happily use all the documentation available. Also, in your code you will always write Qt::AbstractTableModel, never QAbstractTableModel.
So to edit a Disc Jockey record I select a row and click the Edit button near the bottom of the page. Hey presto! An Edit Disc Jockey form appears...
Form for editing a Disc Jockey (Click the image to enlarge)
Nice! And when you click the Save button the Edit form is dismissed and the list of Disc Jockeys in our main window is refreshed!
Qt on Rails is installed in the vendor/plugins directory of your Rails app (see http://github.com/theirishpenguin/qtonrails for more details on how to install). Under vendor/plugins/qtonrails/ there is a directory called app/ which holds the Qt application code. In turn, app/ is divided into the following subdirectories, with each subdirectory corresponding to a layer in our application framework, listed here from the highest level (like the HTML stuff in a web app) to the lowest (the controller in our case - as everything from models down to db is handled by vanilla Rails).
- qdesigns - XML markup files (with a .ui extension) which are to Qt screens/widgets what HTML files are to HTML pages/elements
- ui_proxies - A Ruby representation of .ui files - this is an autogenerated layer which you don't really need to worry about
- qpresenters - Where the presentation logic (not any business logic) for your screen lives
- qhelpers - A place to put logic that you wish to reuse across presenters
- qviews - Where we decide exactly how we will build a view for a particular controller action (I accept that the name 'qviews' is confusing; maybe 'qviewbuilders' would be better or something totally different)
- qcontrollers - Where we decide what data to retrieve for a particular action (though we don't specify 'where to go' in the way a Rails controller has render() or redirect_to() methods)
So here's the flow of control. In our vender/plugins/qtonrails directory we have a 'run' command. When we execute it, the command...
- Fires up a Qt Application instance
- Asks our (very primitive) Router to take a given route and instantiate a QView and a QController for it
- The QController then fetches data depending on the action (just like a Rails action) and hands off the data to the QView
- The QView then decides what screen should be build (or whether to stay on the same screen and perhaps just refresh a list of records)
- Once the appropriate Screen has been built, it is displayed with a show() call. At this point the user will then see something happen on-screen.
The above is pretty much like one request-response cycle in a Rails app. Now we play the waiting game
- The user does some*thing like selects a row and clicks the Edit button.
- At this point the QPresenter comes into play. The QPresenter is your window widget. I didn't tell you then, but the QPresenter was created earlier in the QView layer when we call the constructor for the window (ie. the QPresenter) we wish to display). I'm open to the fact that QPresenter may not be the best name for this! Anyway, the QPresenter contains your presentation logic. In our case, the user has just clicked the Edit button on the MainWindow presenter. This causes the handler for the event - the edit_clicked() slot to be called. Qt uses a brilliant concept called Signals and Slots to handle events in your application - a Signal is something that acts as a trigger (such as a button being clicked) for a Slot; a Slot simply being a function dedicated to doing something useful in response. A Signal is connected to a Slot using the aptly named connect() method. I neglected to bore you with this little detail earlier but this connection was carried out in the constructor for the QPresenter (ie. the window) which took place a few steps back when we mentioned that the QView layer decided what screen is to be built
- Finally, the slot - edit_clicked() in this case - asks the Router to take a given route and now we're back to step 2 of the flow of control outlined earlier
- Phew!
So that's it in a nutshell. How do get all this lovely goodness to turn your Rails web app into a skeleton desktop app? One command, mon ami! From the root of your Rails directory simply run
./script/generate qtify DiscJockey Sponsor
So let's say you have no Rails app right now. Here's how to get to a basic web app and skeleton desktop app in double quick time!
Firstly, just a quick note on OS dependencies. Qt on Rails has mainly been developed to date on Kubuntu 9.04, Kubuntu 9.10 and the Ubuntu Netbook Remix 9.10. For these platforms, you can install the packages mentioned in the "First Install the appropriate packages" section of this Developing Qt4 Applications using Qt Designer and Ruby on Kubuntu article, which also goes into more detail on QtRuby development if you're interested. This QtRuby bindings article on the KDE TechBase also gives some useful info on the Ruby bindings for Qt.
We've not tried this yet on Windows or Mac, but here's a Windows QtRuby install guide by Richard Dale and a QtRuby on the Mac install guide. So you are welcome to try and install QtRuby on one of these platforms but we can't promise anything!
Perhaps, most excitingly of all, Qt on Rails apps can be deployed to Maemo devices such as the N900! Check out this related Deploying your Qt on Rails apps on the N900 (Maemo) article! And MeeGo support will surely follow sometime soon!
Ok, let's cook you up a Rails app. Here we are using Rails 2.3.5 and assuming you are at a Linux command line (see Qt on Rails github project page for more installation details of Qt on Rails itself)...
rails RadRadio
cd RadRadio
./script/plugin install git://github.com/theirishpenguin/qtonrails.git
./script/generate scaffold DiscJockey name:string date_of_birth:date programme_name:string radio_slot:time max_num_guests:integer next_review:datetime
./script/generate scaffold Sponsors name:string signed_up_on:date
rake db:migrate
./script/generate qtify DiscJockey Sponsor
cd vendor/plugins/qtonrails
./run
# If ./run on it's own gave you a permission error you can try 'ruby ./run' instead
# Oh yeah!
Hopefully, you should be seeing an app around about now. Once you have some rows in the list of disc jockeys or sponsors (create some DJs using the New button), you will see that cells of the grid that make up the list can be edited in-place. This is quite a powerful feature to have out of the box. An Edit button is provided also, though if you plan to provide an Edit button to your users, which launches a form, then you should probably make the grid read-only so as not to confuse them by having two ways of editing. As this is a early prototype of the framework, I've left the Edit button and in-place editing enabled, trusting you to tailor them to your app's needs. If you were going to switch off in-place editing you would probably also want to select the entire row (rather than just one cell) when you click on a cell in the row.
Let's have a quick look at form validation in action. Add a validates_presence_of validator to your DiscJockey and Sponsor Rails models so that they look as follows
#In app/models/disc_jockey.rb (under root of your Rails app, not under qtonrails)
class DiscJockey < ActiveRecord::Base
validates_presence_of :name
end
#In app/models/sponsor.rb (under root of your Rails app, not under qtonrails)
class Sponsor < ActiveRecord::Base
validates_presence_of :name
end
Close and restart the RadRadio Qt on Rails app. When you hit the New button and try to create a new Disc Jockey or Sponsor without a name, you will see that the Rails model validation kicks in and you get a validation message telling you that you need to correct the name field. Validation also works if you are editing a record after clicking the Edit button, however validation messages don't appear if you edit a record in-place in the grid (just because I haven't had a chance to implement that yet).
Again, as it's an early release there's also plenty of bugs in there, such as a crash if you try to click the Edit Button without selecting any row. A list of issues is maintained on the Qt on Rails Issue Tracker. Check it out to see what limitations currently exist and add to it if you spot a new problem!
As you can see, this codebase is being opened up quite early. A good start has been made - but the project is still very embryonic! Surely, it's a bit early to be talking about doom? Well, unless hacking on Qt on Rails appeals to some developers out there it will certainly die a merry death on the great scrapheap of nice projects that just didn't make it. Why? Not only is there a lot of work that needs to be done, but also it's more fun to work on the project when there's a crew involved, which also brings new ideas and energy to any project. Otherwise it's unsustainable.
But life wouldn't be fun it it wasn't a bit of a challenge, right? If you think this kind of project might interest you, if you're not put off by insurmountable odds, then know that your framework needs you! Drop me an email at declan [[AT]] weuseopensource [[DOT]] com or twit a quick tweet on twitter (theirishpenguin). The Qt on Rails Issue Tracker is a good place to start looking for things to hack on. Or you're welcome to fork the project on github and develop that killer feature you'd like to see in there!
Qt on Rails, because it's at an early stage, is an easy place to start - there isn't lots of code to weigh you down. The framework itself is very thin, the majority of the code is actually Rails style generators to take the Rails model layer and build the Qt/KDE app on top of it. Because of the tiny codebase, it shouldn't be hard too get your head around what's going on.
It's intended that Qt on Rails gives Ruby and/or Rails developers an outlet to develop first class desktop apps using the best available framework. Rails developers often ask, "If I want to build a great cross-platform desktop app, what GUI toolkit would I use?" The answer varies and there no one headline GUI toolkit/desktop framework that currently has mindshare amongst Ruby developers and works great across multiple platforms. Given that Qt is currently so strong across the Linux desktop, commercial Windows applications, Macs and mobile platforms such as Maemo and MeeGo why shouldn't it be the first thing you reach for when building a Ruby desktop app? Come help us build Qt on Rails! Stave off the doom!
Santa’s got Gems baby! Ruby Ireland Christmas Meetup 2009
Ho ho ho! The month's Ruby Ireland meetup sprag right out of the traps with early adopters showing up at 6pm in the lobby area of the Trinity Capital Hotel, Wed Dec 16th. Easing into the evening with a 4 euro pint and talk of Android phones - seemingly the top item of everyone's Christmas shopping list - the latest crop of gems in the Ruby world was in hot debate, gemcutter in particular.
A couple of folks had been playing around with RubyGame for visualising data as it changes on the fly - showing that this framework is for more than just gaming. The XML/HTML parser Nokogiri was also mentioned a few of times in passing, with the particularly eye-catching quote "XML is like violence - if it doesn’t solve your problems, you are not using enough of it" adorning the home page of its website. And the cracking little tool tig was also brought up, which has a dinky little ncurses interface into git repositories. Pretty cool; not least because it makes it easier for newbies to avoid being bitten when they start git'tin.
The downstairs lobby in the hotel worked out great for people to meet up and relax, with most people turning up at the scheduled 7 o clock for kick off. From there we took over the, what has to be said, pretty classy meeting room complete with old style couches and some Joan Miró paintings. Just in tune with the creative buzz we had going on. There wasn't too much talk of Ruby for a while as most people were in stunned admiration of the room. Then the food platter arrived. Impressively, this is when everyone showed off their good manners by looking shyly at the platter for a few minutes, with that kind of "You first, sir" glint in their eye, before taking the plunge and sinking into the pakoras and wedges! Pretty much undoing any good work in the gym from earlier in the day!
One of the funnier moments of the night was when someone went to check the tweets against the (now settled upon) #rubyireland hashtag. Only to find lost rubyists tweeting from the hotel lobby as to where the meetup was on. After a quick runaround the lobby to herd anyone wielding a Macbook into the meeting room, the evening was back on track. We split up into a few smaller groups, with the main walk-through being on the qtonrails - a Rails plugin to simply developing applications on Linux and other platforms using Nokia's Qt framework atop Rails.
To finish off we had a bit of improv comedy from everyone at different closing stages of the evening; in particular Paul O'Malley with his faithful rendition of an emotion beekeeper. And yes now we're straying off topic so it's probably time to go. We'll leave you with Paul's write up of last night's shenanigans
Thanks to everyone who showed. Have a great Christmas and catch ye all in Jan 2010 - surely destined to be the decade of Ruby domination!
Ciao,
Dec