Parse Shutdown: Three Options for Preparing Your Mobile Apps and Services


On January 28th, Facebook announced that it was shutting down Parse, the popular Mobile Backend as a Service (MBaaS), in January 2017, after having purchased it for a reported $85M in 2013. Thousands of mobile apps and services rely on Parse, and if yours is one of them now is the time to start making plans to transition away from Parse. In late January of next year apps that aren’t updated to use a different backend services will stop working and inevitably earn themselves a collection of “one star” App Store reviews. For most apps, this transition away from Parse will take one of three options, any of which Art & Logic can help manage for you. (more…)

2014 Review: Day 1

As 2014 winds down, we’ll take an opportunity to look back at some of our most-read posts from this year, in case you missed them the first time. 

Photo of night sky by Phil Plait on Flickr

Brian Poteat contributed a few posts looking at the Meteor web application framework:


Error Handling in gulp

Photo of inside fo tackle box by Harrison Kugler on Unsplash

Consider three reference points on the spectrum of errors that might occur in a build system:

  1. The build system broke (we’ll call this “fatal”): the makefile has a bug, a file resource disappeared, a gremlin burrowed through the ram
  2. A critical build task failed (“error”): the coffeescript has a syntax error, the server couldn’t start
  3. A validation task failed (“warning): the sass has a lint warning, a behavior test failed

Should the build fail for each of these error types?  That depends on the context:

  • In a CI server, everything down to a validation warning should result in a failed build
  • In a watch / live-reload context, errors and warnings should be logged but the build should keep (continually) running
  • In a one-off local development build, the “fatal” and “error” levels should cancel the build but a “warning” should not (well, a TDD developer would disagree)

How can these error permutations be handled in a gulp build? (more…)

gulp Minus Plugin

Image of elephant sculpture by mattmariebache via Flickr

I covered the potential simplicity of gulp plugins in my previous post (refresher: gulp, the hot new JavaScript build system, enables writing an asynchronous, streaming plugin in just a couple dozen lines).  On the other hand, gulp’s philosophy leads to a pretty lengthy list of strong recommendations for plugins, including: don’t write a plugin if it can be reasonably avoided.

Whereas the configuration-centric Gruntfile seems to require writing a plugin for any and every tool, the code-centric gulpfile makes it easy to call a tool directly from a task.  There are two major benefits to skipping the plugin:

  1. Plugins should be simple, but simplicity conflicts with supporting end users’ various needs
  2. Plugins hide tool interactions, and non-standard usage may involve time digging into their internals