This isn’t related to anything in particular, but here are a couple of great signs that I saw at Starbucks stores recently:

I saw the Link/Starcraft 2 one a few weeks ago in Little Italy, and the Admiral Ackbar sandwich board was spotted today at South Keys. They both made me smile, so I thought I’d share them.

My first thought (as a developer) was “I’ll write an app for it!”. My second thought, following close behind, was “Someone must have already written an app for that!”. Along these lines, I did a quick search of the android market and the iTunes app store (for my wife’s iPhone). Indeed, there are apps out there that let you track expiry dates on food. However, there were generally two problems with them.

1. They cost money
2. They were for single users only

The first point is self-explanatory, so I’ll expand on the second. One of the big problems in our apartment is when one of us buys food but forgets to tell the other what they got. This inevitably leads to us finding mouldy food that we didn’t know was there in the first place. Any solution to the problem must therefore allow multiple users to enter data separately.

This is when I had my third thought, which went as follows: “I don’t need an app for this at all!”. I realized that all the functionality I needed was already available to me through Google Calendar ¹. Want to know when food will expire? Create an all-day event for it. Want to be notified when food is about to go off? Set an email or pop-up notification. Sharing is also trivial: As long as the events are in their own calendar, the whole thing can be shared with as many people as you need.

The idea is that I will be able to add items to the calendar using my phone as I put them in my basket at the store. That way I don’t have to assign any extra time to data entry than strictly necessary.

The proof is in the pudding (pun definitely intended) however, and I’ve yet to see how this new endeavor pans out. My hope is that it will help us reduce food waste and save us money at the same time. I certainly think that the idea is sound, the main point of failure (if any) will be me forgetting to add things to the calendar. I’ll have to see how it goes.

Over the last 2 months I’ve been continually surprised by the ideas that the students have come up with. As I wrote in a previous post, the 5 groups that I mentored all came up with very different game ideas for their projects. I was really pleased that all of them were interested and committed to the class and that I didn’t see any of them get bored or lose interest. What was even more impressive was the degree to which they actually finished the game ideas they presented to us. My main worry was that they would bite off more than they could chew and end up with some half-finished product that didn’t run, or just stopped part way through the game because that was how far they’d gotten. We tried from the outset to impress upon them how important having something that worked was and how they could implement their gameplay in increments. Judging by the state of the projects that I saw on Tuesday, this advice seems to have paid off.

The teacher whose class we were attached to had some great feedback on the project as a whole, but first some background: The project is not just about people like myself going into classrooms and helping out with the students. There are also several off-site days organised for them where they get bussed out to the IBM offices in Kanata and get to do things like take laptops apart, have an introduction to a development environment and more.

However, the thing our teacher said was that none of the off-site trips were really important to him and his class. For starters, they took time away from other classes and therefore made the whole scheme less attractive.

The XO laptops weren’t the main draw either: Sure they’re excellent machines and there are educational aspects involved in learning about the target market. OLPC is a great project. But in the classroom, from a programming perspective, it was sometimes a hindrance. The testing cycle was always longer as code had to be copied across to the laptop every time a change was made. We didn’t have as many XOs as project groups, so we had to share and give limited time to each group. Furthermore, there were issues with performance. As anyone who has ever done any embedded development will tell you, optimizing code to run on a target device is a huge consideration. For grade 12 students who are just learning programming, worrying about how many times you can redraw the game background before the performance suffers (for instance) is not high on their list of priorities. Nor should it.

The most important aspect of the whole OCRI program for our teacher was us. The mentors. His opinion was that even if there had been no off-site visits or XO laptops then he would still have wanted us to come in and talk to the students and help them out. That was what made the difference, and it meant that the students didn’t get bored, or lose interest.

OCRI is currently looking at what form the program should take next  year, and I’d like to be involved in it whatever form it takes. That said, I will also talk to them about the pluses and minuses of the current scheme and see if we can’t improve it for the next batch of students.

Inflatable Apps is an umbrella title that I created to allow me to brand my android apps starting with TumTum, the app from the interview. Any and all apps for the android platform that I create will be released under the Inflatable Apps name.

