Business 2.0 Magazine has a fascinating article on Kevin Ham, one of the top “domainers”. He reportedly owns about 300,000 domains that generate an estimated $70M per year in ad revenue.
Sheesh. No wonder I can’t find any good domains anymore.
Places with no phone number country code:
Researcher Elizabeth Van Couvering recently published research results on how search engine employees think and talk about their work.
In the face of rising controversy about search engine results—that they are too restrictive, too comprehensive, lacking in certain areas, over-represented in others—this article presents the results of in-depth interviews with search engine producers, examining their conceptions of search engine quality and the implications of those conceptions.
She interviewed employees of Google, Yahoo!, MSN, Ask Jeeves, AOL, Excite, Lycos, Infoseek, and WebCrawler, and her report is remarkable in terms of the insider verbatim quotes. (The search industry is notoriously secretive, so getting people to reveal their inner thoughts about it is challenging.) Her analysis reveals that search industry insiders consistently portray themselves as fighting a war, that they justify much of their work in scientific terms — even when trying to deal with unquantifiable issues like public good — and that they understand in a deep way how their business is driven by profit motives.
Her work is on target. And not just for search; her observations apply to every technical group I’ve been part of or collaborated with, both within and outside of Microsoft. We all used similar language “schemas”. We talked about marketplace war, about science for science’s sake. We often shrouded ideology — “censorship is inherently bad” — in technical terminology — “I suppose the algorithm decided to demote that result because its relevance dropped during our last crawl. We don’t decide; the algorithm decides.”. Or, “Sorry, we can’t implement that feature, the current architecture doesn’t allow it and it would take way too long.” Frankly, it was often easier to fight such technical arguments than to fight the underlying ideological battles, because the latter approach generally ended in stalemate. So technical language became a tool for keeping non-techies from influencing product design, and it shielded teams from struggling with uncomfortable thoughts like, “Does any of my work have a negative impact on society?”. I believe this shielding pattern reoccurs broadly in many science and technology fields.
Elizabeth’s methodology — analyzing the actual words people speak — reminds me of ‘The Four Horsemen’: Why Marriages Fail, a radio story that aired on NPR in 2005. It’s an interview with a researcher who talks to couples about their relationships, then analyzes their word choice and emotional tone to predict whether they will eventually divorce or not. Apparently there are four strong predictors of divorce: criticism, defensiveness, contempt and stonewalling. And words that convey contempt for a partner are the strongest predictors of all.
The NPR piece is designed for a mass audience. Elizabeth’s piece is written for an academic audience. I recommend both.
I recently spent several weeks evaluating Ruby on Rails, and decided to go ahead and use it as the programming framework for some code I’m writing. (Alternatives considered: ASP.NET; PHP; JSP.) My experience thus far has alternated between exhilaration and humbling frustration. Heavy on the humble. Still, there’s more than enough great stuff to keep me hooked.
In the interest of helping other tire-kickers and fledgling Ruby on Rails programmers (RoRlings?) avoid a few pitfalls I’m going to post a few of my own learnings, observations, and embarrassments along the way. This is the first such post.
—-
Q: What the heck is Ruby on Rails, and why are you using it?
A: Ruby is a dynamic programming language, with a very clean and modern object-oriented programming library. See for yourself… there’s a neat interactive tutorial here. Rails is a web application framework written using Ruby.
I’m using it because…
More:
Wikipedia has a good brief and factual overview.
These quick screencasts give you a taste for it.
There are several excellent books… the bibles of Ruby and Rails. I’ve found you really cannot learn Rails fully without these books.
There is also a wiki, which leads to everything else.
Is everything about Ruby on Rails this rosy? Well, no, of course not. It’s still young. But it’s worth a look. I’ll leave the shortcomings list for another time.
Email and RSS updates