Tom Crayford

Value objects in Ruby

2011-03-19T00:00:00-07:00

In the latest Destroy All Software screencast [1], Gary Bernhardt uses a Struct to represent a value object. There are a couple of problems with doing this, because of the way Structs are implemented.

Structs can be used to create a simple object that just holds values in named fields. However, the constructor can take less than the default number of arguments and set other fields as nil:

Point = Struct.new(:x,:y)
Point.new(1)
=> #<struct Point x=1, y=nil>

This can lead to accidental nils floating around your system, as well as you creating a value object with weird semantics. In this case, having a point without a y value probably doesn’t make any sense.

Furthermore, objects created by Struct are mutable. As a long time proponent of immutability wherever possible, I dislike this.

Enter Values

The problems with Struct looked pretty easy to solve with metaprogramming in ruby. So, I created a library for working with value objects as I want to: Values.

Values is used roughly the same way you use Struct (it doesn’t have all the features though):

Point = Value.new(:x,:y)
p = Point.new(1,0)
`=> #<Point:0x00000100943788 @x=0, @y=1>`

But they aren’t mutable:

p.x = 1
=> NoMethodError: undefined method x= for #<Point:0x00000100943788 @x=0, @y=1>
from (irb):6
from /usr/local/bin/irb:12:in <main>

They also can’t accidentally add nil into the constructor:

Point.new(1)
=> ArgumentError: wrong number of arguments, 1 for 2
from /Users/tcrayford/Projects/ruby/values/lib/values.rb:7:in `block (2 levels) in new
from (irb):5:in new
from (irb):5
from /usr/local/bin/irb:12:in `<main>

This library is really tiny (17 lines at the moment), and is has a good number of examples. Its probably not worth using unless you have quite a few dumb value objects in your system (as its effects can be easily replicated with plain ruby classes).

Notes

[1] Destroy All Software is a screencast series that teaches programmers about software design, UNIX and dynamic languages. Highly reccomended.

For reasons why nil is bad, see the example screencast there.

Clean code and University

2010-09-29T00:00:00-07:00

I’ve now finished my summer internship at Eden Development. The summer was a blast, I learned so much about shipping real products to real people (compared to university where one mostly works on short-lived solutions to small problems).

I learned a bunch about what ‘good code’ looks and feels like, mostly from discussions with everybody at eden, and just the inherent learning that comes from pairing. Enrique showed me some very nice examples of code he’s written, which really helped.

Since coming back to university, I’ve been bemused by my coursemates attitude towards ‘clean code’ and testing; for the most part, they don’t care about either very much. I think this is one of the side effects of university projects being short lived, when you only work on the code for a month, its quality seems to matter less.

The counterpoint to that is that lecturers (or more often, their assistants) have to read your code so that they can grade it. If the code is really horrible and hard to understand (even if it does solve the problem), then it is likely you won’t get a good grade.

With tests, it turns out that lots of problems set at the university level have sample input and output. This situation is just ripe for testing, as you can be sure that your program does the right thing (and check that instantly).

The other point about ‘clean code’ at university is that it really comes down to caring about your output. Everybody I worked with over the summer was fanatical about the quality of the product they turned out. That kind of passion shows through in your code, and makes good impressions on lecturers (which often leads to better grades, and helps you get into any further education prospects with the university). For me, this is the real reason I strive to write clean code at university. It puts me in a mindset of only writing clean code, which is a good habit to have.

Sixth Day at Eden

2010-07-15T00:00:00-07:00

(This post is part of a series documenting my apprenticeship at Eden. For more, visit the archives)

Yesterday was very fun. I worked with aimee on a client project, getting Jasmine working so we could test some javascript that we wanted to refactor. To test that we had to break up the code quite a bit, and then mock out things that touch the DOM. This is mostly because we couldn’t work out getting fixtures generated for jasmine, so maybe we’ll work on that today.

