tl;dr: If you’d like to help improve phone synchronization support, please run the script linked to at the bottom and send me the file it produces so that I can compile a list of supported phones.

As Murray pointed out, I’ve been working on SyncEvolution for the past couple months. Recently I added support for getting reliable phone information using the Bluetooth Device ID Profile (DIP). This data is used to match a Bluetooth phone with suitable syncEvolution configuration templates. In syncEvolution, templates are predefined in order to make setting up a sync session easier and less error-prone.

The problem with using the DIP information is that it’s just a hex number. For this information to be more useful, we need mapping from IDs to names. A list of companies IDs is freely available. For products this is a different story. As each company assigns numbers to its products, there is no centralized list mapping products to their assigned IDs.[1] So, we have to make our own list.

Below is a small python script that checks if your phone supports the Device Id profile and asks you for the model of the phone. It produces a file that you can either attach to, or copy into, an email and send to me (email address is in file). Oh, and don’t forget to turn on your phone’s bluetooth.

Bluetooth Device ID Inspector

Thanks!

[1] If anyone has device ID to product name mappings for a particular manufacturer we’d be grateful to have this info.

Last week I went to San Francisco to play Ping-Pong with Andre. At the same time a conference took place.

That conference was of course the 2nd MeeGo Conference. I’d gone to the 1st conference in Dublin in November and written a rather lenghty account. The two conferences had very different feels and it wasn’t due to geography.

The big news at the San Francisco conference was that there was no real news. The keynote had no big announcements: no new devices, no previously unannounced partners. As opposed to the Dublin conference where there was hope for such news, this conference had an expectation of such news. The lack of announcements caused the conference to feel rather less inspiring. While it’s nice to see MeeGo making headway in the in-vehicle infotainment and set-top box markets the lack of a handset device is weighing on the project.

Another obvious and expected difference to the Dublin conference was the much reduced visibility of Nokia. There was a large Qt presence of course. Other than that however, there were very few Nokia logos and fewer Nokia employees came to SF than to Dublin, although there were still quite a few.

Some of the most interesting talks were about the openness and transparency of the project. I’ll simply point you to a very good account of this at LWN.

I was happy to come away with an ExoPC Slate. This is the same hardware as the WeTab which my colleague Jon demonstrated running Maliit on GNOME 3 a few weeks back. These were given out to those who attended the Introduction to MeeGo SDK. The session covered the MeeGo SDK, AppUp SDK, and the AppUp Encapsulator.

Besides the conference it was nice being back in The States. I’m the only American working for Openismus and for the other 4 it was their first trip to the US. I think in the end they were for the most part pleasantly surprised. These Europeans tend to believe what they see on TV.

As part of my Openismus training, I was recently tasked with packaging a Qt application using the OpenSUSE Build Service (OBS). Here I’ll try to note my first impressions as well as offer some solutions to problems I encountered.

Note: This was my first attempt at packaging anything and the application I’m packaging (ConferenceGoer) is a personal project which is in an unusably-early state. So let’s ignore all that and focus on OBS itself.

What is OBS

The OBS allows a packager to create packages for multiple distributions and architectures using one spec file for RPM packages or one set of debian packaging files for debian packages. For example, in my OpenSUSE OBS repository I’ve built packages for multiple releases of Fedora, Ubuntu, OpenSUSE, Mandriva and Debian for the i586 and x86_64 architectures from one set of package files.

Despite the “OpenSUSE” in the name, the OBS is useful for other distros as well. For example, the MeeGo project has adopted it as its build-service of choice. I’ve used both and will refer to them as the OpenSUSE OBS and MeeGo OBS.

This is not an OBS how-to. See the OBS tutorial for getting started with OBS.

Some notes (in no particular order)

Generated moc_ files in tarball

One of the problems I ran into while packaging ConferenceGoer was that the tarball that is generated from the Makefile (which is generated from qmake), includes moc_* files. As anyone familiar with Qt knows, these are genereted files. The problem that this causes is that moc_* files generated with a newer version of Qt (4.7 in my case) will not always be compatible with older versions of Qt. As older distros do not package the newer version that you may be developing against, this will cause build problems. The easy fix for this is to remove the moc_* files from the tarball. qmake will regenerate these files for you anyway during the build process making them unnecessary.

Interacting with the OBS

There are 2 ways to interact with the OBS. The first way is using the web interface and the other is using the command-line tool (osc). I found that a mix of these worked best. The web interface can be annoying and slow for certian tasks. Triggering a build and uploading new versions of your files takes far too long. You can use the command line tool much like you would any svn client. You make you local changes, commit them with a message, and repeat. The commit will trigger an automatic rebuild. This seems to happen much faster using osc than with the web-interface. In short, use osc when you can and use the web-interface for watching the packages build status.

OpenSUSE OBS downtime

Annoyingly, the OpenSUSE OBS site seems to be unreachable rather often. It’s also rather slow. The MeeGo OBS is fast and seems reliable though. I’m guessing this has to do with the high load on the OpenSUSE OBS. Still it’s annoying.

Moving from the OpenSUSE OBS to the MeeGo OBS

If you ‘ve managed to get everything working in the OpenSUSE OBS, moving to the MeeGo OBS should be simple. For ConferenceGoer I just needed to remove the ifdef’s for all OS’s other than the redhat-based distros. We then need to remove all Qt version info from the package names. For example, qt4 becomes qt and qmake-qt4 becomes just qmake. MeeGo only has Qt4 packages so this distinction is not needed.

Also to note is that getting access to the MeeGo OBS is a manual process. You’ve got to have a meego acount set up and request access on irc.

Font problem with Qt apps in MeeGo.

Once the package was installed on MeeGo (on the nice netbook we were given at the Dublin conference), I found that the fonts looked terrible. This turned out to be a known bug. Seems you can tweak a config file to get it looking OK but hopefully this is now fixed.

Conclusion

Overall I think the OBS is a very nice tool. It’s rather gratifying to be able to build for so many different distro/version combinations with such little effort. The command-line tool is intuitive and works well. I’d like to be able to access the OpenSUSE OBS instants on a more regular basis however.

I plan on building some new cluttermm packages soon to encourage more people to start testing and using it as well as to practice packaging libraries. So keep an eye on my repository.

I’m a bit late in the game regarding blogging about the GNOME Developer Documentation and Tools Hackfest that we hosted at the Openismus Berlin office a couple weeks ago. There have been a number of good posts made summarizing what we talked about and worked on. In this post, rather than providing another summary, I’d like to share my thoughts about how we can get the most out of the demos (examples, tutorials… whatever) we started during the hackfest. Some of what I’m going to talk about was discussed at the hackfest, but much was not. Also, be warned that this will have quite a few references to Qt documentation practices.

A Tutorial for Tutorials?
So here we are, we’ve got some nice, simple code examples, some even with tutorial-style documentation. But if you look through the examples you’ll find that the documentation style varies dramatically. Before we go and write too many of these tutorials maybe we need to standardize how we write these. Some issues that arise when writing the tutorials are:

• how do we structure the tutorial? Daniel’s Magic Mirror example incrementally builds up the program while others, including mine, explain the finished program.
• how does one reference the code? Do we use line numbers, show full functions/classes? Do we include unexplained code in the code snippets?
• how do you show a full listing? Do we append a full code listing at the bottom of the tutorial or provide links to files?
• how much should we comment the code? If the code is going to be explained, do we need to repeat the same thing in the code comments?
• and so on…

Some of these have answers. For example, we decided that we should build up the programs incrementally and that referencing line numbers is probably going to be more trouble than it’s worth.

When I was writing my photo-wall tutorial I knew that I was writing it not in isolation but as a larger collection. Thus, I wanted my tutorial to fit in with the other tutorials in the collection. As there was no guide to go by, I poked around the repository to see how others were doing it. I found one I liked and went with it.

The point is that because there is no canonical tutorial or document to go by, we are adding a possible barrier to those wishing to create such tutorials. During the hackfest it was mentioned that we can not motivate people to contribute, we can only demotivate them. Let’s not do that.

For completeness these are my opinions about the above-listed issues.

• structuring the tutorial: Incremental build up is nice for GNOME beginners and that seems to be the target group so let’s go with that.
• referencing the code: No line number referencing. Break the code up into small logical blocks and describe. Blocks need to be small so that one can read the description and see the code without having to scroll up and down repeatedly.
• showing a full listing: Do like the Qt examples do; list all files at the beginning of the tutorial. This gives quick access to folks who don’t need the description.
• commenting the code: Heavily comment the code so that is descriptive outside the context of the tutorial and probably remove the comments when placing segments in the tutorial in order to save space.

Dealing with undocumented code examples

Right now I don’t know that we have a plan for dealing with this so here are my thoughts.

In a perfect world we are going to have a tutorial written for each example in each of the core programming languages. As perfection is rather boring, lets think about the alternatives.

I think in this case we should simply look at the Qt examples. They either have a tutorial-like description or they don’t. The one’s that do have an asterisks, those without don’t.

Regardless of whether the coder is willing or able to write an accompanying tutorial, we should promote getting as many code examples in as many core languages. In fact some example may be too large to expect a tutorial. Take a look at the Qt Network torrent example for one instance of this being the case. Looking at that example you’ll see that even though there is no tutorial, a file listing and description is available. If we were to standardize on having a file listing and functional description of the example at the top of each tutorial we could just copy the description and list the files for each newly added example port. Of course, hopefully someone would eventually get around to writing a tutorial as well.

Relating reference documentation with examples

One of the nice things about the Qt reference documentation is that it often references examples in the See also section. With one click your sent to an example that’s probably more complete than the small snippets you usually find in the API reference. Looking at the QTcpSocket class you’ll find 6 referenced examples. Some have documentation while some are just commented code. Maybe Shaun has something up his sleeve for something like this using Mallard.

Closing words
Basically, I would like to see a consistent, wide-ranging, integrated and ever growing set of examples and tutorials to help developers get started with developing with GNOME technologies. I think the Hackfest was a great start to getting us there. The documentation team has done a great job laying the foundations and providing infrastructure for getting us where we want to be with GNOME 3 regarding developer docs. We just need to finish ironing out a few things before we are quite there.

In 2 days the GNOME Development Documentation and Tools Hackfest starts here in the Openismus office. For the past 2 days we’ve spent a couple hours of each day getting things ready. We’ve designated two rooms as hacker rooms. Our central common area will be the main sit-down hacking area.

Common area hacker space (facing the front courtyard)

Common area hacker space (facing the back courtyard)

Bean bag hacking area in the front room.

On Wednesday we’ll have a welcome dinner for all the attendees sponsored by Openismus. Should be a good opportunity to get to know more of the GNOME hackergotchi heads in real life.

So, Openismus is ready and looking forward to a productive four days.

Last Thursday I and the other Openismus folks returned from our visit to Dublin for the first MeeGo Conference. Here is a summary of the conference and my impressions of it.

Note: If this post is a bit long for you jump to the last section.

Day 0:
Six of us from Openismus arrived at the Conference hotel, The D4 Ballsbridge Inn, at about 4pm. It’s located about 10 minutes from Aviva Stadium, the rather unusual conference venue. After getting settled into my room, which was strangely missing a mattress at first, I chose to do some reading and get to bed early while the others chose to explore Dublin a little.

Aviva Stadium field view

Day 1:
The first conference day started out with a series of keynotes. The first of these started the conference off with a bang. AMD announced that they were getting on board and Intel announced that all (well, except for Intel and Nokia employees) conference goers were to get Lenovo S10-3t tablet netbooks. This went over well, to say the least.

The next talk was from Nokia and stressed their commitment to Qt and their optimism that it could provide a unified development platform for creating apps on the various device profiles MeeGo is targeted for. It stressed the significant role Qt Quick and QML would play in this platform. QML was emphasized throughout the conference.

The next keynote was integrator targeted. The last one was a sit down discussion which felt very staged, which made it also rather boring. I’ll spare you.

A nicely catered lunch seperated the keynotes from the afternoon talks. The first talk I attended was MeeGo Infrastructure. This dealt with the server and build infrastructure of the project. It wasn’t exactly what I had thought it’d be but was interesting nonetheless. This was also the first talk of the OBS (openSUSE build service) which would be praised often throughout the conference.

I then attended the talk about running MeeGo on a BeagleBoard. This discussed the motivations of the project, the steps needed to get it running and its current state. I’ve got a BB at home as well as in the office, so I’m hoping by the time I get around to trying it out it’s an easy install.

Afterwards I headed over to the Qt Quick talk. Here we were walked through the creation of a Qt Quick app for viewing photos. This nicely showed how the process of developing apps with QML works. I’ll have to try it out a bit in order to see if it lives up to the hype (probably not). However a small improvement would also be welcome.

