Evernote worked out very well, and now I can share my notes online just by putting all of them into their own notebook (folder) and making it public.

So without further ado: my notes from QCon.

Overall, I thought QCon was excellent. While the quality of the speakers was somewhat varied in the sessions I attended, I never felt my time might be better spent checking out a different session, which puts it ahead of most conferences. (I’m a big fan of voting with my feet.) QCon is certainly on my short list of conferences to attend next year. Also on my list are (in no particular order): C4, WWDC, RailsConf, eRubyCon, and 360|Flex.

Since the primary use for this knowledge is managing the initialization portion of the component life cycle, I’ve highlighted the lines where your component may extend the behavior of UIComponent to perform its own operations.

The addChild() code bounces around through a lot of the Container class hierarchy, so I’ve included the class name with the method calls inside the parent’s instance so that you know where in the class hierarchy things get handled.

For simplicity, I skip showing the parameters to method calls and I don’t expand some operations (depicted by italicized text).

1. Container.addChild()
   1. calls Container.addChildAt()
      1. removes child’s previous parent, if present
      2. calls Container.addingChild()
         1. calls UIComponent.addingChild()
            1. calls child.parentChanged()
            2. performs style setup on child
            3. calls child.stylesInitialized()
         2. invalidates size and display list of parent
      3. calls UIComponent.$addChildAt()
         1. calls Sprite.addChild()
      4. calls Container.childAdded()
         1. parent dispatches “childrenChanged”
         2. parent dispatches “childAdd”
         3. calls child.dispatchEvent()
            1. child dispatches “add”
         4. calls UIComponent.childAdded()
            1. calls child.initialize()
               1. dispatches “preinitialize”
               2. calls child.createChildren()
               3. calls child.childrenCreated()
                  1. invalidates properties, size, and display list of child
               4. calls child.initializeAccessibility()
               5. calls child.initializationComplete()
                  1. sets processedDescriptors = true
                     1. dispatches “initialize”

There you have it: the order of operations when you invoke Container.addChild(). I hope this proves useful.

That’s just silly.

For data-driven sites—which would be most Web sites with Flex front-ends—this is an completely artificial restriction. The only place where this would make any sense is for applications that do not dynamically load content, but rather dynamically generate content, such as for client-side mash-ups. Additionally, according to Google “if your Flash file loads an HTML file, an XML file, another SWF file, etc., Google will separately index that resource, but it will not yet be considered to be part of the content in your Flash file.” That implies that dynamically loaded content must be RPC-based (and binary?) to be considered part of your SWF (as Ryan Stewart desires) instead of a separate resource. Yuck!

I will continue with my planned solution because demonstrating the technique and learning how well it works for SEO will provide valuable information for the community.

Finally, I’d like to announce that I’ve purchased the domain fleximagicallysearchable.com for this contest¹. There is nothing there now, but I would like to turn it into a blog or user forum for discussing Flex SEO strategies and make it a resource that lives beyond this contest, continuing to be useful in the future by providing tutorials and covering the emerging best practices for Flash and Flex SEO.

¹ Not to be confused with fleximagically-searchable.com, which is owned by zedia.net.

The same principle holds true for other Web applications, whether the garnish is Ajax, Flash, Flex, Silverlight, or—like this blog—good old fashioned dynamically generated HTML. It is the data that must be indexed, the presentation around that data is (conceptually) irrelevant for SEO purposes. I think the matter may be confused because for so long the data and the presentation were bundled together in HTML (like this blog). Now with Ajax and Flash/Flex, we are back to separating the user interface from the data. However, when the data isn’t part of the user interface document sent by the server, it’s harder for search engines to access and index.

So what’s the solution? Expose the data for indexing and detect when incoming links should launch the Flash/Flex app instead of responding with the raw information. Naturally, the Flash/Flex app would be launched to deep-linked directly to the relevant content. If you’re not sure how to make the data indexable, I’ll tell you that I take my guidance from RESTful Web Services. The magic in this solution is detecting when an incoming link should launch a deep-linked Flex application and when it should render the raw data. For the moment, I’ll punt on detailing an implementation—consider it to be an exercise for the reader.

An exercise for the reader that can lead to rich rewards! Ryan Stewart has announced the Flex SEO Contest to encourage the community to establish best practices for Flash/Flex indexing. The rules are straightforward and the top prize is CS4 Master Collection. I like the challenge and may try my hand creating an entry that meets the contest criteria just for the experience of it.

The article really hits its stride in the section “Creeping bureacracy”. If you’re short on time, jump down to that header. I found myself laughing and nodding at these pearls of wisdom:

I think that by far the biggest reason that C++ and Java are the predominant industry languages today, as opposed to dynamic languages like Perl/Python/Ruby or academic languages like Modula-3/SML/Haskell, is that C++ and Java cater to both secure and insecure programmers.

and

Perl, Python and Ruby fail to attract many Java and C++ programmers because, well, they force you to get stuff done. It’s not very easy to drag your heels and dicker with class modeling in dynamic languages, although I suppose some people still manage. By and large these languages (like C) force you to face the computation head-on. That makes them really unpopular with metadata-addicted n00bs.

While the whole article sent my neurons firing off in dozens of different directions worthy of blog entries, I’m going to concentrate on this bit:

Java has been overrun by metadata-addicted n00bs. You can’t go to a bookstore or visit a forum or (at some companies) even go to the bathroom without hearing from them. You can’t actually model everything; it’s formally impossible and pragmatically a dead-end. But they try. And they tell their peers (just like our metadata-addicted logical data modelers) that you have to model everything or you’re a Bad Citizen.

Hello, my name is David and used to be a metadata-addicted n00b. Joking aside, Steve is absolutely right.

I think Java became the garden of frameworks due to its early positioning as an enterprise software platform. Enterprises are strange beasts. Internally developed enterprise software has a tendency to live a long, long time. A decade, often more. Take a moment and pause to think about what you were doing 10 years ago today, and then think about how much technology has changed in that time, too.

One of the problems faced by enterprise software that isn’t typically encountered outside of enterprises is that the systems, protocols, and interfaces that an application was originally written to run on or collaborate with will have been replaced. Vendors are replaced, authorization systems change (database to directory to single sign-on), databases are upgraded, CORBA loses favor to EJB and then to SOAP, and so on. Consequently, the fathers of Java emphasized abstraction—don’t get too close to your touch points, because they may be changed tomorrow. Let’s call this “abstraction at the edge”.

I think that a lot of Java developers—myself included—took abstraction too far. Instead of abstracting at the edge, we started abstracting everything. Rather than creating opinionated software, the Java development community promoted and embraced frameworks that competed to be the most general and all-encompassing. Rather than solving problems, the Java community invested its energy in building problem-solving engines.

This is important because as Java developers have started jumping into new communities—I’m thinking of .NET, Flex, and Ruby on Rails—they have brought their framework addictions with them. NHibernate and Spring.NET are gaining momentum within .NET communities and you can’t look sideways at Flex without tripping over a new Flex MVC framework¹. The Rails community has been very successful at resisting the inventions of “metadata addicted n00bs” because the big names in the community have taken a strong positions against abstraction.

I might be growing up faster than Steve’s timetable for growth, but I’m tired of frameworks that try to do everything. I just want to get things done.

¹ Here’s nine for you: Cairngorm, PureMVC, ARP, MVCS, Flest, Model-Glue: Flex, ServerBox Foundry, Guasax, and Slide. List compiled from here and here.

After registering, I chatted with other developers in my company to determine what sessions would be of greatest benefit to the teams using or investigating Flex. I shuffled those in with some sessions I really wanted to attend and the resulting schedule is below.

Data Visualization with Flex

Customizing the Flex Framework

Continuous Integration with Flex, FlexUnit, and Ant

Optimizing ActionScript 3.0 Performance

Inspire Session: The Dawning of the Age of Experience

What Makes a Design Seem Intuitive?

Pixel Perfect Precision

XD: Prototyping Rich Internet Applications with Fireworks CS3

XD: Adobe’s Approach to Application Design

Optimizing Flex Applications

