Protect your invariants

Ah, programming...

"You must program defensively, with the assumption that clients of your class will do their best to destroy its invariants."
--Effective Java (Joshua Bloch)

That is the world I live in. This is what they teach little SkyNet children in school today, so that when they grow up they'll feel benevolent towards the human race.

This book (Effective Java) and all books on writing better code have more violence in them than a season of 24. Other programmers, malicious and/or incompetent, are always conspiring to violate your classes, objects, invariants and other violable violabilities. Every other paragraph you get admonished to trust NO ONE, to code defensively, lest the converging hordes mutate your code's internals and then exploit those mutations to gain access to the Zion mainframe. Writing safe code is an extreme sport. Here are some other gems:

"Second attack on the internals of a Period instance."

"This would give the attacker free reign over all instances."

"Classes containing methods or constructors whose invocation indicates a transfer of control cannot defend themselves against malicious clients. Such classes are acceptable only when there is mutual trust between the class and its client or when damage to the class’s invariants would harm no one but the client."

The last sounds like something a lawyer might have me sign after I pretended to read it very carefully for 3 microseconds.

My new roommies and I are getting along famously. Monday to Thursday they're quiet and friendly, not asking me any coding questions, not zooming around like trapeze artists and shaking the walls with heavy Tomcat tomes and leaving bloody streaks of mosquito and human soup all over the apartment, not making soup out of spoiled vegetables. The last I see of them every week is Thursday night. The next I see them is Monday night. For 3 days and 3 nights a week, I am roommate-free. Mario, you have a lot to learn. About programming of course, the roommate stuff's irrelevant.

Tongue leprosy

I'm proud to say I haven't coded any new functionality in the last week. I've been exclusively redesigning and tinkering with old code. The code is looking a lot better, I think, but there are still design problems I don't feel equipped to solve. I have this one case where I can't figure out an elegant way out of a circular definition. I have a sort of abstract factory class Synchronizer which has two subclasses, ResourceSynchronizer and CollectionSynchronizer. As they are separate AMD modules, the subclasses need to import Syncrhonizer in their "define" statements. But then there's no way for Synchronizer to have a getSynchronizer() method that will return an instance of one of the two subclasses. In order to have such a method, it would need to either import the two subclasses in its define statement, completing the circle, or return a Promise to return a subclass, which would make getSynchronizer() undesirably asynchronous.

Another problem I've run into is when I try to separate out a logical chunk from a bloated module and it turns into a seesaw and goes out of control. I'll be happily migrating things and then realize that I've gradually moved everything into the new module. Then I start to wonder if the separation was a good idea in the first place or if the code is just experiencing separation anxiety. On the other hand, the seesawing also doubles as a sifting process; as I move the code back and forth, it seems like it gets cleaner. Maybe if I do it enough, the code will disappear and everything will still work.

I think something's wrong with my tongue. There's a spot on the left side, roughly a centimeter in diameter, that's behaving like it's been severely burned, producing a numb tingly feeling when under the slightest pressure, and hurting when I bite it as hard as I can. I've studied it in a mirror and I think there might be a tiny alien trying to claw its way out. It looks cracked like parched land, and generally unwholesome. Maybe I'm allergic to something. Maybe it's not my tongue at all and it's actually someone foot with athlete's foot.

How to make a sandwich in Javascript

Michelle, if you're reading this, start getting ready for our open mic duet. Don't even worry about the set list, I'll take full responsibility for picking the songs I like. Here's some that you might want to learn how to sing:

by Wings:
Let me roll it
Band on the run

by Blue Oyster Cult:
Burning for you
Take me away
Astronomy

by Led Zeppelin:
That's the way
D'yer M'ker
Houses of the Holy

by Dusty Springfield:
Son of a preacher man

