So, I’ve been trying to cook up some decent blog content in the middle of writing this Flex platform, but the need to actually complete the project trumps writing about it… However, I’ve managed to stumble upon my west-coast twin. I’ve even used his wp blog template for a while.

So I collect coins these days. Guns too. I like collecting things, so it would seem, but it isn’t all fun and games–it’s lots of research to find the rarest and most desirable items, and buy them at the right time. If you’re thinking about collecting bumper stickers, here are this years hard-to-finders:

“Sportsmen for Obama”

“Don’t blame me, I voted for Bush”

“It’s not a child it’s a choice.”

“God bless everyone, no exceptions*”

“Ron Paul ‘08 - We can do this, guys!”

Step 1: Download PandoraBoy (http://code.google.com/p/pandoraboy/)

Step 2: Download Airfoil (purchase for $25) (http://rogueamoeba.com/airfoil/)

Step 3: Enjoy Pandora over iTunes remote speakers while keeping all other sounds local.

Just a quick observation of how important it is to me that in order to achieve and maintain focus, I need to reduce my “sphere of awareness” as small as possible. I picture an imaginary bubble around me, and whether I like it or not, my mind is background-monitoring everything within that bubble. The larger the bubble is, the easier it is to be distracted as things vie for my attention, and the harder it is for me to zone in to what I’m doing as I’m constantly polling for updates from everything in that sphere. That’s why we all wear headphones.

The problem arises when switching between managerial and development tasks. A managerial mindset requires the constant awareness of the entire machine, and the ability to triage all kinds of interruptions. You get into that mindset, and you begin to habitually and frequently poll everything in that sphere. You begin to listen in to conversations, feel the need to check on status of things, re-check your to-do list for anything you might have missed. Then, when you detect that precious 10-minute pocket of time between fires, you have to get something done. You take of your managerial hat, and you put on your developer hat.

You’re refactoring the hell out of some code, the body flayed open with guts hanging all over the place, but you are constantly looking over your shoulder, expecting someone to ping you about something on your to-do list that is pending. I live in this place.

Twitter has become a once-a-day blog read, so no more Twitteriffic throwing Growl notes all over the place. IM closed. Yammer closed. Email closed. I decide that enough is enough and I have to get something done today. After a solid hour or two, I finally shake off the itching feeling of imminent interruption and get into a groove. I can’t shake it anymore, and I open my email, only to find that people are frustrated with me as they’ve been attempting to get my attention for hours. My sphere of awareness explodes, and now I’m putting out fires and feeling guilty for working.

My sphere is tired of expanding and contracting. I have to figure out a better way of doing this.

As someone who has worked with Flash since FutureSplash was acquired by Macromedia, and as someone with both a design / animation and programming background, I agree with Adobe’s decision to go with a more structured implementation of ActionScript in Flash with AS3. I believe it is a strategic move to position Flash as a viable platform for true RIA development.

There’s no reason that a toolkit couldn’t be written that abstracts the API to provide some of the functionality mentioned in the article. It would streamline development for designers / animators, yet maintain the architectural integrity of AS3.

It’s undeniable that the new VM is harder, better, faster, stronger. The level of complexity of the API needed to increase to provide access to the host of new features–not only for the contemporary version of Flash, but also to elegantly scale for the future.

Consider even the nomenclature of the AS2 display object hierarchy. “MovieClip”? Think about how someone from a development background (not Flash) would approach the idea of an interface comprised of “MovieClips.” They’re not interested in frame-based animation. They don’t want to play a movie. They want to draw vector graphics on the screen. So they create a “MovieClip”? I think Adobe has done a fantastic job of maintaining cohesiveness between a logically engineered AS3 API and the legacy AS2 API that anyone who has evolved as a designer / developer with Flash would be familiar with.

I believe that AS3 allows a developer to logically approach Flash as a UI platform with some amazing capabilities. I think AS3 alone may prove to be a challenge to a designer without any programming background, but this is not unmitigable with a well-written toolkit for designers. Maybe that’s the core of what I’m saying–that you can go one way but not the other. You can abstract an API to make it easier for a designer to use, but you can’t go the other way and take an abstracted API and make it more powerful for developers.

Specifically related to Charge #6–that’s definitely biting the hand that feeds you. SOME errors are better than NO errors. I think it was incredibly cumbersome to code to AS2 for the example that was cited in the article. I agree with the verdict NOT GUILTY.

I would also like to say that I concur with the other, arguably non-AS3, issues mentioned in the article, specifically “Failure to Unload,” which has caused me much grief in the past.

My intent is not to come off as a pretentious “real Flash developer” to all you “plebeian designers” or something, nor is it to slam Colin, whom I hold in very high regard, but I hope that this provides some counter-rationale.

Ok, I re-read the article, and I have to concede that perhaps my previous comment was slightly a knee-jerk reaction. As a Flash platform evangelist, I really appreciated the architectural changes in AS3 vs AS2. By the time I got to the bottom and read the previous comments, I forgot that Colin’s “What Should ___ Do?” commentary was really well thought through and addressed both the concerns of the designer and developer.

“But despite all the talk of GPU blitting, pixel shading, and ligatures, a non-negligible percentage of the Flash community is rightfully asking: is Adobe still committed to the simple, agile authoring practices on which Flash was founded? It’s a rational enough concern. After all, Flash built its success on ‘ease of use.’”

I think it is a valid concern, but “ease of use” is relative versus the audience, purpose, and power of what is being evaluated. I agree that Flash should be easy to use, but that does not mean what it did 10 years ago.

“Or maybe the time has come for someone to make an entirely new application for building simple Flash websites and animations. Such a tool could even be written in ActionScript, and deployed as an AIR app.”

I wonder when the convergence between Desktop, AIR (runtimes), Browser, Flash Player will happen. I feel like the industry is so confused with levels of abstraction, we’re writing browsers for various OS’s, that render HTML documents, which contain Flash players, that render RIA’s, or animations or whatever, which can also be deployed in an AIR runtime, which can contain a browser, etc… Forgive my rant, but I just don’t see things working like this sustainably for very long. Ultimately, it will come down to a contiguous platform that will allow left-to-right-brained people to interact and produce content in a continuum of connected devices. The moment we have immediate high-bandwidth connectivity everywhere is the moment the game entirely changes, and it’s almost here. But I digress…

A few people here have only recently switched to Mac as their primary computing platform. People generally find most things to be easier and more pleasant to use on a Mac. However, there is frequently a point of confusion for a Windows user when they try to find their “network drives,” or mapped network shares that they had previously configured to automatically remap on login, and were displayed in “My Computer.”

This describes the methodology of mounting network drives in Finder so that they are easily accessible in normal workflow, minimizing the steps required to access those drives, and removing the need to remember if they have been mounted or not.

1. Mount the drives using Finder.

  • Click on Finder, and select “Connect to Server…” from the “Go” menu.
  • Connect to our primary data server “carbon” by entering “smb://carbon” in the “Server Address:” field and click “Connect.” Once Finder has connected, you will be able to select from the following shares: backups, documents, media, proposals, resources, temp, townhall, users, vault.
  • Repeat this process for all the drives you would like to be accessible. Repeat this process as well for other servers as well. Our primary web server, “nitrogen” (use “smb://nitrogen” in the “Server Address:” field), will give you access to the “wwwroot” share.

2. Create a “Network” folder in your user folder.
  • Open a finder window, and click on your username in the sidebar.
  • Control+Click (or right click) in the window and select “New Folder.”
  • Name the new folder “Network”

3. Create shortcuts to the network drives in the Network folder.

  • You should see all your network drives on your desktop. If you don’t, click your desktop, select “Preferences…” from the “Finder” menu, and ensure that “Connected servers” is checked.
  • With the newly created “Network” folder, as well as your desktop visible, select all your network drives and drag them to the “Network” folder. Your cursor should add a small curved arrow when you drag them over the folder.

4. Create shortcuts to the “Network” folder.

  • Drag the “Network” folder into your sidebar, preferably as the first item, above your username.
  • Drag the “Network” folder into your dock, next to the Trash Can.

5. Integrating into your workflow.

  • Remember that you don’t have to remember to “mount the drives” when you need them. Treat them as if they are already mounted and just use them. OSX will mount them as needed.
  • When saving a file from within an application, click the “Network” folder in the sidebar, and then choose the drive you want to open. If it’s mounted, it will be immediately accessible. If it’s not, there will be a slight pause as OSX mounts the drive.
  • When you are opening file, or need to browse the network drive, it is often easiest to click the “Network” shortcut in the dock and select the drive you want to explore. Again, if it’s mounted, it will appear instantly. If it’s not, it will mount automatically. You will see it appear on your desktop.
  • If you find the desktop icons of your network drives distracting, you can hide them altogether, guiding you to always use the dock or the sidebar as your first access to the drives. To do this, click your desktop, select “Preferences…” from the “Finder” menu, and uncheck “Connected servers.”

Keep in mind that this was written for OSX 10.5 Leopard, however this process will also work in 10.4 although the names of certain things may be slightly different. Also, this is just what I’ve found to be a streamlined workflow; it’s not necessarily “the way” ™ to do it. I’d love to hear what others do.

If you aren’t using an MVC framework like Cairngorm, Model-Glue, Guasax, or PureMVC for your Flex development, you really should think about starting. Our adoption of PureMVC at andCulture has allowed us to structure our ideas around a concrete paradigm and move on to arguing about more important things.

I’ve implemented PureMVC in both Flash and Flex projects and I’ve noticed that #3 of this post really applies. I mean really applies. As a general philosophy, I believe it’s better to start out with as few Mediators as possible, and structure them (or it) around the logical parts of the application or module—not the View Components or even their hierarchy as much. And, when the Mediator starts to become cumbersome, think about refactoring. 

For instance, for a Flash kiosk I just finished, I more-or-less had a Mediator for each VC—not entirely, but I definitely ended up with a disorganized mess of Mediators, which I affectionately refer to now as Mediator Soup. 

One of the biggest issues is state. Often elements that have their own Mediators should actually be a complex VC with a single, intelligent Mediator. Or, if that doesn’t flow architecturally, approach the VC as a separate Module or component, with it’s own MVC, and interface to it via it’s own API.

I’ve noticed that this approach allows me to think of the application in a more logical way, and seems to keep the code cleaner. I’d appreciate any thoughts or feedback on this.

Adobe has enhanced the security policy in Flash Player 9.0.115 and 9.0.124 that may cause some issues if you’re interacting with Web Services. Typically when I start a Flex project, I just throw a simple, open crossdomain.xml file on the root of the service site (or elsewhere) and go to town (which is poor practice to leave when you deploy). 

The “come and get it” policy file typically looks like this:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
    <allow-access-from domain="*" />
</cross-domain-policy>

 

However, we noticed that an intranet project we’ve deployed stopped working on certain computers, throwing the following error:

[RPC Fault faultString="Security error accessing url" faultCode="Channel.Security.Error" 
faultDetail="Unable to load WSDL. If currently online, please verify the URI and/or format
of the WSDL (***YOUR WSDL ENDPOINT HERE***)"]
      at mx.rpc.wsdl::WSDLLoader/mx.rpc.wsdl:WSDLLoader::faultHandler()
      at flash.events::EventDispatcher/flash.events:EventDispatcher::dispatchEventFunction()
      at flash.events::EventDispatcher/dispatchEvent()
      at mx.rpc::AbstractInvoker/http://www.adobe.com/2006/flex/mx/internal::dispatchRpcEvent()
      at mx.rpc::AbstractInvoker/http://www.adobe.com/2006/flex/mx/internal::faultHandler()
      at mx.rpc::Responder/fault()
      at mx.rpc::AsyncRequest/fault()
      at ::DirectHTTPMessageResponder/securityErrorHandler()
      at flash.events::EventDispatcher/flash.events:EventDispatcher::dispatchEventFunction()
      at flash.events::EventDispatcher/dispatchEvent()
      at flash.net::URLLoader/flash.net:URLLoader::redirectEvent()

 

When you check out the XSD for policy files, you’ll notice that (among other things) they’ve added a “allow-http-request-headers-from” element. So the new “come and get it” policy file looks like this:

<?xml version="1.0"?>
<!DOCTYPE cross-domain-policy SYSTEM
"http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
    <allow-access-from domain="*" to-ports="*" />
    <allow-http-request-headers-from domain="*" headers="SOAPAction"/>
</cross-domain-policy>

 

This should allow you to consume your services from basically anywhere. Remember to lock your stuff down when you deploy.

We’ve been using this for a while now, and I’d just like to tell the internets that Charles is awesome. I would definitely recommend it.

This works (outputs ID’s):

new Array();
var attributes:XMLList = _data.Attributes..AttributeDescriptor;
for each(var attribute:XML in attributes)
{
	trace(attribute.@ID);
}

This doesn’t (outputs nulls):

var attributes:XMLList = _data.Attributes..AttributeDescriptor;
for each(var attribute:XML in attributes)
{
	trace(attribute.@ID);
}

Any questions?

Update: Kudos to Larry (developmentastic.com) for beating his head against this brick wall on the Winestore project.