Andrew Powell

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

Until recently, I've always used the XML mapping files to define my persistence model with Hibernate. I was not real keen on the idea of using meta to define persistence in the objects themselves via annotations. However, I decided to give it a shot recently. My main argument had always been that by using the XML mapping, my persistent objects are not tied to Hibernate, exclusively. When I stopped to think about it though, one thought really hit me hard: I don't use any other ORM for my Java code. Why would it matter if the meta for mappings is in the code?

This being said, I wanted to pose a question: Is there a benefit to using annotations over XML mapping (other than JVM compatibility)? Your thoughts in the comments, please.