On another note, my typing (seeing as I’m participating in #learn2typewk) seems to be getting worse. However, I’m somewhat aware of my problem areas now (pretty much anything not on the home row), so I know what to work on. I’ve also started a Trickle List for keeping track of my typing practice.

Third Day at Eden

2010-07-14T00:00:00-07:00

(This post is part of a series documenting my apprenticeship at Eden. For more, visit the archives)

Yesterday I gave a tech talk on Clojure to part of the Eden staff. The talk itself went reasonably well, although I hadn’t prepared anywhere near as much as I’ve prepared for previous talks, and it showed. This really reminds me of how important practice is, especially for speaking to groups. After the talk I ran through the string calculator kata in Clojure with the group.

Having not practiced this at all (as well), and not done that much Clojure in the past month left me feeling a little rusty, and it showed (at one point I couldn’t remember the java api for making a regex out of a string). I will be giving this talk again on Friday at the Software Craftsmanship UK meetup, so I need to practice more.

To get into this practice, I am starting to do a kata every single day on the train home. This week it’ll most definitely be the string calculator, next week I’ll switch to something else (if you have suggestions, twitter at me).

Fourth Day at Eden

2010-07-13T00:00:00-07:00

(This post is part of a series documenting my apprenticeship at Eden. For more, visit the archives)

Yesterday (the fourth day) was interesting because I was working on Eden as a business, not directly on code. Most of the things I learnt were with regards to marketing, as opposed to coding.

I did have some time to talk to Enrique about the wiki exercise. Reflecting on this further, I realise that I completely overworked the testing side of the assignment, to the expense of the actual code, a trap I have fallen into before. The lesson I took away from this is to remember why writing tests is important; which is that it helps deliver business value.

I am now going to redo the whole assignment (from scratch), concentrating more on the actual wiki, and less on testing.

Third Day at Eden

2010-07-12T00:00:00-07:00

(This post is part of a series documenting my apprenticeship at Eden. For more, visit the archives)

This a retrospective post, which I’m writing on Monday morning (for Friday). On Friday I finished most of the wiki exercise, then paired with aimee for some client work.

Wiki Retrospective

The wiki exercise was interesting, not least in learning more about testing and abstraction. I think the main flaw with my program (as it stands now) is that every action is modelled with its own Webrick servlet class. This has cost me significantly in flexibilty; if I were to do this assignment again I would write one servlet that just routes actions to something akin to a rails controller. This would have made the testing much easier, and reduced (somewhat) the level of mocking I did.

I’m quite happy with the mocking library that emerged, and found that testing interactions (as apposed to state) fits nicely with my (newbie ish) ideas about OO testing.

The other main lesson I learned was with regards to ruby metaprogramming. Whilst not as ‘flexible’ as lisp macros, I’m finding ruby metaprogramming an interesting way of thinking, because you are mostly manipulating methods on objects (and classes).

The other pleasant thing here was finding out how little code it takes to write a minimum viable testing framework. I also wrote a little rspec clone on top of my testing stuff, which was very simple to do. I didn’t end up using it, because it would have meant converting all my tests to a new format (again, after I converted them to xUnit style), and everything was pretty much finished already. Furthermore, the examples were already pretty readable, and I didn’t feel that specs would add more.

Finally, I keep on feeling spoilt by Clojure’s sequence library. There are a number of functions there that I’d love to have in ruby (partition-by would have been useful for the scoring kata, and group-by is dang useful).

Second day at Eden

2010-07-09T00:00:00-07:00

(This post is part of a series documenting my apprenticeship at Eden. For more, visit the archives)

I’ve now finished the Ruby Koans I started on the first day. The remaining koans taught me some useful things about message passing and method_missing, which I have since used for a little test framework.

After finishing these Enrique got me tdding a wiki server using just the ruby standard library. The twist to this is that you’re not allowed to use Test/Unit, so you basically have figure out how to write tests.

After finishing the day, I looked over the test code, and found it extremely ugly. I’ve often found that ugliness in code means that I’m missing the right abstraction, or at the very least that my design is flawed. My fault here was entirely in the test code, which seemed very unstructured.

To resolve this, I wrote a small (77 lines) implementation of the xUnit testing framework, so that I can clean up the tests on my third day. I wrote this (from memory), based on Kent Beck’s example from TDD by example There’s also a tiny mocking thing, based on Dingus, which I am using for testing servlets.

After writing these two to help me organise the tests, I’m think the rest of the wiki should be much easier to test (and therefore write). This reminds me again of the importance of aesthetics in code. I’ve found ugly code is often very difficult to work with, and makes the developers working on it unhappy as well.

First day at Eden

2010-07-08T00:00:00-07:00

I’ve just finished my first day as an apprentice at Eden. As an exercise for the first day, Enrique (my mentor) had me going through the Ruby Koans, which were pleasantly surprising.

As a further add on to this, Enrique added the rule of not having any method longer than 4 lines. I first saw an idea like this whilst reading Clean Code (which is a very good read). In the past I probably would have written a large method, but this encouraged me to write much smaller ones.

The nice part about the koans is they teach parts of the language one might never touch much (I’ve never really used array slicing, for example). The scoring problem (the koan I’m currently on), was also an interesting design challenge. The solution I ended up with is here:

Even this small exercise reminded me of the important point of finding the right technique being crucial to clean code. With the right angle on the problem, code can become significantly smaller and easier to change.

The right abstraction in this case was finding triples by using

(1..6).each do |i|
  if dice.count(i) >= 3
  ...

After I discovered this, the problem was easy to solve (and the code was cleaner too).

Annendum

Learn to type week (as suggested by Corey) is next week, and I’ll definitely be taking part in it.

A tutorial on the universality and expressiveness of reduce

2010-05-14T00:00:00-07:00

I was getting up to date on The Joy of Clojure recently, and found a link to this paper. It shows some interesting demonstrations of fold (better known to Clojure programmers as reduce), but I had to struggle through reading them in Haskell.

The paper starts out by demonstrating that some standard list processing functions can be written using reduce:

(defn my-count [coll]
  (reduce (fn [n x] (inc n)) 0 coll))

(my-count [1 2 3 3]) ;; produces 4

(defn my-reverse [coll]
  (reduce (fn [xs x] (into [x] xs)) [] coll))

(my-reverse [1 2 3]) ;; => [3 2 1]

(defn my-map [f coll]
  (reduce (fn [xs x] (conj xs (f x))) [] coll))

(my-map inc [1 2 3]) ;; => [2 3 4]

(defn my-filter [pred coll]
  (reduce (fn [xs x] (if (pred x)
                       (conj xs x)
                       xs))
          []
          coll))

(my-filter even? [1 2 3]) ;; => [2]

All of the above functions only work on vectors (the original Haskell versions use lists). They’re also not lazy, and lose a lot of benefits that the full clojure implementations have. Furthermore, I personally find reduce VERY hard to read. Having said that, there’s something to be said for how reduce expresses the above definitions.

The laziness problem is obviously avoided in Haskell (given its lazy nature). I’m mostly bothered (at the moment) by the readability problem. I don’t find many of the above definitions clear at all, and most of the time I need to use reduce, I don’t, only noticing it when I’m refactoring later (and even then I question it, due to the readability problem).

The paper also taught me some more reasons for having first class functions in a language (not that I needed more). See the following definition of comp.

(defn my-binary-comp [f g]
  (fn [x] (f (g x))))

(defn my-comp [& fs]
  (reduce my-binary-comp identity fs))

((my-comp inc inc inc) 1) ;; => 4

Again, this isn’t as all encompassing as clojure’s implementation, but it further demonstrates the expressiveness of reduce.

Users of Haskell will know that Haskell also defines the foldl function, which simply processes arguments in the opposite order from reduce. Hutton points out that this new function is sometimes more useful than fold, by defining reverse in terms of it.

(defn foldl [f value coll]
  (reduce f value (reverse coll)))

(defn my-reverse [coll]
  (foldl (fn [xs x] (conj xs x)) [] coll))

(my-reverse [1 2 3]) ;;=> [3 2 1]

Notes

All the above code can be found here.

Hutton’s original paper is here

Syllabus Review

2010-03-25T00:00:00-07:00

Keeping my student life well organised has been a major part of my life this year, especially as my workload for University (college to all you US folk) has increased. I was delighted to hear of an application designed specifically to help students with this task. Syllabus aims to help students stay organised, by collecting functionality that was spread over several apps into one.

The major plus point for Syllabus (for non-techie students) is that it hides away the filesystem completely. You can just import your files (probably from the downloads folder, as you download them), and Syllabus will keep everything nicely organised. Most users are distinctly scared of the filesystem, and most of the iLife apps already abstract it away from the user. However, for a techie like myself, this doesn’t offer much of an advantage compared using the filesystem, which I already had organised how I wanted it.

This hits on my big problem with Syllabus, for students who are already well organised (probably using iCal and the filesystem), Syllabus offers almost nothing. Furthermore, the time it takes to get data into the app means that it’s pretty pointless for many students.

Syllabus is interesting conceptually, because it tries to do for student organisation what Coda does for web development. That is, turn what used to be a many app task (keeping my student work organised) into a one window task. Many things Syllabus does are handled well by iCal (keeping track of dates), and the Finder/Spotlight (keeping track of files).

The main problem here is that organisation is a very disparate task. Keeping track of professors’ emails for example, is completely separate to keeping track assignment hand in date. Unlike Coda, there is little benefit to moving these two tasks into one app, as they simply have little relevance to each other. Furthermore, because Syllabus does all these separate things, the UI for each task feels unpolished compared to apps that already accomplish that task. A particular example that springs to mind is entering dates in Syllabus compared to iCal (or its bigger brother, BusyCal).

The UI for entering dates being unpolished is a particular problem, because a lot of my usage of Syllabus so far has been entering dates (for lecture times, assignment due in dates, professor office hours and term dates). Another date-related complaint is that the at-a-glance view, which is a very simple outline of what is coming up in the next week, is nowhere near as good as iCal’s week view. This is especially pertinent because of Syllabus’ syncing with iCal (which works very well), as you can get the iCal view for your student work (that you entered using syllabus) by selecting the Syllabus calendar.

The final lacking thing from Syllabus is any sort of search functionality. Particularly for students with many links/files, it seems far more sensible to keep them in a known folder/browser bookmarks (where you can search them properly, etc) than to put the in Syllabus.

Overall, I love the idea of the app. Keeping student things organised is definitely an important task. However, the execution is somewhat lacking, having many disparate tasks with little integration between them doesn’t work well for a single app. Many tasks that Syllabus accomplishes are already covered by iLife, and done better there.

String Calculator Kata

2010-02-10T00:00:00-08:00

A code kata is a simple coding task that you perform repeatedly, analysing each performance to improve your skills.

Corey Haines has been running katacasts.com for a while now. The string calculator kata has proven to be popular under submitters, so I thought it’d be interesting to do one in clojure.

This particular kata involves summing a string of numbers separated by commas and/or newlines. Custom delimiters are also allowed (represented as the first line starting with //). Any negative numbers found should throw an exception.

String Calculator Kata from Tom Crayford on vimeo.

If you have any feedback, leave a comment at the katacasts site, or message me on twitter

Clojure Autotest

2009-12-08T00:00:00-08:00

I’ve been doing a lot of testing for a clojure side project recently, and got envious of Ruby people having nice tools. In particular I liked the coloured output and automatic test running from rspactor.

I found watchr and came up with this script, which simply watches for changes to .clj files in /src and /test and runs lein test in the shell window.

To get started, install watchr

gem install watchr

and run the script in the home directory for your Leiningen-backed clojure project.

watchr /path/to/script

The script also does some (very basic) red/green colouring of outputs using zsh color codes.

Sample output: