Our Blog.

Expert thoughts from our software development and design leaders.

  • Martin Fowler in his book defines refactoring as “a change made to the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior”. This book contains a long list of refactorings techniques that mean to be applied under certain scenarios and with the intention to eliminate “code smells”. Refactorings are a very extense topic and I’ve found them to have an important role in the software development process.
  • My team has faced an issue with timezones repeated times: Apparently, default Locations were not present in our production deployments of our apps, that took us by surprise given locally these were present and working nicely 🤔. This is an issue I’ve faced before. Every time I wanted to show dates in a certain timezone but such timezone was not present in our production environment, Our app ended up in GMT for everything, or we had to create our own locations.
  • One common Javascript flaw I see in repositories I get in touch with is the usage of both yarn.lock and npm-lock.json. This is not on purpose, in most cases is due to the lack of communication on the tooling the repo uses or different points of view on the best tooling for the problem at hand. In this short post, I’m not going to focus on communication strategies for the codebase, nor in which one is better between YARN and NPM.
  • Buffalo is a great tool to rapidly ship software solutions to the market, inspired by the famous Ruby on Rails framework, it brought Rapid Application Development to the Go Language. I say Buffalo, by far provides the best developer experience among other web development frameworks in Go, but I’m obviously biased by being part of the Buffalo core team. Buffalo’s existence has lead my team at Wawandco to deliver great apps within the last 2 years, and we are still delivering.
  • Larry Morales

    A fridge contains drinks

  • From my experience as a software developer, an issue that I have dealt when building an application are the dependencies for external services. A test with external dependencies where you don’t have much control can fail if there is a change in the service and the outcome is not the expected, with this in mind, we need to ensure the non-dependence of external services when running our tests. The most effective way to do this is mocking those dependencies.

    In this post, I will focus on the functional tests of an application. I will also talk about how to mock an external service to not rely on it when running our functional tests.

    To explain how to mock an external service, I’ll walk you step by step through an example.

    Let’s say that we have an endpoint, that is using a third-party package called holidays that is making HTTP requests to an external service to get such holidays.