Video

A tech demo for a little hack I call “mobilenode”.

Text

Today marks my last day working full time with Appcelerator.  It was not an easy decision, but I’ll be joining up with another organization I have admired for a long time. Twilio is a great company with incredibly powerful communications APIs that developers love to use, and I can’t wait to work with the amazing team there.  

But before I start in on this new set of challenges, I’d like to thank Appcelerator for the privilege of being a part of the company.  It has been exciting and awe-inspiring to watch Jeff Haynie build a platform company that powers the success of tens of thousands of developers and businesses around the world. 

Four years ago, I came from a large corporate environment to Appcelerator, my first start-up company. Appcelerator had just recently landed in Mountain View from Atlanta. On my first real work day, I remember thinking many members of the team still looked to be tired and dirty from the journey.  I would later learn that those people just always looked that way, but Appcelerator’s beginnings in Silicon Valley were certainly modest.  Today, Appcelerator is helping to shape the future of mobile, which is shaping the future for all of us.

As corny as it may sound, this experience has been completely life changing.  With Appcelerator, I have had the opportunity to:

  • Write my first line of meaningful JavaScript
  • Give formal presentations to live audiences for the first time
  • Learn to get comfortable striking up conversations with complete strangers to learn about their goals and projects
  • Watch a developer community grow from zero to 375,000 people
  • Make my first contribution to an open source project
  • Figure out what the .psd file extension was for as I cut up a design for the first time
  • Build a developer certification and training curriculum from scratch
  • Work on apps for Fortune 500 companies
  • Visit dozens of cities across the US, and travel outside the US for the first time through Canada, India, Europe, and the UK
  • Meet thousands of sharp developers working on amazing projects (with Appcelerator technology and without)
  • Live through three major pivots (that number might be debatable), four acquisitions, and a near decapitation at the hands of Steve Jobs
  • Work directly with some of the most talented people I’ve ever met, many of whom I am now proud to call friends (one or two would even call me that in return).

…and probably much more that I could list.  This was an opportunity I was unworthy to get in the first place, but it’s one I am immeasurably grateful for receiving. During my time with Appcelerator, I had very little time to think “I can’t” or “I’m not sure how”. No one knows how to build something brand new, in a way that’s never quite been done before.  I didn’t always succeed to the fullest measure, but I learned from every misstep, and tried to take it as an opportunity to improve myself.

And therein lies the true value of working at a start-up like Appcelerator.  It’s how I understand what it means to “draw the owl”:

My owl probably looked like crap plenty of times, but I drew it.  Eventually, some of them even looked pretty good.  But more importantly, because I drew that owl, I know that in the future I will be able to draw other things I can’t even imagine today.

So - how do you say “thank you” to a team (Appcelerator) and a person (Jeff Haynie) who gave you an opportunity to have these experiences and learn this lesson?  I don’t think you can, but this is my attempt to try.

And to the greater Appcelerator team - the 375,000 developers in our community - I have this to say:

You’re on the right track.  I am as confident as ever that the Titanium concept for cross-platform is the way forward for mobile development.  Stay involved, and keep pushing for a stronger, more robust platform.  Learn how Titanium works, extend it, and use the platform as a tactical advantage, not a way to avoid native code. It’s an exciting time to be involved - so please do so, and don’t let Tony goof up Alloy.

Jeff has your back, and will make sure Appcelerator does right by you. I’ll stake my life on that.  But the best things in our community have never come from Appcelerator down to you - they have come from developers buying in to the platform and making things happen.  Whether it’s Liz/Ket/et al forming London Titanium, Pratik Patel running yet another Titanium clinic, or Kota Iguchi mixing the primordial goo for Lanica - the best of Appcelerator has always come from you.

Unfortunately, you are unlikely to be completely rid of me.  Like the second string linebacker on the state champion football team in high school, I will probably linger long after no one remembers my name.  I will be focusing on other areas to advance the adoption of Twilio (and in an attempt to broaden my skill set and try new things), but I will remain a cheerleader for this community.  A Titan, even, if they’ll let me in to the program.

