Sunday, August 28, 2011

A Question For Serious Sci-Fi

I've found sci-fi pretty dull since William Gibson stopped writing any. Gibson took the point of view that things were changing so quickly that near-term sci-fi goes out of date before it's published, and far-term sci-fi lacks sufficient constraints to ever hope for relevance, context, or predictive accuracy. I'm paraphrasing, and may be putting words in Gibson's mouth, but this is at least my general impression of his reasons; and I've seen similar concerns voiced elsewhere.

Anyway, I recently read Sex At Dawn, an examination of sex from the standpoint of evolutionary biology, and vice versa, which revisits, revises, and categorically obliterates the usual stereotypes of human sexuality as understood from the standpoint of evolutionary biology, and in the process completely discredits the pickup artist clichés of alpha males and "displaying higher value." From the standpoint of evolutionary biology, monogamy and marriage are very recent and unusual phenomena which run counter to the fundamentals of human sexuality.

This is a great question for science fiction to take on. There are at least two very interesting interpretations, both potential goldmines of controversy. Monogamous marriage developed alongside agriculture as a way to manage the effects of reproduction on economies. The first controversial interpretation is that monogamy is a destructive maladaptation, like agriculturally derived diets. The second controversial interpretation is that monogamy is a powerful technology which, in supporting the economics of the agricultural era, enabled humans to take over the world and become the planet's dominant species.

Obviously, both interpretations may be correct, and yet one brands monogamy a harmful thing, while the other names it a hero.

The non-monogamous mating patterns of tribal hunter-gatherer societies also pose very interesting questions because of the Snow Crash prediction that post-industrial society fragments and becomes tribal. If such a process is already underway, one would expect some decay in the institutions of monogamy in the world today, and of course anecdotal evidence for this is easy to find, most obviously in the history of the 1960s and 1970s and the very high divorce rate.

However, it seems overbold to call post-industrial society truly tribal, as it is not and will not be possible without education, technology, and many other systems not native to the tribal model and probably not sustainable under it. Therefore you have this very interesting dynamic of society becoming more tribal-ish but never really tribal per se, and this interesting conflict of monogamy the destructive maladaptation versus monogamy the world-changing innovation. The potential for controversy, complication, and pure human drama here is absolutely immense, as you already know if you've ever made the immensely time-consuming mistake of asking a polyamorist to describe their relationships in detail.

Saturday, August 27, 2011

TDD In JavaScript: No Excuses

Madison RubyConf was awesome, but listening to the testing panel outraged me beyond words. I frothed at the mouth and nearly had an aneurysm right there in my chair. It sent me loony in the noggin and left me wondering how many guys on that panel were huffing glue right before they got on stage. Somebody said that testing was an insurance policy, and this madness went uncorrected - despite the fact that test-driven DESIGN is obviously about design - and when the subject of testing JavaScript came up, the consensus was NOT TO FREAKING DO IT.

Names will go un-named to protect the guilty, but I later cornered one of these lunatic miscreants on a rooftop while inebriated, and I have to give him credit, because the distinguished if utterly mistaken gentleman handled my vehement, drunken correction with grace and aplomb. So kudos there.

Nonetheless, if you're not writing your JavaScript TDD, you're out of your fucking mind. It's just so fucking EASY, and it's such a quirky language with so many pitfalls. Writing JavaScript without tests is like having sex without a condom, except worse, because it's the wiggiest language out there, and it can turn on you at any second, so it's more like having sex with a rabid orangutang without a condom during the act or a taser to subdue it afterwards so you can make your escape. Look, just write fucking tests when you write fucking JavaScript, OK? Seriously, what the fuck.



Here's a quick video showing how easy it is. The video uses CoffeeScript but everything in it translates very, very easily and directly into JavaScript; all you do is add punctuation. By the way, I wrote a lot of the code and the tests in this video while sitting in the audience of this testing talk. It's so easy you can do it without even fully paying attention to it because you're also busy listening to somebody tell you how allegedly impossible it is.



Aneurysms aside, Madison RubyConf really was one of the best conferences I've been to. I definitely recommend checking it out.

Update: Bryan Liles was on the testing panel, and he reminded me on Twitter that he did in fact say to test JavaScript.

Thursday, August 25, 2011

Time Management Videos Relaunch Delayed

Yes, it's funny - like when a psychic cancels an event "due to unforseen circumstances." But I'm delaying the relaunch of my time management videos, because I came down with a pretty nasty cold after Madison RubyConf and have been sleeping it off ever since. More news soon, I hope.

Wednesday, August 17, 2011

50 For 50

It's her 50th birthday, so Colleen Wainwright is raising $50,000 for her favorite charity.

I've donated - you should too! Colleen gave me a terrific interview for my short-lived podcast Hollywood Grit.

Video Download Setup Semi-Fixed

Been getting emails from people trying to buy my resumés video. The buying segment is fixed here. The download segment I'm handling manually for now.

Sorry for any inconvenience! Unexpected demand is a good problem to have, but I probably won't have time to fix this fully until next week, after I get back from Madison RubyConf.

Tuesday, August 16, 2011

Programmer Resumes Video: Fantastic Testimonial

Giles - had to shoot you an email because your resume video helped me in a big, big way. I recently landed a dream Ruby job (with an amazing startup) as a direct result of what you taught me in your video. I doubt my old resume would have even made it past the screener.

Before your video, I blasted my resume out everywhere and it was ignored with great vigor - in spite of my strong skill set. (Your skills don't mean jack if you can't get people to read your resume.)

Of course, I was doing it the way we're all taught: just list your jobs and education, then sprinkle some "power verbs" on top. FAIL.

As I discovered, there is only one "insider's way" to do a tech resume...but lots of so-very-wrong noob ways that don't work. All the stuff you read in books is outdated or wrong for our industry. I know because I wasted a lot of time with them.

Once I learned the "what goes first / what goes last" in your resume video, the door really blew open for me. Same skills, one little tweak and everything changed. Now instead of me doing all the chasing...now I'm the one pursued. (I joke with my wife that sending out my new resume is "chumming the water".) Soooo sweet to get responses back within the hour. And they all say the same thing: "Chris, your resume looks great. When can we get you in to talk?"

Only one criticism: It would be better if you chunked the content into quick chapters, instead of one long video. You covered a lot of ground and it might make it easier to absorb. But that's minor. Point is, your information really works. Not ten years ago, not in theory. It works now.

So, thanks!

Chris Whamond

PS - I was really skeptical when I ordered this video. So if you are someone considering it, think about this: If Giles' video helps launch you into a better career making more money with greater job satisfaction...what's that worth to you over the next year? Or over the next five or ten years? The return on your investment here could be huge.


For sale individually and as part of a bundle.

Monday, August 15, 2011

Historical Intriguification

Tuesday, August 9, 2011

Multi-Track Rails Music App via SoundCloud API

Sessian allows you to use your browser like a mixer, with an important caveat: the tracks can only be soloed or muted, not volume-adjusted, as far as I can tell. Still, turning your web browser into a primitive mixer is a neat accomplishment and a sign of things to come. The developer, Chris Whamond, goes into a little detail on his site.

Before coming to Rails, Chris also did a bunch of interesting direct marketing work, and was kind enough to do an interview with me last year, which is unfortunately sort of trapped on a semi-fragile hard drive. I'm going to upgrade my old box to an SSD drive, maybe two, and I'm hoping to blog Chris's interview once I get things cleaned up a bit.

Sunday, August 7, 2011

Browser Exclusivity

Here's something I've never seen anybody do, but I imagine it would work: sell refusal to support IE6 not as a technical decision but as a marketing one - a mark of exclusivity.

Consider this solid-gold iPhone case:



It sells for $100,000. A cheap plastic case probably does a better job of protecting your iPhone. But a cheap plastic case does a much worse job of broadcasting your wealth to everybody around you, which is what this iPhone case is for.



Telling regular people to upgrade their browser is like saying they need to manually modify what they consider to be the dangerous, mystical internals of their computer. Most people don't upgrade, they just buy new machines. But if you say, look, your computer has to be at least this new to use our web site, you're speaking in a language of money, class, and social status, which is a language everybody understands.

