While its only 4 lines of Javascript code to create a webserver with Connect or Express, its still a file you have to create each time you want that functionality.

Enter HTTPster (Hipster). HTTPster is a command line utility that will allow you start an HTTP server to load the files from any given directory on your filesystem. The library is based on Node.js and NPM so you will need to have them installed. From the command line you can run:

npm install -g httpster

This will install the httpster library as an executable on your system. Then just cd to whatever directory you want to server content from and type:

httpster

This will launch a simple http server running on port 3333 which can serve any file in that directory. If you want to change the port its running on just pass the -p option.

httpster -p 8080

Thanks to @GarthDB the app even has a pretty logo and site. Let me know if you have any suggestions for future enhancements. Code and Issues on Github.

So I searched the internets for things like “disable ios bookmark popop” and “phonegap disable bookmark” and “iOS bookmark popup”. But I came back with no hits. It wasn’t actually until I had gone another route in trying to solve the problem (using divs and spans instead of a) that I found the solution.

Using CSS we can disable the callout by using the -webkit-touch-callout property. The options are default|none|inherit.

-webkit-touch-callout: none

You can apply this to just your a tags or to items more specific. If you are actually using anchor tags to display standard hyperlinks in your application you might want to let people bookmark or open in safari. But at least with this you have a choice.

Adobe owns all copyright and trademarks to the Phonegap brand. Cordova is the name of the open source project that is under development by many contributors across many companies. Think of Phonegap as the Adobe sponsored implementation of Cordova. Much like Google and Apple have Chrome and Safari which both implement the open source Webkit project.

Callback is dead. Phonegap is a brand. Cordova is a project.

Disclaimer: I am not employed by Adobe or Nitobi and am just offering my opinion on how this all came about. I hold no insider information on this so if I am wrong, please correct me in the comments so we can actually get this straight.

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.