Its hard to find an easier way to create that type of site than with Rails. Especially when its so simple to deploy and scale Rails apps on Heroku. So wether you are using JSON from your controllers, using an API DSL like Grape, or even using Sinatra, this could be useful to you.

At any rate, the fact that I am not consuming the json from within the same domain as its being served creates a security exception. There are a couple ways to solve this, but the most simple is to use JSONP. If you are not familiar with the difference between the JSON and JSONP, its simple. JSON is the simple structure of the data. When using an interface that supports JSONP the client suplies the API with the name of a function (callback) that should return the JSON when executed. So in order for my API to support JSONP each of my endpoints needs to watch for a paramater called “callback” and if its present wrap the generated JSON in a function using the name provided within the “callback” parameter.

Simple enough, but I don’t want to add this functionality to every endpoint. In fact I don’t want to specify that it needs to be done at all. What I would rather happen is if the data coming out of my application of type JSON, and the client submitted a callback parameter, then this should automatically happen.

Well we are in luck. Wether you are using sinatra or Rails these applications get mounted via Rack. Rack is a middleware layer that facilitates just this kind of magical transformations. And the best part is someone already wrote a JSONP middleware package to make it happen!

https://github.com/crohr/rack-jsonp

So inside your rails application, just add the “rack-jsonp” gem to your Gemfile and install it. Then inside your application.rb file add a require for it and use this code to initialize the plugin:

config.middleware.use Rack::JSONP

With that done, anytime your application returns JSON and the client has supplied a “callback” parameter, the output will automatically be formatted as JSONP.

If for some reason you did not want to automatically have the output converted to JSONP just because you submitted a parameter called “callback” then there is another plugin I found that may be more useful for you.

https://github.com/robertodecurnex/rack-jsonp-middleware

Hope you find this useful when the time comes to add JSONP to your next ruby application.

Mastering the viewport is the first part of the series. This tells you how you can instruct the mobile web browser on how you want your page viewed. It controls things like the zoom level the application starts at and with width it should be. The series then goes on to talk about toolkits and mobile specific css. Its a great crash course to get you started.

So I am going to post the link here for posterity, but also to share it with you.

http://davidbcalhoun.com/2010/viewport-metatag

Check it out if you are looking into doing mobile web dev.

Update: Here is another link that has more info onmobile viewport and scrolling divs.

I have had so many people ask me my thoughts and what I am doing based on Adobe announcing that they are going to stop developing Flash Player for mobile devices as well as on Adobe laying off a large number of their employees.

I don’t want to comment on this just yet as much of the news surrounding these things has been based on rumor and speculation. Several of the items I was upset about have already been proven to be inaccurate. So I am just gonna wait till early next week to make sure that the opinions I share are based on facts and with a level head.

What I can say is that I am sorry to all the Adobe employees who lost their jobs this week. As that is a much bigger issue in the grand scheme of things than wether or not our phone can play punch the monkey ads on our phones.

For those who don’t know (aka my flash buddies) CoffeeScript is a simplified language with many powerful features that gets compiled to Javascript which can be natively executed in the browser. Much like MXML gets compiled to ActionScript in the Flex SDK.

At any rate I found an online The Little Book on CoffeeScript by Alex MacCaw and in the syntax section i found the first real useful example of why I would want to use CoffeeScript. Many of the issues that occor with normal Javascript use come down to variables not being correctly var’ed and developers not understanding how to correctly trap variable scope. Out of the box many of these things are fixed with CoffeeScript. But I feel like the real power lay in the lightened syntax and the use of comprehensions.

So if you feel like you want to get a feel for what CoffeeScript is all about. Please check out Alex’s “Little Book” on CoffeeScript.

Recurly sends all notifications to the same url, but with a different xml document. I needed to find the root node name so that I could process the push notification correctly. With most xmlNodes in CF its very easy to find out what the name is from the xmlName property. Unfortunately if you reference the results of xmlParse, there is no xmlName or any other of the common attributes.

Luckily after digging I found this document on Adobe’s livedocs that showed an example that got me what I am looking for. And the result is that you can use xmlRoot on the xmldocument to get the xmlNode representation of the root node. This way xmlName, xmlText and xmlChildren work the way you would expect.

Just wanted to share since it took me a bit to find this.

Using Connect static provider module with Node.js its trivial to create a web server that can serve static files from a local directory. This has several advantages of allowing you to execute your content using http:// instead of the file:// url. For single page javascript applications this means chrome will correctly execute your AJAX calls. For Flash applications this means you can serve your bin-debug directory and have your swf’s execute in the correct security context.

The short version of this long story is that with this very simple bit of code you can have a web server running on the port of your choice. Requirements for this to work are to have Node.js installed, as well as NPM. Use NPM to install connect, and then save the code below as app.js.

var connect = require('connect');
var server = connect.createServer(
    connect.static(__dirname + '/public')
);
server.listen(8080);

Then from the command line run the following command from the directory where you saved the javascript file.

node app.js

You wont see any output on the command line, but you will have a web server running on port 8080 serving whatever files you put in the public directory which is relative to the app.js file. Just fire up your favorite browser and navigate to http://localhost:8080/ which will try to load the index.html file from that public directory.

You can only run one process on a port at any given time, but you can copy that file around and use it in several places if you change the ports.

Unfortunately the news surrounding the 2.7 release is not all positive. Adobe also announced that its shifting its focus from being completely cross platform on the desktop to focusing on developing new features for emerging mobile markets. If you read Dave McAllister’s post on reasons behind the shift it would appear that Adobe is making a well thought out change that best fits their customers needs.

However if you believe Adobe is doing what is best for AIR and its customers you would be missled. As a contributor and release manager of the popular FlexUnit framework I am very familiar with the companies that are building applications and the scenarios in which they are implementing their testing solutions. I can assure you that the majority of the companies that I have worked with, are implementing their continuous integration testing solutions on linux based hardware. While not a metric that can be readily consumed by adobe, these companies use Linux to test the applications which then get deployed to thousands if not tens of thousands of seats within their companies. Because Adobe provided support for a linux based testing solution, these companies chose AIR for their cross platform application development platform. And despite whether you test or not, this decision may affect you in the future. I have had to cancel one upcoming project for a company whose plan was to offer the application to its linux users in addition to its Windows and Mac OS users.

If you believe the very carefully crafted (PR saturated) content of the blog post announcing the redirection of the development efforts, you might think Adobe has not truly abandoned AIR on Linux. The message we are to take away is that Adobe has just transfered the responsibility of managing release for specific platforms to its partners. For instance Rim is responsible for developing AIR on its platform. Should HP want to implement AIR for WebOS, they have only but to join the Open Screen Project and they can have access to all the resources they wish. The problem with the strategy they are moving forward with is that many of the actual linux vendors have policies to not ship products that are not open source. All of the Vendors they have announced picking up the torch for their platforms are creating closed source products that benefit only themselves. The linux distribution creators have never had any reason to care if AIR is supported on their platform, it violates the principles of what Linux is all about. If this were not a carefully crafted piece of PR, the story today would be about the amazing partners who are taking up the torch to develop AIR on linux. Were AIR an open source platform, this news would mean next to nothing because as a community we could pick up the torch and continue to make releases that suite our needs. But now we are at the mercy of RedHat, Canonical and Sun to devote resources to a platform which gains them nothing. While we the users and developers are left searching for a solution that will allow us to truly build cross platform applications.

In the end only time will tell if this is really the death of AIR as a cross platform development platform for the masses. But without enterprise companies being able to develop and test the application within their existing infrastructure I expect this will be just another reason for people to reinvestigate the power of HTML5 and competing technologies from other companies.

During the discussion we will talk about the differences in architecture between Flex for the Desktop and Flex Mobile. We will talk about Views and ViewNavigators and we will look at how to move data between them. We will also talk about testing your applications locally and on the phone. And lastly we will talk about how to deploy to Android and iOS devices.

You don’t have to have any knowledge before hand of Flex or Mobile development. You will need a laptop with Flash Builder 4.5 installed. And Adobe has been kind enough to provide a free trial of Flash Builder for you. And if you have one, bring along your Android phone and your usb cable and we can actually run the demo code on your phone.

So come on out to the PDX RIA May meeting, and have some mobile fun. And if you make it out you will be rewarded with a chance to win a copy of Flash Builder 4.5! See you then.

If this is the beginning of the Javascript age, what are Flash platform developers to do? Well honestly I say you join them :) Our experience with the struggle of thick client development transitions into the browser very well. And Node.js is just as powerful as a backend to Flash as it is to anything else.

On monday of this week I had the opportunity present “Put some Javascript in your backend” at the 360|Flex conference in Denver. I think the session went really well and many people were excited to see the power available in Node.js. As ECMAscript brothers, Javascript and Actionscript are very similar to write. Both are event driven and writing Javascript code on the backend will be easier for most Actionscript developers than any other language.

In an HTML vs Flash world I tried to emphasize the way these tools can be used together to leverage the strengths of both platforms. Node.js is an amazing platform for real time communication and high load API’s which are required for mutli-player gaming and social mobile applications. The Socket.IO project adds to Node.js amazingly simple API for building real time applications in the browser. Utilizing WebSockets if available and failing back to several options including Flash Sockets, Socket.IO creates a simple API for applications that require real time communication.

In preparation for my presentation I wanted to demonstrate how Socket.IO could be utlized from Flash as well as from HTML. In the end I created a new project called FlashSocket.IO. FlashSocket.IO is a simple library that wraps up the web-socket.js (part of Socket.IO) library and facilitates easy communication with Socket.IO services. The FlashSocket.IO project handles the handshake and heartbeat functionality as well as serialization of object messages.

With FlashSocket.IO it is trivial to allow Flash clients to communicate with Socket.IO applications, allowing for amazing mashups between html and flash clients. As an example of this for my presentation Aaron Boushley and I created NodePoll. NodePoll is a simple application which allows users to vote on poll questions in an html client that works smoothly on all platforms. Using a Flash presenter application, you can push out new poll questions and watch a live dashboard of voting as they are sent in from clients. NodePoll provides a great example of utilizing rich Flash charting to report the results of an HTML client that can be accessed from just about any browser.

So in the age of Javascript where do flash developers fit? In the exact same place they have always. Building rich interactive application, which utilize the best parts of all available platforms.

I have not posted my slides, but I have posted all of the examples from my presentation on github. So please feel free to check out those here: https://github.com/simb/Jass

Do games have a place in the HTML/JS part of the world? Of course. Is the ecosystem and tools around HTML games perfect? Of course not. But with time it will get better. However if you are in the market to create games, the Flash Platform has already spent years working out these issues. The HTML communities will undoubtedly make great strides in this area, but for now Flash remains the dominant platform for Browser based gaming.

So when it comes down to choosing between Flash Platform and HTML in the browser for your next application, keep in mind the tools available and the maturity of the ecosystem around the types of applications you want to build.