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…

Streams in node are awesome. I’ve heard one of the core node contributors say, “if you’re not using streams, you’re doing it wrong”. Why are streams awesome? I’m glad you asked.

• improve performance for large data sets—stream from source to response without buffering it all in memory
• improve perceived responsiveness—start responding as soon as any data is available, rather than waiting for it all
• clean service composition pattern—make a request to another service and stream its response back to the user, filtering or modifying it in some way in the process

However, streaming in node isn’t straightforward. This is more true with the introduction of Stream2, aka “new streams”, since module writers try to support both old and new streams.

I ran into this challenge the other day. After hours of debugging, I realized that mixing stream modes was the cause and I somehow stumbled onto a stupid simple solution. Continued…

Ever wonder about the best patterns for the design, deployment, and monitoring of cloud applications? This presentation describes the current best practices used at BrightTag. Its from a talk given with two colleagues last year at CloudConnect.

I was recently tasked with fighting spam coming from contact forms on a website that uses Salesforce web-to-lead feature.

The contact form in question had previously posted to another PHP page which checked for a hidden field with a known value and, if the received value matches the known value, emailed the lead to the team. This is a very basic but effective spam deterrent, as bots tend to change the value of the field. But then the form was redone to post directly to Salesforce with all the data Salesforce needs to create a lead. While this resulted in a much simpler lead-creation process, it also resulted in a lot of spam as the “spam detection” facility was no longer used.

As I was rolling up my developer sleeves to write a simple PHP proxy to do spam detection and then post from PHP to Salesforce, I stumbled on this bit of documentation from Salesforce on their web-to-lead feature:

Salesforce runs field validation rules before creating records submitted via Web-to-Lead and only creates records that have valid values.

Inspired, I decided to try a pure-Salesforce spam deterrent hack. Continued…

Over the last year, I’ve ran into a number of cases where refactoring led to a generic abstract base class that accepted its parameter type class in its constructor. Something like this-

public abstract class BaseClass<T> {
    private final Class<T> type;
    protected BaseClass(Class<T> type) {
        this.type = type;
    }
}
 
public class ConcreteClass extends BaseClass<String> {
    public ConcreteClass() {
        super(String.class);
    }
}

Note the duplication of the type in the generic parameter declaration and in the call to the superclass constructor. Sadly, this is the usual workaround pattern.

Until Guava, finding the parameter type of a generic wasn’t easy Continued…