Monday, March 31, 2008

Travel Productivity Hack: Print -> Save As PDF

A lot of airport and hotel WiFi options suck. The Print -> Save As PDF option in OS X rocks. Defeat the suck with the rock.

Here's a long article on the Web. I'd like to read it, but I just got back from Utah, my plane leaves for Scotland tomorrow, and I've got a lot to do.

Here it is in 14 lovely, legible pages, readable anywhere, even on the plane, thanks to the magic of Print -> Save As PDF.

Now I'm golden (as long as I can keep my battery freshly juiced).

Rails Error Pages Can Auto-Generate Appropriate Unit Tests And Specs

Thanks to the Laziness plugin on GitHub.

Insightful Article On Rickroll Phenomenon

But if programmers value concentration, why do they rickroll each other as much as, or more than, high school students? The anthroposocial payoff of in-jokes and pranking is obviously less among a group of professionals than it is within a network of teenagers. The answer is easy to understand. Our group studied 437 instances of rickrolling and found a consistent pattern.

Full article here

Sunday, March 30, 2008

One View Of The United States

Turtles And Seals

Saturday, March 29, 2008

Gem Update For Speed: Thank God!

Here's where you get it.

Here's why you need it:

An Elephant Paints Their Self-Portrait

Friday, March 28, 2008

MountainWest RubyConf: Notes On Presentations

Downloadable here.

ev phx rubinius

no task is too small
(goes to clay shirky/cheap failure thing)
very low barriers to contribution
one-line doc patch => commit rights
no bottom in terms of task size
every contributor has worth
forgiveness > permission
debate is healthy
you are not your project
"I'm talking to you Mr. Ego!"
You're not always right, and it's important to be wrong in public
project not about you
core contributors
the community chooses them
no keys to the castle
foster experimentation
with a large group, you get this for free
(also relevant to shirky failure is cheap thing)

"hackers and painters"-esque: citing high levels of experimentation in painting

git makes forking a non-issue - therefore you can encourage MUCH more experimentation
with no cost to the overall project

every hacker needs to read "here comes everybody"
not Ev's thing, mine; to understand why the things he said are guaranteed to be true every time

ez merb

prefer simplicity over magic as much as possible
no need to have monuments to personal cleverness in your code

"you don't need a foundation that is crazy" - Ezra on Rails meta-magic

you're always going to be wrong about what the benchmark might be
benchmark and profile
know your runtime and how it acts
"Ruby is a complex animal"

define_method 3x slower than def

"this looks so elegant" vs. "this runs so elegant"

"No code is faster than no code." - Merb's motto

Why another Ruby Web framework?
"Because I wanted to. Why not?"
Started as a hack, fun experiment

"Rails is so pioneering, so many awesome ideas, things I love, things I loathe,
awesome platform, fully support it"
opinionated software - "differences of opinion"

"Developer time is expensive, servers are cheap - therefore who cares - Rails definitely
does scale, just not efficiently"

"Postmature optimization is the root of all hosting bills"

12mb of RAM
tiny fast web services
start with tiny core, add componentized bits as needed
similar to jQuery that way actually

Rack replaced Mongrel in Merb stack
Rack turns requests into Proc calls with env hashes
returns array with headers, content
Web app turns into Proc
dude wtf that's crazy cool
adapters for every other commonly-used hosting/deployment setup

"say you're Twitter and an API is doing 80% of your traffic" - holy shit, really?

ApiHandler allows you to short-circuit entire request cycle when it's an API call
wicked clean design
obviously based on Mongrel handlers
but works across any Web server you might happen to be using
you can pass in an array of Merb apps and have the first one that returns a non-404
be the one to render to the Web
Rack FTW
make app == define class with call method which returns array
WICKED clean design

Merb has a very powerful router

