Technical Debt: Definition and Practical Approach

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”

How to share Rails i18n messages with React through webpack

This time I’m here for sharing a solution for a specific problem I encountered a couple of days ago.

There’s this existing Rails monolithic application. Team and customer decided that time had come for this app to be decoupled in two components: Rails would do its usual work as an administration and API backend, while React would be used for the frontend component. Everything related to the frontend would then be rewritten, keeping the same behaviour and visual design. But there are a lot of translations related to the user experience and that have now to be included in the javascript bundle, while they were before used by the server.
Continue reading “How to share Rails i18n messages with React through webpack”

How to: Preview a resource in an iframe

Let’s say I have a form to create/edit a resource. On a side of this form I want to show a live preview of my resource. Whenever the form changes I need to update the preview.

At a first glance the solution seems pretty easy, right? Use an IFrame and update the src update on every change. Continue reading “How to: Preview a resource in an iframe”

Continuous delivery with Travis and ECS

ECS is a good product. Sadly it’s authored by the same UX designer that authored all other AWS products, so a lot of people couldn’t even succeed in starting a simple hello world container.

Some months ago @fusillicode wrote a two-part tutorial on how to dockerize and deploy on ECS a WordPress app (you can find them here: part 1 and part 2). Of course, given we’re talking of docker, the technology you’re using is not so important.

What’s missing in those posts is how to do a painless deploy.
Continue reading “Continuous delivery with Travis and ECS”

Ruby builtin Hash

Today I was really debated whether to publish another post about SQL (it was a reflective post on how ORM may have ruined us) and a post about the introspection of a ruby builtin feature.

I hate to be repetitive (the SQL post would have been my third post in a row) and I always find enlightening to study language internals because there you can see the real programming magic. So, why not to post on the Ruby Hash and its lookup complexity of O(1)?

Then I realized there’s plenty of blog posts about the Hash object. And one of these is written so well that I could never compete.

What I really liked of this post is that the author is not only explaining the theory behind Hash, but he also try to reimplement it.

Why do you need Arel?

In my opinion Arel is one of the greatest and most underestimated gems. Of course today Arel is also one of the most used gems because it’s shipped in Rails, but how many people use it actively? And why would they?

Since Rails 3 Arel is the base block of ActiveRecord. Every time you pass a hash to where, it goes through Arel eventually. Rails exposes this with a public API that we can use when we have to write complex queries.
Continue reading “Why do you need Arel?”