Galpin on Rails on IBM

A couple of pieces that I wrote on Rails appeared on IBM at the end of last year. I didn't even realize it until today when somebody emailed me about one of the articles.

The first article is part one of a four part series on using Rails, XForms, and DB2's PUREXML tables together. I also wrote part two, but another writer wrote parts three and four. Only part one is up so far.

The second article is the third tutorial I wrote on using Eclipse as a web development platform. Part one was about using Eclipse for Java web development, and part two was on using it for PHP development. The last tutorial is on using Eclispe (via RadRails) for Rails development. Note, the link for part two shows the intro page to part one. If you login, it correctly gives you part two. Clearly some kind of technical glitch for IBM!

Mac Java 6

There's been a lot of developers upset that Leopard does not include Java 6. Does this make the Mac a poor choice of Java developers? No, it doesn't, not yet at least.

First of all, I fully expect that Apple will release an update to Leopard that will include Java 6 before the end of the year. But it doesn't matter too much because Java 6 was mostly a performance release for Sun. There's some nice things in the Swing implementation included on Hot Spot. Neither one of these things is even relevant for Apple. There are some language features (debugging, StAX parser) but these are pretty minor.

So to me it doesn't matter too much that there is no Java 6 for the Mac. Oh, but there actually is, or was. I personally had some problems with it, so I wasn't too surprised that it's no longer available from Apple.

Things only become problematic if Apple takes a long time to support Java 7 when it comes out, especially if you assume there will be a lot of language changes in Java 7. If that happens, then it could be conceivable that developers won't be able to use OSX. Others have pointed out that a major litmus is Eclipse. If Eclipse will run on OSX, then all is well. Eclipse 3.3 was released just a few months ago and was the first version of Eclipse to require Java 5... Eclipse is obviously important for Java developers, but also for Flex developers and even PHP developers.

Ning Code

I was leisurely sifting through feeds in Google Reader when I came across a new one from the Ning dev blog. It was about enabling public feeds in private networks. They explained why this was a hard problem (it is) but how you could enable it given some security caveats (so far so good.) One of the keys is changing the source code for your network, which is very cool. That's where the coolness ends. Here's an excerpt:

To change the display code, first visit the file /lib/XG_TemplateHelpers.php and find the function xg_autodiscovery_link(). Remove the if (XG_App::appIsPrivate()) { return; } text (but leave the ?> at the end of that line.)

Next, visit the various templates that might display RSS links. These files are:

• /widgets/forum/templates/category/list.php
• /widgets/forum/templates/topic/list.php
• /widgets/forum/templates/topic/show.php

That list is actually much longer, but you get the point. Umm, hasn't anyone here ever heard of encapsulation? PHP supports OOP, or at least enough of it to easily hide this particular flag so you don't have to remote it in twelve places!

It's That Time Again