I'm absolutely not saying this is the way things should be, but anything which gets web developers out of supporting Internet Explorer is worth a shot.

GroupOn Equated To Madoff

irrational valuations for a company whose seeming goal is to make its original founders and investors money while leaving "the next sucker" holding the bag.

Note that original investors have cashed out more than $800 million, instead of using the money for operations... note the stories from the field already coming in - for example, about Groupon selling half a million dollars worth of salon services for a salon that was not even set up yet.

Saturday, August 6, 2011

Great Web Comic: Girl Genius

From a hilarious world ruled by mad scientists, which should look all too familiar if you're a programmer.











I recommend starting at the beginning.

TOLDJA! Unnecessary Registration Costs Businesses Money

BoingBoing, in 2011:

The fastest way to alienate... customers and scare away [their] money is to make [them] establish a relationship with you before [they] can make a purchase.

we did an analysis of the retailer's database, only to discover 45% of all customers had multiple registrations in the system, some as many as 10. We also analyzed how many people requested passwords, to find out it reached about 160,000 per day. 75% of these people never tried to complete the purchase once requested.

Me, in 2008:

Control is a business disadvantage.

Monday, August 1, 2011

ActiveRecord Minus The Record Part

Today an ActiveRecord discussion revisited an issue raised about a year ago. The short version: ActiveRecord models which contain all your application's domain modelling become bloated and a total pain in the ass to test, refactor, and/or read.

A year ago, James Golick said:

The truth is that in a simple application, obese persistence objects might never hurt. It's when things get a little more complicated than CRUD operations that these things start to pile up and become pain points. That's why so many Rails plugins seem to get you 80% of the way there, like immediately, but then wind up taking forever to get that extra 20%.

My favorite comment in today's discussion echoed this thought:

I think this all depends solely on the complexity of the app you are building.

If you're building a small website, even proper MVC might be overkill and things like Sinatra + Sequel might be the best solution.

If you're building a medium sized app, the Rails approach of thin controller / thick model will be just right.

If you're building an enterprise information system, you might need that three-tier architecture with presentation / business logic / persistence layers separation and maybe even other Java world practices.

Don't over-engineer, don't under-engineer. Make it just right for the thing you are building.


Factoring an ActiveRecord persistence strategy (either the design pattern, or the Rails gem) out of the centerpiece of your object model makes a lot of sense once you pass some threshold of scale. In this instance by "scale" I mean code base size but also possibly traffic. The argument for code base size is hopefully obvious, and certainly covered in the blog posts I've already linked to and quoted.

With enough traffic, strong arguments mount for slicing your persistence up. You might read from read-optimized databases while writing to a central write-optimized one (since most web apps do a lot more reading than writing) or handle most persistence through SQL while shunting a small subset off to NoSQL alternatives. It gets ridiculous managing multiple persistence solutions within an object which exists to model your business logic. A line or two of ridiculous, I can handle - I've written ActiveRecord models which snuck in calls to Redis pub/sub on the side - but go much further beyond that and the argument for separate objects becomes rock-solid.

In this sense, the traffic-motivated split is really just a code-size-motivated split with a specific reason for code size growing, and obviously where a general code-motivated split can depend on the overall size of your model code, a traffic-motivated one would depend on the size and complexity of your persistence code.

I don't think there's really any debate here at all, except for one crucial question: where do you mark the threshold? How do you decide when your code needs this split? Although you can certainly perform various measurements to guide this decision, I think this is a judgement call, and pretty much impossible to decide ahead of time. I've worked on sites which I knew for a fact would see gazillions of pageviews from the first day of launch, whether their larger business goals succeeded or failed. For a site like that, I would absolutely start by factoring ActiveRecord out into a service like James does. For more typical Rails sites, I'd start with ActiveRecord and move it out of the picture only when necessary. In my opinion this kind of split is crucial if you hope to scale a Rails site, but optional for most smaller projects.

Disruptive Wealth Creation Happens Disruptively

