Code And Cocktails

The Palm Beach Special

| Comments

(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

| Comments

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

| Comments

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

| Comments

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

| Comments

(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

| Comments

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

| Comments

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

| Comments

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

| Comments

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.

GOOS Guide to Testing and Designing

| Comments

(The second in a series in which I reread Growing Object Oriented Systems and try to digest it better. Overall this section, Chapters 4-8, is filled with timely reminders to me about several things about good design.)

The Walking Skeleton

This is one of the points in this book which seem like such small items but I think have more importance than initial appears. In fact I am surprised in my rereading that the authors advocate the end-to-end tests to be done on deployed systems - that is not something I’ve ever really tried and seems very daunting.

The important things to remember here about the Walking Skeleton is that it is not about writing real functionality, but meant to flush out issues both technological and organizational. It will be definitely smaller than an MMF. It might take a surprising amount of time to write it nonetheless. This is because there will be a whole lot of learning happening. The same goes for the first few features. (Boy is this a timely reminder for me right now…)

Unfortunately this slowness at the beginning of a project can seem like a bad thing - but it is really not. The beginning feels a bit rocky - but then it smooths out as deploy and integration issues have been resolved. In a ‘normal’ project the beginning might be smooth but the deploy and integration problems will crop up and make the end rough.

How to Write a Test

The way they describe to write a test is something I try to do - but it bears repeating (this is valid for tests at any level):

  1. Write the test you want to read (write helper code to make this possible).
  2. Watch it fail - keep working on it until it fails for the right reason with a good error message).
  3. Now write the production code to make it pass.

By taking the time to do this you will ensure that the goal and intent of the part you are working on is clear. When done ensure it has a clear intention revealing name - this is how you will understand the system later.

Start by writing an acceptance test for the feature. Write it in terms of the domain and the user. An acceptance test gives feedback on the external API of the system and upon major integration points both with external APIs and internal components. Since the acceptance test is likely to be failing until all parts of the code is written it will need to be separated from the main build.

Once the acceptance test is well written then start moving down a level to the objects that the acceptance test uses and unit test their functionality into existence. This is the idea of testing from inputs to outputs. Jumping to a lower level object too soon will lead that object to have an interface which does not reflect what it really needs to be. Only by building the objects after building their callers can you know what is really needed.

The Authors have a bit of simple advice as to what to test first: they suggest going for a simple successful path, and they make a good point why. Tests provide feedback, if you focus your initial tests around error or edge cases then your design feedback will be about that instead of the normal work of the component you are writing.

One final important point the authors make on how to write tests is: “If an area is hard to test don’t just ask how can we test this? but why is it hard to test?. If something is hard to test it could be the tests are trying to tell you something. This is one place I have trouble with - I seem to have too much tolerance for pain while coding - a tolerance I need to cure myself of.

How to Design Code (and How Tests Affect That)

Obviously writing tests before the code affects how the code is designed - the pressures to keep each object isolated are very powerful. The book contains a good set of design points which are not unique to the book and not new to me. There were a few specific points I thought good to note.

When objects are composed together the interface for the composite object must be less complex than the union of the interfaces of the composed objects. This makes it a higher abstraction which hides some of the complexities. Higher abstractions allow us to manage complexity.

Each object must be context independent e.g. everything it needs to do its job needs to be passed into in via the constructor or the specific method in question. Thus each object has external knowledge on a “need to know basis”. This leads to the ability to recompose objects to get different behavior.

Create plenty of Value types. This combats Primitive Obsession and also creates attractors for functionality.

Object peers (those objects which are communicated with directly) should be mocked out in tests. This causes coupling and interface problems to be evident. Value types should not be mocked. Neither should third party APIs be mocked since the feedback provided cannot be used since the API cannot be changed. Also mocking external APIs runs the danger of testing against behavior you believe the API has, but may not actually have. Third party APIs should be wrapped in a thin adapter layer which can be mocked in unit tests.

Where do Types Come From?

I rather like the Author’s descriptions of how types are ‘found’ when working in the code. The three ways are valid for both Value and Object types:

  1. Breaking Out: When the code shows that an class is becoming too complex that is a sign that it is doing too much. Some of the functionality could be split into helper types.

  2. Budding Off: When there is a new domain object a new type should be created, even if is empty or contains only one piece of data. The type will act as an attractor for further data and behavior.

  3. Bundling Up: When a group of classes are always used together they can be bundled together. Remember that composite objects should have a less complex interface than their composed parts.

A Final Note About Mocking

I find that now that I can mock concrete classes in Java that I do not use interfaces as heavily as I used to. The Authors specifically point out they use interfaces quite a bit - again because they are concerned with the communication between objects. I think this is one item I’ll keep an eye on as work through the examples. I have used interfaces in this way before but it seems lately I have not been doing so.

Conclusion

I agree with their design ideas. I already try to follow them. I am quite excited to work through the example with them (something I did not do when I read the book previously). I hope that by doing (and blogging about it) these good ideas will sink in more; becoming more normal for me.

I also intend to blog more frequently on it instead of lumping large chunks together like I did here.