A few weeks ago, I've posted a SSH - Launch a terminal on your session without having to authenticate yourself article about the ssh command in Linux.

I'm pretty sure, like me, you are tired to use command line like ssh christophe@1.2.3.4 to start a ssh connection because ... you know, you don't need to connect on a server; no, you need to connect to the server where the application is running; you know the name of the MyAmazingApp application but certainly not the name of the server or its IP.

That's the case for me anyway.

So, I need to connect to my vault, in which I list all the information about applications, server names, credentials to be used, ...

It would be pretty cool to run ssh MyAmazingApp no?

TLDR: one minute is the time you'll need to copy/paste two files' content and to run one Docker statement.

Sounds crazy but it's TRUE. You'll just need one minute to create the example provided here below i.e. create your project's directory, create two files and run two Docker statements and ... it's done.

As PHP programmer, when I've taken time to read a blog article about FastAPI I thought Nodidju ! Ç' n'est nén pussibe (For Christ's sake! It can't be true).

With just two files, we'll build our own Docker image with Python and FastAPI installed and to code our REST API application. No more than two!

Impossible to not try immediately and ... wow ... that's TRUE!

https://heimdall.site/

I've never been a big fan of browser's bookmarks and in fact I have almost none. And, quite logically, I almost never display the favourite bar.

I only visit a few sites on a regular basis and my browser history remembers them; otherwise a famous search engine remembers them for me.

However, I'm not averse to a personalised homepage and I'm quite happy with Heimdall at the moment.

So, no need to tell it anymore, I'm doing everything in Docker containers even coding (since I'm coding using devcontainers) but ... till now, I was using git on my host only.

I mean, I need git on my host because I should be able to clone a repository. But the question is: should I use git from my host except for git clone? Can I work in my container and from there do actions like a git push?

My current workflow is: from my host, I'm cloning a repo on my disk then I build Docker image(s), run container(s) and jump in it (like starting my devcontainer). I start too a console in my container to start processes, work on files, ...

From time to time, I push my changes to my versioning system (like Gitlab/GitHub) and here is the point: I need to exit my devcontainer (or use another console), go back to my host and run, from my host, commands like git add . && git commit -m "feat: The great feature I'm working on it" && git push.

Let's see how to improve this process and be able to run git commands from inside our container.

Did you know that using WinSCP, you can run a search on your FTP to find all the documents containing a given string? It's native in WinSCP; nothing more to install but...

However, it's insanely slow; let's see how we can do it better and almost instantaneous.

You like clean code, don't you? And you hate getting an email from your versioning tool (e.g. Github or GitLab) telling you that your last commit didn't go through, that the formatting of your code is bad; this is because you've left one space too many at the end of a line or you've used single quote instead of double (or the opposite), for example.

You've pushed your changes, already start to work on another activity, perhaps another project and boum, two hours after your last commit (because the CI server was working on a lot of pipelines before yours), boum, you get a Your last commit has failed, #gnagnagna. I hate it as much as I love clean code.

So, what should we do to avoid this?

The answer is simple! Before each push, we should run the same code analysis tools that are executed in the CI, i.e. phplint, php-cs-fixer, phpcbf, phan, phpstan, ... (for PHP) or pylint, mypy, prospector, black, ruff, ... (for Python) or shellcheck and shellformat (for Linux Bash) or ...

We should, but do we think about it every time? Unfortunately not.

Let's see how to correct this.

How about asking Docker to create the files it needs itself?

If you're a regular reader of this blog, you'll know by now that you need a Dockerfile to describe how the Docker image should be created and what should be included in it, and very often you'll also need a composer.yaml file to explain how the container should be created, e.g. which port to map to, which volumes to use, and so on.

Imagine you've an existing PHP application and you don't want to create the files needed for the dockerization by hand.

You just want to very quickly and using a wizard, to be able to answer to some questions and hop, it's ready.

The docker init command is the one you're looking for.

Very small article today, just to introduce recraft.ai (thanks Pierre for the tip) which is an image generation tool assisted by AI.

Unlike other tools like Bing image creator (the one I used to illustrate my articles), recraft.ai can produce the same image but using some variations (using the fine-tune or the variate feature).

Using the editor, we can do some rotation, add text, resize the image, ...

And adding words like Realistic photo will generate images as if they were photos.

If you're a self-respecting programmer, you can't develop without code analysis tools. For PHP programmers, you already know a lot of them (rector, phpstan, phan, phpcs, ...). See my previous articles Rector 1.0.0, my friend, my coach and Docker image that provides static analysis tools for PHP f.i.

What about Python?

Be careful, it's a bomb. Docker has revolutionised the world; let's not be afraid to say it loud and clear, and most probably Dagger.io, created by the same people as Docker, will follow in its footsteps.

Dagger.io aims to be a tool that lets you execute steps of a workflow in exactly the same way as a CI/CD (Continuous Integration / Continuous Development) system like the ones of GitHub, GitLab, Jenkins, ... does.

But what is a CI? It's a step carried out by your server once you've pushed a new version of your project. During a CI, you can validate the syntax of your code, make sure it conforms (e.g. to formating rules), run code quality analysis tools such as checking that you don't have any undeclared or untyped variables or dead code (e.g. a function you no longer use).

During a CI, you can also launch your unit tests and run them each time you push out a new version of your project.

The aim of the CI is to ... crash as soon as something isn't in the expected state; e.g. you've forgotten a ;, you've got a violation (spaces used instead of tabs), a unit test no longer works, etc. So the aim of CI is to guarantee that your code is excellent.