Skip to content
May 9, 2011 / marrowboy

Personal Practices Map

I am enjoying the book Apprenticeship Patterns – there’s lots of very good advice for people who care about developing software. One chapter is about preparing your own “personal practices map”

In your own time, make a list of your 10 most important practices for coding and design. These do not have to be XP related and should be the most important things in your mind. … Try to determine any relationships that may exist between these. Specifically, which practices support other practices.

Read more…

May 4, 2011 / marrowboy

JSON in statically-typed languages

JSON libraries in Java sadden me – there is an impedence mismatch between JSON and static typing.

If we have:

{ "key" : "Jackie" }

then we’d want jsonObject.get("key") to return a String. If we have

{ "key" : 66 }

then we’d want an int. It’s easy to imagine situations where we could want another jsonObject, or an array, or a boolean etc.

So what is the return type of jsonObject.get(String)? We don’t know what it will be, until runtime. This is irreconcilable with a static type system where types needs to be known at compile time, so JSON in Java is doomed to be a bit awkward. The common approaches seem to be:

  • return a supertype like JsonElement which we then have to test to see what kind of thing it is, or
  • have lots of .getAsInt(String), .getAsArray(String) kind of methods.

Neither of which is very nice. Hence – jsonschema (and jsonschema2pojo), JSONx (*shudder*) et al.

Just for reference, here’s how it looks in my favourite dynamic language:

    (jsonObject :key)
April 26, 2011 / marrowboy

“final” countdown

So there I was, working on some code which uses the Java final keyword at every possible opportunity. I mean, literally every concrete method was final, method parameters final – local variables, you’ve guessed it, final. I was confused – I’d never seen this kind of thing before.

I asked the team about why this coding style had been adopted. Answers included:

  • It’s safer – final means immutable, right?
  • For performance reasons.
  • Because the code analysis tool (ie Checkstyle) says so.

Read more…

February 20, 2011 / marrowboy

Naming Things

There are only two hard things in Computer Science: cache invalidation and naming things.
— Phil Karlton

I’ll deal with cache-invalidation another time perhaps, and rather than write an overblown treatise on the correct way to name things, I’ll just go through a couple of naming-things tricks in Java which can make your life easier.

Read more…

February 13, 2011 / marrowboy

Understand your code better by flowe-ing

One of this week’s evening projects was a quite enjoyable foray into Java parsers and code quality. I decided to write a little app to show me how I am (ab)using flow control.

The idea is to anonymise code, strip out all meaningful identifiers and functionality and show what’s left.

Read more…

February 6, 2011 / marrowboy

Composition over Inheritance

Hey, so I thought I’d share a situation that I saw recently, and how it relates to the classic Gang Of Four tenet of favouring Composition over Inheritance.  I really believe that the only universally-applicable “best practice” is to think about what you’re doing, so I wasn’t going to blindly follow GoF advice, no matter how well-respected they are.  Rather, let’s treat it as an experiment and see what the pros and cons are for Inheritance and Composition.

Read more…

February 3, 2011 / marrowboy

Implementing (is-prime? n) in Clojure. Uncle Bob’s improved transformation priority list

Uncle Bob is onto something.  He’s developing a system of “transformation priorities” (TP), which say that when my code has to change to meet some requirement, then I ought to consider certain kinds of changes preferable to others.

The original TP post:

Using TP to build a better sort:

TP ammended after feedback:

So, I’m going to take his new set literally, to implement a clojure function:
(is-prime? n)

Read more…