# GOOS Review Chapter 13: Not Done if the Code Is Messy

(This post is long overdue… sorry about that).

This chapter was not to long but had some points that were interesting to me.

Firstly the thought that refactoring before and after a change should be about clarifying the code via its design. This should not be thought of as cleaning or gold plating.

I found it interesting right when the Authors said that the job was not done because the code was ‘feeling messy’ my gut was telling me that the code was not too bad. This is something I’ve noticed. I think my gut is wrong and needs some new calibration.

The last item I wanted to point out was the idea that you should defer refactoring decisions until you can see/feel what the problems are. But to do this you must know that you will take the time to refactor when you know that refactoring is right. If you don’t have confidence - you will refactor prematurely.

# The Palm Beach Special

(It was noted to me that for a blog called ‘code and cocktails’ that I don’t have many cocktail related posts - so here we go:)

I decided to try a new-to-me cocktail tonight and asked cocktaildb for cocktails which contain grapefruit and gin. It suggested, amongst others, the Palm Beach Special.

• 2 1/2 oz. gin
• 3/4 oz. grapefruit juice
• 1/2 oz. sweet vermouth
• shake well with ice, strain into cocktail glass.

I enjoy the combination of gin and grapefruit in this drink but I have two issues with it which I’d like to experiment with:

1. I think it is too heavy on the gin - I think it overloads the grapefruit.
2. I wonder if something like St. Germaine might be a good exchange for sweet vermouth - obviously it would change the drink - but I think it might be for the better.

As an aside: cocktaildb is a great resource - I wish I could filter out drinks for which I don’t have ingredients however. That is why I am building (slowly) my own cocktail recipe website (defdrink). (The primary purpose of (defdrink) is to be a vehicle for me to learn Clojure)

# Quick Thoughts About @david_a_black's Presentation at @bostonrb 2012-07-10

## 0. Overview

David Black (@david_a_black) presented his his “The Well-Grounded Nuby” presentation to the Boston Ruby Group (@bostonrb) meetup on 2012-07-10. I was unfortunately unable to attend but I watched/listened in on their live streaming.

He presented seven things about Ruby that every noobie should know. I guess I am still closer to noobie than expert but I found that his points where very good for ‘levels’ above noobie. His seven points were:

• Everything evaluates to an object
• Sending messages to objects
• Objects resolve messages to methods
• Classes and modules are objects
• There is always a “self”
• Variables contain references to objects
• True and false are objects

I thought his talk could be summarized (flippantly?) into two points:

1. Ruby is objects the whole way down.
2. Ruby is Lisp-y.

## 1. Objects the Whole Way Down

I had the thought that Ruby must be objects the whole way down; but I had not tested it out, nor thought about it much. I just hadn’t needed to worry about it in my small amount of Ruby work. But this presentation made me much more aware of this. I need to experiment with this more and become more familiar with this style. C#/Java (which I am more recently familiar with) just don’t have this feel.

I do a lot of work day-to-day in Groovy and some of the discussion here sounds familiar. While I knew Groovy was like Ruby, I think it might be more like Ruby than I had been thinking. I need to investigate.

## 2. Lisp-y

Perhaps it is because I’ve been reading Let over Lambda but I immediately started thinking lispy thoughts during a few points.

Specifically when he was saying that everything evaluates to an object and discussed how case is just as if...elseif...else using === I wondered how I might be able to write my own control flow. Does Ruby have macros? I need to investigate.

## 3. The Mixture of the Two (and beyond)

His first point, “Everything evaluates to Object” and “true and false are Objects” made me think lispy thoughts. On the first point it was simply “duh” of course everything evaluates to something, and the second made me think of the difference between Scheme/Clojure and Common Lisp with respect to t/nil or true/false.

Lisp has an object system - but it is built on top of an existing language with the features of the language itself. There is something about this presentation of Ruby that makes me start feeling that Ruby’s object system, while a much more integral part of the language is still defined in that language itself as CLOS is.

His point about “There is always a self” made me think about my recent forays into Javascript at work. These have revolved around me trying to understand what this was at different points in the code.

## Conclusion

The talk was though-provoking in me; and thus, IMNHO, it was good. I have at least two different things to investigate.

Overall his presentation made me realize there was plenty more in Ruby for me to learn, and that there was plenty more in Ruby that was, to me, worth learning.

