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

Customizing Jira for Agile Teams—The Lab Zero Way

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. 

Announcing Bootleg: Simple deployment and server automation for Elixir.

At ElixirConf 2017 we began getting the word out about Bootleg, a project we've been working on for most of this year in-between our normal Lab Zero client work. So what is Bootleg exactly?

Lunch: From Instance to Service

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.

The Quest for Better Tests

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

See More