Macke's Blog

Trac and Kanban - Redux

2011-09-30T11:11:00.005+02:00

Hello there!

Since my last post before summer, the number of total visits has gone from 2000 to over 7000! One of the reasons for this was the Trac and Kanban post, where I breifly describe how to use a Trac wiki page as a basic kanban board. (The main reason is this Stack Overflow question which asks for a bit more, such as drag-n-drop and the like.)

We'we worked with this for half a year now, and it still feels like a good thing. So good, actually, that I simply had to improve it a bit.

Trac and Kanban, v2.0

Mainly I now use the "format=table" option to get a table, which means we get color for the priority, we can show who is owning the item and what resolution it had (duplicate/invalid/worksforme/wontfix, etc) where suitable.

It looks like this (with no one working on anything at the moment, but you get the idea):

This could be even better if Trac supported sorting on several ticket fields, but that is not possible with 0.12. There is a ticket and patch available on the Trac home site, but I haven't tried it ... yet.

Code review

For the confused, note that I still use two custom fields for post-commit code review "reviewed_by" and "has_review_issues".

I will probably change the boolean review_issues to a checkbox that better handles the states and workflow for code review:

not_reviewed
reviewed_with_issues
review_issues_fixed
reviewed_and_approved

A custom TicketChangeListener could then manage the has_issues to issues_fixed transition, so that it's automatically visible that the code has changed.

Automatic subpage/dashboard lists

The second new thing I've discovered and deployed is the TitleIndex macro, to simply list show all sub pages for a single wiki page. Since we have all the dashboards under Dashboard/ProductNameX.Y pages, it's easy to list them all using [[TitleIndex(Dashboard/ProductName,hideprefix)]] on a product's "home" wiki page.

Old/completed milestones could then be moved to DashboardOld container so that they're still there, but does not clutter the "current and upcoming milestones/sprints" list.

Wiki code

The wiki page above was generated from the following code:



This is the ticket dashboard for **[milestone:"Orsync 1.0"]**

([/query?milestone=Orsync+1.0&status=new&status=reopened&status=testable&status=accepted&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component open tickets])

-- [wiki:Orcamp/FeatureList current feature list]



Create new

[/newticket?milestone=Orsync+1.0&component=Apps/Orsync&type=defect defect],

[/newticket?milestone=Orsync+1.0&component=Apps/Orsync&type=enhancement enhancement],

[/newticket?milestone=Orsync+1.0&component=Apps/Orsync&type=suggestion suggestion],

[/newticket?milestone=Orsync+1.0&component=Apps/Orsync&type=change change],

[/newticket?milestone=Orsync+1.0&component=Apps/Orsync&type=task task],

[/newticket?milestone=Orsync+1.0&component=Apps/Orsync&type=demo demo] or

[/newticket?milestone=Orsync+1.0&component=Apps/Orsync generic] ticket.



{{{

#!div style="float:left; margin-right:1em; width:30%"



= Open Tickets = 



Total: [[TicketQuery(status=new|reopened,type!=suggestion,milestone=Orsync 1.0,format=count)]] 

([[TicketQuery(status=new|reopened,type=suggestion,milestone=Orsync 1.0,format=count)]])



== New & Reopened ==



[[TicketQuery(format=table,col=summary|type,status=reopened|new,type!=suggestion,milestone=Orsync 1.0,group=priority,order=type)]]



== Suggestions == 



[[TicketQuery(group=priority,status=new|reopened,type=suggestion,milestone=Orsync 1.0)]]



}}}

{{{

#!div style="float:left; margin-right:1em; width:30%" 



= Work In Progress =



Total: 

[[TicketQuery(status=accepted,order=priority,group=owner,milestone=Orsync 1.0,format=count)]]

([[TicketQuery(status=accepted|testable,milestone=Orsync 1.0,format=count)]])



== Started ==



[[TicketQuery(status=accepted,group=owner,order=priority,format=table,col=summary|type|owner,milestone=Orsync 1.0)]]



== Unreviewed tickets == 



[[TicketQuery(review_issues!=1,reviewed=,status=testable,group=owner,order=priority,format=table,col=summary|type|owner,milestone=Orsync 1.0)]]



== Reviewed tickets with issues ==



[[TicketQuery(review_issues=1,status=testable,group=owner,order=priority,format=table,col=summary|type|owner,milestone=Orsync 1.0)]]



== Ready for Test ==



[[TicketQuery(review_issues=1,status=testable,group=developertest,order=priority,format=table,col=summary|type,milestone=Orsync 1.0)]]







}}}

