Archive for September, 2007
The fat hippy has a nice review of some sweet looking mtb lights.
I’ve always felt my home made lights were great – cheap, reliable, and bright. But when the time came for my wife to get some lights, I decided to go commercial. Why? I wanted them to be absolutely reliable, unlikely to ever require trailside repairs and lightweight. That’s not to say my home made lights have been unreliable, they haven’t, and they’re so simple that if repairs are required, they’re pretty easy. The trouble is, wives don’t like even running the risk of having to fix lights, and if the lights are home made, they’ve got a handy target on which to vent their anger. Well, my wife doesn’t, anyway, and I don’t like taking the risk of being the target… ;^)
And I have to be honest, with SLA batteries, my lights are heavy.
I’d been thinking of trying to make some home made LED lights for myself, and when AY-UP released their sets – with two 2 x 3W Luxeon LED units for less than $400, I thought they might be good. A few people I know bought them and gave very positive reviews. I bit the bullet and bought my wife a kit. Price is a winner for home mades, but the AY-UP kit is comprehensive, and well priced for a commercial LED setup. AYUP have released a Cree LED upgrade – pix at end of review.
Now all I have to do is get some through the budgetary committee…
The second interview started off with the usual pleasantries, and then the technical grilling began with:
Ã¢â‚¬Å“What are the best practices that you would put in place on a project?Ã¢â‚¬Â
I replied Ã¢â‚¬Å“IÃ¢â‚¬â„¢ve come to realise that there is no such thing as Ã¢â‚¬â„¢Best PracticeÃ¢â‚¬â„¢ in architecture Ã¢â‚¬â€œ everything is contextual.Ã¢â‚¬Â
Well, it went down like a sh*t sandwich!
Ted replies (in part).
For some companies I’ve worked for, the “architect” was as you describe yourself, someone whose hands were dirty with code, acting as technical lead, developer, sometimes-project-manager, and always focused on customer/business value as well as technical details. At other places, the architect (or “architect team”) was a group of developers who had to be promoted (usually due to longevity) with no clear promotion path available to them other than management. This “architect team” then lays down “corporate standards”, usually based on “industry standards”, with little to no feedback as to the applicability of their standards to the problems faced by the developers underneath them.
I’ve been thinking of the role of architects for some time, having worked with some good ones (well one) and some bad ones. A graduate recently posted to an AJUG list seeking mentoring (a good call BTW) saying that their career goal was to become an architect. I’m puzzled by this personally, as I don’t see a need to “escape” development in order to advance my career. To be fair to him, he wasn’t seeking to “escape” either, however I’ve observed a general perception in the industry that developers feel that to advance their careers they must “step up” into management or architecture. Surely there are other ways to improve.
I was one of the technical reviewers for the book earlier in the year, and I saw it come a long way from where it started to where the reviewers left it, and it seems to have come a far way since. It started out as a fairly TestNG heavy book and hopefully ended as being a good general reference to practical developer testing with the current stable of Java testing tools. I would have liked to have seen extraction and more coverage of some of the common patterns used in testing (edge, statics, external code, new calls, etc.), but hey, it’s not my book!
Interesting, one of the commenters on Alex’s post asks about coverage of QuickCheck and related tools. Inspired by Tony (fellow mouse & developer on ScalaCheck) and Popper/JUnit’s Theories, Chris and I have been working on bringing this to Instinct. Hopefully I’ll get a chance to extend this work in the next few weeks. I see this and BDD as the next big steps in Java testing frameworks.