Digested

Holidays would be incomplete and unsatisfying if we couldn't find a good book store.

I read Lance Armstrong's book It's Not About the Bike: My Journey Back to Life. The descriptions of the Tour de France were very interesting. Winning 6 of these races can't be a fluke, and we read of his almost fanatical dedication to the sport. The descriptions of the races are fascinating. We think of a bike race as an individual effort; it is a team effort with a group working together so that one person can claim victory. Reading his story puts many of the obstacles and discomforts of my life in perspective.

I'm fascinated by military history, and enjoyed Operatives, Spies, and Saboteurs : The Unknown Story of the Men and Women of World War II's OSS. The book is from the american perspective, interviewing surviving members of that service. The war had an enormous impact in so many ways. The nastiness of insurgency and special operation warfare, with small groups taking advantage of local partisan movements, the shifting allegiances, makes for a fascinating read. Many times the stories revolve around civilians either protecting and hiding, or finding and reporting the operatives. I and many of my generation have never experienced war. It is good to read of the damage done to societies when faced with conflict, and how there is no possible way to stay innocent if involved.

I finally finished Uncle Tungsten, Oliver Sacks' autobiography. For some reason I read about half, then put it down. Reading about the structure of the atom, of electrons, radioactivity and his fascination when exploring these things as a young boy reminds me of when I learned these things. My high school chemistry teacher had the ability to instill wonder when describing the structure of the atom. Sometimes when we learn things the result is not understanding but a flood of questions and possibilities.

I was pondering the times in my life when I had that feeling of setting out on a journey of discovery. In the late 80's I was interested in computers, read computer magazines but wasn't in the position to purchase one. A friend had an Apple IIe that he lent to me. I had some weird infection, so I was home for a week or two. Between sleeping off the fever, I worked through a book on Pascal. The sense of possibilities, the intellectual challenge, the joy of accomplishment. Since then I've always had a programming project on the go. When my friends were learning the intricacies of the drawing and graphic programs, I was exploring assembly language.

Holidays would be incomplete and unsatisfying if we couldn't find a good book store.

I read Lance Armstrong's book It's Not About the Bike: My Journey Back to Life. The descriptions of the Tour de France were very interesting. Winning 6 of these races can't be a fluke, and we read of his almost fanatical dedication to the sport. The descriptions of the races are fascinating. We think of a bike race as an individual effort; it is a team effort with a group working together so that one person can claim victory. Reading his story puts many of the obstacles and discomforts of my life in perspective.

I'm fascinated by military history, and enjoyed Operatives, Spies, and Saboteurs : The Unknown Story of the Men and Women of World War II's OSS. The book is from the american perspective, interviewing surviving members of that service. The war had an enormous impact in so many ways. The nastiness of insurgency and special operation warfare, with small groups taking advantage of local partisan movements, the shifting allegiances, makes for a fascinating read. Many times the stories revolve around civilians either protecting and hiding, or finding and reporting the operatives. I and many of my generation have never experienced war. It is good to read of the damage done to societies when faced with conflict, and how there is no possible way to stay innocent if involved.

I finally finished Uncle Tungsten, Oliver Sacks' autobiography. For some reason I read about half, then put it down. Reading about the structure of the atom, of electrons, radioactivity and his fascination when exploring these things as a young boy reminds me of when I learned these things. My high school chemistry teacher had the ability to instill wonder when describing the structure of the atom. Sometimes when we learn things the result is not understanding but a flood of questions and possibilities.

I was pondering the times in my life when I had that feeling of setting out on a journey of discovery. In the late 80's I was interested in computers, read computer magazines but wasn't in the position to purchase one. A friend had an Apple IIe that he lent to me. I had some weird infection, so I was home for a week or two. Between sleeping off the fever, I worked through a book on Pascal. The sense of possibilities, the intellectual challenge, the joy of accomplishment. Since then I've always had a programming project on the go. When my friends were learning the intricacies of the drawing and graphic programs, I was exploring assembly language.

The KDE community is as healthy and active as I've ever seen it. Vibrant sub communities, such as artists, usability people and others are providing substantial contributions to the project. The sub projects such as kde-edu, KOffice and others are lively, attracting developers. Everyone seems to be having fun. I know I am.

