Wednesday, November 30, 2011

Journey of a software craftsman - the backstory

Just as a disclaimer, I want to state my definition of a software craftsman, as someone who recognizes that there is an art, science, and craft to programming and I'm striving to constantly improve towards mastery, knowing that I'm only going to asymptotically approach it. 

So with that out of the way, I'm going to start a small series related to my journey as a software craftsman, finding a mentor, and improving my craft. Before I get to the present, I feel it necessary to record many of the milestones and moments that have brought be up to this point. 

This post is not technical nor specifically related to Flash or Flex, but it does (hopefully) describe the initial part of my journey (before I even recognized I was on one)


  • Mid 1990's
    • Context:
      I was fresh out of school working at a multimedia company. One of our clients used Macromedia Director to deliver their quarterly+ shareholders meetings. This client had a franchise model, and as part of their presentation wanted photos of each of the franchise buildings. Specifically in their "slides" there were 4 photos spots available, each of a different franchise, and as you advanced forward, the photos shifted by one, so that it looked like a single new photo got added to each slide. This is all well and good, but the number and order of the slides changed constantly (even up to minutes before they gave the presentation.) (As I side note, they often took us along to the meeting so that we could update the stock price to literally be the current price when they presented it). Sometimes there would be 100 slides, sometimes only 15. Oh and also their was a print option, which included the scrolling photos as well.

      So basically there was about 150 potential slides, any number of which could be in a given presentation in any given order. Some of the slides had dynamic data, like the stock price, which was updated (manually) all the time.
    • Result
      While it didn't have a name to me at the time, through this project I had already separated the functionality (ordering the slides and photos) from the UI (the next frame and printing) and the business rules (externalize everything to text files (no feasible DB or internet available at the time)). It was my discovery of MVC, nearly a decade before I discovered it had a name
  •  Late 1990's
    • Context
      Many of our projects at the time were training animations with mostly linear controls. I quickly realized that testing the latter parts of the projects was very tedious as you'd have to wait for all of the previous parts to finish.
    • Result
      Modular design. I often rigged in temporary navigation panels, debugging tools, and other test harnesses, to allow me to test faster and more accurately. I was able to pull out the pieces from the rest of the application and exercise them. Nothing automated yet though, not quite. About this time I wrote a utility that would crawl the application display list,  find everything with an interaction on it, and force that interaction to fire randomly. This is the equivalent to clicking everything on the screen as fast as you possible can.

      This is close to automated testing, but it wasn't repeatable, as it randomly choose what to interact with. But while watching it, and the logs, I discovered many many bugs before it went to production.
  • Early/Mid 2000's
    • Context
      I had this intense project where the goal was to fully (nearly) simulate a about to be introduced cell phone (with a camera :) ). The project had a one month time frame, and I had absolutely no idea how to do it. Another motivating factor, was that if we could do it, there would potentially be dozens of more phones to simulate. Since there was only a month to deliver the whole thing, there was a demo every Friday. Without having heard of Agile, I was now in my own self defined agile methodology.  At each demo, we did some planning about what would be delivered the following week. It was at this moment, that I realized that the structure that I had put in place didn't scale, and I wouldn't be able to accomplish next week's goal. I would spend the weekend rewriting everything that I had to support the new objectives. This happened EVERY week. Of course each rewrite / refactoring got faster and better
    • Result
      I discovered Agile. Now it wasn't formalized, as I wouldn't put a name to it until many years later. I discovered the power of short iterations, not designing upfront, the value of starting over with leveraged experience, and refactoring. This was probably one of my most powerful experiences.

      After successfully delivering this project, and the next 2 dozens phones*, I researched how might I do simulations better next time. I came across this book called Flash MX for Interactive Simulation, which talked about State Machines and the State Design Pattern.

      This book opened up the world of Design Patterns and UML to me. The coolest thing, was that my solution for the phone WAS INDEED the State Design Pattern. I was ecstatic and amazed that I had "invented" the exact thing that others were practicing.

      This was incredible fuel to me. I read everything I could about Design Patterns and UML
    • *
      • Phone #1 = 1 month, 
      • Phone #2  =  2 weeks, 
      • Phone #3 = 1 week
      • Phone #4+ = 2 days
  • Mid/Late 2000's
    • Context
      I had the opportunity to be on some teams where there was more then me as the one developer on the team. Some were agile, most were not. I learned the value of source control, integration headaches, testing, and working with other peoples' code. I stated recognizing that code readability was critical, as well as the entire team dynamic, philosophies and varying still levels. (What do you mean you are going to reach up from the child, to the parent, to the grandparent, to another descent and change a property!! #@%! Haven't you ever heard of events? !)
    • Result
      Started on the Pragmatic Programmer and Agile philosophies
  • Late 2000 - Recently
    • Context
      I was on a massive project. Two years, 24 developers. It was huge. I was the Flex technical lead and architect. I had laid everything out (architecturally), both code wise and processs wise. We had a 13point definition of done. But when all said and done the team only accomplished 2 of the 13. We were functionally complete, but we weren't done. Because of several factors, team & management mentality, on-boarding and delegation process... we ended up with what can most easily be described as Legacy Code.

      I tried often to make course corrections to the code base and team, but it didn't happen to my satisfaction. This sent me on a massive effort to try to figure out why I couldn't communicate all of my experience to the rest of my team and what I could do to fix it.

      I devoured references like Working Effectively With Legacy CodeClean CodeClean CoderPragmatic Thinking And Learning, and dozens of other books. I was starving for any information about how to communicate better, clean up the code that was there, help my team improve, and figure out what I did wrong, or what I could do better, either immediately or in the future.
    • Result
      Recognized that I am a software craftsman, but I still have a lot to learn to get to where I want to be. I am actively working towards becoming a craftsman, becoming a mentor, finding a mentor, improving my craft and trying to advocate that quality is important for my industry. 


