Talking to him, he seemed very passionate to reinvigorate Zope through Grok. I must say I think both Zope 3 and Grok are quantum leaps forward compared to Zope 2.x, and I’m sure they’ll pick up more developers over time. It’s going to take some time for me, though, who got pretty burnt by the Zope/ZODB combination, to give it another try again. And I don’t think I’ll ever trust a database that doesn’t explicitly enforce a schema; it’s just a recipe for maintenance hell.
Archive for the 'Python' Category
This is of course pretty controversial stuff, and in all honesty, Arlo only has his own data and the feedback of 6 teams that tried it as supporting evidence that it works. Of the 6 teams, all had productivity boosts. 4 teams continued, 2 stopped. The reasons why they stopped was interesting, though: they liked specializations, and were happy with slightly less productivity.
The final practice Arlo described was team-owned tasks. Avoiding assigning tasks to people is very important to encourage team responsibility, which leads to team accountability, which is a necessary requisite to building strong self-organizing teams.
Another question they had was:
- Who should do which tasks?
The normal approach is to put the most qualified implementor on a task. Naturally, that should ensure the task got done faster and better, right? Well, just to see how it worked, they once tried the exact opposite: putting the least qualified implementor on a task. Again, what they found was astonishing.
Arlo’s team wanted to be extreme, and they started with one of the XP practices, pair programming. Going extreme meant that they would pair program all the time. No code produced by a single person was allowed to be checked into the repository.
But, pair programming is also a pretty new and relatively undefined practice. There were still a lot of questions open, among them:
How long should each pairing session last?
The most interesting and eye-opening talks at EuroPython 2007 were probably Arlo Belshee’s talks on agile methodologies and his team’s experiments and results in that regard. The following blog posts summarizes what I learned from listening to his talks, doing his XP workshop, discussions with him, and digging up related information on the web (such as a paper and a podcast). I strongly believe this could be the next phase in how we develop software, and I hope I’ll be able to whet your aptetite for change as well
Some cool REST links I’ve come across lately:
- Implementing the DayTrader example application using a RESTful interface shows how even a bit more complex applications can use REST.
- ITC has a RESTful Web Services podcast where Jon Udell talks with Leonard Richardson and Sam Ruby about their new book. They even discuss some things like doing transactions with REST.
A while ago I discovered that by setting an HTML
type attribute to
search, Safari on OS X would show the OS X search widget instead of the standard boring HTML input field. Andrew Escobar has a good introduction and an example screenshot:
This search widget is extremely user-friendly and space-efficient; there is no need for a “Go” or “Search” button anymore.
It also downgrades gracefully to a normal input field for other browsers, but this is unfortunately not enough:
- There’s no placeholder text explaining what you can search for
- There’s no magnifying glass or special styling giving a hint that this is a search box
Taken together it means you have to add explanatory text and a “Search” submit button after it for people to understand how to use it, destroying the user-friendliness and space efficiency and offered by the Safari widget.
I decided to do some reverse engineering…
I caught this very interesting announcement on the Django Developer group:
I like Django, and my unique experience having grown up in a fishing village should make the ideal candidate! If it wasn’t for the fact that I hate cod…
I wasn’t expecting to see Google go so far as to branch into seafood. No industry is safe anymore…