How to prevent Fabric from launching when building your XCode project

Recently, Fabric has been acting really buggy freezing up and mass opening many browser tabs.  If you use Fabric and don’t use the app or don’t want it to launch everytime you build your XCode project, you have a couple options.

Option #1 Prevent Fabric from launching after uploading your project’s DSYM file.

Open up the run script: Pods/Fabric/run and change:

eval $DIR$PATH_SEP$UPLOAD_COMMAND > /dev/null 2>&1 &


eval $DIR$PATH_SEP$UPLOAD_COMMAND;killall Fabric > /dev/null 2>&1 &


Option #2 Only upload DSYM when archiving builds for release.

Check the “Run script only when installing” option under Build Phases:

Screen Shot 2016-04-23 at 5.30.21 AM



How to speed up slow Swift compile times

Swift code compiling slowly? Here’s how to find out what’s causing it.

Under Build Settings, add “-Xfrontend” “-debug-time-function-bodies” to your Other Swift Compiler flags.

Open terminal.

List files sorted by slowest compile time:

$ xcodebuild -workspace MyProject.xcworkspace -scheme MyProject clean build | grep [1-9].[0-9]ms | sort -n

List functions grouped by slowest compile time:

$ xcodebuild -workspace MyProject.xcworkspace -scheme MyProject clean build | grep [1-9].[0-9]ms | awk '{arr[$2]+=$1} END {for (i in arr) {print arr[i], i}}' | sort -n

Print total compile time:

$ xcodebuild -workspace MyProject.xcworkspace -scheme MyProject clean build | grep [1-9].[0-9]ms | sort -n | awk '{SUM+=$1}END{print SUM}'

More here:

Last Cigar

Last Cigar

The limited edition P.G.C. Hajenius Aemstelle year cigar is a slim corona made of a delicate Sumatra wrapper, its interior consisting of a blend of tobaccos from Brazil, Indonesia and Cuba.

I enjoyed these during my daily walks. It starts off mild with hits of spice. I found flavors start to intensify and crescendo especially towards the finish. I smoke ’em to the stub. This cigar packs quite a punch for its petite size. It lasts for about 30 minutes then I usually find myself wanting to smoke another one immediately after LOL. Cheers to my good friends in Holland for helping me see the good things in life.:)


Workaround to rewind HTML5 video on iPhone and iPod

If you’re reusing the same element and changing the “src” property, you’ll see videos won’t properly start from the beginning on iPhones and iPods with Mobile Safari and iOS 5/6. Setting “currentTime” also doesn’t work since it requires the native video player to be in full-screen mode. Sucks huh?

This should work for example (but doesn’t):

$('video')[0].src = "video.mp4";
$('video')[0].currentTime = 0;

The best workaround so far is to use <source> tags instead of the “src” property. For example:

$('video').html('<source type="video/mp4" src="video.mp4" />'); 
$('video').find('source').last().on('error', function() { alert('some error'); });

Give it a try.

Great Golfers who Putted from an Open Stance

Jack Nickalus


18 major wins. Made crucial putts when he needed them the most. Need I say more?

Ben Crenshaw

Two-time Masters champion. Ben is regarded as one of the best putters ever with his long free-flowing stroke.


Bobby Jones

One of the most celebrated golfers of all time. The only golfer to achieve a (pre-Masters era) Grand Slam, winning all four majors, U.S. Amateur, U.S. Open, The Open, The Amateur, in a single season.

In 1924, Walter Travis gave Bobby Jones a brief putting lesson in the locker room of the Augusta Country Club.  As reported in “The Life and Times of Bobby Jones”, by Syd Matthews, it was the putting lesson that “changed the course of Jones’s golfing history”. Travis instructed Jones to “get his feet so close together that the heels almost touch” and changed his grip to a reverse overlap.  Jones acknowledged the resulting improvement in his putting in his autobiography, “Golf is My Game”. –


Dave Stockton Sr.

Two-time PGA Championship winner. Putting might but hard for some people, but it certainly isn’t for Dave.


Bobby Locke

Coming out of South Africa, Bobby Locke is the winner of 4 Open Championships for a total of 72 career wins. The guy who coined the phrase, “Drive for show, Putt for dough.” Players on the PGA Tour wanted him banned because he was just too good. Gary Player said of him, “One six-foot putt, for my life? I’ll take Bobby Locke. I’ve seen them all, and there was never a putter like him. In the 100 or so competitive rounds I played with him, I saw him three-putt just once. … You had to see it to believe it.”

Bobby actually putts with a closed stance but I thought it worth including in this list. Different strokes for different folks!

Missing any? Leave a comment.

Ember.js – 5 Reasons You Should Avoid It


Let me share with you 5 reasons why you should avoid this “ambitious” and “opinionated” framework.

Reason #1 – Ember Data is not production ready

The first thing you see at

Screen Shot 2013-07-31 at 1.58.15 PM

Yikes, a cute little gopher holding a construction sign. They say it’s not production ready and won’t be until 1.0. The latest release is currently at 0.13 and there are 193 open issues. It’s supposed to support polymorphic sub-models, but we couldn’t get that working. We also weren’t able to customize foreign key relationships on some of our models. For example we needed to sideload an array of ids in comments (vs the standard comment_ids). The included REST adapter isn’t very customizable and only works for a limited number of use cases.

Reason #2 – Singletons, singletons everywhere

While not technically singletons, things are setup and behave in a very similar manner. You define and throw everything (models, views, controllers, the router, etc) into a single global App namespace. An instance of each object will be instantiated on startup and is retrievable by the name you gave it. For example, App.IndexController would be retrievable by this.get(‘controller.controllers.index’). This is the framework wanting to be opinionated. Dependencies must be defined using the “needs” API. Controller A needs Controller B, Controller B needs Controller C, and so on. If you’ve read about or used singletons before, I think you can see the danger. There is potential for things to get messy real fast where we’d end up with circular dependencies and tight of coupling.


Reason #3 – Model-View-HUH?

Taken from:

In Ember.js, templates get their properties from controllers, which decorate a model.

This means that templates know about controllers and controllers know about models, but the reverse is not true. A model knows nothing about which (if any) controllers are decorating it, and controller does not know which views are presenting its properties.


In Ember.js, the views know about their controller. They assume properties on the controller exist in order to draw themselves. While I see how this might make it easier for designers to work on templates, it goes against my intuition as a programmer. Plus I’ve never seen this type of reversed coupling in any other framework. Ember views are even granted DIRECT ACCESS to other controllers within the app (via controller.controllers). Spaghetti anyone?


Reason #4 – Difficult to Test

Because of tight coupling and the many assumptions being made in a typical Ember.js app, it becomes increasingly difficult to test individual parts of your application. You also have to deal with the asynchronous nature of the Ember.js runtime (property bindings and automatic observer method calls) where it can be difficult to track down bugs caused by race conditions. It’s not really the frameworks fault when that occurs, but it does present a new set of challenges.

Reason #5 – Limited Flexibility

Making a single page CRUD app against a standard REST interface? You’ll probably be fine. Need to customize things? You might find you’ll quickly run into problems. If you need customizability, instead of fighting with the framework every step of the way, I recommend looking into other options such as Backbone.js and Require.js.