In February I wrote my first scheduled maintenance piece. It’s my chance to reflect and plan on career goals.
In February I was concerned about keeping my skills sharp. I spend a good chunk of my day talking to people, coordinating on projects, and gathering business requirements. This leaves little time for actual coding.
To be honest, one of the biggest challenges I have been running into for the last year is staying on top of changes and new trends in the stacks we work with.
React and state management tools in particular have been challenging to keep up on because those libraries are evolving quite rapidly and in some cases like React hooks, very dramatically from a design perspective.
I found a nice middle ground here, thanks to some coaching advice. I can use my my spare time to develop tools that help me in my role as a manager while staying in touch with changes in technology.
This inspired me to fix up a custom burndown chart and get it working again. As well as adding a new tab with Github activity stats.
I’m using the burndown chart in our standups and retrospectives, it has been really useful.
The Github activity report is pretty early in development, but it helped me become aware of a SASS file that was refactored (nice improvement) and another file that probably needs to be broken up.
As I mentioned, my progress was inspired by a coaching session. I feel very motivated and have several more things I want to try now.
In addition to the coaching session, I finished the book The Phoenix Project. This has me thinking about continuous deployment and streamlining our development process.
I also virtually-attended Failover Conf, which exposed me to the dev-ops world a bit. There are many takeaways I got from that too.
So what’s next? Work-life balance.
My goal this month (May) is to work my leisure and hobbies back into my routine. This past week I was really focused on the burndown chart and Github reports and didn’t give myself enough time to relax. I felt this towards the end of the week.
In addition, I want to see how I can cut down on meeting. These days I hold and attend LOTS of meeting. I need to have some time for engineering.
This last week I’ve been working on getting Drupal running through NGINX so I can test out a page builder feature. I was getting a weird error with the dev-server built into PHP.
I didn’t want to have NGINX running on Windows, so I spun up a VM. Setting up an environment can be time consuming and sharing content between host and client is a bit of a pain.
The last two weeks has had a theme: environment/tools setup. So my mind has been on “how do we improve this process?”
Documenting the process helped a little, but it is still a time consuming process. It also seems like there’s always some new gotchas that eat up time. If only there was a way to automate this…
Here is where Docker enters the picture and where it’s suppose to shine. We can create a group of containers that run a web server, database, and other needed services. This setup can be shared across workstations so we maintain a consistent work environment. We can also use Docker in production too with Amazon’s ECS (Elastic Container Service).
It sounds like a smart move and everyone is on board.
Great, now let’s tear down this idea and look at use cases and scenarios, starting with security.
But in order to feel out security we need to know what Docker is. That can be a little confusing. To be honest, I’m still a bit fuzzy.
My understanding is a Docker container is a very thin layer that can have libs and executables. When you run the container the processes run in their own isolated namespaces.
This diagram is the most helpful of everything I’ve come across.