{{{

#!div style="float:left; margin-right:1em; width:30%" 





= Closed Tickets = 



Total: [[TicketQuery(status=closed,resolution=fixed,milestone=Orsync 1.0,format=count)]] ([[TicketQuery(status=closed,resolution!=fixed,milestone=Orsync 1.0,format=count)]])



== Fixed tickets ==



[[TicketQuery(status=closed,format=table,col=summary|type,resolution=fixed,order=priority,desc=1,milestone=Orsync 1.0)]]



== Denied tickets ==



[[TicketQuery(status=closed,resolution=wontfix|worksforme,format=table,col=summary|type|resolution,order=priority,desc=1,milestone=Orsync 1.0)]]



== Invalid/duplicate/other ==



[[TicketQuery(status=closed,resolution!=fixed|wontfix|worksforme,format=table,col=summary|type|resolution,order=priority,desc=1,milestone=Orsync 1.0)]]





}}}



{{{

#!div style="clear:both"

}}}

There you go. Hope it helps!

Process spawned successfully

2011-03-29T13:26:00.001+02:00

Our daughter arrived on March 19th, hence the lack of updates lately.

Normal service may resume in the future, but expect shorter posts in the near time.

P.S. I'm considering applying as a GSoC mentor for Buildbot, guiding the Javascript UI project together with a few other Buildbot developers.

Book Review - What Technology Wants by Kevin Kelly

2011-02-26T22:13:00.005+01:00

I decided to order a few non-fiction book from Amazon a few months ago, as a change from the reality-escaping high-fantasy, grand space opera or hard sci-fi that I usually churn through. I suppose it's got something to do with ~~growing up~~ getting older.

Included in the package was:

