Technical Debt is inevitable, only you can reduce the interest to be paid
I know this post doesn’t invent anything new and you may have read about technical debt other hundred of times. This post is just another take on the Technical Debt matter, with the description of the practical approach we follow in Mikamai.
The process of software development is traditionally composed by three phases: development, testing, release. These phases can then be further detailed or splitted: the development phase may comprehend frequent deploys on an alpha environment which will contain incomplete features but will allow to receive feedback easily; testing might then happen on different environments, sequentially (i.e. the first one is an isolated environment with an empty data set, the second one is an isolated environment with a realistic data set, the third one is accessible from the internet and can be used for stress testing, and so on)
The one thing happening at the end of the traditional development life-cycle is the release, where the term “release” is much more like a “furniture shipment” than a digital good delivery. In this traditional lifecycle the product is indeed considered stable, without any issues, and we can rapidly forget it and move on to the next product. There can be a period of controlled operativity where we’re admitting that the app may be affected by some bugs, that will be fixed. But anything weird happening after this period is considered expected.
Problem is: a software feature is not a desk, or a seat.
Continue reading “Technical Debt: Definition and Practical Approach”
When talking about users authentication in Rails land there is one name that generally stands above all the other available gems. This name is Devise.
I would not be so wrong to call it the de facto standard of Rails authentication considering the time has been around and the vast documentation it has under its belt.
Regarding for example the OAuth2 functionality there is a well documented page inside the wiki that describes how to implement it for Facebook.
Unfortunately what presented inside the documentation doesn’t always blend well with the other functionalities of an application.
Given an array of measurements ordered by time we have to implement a function that returns an array which will be filled with null measurements for every missing one.
In particular we want at least a measure for each hour after the time the first measure was taken.
This is necessary since we want to display this data in a chart which will try to connect this values with a line and we want to highlight missing measurements problems like in the following image.
Developers who are familiar with the “twelve-factor” app know that configuration should be stored in the environment (loaded via env vars), not in the code. If you’re writing a Rails application you may want to use the
dotenv gem, which allows you to store env variable in a handy series of files such as
.env, .env.development, .env.test and so on. You can read the gem readme for all the details.
Since configuration varies with time and you may be working with many other developers, it is quite handy to store these env files in your git repository, but there’s a big caveat: you should not store passwords, secrets and tokens inside a git repo for security reasons, unless they’re encrypted.
Studying Elixir, I decided to write a client for an existing API and I wanted to do it in the correct way™: writing a complete test coverage.
My choice was to use HTTPoison (since I like Poison for JSON parsing) and ExVCR to write the API tests.
So, what is ExVCR? If you come from the Rails land, it’s the Elixir version of VCR, it:
“Record and replay HTTP interactions library for elixir. It’s inspired by Ruby’s VCR, and trying to provide similar functionalities.”
It allows you to make API calls and record those on “cassettes”, allowing you to replay the recordings at every test run, decoupling the test phase from the API server and permitting offline tests.
In this last period I’ve been developing a project with
redux-saga, and the
styled-components. I am really satisfied with
styled-components so I decided to explain you why I think they are so cool.
Continue reading “A Little Dive into Styled-Components”