Eden Development Staff Notes

(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 ListODO: Link here) for keeping track of my typing practice.

(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).

(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.

(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).

(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.

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.

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

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.

Water washed you upon the shores of this earth
were you walked erect with the gusts of wind caressing your hair
now in flames you go from us never to be forgotten.