Did you ever hear somebody talk about a tool they loved? Or a tool they hated? Here are some quotes from knowledge workers about when they ran into conflict with the tools they used. Here’s Carlton, a design lead:
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.
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.
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.
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.
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. 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.)
Software projects take effort to manage; that’s indisputable. In order to ensure that we’re spending our time in the most productive way, we make sure that the tools we use to help manage our projects are lightweight and focused on tracking useful information. Our development team usually prefers Pivotal Tracker and our design team likes Trello. No tool is perfect, but these two seem to have the right balance of flexibility and ease-of use while providing visibility into a team’s progress toward a goal.
Over the past year, we’ve been using my app, Lunch, almost every day to decide from a plethora of downtown SF restaurant choices. I made it as a fun little tool to teach myself new technologies, but it ended up becoming a routine — a sort of mainstay of our company culture.
Over the past twenty years, I’ve written my fair share of unit tests, mostly just covering the happy path and sending in some bogus inputs to test the edges. Typically following a fat-model-thin-controller method (often recommended by me), I failed to understand the point of integration tests. I tried TDD at the beginning of several greenfield projects, but I was never successful in making it sustainable. Similarly, with Selenium, it worked at first but quickly proved to be too brittle to keep up with rapidly changing UIs. (In retrospect, bad CSS architecture on those projects probably deserved the blame more than Selenium per se.)