Sorry about the lack of updates. My hell week of assignments on top of assignments just began this week. Started off tame too.
Anyways, I am going into “silent running” mode until I get a handle or break from the onslaught of work. Today by itself has 2 assignments due. The cryptography assignment is proving a worthy adversary. At least the writing is done, and I learned LaTeX. The hard part of proofs is now what I must face.
Dorian, over and out.
As a “budding” radio journalist (self-styled freelancer), I quickly realized the need to practice and learn the art of audio documentaries. So I decided to upon keep radio diaries.
For recording, I am using Audacity, an open source sound editing program. Running Audacity under Ubuntu Linux 6.10 proved a bit problematic. After a bit of poking around the Ubuntu forums, and Launchpad, I finally figured out a solution.
At first running audacity refused to work with my soundcard. Having installed alsa-oss already, I ran:
> aoss audacity
The minute I started recording, audacity crashed. This time a problem with the esd mixer many Gnome applications use. I need to turn off esd, by running Gnome instead of KDE.
I then ran System > Preferences > Sound and unchecked the esd mixer option. ESD problem fixed.
But the recording still did not come through. Turns out the volume was turned down to mute. Duh. I ran alsamixer:
After some experimentation, I found I needed to unmute the Line In, and change the Input So option to Front Mic. To turn up the volume, I pressed Tab and increased the Capture volume.
With audacity worked flawlessly, and I can record myself.
Links:
Audacity – an open source (and free) sound editor
Ubuntu Forums – excellent community with support for Ubuntu problems.
Launchpad – Canonical’s bug and developer network, and used heavily for Ubuntu development.
I felt the urge to do some violent gaming. So I grabbed the Linux demo of id’s Quake 4. The installation ran smoothly, but I ran into the infamous sound problem.
Turns out that the demo fails to use the right sound driver. The result doubled delayed sound that sounds like crap. The solution:
> quake4-demo +set s_driver oss
But then my Alsa and Arts mixers clash, and the game reports that it cannot use the /dev/dsp device (soundcard). Since I use Ubuntu (kUbuntu 6.10 GNU/Linx to be exact), I needed to install alsa-oss.
> sudo aptitude install alsa-oss
This gave the useful aoss command. So to run Quake 4 in all gory glory:
> aoss quake4-demo +set s_driver oss
Supposedly the +ss_driver oss argument, should be remembered but I run it this way just in case.
Yawn. Nothing is worse than a bad sitcom ending. Everything gets resolved into nice tidy way, and life proceeds as normal for the characters. Friday and today, many of my “issues” resolved themselves. Unlike a sitcom, this is not ending thankfully.
I finally got my schedule in order. Everything from classes to study periods all works out nicely. Not that I like the amount of bus based commuting I do. That hopefully will diminish after I look for carpooling rides. Now, if I can just follow my own schedule and due dates.
On the note of schedules, I finally made peace between my Palm and my desktop. Everything works at least in the Kontact-Palm interacti0ns. It took some time to bring back my emails, but everything now is in its proper place. My desktop neatly setup with few distractions (except the entire Internet and Half-Life 2) works for me now. Now I need to do work on it.
Most of projects are started and well on their way. The power of an enthusiastic group is awe inspiring. Things get done and quickly. Now if I need to do work.
The only things still in need of resolution are actual school work, my old work and minor things like exercising. Oh and I am still waiting for a coffee date.
On Monday, my class discussed about using software “engineer”for software writers. I naturally argued against it. My mother finished civil engineering, and I strongly believe in the elegance, timelessness and excellence of engineering. This morning, as I struggled with and later killed my groupware program over a dispute of syncing with my Palm, I solidified my stance against the idea of treating programmers as engineers. Here are seven reasons why programmers are NOT engineers.
Sin 1: Documentation
Most programmers do not document their code. Some of them say that code is self-evident, self-describing and self-documenting. Tell that to the poor souls trying to extend or maintain that glob of code you brain-dumped.
Now take a look at a blueprint of an engineer. What would happen if some of the measurements disappeared or someone forgot to label the room that holds the AC.
Sin 2: Testing
Programmers do not test their programs effectively. You wonder why your state-of-the-art PC keeps on crashing, as soon as you plugin that expensive computer card? Or just randomly? Testing frameworks, and concepts exist, but with the exception of a few individuals, no one does a decent job of testing. Whining about different configurations and different users does not help.
When an engineer designs a skyscraper, he/she needs with the whims of people, animals and nature. That is why after an earthquake, skyscrapers and bridges still stand in San Francisco.
Sin 3: Research
Programmers rarely research anything. They simply build a new toy program, and expect everyone to love it. They expect that they can experiment away, and deploy an untested and unthoughtout innovation.
Then surprise and dismay occurs when their innovation is unwanted and even hated.
In engineering, most innovations need a huge amount of research. Engineers need to design, test, and re-test ideas until they know they work. An engineering innovation never builds upon a brand new untested technology.
Sin 4: Meeting Requirements
“I’m the programmer. I know what my client really wants.” Wrong! This cocky behaviour of coding what the programmer wants, and not what is required happens way too often. User requirements often go unresearched or ignored. The users become upset at the developers. Company gets into trouble. And the programmers are forced to fix their mistakes.
Engineering anything revolves around meeting some need or requirement. These requirements and the challenge of meeting is at the heart of engineering. If the client wants a skyscraper in the form of a glass inverted cone, the engineer has to build it. But the engineer must find out, understand and then build according to the clients and the universe’s requirements.
Sin 5: People Skills
When things go horribly wrong, who gets the blame? If a building falls (without an obvious catastrophic uncontrollable reason), the engineer gets the blame. If a user’s data vanishes in a simple operation, the user gets blamed. Programmers always blame their clients of incompetence, even when a problem is caused by bad programming.
This behaviour goes beyond just blaming. Programmers ignore the advice and problems of their users, and keep their jobs. An engineer who does likewise, gets fired.
Sin 6: Reliability
Programmers suffer from terminal featuritis-o-philia. They program a new feature and continue on innovating, all when their program lacks stability of any form. User start believing that programs and computers have a mind of their own, with data disappearing, malware crippling systems and hardware crashing inexplicably.
Engineers strive for reliability. Ever building is designed to last the harassment of humans, nature and even “acts of God”. Every vehicle should not kill its occupant, unless a total, catastrophic disaster occurs. Wondering why to this day, the crash-proof operating system and program is still a dream? Reliability takes second step to “innovation” and “coolness” in the minds of developers.
Sin 7: Overall Cuteness
If there is a single profession I can think of when you can get away with unprofessional “coolness”, it is software development. Programmers love to use obscure shorthands, bizarre implementations and wacky ideas, even competing annually for the “cutest” piece of code.
Cuteness is a sign of un-professionalism, and often immaturity in the real world. A cute engineer is a starving engineer. A cute programmer is a thriving one. See why programmer’s can not become software “engineers”?
Finale
My rant ends now, and I know many will complain that I overexaggerated. True, there are some programmers that do not sin in the above ways. They are the exception. Most programmers pass themselves off as good, and still sin terribly along the way. An engineer who sins as such is a bad engineer, and rightly so. I claim that if programmers ever want to earn the distinction of software engineers, they need to raise their standards considerably higher.
Programming is a misunderstood art. Unfortunately many commercial ventures treat programming like a science and managers treat programmers as engineers. Engineers build things based on repeatable technologies and designs. Programmers craft code, a process more akin to the unpredictable and unrepeatable production of art like writing. Companies get in trouble when they try to apply engineering best practises such as enforcing strict requirements, and tight predictable deadlines. A far better approach works by treating programming as an art, and applying artistic best practises.
The Problem of Creativity
One problem with creativity, is that is hard to predict and control. Creativity comes and goes, at a whim. Since artists work in a creative manner, they need a great degree of freedom in their work. Unfortunately the real world treats art in the same way as it does engineering. The real world expects predictable work schedules and techniques.
This becomes problematic when programmers work on a project as a team. The team needs to balance creativity with reliability. So artists and programmers need to build predictability into their projects. One way to create repeatable and scheduleable for creative work is to use a framework.
Team Frameworks
I am an extremely individualistic person. Yet, I will admit many projects simply take too long for a single person to do. Teams naturally alleviate this problem, by throwing more people at a task. But like Fred Brooks mentions in his The Mythical Man-Month, throwing more people at a team does not guarantee faster completion.
One of the reasons, I dislike teams is the problem of expectations. Before starting on a team project, I find it best to lay out “ground rules”. The rules include:
It is important to work out these rules early on in a long term project. Without getting into specifics of each pint, I think everyone on the team needs to know what is expected of them. This saves the trouble of anguished team members when things go wrong, which in any project always does.
It is essential that these rules (not guidelines) be in place early on. Also every member of the team must follow these rules religiously. Sometimes the rules need changing, but if you did a good job on setting them up, the rules should not drastic changes.
Buffer Schedules
Programmers are notorious at underestimating the time required for work. The problem of “engineering” comes into play, and the result is delays in work. Instead when working on any creative project, you need to schedule in “thinking”, “wasted” and “oh crap, this is all going to heck” time.
The best of doing this is to schedule in a buffer. I usually work on a 1.5X buffer, (which probably is a very short buffer and 2X, even 3X are preferable). A 1.5X buffer basically adds an extra half “of time I think this will take me”. So if I think something takes 2 days to do, I try to schedule 3 days. This gives me room for error and I can finish ahead of time rather than “after-time”. Many successful programming groups also use buffers in scheduling.
I recently discovered the comfort of using groupware, to organize all my communication and email needs. I never used a groupware application before, so maybe I am just realizing the potential of such software. But I am getting ahead of myself.
I commute to university the majority of the time. This means 3-4 hours on the bus, with little to do. Last semester I began intensively using that time to finish homework, edit papers and so on. One of the things I wanted to do is to write emails on my Palm Tungsten E, and send them later. The Palm came with a Windows-only mail client, VersaMail. Not helpful when your main desktop being KDE running on Ubuntu Linux (Kubuntu 6.10). Fortunately that is where Kontact comes in.
Kontact: KDE’s Groupware Offering
Kontact acts as an all-purpose groupware program. I will not discuss the virtues of this program here. It is a serious contender for replacing Microsoft’s Outlook or Novell’s GroupWare. You should check it out yourself. Kontact comes with KPilot, a great program for basic syncing of a Palm. Unfortunately Kubuntu’s version KPilot had bug in it. Fortunately I found a deb from http://ubuntu.lnix.net/edgy/updates/kdepim-proposed/ that fixed my problem.
Migration
First, I needed to migrate my mail and contacts from Mozilla Thunderbird to Kontact. I needed to export my address book in Mozilla to LDIF. Kontact easily imported this. Kontact also comes with a neat feature for importing emails from other clients. A simple wizard, and my Thunderbird emails resided now in Kontact. An hour later of organization, I readied myself for Palm integration.
Palm syncing on Linux can be a chore. Fortunately, Ubuntu 6.10 comes with easy PDA syncing for most Palm PDAs. To my horror, KPilot actually removed contacts from my Palm. After I installed the updated deb for KPilot, this problem also disappeared. Now I all I need was the Palm’s email program integrating with KPilot.
VersaMail versus GNUGetMail
My Tungsten E came with an email client called VersaMail. Unfortunately KPilot’s email plug-in does not use the MultiMail format which VersaMail uses. Not wanting to buy an email client, I searched for a free solution. I stumbled upon gnuGetMail. gnuGetMail is a simple, open source email client and uses the older single account Palm mail format. All I really needed was something to write emails for later sending. gnuGetMail does both sending and receiving of emails.
I recommend both Kontact and gnuGetMail to anyone considering Palm based emailing.
Success!
I need to download and install a newer version of kpilot (fortunately in a Ubuntu deb). Now everything works. Except the Palm email, but that I can look at another day.
Greetings again!
6 days into a brand new year 2007, and I am starting to feel the ominous feeling of stress. Without getting into details, things are not working out as planned, backup plans seem to backfire and a tense atmosphere has enveloped my personal life. Fortunately I have 359 days left to make up.
School started again on Friday. The last semester started and I am not sure which courses I want to undertake. I do have a less then promising backup plan. I hoped on continuing my journalism training, but getting into the course proves problematic. Oh well.
Today, unproductive in the realm of homework and past work, I dedicated to integrating my Palm into my lifestyle. First I migrated to using the Kontact groupware, as KMail and family works better with KPilot better than Mozilla Thunderbird. The migration proved not too difficult. The problem I keep running into is syncing the desktop to PDA correctly. The PDA keeps on loosing contacts, and not updating the desktop’s todo list. Not to mention that the Palm’s VersaMail client refuses to talk to anyone except itself. My goal for the ending minutes of day is to force both Kontact and the Palm to talk to each other.
Confusion (and angst) are the order of the day.
Exams. One word says it all. If you ever taken one you know what I mean. If you never had the “pleasure” of taking one, let me just name some of the side effects: anxiety, dizziness, confusion, insomnia, sleepiness, panic attacks and memory loss. In extreme cases, exams may cause serious injury or even death of: marks, chances of passing, hope of finishing university and getting a degree.
I finished my last exam today, so please forgive my lapse in blogging punctuality. This temporary insanity only lasts for a few days fortunately. I think I passed two of my four classes. 😉
Instead of studying – the ultimate goal is to pass not excel – I contracted a recent meme-virus going around the Internet, videoblogging. After watching a number of videos on Google Video (including the feature film Dr. Strangelove), I kind of like the idea of watching videos online. It passes the time between exams and the split of Stargate Atlantis Season 3. Videoblogging reminds of watching the news, only way geekier, fun and with better looking hostesses (it’s a guy thing). The best ones I watched so far: Rocketboom and MobuzzTV.
Rocketboom, hosted by Joanne Colan feels like watching Slashdot on TV (minus the comments left by good willed gentleman – I love you guys – all trolls, except for one pleasant guy but he’s a troll too). The vlog delves into the wacky and zany antics, those creatures called humans come up with: shoverboards and the Boston Type Writer Orchestra episodes being great examples. The lovely Joanne Colan hosts the week-daily show, bringing a light-hearted humorous feel. The excellent overall quality of Rocketboom, makes me want to call it less of a videoblog, and more of a short on-line show.
MobuzzTV, raises the bar even higher than Rocketboom for videoblogs. I liken MobuzzTV to an on-line tech tv show. MobuzzTV deals with current tech-related events in a humorous, fun light. The presentation: sleek, sexy and professional. If more videoblogs of the same calibre of MobuzzTV start sprouting up, old fashioned TV will die almost overnight.
Videoblogs seems like the future of TV, and even governments seem to think so. Just check out France’s new France24. Impressive, but not surprising. I am wondering with such wonderful show and sites out there, how can a lowly “text” blogger such as myself compete for attention. Maybe some old-fashioned folks, prefer text sometimes.
I fear I must hasten to my assignments, and then I shall experience freedom from university!