Making your oss project more like rails

{OSS Project

Friday, April 16, 2010

{ Rails


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.


Question


Why does Rails make devs

happy?Friday, April 16, 2010

“Optimized for Developer

Happiness”Friday, April 16, 2010

Optimizing Locks You In


Harder, but possible to

optimize laterFriday, April 16, 2010

Defer Optimizing Measurable

ThingsGathering data will make your measurable optimizations better


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


Dynamic


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


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


“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”


“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)


Nothing Beats Adoption


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


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.


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


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.


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.


trademarks of DHHFriday, April 16, 2010

MIT License


Attribution and Credit Build

CommunitiesFriday, April 16, 2010

Nothing Beats Adoption


PDI


Please Do Investigate


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


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

simply because it was easy at the time


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

have dropped off the Rails 3.0 roadmap


@obie Re: Unobtrusive JS. We had someone

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

have someone willing and able, PDI!


http://twitter.com/obie

http://twitter.com/obie

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


http://en.wikipedia.org/wiki/World_view


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


These programmers share a similar

weltanschauungFriday, April 16, 2010



Shared Goals


Convention Over

Con!gurationFriday, April 16, 2010

<abs>situps

</abs>Friday, April 16, 2010

Propaganda Works


Market First


Respond to Objections

LaterThe people with the objections aren’t your early adopters


Be High Impact


Don’t Cheat


(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


Cheating also results in

confused usersFriday, April 16, 2010

Assume Little


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.


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


Controversy is Good


Especially When it’s Not About

Your Core Functionality


FUD


You Can Fight it... to a Point


Pick Your Battles


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.


OK: Productivity

is More Important

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


Better: HTTP Overhead

Makes This Moot


Best: Actually Win Some

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


Avoid Stockholm’s Syndrome


Rails Can’t Scale


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


(not including API)


API Numbers are Higher than

90%Friday, April 16, 2010

Tout Your Successes and

Don’t be CowedFriday, April 16, 2010

Have a Safe Backup


Mobilize Around Weak

PointsFriday, 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”


Businesses


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


“Rails is Too Hard to Deploy”


Identify Your Competition


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


The FTP strategy only takes you so far...


In short, technical

problems...Friday, April 16, 2010

...have technical solutions


Don’t be a slave to FUD


Know Your Competition

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


There’s Plenty to Steal


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.


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.


One Last Thing...


Convention over

Con!gurationFriday, April 16, 2010

Con!guration Options are a

Cop-OutFriday, April 16, 2010

Trade-Offs are Not Linear


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


Dynlang + Vibrant Plugin

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

Clojure? Erlang? Evented Programming? Node.JS?


Pull in Best Practices

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


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)


Thank you


Questions?


Making your oss project more like rails

Technology

Transcript of Making your oss project more like rails