Software Development

How do you Describe Software?

I was talking to my father-in-law yesterday. He’s not a software guy, but we were discussing the HR system he uses at work. He speaks very deliberately, always saying exactly what he means. When he was looking for a word to describe the ideal HR software, he settled on “capable”.

Capable. As in, it does what is needed of it.

I love this idea. Whenever a new technology comes out, be it a new framework or a new programming language, everyone wants to talk about how powerful it is. Or how many features it has (and it had better have a lot).

I think we’re going about this all wrong.

When I discover a new tool, I don’t care about how powerful it is or how many features it has. I just want it to be capable. Capable of fixing whatever problem I have. Capable of filling a need. Capable of doing what I need it to do.

Maybe this is how users feel too. They don’t want us to swarm them with bigger and better software. They just want software that is more capable.

What do you think?

Software Development Web Technology

How to Make a Colour Selector with HTML5 Canvas

Over the weekend, I attended HackOTT, a hackathon here in Ottawa that encouraged everyone to play around with some neat third-party APIs. It was a lot of fun seeing the awesome apps everyone came up with, and even though we didn’t get to demo, I’m happy with how much I learned.

My team was comprised of myself, my softball captain/ex-coworker @jyboudreau, and our fearless leader @davefp. The idea was that we would create an HTML5 application that allowed users to upload an image of a room, select a few colours from that image, and get back a list of products sold through Shopify that match the room. We were pretty excited, and so were some of the API guys we talked to.

Dave and JY grabbed the TinEye and Shopify APIs, so that left me with the UI. While we didn’t quite manage to get everything working in time to demo, we did make a lot of progress, and I thought I’d share part of my contribution, a Canvas-based app that lets the user pull colour swatches out of an image.

Let’s look at how it works!

Basic Setup

The layout is pretty simple. The empty blocks on either side are just divs that will hold our colour swatches, and that image in the middle is actually a canvas. In fact, it’s two canvases, overlayed on top of each other using some absolute positioning.

We used two canvases to make the drawing easier. The backmost canvas holds our image, and that’s it. The frontmost canvas, which is completely transparent, is where the swatch outlines are drawn. This makes it less expensive to redraw swatch outlines, because we don’t have to reload the image each time, and allows two swatch outlines overlap without having them affect one another’s colour.

Now, let’s have a look at the drawing code.

Loading the Image

Loading an image into a canvas is relatively straightforward. Check out the javascript file, and in particular note the addUserImage function. The mechanics of loading an image are simple:

  1. Create a new logical image:
    var img = new Image();
  2. Make sure the image’s onload function ends by drawing the image:
  3. Trigger onload by setting the image’s src property:
    img.src = TEST_IMG;

There are a couple of gotchas, though:

First, you may have noticed that in the image’s onload lamba, we’re adjusting the dimensions of both canvases and their container. This resizes our canvases and the surrounding layout to match the size of the image. We also set the canvases to display block because they are hidden by default (this avoids an ugly resizing-flash right after the page loads).

Second, the image src can’t be just any image. For canvas to load it properly, it must be an image contained within your own domain. This means you can’t just give it a url you found online, or even load it from a file using localhost. We deployed our app using App Engine, but any container should do the job just fine.

That’s all there is to loading an image, let’s move on to swatches.

Drawing the Swatch Outlines

There are three user events we care about for our canvas: mousedown, mousemove, and mouseup. To handle these events, there are three functions: handleCanvasClick, handleCanvasMouseMove, and handleCanvasMouseUp. Let’s look at these a little more in-depth.

First, you’ll notice that each function uses some simple math to get the coordinates of the mouse click:

var clickX = event.pageX - canvas.offsetLeft;
var clickY = event.pageY - canvas.offsetTop;

We get the coordinates from the page via event.pageX, then subtract the top-left corner of the canvas so that we’re left with the distance of the click from the canvas’s top-left corner. Conveniently, the origin for canvas is located in the top-left corner, so we’re already in the right coordinate space and our x/y positions are ready to use.

Next let’s talk about getSwatchIndex(). This is a convenience function that parses the id of the currently-highlighted div to give us a numerical representation. Why is this important? Because we want to maintain an array that represents the current position of each swatch outline, and we use these numbers to index it.

By storing the positions of the swatch outlines in an array, we’re free to clear the swatch-outline canvas and redraw it completely on each pass. This might seem like overkill, but it’s necessary for situations where two swatch outlines overlap, and at a code level, it’s less work than repainting a transparent box over a swatch outline before the swatch outline is painted again it in its new position.

