View
1.938
Download
0
Category
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