Monthly Archives: January 2007

Running Quake 4 Demo on Ubuntu 6.10 (Edgy)

Posted on by

1

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.

The Plague (Part 2): Repulse

Posted on by

More late breaking news from the quarantine zone at home. My brother managed to infect both my father and me. Fortunately I seem to got it easy. After a super-tiring day with a headache, frozen limbs (thanks to the combined efforts of two bus transit systems), starvation and a light-headedness, I got up this morning more or less refreshed and feeling better.

Yesterday’s day-off comes at a bad time for me. University work in writing, cryptography, radio and ethics classes all need attending to. The writing needs interviews and work. Cryptography and ethics requires research and write-ups. And the radio class has a proposal due today.

So much for easy non-rushed living. And my projects just went on hold again. Nothing like a cocktail of illness, university and transportation all conspiring to put everything except the urgent on hold.

The Plague (Part 1): Enemy at the Gates

Posted on by

Today I am blogging close to ground zero of a plague in progress. My younger brother become ill yesterday with a fever. While unfortunate, worse is the knowledge is that he rarely gets sick. When he does, the whole family usually falls ill too. A cause of concern for me, since this might turn out a busy one for me. So I fell an extra incentive to finish my work early on this week, before I too succumb.

On the note of rushed, a Saturday of intense gaming did not help achieve any considerable work. Whoa is me but doing the whole Half-Life canonical story from beginning to end proved to0 tempting. I finished up to the Lambda Core chapter in Half-Life, and skipped ahead to the last two chapters that I never beat. Well I finished it, cheated at the Nilinath final fight, but finished. Half-Life 2 proves much smoother and hence more fun. Up to the Nova Prospekt level, one of my absolute favourites.

Now, if only someone could convince Valve to port Half-Life 2 to Linux. Then I would be totally happy. While id and Epic Megagames both port their game to Linux, I never liked id’s games all that much. Unreal Tournament is different, and I enjoy the hyperactive action. But I am waiting for the 2007 instalment. If Bungie ported to Linux, I would buy Halo. But since Bungie is a part of Microsoft now, I can forget about that.

But all this gaming, I need to put on hold. It takes too long, I lack the funds to spend frivolously, and my procrastination may prove my undoing for this semester. A number of assignments are due this or next week, and need my attention. Instead I plan on resurrecting my old hobby, computer graphics. If I manage my day wisely, I will upload some of my “art”.

Now I must depart. Work awaits, and the “plague” looms. I go hither!

Like a Sitcom

Posted on by

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.

In Search of Sanity and Coffee

Posted on by

I slept in today. Yesterday turned out too crazy for even me. I started off the day with a single plan: catchup. So what did I do? I wrestled with Kontact to work with my Palm. I decided to fix things… by backing up and wiping out my old KDE settings. The wipe out worked, and the backup not so much. That is the way I started my day.

Next, I “chilled” out by blogging and trying not to freak out about the loss of all my emails, contacts, and pretty much everything else.

Audio Docs class followed, and a changing of groups. My group remained the same with Rob, Masha and Amanda (a totally unrelated new Amanda), and a new girl joined our group whose name I forgot. I got randomly picked to record a sound on campus. Fortunately my partner finished 3 years in radio, worked in the CBC and confidently recorded everything. I helped “assemble” the mini-Disc recorder. And I held the bag. And provided conversation. Yes, I am hopeless.

In my absence, my group decided upon on using my idea (my obsession with Ewa) for the documentary project. Apparently the prof used my story as an example, and my group understood it as good. Rob started writing up the script, Masha organizing the project, and Amanda helping Rob. Yes, I feel touched with their decision, but the whole thing just started so spontaneously. Anyways, I promised to contact everyone, as soon as I got my email back.

I asked Masha about meeting up after class, but she said she had work. I then bumped into Kat, and asked her for coffee after 4. She said maybe, as I should of expected. Next I ran off to my cryptograph7 class.

Professor Charles Rackoff had already begun explaining to the class, why Max’s idea of a project on quantum cryptography did not work for the class. Basically, he did not want us dealing with physics especially when the class dealt with “classical” cryptography. Max’s second idea of hard drive cryptography sounds better. I got assigned the task of looking up on it. Cute.

Charles then quizzed us on the “obvious” and beautiful definition of pseudorandom number generators. I am starting to comprehend it, and the rest of the course seems to follow suit. Now I understand the theory, but I can not see myself thinking in pure theoretical-mathematical terms. My cavemen mind can understand art, writing and programming. My learning of mathematics is similar to my learning of dating. Me thinks me thick-skulled.

After class I met up with Kat, who passed up my offer for coffee, free lunch and a pleasant chat with old soup. Yes that is right. She preferred to go home and eat old soup instead of my company. I passed by Masha again, and foolishly proposed coffee after she finished work. She works at one of part of the university. Proposal refused politely and with tact. And not over lame, old soup.

My day ended with Rudy and company working on the average run time of algorithms. Algorithms and statistics are even lower down my mental understanding than cryptographic theory. And I just passed the algorithms course (probably out of the kindness of my prof), and never ventured back into that neck of the woods. So I tried helping Rudy’s group, even going off to figure out combinatorics. I re-learned that part, but still was mostly useless. Eventually, Rudy decided to end my suffering, and go home.

Went home, eat dinner and crashed into bed. Depressing dreams of living in a dystopian universe followed. I ventured out of bed late morning. Watched some old BBC Narnia stuff, cleaned around the house, and now in the process of resurrecting Kontact. Next I must undertake the task, of catching up two lost days and tons of homework.

I guess this puts off my writing my first epic scifi novel, and my blockbuster game. Tomorrow promises to keep me busy, until late night today. Yummy.

The Seven Sins of Software “Engineering”

Posted on by

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.

Tea & Biscuits

Posted on by

Sunday evening I finally managed to meet up with Dmitri. After 2 weeks of an unsuccessful trip to the mall, I convinced Dima to scrap the whole mall trip. Malls are better for shopping and not meeting up for coffee.

I went over to Dima’s house and at Sarah’s insistence, we all had some tea and biscuits. I would of preferred coffee, but Sarah hates the taste of it so tea it was. Sounds old fashioned but I enjoy a talk with friends more than the most “exciting” game or movie. Dima attempted to get me to watch a preview of Jackass 2 and Dexter. As promised, I will watch the first episode of Dexter, but Jackass proved too crazy and silly for me. Sorry Dima, I know you tried.

Before the “tea” party, I helped Sarah and Dima work on Sarah’s assignment. Acting like a snobby writer, I commandeered the assignment. I still persist that most writing needs the golden touch of a good journalist, writer or editor. And I managed to finish up my previous blog. The next ones will be shorter.

Also I received confirmation of someone reading my attempt at journalism. Thank you Sarah for reading my work. You made my day.

Harnessing Chaos: A Framework for Team Management

Posted on by

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:

  1. Quality Expectations
  2. Communication
  3. Scheduling
  4. Individual Talents
  5. Work Synchronization
  6. Task and Job Division

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.

Delays in Posting

Posted on by

Please forgive the delay in posting. Preparing for the new (and final) semester, forced me to sacrifice my time to non-blogging work. In fact, I am waiting for a clean reinstall/upgrade of Ubuntu to finish. We will back to our “regular” schedule by Monday.