Download to read offline
Uploaded byRuby Meditation
What rails taught me – Eugene Pirogov
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.
More Related Content
Similar to What rails taught me – Eugene Pirogov
What rails taught me – Eugene Pirogov
- 1. What Rails taughtme To those who was born within Rails Kyiv, March 2016
- 2. About me 10 yearsprogramming 9 Rails projects of various sizes 6 years of using Ruby on Rails 8 years of web development
- 3. Agenda The Good What makesRails so great? The Bad What parts of Rails hurt development? The Ugly How Rails hurt developers?
- 4.
- 5. • it’s cheapto 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 • builda 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 Iknow now I owe to Rails!
- 8. The Good Q. Whatis 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. Whatis so nice about Rails from an learner standpoint? A. Ecosystem!
- 11. The Good Discourse Travis CI Diaspora Spree GitLab Hound RefineryCMS opensourcerails.com ManageIQ
- 12. The Good Q. WhatRails is known for? A. Big names!
- 13.
- 14. The Good Q. Doesit 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.
- 17. • let’s notjudge Rails in it’s entirety, • it has lots of subsystems, • let’s examine Rails’s worst parts, The Bad
- 18. • Rails istoo 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.
- 20.
- 21. • Validation inmodels • Callbacks in models • Model objects are mutable • Nested attributes The Bad
- 22. The Bad Ruby gemsare abused
- 23. The Bad Bad gemusage 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’veseen 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_ferretacts_as_indexed acts_as_tree acts_as_list acts_as
- 26.
- 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 • Railsis 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.
- 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 barelyescape confort zones, unless forced by business requirements.
- 32. The Ugly We learnhow to use the framework and become Rails experts at best, but do not advance as engeneers
- 33. The Ugly We forgetabout testing and debugging outside Rails
- 36. The Ugly Writing code& learning is replaced by searching for new gems.
- 37.
- 38. The Ugly Once youget 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 istelling how to do things. And often does things himself, without asking.
- 40.
- 41. The First Principles Frameworksshould help you do the things. Not do the things for you.
- 42. Frameworks come andgo. What will remain the same in 10 years? The First Principles
- 43. Don’t eat toomuch framework’s sugar. It will cause you amnesia. The First Principles
- 44. Alway be steppingout of your comfort zone. The First Principles
- 45. Stop abusing thegems. Write the fucking code! The First Principles
- 46. Want to bea better Rails developer? Try programming using different frameworks & languages. The First Principles
- 47. The First Principles Whenshit 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 Forgetyour framework and learn to stand on the shoulders of giants.
- 49.
- 50. If you wantanything to be familiar, you’ll never learn anything new. The First Principles h"ps://youtu.be/rI8tNMsozo0
- 51.