Making your oss project more like rails

Preview:

Citation preview

{OSS Project

Friday, April 16, 2010

{ Rails

Friday, April 16, 2010

Merb

We were trying to do:

* more choice* more modularity* more performance* toolkit for building other stuff (SproutCore)

These things sound counter to Rails’ philosophy... goes to show that seemingly oppositional OSS ideas may not, in fact, be oppositional.

Solving problems given competing constraints is the truly hard problem in OSS.

Friday, April 16, 2010

Question

Friday, April 16, 2010

Why does Rails make devs

happy?Friday, April 16, 2010

“Optimized for Developer

Happiness”Friday, April 16, 2010

Friday, April 16, 2010

Optimizing Locks You In

Friday, April 16, 2010

Harder, but possible to

optimize laterFriday, April 16, 2010

Defer Optimizing Measurable

ThingsGathering data will make your measurable optimizations better

Friday, April 16, 2010

One of the worst things you can do is ask your users to individually bear the cost of an optimization (modularity, perf)

Friday, April 16, 2010

Dynamic

Friday, April 16, 2010

Rails’ choice of Ruby was not due to popularity...

Friday, April 16, 2010

Friday, April 16, 2010

“If you don’t like it, !x it”

Friday, April 16, 2010

“For the past !ve days I have been struggling with a bug in the route code in rails 1.2.3. I

!nally monkey patched url_for to essentially force it to

do the obvious”

Friday, April 16, 2010

“Evil”?

One of the worst things you can do is ask your users to individually bear the cost of an optimization (modularity, perf)

Optimizing for these things at an early stage is essentially doing battle with your users (see: bundler)

Friday, April 16, 2010

Nothing Beats Adoption

Friday, April 16, 2010

Users stress-test your application in ways that you would not have thought of, making it more robust

Friday, April 16, 2010

Users help drive the needed feature-set... the faster you get real users, the sooner you’re basing your project on reality. It’s not easy to reverse course later.

Friday, April 16, 2010

Business Is Good for the

EcosystemFriday, April 16, 2010

Why there’s no Rails Inc.Friday, April 16, 2010

the growth of the Rails ecosystem has been staggering. There are so

many shops out there offering Rails consulting and training. I

believe part of that proliferation is due to the fact that there's no core-

group monopoly that can dominate the market

Friday, April 16, 2010

We have a tendency to underestimate the network effect.

Reducing the friction for users and businesses to interact results in a network effect.

Stifling it, therefore, stifles the network effect.

Friday, April 16, 2010

The company I work for, Engine Yard, exists because DHH encouraged businesses to help build the ecosystem.

Not everything we do is OSS, but our existence increases the amount of OSS in the world.

Friday, April 16, 2010

trademarks of DHHFriday, April 16, 2010

MIT License

Friday, April 16, 2010

Attribution and Credit Build

CommunitiesFriday, April 16, 2010

Nothing Beats Adoption

Friday, April 16, 2010

PDI

Friday, April 16, 2010

Please Do Investigate

Friday, April 16, 2010

Issue is that has_one associations don't cache nils, whereas

has_many do cache the empty array... This results in lots of

unnecessary and unexpected queries for all those

people that don't have thingsNote that this post is in 2006

Friday, April 16, 2010

Yes, please do investigate something better. I believe it was done

simply because it was easy at the time

Friday, April 16, 2010

@obie: Gawd, it's lame that unobtrusive javascript helpers

have dropped off the Rails 3.0 roadmap

Friday, April 16, 2010

@obie Re: Unobtrusive JS. We had someone

volunteering to do the work, but they dropped out. If you

have someone willing and able, PDI!

Friday, April 16, 2010

DHH != RailsFriday, April 16, 2010

These programmers share a similar weltanschauung, but they don't need to care only about the things that I care

about. In fact, the system works much better if they care about

different things than I do

Friday, April 16, 2010

My core philosophy about open source is that we should all be working

on the things that we personally use and care

about.

Sharing a worldview, and waiting a bit for something coherent before opening the doors wide, mitigates against scary shit

Friday, April 16, 2010

These programmers share a similar

weltanschauungFriday, April 16, 2010

Shared Goals

Friday, April 16, 2010

Convention Over

Con!gurationFriday, April 16, 2010

<abs>situps

</abs>Friday, April 16, 2010

Propaganda Works

Friday, April 16, 2010

Market First

Friday, April 16, 2010

Respond to Objections

LaterThe people with the objections aren’t your early adopters

Friday, April 16, 2010

Friday, April 16, 2010

Be High Impact

Friday, April 16, 2010

Don’t Cheat

Friday, April 16, 2010

(it will be obvious)

One of the wins of the 15 minute demo was that it got into quite a bit of nitty gritty. There’s some code generation, but you can easily see that the techniques scale

Friday, April 16, 2010

Cheating also results in

confused usersFriday, April 16, 2010

Assume Little

Friday, April 16, 2010

Don’t Try to Explain

Everything Up Front

Prospective users will give you 15 minutes; you’ll lose a ton of people if you ask them to spend days on it.

Show them the quick win.

Friday, April 16, 2010

Learn Symfony in 24 DaysFriday, April 16, 2010

Today, we have barely written PHP code but we

have a working web module for the job model, ready to

be tweaked and customized. Remember, no PHP code

also means no bugs!Day 3

Friday, April 16, 2010

Controversy is Good

Friday, April 16, 2010

Especially When it’s Not About

Your Core Functionality

Friday, April 16, 2010

FUD

Friday, April 16, 2010

You Can Fight it... to a Point

Friday, April 16, 2010

Pick Your Battles

Friday, April 16, 2010

And the Terms on Which They

Are FoughtFriday, April 16, 2010

“Ruby is Slow”We’ve gotten better at this... this section is more about what we’ve learned than us getting it right the first time.

Friday, April 16, 2010

OK: Productivity

is More Important

Because when it comes down to it, everything in business *is* a tradeoff... velocity always matters

Friday, April 16, 2010

Better: HTTP Overhead

Makes This Moot

Friday, April 16, 2010

Best: Actually Win Some

BenchmarksChallenge the FUD head-on... in this case, Rails has basically *never* been slower than PHP frameworks

Friday, April 16, 2010

Avoid Stockholm’s Syndrome

Friday, April 16, 2010

Rails Can’t Scale

Friday, April 16, 2010

Friday, April 16, 2010

Friday, April 16, 2010

1 in 200 Page Views on the Internet is to twitter.com

Friday, April 16, 2010

(not including API)

Friday, April 16, 2010

API Numbers are Higher than

90%Friday, April 16, 2010

Tout Your Successes and

Don’t be CowedFriday, April 16, 2010

Friday, April 16, 2010

Have a Safe Backup

Friday, April 16, 2010

Mobilize Around Weak

PointsFriday, April 16, 2010

Friday, April 16, 2010

Friday, April 16, 2010

“We started Engine Yard in early 2006 to meet a genuine need:

customers were developing business-critical Rails applications,

but they didn’t want to worry about application deployment,

management and scaling”

Friday, April 16, 2010

Businesses

Friday, April 16, 2010

Businesses+

CommunityFriday, April 16, 2010

Getting businesses invested means that the money is there without huge companies like Sun...

We can fund important projects, but financial interests keep us grounded

Friday, April 16, 2010

“Rails is Too Hard to Deploy”

Friday, April 16, 2010

Identify Your Competition

Friday, April 16, 2010

It’s useful to know exactly what the target is.

At some point, the Rails community ended up with stockholm syndrome about this and didn’t notice the problem was solved

Friday, April 16, 2010

The FTP strategy only takes you so far...

Friday, April 16, 2010

Friday, April 16, 2010

Friday, April 16, 2010

Friday, April 16, 2010

Friday, April 16, 2010

Friday, April 16, 2010

Friday, April 16, 2010

Friday, April 16, 2010

In short, technical

problems...Friday, April 16, 2010

...have technical solutions

Friday, April 16, 2010

Don’t be a slave to FUD

Friday, April 16, 2010

Know Your Competition

I’ve read, cover to cover, the books on virtually all major competing frameworks

Friday, April 16, 2010

There’s Plenty to Steal

Friday, April 16, 2010

Debate is OKThe OSS community alternates from ridiculous to “why are we arguing”

A good vigorous debate, even if it sometimes gets loud, is absolutely OK

But if you’re going to debate, you have to know what you’re talking about.

Friday, April 16, 2010

ActiveRecord comes from

PPoEAFriday, April 16, 2010

“Enterprise Architecture”Does that sound like Rails

to you?

The bottom line is that conflicting philosophies can have good ideas.

Friday, April 16, 2010

One Last Thing...

Friday, April 16, 2010

Convention over

Con!gurationFriday, April 16, 2010

Con!guration Options are a

Cop-OutFriday, April 16, 2010

Trade-Offs are Not Linear

Friday, April 16, 2010

Experiments?Given the “convention” philosophy, you might expect Rails to experiment very little

Friday, April 16, 2010

Dynlang + Vibrant Plugin

EcosystemBut actually, Rails people are some of the most bleeding-edge people around

Clojure? Erlang? Evented Programming? Node.JS?

Friday, April 16, 2010

Pull in Best Practices

But a good plugin ecosystem means you can be fairly conservative.

Friday, April 16, 2010

Make Sure Defaults Still Make Sense

There will always be people tugging on the defaults. The strength of conventions is in avoiding the tug.

Rails 3 solution (in general)

Friday, April 16, 2010

Thank you

Friday, April 16, 2010

Questions?

Friday, April 16, 2010

Recommended