Designers and Developers CAN Love Each Other

Creating New Flex Components

Flex on Rails

I look forward to seeing some of you there!

The first items aren’t that interesting. A 360|Flex folder and an Effective UI graph pad I picked up off a table while at that conference (thanks, guys!). I plan to use the graph pad to layout some screens for an upcoming project at work and want to keep it handy in case inspiration strikes. I’m still waiting for that inspiration.

Then I pulled out a two inch thick collection of papers I’d printed (duplex, to conserve paper). On top of the stack is D-Click’s Adobe Flex Coding Guidelines. I really don’t like placing opening braces on their own line. Drives me nuts. (For my money, the Sun Java Coding Conventions can’t be beat.) But, when in Rome, do as the Romans do. I recognize that being consistent (especially across developers on the same team) is more important than the merits of any single convention, so I’m trying to learn new habits.

Next up are printouts of six chapters from Adobe’s Building and Deploying Flex Applications (PDF here). I have only built Flex apps inside of Flex Builder, so I still need to learn the command line tools. My company is big on “repeatable builds”—meaning that any interally-developed production applications should be easy to regenerate from source without developer involvement. In practice, this means that the application must be built with a command line build script (Make, Ant, etc.). Besides, I get nervous when I’m overly dependent on an IDE. I like code completion, syntax highlighting, and refactoring, but I really like to know that I can do it all from vi or Notepad and the raw Flex SDK if desired or needed. Hence my interest in the Building and Deploying Flex Applications book. And I mean book! A full printout would weigh in at 400+ pages! So I picked the most important parts to me and just printed those.

The first chapter is Chapter 3 (Flex Application Structure). I just finished reading this chapter last night. Not a lot to say here. It’s good to have the layout with which I was familiar due to Flex Builder reinforced in print. Next up are Chapter 4 (Applying Flex Security), Chapter 7 (Building Overview), Chapter 9 (Using the Flex Compilers), Chapter 13 (Using ASDoc), and Chapter 14 (Creating Applications for Testing).

Then I come to printouts of various O’Reilly articles about Ruby on Rails that I intend to read Any Day Now™. Rolling with Ruby on Rails Revisited, Cookin’ with Ruby on Rails: May, Cookin’ with Ruby on Rails: Designing for Testability, Cookin’ with Ruby on Rails: More Designing for Testability.

And finally, I have Greg Hamer’s presentation slides for introducing Cairngorm at 360|Flex. I suppose I can take this out of my bag. I have the general idea of how Cairngorm works. I’m still waiting to write an app large enough to make playing with Cairngorm worthwhile. Okay, that’s not quite right. I’m still working on my first Flex app ever. I’m plugging into the 37signals Backpack API. When I’m done with that, I might look at refactoring it for Cairngorm just to get that experience under my belt.

And that’s wy my computer bag weighs a ton. What’s in your computer bag?

Update: I’m down to 157.

Flex developers come from a wide range of backgrounds. There were some management types and UI designers sprinkled in the mix, and I found that these people had the best questions and comments during the less technical sessions (e.g., “Design Eye for the Dev Guy”). About half of the attendees were designers—most with a strong background in Flash, but some Web (HTML/CSS) designers as well. The other half of attendees were developers—lots of .NET developers, a healthy batch of Java developers, enough Ruby developers so that I didn’t feel lonely, a handful of ColdFusion holdouts.

There were some areas where the conference could have been improved, though—most were related to communication.

• If I had known up front that the sessions would be video recorded and made available later, I would have been more inclined to join the Flex 101 and AIR 101 hands-on sessions, since I could watch the recordings of sessions I missed later.
• It wasn’t clear to me that the Flex Charity Code Jam (more, more) was intended to be a learning experience. I felt that as a Flex newbie, I wouldn’t have much to contribute.
• The vendors, who made it possible for me to attend an amazing conference for only $360, were tucked in a room off in the corner. I would have switched the chill-out room and the vendor room to give the vendors more presence. I swung through the vendor booths twice to pick up their marketing material note all of the URLs to research later. Thanks, vendors!

Beyond that, I agree with everything David Coletta said.