A la carte for me, please

Is Omakase really what you want?

Transcript

2. Cool Framework for literate, tested documentation: http://github.com/rubyworks/qed
3. $ cat .profile | grep export export GIT_AUTHOR="Florian Gilcher" export GIT_AUTHOR_EMAIL="florian.gilcher@asquera.de" export GITHUB_NICK="skade" export APP_NET_NICK="skade" export GITHUB_ORGANIZATIONS="asquera,padrino" export TWITTER_NICK="@argorak" export TM_COMPANY="Asquera GmbH"
4. http://asquera.de
5. Berlin | 16 - 18 sierpień eurucamp.org @eurucamp CFP opens in March
6. I work on a not-so-big framework.
7. http://padrinorb.com
8. Padrino emphasizes building projects in small, cosy components without high ceilings.
9. This is not “my framework is better” - talk.
10. Rails is Omakase http://david.heinemeierhansson.com/2012/rails-is-omakase.html
11. What is Omakase?
12. That doesn’t mean patrons can’t express exceptions. Substitutions are allowed, within reason. So you don’t like test/unit? No problem, bring your own rspec. Don’t care for CoffeeScript as a dessert? Delete a single line from your Gemfile.
13. Order a meal
14. Order a meal, throw half of it away
15. Order a meal, throw half of it away, add your own lunchbox.
16. Is that really what you ordered?
17. . .
18. Rails from my point of view
19. Opinionates on everything
20. Tries to hide the efforts of composition
21. Is hard to argue against by people that already picked the meal.
22. A number of serious problems arise from that:
23. Generators have weak support for non-standard templates
24. Weak framework support for setting up non-standard projects of any kind (e.g. with rspec)
25. Rails has no RSpec-Support, RSpec has Rails-Support
26. An interesting absence of any higher-level abstraction components, e.g. Adapters, View Models, etc.
27. Sometimes, the cook tries to hide something
28. . .
29. module MyEngine class Engine < ::Rails::Engine end end
30. Would you expect this to run a non-trivial amount of code?
31. This is “light in the editor” gone wrong.
32. “The user should not need to know.”
33. “The user should not know.”
34. module MyApp extend Padrino::Module gem! "my_app" end
35. The Guidance Problem
36. Rails optimizes for getting a full stack running as quick as possible.
37. Sadly, this makes guidance through the framework harder.
38. Documentation does not always help.
39. Fostering discovery does.
40. Impliciteness and hiding steps is the enemy of discoverability.
41. The two-stack problem. http://words.steveklabnik.com/rails-has-two-default-stacks
42. Omakase Stack
43. ERB for view templates
44. ERB for view templates MySQL for databases
45. ERB for view templates MySQL for databases MiniTest for testing
46. ERB for view templates MySQL for databases MiniTest for testing Fat Models, Skinny Controllers
47. Prime Stack
48. Haml for view templates
49. Haml for view templates PostgreSQL for databases
50. Haml for view templates PostgreSQL for databases Rspec/Cucumber for testing
51. Haml for view templates PostgreSQL for databases Rspec/Cucumber for testing Skinny models, controllers, and a service layer
52. The “prime” stack is basically just a modification of the “omakase” stack.
53. All we do is iterate away from a pretty big core without support by the framework.
54. Takeaway: Component Flexibility is not a strong point of Rails.
55. Beginners lose out.
56. . .
57. CVE-2013-0156
58. Accepting XML in Rails led to an object instantiation attack.
59. Did your application accept XML?
60. YES.
61. Rails activates an unnessecary external interface...
62. ...without your active involvement...
63. ...that has severe bugs...
64. ...that are exploitable for years.
65. Who owns your security?
66. You do!
67. Why is Rails like that?
68. Rails started out in the void.
69. Opinionating, defaults and a clear preferred stack ensured quality and ease of use.
70. Nowadays, the software is not the problem.
71. But I think the philosophy has become one.
72. $ padrino gen project --help Usage: padrino-gen project [name] [options] Options: -n, [--app=APP] # The application name -b, [--bundle] # Run bundle install -r, [--root=ROOT] # The root destination # Default: . [--dev] # Use padrino from a git checkout -i, [--tiny] # Generate tiny app skeleton -a, [--adapter=ADAPTER] # SQL adapter for ORM (sqlite, mysql, mysql2, postgres) # Default: sqlite -p, [--template=TEMPLATE] # Generate project from template -d, [--orm=ORM] # The database engine component (activerecord, mini_record, datamapper, mongomapper, mo # Default: none -t, [--test=TEST] # The testing framework component (rspec, shoulda, cucumber, bacon, testspec, riot, min # Default: none -m, [--mock=MOCK] # The mocking library component (mocha, rr, none) # Default: none -s, [--script=SCRIPT] # The javascript library component (jquery, prototype, rightjs, mootools, extcore, do # Default: none -e, [--renderer=RENDERER] # The template engine component (haml, erb, liquid, slim, none) # Default: haml -c, [--stylesheet=STYLESHEET] # The stylesheet engine component (less, sass, compass, scss, none) # Default: none Description: padrino-gen project generates a new Padrino project
73. Final words
74. We should rethink “ease of use” and “support”.
75. “Framework support” is less about APIs then about a mindset.
76. “Ease of use” is less about speed of setup than it is about explanation of possibilities.
77. . .
78. Image Credit: http://www.flickr.com/photos/40804746@N02/4314681726/ http://www.flickr.com/photos/jubilo/384339562/ http://www.flickr.com/photos/danielygo/5216691068/