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.

This is part of the Peer Pressure Learning 30 series. Jump to my introduction to the experiment if you got here from Google or some other site.

Several mornings this past week were taken up by building http://ervscafe.com/ with Vince. We did the site for free to help out the restaurant painfully stuffed into the 7th floor of our building. We love having Erv (his real name is Kevin) around to feed us. It’s a pretty ghetto site, but the idea was quick and dirty.

With that pretty well done (I need to do a bit to the Rails app so he can update his specials), I’m back to having a bit more time for PPL. Hopefully tonight will be my last weekday post done in the evening for a while.

Today’s reading: pg 164 – pg 170

While this chapter continued with a bunch of Java-specific framework details (Swing, JBoss, Beans, etc), one particular concept leapt off the page and seemed to have a potential impact on a large Rails app:

In Spring, you write your business logic as Plain-Old Java Objects. POJOs are purely focused on their domain. They have no dependencies on enterprise frameworks (or any other domains). Hence, they are conceptually simpler and easier to test drive.

Whoa! Can you imagine an entire Rails app that used Models as data containers and plain Ruby classes to hold all the business logic? It frightens be rather a lot, but the idea that all that business logic could be more easily transferred to another language, a different framework, or more easily modified sounds incredible. Separating persistence (and framework crap) from business logic sounds like win to me.

Downside? That seems to fight against much of the Rails conventions and common practice, so implementing a solution in that manner would require treading very rough, new territory.

I have a small portion of an app I did constructed somewhat this way. I’ve been wanting to write up a blog post on the topic as it’s a pretty in-depth implementation. This chapter gives me hope that I just might have been onto something purely by chance!

Another great standout from the chapter is the discussion of decision making. This nails it:

We often forget that it is also best to postpone decisions until the last possible moment. This isn’t lazy or irresponsible; it lets us make informed choices with the best possible information.

And finally, the best bit of all:

…never forget to use the simplest thing that can possibly work.

Well said.

Next up? Emergence. Again, I have no idea what that means, but it sounds impressive (it has to be, the word has 3 syllables).

Miles continues to bang out his PPL blog posts. His latest is on the Python framework Django (pronounced, “JANG-go”, I think).

Dear Google,

Your index is out of date and I’d love for you to revisit this site ASAP: http://factsandfiguresscotland.com/. Kthx.

Tim

This is part of the Peer Pressure Learning 30 series. Take a gander at my introduction to the experiment.

Ok, I’m back on track with two blog posts today. My Day 15b – Classes Part 2 post fills in the gap left by my Day 15- FAIL.

I started into the rather heavy chapter on systems. It’s a higher level look at clean code from the architecture and strategy perspective. A ton of it was either over my head (and heavy into Java) or was tough to apply with my Ruby on Rails goggles on.

Today’s reading: pg 153 – 163

Wow, this was some intense stuff. Uncle Bob talked about some interesting pitfalls with coupling the instantiation and management of dependencies in with the business logic. I could see a lot of validity to the problems that causes as you get into larger and large codebases. The pain of changing out your ORM already leads me to believe that Ruby on Rails projects likely suffer from some of the problems he talks about.

He shared some interesting examples of how to decouple the initialization of your objects from the run-time code, but I couldn’t even begin to understand how that would relate to a Rails app.

I have to take a cue from Miles to make any sense of this blog post:

What I Think I Now Know

Think, think, think before you go charging down a path with your classes. The author showed an example of the ubiquitous lazy-loading method of instantiating objects that I’ve used numerous times. In addition to pointing out that it may be a pre-mature optimization, he also explains that it can tie the instantiation too closely with your business logic. What does one do about that? I have no idea.

Realize that your toolkit or framework may fight against what you’re trying to accomplish. While I don’t know what you’d do about it, we have to realize that any framework we use was designed with a purpose or set of goals. Those may be different that we we need to accomplish with the current work at hand. I’m not suggesting that we throw out frameworks, merely that we understand their strengths and weaknesses. And at the same time, we learn to see clearly when it’s time to buck the convention or stick to it.

Finally, one must accept that you can’t architect any system for the needs you’ll have in 12-24 months. It’s just not going to work out exactly the way you expect. As believers in Agile, we need to accept change and do what supports today’s requirements with basic consideration for the future. We need to be wary of over-engineering.

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

Ok, it’s a day late, but I’m back on the wagon. It’s really day 16, but I’ll get back to that in a few moments. I need to play catch up first!

I have to make a brief digression. This Peer Pressure Learning has impacted a number of areas in my life. I’ve found that as I’ve been more focused and disciplined, other priorities have felt more effortless.

I’ve ridden my bike or walked to work almost two weeks now (with one or two breaks). That has paid off big-time for my soccer league. I’ve been a lot more effective on defense and logged my first assist today to bring us back from a 1-2 deficit. Geek fitness for the win! Ok, enough of that, back to the code!

I lucked out with today’s reading. The balance of the Classes chapter wasn’t particularly long. But, it was home to some great material about organizing your classes with an eye towards future change. It’s been said a thousand ways…and I’ll repeat it again here: the only thing in software you can be certain of is that you’ll have to change tomorrow what you wrote today.

Today’s reading: pg 147 – pg 152

I glossed over the Single Responsibility Principle of class design from the first portion of the text, but it was impossible to miss here. The idea is that a class with more than two responsibilities is a broken design. A couple ways to tell that one has broken the SRP (my paraphrasing from memory):

• Describing the class in plain english includes words like “and”, “or”, “if”, or “unless”
• Finding private methods that only support a few of the public methods or private variables used by a small portion of the methods
• More than one type of application change will impact the class (meaning it’s probably doing more than one thing (see the first bullet)

It’s pretty genius. It leads to mountains of tiny classes. Coding this way must be a complete mind shift. One couldn’t do this haphazardly or you’d go crazy. Lots of tiny, but complex classes would be awful. You really would have to get darn good at simplification and organization. Thank goodness for tests, you’d have no way to complete a refactor otherwise!

A throw-in at the end talked about one of my favorite concepts (I like it, but probably am not that great at it): Separate stuff that appears likely to change from stuff that will stay constant. Don’t put them in the same class!

Why do you think we have configuration files full of application constants and don’t put that stuff into our classes? It’s partly to eliminate duplication, but just as importantly, it’s so our system can evolve through editing as few files as possible.

One of my other favorite testing methods was talked about as well. When you have to interface with some external class (one that’s perhaps complicated or an API), pass in the class as part of the initialization or using a setter method. That way, your tests can push in a mock object for easier validation. It also allows you to decouple your code from an external or volatile library. Nice!

Next up, Chapter 11: Systems (I have no idea what the chapter is about, but it sounds cool).

While I’ve been slacking, Miles has been tearing it up!

• Day 14: HTML5
• Day 15: Python

Yea, I managed to blow it today. It’s 11:30 and I just can’t bring myself to stay up another 30 minutes.

I’ll probably look to pit through two posts in the next day or two.

I’m working with a friend to build a free web site for our building’s cafe, so tomorrow will be tough. Wish me luck!