Discussions have been flying around the ThoughtWorks communication channels on balancing the risk of dynamic languages against the pain of static languages. This got me thinking about the similarities between what makes teams work well and what makes for good code and object interactions.
Logicalis have put together some advice on how to reduce the impact of IT on the environment. The suggestions range from reducing hardware requirements through virtualization and other consolidation techniques to old favorites like double-sided printing, video-conferencing, electronic forms and turning off your desktop at night.
We’ve had some discussions recently about best practices when creating Ant scripts, so I thought I’d write up a few of my favourites.
Managing Ant target dependencies
“depends” are great, until your build file gets bigger than a couple of screenfuls. You can end up with a crazy spaghetti monster of dependencies very quickly. On a few builds I’ve worked on we’ve had a basic rule:
Targets can either have depends or a body, but not both.
Coding really is become child’s play. This recent BBC news article points to some of the ways kids are being introduced to programming.
The good people at MIT have put together scratch a visual tool allowing kids to do drag-n-drop coding. The help screens give a good idea of how it works. Basically differently shaped blocks are put together (lego style) to form programs: a loop looks like a capital C and holds all the nested statements; booleans are pointy ended and only fit in pointy slots – likewise numbers are round and only fit in round slots … a nice simple introduction to strongly-typed languages. It actually fits pretty closely with how I visualise blocks of code, so it looks like a great way to introduce children to the coding mind-set. The welcoming colourful blocks are non-threatening and simple to understand.
I’ve seen some demos of Mingle and it looks great, but of equal interest to me is the choice to release it on JRuby. This seems to be another step along the road of Java moving down the stack. Java was selected as the delivery platform because corporate IT understands how to deploy, integrate, support and optimize it; Ruby was chosen as the development language because of the productivity and expressiveness of the language.
I’ve often found that it’s much more effective to show clients what their problems are, rather than just telling them. Recently I’ve ended up using GraphViz as a great tool for high-lighting complexity that needs to be addressed.
At the client I’m currently working for the complexity of the build scripts was getting out of hand. I wanted to goad the customer into prioritising some simplification work. So I turned to GraphViz to depict how complex the build was. The build we’re using is a large, centralised, Ant script that builds about 10 different applications. It manages everything through the process of compile, test, package and deploy.
I found the handy ant2dot.xsl tool that uses XSL to transform an Ant build file into a DOT format graph representing the flow and dependencies between the various build targets.
We talked, amongst other things, about where it fits into the nascent “Web 2.0” bandwagon: