We're hiring!

We're actively seeking designers and developers for all three of our locations.

theft: Property-Based Testing for C

Recently, I discovered a bug in my heatshrink data compression library, a result of a hidden assumption — I expected that input to uncompress would be padded with ‘0’ bits (like its compressed output), but if given trailing ‘1’ bits, it could get stuck: it detected that processing was incomplete, but polling for more output made no further progress.

Under normal circumstances this wouldn’t happen, but hostile input shouldn’t get libraries stuck in an intermediate state or make them waste their callers’ resources. Also, since flash memory is often subtractive (erasing to all ‘1’ bits and writing by clearing bits to ‘0’), if compressed input was being passed to it a page at a time, it could end up with trailing 1 bits from the remaining memory.

I found and fixed the root cause, but since I was also working on theft (a property-based testing library for C), I wondered if it would have found that edge case for me. I wrote a property test saying that, “for any input, getting all available output and then checking whether it was finished should indicate that it is done”: Read More »

Posted in C & C++ | Tagged , | Leave a comment

Property-Based Testing – Testing Assumptions You Don’t Know You’re Making

property-based-testing

Finding good test input can be tricky. Even with loads of unit tests, bugs still get through.

Consider a wear-leveling algorithm for flash memory — it takes a series of write operations and spreads them over the flash, because individual blocks can only be written and erased so many times before they wear out. If any write sequence leads to writes concentrating in specific blocks, something isn’t working.

While dozens of tests could sufficiently exercise the algorithm’s boundary conditions, actually finding them all can be as difficult as correctly implementing the algorithm in the first place. These tests would also be overly coupled to the implementation, adding a maintenance burden if implementation details change.

The important thing isn’t that those tests’ examples continue to work, but that the algorithm works in general. Besides, it’s easy to check if the wear leveling works for any particular input — have a test mode that updates per-block write counters but doesn’t actually write, feed the input to it, and check if the counters are updating evenly. Why not just generate input and let that find the edge cases?

Similarly, many bugs result from incorrect assumptions, rather than failing to accurately implement a design. Developers writing tests for their own code usually leads to code and tests with shared expectations, so input that “shouldn’t” happen but is permitted by interfaces and types can often uncover bugs.

But how do you write tests for assumptions you don’t know you’re making? Read More »

Posted in Development Practices, Uncategorized | Tagged , | Leave a comment

Atomic’s Micah Alles Joins Local Orbit as CTO

Local-Orbit-Micah-Alles

In a unique partnership between Atomic Object and Local Orbit, a thriving Ann Arbor startup, I’m excited to announce that I’m joining Local Orbit as their CTO!

Local Orbit’s small, brilliant, motivated team is dedicated to helping people build profitable businesses and healthier communities. They provide people who are building the New Food Economy the platform and tools they need to do their work. Local Orbit’s software platform connects buyers and sellers of local food with shorter, more transparent supply chains. By organically connecting multiple local food hubs, buyers, and sellers in an emerging market, we are supporting entrepreneurs who rely on Local Orbit to run their businesses. Real people, getting real value, from a cutting-edge platform.

While I’m dedicated full-time to shaping and building an engineering culture and team at Local Orbit, I won’t be leaving Atomic Object. As partners, Atomic Object is invested in the long-term success of Local Orbit. And my connection to both companies will give me the tools to combine the strengths of both to meet the needs of an emerging market in the New Food Economy.

With my leadership as CTO, Atomic Object and Local Orbit are working together to create a product development culture and environment that will build and extend the Local Orbit platform–think Atomic Object, but as a product company. I’ll be bringing the best of Atomic’s tools, processes, practices, lessons, and culture to bootstrap and build a team of new Local Orbit developers with the help of a few senior Atoms.

We’re looking for new Orbits to join the Local Orbit dev team this fall. If you’re interested in working for a product company with the tech culture of Atomic Object, keep an eye on our blog for more information soon.

Posted in News & Events | Leave a comment

My Internship Experience

AOGR Q2 Party

The first time I heard about Atomic Object, I was back home in Iran. I was browsing a Pry gem webpage to see if I could find a substitution for my good old debugger gem. I saw the name “Atomic Object” on the gem’s sponsor list. I thought to myself “hmm — cool name! Atomic Object”.

Later, after moving to the United States to pursue my Masters in Computer Science at Grand Valley State University, I heard about AO lots of times. The company was famous among faculty members for promoting a unique culture and sticking to Agile principles. They had a good reputation in the Agile world as well. Read More »