If you made it this far, thanks for reading my story and sticking around :) I plan on actively contributing to this topic as I continue on my journey. 

Wednesday, November 9, 2011

Flash is NOT Dead - communicating to lay people

So, there is lots of chatter around Adobe's announcement today, that I want to add my 2 cents on. I happen to be teaching a class on Flash tonight, so I thought about how to explain this announcement to my class.

While I agree with Adobe's decision (somewhat), I think they royally screwed up their communication of their message.

They've spent years training people to recognize the Flash brand, and failed to realize that most people can't distinguish all of the pieces that make up that brand. Nobody outside of the community knows that there is even a Flash Pro, Flash Builder, Flash Player, AIR, Flex... it is all Flash to them. Adobe has done a good job in that regard. So today's message that says Flash {insert ANY other words here} is not going to be supported, gets interpreted as the entire brand is not going to be supported.

Here is a snippet of their message:

We will no longer continue to develop Flash Player in the browser to work with new mobile device configurations (chipset, browser, OS version, etc.) following the upcoming release of Flash Player 11.1 for Android and BlackBerry PlayBook.

And here is what the world read:

 We will no longer continue to develop Flash Player


That is akin to reading a hypothetical message that says:
"Continental Airlines will close its Houston hub" as
"Continental will stop flying"

This is only a small piece of the whole equation. But this is what the lay person hears... and hence all of the panic today.

I came up with the non-technology analogy to explain it to my class.
(Bare with me, taking the analogy away from technology requires some leeway) :

Imagine that you are a company, called StoreYourStuffCompany, that produces magic spells (Harry Potter references to follow). Your main product is an enchantment, StuffYourStuff, that makes all of your stuff, like books, clothes, furniture, etc, fit into a given space.

Now, the enchantment has been around for a while, and actually StoreYourStuffCompany has partners including home builders, so that your home comes designed with this StuffYourStuff enchantment. Hence all of your stuff fits into your house or apartment.

Recently, people want to carry more stuff with them, and so StoreYourStuffCompany has partnered with backpack and purse manufacturers, like the following videos.


Harry Potter's Undetectable Extension Charm
and Mary Poppins Carpet Bag:


Now the problem, when you have all of your stuff in one of these bags, is that it is poor experience as Mary Poppins shows looking for her tape measure. It is difficult to get to the thing that you are looking for, and you often have to touch everything to find the thing you want.

Yet, in your house finding your stuff is a relatively good experience (assuming a base level of home organization).

So StuffYourStuff comes up with an additional enchantment, GetYourStuff, which in Harry Potter language is the summoning charm, Accio. This charm allows you to simply say what you want and it snaps to your hand if it is nearby.

The GetYourStuff is hugely successful, so much so that people don't carry the backpacks and purses, instead use StuffYourStuff to keep all of their stuff in their pockets, and GetYourStuff brings them the exact items that they need when they need it.

StoreYourStuffCompany decides to discontinue partnering with the backpack and purse makers to heavily focus on improving the GetYourStuff charm, as well as the StuffYourStuff enchantment.

Rephrased for techology this story reads like this:

StoreYourStuffCompany = Adobe
StuffYourStuff = Flash
Home / Apartment = DESKTOP browsers
Backpacks and purses  = MOBILE browsers
GetYourStuff = AIR for desktop, mobile, other

When you are on your phone, do you go to facebook.com or the facebook app? twitter.com or TweetDeck? gmail.com or the email app?

I'm guessing you said the app. That is because the experience is better. You get the information that you need/want faster without touching everything. You go to the web to look up information that you can't get from an app. You are there to accomplish a specific task, when you are browsing on your phone, and HTML5 might be the technology that will allow you to succeed faster?  

