Cobalt Edge

My infatuation with RubyCocoa continues. I've been working on a small app for the Building Web Apps folks. I'd originally been tasked with a feature that was to be done 100% within the web app. However, some of our requirements changed, and the workflow was not efficient enough. So, essentially what we moved forward on was a desktop Mac application that could interface with NetNewsWire, as well as the Building Web Apps site. The desktop app gives us a faster way to add data into the system - rapidly processing a ton of content and injecting what is desired into the web app, yet without getting slowed down by a web app interface. AJAX or Flex, or some other web UI tech wouldn't make it any faster in this particular situation.

Thus, I pursued building a Cocoa app, but this time using RubyCocoa. I've written Objective-C apps before, and spend the bulk of my time in Ruby, but this was my first opportunity to use RubyCocoa. The combination, much like JRuby, Jython and other hybrid systems, gives you "the best of both worlds." There are cons of course (slower, a few Cocoa things you can't do, debugging is harder, etc.), but for the most part, it's really nice.

For me, the infatuation stems from letting me use the aspects of each system that I am either more efficient with, or that are easier for a particular piece of functionality, all yielding a faster, and better end result. I can iterate on the app more quickly, and get a solution to BWA faster. And, one step further in the case of RubyCocoa: having the native OS integration abilities at hand.

What's been great is the ability to use Ruby's more effective (for me at least) string processing, XML processing, and networking features; create a native Mac application - using any cool Cocoa/native features; and support for AppleScript, which was critical for this particular application. This latter feature ruled out using something like Adobe Air.

This evening I setup the second use of AppleScript/Apple Events in this app: registering a custom URL protocol for the app. Applications like Pukka and Mailplane do this. What for? Well, in this case, it allows me to create a web browser bookmarklet, that can send data from the browser to our app. It also means that it works in basically any browser on the Mac (as opposed to AppleScript not working for Firefox). Further, it allows a simple "push a button" in the browser to send the data over to the app, as opposed to having to switch to the app, pick a menu item to pull the data, or horror of horrors, copy-paste.

How do you do this? This article is short and covers how to do it in Objective-C. It's just as easy in RubyCocoa: You need to add an entry into your Info.plist file to specify the name of your URL protocol as described in the article. Then, you need to register your app as a handler for that protocol:

NSAppleEventManager.sharedAppleEventManager.  setEventHandler_andSelector_forEventClass_andEventID_(    self, :getUrl_withReplyEvent, fourcharcode('GURL'), fourcharcode('GURL'))

The fourcharcode method is my way of translating four character codes for use in Ruby. I discussed this in more detail in my last post about RubyCocoa, but here's the actual method for your pleasure:

def fourcharcode(character_code)  character_code.unpack('N').firstend

Ok, so now that you've registered your app to handle its custom URL protocol, you will get an Apple Event sent to you with the URL whenever one is opened. This is handled (as per the parameter in the registration function above), by the getUrl_withReplyEvent method:

def getUrl_withReplyEvent(event, reply)  url = event.paramDescriptorForKeyword(fourcharcode('----')).stringValue  # url now contains the complete URL as a string  # do your processing of the URL/content...end

That's it. Pretty cool eh? Handling events from NetNewsWire is almost identical (register for them, write a handler function).

And, one more great thing I could integrate: Sparkle. Sparkle is a superb Cocoa library that does automatic application updates. It checks the web for a newer version of your app, downloads it, and installs it. Integrating it is simple, and in fact, depending on your needs, you don't have to write a single line of code. The only code I wrote for it was actually a Rake task to build the appcast and upload it to the server. Slick.

All this could only be done as a native Mac app, which means Cocoa. But, as said above, doing it with RubyCocoa gives me access to all these abilities, yet, I can do all the more heavy string and XML processing I need to do using Ruby, which is much more effective for me. Also, the web services calls and code is a lot easier for me to do in Ruby than Cocoa.

