Healthy Software Projects [ programming/ ]
Love this little gem on eXtreme Programming: eXtreme Pill: Increase the odds of a lasting, healthy software projectstart your journey with a Lean coach that also happens to know intimately what software development is all aboutThough it seems to come as a shock to some that such coaches actually want paying! ;-)
The Way You (Probably) Use Subversion is Just Wrong [ programming/ ]
Trying to learn Hg (Take 2) I learned something about Subversion: it seems that many people are using it all wrong!Prompted by a conversation last week with Brian which touched on Subversion and Git, I decided to have another go at grokking distributed version control. I confess that I'm probably hopelessly brain-damaged on this score; I can't help it: I started out with version control systems in the days of SCCS, graduated to RCS, was forced to deal with the abomination that was PVCS, migrated to CVS, and have largely been reasonably OK (though not ecstatically happy) with Subversion for the past several years and a half. So I can't really be blamed for my difficulties getting to grips with distributed version control, can I? I learned all I know about the subject back in the Dark Ages.
But, hey! I'm a distributed worker kind of guy. I'm sure I can figure this out, even at my advanced age.
Rather than tackle the Swiss Army Chainsaw that is Git, I thought I'd give Mercurial a second go. I lucked into Spolsky's HgInit tutorial which seems a lot more approachable than other tutorials I've seen to date, and a lot shorter than The Mercurial Book. Almost immediately I ran into a passage that stopped me short with the thought, "If this is how people are using Subversion, no wonder they want to move onto something better!"
Joel on Subversion
Now, here’s how Subversion works:No, that's not me he's talking about; that's some other Mike.
* When you check new code in, everybody else gets it.
Since all new code that you write has bugs, you have a choice.
* You can check in buggy code and drive everyone else crazy, or
* You can avoid checking it in until it’s fully debugged.
Subversion always gives you this horrible dilemma. Either the repository is full of bugs because it includes new code that was just written, or new code that was just written is not in the repository.
As Subversion users, we are so used to this dilemma that it’s hard to imagine it not existing.
Subversion team members often go days or weeks without checking anything in. In Subversion teams, newbies are terrified of checking any code in, for fear of breaking the build, or pissing off Mike, the senior developer, or whatever.
Wrong. All wrong!
As luck would have it I was discussing repository-management strategies just last week with a client's (new) development team, and suggesting that they use a much more aggressive strategy than they've ever seen before: Multiple checkins per day by every developer. Maybe go so far as to tie the "File-Save" key to "checkin". Anytime a developer does not make a checkin for 2 days in a row there's almost certainly a problem!
How do we achieve this without the tears and craziness described by Spolsky? Simple! Have every developer working in their own private branch. Or even flipping between a variety of private branches as they switch between tasks. (Yes, I know its not the most productive way to work, but sometimes we have to respond to demands from the outside world, so we do have to take the hit of task-switching.)
I suggested a structure where each developer simply gets a private piece of the repository to work in. Anything that's broken in there is your own problem, but doesn't affect anybody else on the team. When you're satisfied that your branch won't break the world you're ready to merge back to the main development line and integrate your work with your colleagues'. And yes, then you might have some merge conflicts, but I don't really see how any version control system can avoid this; you fix the conflicts and 'Lo! the build is intact. This does imply, though, that you want to merge quite frequently. At least every day or two. Or every time your private branch builds and tests clean. Or maybe just builds clean. All depends on your team - team size, maturity, process-maturity, personal temperaments,... One must study this very hard.
I suppose that the hangups about branching and merging come from the days of CVS, where branching was really, really expensive, and merging really, really difficult. Admittedly, too, earlier versions of Subversion were also not too hot on the merge side of things. (Though I guess it is still work-in-progress and we may yet see some improvements there.)
In recent times I have been using Subversion branches very aggressively. Frequently I'll find myself flipping between as many as 6 or 8 branches on related modules, merging them, abandoning them,... and this is on a one-man project! It means that I have to use branch-names that are pretty long and descriptive, otherwise I would soon lose myself in the forest of twisty little names.
But really, I don't see the dilemma Joel talks about in the quote above. I'll readily agree that Subversion's merging still needs some work: It can be quite counterintuitive and error prone until you get the habits right. But this Big Hairy Deal about breaking the build? Doesn't exist if you just use Subversion right!
Go forth and branch!
Maybe I'm making a mountain out of a molehill when it comes to Hg... Maybe I'll fall in love with it yet, if it makes this style of working easier for me. There's hope for the old fart, yet.
What's Wrong with this Code? [ programming/ ]
What's wrong with this Java snippet?public class Actions implements ActionsFactory {
public Actions() {}
//...
public static synchronized Action deleteProject() {
Action a = new ProjectAction(
ActionProvider.COMMAND_DELETE,
NbBundle.getMessage(Actions.class, "LBL_DeleteProjectAction_Name"),
null,
null );
a.putValue( Action.ACCELERATOR_KEY,
DeleteAction.get( DeleteAction.class).getValue( Action.ACCELERATOR_KEY));
return a;
}
//...
}
First correct entry wins a chockie bar ;-)
Technorati Tags: netbeansrcp, java, smellycode
Boolean Illogic [ programming/ ]
Why do Java programmers hate the boolean XOR operator?Is it that they are just generally ignorant about the full-eval boolean operators in general? You know, the operators that look like &, | and ^. Perhaps its that most Java developers are under the impression that they only operate on bits, an are ignorant of the fact that they operate on booleans (and Booleans with that fucking horrible autoboxing/unboxing nonsense.)
I know that 99 time out of 100 we prefer the early-out operators && and || for their efficiency, but a simple ^ can save a hell of a lot of unreadable and less-understandable if-then-else logic. For example, I've just refactored (somebody else's code)
if( check ){
if( !user.isAnonymousUser() ) doStuff();
}else{
if( user.isAnonymousUser() ) doStuff();
}
which I find nasty as hell to be sure is doing what it's supposed to, into
if( check ^ user.isAnonymouseUser() ) doStuff();
Much easier to understand, no?
Twitter [ programming/ ]
Twitter looks vaguely interesting. Not too much. Not enough for me to bother with it. I think it's very Flavour Of The Day.But it does suit one thing I've had in mind for a while... the idea of a "stream of consciousness" blog sort of thing. Essentially a blog where I can just post a line or two or three, without all the formality and palaver of Subject lines, Categories, Tags, etc. In a nutshell, Twitter,but without the 140 character limit, and hosted on my own server as part of my own infrastructure.
Maybe I'll just write it....
<i>I need another development project like I need more holes in my head. Only two major development projects on the go at the moment, and a couple of minor ones.</i>
Etude Progress Report [ programming/ ]
The Etude project is making some progress. Jason is working on the front-end UI in GWT; I'm building back-end management and server-side functionality. Yesterday I put in Client-management UI and today finished it off with User-management. All in straight JSP/Servlet logic. Ugh. Horrible, messy stuff.The object-model for the project is also a mess -- a sign of my lateness in getting involved on that side of things, I suppose, but we're leaving all alone for now with the aim of cleaning it up later. I know we'll end-up paying for that decision somewhere down the line! But for now the goal is to get a functional Version 1 out, and some paying clients signed-up. Once there's cashflow we can justify the time and effort to make the codebase more habitable.
I guess my next objective is to ensure that the scheduler end of things gets tested...

