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.

GUID Socks: Closer to Reality

Waaaaaaay back in the day, I wrote about creating pairs socks tagged with globally unique identifiers (GUIDS) that would allow you to match up pairs of socks for neat, orderly folding. I remember being pretty enamored by the idea the time and started working on some spiffy second-generation designs where the GUID was translated into visually distinct patterns. I even had the beginnings of a promotional website made, to sell the world on the wonders of cryptographically secure socks.

Alas, that idea has yet to fully come to fruition, but as I was deleting some spam comments from older entries of this blog, I stumbled on this gem of a comment from someone going by the moniker 'Jon':

Hi, I got the very same idea and decided to google it and ended up here.

The question here is how to automatically feed the sock machine with new data for every pair. I need to check with a manufacturer if its possible. :)

Sometimes, the internet is pretty awesome.

Recruitment Meeting

This picture is in no way related to the content of this blog post.

UW iGEM had its recruitment meeting today. It was fun times! But I really need work on my presenting abilities; I find I'm really hit-and-miss in my ability to actually convey information while speaking to groups of people. This doesn't come as a surprise, I was always consistantly bad at "verbal communication" as the elementary school report cards would call it, at least by the crazy perfectionist standards of my youth. Nonetheless, I like to avoid being "that guy that gave that talk that nobody understood" whenever possible.

I find it interesting that the fields I'm working in now, both at iGEM and in co-op terms tend to be the interdiscplinary/academic/cutting-edge-no-one-really-knows-what's-going-on fields that are prone to having miserably unintelligible talks. I've sat through a lot of these talks now and they're fairly painful, so painful at times that it's tempting to simply say that the presenter stood no chance and that the topic was simply too complicated to communicate in the available time. Of course, then I go off and watch some TED talks and realize that you can describe pretty much anything worth describing in twenty minutes if you're just that good.

Postscript: I was just about to post this and was looking through what tags to apply, when I realized I have an existing "Painfully Bad Poetry" tag. We were discussing painfully bad iGEM poetry for some reason or other at today's meeting and, well, I have the tag, so...

iGEM (a haiku)
the title counts as a line
oh shoot, out of room

Okay, this next one's the real haiku, not that that previous one wasn't (also, non-iGEM people, iGEM is pronounced "I gem", which is ironic given its silly capitalization which I've probably ranted about before).

lots of little cells
and biology stuff, woot
will sell soul for sleep

Change is Painful

(click for larger image)

As you may have noticed (or heard me complain about on Twitter), Google recently added a sidebar to the left of their search results. Now, I know some other search engines (named Bing) already have such a sidebar and, in fact, it's not a look that I have any innate hatred for. I generally appreciate designers' attempts to improve software interface, even in such controversial cases as the Microsoft Ribbon or one of the many Facebook Updates.

But I draw the line here.

Google has always had a good interface. A little textbox, search button, and a list of results. It was genius! Even one of those drinking bird toys could probably figure out how to use it. The new sidebar doesn't actually take away any functionality, but at the same time it doesn't do a whole lot. We're helpfully informed that we're searching through "everything" and have the option of narrowing that down to videos, or clicking the little expandy arrow thing to see a big ol' list of things including "updates" and "shopping" to search through. There's also another little expandy arrow thing below that allows you to see options like "wonder wheel", "social", pick a time period to search through, or display fewer or more 'shopping' results.

All well and good, but there already was a toolbar at the top of the page that allowed you to refine your search and the advanced search box provided access to the other fancy Google options. I can see why Google might have wanted to expose more people to the more advanced search options, but well... years of using Google have trained me to look at the spot right where the sidebar is for my most relevant search results and now I am left staring at a cheery 'Everything!' notice instead of useful information. My eyeballs do not want to be retrained, Google. If they did, I would have switched over to Bing when it came out.

It's a bit disturbing, really, how much this slight change frustrates me (to the "I have a headache from looking at this page" degree). It emphasizes how much time I've really spent on Google and how easy it is for little icons, properly placed, to completely distract me from the information I actually need. Some would say this is a wake up call. I think I'll just hang on to the old version of the site, while it's still around.

Bonsai Trees

My dad's been toying with a little bonsai tree for a while. His bears no resemblance to the above sketch; in fact, it's actually a lot cooler looking because it bends down to be parallel to the ground and lines up with its oval pot. It's not fully styled though, which means that it still basically looks like a potted plant instead of a potted tree. We spent some time today trying to figure out what parts to clip off to make it look more tree-like, but it turns out to be pretty difficult to visualize what effect the clipping will have until after its done.

Edit: As a side note, the sketch accompanying this post is the latest in a long line of proofs for my "drawing foliage is hard" conjecture. I tried to draw this one really quickly because (a) as usual, I want to get to sleep and (b) I'd like to be able to use foliage as a subordinate element in visualization sketches.

Edit 2: Bonsai tree, version 2: