Parachuter

Just a doodle because I don't have much to do (aside from work-related things and, as it's a Friday late evening — or very early on Saturday, take your pick — those things can wait). This isn't a "journal doodle" or anything like that... although if anyone wants to jump out of some planes it could become one.

EDIT: After posting the first image, I realized I made some significant technical errors in my depiction of the parachutist's neurophysiological response to the fall. Here's a correction.

How Recruitment Should Work

"We're kidnapping you for your own good. Promise. Write the code and you'll get flatbread."

Yup, the fall term's about to start. It's probably about time to start working on that fancy recruitment campaign for iGEM that we keep dreaming about... but don't worry non-iGEM people who read this blog (hi family!), I'm planning on writing about something else here.

And that something else is...

Things That I'm Going to Rant About to New Students

I don't really see myself as the ranting type in general, but there's something about getting a fresh, naive, relatively uncynical, and slightly puzzled batch of new students that brings out the old curmudgeon in me. So, in list form, the things I'm going to be giving today's generation of youth an earful about are:

1. The definition of engineering. It perplexes me how many people get to third year engineering and then act surprised when they find out that engineering is the profession of applying scientific and mathematical principles to practical problems. Even in systems design, which is basically the study of distilled engineering ideology abstracted away from specific domains, there are still people who think it's all about hard hats and accounting. Yes, that's a part, but... well... if that's your image of engineering, you are a personal pet peeve of mine.
2. Time hoarding. There's time management and then there's being a wuss. I know you've heard the failure rate statistics. I'm sure you've been told it's wise to cut back on extra-curricular activities until you get used to the workload. That's garbage. The easiest way not to fail out is to keep trying to maintain your stupidly over-acheiving lifestyle that got you into university in the first place. If you lower your standards down to "just trying to pass" in first year, you'll never recover. This is a somewhat controversial point and your mileage may vary; nonetheless, you don't have much to lose in first year. Now taking on extra work halfway through second year is a different story.
3. Ability to write. I know, I know. Given the poor standards of this blog, this point's a bit hypocritical, but I stand by it. My standards are not high: just catch the blatant typos and missed articles and use apostrophes more or less where they should be used. You can throw in semicolons, commas, and colons wherever you want. Deal?
4. Stop whining. You only get to make lists like this when you're at least half done your degree and even then only once a term. Grad students are allowed unlimited whining, but they've earned it.
   

Alternate Reality Campus

I'm not sure what prompted this, but I've had this idea of a "University of Igloo" floating around in my head for a while. I think I originally thought of it as a satire of the University of Waterloo's big rebranding efforts, but I didn't get around to developing it into an actual parody. So here's some guy chilling next to an igloo in the summer.

Post-script: It pains to me admit this, but I originally accidentally capitalized igloo as 'iGloo'.

Posters!

According to some posters I saw on the wall, the end of term concert for the University of Waterloo's acappella groups is July 23rd at 8:00 PM in the Theatre of the Arts. I don't know if I'll have time to go, but it should be fun times!

EDIT: Oh, hey, also: it turns out that July 23rd is also the day of the Engineering Jazz Band Charity Gig! Yayyyyy. The jazz band will be playing sometime around 6 PM (I think, details coming) at Waterloo Town Square. As a member of the band, I will probably be there. See both the jazz band and a cappella concerts and get your fill of music for the whole year in one day!

EDIT 2: Still looking for things to do on July 23rd? You could catch a webinar about using Matlab to process large datasets around 2 PM before heading to the afternoon/evening concerts. I know I'll be watching... or, probably not actually... but someone might find it interesting.

Public lectures and I found my stylus!

Yessssssssssss. That is the sound of me rediscovering my tablet computer's stylus. You don't realize how expensive a piece of plastic can be until you start thinking you'll have to replace one. Fortunately, I don't have to replace one, so here's a celebratory doodle:

Click for larger sketchy drawing!

The iGEM team (next post, I'll stop writing about iGEM in the next post) hosted a public lecture today about synthetic biology. There were a ton of people there which was pretty awesome and various misconceptions about the recent Venter Institute announcement were addressed. I did get the feeling the panel was preaching to the choir a little bit about some issues, but with the number of people there, I'm sure the topic was new to a sizeable group.

In other news, I appear to have pulled a gluteal muscle for no apparent reason. This is not so fun. I would go so far as to recommend against pulling such muscles, in fact!

Let's All Learn About iGEM Software! Yay!

This is one of those posts I wrote for my own benefit, not some hypothetical readership. This will likely be apparent. You have been warned.

I was originally planning on writing about something else and including my standard doodle with this post, but my Google search for reference images seriously grossed me out and I don't have time for that. Instead, here's a post about iGEM software which will force me to do some useful research instead of looking up eye-rending images on Google. Yay!

If you don't know me and are new to this blog here are some explanatory links about iGEM. With that out of the way, what's up with this year's Waterloo iGEM software project? Well, we're working with a BioCompiler concept that roughly translates to: take code, apply genius, extract BioBrick assembly instructions. A compiler, in a computational context, takes code and translates it into equivalent code in a much more primitive language and what we intend to do is an exact analogy of that process for biological systems.

We haven't gotten very far with this design yet, but already there seems to be a canonical example of the goal in the form of the pseudocode "if the concentration of (something) exceeds (value) and the concentration of (something else) is less than (another value) then produce [something]". I wonder how much complexity would be involved in simply translating specifications that meet the above template into assembly instructions; intuitively, I don't feel it should be too excessive, but there is already some possibility for conflicts between the signalling pathway of "something" versus "something else" and this system would already probably be pretty tricky to construct. Following this vague syntax, our working design for the main 2010 project would fit the template "if (something) is present, produce (something else); if the concentration of (something else) is above (constant), produce (yet another thing)". That's an almost trivial piece of code, but it's already pushing the limits of what we can model and what we can construct. Whether this a ringing endorsement of the BioCompiler concept or an outright condemnation, I'm not sure.

The BioCompiler concept is both really exciting and worrisome at the same time. Worrisome, because in order to pursue the BioCompiler idea we'll be discarding work done by the software team of the previous term which sets a bad precedent for continuity. Moreover, this project will definitely not be done before the end of the term, so we'll need to depend on the software team from the opposing stream to continue it. On top of the "sorry I killed you project" factor, it also bugs me that this isn't a project I could conceivably sit down and write myself given a couple weeks. I mean, I realize that it's a good thing that we have an ambitious project that will involve more than myself, and I never had any intention of literally writing the whole software project by myself, but at the same time I like being able to deliver tangible results and this project has no guarantees of delivering those results any time soon. Nonetheless, optimism run high.

Okay. That was all a long diversion because the point of this post was for me to force myself to read and talk about UC Berkeley's 2009 software project. Their project had four main components, all of which are helpfully embodied by silly characters in their documentation. Eugene, the "red-headed stepchild and language", is a formal way of describing BioBrick components. His glasses, Spectacles, are (represents? is? this is where the anthropomorphization of the software modules becomes frustrating linguistically) a tool for visualizing Eugene's data. Kepler is a "Wise Astronomer and Workflow Wizard" which is to say that it's the part of the project concerned with the assembly of parts and it/he actually guides a robot through the assembly process. That was bold and italic because it's that mindblowing. Finally, Clotho (AKA the Hot Green Chick) is a "Greek Goddess and Software Tool". Say what you will about Berkeley's documentation, at least it's memorable (and actually the rest of their documentation is decent as well, including design notes from team members and demo videos of some of the software products).

Anyway, Clotho, yeah. Clotho is an attempt to span the design hierarchy between the parts-level design that Kepler, Eugene, and Spectacles work at and the systems-level and device-level design that engineers like to think at. Actually, upon re-reading the Berkeley page, it appears they believe Kepler, Eugene, and Spectacles operate at the device-level. Huh. It also appears that despite lofty aims at hierarchy-spanning behaviour from Clotho, that module is a simple data management system. It might help you organize your thoughts at varying levels of abstraction, but it certainly won't take ideas written at one level and push them to another. That, I guess, is where we come in.

Alright folks, I'm falling asleep so this is as far as we come today. If you've read this far, I... well I don't know what to think. I'm assuming you haven't read this far. Maybe you cheated and skimmed to the end. In any case, thanks for bearing through it and hopefully everyone learned a valuable lesson about iGEM software. Yay!

What's Wrong With Wave?

Wave fail.

When Google Wave first came out there was a ton of excitement surrounding it. I was never fully persuaded by the hour-long introduction video, but I was still an early adopter (in the limited pre-beta beta release, or whatever Google called it) and a relatively enthusiastic user. I've tried playing Sudoku on Wave. I've tried having various group meetings on Wave. Some of these experiences were moderately successful, some of them led to failed projects (goodbye ISC 2010), and ultimately Wave seems to have failed to catch on.

Now, granted, it's still in a beta version, but I don't want to dwell on Wave's prospects. I'm simply surprised that its talented development team (former members of the Google Maps team) were responsible for its confused interface design, identity issues (the hour-long intro should have been a tip-off), and (improving, but still bad) performance and reliability.

I'm not sure what lessons to draw from the struggle of the Wave team. That even the best developers in the world still fail sometimes? That earlier validation of designs is necessary? That addressing problems in existing solutions is a disastrous method for innovation if you don't consider the new problems you're introducing? I could probably go on for a while but the thing is, as easy as it is to identify problems with hindsight, I don't know (and can't know) if I would have caught these things had I actually been involved in the design of Wave.

Companies are often happy to boast about their successful design strategies and crazy new innovation paradigms, but there is an obvious selection bias at play in the reporting of these strategies. Who's going to give a TED talk on "Industry-Standard-Centric Design"? Or "Useless But Totally Cool Sounding Paradigms"? Actually, that second one might be a real TED talk, but generally speaking, despite a trizillion books about it, there are not many trustworthy resources about software project management.

EDIT: This just in, other people are writing about interestingly related material! Specifically, lessons learned from failed software products.