casperfabricius.com

This article is part 1 in a series of articles about an “open source project” I’ve been working on. I’ve put it in quotes because it’s not a real open source project in the sense that many people has worked together – it’s a hobby project with me as the only developer, and now I’m choosing to make its source public because I feel like contributing something back to the community. I call this project Clouds, and you can try it right now, right here.

The idea behind Clouds
Basically, Clouds is some kind of generic notice board. I wrote Clouds because I wanted to use it make a wish list application with a different approach, but I also wanted to make it generic enough to be able to reuse it in other applications. Perhaps even transform it into an engine to make it easier for other people to use it in their applications.

Upon entering the Clouds for the first time, a blank cloud is created automatically. The user is presented to an entirely white page (except for discreet menu bar at the top) and are able to add topics anywhere on the page by double-clicking and entering a text in the appearing box. The user can also add notes to topics, move topics around and even delete them again.

To further enhance the users ability to express themselves freely in their clouds, one could add features such as choosing the color, size and font of topics, but that is not essential to the real function of the cloud: To let users build lists in two dimensions instead of just one (typically vertical). In its bare form, Clouds can be used in many ways and taken in many directions, which is why I wanted people to be able to extend the application to suit specific needs, like a wish list, a mind map or …

As I had this basic functionality, I felt Clouds needed a bit more functionality to be usable to anyone, and yet I still wanted it to be basic and generic. So added the ability to protect editing and/or viewing with a password (not a registration and login – too much work for the user), and the ability to extend any list into a new list. The extension feature would be vital in, say, the wish list application, because it would allow people to extend a wish list and then coordinate who is buying which presents through their new list without the gift receiver knowing, while still maintaining the link to the original wish list.

I still have several ideas for things I want to add or improve, i.e. something as basic as getting the whole thing to work properly in Internet Explorer (no, Prototype and Scriptacolous cannot save you from all the headaches of IE), but also the fancy notion of synchronizing lists live between users, so multiple users working on the same cloud will see each others changes immediately.

The rest of this article and the one(s) to follow will dip into the technical aspects of Clouds, especially highlighting the parts where I’ve run into trouble. You can review and download the source code right here, but remember to check the license if you want to reuse any substantial parts of the code.

Creating a RESTful Rails application
What does it mean for a Rails application to be RESTful? To me it means to use the scaffold_resource as a basis for most entities in the application, and to strive to keep the application normalized by having only the CRUD actions generated by scaffold_resource in the controllers. Of course, these actions will also give the application a RESTful web service API for free, but that’s just an added bonus to me.

This article is a not a tutorial, but I do want to walk you through creating a RESTful Rails application as it will help you to build cleaner applications, also when it comes to database structure. To build Clouds, my first task was to generate the two central entities: The Cloud and the Topic.

./script/generate scaffold_resource Cloud title:string, created_on:datetime, updated_on:datetime, password:string, settings:integer, parent_id:integer
./script/generate scaffold_resource Topic cloud_id:integer, text:string, notes:text, posx:integer, posy:integer

The scaffold_resource generates everything you need to get started with your new entity: Model, controller, views, migration, tests and route. No need to worry about when to use singular or plural names, lowercase or uppercase, underscores or camel case. All files are created and named according to current Rails conventions. All you need to do is run rake db:migrate and restart the server.

Take a look at config/routes.rb. The generator has added map.resources :topics and map.resources :clouds. This enables the user to browse your Rails application using the nice RESTful urls, meaning that the same urls are reused for different actions, depending on the HTTP method used. For instance, if you do a GET (opening the page in your browser) on the url /clouds/1 the controllers show action is invoked, while a PUT on the same url will invoke the update action.

As you can probably read out of the scaffold_resource statements, a Cloud has a title, a password, some settings and a parent (plus two timestamps automatically updated by Rails), but for the basic functionality of Clouds, none of these attributes are required. A Cloud is nothing but a collection of Topics, and a topic has a text (short “headline” visible at all time), notes (longer text only visible on mouse over) and a position on the screen.

Take a look at the index action in the clouds_controller. After determining if the user already has a cloud to edit (by reading a cookie), the action utilizes either the edit_cloud_path(cloud) or the new_cloud_path methods to redirect the user. There is nothing new about named routes in Rails, but as a part of using RESTful Rails we get these named routes for free. Another interesting point in the clouds_controller is the calls to an authorize method located in application_controller, which is used to check if the user is required to enter a password to either view or edit the cloud. This method is invoked with a symbol as its third parameter, which is used to ask the cloud if either the show or edit action are protected (cloud.send(method)). I think that’s quite clever use of Ruby’s fantastic reflection abilities.

Using bitflags
A last thing I want to highlight in this first part in my article series about Clouds, is my use of bitflags. I believe the term bitflags is used and understood differently by different people, but in this context I talk about storing multiple true/false values in a single integer. In Clouds I needed to store some settings per cloud, specifically if the cloud’s show or edit actions where password protected. I could have added two fields to the clouds table called protect_edit and protect_show with the data type boolean (bit), but what if I needed further settings later on? Should I just continue adding more fields to my clouds table?

No. I believe bitflags is a cleaner solution for this, and to my enjoyment I was quickly able to find a small plugin providing me with this exact functionality called has_flags. In a nutshell, bitflags uses the power of 2 to combine multiple numbers into a single integer, while still being able to tell exactly which power of 2’s are in the integer. So the bitflag 22 are the numbers 2, 4 and 16 combined, while 8 is not present in that bitflag.

Take a look at the cloud model:

# Utilizes the has_flags plugin for easy bitflag usage
has_flags [ :protect_edit, :protect_show ], [ :column => 'settings' ]

