After investigating several possibilities (raw DHTML, Backbase...), I have finally opted for Chiba as the presentation engine for jinFORM, my attempt to port MS InfoPath 2003 forms on the web.
Chiba is a cool XForms 1.0 SE implementation that runs on J2EE servers. I investigated it when I started jinFORM last year, but at this time, all actions where bound HTML form post actions, leading to a less than comfortable UI.
The new version, currently in release candidate, is fully AJAX driven, which not only makes it buzz-word compliant, but also dramatically improves the user experience.
Despite several little bugs, the InfoPath forms transformed into XForms and rendered by Chiba are more than usable. So far, the most annoying thing in Chiba is the direct dependency to Log4j: using Commons-Logging would have made it more friendly with the different deployment situations.
I will wave a flag when the first alpha release of jinFORM will be out there.
Friday, February 24, 2006
Friday, February 17, 2006
The Mystique of Software Craftsmanship, Part 3
[Previous Part]
Third Discipline : Let it flow
The lessons learned in other sectors of the industry can also be beneficial when applied to the IT field. The example that immediately comes to mind is the the invaluable contribution from Tom and Mary Poppendieck in applying lean principles to software development.
It is evident that there is still a lot to learn from other organizations: take for example the latest discoveries of the Mind/Body Institute that Herbert Benson has recently presented in Harvard Business Review (November 2005). Benson describes the mechanisms involved into reaching what he calls a “break-out”, a mental state that we call “flow” in the software development industry. Knowing that reaching this state is intimately linked to producing high quality software and that “it takes about 20 minutes to reach the internal state of flow, and only a minute to lose it” (as Alistair Cockburn stated it), we can consider these findings as essential for our business.
Benson describes a four-state cycle: stress, walk-away, flow and back to normal: mastering this cycle could allow anyone of us to reach our optimal productive state at will. The surprising aspect of this cycle is the importance that stress plays in reaching the break-out: voluntarily creating this stress is a critical aspect of being able to trigger the state of flow. Everyone will have a different way to raise its stress level: the important thing is to discover what is our own.
For example, one will naturally procrastinate until the deadline gets short, then, after a short pause, the break-out happens and she will deliver on schedule a better piece of code than if she has spent twice the time on it.
Being aware and able to control this internal mechanism is the kind of proper exercise that we should consider, not only to be more efficient but to ultimately harvest self-satisfaction in what we do.
Third Discipline : Let it flow
The lessons learned in other sectors of the industry can also be beneficial when applied to the IT field. The example that immediately comes to mind is the the invaluable contribution from Tom and Mary Poppendieck in applying lean principles to software development.
It is evident that there is still a lot to learn from other organizations: take for example the latest discoveries of the Mind/Body Institute that Herbert Benson has recently presented in Harvard Business Review (November 2005). Benson describes the mechanisms involved into reaching what he calls a “break-out”, a mental state that we call “flow” in the software development industry. Knowing that reaching this state is intimately linked to producing high quality software and that “it takes about 20 minutes to reach the internal state of flow, and only a minute to lose it” (as Alistair Cockburn stated it), we can consider these findings as essential for our business.
Benson describes a four-state cycle: stress, walk-away, flow and back to normal: mastering this cycle could allow anyone of us to reach our optimal productive state at will. The surprising aspect of this cycle is the importance that stress plays in reaching the break-out: voluntarily creating this stress is a critical aspect of being able to trigger the state of flow. Everyone will have a different way to raise its stress level: the important thing is to discover what is our own.
For example, one will naturally procrastinate until the deadline gets short, then, after a short pause, the break-out happens and she will deliver on schedule a better piece of code than if she has spent twice the time on it.
Being aware and able to control this internal mechanism is the kind of proper exercise that we should consider, not only to be more efficient but to ultimately harvest self-satisfaction in what we do.
Wednesday, February 08, 2006
YAGNI In The Sky (Quote of the day)
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."
Antoine de Saint-Exupery
Thursday, February 02, 2006
The Mystique of Software Craftsmanship, Part 2
[Previous part]
Second Discipline : Be a Hero
We know that learning is mainly based on imitation and imitation can only happen when we are exposed to valuable models. These models constitute the good food our brains need. Either by reading books or attending conferences, we feed us with the result of years, if not decade, of experience and reflection in a few hours. These models, when incarnated in human beings, become the league of heroes we should desire to join.
What, in the case of software craftsmanship, could it mean to be a hero. How in our field of activity, could we exercise valiance, courage and wit? Here are some suggestions:
While pursuing this quest for software craftsmanship heroism, let us not aim the wrong goals. Though they might be reached in the journey, this is not glory and fame that we are seeking: we are looking for doing the right thing at the right time, and that will be heroic enough.
Second Discipline : Be a Hero
We know that learning is mainly based on imitation and imitation can only happen when we are exposed to valuable models. These models constitute the good food our brains need. Either by reading books or attending conferences, we feed us with the result of years, if not decade, of experience and reflection in a few hours. These models, when incarnated in human beings, become the league of heroes we should desire to join.
What, in the case of software craftsmanship, could it mean to be a hero. How in our field of activity, could we exercise valiance, courage and wit? Here are some suggestions:
- let us be a hero for our clients: they are the prime reason we wake up in the morning and the true motivation of our professional endeavors, so we must embrace their cause and deliver the best value possible, even on the things we build but they do not see,
- let us be valiant for always walking the extra mile: when the little bell that warns us of a potentially crappy line of code start ringing in our head, we should not turn our back on it but refactor as soon as possible, and, if we are too tired to solve the issue right away, at the very least we should comment the risks or doubts so nothing remains in the shadows,
- let us do supernatural things like: stealing the overhead projector of your favorite salesperson, plugging it into your workstation to explore interactive programming or design sessions with your peers ; hacking an AmbientDevice to display your test coverage status or the time left before the next release ; training a RoboSapien to pick-up the phone when you do not want to be disturbed by your favorite salesperson (looking for his OHP)...
While pursuing this quest for software craftsmanship heroism, let us not aim the wrong goals. Though they might be reached in the journey, this is not glory and fame that we are seeking: we are looking for doing the right thing at the right time, and that will be heroic enough.
Subscribe to:
Posts (Atom)