# Another Century Ride

## The Stats

• Departure Time: 2012-07-08T06:11EDT
• Arrival Time: 2012-07-08T18:00EDT (approximately)
• Distance: 105.47 miles
• Travel Time: 10h20m
• Average speed: 10.42mph
• Total Time: ~12h
• Days since Previous Century: 364 (2011-07-10)

Yes, I am a very slow rider. I ride a 1971 Schwinn 3-speed. Deal with it.

## Places Seen, People Met

I traveled through a variety of cities:

• Boston
• Cambridge
• Arlington
• Bedford
• Concord
• Maynard
• Hudson
• Marlborough
• Southborough
• Hopkington
• Holliston
• Sherborn
• Natick
• Wellesley
• Weston
• Waltham
• Newton
• Watertown
• Maybe some more I didn’t even know I was in.

I saw lovely tree-lined streets, I saw lovely tree-lined dirt-roads which Google Maps says are bike trails, I saw empty suburban neighborhoods, I saw strip-mall blight, I saw a wide variety.

I found out that while urban/suburban folk put out furniture with a ‘Free’ sign; rural folk put out yellow squash with a ‘Free’ sign.

I saw part of Hopkington twice; but the nice guy on the 2nd story porch pointed me in the right direction. I told him “Hopefully you won’t see me again” as I left, and he did not.

I stopped to tie my shoe and the homeowner working on his lawn asked to make sure I had enough water - was going to get me ice-cold water if I wanted; then we chatted about my bike and bikes he’s had.

I was only defeated by one hill: traveling south on Cedar St. to Hopkington it appeared to me that the hill was about a 45 degree angle and maybe a half mile long. After all the hills in Marlborough I decided to just walk up it.

I reached a personal-goal in the ride of riding across Interstate 495, I did it twice; the second time was an overpass with no ramps was much nicer than the first.

I managed to hit 30mph or come close a few times again; with a good road surface that speed is much safer feeling. But one must be vigilant of any possible bumps, and to be able to evade them takes a road clear of traffic.

## The Good, The Bad and the Ugly

It was good to go somewhere brand new to me, it was also good to have portions of my ride be familiar; especially the end where after reaching Norumbega Tower I knew exactly how to get home.

The bad was that I started the ride with a boring loop around the Charles and then the very familiar ride out to Concord. I found that this stretch was the most dis-spiriting; it was just a boring ride. The rest of my ride (except the last leg home) was new roads I had never biked on (but I had driven a car on a few it turns out). This was all exploration - that is what I need during such a long ride.

The ugly? To put it delicately: my ass hurts.

## Would I do it again?

Of course I would - I’m just that sort of stupid.

I need to find places to go and things to see. I also need to make sure the ride is as comfortable as possible.

Possible future rides (Century or not):

• To Providence with a stop in Franklin (to visit family)
• To the source of the Charles River
• To Seebrook Power Plant

# Goos Review Chapter 12

In this chapter we implement our first real acceptance test. It is an end-to-end test of a real user feature.

I tend to run my tests repeatedly as I write them - so I hit a problem before the Authors revealed it. It was the surprise problem of the connection needing to be closed. I guess my running of tests often led me to find it earlier than others might - so I’ll take that as a win. It was annoying to hit it before the Author’s intended though - I thought I had a broken OpenFire installation.

There were four things that stood out for me in this chapter:

1. Their note about using the same value in test code and production code (e.g. JOIN_MESSAGE_FORMAT) on p109. This is a problem that I struggle with in my testing. Sometimes I feel that it is cheating - or not really testing anything. Other times I think it is the “Right Thing To Do(TM)”. I am glad/disappointed that they have conclusive word on if it is good/bad.

2. They start implementation of the new feature by first refactoring the existing code into one that will make the needed change easy. This is something I’d like to internalize but I haven’t yet. I usually start by implementing what I need (even if hard/ugly) and then refactoring until it is nice and clean. But this often leads to wailing and gnashing of teeth. I also think, in retrospect that I have missed the target of the really nice design, which no longer can really see, but I feel is still out there.

3. There was a phrase on p113 which I think is a good feel for how I usually am thinking when I am implementing: “…our immediate concern is to get message translation to work, the rest can wait.” It is this focusing on the immediate problem and ‘faking-till-you-make-it’ that I do a lot. I like to commit often - so I am always working hard to get small bits working and committed instead of trying to do bigger chunks of work (although I can’t say I am always successful in this).

