• When Should I Use Magento 2 Helpers?

    One of the objects that developers familiar with Magento 1 will instantly recognize are helpers. When working with Magento 1, helpers proved to be a special type of object that looked similar in invocation to a singleton, but in reality it was more of a lazy way to share functionality between multiple locations. The main benefit to using a helper in Magento 1 is that it made it easier to access the __ function for translations and it was directly accessible from the template files .phtml. I’m sure many of you can relate to accessing a helper with the familiar Mage::helper('modulename');.

  • The Magento 2 Learning Curve

    The learning curve for various products and platforms tends to vary greatly depending on the complexity of the system you are learning. For example, people that understand how to use the internet and communicate online via email or Facebook are generally able to figure out how to work with Twitter without much of an issue. On the other hand, when you are looking at the learning curve for designing airplanes that are able to carry people, it should be much more difficult to understand how to start as compared to starting to use Twitter. (Yes, I know there are people out that think learning to use Twitter is exceedingly difficult, and make paper airplanes all day long.)

  • The Best Way to Learn Magento 2

    The very best way that I have found to figure out how to develop with Magento 2 is to write unit tests for a module. It not only requires you to figure out how to work with phpunit, but to also look at the existing codebase for examples of how the Magento 2 team works with the same objects and handles the same kinds of tasks. Once I wrote a full set of unit tests for my first Magento 2 module, I felt that I had a much better grasp of the workings of Magento 2 than I did before I started writing the unit tests.

  • 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.

  • 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.

  • 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.

  • 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.

subscribe via RSS