I’m very keen on going to see what cross over there is between domain modelling for general purpose software systems and content modelling for content managed solutions, a particularly interesting area for me at the moment.

Hope to see you there

Well, that seemed easy. So I tried it out. Hmm, that works. Then I re-watched the ‘Introduction to Git’ video above. Hey presto, from git-to-god in six months. Impressive. I still don’t like video, can’t put my finger on it, but I love the Git. And to those people that brought us the Git and a big thank you to you.

What is the Git? Git is a fast distributed revision control system. Now I use the Git religiously. Not just for my personal coding projects, but for the documents I write, the web-sites I build, people I share knowledge with, and so on. But why do I like Git, a few things really.

Firstly, I tend to operate out of directories a lot and need to version control everything under it. What I don’t want to have to do is create an artificial master copy on a centralised server and have to periodically sync up to that. Pointless. Instead I just want everything I need to be available from within my working area – my directory.

Secondly, branching and the management of branches must be brainless activity. Git embraces and encourages branching. After reading the git tutorial I was shocked at just how easy it is to work with branches. There is just no other way of working for me. Branching in subversion is harder and hence less appealing to me, so that’s probably why I didn’t use it as much as I’d liked/should have.

Thirdly, local commits. I can commit without access to a centralised server. There is NO centralised server. Instead you have a network of peers. No need to distribute/cluster a central repository. Distributed repositories are the norm, not the exception. There is no single-point of failure that you have with subversion, instead, the risk is spread amongst your peers.

Finally, simplicity. Once you’re happy working with branches locally, you can push and pull information to and from your peers’ branches. The syntax is clear and concise. There is not difference really to what you’re accustomed to working locally.

The problem with Git and distributed revision control systems like it is industry take up. Will the build systems such as Ant and Maven, the IDEs such as Visual Studio, IntelliJ and Eclipse, and so on support the Git. I think this is happening but cannot report conclusively on the current status. However, I am starting to see many more open source projects start out with the GIT and other migrating over. Also for web site development, where you try out new stuff, roll forward, roll back, compare and contrast, numerous different solutions, Git and its easy branching solution is a great tool.

Finally, a commercial example. I use a Groove. It’s a collaboration tool primarily used for sharing documents. It has a proprietary algorithm for the effective sync’ing of large amounts of data across a network. It also is a commercial product and so there are lots of features such instant messaging, calendaring, discussions, sharepoint integration and organising stuff. However, for me, all that is redundant. All I need is fast distributed, file-sharing.

The problem with Groove is that is breaks easily (admittedly the pre Microsoft Groove 2007 version). I’ve had to install it many times in the past and that takes time. When I change machines, I have to re-install it. When it starts crashing, I have to re-install it. The sych’ing between my peers has been problematic, to the point where we are asking each other whether you have the latest update. That’s not good. Given that I only use Groove for file sharing, I believe Git would be a much better and reliable solution going forwards. It also has the added benefit of being cross platform.

Successful teams value planning over plans. However, things are really broken when the reverse is true. We’ve all been there before, trapped within the mother of all project plans. You don’t need a sixth sense to see what’s coming – we see dead projects! Jeff Goldblum in Jurassic Park sums up beautifully the typical phases within a plan-only project:

“Ooh, aah, that’s how it always starts, and then later the running and screaming… “

About eight years ago I joined a project to seed Java knowledge. The team was new to both the language and object technology. After an initial requirements discovery phase and some preliminary high level designs, the project manager called a team meeting to discuss the plan. We all sat down ready to start planning. I love planning sessions. Instead, in true Blue Peter fashion, out came a completed Gnatt chart that the project manager “had prepared earlier”. My heart sank as he handed out the “final” plan with all the final steps to success. Upon closer inspection, things were much worse than I had first feared. Armed with the initial designs, add a generous sprinkling of Java for Dummies, and our friendly neighbourhood project manager added every class as a line item within the plan.

