Geoffrey Meredith

Over the last couple of months, I've gotten myself into Twittering more and trying to see how this could be a useful tool to me.  I've found that by following a number of prolific Twitterers, that I can keep my finger on the pulse of a number of subject areas.  One of the problems I ran into is that I often feel that I'm missing out on half of the conversation and wanted to easily see the whole conversation around specific memes.  That's when the concept of a tweme (Twitter meme) came up.  A tweme is a tag that gets included in twitter posts about a particular meme.  This makes it possible to look at twitter posts from the perspective of that meme and see what the whole twittersphere is saying about it.

As a first approximation of what viewing twemes would be like, I've create Twemes.com.  Twemes.com shows the most recent twemes as extracted from the Twitter public status stream as well as a "tweme cloud" of the most active twemes.  You can also view and bookmark pages of specific twemes so that you can follow the twittersphere's thoughts on that meme.

I've decided to convert my infrequently updated blog from Wordpress to Typo.  Not because there is anything wrong with Wordpress.  In fact, I quite like Wordpress but I wanted to try out Typo and I thought it would be educational to have a closer look at a real world Rails app.  The install process was pretty straight forward.  I created my own theme out of the scribbish theme provided.

I did find that the way that Typo managed it's template system to be quite interesting.  While I was familiar with being able to programatically set the layout for a controller or the whole application, what I really wanted to do was to to be able to override any view template for a specific theme.  I've done this kind of thing in PHP but I really wanted to do this "the rails way".  What Typo does is quite elegant although it's a bit risky.  Typo overrides the ActionView::Base function full_template_path which will produce an absolute path for a template.  By default this resolves to templates in the RAILS_ROOT/apps/views directory but Typo overrides this and sets up a list of serach paths to attempt to resolve to that includes RAILS_ROOT/themes/#{themename} .  There are a couple of other tricks to get stylesheets, javascript and image directories to live in the theme directory.

I've been playing with Rails a bit and it's been quite interesting.  I quite like the way that the framework is modeled.  It guides you nicely into a highly structured web application model but allows you to break out of this model when you feel the need.  I generally find that the default behaviours feel right.

I have run into a number of name space clashes that produce mysterious errors.  Try adding an attribute named attributes to an ActiveRecord and see what I mean!

Obviously the "Programming Ruby" and "Agile Web Development with Rails" are must reads before you get started.  A lot of the API documentation has been pulled together at ruby-doc.org, api.rubyonrails.com and script.aculo.us.  I have found that the documentation to be just a little bit thin in places.  It seems to often be more suited as a refresher for experienced Ruby/Rails programmers and not so much to learn the APIs from.  So you often have to resort to google searches to find a blog entry where someone before you has had exactly the same problem understanding the concept or the interface.

I've been following Rails for quite some time now and have now finally come across a couple of new, small projects that might get some benefit from Rails rapid, test driven development framework.  One project is a quick prototype for demonstration purposes and the other is social networking idea that I've had for quite some time.  If nothing these, these two projects should give me a better personal sense of how Rails development compares to others that I've used in the past.

In one perspective, it won't be a fair comparison because most other development environments that I've used in the past did not have well developed frameworks when I did the majority of work that I did in them.  In the mid to late '80s, I was writing code in C and assembler, mostly is MS-DOS.  A lot of these programs were TSR (Terminate and Stay Resident) and extended memory based program so you were really working without any kind of net, let alone a framework.  You even had to rewrite parts of the libraries and startup code that came with the compiler just to make them work in these environments. 

In the late '80s and early '90s we moved to C++ and started to do serious work in Windows.  It was refreshing in some sense because we were at least working in a mostly documented environment although we quickly started to get into hooking into Windows internals so that we could control other applications.  In the early '90s Microsoft brought out MFC but that was worse than using the raw Win16 API.  At the beginning of one big project in '91 we did an extensive survey of all of the available frameworks for Windows and they all failed to impress.  Most suffered from poor performance, bloated size, restricted feature sets and stability problems.  So we built our own application framework (AF).  It used the Windows API as a model but abstracted the interfaces in to a series of object models in C++.  Most importantly it got rid of pointers.  Buffer overflow and bad pointers were almost completely eliminated.  These had been the source of 95% of bugs before that.  The AF made it a lot easier for non-Windows GUI programmers to write Windows code.  The AF worked so well that when Windows 95 and Windows NT came around and the Win32 API was available, it took us 2 weeks to update the AF and all of our software ran flawlessly.  We maintained Win16 and Win32 version of that software for years until people finally abandoned Windows 3.1.

In the mid '90s I moved into web development, writing in C, C++ and perl.  There were some crude libraries to help with some aspects of CGI programing but you were mostly on your own.  We tended to resort to running fairly traditional services that interacted with a web server via CGI connector scripts.  Java started to look like a real ray of hope.  It was a much cleaner, simpler language than C++ and the runtime overhead didn't seem too bad.  You could write desktop and web client apps and the networking libraries were very rich.  Unfortunately the user interface libraries generated ugly user interfaces.  I don't think that Java has recovered from that.  I suspect that is why Java now seems relegated to take the place of COBOL in business/financial apps where UI has never been very important.

In '98 I started using PHP.  I kind of felt embarrassed using such a light weight language.  It almost felt like I was using Visual Basic.  Not something that one admits to.  But the thing was, you could create a simple web apps extremely quickly.  While it wasn't fully object oriented and wasn't designed for programming-in-the-large but there were a lot of web apps that needed writing that didn't need that.  You could also easily find all the documentation that you really needed in one place, the php.net website.  A the time, there weren't any good frame works.  I'm not sure if there are any good PHP frameworks now.  The base API and libraries are at a pretty high level so there is no really urgent need for a framework.  I've created my own libraries and patterns that work for the projects that I've been involved in.

In the last year or so, I've been looking around to see if I could improve upon PHP.  Java and .NET are looking pretty strong in enterprise environments but I was looking more for something that works well in the Web 2.0 world.  Python and Ruby were obvious candidates.  I spent some time with Python and liked the language but fond that the various libraries to be awkward and buggy.  Documentation was scattered widely.  There seemed to be a lot of "lets see if we can reproduce what's been successful in Rails" talk.  So I thought, go for Rails and cut out the middle man!