Due to the extra bank holiday to celebrate the release of Ubuntu (and that little wedding), the Clojure dojo has been moved to the 3rd of May at Thoughtworks. So no Clojure dojo on the three days short week. I am really enjoy learning clojure as the syntax is very straight forward, has some nice abstractions for data structures and has pure functions by default (although you can change state using transactional memory for atomic changes). Sign up on eventwax for some Clojure and quiche.
The London Software Craftsmanship are running another round table on May 11th at YouDevise. Last month was a very heady mix of topics, from dynamic languages, cloud developer services and tools, to avoiding navel gazing in software craftsmanship and actually tell people clearly what its all about. If you want to talk about your issues or challenges, bring them to the round-table meeting and get lots of ideas and options from a diverse set of friendly developers (and possibly one diabolical developer).
Jon Pretty from Scala Technology is talking at the London Scala user group on May 11th. Jon is going to give a whirlwind tour of design patterns in Scala, including (but not limited to) Utility Belt, Pimp-my-library, algebraic data types, Concept and Cake. Jon launched the very first commercial Scala applications in 2005 and named the Cake Pattern in an email conversation with Martin Odersky. Sign up!
Summary of Last weeks events
The London Continuous Integration meetup was packed out and even Dan North turned up for some flirtatious heckling of his colleague. Chris Read presented some great ideas based on how he has been able to streamline deployment at DWR. Some take-aways include:
- Use a single source repository, even if you use distributed version control (git clients with svn, gatekeeper repository with git/mercurial) – JRocket: This is the basis of how the Linux kernel developers manage all there development
- Every commit should build, if you leave failed builds around then it will breed more…
- Test in a production like environment – consider where to draw the line though – how close can / should you get to be realistic
- Keep builds fast as the developers need to know the code has correct behaviour (as defined by acceptance / unit tests).
- Use information radiators especially in larger teams as you need to help the information flow – extend radiators beyond compile, testing, etc..
- Automate your deployment as code has no value until its running in production and doing something useful
The Scala coding dojo got a good turn out considering it was right up against the bank holiday. This time we worked on a maze generation problem as well as the mountain of sandwiches and quiche that Robert and Thoughtworks kindly supplied. We split into two groups of four people and managed to get some interesting tests and code developed (see the LSug Assembla.com repository).