Robby on Rails

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.

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:

rake migrate VERSION=1

then…

rake mysql2pgsql

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!

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. :-)

wink

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: http://www.refactoringrails.com

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

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, www.planetargon.com.

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. (inhabitants.planetargon.com) 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!

FREE RAILS HOSTING!

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: http://www.planetargon.com

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 CommunityWalk.com 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.

WARNING

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

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?

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.

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!