4. On p116 the Authors say that the expectation is the most important line of the test. However I find that it is hidden in the Java code needed to create it. Perhaps it is because I always look at a test in the ‘arrange, act, assert’ way; so I don’t expect to see an expectation in the ‘arrange’ section but in the ‘assert’ section (as it would be with Spock, Mockito, or Moq for example). I wonder how else it could be made more visible?

5. Finally they point out the importance of writing the ‘first draft’ code and then refactoring it after the tests are working. I don’t think I could agree with this more strongly.

On the whole a good chapter for the first real user-feature. I am still annoyed with plain old Java code. Maybe I’ll need to start re-implementing this in Ruby or at least Groovy sooner rather than later.

# How I Learned to Stop Worrying and Love the Monad

(sorry I couldn’t help that title)

For a while I’ve been trying to learn what this Monad thing was. Smart people were talking about them and making them sound important. Smart people I knew and admired were making them sound like something I should know about.

So I’d try to learn what monads are and it all sounded something like this:

A Monad is Kleisi triple: an endofunctor, together with two natural transformations.

Simple right? I just felt dumb. I didn’t think I’d ever understand what they were or why they were important.

That is until I watched two presentations. While I can’t say I understand them yet, I feel like I’ve had an insight which might be useful so I’d like to share them.

(Both presentations use Clojure - but don’t let that put you off if you don’t know Clojure - the Clojure in the presentations is not very complex.)

## Why is a Monad like a Writing Desk

A few weeks ago I finally watched a presentation by Carin Meier called Why is a Monad like a Writing Desk? (presented at Clojure/West 2012). Given my big soft-spot for Alice in Wonderland references I was predisposed to watch this video.

Carin presents monads gently via a cute little story of Alice, a programmer, who is trying to learn about monads but falls asleep and enters a Wonderland like land of talking doors and Astronaut-hosted tea parties. Through the story I learned a little bit about monads alongside Alice.

She covered the Identity, Maybe and State monads which I had seen before but now better understood.

## Introduction to Monads

At the end of Carin’s presentation there was a link to another presentation by Adam Smyczek called Introduction to Monads (presented at a Bay Area Clojure User Group meeting in 2010).

In this presentation he shows a real case where he used several monads to create a clean design for a testing DSL he was creating. It involved some live coding which was good to see.

He also covered the same monads. Seeing them implemented again, helped solidify my understanding of them.

## Insight

Watching these two presentation I came to a realization:

Monads are not a thing, they are a pattern.

That’s it. That was the insight I needed. I realized that previously I was always looking for some explanation of a thing, a language construct, and object, a function. But that is not what a monad is (although it could be built in to a language etc.).

Monads are a design pattern. They are a pattern of flow control, a pattern of chaining functions on sequences of data.

I think my next insight will come about when I consciously implement code using monads. I hope to create an opportunity for this.

I’d suggest to anyone who wants to learn something about monads but is finding it tough to watch Carin’s presentation (sit back, relax, enjoy and learn) and then follow that up with Adam’s presentation. I watched them back to back one evening and I think that really helped.

# Problems Deploying to Heroku After Upgrading Octopress

Just a note (perhaps for my future self).

I had considerable problems after upgrading Octopress and then trying to deploy my blog to Heroku.

The problems stemmed from the update to the Gemfile. There were two problems:

Firstly: everything except for sinatra was put into the :development group. Heroku runs bundle --without=development so all those gems will be missing.

Secondly: due to an earlier problem with the pygment and python environments I need to keep the following in my Gemfile

gem 'pygments.rb', '= 0.2.3'
gem 'rubypython', '= 0.5.1'


After I fixed those two problems deploying to Heroku worked fine.

One bright side is that I now know how to use heroku releases:rollback to shift back to a previous version. This let me keep my blog up and running while I tried to figure out the problem. (Not that anyone actually reads it…)

# Quick Review of 20 Years of 'Professional' Programming

In May 1992 I graduated with a Bachelor of Science in Computer Science from WPI. That means that I’ve been a ‘professional’ programmer for a little bit over 20 years. I have to say that while on the whole it has been good I regret some things.

Firstly, I think I got a good education from WPI. However I wish I had taken it onto myself to get a better education. I didn’t extend myself enough, I didn’t really dig into things as much as I could have. I got good grades and left it at that. This is a regret of mine.