Managing Humans by Michael Lopp (has a very neat 'geek & manager' blog at randsinrepose.com)
Linchpin by Seth Godin (has a pretty unique 'be awesome now' blog at sethgodin.com)
Guns, Germs and Steel by Jared Diamond (the book won the Pulitzer Prize)
Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customer by Geoffery A. Moore (was recommended due to the other books I've ordered)

And, the reason for this post:

What Technology Wants by Kevin Kelly (former Wired editor, etc. Website at kk.org)

Apart from the last one, I've also finished the two first and heartily recommend them. I might review them too, but if you can't wait for that, I'm fairly certain you won't regret spending some time with them. Also, I'm currently a third of the way into Guns, Germs and Steel and it has not disappointed the slightest yet.

Anyway, withour further ado, here comes my short and humble review of:

What Technology Wants by Kevin Kelly
(This review is also posted on Amazon.com)

What Technology Wants is a slightly puzzling title which poked my interest. Can technology actually "want" something? What does that phrase mean? Does it attempt to imply that technology has a will of its own, is it is a "force of nature", or just something inevitable built in the rules of the universe?

These questions might sound a bit like "hippy-talk" (for lack of a better term) and while reading the first chapters of the book, which try to grasp this rather evasive concept, it felt rather hard to follow out where the author tries to lead. Solid lines of reasoning do emerge eventually, so if the narrative feels a bit vague in the beginning, one should not give up. Getting the grips on the driving force behind all the technology that most of us humans has ready access to, and what this actually means, is to say the least a rather daunting task. Also, I suppose the book tries to cater for many readers, not just the tech-savvy, so it attempts to gather everyone and provide a foundation on which the ideas and theories of subsequent chapters can build on.

The amount of background research made for the book is phenomenal. He devotes a large part of the book on the Amish, being that they are a successful group that chooses to live outside the "normal" western civilization, actively choosing to abstain from much of today's technology. However, he notes, crucially in my (and his) opinion, that the Amish would not be able to function without the rest of the society, and that they continually lag about 50 years behind.

This choosing of technology is not specific to Amish though. Everyone is doing it, one way or the other. Often, we are not very consistent in our choices. I.e. we may be on the cutting edge on one part, but several generations back on another, just because we want to.

Kelly relates this to the fact that Amish seem to live a pretty happy and unstressful life, at least in comparison to many of the rest of us. They perform their honest work and labor with the tools they have, being fairly content with the situation. They choose their tools by waiting for the rest of society (and select individuals of their own) to try out technologies before choosing that which is good and not disruptive to their way of living. This of course relies on the fact to the rest of us continues to provide spare parts for old tech, as well as continuously producing new technology.

An interesting side-fact (related to the issue of spare parts above) that is stated is that, apparently, no technology ever dies. You can find somewhere to buy a piece of flint and steel, an axe, an abacus, vacuum tubes (for your "this-goes-to-eleven" guitar amp), a vinyl player, etc. It don't doubt it at all, and it does help to choose between various technologies.

The book also contains a treatise on the unabomber. Being Swedish (and rather young at the time of the event), I knew very little about him before reading this book. There are some excerpts of the unabombers manifesto included (and discussed) in the book, which make the case that technology is inevitable and people cannot escape it. From this, IIRC, the unabomber draws the conclusion that since it's forced upon people by the system, so the system (and/or civilization) such as it is must be destroyed completely for the people to be free. Most of us agree with the first part, but our rejection of the latter conclusion probably separates civilization from apocalypse. (Also, even the unabomber tried to reject civilization and technology for several years, but could not do so completely, since he needed bullets for his rifle, rope for his traps and gasoline for the car to be able to travel to trade these things.)

Kelly proffers the same statement here, which is that technology in something inevitable, in the same sense that the universe has given us DNA, multi-cellular organisms, mammals, humans and civilization (for better or worse). One simply cannot prevent technology from appearing, given how far everything have gone already, and from where it actually started (i.e. the primordial soup). Complexity, and the perpetual increase thereof, is inherent in the foundations of the universe. We've had natural evolution for almost four billion years, and for the last ten to twenty thousand years (give or take a few), mankind (a product of the above) has been selecting, domesticating, refining and reworking different parts of nature to its liking. Now, we're selecting technology instead, and technology is undergoing evolution under the same criteria that (probably) made us domesticate the wolf rather than the hyena. (It's more beautiful, more intelligent, more adaptable, etc etc.)

This strive towards beauty, complexity, adaptability, etc etc is going on with technology today. Personally, I see this in the world of computer components, libraries, frameworks, utilities, etc. The open-source ecosystem a good example of this evolutionary process, as libraries come, evolve and leave. Some evolve quickly then stagnate when there is no opposition, then either gets wiped out when a new, better toolkit appear, or they attract sufficient interest (from it's users and developers) to catch up. The book's final chapters summarizes a number of criteria that are selected for in the evolutionary process, that will continue to be the driving force of change as technology evolves into more diverse, specialized, complex, interlinked, adaptable and beautiful manifestations..

Kelly, rather early, names the entire technological sphere the Technium. In the end, he concludes that what it wants is just to live and prosper, just like any other self-evolvable entity. The difference is that the Technium can evolve a thousand or a million times faster, and that it this speed is because it does not evolve by chance (i.e. mutation), but rather the fact that it is actively driven (you could say developed) towards improvement with every generation. Also, since it's so interlinked, and has perfect memory (i.e. the Internet, more or less), it will build upon itself much faster than evolution (wherein for instance the eye evolved independently eight times) and even faster than human civilization (which could not communicate ideas and inventions especially fast until we had the Internet).

I think this book is awesome in several ways. The question it attempts to both define, investigate and answer is immense. It is also a most relevant question, as I (and I suspect a few more) wonder where we are heading with all this technology, how it will shape us and what we can do, if anything, to guide it during its evolution. And since it actually manages to pull it off, I cannot by heartily recommend it to anyone that has some kind of interest in the field.

Having left me me with a sense that there is really no difference between the big bang and the forming solar systems, life and evolution, humans and civilization and finally technology (and thus the Technium, as Kelly names it), I feel that I'm standing slightly more on firmer ground, while the world around us spins ever faster.

Or maybe, I'm just getting older. ;)

Configuring PyQt across unit-tests

2011-01-17T17:11:00.000+01:00

We had some problems with configuring the PyQt API version across unit-tests. The problems arise because several modules try to call sip.setapi, which you can only do once (even if you call it with the same args, which ought to be idempotent, you'd think.)

Anyway, what I did was to create a module called 'pyqtconfig' with the following contents:

import sip
sip.setapi('QString', 2)
sip.setapi('QVariant', 2)
sip.setapi('QTextStream', 2)

import PyQt4.Qt
Qt = PyQt4.Qt

Then I simply do 'from pyqtconfig import Qt' in each module. Works like a charm.

(If you want to import each module separately, you need to adapt the above code somewhat. I'll leave that as an exercise for the reader. :)

Trac and Kanban

2011-01-17T12:51:00.006+01:00

(Don't miss my update Trac and Kanban Redux)

We use a Trac wiki page as a simple kanban board. It's pretty neat, especially when put on a 42" LCD TV in the project room.

Here's how it looks in the browser:

And here's the wiki code, all built using TickeyQuery-macros, both for counting (to keep an eye on the WIP-limit) and listing the tickets themselves. It's pretty basic, but it works well for our small team and it's easy to understand and maintain.

This is the ticket dashboard for Orcamp for [milestone:"Orcamp 1.0"] ([/query?milestone=2010+M11&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=milestone&col=component tickets])  -- [wiki:Orcamp/FeatureList current feature list]

{{{
#!div style="float:left; margin-right:1em; width:30%"

= Open Tickets = 

Total: [[TicketQuery(status=new|reopened,milestone=Orcamp 1.0,format=count)]] 

[[TicketQuery(group=priority,status=new|reopened,milestone=Orcamp 1.0)]]

}}}
{{{
#!div style="float:left; margin-right:1em; width:30%" 

= Work In Progress =

Total: [[TicketQuery(status=accepted|testable,milestone=Orcamp 1.0,format=count)]] 

== Started ==

[[TicketQuery(status=accepted,order=priority,group=owner,milestone=Orcamp 1.0)]]

== Ready for Test ==

[[TicketQuery(status=testable&review_issues=0&reviewed!=,group=developertest,milestone=Orcamp 1.0)]]

== Reviewed tickets with issues ==

[[TicketQuery(review_issues=1,group=owner,status=testable|closed,resolution=fixed,milestone=Orcamp 1.0)]]

== Unreviewed tickets == 

[[TicketQuery(review_issues!=1,status=closed|testable,group=status,resolution=fixed,reviewed=,milestone=Orcamp 1.0)]]


}}}
{{{
#!div style="float:left; margin-right:1em; width:30%" 


= Closed Tickets = 

Total fixed: [[TicketQuery(status=closed,milestone=Orcamp 1.0,resolution=fixed,format=count)]] 
Other: [[TicketQuery(status=closed,milestone=Orcamp 1.0,resolution!=fixed,format=count)]] 

== Fixed tickets ==

[[TicketQuery(status=closed,group=type,resolution=fixed,milestone=Orcamp 1.0)]]

== Other resolutions ==

[[TicketQuery(status=closed,group=resolution,resolution!=fixed,milestone=Orcamp 1.0)]]


}}}

{{{
#!div style="clear:both"
}}}

Note that the above wiki code contains some references to custom fields (notably review_issues) that we use to manage code reviews on a ticket-by-ticket basis. In our small team, we've decided to allow commits of unreviewed code, but require code to be reviewed before it's cleared for testing.

As always, you should adapt to local conditions. :)

BuildBotIcon - Python Style (and it's got tests this time!)

2011-01-09T18:43:00.001+01:00

If you've read earlier posts here, you might know that I'm behind BuildBotIcon, a small Java application that sits in the system tray, polling one or more BuildBot servers and reports any changes. It also plays sounds and turns lava lamps on or off.

I've decided to do a version in Python using PyQt instead. It's mostly as a fun exercise swim in the ecosystem of python (setuptools, unittest, mocking, coverage, yaml, etc) but it might come out better than the original.

PyQs nice, and the new-style signals-slots makes it a breeze to do what you want if, assuming you know your way around Qt. (Not that it's hard to learn, I just knew Qt pretty well before embarking on this project.)

Writing unittests are a breeze, and I think that it sure helps knowing that the code works, instead of knowing it only compiles. Coming from C++ this is actually pretty nice change. However, you should write with testing from the beginning. Grafting unit-testing later on is difficult and might not be a net win for all components, especially in C++ . (Mostly since you've run them for a while and the obvious (and thus easy-to-test-for) bugs have already been ironed out.)

However, the greatest fun so far has been using Mock, yet another mock object module for python that takes a nice and intuitive approach to mocking, IMHO. Instead of record/replay, or setup/run/verify, it's more like mock/run/assert. Read Mocking, Patching, Stubbing: all that Stuff (and it's link to Mocks aren't Stubs) for more information on this.

The ability of substituting any function or object in the APIs you're running makes unittesting immensely powerful and thorough. If you trust the framework (Qt in my case) it's very easy to verify that play() is called on the right QSound (without making noises) or that get() is run with the right URL to access the network.
Of course, more complex behaviours are trickier to mock properly, so it helps to refactor your app into testable parts (which you should do anyway).

Also, I've used YAML for the settings file this time (using PyYAML). All is good and well, except that it turns out that writing the settings file first and implementing the app second had probably been a better idea. TDD again.

It has all fallen out pretty nicely so far, except that, similar to the Java version, I've bungled together the backend that does networking and parsing with the UI. Since I currently have three ways to show build state (tray icon, sound and lava lamps) I should really had put a Listener interface in there. Fixing that now means refactoring the unit tests too, which is less fun. :-|

Nevertheless, all of this is experience is bound to pay back in my ThrustRacer-project (should I get it off the ground) or at work, where we're about to embark on a year of much Python coding. I don't expect either to get it right from the start, one never does. :)

ThrustRacer (working title)

2010-12-30T01:31:00.003+01:00

I just got the idea to re-create the old Roketz game on more modern hardware, notably using OpenGL GPUs and getting the stuff to run on both my PC and my HTC Desire Android device. (B.t.w, the PC version of Roketz is fully runnable on modern operating systems if you install DosBox, but the Android DosBox project claims that performance is a bit low still. So it won't do for an action game..)

There is already someone trying to do a version called OpenRoketz but that seems to be in 2D using SDL (which isn't available pre-compiled for VS2008 ... and it didn't compile out-of-the box either). Anyway I sort-o- planned the thing as a neat side-project to try proper OpenGL ES 2 (as opposed to vanilla OpenGL with all the fixed function stuff, which is what I learnt 12 years ago just after doing some 3DFX-Glide stuff, just after writing my own triangle rasterizers and whatnot).

I'd also like to try and attempt to create a small community with high-scores on the web, network play and user-creatable maps. Web servers are pretty cheap nowadays and Django is always fun to muck about with. (The editor will probably be in Python and Qt).

It'll probably not amount to much, but what the heck. :)

Mercurial rebase/merge musings part 2

2010-11-27T12:18:00.000+01:00

In a previous post I wrote about how nice it'd be if Mercurial automatically could choose rebase or merge depending on whether there are conflicts that need manual resolution.

So, "yesternight", after finishing the checkfiles extension I wrote about recently I couldn't go back to sleep (despite it being 2:30 AM). So, I got back up and hacked together the rebaseif extension that adds a command and an option to pull that does exactly that. It turns out it wasn't that hard, although the process could probably be optimized slightly as it currently attempts a rebase, aborts on conflicts and then does a merge. (The better way would be to detect which operation would succeed and perform that.)

Now, some support for that in TortoiseHg and we're all set. :)

Mercurial extension writing

2010-11-27T00:52:00.003+01:00

I just spent the better part of the evening and early night to hack together a Mercurial extension to check for and fix tabs and trailing whitespace in files to be committed.

Diving into a (relatively) poorly documented Python API is not easy. My previous attempts with Django (extremely good docs) and BuildBot (perfectly acceptable docs) went much better in terms of tackling the early learning curve.

As an example, I have not yet managed to figure out how to get the added diff lines of the working directory, or the files included in an upcoming commit (this are slightly different). The MercurialAPI wiki page only gives a brief overview, after that you're on your own and have to use the source. This is pretty fine, except that dynamic languages need more written docs if the source is to be understood better.

Anyway, the extension works pretty nicely as I decided to check the _entire_ file instead of just the changed lines. Shouldn't make a big difference performance wise, and it will allow a code base to go from mixes-tabs to spaces-only much faster. I can always revisit that part later if the need arises.

The next part in the plan is to write a small script that auto-injects this into each developers hgrc file on checkout. (I have a script that one must run, more or less, to deploy/unzip third-party libraries and set up environment variable, so it can just as well edit the hgrc file too.) I'm not worried about the security implications currently, as we're four developers on a corporate network, so everyone should play nicely at the moment, and secondly, I can always safeguard the paths to the extension (or put in in a subrepo) to which no-one but a select few, including myself, have commit/push rights (in case of a rogue developer).

The next little script I write will probably be something like that, to allow deployment of local extensions. I'll also add some extra meta-data to a commit and a central-repo hook to check for that, so that one can't push without the meta-data (ensuring that everyone starts using the hook ASAP) and also run the same checks there (in case someone decides to override the hook).

Hacking should not happen out of pure malice, but I've had developers disabling the global warnings-in-log-at-exit popup just because they where annoyed by them. (The best way would've been to fix the warnings inside the app, or at least have a chat with me on which log messages are warnings and if it's worthwhile to add a feature where said developer may disable the popup for a few hours.) Since the popup was disabled, many others in the team missed warnings or errors in the log and subsequently the CI build failed with warnings after commit. Sadly quite contraproductive and against the spirit of early-warnings.

Summing it up, I really enjoy hacking together small things in Python, but for larger projects it seems to become pretty unbearable and you really want to know the types of the variables. I really wish C# and WPF was available on more than one platform, so that we could go with that instead of C++/Python on Qt. It does seem to be a nicer road to walk.

(Yes, I've thought about Java, and I've worked with it for a few years. And no, I don't really like it, but I suppose SWT is at leats a bearable GUI-API (i.e. better than Swing), but lately with the Oracle takeover I'm very wary of betting on Java going anywhere but down the drain for non-enterprise projects.)

Obligatory links:

checkfiles.py on BitBucket.org.
CheckFilesExtension on the Mercurial Wiki.
ml-hgext project on Ohloh.net
Ozric Tentacles on Spotify, great background coding music (instrumental progressive/trance crossover)

New toy!

2010-11-09T22:36:00.000+01:00

Also, I got a HTC Desire a few weeks ago. Love it!

It's really becoming the multi-purpose do-it-all device that we all need to make our life a non-stop information gathering/processing journey from the cradle to the grave. :-P

More on HTML & JavaScript Client Apps

2010-11-09T22:33:00.001+01:00

In a recent post I wrote about the new log window for our Qt apps at work. Essentially, it delivers the log via AJAX to a web browser, with the html & javascript embedded in and served statically by the app. Works well enough.

However, there are two more ships on the horizon flying similar flags.

The first is my (secret) plan to build a debugger for a State Machine for a few years. Since Qt now has a state machine as of 4.6, and it seems both solid, well documented and behaves mostly correct (observing that we've yet to learn all ins and outs of a full state chart machine) is seems a good target for this. I've already written a QStateMachine to GraphViz translator, which outputs an SVG which can (with some good faith and heavy squinting) be interpreted as a UML state chart (cough cough).

Now, SVG is an XML document which has a DOM, which you can manipulate with Javascript in most modern browsers. Yay! However, this did not, at the time of having the idea, include Google Chrome (my favorite), since SVG-DOM updates didn't redraw the image immediately.... They have fixed it since, but I am pretty busy with other things so this small show stopper held me up. I hit a bump, I move in another direction, especially when I'm just going somewhere to see where I end up. Will have to get back on this one ... :)

Anyway, for the final product, I think a nice event log and some dynamic colouring/resizes of states and transitions would work wonders for debugging the app. Breakpoints via mouse-click events in the graph is then the second step. Then there are some question marks, but the last step is, as always, profit. ;)

The problem is always to package it so that other people can re-use it. I have to try to get better at that, but it's sadly not on top of the priority pile when working at a startup.

Secondly, it seems as the BuildBot project is planning to boot my Jinja webstatus implementation that replaced the html-string-pasting in python. (I never blogged about that.. oh well.. fun times it was anyway) Anyways, sad as that can be, the new plan is for... a html/javascript-only client! The content can then be served statically (via twisted or your local "real" webserver, for more oomph) and the webpage then communicates with the buildmaster using relatively small AJAX requests.

I think the idea is pretty neat, and has much in common with the things above, so I might go ahead and tackle that as well. Or procastrinate until someone else does it and steal^h^h^hborrow ideas from that place. Anyways, the jinja-rewrite made it much easier to see the actual HTML, so the new javascript (preferrably using jQuery) client could build on top of the existing layout.

Small steps in the right direction makes the world a better place. :)

Also, some day in March, if things go as they should, the household will gain a new member. One very small and in need of almost-constant care. I estimate I will not be able to contribute to open source for a few years starting then. Best do what I can before that. ;)

Mercurial rebase/merge musings

2010-11-04T17:40:00.003+01:00

I asked about how-to-check-for-potential-merge-rebase-conflicts-in-mercurial on StackOverflow yesterday and got a few interesting responses.

I think I'm going to write a small plugin that rebases if there are no file conflicts, and merges otherwise. This is what I want myself and everyone else to do, as it helps with clearing up bad merges afterwards, and avoid "'rebase broke the build and my life sucks" situtations.

Update 2010-11-27: I've written an extension for this, see this post for details and links.

LogWindow 2.0 using LibQxt

2010-11-04T16:50:00.006+01:00

I just implemented a small web server for our Qt apps that use LibQxt's QxtWeb classes to serve the application log over HTML.

Static files are served from QResources and log events are fetched by AJAX/jQuery, using a small javascript code to format them into a table in the web server.

Next on the todo-list is to add a dynamic filter by severity/thread/location. Should be pretty easy to get going.

We used an in-application LogWindow before, but that sucks performance wise and it doesn't redraw when debugging the GUI-thread, obviously. This is also way easier than creating and managing an logging application as an entirely different process.

The most recent LibQxt even has a JSONRPCService, which might've been useful. We're using a slightly older one so I manually implemented a WebService which serves JSON or html/css/js.

Anyway, this ought to be cleaned up a bit and contributed back to LibQxt.

Validating DTDs in python with lxml

2010-01-22T19:51:00.008+01:00

After replacing the string-pasting in Buildbot's web-backend with proper html-templates (using Jinja), I decided to write a unit-test that follows all links on all pages and make sure they validate and don't contain stale links.

lxml seemed like a nice tool for that, but our XHTML starts with a reference to w3.org's DTD I got this straight away:

failed to load HTTP resource

Googling found me the Caching DTDs using lxml and etree article by Jimmy Stratton. He had ran into the same problem last fall, dug around for a while (against the forces of nature, in this case represented by authors and documentation for lxml and python), and was nice enough to post his solution on the web.

The resolver works flawlessly. Thanks Jimmy! I owe you one.

Update: Since this is a reasonably popular post, here's the unit test for BuildBot, which applies this using the Twisted framework to validate all linked-to pages on the website. (It's was lost from the source tree in one of the many refactorings and cleanups of BuildBot's test suite. Also, it added some troublesome dependencies for the many builds slaves, and was too broad in scope. It should be re-cast as unit-tests for each page's possible states.)

Dirty coding tricks

2009-08-31T18:55:00.002+02:00

If you've gotta ship, you've gotta ship.

See this Gamasutra article for some funny stories. :)

Teh build is fail!

2009-07-09T18:12:00.005+02:00

Just to complete the gallery:

The responsible one has left the building but it's been pretty effective so far in getting people to fix the build a.s.a.p. :)

Also, the latest version of BuildBotIcon has optional sound, and currently we have Homer Simpson going 'DOH!' or 'Woohoo!' (rather loud). This makes everyone aware of it instantly.

(And yes, I've been reading lolcats too much lately..)

Oh noes, the red light is on!

2009-06-30T18:20:00.002+02:00

This is how it looks before things get really bad. The build was fixed before the lamp was running at full speed though. :)

Lava lamps - up and running!

2009-06-24T17:25:00.005+02:00

One picture, 1k words, etc:

We've also added a timer to turn them off during the night, along with the status monitor (which you can't see), to be nice to the environment.

Again, the USB board can be bought from Active Robots who were very friendly and helpful shipping the package to me, in spite of the efforts of our local post office. ;)

Lava lamp USB board assembly pictures

2009-06-22T21:19:00.011+02:00

Here's some pictures of the assembly process. It went reasonably well, but making sure you have big enough drills beforehand helps a bit. :)

Here's how the board looks before assembly:

First, check that the circuit board fix in plastic box. Tight fit. :)

Drill holes for 230V mains (in/out) and USB cable: (Had to use a knife to make the hole for the USB-B connector fit, as it is slightly asymmetric. Luckily, the plastic was very easy to work with.)

Drilled for circuit board with USB connector in place (avoids misalignment):

Prepare cables:

Do the wiring (and remember to pull the cables through the holes in the box first):

Fit the wired circuit board in the box, make sure all cables go inside and put tie-wraps on the cables to secure against mechanical stress:

Here's the box with the lid on:

Ta-daaa. :)

As you can see, I currently only use one relay. It's of course possible to use all four, but that requires more drilling and wiring, and more lava lamp shelf space. :)

Always leave room for upgrades, I say. ;)

Lava lamp - 99.5%

2009-06-17T16:08:00.005+02:00

Here's a tech-porn picture. :)

It's connected at office and it works, but I didn't have time for lavalamps.

Instead, I connected it to my office stereo system and set the computer to constantly play something from Tribute to Vengaboys when the build has failed.

Forget the carrot, it's all about the stick. :)

Lava lamps - 99% there

2009-06-16T23:29:00.003+02:00

The usb-board and wiring is finally connected and safely encased inside in a box!

I'll go shop for lamps tomorrow and have pics up in a week or so. (Got much to do this weekend, as it's Midsummer holiday in Sweden.)

