Last week I organized a hacking session for my team at work. We ordered pizzas and we stayed a couple of hours extra to have a look at Docker. For some people this was completely new, for some others not as much. The feedback however was positive overall.
Here’s what we covered initially:
- Docker introduction and some concepts. What is Docker? What is a Docker image? What is a Docker container?
- Hands on (after all this is a hacking session): Install Docker on our laptops and run the hello world (some folks had Windows 7 laptops so they installed Docker Toolbox instead).
- Introduction to Dockerfile. We went over the instructions. We discussed ports, volumes, environment variables and base images.
- Introduction to Docker Store (formerly Docker Hub). Discussed certified images, popular images, etc.
From there, we created a simple Spring Boot application and dockerized it (following this guide from Spring):
- First, we created a hello world Spring Boot web application. To some people this was also new, so we stayed on this point for a bit longer.
- We created a Docker image for the app using Docker’s CLI.
- We created a Docker image for the app using the Spotify Maven plugin.
- Finally, we published the custom Docker image to AWS ECR.
- Just when we ran out of time, we briefly took a glance at docker-compose as well.
In my opinion, the success of a hacking session depends on the participation of the joiners (and that’s why our session turned out quite nice). This is not like a meetup where you go and hear someone speaking. In a hacking session, you have to join with a hands on experimenting mentality. You type, you search, you figure it out, you learn, you have fun!
(The photo is from the 1995 movie Hackers, but you already knew that)
Back in March, I gave a presentation at the Continuous Delivery Amsterdam meetup. You can watch the video here. The title is “CD at scale: the success story of a big rewrite”. It’s about how we applied CD in a big project that involved complete rewrite of our storefronts at work.
The term microservice has been getting a lot of hype and attention. I have to admit that I fail to understand what’s the big deal about it. The best practices about microservices are similar to the ones we should apply to everyday software design. Avoid tight coupling. Single responsibility principle. Keeping things simple. Even those principles go back to the old Unix mantra of doing one job and doing it well (and that’s from 1978). And even that could in turn be labelled just “common sense”.
Continue reading “Keeping it simple with microservices communication”
I recently joined a different team at work, working on a whole different project. For the past one to one and a half year, I did my bit in building up a culture in my old teams regarding code quality and the moral responsibility of a developer towards the codebase (also known as boy scout principle). Now, we have to start all over from scratch with the new team.
Continue reading “On Code Comments”
During the past year at work, we did a complete rewrite of our websites from scratch. Not only did we aim to build a mobile-first responsive website with high performance, we also tried to do it with continuous integration and continuous delivery in mind. All that on a proprietary platform not built with CI in mind. This was a very big challenge, which involved a culture change in a lot of people. Unfortunately, the project had a hard deadline. Things were left out. Corners were cut.
Continue reading “Worked fine in DEV, OPS problem now”
Taking a backup was arguably easier back in the days. You had only one computer, your data could fit inside a few floppy disks and the only cloud in your life was the one that would indicate chances of rain later in the afternoon. Things are a bit different today. Nevertheless, the need to preserve your files, your work, and your digital memories, remains the same.
Continue reading “Backup Strategy”
I spent the previous week migrating some old code I had laying around into GitHub. More specifically, I had a single git repository named “Legacy” that contained all sorts of projects and demos I had created over the years. It’s difficult to find exact dates but I found a few that go as back as 1998, so I can justify the title of this blog post.
Continue reading “20th Century Code”