Xblog

When I started biking, I was over a hundred pounds more than that. I had read about this being a problem before I got my bike, so I eschewed a light road bike and went with a bulkier, heavier hybrid. The bike as a whole has stood up pretty well, but a few parts have suffered worse than others.

One lesson I have definitely learned: salesmen will automatically assume that heavier people need a seat mount with a spring in it to soften the bumps on the road, and they couldn’t be making a bigger mistake. The springs will inevitably be worn out much faster from having to deal with weight far in excess of what they planned.

That’s the least of the problem though. The real problem is my rear wheel. My added weight puts tremendous strain on the rear wheel. I’ve repeatedly bent spokes and/or the wheel, even as I’ve lost weight from the riding. I’ve spoken to several experts, and the consensus is that off-the-rack wheels just aren’t strong enough to handle the load. I’ve upgraded to a stronger rear wheel, and at least so far that has kept the wheel from needing work, but I still seem to get a lot of blown tires.

I looked at this information on tire pressure, but it seems to suggest I need tire pressures well above 100psi, which seems insanely excessive for the fairly beefy tires on my hybrid. The tires I’m riding with are rated at 85psi, which is where I try to keep them (checking their pressure every few days), but I have to admit that when I’m riding they do seem bend a bit more than I’d like. I checked the tube on my last flat, and it appeared to have a snake bite, but I’m not entirely sure whether it got there before or after the air leaked out of the tire.

A friend of mine who is a much more experienced biker says that I need to buy aftermarket spokes and most importantly learn to build my own wheel to get something strong enough to handle my weight. I think I’ll be taking this route soon, but I have my doubts as to whether this will really solve my problem (are bike shops really that bad at building wheels?).

So, I turn to the great internets. I can’t imagine I’m the only overweight cyclist out there. What have the rest of you learned to do to compensate for the industry’s seemingly obsessive focus on those who are already at a healthy weight? Have you encountered other problems I have yet to deal with?

This morning I got out of the house a tad earlier to meet up with one of my co-workers, who was doing the trek all the way from Pasadena (I kid you not). We met up at a Del Taco at Hollywood & Santa Monica, and biked in together from there. I can’t say enough about how much more fun it was to bike in with someone else. 15-30 minutes on a bike by yourself is no biggie and can actually provide some useful “me time”, but for longer trips, I’m enough of an extrovert that having some company really makes the experience more fun. Better still, having someone else along for the ride made both of us work harder to maintain a good pace. Particularly since we had some… significant differences in gravitational forces applied to us, I had to work harder to keep up with him when going up inclines, and he had to work harder to keep up with me on the declines. Net effect: he actually set a personal best time for his ride in (and by a significant margin), even though he covered an extra mile from his previous record, and I likely did the same (if only I kept track of such things).

I didn’t make the effort to visit all the stations where they were handing out all the free schwag, but I was handed a Google-branded portable bicycle pump for my efforts. I actually already have one of those, so I’m offering it to anyone who actually has participated in Bike to Work Week. If you have other interesting schwag to offer in exchange, that’ll bump you to the front of the line.