Posted in Growing as Makers | Leave a comment

Software as a Journey – My Favorite Development Metaphor

software-journey

What do Film Making, Manufacturing, Construction, A Television Sitcom, Time Travel, and Oyster Farming all have in common? They’re all metaphors for software development (thank you Naresh Jain for your post on Software Development Analogies). Although there are a lot of software analogies out there with varying degrees of relevance to the situation at hand, it seems few people are as fond as I am of the Software as a Journey metaphor.

Into the Unknown

For those of you that aren’t aware of it, this analogy likens software development to a trip across unknown terrain. As your journey progresses, you run into obstacles that you never anticipated such as mountains, rivers, deserts, or oceans. In software creation, these could be considered analogous to political limitations, interoperability problems, communication barriers, or any other roadblock that confronts you during the course of a software project. A nice illustration of the analogy can be found here. Read More »

Posted in Project & Team Management | Tagged | Leave a comment

Marionette.js Behaviors, Part 2: Testing Behaviors

This post is a follow-up to Al’s high-level introduction to Marionette Behaviors, published yesterday. As Al said, Marionette.Behaviors are an abstraction for sharing UI code between different views. They are a recent addition to the Marionette toolbelt (added in version 1.7). Prior to the introduction of behaviors, code sharing between views in Marionette had to be handled at the Javascript language level with inheritance or by delegating to external modules.

The Challenges of Testing Behaviors

Behaviors offer an awesome abstraction, but they exist only as a mix-in in the context of a view, which offers some challenges when it comes to testing:

  • Testing a behavior independently of a view is challenging – Behaviors are tightly coupled to views with listeners and callbacks, which means testing them in isolation requires a lot of setup and doesn’t add much value. Read More »
Posted in Web Apps | Tagged , , | Leave a comment

Marionette.js Behaviors, Part 1: The Basics

Part 2: Testing Behaviors is available here

Marionette is a Javascript application framework built on top of Backbone. It provides great features missing from core Backbone like collection views, subview management, and abstractions for building event driven applications.

Extracting Duplicate Code with Behaviors

Marionette.Behaviors are an abstraction for sharing UI code between different views. They are a recent addition to the Marionette toolbelt (added in version 1.7). Prior to the introduction of behaviors, code sharing between views in Marionette had to be handled at the Javascript language level with inheritance or by delegating to external modules.

Behaviors are designed to be loosely coupled and injectable. A behavior knows about the view it is injected into, but the view does not know the details of the behavior. This helps to keep behaviors abstract and reusable between views. Lets take a look at a couple simple Backbone views and how they could be refactored using Marionette behaviors. Read More »

Posted in Web Apps | Tagged , , | Leave a comment

5 Ways to Maximize your NewCo Festival Experience

This post was also published on the NewCo Detroit blog.

atomic-object-detroitOn September 18th, Atomic Object will be a host company for the 2014 NewCo Festival. We will be showcasing our cool Detroit location, providing an overview of what makes Atomic unique, showing off some of the products we’ve developed, and serving coffee, tea, and bagels to help get your day started.

Were excited about having visitors in our space. We also participated in this festival in 2013 and enjoyed being a part of it so much were doing it again this year. Our goal this year is to help our visitors better understand the role Atomic Object plays in turning an idea into a product. Read More »

Posted in Growing as Makers | Leave a comment

Why You Should Never Use the Word “Obviously”

obviously

One of our core values at Atomic is Teach and Learn. This belief is evident in many different aspects at Atomic, from the external (presenting and attending conferences) to the internal (setting up brown bag presentations and weekly cross-team design reviews). It is also clear in the day-to-day work, like pairing and problem solving as a unit instead of as individuals.

As I’ve spent time learning and listening to the great teachers we have at Atomic, I’ve noticed one word missing from nearly everyone’s vocabulary: “obviously”. Read More »

Posted in Culture | Tagged , | Leave a comment

3 Reasons You Shouldn’t Ask Us to Sign your NDA

nda-harmful

Nondisclosure agreements are legal contracts that limit one or both parties from disclosing information covered by the NDA. They can be used to protect trade secrets, business plans, customer lists, sources — in short, pretty much any aspect of business. They tend to be short and are readily understandable by non-lawyers.

You may be surprised to find that Atomic Object usually doesn’t sign NDAs at the first stage of a potential relationship. We don’t do this entirely from our self-interest, we just think that you don’t really need one, and you’re better off without one. Read More »

Posted in Choosing Your Team | 2 Comments