‘TDD’ Means Something Different at Lab Zero

Lab Zero uses a unique methodology that has roots in Test-Driven Development (TDD). In Test-Driven Development, you write the automated tests that will be used to test software before you write the code. So, in TDD, your first ‘success’ is to write and run a test that fails. After that, in TDD, you keep writing code until the test passes. Then you repeat until you have a passing test for every requirement. At Lab Zero, we have the same state at the end, but we don’t necessarily write our tests first. Rather, we write the tests as we go, and deliver code with all tests present. At Lab Zero, TDD stands for ‘Test Delivered Development’. This post is a hypothetical argument between a testing Skeptic and a Lab Zero Advocate of Test Delivered Development. We invite you to discuss.

Get Better Signal from User Testing

Delivering value to your customer is your primary goal. You want purpose to motivate your product; you want it to be sustainable and intuitive to use. The way to get it there is by talking to the only people who can assess that value. Those people are your customers.

Ten User Testing Ideas that Really Work

Whether you’re building a swingset in the backyard or coding a blockchain ledger for microtransactions, you’ll soon know the value of user testing. Sometimes just trying to find the users to talk to teaches you something that you can put into your product. Listening to the voice of your user is such a powerful thing--we think these ten ideas will help you start off on the right foot.

Mount Amazon EFS Drives Inside Docker for Simple Network Storage

At Lab Zero we ran into a use case a while back where we had some files that needed to be created and shared across Docker containers in the same EC2 Container Service (ECS) cluster. We typically use S3 for solving most types of shared storage situations, but in this case, we needed the storage to be mounted locally on each container instance. Thankfully Amazon Elastic File System (EFS) fit the bill. It provides elastic storage that can be mounted as an NFS drive with just a few simple steps.

Including a Device Tree Overlay in an Elixir Nerves Project

I’ve been working on a Raspberry Pi 3 and Elixir Nerves project that utilizes an additional piece of hardware attached through an SPI controller. In order to get this hardware recognizable in Raspbian, I had to include an additional device tree overlay with my Nerves firmware. Raspbian uses a device tree to manage resource allocation and module loading.[1] In order to make the kernel aware of our external SPI device, a device tree blob (DTB) that describes the hardware must be provided to the kernel on boot. While the process was pretty straight forward for Raspbian, I was left a little lost when it came to translating that over to a Nerves RPI3 system configuration. This was my first Nerves project, and I found the documentation was a little light in this area. (I have since updated the Nerves Advanced Configuration documentation to include information about device tree overlays.)

See More