Edgy Developments

I’ve been enjoying using foxy fixtures on new Rails projects, and wanted to start using them on some older fixture-heavy projects, but couldn’t bring myself to manually change over from id-based to foxy name-based fixtures. It would involve finding all the foreign keys in each fixture, then looking up the names of the fixtures with those ID in other fixture files, and substituting in those names. It sounded tedious and easily automated, so I went in search of a plugin or code snippet to do the work. Finding none, I wrote a plugin, ‘Foxify Fixtures.’ Install it with:

script/plugin install http://foxify-fixtures-plugin.googlecode.com/svn/trunk

Make sure your app is safely checked in to version control, or make some sort of backup in case things go awry, and run:

rake db:fixtures:foxify

The plugin was developed around two apps that I wanted to refactor to use foxy fixtures, so in all likelihood it won’t work on other apps without some tweaking. Feel free to contribute back any fixes through the plugin’s new home in Google Code: http://code.google.com/p/foxify-fixtures-plugin.

In order to separate blog posts on software development and startup stuff from posts on food, health and TriggerFood, I’ve started a separate blog, Thought Triggers. So from now on, expect this blog (Edgy Developments) to have posts that would be of interest to people in the web application world, and the new blog to be of more interest to people who could benefit from TriggerFood.

A recent article reports that 6 percent of middle schoolers and 14 percent of high schoolers suffer from IBS(irritable bowel syndrome)–such shocking and unfortunate figures. The only good news that the article is reporting on a recent study showing that low dose antidepressants improve IBS symptoms for these youth, something that’s already been found for adults. This just serves as another reminder that medical knowledge is constantly expanding, and it’s important to make use of medical advances that doctors can offer, in addition to health management techniques like using a food an health journal.

While developing TriggerFood, I’ve been doing a decent job with software development and system administration, but have had a harder time getting up to speed with web design. I’ve heard that when developing web applications, one must recognize one’s strengths and weaknesses, and seek professionals for those rough spots. Plus, I only have so much time, so it helps to offload some of the work. So a few weeks ago I signed up on elance.com, and used the service to procure the services of a talented web designer. It was a great experience, and I highly recommend it to anyone seeking to outsource portions of their projects.

I think the key to having a good experience with hiring a freelancer is coming up with a very well specified task, so that it’s clear on both ends what’s supposed to be done. Clear task descriptions are also likely to attract more (and perhaps better) bids, since a vague description is a good indicator that the person outsourcing the job doesn’t know what they want.

As a first time user of Elance, I also really appreciated the escrow, milestones and private message board features. These all go a long way toward making a first time user feel safe using the system.

See the snazzy result at www.triggerfood.com.

It’s amazing how often the potential usefulness of TriggerFood comes to mind in everyday conversation. Here are just a few recent health concerns that came up as potentially having trigger foods:

• Foods that nursing mothers eat that make their babies fussy
• Acne
• Asthma? http://www.ific.org/food/allergy/index.cfm

Nothing makes you appreciate a well-built web application more than building one yourself.

I thought it might be useful to start posting some of the web apps I use myself and find particularly inspiring. One that I’ve started using recently is Mint, a personal finance application. There’s so much to like about it:

• Beautiful interface: It’s easy on the eyes, and uses various web 2.0 techniques to make the user experience more enjoyable. Perhaps the most visually impressive aspect of Mint is the interactive spending pie chart. You start with a pie that has a slice for each major spending category, but when you click on a particular slice, it divides into subcategories and expands out. Stunning, and probably better appreciated if you check it out yourself.
• Simplicity: It is not Microsoft Money or Quicken, nor does it aspire to be like these juggernauts of personal finance. Mint is not for everyone. I’m sure there are innumerable features that Mint doesn’t have, but it does what it’s intended to do quite well–automatically gathering your various account transactions and tagging them, and then letting you track your spending and do budgeting if you like.
• Free: Mint employs an advertising-based business model where users are presented with ways to save money through affiliated businesses, such as interest-bearing checking accounts or lower-interest credit cards. So the ads are both very targeted (Mint know what interest rates you’re currently getting), and show dollar amounts that you stand to save if you take advantage of them.

A name has been decided upon, and a site is now up. Aptly named TriggerFood, this site will eventually be a web application that combines a food and health diary with analysis to find foods that affect one’s health. Right now the site just exists to let everyone know what the software will be all about, and let you sign up to be on the mailing list (no spam, I promise). Work is well underway on the web application, and this blog will continue to chronicle Ruby on Rails tidbits I come across as well as other interesting aspects of creating a web application.

Anyone developing and deploying a web application will be aware of the numerous choices for each part of their technology stack: web host, server type, operating system, web server, database, and of course the actual application language/framework you’re using. My choices for an initial setup were constrained by personal bias and cost. Personal bias led me to use Ruby on Rails as the application framework, and MySQL as the database, since I’ve used these quite a bit in the past. Plus, I’d argue that they’re good choices in their own right.

Cost was a major driver in the choice of web hosting and the type of server I chose. Previous Rails projects have taught me that a shared web server isn’t a great idea–with many hosting companies they tend to be a overloaded, making Rails apps slow to a crawl at time. Plus, deployment is often limited to Apache+FastCGI, an often troublesome combination. So despite being cheap, shared hosting wasn’t going to work for this project. Thankfully,with the advent of virtual private server (VPS) hosts, you can get your own allotment of CPU and RAM, on a virtual server that’s entirely under your own control. My choice was slicehost, which I’ve had a very good experience with so far.

Being able to configure the server from scratch meant having any choice of web server deployment setup. I picked Ubuntu 6.06 as the operating system, since it not only is Ubuntu what I use for my desktop computer but there is also extensive documentation by other Slicehost users for Ubuntu. In order to have a small memory footprint, I picked the combination of nginx and mongrel. Mongrel seems to be vastly preferred over FastCGI, so this was an obvious choice. For the actual web server, Apache seemed like overkill as just a front end to the mongrel processes, and I noticed that nginx has been gaining popularity with the low memory footprint Rails crowd. It also supports SSL, which may be something I eventually need.

So that’s the stack I’m using: Slicehost VPS+Ubuntu+nginx+mongrel+RoR+MySQL. It’s relatively painless to set up, and an excellent opportunity to improving one’s Linux administration skills.

After years of using Eclipse as my Java IDE of choice, it was easy for me to switch over to RadRails/Aptana when I started working in Ruby on Rails. Despite these inclinations, when I heard that NetBeans had Rspec support and a few other niceties, I couldn’t resist checking it out.

Although all of the necessary pieces for getting started with Rails in NetBeans and Rspec/Autotest support are have already been documented in bits and pieces, I thought it’d be useful to lay out a guide for setting this up from scratch. Since IDEs tend to have graphic interfaces, we’ll rely heavily on screenshots.

Prerequisites

Before starting, I’ll assume you have the following installed and working:

• Ruby
• Ruby Gems
• Java JDK

Download and install NetBeans 6.0 Beta 2 or newer

At the time of writing, the latest beta release of NetBeans 6.0 can be obtained here. The installation should be straightforward, assuming you have a recent JDK installed.

With installation complete, launch NetBeans. Here’s the default interface layout. Nothing to groundbreaking, with the editing pane surrounded by navigation on the left, and output on the bottom.

Now we’ll need some gems, which we may as well install through NetBeans. Go to the Tools -> Ruby Gems menu option.

Go to the New Gem tab. We’ll need rails, ZenTest, ruby-debug-ide and sqlite3-ruby (plus all their dependencies). Select these and Install.

Be sure to include dependencies, and in this case we can just use that latest rails (1.2.5 at the moment).

If all goes well, you should see something like this. Repeat the process for the remaining gems you’ll need (ZenTest, ruby-debug-ide, sqlite3-ruby)

Now to actually create a project. Go to the File -> New Project… menu option.

Choose Ruby on Rails Application, and hit Next

We’ll draw on the original Tutorial in Ruby on Rails for inspiration, hence ‘MyProject’ as a title, but name the project whatever you want. Use sqlite3 as the database unless you have another preference. Make sure the ruby interpreter you want to use is selected. Next.

The last screen in the new project wizard should show that Rails is already installed, if the Ruby Gems steps above worked correctly. Finish.

NetBeans has created the skeleton of our Rails app, which can be explored through the navigation pane on the left. It pops open the database.yml so that your database configuration can be defined. No changes are needed if you’re using sqlite2 or sqlite3.

Now we need to install the necessary plugins so that we can use Rspec. In the navigation pane on the left, right-click on the project name and choose Rails Plugins…

We need to add the repository for Rspec. Go to the Repositories tab, and choose to Add URL…

Enter the URL for the Rspec Subversion repository:svn://rubyforge.org/var/svn/rspec/tags/CURRENT. Hit OK.

Now go to the New Plugins tab, and select both rspec and rspec_on_rails. Choose Install.

You have the option of installing the plugins as svn:externals or as an svn checkout. I tend to skip the elegant svn options so that I have the files in my own subversion repository, rather than relying on someone else’s indefinitely being around. Hit OK.

Now the plugins have been installed, so we can make use of Rspec in our project. Close.

Next, we have to generate some files in our project for Rspec. Right click on the project name in the left-hand navigation pane, and click Generate…

Choose rspec and hit OK. Now we’re all set to use Rspec.

Now to generate a controller and it’s spec. Right-click on the project name, and pick Generate…

Using the rspec_controller will provide us with a controller as well as the necessary spec files. By entering ‘hello index’, we’ll produce a controller named hello with one method called index. Hit OK.

In the navigation pane on the left, there will now be some files under Rspec.

Open up hello_controller_spec.r. To run the spec, either choose Run->Run File->Run “hello_controller_spec.rb”, or use the keyboard shortcut Shift-F6.

The output window at the bottom will display the output of running the spec, plus in the editor pane you’ll get a summary that’s either colored green if your spec had no failures, or red if there were failures.

We can take Rspec a step further if we like, and get Autotest running (assuming you installed the ZenTest gem). Just right-click on the project name in the left-hand navigation pane, and choose Autotest. This will start an initial run through all your specs, and then re-run every time a file is saved.

Now we’ll add a trivial spec for our ‘hello’ controller, saying that there should be a ‘message’ assign that says “Hello World”. If we then save our spec, autotest kicks in and says we now have a failure.

Another nice feature of NetBeans is that you can quickly switch between a spec and the controller/model/view that’s being spec’d, using the keyboard shortcut Control-shift-T. Do this to switch to the ‘hello’ controller itself. Add a line so that @message is set to “Hello World”. Save the controller file, and autotest kicks in again, saying that our tests pass!

So that’s all there is to getting going with Ruby on Rails in NetBeans, with added bonuses of Rspec and Autotest. Enjoy!

As a Ruby on Rails developer it can be helpful to keep an eye on changes being made to Edge Rails (the latest developmental Rails code base). Sometimes you’ll spot specific fixes for issues you’ve run into, or see neat stuff that is won’t make it into an actual Rails release for quite a while. I thought the ideal way to keep track of this would be an RSS feed of all the changes. A quick search on the subject didn’t turn up anything, so I found two ways to accomplish this.

The first method is generally applicable to any Subversion repository. It involves outputting the Subversion change log, and then using a nifty XSLT created by Martin Pittenauer. I did modify the XSLT slightly so that it puts the commit comments in the title (rather than just the revision number and author). Here’s the command-line business to generate the RSS for updates over the past week:

svn log http://svn.rubyonrails.org/rails/trunk -r {`date --date='1 week ago' +%Y-%m-%d`}:{`date +%Y-%m-%d`} --xml -v > rails-changes.xml
xsltproc ../svnlog.xslt rails-changes.xml > rails-changes.rss

I set up a cron job, which hourly updates this RSS at http://rails-changes.dreamhosters.com/rails-changes.rss, although I find that with Google Reader the updates are quite slow.Of course, after all this effort I found that there’s a better way. Since the Rails project uses Trac, I found that Icould just customize the ‘Timeline’ page and then use the RSS feed link at the bottom. This link reproduces what I did above, without all the effort.