Andrew Powell

Inspiration comes from all places. Sitting in Ryan Stewart's presentation at 360Flex this week, I got hit with the geolocation bug again. I saw some of the demos that Ryan was doing and figured that I can take some of those a bit further. This gave me a chance to do some work with HTML 5 and AIR for Android as well.

Seeing Ryan's presentation, I took the initiative and updated one of my old samples around Yahoo! Local Search and Adobe Spry. The old version actually asked you to provide a city state pair to do the local search. After taking a look at how Serge Jespers was using an ExternalInterface call to get HTML5 geolocation data into Flash, I took the same approach to grab the latitude and longitude from the HTML5 geolocation API and pass it into the ColdFusion service that I'm using to abstract the Yahoo! API. The end result, which works in any HTML5 enabled browser looks like this:

Migrating this example to HTML5 was cool, but I felt like there was still something missing. I banged out the HTML5 version pretty quickly because I was migrating existing code. I needed a real challenge. Ryan's examples had all been based in AIR for Android. I had been signed up for the prerelease for a while, but hadn't been able to think of a compelling app to build. I decided to take the HTML5 app that I had just created and build an AIR for Android version, so I fired up IntelliJ IDEA and went for it. I figured a listing of the elements wouldn't be a good showing of what AIR for Android can do, so I decided to sexy it up a bit. I added in some nifty native geolocation functionality and some of the new uri based functionality to trigger the phone system, i.e. tel:4045551212. Since it was a Flex 4 application, I decided to use my Flex framework of choice, Swiz, to help me build the application quickly and keep my code organized. I picked up a beer from the 360Flex party on Tuesday night and then headed to my hotel room to crank out some code. The result isn't pretty, but it is pretty darn cool.

When the application starts up, it will check for the current location and center the map on that latitude and longitude. When you do a search, it will call the same ColdFusion service that the HTML5/AJAX version is using to get the local search results. It then leverages the MapQuest 6 API to plot the data. I added a double-click handler on the POIs to trigger phone calls to a given location.

Download the APK here. Warning, it's still just a POC quality, so you may need to force quit the application to keep it from eating all of your battery.

If you're an Atlanta area (or even Macon / Augusta / Chattanooga area) developer and want to learn more about how a developer sees user experience design, make sure you come to the Atlanta Flex User Group meeting tomorrow.  I will be giving my presentation:

It's guaranteed to make you laugh, cry, or angry.  I'd like to say it's entertaining, but that's just a bit more shameless self-promotion than I'm willing to do (at this time).  I think that this presentation is well suited to any type of developer (not just Flex) that wants to learn more about what exactly user experience design is.  I've heard, even Sledge Hammer! might be making an appearance.  

A few months ago, I started a project to make a framework for ColdFusion to enable its functionality as an Enterprise Service Bus (ESB).  I kept running into roadblocks in my mind as how to structure things, but I realized something.  Everything I was trying to do to make ColdFusion an ESB was simply hindering tasks that were already easy to do.  ColdFusion, out of the box, can function as an ESB.  

It wasn't always this way, but over the years, with the addition of things like JMS gateways, .NET integration, HTTP, and FTP integration; it's easy to create workflows that receive data from an input, processes it, and sends it to another destination.  ColdFusion 9 enables this even more so with the addition of Sharepoint integration. 

Why worry about installing something like Mule?  ColdFusion already does everything you need it to do out of the box.  ESBs are the next generation in integration.  ColdFusion just makes it easier and faster than traditional Java or .NET based solutions. 

The early bird pricing for Flash Camp Atlanta ends in less than 24 hours!  Tickets are on pace to sell out soon, so if you don't want to pay more later, go sign up now.  The early bird pricing is dirt cheap, only $40 for the main session and $15 for the introductory session ( an intro to Flash, Flex, and AIR ). 

Spring has been, is, and will continue to be the easiest way to deploy enterprise class services with your Java applications.  There is a common pattern to the way Spring lets you expose your beans as services.  What this means is that the methodology for exporting a bean as a Hessian service, a Burlap service, a WebService, or now, an AMF Service (via BlazeDS) is consistent.  This consistency is what BlazeDS needed to be accepted into the Spring world.

Until the release of the Spring / BlazeDS integration by Spring Source, Spring has always been a bit of an interloper when it comes to BlazeDS.  Sure, Jeff Vroom's SpringFactory has served many of us well for a long time, but it was always something extra that had to be added on to the BlazeDS configuration.   To make it work, the services-config.xml file had to be modified and you had to specify special properties within the remoting destinations of remoting-config.xml.  It was a lot of steps to make something that makes things simple work with BlazeDS. 