Rails routing plus "much more powerful features"
auto-deferring routes on regex match against request
(reminds me of Python Twisted but not sure if that's accurate)
easily look up subdomain from DB, for instance
either return hash of controllers, actions, params, or nil, to cascade down to next deferred routes
(auto-deferring routes officially called deferred routes)

loved respond_to idea, hated syntax
provides :json, :yaml, :xml # keyword version of respond_to, roughly
Merb.add_mime_type correlates keywords to methods on objects
so fresh so clean
(except you in most cases can assume :format will call :to_format)

working on canvas-style renderer (obviously Seaside-inspired)

Merb actions much more like Ruby methods than Rails actions
no auto-rendering
return value of method is what goes to client

Abstract controller type knows nothing about the Web

merb-core / merb-more
code generators!
parts - "components done right" - ?
not callable from Web, callable from other controllers and views
Seaside/Iowa/WebObjects steelo
mailer just another type of controller
Rails mailers: "what are they? why do they live in the models directory? who knows?"
Merb compiles your templates into methods on load and calls them
somebody read the Google paper

Merb is like Rails for programmers
(that was me not Ezra)

plugin architecture for ORMs
also other plugins of course
most ActiveRecord plugins work fine in Merb (ActionPack more iffy)

Merb on github
git fosters experimentation - again, it's all what Shirky said. I'll have to blog that.
svn branching nasty, not conducive to experimentation
60 to 70 forks on github right now
encourages experimentation much much more than svn does
forks can be easily maintained, easily kept consistent to main repo's new features
without losing individuality

Yehuda: "It's definitely our mission to make Merb as easy to set up as Rails."

Rails moving to git
core team won't be monolithic thing any more
promotes survival of the fittest
"it's an open source project to begin with, distributed version control is a
much better way of working with the community"

Performance question on Rack stuff
Merb architecture allows you to separate which actions go to which servers

Quite a few large clients using Merb, usually in conjunction with Web services
startup I worked with resisted this, I have to say in retrospect I think they
were (very probably) utterly wrong about that
(Ez didn't name names, I can't either)

profiling question
ruby-prof ftw
for Matz' Ruby

Rubinius has nice built-in profiler with no performance side effects
ruby-debug ftw
Merb has built-in profiling options (of course)
Bleak House ftw

Parameter passing for Merb actions?
method definition tells controller what elements in the params hash to find
controller automatically maps that to a variable
I wonder how the hell they did that - they must use magic too, like Rails, but more judiciously
ParseTree, Ruby2Ruby
fucking MIGHTY
sexp heh heh heh heh heh.

Dev mode, like Rails, skips DB access solution during dev
maybe they didn't read the Google paper; maybe they just discovered it independently
the feature is opt-in
they made Windows binaries for ParseTree and Ruby2Ruby so Windows devs could deal

Jim Weirich: "action args really cool, but seems like magic - where draw line?"
Ez: usefulness
that's why it's in -more rather than -core
"probably most magic part of Merb"

(me: I don't see why they call it magic. I really don't get why everybody calls this stuff magic.)

EY => mostly 99% Mongrel, but maybe 20 clients on Thin
Ebb hella fast (for short requests)
very young, wouldn't recommend in prod yet
neither Ebb nor Thin handles long requests well compared to Mongrel

"almost all apps I see in the wild have 2 to 10 second requests"
not sure context for that tho
specific to particular server implementation stuff

throughput of event-driven servers drops like crazy in long-running actions

Merb 0.9.2 recently went to RubyForge
1.0 "still a little ways out"
aiming for very polished and feature-complete @ 1.0
thereafter seeking to be community of modular features
platform, ecosystem, rather than perpetually ongoing project

this reminds me of when he was doing the Yakima Herald stuff. smart as hell.

continuations / deferrables
damn sure that's something to do with Python Twisted
I think they were called Deferreds
wish network wasn't so FAIL

Merb Manning book coming soon
hell yeah

"if anybody wants to write some documentation that would be great"
doc/api standards
public api different from private apis
private specs, public specs
public API: contract with users
private API: completely changeable as long as public contract remains intact


couldn't take notes during Yehuda Katz's presentation because finding a seat after my own
was basically impossible. standing room only. long story short: DataMapper awesome.


Jay Phillips identified stuff in my Rubinius code which could actually be done in Ruby
as well.


jon younger amazon w-s
rightscale SQS plugin
discrepancy between requested SQS instances and actual (?!)
kato - pool manager
based on Lifeguard (Java)
Kato Ruby port of Lifeguard
RightScale gems
Amazon charge full hour for any hour within which an EC2 instance runs; Kato config
therefore takes definitions for minimum runtime required to justify new instance
Amazon AWS imperfect

chunky bacon workflow

Amazon reliability / responsiveness imperfect, but still effective / useful

teh criterion: requires elasticity, dynamic scaling

farm scaling component to AWS, keep gateway box on 24/7 somewhere in colo

scalable CI on Amazon AWS
commits go into S3
filename plus metadata into SQS
CI process runs on EC2
really wiggy!
ec2/sqs emulation: merb apps with god
wonder how he did the UI, that was awesome
rightscale plugin monkey-patched to hit local DB(s)


Tom Mornini interested in tying Merb/DataMapper/jQuery back to Rails, to avoid fragmenting the
community, but I think it's a pretty kick-ass entirely-alternative stack. I think more
probably Rails will adopt some of this stack's fixes to achieve better performance but still
have its own specific goals which are different enough from Merb/DM/jQ approach that the
two can very peacefully coexist.


guessmethod - levenstein distance method-guessing - kicks ass
Clss.nw.clas.should == Class # => true
grake - method-guessing rake


active_scaffold -> Ajax scaffolding
one-click PDF translation, kick-ass
Ed (Borasky?) also maintains localization plugin, so localization built in


Josh Susser's migration concordance plugin
up on github
checksum migrations to see if they've changed
(I still say only ever use rake:auto:migrate, but that's a good idea)


Jeremy McAnally: domain-specific frameworks on top of Rack
I'm not sure if that actually is Jeremy, his hair looks different


language parser
resource abstraction

think I saw this demo-ed at FOSCON

except for package mgmt, no real evolution of sysadmin tools compared to dev tools

sophisticated automated systems as collections of components???
services restart on changes to files they've subscribed to

highly portable

lots of people using it, incl. Google, Wesabe, Geni

"manage services, not servers"

Puppet language, not valid Ruby
Luke - yes I did see this demo-ed @ FOSCON
tried in Perl, failed, it worked in Ruby


solution for uploading many images, not just one
PHP, .NET, Ruby
hidden flash movie file looks like OS
realtime upload indicator
Rails thinks it's getting one image at a time, looks as if doing bulk upload
JS for styling, everything standards
just stubs out a browser weakness, runs it in Flash
small hacking required to make JS work with Rails (in new SWFUpload)
Ajaxy stuff too, not totally sure what he's saying but it's obviously a useful technique


RubyAmp(ed?) TextMate bundle
Eclipse-y magic nav in TextMate
looks as if it might become highly recommended for TextMate dev
part of this just replicates stuff I already did in Utility Belt, though.
I need to work on my marketing. :-p


JRuby -> Swing
monkeybars! I've heard of this thing before
people were talking about it on ruby-talk I think
building a GUI in a GUI builder in NetBeans.
rake generate - that's a good idea. Rails (script/generate foo)s should probably all be (rake generate)s.
auto-gens jars


PJ Hyett


Joe O'B from EdgeCase

85% of software cost maintenance
quick dev attacks 15% of the problem
readability is why Merb matters (me not Joe)
Rails maintenance too polarized: either power-user or total n00b
maintenance and minor changes easier with DM than AR
modifying existing app with new stuff easier with more flexible app dev (Merb)
Eric Raymond "Art of Unix Programming"
Fowler's external/internal DSLs distinction
forgot to mention in my own pres, "Code Gen In Action" talks about DSLs using different name
"full-domain languages"

OK my brain is fried.

Online Newspapers: The Problem And The Solution

The problem.

The solution.

Thursday, March 27, 2008

MountainWest RubyConf Location FTW

Plato Says Knock You Out

Update: This is not really a blog post. This is really just a gigantic Twitter post. I stand by every word in this post, but only in the context of the frameworks panel at Philly ETech. If you weren't there when that happened, please don't generalize this to the broader universe, as you'll really just be wasting time.

That being said, I think the comment thread on the Ruby Reddit is unusually good.

Watch out - I'm rolling Yegge-style today. I wrote this while waiting for a plane, and I don't have time to edit it properly.

37 Signals recently blogged that we have healthy debate in the Web dev community but we never see it at conferences. They would have been satisfied yesterday. Obie Fernandez spoke as part of a panel at the Philly Emerging Tech for the Enterprise conference yesterday. The panel was billed as a battle of the Web app frameworks, and Obie took the battle part literally. He didn't pull any punches. The panel nearly broke out into a fistfight when people started getting into things like Eclipse vs. vi. When somebody started saying Twitter proves Rails doesn't scale, Obie shouted "That's bullshit!" - in fairness, many people in the audience nearly did the same thing.

Obie kind of came into the session loaded for bear. Here's why I think that was cool.

Plato's Republic introduced the allegory of the Cave to Western philosophy. The Cave is a place where people see shadows cast by faraway objects. People in the Cave imagine these shadows are real. The philosopher is someone who escapes the Cave, discovers the real world outside and all the real things in it, and returns to the Cave to tell everyone what they've learned. The challenge the philosopher faces is explaining real objects to people who only know shadows.

There's an interesting variant on the allegory of the Cave in early science fiction. An explorer stumbles wounded into a lost country where nobody has eyes. The natives restore his health and he falls in love with a local girl and marries her. He enjoys a strange status in his new society, because smells and sounds which everybody else can perceive readily are obscure to him, while at the same time he has access to entire classes of perception which his new community doesn't even have words for. Eventually this causes friction between the explorer and his father-in-law, a powerful man in this blind country, who orders a bunch of doctors to examine the explorer and figure out what to do. The doctors discover freakish orb-like growths in the man's head and realize they have the power to restore order to their society with a simple surgical procedure.

I think I read this variant via Paul Graham originally, but it doesn't really matter. The moral of the story is that you have to be careful when you bring the light of the real world to dwellers inside the Cave, because they're not necessarily going to believe you and they have the ability to seriously rain on your parade. Several people who saw the panel said Obie could have been more diplomatic; that it's a lot easier to say, look, this stuff makes our lives better, it can make your lives better too. From that point of view, picking fights is seriously counterproductive. It's a completely reasonable point of view. But there's another point of view, which says that people who might take your eyes out of your head because your visions disturb them are better kept at arm's length.

At this stage, if you've heard of Rails and you haven't converted, it's entirely possible that you never will. It's also entirely possible that anybody who still isn't even taking Rails seriously by this point might just be some kind of idiot. Certainly, people who meet that profile might not really be the type of people we need to add to our community.

Every programmer should read Fred Brooks' "The Mythical Man-Month." Its primary lesson is that adding new programmers to a late project only makes it later. The corollary is that adding incompetent programmers to a thriving project is unlikely to improve that project in any way. Anybody who still doesn't take Rails seriously in 2008, and still imagines Twitter to have some kind of scaling problem, is probably incompetent to some degree, at least insofar as their Rails-related blind spots are concerned, and therefore probably not likely to become a huge benefit to the Rails community. To put it bluntly, they're doing us a favor by being somewhere else.

Every programmer should also read Chad Fowler's "My Job Went To India" book, where he explains that as larger and larger numbers of programmers adopt a particular skill, that skill becomes more and more a commodity. Rails development becoming a commodity is really not in the economic interest of any Rails developer. This is especially the case because programming skill is very difficult to measure, which - according to the same economics which govern lemons and used-car markets - means that the average price of programmers in any given market is more a reflection of the worst programmers in that market than the best. An influx of programmers drives your rates down, and an influx of incompetent programmers drives your rates way the fuck down.

But this means there's actually a very good use for angry outbursts like Obie's, and for taking a confrontational attitude in general. Incompetent programmers are already too common in the Rails community. Anything which keeps more of them out is a good thing, and telling them to fuck off is a pretty good way to start a conversation with them. It's a pretty good way to end a conversation with them too. It's pretty much the only conversation you need to have with them at all. In 2005 and 2006, anybody who discounted Rails or underestimated it because of its bratty image could be forgiven - but by now people should have realized, unless they're complete fools, that the only way you can stay in business at all with that kind of attitude is by being really fucking good at what you do. That's as true for communities as it is for people, and the prevalance of arrogant, immature rock stars with tons of money in our community is a very different thing than a proliferation of arrogant, immature wannabes with nothing in their pockets would be.

This doesn't necessarily apply to every programmer out there, busy with his or her own work, but it certainly applies to anybody who develops frameworks or writes books about them - and everybody on the panel fit that profile. A certain amount of ignorance about other people's communities is natural, but cultivating that ignorance deliberately is a hostile, prejudicial attitude.

I'm not saying Rails is perfect. That's crazy talk. But to think in 2008 that what was true of Rails in 2005 is still true is just irresponsible and unprofessional, and you don't want to compete with irresponsible and unprofessional people, because the only way to do it is by entering the market for irresponsible and unprofessional services. Those are not the kind of services you want to provide. You only want to compete in a marketplace where skipping your due diligence costs you business. If you alienate developers who don't do their due diligence when developing their opinions, you separate yourself from the segment of the market which they dominate. This is a good idea. The segment of the market dominated by programmers who don't bother with due diligence is the segment of the market which serves employers who don't value due diligence. Those are employers to avoid.

The Web application frameworks ecosystem is infinitely richer today than it was before Rails came on the scene. Rails taught many existing frameworks new tricks and got schooled here and there as well. Anyone who uses Web app frameworks in 2008 has options to choose from, and anybody who develops these frameworks benefits from this combination of competition and collaboration. Closed-mindedness and arrogance on the part of any particular framework's community is detrimental to every framework's community. Attacking it makes perfect sense.

That's why when we got the chance to ask our questions, I asked the most antagonistic, obnoxious question I could think of. ("Is there a difference between frameworks which are old and frameworks which are mature?") Or at least, that's one reason. The other reason: it was fun.

Wednesday, March 26, 2008

Seaside Startup Sells For Serious Samoleans

via TechCrunch. Unfortunately there's no mention of it in the TechCrunch post; the only reason I know it's a Seaside startup is because one of the founders told me so after one of my several blog posts about Seaside. Unfortunately also the lead TechCrunch guy says he's not going to pay attention to the story any further because it's not going in a glamorous or exciting direction - just one that makes money. Further proof of the fundamentally weird dynamic between programmers and businesspeople.

Monday, March 24, 2008

Nothing Will Ever Reign Supreme, Ever Again

So I kinda went nuts on somebody else's blog:

In my defense, it felt really good.

Here's a book which will explain where I'm coming from:

You should buy it immediately.

It doesn't actually explain my point of view; it just gives you the background based on which I expect the rest to be obvious.

(I should write this up in a productive, useful way to be a little less anti-social and aloof, but I'm really tired.)

Saturday, March 22, 2008

Haskell Job In San Mateo (Maybe)

The maybe because startups sometimes lie about the technologies involved just to get smart people in the door. Found it here, dated March 13.

Robot Warriors Will Destroy America

You might think you know what I mean.

Not quite.

Military robotics trends point in some scary directions.

And military robots are becoming very effective, very quickly.

The 80s-movie doomsday scenario here is robot genocide against humans, or more simply, robots used as a weapon of oppression.

But this scenario overlooks two very important, fundamental phenomena which have historically always influenced the real-life use cases for any technology:

1. Miniaturization

2. Commodification

As cool as a $30 miniature helicopter is, that's nothing to a simple palm-sized flamethrower you can build for about the same cost.

It's only a matter of time until somebody glues a $30 miniature remote-controlled helicopter to a $30 palm-sized fireball launcher to scare the living hell out of their neighbor's cat.

But there are serious repercussions as well.

In the early 90s, I wrote an ebook and uploaded it to America Online. It was called "In Defense Of Terrorism." I'm scared to even tell the world I wrote this now, with Guantanamo Bay and unjustified persecution becoming commonplace. But what the hell. If Harold and Kumar can escape from Guantanamo Bay, maybe I can too. I'll tell you my defense of terrorism.

Terrorism is worse than pacifist nonviolent protest - but it's better than war. I'm going to assume that the worse than nonviolent protest part is obvious. Here's why terrorism is better than war: less people die, and terrorism achieves the same result.

War is violence which achieves political goals. Terrorism is the same thing. A lot of people think of terrorism as irrational and unpredictable, but it's no more so than war. A lot of people think terrorism never produces real political results - and they're completely wrong. Study the history of Sinn Féin, the PLO, and the Irgun - there's a consistent trend of terrorist organizations "growing up" into legitimate political parties.

This ebook I wrote went into detail and fully charted the parallels, but I don't have time for that here. If you read the links looking for these parallels, they're pretty easy to spot. My goal with the ebook wasn't actually defending terrorism per se, but pointing out that you could see terrorism as a cheaper form of war - cheaper both in terms of materiél and in terms of human casualties. I can't totally stand by the argument, though, because what I didn't realize at the time was that there's a significant upside to war being inherently expensive, in that the expense and the logistics act as a dampening factor on warlike tendencies in any given society. It's kind of a good thing when people have to really think it over before going to war.

So even though at the time I thought I was sure terrorism was actually better than war, these days, I have to leave it as an open question. Either way, though, terrorism functions as a cheaper version of war. It's organized violence which results in substantial political change. It's a lot like war. It's just smaller.

You might wonder what this has to do with robots.

Let's flash back to one hypothetical image of military robots in the future.

Scary. But we know that's not going to happen. We know it's not going to happen because we know about commodification and miniaturization, and the fact that we can build a simple proof-of-concept remote-controlled flying miniature flamethrower for around $60. That means that if/when robots are used against humans, they won't get bigger and bigger as they get more and more sophisticated; they'll get smaller and smaller, and as they get smaller, they'll get cheaper, too.

(Actually the if is a lie; there are already military robots in Iraq and Afghanistan, and although officially none of them are armed, one of them is very well-specced for use as a roving gun platform. But even with all that, the points about miniaturization and commodification hold true. These robots are smaller than people, and will become even more so as time moves on.)

What direction does that point us in?

For the record, I'd just like to tell you how I discovered the above video. Using the above reasoning, I logically deduced that this video would exist, and then I went on YouTube searching for it, and it was right where I expected it to be. Now this process of logical deduction began in the early 90s at least, but I'm still taking that as a fairly powerful validation of my reasoning. I actually wrote a very bad screenplay where miniature robot weapons figured predominantly, also in the early 90s, but at the time I didn't have the experience in the technology industry to acquaint me with the organizational implications of commodification and miniaturization. Back then I really only knew they'd be small and numerous.

Anyway, this is a bit of a tangent. Just to wrap it up, I've found a few related videos as well.

Now the question is, if terrorism functions as a cheaper version of war, what will military robotics swiftly become?

Here's a big hint: consider that you don't actually have to be a government to build a giant robot.

Next consider that most military robots won't be giant anyway.

And then consider that late last year, the United Nations nearly declared the United States to be one of the many nations in the world with child soldiers, based on the reasoning that many ghettoes in America function as undeclared war zones, where children carry guns.

Now take a look at this picture from a recent LA Times story about a shootout in LA which occurred between gang members and quote-unquote "police officers":

"Police officers" my ass. If you're wearing camoflauge and body armor, and you're carrying an M16, it does not matter what your spokespeople stand up and say to the press. These men are obviously soldiers.

So here's what I'm saying. Terrorism is cheap undeclared warfare. Undeclared wars already happen in the United States. And within the next few decades, advances in robotics, and more importantly, the commodification and miniaturization of advances in robotics, will make the weapons available to the politically disenfranchised and/or criminal-minded dramatically more effective.

Today, individuals can single-handedly create and run multimillion-dollar companies. With every advance in information technology, the size of the average company shrinks. What will advances in weaponry do to the size of the average country, or the average army?

Robot controlled by Nintendo DS

What if the size of the average country is a function of the size of the average army?

Commodification and miniaturization doesn't mean a proliferation of robot weapons - it means a proliferation of robot soldiers. When soldiers become cheap, wars happen more easily. This will dramatically magnify regional political variations, and make government at the Federal scale really difficult to maintain. If you can strap a gun or a pipe bomb to a remote-control helicopter, that makes highly tactical urban warfare cheaper than a crappy used car. And that's just what we have today. In the near future, highly tactical urban warfare will become cheaper than a crappy iPod. Our current assumptions about government just don't operate at that kind of scale. It'll be like Microsoft competing with 37 Signals. A dinosaur doesn't realize it's competing with mice until too late.

When I say robot warriors will destroy America, I don't mean there's going to be this big war with big robots crushing big tanks. I mean there's going to be lots of tiny conflicts with lots of tiny weapons, which will in aggregate exert this tremendously powerful erosive effect which will transform every idea of government we have and force societies everywhere to re-organize at unknown scales and in unknown ways. Robot warriors will destroy America because robot warriors will change the nature of war so much that all countries will become obsolete.

Update: Some of this is already happening. Markus Prinz reminded me about the Boing Boing post about a man who built a vigilante robot to patrol his neighborhood and spray "unsavory characters" with water. It looks like a steampunk Dalek, but it's a sign of things to come.

Update: iRobot machine gun platform Wiimote hack

Friday, March 21, 2008

VC Philanthropy Solves Recidivism Problem

SAM AMAYA was six years old when he first pulled a gun on another person - his father, who was beating his mother...

He began running drugs as a teenager, picking up consignments of marijuana and cocaine near the border with Mexico and selling them around Texas...

Mr Amaya was arrested after pistol-whipping a girlfriend and is today, at 28, about to finish a long sentence for aggravated assault. Statistics would suggest that he will be back before too long: according to the Pew Centre on the States, more than half of released offenders return to prison within three years...

Just before he is released on June 23rd, if all goes to plan, Mr Amaya will graduate from the Prison Entrepreneurship Program...

many criminals are intelligent people with good heads for business and healthy appetites for risk, and that these traits can be put to productive use...

During the past four years PEP has put more than 300 inmates through four months of business classes and study...

Fewer than 5% have reoffended.

Rehabiliting prisoners: a new deal @ the Economist

Wednesday, March 19, 2008

Interactive Writeboard: Avoid Streamlight Stylus

If you're trying to build one of these:

Don't use one of these:

They're much too directional to be useful.

Burning Man Engineering: Steampunk Treehouse

Tuesday, March 18, 2008

But I'll Never Be Able To Use That Language For Real Work

Write a simple Web application in it.

Create a Gentoo Linux customized for it.

Deploy to a cheap VPS.

No complaining allowed.

Monday, March 17, 2008

No Flash On The iPhone Could Be A Good Thing

Some people say it's Adobe, refusing to license to Apple unless Apple tanks Preview.

Fortune magazine found a more plausible theory.

Usability: Alphabetize Dropdowns, If You Use Them At All

Sunday, March 16, 2008

Live-Coding MIDI In TextMate With Ruby

I found some code in Topher Cyll's book and adapted it to my own purposes.

Inge Jørgensen found this code and adapted it to his own kickass purposes.

Meta-Variable Interpolation Cleaner In Perl Than In Ruby

For the most part, I'm a Ruby partisan. But this really sinks my battleship:

Look how much cleaner it is in Perl:

And that's with extra code added in to populate the variables so you can run it and see what it does.

I'm going to have to fix this some day.

Update: solutions from Nicolás Sanguinetti:

and Assaf Arkin:

Both these solutions are cleaner than my Ruby, but I think neither one is as clean as the Perl.

(And neither one addresses the more challenging Hpricot use case.)

This local_variables thing is one shiny new toy, though. I never saw that before.

The other interesting discovery: Nicolás says PHP has this syntax too, and calls it "variable variables." Apparently in my language snobbery I underestimated PHP. Nicolás also said that he'd been up for 26 hours on too much coffee. Dude, Nicolás, get some sleep!

Update: Dan Yoder's solutions:

puts "<img #{%w( src width height ).map { |attr| "#{attr}='#{eval attr}'}.join(' ') }/>"

assuming, as you do in the Perl example, that the attributes are already locals, since it isn't really fair to lump the hpricot interface into this. Even if we include Hpricot tho:

puts "<img #{%w( src width height ).map { |attr| "#{ attr }='#{[attr] }'}.join(' ') }/>"

it's been awhile since i hacked in perl but i don't recall being able to do things like this in one line. :-)

But again I think the Perl remains cleaner. I'm not saying it can't be done a variety of ways in Ruby - I'm just saying the Perl solution is nicer-looking than any solution I've seen in Ruby.

Update: Dan's response:

Consider, however, that it only works for variables, whereas the Ruby syntax works for any expression. Should Ruby have a separate interpolation operator for locals, like, say '$$'? Or maybe keep the interpolation as it is an introduce an operator that says "eval this":

"#{attr} = '#{$attr}"

Ah, but wait! We can actually define such a thing if we want ...

class String
  def ~ ; eval self ; end

"#{attr} = '#{~attr}"

and I am still free to use an expression here to get the value of attr if I want. I think Ruby gets it right just because it provides a single powerful interpolation operator inside of which we can do whatever we want. :-)

In fact, that is why I can write the whole loop in a single LOC. It's all inside the quotes!

No way around it - that kicks ass. The Perl really remains cleaner even still, but it does so by a much, much slimmer margin than before, and the payoff for that slim margin is a lot of power.

Saturday, March 15, 2008

Facebook Beacon Is Horrible And Creepy

Luckily it's guaranteed to die , because its foundation is totally unsustainable.

For every long-lost chum who reaches out to me on Facebook, there's a guy who beat me up on a weekly basis through the whole seventh grade but now wants to be my buddy; or the crazy person who was fun in college but is now kind of sad; or the creepy ex-co-worker who I'd cross the street to avoid but who now wants to know, "Am I your friend?" yes or no, this instant, please.


It's socially awkward to refuse to add someone to your friends list -- but removing someone from your friend-list is practically a declaration of war. The least-awkward way to get back to a friends list with nothing but friends on it is to reboot: create a new identity on a new system.


That's why I don't worry about Facebook taking over the net. As more users flock to it, the chances that the person who precipitates your exodus will find you increases.

People really need to rethink their assumptions when they get all worked up about Facebook, Myspace, or whichever social site has the biggest/fastest-growing community at any given time. Those communities are transient communities, like nightclub communities. Building Facebook apps can be a good idea, but it's an idea with an inherently limited shelf life.

One-Liner To Get RSS Feeds Out Of Safari

Couldn't find any export option in the File menu, so:

sqlite3 ~/Library/Syndication/Database3 'select url, title from Sources;'

Friday, March 14, 2008

Time To Fix The Radar

Tim Bray's rationale for advocating PHP and Ruby on Rails:

If you and I have the same good idea for a community-based Web site on the same day, and mine is on the air in five months and yours in eight, then you’re dead. And it doesn’t matter if yours is better, because the community has gathered.

Twitter would be the canonical example. They went with Rails because it let them build fast; and they built fast...they’re in a very good place. Smart people tell me that Pownce and Jaiku are slicker and better but who cares?

There are a few problems with this line of reasoning. First, five months to build a Web app with Rails is pathetic. Second, Yahoo was first to market, and Google won. Third, Twitter is not profitable, and if it went out of business today, its entire community could migrate to a new system overnight.

The Rails community does not need people who evangelize to the venture capital culture that using Rails makes your startup a faster, nimbler locust. With a few exceptions the venture capital culture is fundmentally unhealthy. Many things that the VC culture has given the world in the last decade, both in terms of technologies and economic trends, have been bad for everybody involved.

Similarly, putting Rails in a category with PHP is not good for Rails. Rails already has too many things in common with PHP, both technologically and culturally. This is a bad thing.

Long story short, Tim Bray shows up on my radar way too often.

Thursday, March 13, 2008

OS X: Disable Front Row Keyboard Shortcut

If you're like most Mac users, you probably have had the surprise of discovering your copy of Front Row. In Leopard, they improved the design, and Front Row now identifies itself as Front Row. In Tiger, all you got was this mysterious, condescendingly cheerful UI with no identifying features, which appeared out of nowhere like a fucking ninja and took over your computer for no obvious reason, giving you a variety of unappealing, irritatingly "friendly" options.

When this happens in the middle of an intense coding session, it's kind of like getting kidnapped at gunpoint and forced to go to McDonald's.

If you're like most developers who use OS X, you probably want to remove this Front Row thing from your computer. There are two ways to do this. One way is to trash the application itself. I haven't tried this; I'm afraid to. Traditionally, software of this nature reinstalls itself if you uninstall it. (See, for example, the "Downloads" and "Music" folders in OS X, or nearly every folder in the Windows XP filesystem.) Worse yet, sometimes, when you throw it away, it comes back angry.

Here's the safe and easy way to get rid of Front Row:

Why Only Emacs Uses Lisp

Why is it that the primary use case for the world's most powerful language is pimping out text editors?

Doesn't that imply that the technology industry as a whole squanders resources to an absurd degree?

Imagine if doctors did surgery with sharpened rocks and only used laser scalpels to open their junk mail.

Many programmers know that the costs of using powerful languages are low, and the benefits are immense. Cost-benefit analysis is obviously a useful strategy. Why is it not the most popular strategy?

The answer is simple.

When a nontechnical person tries to perform cost-benefit analysis against technological strategies, they're basically solving for value, where value equals benefit divided by cost. That's trivial arithmetic. But even though it's trivial arithmetic, it's unsolvable trivial arithmetic, because value is unknown, benefit is unknown, and cost is unknown. Question mark equals question mark divided by question mark.

x = y / z
solve this equation, for all values of x

Wednesday, March 12, 2008

More Metablogging: Return Of Kathy Sierra Rumored

Hope it's true

How To Release 10 Open Source Projects In 3 Months

In December, January, and February, I released about ten open source projects (and initiated more).

The reason is that three things happened at roughly the same time.

Debugger Flamewar

The debugger flamewar made me disinterested in blogging.

Chess Club Poseur

Charles Nutter persuaded me that writing code is worth more than writing about code. (I disagreed with him at first, then saw the light.)


I spent too much money and had to forego acting classes for a month.

You might think that's a minor thing, but it was actually the most influential thing, for two reasons.

First, people in Hollywood observe an utterly psychotic work ethic. Startups only hit the lower bound of the Hollywood work ethic's range. Seriously. They're demented. In a good way. People in Hollywood make Jason Calacanis look like a stoned slacker sleeping on his mom's sofa in the basement. Even the lazy ones. So taking a break from acting classes means freeing up a lot of time.

Second, acting classes train you, more than anything, to associate into your experience. "Associate" is used here in a technical sense which comes from hypnosis. The technical meaning is enormously difficult to compress for the uninitiated, especially if you want a great deal of precision and accuracy, so I'll simply say that acting classes cause you to become more intense and dynamic. For more details you really need to find some very good books on hypnosis/NLP/etc., or just take some exceptionally good acting classes.

So, I spent a ton of energy developing an intense work ethic and becoming a more dynamic person. I decided blogging attracts people who have too much time on their hands. I decided that writing code was worth more than writing about code. And then I suddenly had a bunch of spare time. So I released about ten open source projects in three months.

I kind of hope my progress will slow, because frankly, I'm back in acting classes, so it's messing with my sleep schedule, but if you want to know how to increase your productivity as far as the open source community is concerned, there's one way to do it.

Edit: I started this blog post a while ago and left it in draft mode for a while. My progress hasn't slowed, but I did narrow my focus. I'm really only working on my favorite of all the new projects now, which is probably kind of irritating to people who are using and/or developing the other nine. Sorry.

Anyway, there's an interesting footnote here, and it's the reason I took this thing out of draft mode and finally posted it. One of the most popular programming bloggers I used to read was Jeff Atwood. I can't read him any more. His blog turned as boring to me as a weather report from Antarctica. "Snowy, with a strong chance of snow. Next up: we interview penguins to determine how they feel about this recent development." And that was before he decided to bravely tackle the fascinating topic of Mac vs. PC.

I bring this up, unfortunately, because I just learned that Atwood left his job to make blogging his main thing. I left this post in draft mode for such a long time because I didn't think it was worth blogging about; basically, the point of this blog post is that blog posts are not always worth writing. It's like, oh, I better blog that one right away. The world must know!

Sadly however this is now topical, and unfortunately not in an entirely positive way. For every blog post which sharpens your saw there's a ton which are nothing more than daytime TV for programmers. Every once in a while Atwood writes something very good. I've got nothing against him. But I have to say, even if I had the gazillion readers Jeff has, I think I'd be much more likely to shut down my blog for good than to go pro, and I'm kind of proud of that.

Tuesday, March 11, 2008

Ruby's Most Succinct Strategy Pattern Implementation Possible

I could be wrong about this but I believe I'm using it.

Here's how you set it up:

(The assumption here is alias :L :lambda.)

Here's how you use it:

Since you've got Procs as instance variables, swapping out the strategies is as easy as declaring

attr_accessor :strategy

and then saying

Widget.strategy = lambda {|*args| do(stuff)}

To invoke your strategy from within the Widget, just do



@strategy[:foo => "bar"]

Design patterns remain useful in Ruby, but they become much, much more compact.

By the way, in the above code:

@when is assigned the value of running @next against a @queue. If you check the top of the page you'll see that @next is a Proc, which means you can modify dynamically how it computes the next value in the queue, simply by setting a new value for @next. But what's interesting is that @queue is a queue of Procs, and elsewhere in the code base there are calls to @when which leverage the fact that it's going to be a Proc.

This kind of system, where you have strategies for selecting strategies, could be unwieldy in many languages. It's smooth as silk in Ruby.

Nailed It In One

A music education has been made mandatory. "We are helping our students become more competitive in an increasingly sound-filled world." Educators, school systems, and the state are put in charge of this vital project. Studies are commissioned, committees are formed, and decisions are made - all without the advice or participation of a single working musician or composer.

Since musicians are known to set down their ideas in the form of sheet music, these curious black dots and lines must constitute the "language of music." It is imperative that students become fluent in this language if they are to attain any degree of musical competence; indeed, it would be ludicrous to expect a child to sing a song or play an instrument without having a thorough grounding in music notation and theory. Playing and listening to music, let alone composing an original piece, are considered very advanced topics and are generally put off until college, and more often graduate school.

As for the primary and secondary schools, their mission is to train students to use this language - to jiggle symbols around according to a fixed set of rules: "Music class is where we take out our staff paper, our teacher puts some notes on the board, and we copy them or transpose them into a different key. We have to make sure to get the clefs and key signatures right, and our teacher is very picky about making sure we fill in our quarter-notes completely. One time we had a chromatic scale problem and I did it right, but the teacher gave me no credit because I had the stems pointing the wrong way."

- A Mathematician's Lament

When I was reading Euclid at St. John's College, partly in the original Greek, it was the first time in my life I enjoyed a math class. Today I read math for fun. Parents, don't let your kid take math classes. Your kid needs to understand math, and math classes stand in the way more often than they help.

Sunday, March 9, 2008

Simple Metaprogramming Logger With Graph Generation

Avdi Grimm's objections to monkeypatching overkill, which I've blogged about before, ultimately inspired this code.

Monkey-patching is the new black. It's what all the hip kids are doing, to the point that smart, experienced hackers reach for a monkey patch as their tool of first resort, even when simpler, more traditional solutions are possible.

I don’t believe this situation to be sustainable. Where I work, we are already seeing subtle, difficult-to-debug problems crop up as the result of monkey-patching in plugins. Patches interact in unpredictable, combinatoric ways. And by their nature, bugs caused by monkey patches are more difficult to track down than those introduced by more traditional classes and methods.

Pat Maddox responded to Avdi's post with a self-logging alias_method_chain. I decided to follow Pat's line of reasoning into the wild wild West of Rubinius, and create self-logging versions of Module#include and Object#new. I figured the best way to resolve bad monkey-patches would be to monkey-patch monkey-patching itself.

To run this code, you'll need a copy of Rubinius. I developed it against Rubinius as of March 4th, so it's a few days out of date, but that probably won't matter. It functions as a very simple proof-of-concept for metaprogramming loggers: it logs to STDOUT when modules get new methods, or objects get instantiated. (It should also log when modules are included, but I forgot to do that part.)

Here's some of the code. (Grab the Pastie for all of it.)

This code includes a module on a class, and then calls the mixed-in method. That part's obvious. It shows up on your screen when Rubinius logs it, via a modified version of __add_method__, which is an internals method on Module.

I got the first method, Class#new, from the comments/RDoc in the Rubinius source. I think they actually included it as a joke, or at most a simple demo, but it's fun to actually turn it on and see what it does. The other methods in my logger are equally obvious.

Here's the output.

minimal output, from the command line

verbose output, from within irb

So far, so good. It's pretty trivial to modify Rubinius in such a way that Ruby automatically logs the ongoing internal activities of its class and module system. That's nifty.

Logging really isn't enough, though. These are toy methods, and logs are for computers to read. If we write a slightly more sophisticated system, we can generate object/method graphs semi-automatically.

The first step is to target the right grapher. I'm feeling some peer pressure to use Gruff or Shoes, but the simplest option here, Nodebox, combines Photoshop with Processing, and adds a Python scripting interface.

We're going to need Python output which Nodebox can use to generate a graph. We've already got text output. First, we modify our Rubinius code to change the text output into Ruby output.

Capturing this in an actionable format is trivial.

./shotgun/rubinius nodeboxr.rb > objex.rb

Next we write some additional Ruby code to eval this Ruby code.

This generates Ruby objects. With ERB, it's easy to transform those objects into Python code. Here's the Python to create an utterly trivial graph:

A fully robust solution would include some code to arrange the nodes around the screen. I've played with that kind of stuff in the past, and it's satisfying when it works. Here, though, I'm going to skip that and just target the simplest use case.

Here's the ERB Python template.

Here's the Ruby which populates it.

Calling it, of course, is trivial.

./shotgun/rubinius templater.rb >

Next step: go into Nodebox, open the Python file, and hit command-R to run the code. We've already seen what that looks like; the only difference here is the name of the file in the window's title bar.

It's probably worth mentioning that Nodebox can generate graphs dramatically more complex than this.

superfolia, written in nodebox python

Obviously, our object graph is primitive by comparison. That's fine. Pretty much every step of this post addresses simplified versions of the real problem space, and if you look it over you'll spot some extremely blatant cheating. That's kind of the point. I wrote this code in a day, it's all pretty trivial, and it visualizes information which people were claiming an entire programming philosophy irretrievably obscures.

If you have incredibly powerful tools, you can do a lot with very little effort.

δος μοι πα στω, και ταν γαν κινάσω
"give me place to stand, and all Earth I will move"

Code generation's an incredibly powerful tool; John McCarthy's fundamental insight that code is data remains equally powerful whether you leverage it from within Lisp or across a Unix filesystem. Rubinius is also incredibly powerful; if modifying classes and modules in real time is metaprogramming, then modifying the systems which enable that flexibility must be metametaprogramming. Whatever the term, when we combine an excellent strategy like code generation with a turtles-all-the-way-down language implementation like Rubinius, we can create very powerful analysis tools very quickly.

King Yertle