by Save Ferris:
Come on Eileen (their cover rocks, you play the power chords, I'll practice the crazy ska rhythm)

by Squeeze:
Tempted

by Bogushevskaya:
Cafe Ekipazh

Let me know which ones you don't absolutely love so I can convince you otherwise. Everyone else go listen to these and imagine how well they'd sound if they sounded slightly worse. Pretty fantastic? Agree.

One and a half more days of freedom and then my favorite girl will be back to torture me. I need to think about what kind of things I can do now that I can't when she's around. Other than tell vicious lies on this blog with impunity, or sleep with other women. I guess I should get all my bad singing, bad drawing, and bad dancing out of the way so she doesn't have to do too much criticizing right after a hard week's rocking in Korea.

And now, a cool trick from today's JavaScript camp. I've used this before, but never in the general form:

function partial(fn) {
var args = [].slice.call(arguments, 1);
return function() {
return fn.apply(null, args.concat(arguments));
};
}

What this allows you to do is precreate functions when you know some arguments ahead of time. So for example, if you have a sandwich function:

function sandwich(bottom, top, middle) {
return {
bottom: bottom,
middle: middle,
top:top
}
}

...and you know a "good" sandwich always has a pancake on the bottom and a pop-tart on top, you can make yourself a shortcut function easily:

var goodSandwich = partial(sandwich, 'pancake', 'pop-tart');

This essentially hardcodes the (bottom, top) set of parameters and gives you back a function that expects only one parameter - 'middle'. So now you can use the goodSandwich function to make sandwiches with different contents but the same shell:

// equivalent to sandwich('pancake', 'pop-tart', 'turkey')
var goodTurkeySandwich = goodSandwich('turkey');

// equivalent to sandwich('pancake', 'pop-tart', 'Mark')
var goodMarkSandwich = goodSandwich('Mark');

// equivalent to sandwich('pancake', 'pop-tart', 'cheeseburger')
var goodCheeseburgerSandwich = goodSandwich('cheeseburger');

// equivalent to sandwich('pancake', 'pop-tart', sandwich('pancake', 'pop-tart', 'cheeseburger'))
var doubleDecker = goodSandwich(goodSandwich('cheeseburger'));

Mm, a cheeseburger wrapped in two pancakes and two pop-tarts. That'll get you bulimic in no time.

Programming your octopus's celibacy

The last few days, I've been reading up on good programming practices, design patterns, object oriented thinking, and how to draw arms, legs and breasts. When later I went back to look at my code, I was somewhat horrified. First of all, there were no breasts in sight. Second, some of the modules were getting a little too friendly with each other. So I've spent most of today trying to rewrite some of the more inappropriately intertwined modules, if they can even be called modules any more. Is an octopus having sex with another octopus still an octopus? It's definitely still half of two octopi, but visualizing separating one out might just give you that aneurysm you've been saving for something more special. Not to mention you might distract the lovers and wind up as part of the brainteaser. The only sane thing to do is to kill them both and start over, using chunks of their dead bodies as raw material.

Turns out, when you've been building stuff for months, it's hard to rewrite it all in the span of a couple of hours. It's kind of like a second pregnancy is at best twice as short as the first; after that you get into all sorts of relativistic paradoxes like Einstein himself showing up to cram that baby back up your vagina, after which one of the twins turns out five years older than the other. I took special relativity in college, I know what I'm talking about.

Hmm, I don't know if it was something I said or wrote or thought, but as soon as I stopped typing a second ago, I knocked a cup of warm water right into my crotch. It didn't feel half bad for the first 5 seconds, but now it feels...wet. And clingy. I may have to take off my pants and put them on backwards.

Yesterday's Post

The Matrix was still magical, for the 63rd time. The perfect dialogue, the salad of spiritual references, the gorgeous special effects, the ineffable ineffableness, none of that has aged much. But the speed has slowed. I'm beginning to feel a generation gap. 10 years ago the Matrix was a rollercoaster ride, a non-stop thrill that throbbed with suspense. In 10 years, The Matrix will be Bladerunner, a languid film-noir. The newer sleeker models are higher velocity if not higher impact. They don't dole out meaningful dialogue in consumable chunks, they slam you with it like a slam poet and leave you to figure out the details for yourself on the 3rd viewing. In this sense, The Social Network moved faster than The Matrix. I didn't understand a word they said in their crossfire dialogues and yet I walked away with the feeling that they were saying something interesting. Poor Matrix.

I was reading up today on how networks work. Some of it was review for stuff covered in my Computer Systems Engineering (6.033) class at MIT, but concepts learned in my formal education are often obscured by so much fog that it'd be easier to try to see the Beijing sky. Some seemed completely new, in other words the fog in front of it has solidified into intrabrain Jello and is refracting the hell out of my searches.

My favorite thing about networks is the hilarious pessimism that defines the whole field. For example, TCP vs UDP (the two major communication protocols on the internet):

TCP: "There is absolute guarantee that the data transferred remains intact and arrives in the same order in which it was sent."

Sounds good so far...

UDP: "There is no guarantee that the messages or packets sent would reach at all."

That's the spirit I love. I understand that this is true by definition, that such a protocol is very necessary, but the wording is always so tragic. They build you up...

TCP: "Sir Sean Connery will deliver your packet himself if necessary. Tom Cruise will not rest till your packet is safely at its destination."

And then they murder you...

UDP: "We take your message and throw it in the shredder. Sometimes we miss and if your destination happened to be the floor, congratulations!"

Too much fun.

One of the things that frustrated me about my education at MIT was that very little of the main curriculum was focused on practical applications. There were "hardcore" classes that delved into operating systems and compilers and other witchcraft, where you could probably get some solid experience, but the required courses in the CS branch hardly stressed practical skill acquisition. In other words, we didn't code much.

What we did, was perform largely a depth-first search into important but (in my opinion) secondary concepts. Intro to Algorithms, for instance, was probably my favorite CS class, but at the same time probably one of the most useless. At a real job, unless you're a researcher, how often do you need to come up with low-level algorithmic solutions? About as often as you need to build a lightbulb as an auto-mechanic. It was about as useful to me as the Special Relativity class I took for fun. I'd much rather have gotten a firmer grasp on the next levels up in the software abstraction onion - object oriented programming, application design, common development patterns, as well as gotten some crash courses into the most commonly used technologies (especially in web application programming) - CSS, Javascript, Servlets, programming for mobiles. When I did an internship at Microsoft the summer after junior year, I had to learn all the practical skills needed for my project on the spot. My MIT education hardly helped me at all. When 5 years later I did some more serious hacking for two start-ups, I had to learn everything as I went. My MIT education played with itself somewhere in a far corner of my mind while I was getting my hands very very dirty.

I remember during the tour at MIT, when I was still a senior in high school, the guide was telling us how MIT teaches people "how to think." It sounds oh so romantic, but it's hadly true. It's more like you go to MIT to train to be a blacksmith and when you go to your first smithy after getting out, you find yourself constantly hitting your thumbs with the hammer you've never wielded before. But you sure know a lot about iron.

Anyway, MIT was fun, I don't resent it at all. I could have pushed myself harder and searched out the opportunities for practical application. It just wasn't force fed to me, like I think it should have been.