Using the Spring/BlazeDS integration, it is no longer necessary to touch anything in the services-config.xml (unless you're changing the channels) or the remoting-config.xml files.  It just works out of the box by exporting your spring beans just as you would for any other remote services.  This consistent methodology will make it easier for teams to choose to use BlazeDS, and in turn, Flex for projects.   It means that teams will get the benefit of AMF with, possibly, no refactoring of the service layer.  All one would need to do is generate the AS classes to match the resulting datatypes (XDoclet can help a ton here) and you're done with the middle tier.  This allows for more development time to be focused on the Flex layer instead of being mired in getting the middle tier setup.  

By becoming more like other remoting methodologies in Spring, it appears that AMF and BlazeDS are ready to become prime-time players.

Recently, I've been playing around with ideas of how to improve site performance.  One of the things we've done in the past, to improve performance, is move all static content to a separate server, on the same network, so that your application server (ColdFusion, etc) is focused on only processing your application pages.  All static content is served from the "static" server and can be configured with things like content expiration and caching to help speed up site loading.  Recently, however, Amazon has made great strides with their Simple Storage Solution (S3) platform.  More directly, they have introduced CloudFront which can distribute your content to their edge servers from a S3 bucket.  What does this really mean for you?  Well, much like Akamai, CloudFront makes sure that your users are pulling the content from the server that is closest to them.  CloudFront uses the following edge locations:

United States

• Ashburn, VA
• Dallas/Fort Worth, TX
• Los Angeles, CA
• Miami, FL
• Newark, NJ
• Palo Alto, CA
• Seattle, WA
• St. Louis, MO

Europe

• Amsterdam
• Frankfurt
• Dublin
• London

Asia

• Hong Kong
• Tokyo

So, no matter where your users are, there is probably a CloudFront location near them, which means faster content delivery.

Getting your content up on CloudFront is pretty easy too.  You can use the Manager For Amazon CloudFront to help you create CloudFront distributions from your S3 buckets.  Just a note, there are CloudFront limits you to 1,000 Mb per second of transfer and 1,000 GET requests per second.  If you expect your application to go over that, then you've got a pretty popular application, but Amazon can accommodate you.  

So, what is the difference between S3 and CloudFront?  S3 sets you up in one of two locations:  United States or Europe.  CloudFront distributes your content to edge servers around the world.  While S3 is fast, it is not as distributed as CloudFront.  I have, recently, switched all the static assets of this site to be hosted on CloudFront.  Take a look at the activity when you load this site and you will see a dearth of images coming down from "static.infoaccelerator.net", which is my CNAME to my CloudFront distribution.  

CloudFront is a very cost effective and reliable way to help improve the performance of your web applications.  It scales itself for you, and, it costs less than a new server to deploy.  If you're looking for a low-cost, fast and reliable hosting provider for static content, go take a look at CloudFront.

FlexServerLib , the extension project for BlazeDS, is a powerful library that allows you to access functionality on the server, in Flex, as easily as ColdFusion allows developers to access complex server functionality in CFML.  Imagine if sending an email was as easy as sending a message into a destination and receiving an email was as simple as subscribing to the same destination.  This is just some of the functionality FlexServerLib aims to implement.

A topic has been submitted on FlexServerLib for 360|Flex Indianapolis, but if you want to learn more, we need your vote.

Follow this link to vote

Most of us use tools like Charles or Service Capture to help debug our web applications and flex applications.  They show you the AMF data going back and forth between your browser and the server.  It's all very helpful.  However, there's a little trick if you are trying to debug traffic to a local instance of a server.  Say you're running tomcat locally and are trying to debug the calls with one of these tools.  In your browser, you would put:

http://localhost:8080/mycontextroot/myapp.html

This works to test the app, but you don't see anything in your debugger tool. If you want this traffic to show up in your debugger, you need to use the following variation on the url:

http://localhost.:8080/mycontextroot/myapp.html

This will ensure that you do not bypass the proxy settings used to route your web traffic through the debugger.  

In listening to people complain about different languages (MXML, AS3, Java, ColdFusion, C#, etc), most everything someone lists as what they love/hate about the language is a function of the IDE.  The IDE, in turn, is usually built around the functionality of the language.  I guess what I want to know from you is, would you be less down on a language / technology if the IDE was better to work with?  In Java, if you don't like Eclipse, you can go to IntelliJ, and vice versa.  The .NET languages tie you into Visual Studio, for the most part.  Flex, until recently, was limited to FlexBuilder.  Anyway, your thoughts on the issue would be appreciated.

Does the IDE influence how much you love / hate a language?

I did this last time around, so here it is again, my session survey results.  Did people love me?  Did they hate me?  Did they care?  Well, the ones who cared enough to fill out the session survey did enough to fill out the survey.  Either way, enough rambling, here's the link:

Survey Results