Read my latest article: 8 things I look for in a Ruby on Rails app (posted Thu, 06 Jul 2017 16:59:00 GMT)

Keeping the Code Organic

Posted by Sun, 30 Oct 2005 00:30:00 GMT

The landscape around us is quickly changing-really, it has been changing for some time now-we’ve come a point where we admit that it’s okay to want more for less. We want more features, in less time. We want more control, for less money. Why? When did we collectively decide that huge monolithic systems could be completed in a fraction of the time it should take?

After years of working in .NET, PHP, Perl, and even a little Python, I have gone down the road of simplicity. I want simple looking code (thank you Ruby). Code that I can hand off to another developer and for them to simply get it—which helps to keep things moving. It’s about getting the project done.

Scenario: The client wants delivery in X days, so you aim for Y days early. Shortcuts get made, tests are forgotten, code is blemished, and deadlines still manage to sneak by unmet. Why do we do this to ourselves?

I say, no more!

Sacrifices Are Okay

What? You mean I can choose to leave something out? I can-dare, I say-tell my client no? Yes! Well, maybe. It’s time to re-think how you view your projects. Have you asked your client, “What is the single-most-important feature of this project?” Every project has one. Your customer will likely be relieved to hear that you care about the purpose of the project. And it gives you an idea as to where not to make sacrifices, which in turn helps to identify the areas where you can.

So, if you haven’t asked them yet… ask them now.

The Big Picture

If things change, how will it impact your timeframe? When your schedule is threatened, it becomes easier to see what isn’t necessary, or perhaps, not necessary right now.

All features in a project are part of the big pictures. If you ask your client what is required they will almost always respond with the all to easy, “everything.” Simply accepting this as fact often leads to shoddy workmanship in favor of giving your client “everything.” To the client it may seem like you aced the test, but that’s because they don’t know you’ve cheated. I’m sure a lot of you know what it’s like to inherit the code of someone who has done this, and you know you’ve probably been on the other end as well.

A Neverending Story

Projects aren’t just instantly created, they evolve. They need to be fine-tuned, maintained and should most certainly be refactored when necessary. Most projects require ongoing work… because requirements do change.

It’s time to stop and really consider how you approach both your clients and their projects. Can the next project be built in an evolutionary fashion? Can you focus on one new feature at a time, maintaining your tests, and avoiding bloat?

“Big fleas have little fleas Upon their backs to bite ‘em: Little fleas have lesser fleas And so ad infinitum.”

I found this in a book that I picked up at the local Library booksale for something like 20 cents. The book, The New Utopians by, Robert Boguslaw was written in 1965 and has some insightful thoughts on systems as organisms.

Keep it Organic

Pesticides are not necesary to produce quality produce. They are a cheap shortcut that can cause other problems in the longrun, and are generally not a healthy addition to the lifecycle of the fruit or vegetable (or to those who harvest it and consume it).

Test-Driven Development allows you to constantly monitor the behavior of your application. Feature-Driven Development keeps your team focused on what is currently the most important piece of your project. Don’t rely on pesticide, let the project flow the way it wants to.

Keep it Flexible

Business Rules should not be flexible… but they should. That sounds confusing, but it’s not. Know where to make that distinction. Add your rules first… build your tests… then code. Maintain flexibility through your rules.

Test First. Code Second. Lather. Rinse. Repeat.

Be Proud of Your Code, But Not Blinded By It

You’re biased. Your code is biased. The opinion that you have about your code is biased. You are proud of your code… but you can do it better and some people are better at somethings than you are. Don’t dwell on it, embrace it.

How many of you are making the mistake of being the only programmer on a project? I’m not a big fan of big teams, but I know that small and focused teams are extremly productive and better positioned for the big projects of tomorrow. Find someone that you trust and trade peer-review time. Not sure where to start? Pick up a copy of Refactoring. It’s time that you RE-think how you are doing things.

Embrace Heuristics

It’s time to challenge yourself. A new year is almost upon us and we’re all behind on our goals… because things change. This is the time to explore your possibilities. Learn something new. Don’t be afraid to break things. Just learn why the thing broke. Learn to be a good tester. Learn to write cleaner code. Learn to refactor your code. Learn to make it readable.

Learn to learn… and remember to buy organic. ;-)

Migrating from MySQL to PostgreSQL in 60 seconds (with Rails)

Posted by Sat, 29 Oct 2005 18:23:00 GMT

I do quite a few MySQL to PostgreSQL migrations for clients of PLANET ARGON and over the years I have gone through different methods of handling this procedure. Typically, it involved exporting data, re-importing it through some shell script that does its best to take into consideration the slight differences between the two databases.