Furthermore, this is plain fun! Unlike some, I feel desktop apps still have a place, but love webapps at the same time. With RubyCocoa I can build super cool Mac apps, but do so in a language I'm happier using, yet have the power of Cocoa available to me. For me, some of the best "applications" these days are such hybrids: a web app that does your primary data storage, and gives you access to the app from "anywhere" (i.e. anywhere you can get to a browser and net connection), but a desktop app to use most of the time for faster interaction, potentially better integration on your desktop system, and so on. It's the same reason I use Mailplane (desktop app for Gmail), or PackRat (desktop app for Backpack). I suspect it's the same reason we're seeing other solutions like Adobe Air, or Google Gears. Technology is so cool, isn't it?!

For a few months now we've been seeing more offline web app support. This includes technologies like Apollo, some of the tricks people are using with Firefox (like ), http://www.blogger.com/img/gl.link.gif, and lately .http://www.blogger.com/img/gl.link.gif

What amazes me is how much people want to seem to stay within a web browser. They're trying so hard to cram a feature into a space that wasn't designed for it, not to mention is just a crappy solution. No doubt there are a few nice uses of offline support for a pure browser-based app, but why haven't more people started to realize how much better they can do by going beyond the browser? Why do you want the browsers UI to be your dominant surrounding UI? Why do you want to be constrained to the browser's window, and force your user's to have your app running in another http://www.blogger.com/img/gl.link.gifapp, that doesn't have it's own dock/task bar icon or ability to interact with the OS?

I also don't think it's an all or nothing situation. I value having a browser-based UI available to me, so that when I'm not using one of my computers, I can still view my data. I don't expect the experience to be as good, and it can lack features, but I can get to the data in a pinch. But, I would much rather have dedicated applications for the "web applications" I use a lot. Examples of this would be Backpack, project tracking systems (currently I use Scrumworks, which has a Java desktop client that works with their web app, and Basecamp), music players, weather watchers, GotAPI, Twitter, and many others.

There are some examples popping up. Twitter has Twitterific, and FineTune has their Apollo player. These are both excellent examples of how deficient the browser is for many web applications, and how much better you can do outside the browser.

I admit that Apollo is really what took my thinking on this to the next level. You no longer have the excuse that you don't know native code or native code toolkits and such. Building an Apollo app can be done the same as you'd build a web app, and even gives you the choice of Flex or HTML, or a combination (this gets very powerful). You can even simply pop an existing web app into an HTML view in an Apollo window, and thus have a dedicated application (doesn't give you much more but at least you aren't just a tab in your browser, and can display it on a different virtual desktop or size the window differently than your browser window, etc.).

To make this more positive, this is a call to all web developers to think hard about this. Even if you don't need offline support, or you don't need it right away, think about the user experience and how you might create that much better of an app by not being constrained to a browser. I won't have anything in the next week, but yes, I'll be eating my own dogfood, and having some apps out soon enough (watch this space).

Today is the big day for us: our two presentations at RailsConf. In the morning my co-worker, Chris Haupt, and I are presenting a session purely on Apollo. If you don't know much about Apollo, or want to find out more, join us for this. Then, in the afternoon, we'll jump into using Apollo with Rails, and our experiences in that regard. Both talks will include demos and code.

If you attended Peter Armstrong's BOF on Flex and Rails last night (which was great, good job Peter!), come see the Apollo talks to see how you can take that even further with what Apollo adds to Flex.

My co-worker Chris Haupt has tweaked the TwitterCamp Apollo app, for displaying RailsConf tweets. Very nice. You can get it on the RailsConf wiki "Toys" page.

Following on ApolloCamp this past Friday at Adobe, you can now go and download the Apollo runtime, SDK, and Flex Builder extensions. Get it here. This is the coolest stuff, seriously.

For those of you interested in Apollo, check out the free ApolloCamp, on March 16th at the Adobe San Francisco office. See you there!

I just found out yesterday that the proposal my co-worker and I submitted for RailsConf 2007 was accepted! Quite exciting. I hope to say more later, but for the moment, the talk will be about using Rails and Adobe's new Apollo technology.

Adobe is doing another Understanding Apollo seminar. The last one was very good, so I'd encourage folks to check it out. I've been doing some work with Apollo and it's really cool. The ability to create web apps that work online and offline has been a huge interest of mine, and really ups the usefulness of many apps.

We're hiring at Adobe (we always are, but my team specifically)! We have two positions, with one being essentially more senior. See the job descriptions below. If you're interested, and meet the requirements, email me your resume (in PDF) at chris.bailey at adobe dot com.

The Digital Imaging Services team at Adobe Systems is looking for a superior web services developer to help us make our hosted applications and web services architectures best of class in an entrepreneurial and fast moving environment.

You need to have serious Web Development chops targeting LAMP-like platforms using the latest tools. This means you've implemented web services and hosted applications that utilize the latest dynamic techniques and languages, can simultaneously develop for multiple operating systems, know and use n-tier architectural patterns, can sling around SQL, a couple of scripting languages, and automate unit tests with ease, and may have even scaled up a hardware or network infrastructure or two. You should have demonstrated experience working iteratively and incrementally in an agile fashion with a high performance team. Be prepared to explain some of the architectures you've developed, answer coding questions, and tell us about your successes working with a dynamic team!

Knowledge & Skills:

• Expertise with developing multi-tier, distributed web application architectures and deploying in live production environments.
• Experience with Java, Ruby on Rails, or other current technology stacks required, experience with native code development in C/C++ a big plus. Four or more years of hands on LAMP (Linux, Apache, MySQL, Perl/Ruby) development.
• Experience using quality focused development practices such as heavy unit test and automation tool usage or Test Drive Development strongly desired.
• Experience of successful deployment of multiple iterations of a commercial/publicly accessible high traffic web service or application required.
• BS/MS degree in Computer Science (or equivalent).
• Must be able to work both independently and in a focused and efficient Agile engineering team that is geographically dispersed.

The Digital Imaging Services team at Adobe Systems is looking for a superior web services and infrastructure developer to help us make our hosted applications and web services architectures best of class in an entrepreneurial and fast moving environment.

You need to have serious Web Development chops targeting LAMP-like platforms using the latest tools. This means you've implemented web services and hosted applications that utilize the latest dynamic techniques and languages, can simultaneously develop for multiple operating systems, know and use n-tier architectural patterns, can sling around SQL, a couple of scripting languages, and automate unit tests with ease, and may have even scaled up a hardware or network infrastructure or two. You must have experience building infrastructure that is highly available and has had to grow quickly due to rapid uptake. You should have demonstrated experience working iteratively and incrementally in an agile fashion with a high performance team. Be prepared to explain some of the architectures you've developed, detail growing pains and solutions while scaling SW/HW/Net infrastructure, answer coding questions, and tell us about your successes working with a dynamic team!

Desired Talents:

• Analytic.
• Learner.
• Communication (written and oral).

• Expertise with developing multi-tier, distributed web application architectures and deploying in live, high availability production environments.
• Expertise with current commodity based hardware, networking, and software infrastructure and related Operations exposure.
• Experience with two or more of Java, Ruby on Rails, Perl or other current technology stacks is required, experience with native code development in C/C++ a big plus. Eight or more years of hands on LAMP (Linux, Apache, MySQL, Perl/Ruby) or similar development.
• Experience using quality focused development practices such as heavy unit test and automation tool usage or Test Drive Development strongly desired.
• Experience of successful deployment of multiple iterations of a commercial/publicly accessible high traffic web service or application required.
• BS/MS degree in Computer Science (or equivalent).
• Must be able to work both independently and in a focused and efficient Agile engineering team that is geographically dispersed.