Workflow for Chef with Vagrant

UPDATE (20/11/2011): The hacks here are superseded by updates in chef-solo and vagrant. Check out Ches Martin’s useful comment below.

I have now got a relatively decent workflow for configuring both a vagrant instance and a server using chef.

I’m using a vagrant instance configured (initially) to use chef-solo. Because I will eventually be using chef with the opscode platform, I’ve acquired a couple of hacks that help me use data-bags when using vagrant.

Understanding BDD motivations better

I posted earlier some reservations about BDD – largely based (as I now understand) on the declared motivations of some BDD practitioners (ringleaders even) that BDD tools enable customers to write tests (and also it felt like another software practice that swept up ‘requirements elicitation’ as a simple step to do before coding (and even if you do this iteratively, you are still doing ‘spiral’ development, but certainly not doing agile development).

However, reading at the interesting pairwithus:

Write it on an index card

I am a fan of index cards and always have been. However index cards always end up being only a tentative experiment for me – from the days as I child where I would try to “categorize everything” into cards (I had several index card boxes with partial categorizations) – somehow this frustrated my parents greatly (Now as a parent I can begin to understand this).

I tried the ‘Hipster PDA‘ index-cards-as-organizer thing – at different times in my life (yes, even before they blogged about it), but only ever for a while. It’s fun while it lasts (till my backing cardboard gets too bent and all my rubber bands snap ).

I’ve tried doing CRC cards, too (though never really caught on with me).

And then there’s story cards. We had a great experience with running sodaplay development with these for a while – until some of us needed to work remotely. Since then we’ve had some good experience of transferring the principles to Trac, but the mystique (and discipline!) of story cards (that derives in many ways from the physical features (let’s say, affordances, even) of index cards) is missing.

Enter Mingle, perhaps?

This is a rather exciting* looking offering from thoughtworks (which seems to be crossing the consultancy-product gap in interesting ways) which seems to combine the virtuality of a trac-like system with some of the power of index cards. Plus oodles of optional process-y stuff (that trac largely eschews).

*’exciting’: perhaps only understood in context, and maybe only if you are a process-anorak (oh dear, that must make me one). 

In some ways, I like the look of Mingle (I have to admit I haven’t tried it out, but only looked through the tour). However as a micro-business, with tiny (1-5 person) teams, all it does for me is increase my frustration with trac – don’t get me wrong, I do love trac, but it is aiming at a slightly different audience –  opensource and product-management, I’d say, rather than project iteration management.

But Mingle’s not aiming for my segment of the market either, as at least evidenced from the price point. It is just too steep a hike away from even the most luxurious of hosted trac offerings. And in any case that price is license-only (unhosted).

The per-user pricing also hits if you are project-focused (which red56 is) – because the team needs to include one or more customers, each of which need to be a team member (interestingly the customer isn’t really a part of most of the tour – are index cards meant to be only part of the development ‘back room’?)

This probably adds up to a request for a different product – hosted, aimed at smaller companies, and probably with some of the issue tracking features of trac as well (after all a bug/enhancement ticket/issue is part of the pipeline towards becoming a story  – though some (notably 37signals) disagree). Perhaps someone will write this application, launch a hosted service, sign me up and start billing me for it – or just tell me about it (send me one of those index cards with pictures on the back).

One odd thing that strikes me about Mingle – a ‘project collaboration and management tool for Agile software development’. Isn’t agile meant to be about “Individuals and interactions over processes and tools”? How do we measure that against promotion in Mingle of  features that “make it easy to ensure adherence to project compliance”?

Simplicity or Optimization?

A comment from a colleague on the importance of the experience programmers bring when refactoring to good design

“Something that doesn’t get mentioned about refactoring to a ‘good design’ is that there is a lot of experience brought to bear about what is good. ”

The joys of parameterization

A hidden gem of parameterized tests discovered in Junit 4 javadocs.

While developing the tests for the new sodaplay.com, which needed to test that certain pages generated correct links no matter the name of the context path… That’s a pain because you want to repeat the same tests with just a single parameter difference (the context path). And I’m going to have to do that for each page that I want to test…

Customisations

When talking about playforge modules last year, we had an idea that XML-based ui definitions might be helpful. Some of us had had some experience with XUL/Mozilla – and saw the power. We thought initially, maybe we take some sort of existing framework and integrate it. However the more we’ve looked the more we come to believe that our requirements are slightly different to most of the XUL-like options out there.

Annotations

Currently in the playforge development we’re using annotations to help with specifying “persistence” (really serialisation&marshalling, but it’s always within the context of saving and loading) and ”bindings” (hooking up XML-specified UIs to the execution of java code during runtime). Some people might well ask (especially those who have read around the issues about “Annotation Hell” or “Annotation Overkill”) why use annotations for this at all, why not just use method-naming standards and normal java introspection? 

Bindings

Have started to make it possible to make a ui described in one or more xml files to be connected (bound) to code in a (java) application. There are two kinds of relationship currently envisaged:

• simple callbacks representing a one-way execution of code from the ui
  for example, code that is invoked when a button is pressed
• variables representing a two-way relationship of code to the ui
  for example, a slider that not only controls some feature of the application (e.g. the gravity slider in constructor), but might itself respond (“listen”) to changes in the application, as in the selected slider in the constructor application is indicated simultateously in both the main simulation window and in the sinewave window on the left. In a new version of the constructor application there might be sliders (or even just numeric editors) that can control the position (x and y values) of the selected mass and also reflect changes in its position.