While working on a recent project that was to be migrated from MySQL to PostgreSQL, but after some Refactoring had been done to the code base. I had been meaning to spend a few hours coming up with some simplified process of taking data from MySQL and replicating it to a new PostgreSQL database, while maintaining referential integrity.

My original idea was to build a script that referenced two seperate databases and then copied data out and inserted it into the new db after performing a few data changes. This seemed like too much work and I knew that I should be able to harness the power of Ruby and Rails in my process. My next thought? RailsFS.

In a perfect world, I would mount one instance of the application with a mysql database and another with a postgresql database… and just copy the yaml files to the postgresql and bam, it’d work, right? Well, it doesn’t quite work that way. So, I ruled out that idea.

Then I had another idea. I would build a task in my Rakefile that… imported each of those YAML files into PostgreSQL!

We can now type in the following commands:

This first creates my PostgreSQL database tables using Migrations.
rake migrate VERSION=1


rake mysql2pgsql
mysql2pgsql runs…and approx 60 seconds later, I had an exact copy of the MySQL database in PostgreSQL. But wait! PostgreSQL has SEQUENCES… so I then run:
rake migrate VERSION=2

...and my SEQUENCES are ALTER’d.

Yes, I will post some code in the near future. But all I am doing is basically running through all the YAML files that are available from RailsFS and adding them into the new database. It automatically figures out the model name…and is fairly generic at the moment. However, I’d like to spend a bit more time stress-testing it before I post it. :-)

I want to try to work on a RailsFS-less version as well so that I can run this on my PowerBook.

Until next time… have fun!

I wink'd at Ruby-Doc and all I got was this lousy...

Posted by Fri, 28 Oct 2005 01:50:00 GMT

It seemed like just a few minutes ago that I was looking at some documentation on Ruby-Doc. While there… I noticed something rather strange. Something different. I found myself looking directly into the cold eyes of the famous hoodwink.d icon. After about seven insense seconds of confusion, I reminded myself that it was okay. As much as winks frighten me, I really don’t believe that _why is smart enough to figure out how to watch me through those icons. Could he be there? Watching me? Could it happen? Is AJAX going to allow _why to do this?

Could This Be The OTHER SIDE of Hoodwink.d ?

In any event, I believe that I am the first person to post a wink on the RUnit library. I was very assertive when I posted my wink.

Come wink at Ruby-Doc with me!

The opinions expressed in this blog post do not reflect the opinions of other hoodwinkers. _Why, if you’re watching me. Stop it. :-)


Refactoring Rails... coming soon

Posted by Thu, 27 Oct 2005 18:30:00 GMT

As you may have heard earlier, Jeremy Voorhis and I are working on a top-secret project together. We’re going to keep things quiet for just a bit longer while we get an initial site together. In the meantime, sign up on our mailing list to be notified when we launch it.

We present to you…. Refactoring Rails.

Jeremy posted a short teaser on his blog and we’ll just keep you in suspense… but keep an eye out in the coming week(s). :-)

For more information, bookmark:

“Remove ambiguities and convert to specifics”Brian Eno, Oblique Strategies

PLANET ARGON 2.0 Release Candidate

Posted by Tue, 25 Oct 2005 17:10:00 GMT

We finally found a way to sneak in some extra time to finish up the first phase of our new website. Allison and I are excited to announce the launch of new PLANET ARGON website,

What Powers It?

Ruby on Rails and PostgreSQL!

What Has Changed?

For starters, we have a new design. Hopefully the information that you are seeking is easier to navigate to and the order process is a bit easier too. Aside from that, we’ve made just minor changes to our hosting offerings to reflect the needs of our customers. I’ll touch on that shortly.

ReEmphasize The Small Stuff

We first started offering Rails hosting to the public at the beginning of February. In just a week we’ll have nine full months of experience under our belts. Our customers have been a huge influence on the type of services we offer, and the level of support that comes with it. It was out of my own desire to have a web host that allowed for bleeding-edge technology that lead me to start my own hosting company… so that I could turn around and offer other developers, like myself, the same service, without the time commitment of managing your own server and the price tag that goes along with it.

Our Customers are Awesome!

No really, they are. We recently setup an RSS aggregator of some of our hosting customers that run blogs (many of them are running Typo). We call this site, Inhabitants of PLANET ARGON. ( Check it out!

More Space!

We’ve spent some time really looking over our hosting plans and wanted to give them a make-over that reflects the requests of our customers and potential customers. We’ve increased the disk space on the first three of our shared-hosting plans, and lowered the price on the fourth. Take a peek.

Some of our prices have gone up (with the increase in disk space), but our Level 1 plan still starts as low as $11.25/month. This can get you rolling on Rails using PostgreSQL and/or MySQL! :-)

Typo Hosting

