Well, at least I never saw a 1.1 between 1.0 and now 1.2. C-JDBC is an interesting piece of middleware. I once proposed it to a client as a possible solution for a MySQL-based architecture if real database clustering would be required. It wasn't a must and since C-JDBC was back then pre-1.0, nothing came out of it and the system went to production (and I believe it still is) with MySQL replication and the application server's DataSources handling failover on their part.
Anyway, I'm happy to see there's still much activity going on around C-JDBC. I wonder if my couple of lines of submitted code are still in the admin tool's codebase...
When you see things like this little .sig I spotted from ruby-talk:
$stdout.sync = true
"rekcah ybuR rehtona tsuJ".reverse.each_byte do |b|
('a'..'z').step do |c| print c+"\b"; sleep 0.007 end
print b.chr end; print "\n"
(Well, I added a little touch myself, having the fever and all...)
Oh, crap. Why did I end up reading this blog entry? Now that I'm painfully aware that someone is offering Rails hosting for reasonable prices (I don't consider TextDrive's pricing to be even close to "reasonable"), I'm really tempted to move away from PCHighway (who do have Ruby installed but no Rails, no FCGI, etc.). Then again, I still haven't set up my web identity, so...
Oh, and since I have this Ruby fever going, I decided to create a whole new category in my blog for this stuff so that those who are only subscribing to the Java and General feeds, for example, don't need to listen to me go off about learning to use closures and stuff.
Joel Spolsky (of the Joel on Software fame) has started a series of blog entries shedding light to what they've done at Fog Creek in the past.
In the 3rd installment, Joel tells about how they needed to port their ASP-based application to PHP so that it would run on UNIX boxes as well as Windows. Their solution was to build a custom ASP-to-PHP compiler, relying on a variation of Hungarian notation among other things.
What I don't get is this: If your goal is to make your application portable, for how long is it worth the effort to develop the ASP version and make sure that the custom compiler can keep up with what they're doing? Wouldn't it be easier to go the other way? I.e. compile once from ASP to PHP and then keep on doing PHP only -- deploying on Apache on both Windows and UNIX.
I'm certain that there were valid reasons for sticking with the ASP codebase as the master some 2 years ago but I have to wonder if Joel & Co. should really be looking at switching to a portable language like PHP/Java/Python/Ruby instead of maintaining their own portability layer?
David Anderson blogs about paradigm shifts. I have to say that those five bullet points communicate quite effectively:
- Flow through value chain, focus on throughput and effectiveness - as opposed to, cost and effort estimating and tracking, cost accounting, efficiency and earned value analysis
- Theory of variation (common and special cause) and buffering - as opposed to, deterministic scheduling and Gantt charts and deviation from plan
- Synthesis and systems thinking - as opposed to, Cartesian decomposition, (bottom up rather than top down)
- Process control and continuous improvement - as opposed to, conformance to plan and specification
- Empowerment and service - as opposed to, command and control
Keith Ray is not far from the topic either with his short report of a visit to Toyota's NUMMI facility. Can you imagine working in 83-second iterations? Maybe not, assuming you're in software development. But what if it was 83-second test-code cycles?
I'm more or less spacing out in my hotel room so I'll keep it short...
Glen Stampoultzis has done a write-up about his 6 months working in an agile shop.
Juergen Holler has posted his view on Spring, EJB 3, and the future.
Q: What's the most important feature a unit testing framework for Java needs to have in order to become mainstream?
(I'm only 27% joking, by the way...)
Congratulations to Cedric and Alexandru!
For those of you not in the know, YAUTF spells out as Yet Another Unit Testing Framework...
This time the new contender is called JTiger. The author, Tony Morris, is apparently going to publish something, perhaps including comments from Erich Gamma.
Slap! ... Slap! ... I really, really need to do something about it.
Hey Mike, how about a second installment for us lazy Java types ;)
While I'm still not using AOP at work, I keep a finger on the pulse so that I'll have at least a vague idea of what's happening that side of the fence.
The pulse just caught something I found valuable: a comparison of different approaches to weaving aspects
I recently read an article on automated tests in developing a videogame by Phlip Plumlee. This is the kind of stuff I love. Stuff that gives me insight. It kind of reminded me of that one paper session at XP2004 where Geoff Bache presented a record/replay based solution for testing a GUI application.
Here. Hats off to Scott for coming out and saying all that. The sad part is that vendors like BEA and IBM and pushing new Java developers towards a similar visual editor type of tools and approach, which I obviously don't think is a good idea (except in the sense that they might be able to sell all sorts of hot air products to their unexpecting victims).
Mike Clark just started what will hopefully become an easy to follow series of blog entries for learning Ruby. Thanks to Mike, I finally got around to installing RDT and for the first time, see the green bar in Ruby (so far, I had only used the command line while reading the book) and boy did that give me an unrealistic sense of achievement :)
Mike, please keep going!
While looking for the Eclipse plug-in for Ruby at eclipse-plugins.info, I also checked the homepages of the PyDev and PHPEclipse plugins. I'd go as far as saying that if you're still using a fancy notepad for developing in some scripting language, you might benefit from a quick looksee to what an IDE platform such as Eclipse has to offer.
Dion also reacted to Mike's blog entry by discussing his own learning tools for getting up to speed with a new programming language, namely automated tests and an interactive shell. I think the list is missing something vastly important -- code completion. I want to get up to speed as quickly as possible and I just don't think that having to browse an API website somewhere is the quickest possible way... Now if only the Ruby plug-in would have a slightly better code completion, I'd be even happier.
Once again, there's a discussion going on about whose unit testing framework is bi... I mean, better. Cedric is asking are dependent test methods really evil to which Robert Watkins replied that they're at least mildly naughty.
Dion's latest reminded me of something that came up in the Agile Finland seminar last week.
While talking about pair programming and war rooms, someone in the audience mentioned how difficult it is to get into flow and how a war room makes it difficult to concentrate and get into flow. Personally, I don't find it at all difficult but I do recognize that people differ in this regard. Here's what I have to say about the effect of a war room and pair programming on flow:
First of all, how likely is it that you'll be interrupted by someone while pairing? When I have a question in mind that doesn't require an immediate resolution and I see that that someone is busy with someone else, I don't interrupt them. In other words, seeing someone collaborating with someone else makes me consider the relative importance of that activity much more often than if that someone would be "just" typing something into his IDE. Yet, if the question is urgent, am I not correct in interrupting a less urgent task?
Second, how likely is it that you'll start reading and responding to an email when pairing with someone? Again, in order for me to do such a thing, that email has to be pretty darn urgent. Better yet, I don't even have the annoying popup in my Outlook like some have so most of the time I might not even notice that someone has sent me an email until I take a break from whatever I'm doing.
Third, if your partner gets interrupted while pairing, it really does not take 15 minutes for him to get back into your flow. With "your", I'm referring to the two of you. It's a pair thing, you know.
Finally, if these interruptions really are a pain in the ass, do something about it. Don't just bitch and complain and blame it all on the war room or pairing. Fix it. You'd be surprised to see how many things you actually can affect in your immediate surroundings if you try. Think about why all those interruptions happen and whether you could do something to decrease them. Think about having periods of quiet time to create a rhythm for your team. Think about buying stuff. Think effectively.
In our series of wacky things to do with your spare time...
Take the quiz: "Which American City Are You?"
New York
You're competative, you like to take it straight to the fight. You gotta have it all or die trying.
I blame The Vision Thing for making me jump on this sort of wacky thing:
1. Grab the nearest book.
2. Open the book to page 123.
3. Find the fifth sentence.
4. Post the text of the sentence in your journal along with these instructions.
5. Don't search around and look for the "coolest" book you can find. Do what's actually next to you.
Ok. The book closest to me when reading that blog entry was Kent Beck's Test-Driven Development: By Example (Honest! I didn't go looking for a cool agile book from the bookshelf...) and the 5th sentence on page 123 says:
How do we choose what data to test?
Wow. That's a tough question. How do we choose what data to test with? I suppose there is no globally correct answer (there hardly ever is), but my suggestion would be simple data. If the test data is difficult to understand, the test implicitly becomes difficult to understand. If the test is not about handling special characters, don't use special characters in the data. If you're not testing an edge case, don't use a single character string or a zero-length string.
Test one thing and test it properly.
-- me
Do you have any rules of thumb of your own for selecting test data for programmer tests?
Finally, I've gotten some of those photos I took online. I don't have an exact count, but it looked like we had well over 80 attendants!
The event started with a talk by Pekka Abrahamsson from VTT...


...and continued with a more XP-focused talk by Peter Schrier of Exoftware...


...and I also noticed that Juha from Tecnomen took a shot of me doing the compulsory introductions as well:

Regarding the relatively high level of the talks, that has actually been an important aspect of the whole Agile Seminar concept -- each seminar having at least one introductory level talk for those new to agile methods.
I'd also love to listen to other people talk about their experiences in more detail. If you've got a story to tell, please contact me or express your interest on the mailing list (it's coming soon, I promise...) so that the rest of us can listen to what you've got to say in the next "Agilists Anonymous" meeting ;)
PS If you've got photos of the event (especially of Pekka's video!!!), I'd love to get a copy...
Congratulations to David Anderson for the Best Project Management Blog of 2005!
J.B.'s latest blog entry reminds me of how TDD has killed my courage.
(No, I don't think your tests can be too fast. Made you look, though;)
Clarke Ching blogs about the legendary Hawthorne effect being a flawed theory.
Without commenting on the argument of the theory being flawed, I'd like to draw attention to something in Rice's article:
Proponents of the Hawthorne effect say that people who are singled out for a study of any kind may improve their performance or behavior not because of any specific condition being tested, but simply because of all the attention they receive.
...
For example, unlike the big open floor of the relay-assembly department, the test room was separate, smaller, and quieter, with better lighting and ventilation. And the supervisors were friendly, tolerant observers, not the usual authoritarian foremen. Any or all of these factors may have contributed to the improved performance.
While it is obvious that improved working conditions can and probably will affect performance, I strongly feel that we cannot dismiss the importance of attention. Walking around a cube farm at pretty much any client site, one typically sees more people browsing CNN.com than people doing actual work. Would that be the case if everyone had constant attention? Of course not. Would it be good to have constant attention all the time? I don't think so. Perhaps most of the time, though, assuming the attention is of the right kind.
And it's not about preventing people from reading CNN. It's about creating an environment which accelerates productivity through collaboration and interaction.
I just checked what Google says about our upcoming Agile Finland seminar and found that ITviikko and Digitoday weren't the only medias writing about the event:
Tietoviikko published something, LearningBusiness.fi wrote about the seminar, NetProfile (who handled the press release) posted the press release on their site, TietoYhteiskunta.fi posted more stuff, and the Prosessori magazine had added the seminar to their event calendar.
I love Jonathan Kohl's blog more and more every day. Check it out. Lots of very thoughtful posts. Unlike my blog, for which I owe you an apology. There's a lot happening in my life right now--hopefully I'll be able to blog about some of those things in the near future...
I haven't read a book on PHP in ages. In fact, I haven't programmed in PHP since 2001. With this in mind, I can say that Matt Zandstra's "PHP 5 Objects, Patterns, and Practice" was a very approachable introduction to what the latest version of the PHP platform has to offer to an OO developer from the Java scene.
The book is split to three main sections: objects, patterns, practice. The first section runs through the new object-oriented features of PHP 5, the second sections introduces design patterns and includes a catalog of some of the more common patterns from the original Gang of Four patterns as well as from "Core J2EE Patterns". The third section is a set of tutorials on tools and assets that a modern day PHP developer really should know about and make use of: the PEAR installation tool, PhpDocumentor, and the Phing build tool. The author also squeezed in a bit about the PHPUnit2 library for unit testing PHP code which I especially appreciated.
The design patterns catalog is far from comprehensive, covering only a small subset of published design patterns in the Java/.NET camps, but serves its purpose alright. Every included pattern is illustrated with an example that the author has crafted for the PHP context – in other words, these are not just direct ports from their Java equivalents, for example.
While being an easy read, Zandstra's introduction to the object-oriented features is, I believe, perfectly adequate to get started with object-oriented PHP programming. Combined with the discussion about design patterns, the book feels like a valuable asset for getting up to speed after a break. A more up-to-date PHP developer might find the information a bit lacking but for someone new to PHP 5's object-oriented features, this is a good package to get started with.
This review was posted at Amazon.com with 4 stars and will be soon posted at JavaRanch.com with a rating of 8 out of 10 horseshoes.
There's been a bit of a rush of books about the Spring Framework recently with a number of publishers releasing their own titles one after another. Without having read those other books, I feel confident in saying "Spring in Action" won't let you down. It's a wonderful introduction to the framework and a handy reference for those desperate moments with the Spring configuration files.
What I especially like about "Spring in Action" is the style of writing. The book is largely about how to configure this and that and still I read most of the book in one sitting. The text flows well and the humor sprinkled throughout adds a nice touch. The other good things about this book include a good coverage of the Spring Framework itself. Only some parts of the Acegi security framework have been left out, as far as I can tell, and those features (ACL's and run-as) are not what I'd call essential so it didn't bother me much. In addition, the authors give a good comparison (brief, but a good overview) of Spring and other technologies and frameworks such as EJB, Struts, WebWork, Tapestry, PicoContainer, HiveMind, etc. Furthermore, the authors show you how to integrate with these other frameworks (except for the other IoC containers) and view technologies like JSP, JSF, Velocity and FreeMarker. Add to that, the index looks very comprehensive which is an important detail for a book that one might use as a reference afterwards.
So, what separates this book from perfection? For one it had a lot of little typos, the text did exhibit a bit of repeat (didn't I just read this sentence on the previous page?) here and there, and I feel like mixing multiple ViewResolvers was covered too lightly. I don't consider these to be big issues, though, and I won't hesitate for a second in recommending "Spring in Action" for someone looking to get started with the framework.
This review was posted at Amazon.com with a full 5 stars and will be soon posted at JavaRanch.com with a rating of 9 out of 10 horseshoes.
Paraphrasing Carl Schweppe in the XP Yahoo! group:
Agile software development is about
forcing the customer to make choices
and giving her the means to make them.
Cool bananas! The upcoming Agile Finland seminar got even more press than the article on last week's issue of ITviikko. First they published this in Digitoday, one of Finland's biggest IT online news providers, and then this.
By the way, we've already got almost a full house! I'm definitely looking forward to seeing all the new faces next Thursday!
I was recently interviewed by ITviikko for an article on agile software development "rushing to mainstream" (a bit of an exaggeration, but that goes with the territory, I guess). The article was published in today's issue. It had a ridiculous amount of typos etc. but at least the upcoming Agile Finland seminar got highlighted :)
Not yet, but should be within 6 months. Needless to say, I'm expecting the book to be a pretty darn good read, having enjoyed a bunch of other recent pragmatic titles (Mike Clark's automation book is a classic, the Ruby book is the definitive source for any Ruby freak, and the CVS book is delightfully light and focused).
Now if only I could get my hosting provider support Rails... You see, I've got a vacant parking space to fill.
If you're suffering from Workshopitis, here's at least some relief for your poor soul:
Integrating CruiseControl With WebLogic Workshop Applications
Spotted in Andy Pols' blog:
Continuing on the theme of breaking the self imposed rules, I heard a wonderful story about a team working in an environment that involved a customer requirement to provide an audit trail of all project design decisions.
This was a real rule.
Many teams would interpret this as a requirement to have lots of heavy documentation and associated traceability. This would have been a self imposed rule.
This team solved the requirement in a wonderfully low energy way. They simply attached a long roll of brown butcher’s paper around the room. Whenever people on the team made a decision, they made a note of it on the paper, dated it and signed it. This acted as a short term information radiator of team decisions. Once it was full, they rolled it up, marked it with the date range and filled in it the corner of the room.
The auditor loved it as it was quick and easy to see what was happening over time.
The Vision Thing and Software As She's Developed so far represent the majority of my experience with podcasts. I have to ask, what's with the corny intros and loud music? Otherwise, I love being able to "just listen" while cooking or otherwise spacing out a bit.
Well, despite the corny intros and loud music in the beginning, I really digged this podcast on project management with Hal Macomber, Johanna Rothman and Clarke Ching.








