Writing a Fuzzing API with Clojure’s test.check

I’ve written before about testing CSS using a fuzzing API. Having relied on my fake, random API over the last several months, I’m confident that it’s a tool I’ll use on all my future projects. Besides supplying the app with random data, it’s also given me an unprecedented ability to customize the fake API’s behavior and test unusual and hard-to-reproduce scenarios. In this post, I’ll walk you through the key components of my API and some ways that I’ve used it.
Read more on Writing a Fuzzing API with Clojure’s test.check…

Estimating Project Completion with Burn Charts

Micah has written before about using burn charts to track team progress. One of his tips is to use a project’s projected finish date to help the client understand what changes can or must be made to the scope and budget. I’ve long been curious about calculating when a project will finish, so after reading Micah’s post, I did some research.
Read more on Estimating Project Completion with Burn Charts…

4 Types of APIs and When to Use Them

Most apps today draw a strong line between the server and the client. The client, maybe a single-page web application or a native mobile app, focuses on the user-facing features, while the server provides the data and a way to update it. Atomic has done a lot of projects this way, and we’ve found it’s a solid way to decouple the core business logic and database from different platforms.

Decoupling the client from the server means we can use an alternative back-end instead of the eventual production server. Several projects I’ve worked on have used this ability to keep development on the client moving forward, even though the actual production back-end wasn’t ready yet. Ryan wrote about the benefits of fake APIs like this a couple of years ago. But there’s more to swappable back-ends than fake APIs. Different situations call for different servers with different powers.
Read more on 4 Types of APIs and When to Use Them…

How I Test CSS

At Atomic, we practice Test-Driven Development for all the code we can, from single functions to entire stacks. But there’s one kind of code we’ve long neglected testing: CSS. We rarely have coverage of it, and we often discover bugs and style regressions long after they were introduced. We’re not alone. Most software developers don’t do CSS testing. It’s tough to assert that a website looks the way you want.

I’ve wrestled with the problem of CSS testing for a long time, and I have two suggestions for catching style problems early. Read more on How I Test CSS…

Why is Your Team Falling Behind? Ask ‘The Penny Game’

One of the chief concerns of a software development team is managing work. We even have our own jargon—user stories, tasks, chores, bugs, epics, sprints—terms we use to help juggle assignments and stay organized.

But even a smart, hard-working team full of disciplined developers can fall behind, failing to meet deadlines and feeling overwhelmed by everything that needs to be done. To understand why work piles up like this, it helps to look at a different but similar industry: manufacturing. Read more on Why is Your Team Falling Behind? Ask ‘The Penny Game’…

Write More Maintainable CSS with Purple Prose

On a large project, CSS often becomes messy and difficult to maintain. Selectors get longer and longer, reaching deeper and deeper into the DOM. Properties override each other. Fonts and colors have to be specified for just about every element. And the dreaded !important begins to rear its head.

Before long, team tension is palpable. Fortunately, there’s a better way.
Read more on Write More Maintainable CSS with Purple Prose…

4 Tips for Thinking Functionally

I’ve written before about why I prefer a functional programming paradigm to an object-oriented one, but it’s taken a long time to get there. I dabbled on and off for half a decade before the core ideas behind Clojure and Haskell really sank in and I could write code in my head without having to sit at a computer.

My relationship with functional programming may have been slow, but it was punctuated by several key insights. These deeply altered my approach to designing code, even code in non-functional programming languages.

Here are four habits that dramatically shifted my thinking toward functional programming.
Read more on 4 Tips for Thinking Functionally…

A Shell Script for Working Step by Manual Step

While I prefer a project’s deployment process to be automated, some systems just aren’t made for automation. For instance, many content management systems are designed to be updated by a live user— someone manually selecting check boxes, filling in text fields, and clicking submit buttons. Often, all that configuration is stored in a complex format in the database, making it risky to update with a script. In the end, a manual process is not only the cheapest, but also the safest way to go.

But even though the process may be manual, remembering it doesn’t have to be. Read more on A Shell Script for Working Step by Manual Step…

Why I Choose ClojureScript

I’ve always enjoyed learning different programming languages. I’ve had colleagues who wished one language would emerge obviate all the others, but not me.

For me, programming languages are like food: it’s the variety that makes it fun. Every language makes different tradeoffs, they elevate different ideas, express them in different ways. Each is a unique tool in my toolbox. Read more on Why I Choose ClojureScript…

Read more on Why I Choose ClojureScript…