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 great...
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:
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.
Have you recently got an exception saying
NoMethodError: undefined method `name' for nil:NilClass? Most likely more than once. And how did you solve it? Maybe you used
try and thought the problem is solved... until the same exception happened in a different place! Using methods like
try is just treating symptoms, it doesn't even touch the real problem. Maybe the right question would be: why was it nil in the first place? Could it be avoided? Was the possibility of nil a desired behavior? And why at all is
nil even a problem? Let's find out and investigate some usecases