Next up was a talk on MeeGo input methods. It was interesting to see how this is shaping up. The architecture seems in place and the default keyboard looks nice. They stressed that one way they are trying to improve over other on-screen keyboards is through customization. They showed various layouts the the programmer can make use of and briefly described how to change the layout and themeing of keyboards. It will be interesting to see whether these customization features will be a good thing or just clutter and confuse.

I skipped the last two sessions, deciding to get some fresh air before the evening reception. The reception was at the stadium and included finger-foods and drinks. After lots of chatting, a contingent of Openismus folks and friends got together to find somewhere for dinner. After a short walk we found a pub and capped off the evening with a nice dinner and more conversation.

Day 2:
It had been announced that the netbook were going to start being given out at 8am, so several of us got an early breakfast and proceeded to the stadium to avoid the crowd. The tickets for the Ireland vs. Norway football match were also available starting at 8, so we were killing two birds with one stone. We quickly got our tickets for the football match but the netbooks were a bit harder to get to. Eventually we found the very long route to the pickup area. It turns out we were lucky that we got there as only 1/3 of the shipment had arrived and many others had to wait till the next day, which meant more waiting in line. The early bird gets the worm I suppose.

So far I really like the new netbook (my first). Thanks to Intel for this. Not everything is working 100% right now but I look forward to seeing how MeeGo evolves on this hardware. Specifically, it’s got a multitouch display that would be nice to use as such.

Later in the day I was also given an N900 by a Nokia representative. Thanks, Nokia! Working at Openismus, one feels rather out of place without one of these. I’m happy to have a device to test an app I’m currently working on. That’s a later blog post, though.

Lenovo netbook and Nokia N900 freebies

I missed the opening session, while standing in line for the netbook. My first talk of the day was on implementing protocols with Telepathy. This was rather interesting as I haven’t looked at Telepathy deeply at all. Hopefully, I can play around with it some in the future.

I moved on to talk about MeeGo on the N900 next. Unfortunately it looks like there is a long way to go before the N900 will be running MeeGo in a usable fashion. Guess I’ll be sticking with Maemo for a while.

Side note on Maemo: In case your wondering how Nokia views Maemo now, they were promotiing using Maemo 5 as the development device for apps targeted for the MeeGo handset profile.

Next on the schedule was a talk on packaging using the OBS. The was a well presented talk. As a recent openSUSE convert, I’m very interested in getting up to speed with OBS. However, the most interesting thing about the OBS is that for the task of building packages it’s not really related to openSUSE more that any other distro. I think the openSUSE branding is unfortunate as it really seems to be a general tool, as MeeGo is very much showing. One of my next tasks at Openismus will be to learn more about the OBS.

The next talk was about getting 3rd party apps into MeeGo. This presentation was packed with tons of information (probably too much for one talk) about the tools and processes available (and planned) to application developers. There were lots of links and references within the slides, which prompted one attendee to request that the information on the slides be placed on the MeeGo wiki. The presenter agreed this would be a good idea, so keep an eye out for that soon.

Following the last talk was one regarding the community OBS and repositories. The questions following this talk made it obvious that there are many questions left unanswered regarding processes in MeeGo. The most common question was how the community and core OBSs relate and how an app migrates from the community OBS into the core OBS. Unfortunately the presenters were not able to make any definitive comments on this as the release team is in charge of the core OBS and have not yet defined this migration pattern. Additionally, the intention was to retain a similar repository structure to that in Maemo: extras, extras-testing, extras-devel. The naming scheme is subject to change, though.

I took a break but then attended the talk about Zypper. Being a recent openSUSE convert, I’ve been learning the openSUSE-specific tools. I’m not too fond of YaST but Zypper has been a very pleasant surprise. It’s much faster than yum and the apt* tools and seems to be more intelligent at resolving dependencies, too. It also has a very consistent command line UI. It’s easy to see the why it was chosen over the aforementioned tools once one tries it out; and this was discussed during the presentation. Many of the questions afterwards came for yum users who were asking for features that were in yum but not yet found in zypper. The answer was almost always that they were working on it or basically “patches welcome.” Also interesting is that zypper is written in C++;

Next on the agenda was the talk about designing UIs for multiple MeeGo profiles. This was very much a QML presentation and focused on why QML is the right choice over the other alternatives.

The day was getting long so I skipped the last two sessions and rested in the hotel till the buses started to leave for the party.

