Recently, I’ve been playing around with a search in Elasticsearch and got stuck with development when attempting to work with an array of objects. Indexing went fine, the query results, however, did not look as expected.
A couple of months back, I finished my first major project with Ruby but sans Rails. You probably don’t know that, but I’m one of these people who first try to master a framework and only then look at the language documentation. This is the approach taught by “the Rails way.” When I started my adventure with Rails, I believed it to be a perfect framework, God’s gift to developers. A couple of months later, I saw big, old RoR projects… and I wanted nothing more than to run away from Ruby as far away as possible.
If you've ever been working on an application with a domain concept like organizations I bet you had to struggle with custom features, behaviors and complete white labels. Most young fellows start such with the if-else construction which quickly can fall into monster-spaghetti. Can we do better?
Some time ago we mentioned on our blog that according to Clutch, Monterail was ranked as a market leader in Polish development companies, Ruby on Rails developers, and software companies in general. With more testimonials published on our profile, we’ve climbed even higher and managed to become #1 in Ruby on Rails category.
In February, Clutch - a Washington-based business analytics company, released 2017 edition of updated research of top development companies. We’re very excited to announce, that Monterail, competing with 100+ companies, was recognized as a Market Leader in Polish Development Companies and Ruby on Rails Developers categories, currently ranking on 2nd place in both.
If you've ever found yourself adding another boolean flag to mark your object's state, chances are you would greatly benefit from introducing the workflow or aasm gems. Those two are best-known and most well-proven state-machine solutions in the Ruby world. I had the chance to work with both of them and found the experience pleasing. Today I'm going to concentrate only on the latter. I encourage you to check both and decide what best suits your needs.
A recent confession by Piotr Solnica started another bit of drama in the Ruby world. I started writing this post just after reading Fabio Akita's response to Piotr's post - for me it shows all the problems with Rails' defensive mindset, but it also reminded me that Rails is still a pretty cool framework. Feel confused? Let's solve that.
At Monterail we like to try new stuff. We try new languages and new (maybe not so new) frameworks.
Have you ever wondered how many simultaneous queries your application sends to the database? A hundred, a thousand, or perhaps a million? Whatever your answer, we should be aware of the influence that this number has on the performance of our programme. I would like to introduce to you the rspec-query-limit gem (you can find the source code on our github in the monterail/rspec-query-limit repository): this gem is a rspec matcher that measures the numbers of queries being sent to the database in Ruby on Rails applications. The main goal of this gem is to prevent the so-called
N+1 problem from occurring, and to make us realize how many different queries are subsequently being sent to the database. Rspec query limit measures queries using Active Support Instrumentation which allows us to measure certain actions in Rails.
Recently, I had my first real experience with deploying a (small) web application. I had to perform a pretty wide research and torture some experienced people with handling the difficulties. I gained knowledge that I consider worth sharing. Let me describe configuration of deployment stack and scripts created for the aforementioned app.