- 23 October 2016
- Patterns Ruby Design
- Ruby - Dependency Injection
Hi there. Today we will discover Dependency Injection (DI). To understand all benefits of dependency injection we should understand why dependencies are bad.
Hi there. Today we will discover Dependency Injection (DI). To understand all benefits of dependency injection we should understand why dependencies are bad.
Today's post will be more theoretical rather than practical. But it's worth reading because Command-Query Separation allows you to improve design of methods. So today we will discuss CQS.
Hi there. When you work on a greenfield project everything goes well. But at some point each big project has this issue with DataBase performance. It get's not easy to make changes to DB structure, insert data. Queries are getting slower and slower. It's time to do something with it.
Recently I wrote about template pattern. Today I would like to talk about another useful pattern - decorator.
Today I would like to show you how easily spot a problem and improve performance of your app.
If you didn't hear about N+1 query problem you can read about it even on official Rails guides website.
We're so get used to nice features of ActiveRecord
that we don't care about resulting SQL that being generated by ORM. We don't count how many queries we do and how complex they are.
Today I would like to show by simple example how to use template pattern in Ruby.
I'm sure you will find many ways of using that pattern in your application.
Hi. Today I would like to talk about memoization in Ruby.
But to begin, let's consider some abilities of Ruby. Often, we want to assign result of execution of function to some variable. If result of execution is false
or nil
we would like to assign some default value.
After couple of theoretical posts (Tell, Don't Ask and Law of Demeter) I want to write about more practical things.
About something that we use on everyday's job dealing with arrays and hashes.
There is a great principle in object-oriented programming which says: "Tell, Don't Ask".
This principle tells that we should not ask object about their state, make decision and only then tell them what to do. Rather we should send commands.
There is a good quote about that: