It's Business Time

Ruby

It's Business Time

Jim Gay

@saturnflyer

#business-logic

#user-interface-ui

#model-view-controller-mvc

#software-architecture

#ruby

#clean-code

It's Business Time

by Jim Gay

In the video titled "It's Business Time," speaker Jim Gay discusses the principles of application architecture and user interface design, focusing specifically on the Data, Context, Interaction (DCI) methodology. He emphasizes the importance of writing clear, maintainable code that aligns with business processes while keeping the user experience in mind. Gay relates the need for organized coding practices to the overall goal of developing software that efficiently supports business objectives.

Key points from the talk include:
- Focus on Business Processes: The ultimate goal of software should be to support business processes and deliver working software. Communication is vital, akin to how user interfaces facilitate interaction.
- User Interface in Code: Just as user interfaces in applications need to be clear and user-friendly, the same principles apply to writing code. Gay stresses the significance of well-defined names for methods and organized logic to facilitate understanding.
- Avoiding Obesity in Models: He highlights the trend of 'fat models and skinny controllers' and encourages developers to avoid bloated models that become hard to manage. Instead, the separation of responsibilities in software architecture is crucial.
- Introduction of DCI: Gay introduces DCI as a complementary approach to Model-View-Controller (MVC) that helps in determining how objects interact without overcomplicating the application architecture.
- Lean Software Development: With DCI, decisions regarding persistence can be postponed, allowing developers to focus on business logic first. This method enables the use of simple Ruby objects and better organization of code based on common use cases.
- Effective Documentation through Code: Instead of relying on extensive documentation, Gay advocates for using runnable code that reflects the interactions and business logic. This approach not only makes the code easier to understand but also aids in refactoring and experimentation.
- Conclusion and Key Takeaways: The core of Gay's argument is that writing code that is simple, readable, and reflective of business use cases allows for easier collaboration among developers and clarity for business stakeholders. He believes that following the DCI principles will enhance the maintainability and understanding of applications.

Overall, this talk encourages developers to adopt methodologies that align coding with business needs, improving both understanding and efficiency in the development process.

00:00:16.240 I wasn't sure what to title this talk, but I think it will fit in well with what we've seen so far. It's business time.

00:00:21.279 This isn't going to be as fun as that song by Flight of the Conchords; it's going to be a little more serious.

00:00:28.880 I'm Jim Gay, and I'm writing a book about DCI and, more generally, clean Ruby, which you can find at cleanruby.com. I'm also on Twitter at Saturn.

00:00:58.960 Funny thing about this picture, I was actually speaking French when it was taken, so I don't know how it came out like that.

00:01:04.159 I'm one of the organizers of Arlington Ruby, and I have some shirts to give away, the same one that I'm wearing. We ran a conference about a month and a half ago.

00:01:17.280 What's important to me when I write my Ruby code and when I work on my applications is building user interfaces. These are the principles of user interface design that I care about.

00:01:25.759 We also care about these principles when we are building our applications. When we are writing code, we need to focus on these same issues.

00:01:32.400 While I build user interfaces that are used in a browser, I do it in my code as well, and you do too. It's really important to look at what you write as a user interface.

00:02:03.759 So who can tell me what the primary goal for software is? Anyone?

00:02:12.720 No takers yet? The goal is to support a business process, which is pretty good.

00:02:31.760 So what's the goal? It should work. That's the end goal we talk about with agile approaches: we want working software.

00:02:38.319 A way to focus on getting there is through communication, which is exactly what a user interface is all about.

00:02:57.280 This is a fantastic book by Uncle Bob Martin. Has anyone here not read this book? I think it's great; it has lots of nuggets of information on how to write good code.

00:03:08.879 A lot of it, even though it doesn't explicitly say so, is about writing a good user interface in your code.

00:03:14.159 One of the things that stood out to me while studying DCI in my own applications is that you should take naming seriously.

00:03:26.640 I probably spend more time worrying about names in my projects than any other developer. I care about what the name of a method implies about its use and its result.

00:03:38.799 You should keep logic organized; keep things that are dissimilar apart from each other, while keeping similar things together. In the Rails community, we've adopted the notion of fat models and skinny controllers.

00:04:06.879 A lot of what people are doing today stems from the idea that we were building apps that became too big. Often, logic would be in our controllers, so we decided we needed to move it to the model.

00:04:12.000 As a result, the models grew larger and larger, and that's not desirable. We don't want fat models; we end up with obese models.

00:04:39.040 It's essential to realize that your data model is not the same as your domain model. Can anyone complete the thought for me? I think this comes from 'The Pragmatic Programmer.' I wrote down the quote but couldn't find the reference before the talk. It's an excellent book.

00:05:36.800 One key hallmark of good software and good programming is maintainability, which is the ability to withstand change over time.

00:06:01.199 We care about behavior. Our persistence layer should be separated, as has been discussed before. It's great to have a solid focus on that when it's business time.

00:06:09.120 While the persistence layer is important, we need to prioritize solving business logic problems and ensuring we deliver working software.