The evenings party was at the Guiness Storehouse and was the social highlight of the conference. I and several of the other Openismus folks were on the first bus and were greeted by some Irish lads drumming supposedly traditional Celtic drum music. Not sure how traditional it was but it was very loud. The building spread over 7 levels, the top level being known as the Gravity Bar and having walls of glass overlooking Dublin. To get to the top one went through the Guiness museum/tour. I’m not a beer drinker but it was nonetheless interesting. Once we made it to the Gravity Bar there was beer and wine in ample supply followed by appetizers and later small dishes of food, all brought around on platters. At some point everyone was summoned to the 2nd floor where a U2 cover band started playing. They were pretty good but we eventually made it back up to the Gravity Bar where we chatted while rain beat upon the glass walls.

Marco and me in the Gravity Bar at the Guiness Storehouse

After the party everyone was brought back to the hotel. There was a hacker room setup in the hotel for conference goers to hack, play games (ping pong, fussball, Wii, XBox, Chess), chill out and/or munch on the seemingly endless supply of snacks and drinks. Several of us hung out there till about 2am, playing chess (or rather being taught how to play chess by Michael) and chatting. A nice end to a very active day.

Jon and Murray relaxing on the hacker space sofa

Day 3:
The last conference day was designed to be an “unconference.” Basically, if you wanted to talk about something you could through your name and topic on a board and hoped people come. I went to a few of these but by far the most interesting (if not 100% meego related) was Micheal Meeks‘ LibreOffice talk. I pretty sure this was mostly the same talk he gave in Boston a couple weeks ago so maybe this should be considered cheating. Regardless, it was very interesting to see the night-and-day change that has happened since the announcement of LibreOffice. I asked why this had not happened at least 5 years ago. The answer was basically that the stars had not yet been aligned.

unconference schedule

The conference day ended early (16:00) because the stadium needed to be prepared for the Ireland vs. Norway football match. For those who had gotten tickets there was a pre-party in on of the VIP rooms. Again, we were more than adequately supplied with food and drinks and additionally given “Ireland” scarves and noise makers. Just before the match started we were asked to go to our seats. Ireland started out strong and scored first on a penalty kick. Norway then equalized just before the half. At half we were again treated to drinks. I started chatting and never really make it back to my seat. I did manage to catch Norway make the goal that won the match, however.

Ireland vs. Norway pre-game

General impressions

The general impression is that MeeGo has a very enthusiastic and diverse community. There is not a since of contentment, though. Many areas need to be defined regarding processes, especially regarding insuring that it truly is the open platform it describes itself as.

The most talked about technologies were QML and OBS. The OBS was universally praised and QML saw a lot of interest from people trying to see what it actually was, removed from the marketing hype. Nokia reiterated over and over it’s commitment to Qt and MeeGo as a platform.

It was interesting to see GNOME and KDE people in equal number and working on a common platform. There was one talk that I did not attend about MeeGo on the enterprise desktop (I generally run from the word enterprise). Perhaps MeeGo will be the means by which the GNOME and KDE communites come together. …or maybe not.

The conference itself was very well received. There was obviously a slew of money thrown into organizing and executing it. Everyone really appreciated the free netbooks and social events (especially the open bar!). The next conference will be in San Fransisco in May and at least one of the organizers for that has already expressed doubt that they would be able to top this first conference. Furthermore. there will be a MeeGo summit in June. Quim described the Summits as regional events while the Conferences are the General community events after releases designed to resync the community.

What the conference could not answer however was just how much traction MeeGo will receive in a very competitive market. With very well know and very good platforms that are currently available MeeGo is trying to differentiate itself by being an open and inclusive platform. I think this is something the AMD announcement underlined. However, we won’t know how much this differentiation will matter in market terms until there is a major piece of hardware featuring MeeGo. No one really expects Intel to directly introduce a netbook anytime soon so this only leaves Nokia for the immediate future. Until they releases their first phone featuring MeeGo (and targeted at a general audience) we just won’t know how much traction MeeGo can get in a very competitive market.

Of course, as developers we want to work on interesting and relevant projects. If Intel and Nokia were using this conference to spark interest and proclaim relevance I think they have (at least initially) succeeded. However, this coming year will be extremely important to see if this persists.

For the last few week I’ve been working on a version of GMemory written using the gtkmm and cluttermm bindings. The project is called Merkmal.

Merkmal 0.1.0 screenshot

