Karol Galanciak - Ruby on Rails developer from Poland

When Validation Is Not Enough: PostgreSQL Triggers for Data Integrity

Is validation in your models or form objects enough to ensure integrity of the data? Well, seems like you can’t really persist a record when the data is not valid unless you intentionally try to bypass validation using save: false option when calling save or using update_column. What about uniqueness validation? A classic example would be a unique email per user. To make sure the email is truly unique we could add a unique index in database - not only would it prevent saving non-unique users when bypassing validation, but also it would raise extra error when 2 concurrent requests would attempt to save user with the same email. However, some validations are more complex that ensuring a value is unique and index won’t really help much. Fortunately, PostgreSQL is powerful enough to provide a perfect solution to such problem. Time to meet your new friend: PostgreSQL triggers.

Security on Rails: Hacking Sessions With Insecure Secret Key Base

I was recently asked what is secret key base used for in Rails applications and why not secure value of it (or even worse - the public one!) creates a security issue. That was a really good question, I remember how it was a serious threat years ago, especially before introducing secrets.yml in Rails 4.1 - at that time by default secret_token initializer was generated and the secret key was directly stored there. The result was that in many open source projects secret key was publicly available creating a great security risk. Let’s take a look how exposed secret key base could be exploited.

PostgreSQL in Action: Sorting With NULLIF Expression

Ordering with ActiveRecord and PostgreSQL may seem like an obvious and simple thing: in most cases you just specify one or several criteria with direction of ordering like order(name: :asc) and that’s all, maybe in more complex scenarios you would need to use CASE statement to provide some more customized conditions. But how could we approach sorting with forcing blank values to be the last ones, regardless of the direction of the sort? You might be thinking now about NULLS LAST statement for this purpose, but that’s not going to handle empty string. For this case you need something special: time to meet NULLIF conditional expression.

Implementing non-RESTful Actions With Ember Data

In my recent post I mentioned some strategies of handling non-strictly CRUD / RESTful actions in API. One of them was adding extra actions beyond creating, updating and deleting resources. As it’s not a standard solution and some data layers on client side (like Ember Data) don’t handle it out-of-box, I was asked by some developers what’s the best way to handle such actions. So let’s see how can we hack into Ember Data and make it smooth.

How to Handle Non-CRUD Logic in Your API

If you happen to develop API for non-trivial app with complex business logic beyond CRUD directly mapped to the database tables (i.e. typical Active Record pattern) you were probably wondering many times how to handle these cases and what’s the best way to do it. There are quite a few solutions to this problem: you could add another endpoint for handling given use case, add non-RESTful action to already existing endpoint or you can add a magic param to the payload that would force non-standard scenario in the API. Let’s take a closer look at the these solutions and discuss some advantages and disadvantages of each of them.

Refactoring Tips: Trade Conditionals for Type Delegation

Having some kind of type attribute in your models is a pretty common thing, especially in applications with more complex domain. How do you handle such cases? Is it with multiple conditionals / case statements in every method dealing with the type attribute? If you’ve been struggling with organizing and maintaing code for such use cases then say hello to your new friend: type delegation.

Ember and ES7: Async / Await

In the previous blog post we were exploring a new wonderful feature coming with ECMAScript 7: decorators. This time we are going to learn about async / await, which is at this moment at Stage 3 in TC39 process, which means it’s already a release candidate that passed Proposal and Draft stages. Just like decorators, it’s already available in Babel. Let’s see what kind of benefits does it offer.

Ember and ES7: Decorators

ES6 introduced plenty of useful features such as modules, arrow functions, let variables, destructuring, classes and many more which made writing JS code much readable and enjoyable. Thanks to Babel, a JavaScript transpiler, it’s been pretty painless to use them all in the applications. If you happen to develop EmberJS apps and use ember-cli, you don’t probably think much about Babel or any transpilation as these features are a natural part of every Ember application. But the new features didn’t end with ES6, we’re going to have even more of them in ES7 (2016). Some of them can already be used, thanks again to Babel. In this blogpost I’m going to explore a very powerful concept which of decorators.

Embarking on Programming Journey

Recently I’ve been repeatedly asked how to get started with programming, especially Ruby and Rails. To keep things DRY and make sure I always include all great resources for learning, I decided to write this blog post. Most of people who asked me had never programmed before or had done some coding before in other languages, but are not (yet) proficient developers, so if you are a total beginner or just started learning Ruby / Rails and you are not sure what the next step is then you came to the right place.

Model Your Domain With Composed Models

In many Rails applications the modeling is limited only to creating classes inheritng from ActiveRecord::Base which are 1:1 mapped to database tables. Having AR models like User and Project doesn’t tell much about the domain of your application. Well, you can add some domain logic to the models but that way you will easily end up having giant classes with thousands lines of code, so let’s just use models for database-related stuff only. Other option would be to create service objects for every usecase. That’s a good and clean way, but it’s merely the interaction layer between different parts of your application. You may end up easily with all logic encapsulated within service objects that will start looking more like procedural programming rather than proper OOP and not real domain API at all. The good news is that you can easily counteract it: time to use composed models.