If you want to see an example of how executive leaders can inject inspiration, fight, and stability across their company and supporters of their products; take an hour and watch Steve Jobs' closing keynote for the WWDC '97.

Note in 1997 Apple was just coming off the ropes. SImilar to an Ali / Foreman or Frazier fight. The web was just starting to mainstream and Microsoft was crushing everyone post Windows 95...

Apple was on an island, no strong network integration, they were really just sitting on the bench watching opportunities gone by. Steve Jobs changed all of this and you can see in his responses to the questioning his passion for not only the company and its new approach bringing laser focus to the customer; but for common sense innovation. So glad I got a chance to see this.

No matter what anyone thinks regarding Steve Jobs and his leadership abilities; his transparency and candidness is a true inspiration to those who aspire to leadership roles within their respective companies. Enjoy!

Start your engines...

You can get the scoop here:

http://blogs.adobe.com/flex/

I recently wrote a white paper for a client to assist them in ramping up with Spring and BlazeDS Integration (SBI) best practices. The link below will allow you to download the white paper.

It contains many links to helpful downloads and assists in a "painless" install and configuration for this solution set. There is also a java and flex example app to get you started. Enjoy...

BlazeDS Best Practices

If you are looking for a great day of Flex and Adobe discussion/training sign up for Flash Camp Atlanta!

It's on Aug. 28th and starts at 8 for the special introduction course with general sessions starting at 9. You can't beat the training you will receive from these experts in Flash and RIA; plus it only costs 50 bucks!

I am planning to attend, hope to see you there; click on the image to register:

I have been wanting to blog about an experience I had not too long ago on a project where the jvm was consistently throwing OOM errors. It had me banging my head against my desk for a few days attempting to trace where the culprit was.

Was it code related?... yes, was it bad code?... sort of, was it very very very intense code (looping over many sql calls and instantiating many objects)?... YES! The challenge here was to apply a quick band aid rather than redesign this rules engine that had the characteristics listed due to time constraints. It is important to note I was not responsible for the poorly written code 8-).

I had to first identify if there were memory leaks due to this code. To do this I utilized YourKit Java Profiler. They have .NET and Java profilers that allow you to monitor their respective runtimes. YourKit Profiler is very simple to configure within the jvm.config file (I'm not going to get into that in this blog). My point here is that I witnessed memory steadily climb and at times spike, but was only able to reclaim memory when executing a manual GC. UGGG!!! So, no memory leak, but the runtime was hanging on to what it had... Why was the GC not reclaiming memory quickly on it's own? I had all the BP jvm args of old, etc., etc. ParNewGC and RMI to no avail.

And to get back to the initial issue; the blasted OOM error. I searched high and low and identified a thread on a Sun forum that there were issues with jre 1.5 that ultimately threw a OOM error if the runtime was unable to reclaim memory during a GC within a given time frame. The workaround for this was to set a time constraint in the JVM (which didn't work) or install 1.6_10 or later. This was my first step. I installed this JRE version and pointed my jvm.config to it. The application ran fine under this JRE except that I was still seeing the memory creep to the ceiling with no reclaim.

I then read on one of Sun's GC tuning white papers the following paragraph:

The -XX:+AggressiveHeap option inspects the machine resources (size of memory and number of processors) and attempts to set various parameters to be optimal for long-running, memory allocation-intensive jobs. It was originally intended for machines with large amounts of memory and a large number of CPUs, but in the J2SE platform, version 1.4.1 and later it has shown itself to be useful even on four processor machines. With this option the throughput collector (-XX:+UseParallelGC) is used along with adaptive sizing (-XX:+UseAdaptiveSizePolicy). The physical memory on the machines must be at least 256MB before AggressiveHeap can be used. The size of the initial heap is calculated based on the size of the physical memory and attempts to make maximal use of the physical memory for the heap (i.e., the algorithms attempt to use heaps nearly as large as the total physical memory).

Note: -XX:+UseAdaptiveSizePolicy is on by default so I don't explicitly define it in my args.

Amazingly, once I added this to the args, removed ParNewGC (enabled UseParallelGC) the server ran flawlessly for days and days without a restart. I was serving requests into the millions without a restart!!! A partial arg list specific to these setting are below, please let me know your thoughts and concerns as I always enjoy constructive feedback.

java.args=-server -Xmx1024m -Xms1024m -XX:+AggressiveHeap -XX:+UseParallelGC -Dsun.io.useCanonCaches=false -XX:MaxPermSize=512m

Note: This was for a ColdFusion 8 instance.

I was recently tasked on my current project to generate this. I hope it helps some of you in communication regarding Flash support across multiple OS and Browsers.

Matrix

I just got word that I will be contributing to the books supporting the ColdFusion 9 release.

Adobe is making significant improvements as they continue to evolve the product.

I am stoked to be involved for a third release and look forward to working with a stellar team of authors.

I wanted to blog a reminder that I am promoting Flex Camp Miami (http://www.flexcampmiami.com). It will be on the University of Miami campus. A great place to meet during the winter season and registration is only $30!!!!

The testimonials alone are reason to attend: http://www.flexcampmiami.com/page.cfm/testimonials.

It's an opportunity to learn from the industry's finest, network, discuss the daily grind, etc. I look forward to seeing you there!

Here is the Agenda:

So as you can see, something for everyone. Look forward to seeing you there.

I spoke to the GMCC yesterday afternoon about SEO and how Universal Mind has overcome the challenges of spidering flash based solutions.

It was an enjoyable presentation and I appreciated the genuine interest and questions from the attendees. Thank you Chamber! I look forward to visiting again. The "download" link below will allow you to save the PowerPoint presentation.

I haven't blogged in awhile due to schedule, but had to blog this experience I recently had while attempting to stabilize an application and enhance performance.

I have always taken for granted that createObject was lightning fast... Well, as fast as feasibly possibly under a given JVM.

I think I was dead wrong and this may be an issue for Adobe to address. I am unclear on the internals of course. But I have been up against OOMs on my current project and wanted to test out using soft reference (cached objects) and use duplicate from the cache rather than createObject.

Far stretch I know... but hey it was worth a try. What was revealed was that performance was negligible and createObject was faster in some intervals. Memory behaved the same, no real bonus. So in discussion with a fellow consultant I told him I'd ship a zip to him for test purposes as he had said he'd seen a significant performance enhancement with duplicate (not true by the way).

What happened next totally shocked me. To simplify the test code I snagged my VO.cfc out of it's proper place (several dirs down i.e. sitedir, com, bus, app, model, vo.. you get the idea) and put it in the root of the calling cfm. I then removed all the pathing (dot notation) from my createObject call and executed the cfm to see if it would run ok after the change.

The test was a loop of 10k over this create object call. I was seeing execution times of around 30 seconds. When I ran the updated code it went to 577 milliseconds... I am still befuddled by this. Is there that much overhead with pathing?

I initially thought it was a mapping issue because I had been using mappings, but absolute path from root was just as slow.

Please Adobe tell me this is Sun's jvm and not your code. I know this is negligible with 100 or so creates, but imagine the boost if I did find something here.

For clarification I am running on a Mac (OS X, CF running in JBOSS), but also tested on my old Dell (XP, CF running in JRUN). I didn't see as dramatic a difference on WIntel, but my exec time went from 30 seconds to 4 seconds. I am happy with 10x faster on Windows too...

Any insight here is greatly appreciated. Example Code: