We don’t have to tell you that the world of technology is an ever-evolving landscape of ideas and concepts, and that even when you have a firm intellectual grasp of a technology this knowledge can quickly become outdated. With this in mind, we thought we’d readdress one of our blog posts from 2015 with a fresh, 2018 perspective.
Test Driven Development is the practice of writing a test for a piece of required functionality, before writing any implementation code. This test should fail when first run, and then, you write the code to get it to pass. It doesn’t have to be the most perfect code, just so long as the test passes. Once it does, you can then safely refactor your code.
Most applications you write rely on certain data stored in a database that is essential for it to work. That data defines your business logic as much as the code. That data should be represented in code. In this post I’ll discuss how we handle migrations and seed data through our Continuous Delivery pipeline at Made.
As Benjamin Franklin once said, time is money, and for an e-commerce website every millisecond counts. Page speed is a common sticking point for most solutions out there, so in this article I’m going to describe 3 practical ways you can decrease your page load time.
At Made we pride ourselves on crafting websites that deliver a great aesthetic, and a rich user experience.
Many studies have been conducted in an attempt to formalise the quality of software. Some quality models have been established, like SQuaRE by Consortium for IT Software Quality, which takes into consideration 5 key points: Reliability, Efficiency, Security, Maintainability and (adequate) Size.
Here at Made Tech we’re big fans of Ruby and use Ruby on Rails for most of our web applications. Over the years we’ve had countless conversations about the pros and cons of Ruby.
We build rich websites at Made. In production, the SCSS we write is precompiled, minified, gzipped, and served from Amazon S3. However, in the development environment we’re without any of this magic, and the rails app server can sometimes feel like it’s ground to a halt.
Before joining Made, my experience with unit testing was always with PHPUnit. It’s very flexible in allowing you to write tests quickly; create a class, add some methods that start with test, include some assertions, and away you go. What I don’t think PHPUnit—and similar—allow you to do well is think about how to structure your tests, and what to focus them on. For that you have to rely on experience and good discipline.
We love writing tests at Made HQ. They are part of the foundation on which we work to provide our clients with stable deliveries. We work fast and deploy daily so we test vital paths of our applications using feature tests. We also unit test, albeit less, when we need to cover a range of edge cases.