Removing Exif Data To Resolve IOS Issues

Related to my last post, I had a bug to fix. The images looked rotate 90 degrees locally, so I used Imagemagick’s convert command to rotate them 90 degrees. They looked right locally, and on the sight when viewed in chrome.

However, iOS was showing the images over-rotated by 90 degrees. It turns out after some digging that the pictures were taking on an iOS device and had saved Orientation data in the EXIF data of the image (metadata). The iOS browser was still honoring that metadata.

Because metadata also has date, time, and location info, a lot of people prefer not to publish EXIF data anyway. Photoshop offers options to remove this data when exporting. I believe GIMP may as well.

But I just wanted to make it part of my process. So I updated the Rakefile from the last post with the following command option from Imagemagick’s convert:

convert input.jpg -strip output.jpg

All is well now. Use your favorite EXIF viewer to confirm success.

Resizing Images in Bulk

I help maintain a site for a craft business. One of the challenges is multiple sizes of images for new stock each year. I used to go through and resize each image manually with a program like Gimp.

I finally got smart and installed ImageMagick.

With a Rakefile, I can pass each image into the convert command with the proper sizing, and get the output into a new folder, ready for upload. The code is shown here:

One catch to keep in mind if you work on a Mac. There can be orientation metadata from some images that OS X will honor, but a browser will not. If your images show up on the web in the wrong orientation, look into ImageMagick convert command’s -rotate option.

Data-Driven vs the Dashboard 

It is common for technical product companies to call themselves “data-driven” these days. The idea is that metrics are used to drive decisions. Sounds easy enough, and compatible with a technology landscape that is enamored with data science, etc. 

But something didn’t always feel right to me. Strange, right? If you follow this blog or know me, you probably know that I have been steering my career in a data-centric direction. I coordinate the Cleveland R User Group, and have spent most of my personal technical time with a variety of tools to do analysis and modeling. 

Maybe it’s a deeper understanding of statistics and related skills that lies at the center of my problem. Many people view these fields as black and white. “Show me the numbers”, people say. As if they are stone tablets chisled with the truth. Creating summaries, graphs, models, etc. requires understanding the domain, and subtle interactions. The tools are getting better, but we still need people to drive the tools and frame the questions right. To correct mistakes of causality. 

In explaining this, the example that hits home for me is a dashboard for a product. Have you ever tried building a B2B software product without one? Good luck when sitting in front of an executive board and you can’t show them a dashboard they can monitor. Never mind that for all of your existing customers that dashboard is the least used page in your analytics. It’s key to the sale. But if you ignore that, and just look at user data to drive all of your decisions you’ll miss that. 

So maybe there’s nothing wrong with being data-driven, it’s just that you have to be willing to mix in some decisions based on strategy and experience. And you have to ask your customers the right questions in the first place.

To be a great firm, a company should find a sophisticated middle ground. You can’t rely on a visionary employee to drive all decisions. Many founders think they are Steve Jobs and can divine all customer needs. Steve Jobs is an outlier among outliers. The answer, however, is not to turn in your brain because you started gathering data. The metrics are a tool, and you can still choose how to use your tools. A feature (or page) may still be legally required. Or it may be used rarely, but of tremendous value when it is. Data provides clarity for the many mundance decisions. It should still be up to a person to set the strategy. Otherwise, you’ll be selling a product without a dashboard. Heaven forbid…

Why Aren’t You Using PhoneGap?

PhoneGap (now becoming known as the Apache Cordova project) is commonly thought of as a cross-platform mobile development solution. While true, I think it’s best to think of PhoneGap as modernzr for the mobile web.

The W3 is working on standards for web sites to be able to access specific hardware features. These common hardware features were first prominent in mobile, but are coming back to laptops via tablets and hybrids. Feature examples are GPS, Camera, Motion Sensors, Network Sensors. Also, mobile has popularized the idea of system maintained contact lists and other information that is now available (with proper permissions) to all apps.

The runtime in your application is a native app which hosts a native browser control, and that browser control is pointed at a local directory you include in the app with html. And the javascript has access to some os specific features that are exposed to javascript.

When those standards are in place, mobile web sites will be able to fulfill most of the promise of native applications. This is why Steve Jobs didn’t want to build an app store in the beginning, and both RIM and Microsoft have been pushing html/css as 1st class ways for building apps.

In this new world with device access standards, only special circumstances like intense 3d graphics should require native code in a c-like language.

But this isn’t the world. Those standards aren’t in place. So PhoneGap fills that gap (any guesses about the name?). And it has the added benefit of supporting the app store distribution model, where mobile web apps require the user to bookmark the page to their homescreen.

Most cross-platform apps get knocked for performance reasons. Sure PhoneGap apps are html and javascript, but javascript engines are improving a lot these days, and you can always use plugins to push key pieces of your application into the native arena. Plugins in PhoneGap allow you to write native code (ie Objective-C on iOS) that is exposed to the javascript in your application.

Also, cross platform frameworks are usually criticized for their look and feel. In PhoneGap, you’re using html and css, a platform that we’ve been working to style for a very long time (in tech terms). I think this fact explains some of the reasons that companies like facebook and linkedin use html heavily in their frameworks.

If you’re interested in getting started in PhoneGap, I recently reviewed a book I recommend to get started. It’s a couple versions back now, but it covers things conceptually well, and it’s a nice companion to the docs.

Not every application is a fit for PhoneGap. There are reasons to go native. But I think that for basic data goes in / data comes out type of applications, It’s a great way to start. And getting good at writing single page style apps with heavy javascript will push you in the direction the web is already going.

Working With Social Network APIs

Creating Vicinity Buzz naturally involved working with a the APIs of social networks. That information seemed worth sharing for those of you interested in writing any type of application that would integrate with a social network.

Developer Documentation

Any of the social networking sites you probably want to integrate with have developer api’s that are well documented. Here’s the starting points for a variety of services:

Working With JSON

All of these APIs are best used with JSON. If you’re not familiar, you can read up at json.org. It’s the notation for serialization of javascript objects, and object literals.

Where To Make the Call From

If you are working in a standard web page, you could call the api from document.ready (assuming you are using jquery). This is the approach I take on hoolihan.net, my personal homepage. There is a twitter feed on the right side.

If you have a bit more of an application, you may want to look at one of the many javascript frameworks that help you route events to actions. These are frameworks like backbone, knockout, spine, etc. There are also commercial variants like kendo, dojo, and sencha.

jQueryMobile is commonly paired with PhoneGap, and in that scenario, using something like backbone is a bit tricky. You may want to bring in a template binding library, but avoid routing.

Binding

jQuery.templates was one of the first good javascript template binders that I’m aware of, but there are now many different options. In the jQuery world, most of the momentum seems aimed at jsrender. Recently I’ve considered bring in knockout and only using the binding part, but I’m not far enough in to evaluate that direction.

API Keys

Unless you’re using the most basic parts of the API, you’ll probably need to register your app and get an API key. It’s a token that identifies your application. In the event of API abuse (too many calls, etc), they have information to contact you and analytics around the issue.

Open Authentication

This is a big topic, but if your application wants to use a social network to identify your users, this is possible via open authentication. If you are interested in this, get started here.

What Do You Think?

Are there any particular areas of the APIs that you’d like to see more detail about? Any conceptual parts that would warrant their own post? Let me know what you think below.