As I mention before, I’m an open source enthusiast which happens to work developing software, designing architectures, and automate IT staff. So while on the computer, I want to have a tool flexible enough that allows me to do anything. Nowadays, many new IDEs are able to do that, yet I prefer Emacs.

Emacs is able to do anything, from reading an email all the way to run some AI assistants, while supporting many language server protocols (LSP). Most of this are not working outside the box, and it has a slightly stepped learning curve, yet it could become one of your favorite tools, due to customizations possibilities. This doesn’t mean that it is perfect.

At the end it doesn’t matter too much the tool, if it fits in the workflow with as less friction as possible.

Containers, this is a big part nowadays. It gets difficult to mantain a system that has many moving pieces. So having them into a box or container, it facilitates all the organization. Also, getting it setup in that way from the beggining helps to share it and use it on the cloud if it’s mean to.

Requirements:

• The Twelve-Factor App

Although every project has a different ecosystem, it’s important to standardize as much as possible. So there is a little bit less to remember. For example, working only with Node, you know that running `npm start` will run the code, but if you have another language as PHP, the same instruction will do nothing. I prefer having something like `make start`, so the project regardless the language used.

In case the project is not personal and has a method defined, then bash functions and aliases could help to make it available anywhere. One way to resolve this issue could be to write a Makefile, so from now on, and

For me this was a good improvement, yet I don’t like to install the dependencies locally, specially thinking that the environment has to be build close enough to a production version to avoid any issues on the continuous integration and delivery process (CI/CD), and simple enough to not overload the machine.

The whole idea of this post is to automate as much as possible on my workflow, like a standard that I will apply and try to improve as much as possible.

All coding projects have a starting point, that will be eventually tracked in a git repository. So why not to have a skeleton to speed up the ramp up. These will be:

• README - to explain the project
• Makefile - to standardize the actions, basically to run docker-compose actions
• docker-compose - to be architecture independent and a package to go to production
• /src folder - the project code

A Makefile could be as simple as you want, however, it would help a lot to be documented, I’ve found a project called mk-libs which after the setup, is ready to be used with docker-compose, please check it out. The installation is very simple:

curl -sL https://git.io/vh4Gn | sh

Ideally every repository will create only one image, that later will be deployed in stage and production environments, yet it’s quite common, that a project requires multiple containers to run properly. The idea here is to have a common workplace to be able to use domain name services to run and test the projects, without having to remember ports, check out development proxy.