MY HUMBLE EFFORT TO SIMPLIFY DOCKER PART II

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.

My humble effort to simplify Docker Part I

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.

This is the first part in a series about simplifying Docker usage. In this blog post…

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.

What do you mean by difficult people? 🤔

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.

Here’s why.

Just one small thing: what do I mean by “demo”?