REST as a concept was introduced by Roy Fielding in his doctoral thesis, named Architectural Styles and the Design of Network-based Software Architectures. 16 years later, REST as an architecture is the most widely accepted way to design and build APIs. I am sure we have all heard about it, and most of us think we are building actual RESTful APIs. But, are we? Let’s remind ourselves what REST is and then continue on something else that supplements REST, called HATEOAS.
Starting a greenfield application everyday is nearly impossible, especially in your daily job. In fact, most of us are facing (somewhat) legacy codebases on a daily basis, and regaining the context of why some feature, or line of code exists in the codebase is very important. This is where git, the distributed version control system, is invaluable. Let’s dive in and see how we can use our git history and easily navigate through it.
Recently, I have been building an API as part of my day job. Rails is a great framework to build APIs in, and it has been a joy so far. When building the responses of the API, it’s paramount to understand what HTTP statuses you should utilize, which will in return help the consumers by providing more meaningful responses. Sure, you could always have a status property in the response JSON, which will be a human-readable status code.
Object-oriented programming and design is (or, was?) a revolutionary way of thinking and designing programs. It introduced classes, objects, inheritance, polymorphism and many other ways to think about programming. As an addition, some very smart folks identified some pitfalls and patterns that occur in object-oriented programming and put them in books. That’s how we got a list of general code smells, design patterns and refactoring patterns that we can use in our everyday work.
Most of us use Git on a daily basis. We have all read a book (or part of a book) about Git, we learned how to do commits, track additions and removals, work with branches and so on. But, there’s so much more to Git than just committing your changes. In this post I am going to rant a bit about how we don’t utilise the power of our Git history, and how one can actually start doing it.
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: