Today Wycats posted about possible inclusion of method_missing into javascript. This overwhelms me with glee. I don’t know who we have to grease to make noSuchMethod a reality, but you can put me down for fifty bucks.
I know better than to get my hopes up, but now that they are up I might as well try to help.
So write your standards expert and tell them this is important.
I have long been a fan of JSON. At RideCharge we still work with xml and soap, and they are fine (still better than FTP drops). The truth is when you have to do B2B work you usually agree to almost anything to get your work done.
But when you release a web service for public consumption, you really need to think about in what format you want to expose your data. We expose most of our APIs in JSON, XML, and YAML. We only get this luxury because it takes almost no effort to do all three. I mean, come on, who would expose something in YAML otherwise J.
That is why it was semi surprising when Google quietly announced their new server-side AJAX API would be JSON only. At first it made very little sense to me, but after some thought, it makes reasonable sense. I declared that 2007 was going to be the year of JavaScript Only APIs (I am a tech blogger not a futurist), because Google released their AJAX Search API as JavaScript only. But now I see it is much more about supporting only one output format, JSON. Whether it is consumed by you, me, Google or Google AJAX JS API. They realize their data is valuable enough, if you want it, you will write:
JSON.parse(response.body)
After seeing about a hundred posts on git, I decided to give it a try. It seems to be much better at branching, merging and most importantly submitting patches. And for that reason I decided to dump svn in favor of github for simpltry widgets.
I encourage you to fork my repository and send me a pull request. Or if you don’t want to fork my project, you can fork prototype or rails. What I am really saying is, if you want to contribute to the ruby open source community you are going to have to break down and learn git.
Starting today, I am going to be working on [iUi](http://code.google.com/p/iui/ “iui - Google Code”). iUi was initially developed by [Joe Hewitt](http://joehewitt.com/), he has since gone on to build the iphone version of [facebook](http://www.facebook.com/ “Facebook”). iUi hasn’t seen many updates over the last few months, but I am a firm believer that it is and can continue to be the best way to build an iPhone version of your website.
I committed my [first patch](http://code.google.com/p/iui/issues/detail?id=63 “Issue 63 - iui - Google Code”) to the project today. The funny thing is that the commit happened on the same day [Apple](http://www.apple.com/ “Apple”) finally [announced an event](http://www.tuaw.com/2008/02/27/get-your-sdk-engines-running/ “Get your SDK engines running - The Unofficial Apple Weblog (TUAW)”) that *might* reveal the details of their native SDK. I guess that won’t negate the importance of native iPhone webapps.
After seeing the [staggering number](http://www.macrumors.com/2008/02/05/iphone-with-28-of-u-s-smartphone-marketshare-for-q4-2007/ “iPhone with 28% of U.S. Smartphone Marketshare for Q4 2007 - Mac Rumors”) of iPhones sold in the forth quarter, I decided it was time to port my [site](http://dcrails.com “DCRails.com || Making the Metrorail fun!”) to the iPhone. As of a few days ago there is an iPhone version of [DCRails](http://dcrails.com “DCRails.com || Making the Metrorail fun!”). It was a joy to build!
It was built on the back of the [brilliant work](http://code.google.com/p/iui/ “iui - Google Code”) by the amazing [Joe Hewitt](http://joehewitt.com “JoeHewitt.com”). But this brings me to my announcement, Joe also brought [firebug lite](http://www.getfirebug.com/lite.html “Firebug Lite”) to the iPhone. It is a very cool piece of code that proxies **console.log** output through a server-side proxy and displays it in a local browser. The flip (and equally cool) side is you can execute arbitrary javascript from a local browser and have it run on the iPhone. It is called [iBug](http://www.joehewitt.com/blog/firebug_for_iph.php “JoeHewitt.com”), I am not sure my description does it justice, so give that article a read.
Anyway, iBug relies on you starting a little python webserver locally. Unfortunately, this is was problematic, since it relies on iFrames having access to the **parent** window. This poses a security risk since mongrel and iBug were on different ports (XSS police are comin’ to get ya!). So, I ported his webserver over to mongrel. This was very challenging for me, it took me far out of my normal element. I had to learn the following technologies to get this to work, [mongrel handlers](http://mongrel.rubyforge.org/rdoc/index.html “Mongrel”), [comet](http://cyll.org/blog/tech/2006-08-09-themongrelcomet.html “Topher Cyll”), and a little threading in Ruby.
Anyway it isn’t completely done, it looks a little like someone ported some python to ruby, and it could use some polishing, but it does work and I would love some feedback or patches. To get started, install the plugin and read the README file (it’s shorter than this post).
script/plugin install http://svn.simpltry.com/plugins/iphone4r
There are 2 more things, you must use mongrel, and mongrel will have trouble stopping because of an intentional infinite loop (suggestions are welcome).