Once we’ve updated our array, it’s off to our redrawSwatches function to actually draw them. The algorithm here is what you would expect, we loop over the array of swatch outline positions, and draw each one with a semi-transparent background and a solid border. We’re also watching for the currently selected swatch index to come up, because we want to highlight that border with a brighter colour so that the user knows which swatch outline is active.

Handling Dragging

We wanted the user to be able to drag a swatch outline around to make sure it’s placed in exactly the right spot. This ended up being easier than we thought. You may have noticed the dragEnabled variable in our mouse event functions. This is a global boolean that we set on mousedown and clear on mouseup. That way, when mousemove fires, we can check it and redraw if a drag is occurring. Simple!

Extracting Colour Information

Let’s head back to handleCanvasMouseUp and look at the colour extraction (which should probably be in its own function).

The important step is this one:

var imageData = context.getImageData(

Here we’re telling the canvas to give us the image data for a square positioned where the user clicked, and the size of our swatch outline (that I for some reason called a highlight this time &#151 we were in a rush). That returns canvas’s own ImageData object, which probably does all kinds of neat things, but we just wanted the pixels, so we called .data to grab them.

Pixel data in canvas is stored as a giant rgba array. So if you have a 10×10 canvas, then the array will be of size 400 (10x10x4) and will be formatted as [r1, g1, b1, a1, r2, g2, b2, a2, etc]. We want the rgb values only (we skip straight over the alpha values in this case), so we sum up all of the reds, blues and greens individually.

Finally, we average out each colour by dividing it by the number of pixels, floor the totals to get integer values, and voilà! We have an average colour we can show in the swatch.

It was fun spending the day playing around with canvas. Hopefully next time we’ll get something we can demo!

Software Development

What Your 16-Hour Workday Says About You!

I came across this link many times over the past week.

As a software developer, I’ve worked my share of 16-hour days. I’ll admit that I can’t argue everything on that list (I struggle with time management, for example), but I believe that long workdays often say a different set of things about someone. For me and many people I know, the list looks more like this:

  • You love what you do.
  • You’re not just in it for the money.
  • Your life is full of supportive people.
  • You’re learning a lot.
  • You follow through.
  • You’ll never be unemployed.
  • You’re doing work that matters.
Software Development Web Design

The Golden Rule of Web Design Implementation, Part 2

This is part two of The Golden Rule of Web Design Implementation. In part one, we learned that pages aren’t views, and that thinking in terms of views is much more beneficial. Today we’ll wrap up our analysis by looking into development.

As you may recall from Monday’s post, the Golden Rule is:

The time it takes to implement a web design will always average out to one view per day.

Our first corollary was related to views. The second is about development. Or more specifically, developers.

There’s a reason I put that always in there. It’s to remind myself (and you) that this rule can stand up to a lot of variables. As I’ve mentioned already, the technologies being used and the platforms being targeted are irrelevant. Plenty of other things are too. But what I found most interesting was this:

The developer’s skill level doesn’t matter.

This is counter-intuitive. If a weak developer needs an average of one day to implement each view, then shouldn’t a more experienced developer be able to get those same views done faster? The answer is no. In fact, it will take a strong front-end developer and a weak front-end developer about the same amount of time to implement any given design. We’ll get to why in a moment, but first let’s clear up some definitions:

  • By weak front-end developer, I mean someone that knows the basics of front-end development in the technologies being used. That statement above is obviously false for someone with zero experience.
  • By strong front-end developer, I mean a real ace. Someone that can put “HTML/CSS Expert” or “Adobe Certified Flex Expert” on their resumé without exaggerating.

All set? So how is it that a below-average developer and a bonafide expert will require the same amount of time to implement the same design? It all comes down to the perceived level of what constitutes a correct implementation. In other words:

Better developers don’t code faster, they code better.

Picture a standard HTML/CSS implementation. The design is there, and you hand it off to your weak developer and your strong developer, and tell them each to get to work. After X days (where X is the number of views, of course), you get both implementations back. Here’s what you can expect:

The weak developer will have done exactly what you asked. The pages will look just like the mock-ups, pixel for pixel, and work as intended. There will be nothing wrong with the design from a typical user’s point of view.

The strong developer will deliver an implementation that looks about the same. Surprised? Don’t be. That’s all these two implementations will have in common. Let’s look at some things the guru probably did that our weak developer didn’t even consider:

  • The HTML and CSS both validate, with no errors.
  • Each page has a proper doctype.
  • There is a clear separation of structure and presentation.
  • Accessibility has been accounted for wherever possible.
  • The HTML is semantically clear, and would be easy to restyle.
  • The CSS is beautifully minimal, and optimized for maintainability.
  • There are <noscript> blocks for users that don’t have javascript enabled.

Do you see the difference here? On the surface, it’s barely noticeable. But just beneath that surface is a trove of quality that goes far and beyond what was asked. To the guru, this isn’t even extra work. This is just how HTML and CSS are used.

Don’t blame the developer.

You may be thinking: “The guru shouldn’t waste time doing what wasn’t asked of him; he should be able to translate that extra time into finishing the implementation faster.”

Please don’t ever ask this of your developers.

Would you ask a master carpenter to build a simple chair as quickly as possible, and not “waste” time without worrying about quality, durability, ethics, or craftsmanship? Of course you wouldn’t. That’s simply not how experts work.

The solution to this problem is simple: choose the best developer for the job. If you don’t care about the internals of a deliverable, assign a developer that has lots of room to learn. If the project requires some baseline level of quality, consider a developer that is better versed in the fine art of building interfaces. Only call in the guru when the project requires an unmatched level of care.

And remember that no matter how hard you push, and no matter which developer you choose, you’ll never beat one view per day.

Software Development Web Design

The Golden Rule of Web Design Implementation, Part 1

Hi folks! Today’s post was so full of awesome that I had to split it in two. This is part one, about views. Part two is about development.

Estimating is hard, and I hate doing it. But I have a trick.

Specifically, I’m going to talk about how to estimate the implementation of a web front-end project. Maybe it’s a UI refresh for an existing web site, maybe it’s a new take on e-commerce, maybe it’s one of those new-fangled web-apps… it doesn’t matter. As long as you’re implementing a relatively well-spec’d-out design, this rule will work every time.

Oh, and the technology doesn’t matter either. It can be HTML/CSS, with or without JavaScript. It can be Flex, it can be JSP or ASP or anything else. As long as you’re not doing any significant back-end work, this truth still holds.

This is really important so I’m going to write it in a really big font:

The time it takes to implement a web design will always average out to one view per day.

So if the design has 16 views, the implementation will take 16 days.

There are two interesting facets to this rule. Today we’re going to talk about the first one, the significance of the term “view”.

Views != Pages

This is an important distinction: it’s not about pages anymore. We’re past that. We have bigger monitors, and that means we can have more elaborate pages. In fact, we often put several views on the same page, just because we can.

Imagine you have a page in a standard two-column layout. The main content is one view, that’s obvious. What about the sidebar? These days, if it’s anything other than nav, it’s probably also an independent view. Even the main content can be more than one view, if it separates logically and especially if part of it will be re-used on another page.

Of course, not all views are created equal. Maybe the sidebar view in our example is a lot less work than the main content view. That’s bound to happen, and it’s fine. The rule states that this will average out, and believe me, it will. For every super-easy “only took an hour and a half” view you find, you’ll get stuck with one that takes nearly twice as long as it should because you hit some silly browser compatibility issue.

Get used to thinking in terms of views.

There’s another reason for looking at the design in terms of views: That’s how implementation works. You start with the overall page architecture, build out a grid or column structure, and then tackle each distinct view one at a time. The developer’s standard divide-and-conquer approach.

Doesn’t it make sense to estimate the same way? By considering the design in terms of views at scheduling time, you’re estimating the same chunks you’ll be implementing. This will lead to more accurate estimates.

It will also make your estimates easier to defend if they seem too high. Write out a list of all the views in the design, and say “this is a breakdown of the implementation in one-day chunks”. If there are 12 chunks, that’s 12 days. You don’t even have to use the term “view”.

By throwing away the pages metaphor and instead thinking in terms of views, you’ll get better estimates that are more accurate and easier to track, and easier to explain to others.

There’s still more to learn!

We’ve only looked at the first interesting corollary from the Golden Rule. In part two, we dig even further to reveal the secrets of development.

Software Development Web Technology

Should You Support Classic Features or Should You Innovate?

A few months ago, the Internet Explorer team did a Q&A about IE9 via Reddit. While there were a few interesting items discussed, I almost did a spit-take when I saw this one:

Why doesn’t IE have a built-in spellchecker?

Are you kidding me? IE9 is going to ship without spellcheck? Ludicrous!

I immediately thought of all the typing I do in my browser every day, and how awful it would be to do it all sans spellcheck. I write my blog posts in WordPress. I comment on blogs. I consider proper spelling a necessity in my writing, and I simply can’t achieve it without a little help from my browser.

And it’s not just me.

Regular users are writing important emails, posting thoughts on Facebook, filling in online forms… How can anyone survive without spellcheck? What was the Internet Explorer team thinking?

I was really disappointed. Then I read the reply from the IE team:

Like any software project, developing IE is a trade off between features, quality and schedule. A built-in spellchecker would be a great feature that simply didn’t make the cut this time in favor of other things like <CANVAS>, <SVG> and other platform features.

Suddenly, I’m conflicted.

The SVG support coming in IE9 is a truly cutting-edge feature that really pushes what we can do inside a modern browser. And Canvas is no small feat either; people like me have scolded the IE team left and right for over a decade for not supporting open standards. These new features really are important to me both as a web developer, and as a browser-technology enthusiast.

So which is more important?

On the one hand, I really don’t think I can use a browser day-to-day that doesn’t have built-in spellcheck. On the other, I’m ecstatic that the Internet Explorer team is finally choosing to innovate and support new standards. I’m really not sure which side to take on this debate.

What do you think? Is it more important to support old, tried and truly-important features, or is it better to spend that time pushing the envelope and coming up with something new?

Software Development

Don’t be a NAMCO

I noticed a disappointing post via Slashdot the other day; apparently Namco has decided to force MIT to remove a PacMan clone made in Scratch. At face value, that probably doesn’t sound like a big deal to you, but that’s probably because you’ve never heard of Scratch. Allow me to explain.

Scratch is the future of programming education.

I’ve been teaching kids to program using Scratch for years (through OCRI). The reason we often choose Scratch is that it was made by MIT with the express goal of introducing students to programming and programming concepts (check out the About Scratch page if you’d like to learn more). The idea is that students who have never programmed before can create real, working software applications and share them online for other students to gain inspiration and learn from.

This is very similar to how real software development works. These students pour their heart and soul into creating something they care about, and proudly share it with a community that reacts to their ideas — adding features, remixing concepts, pushing the boundaries of what can and can’t be done. This is exactly how the web works. This is how kids learn.

Of course, if you’re Namco, that’s less important than preserving the copyright of a game that is older than almost everyone that uses Scratch (myself included).

Why is a Pac-Man clone important?

Several reasons:

First and foremost, it’s something kids recognize and can relate to. The tutorials for Scratch make some pretty bland applications, so to really push them to create something incredible, it’s important to show the students something they find impressive. The go-to applications for this are game remakes like Pac-Man and Tetris. Why? Because these games are instantly recognizable, and get students hooked on the idea of Scratch. They realize that with a bit of hard work, they can make something really cool.

Second, game remakes help the creative process. When you start with a blank slate, the idea of making something fun or interesting can be very daunting. Where do you even begin? For students, this can lead to frustration. Encouraging them to draw from other things they like helps narrow their focus without robbing them of choice. They can make something that they want to make, focus on solving the programming problems for that specific game, and make whatever creative changes they see fit along the way.

Finally, polished games are extremely difficult to write in Scratch (even something as basic as Pac-Man). These examples always contain interesting techniques and approaches to problem solving that show some really neat aspects of Scratch that I’ve never seen done any other way.

What does NAMCO get out of this?

You tell me. Do they really think people were lining up to play a Scratch version of Pac-Man? Are any of these (likely non-existent) people going to go out and buy a copy of Pac-Man from Namco now that the Scratch version has been removed? Other than ruining something that means almost-nothing to them and a whole hell of a lot to people like me, what exactly does Namco expect to accomplish?

What if they took the opposite approach. What if they decided that, copyright be damned, it’s awesome that 30 years later people still find the original Pac-Man fun. What if instead of being appalled, they were honoured that someone chose to learn to program by reproducing one of their games. Can you imagine a world where rights holders and every-day people with no intention of ripping anyone off worked together to promote culture and innovation? Because that’s not what I see here. I see a company that has its priorities so ass-backwards that it’s targeting a platform whose sole purpose is to help children learn.

Don’t they have better things to do?

Software Development

How Much Longer will it Take?

Let’s talk about re-estimating software projects. Here is a situation I find myself in every now and then:

Say I’m the lead/best/only developer on a project, and partway through that project, we realize that we’re going to miss an important deadline. My manager will come to me with a question that I absolutely dread:

How much longer will it take?

It’s a perfectly fair question. Since I’m the lead/best/only developer, I’m in the best position to estimate how much more time is necessary, and my manager needs this information to make important decisions (add more people? talk to the client? etc). But it’s extremely difficult to answer! If the initial estimates (which I either came up with or approved) are wrong, how am I supposed to magically come up with better, more accurate ones?

The most important thing is to not answer on the spot; a great manager once told me that the best answer any time anyone asks you for an estimate is always “I’ll get back to you” and he’s completely right — there is absolutely no way you can put together a sensible estimate off the top of your head. Ever. You’ll always have to do a bit of math and take a few things into consideration, so give yourself time to do those things.

Now, let’s talk specifics. There are three main approaches I’ve seen myself and others use to re-estimate a project. For the following examples, let’s pretend that you’re in charge of a project that was initially estimated at 10 weeks, and after 5 weeks of work you find yourself 1 week behind schedule. How much longer will it take?

The Naive Method

The knee-jerk reaction that you might even say out loud if you answer on the spot is that you’ll need 1 extra week for a total of 11 weeks. The naive thinking here is along the lines of: “hey, we’re 1 week late, so give us 1 extra week to make up that work and everything will be fine”. The problem here, of course, is that if you have been late on your initial estimates for the first 5 weeks, you’re probably going to be late on your initial estimates for the next 5 weeks as well. We need to account for more than just the time missing so far. This brings us to:

The Logical Method

You may be thinking that the correct answer is 2 extra weeks for a total of 12 weeks, since if you need 1 extra week after the first 5 weeks you’ll probably need 1 more extra week on the 5 remaining weeks. That’s no longer a naive answer (it’s indeed logical) but your math is flawed and we can do a bit better.

Look at it this way: it took 5 weeks to do 4 weeks’ worth of work. So after 10 weeks, we’ll have done 8 weeks’ worth of work. Historically, if 4 weeks’ worth of work takes 5 weeks, then that last 2 weeks’ worth of work will actually take 2.5 weeks. So what you should be asking for is an extra 2 weeks and 3 days (always round up) for a total of 12 weeks and 3 days.

Now we have an entirely logical answer, and by all accounts you should be able to tell your manager with confidence that the project will be done after 12 weeks and 3 days. But here’s the thing — you’re probably still wrong. The fault lies in the very concept of estimates: you’re assigning a logical, mathematical number to the actions of real people with real lives and real feelings. If your team was entirely composed of robots, then yes, the logical answer is probably a great estimate, but that’s not how teams work. There are a number of estimate-affecting factors that the team dynamic adds:

  • Some people will work longer days, evenings or weekends.
  • Some people will “speed things up” by skipping test cases or code review.
  • Missing milestones affects team morale.

None of these are always going to be good or bad for the project schedule, but it is foolhardy to ignore them outright. That’s why I believe in:

The Human Method

This is where it pays to know your team.

The idea is to take the proper logical answer, 12 weeks and 3 days for our running example, and tweak it based on the team dynamic. Does one of your fellow developers step up her game when the project falls behind schedule? Knock a day or two off the re-estimate. Do you have a teammate that gets easily overwhelmed? Add a day just in case. Is a stakeholder in the project going to want to have frequent meetings about why the project is late? That’s another day or two as well. You might be surprised at how things stack up: maybe it’s not as bad as you thought, maybe it’s much worse. But at least now you know.

Of course, you can’t always predict everything about your team, so sometimes you have to ballpark the team-dynamic chunk of the re-estimate. The best thing to do in this case is to err on the side of caution and add a buffer — something in the 20~30% range. For our example, that means adding another 25-ish% of the 2 weeks and 3 days that we’ve already added, call it 3 more days, bringing us to 3 weeks and 1 day. This means that our originally-estimated 10 week project is actually going to take a little over 13 weeks. Probably longer than what your manager was hoping for, but at least now we have some numbers to back it up.

And what’s your alternative, really? Make something up off the top of your head?

Software Development Web Misc

Motivation Overflow

Let’s talk about motivation.

I recently joined Stack Overflow (here’s my profile) and one of the things I noticed right away is how easy it is to spend time there. I think I’ve checked in every day since I joined, and in ten days I’ve already answered fifteen questions. Now, before we discuss whether or not I’m developing an unhealthy addiction to social networks, I’m sure some of you are wondering what Stack Overflow is — let’s sort that out first:

Stack Overflow is a place where people can ask highly technical questions about computer programming and related topics, and get answers from a community of well-qualified geeks such as myself. When I log on, for example, I scan over a few dozen questions and answer any that I feel qualified to weigh in on. It’s free, self-organized, and completely voluntary.

Now, back to the issue at hand: why would I choose to volunteer my valuable free time answering other people’s questions? Or more specifically:

How does Stack Overflow motivate its community of users?

We’ll get to the answer in a moment, but before we do I’d like to take a moment to mention that I recently read Dan Pink’s Drive, a fantastic book about modern theories of motivation. I highly recommend this book. It’s an easy read that’s full of all kinds of useful information, and I’ll borrow a lot of its concepts and jargon in the remainder of this post.

Stack Overflow implements a wide variety of motivational techniques. For starters, all users have a “reputation” score which is basically a fuzzy measure of how well the Stack Overflow community trusts you. You earn reputation by asking and answering questions, so users that participate more actively in the community will get more reputation. Already that’s a form of motivation right there; the more you do for the community, the more reputation you build up.

Specifically, you gain reputation when you do positive work for the community. Users can vote on each others’ posts, so a good answer that gets a lot of votes will grant more reputation than a mediocre or weak answer (and likewise for questions). It’s very encouraging to see your answers get a lot of votes, and this sort of now-that reward (now that you’ve provided a good answer, we’ll boost your reputation) has been proven to be a repeatable tactic to motivate good behavior.

Similarly, good behavior is occasionally rewarded with badges. For example, if you answer a question and your answer is up-voted by ten different users, you earn the “Nice Answer” badge. This is known as an if-then reward (if your answer is accepted by many of your peers, then you get this badge added to your profile) and is historically a very effective technique for short-term motivation. Stack Overflow does a couple of things to keep badges relevant in the long term:

  • Some badges are extremely hard to earn — I’ve seen a few that have only ever been awarded a few dozen times.
  • Some badges can be awarded multiple times.

These conditions mean longtime users still have something tangible to strive for, so the motivational boost generated by badges doesn’t dwindle over time.

But rewards aren’t the only things that motivate us.

So far we’ve looked at the measurable ways that Stack Overflow motivates its users, but there are a number of non-measurable motivators as well. For example, the higher purpose of helping others and contributing to a database of valuable knowledge is a strong intrinsic motivator, and studies have shown this type of motivation to be the most powerful. On a basic, human level, we like to help each other out and do good work. Stack Overflow is an outlet for these tendencies.

Likewise, we enjoy pushing ourselves to master various skills. Like the carpenter who perfects his craft over years of experience, it’s rewarding for geeks like myself to hone the technical and communicative skills required to answer challenging technical questions. Not only do I learn something new every time I log on to Stack Overflow, I teach something new as well — this knowledge-transfer cycle is something I simply crave.

Let’s discuss this a little more.

If you’ve spent any time on Stack Overflow, I’d love to hear your take on this. Do you find yourself motivated by the factors above? Did I miss an important motivator that really drives you to contribute to the community?

Better yet, did you stop visiting Stack Overflow because you found it boring or uninteresting? What motivated you to leave?

Software Development

Ottawa High School Technology Program Winter 2010 Wrap-up

As some of you may recall, I volunteer with the Ottawa Centre for Research and Innovation in a program that aims to teach high school students how to develop real, working software. I’ve mentioned this before (in fact, I have an entire page dedicated to what I do with OCRI), but I haven’t really been blogging about it much (read: at all) this semester.

Fortunately, my co-mentor for the past twelve weeks has. I present to you:

I’m not sure why I didn’t even check in once over the course of three months, but I’ll try to actively post about it next time around. This is something I like to talk about.

Finally, this season’s program ended last night with the annual showcase. This event allows students to demonstrate their final product, (hopefully) running on a real XO Laptop, to friends, family, mentors such as myself, students from other schools, and various representatives from OCRI. It was a fun time, and as always, the ability of students that are often being exposed programming for the first time to crank out creative, engaging applications is absolutely stunning. I couldn’t be more proud of the students I’ve worked with and the software we’ve created.