Moving House and Home…

Please excuse the past few days of silence. But I’ll moving this blog/journal/collection of incohesive rants yet again.

The new home will be at my new brand new domain:

Now at the moment of posting this message, the domain is not up.  CIRA, you fail again.  So for the next few days I’ll be working on putting up a new blog on that site, and copying over my content.  I’ll keep this blog up for posterity though.  However I will post new entries on the new site.  Also I might be silent for a few days while I transition over.

Retro-gaming: Torus Trooper

In the mood for a bit of retro-gaming?  Try out this amazing abstract shooter.

Torus Trooper is a fantastic game, where you fly a fighter through a twisted torus filled with enemies.  The art brings you back to the era of wireframe graphics.  The trancy, techno music provides an excellent, motivating yet relaxing ambience.  The gameplay starts off easily and progresses with successively more challenging levels.  If you love a frantic, furious shooter to pass the time, you’ll love Torus Trooper.

Ubuntu Linux gamers can install it from the Universe repos with:
sudo aptitude install torus-trooper

Windows gamers can download it from:

The Filter Problem

Recently, Matt Asay blogged about Clay Shirky’s keynote on Web 2.0 Expo.

I must agree that many problematic aspects of my web experience hinge on the concept of filtering.  Now I realize that ultimately everyone on the web can read my content.  However, I would prefer different people to get different content at different times.  It is not that I have something to hide.  But I don’t want every single one of my contacts to read up on my all blog entries, my personal Facebook updates, my professional LinkedIn account and follow my project progress at the same time.  Why should professional contacts care or know about my relationship status?  Or should my high school buddies to follow up on my professional interests?  I certainly don’t want everyone at work to see know about my side projects or my silly photos from my last vacation.  It is all a question about audience is privy to which information and view from which perspective.

So rather than provide a rich networked experience to all of my audiences, I try to separate my different online parts of my life.  In theory I could flood everyone with so much data to make it impossible to get a complete picture of my life.  But that would inconveinence everyone…  No, what we need to do is to create intelligent filters that provide different lens for different people to see my life through well-engineered perspectives.

Hard Crash

Yesterday I realized I need more sleep.  Basically living the life of a rockstar: 5 hours sleep and then 1.5-2 hours of a catnaps just doesn’t work for me.  Initially I became more productive with more time in my day.  But it seems that illness and tiredness caught up with me.  And I get irritated, nervous and slothful when I don’t get enough sleep.  So I slept A LOT yesterday.

Today I am back to my cheerful, energetic and productive self again.  And for the most I caught up with most of the tasks and projects that carried over from last year.  There is still work to be done.  But nothing worthy to loss sleep over.  So a new, New Years resolution: sleep my 7.5 hours a day.

How Not to Run a Community-Project: justCheckers Post-Mortem

So the day before yesterday, Aaron Seigo wrote up a brilliant piece on running a community-driven project. Since I stole^H^H^H^H^Hborrowed his post, I want to contribute back my own experiences. The justCheckers project is currently in a semi-active state at the moment. But in its heyday, we had a group of 5 active developers. But overtime the momentum dropped off until only I remained on the project.

A major reason for this is my own inexperience in managing a project. Over the years, I learned about and tried out different project management techniques. Unfortunately by the time I could implement those in justCheckers, people had moved on to greater things. And I even thought of closing down the project, until recently I revived it again for a different purpose…

Some of the lessons I learned along the way are:

  1. Manage Expectations. This is a real killer. It is fun and easy to overhype your own project and your involvement in it. But it doesn’t help the project in the long run especially once people realise that their initial expectations differ wildly from reality. Myself I promised the moon, and didn’t deliver.
  2. Be Prepared to Spend the Time. As a lead developer, you will end up doing most of the work. Open source projects begin as ordinary projects, and only in the later stages do submissions and community efforts come into play. So before you begin, be prepared to do a lot of pushing until the project can maintain itself. Being a university student and running an open source project can be difficult if you are still developing your time management skills.
  3. Code is King. This I believe is one of Matt Asay’s favourite sayings. Source code contributions are what make open source work. Later on other kinds of contributions come into play. But source code should come first. I spent an inordinate amount of time on documentation and planning. Instead I should of thrown up a quick sketch and just concentrated on coding.
  4. Establish Good Lines of Communication. Without good, honest and open communication your project goes quickly astray. Facilitating that communication is not a trivial task. My greatest success was via individual e-mails and forums. But things went downhill when I lost the forums. Bringing them back ended up in fighting spam. Same thing with a wide open wiki. A wiki is good for knowledge discovery but not for discussions so much. I tried setting up an IRC channel on but my request never went through. This is one issue I never figured out how to resolve.
  5. Be Flexible. I tried applying conventional project management techniques and that doesn’t work for a volunteer open source project. In time I learned about the importance of voluntary involvement and persuasion as the best tool for moving forward. But that is another matter altogether.
  6. More Warm Bodies Don’t Mean Faster Coding. I learned that open sourcing a program doesn’t suddenly mean that a bunch of people will suddenly appear and work on your ideas. No, again you need to be the primary mover until others decide to help out to use the program to their advantage.

We did do somethings well:

  1. Delegate Tasks by Components. This gave everyone ownership of some part of code. This also prevented people from setting on each others work.
  2. Market Help Needed. This helped a lot in bringing together the core team. In fact the project would of never got off the ground without Sourceforge‘s ask for help functionality.
  3. Build to Last. We tried to build everything in a generic enough manner to allow for future functionality. It takes more time to build this way, but it ensures better design and future-proofs the end result.

Now, the justCheckers project is heading in a different direction. And so a different approach is needed.

Building a Community

Ok.  Aaron Seigo of the KDE project is a genius.  He really is.  Not only does he lead the absolutely revolutionary Plasma project in KDE, but he also knows what he is talking about.

Anyway he wrote a kickass article about how to build a community in open source.  And I’m too lazy to write one myself, since my experience is not as long or as exciting….  Or I might write it up later for reasons of posterity.

Without out further ado: advice from Aaron on building a community in an open source project.

Dear Lazyweb: How Do You Deal with Blockers?

After reading a number of post on the Ubuntu and KDE planets, addressed to Dear Lazyweb.  I’m not going to be lazy and not do research on this topic.  Rather I am interested in hearing how people deal with certain problems.  So I’m going to turn the blog over to you guys and gal, and get your ideas.  Please prove to me that this crowdsourcing of ideas idea really works. 🙂

So dear Lazyweb,
How do deal with blockers?  Blockers being larger/enormous tasks, that prevent your project going forward organically.

Thanks in advance.

A Short Paper on Snowfall and its Effects on a Northerly People

We take a break from our regularly scheduled program on technology, gaming, freedom, life management and progress updates; for a totally pointless post.

Up in the frigid northern regions called Canada, there lives a nation of people who well… basically live there. The very thought that someone would want to north of the 49th parallel, is downright shocking to Canadian’s southerly neighbours. More shocking is the revelation that said Canadians in fact do not normally consider dog sleds a mode of transportation. Nor do they consider igloos as mortgageable housing. Something that is not shocking is the presence of a substance known as snow.

Snow, or the collective name of crystalized water droplets in flake form, is a common occurence in Canada. In fact snow is the second prefered form of precipitation in the wet winter season. Rain is naturally prefered but not when combined with freezing temperatures. Oddly regardless of the number of times a Canadian has experienced snowfall, they react as someone who has seen the phenomena for the first time.

A Canadian will at first mention of a coming snowfall, will deny the existence of snow or its falling. Once the first snowflakes appear near the ground, a Canadian will appear shocked. Then dismay will follow. This dismay may lead to a near complete loss of driving abilities. Additionally, a significant amount of flakes accumulate on the ground, can profoundly affect the mood of a Canadian. A normally cheery and sensitive Canadian can be an unhappy, grumbling, insensitive individual. While other events can affect Canadians such as: election day, a referendum on Quebec separation or the unlikeliness of a Canadian team winning the Stanley Cup; these events happen with significantly less frequency. Such behaviour in a northerly people is confusing, given the frequent nature of snowfall.

There are a select few who worship the coming of snow. But even these rare individuals admit it, they prefer if the snow remained solely on top of hills and mountains rather than on roads. Also children seem to appreciate snowfall more than adults. However this appreciation is shortlived if the quantity of snow is less than required to close local schools.

The benefits of snowfall in Canada are multitude. Snowfall for one gives Canadians free exercise. It also cultivates the skill of shovelling. While a more profitable skill in the 19th century thanks to the use of coal and steam engines, shovelling can provide meaningful employment in construction, irrigation maintainence and ditch digging. Paradoxically, snowfall also provides a form of national unity.

The researchers of this paper recommend that a more thorough study on the contradictory nature of snowfall and Canadian attitudes is in order. The researchers are currently applying for a grant from the Metrological division of the National Research Council to cover costs of supply, equipment and travel to conventions held in more southerly countries.

This message was sponsored by local snowplow drivers and disgrunteled snowshovel wielding Canadians. And is dedicated to a certain ice princess.

A Week into the Year, and Back to Writing

A non-calendar week (7 days) passed already for this year. And I can say that I’m about 1/52 or less than 2% in completing this year’s goals. One goals is to finish writing and publishing my first science fiction novel, Echoes in the Endless. Thanks to my good friend Domenic’s suggestions I am reworking the first chapter again.

I decided to use a more conventional, simpler narrative. I dropped the techno-lingo and I will try using 21st century terminology normal people can understand. Normal as in non-military scifi geeks. 🙂 Overall I have a cleaner plot, and nicer story in mind. And I will avoid sinking the reader with too much background at once.

Anyways, the goal is to edit at least the first chapter this week. Then I plan on reworking in an earlier version of chapter 2.