Making your oss project more like rails

{ OSS Project

Friday, April 16, 2010

{ Rails


We were trying to do:

* more choice
* more modularity
* more performance
* toolkit for building other

Merb
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?

“Optimized for
Developer
Happiness”

Optimizing
Locks You In


Harder, but
possible to
optimize later

Defer
Optimizing
Measurable
Things
Gathering 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”


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

“Evil”?
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
Ecosystem

Why there’s no Rails Inc.

the growth of the Rails ecosystem
has been staggering. There are so
many shops out there oﬀering
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
net work effect.

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

Stifling it, therefore,
stifles the net work
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 DHH

MIT License


Attribution and
Credit Build
Communities

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 things
Note 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 oﬀ 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!

DHH != Rails

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
diﬀerent things than I do

My core philosophy
about open source is that
we should all be working
on the things that we
Sharing a worldview,
personally use and care
and waiting a bit for
something coherent
before opening the
about. doors wide, mitigates
against scary shit


These
programmers
share a similar
weltanschauung

Shared Goals


Convention
Over
Con guration

<abs>
situps
</abs>

Propaganda
Works


Market First


Respond to
Objections
Later
The people with the
objections aren’t your
early adopters


Be High Impact


Don’t Cheat


(it will be
One of the wins of the

obvious)
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 users

Assume Little


Don’t Try to
Explain
Prospective users will

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

Up Front
Show them the quick
win.


Learn Symfony in 24 Days

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

You Can Fight
it... to a Point


Pick Your
Battles


And the Terms
on Which They
Are Fought

“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
Because when it
comes down to it,

Important
everything in
business *is* a
tradeoff... velocity
always matters

Better: HTTP
Overhead
Makes This
Moot

Best: Actually
Win Some
Benchmarks
Challenge 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%

Tout Your
Successes and
Don’t be Cowed

Have a Safe
Backup


Mobilize
Around Weak
Points

“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
+
Community

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...

...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 OK
The OSS community But if you’re going to
alternates from ridiculous debate, you have to know
to “why are we arguing” what you’re talking about.

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

ActiveRecord
comes from
PPoEA

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

Con guration
Options are a
Cop-Out

Trade-Oﬀs are
Not Linear


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


Dynlang +
Vibrant Plugin
Ecosystem
But actually, Rails people
are some of the most
Clojure? Erlang? Evented
Programming? Node.JS?
bleeding-edge people
around


Pull in Best
Practices
But a good plugin
ecosystem means you
can be fairly
conser vative.


Make Sure
Defaults Still
Make Sense
There will always be people tugging Rails 3 solution (in
on the defaults. The strength of general)
conventions is in avoiding the tug.

Thank you


Questions?


Making your oss project more like rails

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (9)

Ähnlich wie Making your oss project more like rails

Ähnlich wie Making your oss project more like rails (20)

Mehr von Yehuda Katz

Mehr von Yehuda Katz (12)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Making your oss project more like rails