This is the last post in the simplify docker series ( if you haven't read the previous ones, go ahead and read them, it will make more sense afterward — part I & part II). This time I’ll cover networks, docker-compose, docker volumes, and more.
Docker-compose allows you to define and run multi-container Docker applications. With Compose, you configure your app’s services using YAML files (more on YAML here). Afterward, you can start all the services your configuration created with just a single command.
The following example is from TechWorld with Nana GitLab. BTW, Nana’s youtube channel is highly recommended…
I covered the basics of creating and building Docker images in part I (if you haven’t read that yet, I would recommend it since this part is based on it). In this part, I’ll explain how to run and delete an image of the container you’ve built.
I’ve heard a lot about dockers, even had some experience with it as part of my graduate degree. Still, as the old saying goes, learning is by doing. By doing, I mean using the stuff you want to learn as part of your daily work (instead of using it as part of a course in a semester since it will be forgotten). Actually, this is a technology that, in my perspective, should be in some familiarity level in each software engineer’s tech stack.
As long as I recall my relationship with computers, I’ve been using Windows. I customized everything to the perfection that fits my needs. Whether it's keyboard shortcuts, specific applications (like this one) that helped do my work, scripts, and more. If it can be modded or automated — I’ve done it.
Recently it all changed. 😱😱😱
I decided to take a new position. I confronted the fact that my daily usage will rely on macOS, which was unfamiliar territory for me. What to do? How will I get used to it? …
Recently I switched jobs, and as part of this change, I’ve been introduced to a whole new tech stack. RabbitMQ 🐰, Java Spring, Docker, etc. (meaning more subjects to write about 😂). Most of the technologies I use on a daily basis consume YAML as their configuration. In this post, I’ll try to illustrate what I’ve learned (and from where) while trying to understand this new world.
Here is a situation that I am pretty sure every team or individual contributor has encountered throughout his career. You get well-defined requirements, review them, ask questions, adjust them with your product owner, and prepared one heck of SW design. Soon after, the implementation phase begins, and a few hours or days before the end of the story, the business calls and asks for an extra feature (or change) to be implemented. WHAT?!
Usually, the project manager\product owner is responsible for filtering out these requests as “must-haves” or “nice to have”, but there are cases where…
Everybody, at some point, will encounter a challenging colleague. Being able to deal with a person like that is part of developing conflict resolution skills and learning to overcome those setbacks.
In the following paragraphs, I will try to illustrate how I deal with these situations.
To be honest, we have to know that not everyone we struggle with is someone who tries to give us a hard time, as every relationship will have friction moments. …
There are many ways you can determine whether a new feature will add value to the product or turn out to be a complete waste of time. For instance, you can undertake user research, analyze the demands of the market, and study existing solutions. However, we (developers) have a fantastic tool in our sleeves: Developing a running project that demonstrates the proposed solution’s key ideas is your optimal option — in my opinion.
Just one small thing: what do I mean by “demo”?
Does the team complain about bottlenecks that slow them down? The same things happen over and over again? Luckily there is a simple practice that, in my experience, can help instantly. What I actually mean is, does your team take part in a retrospective meeting? No?! 😱 Make sure to adapt it ASAP, no matter which software development methodology you follow.
“Those who don’t learn from the past are doomed to repeat it.” — George Santayana
A retrospect meeting is a safe place. Everyone can say what’s on their mind without being judged for their opinions or getting negative feedback…