Energy Consumption

Apparently US data centers consumed 61 billion kWh in 2006 (according to this EPA report (PDF)). That sounds like a big number, but I like to judge these things by my favourite Big Energy metric: how much mass would you have to completely annihilate to get that much energy?

Well, assuming I crunched the numbers correctly (ie, assuming I can blindly trust Google's calculator), that amount of energy can be expressed as 2.196*(10^17) joules, which, when divided by the speed of light squared yields: 2.44 kilograms.

Given that the same EPA report claims that this energy usage statistic accounts for 1.5 percent of the total US electricity consumption, that means that to power all of the US for a year, you would need to annihilate 2.44 divided by 0.015 = 163 kg of matter.

That strikes me as a remarkably high number. It means that if I were to encounter my antimatter twin (and both of us weighed somewhere around 68 kg), even if we did fully annihilate each other and even if all the energy from this event were captured (and stored perfectly until needed), this would only power the US for somewhere around 300 days.

This saddens me, because it means that my human-antihuman power supply will require a disturbingly large number of sacrifices to keep running.

Best day... ever?

I was hoping to write a proper post about this, but I am somewhat too tired to do so, so I'll resort to posting a schedule of the day.

9:00 AM: Brain Day starts, introductions to talks by...

9:15 AM: Sebastian Seung (MIT) [I am my connectome TED Talk, on Youtube].

10:45 AM: Peter Strick (Pittsburgh): Motor control and basal ganglia / cerebellum topography.

1:30 PM: Jonathan Cohen (Princeton): Adaptive cognitive control.

3:00 PM: Ned Block (NYU, Philosophy) [On Consciousness Youtube clip].

[End of Brain Day]

7:00 PM: Perimeter Institute lecture by Roger Penrose [Discover Magazine article]

10:00 PM: Read web comics. There was a good crop today!

EDIT: Apparently Ryan North of Dinosaur Comics was also at the Perimeter Institure lecture. I'm kinda disappointed I spent too much time listening to the lecture to notice this.

Popular Neuroscience

This is a personal blog, it is not necessarily a reliable source of information.

I don't normally talk about the work I do on co-op terms, because I don't want to accidentally offend my employers by telling everyone how horribly nice they all are or making the similarly unfortunate error of posting confidential information. However, as I'm currently working for a neuroscience lab and it is pretty awesome I figure it couldn't hurt to write a series of posts about neuroscience stuff. Now, having said all that, here's a confidential training video:

Okay, so that video wasn't actually confidential, but I did steal the link from our lab forum. Now, Cleese's talk is pretty advanced (though quite entertaining), so I'm going to take a step back with a short Q&A (I'm not one to pass up an opportunity to talk to myself).

Q: What is neuroscience?

A: It's the study of the nervous system, nominally. In the long run, neuroscience, psychology, cognitive science, biology, and computer science are all intricately linked in a crazy quest to understand the way we think, the way intelligence and information processing in general works, and how it all somehow works with physical, biological components.

Q: Is neuroscience really that similar to cognitive science? Isn't it really just biology, but concentrating on the nervous system / brain?

A: I'm not very good with all the research classifications in the area, but it seems like most of what's being published under the label of neuroscience is neurobiology. From an experimental perspective this certainly makes sense: the brain is biological, after all, so obviously a substantial amount of the work being done in reverse-engineering it involves biology. Ultimately though, we're largely interested in the functionality of the brain and the way it gives rise to the interesting, complex interactions we all know and love: calling this functionality 'cognition' and attempting to understand said functionality is more or less what cognitive science is about. There is a big gap in understanding currently between neurobiology and cognitive science which is (to grossly and incorrectly simplify things) what theoretical neuroscience is puzzling over.

Q: tl;dr

A: Grr. Ok, look: biological understanding of brain = improving, but massively, insanely complex already and not capable of explaining brain function. Cognitive science = good at finding ways to do specific things; lacks general theories and can't compete with real brains. Gee, it sure would be nice to have people working on some combination of the above things! Those people would definitely deserve enough funding to pay their co-op students. Big time.

Q: I'm not convinced. What's the point of taking multiple different (and possibly conflicting) approaches?

A: First, which one's 'right'? I dunno. That's pretty much answer enough: they both provide more information, thus they're both valid approaches. If they happen to conflict, even better: there would then be an opportunity to investigate and fix problems that are found with the theories. That's pretty much how science works.

