Plans for the future
In the past week I started playing with Rack and put together a little Rack application that generates content from my blog’s rss feed about the site. As I stated in that post I really didn’t like having the “parked” page up there, and I also wanted to try out Rack, which has gotten so much press of late. I was very impressed with Rack, and how easy it was to put together a simple web application with it.
Until that point, I had used Rails, used non-Ruby web frameworks and used Ruby for other non web-based projects, but I had not created a Ruby based web application with anything other than Rails. It was an enlightening experience. It got me thinking about Rails, what it provides out of the box:
- ActiveRecord for persistent, vendor agnostic storage and model building goodness
- Built in support for AJAX and partial views.
- Controllers to coordinate between them
- Simple support for REST web services
- ActionMailer for email handling
- Flexible url routing
- An active and growing community that provides a large number of useful and often cutting edge add-ons and guides.
Additionally, many of these features are modular and can be swapped out or replaced with other modules to suit your tastes. That is quite an impressive and list, and by no means comprehensive. With Rails 3 on the horizon, there are even more great things on the way. It’s no wonder, that I fell in love with Rails.
However, I realized that a number of things I use to develop Rails applications are not truly Rails features, but only supported by Rails. This by no means a slight against Rails, but it is something great about Ruby and the Ruby community. Here are some features and libraries that I make use of:
- erb – Templating engine available in ruby itself.
- rake – An essential make utility for automating reoccurring tasks.
- Test::Unit – Unit testing framework, baked into Ruby.
- Cucumber, RSpec and friends – There are group of great libraries available for testing Rails and other Ruby apps.
- git and github – Fast, distributed source control and repository hosting.
- Rack – The new hotness in standardized web server interfaces.
- Capistrano – Automated deployment.
- Phusion Passenger – Once called mod_rails, it is actually more than that, as it supports all Rack based applications.
- Dedication to best practices and self-improvement – While not technically a feature, it is ingrained in the Ruby and Rails communities and it’s contagious.
Chances are, if you have done any Rails development you have encountered, used and enjoyed some or all of these. My point here is not to say that Rails is only great because Ruby is great. Rather that while Rails is awesome, there is a strong and viable codebase for building applications, web-based or otherwise, in the greater Ruby community. The relationship between Rails and Ruby and the popularity of Rails as a framework have made both better and stronger tools.
Building Cohesive Applications
This relationship would not be as be strong, if Rails was built as a monolith. Instead, Rails is designed in to be modular. The framework itself is broken up into no less than 6 gems:
rubyyot@atlas:~$ jruby -S gem install rails Successfully installed activesupport-2.3.2 Successfully installed activerecord-2.3.2 Successfully installed actionpack-2.3.2 Successfully installed actionmailer-2.3.2 Successfully installed activeresource-2.3.2 Successfully installed rails-2.3.2 6 gems installed
Within that, as we saw, the standard way of building rails uses a number of other tools and libraries. These parts are generally built to be highly cohesive rather than highly coupled. This property of good design is probably best described by Uncle Bob’s SOLID principles. These are:
- Single Responsibility Principle
- There should never be more than one reason for a class to change
- Open Closed Principle
- Software entities (classes, modules, functions, etc.) should be open for extention but closed for modification.
- Liskov Substitution Principle
- Functions that use … references to base classes must be able to use objects of derived classes without knowing it.
- Interface Segregation Principle
- Clients should not be forced to depend upon interfaces that they do not use.
- Dependency Inversion Principle
- High level modules should not depend on low level modules. Both should depend on abstractions.
- Abstractions should not depend on details. Details should depend upon abstractions.
While these principles were written with less dynamic languages than Ruby in mind, such as Java and C#. Understanding them and applying them in any language will help you to write clean code. Code with minimal dependencies that strangle it’s agility and make make maintenance a nightmare. These SOLID principles also make code more modular and enable the long promised re-usability that all object-oriented programmers learn about in OO101.
Ruby Web Frameworks
One of the trends in the Ruby and Rails communities in the past year or two, has been the building of other web frameworks. These were often termed micro-frameworks because they offered the ability to build ruby based web applications without having to run a full Rails stack. The most notable of these are Merb and Sinatra. While these began to splinter ruby based web development, my mantra for this year is:
Change is good.
These project went and approached the building of web applications in Ruby in different ways. In doing so they opened up the doors to creativity and brought some improvements and fresh ideas to the table. The benefits of this are even now coming clear with the announcement that Merb will be merged into Rails 3. This promises to bring more speed and modularity to the Rails framework.
Pragmatic Thinking and Learning
I recently completed the book Pragmatic Thinking and Learning. It was an excellent book that centers around bringing our innate creativity (R-mode) to the party to achieve goals and solve problems. While it’s a book targeted to technical people it is not written for one specific language or even just for programmers. It takes a number of interesting studies and theories, most notable for me is Betty Edwards’ Drawing on the Right Side of the Brain and brings them together into a series of tips and hueristics for improving your thought processes. It’s a very interesting book and I would recommend it to anyone interested in the topic.
Rails and Lettuce
In of the book, Andy Hunt is discussing personal wikis and shows a page from his WikiNotes (figure 8.3 ). It shows a series of thoughts as follows:
- U.S. per capita consumption of Romaine lettuce increased 162%
- Lettuce consumption at a record High
- Convenience of pre-washed, bagged lettuce outweighs cost.
- MORAL: it’s got to be easy
I thought that this was a particularly interesting observation and in a way is a metaphor for Rails.
The sales of Romaine lettuce increased 162% by pre-washing and packaging it in convenient bags. This packaging is widely popular in spite of the increased cost. It’s clear that lettuce is a great product. Everyone knows it’s healthy and it’s the building block of salads and great in sandwiches as well. Still it’s popularity were greatly improved by giving it an instant, right out of the box, interface. Similarly Ruby web frameworks are great products. Rails packages that goodness up in an easy to learn, build and deploy.
Reinventing the Wheel vs. Digging a Rut
Rails is built on top of Rack. Rack is written in Ruby and specifies the interface between the web server and the Rails framework. In fact Merb and Sinatra are built on top of Rack as well. Still, as we saw, Rack is available for building upon directly and of course Ruby and it’s libraries are available as well. So why not build a Ruby web application without any framework at all? Well the obvious answer is that you won’t have all of the nice things that these web frameworks provide. Not to mention many of these pieces have now been used and tested by production applications for years now. It may be a better question to ask:
Why wouldn’t I want to use one of the pre-built frameworks?
The answer to that question is what has been forming in my mind since I tried out Rack for the first time.
- Frameworks remove options - Even the best framework on the planet is going to take away options. Lean Methodologies include the idea of delaying decisions as long as possible allowing for greater flexability later on. Many times we want to use a framework, because it leave a clear path to a production ready application. This comes at the cost of options and I don’t want these removed.
- Learning Opportunity - Often the best way to learn something is to do it. I’m not an expert with Rails, I still have more to learn, but I also want to learn more about writing and designing applications for the web in general. Therefore it makes sense to bypass the framework and hook directly into Rack.
- Many libraries are still available – As we saw before, many of the tools used in the creation of Rails applications are still available for use.
- Completely Custom – I used to love watching shows like American Chopper and Monster Garage even though I know next to nothing about building a car or a bike. The thrill was in watching highly skilled people create baddass and functional custom vehicles. This is a similar though admittedly geekier endeavor.
- Beginner’s Mind – This zen concept urges you to remove look at things without filtering them through your pre-conceived ideas and biases to gain greater understanding. Approaching this project without relying on a pre-conceived framework should lead to similar results.
All of these are great reasons for me to try making my own path and not generating yet another Rails application. That’s not to say that Rails isn’t great, or I’m better than Rails. It’s just not the right fit, right now for my project. In the end I’d rather re-invent the wheel than dig myself into a rut.
Vaporware and Playing to Learn
One thing that I do when working with my personal projects is that I will have an idea and start to run with it. After a while of working with the idea, more ideas will come and my attention will turn away from my original project and move on to other things. Some examples of this are:
- Resolvr – A dependency injection mechanism for Ruby.
- Gippr – A library for parsing the GIFT file format.
- RSimpy – A wrapper for the API to Simpy.com
Will I ever get back to these and complete them? Maybe. Much of what I do in my personal projects is playing to learn. Like when I was a kid and I wanted to build a giant working robot or transformer out of legos. Did I ever finish these projects? No, but they were fun and I learned a number of interesting things along the way. This is one of the great things about personal projects. There is no one expecting you to deliver a product, so you are free to persue whatever interests you. Even if that means that you abandon the project altogether and move on to another.
There is a character on the show Jimmy Neutron, that my kids watch, called Professor Calamitous. He is a brilliant scientist bent on doing evil. However, he is continually undone by his character flaw, that is that he can never finish anything. I have often teased my wife, because she will get very excited about a project and work on it. She won’t just do a little, but she really digs into it and attacks the subject. After some time she will, almost overnight, lose interest and move on to something else. I’ll tell her that her inner Professor Calamitous has struck. In actuality, I’m just as guilty of it as she is if not more so (sorry for teasing you).
When viewed from a goals oriented perspective this is a horrible waste of time. Why put all the energy into something that will be left to rot, unfinished? From another perspective, that of a learning tool, it is a great accomplishment and a goal achieved. The time wasn’t wasted because in doing something with the project, rather than just reading (or writing, speaking, etc.) about the topic, you develop hands on experience and engage much more of your mind (R-mode) than you would have otherwise.
Personal Wiki
Now I feel it’s my duty to bring all of these random thoughts together and issue a challenge to any out there who might be reading this. The book, Pragmatic Thinking and Learning, recommends the use of a personal wiki to gather together your thoughts and organize them into an exocortex. I looked through all of the available wiki software out there and none of them really felt right. That was a kind of personal decision and it’s nothing against any of the software available. They either didn’t provide the features I wanted, or I didn’t like the look and feel.
Requirements
- Good feel – If I’m going to do this, I will be spending a significant amount of time with it. Any tool I will be spending that much time with, better not have annoyances, no matter how small.
- High Availability – While it may not need to be as available as a ubiquitous collection tool, it should be available to me at work and at home, at the very least.
- Wiki Formatting - Whether via wiki markup, RedCloth or some other means it should be easy to build and grow as a wiki. That’s kinda the point of a Personal Wiki
- Single user editing - It may seem odd to have a wiki that is editable by a single person, but if it’s just for me, then it only makes sense.
- Public display – Some of the things I put in it would make sense to be available to others who are interested.
- Private display – Some of the things in it may be private and kept that way.
- Easy backup and recovery – If I’m going to go to all the trouble of writing and gardening a wiki, it should be safe and recoverable in the event of corruption, disaster or my own foolishness.
- Customizable – I may want to have dynamic content on some pages. Perhaps it should pull in my bookmarks on a topic and display them with other content.
That is quite a hefty list and I’m sure that there will be other things along the way that I’ll want to put in there. It’s no wonder I couldn’t find what I wanted out of the box.
I’ve decided to build this directly on Rack, using git, github and other useful tools I would use in building a Rails app. I’m not sure how this will go at this point, but it’s an exciting project and I hope to have something to show for it by the end of summer.
The Summer of Learning Challenge
We all have these kinds of ideas floating around in our heads, and the more creative ideas we listen to and act upon, the more will come to us. I think that right now is a great time, as it is the beginning of Summer 2009 to act on one, or more, of these. The summer provides a set time frame that is long enough to make something great, but short enough that we won’t put it off forever. I think that it would be great to see others (you) find a project they are interested in a make a commitment to work on it this summer. If you are a developer/programmer, make your project open-source. It could be a great benefit to others. It will defiantly be a great experience for you.
A few years ago I took part in and completed NaNoWriMo. My book wasn’t finished at the end, but I wrote 50,000 words of it in one month. That was a great accomplishment for me, something that I didn’t think I could do when I started. By setting the goal and working toward it I was able to complete it. It felt great. What could you do if you set your mind to it?
What Will You Do?
If you are interested in taking the challenge or just have an idea or a comment about mine. Please leave feedback or blog about it yourself an leave a postback. It’s going to be a great summer. Enjoy!