Then, he did it. Oh boy, did he do it. He asked us to estimate each class on his project plan. So for the AbstractDataFactory class, 1 day, StringUtils, 2 days. And so it began, every day at 4pm GMT, we had a status meeting where each team member provided an update on % Complete for every class that they were responsible for. After 3 of these 2 hour daily meetings the team rebelled. Our project manager was suffering from a bad dose of plan-blindness. He could NOT see past the plan. The plan was the deliverable. The project been relegated to being the dark horse of the family. We no longer planning. Am pretty awful place to be really.

Fruitless discussions between the team and the project manager brought about no change. Time was a premium so we made a decision. Project over plan we agreed. The team started scheming. From our perspective, the plan was total project waste. I won’t even tell you what happened to the plan when we re-factored the code base on day two. So we looked at all the classes on the plan, wrote a simple application that sent an email that bumped along our % complete to successfully deliver the plan. The email basically told our project manager want he wanted to hear, delivered the plan, and immediately re-claimed a valuable 2 hours per day per developer. We then set about successfully delivering the project.

So what? First of all, I’m not saying you don’t need a plan, but the plan is not as valuable as the act of planning. Secondly, continuous planning is essential. If you sat down with your team now, handed them a piece of paper and asked the following questions:

1. What is your next deliverable?
2. When is it due?
3. Are you on track?

If your team members come back with different answers, something is broken. Finally, some people are good programmers, others are not. Same for planning. Some people are just not wired up to plan ahead and prefer to just do it. That’s not a big deal but you just need to be aware of that and encourage them to participate in planning sessions.

Now the more pressing problems and prickly questions around the enterprise, integration and scalability need to be addressed and this is where Ruby is amore compelling story. In fact, things in the Ruby space are really moving forward at break neck speed. It’s not surprising really, given the relatively few Ruby conferences there are each year, that Ruby gets to play out and steal some of Rail’s thunder at RailConf.

So what is going on in Ruby space that’s so interesting?

Ruby Implementations – Where integration is Key

First up there’s JRuby. This is a 100% pure Java implementation of the Ruby programming language. And right there is JRuby’s sweet spot. The ability to seamlessly integrate with the Java platform through Ruby is a big win for some. So running Rails under JRuby and using it as a web gateway into your Java enterprise, together with the ability to leverage mature/known Java tools and the free performance hikes that accompany it has been a very appealing proposition to some. A prime example being the ThoughtWorks Mingle product. Also, having access to the abstract syntax tree which can be shared between multiple Ruby runtimes hosted within the same JVM process is pretty neat and a highly efficient way of managing memory.

MacRuby! As a Mac User I’m excited by this implementation of Ruby 1.9. With MacRuby you can write Mac OS X applications in Ruby without the performance hit typically attributed to standard Ruby and Ruby Cocoa. MacRuby is native to Mac OS X core technologies. Damned quick with all the elegance of Ruby to boot.

IronRuby, backed my Microsoft and sits on top of its Dynamic Language Runtime (check out John Lam’s talk on the DLR), is a .NET implemention of Ruby. IronRuby enables Ruby programmers seamlessly integrate with the .NET platform, in much the same way that JRuby does on the Java platform. Ruby.NET is open source .NET implementation that does not have the same pull as IronRuby.

In fact, the main draw for Ruby developers that target JRuby, MacRuby, Ruby.NET or IronRuby is integration with the Java, Mac OS X or .NET plaforms respectively.

Ruby implementations – Standards are key

Let’s park integration. Let’s focus upon Ruby developers building Ruby apps with an Ruby-oriented environment. Both Rubinius (a spec led Ruby implementation) and MRI/YARV (currently the official Ruby) are competing VMs for running Ruby applications. Everyone started with Matzs Ruby Interpreter (MRI) but now we have many more alternatives. The Yet Another Ruby VM (YARV) project has officially merged into MRI as of May 2008 to combine the best of both worlds to enhance the official Ruby implementation.

