Talks
Speakers
Events
Topics
Sign in
Home
Talks
Speakers
Events
Topics
Leaderboard
Use
Analytics
Sign in
Suggest modification to this talk
Title
Description
The Ruby on Rails developer faces an interesting duality. Their inner Rubyist is driven by a sense of beauty and explores a wide range of ways to solve a problem. The inner Railser is driven by a strong set of conventions and is guided by the Rails Way™. The /lib directory is where these developers meet and end result is a junk drawer of awkward code. In this talk, I go over a few ways to keep this junk drawer problem from happening by adding some conventions I've created from building Rails in anger: * Treat /lib as a temple (keep /lib in a state to extract to a gem in minutes) * Avoid autoloading everything in /lib * Use configuration to hide credentials from your library code * Isolate your Domain Objects from library concerns through DCI Help us caption & translate this video! http://amara.org/v/FGaw/
Date
Summarized using AI?
If this talk's summary was generated by AI, please check this box. A "Summarized using AI" badge will be displayed in the summary tab to indicate that the summary was generated using AI.
Show "Summarized using AI" badge on summary page
Summary
Markdown supported
In the presentation titled "Building Extractable Libraries in Rails" at Rails Conf 2013, Patrick Robertson discusses the intersection of Ruby developers' creative instincts and the structured conventions of Rails. He emphasizes the importance of maintaining a well-organized `/lib` directory to prevent it from becoming a disorganized space filled with random code snippets. To achieve this, he introduces several conventions aimed at enhancing code quality and facilitating future gem extraction. ### Key Points Discussed: - **Philosophical Foundations:** - Rubyists often work under the influence of both creative freedom and strict conventions imposed by Rails. - The `/lib` directory represents this tension, encouraging both flexibility and structure in coding practices. - **Conventions for the `/lib` Directory:** - **Treat it as a Temple:** - Keep the directory organized so that components can be easily extracted to a gem when needed. - **Avoid Auto-loading Everything:** - Ensure every piece of code in the `/lib` has explicit entry points, facilitating better management and future extraction. - **Configuration Management:** - Separate sensitive credential information from library code to improve security and maintainability. - **Domain-Centric Architecture through DCI:** - Utilize the DCI (Data, Context, Interaction) pattern to keep business logic separated from external dependencies, ensuring that core application logic remains clean and focused. - **Examples and Case Studies:** - Robertson uses a hypothetical feature request involving patient data updates and Twitter integration to illustrate DCI. He demonstrates how to effectively separate the core logic (patient BMI updates) from concerns related to external service (Twitter API handling). - **Testing Methodology:** - Emphasizes the use of method roles in testing library code effectively without being dependent on the database, enhancing the testing process for business logic added to plain data objects. ### Conclusion and Takeaways: Robertson concludes by urging developers to respect the structure of their `/lib` directory, implement effective configuration practices, and protect domain interactions to maintain a clean and manageable Rails application as they scale. He highlights that treating `/lib` as an organized space will facilitate easier extraction of gems and ensure efficient coding practices in Ruby on Rails development. Overall, this talk provides practical insights for Ruby developers seeking to optimize their library management and maintain clean, efficient, and scalable codebases.
Suggest modifications
Cancel