Time for Terry to fan the flames and listen to the ROR... In truth Terry is an avid Rails freelancer. He charges even less than what "average" PHP programmers charge for their hackin', just because he enjoys The Rails Way so much. When he says he is "sick" or "drunk", he's actually busy creating another blog site with Rails (he's up to twenty-four now, and is yet to write a single line of configuration.)

Writing a Facebook App

I've been writing a Facebook app. They offer a Java client library (as well as several other non-official ones for other languages) but I'm using the PHP one. I really like the library they include. It has been incredibly easy to use, even for a PHP hacker like me.

One of the best parts of their library is the FaceRestClient call_method function. Only problem is that it does not work with photo uploads. Of course that happened to be one of the things I wanted to do. It doesn't work because you need to set a multi-part mime header for a photo upload and format the binary data per that content-type. Obviously all this can be done by hand, but luckily I found something better: the photos lib. This makes it trivial to upload an image. Here's the code I wrote for it:

 include_once 'facebookapi_php5_restlib.php';
 include_once 'facebook_php5_photoslib.php';

 // get your own api_key and secret!
 $facebook = new FacebookPhotosRestClient($api_key, $secret);
        
 // user logged in prior to uploading pic, so sesion key passed as param
 $session_key = $_REQUEST['session_key'];
 $facebook->session_key = $session_key;

 $tmpLocation = $_FILES['uploadedfile']['tmp_name'];

 if (is_uploaded_file($tmpLocation)){
  $aid = $_REQUEST['album'];
  $caption = $_REQUEST['caption'];
  $res = $facebook->photos_upload($tmpLocation, $aid, $caption);
  echo "Here is a link to your pic, make sure you approve it first:".$res['link'];
 } else {
  echo "Ye gods! Something went wrong!";
 }
?>

Facebook

I must admit, the hype about Facebook's F8 platform has got to me. First, I started playing around with my very under-utilized profile on Facebook. I added some apps: Flickr and Twitter. These are "apps" on my blog as well, so they seemed natural enough. Then I added the most popular new Facebook app, iLike. I figured it would be similar to last.fm, which I had on my blog. I even went to the iLike site, signed up, and insalled their "sidebar" for iTunes.

What a disappointment! First, there is no connection between iLike and the iLike-Facebook-app. To add songs to the iLike-Facebook, you must do it manually. Ick.

Next problem, the iLike sidebar is very buggy. It seemed to keep my CPU utilization pegged. It didn't matter if I was listening to a song or nor, or if "hid" the bar. It's obnoxious anyways, taking up way too much real estate for an application that is a complement to another (iTunes.) When I realized that the songs I listened to on iTunes were not showing up on Facebook, it was obviously time to uninstall iLike.

Ok, so back to Facebook. I like the idea of their platform. It's much of a real platform than any of the widget/gadget/whatever platforms out there. They give you access to Facebook services, and give you UI tools for integrating your app's UI into Facebook.

What's interesting to me is to compare it to Ning. A Facebook app does not live on Facebook. It lives somewhere else. It can communicate with Facebook and its UI is shown inside Facebook. A Ning app lives on Ning. The Ning app must be written in PHP. The Facebook app can be written in any language. An app on Ning gets to take advantage of Ning's scalability. An app on Facebook can see huge traffic, but your server/hosting provider has to able to handle that. You had better find some quality, cheap server hosting.

Obviously I have some special interests in all this. At Ludi Labs, the Roost website had some similarities to Ning. It was a build your own site (we didn't add the social networking adjective) using all of these great services. Of course Ludi failed and Roost was never available to the masses. Thus I find myself rooting for Ning now. I think F8 poses a real problem for them...

Web APIs: Flickr vs. GMaps

I was doing a little research on web APIs. Two of the better ones (or at least well known and used) out there are Flickr and Google's Map (GMap.) They present two very different ways to enable third party developers to leverage powerful web services. So I thought I'd do a little compare and contrast.

Flickr's API is a classic procedural library. There are calls for almost any action you could possibly do with all things Flickr : photos, account, tags, sets, etc. You can upload photos, access photo streams, search by tags ... pretty much anything you can do on Flickr's site. Each call is a different HTTP request. You can send the package of your request in a variety of formats: REST, XML-RPC, and SOAP. The REST and SOAP follow the usual patterns for these formats. The REST requests are "pure" HTTP requests. Flickr's XML-RPC is very true to the RPC mode. It uses simple XML to specify a procedure to call along with it's parameters.

You can also specify the format of the response you get back from Flickr. Since they support REST, XML-RPC, and SOAP for requests, it's not surprising they support all these for responses. They recently added JSON and PHP as response formats. I was pleased to see JSON. I can imagine that if I was going to use Flickr's API, I would probably choose to use REST+JSON. Make a pure HTTP request and get back a JavaScript object. Seems like the lean-mean approach to me. I was surprised to see PHP as a response type. In this case, they are referring to serialized PHP objects. The structure of these objects is identical to the JSON structures.

GMaps is different in many ways to Flickr. Instead of supporting procedural calls to Google, everything is object oriented JavaScript. You include a library from Google and then use their objects. Many of their objects provide methods for making calls similar to what you see in Flickr. For example, you can geo-code a location, calculate directions, etc. But you don't make the HTTP request and you don't parse a response. Google's JavaScript objects do these for you.

The differences in these web APIs reflect the differences in these web services. Flickr is more of a pure data service. You can modify data (photos) and query that data (search for photos, etc.) Flickr wants to be your photo database. As such, they give you a number of ways to access your data. What you do with the data is up to you. Show your pics on a website, provide tools for uploading, print the pics, make aprons, whatever...

GMaps wants to draw maps for you. They don't want to give you mapping data for you to do whatever for it. They want to draw. They'll take your data and draw maps with it. They always draw the map, so they give your users a familiar interface that also integrates into Google. All roads lead back to Google.

Thus the APIs to these services are very appropriate for the services. I don't know for sure, but I'd wager they also reflect the programming design behind the services. It seems pretty obvious that Flickr is written in PHP and that Google Maps is written in Java (maybe the last one is less obvious, but I do have a little inside information on that one.) So it's not really surprising that a PHP site would have a very flexible, procedural API, and that a Java site would have more closed, object-oriented API.