RubySpec

But unlike Smalltalk that was really killed by competing implementations, the Ruby community, through RubySpec are collaborating on standards and competing on implementation. This is good. No, hold up, this is great! This will hopefully provide more choice to the developers to select the appropriate Ruby implementation that best fits their solution requirements. Hopefully, this will hold the community together and keep everyone pulling in the same direction. So far, that appears to be the case…

..but then there was Ruby for Scale – Maglev

Maglev is a Ruby implementation built on top of Gemstone’s VM that is written in Smalltalk. Chad Fowler goes into the why and when you would choose to use this Ruby implementation other the others. But the problem is very few people have access to Maglev. It promises the world and come on guys its time to show me the money! The community has seen is a presentation. A damned fine presentation I’m told but Charles Nutter of JRuby is not convinced and other people are already dismissing outright Maglev’s claim to scale. 100 times performance improvement is a big claim. One to watch I guess.

And Finally!

Take a look at the following code snippet:

#!/usr/local/bin/ruby

require 'scalability'

# your code

Now the Twitter guys must be get this all the time. Twitter is growing in size and its architecture will mature and incorporate different technologies I’m sure that best fits their current problems. Time will time. But to say its Ruby’s fault is a little naive at best. That said, wouldn’t it be just great if only you could include scalability in Ruby applications, Java apps, .NET apps, or whatever the platform.

Now, that would be awesome. But the simple fact is you can’t include it, you have design it in. Boooooo say the crowd. Kill joy chant the business. But unfortunately, like so many things in the software industry, you have to go the long way round (read as experience) to get desired results. Because there are no short cuts (read as foolish hacks, or inexperience) on the road to scalability…only blood, sweat and tears! But there are leg ups, tools and techniques and people to assist, but that’s any story for another day…

It is now time for Java Developers to Stop, Look, Listen and Live! The climate is changing. Java the language is entering middle age. Java is not the first language that developers are picking up. These days when I talk to young non-Microsoft developers, a lot of them don’t know Java and have no plans to learn it either. Dynamic and functional languages are on the rise. The web IS a viable platform for business. More and more applications are moving out of datacentres and into the clouds. Since Java 1.4, the interest shown by experienced Java developers suggests that are not focussing on Java the language. A lot of Java developers have not developed against Java 5. Even less against Java 6. As a Java developer, do you know what’s coming in Java 7? Do you care? Do you, Mr. Busy Java Developer, really care? If so, here’s a couple of things I reckon you should, if you haven’t already done so, think about this year as a Java developer.

The Three Gees: Groovy, Grails and Gant. Groovy is a dynamic language for the Java Platform. In short, building on top of Java, it injects a degree of flexibility in the way Java-based software systems are created and continue to evolve. As a Java developer, you are seriously missing a trick if you do not have Groovy in your toolbox.

Grails is damned fine web framework. The Grails/Groovy pairing brings the same advantages to the table that Rails/Ruby does. Now I’m a big fan of Ruby, for the busy Java developer I think that JRuby/Rails/Ruby is more of a distraction than the Grails/Groovy option. Groovy’s support for Java frameworks such as Spring and Hibernate are too good to ignore. Also, if you already know Groovy, Grails is a no brainer. In fact, at the Java Web Frameworks Tournament 2008, Grails made it into the semi-finals. Not bad…JRuby on Rails won

Finally, we move onto Gant. Which is like Ant but the language is Groovy not XML. With Gant plugins for Maven 2, your build options are trivial. The only real contender to Gant is Buildr which is a damned fine Ruby based build system for Java applications. Again, the trade-off for simplicity in the Busy Java Devleoper life is, if you keep to the Three Gees, you’re covered. Otherwise, you have another build system to learn and require all your developers to know Ruby.

