December 17th, 2008 by Mark Ramm
I’ve been very, very busy trying to get TurboGears 2 beta 1 ready to go, as well as a few other interesting projects, and had neglected to blog about a ArbCamp before, then it was sold-out, and I didn’t blog about it because I didn’t want to raise people’s hopes only to have then dashed upon the rocks. But, we’ve secured a new venue, so ArbCamp registration is now Un-Sold-Out. It’s UnSold because it’s free, and it’s un-Sold-Out because we can now fit everybody in. We had over 160 people registered and on the wait-list, but could only let 100 people in. Now we have space for 200, so those on the wait-list and those who didn’t sign up in time have a second chance.
ArbCamp will be tomorrow night, in the upstairs of the downtown Cottage Inn’s, so this is kind of last minute, but I think it’ll be a very cool event. It’s an UnConference, and people will be self-organizing a variety of sessions, and the possibilities are endless.
January 17th, 2008 by Mark Ramm
Apparently Sun thinks MySQL is worth a billion dollars. I still prefer PostgreSQL, but unfortunately I don’t have a billion dollars lying around, either.
Good thing they are both open source!!
September 24th, 2006 by Mark Ramm
On September 29th (this Saturday), I’ll be at the OhioLinuxFest, hanging out at the Spliced Networks booth talking about TurboGears, the TurboGears book, and Spliced Networks “app stack” for TurboGears deployment.
If anybody wants to get together for lunch/dinner to talk about TurboGears, Python, or web development feel free to drop by the booth, and we’ll set a time and place. You can also leave a comment here, or e-mail me (my address is my first name at compoundthinking.com).
November 30th, 2005 by Mark Ramm
Over on Planet Turbogears, I found this comparison between two of my favorite things. Roland calls Turbogears “The Ubuntu of webframeworks =)” because both bring together existing components and add a little bit of their own special sause to create the best possible total user experience.
I love it!
November 16th, 2005 by Mark Ramm
There are a lot of people hacking on the Linux kernel all around the world. And while they mostly work on this or that sub-system, there are a lot of cross-cutting concerns. Not only that t there are any number of people working on cleaning up old kruft, so you’d expect that they would either need to be very well coordinated, or they would have a lot of patch related pain.
But they don’t!
This is the result of the widespread use of a distributed version control system, where every single linux developer can publish their own source tree, and cherry pick patches from anybody else’s source tree. This, when combined with a set of maintainers — who get patches, aprove them and put them in their own trees and then work with Linus to get them moved into the “official tree” — creates a remarkably effective system.
For people who want to transfer ideas from Toyota’s Product Development success into software development distributed revision control is an all important tool. But unless you let go of your fear of duplication of effort, you’ll never see the full value of Bazzar–NG.
The key to Set Based Development as practiced by Toyta and Honday is the ability to break down your product into different components, with various interfaces. Then you develop the various components concurrently, and work on several approaches to each of the components simultaneously. As you move forward toward product release, you have a series of integration events, where the interfaces between components are defined more and more concretely.
Other critical components for making set based development work are:
- clear documentation of the design decisions for the various approaches for each components — even those not used in the final product
- a single technical lead who can focusing the vision for the entire product when selecting from among the various alternatives
If you do set based development right, you will always have a safe bet, and you’ll almost always have one or two experimental pieces that turn out great — even if they don’t turn out to be a good fit for the specific product you are working on right now.
But this only works if you can leverage tools like Bazaar-NG to make sharing patch sets easy, and make branching and merging custom development trees painless. Of course, no tool is going to take away the need to document trade-off curves, or make good technical choices for you or your distribution team. But distributed version control tools should make it easier to have lots of choices, and easy to find the right ones for your project and fit them into your product.