Lava lamps - soon

2009-05-17T18:13:00.005+02:00

I just added Lava Lamp support to BuildbotIcon using the Phidgets USB interface kit. (Bought from Active-Robots UK)

Can't wait to have it going in the office. I've got the code running, but I need some casing and wiring for it to be safe to connect to the 220V outlet.

If you like it, click here:

Of course, it's nothing compared to Last.FM's setup but you have to start somewhere. :)

Smartphone retro gaming!

2009-04-01T00:38:00.005+02:00

Wohoo! Smartphones with touchscreen can run games properly!

Morphgear is an emulator platform for (amongst other) Windows Mobile. There are modules for NES, SNES and more available. You'll have to pay for it to play more than five minutes, but hey, it works and with this amazing skin I've got myself a little gameboy thingy.

And ROMs are amazingly small. (Super Mario Bros is 40 kb! I can add 200 000 of those on one SD card). The music brings me back.

Woot woot. :)

Two good links

2009-03-31T23:36:00.004+02:00

Just for fun, but you really ought to read SinFest. My favourite webcomic keeps getting better and better. New comic every day since the start.

Also, Broken Picture Telephone is a very fun take on the old whispering game of miscommunication. Describe a picture, draw the description, repeat until satsified. See results. (The site has some problems, so you can't even connect to donate some times. Best to try it when the US is sleeping. :)

Making the smartphone smart, only €19.99

2009-03-31T23:14:00.004+02:00

My HTC Touch HD (a.k.a. Blackstone to you guys across the pond) is my first "Smartphone", and was reputedly an iPhone killer.

It hasn't lived up to that. Not that I've owned an iPhone.. yet.. but it feels a bit clanky to use. And no games has worked well yet. Bah!

But, since it's got 0.5 GHz, ~300 mb ram and 8 gb flash, it ought to be good at something. And I just found out that with WMWifiRouter it becomes an excellent 3g modem + wireless router (that can also play youtube videos in 800x480 :).

This is an excellent piece of software. It installs smoothly, asks for some options, then gives me 6 buttons to start mapping between wifi, 3g, bluetooth and usb whichever way makes sense.

It also monitors the battery's temp in case it overheats... Oookay. I suppose it's a good thing that it does, but it's like having a warning light + engine shutdown in your car in case the rear wheel nut is coming loose.

Can't blame the program for that, though.

I ended up with this because Vista fails to reco'nize my HTC as a PAN supporting bluetooth device. Pfft! My old GSM-only Nokia worked amazingly well (connect to network - bluetooth pan - presto), although it was hideously slow. Well, since it worked for the Nokia, I'll blame HTC this time around.

Anyway, I'm glad that I can now access the net from my laptop _anywhere_. Very nice when on some trains that don't yet offer WiFi. (Most budget trains don't, and the only ones running to my parent's part of the country don't either... although they do have power outlets.)