asdf the “easy to write and hard to read” version manager

As a Rubyist one of the first thing you end up doing is to manage many different Ruby versions on the same machine. As a matter of fact, one of the first steps in setting up a new workstation is to install some kind of version manager like RVM or rbenv.

Unfortunately it doesn’t end up simply like this…

Continue reading “asdf the “easy to write and hard to read” version manager”

Elastic IP Address (EIP) and ECS (EC2 Container Service) cluster, a naive solution

Recently I had the opportunity to set up another ECS cluster for a Ruby on Rails application that exposes a few API endpoints and a backend to manage some contents, i.e. images, videos and so on.

Considering our previous experience we decided to automate the provisioning of the infrastructure by using Ansible and after a bit we ended up with a few playbooks that allowed us to bring up everything we needed, from the DB to the instances, ELB, task definitions and services.

Everything was working quite well until we were asked to provide a static IP that could be used to access the aforementioned API endpoints.

Continue reading “Elastic IP Address (EIP) and ECS (EC2 Container Service) cluster, a naive solution”

A few (silly) tips about AWS EC2 instances “backup/migration”

EC2 instances are often considered long lasting resources in charge to deliver the Web applications deployed on them.
This is actually a wrong belief as their nature is instrinsically ephemeral and they should be considered reproducible assets in the context of a much larger infrastructure.

Continue reading “A few (silly) tips about AWS EC2 instances “backup/migration””

Bash quirk in Dockerfile

In my last article I wrote about my initial experience with ECS, Docker and WordPress.

While already practical with the core concepts of Docker, after learning the basics of ECS and creating a working Dockerfile I encountered the need to dive deeper in many aspects of the “platform” and the technology under discussion.

Continue reading “Bash quirk in Dockerfile”

Check PHP syntax error in PHP.

This sounds much like “Inception” right?

Well a week ago I had the need to implement a PHP syntax check in PHP, to be more precise inside a PrestaShop (PS) module.

After a little bit of “googling” I stumbled upon a StackOverflow comment showing the solution I needed. Actually I missed the original link so I’m posting this pearl as a “bump” just to help spread the solution. I don’t own any credits 😉

Continue reading “Check PHP syntax error in PHP.”

error_log all the things! (in Prestashop)

William Edwards Deming once said: "You can’t manage what you can’t measure.“

I find this statement pretty similar to: "If I can’t var_dump I can’t fix”.

Actually this statement is just a bit stronger than Deming’s one but I find it true in most of the cases.

It doesn’t matter if code is properly written and TDD and/or BDD are actually used. When a program begins to work unexpectedly, one of the things that is usually done to shed some lights on the problem is to put some “log” directives here and there and look at the results.

This kind of debugging strategy, while being rather primitive, can be very useful in many contexts.

For example if you’re developing something with PrestaShop (PS) (so you’re writing PHP…) you may feel the need to log something inside the apache error log.

This can be easily accomplished by using the PHP function error_log.

But this function  accepts only strings, so in order to log a complex structure like an hash you should first convert it to a string using something like var_dump or print_r.

Sincerely I was expecting some kind of support from PS core functionality but unfortunately this wasn’t the case.

As a result I end up writing a bunch of lines of code to log whatever I need right inside the apache error log.

Here they are:


class Tools extends ToolsCore
{
  public static function console_log()
  {
    $args = func_get_args();
    $log = '';
    foreach ($args as $arg) {
      $log .= print_r($arg, true);
    }
    error_log($log);
  }
}

I simply added a public static function to the Tools class (by properly overriding it) that takes any number of arguments and builds a string by using the print_r function.

The string is eventually logged on the apache error log.

I hope this can be useful to the ones willing to go with the old style debugging 😛

Cheers!