If you’re here, you know where to find me :) - I’ll be making some changes to this site soon to make it easier to contact me, but you can hit me up on Twitter in the meantime.  

Until then - go draw the f***ing owl.

Text

In what is one of Chris Rock’s best stand up performances, he does the bit below on how his family used Robitussin to cure everything from asthma to broken bones.

Sometimes I feel developers fall into this same trap (though for reasons of inertia or religion rather than lack of health care coverage) - we have one tool that we really like to use, and we use it to the exclusion of all else.  To the point of being ridiculous sometimes, as in the clip above.

Doing a native app’s entire UI in HTML falls into the “Robitussin for compound bone fractures” category for me.  Web developers must go to extraordinary lengths to make their interfaces even approach native quality when embedded within a native shell, from batching touch events to fire on requestAnimationFrame to obsessively tuning CSS and JavaScript to provide bounce physics that match those of a native platform.  The lengths to which I’ve seen developers (and frameworks) go to emulate native UI in a web view have been astounding (and in some cases quite effective) - but on another level these tricks are completely insane.

How much time would a developer spend tuning HTML to feel like native UI in a non-trivial application?  How many external dependencies and heavyweight frameworks will you pull into a project, just to make HTML feel more native?  And when you optimize for one platform and web view, how much code is REALLY reusable on other platforms when browser differences and platform UI expectations are taken into account?  

It would vary greatly depending on the project’s requirements, but just bringing an HTML-based UI to a level of parity with native UI in terms of feel and performance is challenging.  Some would argue that it’s not possible at all to make HTML/CSS indistinguishable from native.  But no matter what you believe about the potential effectiveness of HTML/CSS versus native UI, any time you spend hacking HTML/CSS to bring it in line with native look/feel/performance is time NOT spent adding value for your users.

The web as a platform is incredibly powerful and important.  Browser based applications have real advantages over native apps, and the web stack continues to grow more powerful.  The Firefox OS effort and device APIs generally are moving the web forward as a platform for delivering applications.  I truly believe that in time, the pendulum will shift back toward web applications, and we’ll start seeing a more balanced mixture of native and web apps used on mobile devices.

But for native apps, I don’t get why you’d want to ice skate uphill with HTML and CSS in a thin native wrapper - essentially starting yourself off behind the 8 ball in performance and features.  Obviously I am biased, but taking off my Appcelerator hat it still makes no sense to me.  Stop using HTML and CSS like Robitussin.

Text

A common question I get asked at developer events and conferences is how Titanium compares to PhoneGap. I thought I would take some time to explain how each technology works at a high level, and assess how the two technologies compare to one another.

From 10,000 feet, PhoneGap and Titanium appear to be similar. They both provide tools for cross-platform mobile development. Both also require the use of JavaScript and web technologies in some capacity. Both Titanium and PhoneGap are open source software with permissive licenses (the Titanium Mobile SDK is released under the Apache 2.0 license - PhoneGap, which might also be called a “distro” of the Apache Software Foundation-governed project “Cordova”, is similarly licensed).

But that’s really where the similarities end. While both technologies exist to enable cross-platform mobile development, the philosophies and approaches to solving this problem have very little in common. Also, the business goals driving each project from the perspective of the sponsoring companies (Adobe for PhoneGap and Appcelerator for Titanium) are very different. I will attempt, from my perspective, to describe these technical, philosophical, and business model differences in some detail in the text to follow.

Also, if you weren’t already aware, I am a long time Appcelerator contributor and employee. That said, I have worked hard to keep my technical and philosophical assessments based in technical fact and the explicitly expressed goals of the teams involved. If you feel I have made any points that are factually incorrect or misleading in some way, please let me know in the comments and I will update this post as appropriate.

I will first describe at a high level how both technologies work. I will also describe how both technologies are extended with additional native functionality. For each technology, I will also summarize the key strengths and weaknesses with their chosen approach to cross-platform. The technical differences will quickly become obvious, but after these overviews and comparisons, I will also describe what I feel are the philosophical and strategic differences between the platforms and where they are going.

