Dev Thoughts

To kick off Rails Conf, the founder of the Ruby on Rails framework (along with 37signals, Basecamp, etc), David Heinemeier Hansson, discussed a number of topics:

• Picking the right tool for the job from an application development perspective.
• Understanding that it's not possible to know everything in the development community (aka a new JS framework each week, every SQL command, etc.).
• Embracing the Rails community, where developers can work together to grow as developers.
• Web development is an ecosystem of choice. (PHP, Rails, etc.) This is different from the world of native mobile development, where you're required to utilize tools such as Swift or Java.
• Years ago Rails was the easiest choice, but that's not the case anymore due to the large number of frameworks.
• Discussed analogy of the 90's console gaming wars to modern web frameworks. Each console had vocal proponents and opponents. In the same way, developer argue for the benefits of using one framework over another.
• The missing part of the argument is that the technical rationale isn't the most important point of the discussion. The most important factor is deciding what framework is the best option for the set of application requirements.

Zen of Python in Comparison with Rails

He then discussed the Zen of Python:

1. Beautiful is better than ugly.
2. Explicit is better than implicit.
3. Simple is better than complex.
4. Complex is better than complicated.
5. Flat is better than nested.
6. Sparse is better than dense.
7. Readability counts.
8. Special cases aren't special enough to break the rules.
9. Although practicality beats purity.
10. Errors should never pass silently.
11. Unless explicitly silenced.
12. In the face of ambiguity, refuse the temptation to guess.
13. There should be one-- and preferably only one --obvious way to do it.
14. Although that way may not be obvious at first unless you're Dutch.
15. Now is better than never.
16. Although never is often better than right now.
17. If the implementation is hard to explain, it's a bad idea.
18. If the implementation is easy to explain, it may be a good idea.
19. Namespaces are one honking great idea -- let's do more of those!

Mainly focusing on the similarities, but then discussing one of the key differences, which is that Rails believes that there are multiple correct solutions instead of a single path.

Doctrine of Rails

He then walked through the doctrine of Rails:

1. Optimize for programmer happiness
2. Convention over Configuration
3. The menu is omakase
4. No one paradigm
5. Exalt beautiful code
6. Provide sharp knives
7. Value integrated systems
8. Progress over stability
9. Push up a big tent

Mastery is key when it comes to picking a programming language/framework. It's vital to have roots in a specific field and community.

He then discussed the quote from Émile Durkheim:

"For if society lacks the unity that derives from the fact that the relationships between its parts are exactly regulated, that unity resulting from the harmonious articulation of its various functions assured by effective discipline and if, in addition, society lacks the unity based upon the commitment of men's wills to a common objective, then it is no more than a pile of sand that the least jolt or the slightest puff will suffice to scatter."

And discussed the importance of having roots with a community, so that we don't oscillate from framework to framework based on what's hot at the moment.

Pick and Choose

There's flexibility when it comes to following the Rails doctrine. He gave the gives the analogy of a buffet and being able to pick and choose what components of the Rails doctrine are right to be used for your own purposes.

It's important to decide on what's important to you when it comes to development. DHH mentioned the importance of writing beautiful code, and for him Rails accomplishes that goal (along with having the ability to satisfy an application's requirements).

Struggling Through Features

Discussed how development can be challenging in a number of ways. And without solid roots in a single language/framework, it makes it hard to work through difficult circumstances. Roots in a framework can provide a foundation that you can always return to.