I have been running the test and merge process for DrizzleDB using Jenkins.
Jenkins is a pretty standard Java-based web app. The configuration settings are stored in XML files, and that configuration is manipulated using an "easy to use" Web GUI.
The "old skool" UNIX-like way to keep configuration settings is in a text file, which is edited with an ordinary text editor, and is read by the program daemon on start or SIGHUP. This is considered "scary", "hard to learn", and "hard to use" by novices.
There is a big problem with GUI-only managed configuration, an issue where text file configuration has a major advantage.
I did not set up the Jenkins server or nodes. I am not the only person with admin access to it. Several other people have set it up, set up various projects in it, and added new nodes and new types of nodes.
As I work on it and look at the existing configuration, I often find things that are "surprising", things that make me say "Is that right? That can't be right? Can it?". And then I have to spend time digging into it. Sometimes it IS right, for reasons I didn't know at that moment. Sometimes it used to be right, but isn't necessary any more. And sometimes, it just wasn't right.
In a textual configuration file, you can put comments. The purpose of a comment is to communicate into the future, to tell those who came after you (including your future self) what you were intending to do, and why you selected some "surprising" option or way of doing things.
There is no good way to put comments into GUI or WebGUI configuration, even if it has a freeform field labelled "comments".
Update, this post is being discussed at Reddit.
Update, this post is being discussed at Forrst Podcast ep 122.
2011-06-14
"everyone had something valuable to contribute"
I'm reading the July 2011 issue of "Linux Journal", and in "Upfront, diff -u" there is some text that is worth noting and repeating:
It is maybe an excess of hope to say it "dominates the world".
There is still entirely too much "fauxpen source" software, where corporate dev teams or small mentally incestuous groups emit "releases", while sitting behind legal and social barriers to outside contribution and feedback. The tightly coupled development process results in tightly coupled and poorly documented software, which is hard for "outsiders" to contribute to, and the resulting feedback loop spins around until the software is so knotted up that useful development basically stops. (Of course, closed source software has the same problem, only worse.)
The open development open community model does avoid this problem, and so it's use is spreading.
This is actually one of the first and greatest innovations Linus Torvalds achieved with Linux. While the GNU folks developed the idea of free software, they limited themselves by sticking with a just a tight group of core developers, who largely would ignore suggestions and patches from outside. It was Linus' belief that everyone had something valuable to contribute that led the style of open-source development that now dominates the world.
It is maybe an excess of hope to say it "dominates the world".
There is still entirely too much "fauxpen source" software, where corporate dev teams or small mentally incestuous groups emit "releases", while sitting behind legal and social barriers to outside contribution and feedback. The tightly coupled development process results in tightly coupled and poorly documented software, which is hard for "outsiders" to contribute to, and the resulting feedback loop spins around until the software is so knotted up that useful development basically stops. (Of course, closed source software has the same problem, only worse.)
The open development open community model does avoid this problem, and so it's use is spreading.
2011-06-08
Android & iPhone, regarding Twitter.
One new "feature" of the next release of Apple iOS is the integration with Twitter. To get these features, Apple Inc and Twitter Inc had to "partner".
Twitter has been just as "integrated" with Android for quite some time. And all Twitter Inc had to do was write an app, that used the standard Android API hooks.
In fact, my own Android phone doesn't even use the "official" Twitter app (which I find to be slow, heavy, and poorly done), it uses an even better and more advanced one called twicca. And the author of Twicca didn't need to "partner" with either Twitter Inc or Google Inc. He just wrote a better app, that again just used the public APIs.
It doesn't take a high-level corporate partnership, a 12 month product roadmap, and a heavyweight development cycle by employees of a set of large companies to add a deep and useful integrated feature to Android. It takes a single developer working in a cafe.
Twitter has been just as "integrated" with Android for quite some time. And all Twitter Inc had to do was write an app, that used the standard Android API hooks.
In fact, my own Android phone doesn't even use the "official" Twitter app (which I find to be slow, heavy, and poorly done), it uses an even better and more advanced one called twicca. And the author of Twicca didn't need to "partner" with either Twitter Inc or Google Inc. He just wrote a better app, that again just used the public APIs.
It doesn't take a high-level corporate partnership, a 12 month product roadmap, and a heavyweight development cycle by employees of a set of large companies to add a deep and useful integrated feature to Android. It takes a single developer working in a cafe.
Subscribe to:
Posts (Atom)
