A Comparison of 5 Uniprocessor OS Scheduling Policies

In my recent post on Uniprocessor OS Scheduling Policies, I covered the algorithms for five short-term operating system scheduling policies:

  • First-come-first-served
  • Round robin
  • Shortest process next
  • Shortest remaining time
  • Highest response ratio next

But I didn’t compare, analyze, or go over the use cases for each policy. I would like to do that in this post. Note that the concepts covered in my previous post are required to understand this one.

Read more on A Comparison of 5 Uniprocessor OS Scheduling Policies…

Sticky Documentation, Part 2: Source Control History as Documentation

Last week, I introduced a concept I’m calling “sticky documentation” and reviewed a few ways that we can make the most of the “stickiest” documentation we have: the code. Today, I’d like to talk about another form of “sticky” documentation: source control history. Read more on Sticky Documentation, Part 2: Source Control History as Documentation…

Specifying the Destination of an Unwind Segue Programmatically

I once wrote an iPad app to help people take self-guided tours through a museum. One of the interesting parts of this application was that many of the views were implemented by the same view controller. The functionality of each screen remained the same with slightly different assets in each view. This would be a problem if I needed to Unwind to certain screens in my application.

Read more on Specifying the Destination of an Unwind Segue Programmatically…

Sticky Documentation, Part 1: Code as Documentation

I support and maintain a variety of applications in production. Some of these applications consist of what might be considered “legacy” codebases. When troubleshooting issues with these applications, detailed and accurate external documentation is not always available. I often find myself acting as a code archaeologist, reliant on only the contents of the source code repo to get to the bottom of a thorny problem. Read more on Sticky Documentation, Part 1: Code as Documentation…

Using Reflection to Test Complex Objects

“Looking back” by Susanne Nilsson, licensed under CC BY-SA 2.0

Having code with automated tests keeps our quality high and makes us more efficient. But some code can challenge that efficiency—when code is simple in function yet complex in structure, making minor structure changes can be problematic. We don’t always completely think through the impact of those changes, sometimes accidentally leaving pieces of functionality untested and creating bugs. Thankfully, there’s a way to reclaim that efficiency and maximize our test coverage. Read more on Using Reflection to Test Complex Objects…

autoclave: A Pressure Cooker for Programs

I’ve been working on a multi-threaded, distributed system, and there have been some bugs that only manifested when things lined up exactly right. While the project’s deterministic elements have lots of unit and system tests, every once in a while mysterious failures have appeared.

On top of the other tests, the code is full of asserts for numerous boundary conditions, and stress tests intentionally overload the system in several ways trying to see if they trigger. While the system is generally stable, every once in a while something has still happened due to unusual thread interleaving or network timing, and these issues can be extraordinarily difficult to reproduce. Read more on autoclave: A Pressure Cooker for Programs…

Setting Up a Project Workspace in Tmux

As a developer, I spend a lot of time working in the terminal. Besides starting long-running daemons such as web servers in the terminal, I also use Git, Vim, and other command line tools throughout the day, and terminal sessions tend to pile up. On any given day, I can have more than a dozen terminal sessions open at a time, and that’s just for one project. Read more on Setting Up a Project Workspace in Tmux…

Read more on Setting Up a Project Workspace in Tmux…

What Does Good Code Look Like?

I’ve been helping out with interviews recently at Atomic, and one question I tend to ask candidates is: “What does good code look like?” I thought that this would be a softball, a question that any candidate with a love of the craft would breeze through. What I’ve found is that even developers who write really beautiful code often don’t have much of a response to the question. So here’s mine, in four points. 

Read more on What Does Good Code Look Like?…

Custom Animation for an Unwind Segue

On the first post in this series, someone left a comment asking, “What do you do if you want a custom segue transition for the unwind?” I thought that was a great topic to cover since most people only worry about the transitions going forward on a navigation stack and don’t think about how to transition when you unwind several layers back.

Read more on Custom Animation for an Unwind Segue…

Intro to Refactoring: Making Code Easy to Understand in 4 Steps

Refactoring is the process of organizing code to make it more readable and maintainable. There are a few steps you can take to refactor your code, if you don’t know where to start, or if you feel overwhelmed here are some ways to start. The goal is code that is easy to read and understand. Read more on Intro to Refactoring: Making Code Easy to Understand in 4 Steps…