Recently, we rebuilt Atomic’s SVN server. We wanted to upgrade to the latest Ubuntu LTS release and also wanted to manage the server with Chef. Provisioning the server and bootstrapping it with Chef was straightforward. However, actually preparing the server for hosting our SVN repositories and migrating all of the data posed some challenges. I was reminded some useful commands, techniques, and learned how to fix some problems.
Unlike git, which allows us to clone a new bare repository from any existing one, SVN repositories must be exported or ‘dumped’ to a portable format (called a ‘dumpfile’), transferred to the new location, and then loaded into a new, empty repository.
Even after 10 years, I find I occasionally need a reminder to check all the obvious things when something goes wrong.
I just spent about a day debugging an issue with tests hanging, but only on one machine under continuous integration. The other machines were all fine. I assumed one of my tests was just broken: maybe I was polling for an update in the UI forever or something like that.
I definitely took the long way around trying to debug things. I analyzed which tests were running and how far each was getting by adding print statements that I could view in the CI output. I searched out all the tests that triggered events, just in case my mock event handler was doing Something Strange. Read More
At Atomic, we currently have 4 designers. Our small (but mighty) team is working to continually evolve and improve our team practices and rituals. We’re in the process of evaluating and possibly revamping some of our design rituals, in fact. As of right now, we have a few things that we’re practicing:
Show n’ Tell
Once a week we reserve an hour to share work. This can be used for formal critique, but is also a time to simply share what we’ve been working on. An hour normally gives us time to review 2-3 pieces of work, depending on how complicated the work is. Previously, this time block was used purely as critique, but we altered the time to be more of a come share with the team time. Read More
Pre-project consulting. Sounds expensive, doesn’t it. Well… it is. But your project is worth the time investment, and Atomic is willing to pick up the consulting tab.
Getting to Know You & Your Project
When discussing your project with Atomic, you’ll meet with members of our Upfront Team — technical professionals with years of real project experience.
We’ll kick off pre-project consulting with a conversation that’s geared towards getting to know each other. We want to understand what your company does, your role in the organization, and the challenges you are facing. We also want you to be comfortable with Atomic and the our way of doing things. Read More
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
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
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, then apply here!
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
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