Currently the functionality is on par with that of GMemory. It requires at least cluttermm 1.1.2, clutter-gtkmm 0.9.6.

Here is a video of Merkmal in action. As you should see, basic game play is working but there are tons of things to be added to make the game more interesting. I listed some of those in the GMemory post.

Merkmal 0.1.0 screencast from Chris Kuehl on Vimeo.

Cluttermm

Now that I’ve ported the game to C++, adding these features should be much easier. However, there are some issues that I’ve been running into. I seem to be among the first (if not the only) consumer of cluttermm at the moment. This has of course meant that I’ve been running into bugs here and there. I’ve fixed the ones I’ve run into. I’ve also started filing bugs for missing api. For example, the new layout classes and animation framework have yet to be wrapped. I’ve filed some bugs for the ones that I’d most like to use.

GNOME Bindings

Having written the same application in both gtk+ and gtkmm, I don’t see why one would not use one of the bindings to write user apps. One of the beauties of GNOME is that there are so many high-quality bindings available. Bindings are a top priority for the project and it shows. With the introspection work that is going on, the situation will only get better.

For the last few weeks I’ve been working on a small concentration game called GMemory. This was done as a part of the Openismus trainee program.

Update: See below.

For those not familiar with the game Concentration, or Memory as I grew up knowing it, the basic idea is that one has a number of matching card pairs turned face down. The player(s) then attempt(s) to match these pairs by turning over two cards. If the cards match those two cards remain face up. Otherwise, the cards are returned to the face down position. This is repeated until all cards are face up. Here’s a screencast of GMemory being played.

As you can hopefully see, GMemory is currently in a playable state and it actual quite enjoyable if you’re into these types of games. However, there is a lot more to do to reach what I’d consider a 1.0 release. Besides some code reworking and some known bugs, I’d like to see a score tracker, multi-player mode, card animation and selectable themes.

The game is written in C using GTK+, GObject, Clutter and Cairo. In the course of writing GMemory I ran into a few bugs in clutter-gtk. The first bug was that no events were being received when using the embedded clutter gtk widget. You can find the bug report here. The second major bug I ran into was that once I got a version combination that gave me events, I always received double the events that I expected. This is a known bug and I’ve got a work around in the code for that.

There are also a number of known bugs. As you may have noticed from the screencast, the last card of the last successful match does not get shown before the statistics dialog box pops up. It seems the dialog blocks the drawing even thought the function to draw the card is called before the call to show the dialog box. Another bug is that once the game is over the playing area does not resize when the window is resized. I’ll tackle this once I’ve reworked the code some.

You can find GMemory’s git repository at Gitorious and the tarball can be had here.

Unfortunately, right now I’m building against the master branches of clutter and clutter-gtk. Expect breakage.

Btw, right now.

Update: After trying this on Ubuntu Lucid, I experienced none of the event-related problems with clutter-gtk. This seems to be Fedora 13 specific. Thus, I’ve removed the workaround for the double event issue and changed the configure.ac file to rely on the clutter and clutter-gtk versions shipped with Ubuntu Lucid. The new tarball is here.

As I mentioned in an earlier post, I’ll be moving back to Berlin at the end of May. Making the move has become even more exciting after learning that I’ve been chosen as one of the new trainees for Openismus. Since Murray has made the announcement, I thought I’d introduce myself to the community.

First of all, I should state that I’m American despite what the umlaut in my last name would suggest. My last name was Wilson before taking my wife’s last name just before our daughter, Vada, was born a couple years ago. I met my wife in Berlin and am very familiar with the city, having lived there from October ’99 until late 2005. I love Berlin and am excited to be moving back.

In a few weeks I’ll be graduating with a BS in Computer Engineering from San Diego State University. While in school I interned at a small company programming mostly in C++. I learned a lot from my work there but feel like I’ve got lots more to learn.

I’ve been a long time GNOME user after being converted from KDE at about the 2.4 release. Before starting school I’d occasionally submit bugs for Ubuntu and GNOME. I even attended GUADEC in Stuttgart where I met lots of interesting folks and got really inspired. But, alas, school started and free time vanished. We then sprouted a family which is a timesink, but such a wonderful one. Having a chance to learn and contribute on the job is a chance I couldn’t pass up.

I’m very much looking forward to the opportunity that I’m getting at Openismus to learn about and contribute to the projects I’ve been following so closely for so long.

Thanks Murray and Openismus.