Q: Fine, fine. You can start at either the biology or psychological/cognitive levels, I get that. How could you possibly work from the midpoint between the two levels outwards?

A: This conversation makes more sense when it's less abstract. Instead of talking in terms of a 'midpoint' between two different research areas, I should really have framed this as a need to go beyond current empirical biological data to build more functionally complex models. Instead of making hypotheses based solely on raw data, you can start making predictive models constrained by assumptions, information processing requirements, simplifications required for tractability, and so on...

Q: Sorry to interupt, but isn't this post way too long already?

A: Yes.

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.

1 down 20 left

I just finished a linear systems and signals problem without looking at the solution: feeling pretty good about life.

Quizzes, More Quizzes, and the Glowing Sidewalks

I had a bunch of rather stressful quizzes (aka midterms, except that they aren't necessarily in the middle of the term) in the past couple few days. On the plus side, I also had a couple midterms returned that I did reasonably well on. It was particularly interesting to finally see how marking works in non-engineering faculties (disclaimer: note that one midterm can't fairly be used to extrapolate to all courses taught by all non-engineering faculties, but I'm going to do so anyway). For one thing, the marks were quite high: an average of 78%? A top mark of 100%? Only one failure? Preposterous! But aside from that, it was weird to see comments like "good, but too short" instead of "good: 10 marks" or "wrong: zero out of ten". Oh subjective marking, how I've missed you.

Disclaimer 2: engineering does actually have subjective marking. It's currently mostly relegated to a certain online professional development course; still, even mathematical courses usually have some degree of subjectivity. Incidentally, that certain online professional development course has recently been the subject of an independent review (PDF) which is an informative read for anyone interested in such matters.

On a completely unrelated topic: there's a tutorial on Instructables about building a pressure sensitive glowing sidewalk as seen in Michael Jackson's "Billie Jean" music video (obligatory link to the official YouTube copy of the aforementioned video). Fun times.

You Don't Know Slow

Driving below the posted speed limit is not slow. The pace of the "Fellowship of the Ring" book was not slow. A snail dragging a brick is not slow.

Then what is slow, you ask, if not these things? A computer program to simulate all possible recombinations of a couple strands of DNA, is what. Specifically, the current implementation of the Recombinatron project I've previously posted about.

We've known for a while that the program was slow. There was talk of "factorial run-time" and "exponential growth" but we didn't really pay that much attention to these things. Time's too short to waste it figuring out Big O notation when you could instead just run the program.

On a computer with 12 GB of memory.


And wait eight hours as the program stalls on step 4 of 255.

...

...

...

It turns out the program's pretty slow. Not "man, FancyApp 2.0 sure is slow" slow, but "man, this won't even be halfway done before the sun dies" slow.

Playing with Transformers

I'm on vacation now. Naturally, this means that I no longer have to program, or do circuits labs, or build cardboard bridges. Equally naturally, I'm hoping to get some programming for iGEM done and maybe start a woodworking project and play with electrical stuff...

It was while playing with electrical stuff recently that I found out just how little I actually recalled from my class in Electricity, Magnetism, and Optics (EMO). I mean really, how hard can it be to hook up a fluorescent light? (Answer: if you don't have the ballast, good luck with that.) Even making LED circuits involves a surprising amount of calculation which, engineering student that I am, I immediately delegated to an online designer.

My dad also keeps a box full of random parts salvaged from various radios and computers. This is pretty cool. The box had a few transformers in it, so we decided to test one by hooking a battery up to one end and a multimeter to the output wires to see what we obtained as output voltage. At this point, the electrical engineers reading this (and who have seen the image at the top of this post) can probably guess what happened.

Nothing happened. At least not at first: we had connected the battery, then I connected the multimeter probes, holding them to the output wires of the transformer with my fingers. My dad then removed the battery, and I jumped out of my skin. Fortunately, even with the transformer, the shock from the AA batery was far from deadly.

So what happened here? Why, and this is becoming something of a theme on this blog, am I such an idiot?

The thing is, transformers are meant to be used with alternating current (AC) and not direct current. The reason for this is pretty simple: the transformer consists of two coils of wires which are, as wikipedia says, inductively coupled. And, as I should have known, the induced voltage in an inductor is proportional to the rate of change of the magnetic flux through it. With the battery attached, there was no change in current, therefore no change in magnetic flux and no electrocution. Remove the battery, however, and things do change.

There's nothing quite like a light shocking to act as a remedial science lesson.

Scaring the First-Years

Run. Now. Get out while you can. Drop out of engineering and go into an arts program. Calculus is difficult. The economy sucks; you'll get a co-op job counting packaging peanuts. Friends, sleep, or work: pick work. The cafeteria food is made of recycled plastic polymers. The Canadian geese will kill you and defecate on... well, you get the picture.

If you're just starting university, all you need to know is that you can't trust anything older students tell you. Except about the geese; that part's more or less true.

(Text)book Review : Signals & Systems (2nd Ed)

I've been looking forward to taking Systems & Signals for a while now, so when the official textbook for this year was announced (surprise! it's the same as last year's again), I went and picked one up.

And yes, I know it's a bit weird to get textbooks over a month before the term starts. And I realize that I probably won't get all that far before the term starts. And I realize that the promised 'review' in the post title will be weakened slightly by the fact that I haven't yet read the book.

But I think there's some value in giving my impressions of the textbook now, before the long and presumably difficult term that is to come goes and spoils my appreciation of it. Or maybe this will help someone deciding whether or not to buy this book at all. Or maybe I'm just crazy. Regardless, I've stalled enough, so on to the review...

The first thing you'll notice with this textbook is that it's remarkably plain. Gone is the translucent periodic table inserted into the chemistry text, gone is the lovely layout design of Linear Algebra and Applications, gone is the marketing spiel, the learning aids and the motivational pictures of Fundamentals of Physics.

It is, in short, not a first year textbook. There is nothing about it really that makes you want to buy it, or feel good about having bought it, or waste your little attention on it. By this point, the makers of this textbook know, you're damn well going to buy the textbook. The alternative, after all, is to flirt with failure and the chance to buy the textbook the second time around.

I'll admit to not being overly impressed with my initial glance through the book, but first impressions aren't everything and, as much as I like textbooks that will compete for my attention, it's really more important that they cover interesting material.

So what material does S&S cover? From the table of contents...

1. Signals and Systems (duh)
2. Linear Time-Invariant Systems
3. Fourier Series Representation of Periodic Signals
4. The Continuous-Time Fourier Transform
5. The Discrete-Time Fourier Transform
6. Time and Frequency Characterization of Signals and Systems
7. Sampling
8. Communication Systems
9. The Laplace Transform
10. The Z-Transform
11. Linear Feedback Systems

Now, I realize that list might not strike everyone as fascinating reading; but honestly, Fourier transforms are pretty awesome. Especially reverse ones.

Recommendation : If you're not particularly interested by signals or systems you'll probably be slaughtered by this course anyway, but I would suggest getting the book. It's an old edition so you can pick it up second hand and it could be handy if you ever need to brush up on fancy signal transformation stuff before a job interview.

If you do like systems and signals, then this should be a pretty easy decision. Unless of course, you're really into them, in which case maybe you have a shelf full of signal processing books already.

Keeping Your Sanity (Blanket)

This has been a pretty crazy week for me, which I could rant on for a while about but I've used my 'rant' tag a lot lately so instead I'll just say that I saw EngPlay today.

EngPlay is a once-a-term tradition here and, as the infinitely subtle name sneakily reveals, it is a play put on by engineering students and for engineering students. There is a lot of innuendo, some clever lines, a lot more innuendo, some decent acting, and a bunch of swearing.

It's one of the three events that I look forward to each term, along with the SyDE coffeehouse, and the end of term engineering jazz band gig. Of course, there are other high profile events, including the SCavenger hUNT, Bus Push (ceremonial hauling of a bus for charity), TalEng (talent show), the Water Boys (a cappella group) end-of-term concert, the Accent (jazz a cappella group) end-of-term concert, and so on, and so on...

Yes. Stay sane, kids. Stay sane.

RECOMBINATRON!

I spent the whole day programming for Waterloo's iGEM team. iGEM, for anyone who doesn't know, is the International Genetically Engineered Machines competition hosted by MIT, the goal of which is to figure out ways to design useful things out of biological components.

There's a subtle but important difference between iGEM's philosophy and conventional biotechnology, and it lies in the issue of design. People have been able to do things like getting bacteria to produce human insulin for a while now, by taking the human gene for insulin production and inserting it into the bacteria. What we haven't been able to do is to really understand the genes that we're dealing with.

Biological parts have been impenetrable black boxes: if something comes out of that box that we can use, that's great, but more often than not we would like to get into that box and tinker. What's more, these parts don't tend to play well with each other, and all sorts of chaos ensues when you start mixing together genes.

iGEM's approach is to create new biological parts. Parts that are not massively complex genes, but simple, reliable, reusable components that have intended purposes and known effects with other components. The goal, really, is to allow for true genetic engineering instead of genetic experimentation.

This isn't to say that all genetic parts created for iGEM are simple or reusable and it certainly doesn't mean that all that many of them are reliable, but we're working on it. The project I was coding today, for example, is intended to allow the team to predict the results of certain biological reactions, the end goal of which is to develop a repeatable method of inserting genes into chromosomal DNA.

At least, I think that's what it's for. Biology hurts my brain.

WIE!

While half researching and half procrastinating on a professional development assignment (oh yes, we have professional development assignments... but that's a whole other blog post) I stumbled upon another blog called "This is What an Engineer Looks Like".

It seems to be a collective blog written by various women in engineering most of whom seem to go to my school (the University of Waterloo). So there you go, check it out.

EDIT: I forgot to explain what 'WIE' is: it's an abbreviation of "Women In Engineering" and is the name of various organizations dedicated to the women who study engineering, the largest of which is probably IEEE WIE.

Rob's in Malawi

And you can read all about it at http://robinmalawi.com/.

Design the System

(click image to see full-sized)

I knew a guy back in high school who had one of those "F--- the System" shirts. He was a pretty cool guy and he managed to get away with the blatant infraction of the school dress code that occurred each time he wore it.

Still, as fun as it is to wear slogans like "eff the system", there comes a point a in one's life, around the time when one enrolls in a systems design engineering program, when such slogans start losing their appeal. It's pretty hard to stick it to The Man and The System when you're the guy who's supposed to be designing the system.

It's a frightening thing realizing, after all these years, that you're The Man everyone's been printing angry t-shirts about. "Look," you want to say, "the System's not that bad, all right? I mean, okay, it sucks a little, but I'd like to see you do better and hey! Stop making those hand gestures at me, you little twits!"

The point is, it's easy to criticize and it's even easier to not criticize and just ignore things, but when it comes down to actually fixing problems things get a bit more complicated. Now, I'm obviously biased, but I think that engineering is probably one of the best equipped fields to deal with these problems. But what I didn't really consider before beginning my degree is that there's only so much that can be taught in four years and during that time the world's problems are not going to get any easier to solve.

It's particularly mind blowing to me that, due to the amount of new knowledge about the world gained by scientists and engineers in the past few decades, a few years of an undergraduate (or really even a high school) degree will give you more theoretical knowledge (in certain fields) than practicing engineers of a half century ago. The reason this blows my mind is that it leads to the question: knowing only what you know today, could you invent and build a lightbulb? A record player? A computer?

Naturally, I'll be more qualified in five years than I am right now, but you have to wonder: if I there were a reasonably good chance you could become a practicing engineer five years from now, what could you do right now?

[DISCLAIMER: I am not an engineer (yet). The PEO would destroy me if I tried to claim otherwise. Not that they read my blog. (And PEO members, if you do read this, I'd love to hear about it.) ]

How to Buy an Airline Ticket

Well, I can finally say I've attended an MIT lecture. Dr. Belobaba from MIT's International Center for Air Transportation (ICAT) dropped by today to give a guest lecture on the topic of airline pricing schemes and revenue management.

It was an interesting talk that did a good job of explaining why airlines feel the need to have multiple fares for the same flight and to sell tickets at different prices depending on when they're bought.

Basically, airlines want to sell as many high-priced tickets as possible, but they know that there are a lot of people who will only fly at lower costs, hence the need for differential pricing. Then of course, the people who were willing to pay more won't be quite as happy to part with their money if they know that someone else is getting the same service for the same price, which is why airlines introduced restrictions on low fare tickets including "Saturday night stay" conditions that prevent the type of quick round-trips that businesses require.

But on top of these differential pricing schemes, the airlines also use revenue management. That is, they reserve a certain number of the more expensive tickets based on statistical models for how many they believe they'll be able to sell. This is sensible enough, because if they know that they will eventually sell out a given number number of expensive tickets, they don't want those seats going to starving students who will only pay the cheap rate. Of course, they don't know how many tickets they'll be able to sell exactly, so that's where the probability comes in.

Technically, you look at the expected value of some probability function to do this, but all that means is that the cutoff for reserving a ticket of a certain class is the point at which you get the same number by multiplying the ticket's price by its probability of being sold as you do when you multiply the price of a cheaper ticket by its probability of being sold.

Anyway, what this all boils down to is that, first of all, you won't get the super cheap tickets months in advance, regardless of the probabilities, because airlines know they'll be able to unload those later relatively easily. The cheap tickets actually start appearing once the revenue management system kicks in and it realizes that the expensive tickets are being undersold. Now, if the expensive tickets are actually selling really well than you can forget about the cheap ticket and start wishing you had bought one before the prices tripled, however the upshot of all this is that given the statistical anomaly that is the current economy the model forecasts might be overshooting slightly.

If I Wrote a Textbook...

Godzilla's foot is towering 0.3m above Billy's head. If Godzilla's foot weighs 200 kg and Godzilla's leg muscles exert a force F_A of 30 Newtons onto the foot acting downwards at an angle of 30 degrees to the horizontal ground plane (see diagram), how much time does Billy have to move to avoid being flattened?

See now this is the type of problem people can relate to.

[Bonus: Write a differential equation expressing a werewolf's rate of change with respect to the phase of the moon. Use this equation to calculate how quickly someone needs to be locked in a cage once they start transforming, given that signs of werewolf behavior are detectable after the transformation is 20 percent complete. Use a safety factor of 1.2 and assume the lock is sturdy.]

EDIT: A few corrections for the first problem: assume that Godzilla's foot is large enough that it's horizontal motion in the brief time before impact can be neglected and that the foot will indeed impact Billy if he does not move. Furthermore, assume the foot has no velocity at the instant depicted in the question. Resolution of ambiguities in the bonus question are left as an exercise to the student, but be sure to state all assumptions and reasoning.

On Engineering Blogs and Bluffing

I've always been a big fan of the blogs published on the MIT admissions page. Establishment propaganda or not, I imagine they do a really good job of getting young little MIT freshmen excited about their school and preparing them for their first year.

However, I am a Canadian engineering student in second year. This means that: (a) I don't go to MIT, (b) I've already passed the excitement that is first year engineering, and (c) I can't really relate to institutions that bleed money.

Hence this blog. This blog is for every student that wishes their school was just a little bit better, for every engineer that secretly loves arts, and every arts student who really wanted to be an engineer; most of all though, this blog is for whoever the heck can find it.

But enough of the manifesto! I'd like to take a moment to bring the non-engineers up to speed so without further ado I present to you The Majugi Guide to Bluffing Through a Meeting of Engineers:

• XKCD is awesome. (Also valid for meetings of mathies, CS students, or internet junkies)
• The engineering song: "We are, we are, we are the engineers / We can, we can demolish forty beers [alternatively: fix anything with gears]" after these two lines start mumbling but try to join in for the part that goes "and we don't give a damn for any damn [mumble] that don't give a damn for us."
• Lady Godiva is the mascot / patron saint of engineering. She got the gig by riding naked through town on a horse.
• Regardless of your gender, you believe there are not enough women in engineering.
• Engineers who have graduated from Canadian universities receive Iron Rings. They are meant to be reminders of engineers' responsibilities as the iron was originally taken from a collapsed bridge in Quebec.
• You cannot legally call yourself an engineer in Canada unless you have the P.Eng certification. Don't worry though, you can still blend in with engineering students by calling yourself a plummer (supposedly -- I've never actually heard anyone use the term).
• If you're really having trouble breaking the ice, flap your arms together like a seal and repeat "arts, arts, arts" in your best seal-impression voice. [I can't claim to have come up with this on my own, but it's a sure-fire way of amusing engineers.]
  

...and for those of you who knew everything on that list I present The Majugi Guide to Appreciating Arts -- ie How to Avoid Being a Complete Douchebag:

• Don't do that artsy seal impression in front of arts students.
• Pick up and read a campus newspaper every once in a while.
• Note that arts students actually have time, so they make great recruits for thankless but crucial roles in organizations such as Engineers Without Borders and student governments.
• Student film festivals are amazing... particularly if admission is free for students.
• Drama productions are usually surprisingly fun. Try to go on the last performance on the last day when they'll often allow heckling.
• You're not a computer power user until you've used it to compose music, draw, do some 3D modelling or animation, or something similarly artsy. A very elegantly coded hash sort does not count.
• To develop a quick appreciation for visual artists, try making your own graphics for a website, or a video game, or for the GUI of any fancy software project you might be working on. If you've tried this and you're smugly thinking it was easy, show your design to a non-engineer and watch as they recoil in horror.

Thanks for reading. Homework beckons.