There’s more to it than that though. Aside from myself, I know a number of people who are interested in android development. Behind the scenes, I want Inflatable Apps to offer a collaborative and friendly environment for developers that I know to work in and ultimately publish their completed apps under. I’m hoping that by doing this our apps will reach more people and gain a reputation for quality.

The Inflatable Apps website is now live at http://inflatableapps.com. The developer community is currently at an embryonic stage, but now that the site is up there is extra incentive for others to get involved. I also have my own ideas for new apps, so if nothing else those will be going up soon.

I’m excited about the potential Inflatable Apps has to produce excellent mobile applications for the android platform. Please check the site out, and let me know what you think!

I was pleasantly surprised that all of the groups had started out in different ways. The first pair that we spoke to had jumped right into their astronomy-based game and wanted to know how to make a sprite move in a circle. This required a brief maths lesson from the teacher as he explained the equations for finding the x and y co-ordinates of an orbiting object based on the distance from the center of rotation  (the Sun in this case) and the angle the object was at.

One of the other teams had started straight out with designing their interface in photoshop. It was therefore the prettiest (albeit least functional for the time being) of the games at this early stage. Fortunately,because REAL Basic is a visual editor, there’s no harm in throwing design elements at the canvas first and then hooking up the logic later.

Another group hadn’t done any coding at all. They had decided to theme their game around the environment, concentrating on endangered species. Rather than tack this element onto the end of their game production they had instead decided to do the research required up front and when I saw them they were busy looking species of exotic birds on Wikipedia.

There are other groups in our class, but these three were the ones that I spent the most time with today. The range of different approaches to the project is interesting as since university I’ve not been part of a project from the get-go besides my own personal one-man efforts. I think all of the student teams have made a good start and I’m looking forward to heading back next week and seeing how they’re progressing.

3 XO Laptops

Chief amongst these is the mesh networking capabilities of the XO. Whilst it can connect to a regular wireless network just like any other computer, the XO can also form its own peer-to-peer network with others in the vicinity. This is really important as many of the applications that ship with the XO are social or collaborative in nature and the mesh allows them to be used in situations where a centralized network is unavailable.

With this in mind, I started thinking about how to harness the powerful capabilities of the mesh for my own applications. As far as I could tell, the whole thing just worked by magic. This was great, but didn’t give me any idea on how to send and receive messages from other machines on the network.

The teacher of the particular grade 12 class I’m mentoring (along with my good friend Dan Menard) is teaching his students REAL Basic. I’d not seen this environment before, and I can’t remember the last time I did any Basic programming. Fortunately, RB comes with extensive documentation.

RB comes with a set of pre-defined ‘modules’, roughly equivalent to the way that Java provides default packages/objects for common tasks. There were a couple of interesting modules that I wanted to take a closer look at: EasyTCPSocket and EastUDPSocket.

Both of these allow simple interaction over the network. You bind them to a port, then send information to a specified IP on that port. That’s all well and good, but what I really wanted was a way of discovering other machines on the network automatically. I knew that each XO on the mesh was somehow assigned an IP address, but neither socket provided a means searching for addresses automatically. I dug a little deeper, and struck gold.

RB has a nice little module called AutoDiscovery. Subclassed from the EasyUDPSocket, it allows you to bind to a port and then join a named group within the subnet. Furthermore, it can pull back a list of IPs in that same group. Perfect! After a little bit of trial and error, I managed to get two desktop computers on my home network to join the same group and exchange IP addresses. For proof-of-concept, that was enough. It was time to move to the XOs.

Fortunately, RB can cross-compile applications for Windows, Mac and Linux. The XO runs a modified version of Fedora, so I built a linux version of my simple app and transferred it to my pair of laptops via a USB key. I was slightly worried that they wouldn’t have the required GTK libraries installed, but both applications started up fine. A couple of seconds later, and success! Each XO was proudly displaying the other’s IP in it’s group list.

A pair of XOs running my proof-of-concept app