So what has KDE done right? This is what I see:

The legal organisation does what they are best at: organize conferences.

Long standing core developers are employed by companies that benefit from KDE.

The repository is open. It is very easy to get write access to the repository. The systems are in place so that experienced developers can watch what goes in, but nonetheless, to become a contributor is easy.

Sharing the repository creates a ready 'market' for well designed libraries and services. The libraries and services get use and testing. KDE as a rather large package provides a test environment for users. The feedback loop isn't 'corrupted' by outside packages and dependencies that swallow time and resources better used in fixing KDE issues.

No single point of failure. How many experienced release dudes are there? The very loose structures seem to come together when needed, and allow motivated individuals to fill the needs as they see fit.

Biannual releases grows the userbase, keeps KDE in the limelight and attracts new developers.

What do you think? Much of the work is unpaid. Something is keeping us all interested and motivated. What is it?

Other than a few minor issues, the code to generate the Digest from Subversion is done. But in my opinion the layout and look sucks. I can say that freely because I designed it. Obviously some artistic talent is needed to design a new layout. This is a request for assistance to that end.

The design parameters for the project are:

No hand editing. A script will generate the html from data sources, and the design needs to take into consideration the variation that occurs in the commit logs, and other sources of data.

The content is dynamic. The number of entries, the number of types and categories may and do change from week to week.

The digest is read from top to bottom or in sections by a good number of people. The purpose of the design is to allow comfortable and pleasant reading of a lengthy technical report.

Preferably the graphical elements would be easy on the server. Outside of these basic requirements, the field is wide open.

The most challenging parts are the table of contents and the layout of the commit log with all it's attendant data.

If you would like to help, send me an email. Your name and picture will be prominently displayed in gratitude. The code is available in the kde svn repository in trunk/www/areas/cvs-digest/enzyme. I can do the required coding, I need help with the design.

I will be posting this request on www.kde-artists.org.

I'll be away next week, so there won't be a Digest on the 17th of June. A well deserved time off. Is it a good or bad sign when your boss remarks that finally you are taking some time off?

Had a brainwave today while scrolling through the kde-commit emails. I look for bug numbers (among other things) and try to avoid the revision numbers sometimes referred to. Why not link to the revision when a developer refers to it in the commit log? Now the challenge of creating a regex to differentiate between the two.

Frameworks work.

Let me explain. I've been using a Palm handheld for a number of years. Mostly for keeping track of the multitude of details at work. Part numbers, contact information, the innumerable details that make up my day. Without the palm, I would fill up a pocket booklet in about a month, with all the recall issues that come with paper. When I first started using the Palm, the built in software seemed inadequate; I wrote my own application that tracked all the stuff I needed.

The problem with rolling your own is the maintenance and side issues that require time. Palm has changed processors and many other things that my app requires. I never got around to writing a hotsync for it, so the data never strayed from the handheld except as a binary backup.

And more importantly, I never was able to see any usefulness of the KDE PIM tools, which today make up Kontact. My older Palm started losing it's mind, so I purchased a Tungsten E. I started using the built in Palm applications to track the days details, and magically they appear on my desktop. Every morning I do a hotsync, then drag stuff around or edit as necessary. I have actually started using Kontact.

Since I have the summary view open, I've written scripts with dcop calls to add notes and reminders for my perusal. I'm considering writing a script that extracts all the data from my application and inserts it into the calendar. The whole thing is getting more and more useful. My creative juices are flowing as I see ways of expanding usage to the others I work with.

Along the way I've run into some bugs or lack of function that I will either fix or report. No doubt as Kontact gets heavy usage the bug count will skyrocket.

But the most important lesson I've learned is the value of working within frameworks. This implies two things. The framework has to be extensible and powerful enough to contain almost any workflow situations. Quite a challenge. How difficult it is to extract the data from Kontact for other purposes? How easy and complete are the scripting interfaces that would make these things possible?

And I have to content myself with almost perfect solutions that are maintainable. A database app may suit better, but the tie-ins to the handheld that would require maintenance.

It is critical that the scripting bindings be included in KDE installations. That way users and writers of scripts would be assured of things working as expected.