What rails taught me – Eugene Pirogov
0 likes174 views
This document discusses the author's experience with Ruby on Rails over 10 years. It outlines both the benefits and drawbacks of Rails. The good parts include how easy it is to build prototypes, get help online, and find jobs. However, Rails can also make developers overly reliant on its frameworks, opinions, and gems. This dependence limits learning and flexibility. The author advocates learning first principles, stepping outside comfort zones, and understanding underlying technologies like SQL instead of just using Rails as a black box.
![[.Net开发交流会][2010.06.19]better framework better life(吕国宁)](https://cdn.slidesharecdn.com/ss_thumbnails/net2010-06-19betterframeworkbetterlife-101007223326-phpapp01-thumbnail.jpg?width=560&fit=bounds)
Ad
More Related Content
What's hot (9)
Similar to What rails taught me – Eugene Pirogov (20)
Ad
More from Ruby Meditation (20)
Ad
Recently uploaded (20)
What rails taught me – Eugene Pirogov
- 1. What Rails taught me To those who was born within Rails Kyiv, March 2016
- 2. About me 10 years programming 9 Rails projects of various sizes 6 years of using Ruby on Rails 8 years of web development
- 3. Agenda The Good What makes Rails so great? The Bad What parts of Rails hurt development? The Ugly How Rails hurt developers?
- 4. The Good
- 5. • it’s cheap to try new ideas, • it’s cheap to write CRUD apps, • it’s easy to get help on the internet (talk to people on blogs, forums, look at OSS Rails apps), • it’s easy to find a Rails job! The Good
- 6. The Good • build a prototype (until comfortable with something else), • work on a project based on a very promising idea (enter Rails dev, butmove on to more interesting things eventually), • to quickly improve one’s finance situation.
- 7. The Good Everything I know now I owe to Rails!
- 8. The Good Q. What is so nice about Rails from a technical standpoint?
- 9. The Good • routing, • rack middleware stack, • view helpers (like `link_to` etc.), • hot code reloading, • asset pipeline.
- 10. The Good Q. What is so nice about Rails from an learner standpoint? A. Ecosystem!
- 11. The Good Discourse Travis CI Diaspora Spree GitLab Hound Refinery CMS opensourcerails.com ManageIQ
- 12. The Good Q. What Rails is known for? A. Big names!
- 13. The Good
- 14. The Good Q. Does it matter? A. No! Success is very little about a technology.
- 15. The Good Facebook (PHP) VK (PHP) StackOverflow (C#) Reddit (PHP) A lot more…
- 16. The Bad
- 17. • let’s not judge Rails in it’s entirety, • it has lots of subsystems, • let’s examine Rails’s worst parts, The Bad
- 18. • Rails is too much of a framework. • Rails is way too opinionated. • Rails is coupling itself to the app logic way too much. One can barely notice this, let alone stop it. The Bad
- 19. The Bad
- 21. • Validation in models • Callbacks in models • Model objects are mutable • Nested attributes The Bad
- 22. The Bad Ruby gems are abused
- 23. The Bad Bad gem usage mindset: there’s a gem for that™ Betteer gem usage mindset: use low-level gems only: start with redis, memcached drivers, maybe devise, etc.
- 24. The Bad > I’ve seen former colleagues to just install a gem … for just a couple, literally a couple of lines of code that you needed from the gem. Luca Guidi, https://devchat.tv/ruby-rogues/228-the-lotus-framework-with-luca-guidi
- 25. The Bad acts_as_api acts_as_audited acts_as_commentable acts_as_ferret acts_as_indexed acts_as_tree acts_as_list acts_as
- 27. • “write code, then entangle it with tests” philosophy, • TDD is not appreciated, • controller tests as hard to understand, • abuse of factories, • a lot of magic with setting up testing env. The Bad
- 28. The Bad • Rails is extracted from Basecamp, • Rails's advancement defined & bound by Basecamp’s internal philosophy and needs, • …see introduction of Turbolinks, • …see ActionCable, • …see most of stuff introduced by DHH. Also…
- 29. The Ugly
- 30. The Ugly • Rails + gems + community… • …can be very helpful, • …can generate a lot of value, • …can be a HUGE comfort zone, • …can be a mindset’s trap.
- 31. The Ugly We barely escape confort zones, unless forced by business requirements.
- 32. The Ugly We learn how to use the framework and become Rails experts at best, but do not advance as engeneers
- 33. The Ugly We forget about testing and debugging outside Rails
- 36. The Ugly Writing code & learning is replaced by searching for new gems.
- 37. The Ugly
- 38. The Ugly Once you get used to quick pace, Rails doesn’t embrace patience or discipline. When your boss gets used to your quick pace, – this is turning point in app development. You no longer have time to proper think about solution, and things start to go really bad.
- 39. The Ugly Rails is telling how to do things. And often does things himself, without asking.
- 41. The First Principles Frameworks should help you do the things. Not do the things for you.
- 42. Frameworks come and go. What will remain the same in 10 years? The First Principles
- 43. Don’t eat too much framework’s sugar. It will cause you amnesia. The First Principles
- 44. Alway be stepping out of your comfort zone. The First Principles
- 45. Stop abusing the gems. Write the fucking code! The First Principles
- 46. Want to be a better Rails developer? Try programming using different frameworks & languages. The First Principles
- 47. The First Principles When shit breaks, the only thing you can rely on is what’s behind it. Learn Unix/Linux and SQL. (“Ruby is unlike a Banana”)
- 48. The First Principles Forget your framework and learn to stand on the shoulders of giants.
- 50. If you want anything to be familiar, you’ll never learn anything new. The First Principles h"ps://youtu.be/rI8tNMsozo0