Robby on Rails

Why is everybody interested in using PostgreSQL? We all know that it’s a pain to install, a pain to maintain, and Rails only works with MySQL. So, why do we bother?

This article titled, Five reasons why you should never use PostgreSQL. Ever. clears up these questions.

My favorite is… “Reason #5: You (don’t) get what you (don’t) pay for”

Imagine if we said the same thing about Ruby on Rails?

Similar Post(s): The bitter-sweet taste of agnostic database schemas, Localization with Rails and PostgreSQL, part 1

I was skimming over a few RSS feeds ( blogs.thoughtworks.com ) this morning and came across an entry by Griffin Caprio. He shared his thought on the new book by Chris Pine, Learn to Program and says the following:

”...You wouldn’t see these types of books in other professions like medical, engineering, or accounting because there are boards that prevent just any old person from practicing in those fields.

And I understand everyone’s love of Ruby, but come on people. It’s just a language.”

Actually, yes. Learning to program, build, create, test, problem solve, etc… are all things that we should encourage.

Let’s do a quick search on amazon for the following, Learn to Program. I’m pretty sure these books have been common place for the past 20+ years… so, what’s the big deal?

It’s like telling a kid not to build a bird house until he gets a contractors license and a permit.

...or telling someone to not pick up a guitar until they had proper lessons.

...or maybe you shouldn’t be running a business without graduating from college.

I could go on and on.

Oh… and by the way…

puts "Hello World"

is much sexier than

public static void main(String[] args) {
  System.out.println ("Hello World"); 
}

On that note… check out Learn to Program by Chris Pine.

UPDATE Griffin has followed up to my blog entry with another. He goes on to say, “The kid who builds the bird house above would never be hired to build an actual house. Not true in Software Development.” (read more)

I think this problem raises a completely different problem. Why are unqualified people being hired to do things that they aren’t qualified for? Do we blame the people learning to program or do we look at who hires these people in the first place? I’m still confused by his argument.

That kid may not get hired to build a house, but he may get interested in that as a career and continue to pursue it… if someone hires him to build the whole house, then the person hiring should be held accountable do some degree as well. Check references! ;-)

On the flip-side… is this an argument to only take people who have been approved by some board (...MCSE?) seriously when hiring developers?

Update #2

Griffin has outlined his points in more detail in this third entry.

DHH wrote that Tim O’Reilly wrote on O’Reilly Radar, Ruby Book Sales Surpass Python.

While I was looking at the data, though, I noticed something perhaps more newsworthy: in the same period, Ruby book sales surpassed Python book sales for the first time. Python is up 20% vs. the same period last year, but Ruby is up 1552%! (Perl is down 3%.)

...awesome!

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.

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

• Got double booked on meeting night with the PHP group
• Got asked to leave after getting threats of the lights being turned off
• Stayed almost til closing time at a brew… we heard, “Last Call!” and still continued talking…

Tonight I finally got to meet Ben, Caleb, Justin Watkins, Marcus Estes, Lennon Day-Reynolds, Jeremy Kempter (bitsweat), Aaron Johnson, and Peat Bakke-each for the first time. I also got to see Scott Laird (of Typo fame) and John Labovitz again. Scott and I met at FOSCON and John once found me when he was trying to hack people at a coffee shop and saw that I was on the wireless network. Okay, he wasn’t hacking… but found me at Urban Grind. :)

We had about ~25 people show up. I don’t think that there was a head count made. We sat around in a big circle and fired questions at both Derek Sivers and Jeremy Kemper. Topics ranged from how Derek found his way to PostgreSQL to why he thinks that he is an amazing web designer (smirk) to why Ruby and Rails was picked as the platform to move to from a PHP/MySQL system. Jeremy shared some insights into some problems with Rails that need to be worked on (boolean-stuff for example), tips on debugging, and many other things that I don’t recall off the top of my head.

It was a very relaxed and open conversation with some cool local developers who are working on getting their Rails/PostgreSQL system finished.

After we got kicked out of FreeGeek most of migrated to the Lucky Lab Pub… and then we realized that Derek and Jeremy didn’t show up. So, we found our ways to a big table and broke up into smaller conversations. I got stuck at the table with Ben, Scott, Caleb, and John. Actually, it was quite enjoyable. Scott talked about his work with Typo and Ben and I gave him some of our thoughts on things.

This is a horrible summary of the whole evening. It’s what I remember… and it’s late and I look forward to getting to hang out with this gang again in the future. I think that it was great to get to finally meet a few of the people that I have worked on some smaller projects with. If everything works out well, expect there to be some more projects coming out of the PDX.rb in the coming months. :-)

Thanks again to Derek Sivers and Jeremy Kemper for taking time out of their busy schedule to meet & greet with the Portland Ruby people. :-)