In my career, if I ever get asked to interview someone, I would always start the interview with version control. Maybe it’s a bit of an exaggeration, but to me, understanding version control and having a good grasp of programming logic is more important than just knowing the syntax and the stdlib of a programming language. But, for whatever reason, whether it’s laziness or simply conformism, we often learn a tool until a certain point that works for us and we stop.
I don’t think that at this point Rubygems needs any introduction. Except if you have been living under a rock for the last 10 years or so. In that case, I think that you wouldn’t be here reading this blog. You would be having a problem understanding why someone would like to share what they are eating, or what they are doing at the moment. For the rest of you, have you heard that Rubygems is extensible?
Imagine you just woke up, took a shower and you immediately go to your coffee machine to make that strong, large, morning, double-shot, extra-spice-and-everything-nice cup of coffee. Sure, you go to the machine, press some buttons and the next thing you know, you are waiting for the coffee to start pouring into your cup. And then, something’s not right, and something starts to smell bad. A morning nightmare, right?
We’ve all been at this point where we have bloated our classes with primitive values all over the place. Usually, we drop in primitive constants that, for whatever reason, we think that are a good fit to the class. Or sometimes, we just dump primitive values instead of small objects, thinking “it’s okay, it’s just an attribute in the class”. But, does it always make sense? The problem Say we have a project for a finance journalist who wants us to automate his text editor to do some random fixes to his texts, on the fly.
Indexes in relational databases are a very imporatant feature, that reduce the cost of our lookup queries. In the last post on the basics of indexes in PostgreSQL, we covered the fundamentals and saw how we can create an index on a table and measure it’s impact on our queries. In this post, we will take a dive into the inner workings and some implmentation details of the most used index type in PostgreSQL - the B-Tree index.
We have all heard about indexes. Yeah, that thing that it’s automatically added to the Primary Key column that enables fast data retrieval and stuff. Sure, but have you ever asked yourself if there are multiple types or implementations of indexes? Or maybe, what type of indexes your favourite RDBMS implements? In this blog post, we will take a step back to the beginning, exploring what indexes are, what is their role, types of indexes, metrics and so on.
Reactive Programming is a relatively new and interesting programming paradigm that has picked up quite a bit of popularity lately. Out of curiosity, I did a bit of research over the weekend. In this blog post I will summarize what I learned and try to explain what RP to any novice out there. Also, I show you how to use the Reactive Extensions for Ruby. Let’s dive in! The Motivation I rarely have strong opinions, but I really think that to understand anything in life, you need to understand the motivation behind it.
Recently I started tackling refactoring in Ruby with my blog posts. It seems that it’s one of the most popular topics that people would like to read about, so here I am with another installment of refactoring in Ruby. This time, we will see if it’s the right time and place for a Builder… whatever that means. Just a bit of backstory In my last post on refactoring in Ruby, I covered how to detect and refactor the long parameters code smell.
In the last couple of years, we have seen a lot of development in the devops field. It’s becoming much easier for developers to provision servers and deploy their applications on those servers just with a couple of key strokes. Since the start of the SaaS and PaaS products (even before we knew them as that), we have seen a vast number of companies and communities try to make our lives easier by developing smart tools that will fit into our workflow seamlessly.
Ruby is a really clear and expressive language, but we developers sure know how to make a mess. Even when you think your classes are nicely written and tested, things can still get out of hand. I am pretty sure you’ve heard one (or more) of your more experienced colleagues/mentors tell you that “something is smelly” in the code. Well, in this article we will cover one of the simplest code smells - long parameters lists in your method signatures.
There are a lot of refactoring patterns available out there for us. I assume that most of us use these patterns, at certain times without being aware that those refactoring steps are defined as a pattern in the past. In this post, I will take you through an example of refactoring Ruby code with the Extract Class pattern by using Test-Driven Development. Let’s dive in! What went wrong at the test?
Ruby on Rails as a framework does a lot of things for us developers. We get a very customizable middleware stack, great routing system, very expressive ORM, helpful modules with great utility methods in them and so on. But in Rails there’s more than meets the eye. It does some great things that we just take for granted or on occasions we don’t even know they exist. Some of these features are TLS redirection, secure cookies and HTTP Strict Transport Security (HSTS).
Most of us write some Rake tasks and completely forget about them. In fact, we rarely give any love to our Rake tasks. Well, I think it’s time we change that. Let’s see why and how we can test our Rake tasks. But, why? Yes, it’s a legit question. You can always say “I already tested my classes!”. But, there are couple of reasons why you should always test your Rake tasks:
Elixir is a really cool language. Although I do not have much experience with it (yet), I am always trying to build interesting stuff with it and learn the built-in tools. In this blog post I decided to show you how to build a self-contained command line application with Elixir, with some help from escript. Escript Erlang and Elixir have this cool thing called escript. It’s basically a tool that compiles an Elixir app that you have as a command line application.
Learn how to integrate Minitest into your Ruby project and reap the benefits of test-driven development. Read the article here.
Mixins in Ruby are a very powerful feature. But knowing how to test them sometimes is not so obvious, especially to beginners. I think that this comes from mixins’ nature - they get mixed into other classes. So, if you think that there is a lot to testing mixins and you easily get overwhelmed by it - take it easy, it’s not that hard. Let’s see how easy it is to test mixins, with some help from the lovely Minitest.
Phoenix is a really powerful and customizable framework. One of it’s small but important configurations is filtering custom params from the logs. I am sure that this will be more interesting to beginner than experienced developers, but nevertheless, let’s see what’s the motivation behind this and how to do it in Phoenix. Motivation First, I’d like you to understand the motivation behind this and why this is useful. Think about it.
Elixir’s built in testing library is called ExUnit. It’s a proper testing framework, which, although simple, gives the developers a lot of power and flexibility. If you come from Ruby land, I am sure you’ve been in a position where you want to set a certain test to be skipped. For example, RSpec in Ruby does it with the pending method. Let’s see how we can customize our test suite so ExUnit can skip over tests in our test suite.
As some of you have heard lately, Elixir is the new hotness. Is it just hype? Well, I thought so at first, but I told myself “heck, even if it’s a waste of time, at least I’ll broaden my horizons”. Which, if you think about it, it not really is a waste of time. Long story short, after couple of weeks of fiddling with the language, mostly by playing with it’s web framework I am delighted to say that it’s a really cool language that you should try out and also, I published a really small API wrapper for Elixir.