From Martin Fowler's "Patterns of Enterprise Application Architecture", page 388:
"In an object-oriented model, you do best with small objects that have small methods. This gives you lots of opportunity for control and substitution of behavior, and to use good intention-revealing naming to make an application easier to understand."
Wiser words were never written.
Thursday, April 19, 2007
Friday, March 02, 2007
Thursday, February 15, 2007
Hapa Hua-Qiao
I'm often asked about my surname. More often, I'm not asked, but I can sense the confusion it creates.
Some people -- always women, interestingly -- commend me for it. Other folks are apparently less sure, or even incredulous, insisting on calling me by my "maiden name" ("bachelor name"?) even if they've known me only since The Switch.
I'll admit, I sometimes don't quite believe it myself. More than once these seven years, I've accidentally called myself "Mark Van Haren." I suspect it's that I, just like the curious people I meet, never expected my name to change. Most (American) girls assume -- or used to? -- that they'll one day change their name. But for me, Van Haren was never my "maiden name", just my name.
Of course, that thinking changed. Having only my wife change her name didn't feel gender-equitable to us. And as a hua-qiao, my wife didn't want to lose the Chinese-ness of her surname. What to do?
Option 1: Both remain unchanged. But we'd lack a common family name. Would it even feel like we're married? What name would the kids take?
Option 2: Both adopt some brand new name. But what? And that probably doesn't solve the Chinese-ness issue. We'd probably both feel we'd lost something.
In the end, hyphenation seemed the only viable road. In theory, I was good with this. In practice, "Wong-VanHaren" has always been a little difficult to get excited about. "Wong" breaks up the (original) flow of my name, like a middle name I suddenly insisted on always using. And the new moniker got off to a rocky start when, at our wedding, we were pronounced "the new Mr. and Mrs. Wong-VanHaren", and our unwitting assembly of dear friends and family... wait for it... they laughed. Ouch.
Maybe what's weird(est) about it for most people is that the two names are so different. It ain't Smith-Jones or Chang-Wong. I'm a haole guy with a merely hapa-haole name, and I suppose it just looks funny on me, like a kente cloth on an Inuit.
Anyway, just deal with it. :-) I do. Oh, and please try to get it right. It's "Wong-VanHaren," with three -- count 'em, 3 -- uppercase letters and not a single space in the mix.
Some people -- always women, interestingly -- commend me for it. Other folks are apparently less sure, or even incredulous, insisting on calling me by my "maiden name" ("bachelor name"?) even if they've known me only since The Switch.
I'll admit, I sometimes don't quite believe it myself. More than once these seven years, I've accidentally called myself "Mark Van Haren." I suspect it's that I, just like the curious people I meet, never expected my name to change. Most (American) girls assume -- or used to? -- that they'll one day change their name. But for me, Van Haren was never my "maiden name", just my name.
Of course, that thinking changed. Having only my wife change her name didn't feel gender-equitable to us. And as a hua-qiao, my wife didn't want to lose the Chinese-ness of her surname. What to do?
Option 1: Both remain unchanged. But we'd lack a common family name. Would it even feel like we're married? What name would the kids take?
Option 2: Both adopt some brand new name. But what? And that probably doesn't solve the Chinese-ness issue. We'd probably both feel we'd lost something.
In the end, hyphenation seemed the only viable road. In theory, I was good with this. In practice, "Wong-VanHaren" has always been a little difficult to get excited about. "Wong" breaks up the (original) flow of my name, like a middle name I suddenly insisted on always using. And the new moniker got off to a rocky start when, at our wedding, we were pronounced "the new Mr. and Mrs. Wong-VanHaren", and our unwitting assembly of dear friends and family... wait for it... they laughed. Ouch.
Maybe what's weird(est) about it for most people is that the two names are so different. It ain't Smith-Jones or Chang-Wong. I'm a haole guy with a merely hapa-haole name, and I suppose it just looks funny on me, like a kente cloth on an Inuit.
Anyway, just deal with it. :-) I do. Oh, and please try to get it right. It's "Wong-VanHaren," with three -- count 'em, 3 -- uppercase letters and not a single space in the mix.
Wednesday, February 14, 2007
DMD Tremens
Sometimes, working toward deadlines is pretty rough. I guess that's why I hate deadlines, because I take them seriously, no matter how ill-considered they may be.
After 11 days of reduced sleep -- started at 5 hours/night; ended at 2 -- and anomalously high caffeine consumption, I kinda broke. About a dozen hours after my last Diet Mtn Dew, my autonomic systems went haywire.
First, I got the shakes. Wow. I mean, what? It was weird. Terrible headache, shaking, weakness, fever, muscle soreness, copious sweating, the works. Did I mention terrible headaches? and shaking? and copious sweating?
At the time, I figured it was simple fatigue combined with mild illness (flu?). And maybe it was. But, my wife suggested it may have been a mental disorder. Really. She meant caffeine withdrawal.
There are a couple of serious lessons to be learned from this. First, better-considered deadlines; no matter how much urgency we may feel, I'm baking more time into each milestone, just to be sure. Second, sufficient sleep is mandatory. Third, caffeine is a drug.
After 11 days of reduced sleep -- started at 5 hours/night; ended at 2 -- and anomalously high caffeine consumption, I kinda broke. About a dozen hours after my last Diet Mtn Dew, my autonomic systems went haywire.
First, I got the shakes. Wow. I mean, what? It was weird. Terrible headache, shaking, weakness, fever, muscle soreness, copious sweating, the works. Did I mention terrible headaches? and shaking? and copious sweating?
At the time, I figured it was simple fatigue combined with mild illness (flu?). And maybe it was. But, my wife suggested it may have been a mental disorder. Really. She meant caffeine withdrawal.
There are a couple of serious lessons to be learned from this. First, better-considered deadlines; no matter how much urgency we may feel, I'm baking more time into each milestone, just to be sure. Second, sufficient sleep is mandatory. Third, caffeine is a drug.
Monday, February 12, 2007
Prototipo, Rubí
My English is native. My Spanish isn't, and is limited to certain usage situs. So no surprise, I express myself better in English.
As a programmer, Ruby is my English, JavaScript my Spanish. No surprise: I like to write JavaScript in a Rubyish way. It matches better how I want to think and makes things just flow better. Prototype.js makes this possible.
There are three particular Rubyisms that prototype.js gives me access to in JavaScript: [1] class-based OO, [2] modules as mixins, and in particular [3] the mixin Enumerable, which helps me to think functionally.
JavaScript is really prototype-based OO -- clone an existing object and extend it to create a new type. With protoype.js's Class.create(), I can pretend I'm just defining a class, whose #initialize method gets called upon instantiation.
Since I now have (something functionally equivalent to) classes, I can use Object.extend() to mix in modules.
Now, sadly, JavaScript doesn't encourage functional programming like Ruby does -- with its implicit returns and its blocks as method arguments. Nothing we can do about JavaScript's lack there -- we have to return explicitly, and we have to pass full-on methods, which if on some object, must be #bind-ed so the closure has the proper value for "this".
However, prototype.js still makes functional-style programming fun, giving us an Enumerable mixin rivaling that of Ruby's.
So prototype.js may not take us all the way there, but by making JavaScript a lot more Rubyish, it allows me to continue to program in the same style -- and think in the same way --, regardless of the syntax.
As a programmer, Ruby is my English, JavaScript my Spanish. No surprise: I like to write JavaScript in a Rubyish way. It matches better how I want to think and makes things just flow better. Prototype.js makes this possible.
There are three particular Rubyisms that prototype.js gives me access to in JavaScript: [1] class-based OO, [2] modules as mixins, and in particular [3] the mixin Enumerable, which helps me to think functionally.
JavaScript is really prototype-based OO -- clone an existing object and extend it to create a new type. With protoype.js's Class.create(), I can pretend I'm just defining a class, whose #initialize method gets called upon instantiation.
Since I now have (something functionally equivalent to) classes, I can use Object.extend() to mix in modules.
Now, sadly, JavaScript doesn't encourage functional programming like Ruby does -- with its implicit returns and its blocks as method arguments. Nothing we can do about JavaScript's lack there -- we have to return explicitly, and we have to pass full-on methods, which if on some object, must be #bind-ed so the closure has the proper value for "this".
However, prototype.js still makes functional-style programming fun, giving us an Enumerable mixin rivaling that of Ruby's.
So prototype.js may not take us all the way there, but by making JavaScript a lot more Rubyish, it allows me to continue to program in the same style -- and think in the same way --, regardless of the syntax.
Many Happy Returns
Ruby has implicit returns -- every method responds with something, whether you need it to or not.
For those unaccustomed to this, it may feel wrong. "If the result is meaningful, have the code tell me it is!" ...I disagree. If you're thinking this way, you're thinking procedurally.
Instead, think functionally. Always make your methods return something useful. If you can think of nothing more meaningful to return, return self. Method chaining is your friend.
For those unaccustomed to this, it may feel wrong. "If the result is meaningful, have the code tell me it is!" ...I disagree. If you're thinking this way, you're thinking procedurally.
Instead, think functionally. Always make your methods return something useful. If you can think of nothing more meaningful to return, return self. Method chaining is your friend.
Making Ruby Functional
I'm no expert at functional programming. I did a bit of LISP in college. Like you, I thought it was ugly. But I like FP anyway.
FP is supposed to be important because of higher-order functions and lazy evaluation, as they encourage modularity. And hell, who can argue with modularity?
But in Ruby, our most important tool for modularity is, um, modules (classes, objects). We're not fully FP. At a high level, we modularize using objects, and FP comes in at a tighter granularity, where its benefits are more limited -- but still important.
In Ruby's mixed environment, we can make our code simpler by using the higher order functional abstractions provided us (by Enumerable). There are as many "map"s in my code as "if"s. Make your own higher-order functions, even curried ones, if you like (though I rarely find the need).
We also make our code more expressive of intent. In FP, functions lack side effects. In other words, by asking a question, you want just the answer, not to change the state of the world in the process. Well, if what I want is an answer and not to be changing the state of the world, then expressing my intention using an FP style looks right. I'm declaring what I want. I see my code a week later and I know what I was doing. It's just laid out right: here's the goal, here's the starting point, and here are the steps that take me from the latter to the former.
Ruby makes this easy.
FP is supposed to be important because of higher-order functions and lazy evaluation, as they encourage modularity. And hell, who can argue with modularity?
But in Ruby, our most important tool for modularity is, um, modules (classes, objects). We're not fully FP. At a high level, we modularize using objects, and FP comes in at a tighter granularity, where its benefits are more limited -- but still important.
In Ruby's mixed environment, we can make our code simpler by using the higher order functional abstractions provided us (by Enumerable). There are as many "map"s in my code as "if"s. Make your own higher-order functions, even curried ones, if you like (though I rarely find the need).
We also make our code more expressive of intent. In FP, functions lack side effects. In other words, by asking a question, you want just the answer, not to change the state of the world in the process. Well, if what I want is an answer and not to be changing the state of the world, then expressing my intention using an FP style looks right. I'm declaring what I want. I see my code a week later and I know what I was doing. It's just laid out right: here's the goal, here's the starting point, and here are the steps that take me from the latter to the former.
%> my_result =
starting_point.munged_once.and_again
Ruby makes this easy.
Monday, February 13, 2006
Script.not-so.aculo.us
Because of the context in which it runs, JavaScript is a highly unusual language. Much JavaScript code is open source, but even that which isn't is "apparent source." Everyone's scripting skills are on display. It's a film festival crying out for critics.
As a coder, that's scary to me. I know I should welcome constructive feedback on my code, but it's oh-so-painful, especially when done in public. So, you know, be nice.
I've been using the RoR framework for building my web application, and I like it. Ruby is beautiful. The Rails framework feels simple, even though there's a lot going on under the hood. It makes sense to me. YMMV. Anyway...
Built right into RoR is a JavaScript library called Script.aculo.us, which provides DHTML goodies, such as visual effects (fading, resizing, repositioning, etc.) as well as drag-n-drop tools. Its author has selflessly given his code away for all to use. It's like the Summer of Love all over again.
With all due respect for Script.aculo.us' creator, I regret to report that I find it unusable.
If a library is a black box, providing all the right buttons and levers to fiddle with, and they all work as advertised, then great -- we don't have to care about the internals. For me, script.aculo.us fails the "black box" test. (How? I'll have to document that soon.)
Secondarily, if a library fails the black box test, but its internals are sensibly structured (clean OO encapsulation, well named classes/methods/variables), then we're okay -- we can use it as a starting point, and improve on it. In terms of sensibility of structure, suffice it to say that script.aculo.us proved very frustrating. I posit that no significant improvements to script.aculo.us could be made without a complete overhaul.
Thus, I have begun creating one. I hope to make them available soon. Stay tuned.
As a coder, that's scary to me. I know I should welcome constructive feedback on my code, but it's oh-so-painful, especially when done in public. So, you know, be nice.
I've been using the RoR framework for building my web application, and I like it. Ruby is beautiful. The Rails framework feels simple, even though there's a lot going on under the hood. It makes sense to me. YMMV. Anyway...
Built right into RoR is a JavaScript library called Script.aculo.us, which provides DHTML goodies, such as visual effects (fading, resizing, repositioning, etc.) as well as drag-n-drop tools. Its author has selflessly given his code away for all to use. It's like the Summer of Love all over again.
With all due respect for Script.aculo.us' creator, I regret to report that I find it unusable.
If a library is a black box, providing all the right buttons and levers to fiddle with, and they all work as advertised, then great -- we don't have to care about the internals. For me, script.aculo.us fails the "black box" test. (How? I'll have to document that soon.)
Secondarily, if a library fails the black box test, but its internals are sensibly structured (clean OO encapsulation, well named classes/methods/variables), then we're okay -- we can use it as a starting point, and improve on it. In terms of sensibility of structure, suffice it to say that script.aculo.us proved very frustrating. I posit that no significant improvements to script.aculo.us could be made without a complete overhaul.
Thus, I have begun creating one. I hope to make them available soon. Stay tuned.
Friday, September 16, 2005
Optimize for Productivity
Choosing a software stack for building a website isn't easy. There are lots of factors to consider. Scaling is an important one.
"Scaling" can be split into two factors: 1) how much hardware you can throw at the problem, 2) how well the framework/language utilizes the hardware.
When it comes to adding hardware, Ruby on Rails scales like any LAMP setup -- you can add app servers and web servers fairly easily. (Well, Rails isn't LAMP, it's LAMR.) The major bottleneck (and even then only for enormous sites) is the database server, but that's a general LAMP issue, not a RoR issue. (Correct me if I'm wrong, but I believe the same limitations apply to php, perl, and python-based setups).
Rails may not be able to outperform Java on similar hardware (on the other hand, it may. The jury's still out.) but there is enough evidence out there to safely conclude that Rails' performance doesn't suck. It's not ridiculously slow, and in some tests, it's on par with (or superior to) Java.
Some readers will be pulling their hair out here, thinking "under what circumstances?" Since Java is statically typed, which helps with some performance optimizations, there will be setups in which one can squeeze a lot more perf efficiency out of Java than Ruby. But just pretend for a minute that [1] (at least some of) those optimizations wouldn't be gotten around to, and [2] they still wouldn't, say, double the capacity of the hardware. Nobody knows for sure, but it seems reasonable.
In most cases, if hardware efficiency is fairly similar for several solutions (e.g. neither one is, say, 2x as fast as the other), performance questions become secondary to questions of development cost. Developers are way more expensive than hardware. If you need to use a beefier server to handle RoR, but it allows your developers to be slightly more productive, that's a good trade-off.
So, Ruby probably never outperforms Java. But in many circumstances, its performance is probably somewhere in the same ballpark, and we have several examples of sites that use it on a moderately large scale with success. For 99% of web development, that should be plenty of evidence. Right?
Don't agree? Fine. What would it take to convince you that RoR can scale? Why do you believe that any other language/framework can scale?
"Scaling" can be split into two factors: 1) how much hardware you can throw at the problem, 2) how well the framework/language utilizes the hardware.
When it comes to adding hardware, Ruby on Rails scales like any LAMP setup -- you can add app servers and web servers fairly easily. (Well, Rails isn't LAMP, it's LAMR.) The major bottleneck (and even then only for enormous sites) is the database server, but that's a general LAMP issue, not a RoR issue. (Correct me if I'm wrong, but I believe the same limitations apply to php, perl, and python-based setups).
Rails may not be able to outperform Java on similar hardware (on the other hand, it may. The jury's still out.) but there is enough evidence out there to safely conclude that Rails' performance doesn't suck. It's not ridiculously slow, and in some tests, it's on par with (or superior to) Java.
Some readers will be pulling their hair out here, thinking "under what circumstances?" Since Java is statically typed, which helps with some performance optimizations, there will be setups in which one can squeeze a lot more perf efficiency out of Java than Ruby. But just pretend for a minute that [1] (at least some of) those optimizations wouldn't be gotten around to, and [2] they still wouldn't, say, double the capacity of the hardware. Nobody knows for sure, but it seems reasonable.
In most cases, if hardware efficiency is fairly similar for several solutions (e.g. neither one is, say, 2x as fast as the other), performance questions become secondary to questions of development cost. Developers are way more expensive than hardware. If you need to use a beefier server to handle RoR, but it allows your developers to be slightly more productive, that's a good trade-off.
So, Ruby probably never outperforms Java. But in many circumstances, its performance is probably somewhere in the same ballpark, and we have several examples of sites that use it on a moderately large scale with success. For 99% of web development, that should be plenty of evidence. Right?
Don't agree? Fine. What would it take to convince you that RoR can scale? Why do you believe that any other language/framework can scale?
Employee #1
Two days ago, I accepted an offer to join a start-up. After the founder/CEO, I'm employee #1 and CTO. I'm very excited.
This is a change for me. I'm used to being a founder, not an employee. I'm used to feeling (and having) ownership. I'm spoiled, and it's been difficult to accept that I'm not always entitled to everything.
But, you know, starting a good company is hard. Really great business ideas are harder to come across than the Yeti. I spent roughly a year trying to come up with ideas, and I batted .000.
So I feel lucky and thankful. I met The Founder just as he was looking for a tech person to join him. And unlike me, he's got a Great Idea. And I'm going to help knock it out of the park.
This space == my memory bank through this process.
This is a change for me. I'm used to being a founder, not an employee. I'm used to feeling (and having) ownership. I'm spoiled, and it's been difficult to accept that I'm not always entitled to everything.
But, you know, starting a good company is hard. Really great business ideas are harder to come across than the Yeti. I spent roughly a year trying to come up with ideas, and I batted .000.
So I feel lucky and thankful. I met The Founder just as he was looking for a tech person to join him. And unlike me, he's got a Great Idea. And I'm going to help knock it out of the park.
This space == my memory bank through this process.
Subscribe to:
Posts (Atom)
