Finally Found

Sometimes it is difficult to find the location of opensource software. It is not always available where you would look for it. I have been looking for the source code location of Adept for a while now (well, I haven’t wanted it so badly that I was willing to install Ubuntu.) Currently the only source copies are in KDE svn. Get adept from anonomous KDE svn this way:

svn co svn://anonsvn.kde.org/trunk/playground/sysadmin/adept

Software Development
and Project Success

When I was growing up our family’s resources were less extensive than they are now, and as such, we sometimes had to do without some perks. One of these perks was a complete set of tools for home/car repair. Simple fixes like changing a battery would result in hours of work because of the inherit limitations of our tools; which ostensibly consisted of a hammer and a butter knife. Whenever I was brushing off the latest “injury” incurred while fixing something, my father would say to me, “Everything is simple if you have the right tool.” The better the tool is at doing a specific task, the easier it will be to complete that task. Ever watched “This Old House?” They had a tool to do everything! I didn’t even know they made adjustable-corner-rounded-cut-circular-door-saws with the optional digital level… cordless, if you are lucky. Heck, if I had a shop with 30 million dollars worth of specialized equipment, I bet even I could make something as fundamentally complex as a bar stool.

“Everything is simple if you have the right tool.”

This maxim (while not always true) is amazingly accurate in describing the modern development process. In fact, this is the reason I work on KDE (as opposed to the “other” Linux desktop environment.) Things are simply easier to do, are more productive, and more functional because the tool is designed better and focused specifically on desktop software development.

Today I ran into a series of articles by some application developers who I have come to respect. Their insight into the software development process will hopefully help give me some direction on future project management. Here they are will some selected quotes that stand out:

The strongest indication of a weak team is the realization that if you were to quit and start your own business, you wouldn’t try to poach any of your colleagues.

“Strong teams have almost impossibly high hiring standards. Strong teams will always leave a desk empty rather than settling for less than the best.”

“Examples of development hygiene include source code versioning, maintenance of an accurate bug or issue database, significant use of automated testing, continuous integration, and specifications that are kept current (whether incredibly detailed or high-level overviews).”

“A chicken is an individual who has significant authority over your project, but does not make a personal commitment to the success of the project.”

“And every time I’ve delivered software on schedule milestone after milestone, my influence and standing with stakeholders has grown. And every time I’ve missed a date, I’ve suffered, regardless of whether the late software was demonstrably better than what was originally planned for the missed date.”

“Documents such as specifications yield the same benefits of source control.”

“Discard all processes that are mechanically completed with little actual benefit. Tweak those that require more effort than necessary, maximizing the results while minimizing the effort.”

KDE: Shared vs Open

Shared specifications and shared standards are an admirable goal as long as the “standards” are not acting as limitations to the advancement of a given technology. This was the problem that KDE ran into with the use of Corba. It was a open and shared standard used by KDE (and Gnome) in its early development. But we quickly discovered that it became a nightmare to manage/extend to the more advanced uses that we wanted to see KDE move towards. The decision was made (and lots of “shared standard” developers SCREAMED about the change) to switch to a custom KDE specification now known as KParts. History has shown that decision to use KParts was the correct one, as KDE would NOT have progressed to the level it has using Corba.

As long as the standard is good for KDE development and advances our ability to provide application solutions to users (and developers) then I am all for shared standards. But the moment those standards hold back KDE development in the interest of some “perceived” value from shared specifications. We can all agree on standards up until those standards have the net result of holding-back all of our development efforts equally.

Think of specifications as food for software. Good standards will help you (or your software project) grow strong and healthy. Bad standards will make your application bloated, lethargic, and will eventually be the cause of most of your application “sickness.” Standards are NOT more important than the applications (arguably they are part of the application, but a part is seldom more important than the whole.) Because they are NOT more important than the applications themselves, comments like this verge on being insulting.

The fact that KDE gets appreciated this much and that KDE is the market leader in UNIX and Linux desktops today is negligible compared to the extremely important effort to create a single specification of the free desktop environment.

Also, I think too many people get shared specifications confused with open specifications. KDE (and Gnome for that matter) will ALWAYS have open specifications because of the very nature of F/OSS. Open standards are very very important, shared standards are less important. One could argue that Microsoft DOC format is a shared standard because just about every office package in existence tries to write and save to it. That doesn’t make it an open standard.

No Title Today

I have not been in the mood to blog lately. I am not entirely sure why, but it may have something to do with just being burnt out. In spite of how I feel I must get these links up. That said, I have been scanning news feeds for articles about Linux authentication mechanisms. Linux (via PAM) has the uncanny ability to authenticate to everything from a Windows AD network to SSL shared keys. I am fairly sure it would even be possible to get PAM to use the current state of my toaster oven to validate a user. Of greatest interest to me is, getting Linux to use use LDAP for network authentication. As such we have todays links.

Hopefully I will be back to my full blogging glory after this weekend. Lots has been happening in the world, in my life, and in my home; but until I get out of this slump my body just keeps saying “NO blogging today!”

KExtProcess: Part 1

kconfigure, my KDE build management tool, uses KProcess for its handling of automake, qmake, and checkinstall functionality. It does this because fundamentally these tools are command-line driven tools without a library interface for C++ to work with. The problem with KProcess is that, while it is probably the most powerful command-line processing library available, it is still very limited. Evidently I am not the only one with this problem as Martijn Klingens has released his updated KProcess-like tool KExtProcess.

The beauty of KExtProcess is that it not only handles command-line communication processing (i.e. STDIN, STDOUT, STDERR, etc..) but that it is network transparent. It also supports the concept of “profiles” that allow you to string together commands into a single “profile” that is loaded before the process is started. This allows things like: ssh’ing from one machine, to another, to a third before running a command locally on that third machine; or remotely accessing a machine as a one user, and then su’ing to root before beginning your process as root. While KExtProcess is still in its early stages, it will, no doubt, quickly achieve its place alongside KIO and DCOP as one of the powerful *nix desktop technologies in existence.

HOWTO: unsermake

unsermake is a replacement build tool for KDE. Some of unsermakes advanced features are multi system compile support, simplified makefile syntax (using KDE’s custom Makefile.am files), build progress indicators, full Qt moc file support, cleaner build output and much faster build times.