The ride back was solo the whole way, but was still shockingly effortless, confirming once again that my body really does repair itself better on five days rest as opposed to four (or none), even if I’m dreadfully ill during the rest time. To those of you who don’t grok what this means, I’ll spell it out for you: I’m getting old. :-(

All, in all, this has made me more interested in trying to find like minded (and like-capable) parties to share the ride in to and back from work. I’m sure if I do some hunting around amongst the various biking interest groups in LA, I’ll find some good candidates.

Other bike-to-work observations:

• Bus drivers don’t care if it is Bike to Work Month/Week/Day. I probably should have just ended that sentence at “care”, but in fairness they do seem to care about the folks that are actually on their bus… just noone else.
• The Los Angeles area really does just have an insane number of potholes along the side of its roads, and Beverly Hills is shockingly one of the worst offenders.
• You might think that reporting potholes would be a wise way to address the above, but you’d be wrong! The potholes I reported last week were mended… resulting in a massive lump of asphalt rising from the street, surrounded by a protective moat that appeared as though dug by some diminutive siege engineer attempting to provide protection to a soon-to-be built castle at the summit!
• Bike to Work Day is probably the only day you can “take the lane” while going under the 405 on Santa Monica without anyone honking at you.
• Worst part of biking in warm weather: waiting at a red light while seemingly paradoxically producing more sweat than the entire time you spend on the trip actually moving.
• Biking to Work is good and all, but be sure not to accidentally take the car keys with you as you head out the door. I have a very forgiving spouse, but I think I still may need to sleep with one eye open tonight.

So starting with the outer bits of the code first, it is pretty clear that the bulk of the message is escaped Javascript which is fed in to eval. Not exactly a good sign, but not necessarily a bad thing. The first step I took was to unescape the relevant data (without performing the eval of course), which yielded this.

The source was clearly obfuscated, so I went through it, cleaned up the formatting and attempted to assign more meaningful names to variables and functions. This yielded this. The transform1 function included a use of eval(someString.replace(/blah/, ”)), which was clearly just a way of obfuscating how myCallee was computed, so I performed the replace and substituted the result, yielding this much clearer source, which shows that myCallee is actually the function itself!

So, it now becomes clear that the obfuscation of transform1 was not entirely random in nature, as the source itself was used as part of the key to decode the “payload” (the string passed in to transform1 after its definition). The easiest way to accurately decode this was to create both the original fpTu function in all its obfuscated glory, then set myCallee to fpTu in transform1, and then see what we got back from transform1 when we passed it the payload.

Not surprisingly, we have another somewhat obfuscated chunk of Javascript. After reformatting it (thank you Steve Yegge for js2-mode and providing some more meaningful function and variable names, the payload now looks like this.

There are still a bunch of places where the replace(/blah/, ”) idiom is being used to obfuscate things, and another place where a variant is used where all alphanumeric values are being replaced with a period, and then all instances of multiple periods are replaced with a single one. After unraveling those, the intent of the code becomes clear and we can attach more meaningful names to the functions and variables. Thus I ended up with this.

We can now see that the code points to 3traff.cn (don’t you feel safer already? ;-), and it cleverly embeds an iframe pointing to 3traff.cn in to each document as it is loaded. I’m not up on my browser exploits, but it looks like the intent of all this is to at the very least track users as they go off site, and also might be hoping to confuse a browser about which domain a document came from, and therefore potentially cause cookies to leak to 3traff. Either way, this isn’t the kind of code I like running in my browser.

The killer insight that I was lacking was the notion that people reading the books would focus on the wrong thing. I was blinded by what I found to be very clear statements by the authors of the book about the benefits and purposes of patterns, how one should select patterns, how they differed from other reuse techniques, and indeed even the title itself. It seemed clear to me that it was all about design, all about practical solutions to common problems encountered in OO designs (and yes, the authors explicitly state that these solutions are nothing new, but rather well established), and most importantly: not about the code.

What the Design Patterns book teaches is for people to think in the box instead of outside of it; just as I did on that exam. Pattern thinking has now permeated and perverted peoples’ thinking to the extent where patterns are perceived as being an ends; something you need to use to correctly solve problems.

First, I don’t get how that principle related to “the Plank”, because it seems clear from the statement that he knew how to solve the problem using a different one of the cookie-cutter solutions he’d learned. Rushing to judgment before understanding a problem doesn’t strike me as “thinking in the box”. Normally, people “thinking in the box” spend most of their effort on careful consideration of how a problem resembles and differs from problems they’ve seen before, giving up if it is too different from anything they’ve worked with before. Secondly, he jumps from talking about “Design Patterns” the book to “Patterns” in general, apparently failing to recognize that Design Patterns was just one book detailing commonly encountered design techniques of OO developers and comes far short of representing all patterns (indeed, the PLoP books detail new patterns presented each year), they were just the low-lying fruit. Even if you forgo this misnomer, it somehow misses the very logical conclusion one should reach in not finding a pattern that fits your problem: your problem isn’t a commonly recurring one. It boggles the mind to think one would instead think to apply a pattern to a problem it was explicitly not designed for.

Now I understand why people gripe about the Singleton all the time: they’ve too often run in to developers who use it because they can, not because they need to, developers who think of the Singleton solution instead of the kinds of problems the pattern addresses.

Here’s the problem, if one is the sort of person who tries to figure out the minimal amount of studying to get through one’s statistics class (ironically applying approaches to achieving this that could have been derived from statistical principles ;-), one probably skimmed (or worse skipped) over the beginning of the book that takes the time to explains how to use the patterns. One probably went straight to the patterns themselves, and after looking at several of them, one probably decided the real meat of the patterns was in the code itself, because one’s main use for programming books was to look for code samples and apply them to your work without having to think so carefully to avoid making mistakes.

To paraphrase JWZ: now they have two problems.

Thinking in patterns is exactly the wrong thing to do! It makes you think in terms of the solution instead of in terms of the problem! Pattern thinking makes you try to fit a round, square, or oval hole (your choice of patterns) to the triangular peg (your problem). When all you have is a hammer…

A designer who goes around thinking about design in terms of trying to shove a bunch of pre-built solutions in to a problem is screwed whether they’ve read Design Patterns or not. A designer’s first focus should always be on what problems they have to solve, and only think about solutions as a consequence of addressing said problems. If you focus on the solutions instead, you will inevitably be wandering around with a hammer, thinking all the problems you face are pegs.

What was curious to me when first reading the quoted text above was that I thought it was odd to think of Patterns as solutions looking for a problem. The book quotes about the specific way that patterns are documented, and right there at the beginning of each pattern is talk about the kinds of problems the pattern is appropriate before. Heck, the pattern catalog was even grouped by the kinds of problems each pattern solved! It seemed obvious that the proper way to organize your thinking about patterns was in terms of the problems they solved (indeed, I’d often forget details of specific aspects of designs or implementation techniques for patterns I didn’t use much, but I tended to remember their applicability quite clearly). It’s odd to me that one would think one had to organize your thinking in terms of the solution, particularly since the solution was inevitably so much more complex than the problems it solved. What I was missing of course, was that to someone trying to find the “meat” of a pattern without reading and understanding the whole thing, they’d tend to of course focus on where the biggest sections of the pattern description were, and where the complexity was. So now you’ve compounded the problem: you’ve dramatically increased the cognitive load necessary to select appropriate patterns and you are focused on the wrong thing for coming up with a good design.

But wait, it gets worse!

For example, before dumb and dumber decided to call it the “visitor pattern” every programmer worth his salt would just call it a “map” operation (as in the LISP functions “map”, “mapcar”, “maplist”, etc). That’s just, oh, something like 1994-1960(?) = 34 years of previously established terminology! Twits.

Yup, he just completely missed that the visitor pattern is primarily about double dispatch, and even talks about how CLOS does this natively. It talks about how Smalltalk’s do: (the moral equivalent of map/mapcar/maplist) won’t get you double dispatch support. Most importantly, it even talks about how putting traversing behavior in the Visitor, as done in the sample code, only really makes sense if the logic for determining what to traverse depends on results of the algorithm itself (i.e. when map/mapcar/maplist won’t work).

So, by focusing on the code, rather than the discussion of the problem, it’s various facets, and how they effect possible solutions, one not only misses out on understanding the problem, but also in understanding the solution.

It really is a poor craftsman who blames his tools. The problem is being focused on solutions, and that doesn’t come from Design Patterns, it was there before hand (as demonstrated by The Plank).

In retrospect, I think the real mistake some pattern advocates may have made was in encouraging people who just didn’t get it, or didn’t want to get it, to use patterns anyway. To really mix up some metaphors: once you’ve brought the horse to the fountain of knowledge, if it doesn’t drink, just shoot it and put it out of its misery. If you force it, it’s just going to pretend to drink while secretly gargling, and you’re going to find yourself stuck in the middle of the desert with a dehydrated horse. ;-)