Wizzards [ programming/ ]
Programming software is Magic.
I don't mean that there's something mystical about it, nor that it is intrinsically inaccessible to ordinary people. Nor (I emphatically add) do mean that it is like Magic. In every aspect I can think of, the act of Programming software meets all the criteria for performing Magic. Magic in the Swords and Sorcerers or Unseen University sense. "Alakazam!" and the Prince turns into a Frog. "Shazam!" and you're whisked away to a far, far place at high speed.
Just look at the facts: We (programmers) write programmes -- spells -- in arcane and cryptic symbol languages unknown to the common mob. Get the slightest part of the spell wrong, and, at best, it fails utterly to do anything. At worst it runs amok and fearful consequences ensue -- fires, floods, loss of money and even life! Get it just right, in every teensy, tiny, ball-aching, nit-picking detail2, and Lo! out of nothing, stuff happens in the real world. Gold changes hands. Trains run on schedule. Music plays and Feyries dance1.
Where nothing was before the spell was cast, something comes about solely because of the spell. That's Magic.
And, just like in the fantasies where Wizards keep pet Dragons and dribbly candles set atop skulls are the acme of interior decoration, programmers frequently work at odd hours, with intense, monomanic concentration bordering on the inhuman. And, like the traditional Wizardly Schools, programmers are admitted to different schools of various arts and degrees. So we have Clerics -- programmers content to churn out the boilerplate code needed to keep the wheels of commerce (and most web applications) running, but lacking any true proficiency with martial weapons of higher degree; Monks -- who eschew the use of particular weaponry but, ninja-style, willingly embrace whatever comes to hand as combat fodder; Wizards -- capable of serious Magic, but forget their spells once cast, capable of wonderful stuff, but doomed to repeat it -- with minor variations -- time after time; and then there are the Sourcerers -- Masters of The Source3 whose code is so elegant and expressive, so parsimonious and pretty as to make brave Programmers weep with envy and admiration.
No, you can not deny. Programming really is the realisation of the ancient idea of Magic. Say the Magic Spell and Change Reality.
[1] Well, anybody who wants to dance, I suppose, really.
[2] ...and My God, there's an inordinate amount of crappy detail that all has to be Just So!
[3] Waves to Ken, Doug, Dave, Jason, Paul, Johan, Bob, Brian, John and several dozen others...
Quartz Crystal [ programming/ ]
A very trying couple of days... Faced with a job that cries out for a decent scheduler (polling feeds), I turned to OpenSymphony's Quartz. I mean, the ads look so good: Robustness, recoverability, scalability, blah, blah.First hint of warning I should have paid attention to was a couple of developers' names that I long associate with Doomed Pieces of Shit. But it all still looked so good. Until I got closer to the code. Quartz? Quartz Crystals for accuracy? More like Crystal Meth! Documented methods that mysterious fail to exist. Examples that aren't. I thought the JavaDoc got generated from the source, no? I guess we have here the penetrating stench of Configuration Mismanagement.
Then you enter a twisty little maze of undocumented dependencies. You will use Commons Logging. You will use a bunch of J2EE stuff, even though you application is a simple standalone with no hint of J2EE awfulness in sight.
No. After a day or so of hacking at this steaming turdpile my brain feels like so much oatmeal porridge that I can't even work even work up enough bile for a decently vitriolic blog post. For me, one of the surest signs of a dying opensource project is when their wikis and forums are filled with spam because nobody can be bothered to disallow Guest users from posting; when the version-control system shows six checkins in the past six weeks.
I'm outa here in favour of Doug Lea's concurrency stuff. What a pleasure by contrast. I'll live without clustering for now...
Technorati Tags: quartz, scheduling, opensource