In my opinion, there's a little bit of foolishness here, but it's mostly dead on:

Most popular web-based businesses are deflationary. They substitute expensive forms of content consumption for cheap ones, they make it logistically easier to deliver discounts to people who will respond to them, and they create numerous financially cheap forms of social status. As more activity moves on to the web, the main effect on the economy will be broadly lower prices and less need for employment.

A related note: tech and biz journalism assumes that all forms of new technology give birth to gigantic corporations. However, what about technologies which are so fundamentally disruptive that they obviate corporate structures? Look at Y Combinator and taco trucks.



Y Combinator swoops and scoops venture capital by starting companies with much, much less money. The Internet made this possible, venture capital was slow to adapt, and Y Combinator nabbed it. Cities had taco trucks for a long time before the Internet, but Twitter made them fashionable. You don't actually need a physical location to launch a successful restaurant; you only need a long line of people eager to eat your food. (Quote from lafoodie.com: "Is a Kogi BBQ taco worth an hour's wait? Yes.")

In either case, the web made a winner out of a smaller company with more immediate, less expensive goals. For business, the web is a fat-trimmer more than anything. Combine that with the aforementioned (or actually aforequoted) blog post's notes on web economics:

The web makes entertainment cheaper...

The web makes it easier to access non-traditional employees at much lower salaries...

The web offers cheap social status: In the long term, this may have a bigger effect than the web merely making digitizable products cheaper. Social status games drive a huge amount of economic activity...

Internet companies have higher revenue per employee, which can be restated to note that they need fewer employees to get a given level of revenue.


(My emphasis.)

The blog post I'm responding to here is a bit over-optimistic in my opinion. Consider an unbalanced situation: 10% unemployment or more for the technologically illiterate, and annoying recruiters everywhere begging to hire anyone with high levels of technological literacy. At my favorite local café, the baristas have Etsy stores, but I don't think they're pulling in six figures. Disruptive economic phenomena disrupt economies.

This employment imbalance may be a short-term fluke, but it may persist until education re-orients to accomodate the modern requirement for technological literacy. Either way, it presents both enormous risks and enormous opportunities. I like to think that the end result will be more democratic, since social media and related technologies disaggregate corporate structures and make smaller businesses possible.

At the same time, however, the web's fueled a lot of new aggregation. Amazon's eaten Borders, and for some people I know, it's also replaced Target, IKEA, Staples, Home Depot, and entire shopping districts. Facebook represents the most audacious virtual land grab in history - an attempt, ultimately, to charge people rent for their own names - and for myself personally, Apple's iOS and TV have replaced HBO, AMC, Showtime, NBC, ABC, CBS, Fox, Comedy Central, Tower Music, Amoeba Records, etc., etc., etc. Pretty much every company in entertainment distribution which made money from me in the past has lost me to Apple.

But again:

Most popular web-based businesses are deflationary. They substitute expensive forms of content consumption for cheap ones...

The web makes entertainment cheaper...

Internet companies have higher revenue per employee, which can be restated to note that they need fewer employees to get a given level of revenue.


In the case of Apple vs the entire pre-Internet entertainment distribution industry, they also need fewer employees to deliver superior value at a lower price point. The average US monthly cable bill is $71 according to one study; I pay $8 per month to Netflix and $15 every two weeks to Apple for The Daily Show and that's pretty much it. In return I get content I can take anywhere I go. I can't tell you the number of times I've used iOS devices to watch movies or TV on a plane or a bus, or in a hotel or on a friend's sofa while on a trip somewhere my cable TV access wouldn't have followed me.

(I do go on occasional binges which quirk those numbers - I think I watched the entire first season of True Blood inside a single 24-hour period - but amortize the $20 to $40 I paid for that on iTunes across the several months it would have taken me under the pre-Internet model. Then compare it to the pre-Internet model's requirement that I watch on somebody's else schedule instead of my own and subscribe to unnecessary "channels" broadcasting loads of additional crap I don't want. It's still an easy win.)

Anyway, long story short, most popular web-based businesses are deflationary. It's a crucial insight.