Occasional reflections on programming
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.
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:
Was just talking to Garry idly about how we enjoyed both NoKahuna and Things and how annoying it was that there was no way of making them work together, and we started building a fantasy API – a generic Task-tracking API which all the task-tracking webservices (RTM, NoKahuna, BackPack, and Mingle, Trac, Mantis, Bugzilla…) might then implement, and all our favourite clients (like Things, Things.touch, but also OmniFocus and others) would also implement (or provide plugin architectures or (open)source-level access to allow others to implement).
Wouldn’t it be nice?
Plenty of updates to http://permatime.com recently, partly inspired by the spike in new visitors, referred by the comments and updated posting to do with the recent 37signals-live online realtime video event: first-time visitor friendliness, links, samples and bug-fixes.
(Have no idea what I’m talking about? Permatime.com is a micro webapp aimed at making it easier to share a point in time with people across different timezones. A sample (all the bells and whitstles) permatime link might be: http://permatime.com/US/Central/2008-12-04/11:00/37signals_live?link=http://live.37signals.com. More samples on the homepage.)
I had a busy weekend being a social innovator. Well being social at least (let’s keep the claims reasonable): I think I met more people in one weekend than I have done in the whole of last year. Enough great ideas to give me a headache too (or was that post-sicamp pub session?).
Reading a thread on the mysociety list, which discusses a posting showing a mashup technique “with no coding required” and a subsequent critique of the specific mapping presentation to which this technique was put, led me to think about how screen scraping adds or removes value from it source data. My first response was that the two parts of the online discussion – technique and usage – were separate evaluations that shouldn’t be conflated.
As part of the process for trying to get Clever Plugs onto the BBC commissioning roster for on-air graphics, we had to reflect on how we would help the BBC reduce costs. So I wrote the following about why I thought our approach – iterative, tendency agile (see e2x’s article on sustainable software for an interesting differentiation here).
We work with the latest technologies and with only the highest standard of multi-disciplinary developers and designers. These are both ways of cutting costs, but can also present risks (latest technologies carry unknowns, highest standard of developers delivery quality, but are expensive). For this reason we find that risk is the highest factor affecting cost, and we dedicate our working practices to controlling and reducing risk within the project, aiming to have a smooth curve in the decline in risk over the course of project’s timeline.
To do this, we use best practices & methodologies from the agile methods of software methodology (see Martin Fowler on the New Methodology and The Agile Manifesto). Overall this means focusing on interactions amongst the team, working software, and collaboration with our customer to achieve the needs of the project over its lifetime.
This leads to practical impact on what we don’t do, what we do do, and then how this reduces cost…
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”?
I was about to write a quick post on why I’m fussy about what URLs look like (see below Locator + Name = Good), and thought there was an important distinction between URI s/URNs and URLs. Then I googled to check my terminology and discovered that not only was I wrong, but it was hard to find a good succinct definition. I aim to clarify here the best-practice terminology of the basic building block of the web “URI” and the important notions of URI that are “names” (formerly URNs) and URIs that are “locators” (formerly URLs).
Read the rest of this entry »
Hit ‘alt-control-delete’ to restart this blog, or at least show the running processes. (Actually though, I’m now on a mac, so mostly shouldn’t need to refer to those keys anymore).
I keep re-reading Joel Spolsky (whose last name is not, I discover, “on Software” – not, then, a member of some kind of minor german nobility) emphasizing that good programmers must be good writers. Well, actually when I google for him saying it, I find he actually says:
…years of experience working with programmers have taught me that programmers who can communicate their ideas clearly are going to be far, far more effective than programmers who can only really communicate well with the compiler.
and elsewhere goes so far as to say:
Red56 blog 