The VP Geek Speaks

Magento 2, Docker, and macOS don't mix

I was excited when the Docker team launched their better-integrated solution for running Docker containers on OS X this past summer. It allowed our team to switch from using full Vagrant/Virtual Box based virtual machines for local development to a much lighter-weight solution. Compared to the Vagrant setup, Magento 1 seemed to run a bit faster and require fewer resources when running in Docker.

However, when trying to setup a similar environment with Magento 2, the performance numbers didn’t quite line up when using a macOS host. I’m sure a little background as to the system setup would make things a bit more clear.

Weird Errors Running Magento 2 Unit Tests

One of the great promises with the release of Magento 2 was that the core codebase would ship with unit tests built in so that you could have some way to be able to tell if you did something to break the site long before you ever pushed your code to production. In reality, though, since you should never directly edit the core files, instead only override their functionality, as a Magento 2 developer, there is little that you should be able to do that will cause the shipped tests to fail. Instead, the testing framework for unit tests makes it much easier for the extension developers and customizers to be able to unit test their custom code to ensure that the code does exactly what they expect it to.

Magento 2.1.3 Upgrade Static Files Not Loading

Magento just released an update to the latest version of their ecommerce platform to up the version from 2.1.2 to 2.1.3. There are a few differences between the versions, and one of those differences relates to the handling of the static files and what method is used to bust the cache of browsers to ensure users get the latest code whenever changes are deployed. Unfortunately, this upgrade by default breaks sites that aren’t aware of the changes needed to make this work properly.

What is Jekyll, and where have I been?

It has been a while since the last time this blog was updated, and I thought it was time that changed. The plan is to make sure to regularly update the site so that it doesn’t become completely stale, but its obvious the best of intentions don’t work unless they do, so here’s to something.

I’m sure if you have seen the site before, you will notice that the design has changed to look a bit different than it was in the past. That really just has to do with the platform of the site, which historically has been a Ghost powered blog. However, after using Jekyll for a few other projects, writing posts in Markdown with a static site generator has become quite attractive to me, and as a result, this blog is now using Jekyll for the management of the posts. One of the nice side effects of using Jekyll for the site is that you are able to take advantage of Github Pages for free hosting of your site. From what I have seen, the performance of sites using their infrastructure works wonderfully and always seems to be quick.

The Scrum Daily Standup

One of the hallmarks of the Scrum method of agile software development is a daily meeting, or “standup”. The purpose of the Scrum Daily Standup is to make sure the Scrum team is aware of what tasks the other members of the team are working on as well as asking for and offering assistance to other members of the team as needed. The Scrum Daily Standup is NOT a meeting to gather the project’s status. In addition, this is not a planning meeting, so the discussion of implementation details is outside the scope of the meeting, and should be handled in a separate meeting, or after the conclusion of the Daily Standup. The is typically characterized by being 15 minute long at its longest, and everyone stands during the meeting. Each speaking member of the meeting will typically answer these three questions:

How do you handle a developer that doesn't play by the rules?

Software development teams are fickle groups. It seems everyone has their own pet peeves that set them off, and a group that is cohesive and functioning well can quickly turn into one that shows little output for the time spent working.

In order to create and nurture a software development team takes leadership that understands all of the idiosyncrasies of their team members, and ensure that no one member derails the rest of the team. While some may use this as a way to discriminate against entire groups of people, if done properly, should only be utilized to maintain harmony after all hiring and performance decisions have been made.

SCRUM Sprint Planning Gone Wrong

One of the things that is a hallmark of the SCRUM method of Agile development is that you have a unit of time during which you commit to accomplishing some amount of work before that unit of time has elapsed. In order to commit to how much work should be accomplished during the “sprint”, all members of the team meet at the beginning of each sprint for a sprint planning meeting.

Handling Callbacks with a Depth-First Tree in JavaScript

One of the hardest things to do in JavaScript when working with complex data structures and a callback oriented platform is to know for sure when all of your callbacks have been fully executed. This issue came to light when working with a MongoDB datastore that was being used to store an infinitely-deep nested menu structure.

This menu structure could be visualized as being a tree. In order to get the all of the needed menu items from this tree, a depth-first traversal of the tree was determined to be the easiest to track. Since I typically try to write the least amount of code possible to solve a problem, I started out with a set of simple callbacks that worked perfectly as long as there was only one menu-item that had any children. As soon as I had multiple children to traverse, the timing of the execution of the final callback happened well before it should have as well as occurring again at the correct time, causing some unexpected results.

Don't Use MongoDB For The Wrong Things

The early phases of a greenfield project always seem to conjure up grand ideas of how to use the hottest new technologies to accomplish your goals. Many times, these grandiose plans give way to a more level-headed design discussion where more realistic technologies are adopted. However, there are a few times where the developer with the idea to use the hottest new technology is the one in charge, and ends up getting his way.

Write Your Own Compass Mixin

As a developer working with CSS, one of the things that I find a bit troubling is the amount of style definitions that I have to repeat over and over to achieve the design I desire. One of the basic tenets of software development is to utilize the DRY principle, otherwise known as Don’t Repeat Yourself. Fortunately, when you implement Compass and SASS in your project to generate your CSS, you have a way to avoid copy-paste programming.