DocRipper 0.0.7 Release: .sketch files are now tap

Release Notes:

A brand-new version of DocRipper has been released to the wild. This will be the first release of several upcoming releases that will bring support for new file formats in DocRipper. The goal is to maintain a limited set of dependencies and where necessary only add dependencies that provide a high level of performance.


  1. .sketch files are now supported! All text content (text labels, artboard labels and layer labels) are returned as a concatenated string. I’ve kept the parsing simple to avoid breaking changes and conform to the spirit of DocRipper’s mission to simply grab text from files.
  2. Cleans up module namespacing internally

Parsing Sketch Files

Extracting text from .sketch files proved to be an interesting excercise and required a couple of levels of digging into this proprietary format:

  1. Sketch files are sqlite3 databases Thanks to this SO question, I was able to read .sketch files using Ruby’s sqlite3 adapter. Sketch files contain a single payload “blob” which requires additional parsing.
  2. Binary Plist The payload blob turns out to be binary plist which I was able to parse using CFPropertyList. The plist contains an array of objects that are parsed to build the sketch file. The array appears to contain flattened references with several objects (string, uuid, dictionary) sometimes describing a single “sketch” object. Finding text references was a matter of identifying the text objects in this array. I ultimately found that using a black list to remove non-text objects was the practical solution in this case. I could not identify a consistent “rule” or class identification for text labels in this object list. I hope to re-examine this approach in the future.

Find your PostgreSQL database Datestyle

Sometimes you need to find the expected format of dates in your PostgreSQL database. You can find the database’s default style using your psql console:

#Log into the postgresql console

#connect to your database
\connect your_database_name

#interact with your database
show datestyle;

Sublime RubyTest Shortcuts

Run entire Rspec File

Run specific test or block (where cursor is selected)

Encapsulation patterns in AngularJS

Providing public and private design patterns in Angular.js

The concept of Encapsulation is an important design pattern in most object-oriented programming designs. Determining which properties and methods should be accessible is a nice forcing function because it forces the programmer to think about how his or her could will be consumed.

If you’ve spent any time in the world of Javascript, you probably know that Javascript does not provide native support for defining public or private interfaces.

If you haven’t explored Javascript encapsulation in the past, encapsulation is most often used in Javascript Constructor functions which operate a bit like class definitions in Classical inheritance using the new Object() constructor pattern.

Encapsulation is typically achieved by defining local variables within the function object. These locals can only be referenced by other functions defined on the function object.

You can find a more detailed exposé of encapsulation in javascript here.

What about AngularJS?

Angular provides a number of ways to create javascript singleton objects that are available via dependency injection. Depending on who you talk to, it’s a bit of a mess. At the end of the day though, AngularJS is just javascript and we can build encapsulation into our Angular factories and services using the same types of patterns.




I find myself thinking a lot about what should be exposed publicly in my view controllers. As a beginner, it’s easy to just attach your functions and variables to $scope (or this if using `controller as` syntax) and call it a day. But do you really need your view to have access to all of those functions? In most cases you don’t. Instead, assign these private functions or values to a local variable within your controller function.

I often define a function that initializes the default values within the controller.

Making peace between server and client: Camelizing and de_camelizing Restangular data

Sometimes you find that the API that you’re interacting with via Angular $http requests uses the underscore convention rather than Javascript’s camelCase convention. In this case, our Ruby on Rails app spits out blobs like the second example and we ultimately want it re-serialized like the first example. It’s easy to create a confusing quagmire of under_score and camelCase functions and keys all over your project if you don’t implement a way to translate object keys.

We need some way to re-serialize this object’s keys to camelCase after a response is received. Similarly, requests made to the server should be translated to under_score like the server is expecting. Fortunately the Restangular library makes this quite easy to accomplish.

Restangular allows you to add response and/or request interceptors which allow you to modify your data before and after a $http request. Using the Humps library to camelize and deCamelize, it was simple to modify the requests and responses handled by Restangular. Simply add a config block and use the provided RestangularProvider to add a responseInterceptor and a requestInterceptor:

More >>