One of the most common practices when writing controllers in Rails is using before_actions to keep them DRY. Sure, repeating code is a bad practice and leads to maintenance nightmare, but what happens when the readability drastically deteriorates after making the code DRY to the max? Is it still worth it? Let's see how it applies to controllers, what are the consequences and possible solutions
This is the second post of the series on our blog, in which I'll present to you the part of our infrastructure that is visible to the users. Here you can find links to past and, when we publish them, future posts:
Ruby 2.0 came with some pretty useful features like lazy enumerators, keyword arguments, convention for converting to hash. There is also Module#prepend, which is not that commonly used, but there are some cases where it really shines. Let's see what we can get from that feature then
Gems are a superb tool for every Rubyist. They can help you rapidly implement complex solutions in your applications without having to reinvent the wheel
The second edition of Rails Girls Łódź took place a few weeks ago and I cannot be more proud to have been a part of that – again. The recipe for a great workshop boils down to just a few good quality ingredients. Come along, I'll show you
One of the most important things for applications is stability. There are various hosting platforms that give you virtual servers, where you can run multiple services. There is no limit to the number of processes so it is up to you how much of their...
I have recently changed payment service provider to Braintree on Shelly Cloud and would love to share the experience with you. This post will show a fast and easy way of adding credit card payments to a Rails application.
I would like to share with you the details of how we built Shelly Cloud, our platform for hosting Ruby applications, and how it works.
This is the first post of the series on our blog, in which I'll present you with an introduction to the company and an overview of our stack.
Chef is a framework written in Ruby, and partially in Erlang (Chef Server). It provides an API for numerous system services. With Chef, your infrastructure can be expressed as object-oriented code that is versionable, testable, and repeatable. One of the main ideas of Chef developers was to bury the walls that exist between software development and system administration, allowing them to bring system configuration to a higher level.
Ever run into the situation where you had to perform some operation based on the value from select field? How did you handle it? Maybe multiple case / switch statements? Or if you are lucky enough and code in language with good support for metaprogramming like Ruby you can write some magic code like this one:
"#{params[:type].classify}Calculation".constantize.new.calculate(params)
which in fact can be treated as hidden case statement, but much easier to handle.
Are there any cleaner solutions to such problems which would be more readable? Fortunately, the answer is yes - some frameworks like Ember give possibility to use cool patterns that are not possible in other cases.