00:07:14.000 We have to separate responsibilities in our application. The persistence layer is important, but starting with SQLite or in-memory objects is acceptable.

00:07:32.000 The main goal remains to build working software.

00:08:01.840 The challenge is figuring out how to bring these responsibilities together in a meaningful way. We want to ensure our application is clear for new developers who may join the project.

00:08:28.400 That's where Data, Context, and Interaction (DCI) come in. DCI was created by Trigva Rinskog, who also developed MVC.

00:08:41.120 DCI complements MVC and allows you to control the procedures for how your objects interact.

00:08:52.240 When we think about object-oriented programming, we tend to imagine our running application as objects sending messages to one another.

00:09:05.760 However, when we focus on our coding, we tend to write classes and perceive our objects through the lens of these classes.

00:09:11.920 It's essential to recognize that your application architecture is not solely defined by your framework.

00:09:17.120 This book about DCI by Jim Copeland discusses a lean approach to software development that helps achieve this.

00:09:27.920 DCI assists you in understanding what different actors in your business use cases are doing and in what order.

00:09:34.560 One crucial takeaway is that you can postpone decisions with a lean approach. You don't need to worry about persistence right away; the focus should be on business logic.

00:09:50.640 Your data objects can be simple Ruby objects. Consider defining roles within your objects, as a user object or class might define different representations of a user depending on their role.

00:10:19.279 A user might be someone asking a question and, in another case, it could be an expert answering it.

00:10:25.600 What matters is the behavior when they are fulfilling that role.

00:10:31.200 Your code should be organized based on how you use it, rather than lumping all the logic into massive classes.

00:10:51.680 When building an expert social network with various functionalities—such as signing in, asking and answering questions, and registering—it becomes easy to make classes bloated with multiple methods.

00:11:04.160 But the key is to organize them sensibly, according to their use. These methods should live elsewhere—we don't need to worry about users when we care about the tasks they can perform.

00:11:09.040 With DCI, we see a full set of interacting objects. You design your code to reflect how these objects behave in real time, rather than just seeing classes as actions they can perform.

00:12:07.440 DCI is not merely about extending objects for specific behavior; it's about defining use cases in code. In DCI, we define our data context and interaction, which connects data objects to the behavior of their interactions.

00:12:16.160 In these classes, I choose to define the use case in comments, stating the primary actors and the scope of the process I am describing.

00:12:33.760 I take a business process description and delineate the prerequisites that we need to get specific tasks done.

00:12:39.120 This structure allows me to test as I go: once I initialize a question with given parameters, I can effectively use methods to act upon it.

00:12:50.320 In my enhancement, I find it useful to employ the 'call' method name since it is generic enough to accept various callable methods in Ruby.

00:12:58.239 When defining how we ask questions of experts, it makes more sense to use domain-specific language rather than generic terms.

00:13:14.880 So I might start defining the behavior of asking a question, and collaboratively with my fellow developers, we can shape the understanding of that behavior.

00:13:41.120 Because we are working within a web application, we have requests coming in.

00:13:46.640 If a question is asked but no expert is available, we can specify that the question will be answered at a later time.

00:14:01.840 We can define methods to create the question and notify the expert of it.

00:14:14.400 I’ll finish with how we define behavior for our expert. Regardless of whether this is the best implementation, it's one way to start breaking down the understanding of our application.

00:14:55.839 When I'm building applications, instead of writing extensive documentation, I begin by detailing the interactions of the objects involved.

00:15:20.320 It becomes easy for business owners to grasp the procedure and the overall system with this runnable code.

00:15:27.600 You don't have to write volumes of documentation or explanation; instead, you can use runnable code to demonstrate the process.

00:15:35.360 This allows for refactoring and experimentation without worrying about throwing away all the work.

00:17:18.559 Reading code takes time and can get complex. If it's a monolithic application with a lot of classes, piecing it together can be difficult.

00:18:10.880 Conducting business or operations efficiently saves both time and money.

00:19:41.360 This principle applies to how easily human beings can understand and manage their attention on various tasks.

00:20:33.440 The aim of DCI is to write code that makes it easy to reason about what is happening in the running application.

00:20:57.360 The essence lies in writing code that's easy to read, facilitating understanding how objects interact.

00:21:41.880 Considering how the user interface aligns with the system maintains clarity when adding methods or functionality.

00:22:07.500 I’m currently writing a book on this topic, not yet in beta, but being developed at fulloo.info, where you can find reference code for various programming languages.

00:22:30.000 That's it!

00:23:22.640 I have a question about performance. How does it compare when using this approach with existing tests?

00:23:41.600 Ruby has some issues with extending objects. It can lead to problems with method caching.

00:23:51.440 But in practice, I've run applications that use this technique without experiencing significant performance issues.

00:24:39.760 Using caching can yield better performance as a general strategy.

00:24:56.960 Delegating can also be a solution rather than relying solely on extending objects, which is a better approach.

00:25:05.720 You can also find alternatives to extending objects, depending on your application's requirements.

00:25:12.960 You might want to consider implementing behaviors within the context of the application rather than scattering them across different parts.

wroc_love.rb 2012