humancode.us

Keep Your Commits Clean

January 26, 2018

Keep your commits clean. Address only ONE issue per commit. Make sure the project continues to build and run at each commit. Your future cherry-picking or reverting self will appreciate it.

PS: And no sneaking in small, unrelated changes to avoid a code review! You know who you are.

Embrace Conway’s Law

January 19, 2018

In a sufficiently large organization, embrace Conway’s Law. Create software that mimic organizational structure, or modify organizational structure to mimic software architecture. Any other arrangement leads to chronic friction.

As a corollary, refactoring of organizational structure can be a forcing function for refactoring software architecture. It may take time, but your software will eventually reflect your new organization.

#inadvertently

February 13, 2017

I made a topical cartoon. #inadvertently

Remembering 9/11

September 11, 2016

World Trade Center Twin Towers

Credit: Jeffmock CC-BY-SA-3.0

On this 15th anniversary of 9/11, I recall my most vivid memory of the events. I drove in to work at Honeywell Aerospace in Kansas City after watching the second aircraft crash into the Twin Towers on live TV. Partway through my drive, I saw something I’d never seen before or since: arcing contrails, all over the clear blue Kansas sky. It wasn’t after I got in to work that I found out that the FAA had grounded all aircraft in flight. Those contrails showed where aircraft turned around and landed where they came from.

We didn’t get much work done that day. Someone hooked up large screen TVs and we watched as the towers fell.

Keeping Things Straight with GCD

June 14, 2016

GCD Logo

This is the sixth and final post in a series about Grand Central Dispatch.

Long time users of GCD will tell you: it’s easy to forget where you are. Which queue am I on? Should I dispatch_sync to a queue that protects my variables, or has my caller taken care of that?

In this post I will describe a simple naming convention that has kept me sane over the years. Follow it, and you shouldn’t ever deadlock or forget to synchronize access to your member variables again.

Designing thread-safe libraries

When designing thread-safe code, it helps to have a library mindset. You should distinguish between the external or public interface (API), and the internal or private interface. The public API is presented in public headers, and the private interface is presented in private headers, used only by the library’s developers.

The ideal thread-safe public API does not expose threading or queueing at all (unless, of course, thread or queue management is the point of your library’s utility). It should simply not be possible to induce a race condition or deadlock when using your library. Let’s take a look at this classic example:

// Public header

#import <Foundation/Foundation.h>
// Thread-safe

@interface Account: NSObject
@property (nonatomic, readonly, getter=isClosed) BOOL closed;
@property (nonatomic, readonly) double balance;
- (void)addMoney:(double)amount;
- (void)subtractMoney:(double)amount;
- (double)closeAccount; // Returns balance
@end

@interface Bank: NSObject
@property (nonatomic, copy) NSArray<Account *> *accounts;
@property (nonatomic, readonly) double totalBalanceInAllAccounts;
- (void)transferMoneyAmount:(double)amount
                fromAccount:(Account *)fromAccount
                  toAccount:(Account *)toAccount;
@end

If it weren’t for the helpful comment, you wouldn’t be able to tell from this header that the library is thread-safe. In other words, you’ve defined thread-safety as an implementation detail.

Read more…