RubyFlow : The Ruby Community Blog

Home   Submit   Sign Up   Log In   leaders   Twitter   RSS Feed  

vsavkin — 17 posts

Adding new functionality to a large legacy Rails application is often expensive, if possible. But what if instead of adding new behaviour to the Rails application we implemented it as a single-page application in JavaScript? In this article I will show a few useful techniques for doing that. Read more...
I Wish Ruby Had Interfaces
Types have a bad reputation in the Ruby community for making code harder to read, and adding unnecessary ceremony. In this article I’d like to show that a type system done right can help make code more readable and toolable without constraining the expressiveness of the language. Or in other words, I will show how a type system can allow the flexibility of Ruby and the toolability of Java to coexist in one language. Read more.
Recently, the topic of building loosely coupled systems with Rails has gotten a lot of attention. More and more people are experimenting with different approaches trying to make their Rails applications more maintainable. The hexagonal architecture is one such approach. And in this article I am going to show how it can be used with Rails. Read more...
Building rich domain models in Rails is hard. Primarily, because of Active Record, which doesn’t play well with the domain model approach. This article shows how to use Active Record as just a persistence mechanism and build a rich domain model on top of it. Read more...
How many times have you tried to refactor out a responsibility from a god class? How many times have you succeeded? It’s hard. Primarily, because of the limitations of the brain. We cannot keep more than 3-4 things in our working memory. This means that understanding the ways in which 30 methods interact with each other is extremely difficult. And that’s when feature sketches can come in handy. Read more...
Programmers tend to use software to solve absolutely all problems. Need to take notes? Here is an application for taking notes. Brainstorming? All sorts of mind mappers are available for you. Even though in most cases it makes perfect sense, sometimes I find that a piece of paper and a pen are better tools for the job. I’d like to talk about one of the most interesting and, unfortunately, underused tools for brainstorming: CRC cards. Read more...
This article is a practical introduction to DCI (Data Context Interaction). I’m not going to explain all theory behind it. Instead, I’m going to show you what kind of problems DCI is trying to solve and how it can be implemented in Ruby. Read the article
Enterprise software has been being bashed for years. I believe it's time to change this attitude. Let’s think a little about what enterprise software is and if Ruby can be a good platform for building it. Read more...
DCI (Data Context Interaction) is a new way to look at object-oriented programming. Instead of focusing on individual objects, the DCI paradigm focuses on communication between object. It improves the readability of the code, separates system behavior from static domain concepts, and most importantly tries to represent people's mental models in the code. DCI-IN-RUBY.INFO is a project aiming to help all Rubyists become familiar with DCI.
Want to run your apps on the JVM, but not a fan of the Java language? If you prefer dynamic languages, there are lots of available options. The most mature ones are JRuby and Groovy. If you are asking yourself, "Should I pick Groovy or JRuby", read this post and, hopefully, you will be able to make the decision. Read more...
You start with nicely designed groups of objects. All the objects have clear responsibilities, and all interactions among them are explicit. Then, you have to consider additional requirements, such as transactions, integration with external systems, event generation. Soon you end up with a bunch of interconnected objects without clear boundaries. Maintaining this mess becomes harder and harder. Thankfully, Domain Driven Design provides a good remedy for this situation: Aggregates. Read more
I’ve started writing a series of blog posts about using the building blocks Domain Driven Design in Rails applications. In this post I’m talking about Entities and Values, about their characteristics, and how they can be implemented. Read more.
Working on large rails applications I’ve noticed that in many ways Domain Driven Design and Rails contradict each other. Therefore, I’ve decided to write a short series of articles, which will be my attempt to reconcile both paradigms and to find a way to use DDD while not fighting Rails. Read more.
A short introduction to messaging and how it can help us to manage complexity and tackle performance related problems. I use RabbitMQ to show a few basic messaging patterns that can be used in a lot of Rails applications.
No matter what kind of programming you are doing these days you probably heard a lot about Smalltalk. And there is a reason for that. Its influence on what we are doing and using right now is hard to overestimate. Refactoring, XP, TDD, many VM technologies came from the Smalltalk community. more
Typed Fields in Ruby
One of a few things I missed when I switched from ActiveRecord to ActiveModel is all type conversions AR takes care of. You just pass a bunch of strings and it knows what to do with them. TypedFields gem does similar kind if stuff but without tying it to ActiveRecord.
How to implement DCI in Ruby
In this post I show different ways of implementing DCI (Domain, Context, Interaction) in Ruby.