Ruby Meditation #7 March 19, 2016 Kyiv

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

20. The Bad
ORM sucks

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

26. The Bad
Controller tests

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.

40. The First Principles

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.

49. The First Principles
http://antiflasher.livejournal.com/4230.html

50. If you want anything to be familiar, you’ll never learn
anything new.
The First Principles
h"ps://youtu.be/rI8tNMsozo0

51. Thanks! Questions?