Tim Harvey :: Blog

Yea, so I completely procrastinated on getting a bunch of domains off a server that I had setup with annual billing. Moving domains from one server to the next is one of the worst ways I can think of to spend time. I’d probably rather have a root canal.

Due to the hosts billing setup, I can’t go month-to-month. While that creates an awful headache as I have to move every site off NOW…it’s best in the long-run.

A friend of mine is taking over all my consulting clients so I will no longer be in the hosting business, nor responsible for clients sites if they go down. I still have a couple web-based services that I’ll continue to support for a while.

One or two will get shut down pretty quickly (Am I Down has already been open-sourced, and the Twitter Filter is next). ShipperTools is a bit harder to drop as it’s profitable. I suppose that the maintenance time on it is next to nothing, so I’ll keep it going for a while.

This site was the first one to shift over. Wish me luck!

This is part of the Peer Pressure Learning 30 series. Jump to my introduction to the experiment if you haven’t been following along.

Wow, this week has been a PPL catastrophe for me. The following are all lame excuses, but I’ll give them anyways.

The weekend definitely kicked my butt. The ladies have all been sick, so a number of late night compounded into me not getting up early and having zero energy to blog at 11pm. So there went Sunday and Monday.

Yesterday got really interesting. After doing a spontaneous 10 mile ride in the morning on the way to work (the most I’ve done before is 5-6 miles), I played soccer for 90 minutes in the evening. While I was about done, I realized that I have a VPS server that will expire within a day or two that needs migrated to a server run by a friend who took over all my hosting clients. AHH!!! These sites are so old that I doubt they (or I) have the best backups around. So into panic mode I went attempting to extend my server service and get sites moved. Not good.

On the bright side, Peer Pressure Exercise and Geek Fitness are looking great. I’ve biked to work for three straight weeks and am beginning to get some longer rides in. Gotta look on the bright side, right? GRIN.

So…I’m hoping to get back into it at lunch today, keeping the bleeding to just three days. If all goes well with the server move, perhaps I can get back on track before the Indy.rb meetup next week. If not, I think the heckling might be more than I can bear!

End of sob story…back to the code!

This is part of the Peer Pressure Learning 30 series. Go read my introduction to the experiment that Miles and I embarked on.

Since this is a pretty meaty chapter, I want to take my time and really internalize the lessons here. Just like a University’s capstone course, these case study chapters should apply all the lessons that came before and help me see how it all comes together.

As such, I’m converting the example code into the Ruby equivalent. That will both make it familiar and push me to think through why I would make the various refinements. It’s also great to do some pure Ruby. I do so much that’s Rails specific that I like the opportunity to get back the the core language.

Today’s Reading: Reread pg 177 – pg 186

I skimmed ahead a bit since I covered the same material from yesterday. I realized that I was converting the nice, clean copy of the argument parser and probably shouldn’t. The text goes back in time to an earlier copy that’s pretty rough, then proceeds to show how it evolved. Oops. (I thought we would be taking the nice one…mucking it up with some hacky fixes, then cleaning it up)

So I’m taking a step backwards to code up the “bad” version in Ruby and will follow along with the improvements. Unless the tests are in the chapter (which I don’t think I saw), I’ll probably see about throwing in some rSpec as I go to fully TDD the whole thing.

Out of deference to the author and all the work he did on these examples, I won’t be sharing the Git repo. However, I’ll look for some chunks of code that I could post to illustrate interesting points.

What’s next

Always one to get going on the next thing…I’m already thinking about what I’ll do next month. The ideas I like best involve either creating an app from scratch and applying Clean Code principles, or perhaps cleaning up my Twitter Filter or Am I Down.

I may not be brave enough to commit to a full 30 days, but perhaps I can keep up the pace. Ideally, I would spend 30-60 minutes each day and post the repo and selected improvements as I go. My latest thinking is that I would implement Am I Down in Rails 3 with Reddis and maybe Mongo.

This is part of the Peer Pressure Learning 30 series. Go read my introduction to the experiment that Miles and I embarked on.

It’s actually not too late in the evening and the whole family is asleep. It’s a good time to hit the Clean Code! The next couple chapters will be interesting to write about. There are several extended case studies, so it’s a change of pace. We’ll see what comes out of them!

Today’s Reading: pg 177 – pg 186

Well, not a lot to say for this first portion of the chapter. I will say this, I read a ton of code and need more time to digest it. Another run-through tomorrow will help.

The following made me really happy I don’t used Java:

It’s remarkable how much code is required to flesh out the details of this simple concept. One of the reasons for this is that we are using a particularly wordy language. Java, being a statically typed language, requires a lot of words in order to satisfy the type system. In a language like Ruby, Python, or Smalltalk, this program is much smaller.

I almost feel that to do this chapter justice, I should do just that; write it in Ruby. That way, I get a better feel for how it works and what’s going on as the program changes. I think I’ll lose too much in translation as I try to ignore the verbose nature of Java.

This is part of the Peer Pressure Learning 30 series, taking me through Clean Code in 30 days. Take a gander at my introduction to the experiment if you have no idea what that means.

The site I talked about yesterday, http://ErvsCafe.com is available on GitHub if you want to see the source. We’ll continue to update that repo as we improve the site.

I’m trying really hard not to treat this chapter as a throwaway. Clearly, the author included it for a reason, but it’s so small!

Today’s reading: Pg 171 – pg 176

This chapter was actually pretty darn good. It boils down a lot of critical concepts from the preceding text. Where the earlier chapters provided an excellent foundation of tactical (and increasingly strategic) methodologies, this chapter moved over the delivering some excellent big picture thinking. It summarizes the previous chapters beautifully using a few key rules from Kent Beck’s Extreme Programming Explained (which I’m going to reproduce from Martin Fowler’s blog):

In XPE Kent gives four criteria for a simple system. In order (most important first):

• Runs all the Tests
• Reveals all the intention
• No duplication
• Fewest number of classes or methods

There’s a LOT of meat there. I can see this heuristic becoming extremely valuable.

My biggest fault at this point is probably duplication. I really need to work on strategies for reducing duplication in my code. This challenges me to push harder on refactoring once my tests pass and the functionality works.

I really appreciate all the encouragement I’ve been getting to keep up the pace and keep the Peer Pressure Learning going.