Notes

Software is always challenging to explain to non-engineers and having a metaphor is valuable to explain complex concepts. Bridges happen to be a good analogy to software. But the devil is always in the details. Any piece of software provides a benefit to its users. It’s similar to people using bridges to cross rivers. As with bridges, many kinds of software can solve the same problems. Some bridges support many cars and pedestrians which is analogous to a high-throughput like a server that can support many users. Others are very nice walkways with trees, a highly usable piece of software that supports only a few users. Most of the time, users only see the bridge from the top. Like seeing only the tip of an iceberg. ...

What is simple? Rich Hickey makes a good abstract definition, but it can be difficult to translate to everyday code. I encourage you to watch that before returning to this. I’ll still be here. Ok, let’s start at that definition. Hickey’s simplicity is the disentangling of concerns. It’s easy to convolute from what seems like straight-forward statement. For example, a high-level example would be what domain-driven design proponents argue for. Separate solving your problem domain from the machinery that you use to solve it. Separate How from What or When. ...

It’s a bittersweet end to a chapter. I’ve thoroughly enjoyed my time at Pivotal Labs. I met a lot of great friends. I paired and talked with geniuses and newcomers alike. And I’d recommend anyone with an opportunity to work at Labs to take it immediately. I look back with great memories, shared termoil, and personal growth. As an introvert, it was a boundary-expanded endevor: pair programming every day. I learned the value of tests which is evident to most of the major open source work I’ve contributed to. I’ve sharpened my mind by the discussions I’ve had there. ...

It’s no secret that I’ve been interested in testing. Most of the work I’ve done are around example-based testing. While useful, it’s interesting to look at other communities for inspiration. I’m specifically fascinated in the functional programming community. Generative testing in particular. It was popularized in the early 2000s by a famous implementation in Haskell, QuickCheck. In short, generative testing is allows you specify properties your software should have. Then the testing library generates test cases. It’s an alternative path the functional community has taken when it comes to testing. This becomes evident since testing functional code becomes mostly boilerplate management: ...

Note: This previously was on Pivotal Labs blog. In the previous article, we used TDD to parse JSON into our Person model and refactored the code under test. In part 2, we’re going to refactor the code further to be more reusable and extendable. All the code in this article will also be in the same repository. Redesign The refactorings in the previous article were fairly straightforward and mechanical. Ultimately, we’ll need to break apart different concerns of this code. One approach would be to start with some questions: ...

This post was original written on the Pivotal Labs Blog. JSON parsing is a frequent task for clients interfacing with any recent web API. Those web services frequently vary in quality: Is the API following a RESTful design pattern? Is it providing an object graph or just a single/collection of objects in the JSON response? What are the data types of the fields being returned? Can they be relied upon? How much work are clients duplicating to work around the server (e.g. - Performance, Business Logic, etc.)? If you have full control of the resulting API endpoints, then it is easy to build or fix the API to your client’s specific needs. Controlling the incidental complexity can be challenging for APIs you do not control, or which have to support a variety of clients. ...

Languages that have dynamic introspection provide powerful meta-programming capabilities. This is generally done at runtime with additional memory used for storing metadata - such as types and method signatures. But they also provide the same power for people reverse engineering your code. Let’s look at Objective-C, a simple code snippet: @interface MyObject : NSObject @end @implementation MyObject { NSInteger _number; } - (void)doSomething { _number++; NSLog(@"The %@", [self _doSomethingSpecial:_number]); } - (NSString *)_doSomethingSpecial:(NSInteger)number { return [NSString stringWithFormat:@"Number: %d", number]; } @end Simple enough, but what if we don’t have the source? Let’s step back to how Objective-C works… ...

It’s great to use classic algorithms to solve problems at hand. Take this problem of ellipsis: For a given text. Fit the maximum number of words that fits in the given size, append “… More” if there was truncation. No, NSLineBreakModeTailTruncation will not work. We need different text. The näive solution would simply to cut a word one-by-one until it fits with a custom ellipsis text: @implementation NSString (CustomEllipsis) - (NSString *)textThatFitsSize:(CGSize)size ellipsisText:(NSString *)text { CGSize infiniteSize = CGSizeMake(size.width, INFINITY); CGSize fullSize = [text boundingRectWithSize:infiniteSize options:NSStringDrawingUsesFontLeading|NSStringDrawingUsesLineFragmentOrigin context:nil].size; // if text fits if (fullSize.height <= size.height) { return text; } NSString *finalString = nil; // if text doesn't fit NSMutableArray *words = [[text componentsSeparatedByString:@" "] mutableCopy]; while (fullSize.height > size.height) { [words removeLastObject]; finalString = [words componentsJoinByString:@" "]; finalString = [finalString stringByAppendString:@"... MORE"]; fullSize = [modifiedString boundingRectWithSize:infiniteSize options:NSStringDrawingUsesFontLeading|NSStringDrawingUsesLineFragmentOrigin context:nil].size; } return finalString; } @end Run that in a table cell and you’ve got performance problems! ...

Every time you look at a new (or familiar) technology. You should ask: What are the tradeoffs? It’s obvious to see the benefits of something - it’s generally advertised everywhere. Everyone is always shouting the the pros of X. “X does Y easier” “X does Y faster” “X integrates with Y” Pros tend to flood the internet way more than cons: X makes Z harder X makes Z slower X locks you into Y X does Y, at the expense of Z These are harder to find. Especially when the library is relatively new. But you can imagine based on how critical it is on your software stack. ...

Lazy data structures are a powerful abstraction can increase the readability of your program while encouraging separation of concerns. What are they? Simply put, they are data structures that “realize” what they contain when they’re needed (or right before they’re needed). What can you do with lazy data structures? How about a page-scraper that paginates as needed: # pseudocode seed_url = "http://example.com/page/" # generate a lazy list of urls: # - http://example.com/page/1 # - http://example.com/page/2 # - etc. urls = lazy { for (i = 0; i < 100; i++) { yield seed_url + string(i) } } # a lazy list of html pages pages = map(urls, fetchURLPageContents) # a lazy list of list of links links_per_page = map(pages, extractLinksFromHTML) # flatten to just a lazy list of links links = join(links_per_page) # do stuff with links for link in links { record(link) } This creates a powerful abstract that separate tasks your program needs to get done behind an implicit interface. The ending for loop doesn’t need to know that those links came from multiple page fetches or the file system. If the loop short-circuited, then it minimizes the number of unnecessary fetches. ...