Nextly, upon graduating, I got some jobs and things went well. I fell into thinking that I knew what I was doing. I think I was, while cocksure, still a bit better than the average programmer of the time with equal experience. But it was during this approximately 10-15 year period where I fell into a lull. I thought I was good and I never did too much extra-curricular research. I did have a small piece of free software that I worked on during this time

• but that didn’t really stretch my abilities. The work I was doing at work was good - but again not stretching my abilities.

During this time I only remember going to a single ‘conference’. That was when the local ACM chapter in Boston brought in one of the Gang of Four to talk about their book. I distinctly remember that during the lunch I was so shy/awkward that I felt like never attending anything like this again.

Sometime during the last 5-10 years I started to become dissatisfied with how software projects were being run and how quality, my own and other developers was being handled. Sometime during this time period I was exposed to Agile methodologies. Perhaps the time was just ‘right’, but for whatever reason instead of just sitting around and accepting things I did a lot of research, I started reading blogs, I started trying things out for myself, I even went to conferences and made some good connections with people.

It was at this point I started to realized 1) how little I knew and 2) how much I had forgotten.

This is where I am now. I am trying to turn myself around and learn more and all the time.

I hope my next 20 years of programming (because I plan on coding (maybe not always for pay) until I die) will not find myself falling into another rut…

# GOOS - the Walking Skeleton Starts Walking

Just a quick post to ensure I keep this moving along.

I have completed my review of Chapters 9-11 of GOOS. These chapters cover the starting of this example project – the Auction Sniper. There seemed to be mostly ordinary stuff here (perhaps it is ordinary to me now that I have worked in something like this style for a while…).

After discussing what the scope of the project is and some of the 3rd party protocols we’ll be dealing with we create a to do list of the initial ‘stories’. This will be our backlog.

We then start an Iteration Zero to get the Walking Skeleton up and running. I’ve seen Iteration Zeros which didn’t work - but I think the failure there was not keeping them tightly timeboxed like any other iteration. The Author’s recommendation is to keep them timeboxed - so I have no complaints there.

One thing mentioned in this chapter as the first end-to-end test is created is “programming by wishful thinking”. This is something that fits my style well and I think I keep learning that if I don’t do it; things don’t end up as nicely. Someday I’ll learn to trust the instinct and style.

Finally in the final chapter of this little section we get the Walking Skeleton going. The code isn’t bad - there are some things I don’t find aesthetically pleasing - but I don’t want to refactor too much - because if I do it might be harder for me to follow along the future examples. Perhaps after a bit more code is written I’ll refactor on a branch.

I think the major thing I’m learning is how happy I am not to be writing straight Java all the time. I write in Groovy mostly at work and Ruby and Clojure at home. Straight Java is not horrible - but really there is so much typing - it could all be done with less typing.

(Another reason to write this short post is to get rid of the mental block that is keeping me from just jumping into the next chapters!)

# OMG Git Is Scary and Amazing

I just bought a chainsaw - my problems are solved

I created a modification to lein-midje which allowed it to be a lein new template to help people get started with Midje. I submitted a pull request and in doing so realized that I really ought to have done my work on a branch. ugh.

Knowing that Git is super-awesome(TM) I thought there must be some necromatic incantation to take previous commit and put them on a branch. I was surprised/horrified to find out how easy it was! (the first answer, at the time of this posting, is the important one).

For the record this is all you need to do:

git branch <newbranch>
git reset --hard HEAD~2 # or however far back you want to go
git co <new branch>


It seemed to easy to I tested it out. I created a new repository with a file which was empty on the initial commit. I modified it two times committing each time. Then did the above steps. Then on the master branch I committed a different change. Now git log --all looks like this (my personal formatting stolen from garybernhardt):

virgil:foo(abranch)> git lg --all
* 0d4d369    (8 minutes)   <Mark Simpson>   (master) after branch
| * f0101f4  (9 minutes)   <Mark Simpson>   (HEAD, abranch) third co
| * d8160bf  (9 minutes)   <Mark Simpson>   second commit
|/
* cceb15b    (10 minutes)  <Mark Simpson>   initial commit


Git is scary and cool at the same time. It is a serious chainsaw and you can get stuff done, but you could also chop your leg clean off.