Here are some other good insights into the matter:
http://mattgemmell.com/2011/11/09/adobe-communication/
http://forta.com/blog/index.cfm/2011/11/9/Some-Thoughts-On-Flash-And-Devices

My biggest fear is that for the lay people and business people who only hear that "Flash is not to be supported" / "Flash is dead", will base their financial decisions on that little and incorrect sound bite.

Adobe will need to do some serious marketing to get the right message across.

Friday, November 4, 2011

Working effectively with novices


So I have two books that I highly recommend.

First let me explain where I'm coming from: First I'm a professor, mentor, and trainer, and I always have to try to express my knowledge about Flash and Flex to people who are brand new.

Second, as a consultant, architect, and developer, I frequently need to express the value of TDD, Agile, CI, and lots of other really good things, that are not quite development.

These books highlight the differences between a novice's brain and an expert's, and how to start bridging that gap.


Pragmatic Thinking & Learning by Andy Hunt, talks about the novice versus expert brain. How the brain interprets and responds to signals. This is written by programmers, and is incredibly useful.

For me, this book answered the question of why did my project managers always seem to make decisions that I didn't agree with and I urged against.






Made To Stick by Chip & Dan Heath, is a fantastic book about what makes an idea or concept "sticky". Why do we remember certain stories, advertisments, urban legands after hearing them once, yet things critical to our job we forget the moment we leave the meeting.

I feel like this book would have been helpful for me to persuade the aforementioned managers of why some of the things I was staying was important.




For me, these two books are game changers. I re-written my entire University of Houston, "Intro to Multimedia" course to target the novice brain better, and I'm working on incorporating more sticky ideas too.

Because I'm so excited by these books, I've had to share.

Thursday, November 3, 2011

Migrating from Flex 3 to Flex 4 - A bulleted list

I know that there are lots of migration guides, but I thought I post a bulleted list. The intent of this migration is NOT to move to spark components, but to keep as much the same as the flex 3 build. So for example if you have a flex 3 dashboard, that you now want to load in flex 4 content.

1) Fix name spaces:
Search: xmlns:mx="http://www.adobe.com/2006/mxml"
Replace xmlns:fx="http://ns.adobe.com/mxml/2009" xmlns:mx="library://ns.adobe.com/flex/mx"

2) fix MetaData
Search: mx:Metadata
Replace: fx:Metadata

3) fix Script

Search: mx:Script
Replace: fx:Script

4) fix Component

Search: mx:Component
Replace: fx:Component

5) fix Bindings

Search: mx:Binding
Replace: fx:Binding

6) Declarations wrapping
All non-visual elements need to be wrapped into the Declarations Tag.
Create a Flex Template, to make this process really easy.
Declarations_multiline
<fx:Declarations>
${line_selection}
</fx:Declarations>



Declarations_singleLine
<fx:Declarations>
${word_selection}
</fx:Declarations>

Then it is just a matter of selecting the non-visual elements, hitting cntl-space and choosing the correct Declarations template

7) Adding the halo skin back into the workspace

  • Copy the Halo theme into the workspace into a folder called "themes"
    c:\p.f\adobe\Flashbuilder\sdk\framework\theme\Halo.swf
  • Flex Build Path -> Source Path -> Add Folder -> ${DOCUMENTS}\themes
  • update the compiler settings to include:
     -theme=Halo/halo.swc
8) Migrate the states.
This takes the most work, because there is not much automation that you can do

  1. Select all of the states and duplicate using cntl-alt-down
  2. cntl-shift-c, to comment out the duplicated code
  3. delete all of the nested nodes (AddChild, SetStyle, etc)
  4. Create a 2nd Editor View (Window -> new Editor), and adjust them so you can see both
  5. Keep the commented states on one side, and the version you are editing on the other
  6. Systematically add the state properties
    1. On the adds / removes, be sure to include the "includeIn" property
    2. Use the Flex4 state syntax for the properties and styles
  7. Be careful with the basedOn property of the states, you will need to make sure that your includeIn and properties reflect that as well. 
*********** At this point we should be just down to warnings ***********

9) Remove warnings about the styleManager
Manually replace "StyleManager.getStyleDeclaration" with "FlexGlobals.topLevelApplication.styleManager.getStyleDeclaration"

You need to do this manually, as you will also need FlexGlobals imports. Also if you are within a visual element, you can just use styleManager instead of the static FlexGlobals property

10) Manually replace "Application.application" with "FlexGlobals.topLevelApplication"
You need to do this manually, as you will also need FlexGlobals imports.

11) You might still have some CSS warnings left, if so, you can select the Flex 3 compatibility mode within the Flex Compiler options



Some useful resources I found along the way: