I attended Microsoft’s MIX 2010 conference in Las Vegas the week after 360Flex.  I had previously attended I think the 2007 or 2008 one.  I had actually recorded a lot of video from the first one and trashed all of it.  The 200x one was an EXTREMELY weird conference.  It occured in the Venetian, the same hotel that Adobe’s MAX was at.  So, I had the opportunity to see the vibe differences between the 2 communities, and whoa man… what a difference.

Adobe has more chicks, more of a party vibe, and “appears” more diverse in terms of backgrounds.  In talking to some of the individuals at after parties, the majority at MIX were involved in the Microsoft technology stack in some shape or fashion whereas at Adobe, you had no clue what those people did.  There were patterns, yes, but design, back-end, Flash, Flex, Python…. all over the map.

At the 200x one, when they showed Silverlight 3 new features, I nearly lost my shit.  The audience was really excited about features that I perceived as things the Flash community had done 5 years ago.  Yet, if you looked at the audience, they were eating it up, excited, and you could tell they couldn’t wait to start coding.  After taking some time to reflect, I realized that Microsoft developers use Microsoft technologies.  They don’t “branch out” like Adobe ones do.  That’s why it’s rare as heck to see a .NET dev who uses Flash/Flex for their front-end.  Most use AJAX… generated from Microsoft tools.

This year was different.  I was armed with the understanding that Silverlight really isn’t just about competing with Flash/Flex/AIR in the video arena, but rather providing a missing piece that .NET devs didn’t have in the past.  The features added into Silverlight 1 through 4 match a lot of what us Flash/Flex Developers have.  They also validate our work. It’s also about building on Microsoft’s platform, which is great. You need a great web runtime + a phat browser + device to kick some tail. Apple does it, Google’s doing it… Adobe? Well, no device or browser, but Flash Player rocks, so….

However, no matter how on parity those features get, or even surpass, the Microsoft community clearly is missing the design aspect in terms of designers working with .NET devs.  There are some, yes, but it’s a night and day difference compared to your average Flex consulting firm, or Flash agency, or small software shop that uses Flex.  I even talked to one small .NET shop manager who hired a Flash Designer specifically to get his UX/Design help with their Silverlight/WPF endeavors.

What many predicted finally came true: Microsoft forewent fighting Adobe on the design front, and embraced it.  It’s actually scary vs. cool.  I mean, it’s cool, but damn they did it well.  I haven’t used the tools in production, thus this entire paragraph is suspect, but wow.  They are now supporting PSD (Photoshop) and AI (Illustrator) native import as well as FXG.  Holy.  Shit.  I was on my 2nd cup of coffee, and I still did a triple take when Scott Guthrie mentioned “So, we’re going to import some FXG…”.  Say what?  Where’s Design!?

“Designers don’t use Design, they use Photoshop & Illustrator.”

said Mike Downey when I confronted him about it.  His tone was very matter of fact, confident… almost like, “Yeah man… exactly”.  What that means, though, is that they are on the RIGHT path.  Very cool stuff to embrace the design tools we all use.  Also lowers the barrier of entry for the design agencies to work with these Microsoft shops as partners.  Wow.

Yet again, it was great to see Sketchflow in action.  Rapid prototyping is HUGE in helping sales snag gigs, and now that the .NET world has a way to do this WITH valid design tools, man.

The common theme of the conference was “mobile, mobile, mobile”.  They were pushing their Windows Mobile 7, or whatever the heck it’s called, HARD.  I body checked ‘em on the 3 buttons, and they had some valid use cases.  Everyone codes a back button in iPhone apps… why not remove that step and put it natively on the phone?  Also, making search a first class citizen.  Well… can’t argue with that.

Like I drunkenly yelled at Jens, this was the most amazing keynote I’ve seen in terms of flow and momentum.  Microsoft this year clearly had it down pat.  They had a consistent message, it was effectively communicated, and it inspired the audience into action.  Well… mostly.  While the developer story was picturesque with all the tools working together with a device & marketplace just waiting on you to start coding, the phone doesn’t exist yet.  iPhone does.  When it arrives, though, holy fish.  I believe Adobe can definately have just as a compelling story… but there was just something really professional, confident, and effective at this MIX keynote.  Maybe it was the speakers’ experience level.  Maybe it was good rehearsal.  Maybe it was good content.  Every speaker was certainly very positive and didn’t come across as better-than-thou like in times past.  Maybe it was all it.  Bottom line, it was great, and set a high bar.

….but like I said, the audience is just not a Adobe audience.  If it was, it would of been a lot louder, with random screams and yells, perhaps some heckling.  .NET devs need more Redbull… that’s all I can say.  Maybe some Picasso too.  I don’t know.  Maybe that’s why all the Flex & Flash devs were there. *ahem*

I hopped around sessions to “see what people were working on”.  They were doing the same things we’re doing. CMS systems that have rich front-ends to manage & deploy media.  Video players.  Mobile development for phones that don’t exist (see what I did thar?).  Dealing with scaleable client-side software via modules.  Bottom line, they are a lot like us, doing very similar work.  Sadly, most of the Silverlight specific stuff is still funded-by-Microsoft vs. a client hiring someone/some firm/company.  While the technology seems to be ready, the market isn’t.

And that leads me to my conclusion.  Once they get to 60%, we’re in trouble.  Not big trouble, but we WILL start losing work.  At that point, you have 2 choices.  You can take the Cynergy approach of a few years ago, and go, “Dude, we do both ’cause they both rock!”, or you can just deal with the reduced amount of gigs.  I don’t know to what degree this will affect the Flash/Flex world, but I know a lot of the big clients I’ve had in the past 2 years will no longer exist… unless I code Silverlight.  I, like others, still get a lot of work, so it’s not like we’ll just become unemployed, not in the least.  It’s just that the “MLB’s” and the “Olympics” style gigs will start to flow towards the Microsoft realm vs. the Flash realm.  And no, just because Flash has a higher install base won’t matter.  I can’t compete with free, regardless if my plugin of choice is at 99% and theirs is at 60%.  That said, Java/Python/Ruby etc. still exist in large quantities.  They target specific markets & verticals.  A lot of those is where Flash & Flex still shine, and will continue to do so.  Not everyone on the planet uses Microsoft technology stacks.

ESPECIALLY in the consumer sphere.

That’s what was interesting about the way Microsoft pitched their phone.  To consumers.  They hired all the right people, said all the right things, integrated all the right tools.  While I’m sure the manufacturers will make pimp devices, it’s challenging not to be cynical about Operators.  I guess if Apple can do it with glib, perhaps Microsoft can do it with dough?

Finally, Microsoft is definitely hiring the right people.  They are positioning key individuals in certain parts of the company, removing the old guard who just don’t get the web, nor younger consumers.

Will I be doing anything different after my 2nd MIX?  No.  Yes, I’ll be keeping in touch with my new found Microsoft friends… but until the Silverlight work flows to me vs. me having to form Microsoft consulting/partner relationships, nothing changes in my world.  It’s all about the money.  If people pay, I’ll do it.  Right now, Microsoft pays.  I don’t mind working as a partner for Microsoft, but right now the world knows me as a Flash & Flex Dev who likes to kick ass with Flash Player, not Silverlight.  It’s up to the greenbacks flow to change that. I know it comes off as reactive, but the Microsoft market is large enough that if I did dive in, I’d have zero problem finding clients even if am “late to the game”.

Oh yeah, and lastly, all the “free” software Microsoft is releasing to get you on board is a smart f’ing move.  And Visual Studio still looks awesome… so does C#.  Maybe I’ll go learn Unity this weekend to get taste without having to dust off my PC or install VMWare or whatever it’s called.  Anything I can do to avoid Objective C….

Anyway, thanks a ton to Microsoft for inviting me, I really appreciate it and all the events, they were fun, and I love meeting new people.  It was the best MIX yet, I learned a lot, and I look forward to speaking at the next one!

I attended and spoke at the 360 Flex conference in San Jose this year. Before the high fades away, I wanted to post what I learned last week for a few reasons. First, to share with others. Second, to share for those who didn’t attend, but might if they feel they’d gain something from it. Third, a growing number of Flex devs, albeit really small, feel they don’t gain much from conferences. I wanted to show a potential counterpoint to this in hopes it’ll convert them back.

360 Flex was in San Jose, California this year, so it’s a long hike. That said, people from all over the USA and world converged to meet & greet. 360 Flex is THE premiere Flex conference. As a speaker, it’s always been the place, next to Boston, where I KNOW people in the audience will get what I’m talking about. As I’ve progressed in my career, I’ve struggled to present topics that weren’t too advanced for the general Flex community, yet would interest those who are advanced as well. Her majesty constantly reminds me that the things I’ve spoke about 2 years are still very relevant to Flex & Flash devs today, and I should find some way to get passionate enough about those topics so I can speak on them. Regardless, I don’t have that problem in San Jose and Boston, so it was a nice reprieve.

This attitude is based on my perceptions of the body language of the audience as well as twitter & in person responses afterwards (or lack thereof). It’s not 100% accurate, but I can usually read an audience, knowing if they are getting it, and recognizing what things in my talks need to change material wise. I also find that I speak better when I’m jet lagged and/or hung over. This mellows my normal spazz-tastic nature, and helps me find a really good pace, especially if her majesty reminds me to have fun before hand. Timing these sorts of things is hard, hehe.

I’m usually just so excited to speak about something I love that I forget the basic tenets of giving speeches, and that is “effective pausing”, pace, and stopping to re-assess the audience’ engagement. That’s one of the reasons I continue to speak. I feel like I rock at Flex, but still have a long way to go at speaking. Regardless, what “job” allows you to spread knowledge, gives you the opportunity to have dialogues with geniuses, and act like a crackhead in front of an audience causing them to lolcano?

I may not come away from conferences & user groups with gallons of insight like I did in the past, but I’ve found other angles of knowledge, and EVERYTHING is right with making new friends, and re-connecting in person with existing ones. I love this shit.

Goal: Flex 4 and Catalyst Workflows, & Meeting Different, New People

My goals for Flex/Flash specific conferences nowadays are to hit the sessions that are gaping holes in my knowledge.  I’m probably the last Flex dev on the planet who doesn’t use Flex 4.  This is a combination of my consulting work on existing Flex 3 projects, tight deadlines, and the need for dependability.  Thus, anything Flex 4 specific I’m interested in, not really from the technical side (Adobe’s got great docs), but more from piercing the marketing bs.  Asking top tier to regular devs “how do you REALLY work with the tools?” and striking up a dialogue.

Another passion of mine is people.  I love people.  I love working at Starbucks, and even more so, Manhattan, because I’m surrounded by people. By energy.  By life.  It’s an exciting feeling, and helps motivate to create cool shiz.  I’m fascinated by what makes people tick.  I like to see how some people have certain causes that lead them to certain effects.  If you challenge some commonly held beliefs, you can really get a good dialogue going with developers.  If you make vaporous statements about commonly held agreements, you’ll nodding confirmations, but not much more.  From groups to individuals, you can cause a lot of interesting things to happen. IF you know what buttons to push.

I’m not just fascinated by crowds and groups, but by individuals.  If you’ve ever been to a Microsoft conference, one thing that differentiates the Flash/Flex world from them is our diversity.  We don’t have every application angle handled by Adobe, thus we must reach out to others for help in certain areas.  While we do technically have a client side and middle tier, we don’t have a database solution.  We must use MySQL, SQL Server, Oracle, etc.  This requires us to integrate with other communities.  In turn, they are exposed to us.  We’re different, from different backgrounds.  Some of the culture these clashes are bad, most are good.

Because our tech works with a common goal, we have a “managed diversity”.   Studies have proven that companies who have diversity that’s managed are more successful than those who don’t have diversity.  In turn, those who are so diverse, but aren’t managed are worse.  Flash hitting Rails, Flex hitting Django, AIR conjoining with C++.  Design agency punks mingling with executive, khaki wearing Enterprise Java J2EE devs.  It’s wonderful, crazy.

In short, the opportunity at these conferences, both large and small, to meet someone totally not like me is high.  Yes, we have a common thread; we love t3h SWF.  Yet we all have different backgrounds, different goals, desires… and once you dig into someone’s background, and get them talkin, I eat that shit up.  I love hearing about where people come from, how they arrived where they are, and why they decided to come this way, if at all.

It’s said that the best things about tech conferences are the discussions between/after sessions. For me, it IS the conference.  I’ve always tried to surround myself with people that are better than me.  They rise you up.  Debating with computer scientists, and genius artists… how can you NOT walk away a better person?

What Did I Learn?

A ton.

1. A lot of developers don’t mind the lack of career path.  You rise to architect/consultant level, and instead of hitting the glass ceiling and breaking into management, many just saturate Flex/Flash avenues as far as they can, or go learn another technology and do the whole thing over… only a lot quicker than it took them the first time.
2. A lot of developers read technical manuals & programming books vs. marketing & sales ones.  There are exceptions, but most drink from the tech knowledge fountain and can’t get enough.  I feel like I have a responsibility to help fill the gaps to help them so they either (A) don’t have to worry about this gap or (B) have a desire to get out of their comfort zone.
3. Adobe doesn’t like me much anymore.  There are some great people there whom I still interact with, but it’s been pretty clear over the past 3 years that as I’ve moved into a more architect/sales role with my professional consulting, I’ve had zero time to evangelize software I don’t even fully believe in.  You can get away with not filing bugs for Adobe as long as you evangelize and help the community, but even that value perception has fallen out of favor apparently.  Given the fact that I’m focused on higher level problems like software workflows, marketing, sales, and products, this is time NOT spent talking about how dope Flex 4 states are, or how wonderful Flash Builder 4 handles certain coding challenges.  I’m not alone in this career transition, it just sucks that I can’t really devote the time I need to get respected again.  Additionally, Adobe’s focus, at least in the Flash Player sphere, has been exposing boilerplate API’s and functionality to allow them + 3rd parties to build powerful extensions on top fo the Flash Player.  I totally agree with the approach, but I’m not technically saavy enough to really help them in this area.  I know what my clients need and want, but translating that to a use case “please expose sound data via sound sample data so I can build Hobnox” is just not a jump I can technically make. To be fair, only 10% of it is CS3/CS4 related.  I screamed and bitched at Macromedia and Adobe for years, and saw the fruits of my suggestions along with the communities become a reality.  While some of their software is old, and it’s challenging for them to add pimp, new revenue generating features without alienating old markets or breaking old workflows, they still have people with mad skillz working for them, with a long successful track record (except for Flash CS3 and CS4; even though Fireworks CS3/4 crashes, we ALL love that prog).  I’m still in good with the Flash Media team, though, and that’s been helpful since I’ve been 100% focused on video for the past 3 years.  They are a pretty thick skinned bunch, so maybe that’s why… Anyway, given the amount of responsibility I have with running my own consulting firm + having 2 kids, I just don’t see how I can return to the days of old where I’d take 4 hours one night, create some kick ass shit, blog it, and thank Macromedia/Adobe for the cool toys…. and then suggest new things.  Maybe someday.
4. The latest fad with our industry is Dependency Injection, and Yakov Fain won’t tell me what the next fad will be… if you figure that out, you’ll be the shiz.  Historically this has been what another programming community has had for years, and the Flash/Flex devs just suddenly get and freak out.  While cool, it was apparently obvious to others.
5. If a mentoring program existed for the Flex community whose sole goal was to make 1 product/project complete and “live” from 1 of the 30 “side projects” each Flash/Flex dev has on their computer, the world would be an AMAZINGLY better place.  All these 20% to 80% done apps/libraries/products that these developers have, some are really damn cool and NEED TO BE RELEASED.  Those like me who know this have a moral responsibility to help/empower these individuals to “do the last 10%”.  I don’t know how to do that, but it needs to be done somehow.
6. People who create kick ass open source projects don’t get enough feedback.  The only solution I can think of is people need more evangelists to not only promote their projects if they aren’t capable of being evangelists themselves, but also utilizing those envangelists to forcibly extract/publicly recognize via Twitter & Blog streams successful projects that have utilized their software.  Meaning, like Joel Hooks will re-tweet Robotlegs endeavors done by the community to help give it a wider recognition.  Additionally, he’ll interact with those who’ve done projects, and take “back to the Robotlegs community” the problems/concerns/commendations those who use the software.  Steven Sacks getting public, community member quotes on the Gaia site is another example.  Projects like PyAMF and Hamcrest need this role, and I’m not really sure how to help them recruit for it beyond citing simple tasks they can do to help themselves.
7. Dan Florio was right in ignoring my advice.  I told him not to do RunPee.com.  I didn’t think it’d be profitable.  I was wrong.
8. A lot of people in our industry are happy to make bling working on consistent Flex work with a consulting firm.  I am not like this.
9. There’s a growing desire for many developers to learn & teach UX concepts.  This is a direct result from the lack of qualified UX talent.  Since this discipline most affects our client’s bottom line as well as project costs & risk… we don’t have time to wait for UX people to just magically popup out of colleges.
10. I’ve gone 10 years without having a contract of my own, and signing any contract a client/company/consulting firm throws at me.  As long as the correct rate/price is on there, I didn’t care what the rest said.  After seeing Ellie Khabazian’s presentation, while I won’t create a contract of my own (since the clients work with would never sign it) I will most definitely ALWAYS be reading contracts I sign, and adjusting wording as necessary.  I’m one lucky mofo.
11. There seems to be more animosity towards Silverlight, and more fear towards HTML5.  Those in the know don’t care about HTML5, and don’t seem to fear Silverlight.
12. A lot of the old Flash devs don’t seem to see a lot of rapid innovation in produced content, whereas the new devs seem to have that feeling of daily finding wonder that the old ones had back in 2002.
13. Twitter makes blogging hard.  We all already knew this, I just got more corroboration.
14. Writing large scale examples for frameworks is a constant problem in “finding the time”.
15. I have a lot to learn about sales.
16. Getting developers on camera is freaking hard.  For a podcast?  Simple.
17. Getting Kevin Suttle to break character is freaking hard.

Hope to see y’all another conference soon!  Thanks John & Tom.

There are a lot of good articles already written & screen casts about memory management in Flash Player.  I encourage you to read them first before reading the below.  I cover memory management in a large application using a PureMVC architecture, typically on top of Flex.

• Unloading Flex Modules
• Resource Management in AS3 Session Notes Available
• AS3 Resource Management: Part 1
• Garbage Collector Interactive Simulator
• Garbage Collection and Memory Leaks
• Memory Performance in the Land of References
• Flash Player Memory Management
• Using Object Pools
• Object Pool Class
• Tweening and Object Pools
• Garbage Collection with Flex and Adobe AIR
• Screencast: Performance and Memory Management

Introduction

Memory Management, referring to making sure your application doesn’t leak memory through the use of responsible coding practices, is hard.  It’s even harder if you don’t have a history of having to deal with such things (*cough* Flash Developers *cough*).  It was challenging for me to learn… and I’m still learning.  As the Flex community has grown, we’ve seen the influx of more traditional programmers to help write blog entries and white papers, especially for AIR apps, on better memory management, how to prevent memory leaks, and how memory in the Flash Player works (and doesn’t work).

What I haven’t seen is this applied to Enterprise programming and frameworks.  Most articles are either from a Flash game developer, or a Flex dev referring to AIR applications.  From my consulting, the people who need the biggest help are doing the web applications that need to run as long as a normal desktop application.  Below, I’ve documented how you do this using PureMVC.

Why Memory Management?

Many Flex & Flash projects don’t need to use good memory techniques.  Memory leaks on a small scale are ok.  If the application is responsive to the user, you have no problem.  The purists will argue that creating a bunch of things and not removing them from RAM is bad.  However, if your application works, is responsive to the user, and doesn’t adversely affect other applications, then the purist is wrong.

For things like games that use a lot of system resources, or applications that need to run on your computer longer than 10 minutes, memory leaks will eventually use all available memory that a SWF is allowed, and cause it to stop working, or the browser to crash.  The application will be slow to respond, Garbage Collection may freeze Flash Player while it attempts to clean up, and/or your memory will become fragmented over time.  Fragmented memory makes things slower to access it, and thus can slow down your application.

Another side effect of not cleaning up the memory you’ve used yet no longer need is weird bugs.  You’ll sometimes have objects around that are doing things, yet you have no strong-references to.  Examples include timers still running, service classes that were “removed” yet receive a response from the server and no one is still listening for the response, or duplicate PureMVC classes.  Weird bugs can arise from these situations, causing your debugging time for problems to take longer.

Bottom line: If you want  your application to run for hours at a time, not to adversely affect other applications, and remain responsive, you need to employ good memory management.

Smaller projects that have memory leaks can often be re-factored.  Enterprise ones, however, will often take months to fix.  Worse, those months will have a major lack of visible project progress as things are broken on purpose to get things back into shape.  This is sometimes a contributor to the reason larger projects have the infamous “last 10% is 90% of the work”.  If you don’t start early with easy to follow conventions, it’ll be really hard to add them in later in; “add” is too nice a word since those projects don’t just stop to wait for you to clean up some memory; the logistics are a lot more complex than that.

This is even worse in Agile.  Where 80% of your time is re-factoring and you’re constantly creating new code, it’s quite challenging to keep up.  The best you can do is have a good understanding of the life cycle of your app.  The better understanding you have, the better you’ll be able to know what you don’t have to clean up, and what you do; i.e. when you have to write code and when you don’t.  Remember, designers / UX people can help here.  They’ll be able to give you a better understand of user paths into your app, and you can focus on what truly matters and knowingly let the rest remain in memory.

Example: If the user is constantly creating 3 types of forms, you can focus your efforts on ensuring they are cleaned up.  If the user hardly ever goes to a FAQ page, you can spend little to no time ensuring it’s cleaned up.  The reverse can be true as well.  If the 3 forms are accessed often, you can ensure that only the data they create is unique, but the forms themselves remain in RAM.  You can instead focus your efforts on those items that are rarely accessed.  If you user does go to the FAQ page, they shouldn’t be punished when they leave; it should remove from memory.

Why NOT memory management?

Memory management, sadly, requires you to often write more code.  More code is a negative contributor to projects.  For Enterprise code bases, they are often quite large.  Even when all features are completed, you are often adding more code for modifying features, or fixing bugs.  The last thing you want to do is knowingly add more code if you can help it.

A common practice for classes is to add destructor methods.  These are basically methods that are called “public function destroy():void” and clean up the class.  It’ll remove strong event listeners, remove child display objects, and stop asynchronous classes such as Timers, Sockets, and service classes.  Another common practice is to create “addListeners” and “removeListeners” functions that will do just that; add event listeners to an object/objects, and remove them.

Often, though, both classes fall into the trap of those methods never staying in sync with the rest of the class.  If you create a new object, you forget to clean it up in destroy.  That, or you add a new event listener amongst the other 4, but forget to add it to the removeListeners function.  Worse, and most often the case, these methods aren’t ever called.

The developer meant well, but ended up creating more code, code that isn’t used, and code that isn’t even finished with no obvious indications thereof.  The road to hell is paved with good intentions.

When View’s Go Away

When creating applications, whether Flash or Flex, you’ll have View’s that are shown and hidden.  You’ll have to make the decision how they are hidden.  If you need the View quickly, you’ll set visible to false and true.  If you don’t need to View quickly, you’ll simply addChild/removeChild.  If you only need the View rarely, you can destroy it entirely and rebuild it when you need it.

When you know you need to destroy a View, then you can write code to remove it from memory.  This is the only YAGNI approach I’ve found that works.  Meaning, as soon as you recognize you’ll need to remove a View, only then do you write code to clean up the mess.  If you do it prematurely, you just wrote a bunch of code you may never need, and now have to maintain.  Adding it later actually isn’t so bad, but that assumed you designed for it.  Meaning, if you don’t make it easy to remove a View, it’ll be hard because you first have to re-factor the code that uses it.

From a GUI perspective, this is sometimes ok.  Take the case of a View used in a Flex ViewStack.  All a ViewStack does when you leave a View is remove the View from the DisplayList.  If she’s a big View, that’s nice… but not enough.  You’ll need to refactor this code to support the child in the ViewStack from being destroyed.  You can either wrap the View you want destroyed in say, a Canvas that has code to destroy/create the single child View based on Event.ADDED/Event.REMOVED.  That, or you could make the child a ModuleLoader, and based on Event.ADDED/Event.REMOVED, load/unload the module.  Or, you could just write a function that creates/destroys views based on where it’s supposed to go.  You lose the flexibility & ease of using a ViewStack, but you get more control with more efficient code.

Registering & Unregistering View’s in PureMVC

…but this assumes you can, in fact, get the View out of memory.  In the case of frameworks, larger Views will often use the Presentation pattern, a Mediator, or something like it.  Sometimes it’s directly in the View itself.  How ever it’s done, the “Master View” will integrate with a framework.  In PureMVC, this is usually via registering itself with PureMVC.  There are varying ways to do this.  The way I do it is via ApplicationFacade.getInstance().registerMyView(this), where “this” is the instance reference passed in.  The ApplicationFacade will take the instance, create & register a Mediator passing the instance into the constructor of the Mediator.

public function registerMyView(view:MyView):void
{
        facade.registerMediator(new MyViewMediator(view));
}

Others will dispatch an event, and have a Command class handle those details to prevent their ApplicationFacade from growing large.  Either way, time and time again, I see View’s that should be removed, but have no “unregister” function, nor a Command to remove the Mediator.  Basically, there is a lot of code to register the View the the framework and create associated Application domain classes, but nothing to clean up everything when you’re done with it.

The way I do it is via ApplicationFacade.getInstance().unregisterMyView(this).  This is the opposite of the last method; it’ll unregister the Mediator.  The Mediator’s onRemove function will fire, which gives the Mediator an opportunity to clean itself up.

public function unregisterMyView():void
{
        facade.removeMediator(MyViewMediator.NAME);
}

Weak vs. Strong Listeners

Let me take this opportunity to protest against using weak listeners.  They are for pussies.  Seriously, the only time they are valid is when you are creating code modules that other developers could use, and there is no conventional destruction point.  Since you have no control over when your code will have the opportunity to clean itself up, nor do you know if the developer using your code is smart enough to call your destroy method, you try to code as defensively as possible.  If you must snag a reference to a global object such as “stage” for example, which’ll surely lock your code into memory, you at least make it a weak listener AS WELL AS listening for Event.REMOVED_FROM_STAGE.

It’s been suggested to always use weak listeners when using Timers for example.  Since these are some the major culprits of memory leaks in applications, if you use a weak listener, you’re set right?  Same with Dictionaries with weak keys, right?  *face palm*  Sure man… with that attitude, I’m sure you’re code REALLY makes an effort to help clean itself up.  Besides, Flash Player 9 has some issues garbage collecting weak listeners, so you can’t even depend on it working as advertised.  They’ve fixed a lot of this in 10, but you need to make an effort to de-allocate as much memory as you can.  Just because a large object has no references to itself doesn’t mean the Garbage Collector will immediately free up everything.  While it is a black box, you do have ways of helping it out.  In my experience, it’s more likely to free up smaller objects more often than large objects since running Garbage Collection itself is a processor intensive operation.

If your code is explicit, it’s clear where you’re freeing memory.  If you’re not, it’s challenging to figure out where leaks occur, nor is it easy to write proactive code to free up memory.  Granted, deadlines may dictate otherwise, and I concede the point on those instances.  Regardless, a lot of people who use weak references for listeners forget that unless they keep a reference to the object itself, it’ll randomly get garbage collected, which leads to strange bugs for asynchronous classes that are hard to reproduce reliably.  If you don’t know what you’re doing or have doubt, just use a strong reference and provide a clear way of removing it later.

Any help you can provide… would be… well… helpful!

Make no mistake: Helping the Flash Player garbage collect your objects has major, positive impacts.  Even a half-assed approach is better than none.

Let’s take an Array or ArrayCollection full of Strings for example.  He’s within a View, and you removeChild the View, and null the reference in his parent.  The GC will eat it eventually right?  Wrong… you accidentally have a stage listener buried deep within the bowels of a base class of a Button you’ve written.  If that’s all you’ve done, simply removing the child from the DisplayList and nulling the reference, you’ve at least giving back memory the View was using to display itself to the screen.  Glass half full baby!

Taking it a step farther, what if you’re View implemented a destroy method, and cleaned up its internals to help the GC out, and free up some memory of things it’s no longer using?  Remember, the View itself is still locked in RAM because you don’t yet know about the rogue stage listener.  BUT, you at least remove all Strings in the ArrayCollection and null its reference in your destroy method.  Running the Flex profiler, you’ll see some [reap] and [sweep] using more CPU time + memory go down slightly + less String instances.  Yum yum… while your View couldn’t get it’s fat arse outta RAM, you at least managed to free up all of those Strings it had a reference too.  They no longer have any references to them, and therefore they are cleaned up, and the memory THEY use is freed up.  Rad!  GLASS HALF FULL BABY!  Even with a memory leak, we’re lessening the damage by freeing as much memory as we can.

I know this doesn’t fix the problem, but if you’re under a deadline you gotta do what you can to survive.  The only reason I don’t think weak listeners are justified in the deadline scenario is because it’s like you’re not even trying to do the above: thinking about what View’s & classes need to be removed, writing destructor methods, and validating they worked.  Sometimes you just don’t have time to do those things, though…

What do you do in a Mediator::onRemove method?

Assuming you’re PureMVC is setup correctly, then the onRemove function of your Mediator’s will fire when it’s removed from the PureMVC ApplicationFacade.  Here, you can remove strong event listeners you’ve made on the View, remove the Mediator’s view reference by setting it to null, and clearing any other data.  This is where things get hard.

Removing the View’s listeners and it’s reference is easy; there is a 1 to 1 relationship with with Mediator’s and a View.  But what about Commands and Proxies?  If the Mediator registered one or more Commands, it’s pretty clear he should unregister them.  Often I’ve seen Commands that are relevant to a particular View being registered in the ApplicationFacade by overriding the initializeController method.  For smaller applications this is ok.  For larger ones, it’s still ok in that they don’t necessarily take a lot of RAM.  The problem is this doesn’t scale.  Your Facade will get really really large.  Some people compensate for this by creating multiple Facades for the relevant Application Domain (called Contexts in early RobotLegs builds).  While this spreads the damage, it removes relevance from the code; it isn’t immediately obvious what problem domain these Commands are associated with.  When the Mediator registers them, it’s usually pretty obvious.  That, and it makes it easier to remove them with confidence without worrying about breaking things.

…Proxies, however, are another story.  Proxies are the #1 cause of race conditions in PureMVC.  Regardless of how they are written (holders of data as your Model or Services or both), they are often encapsulated enough that they could be relevant to many different Views, and thus many different Mediators.  This causes a problem in knowing when they should die… if ever.  The benefits of using a stateful client like Flash Player RIA’s, as opposed to a paged based, non-AJAX HTML application, is that you get the benefits of keeping data in RAM.  This in-RAM data allows the application to be quick and responsive.  As long as your data is ActionScript objects (excluding XML, Strings, Bitmaps, and large ByteArrays) your memory usage is often very low.

Therefore, there isn’t a lot of harm leaving Proxies around.  The one side effect is when your profiling your application via System.totalMemory, you’ll notice it doesn’t go down as much when you’re View is destroyed.  Using the Flex profiler, when taking memory snapshots, you’ll notice you’ll have a lot of potential loitering objects (things that are still around in memory even after your View is destroyed and Garbage Collection has run).  If you’re trying to track down a leak, some of those loitering objects, your Proxy and his data, are valid… you want them to loiter in the first place so you can immediately access them again later.  Additionally, you’ll need to write more defensive & proactive code in your PureMVC code that accesses the Proxy.  For example, instead of registering the Proxy every time, you need to ensure it’s not already registered.

private function getSearchProxy():SearchProxy
{
        var searchProxy:SearchProxy;
        if(facade.hasProxy(SearchProxy.NAME))
        {
                searchProxy = facade.retrieveProxy(SearchProxy.NAME) as SearchProxy;
        }
        else
        {
                searchProxy = new SearchProxy();
                facade.registerProxy(searchProxy);
        }
        return searchProxy;
}

Another tactic if the amount of data a Proxy has uses a lot of memory, or you just need every byte you can, is to cache on the local machine.  If you’re running in a web browser, you can use a local SharedObject and save your serialized data.  If you’re using AIR, you can read from the local disk via File, or use the local SQL database support. When the Proxy is re-created, he can check the local cache first, validate the data is good, and use it instead of fetching it again from the back-end.

Bottom line, if you DO remove a Proxy, that’s your cue to go implement his onRemove method as well.  Here’s an example of a Mediator cleaning up its View reference & listeners as well as proxies.

protected override function onRemove():void
{
        if(community)
        {
                community.removeEventListener(LoginEvent.LOGIN, onLogin);
                community.removeEventListener(LoginEvent.LOGOUT, onLogout);
                community.removeEventListener(LoginEvent.CHANGE_PASSWORD, onChangePassword);
                community.removeEventListener(SearchEvent.SEARCH, onSearch);
                community.removeEventListener(PowerEvent.OPEN_POWER, onOpenPower);
                community.removeEventListener(PowerEvent.DELETE_SEARCH_POWER, onDeletePower);
                community = null;
        }

        facade.removeProxy(AuthenticationProxy.NAME);
        facade.removeProxy(SearchProxy.NAME);
        facade.removeProxy(GetPowerProxy.NAME);

        sendNotification(ApplicationFacade.COMMUNITY_SHUTDOWN);
}

And here’s an example of a SearchProxy nulling out internal data, an ArrayCollection and a String, as well as cleaning up an internal web service.

protected override function onRemove():void
{
        powers 		= null;
        _searchText = null;

        if(searchPowersByNameService)
        {
                searchPowersByNameService.removeEventListener(CommunityServiceEvent.SEARCH_POWERS_BY_NAME_ERROR, onSearchPowersByNameError);
                searchPowersByNameService.removeEventListener(CommunityServiceEvent.SEARCH_POWERS_BY_NAME_SUCCESS, onSearchPowersByNameSuccess);
                searchPowersByNameService = null;
        }
}

Remember, once you start implementing clean up methods, you’ll need to keep them in sync with any changes in the class.  Tread with confidence.

Conclusions

Managing memory in Flash & Flex applications is hard.  Validating your hard work actually is paying off is time consuming.  Most programmers who are used to managing memory keep it in the forefront of their minds while their coding, so they often don’t perceive it as an issue/challenge.  A lot of times the frameworks we use handle a lot of the mundane details of these operations for us (like Tweening engines).

If you’re application does need to run for any long length of time and you’re using PureMVC, having a good, up front understanding of what Views need to stick around and which ones don’t will help you better plan for which Views, Mediators, and Proxies you’ll need to write code for to free up memory.  If you do your best to make each View follow it’s own Application Domain problem it’s solving for, then it’s easier to have that entire silo follow the standard removal scenarios, and thus code to it.

For example, if you are creating a FAQ View, and it has a FAQ Mediator with a FAQ Proxy, then it’s pretty simple to clean up thing when you’re done: implement a destroy method in your View, then implement onRemove methods in your Mediator and Proxy.  When in doubt about the Proxies, just keep ‘em around since they usually aren’t the biggest memory offenders… but be sure to validate this using the Flex Profiler and/or System.totalMemory as even rogue XML can take 200 megs or more.  It’s easier to make View’s more efficient than it is to solve for race conditions in PureMVC.

A good tool to help visualize your memory usage in real-time is Mr. Doob’s “Stats”.  Just be sure your system is only running 1 SWF at a time as System.totalMemory, what Stats uses, applies to all SWFs running on your box.  I usually wrap him with a UIComponent, add a right click menu to my app to open him via ContextMenu, and launch him via PopUpManager.  Another tool you can use is Flex PMD.  It’ll help identify which code isn’t used… and perhaps should, like destroy methods that aren’t ever called.  Finally, if you’re desperate on Flash Player 9, you can also force Garbage Collection via the LocalConnection hack.  This saved us on a project where we were loading SWF’s.

Remember, if you destroy & recreate a View and his PureMVC equivalent classes a lot, you may fragment the memory over time, so don’t get overzealous.  Use your best judgement, and don’t be afraid to get the designers help on which sections of the app need to be the most responsive, and which ones it’s ok to lazy load.

Short Version

I’ve built an AIR application in my spare time using Flex that helps you play Dungeons & Dragons 4th edition faster. It took 6 months in my spare time and cost around $50k to build, and $40 a month to maintain.

See and download it here.

It was created in response to my new players, who are tech saavy, having a slow time getting a game going. I copied the design metaphor used in MMORPG games, as well as creating an online database via Django of user submitted content to help the process go faster, as well as supporting house rules. In doing market research, I found my product is for a younger generation, and this makes it challenging to market. I used an Iterative/Agile development process to ensure it got completed.

The app had 3 goals: make money, make our games quicker & easier, and prove to myself I could execute. I succeeded in the latter 2, and failed in the making money… so far.

• Preface
• Introduction: Why the need for Powerz?
• The Power of Power Bars
• Why AIR?
• Why Django?
• Self-Inflicted Iterations
• Quick Note on Scrum
• Schedule
• Technical Details
• Flex 3 vs 4
• Libraries
• Monkey Patches
• Development Challenges
• Feature Casualties
• Marketing & Research
• Target Audience
• Trip to Dragon*Con
• Failures
• Successes
• Conclusions

Preface

I’ve spent my spare time the last 6 months building an AIR application called “Powerz“. Simply, it is an application that allows you to play Dungeons & Dragons 4th edition a lot quicker. It was built in response to newer players hastily flipping back and forth through rule book pages, all the while lamenting how much easier it is to do this in World of Warcraft.

It also became a test for myself. I wanted to see if I could release a product on my own, perhaps even turn a profit. I’ve been attempting for 5 years to create an online version of D&D, fueled by the wishful emails of those around the world who both managed to get their hands on alpha builds and validated my target market. That, and I had recently become an advisor for a startup, so needed creditability that I had produced results in the product sphere as opposed to the service industry which I’m currently in (Flex & Flash consulting/contracting). I had just recently completed my first official Agile/Scrum project getting a startup client to (*ahem* near) Alpha, and upon reflecting, knew I was now capable of releasing a real product on my own.

Introduction: Why the need for Powerz?

D&D 4th edition was created, in my opinion, to cater to, what I call, the “WoW Generation”. Wizards of the Coast, the company also responsible for Magic the Gathering, owns the D&D game. They recognized that to gain broader appeal of a game traditionally challenging to learn and losing market share to video games, they needed to not only make it easier to learn and play, but also target this gaming demographic. The new rules do just that. They are easier to learn for those not inclined to “read a bunch of rules”, and the new power concept allows a gaming group to quickly ascertain how they can contribute to the group.

The problem with the WoW gen’s, though, is that they grew up texting, and not only want, but EXPECT digital tools to be there, as well as cross device. D&D, at least currently, doesn’t totally work like that. They have made great strides in years to provide online digital content, such as Character Builders, rules compendiums, and online magazines with exclusive content. What’s funny to me is that the main goal for most of this content is to be printed to paper and used during gameplay. If you want to use these tools strictly digitally, you can, but that wasn’t why they were made. Ultimately, your still going to be using “real” books during gameplay.

When you have a background in MMORPG’s, or even just gaming on consoles, you look at rule books as primitive, and cumbersome, and ultimately, not as fun. They, like me, know this problem has already been solved digitally.

What kept coming up as a hassle during gameplay with this new generation of gamers was referencing their character’s powers, the main crux of 4th edition rules. I figured if I could solve this problem digitally, I’d be onto something special. I knew I couldn’t solve everything; I’d tried multiple times in the past to digitize the entire D&D experience, and I simply didn’t have enough resources to pull that off. For a digital power bar, however, I didn’t need a lot of resources…

The Power of Power Bars

If you’ve ever played World of Warcraft, Star Wars Galaxies, DDO, or any other Massively Multiplayer Online Role Playing Game, they have the concept of a power bar. There are a series of slots on the bottom, like a horizontal list in Flex, and in each you can drop a power into. It’ll be represented as a little image icon that infers what the power does. Upon rolling over them, they provide details of what they do. Upon clicking them, you use them. While veteran players use keyboard shortcuts and macros, this GUI concept is the core to most MMORPG’s today. Players familiar with such games “get it”, just like you and I understand to click & drag on a scroll bar to scroll text.

World of Warcraft Power Bar

This interface element is important because in MMO’s, those powers, while forming the crux of the 2 most important aspects in those games, chatting & fighting, they also serve another subtle purpose. RPG games in general are technical. They basically take a lot of math, specifically ratio’s & percentages, and personify the results through the use of chance. While neat from a geek perspective, newbie players, especially those not tech saavy, can get overwhelmed by information overload.

Just like how Word hides non-frequently accessed information in menu’s that reveal, so to do MMORPG’s “reveal” information when the user requests it. Additionally, since these interface elements are actually over top of a 3D virtual world, they need to be as non-intrusive as possible.

In short, they provide the user with the ability to learn what their character can do, when she/he can do it, all using a mnemonic device of visual icons that relate to the action in a non-intrusive interface.

Why AIR?

I’ve bashed her in the past and got shot down by desktop developers who came out of the wood work.  To this day I still don’t get clients asking me to build AIR apps.  Regardless, it was a pretty clear choice as to why I needed AIR: offline capability to run Flex apps.

You can play D&D ANYWHERE. I’ve played at friends houses, at a camp site deep in the woods, on a plane, a bus, etc. All of these places don’t always have internet. Nowadays with wireless and cell phones that have decent coverage, you can tether on your device to ensure you have an internet connection just about everywhere. “Just about” isn’t good enough; if you can’t use it, or it’s a spotty connection, you view the “cloud” as holding your data hostage vs. some benevolent caretaker.

So, I didn’t want an internet connection to be a requirement, and thus, targeted AIR vs. a web browser. If you know me, using the Flex SDK was a no-brainer. If you don’t, here’s the run down:

1. Needs to work on as many platforms as possible. AIR works on most PC, Mac, and enough Linux distros. I use a Mac mostly, my gaming group uses Linux and Windows. The Character Builder for DDi works on a PC with .NET. Using CrossOver or Parallels isn’t cheap. Buying an OS + emulation software when you already have a working computer is lamesauce.
2. Writing my own component framework is time consuming. It took me 6 months to build Shuriken for Flash Lite 2, I’m still working on CorePlay for pure AS3… so if I ended up doing that, I’d spend all my time on developing code to develop code vs. finishing my product. Flex has all the components & styling features I need, Flex 4 more so.
3. I make my living developing in Flex Builder. This is what I’m most comfortable, and thus productive in.

Why Django?

Once I personally started using Powerz in my game sessions, taking her for a test run with my gaming group, a new problem arose: setup time. While battles finally went a lot faster, and focused more on strategy and chaos vs. wtf can I do, actually STARTING to play took awhile. Players had to manually input the powers from the Players Handbook into Powerz. Without OCR, this is a lot of meticulous hand typing.  This included those who played with made up house rules.

I thought, why couldn’t we do something like the CDDB days of old? CDDB was an online database where people would submit CD track lists. That way, when you turned a CD into MP3’s, it automatically filled out the song names and album name for you.  By the time it got popular, most CD’s were in the database so you didn’t need to submit them yourself. This was the first Web 2.0 (aka the read-write web) phenomenon that I remember. Basically you are leveraging the community, much like Wikipedia leverages the knowledge from every contributor in the world. This is a double-edged sword, as sometimes CDDB would have incorrect data without an easy way to change it. Wikipedia has had its fair share of drama about article authenticity, and who defines the truth when multiple authors disagree about the same topic.

Regardless, both are using the forces of good, and showcase how leveraging community input can greatly benefit the masses. Two heads are better than one, and thousands are just f’ing awesome.

I set out to build an online database of powers so when one person submitted it, everyone else could use it.  The most common ones, say all 1st level ones for all classes, would be ready to go. That way, even new players could quickly get up to speed. Powerz is supposed to speed up gameplay, and this would be the final lynchpin.

I hate, and suck, and server-side anything. I’d argue the majority of arguments, philosophical debates, and technical podcasts about software are regarding server-side development (iPhone apps aside). When people talk about Inversion of Control, server clustering, or Aspect Orientated Programming, my eyes glaze over, I face palm, and am like, “Wow… that’ll solve like 10% of my problems. That 10% is on the server… WHERE MY CODE ISN’T RUNNING!” To be fair, the majority of all cool software is running on the server. Most Flex apps I’ve written are merely pretty faces for pimp server-side action. The problem with server-side stuff is that you can’t see it. I’m a visual person, I went to art school, and if I can’t see it, to me it’s boring. I like seeing visual results from my coding efforts, and no, logging statements don’t count.

So… I knew I was in trouble with my idea. Every time in the past I had such an idea, I merely turned to PHP, since finding good server devs looking to work for free is really hard. PHP is available on just about every web host, for free, and there are a lot of resources out on the internet for it. It’s also very similar in syntax to ActionScript, so learning it was easy. The problem is, I’m not “in” the PHP community.  Creating a user account system may seem like a reasonable programming task to me, but an ignorant waste of time to a veteran PHP programmer who has used Zend or Drupal on many projects. Most of my endeavors into larger PHP systems have failed because the workload was just to large for me to tackle both the front and back-end. I knew this time I HAD to find whatever framework others were using for a user account system. I’ve failed to find like-minded server-side developers in the past for such ideas. I actually had a friend offer his services for this very project, but I was concerned I might actually make money, and I make a rule of not mixing friends and business.

However, I had just got off a Django project. Having spent 5 years or so evangelizing AMFPHP, yet never actually successfully getting native object passing working, I decided I’d see how easy it was in Python. Additionally, my experiences using Django’s user administration interface along with PyAMF Flex integration was a very pleasant experience. Since I’d already taking a look at Ruby on Rails awhile ago, I figured I’d give Python a chance.

Best decision ever.

I don’t know Terminal, my SQL knowledge equates to SELECT * FROM *, and I’ve never coded Python before. Django is the shit. It’s so easy, I learned my way around Terminal enough to not only “run a local server” (I know, right?), sync my database, and even play with Python code, just like Director’s message window. I even learned how to remote ssh into my production server, install PyAMF remotely, and deploy my code. Django is merely a framework atop of Python, but you have to know all that insane crud just to do it. Oh yeah, and I ended up buying TextMate (in part to Kristofer’s recommendation) to use for coding Python.

Speaking of Python, it’s a LOT like ActionScript 1. Really strange going back to loose typing. Unfortunately, the only real benefit I found was more succinct code. The Aspect Orienated/Functional stuff that uses the Decorator pattern with metadata tags for designating what methods require the user to be logged in only works for more recent builds of Python. Still… I got it and think its hawt. Additionally, the fact that you can import just a method of a class and use it is neat. There’s been a request on an unnamed list requesting ActionScript 3 get this ability so when you import 1 method of a library, you don’t end up importing the whole library, and thus incur the file size penalty. Since SWF is for web, this makes a lot of sense in investing in such a feature. Python’s for loops? Holy fish, advanced, and really cool stuff, way easier than doing similiar things in ActionScript 3 (faster? doubt it). I still don’t get their slicing syntax, but I’m sure if I did it every day I would.

So why Django? Within 3 days I had learned Python, Django, and PyAMF integration to have a working user authentication system working in my Flex app. Blah blah blah… open source has no value… blah blah blah.

…I suck at debugging it, though, a friend told me to look into Python logging, but I just ran out of time… print print print OT OT OT. That, and my admin only works on my local box, not the remote server… *ahem*.

Self-Inflicted Iterations

All my personal projects suffered from the most common symptom that affects a lot of us software developers: starting new projects is ALWAYS more fun than finishing them. You accrue a long list of awesome ideas that never make it to fruition. Of those, a few you blog about. Knowing this industry, a bunch are probably worthy of actually finishing and marketing because they’ll make bling… but… we’re a busy bunch. That, or you see no point because you have no clue how to monetize them.

I’ve had this happen 3 times with my major D&D online project in 5 years, 3 times with some games, and once with every other project that wasn’t specifically created FOR a blog entry since my career started. I almost swore a blood oath before starting Powerz. I didn’t really have too, though, because of circumstances.

First, I had just got off the best gig I’ve had in my entire career. It was working for a startup as a service consultant through Enablus. So, I make bling, but see $0 bling when they insanely succeed. Quite the soul reflection project. Second, I read a book called “Rich Dad, Poor Dad” upon a recommendation form a friend, and was then pissed for 3 weeks straight. Third, I now knew how to do Agile development which was better than my made up iterative process of the past. Fourth, D&D 4th edition really is slow if you don’t know your powers by heart; it’s even worse for DM’s who have 50 billion other things to keep track of. I needed this tool!

I made a simple rule. If I was going to work on Powers, I needed to release SOMETHING a week from when I started. If I grabbed a beer and started coding on a Friday night, there better be a new build, with associated forum post, WORKING up online the following Friday. If I had something come up, like say real, paying work, or my kid(s) got sick, or whatever…. then 2 weeks. If that didn’t work because, say I only had 4 hours in a 2 week period, then I’d lock myself into finishing just one feature before I was allowed to work on anything else.

Failure was not an option. To fail is to fail myself, and everything I stood for, and for those who listened to my blog entries full of “advice”. If I did fail, it meant Agile didn’t work, and all 10 of those blog entries I wrote espousing it were utter bullshit, and I needed to die in a fire. Seriously. After being so frustrated for so long about “figuring out” software development for the past 9 years, this was the line in the sand. Pick your platform, pick your tool, pick your framework, and either put up, or shut up.  Get something done vs. proselytizing about “how to program” with nothing to show for it.

In short, finish something I started.

6 months later, I’ve released version 1.0. That feels f’ing good. Really good. That, and D&D is easier to play now for me, and a lot of others.

Quick Note on Scrum

Remember, if you ever hear about this Agile or Scrum stuff, and are like, “Wtf?”, don’t stress. All you need to know about using Scrum correctly is release working software with a new feature every week (or every 2 weeks). That’s it, that’s all you need to do to be JXL Scrum compliant. If you don’t do that, you should really take a look at what you are really trying to accomplish.

If you’re a manager who’s trying to implement it, and your developers keep going off on paths they weren’t assigned, play to their ego’s. For example, if someone says, “I could write a login form in less than a day!”. If it then takes them 8 days for the form to actually work, call them on it. I guarantee you they’ll spout off about “OOP/Framework setup”, or some other lack-of-DRY-adherence excuse. That’s ok; the point here is to show them that what they thought they could do, they didn’t actually execute on. They’ll either re-assess what it really takes to develop even simple things, or you’ll come to a mutual understanding of what “working” really means.

I had to do that. In 2001, I created a stock charting application in Flash 5, AS1 pre-#initclip days, knowing very little OOP, zero best practices, and no frameworks, in 1 month. Today, that same application would take me 4 to 6 months, and cost 177% more per hour. Granted, the devil is in the details (quality of user experience, less bugs, more features, I actually know what I’m doing now + have experience, etc), but that, to me, says something about my ability to execute. Those in software know faster doesn’t mean better… but when you start splitting hairs about even simple features, you find some surprising things about yourself. I call this, programmer self-awareness through Scrum.

Schedule

For those who are interested, here is how my schedule worked out. When I mention a week, I’m speaking about a week of development time. So, if I started coding on Friday night, but only put in 4 hours for an entire week… I certainly had very little to offer in a true build. So, my first rule was, if I could do a week, do a week, and release. If I couldn’t because I had real work to do, then I’d instead get 1 feature DONE and release. This was still hard, because even if I could only devote like 2 hours a week to my personal project, it HAD to be on that one feature, and I had to force myself to finish it so I could get a build up, and move onto another. It was far from perfect, but it’s as Scrum as I could get with my free time… and it guaranteed I’d release multiple builds with enough room for user feedback.

• First 3 weeks, spent designing & doing initial prototyping (aka design phase in Waterfall). I had no gig lined up, so worked 3 weeks straight on my own stuff. I worked for about 7 days straight in Photoshop CS3.
• Work 1 hour one night, 4 hours another, 8 maybe on a weekend, or perhaps none for 4 days in a row. Bottom line, I still followed my weekly/bi-weekly/single feature release schedule.
• One build took 6 weeks (Alpha 9 to Beta 1) because I had to learn Django and do real work at the same time. Some weeks during that time, I only worked 1 to 2 hours per week, others, I’d work 3 days straight.
• Some weeks were coding. Some weeks were pure Photoshop. Three weeks was learning/implementing Django. Four weeks was setting up the website, porting all code & assets to work on it, and installing all forum and blog software. All was mixed amongst each other. Since I was doing everything myself.
• I did Analytics once in the beginning, and then changed it 2 weeks later when I couldn’t understand my own metrics.
• Start Date: Around April 5th, 2009.
• End Date: Hopefully September 26th, 2009.
• Total Time: 6 months

It’s hard for me to predict how long Powerz would of taken had I been able to spend 100% of my time on it. A lot of things came up, positively & negatively, during development that adversely affected the timeline. Users asked for features, work flows I originally tried didn’t pan out, Photoshop designs took a few tries, and learning Django staggered overall development on the Community portion. All I know is, Flex Builder 3 and Flex SDK 3.3 is foogin’ solid for what I needed.

Technical Details

The web site is pretty standard stuff. Forum is PHPBB, and blog is vanilla install of Wordpress. Hopefully post 1.0 launch, I can modify the blog to match the rest of the site look and feel (excluding forum) via the Dreamer, an easier way to design Wordpress sites via Dreamweaver. Her majesty used it for her site and it’s pretty cool.  I also need to redo my dated screen cast, and tons of other things.

While I did the original web site designs in Photoshop, the site itself was done by her majesty and I in Fireworks.  Fireworks’ text handling is superior to Photoshop’s, and now that CS4 shares the same font engine, you can get good looking interfaces.  If Photoshop were to improve their text handling capabilities, I’d probably still use Fireworks for it’s easier object editing + grouping + moving functionality.  For the web with lots of content, it was just quicker for me and her majesty.

For the video, shot using a Sony DCR-SR200, and edited in Premiere CS3 & After Effects CS3.  ScreenFlow was used for demoing the software.

Flex 3 vs 4

Yes, I very much wanted to use Flex 4. Unlike Flex 2 Alpha, however, she’s unstable and changes all the time. You could build some pretty Enterprise stuff on Flex 2, Beta 1. I would never do such a thing with Flex 4 just because she’s in such flux, and the IDE (+ Catalyst builds) is somewhat flaky. Obviously 6 months later things are more stable… but they still changed a lot (fx prefix, Halo interop, etc.).

I used Flex Builder 3 & Flex SDK 3.2… then 3.3… then 3.4. I use AIR 1.5.2. AIR still has a bug where you can’t seem to use compc (aka Library Projects) because of some weird Vector bug in playerglobals.swc or something. So I just gave up on using a library project.

Libraries

I have 1 Flex project, and a ton of libraries. Ones of note are:

• Cliff Hall’s PureMVC
• Ely’s SuperImage (that I patched)
• Claus Wahlers’ and Max Herkender’s FZip for reading & writing my custom file formats
• Christian Cantrell’s NativeAlert ported to Flex
• Google Analytics
• Google AdSense
• as3corelib for JSON, used in reading & writing custom file format
• Adobe AIR Update framework (which refuses to GTFO of RAM) with custom badges written in Flash (zomg!)
• my DebugMax window which is a lame attempt to copy that older Flash debug window (the Portuguese one)
• …and Grden’s localToLocal function
• Server is running Django on Python, using PyAMF to send AMF objects back and forth. I’m only using one class; getting nested ValueObjects to work with inherited and one to many relationships in Django’s Models was nigh impossible to debug.  For now, I just pass simple Objects which are uber-easy to parse.

Blah blah blah… open source provides no value… blah blah blah.

Monkey Patches

1. Commented out a bunch of InterManagerRequest code in AIR’s NativeDragManagerImpl class. Doing drag operations would cause the app to lock up for 7 to 11 seconds. Not sure if this was fixed in 3.4, but I don’t load multiple Flex apps with different SDK versions, so don’t need this code.
2. Added bitmap smoothing in SWFLoader, which Flex SDK 3.4 (or 3.3 I forget which, added officially)
3. Added a numLines getter to Label for more accurate text height measurement… which I then later didn’t use.  Proper invalidation fixed my measurement bug; text can be finicky, but if you wait a frame……

Development Challenges

There were 3 development challenges I faced.

The first was developing in AIR. If you are using Flex in AIR, it’s nearly the same thing. The hard parts were learning how Windows work, and their quirks (such as when does Window REALLY get its reference to nativeWindow?). How do you design for this as a designer, and what is an appropriate design metaphor? Multiple windows, or 1 window with many states? Also, event bubbling doesn’t work with windows, since each has it’s own stage, so there was a learning curve of when to manually re-dispatch, and when to just hand off to PureMVC Mediators.

The second was learning to work with reading and writing files. The FileReference class is EASY, but there are actually 3 classes (really you just work with 2) for AIR. They too have intricacies to learn, and how you can abstract them, and what the costs are in doing so. What was fun to figure out was how to associate a file with a document window in the PureMVC framework. I really had a tough time trying to tightly couple something when you’re technically not supposed to tightly couple anything in programming.

The third was creating a file format. I believe most traditional developers would of used some sort of serialization via ByteArray and the IExternalizable interface for your objects. To me, that stuff takes a lot of work, and isn’t easy for me to debug, nor verify if it worked. Maybe to those who think in 0’s and 1’s, but not me. It took some tinkering; I copied how SWC works.  SWC is a ZIP file with some XML and binary assets all inside. My file formats are basically the same thing; a ZIP file with a JSON text file holding the serialized object, images for any icons, and a text file determining what type the file format is (since you can’t rely on file extension). This allowed me to open up the file to see it’s contents and confirm my code worked as well as perusing the JSON to see if my objects serialized correctly.

What was great about being the only developer was that I was also the designer and back-end developer.  I knew how to design assets for Flex and could predict what I’d need designed. As the back-end developer, I could create data that the client would need, thus making my job easier in both places.

Feature Casualties

I had 2 features that caused major scope creep, and thus extended how long it took. They weren’t a waste of time, but as with every project, I learned something.

The first was the whole “document editing process” that people are used to. You open a file, edit it, save it if it’s dirty, and close the “document”. If you “Save As…”, you create a new file, yet use same window. I didn’t use this model at first. Instead, I just opened files, kept a reference to the file handle for each AIR window, and removed it when the window closed. However, this is not how every other desktop application works. Additionally, for those on network drives, you couldn’t really work with the files easily when moving things since it always had an opened file handle. So, it was a pretty big re-write/re-factoring effort to put this functionality & work flow in. I know how to do it now, but I’m just glad no one asked for undo yet. *whew*

The second was pimping out Christian’s NativeAlert window. I spent 3 days in AfterEffects when I was between gigs creating a transition in and transition out for the window.  Instead of just popping in, it’d “materialize” in, all magical like. To me, and one of my users, it looked awesome. It got old after 2 uses because you had to wait for it and there are a few alerts when saving files. If I speed it up any, it loses fidelity… so I just removed it. It required a lot of custom code to make the alert do it’s modality magic in time with the transition. I didn’t get to use any of it.

Marketing & Research

This was the most interesting for me. While I’m not a good salesman, I feel that I get online marketing and branding. I also feel like I understand my target audience, since I’m part of that audience. I actually did market research (aka learning my target audience and their needs) both at the start and during development.

I looked online and read about what WotC was offering, and then I looked at all the 3rd party offerings. I took a few for a spin. I read user reviews on forums and blogs, especially the passionate ones. I wanted to gain a better understanding of what they liked about the software, and how they expected software to work. There wasn’t really a pattern. The bitching about lack of Linux/Mac support was low, and a lot of the 3rd parties utilized Java. For those that didn’t, there we already well documented ways of installing a Windows emulator.

One thing that reading the forums did for me was really educate me on the current flux of the industry. Technology really has changed, and continues to change, table top gaming. WotC is in an interesting time of the market, and frankly I’ve think they’ve done a good job on positioning their D&D brand & rules for 4th edition to perform well with these changes. Where they haven’t done entirely well is executing both their community aspects online, as well as delivering their associated digital tools.

The short version of WotC’s transition to the digital age is, as magazine sales declined, WotC first sold their magazines to Piazo, and later brought them back and incorporated them into their new online subscription service; they no longer print magazines. You get the monthly magazines digitally, exclusive content, as well as access to their desktop and web tools. There are good and bad things about this. Some of their software isn’t released years later, but the ones that are are definitely nice.

Target Audience

I wrote something similar to this over a the Powerz blog.  Bottom line, there is a lot of confusion, at least for me, on who really is the target demographic. The high level view is that the older players prefer tangible rule books, whereas the younger ones are more apt to digital content. That’s where the black and white views end. Some from both groups are fine with digital content, but intend to transfer that content to paper in use in their games. Others would prefer to wholly digital, yet still play in person with their friends; like a LAN party.

I intended to confirm this suspicion beyond just talking online…

Trip to Dragon*Con

…so I took a trip to Dragon*Con 2009 this year. I go every so often to stock up on new dice as well as to see the 501st. My goal this year was to promote Powerz, and meet potential customers. I knew it would be challenging for a few reasons. First off, finding D&D players is actually hard. It’s a huge Sci-fi & fantasy conference; it’s not solely for D&D’ers. Additionally, most D&D’ers who do go play with their friends at predefined tables in a reserved hotel ballroom. These are usually niche groups, and while friendly, you can’t just barge in on them in a middle of game. If someone did that to me during mine, I’d be really ticked off. Additionally, the conference itself is confusing because it’s spaced around 4 semi-adjoining hotels (Hilton, Marriott, Sheraton, etc.), and signage isn’t large/verbose enough for you to get a clear picture of where you are, nor what events are happening where. I knew it’d be hard. Her majesty helped set my expectations to a reasonable level.

My first attempt was while waiting in dice line (like a food large buffet, except there are different colored dice you can choose from). One particular customer was taking awhile to get his transaction finished, and was in a TF2 spy costume (I think), so I figured he was a good target.

“Hey chief, you play D&D?”

“Yeah!”

“Cool, you play 4th edition?”

“Naw, 3.5.”

*sigh*

I then asked the attendant who was waiting on customers, but he didn’t play, just pointed to one of his co-workers; but they were UBER busy. Even Solid Snake briefly came out of his box to browse their wares. I didn’t want to annoy every customer, so moved to another vendor booth, full of D&D books.

A girl was just sitting down in a chair, and lamenting about how good it was to sit down. Prime target.

“Hey, you play D&D?”

“Yeah…”

“4th edition?”

Irritatedly, “Only because my group made me…”

“Rad, do you mind if you ask you a few questions about some software I’m building?”

Cautious, and body language suggesting she was about run at the slightest sign I was a vampire, “Ooookkkayy….”

I sat down next to her on the floor to make her feel more comfortable with my laptop, and briefly walked her through why I created Powerz, and what it does.

She immediately got excited, “Oh we already use that through our DM. He uses WotC’s subscription service… DD something…”

“DDO or DDi?”

“Yeah.”

“Which one?”

She shrugged but excitedly explained, “I don’t know, but it’s great. You can input all of your character data, and it prints out all your powers. Our whole group does it.”

I then proceeded to ask her questions about how her group plays, and take notes. Another gent from her gaming group joined in on the conversation, and motioned to a 3rd member who was also browsing books nearby. After I had asked my questions, I thanked them for their time… and went looking for a bar. I suddenly felt insecure, ‘How could DDi do all that? There is no way, I’ve seen the screen shots, read the reviews….’

While waiting for the bar tender who was overworked, and was already getting heckled by some disgruntled women next to me, I reflected on those I had talked to. I knew a lot of the older generation was very pro-3.5, me included. I really like, still, the 3.5 rules and felt they were akin to Macromedia’s Flash 8; the pinnacle of the company. I started getting really depressed, and quickly started going over all of my past research in my head.

…then I remembered something the girl had said. “Print them out.” Print? To paper? wtf? A smile came to my face, I gave up waiting on the bartender, and quickly headed to where I remembered the D&D gaming tables being the previous year. I stopped by the bellman’s desk to obtain some change so I could buy a few people beers in exchange for me pestering them with questions.

Paper. That was really what I kept seeing. The generation gap in that one prefers tangible assets to play with and the younger ones do not. Again, it’s not that black and white sometimes, but it’s still true. While waiting 1 hour and 40 minutes in line, I met a father who had brought his 11 year old daughter to “meet” the creators of the online game she played. It was some alternative to Club Penguin, which was apparently ruined under new management. She was really excited, and wanted to be a programmer when she grew up. The father, clearly out of his element, saw me in my business professional getup, clearly over dressed for such a casual, and often costumed event, and seemed happy to have some one to talk to. He found it strange that his daughter would spend his money on these online games for things that didn’t exist. Instead of a new barbie doll, she’d get a some new, exclusive outfit for her online character. We discussed her online habits, and those of her friends. I explained what I did, and he was intrigued.

His daughter is my target audience. The girls and boy in front of her, definitely early teens, one dressed up as Naruto, and others as Sango from InuYasha… those are my target audience. They grew up texting, the internet always existed. Those who were my age, dressed up as star trek characters… those probably aren’t my target audience. These kids revel in online content, but still have social interactions with each other in person.

People like me, and the kids who are used to digital tools don’t mind keeping things digital. Others see digital tools as a means to a paper end.

Upon leaving, I was convinced my target audience was mostly online and not at Dragon*Con… or at Dragon*Con WITH their PARENTS. It was a great learning experience, even talking to the few people I did was helpful.

Failures

The project as a whole, while successful, failed to meet one of its primary goals: make money. It does have some successes, which I document below. I had two main goals: releasing a product to prove I could execute, and to make money, enough to cover costs. Currently, there is not enough community features to justify a subscription pricing model. Additionally, I highly doubt I’ll get enough users to cover the costs via the ad supported model I use currently.

If you add up all the costs:

• Around 6 to 10 weeks of man hours (design, development, marketing + expenses)
• hosting costs ($20 hosting + $20 Django container @ Mediatemple)

The total comes to around $50,000. Each month I go $40 more into the hole as the ads currently aren’t providing enough revenue to cover costs, and I haven’t figured out how to monetize the anonymous usage data.

I have a new idea that will actually generate revenue, and Powerz could actually be a companion application, so that’s a positive.

I’m not sure about this statement, but… here goes: I’m glad I know I’m capable of executing vs. knowing how to make money and not execute. This, as opposed to someone who knows how to make money, but can’t execute. The sad fact is, most rich people I read about know how to make money, and get other more qualified individuals to execute for them.  Doh!

As a developer, however, I view this as yet another thing to learn, so that’s a good thing! If I start learning how to monetize things better, I can focus my development efforts on what matter monetarily, and eventually find easier ways to leverage help vs. doing everything myself. If at first you don’t succeed, try, try again.

Successes

My favorite part, the wins.

1. I now have a tool to make my D&D gaming easier, and more fun.
2. Others now have access to the same tool, with the ability to help guide it’s direction.
3. I’ve proved to myself for the 2nd time that Iterative development works.
4. I’ve proved to myself that I can execute on my ideas.
5. I learned Django & Python, and also learned not to hate the server-side.
6. I’ve learned, again, how much work it really takes beyond just coding to release a product.
7. I learned a little bit about engaging potential customers.
8. I learned a little bit about market research.
9. I learned how NOT to migrate data.
10. I now have something new to learn: How to make money with software.

Conclusions

While I’m disappointed I failed to monetize my work, it’s still early in the game, so maybe I’ll think of something. Overall, I’m really happy to have finally finished one of personal projects into an actual product. That, and I learned a ton. Soon, onto idea #2!

If you play D&D 4th edition, check it out and let me know what you think. If you don’t, but know people who do, let ‘em know; I’d be most appreciative!

1. Part 1 – Stressful
2. Part 2 – Code Refactoring
3. Part 3 – Branch Workflow
4. Part 4 – POC, Strategy, and Design Challenges
5. Part 5 – Acceptance Criteria & Punting
6. Part 6 – Tools, Extra Merge Day, and Postponed Transitions
7. Part 7 – Bugs, Unit Testing, and Throughput
8. Part 8 – Demo, Burnout, and Feature Juggling
9. Part 9 – Scope Creep
10. Part 10 – Conclusions

This entry is about utilizing branches for each developer in Subversion, Merge Day, and how while cool, it’s an ivory tower process.

Note: This isn’t a tenet of the Agile methodology itself, it’s just something that works well when you have a bunch of developers collaborating together rapidly, and a specific workflow our client requested we follow.

Branch Workflow

We’re utilizing a Branch Workflow on my current project.  What this means is that each developer creates their own branch in Subversion.  If you’re utilizing Tortoise SVN on PC or Versions on Mac, this is effectively a folder.  As you may know, Subversion has 3 default folders that you typically utilize in a repository, and hopefully each project gets its own repository.  These are branches, tags, and trunk.

Some people choose to ignore these.  Some put multiple projects into the same repo.  Both are fine because the mere fact people are utilizing source control in the first place, even if its just for disaster recovery, is great.

These folders, however, really do have a few reasons for their existence that have been well thought out.  Each source control system tries to out-do the next.  In Subversions case, the simple definitions are trunk is for the current version of your project, tags are for multiple older versions of your project, and branches are for experimental features or code that will possibly be merged back into trunk later.

Those are EXTREMELY simple definitions.  If you read the SVN book as well as other people who incorporate SVN into their workflow, the definitions and purposes can get quite complex.  For the project I’m currently on, branches take on a new meaning.  Not only are they where experimental code goes, but they each represent a user story.  Meaning, if I’m working on completing the user story where the user can modify their hardware device settings via a Flex form, that’ll go in it’s own branch.  Using source control to do this is pretty straight forward.  Instead of checking in here:

https://svn.server.com/repos/project/trunk/

You instead check-in here:

https://svn.server.com/repos/project/branches/sprint2/deviceform/

And the other developer with me would be working from:

https://svn.server.com/repos/project/branches/sprint2/registration/

Pretty easy right?  It gets even easier to check in.  No more, “Dude, have you checked your shiz in?” to another developer, or the cardinal rule of doing an update before checking in.  Now you can check in to your hearts content knowing it’s your own repo to abuse how you wish.

This has the side benefit of NOT breaking trunk… usually.  Again, the point of having frozen code you KNOW for a fact works is to use a tag, or a series of tagged builds.  A lot of developers get seriously bent out of shape if you break the trunk.  At one job, whoever broke the trunk had to use this monkey icon for their IM icon for one week.  It was funny until the 50th person asked why I had a silly monkey icon, and by that point, I was swearing I’d never break ANY trunk ever again.  This can possibly have the effect of keeping ‘em happy.  At the very least, this reduces the possibility of it happening because no one is working from trunk.

Instead, you check into trunk at the end of every sprint, or for my team, from Merge Day onwards.

Merge Day

Part of Agile is to have a day a few days before your UAT where everyone merges their working user stories into the same code base and “works out the kinks”.  Since everyone was coding in a different direction, this can be good and bad.  Good because they are working on completely unrelated things, but in GUI coding, we all know some things are extremely related.  Specifically, these are your data model in the form of ValueObjects, calls to a framework such as the use of Event classes in Cairngorm and PureMVC Mediators, and modifying settings in higher level view’s or CSS.

Since this can potentially have major consequences for some portions of a user story, or set of stories, it’s important to devote a pre-scheduled time where the team knows their code will be merged with everyone else’s code.  This is called Merge Day on my project and it happens every other Wednesday.  I take my branch and my co-workers, and merge his code into mine.  Then, I fix things that explode.  This could be as simple as just merging code over, or a complex verbal discussion to work towards resolving 2 different implementations.  No code is trivial.  If another developer added a style to MXML for example, setting the background color may seem small to you, but could be the difference between working or non-working code for the other developer’s code, so its important you do these merges together.

Once that is done, I merge into trunk, test again, fix explosions, and finally check in the working build.  I then upload a new build, or in the case of my current project, deploy a new build in a new sandbox utilizing Django’s web interface.  It can deploy to the web the latest bin-release that’s checked into SVN by merely clicking a button.  I’ll send an email to all members of the team identifying what’s new in the build.  This includes user stories, fixed bugs, and other things of note that are different from previous builds.

For fellow developers, this is a courtesy.  For Project Managers, it’s a necessity for them to set client expectations for Friday’s UAT.  For everyone it’s a Sprint milestone as well as reality check.  You can identify what user stories are done, which ones aren’t, what older ones you may have broken, and which current ones have issues.  You can then plan with your team what to spend the next day and a half on.  This is also where the rules can potentially break down.  What I’ll usually do is check my local copy into a new branch, and either fix partially completed or broken user stories, or just finish what I can.  The temptation here is to abandon branches since you only have a day and a half and it isn’t worth the trouble; just don’t break trunk in the meantime.

…riiiight.  The last thing you want to have happen the day before UAT is get all stressed out because trunk is broken.  To me, it’s worth the extra time in using the process to ensure your UAT prep goes smoothly.  I’m conservative.

I say that all high and mighty like, but on Sprint #2, I did just that.  Did I get lucky or was it just mad skillz?  Luck.

Conclusions

Now, all of the above processes could have been done with just utilizing trunk.  As you can hopefully see utilizing a branch for each developer, or multiple since creating a new folder is really easy, helps things go a lot smoother without surprises.  You can also plan for the chaos on Merge Day, which while extremely stressful for whoever is doing the merging, is at least expected and a concerted team effort.  I really have enjoyed the Branch Workflow so far.

…however, I don’t see it catching on.  Every Flash & Flex developer I’ve ever talked to doesn’t use branches.  Sam Robbins mentioned over Twitter they might start adopting this workflow at their place of work, and that’s great, but again, it seems to me most developers feel trunk is good enough and branches are just an unnecessary complication.

Stay tuned for #4 in the Agile Chronicles series where I talk about the POC (Proof of Concept), business strategy, and design challenges.