From this starting point, it is easy to see that more complex network-enabled apps can be built: Either by using the discovery mechanism as a way to exchange IP addresses before forming dedicated one-to-one connections with other machines (using the EasyTCPSocket, for example) or communicating with the group directly using a broadcast function. Both options have their pros and cons, but the main hurdle of harnessing the underlying mesh has been solved.

I’m really excited to see what the students do with the starting point I’ve given them. They’re still at the design stage right now, but by the end of term I expect that they’ll have produced some really phenomenal stuff.

An XO Laptop on my desk at work

Over the last couple of weeks I have had the pleasure of a pair of XO Laptops at my disposal. The XO is the result of the One Laptop Per Child project, founded by Nicholas Negroponte. The device itself is a real marvel of design and engineering, and I’ve had great fun hacking around with it.

The reason I am able to do this is because I am a volunteer mentor for OCRI, the Ottawa Center for Research and Innovation. In a nutshell, their remit is to promote Ottawa as a prime candidate for software and other technology companies to set up shop in. To quote from their website:

Our Vision for 2010 [is] to make Ottawa recognized as one of the most innovative cities worldwide.

One of the things OCRI does  is run a high-school program to encourage students to consider a career in the technology sector. That’s where the XO laptops and I come in.

Over the course of 12 or so weeks, myself and other industry professionals (I feel like such a fraud calling myself a ‘professional’) go into classrooms around Ottawa and mentor the students as they design, create and test an educational game for the XO laptop platform. The idea is that these projects will become available over the internet to teachers in Africa whose schools are part of the OLPC project and that they in turn can pass the games on to their students.

The students at the school I’m mentoring in are currently preparing presentations on their game designs, and I’m really excited to see what they come up with. I hope to post follow-up articles over the coming weeks describing some of the challenges of programming for the XO, as well as neat things the students manage to pull of. I already have a post in the works on mesh networking which I will be putting up later this week.

www.youtube.com/watch?v=TFoX1A__-zw

Instead, I’m now using a free wordpress theme called LightWord. The design is far superior to my previous attempt, if somewhat generic. However, I can now tweak this theme to my own needs without worrying too much about all the little details that I would miss if starting from scratch. This approach appeals to me because it’s an example of one of the central pillars of good programming: Code reuse. There are literally thousands of existing themes out there, so starting from scratch would mean repeating the work of many, many people. Seeing as I don’t plan on making design work part of my professional portfolio any time soon, I’m perfectly happy to borrow existing works (within the terms of their license) and bend them to suit my needs.

This week, I was tasked with gathering and analyzing some data at my job. The task involved generating a couple of thousand data-points and examining their spread. The first part was easy, and accomplished in a couple of hours. What happened next was interesting though.

My script to gather/generate the data was written in python, so by the end of each run I had a large data structure in memory with all the results in. After printing some random samples to make sure the data was all in the correct ranges, I considered how to analyze it. A graph seemed the obvious choice and for my particular data-set an x/y scatter plot would be very useful. This decided, I went looking for a way of drawing such a thing.

My thoughts immediately went to finding a python library that would render the chart for me. After asking around a couple of my fellow developers I took a look at matplotlib and was very impressed. It seemed to offer a huge range of different graph and chart types, along with a whole host of rendering options. I say ‘seemed’, because I never actually used it. I realized that there was a much simpler solution to my problem.

Excel!

Excel, the spreadsheet software I was taught to use way back when I was 13 and not touched since. Technically, it’s all the things I dislike about software: bloated, over-engineered and closed-source. However, it does draw some pretty good charts with minimal work. Five minutes after realizing this, I had a thoroughly understandable representation of my data without writing a single extra line of code. Who’d have thought?

Could matplotlib have made the same chart? Of course. It probably would have had more colours, been in 3D and made you tea when you got up in the morning. On the downside, I didn’t really need any of those things, and it would have taken a whole afternoon, if not longer.

Similarly, I could have used an open-source solution such as OpenOffice or something lightweight like Google Docs. Excel just happened to be the most convenient option as it was already installed on my laptop at work.

The lesson I drew from this is that even though I can do some pretty cool things, I don’t always have to. Sometimes, existing solutions perform a task well enough and much faster to boot.