Let’s start by exploring PhoneGap and how it works.

What is PhoneGap Trying To Accomplish?

The purpose of PhoneGap is to allow HTML-based web applications to be deployed and installed as native applications. PhoneGap web applications are wrapped in a native application shell, and can be installed via the native app stores for multiple platforms. Additionally, PhoneGap strives to provide a common native API set which is typically unavailable to web applications, such as basic camera access, device contacts, and sensors not already exposed in the browser.

At a higher level, PhoneGap might be considered the vanguard of the emerging W3C Device API standards, as they attempt to bring that future to web developers in the present. Today, no platform makes web applications first class citizens, though Mozilla’s promising Boot To Gecko platform has a chance to change that. Microsoft is also making interesting strides for Windows 8 with regard to first-class API access to web applications. But the goal of PhoneGap is to seize a subset of these rights for web applications today.

End User Workflow, Tooling and Interface for PhoneGap

To develop PhoneGap applications, developers will create HTML, CSS, and JavaScript files in a local directory, much like developing a static website. In fact, some PhoneGap developers cite as a bonus of the tool that they can develop in a desktop web browser most of the time, without needing the native toolchain at all.

To run a PhoneGap application on a native emulator/simulator, developers will generate a project for each of the native platforms they wish to support, configure that project’s “web root” directory in Xcode, Eclipse, or whatever native toolchain is needed, and then run the project using that tool. The precise steps are outlined in their getting started guides, per platform. Often, symbolic links are used to route the “www” folder across multiple native projects to a common directory location.

Installing a native-wrapped PhoneGap application to a device requires a similar workflow. However, to augment that process and alleviate the need to have native SDKs installed locally, Nitobi (recently acquired by Adobe) had created a service called PhoneGap Build, which will generate installable applications in the cloud. Functionality to support PhoneGap build deployment has recently been integrated into Adobe’s Dreamweaver tool.

The tools used with PhoneGap are the standard tools of web development, such as Firebug, Web Inspector, and your text editor of choice. There is also an emerging tool for remote debugging known as Weinre that is becoming more commonly used. Overall, the fact that you are developing a native application at all is mostly abstract during the development process.

How PhoneGap Works

As we mentioned previously, a PhoneGap application is a “native-wrapped” web application. Let’s explore how the web application is “wrapped”.

Many native mobile development SDKs provide a web browser widget (a “web view”) as a part of their UI framework (iOS and Android, for example). In purely native applications, web view controls are used to display HTML content either from a remote server, or local HTML packaged along with the native application in some way. The native “wrapper” application generated by PhoneGap loads the end developer’s HTML pages into one of these web view controls, and displays the resulting HTML as the UI when the application is launched.

If JavaScript files are included in a page loaded by a web view, this code is evaluated on the page as normal. However, the native application which creates the web view is able to (in different ways, depending on the platform) asynchronously communicate with JavaScript code running inside of the web view. This technology is usually referred to as “the bridge” in the context of PhoneGap architecture - the “bridge” means something slightly different in Titanium, as we will see later.

PhoneGap takes advantage of this to create a JavaScript API inside a web view which is able to send messages to and receive messages from native code in the wrapper application asynchronously. The way the bridge layer is implemented is different per platform, but on iOS, when you call for a list of contacts, your native method invocation goes into a queue of requests to be sent over the bridge. PhoneGap will then create an iframe which loads a URI scheme (“gap://”) that the native app is configured to handle, at which point all the queued commands will be executed. Communication back into the web view is done by evaluating a string of JavaScript in the context of the web view from native code.

There is much more to PhoneGap than that, but the messaging from web view to native code via the bridge implementation is the key piece of technology which allows local web applications to call native code.

Extending PhoneGap

Writing native extensions for PhoneGap requires that you:

  1. Write a JavaScript interface for your extension which will use PhoneGap’s API to queue up messages to be sent to native code.
  2. Register your extension with the native project in some way - on iOS this is done in the Cordova.plist file.
  3. Write native code that PhoneGap will route requests to from the web view, and implement any native code needed

Basically, developers can participate in the same asynchronous messaging system which powers the core PhoneGap native APIs.

Strengths of the PhoneGap Approach

In my estimation, PhoneGap’s primary architectural strength is that it is so small and simple. It does what it does, and it does that well. The PhoneGap team has intentionally implemented only the lowest common denominator of native APIs for the web browser-based app. Because the native API set is so small, it has been relatively easy to port PhoneGap to many different environments. Basically any native platform that supports a web view or web runtime can be a PhoneGap platform.

Non-visual native extensions in PhoneGap are also very simple. The requirements for registering native code to receive messages from the web view are very modest. Simple native extensions can be developed rapidly. This plug-in architecture was also well executed in my opinion.

There is also strength in the fact that native APIs and native app development are almost completely abstract to the end developer. Anyone who can write HTML, CSS, and even a small bit of JavaScript can wrap up a web page in a native app and distribute it as such. The barrier to entry in using PhoneGap to package web pages as native apps is extremely low.

Weaknesses of the PhoneGap Approach

The quality of the user interface in a PhoneGap application will vary based on the quality of the web view and rendering engine on the platform. The Webkit-based rendering engine on iOS is strong, and provides the best performance. The Android web view is functional, but has some notable limitations. On other platforms, the web view performance can be suspect depending on the OS version.

There are also the standard cross-browser issues web developers have always had to deal with. UIs will need to employ progressive enhancement, media queries, and that entire bag of tricks to remain usable on multiple platforms. It helps that many mobile platforms are adopting Webkit, but there are still significant differences even in Webkit based environments.

Mobile browsers are getting better all the time, which will help mitigate those problems. But approaching native-quality UI performance in the browser is a non-trivial task - Sencha employs a large team of web programming experts dedicated full-time to solving this problem. Even so, on most platforms, in most browsers today, reaching native-quality UI performance and responsiveness is simply not possible, even with a framework as advanced as Sencha Touch. Is the browser already “good enough” though? It depends on your requirements and sensibilities, but it is unquestionably less good than native UI. Sometimes much worse, depending on the browser.

PhoneGap also cannot be extended with native user interface. The end developer’s application its self lives inside a web view, and user interface is rendered in HTML. One can message to native code and create native UI that goes on, over, above, or adjacent to the web view, but it’s difficult or impossible to integrate a dynamic, HTML DOM-based UI with native UI components. Appcelerator would know - we tried to associate native UI with DOM elements early on, and needed to scrap that effort as the results were unpredictable and of insufficient quality.

There is also the other edge of the “lowest common denominator” sword. Very few native APIs are exposed to PhoneGap applications by default, which makes platform integration limited. There are a variety of plug-ins that exist to plug some of these holes, but in my personal experience they have varied in quality and maintenance. This could very well continue to improve over time though - there is a strong community around PhoneGap.

We’ll dive more into the philosophical aspects of PhoneGap soon, but let’s explore these same technical areas for Titanium first.

What is Titanium Trying to Accomplish?

The goal of Titanium Mobile is to provide a high level, cross-platform JavaScript runtime and API for mobile development (today we support iOS, Android, and the browser, with BlackBerry 10 and Windows Phone coming soon and eventually, respectively). Titanium actually has more in common with MacRuby/Hot Cocoa, PHP, or node.js than it does with PhoneGap, Adobe AIR, Corona, or Rhomobile. Titanium is built on two assertions about mobile development:

  • There is a core of mobile development APIs which can be normalized across platforms. These areas should be targeted for code reuse.
  • There are platform-specific APIs, UI conventions, and features which developers should incorporate when developing for that platform. Platform-specific code should exist for these use cases to provide the best possible experience.

So for those reasons, Titanium is not an attempt at “write once, run everywhere”. We think there are great, user-experience enhancing features across multiple platforms that developers should be using. We think that native apps should, where appropriate, take advantage of familiar, high-performance native UI widgets. However, we think it is unnecessary that native developers need to learn platform-specific APIs to draw a rectangle, or make an HTTP request.

Titanium is an attempt to achieve code reuse with a unified JavaScript API, with platform-specific features and native performance to meet user expectations. When you write a Titanium application, you are writing a native application in JavaScript. Titanium should be considered a framework for writing native apps, versus an abstraction from the actual platform you are targeting.

End User Workflow, Tooling, and Interface for Titanium

To develop native applications with Titanium, the developer is required to install the native tool chains for iOS and Android. After those tools are installed, however, the developer usually only interacts with the Titanium SDK’s scripting interface (today Python based). This is done either directly through the command line or (more commonly) through Titanium Studio, our Eclipse-based IDE.

Using the Titanium tool set, you will generate an application project directory which contains a configuration file, localization files, and a directory to contain the images, assets, and JavaScript source you will be writing to power your application. You will not, by default, be editing HTML and CSS files, unless you intend to create a hybrid-type application which contains both native and HTML-based UI. Titanium applications can and often do employ a “hybrid” (native and web) UI, like Facebook’s native application for instance. In this way, one could actually implement PhoneGap with Titanium, but that’s out of scope for this discussion.

Using this toolchain, your application is run using the actual em/simulators for the platforms you’re targeting. Titanium Studio also provides step-through debugging, code completion, and other IDE-level features.

Installing to a device for testing is also typically done using our build system. In Studio we provide a wizard interface to configure any code-signing dependencies, and then handle the deployment of your application to a connected device. You can also use the native toolchains to deploy or package your applications, if that is your preference.

When it comes time to ship your application to the stores, our build system will handle the creation of the final application packages for you. This is done locally on the developer’s machine using the native toolchains. The upload process will be the same as it is for native-only developers.

While developing a Titanium application, the underlying tool chains are mostly abstract. They must be present for development, but the end developer is rarely required to use them directly. The fact that native apps are being developed, however, is not abstract. User interfaces are created with cross-platform AND platform-specific components, and your applications should be dealing with things like background services, local notifications, app badges, configuration, activities/intents (on Android)… all things that are exposed via the Titanium JavaScript API.

How Titanium Works

There’s quite a bit happening behind the scenes in a Titanium application. But basically, at runtime, your application consists of three major components - your JavaScript source code (inlined into a Java or Objective-C file and compiled as an encoded string), the platform-specific implementation of the Titanium API in the native programming language, and a JavaScript interpreter that will be used to evaluate your code at runtime (V8 (default) or Rhino for Android, or JavaScriptCore for iOS). Except in the browser, of course, where the built-in JavaScript engine will be used.

When your application is launched, a JavaScript execution environment is created in native code, and your application source code is evaluated. Injected into the JavaScript runtime environment of your application is what we call “proxy” objects - basically, a JavaScript object which has a paired object in native code. Colloquially we will often refer to “JavaScript land” and “native land” in a Titanium application, as they are kind of parallel universes to one another. The proxy object exists both in JavaScript land and native land, and serves as the “bridge” between the two.

In your JavaScript code, when you call a function on the global Titanium or Ti object, such as var b = Ti.UI.createButton({title:'Poke Me'});, that will invoke a native method that will create a native UI object, and create a “proxy” object (b) which exposes properties and methods on the underlying native UI object to JavaScript.

UI components (view proxies) can be arranged hierarchically to create complex user interfaces. Proxy objects which represent an interface to non-visual APIs (like filesystem I/O or database access) execute in native code, and synchronously (or asynchronously for APIs like network access) return a result to JavaScript.

Hopefully this helps directly address two common misconceptions about Titanium - at no point does Titanium require the use of a web view component. The developer can create a web view as a native UI widget, but the web view is not used to evaluate Titanium source code. Nor is JavaScript code cross-compiled to Objective-C or Java in Titanium. Your JavaScript source is evaluated at runtime.

Extending Titanium

Titanium is extensible with both non-visual and UI capabilities in native code. By implementing a Proxy and/or View Proxy interface in native code, developers can create new native functionality for Titanium applications exposed in JavaScript. We expose the same interface we use to create Titanium’s own internal interface to module developers both on iOS and Android.

Strengths of the Titanium Approach

Since the goal of Titanium is to provide a higher level API for native mobile development across platforms, you will get access to a wide array of native features and functionality out of the box, from user interface components to socket interfaces to notification system integration. The goal of Titanium is to reduce the functionality gap between Titanium and pure native apps to something approaching zero. We’re likely to never support an entire platform’s API out of the box, but we want to cover 90% of the most common use cases and provide a platform where the other 10% can be added by people that need it.

Since Titanium can be extended with visual components that plug into the same view hierarchy as the rest of the application, you’re able to (ultimately) implement any user interface that is possible on the underlying native platform. Need a TableView to scroll at 60fps with special native code? You can do that. Want to seamlessly integrate an OpenGL drawing surface for a game, and keep the logic for the run loop in JavaScript? You can do that. You can integrate these UI extensions directly into the rest of your application built with the core Titanium APIs.

The look and feel of a Titanium application, when using common UI widgets, is also a strength of the platform. There is no visual emulation going on (either through the application of CSS, or rendering of UI widgets using OpenGL or Flash). When you create a NavigationGroup, it is backed by an actual UINavigationController on iOS. The animations and behavior match what a native app user will expect, because you’re using the same UI control.

Since Titanium provides a high level native programming API in JavaScript, the barrier to entry for native programming is significantly reduced for anyone who has used an ECMAScript based language (which is a lot of developers). Atwood’s Law is alive and well through Titanium.

Weaknesses of the Titanium Approach

The scope of the Titanium API makes the addition of new platforms difficult - implementing the Titanium API on a new native platform is a massive undertaking. For that reason, the Titanium platform is only available on what have been deemed the most critical mobile platforms at present: iOS, Android, and the web.

Our mobile web browser support is not yet of GA quality - we are continuing to work on the performance and feel of our UI widget set, as well as rounding out the implementation of our core Titanium APIs.

Because the layer of abstraction provided by Titanium is large, sub-optimal API implementations remain in our own internal framework. Some user interface components do not yet perform as well as their native counterparts under some circumstances, such as very large table views with highly customized layouts. Optimizing our core user interface components remains the primary engineering task for our team. As we fix bugs and hardware improves, we are seeing this become less of an issue. We also find that information architecture, especially for large data sets, needs to be applied in many cases.

Also owing to the ambitiousness of the Titanium platform, extending Titanium is non-trivial. A good working knowledge of Titanium’s architecture and the environment is necessary to effectively integrate a new native control or API. The developer experience, API docs, and high level guides for module developers were improved a lot with our latest 2.0 release, but remain an area of focus for us.

Philosophical Differences

By now, I would hope that the technical differences between PhoneGap and Titanium are pretty clear. But beyond those differences, the goals and direction of each project are different as well. The stated goal of the PhoneGap project is to, eventually, cease to exist. As stated earlier, PhoneGap is intended to be the leading implementation of emerging browser standards around device APIs. In theory, once browser vendors implement the features of PhoneGap, the platform will no longer be necessary. PhoneGap its self isn’t intended to be a platform - it’s a shim to add native app-like functionality to web applications. The web is intended to be the platform.

PhoneGap’s new sponsoring organization, Adobe, is also very much interested in the advancement of the web as a platform. In recent months, Adobe has been aggressively building out tools to enable the development of HTML 5/CSS 3 web applications. It seems obvious to me (and many others) that Adobe sees a diminishing role for Flash as standard web technologies evolve.

At it’s core, Adobe is a tools business. Platforms are a channel through which Adobe can sell tools. Once, that platform was Flash. Now, that platform is the web browser (in addition to Flash). I don’t know precisely how PhoneGap factors into Adobe’s product roadmap, but in a lot of ways it serves a similar purpose as Flash. PhoneGap is an attempt to create an abstract runtime environment to enable cross-platform deployment.

If Adobe can sell tools to develop for the web, and the web can be used to develop more types of applications, then that’s a clear win for Adobe. Which is fine, by the way - nothing wrong with selling tools.

It’s worth noting, however, that Adobe is not the governing body of the Cordova project, on which PhoneGap is now based. That project is owned and governed by the Apache Software Foundation. It remains to be seen what the interplay is going to be between the two projects, but my gut instinct is that they won’t diverge much. I think their goals will remain philosophically aligned.

Appcelerator is also interested in and supportive of the advancement of the web as a platform. Everyone wins when the web gets stronger as an application platform. The difference is that we view the web as one great platform among others, with a unique character and set of strengths and weaknesses. We don’t expect the web to become the only mobile application platform. We think that platforms like iOS, Android, BlackBerry, Windows Phone, and the like will continue to be influential, and will provide great experiences for users. That choice and competition will be a good thing for consumers, but will remain a problem for developers.

What we expect to provide for developers through Titanium is a way to target the web and native platforms from a single codebase, while retaining the features, performance, and tight platform integration that the users of that platform expect. We expect to build an enduring platform for mobile client development, with services and tools to speed up that process. We are not a tools company - we are a platform company, and our success will be linked to the success of developers on top of our platform. Over time, we hope to build an open source platform company in the spirit of Red Hat and other giants in that space.

Which tool or approach is right for you? Like all things in software development, it depends. There are no silver bullets. But hopefully this description and comparison will help you make the right choice for your situation.

Link

trevmex's tumblings: Building Rails Apps for the Rich Client

trevmex:

#railsconf 2011 Notes

Yehuda Katz (@wycats)

How do you build Rails apps that work with rich client-side applications?

Rails can be very useful, even if you are not rendering HTML, Rails makes making APIs really awesome. It can work well for machine-to-machine communication.

“If all I’m doing…

Source: trevmex
Link

Higher taxes not hurting (even helping) Norwegian start-ups

In the States, it is popular to assume higher taxes are always and in every situation bad for business. There is no statistical data to support such a claim, and there is compelling evidence to the contrary (or at the very least suggesting that personal income tax rates and business prosperity are not inextricably related, as many Republicans would have us believe). Our collective inability to have a rational discussion on tax policies is crippling and will eventually bankrupt our government. From the article:

There is precious little evidence to suggest that our low taxes have done much for entrepreneurs - or even for the economy as a whole. “It’s actually quite hard to say how tax policy affects an economy,” says Joel Slemrod, a University of Michigan professor who served on the Council of Economic Advisers under Ronald Reagan. Slemrod says there is no statistical evidence to prove that low taxes result in economic prosperity. Some of the most prosperous countries - for instance, Denmark, Sweden, Belgium, and, yes, Norway - also have some of the highest taxes. Norway, which in 2009 had the world’s highest per-capita income, avoided the brunt of the financial crisis: From 2006-2009, it’s economy grew nearly 3 percent. The American economy grew less than one-tenth of a percent during the same period.

Also, note the payroll differences in high-tax Oslo, Norway versus New York City. To employ a software engineer at a $100,000 salary costs $116,603 after taxes and benefits. In New York City, it costs $122,490 for a single person, and $138,314 for an employee with a family.

Photo

Had a person in class with a MacBook Pro with a corporate IT configuration. They ran the iOS simulator and were unable to get location services to work. Turns out that your Mac’s location services are used by the iOS simulator, and they need to be enabled for location services to work. This is in System Preferences » Security.

The symptom you’ll likely see in the simulator is an error related to location services being disabled for this device, or something along those lines. This is persistent despite resetting content and settings from the iOS Simulator menu.

Photo

Gorgeous site design generally, but classic example of getting too cute with the UI.

Text

Here are the slides from my talk at Mobile March 2011 - thanks to Justin and the crew for putting on a great event!

Text

Every day it seems like I see another tweet or plea for help from a developer flailing about trying to implement oAuth in their desktop or mobile application. This is because oAuth is probably the least user friendly technology I have encountered in my decade of software development. As frustrating as it is useless, I cringe every time I need to come near it. For the busy, here are the bullet points of my upcoming rant:

  • oAuth doesn’t protect the end user’s password
  • oAuth is a horrendous user experience
  • oAuth is not impossible, but a pain to implement
  • Using common sense in your web service API design, all the goals of oAuth can be realized

While oAuth is reasonably easy to implement in a browser-based application, it remains incredibly unwieldy for desktop, mobile, or any other type of client. With a bit of determination, the libraries exist to do oAuth in your client app today, the JavaScript version of which works in Titanium with a bit of massaging. For Titanium Mobile, there’s a welcome attempt from a community member to generalize the process out into a JavaScript library, which is so far looking promising, if a little rough around the edges. So without a doubt, there are many, many people who have successfully implemented oAuth in many different contexts, so clearly it is possible. It is also possible for me to swim from Saint Paul to Minneapolis in the Mississippi river in early December wearing a Speedo and a rakish grin, but that doesn’t mean it’s a good idea.

Here’s why oAuth is ridiculous, and should be banished from the face of the Earth. It should be said that these arguments largely pertain to non-browser web service clients:

oAuth does not protect the user’s password

The biggest fallacy of oAuth is that it prevents an end user’s password for Service A being retained by Service B, who uses Service A on behalf of the end user. By taking the end user to a login screen branded by Service A, the user is made to believe they are giving their password to trusted Service A (which most of the time is the case). However, if I am the developer of Service B, and I have a malicious intent to grab the user’s password, I have any number of ways to intercept the password being entered. Or maybe I just fool the user with a well-decorated login screen which mimics the look and feel of Service A.

I call shenanigans on this most ‘useful’ feature of oAuth - it’s no more secure than giving your Service A username and password directly to Service B.

oAuth is an awful user experience

I shouldn’t have to call out that opening up a random browser window, removing the user from your experience, is hardly an ergonomic means of authenticating users. Anyone who has used a Facebook-connected desktop app knows how weird the boxy blue CSS of Facebook looks inside an application that is neither blue, nor boxy. This is a minor gripe, but from a UX perspective I am diametrically opposed to disrupting the user’s interaction with my application by kicking them out to a browser window, embedded or not. Especially since, as noted earlier, it does not enhance their security.

oAuth is painful to implement

Yes, there are many client libraries out there for consuming oAuth services (so too are there for SOAP web services, maybe the next most reviled technology on my list). But there are just as many developers who struggle to implement these libraries in different languages and different runtime environments. oAuth is a weird abstraction layer dependent on a bizarre song and dance of hashing and string concatenation, none of which is ultimately necessary if you make different choices in your web service API design. And I am generally distrustful of any web service API that requires a sophisticated client library to even use (yes SOAP, again I am looking at you).

The goals of oAuth can be achieved differently

Maybe I am missing something, but as far as I can tell there are a few named benefits of oAuth from the perspective of the oAuth provider:

  • Do not divulge username/password combos to third parties
  • Do not require (or allow) the use of username/password combinations on every request
  • Retain the ability to revoke the permission of a third party application to act on a user’s behalf

The first problem is essentially unavoidable for the reasons stated in the first bullet point - if a third party is going to ask for a username and password combination, they have the ability to grab and retain it if they act unethically. What you as the web service provider can do is design your web service API such that a username/password is exchanged for a token, which may have an expiration date and can be revoked if needed. In this case, the third party has no ethical reason to retain a username and password, which is the best you can hope for. A reasonable web service API will:

  • Use SSL to protect the contents of a request and response
  • Exchange a password for a token that can be revoked by the service provider or the end user
  • Require the use of a token for authenticated requests, not a username/password combo
  • Potentially, use an API key to have an understanding of who is using your API and why, and retain the ability to shut them down if they cause problems.

None of this requires the two or three legged oAuth BS that serves as a source of consternation for so many developers. Am I missing something? Taking crazy pills? If so, please set me straight in the comments. Otherwise, join with me in rising up against needless complexity in web service APIs.