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.
