Skip to content
November 8, 2011 / marrowboy

How to host a maven repo on github

If you’re anything like me, you probably make little throwaway projects in order to learn something. Sometimes they turn out quite cool but mostly they don’t. Doesn’t matter, but the ones that are nice enough to share present you with a dilemma – you want to share what you made but they’re probably not worth the effort of putting in a public repo like Sonatype with all the ceremony entailed. Here I’ll walk through the process of setting up a repo on github which people can add to their maven builds to pull your code right in. I won’t go into details on maven or how its dependency management system works – you can read about that elsewhere. This method will also work for the other build tools which know about the maven repo layout like sbt, leiningen, and others.

Read more…

October 21, 2011 / marrowboy

Worker Queues in Clojure

In Rich Hickey’s talk “Simple Made Easy” he gives a great deal of good advice on how to manage (reduce, avoid) complexity in your code. He points out that complexity is sometimes easy to create but that simplicity is more desirable even if it is sometimes difficult. So simple != easy, and over-concentrating on developers’ ease at the expense of simplicity is killing our software.

Please, watch this talk – it’s hardly about Clojure at all, more about a rational way of thinking about coding. I’d like to concentrate on one specific piece of advice and see about how we can implement it.

Read more…

July 21, 2011 / marrowboy

ClojureScript

On July 20th, at a Clojure Users’ Group meeting in New York, Rich Hickey presented a talk called “I’ll be talking about something new!”. This was a pretty secretive move, and in the end the “something new” was called ClojureScript.

In the past, Clojure had been mainly intended for use on the JVM – ClojureScript has a new target runtime environment: JavaScript. So, simply put, you write Clojure and use the ClojureScript compiler which results in javascript which you can run in your browser, in node.js, or in another JavaScript interpreter.

Read more…

July 10, 2011 / marrowboy

Sorted

In which I show you around the sorting algorithm used in Java 6

Respect due

Although it’s a pretty standard interview question, almost nobody writes their own sorting routines these days. Java has a variety of “sorted” things (Sets, Maps, etc), so that you don’t have to worry about it yourself.

If you can say which order any pair of things goes in (ie they are mutually-comparable, either by literally being Comparable, or if you have a Comparator for them), then you can do a comparison sort of a collection of things. This is great of course, because we’ve usually got better things to do than rewriting a sort. The algorithm which underpins all the sorting features in Java’s collections API is in java.util.Arrays. Let’s have a closer look.

Read more…

June 25, 2011 / marrowboy

Java Collections API

If you read Apprenticeship Patterns (and you should), you will be encouraged to use the source.

…one of the beliefs that can hold you back is the idea that the people who built the tools that you depend on are somehow different or special or better than you are. By reading their code you can learn to program like them, and more importantly, you can start to understand the thought processes that created the infrastructure that surrounds you.

I’m lucky to act as a mentor for someone who shares my interest in algorithms and datastructures, so we picked the Java Collections API source to look through. It ain’t all pretty by any means, but there’s a lot of cool stuff to learn. I’ve made some notes.
Read more…

June 24, 2011 / marrowboy

Code reviews

Code reviews indeed. Very useful. I noticed this morning that a code review with two people (coder and reviewer) can feel quite confrontational.

Avoid this by involving more people.

Read more…

May 13, 2011 / marrowboy

Design

Do your tests drive it?

I got asked at work (again), wouldn’t development be quicker if we didn’t spend so much time writing tests? Surely, people argue, you can just get the code out quickly, then if it turns out to be worth keeping & building on you can chuck some tests around it to make sure it doesn’t get broken later on.

This is not what TDD is. This misses the point of TDD.

Read more…