Making your oss project more like rails

2,263 views
2,161 views

Published on

Published in: Technology
0 Comments
15 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,263
On SlideShare
0
From Embeds
0
Number of Embeds
34
Actions
Shares
0
Downloads
53
Comments
0
Likes
15
Embeds 0
No embeds

No notes for slide

Making your oss project more like rails

  1. 1. { OSS Project Friday, April 16, 2010
  2. 2. { Rails Friday, April 16, 2010
  3. 3. 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. Friday, April 16, 2010
  4. 4. Question Friday, April 16, 2010
  5. 5. Why does Rails make devs happy? Friday, April 16, 2010
  6. 6. “Optimized for Developer Happiness” Friday, April 16, 2010
  7. 7. Friday, April 16, 2010
  8. 8. Optimizing Locks You In Friday, April 16, 2010
  9. 9. Harder, but possible to optimize later Friday, April 16, 2010
  10. 10. Defer Optimizing Measurable Things Gathering data will make your measurable optimizations better Friday, April 16, 2010
  11. 11. 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
  12. 12. Dynamic Friday, April 16, 2010
  13. 13. Rails’ choice of Ruby was not due to popularity... Friday, April 16, 2010
  14. 14. Friday, April 16, 2010
  15. 15. “If you don’t like it, x it” Friday, April 16, 2010
  16. 16. “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
  17. 17. 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) Friday, April 16, 2010
  18. 18. Nothing Beats Adoption Friday, April 16, 2010
  19. 19. Users stress-test your application in ways that you would not have thought of, making it more robust Friday, April 16, 2010
  20. 20. 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
  21. 21. Business Is Good for the Ecosystem Friday, April 16, 2010
  22. 22. Why there’s no Rails Inc. Friday, April 16, 2010
  23. 23. 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
  24. 24. 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. Friday, April 16, 2010
  25. 25. 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
  26. 26. trademarks of DHH Friday, April 16, 2010
  27. 27. MIT License Friday, April 16, 2010
  28. 28. Attribution and Credit Build Communities Friday, April 16, 2010
  29. 29. Nothing Beats Adoption Friday, April 16, 2010
  30. 30. PDI Friday, April 16, 2010
  31. 31. Please Do Investigate Friday, April 16, 2010
  32. 32. 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 Friday, April 16, 2010
  33. 33. Yes, please do investigate something better. I believe it was done simply because it was easy at the time Friday, April 16, 2010
  34. 34. @obie: Gawd, it's lame that unobtrusive javascript helpers have dropped off the Rails 3.0 roadmap Friday, April 16, 2010
  35. 35. @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
  36. 36. DHH != Rails Friday, April 16, 2010
  37. 37. 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
  38. 38. 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 Friday, April 16, 2010
  39. 39. These programmers share a similar weltanschauung Friday, April 16, 2010
  40. 40. Shared Goals Friday, April 16, 2010
  41. 41. Convention Over Con guration Friday, April 16, 2010
  42. 42. <abs> situps </abs> Friday, April 16, 2010
  43. 43. Propaganda Works Friday, April 16, 2010
  44. 44. Market First Friday, April 16, 2010
  45. 45. Respond to Objections Later The people with the objections aren’t your early adopters Friday, April 16, 2010
  46. 46. Friday, April 16, 2010
  47. 47. Be High Impact Friday, April 16, 2010
  48. 48. Don’t Cheat Friday, April 16, 2010
  49. 49. (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 Friday, April 16, 2010
  50. 50. Cheating also results in confused users Friday, April 16, 2010
  51. 51. Assume Little Friday, April 16, 2010
  52. 52. 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. Friday, April 16, 2010
  53. 53. Learn Symfony in 24 Days Friday, April 16, 2010
  54. 54. 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
  55. 55. Controversy is Good Friday, April 16, 2010
  56. 56. Especially When it’s Not About Your Core Functionality Friday, April 16, 2010
  57. 57. FUD Friday, April 16, 2010
  58. 58. You Can Fight it... to a Point Friday, April 16, 2010
  59. 59. Pick Your Battles Friday, April 16, 2010
  60. 60. And the Terms on Which They Are Fought Friday, April 16, 2010
  61. 61. “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
  62. 62. OK: Productivity is More Because when it comes down to it, Important everything in business *is* a tradeoff... velocity always matters Friday, April 16, 2010
  63. 63. Better: HTTP Overhead Makes This Moot Friday, April 16, 2010
  64. 64. Best: Actually Win Some Benchmarks Challenge the FUD head-on... in this case, Rails has basically *never* been slower than PHP frameworks Friday, April 16, 2010
  65. 65. Avoid Stockholm’s Syndrome Friday, April 16, 2010
  66. 66. Rails Can’t Scale Friday, April 16, 2010
  67. 67. Friday, April 16, 2010
  68. 68. Friday, April 16, 2010
  69. 69. 1 in 200 Page Views on the Internet is to twitter.com Friday, April 16, 2010
  70. 70. (not including API) Friday, April 16, 2010
  71. 71. API Numbers are Higher than 90% Friday, April 16, 2010
  72. 72. Tout Your Successes and Don’t be Cowed Friday, April 16, 2010
  73. 73. Friday, April 16, 2010
  74. 74. Have a Safe Backup Friday, April 16, 2010
  75. 75. Mobilize Around Weak Points Friday, April 16, 2010
  76. 76. Friday, April 16, 2010
  77. 77. Friday, April 16, 2010
  78. 78. “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
  79. 79. Businesses Friday, April 16, 2010
  80. 80. Businesses + Community Friday, April 16, 2010
  81. 81. 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
  82. 82. “Rails is Too Hard to Deploy” Friday, April 16, 2010
  83. 83. Identify Your Competition Friday, April 16, 2010
  84. 84. 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
  85. 85. The FTP strategy only takes you so far... Friday, April 16, 2010
  86. 86. Friday, April 16, 2010
  87. 87. Friday, April 16, 2010
  88. 88. Friday, April 16, 2010
  89. 89. Friday, April 16, 2010
  90. 90. Friday, April 16, 2010
  91. 91. Friday, April 16, 2010
  92. 92. Friday, April 16, 2010
  93. 93. In short, technical problems... Friday, April 16, 2010
  94. 94. ...have technical solutions Friday, April 16, 2010
  95. 95. Don’t be a slave to FUD Friday, April 16, 2010
  96. 96. Know Your Competition I’ve read, cover to cover, the books on virtually all major competing frameworks Friday, April 16, 2010
  97. 97. There’s Plenty to Steal Friday, April 16, 2010
  98. 98. 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 Friday, April 16, 2010
  99. 99. ActiveRecord comes from PPoEA Friday, April 16, 2010
  100. 100. “Enterprise Architecture” Does that sound like Rails to you? The bottom line is that conflicting philosophies can have good ideas. Friday, April 16, 2010
  101. 101. One Last Thing... Friday, April 16, 2010
  102. 102. Convention over Con guration Friday, April 16, 2010
  103. 103. Con guration Options are a Cop-Out Friday, April 16, 2010
  104. 104. Trade-Offs are Not Linear Friday, April 16, 2010
  105. 105. Experiments? Given the “convention” philosophy, you might expect Rails to experiment very little Friday, April 16, 2010
  106. 106. Dynlang + Vibrant Plugin Ecosystem But actually, Rails people are some of the most Clojure? Erlang? Evented Programming? Node.JS? bleeding-edge people around Friday, April 16, 2010
  107. 107. Pull in Best Practices But a good plugin ecosystem means you can be fairly conser vative. Friday, April 16, 2010
  108. 108. 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. Friday, April 16, 2010
  109. 109. Thank you Friday, April 16, 2010
  110. 110. Questions? Friday, April 16, 2010

×