Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

What rails taught me – Eugene Pirogov

21 views

Published on

Ruby Meditation #7
March 19, 2016
Kyiv

Published in: Technology
  • Be the first to comment

  • Be the first to like this

What rails taught me – Eugene Pirogov

  1. 1. What Rails taught me To those who was born within Rails Kyiv, March 2016
  2. 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. 3. Agenda The Good What makes Rails so great? The Bad What parts of Rails hurt development?
 The Ugly How Rails hurt developers?
  4. 4. The Good
  5. 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. 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. 7. The Good Everything I know now I owe to Rails!
  8. 8. The Good Q. What is so nice about Rails from a technical standpoint?
  9. 9. The Good • routing, • rack middleware stack, • view helpers (like `link_to` etc.), • hot code reloading, • asset pipeline.
  10. 10. The Good Q. What is so nice about Rails from an learner standpoint? A. Ecosystem!
  11. 11. The Good Discourse Travis CI Diaspora Spree GitLab Hound Refinery CMS opensourcerails.com ManageIQ
  12. 12. The Good Q. What Rails is known for? A. Big names!
  13. 13. The Good
  14. 14. The Good Q. Does it matter? A. No! Success is very little about a technology.
  15. 15. The Good Facebook (PHP) VK (PHP) StackOverflow (C#) Reddit (PHP) A lot more…
  16. 16. The Bad
  17. 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. 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. 19. The Bad
  20. 20. The Bad ORM sucks
  21. 21. • Validation in models • Callbacks in models • Model objects are mutable • Nested attributes The Bad
  22. 22. The Bad Ruby gems are abused
  23. 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. 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. 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
  26. 26. The Bad Controller tests
  27. 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. 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. 29. The Ugly
  30. 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. 31. The Ugly We barely escape confort zones, unless forced by business requirements.
  32. 32. The Ugly We learn how to use the framework and become Rails experts at best, but do not advance as engeneers
  33. 33. The Ugly We forget about testing and debugging outside Rails
  34. 34. The Ugly Writing code & learning is replaced by searching for new gems.
  35. 35. The Ugly
  36. 36. 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.
  37. 37. The Ugly Rails is telling how to do things. And often does things himself, without asking.
  38. 38. The First Principles
  39. 39. The First Principles Frameworks should help you do the things. Not do the things for you.
  40. 40. Frameworks come and go. What will remain the same in 10 years? The First Principles
  41. 41. Don’t eat too much framework’s sugar. It will cause you amnesia. The First Principles
  42. 42. Alway be stepping out of your comfort zone. The First Principles
  43. 43. Stop abusing the gems. Write the fucking code! The First Principles
  44. 44. Want to be a better Rails developer? Try programming using different frameworks & languages. The First Principles
  45. 45. 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”)
  46. 46. The First Principles Forget your framework and learn to stand on the shoulders of giants.
  47. 47. The First Principles http://antiflasher.livejournal.com/4230.html
  48. 48. If you want anything to be familiar, you’ll never learn anything new. The First Principles h"ps://youtu.be/rI8tNMsozo0
  49. 49. Thanks! Questions?

×