Scala: This is a newbie on the language scene that has been bubbling away since 2001. However, like Groovy it integrates with Java beautifully and provides a nice mix of object-oriented and functional to bring yet more options for solving a differ class of problems for Java developers. For the Microsoft people out here, Scala implementations also integrate with the .NET platform. In this era of distributed computing, scalability and component based development Scala arms the Java Platform with some great tools for addressing these problems. And again, for the Busy Java Developer whose bread and butter is the Java Platform, you cannot afford not to be aware of how Scala may fit into your world. Word of warning, Scala is not for the lazy or faint hearted. You need to put some time into this language before you start reaping the benefits!

Spring Source Application Platform: EJB 3.0 is alive and kicking. EJB 3.0 is a great platform. EJB 3.0 is not future. EJB 3.0 will never be mainstream. After the non-sense of EJB 1.0. The constant public pounding by Roger Sessions @ ObjectWatch (Poor Ed Roman). The rather feeble attempt of EJB 2.0 to rectify the shortcomings of EJB 1.0. The industry couldn’t and didn’t wait for EJB 3.0. Now if we could wind back the clock say 24 months and re-branded EJB 3.0 as HellFire 1.0, there would be no such thing as Spring Source Application Platform. EJB 2.0 created the market and effectively stepped out the race by giving us such long lead times. The guys at Spring have capitalised on this massive window of opportunity and have produced something pretty cool. However, not all is great. They have rather naughtily upset the OSGi people, in particular Peter Kriens. Hopefully, they’ll change fall into line for the good of the community.

I like your Bundle!: This leads us nicely onto OSGi. If you haven’t heard about this as a Java developer, where have been? Please, please, please, add it to your list of things for this year to pick up. It a must. Have you never wondered how Eclipse manages the lifecycle of its components? How you can upgrade stuff easily and without a restart. No messy classloaders. Define, package, deploy, stop/start and manage your components. Side-by-side deployments of versioned components. Essential for 24/7 Java applications. This is OSGi. The guys at Spring have created a Bundle Repository that makes the use of OSGi simple.

Domain This, Domain That: Not essential but an important thing to know about. Domain Models, Domain Driven Design (DDD) and Domain Specific Languages (DSLs). When you start thinking about the Three Gees, Scala, OSGi and so on, how can you do that without a domain model. The DDD is an approach to domain modeling, where DSLs are way to facilitate human to machine communication that invariably operate within the context of a domain.

Right, I’m exhausted. Everyone gets busy. It’s easy to be left in the trenches and not have time to step back and take a long look at what is going on around you. I’ve suggested a couple of things that I think are useful. You probably have more. If so, please leave a comment…

I wrote a simple English->Polish translator application in Ruby. It does all the usual stuff such as add new words, search for words in either language, and maintain the words in named bundles. The challenge I set myself as a novice Ruby programmer was to implement the core set of features knowing that the code would be fat and not very pretty. I then aggressively sort to refactor the code to reduce its size, whilst increasing the feature set.

The core translation engine started out as 120 lines of code with just the add new word feature. Since then I’ve learnt a lot about how to structure Ruby programs and the effective use of closures, iterators, containers and yaml. In the process, I’ve added search, display and bi-directional features to the translation engine and reduced the lines of code to 114.

I have a new found respect for Ruby the Language. It is the most expressive language I played within in a long time. Also, contrary to what many non-Ruby programmers tell me, Ruby is readable when written well. Unfortunately, on my travels through the web, I have seen some really awful Ruby code and this stuff is truly poisonous. Bad Ruby is completely unfathomable. A ticking time bomb. However, well-written is Ruby is sublime. I truly believe that there are no shades of grey here

What became abundantly clear to me is that although the room was jammed packed full of smart people, only about half of us knew what lexers and grammars were. This got me thinking about assumed knowledge. I’d also assumed that the majority of application developers knew at least Java or .NET. Not so. There were a lot of attendees that were pure Ruby, Perl or another.

