1. Too many open files

    Error: EMFILE, Too many open files

    If you work with NodeJS on the Mac, you will eventually hit some build-in I/O limits of the operating system. The default maximum number of file descriptors in Mac OS X 10.6 was 256.

    You can find the user limits from this command:

    $ ulimit

    My response was “unlimited” However, if you add the -n parameter (max number of open file descriptors), it will return the current setting. The default was 256.

    The Fix: Raise the Limit

    $ ulimit -n 2560

    Being ten times the default, this fixed my issue of having a lot of components being required from cache.

    Why So Much I/O?

    Raising the limits could be a smell that your application is doing too much I/O. Ideally, we should address the underlying cause of running-out of the file descriptors in the first place. But with the rise of modular, component-style apps (like npm) you need to handle potentially hundreds of tar and gzip files very quickly. Isaac Schleuter has a great post on how this has been dealt with in the NodeJS community.

    My take is that npm isn’t going away, so just raise the limit.

  2. Use Git Hash for Versioning

    We want to ensure that the most current version of our stylesheets is the same one that’s in our latest build. A common way to do this is to compare the hashes of a particular file that was changed.

    The problem is that any one of several stylesheets could have changed, and we need to detect this automatically. This is already being done because we use git for version control. The trick is to grab the hash of the latest change, and include it in our stylesheet build. 

    The below excerpt is from a bash script that is part of our publishing flow. And it’s based on this super-handy git command: rev-parse. We pass the HEAD parameter, because that’s the revision that we’re most interested in.

    #Returns the latest hash

    VER=$(git rev-parse HEAD) 

    #Overwrites the version file with the hash in a single CSS comment.

    echo “/* $VER */” > $LATEST_BUILD_PATH/version.css

    We get a new, unused version.css file in the directory with our compiled CSS files, so it will get deployed with the rest of them. Now we know exactly which version of the styles are deployed at each phase of the publishing process. 

    This has helped us track-down errors in the entire build process from local environments to github to artifactory to build servers to the CDN. 

  3. LayerVault Blog: PSD.rb →

    Unlocking the  Photoshop Document!


    The Photoshop file format is over 23 years old, yet it remains one of the most opaque file formats out there. PSDs are very widely used, yet Adobe has never produced an easy way for developers to work with the format. Indeed, some developers have gone mad trying to parse PSDs. We know the…

  4. TJ Holowaychuk: Stylus vs SASS vs LESS error reporting →

    Stylus currently has the best error messages of the stylesheet preprocessors.


    I was curious what SASS did as far as error reporting goes, so I tried the following snippet with SASS, LESS as well as Stylus.

    body { form input { background: foo[fail]; }


    The output from LESS was terrible:

     Syntax Error on line 4

    note: that for LESS I had to tweak the…

  5. Deleting (Mac OS) X Attributes

    There is an interesting “feature” in Mac OS X that afflicts the recent releases: SnowLeopard and Mountain Lion (I am running 10.8.3, build 12D78). Whenever you download something from the Internets, it places places an OS attribute of “com.apple.quarantine” on the file. 

    You can see this on the file by running the ‘list - all, by line’ command from your command line. 

    $ ls -la

    Note that the file has next to no permissions (600) and that extra “@” by it. The ampersand indicates that this file has x-attributes. To see what attributes it has run the ‘X attributes’ command:

    $ xattr <filename>


    The “com.apple.quarantine” is the most common attribute that I encounter. Now, to delete the attribute just run ‘X attributes, delete this attribute from this file’ command. 

    $ xattr -d com.apple.quarantine <filename>

    I used to do this so often that I made an alias for it. This goes into your bash profile (~/.bash_profile).

    alias “xdq”=’xattr -d com.apple.quarantine’ 

    Meh. But I what I really wanted was to create a script that would read the x-attributes, and then delete each oneAnd then I wanted to alias the script so that I could use it like a command. This was not a great idea.

    And that’s how I learned about bash functions!

    So it came down to using ‘xargs’ (a traditional bash command not affiliated with OS X) to return the list of attributes from the first xattr call as parameters to the second xattr call. This also goes in your bash profile. 

    function xattrd() {

         xattr “$1” | xargs -I {} xattr -d {} “$1”;

    export xattrd


    $ xattrd <filename>

    It works! But for one file only. 

    Most recently, I had to download a JBoss server from SourceForge. Every file and every directory was quarantined. It would take forever to remove them all! I needed to make this function somehow work recursively on directories and handle both single and multiple filename input. 

    First, added check for input (if statements). Evaluate the first argument, and see if it has content.

    if [ -n “$1” ]

    Second, got the “then” clause working for one <filename> input. Similar to existing function. Printed a line that states it’s just working on one file. 

    Third, got the “else” clause working with ‘while’ for multiple <filename> inputs. Used a while statement. Printed the multiple files that it’s working on. 

    function xattrd() {

            if [ -n “$1” ]



                    xattr “$IN” | xargs -I {} xattr -d {} “$IN”

                    echo “Cleaned one file: $IN”


                    while read IN ; do

                            echo “read $IN”

                            xattr “$IN” | xargs -I {} xattr -d {} “$IN”




    export -f xattrd

    Single usage: 

    $ xattrd <filename>

    Finally, to get it running for multiple commands, you have to accept a list of arguments. The best way to do that is by using the ‘find’ command in combination with the ‘execute’ parameter. This will take every result from the search and run a built-in command on it.

    The problem is that I want to call my function, not a built-in command. This is were you can have bash evaluate a string as a command. It will read a custom command from a string. The arguments are passed as parameters and evaluated within the double quoted braces. 

    Multiple usage:

    $ find . -exec bash –c ‘xattrd “{}”’ \;

    And this baby works recursively because find is recursive!