We started offering affordable blog hosting last year. Then Typo took off, and none of the other blog software packages were being requested! We have dropped all the PHP blogging applications from our offerings and are now offering Typo Hosting exclusively. For $3/month, you can have your own pre-installed Typo blog!


Well, sort of. If you sign up by midnight (PST) on October 31st, you will receive 1 FREE Month for every 6 month account and 2* FREE Months* for every year! (Blogs too)

We’re Not Just a Hosting Company

PLANET ARGON was started as a web development and consulting company, and it still is!

Who Is Allison?

Allison is the Creative Director here at PLANET ARGON. Existing customers of ours know about her… but she’s kept a low profile up until now. She is a ninja in the ways of project management, clean design, and has been known to have a tab open in her browser to the Ruby on Rails API. Expect to hear more from (and about) her in the near future.

For more information, see:

Using Named Placeholders in Ruby

Posted by Fri, 21 Oct 2005 04:53:00 GMT

2 comments Latest by Sokolov Yura Sun, 27 Aug 2006 07:34:26 GMT

Insert Hip Quote Here:

“In ancient times, hundreds of years before the dawn of history, an ancient race of people… the Druids. No one knows who they were or what they were doing… “ – Nigel Tufnel, Spinal Tap

Story Time…

Earlier, I was giving a customer of ours, Jared from a quick tutorial on some of the features script/console… which lead to helping him with a SQL query. When I provided him with some working code he was curious about what I had done in the SQL query string that I was passing to find_by_sql.


If you have ANY SQL queries that resembles the following, PLEASE READ THE REST OF THIS. :-)

values = params[:search]
RockLegend.find( :all, :conditions => "first_name = '#{values['first_name']}'" )

If you are doing that… then you are opening yourself up to some security problems. Let’s take a few minutes and discuss how you can make this more secure and still keep your code readable. (the best of both worlds!)

The ? Placeholder

Many of you are probably familiar with this approach…
RockLegend.find( :all, :conditions => ['first_name = ?', 'Nigel'] )

RockLegend.find( :all, :conditions => ['first_name = ? AND last_name = ?', 'Nigel', 'Tufnel'] )

You can pass it a hash as well.. and as long as you put everything in the same order as the ?s are placed… then all is well.

My only real problem with this approach is that it requires you to keep things in a specific sequential order… and who wants to keep track of that? So, I would like to recommend that you use named placeholders. Aside from that, it looks magical and I don’t like magical-looking code. I like easy to read code. :-)

Named Placeholders

If you already use these… you know how useful they can be in your SQL queries. If you haven’t seen them before… it’s because the Rails docs don’t really mention it and is something that comes from the underlying database library in Ruby. So what is so great about these?

Let’s first replace the above code with named parameters…
RockLegend.find( :all, :conditions => ['first_name = :first_name', { :first_name => 'Nigel' } ] )

We are passing a hash with a matching key to the conditions option. Pretty neat, right? In this case with just one placeholder we just increased the amount of code to do the same thing. So, it might always be the best solution… but it is easier to read.

Let’s try another with multiple keys in our hash… infact, we’ll build the hash prior to calling find.

values = { :first_name => 'Nigel', :last_name => 'Tufnel'}
RockLegend.find( :all, :conditions => ['first_name = :first_name AND last_name = :last_name', values ] )

It will happily match the hash keys to the named placeholders in the conditions string. Again, nothing terribly exciting…but it is easier to read.

Who cares about order? Not named placeholders!

Okay, let’s mix things up a bit…

values = { :last_name => 'Tufnel', :first_name => 'Nigel' }
RockLegend.find( :all, :conditions => ['first_name = :first_name AND last_name = :last_name', values ] )

The hash keys were not added in the same order… but it still works!

Okay, now for one last quick example (it’s late and I am tired…).

I have a search mechanism on a site that allows you to search for a string of text across multiple fields. So, I have one string… but several fields to compare against.

Here is a string that I will pass to the find method.
conditions = "role = :role AND (first_name ~* :str OR last_name ~* :str OR nick_name ~* :str)"

Note: this string is using PostgreSQL regular expressions... (~*).

Here is a hash that with that matches the keys, :str and :role

values = { :str => '^(Nigel|Tufnel)$', :role => 'Guitar' }

If you look above, you’ll see that the conditions string contains four named placeholders… but the hash only has two keys. With the ? placeholder, we would have to pass the same vaule three times… which isn’t any fun to read or maintain. ;-/

So, with our new friends, named parameters, we can call find (or any find-like method) using this technique for placeholders.

RockLegend.find( :all, :conditions => [ conditions, values ] )

...and hopefully this is useful to you. :-)

Have fun!

Older posts: 1 2 3