I just finished reading Release It! by Michael T. Nygard. Unfortunately, however, I didn’t learn about circuit breakers until the app featured in the “Intro to Streams” series (part 1, part 2) was complete. Let’s walk through the streaming example again and add a circuit breaker to protect the integration point. Continued…

I just started learning how to write my own Cocoapod yesterday. There’s a great tutorial to get you started. However, I ran into an issue when trying to lint my new spec. It looked like this:

$ pod spec lint MyAwesomeLibrary.podspec
 
 -> MyAwesomeLibrary (0.0.1)
    - ERROR | [iOS] [xcodebuild]  2013-05-29 23:03:08.370 xcodebuild[91499:3f03] error: Error Domain=NSPOSIXErrorDomain Code=2 "Non-zero exit code 255 returned from shell command: /usr/bin/gcc-4.2 -v -E -dM -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk -x objective-c -c /dev/null 2>&1" UserInfo=0x4001c4e60 {NSLocalizedDescription=Non-zero exit code 255 returned from shell command: /usr/bin/gcc-4.2 -v -E -dM -arch armv7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk -x objective-c -c /dev/null 2>&1, NSLocalizedFailureReason=No such file or directory}
    - ERROR | [iOS] [xcodebuild]  2013-05-29 23:03:08.457 xcodebuild[91499:3f03] error: Error Domain=NSPOSIXErrorDomain Code=2 "Non-zero exit code 1 returned from shell command: /usr/bin/gcc-4.2 -v -E -dM -arch armv7s -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk -x objective-c -c /dev/null 2>&1" UserInfo=0x4018946a0 {NSLocalizedDescription=Non-zero exit code 1 returned from shell command: /usr/bin/gcc-4.2 -v -E -dM -arch armv7s -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk -x objective-c -c /dev/null 2>&1, NSLocalizedFailureReason=No such file or directory}
 
Analyzed 1 podspec.
 
[!] The spec did not pass validation.

Continued…

Update 2020: a kind contributor has transformed the original blog post into an sslcontext library. He also shows how to configure SSL in the top dozen HTTP clients in Java.

Now that we know how to use multiple SSL keystores in Java, how do we configure Apache HttpClient (embedded in Apache Camel) to use them? This is useful if you want to load additional keystores in addition to the “factory” installed ones, for example. There’s no obvious way to do this using HttpClient or Camel. If you look at any of the documentation online, you’ll either see configuration via the JSSE configuration utility, like so: Continued…

This is the last part in the Intro to Streams2 series. If you haven’t read Part 1 yet, you should. The examples here build on the ones presented there.

Part 2 is about design patterns for streams. Design patterns help us write clean code, like this.

function publish(data) {
  data
    .pipe(config.formatter())
    .pipe(config.connector())
    .on('error', function(err) {
      self.emit('error', err);
    })
    .on('success', function() {
      self.emit('success');
    });
}

Continued…

Update 2020: a kind contributor has transformed this blog post into an sslcontext library.

For communication between internal services at BrightTag, we use self-signed certs on both the client and server. Simple and cheap (free!). Most of the time, these services only communicate over HTTPS with other internal services, so its been fine to use our own keystore; we didn’t need access to the “factory” certificates anyway. However, I ran into a case last week where I needed to be able to talk to both internal and external services and realized there’s no simple way to use multiple keystores in Java. We wanted to use both the standard JVM keystore and our custom keystore. The cleanest solution I found was to write my own CompositeKeyManager and CompositeTrustManagers. Creating a new keystore with both the standard JVM certs and our custom certs was also considered, but ultimately we didn’t want the responsibility of updating the standard certs in a bundled keystore.

Continued…

There’s a saying among the core Node contributors: if you’re not using streams, you’re doing Node wrong*. So I spent last week learning the new Node streaming API (“streams2″) while building a small node app. While the documentation is pretty good, there’s not a lot of examples that are both realistic and easily digestible.

This two-part tutorial aims to build on the DailyJS’s Five Minute Guide to Streams2, providing real use cases for each of the different types of new streams (part 1) and the application of more complex design patterns to streams (part 2). Continued…

Shell scripts aren’t known for being the cleanest, most elegant part of your technology. But I argue that, as a vital piece of your stack, they should be afforded the same thought and care as other parts of your codebase.

Sure, shell scripts like bash have some inherent limitations, but they shouldn’t prevent you from following standard software engineering principles.

For example, bash functions can’t return values, but functionality should still be broken into small reusable chunks each having a single responsibility. Just call the function in a subshell and have it echo the result. Or use a standardized return value. Plus, you can easily take advantage of the return codes of invoked programs.

Consider this simple script for generating a random alphanumeric identifier that’s unique across a group of files within a folder Continued…