Getting More Familiar with Docker


I’ve been spending this week getting more familiar with Docker. I’ve learned how to build new images, spin up a collection of related containers with Docker Compose, and push an image to AWS.

I’m pretty excited about how this will help my team, but I’m also nervous about the unknowns we’ll encounter. My goal is to free up time, not take up more.

It’s important to know what Docker is and isn’t. To be honest, I’m still a little fuzzy. I wrote about this in my last post.

Docker utilizes virtualization technology to run processes in isolated environments called Containers. It has some similarities to virtual machine technology, such as VMWare and VirtualBox.

Docker Containers do not hold an OS, but they do have libraries and binaries from other OSes.

After working with Docker a little, I’m now much familiar with commands to setup a container and access the container (docker exec -it is my friend). I’ve also gotten more familiar with docker-compose (docker-compose up/down are pretty cool).

The documentation for Drupal on Docker provides info on both setting up Drupal and MySQl.

I’ve been able to spin up a Redis and MySQL server with Docker, it has simplified the setup and given my team a consistent toolset.

What is this Docker Nonsense?


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.

Regularly Scheduled Maintenance


For about the past year I’ve been putting my time towards planning and managing projects and less time with implementation.

I was stubborn in accepting I didn’t have enough time to both manage and code. I learned the hard way.

I tried to code out a complex solution that ended up taking a long time to finish, because I kept getting pulled away. After that, I focused more on coaching. Guiding my developers to make good decisions has become a more effective use of our time.

One challenge with this approach is my coding skills are becoming a little rusty. My memory of higher level design is fine, but my familiarity with the code base and specific implementation has started to become fuzzy.

Another challenge is keeping up to speed on new features that come out for languages and frameworks. Last year I had an instance that caused a little conflict when I wasn’t familiar with with some new React features that had been announced the year before.

There is a question I’m hoping to get an answer for this year; is it possible to be a technical lead and a manager?

I’ve heard of positions that are both, but my personal experience has shown me it’s difficult and probably best there’s a separation of the two.

Regardless of if I hold on to those responsibilities or not, I want to keep my skills up to date. And that requires some routine maintenance.

I think it’s best to focus on one area at a time, which has me a little torn. Do I put that attention on work or hobby? That’s a topic to delve into more in another post. For now, I’m going to side with work and explore Drupal more.

I was tempted to say Drupal and React, but I need to limit myself to reasonable goals.

Putting in any time to perform any maintenance is an improvement over the past two months.

My target is to get Drupal setup in an environment to test out the layout builder and see how their database schema is structured.

Wish me luck!

An Uncertain Path


I’ve been working towards becoming a Software Engineer Manager for several years now. 2019 was a crucial year for my path to management that held as much doubt as it did promise.

At the beginning of the year I was working with my director/manager to officially request a promotion. I had been shadowing and taking on management responsibilities over time.

The more managerial tasks I took on, the less coding I was doing. That was expected and I was fine with that. I was still able to create proofs of concept and stay ahead of my developers.

However I hit a roadblock along the way that postponed my promotion. There were some things I still needed to work on to make others comfortable with me managing. It was a strange time in my career, I felt like I was losing touch with my software engineer skills and I wasn’t a manager either.

To be honest, it was a bit scary because I thought I was existing between roles and facing the reality my path may dead-end.

One fear that kept creeping up in my mind was becoming rusty with programming. If things didn’t pan out with management, would I be in trouble from rusty programming skills?

I got my answer towards the later end of the year after looking into what responsibilities a lead hold in other companies. For some, it didn’t differ much from what I was doing. The responsibilities for management and a lead could overlap quite a bit.

I no longer felt as lost, but I had also gained a lesson; roles aren’t cookie cutter. From company to company, they mean different things. And over time they may be redefined (though there are some foundational attributes that stay the same).

Fast forwarding a bit, as of last week I finally got my promotion. It involved quite a bit of personal growth that I didn’t touch on here.

What I’ve been focusing on here is feeling in between roles and discovering it isn’t abnormal.

However others may have a more well defined sense of roles. Mileage may very.

I still have a fear of letting my skills become rusty. This last weekend it became apparent I need to work on some side projects again to sharpen my skills.

I’m feeling really good about my daily responsibilities though and am looking forward to helping my developers go and working through challenges.

More on that later.

October Development Progress


This is the first of my weekly reviews. I’m starting this to help keep track of what I’m doing and and to set forward goals.

The past two weeks have been a mix of new and old projects, including business-oriented project planning web applications, a World of Warcraft data sync, and two game development projects.

Asana Features

I use Asana to manage my teams tasks. Asana is very simple and flexible, but is missing some features we need to keep track of our sprints and better organize our tasks and Kanban board.

Sprint Reporting

One of these missing features is a burndown chart based off of effort estimation. I’ve been building out our own burndown chart in an Electron app using Google Charts to display the statistics and feeding in the task data from Asana using their API. At this time I’ve got the chart but also a break out of the effort we’ve committed and the effort we’ve knocked out.

This has already proven to be really helpful, as we now have an easy way to track our progress and see the sum of effort completed at the end of the week.

Asana Bot

Asana supports custom fields, but doesn’t allow us to make them required. Requiring the effort estimation for a new task would be ideal. In addition there are a few other events where I would want additional info provided, such as when a task is labeled as blocked, a due date is passed, or a new task is added to the sprint.

To solve these problems, I’m building out a Slack chat bot using the Botkit framework. So far I’ve been learning the ropes of what the chat bot can do and building out the groundwork.