Looking back, my language stack consists of 5 years of assembler/C, 10 years of C++, and 10 years of Java, where there was gradual hand-over from one language to the next. On the way, I dabbled in Smalltalk, Eiffel, ML, Prolog, and more seriously in .NET and Ruby. The very nature of the language meant that I needed to know about compilers and language design. Also, as part of my thesis I had to swallow context free grammars and chomsky, to write a header file parser that performed the static design analysis of large C++ systems. But the only reason I did this is because I had to, and the tools available to me then were yacc(grammar)/lex(lexical analysis).

Now, if you don’t use these types of languages and parse very simple grammars, there is no need to get your hands dirty. However, Rebecca was spot on when she pointed out that tools such as yacc/lex and to a lesser degree antlr, have received bad press as being archaic, blunt tools with magical powers that are wielded by the chosen few. In reality, there hasn’t been much cause for the masses to use them. Will the drive for external DSLs where you want to create your own language make them more popular? I doubt it. I think people will still opt for internal DSLs that are written essentially in the host language (e.g. rSpec, JMock, and so on).

But I have to realise now that those guys/gals born in the eighties and heaven forbid the nineties, are operating off a completely different programming stack. Their minds are in different places and their toolset is somewhat orthogonal to mine.

Strange. I suddenly got older very fast…

Technorati Tags: dsl

For me, having sat through the tutorial, the headline moments for me were:

• Understanding what the differences are between an internal and external DSL
• Knowing when to select one over the other
• There is a lot of unknowns surrounding the whole area of DSLs, and what Fowler and Co are doing are exploring the problem space and proposing options.
• Some languages, Ruby, Groovy, Scala lend themselves more easily to writing readable internal DSLs
• Other languages, such as C# and Java, tend to pollute their DSLs with syntactical noise in the form of {}, “” and ()
• When the language is getting in your way, it’s time to more from internal to external
• DSLs are a layer on top of a framework that is used to setup and configure framework objects
• External DSLs free you from the constraints of a specific programming language but introduce an extra step in the form a parser generation code to your build
• There were a LOT of Ruby guys in the room, including the leads on rSpec, an internal DSL for Ruby testing
• The definition for DSLs is wide open for interpretation and a lot more will happen in the space over the coming months
• I need to do some more reading around the concept of a language workbenches. Very interesting stuff.

So when is a good time to hold a code review? Weekly, after every sprint/iteration, monthly? The regimented, thou shalt have a code review every X, has never worked for me. You cannot predict what will be going on in a project and shoe-horning a code review is just counter-productive in the extreme. Typically, you should always hold your first code review when you get to a place when you have something to take about. In the article, the author says this is 20% through the build. Maybe. But I think this depends on the project, so its a team gut feel. It’s got to be early enough for changes to made, glaring errors and/or omissions to be highlighted but far enough through to warrant the time and effort that needs to be invested to make it worthwhile.

After the first review, its a judgement call, as to whether another code review is needed. This is where certain design quality and product metrics can be used to help make that call. Are the number of broken builds increasing? Is the test coverage going down? Are the number of dependencies between packages increasing? Is the team producing more complex and/or large methods? Is the source not conforming with pre-defined standards. If so, maybe its time for a code review.

Oh, and before the pure agilists start jumping all over this and say code reviews, isn’t that covered by pair programming throughout. Well yes and no. I think a code review, at a team, rather than just at pair level, is a very important exercise that should not be replaced by pair programming.

Heroku allows me to build and deploy Rails applications. It couldn’t have happened at a better time for me because my current provider doesn’t give me what I need re. Ruby and Rails. So I took the following steps:

1) Registered with Heroku
2) When I got my sign-up email, I zipped up my Rails app (removing the .svn directories, tmp and log folders)
3) Uploaded to Heroku
4) Then run it

The application is a re-write of http://www.clevegibbon.com and can be found here http://clevegibbon.heroku.com. I’ll evolve it there.

Heroku is novel. Stunningly simple. Very expressive.

Sweet!