This single line of code automagically adds protect_edit and protect_show as boolean attributes on the cloud model, while [ :column => 'settings' ] tells the plugin to store the bitflags in a field called settings. This is an easy, elegant and first and foremost “Railsy” way of using bitflags in your models.

In part 2 of this article series on Clouds we jump into the core part of the application: The javascript.

With this article I am taking up the challenge in Pat Eyler’s blog On Ruby, which is: Write a blog about how Ruby on Rails has made you a better programmer.

I saw the light in January 2006. Yes, it was that late. Up until then, I’d been a Microsoft-programmer all the way. ASP taught me to do server-generated homepages. C# taught me to do object-oriented programming. But Ruby on Rails taught me that programming was an art, and not just a craft.

A friend I met in college introduced me to the open source world back in 2003. He tried to convince me that Linux and Perl was much better than my beloved Microsoft equivalents, and while I didn’t buy into that back then, it did widen my horizon quite a bit. Another good friend told me about Ruby on Rails when it was first made public. “I haven’t tried it myself, but it’s supposed to be really cool, and the guy who created it lives in your neighborhood.” I wasn’t convinced, but the notion of this cool, new way of developing web applications stuck with me, nevertheless.

I saw the light in January 2006. And by light, I’m not just talking about Ruby on Rails, but that whole new paradigm Rails is part of. Some like to call that paradigm web 2.0. For me, web 2.0 is more than just technology; it’s more than Rails and Django, blogs and podcasts. It’s about being open, giving and sharing stuff. It’s about really smart people not just trying to earn a lot of money, but also having a genuine desire to help other people getting better.

Ruby on Rails has made me a better programmer by showing me how easy, friendly, open and helpful things should be. Compare the Rails community to the ASP.NET community. The ASP.NET community is certainly not without people willing to share and help out, just look at Codeproject, but I have to say that I think the average Rails-programmer’s IQ is higher than that of the average C#-programmer’s. This is probably because the Rails community is smaller and attracts certain kinds of people, but I wonder if it will be watered down as it grows, or if we can continue to be nice and helpful to each other.

I had several fantastic experiences with Rails during the past year. RailsConf was awesome, not only because it had so many great speakers, but especially because everyone was so damn nice! Also Copenhagen Ruby Brigade was formed, and we were lucky enough to get the company of David Heinemeier Hansson and David Black to one of our sessions hosted at my workplace, Kraftvaerk.

So how has Rails made me a better programmer, technically speaking? Well, I can’t say the stuff about DRY and testing and DSL’s and so on was new to me when I started doing Rails – I mean; I’ve had The Pragmatic Programmer in my book shelf for years – but there are things about Rails that make it easier to do things right, and harder to do them wrong. I’m quite interested in some of the more … academic sides of Rails, like how it utilizes patterns, and an important example of that is the whole RESTful notion, which is “new” in Rails 1.2, but has been used by me and many others since it was in EDGE sometime last summer.

For me, it boils to this: More models with fewer actions. Preferably only the CRUD actions, index, create, update and delete. Why is this good? Because it’s convention. Example: Instead of /users/login you have /sessions/new/. It makes sense to me, and like many other things in Rails, it tells me do more of these conventions, also in my ASP.NET applications.

Has Rails made me a more productive programmer? Well … yes and no. I mean, the Rails framework is much more efficient and intuitive to work with than, say, the .NET framework, and Ruby does have a lot of clever ways of doing things in one line that requires 5 or 10 ten lines of C#. But … I also spend a lot of time browsing and searching the Rails API because I can’t remember the order of the arguments to call select. If I had intellisense like I have in Visual Studio 2005, I’d just start typing. I also find my Rails applications much harder to debug and install (deployment through Capistrano is a dream, but Apache, Lighttpd or even IIS to run the code is different!) than my ASP.NET applications. Okay, things are getting better and easier, but my point is; it’s not all good.

Nevertheless, Ruby on Rails has widened my horizon and opened my eyes, and that’s worth more than any productivity boost.

Simple question: Am I running Mac OS X or Windows XP in the screenshot above? (Click to enlarge).

Simple answer: I’m running both.

Complicated answer
I’m really running Parallels with the coherence feature enabled. Parallels is an application that utilizes the Intel processors in newer Macs, allowing Windows XP to run in a virtual machine, but without the whole hassle of emulation. Without emulation, speed is greatly increased.

Coherence means that the Parallels makes the Windows desktop transparent while running the virtual machine full screen. This allows Mac and Windows applications to run side by side, without the hassle of having to switch to the virtual machine, and then selecting the Windows application you want to use. This way; Windows application really feel like any other applications on Mac.

This is cool, but it’s old news. Now, I’m using boot camp to dual-boot on my Macbook Pro. I use Windows for .NET development at work and for gaming. I use Mac OS X for everyting else. The great thing about this new beta of Parallels I’m running, is that I don’t have to create a new virtual machine and install Windows, Office, Visual Studio and so on. I can just boot my existing Windows partition directly in Parallels. How cool is that?
If you are dual-booting between OS X and Windows, I can only recommend that you try out the free 30 day trial of Parallels. It is unbelievably easy to get up and running; you just go through a wizard, select Boot Camp, and – BAM! – you have your well known Windows desktop right there next to your Dock, Mail, Safari, and so on. If you try this setup, I have one tip for you: Don’t attempt to click on anything when you boot in Parallels and Windows detects new hardware. Parallels will take care of everything, so just sit back and wait until the virtual machine is not working anymore.

And by the way: Running your Windows partition in Parallels doesn’t in any way change or harm the partition. You can always boot into Windows as usual, which is still necessary if you want to play a 3D game.