Code Slinger

Wanted: Technical Writers with Free Time and an Altruistic Spirit

Thu, 08 Jul 2010 18:19:00 -0400

As many of you know, I am the project lead for FlexUnit 4.x. The technical side of the project is in great shape with new features, releases and tests forthcoming, however, the place we are really lagging is good documentation.

Right now the FlexUnit team is quite small and 120% of our time is occupied with development and user support. Unfortunately this means that the best engineered plans for good documentation seem to get farther behind as the days go on.

We are looking for a few people who would be willing to own large chunks of the documentation. We would arrange conference calls as needed with the developers of key sections to talk through approach, technical details and future plans. The goal would be to ensure you have a full understanding and access to anyone you need when writing. Ultimately, it would also give you a few things.

First, you would have unlimited access to learn FlexUnit at a very, very deep level. Second, you could help create a volume of work (I am hoping we can produce both wiki content and eventually a comprehensive PDF book) which will continue to be attributed to you. Third, that attribution plus future recommendations from myself and others on the team and in this industry are guaranteed (and very helpful for future interviews).

Anyone who is seriously interested should leave a comment on this post and I will reach out to you immediately.

If you want to take a look at our current efforts, head over to docs.flexunit.org

Thanks,
Labriola

FlexUnit 4.1 Beta 1 Now Available

Mon, 07 Jun 2010 18:31:00 -0400

For months now the core FlexUnit team and contributors have been working diligently to move the next release of FlexUnit forward. The 4.0 release was a success but we always knew there were many optimization and enhancement still to come. Today, we are happy to announce some of those are available as the 4.1 public beta begins. You can download the latest bits from the flexunit.org download site. Here are a few feature descriptions and bullet points of some of the new features in the FlexUnit 4.1 world.

Parameterized Testing

There are times when you need to repeat a test across a series of data points. Imagine a class that does a complex calculation based on input values. It is likely that you would want to test hundreds or thousands of different input values, checking each of their expected outputs to feel comfortable that this class was behaving properly. Or, perhaps you have a whole series of components which implement an interface and you wish to verify that setting the 'x' property on each of those objects dispatches and expected event or updates a given property. These are both cases where Parameterized testing can simplify your life. [More]

VectorCollection

Tue, 18 May 2010 14:14:00 -0400

First, let me say I am sorry. A year or so ago, I wrote these VectorCollection classes. They are not spectacular works of art, they are very basic implementations required to use Vector inside of Flex components which are looking for IList and ICollectionView for their dataProviders.

Vector has some performance advantages in some cases (for more details, take a look here. ) but overall, the big advantage to me is type safety. I know what should be in the Vector and flash knows if I mess that up.

On the whole, these are simple implementations that don't solve every problem I would love to solve if I had the Flash Player source and some time, but they will allow you to use Vectors more directly in Flex. So, if you find them useful, then enjoy.


private var source:Vector.;
source = new Vector.;

private var vc:VectorListCollection;
vc = new VectorListCollection( source );			

var sort:Sort = new Sort();
var field:SortField = new SortField( null, false, false, true );
sort.fields = [field];
vc.sort = sort;
vc.refresh();

Files available from Download link below post.

Cheers,
Mike

360| Flex and WorldWare Ahoy

Wed, 06 Jan 2010 14:42:00 -0400

March is shaping up to be a busy month for speaking, and I am pretty happy about it. I have the opportunity to deliver two distinct talks on topics where I feel, let's just say, a lot of passion.

First up in the 360|Flex Conference in San Jose on March 7th-10th. Here I am delivering a talk about the Flex Framework and its relationship to the component development in the Flex 4 methodology. There will actually be quite a few Flex 4 talks (and even component talks) available at 360|Flex this year; however, I think this will come across differently. I intend on tearing apart the framework again along the lines of my Dense and Hot presentation a few years back. The intent of this presentation is less about what and more about why. I want you to know things like the order that nested components have their commitProperties called versus their measure when you leave. More importantly though, I want you to walk away knowing that it's because of priority queues and nest-levels. I want you to feel comfortable explaining it to that poor guy back at the office that couldn't make it to San Jose for the conference. That guys deserves some love to. You want to help him, right? I digress.

In either case, I hope you can make it out to 360|Flex. It is always a good event. It is chocked full of great content and I don't know that there is a better value in the Flex conference space. If you want to be extra-nice to me, you can register with this link. Apparently if enough people register that way, John Wilker is going to carry me from place to place in some type of litter. All said though, try to make it if you can. Even if I wasn't speaking, I would still be there learning from a great community willing to spread a lot of knowledge.

Right on the heels of 360 is the WorldWare conference in Santa Clara on March 16th-18th. WorldWare is a conference dedicated to those developing applications for an international market. I will be doing a pre-conference workshop on the benefits of using the Flex Framework, with all of its UI swapping, layout object goodness, to the benefit of those wishing to write an i18n application in a reasonable amount of time and with a reasonable expectation of maintaining it (without sleeping at the office for the rest of their lives). This year's theme at WorldWare is the ROI of Software Internationalization and I am honored to even be considered near the profound list of speakers. If your application or company is targeting the international world this is the place to be in March.

Hope to see you at one (or both )of these events,
Cheers,
Labriola

Food for thought, using the Flex framework for dependency injection

Mon, 28 Dec 2009 20:47:00 -0400

Dependency injection with Flex UI components can be tricky business. Not just doing it, there are a lot of strategies for that, but to do it without causing performance degradation and unnecessary work on the part of the framework and ultimately flash player. To understand why, we need to discuss a bit about the whole component life cycle.

When a component is first instantiated, its constructor is executed and any local variables that might have been declared with initial values are set, etc., but the most important stuff... the stuff that makes a component a Flex component hasn't happened yet and it won't anytime soon. Properly written Flex components do the balance of their work after they are added to the display list. Back when I first started yapping about this stuff most of these life cycle methods weren't well known, but today there are a lot of great resources on them, so I am just going to stick to the basics.

The methods I care about are createChildren, measure, commitProperties and updateDisplayList. Each of these methods is called by the Flex framework after the component is on the display list. With the exception of createChildren, you can almost think of these methods as being scheduled. They get called by the framework, at an appropriate time for optimal Flash player performance, if the component itself or some outside force deems it necessary.

To take advantage of this scheduling and to ensure you don't have timing issues, a properly architected Flex component waits to create any static visual children until the createChildren method is called. It waits to make visual changes to the component until the updateDisplayList method. When a property is changed on the component that could affect one of the components children, i.e. the textinput inside of a datefield, the component saves off this change and applies it when commitProperties is called. Finally, the component aggregates information about its size and reports it (but never, ever changes it) during the measure method.

The reason I mention all of these things is that there is a fair amount of work that starts happening the moment the component is added to the display list. From that point on, all of these methods are called and changes to the component, especially those involving the amount of space it takes on the screen, can cause major amounts of rework. (If I change the size of a button in the middle of the page, I may need to size and layout the whole page again). You would never know this from the Adobe docs, but the creationComplete event is likely the worst place you can do many things and that is for this same reason. Everything is sized, positioned and ready to do... then you cause it all to change again.

[More]

$10 to advance your career

Fri, 23 Oct 2009 10:34:00 -0400

If you are in the midwest this weekend, you should really, really consider dropping by BFusion & BFlex in Bloomington, Indiana. It is a bring your own laptop event full of hands-on tracks conducted by speakers from around the globe combined with optional full-day training sessions. The schedule is packed so full of content on Flex and ColdFusion topics that your only regret will be the inability to attend twice.

Here is a smathering of sessions from the Flex track (and remember, there is also a full day of fusion content too )

Hooking up Flex and ColdFusion. An introduction to CFAAS
Integrating BlazeDS and ColdFusion
New Flash Builder 4 WSDL and HTTP Connectors
Drag and Drop Image Manager with Flex & AIR
Practical Cairngorm for Adobe Flex Applications
Creating Your First HTML-Based Application for Adobe AIR with Dreamweaver CS4
Building Flex Apps with Swiz: Simple, fast, flexible, powerful.
Spark Components for Flex 4
Component Development using the Flex 4 Model
Using Merapi to tap into native code in your Flex application
Flex Component Development from Scratch
90 Minutes + Flixel = 1 Game
Creating Applications for the Flash Platform
Flex Intro for Developers
Introduction to Flash Catalyst

I am not sure how the folks at BFlex manage to provide this for a $10 price tag, but if you are close enough to even consider going to this event, it would be a mistake to miss it.

Hope to see you there,
Labriola

FlexUnit in Flash Builder Bugs plus TDD

Sun, 13 Sep 2009 20:31:00 -0400

I just finished my presentation materials for my Test-driven development session at Adobe Max, and I am pretty excited how it turned out. It is a 90-minute BYOL (Bring your own laptop) lab, which is always challenging. Each person showing up with a diverse setup and (hopefully) our files installed.

So, if you are planning to head to Max, and you are interested in TDD, try to attend. I think it will be well worth the effort.

That said, there will also be two sessions at the 360|Flex Max unconference where we will be reviewing the FlexUnit 4 framework from the inside out. The goal here is to provide initial context for those interested in becoming committers on the project. FlexUnit 4 is a highly functional testing framework, but it is also complex. Until we have the chance to document every corner, this might be your best chance to learn the ins and outs of it.

Finally, working on this session has given me the opportunity to work with the FlexUnit plugin in Flash Builder. I must say I am very pleased with how this is evolving. Nonetheless, there are a few enhancements I would still like. If you are of a like mind, read through the bugs and cast your vote.

Auto Refresh of the flex unit compiler application when deleting a test case or (minimally) re-running the wizard
Right now deleting a test case causes a manualy compilation error that needs resolution. I think this could be more elegant.
Uncheck Create Constructor by default in FU4 test case
Just a minor inconvenience. You generally don't need constructors in FU4 test cases, so you uncheck a checkbox... often
Generate Before/After in place of setup/teardown for FU4 testcases
Right now the wizards don't know how to generate the FU4 equivalent of setUp() and tearDown(). Not a big deal, but I think it's low-hanging fruit.
Remember Last Selected Type when creating test cases from the wizard
Just a minor inconvenience. You always need to re-select the radio button when using the wizard with FU4.

If you agree, vote away.

Hope to see you at Max,
Mike

FlexUnit 4 and Flex 4 presentations galore

Thu, 03 Sep 2009 00:56:00 -0400

So after a very welcomed summer lull in travel, I am gearing up for the fall speaking season. A good portion of my time this fall will be spent discussing, encouraging the use of, and getting Feedback on the FlexUnit 4 project. The rest will be spent teaching about the early architecture and internals of the future Flex 4 product.

If you have tried either of these and want to discuss, or if you haven't had the time and want to learn more first, please come and support one of the following great events where I will be presenting.

September 5th, Rimini, Italy at Flash Camp on the Beach

Testing with Flex and Flash Builder October 5th - 7th, Los Angeles, CA at Adobe Max, Los Angeles, CA

360|Max unconference

October 15th and 16th in Omaha, NE at the Heartland Developers Conference

October 17th and 18th in Raleigh, North Carolina at CFinNC

Next Generation Testing

I hope you have the opportunity to participate and engage with the Flex community at some of these community events.

Cheers,
Mike

FlexUnit 4 Beta 2 is finally here (and it likes your CI Server)

Mon, 24 Aug 2009 17:02:00 -0400

Alright, it has been an insane few months but we are ready. FlexUnit 4 Beta 2 is now available on the adobe open source site. You can download the turnkey project to play with built libraries quickly or follow the directions on the Source page to grab the source yourself.

There are a huge number of fixes and enhancements in this version, all of which you can find for yourself on the release notes page but the largest change of note is the availability of CI tasks and a CI listener to allow easy hooks into the continuous integration system of your choice. A lot of hard work went into building and vetting these out on different platforms but I wanted to call out a few names in particular.

First, thanks to Peter Martin, because all of this was based on his original work for the FlexUnit .9 tasks. Second, thanks to Joe Adkins, Conrad Winchester, Brian LeGros, Xavi Beumala and Simeon Bateman all of who contributed to development, testing and/or generally being good spirits despite inevitable development slow-downs and hiccups. This is beta code, so there are a couple of caveats and to-do items still on the list, so please be sure to check out the README file in the sample project, or read it on the wiki.

So, take a few minutes, grab the bits and play around. If you have any questions or comments, in particular around the new CI tasks, head over to the FlexUnit forums. If you believe we mutually disagree on the definition of a functional feature, then please log it into the bug database.

This is a completely community run project and your help and support are always welcome.

Cheers,
Labriola

FlexUnit 4 and Flash Builder 4

Wed, 03 Jun 2009 21:49:00 -0400

So, suppose you are the kind of person who has downloaded the FlexUnit 4 turnkey beta from opensource.adobe.com. Suppose you are also the type of person who downloaded the new Flash Builder 4 beta from labs.adobe.com. Well then perhaps you are thinking to yourself, "Self, I would really like to see the results from my FlexUnit 4 tests right inside of the FlexUnit Result view in Flash Builder. I wonder how I would do that."

Well, I would personally suggest you add the following import to your FlexUnit4Turnkey.mxml file:


import org.flexunit.runner.notification.async.XMLListener;

And then add the following line before your call to the run method of the FlexUnit 4 core.


core.addListener( new XMLListener( "FlexUnit4Turnkey" ) );

Ideally, it will look something like this:


core = new FlexUnitCore();
core.addListener( new XMLListener( "FlexUnit4Turnkey" ) );
core.run( FlexUnit4Suite, HamcrestSuite, FlexUnitIn360  );

Where the string "FlexUnit4Turnkey" represents the name of the project where this MXML file resides. If you open the FlexUnit Results view in Flash Builder and execute this MXML file, you will see the results in Flash Builder.

Unfortunately, you need to be aware of some of limitations. First, Flash Builder doesn't know how to generate these tests yet and will currently fail if you click any of the buttons such as Run All Completed Tests, Run All Failed Tests, etc. We can just give it back information about the success and failure, Flash Builder doesn't yet know how to choose, run or specify FlexUnit 4 tests. Also, and perhaps more severely, Flash Builder considers any Ignored tests a pseudo-failure. Truthfully, it just doesn't understand what we mean, so, in some cases, it looks like a failure, but in others it doesn't.

Right now, FlexUnit 4 beta still also outputs to the console, which means Flash Builder will try to keep switching you over to the console view, but this will be a little cleaner in our (FlexUnit's) next beta drop. In either case, it is perhaps a bit of a novelty for the moment, but it demonstrates the power of the listener model that FlexUnit 4 uses. Wait till you see the stuff coming for Continuous Integration :)

Cheers and have fun,
Labriola

Any Which Array but Loose.. the code

Wed, 20 May 2009 21:45:00 -0400

For those that attended my 360|Flex session on Array/DataStructure performance, here is an updated version of the code I was using to demo. A few things:

The timing method I am using only has millisecond resolution. So, the difference between 0 and 1 millisecond could change in subsequent calls. I would pay more attention to the difference between 1 and 100, which is what we really care about.
Right not the default number of items being created in each structure is set to 5000. You can change this and the insert/delete numbers by changing the constants in the main MXML file
Playing with the aforementioned numbers will really help you get a sense of how these things work. For instance, it is really interesting to see the difference between sorting the ArrayCollection up front or later as the array size grows.
There are (n) more variations of each of these.. using push() instead of direct addressing. Telling the vectors to be fixed size instead of dynamic. I kept this open enough that you should be able to add those cases and explore as you see fit, but I didn't cover every permutation in this code
I added some filters on the main page so that you can easily lose/add tests or datapoints to get a better view of the data
I didn't include the LinkedListCollection code in this package. I will get that out soon, but I want to clean it up and comment it. It is confusing to me right now and I wrote it

Okay, so, that's it. Have fun and play. In the end, this is all about finding the best tool for any particular job.

Cheers,
Labriola

FlexUnit 4 in 360 seconds

Sun, 03 May 2009 22:57:00 -0400

About a year back I remember reading a blog post called JUnit in 60 seconds. At the time I pondered how great it would be to have these features in Flex. Little did I know that today I would be writing this post introducing the Flex world to FlexUnit 4.

So, first a little background. FlexUnit 4 is the name for an upcoming release of FlexUnit. It represents the best features of the FlexUnit project combined with the best features of the Fluint project. It is built on top of a newly created foundation designed to support the latest techniques used in the JUnit testing community, but written for the specific requirements and needs of the Flash Player. Top all that off with an extensibility layer that encourages developers to create new types of test runners and extensions while simplify the process of integrating the results into IDEs and continuous integration environments, and it should give you an idea why I am excited about this release.

If it sounds interesting to you as well, the public alpha of this upcoming release is now available as a turnkey test project you can download from the adobe open source site. I hope you will use it to learn and explore the new features, and to provide feedback about any bugs you find along the way. However, it is an alpha, so locations and names of classes, signatures of methods and even which features are supported are all subject to change before release. It is not be advisable to use this as your production testing system.

Speaking of features, let's jump in. There is a bit more content to go through than the original 60 second tutorial, so, I think you will need 4-6 minutes to get through it all. To keep things consistent, many of these examples are adapted right from the JUnit in 60 seconds site referenced above.

[More]

A few introspection classes to keep things going

Thu, 23 Apr 2009 21:03:00 -0400

Okay, it has been way to long since I have had the opportunity to post anything of value. So, here are a few classes I wrote called Constructor, Field, Method and Klass. They also use one additional class named MetaData tools. These classes roughly mirror the java.lang.reflect classes. They aren't quite as thorough, but there is some good stuff in here.

In the next few weeks these will be released as part of a larger project, but I thought I would take the opportunity to throw these early versions online as I have found them extremely useful over the last month. In addition to the 'normal' stuff you would expect in introspection, these also take care of a few gotchas that you might run into if you are used to Java and now play in the AS sandbox.

First, the default describeType method of the flash.utils package doesn't actually know how to get constructor parameters from the metadata until the class has been constructed, in some capacity, once. This is really frustrating but can be handled by doing a behind the scenes instantiation and capture. Not gorgeous, but it works and gets me the parameters I wanted.

Second, DescribeTypeCache has a few issues regarding when a description is cached. If you cache it for the first time before the first instance is built, you will forever get that version back. This means that the cached record may look different dependent upon the order you called it... so not cool.

Third, pre-flash player 10, you can't specify that an array will contain a given type of data. Flex has a metadata tag called ArrayElementType, which MXML will respect (in some cases) but overall it is mostly useless. This library will actually look at that ArrayElementType at runtime and at least tell you what data you expected to go into the array. This is actually quite useful in a number of situations ( however, you need to ensure you instruct your project to keep the ArrayElementType metadata.

Fourth, you can fake out having a constructor.apply() at least for a limited set of arguments.

Fifth, actually, I'm not sure what's fifth, so just grab these classes and give them a whirl if you are interested. I promise they will be documented and have some asdocs by the time they are released, but these are a start.

Also, in the next month I will be presenting at both 360|Flex Indianapolis and webDU (within a few days of each other). These are two of my favorite conferences. They both have a unique message and a great crew behind them. I hope to post more about these soon, but if you can make either of these conferences, I would love to sit down and explain the bigger picture of where these classes come from, and, hopefully, get you playing with some very interesting new code.

Cheers,
Labriola

Fluint 1.1.0 Released

Mon, 16 Feb 2009 11:53:00 -0400

At the end of last week Fluint 1.1.0 was released. For those of you that don't know, Fluint is a unit and integration testing framework that was originally developed as an internal tool here at digital primates. We decided to open it up to the world as we thought there was some benefit. Turns out that others thought so too.

The greatest thing about this new release is that almost all of the code was written and submitted by community members using the product. Here at DP we have been making some changes internally that we intend to offer back to the project (if the community wants to incorporate them) but in the meantime, the new build offers:

Better differentiation of errors and failures
Compliant XML output that can be used with JUnitReport and Surefire
A method of running Fluint on a headless CI server
Improved ant tasks
Improved separation of the test runner and tests with modules
Bug fixes and a menagerie of other features

At the end of the day, I am just proud to be a part of the project and want to offer a thank you to those who helped on the forums, submitted code or even just complained to bring things to our attention. So, thank you.

Soon we will begin active dialog on the next round of features, so if you are interested, please join the discussion.

Cheers,
Labriola

A rose by any other prefix won't smell as sweet

Wed, 11 Feb 2009 16:54:00 -0400

Okay, I haven't blogged about anything of value in a while, yet I am still here to ask a favor. Right now Adobe has a big decision to make. They need to decide whether or not to prefix all of their classes for the Flex 4 release. Simply put, developers in Flex today are used to writing a line of code that looks like this:

<mx:Button/>

The mx namespace is mapped somewhere in your MXML document to a URI. That URI indicates you mean the Flex 2 or 3 component set, affectionately called Halo. Flex 4 is going to introduce a new set of components with a different organization, but Adobe is struggling with how to allow their interoperability. Right now, the proposal is to prefix the name of each of these classes with an Fx, meaning that from now on there would be

<Button/> which means the old Halo component and
<FxButton/> which means the new Flex 4 component

Now, the idea of two separate button classes is a given, it is the only way that progress can be made developing a new flex framework while maintaining any compatibility, but it is the Fx prefix that seems problematic. What happens when we go to the next version of Flex, will it be

<NewFXButton/> or <NewerFXButton/>

Overtime, people will use fewer and fewer Flex 3 components as Flex 4 evolves, but we will forever be caught with this naming convention. The alternative, and, imo, preferable way is to continue to use namespaces as we do today. So:

<mx:Button/> would mean the old Halo component and
<fx:Button/> would mean the new Flex 4 component

Effectively, you are simply indicating a Button and the namespace indicates which one you would like. To me, this makes a bit more sense as we are already familiar with this concept today. If you make a custom component or a custom library, you are likely already mapping a namespace to get your specific version. If you are not intermingling the two types of components (which will eventually be possible) you could simply map the namespace differently and type <Button/> again.

While there are some CSS complications that need to be addressed in either case, the primary reason for this prefix discussion seems to be Adobe's belief that new users won't be able to grasp the concept of mx:Button versus fx:Button. Now there are plenty of challenges a new developer faces while learning Flex, not the least of which are likely caused by the belief by some that Flex is supposed to be trivial to learn, but in my years of training and mentoring, I have never had a pupil so confused by namespaces that a minute long explanation didn't suffice.

I am just against making every developer from this point on always have to retype a prefix. I am against deviating from what seems like a sane plan of continuing to use namespaces as we do today, and I am generally worried that the decision is being made for the wrong reasons.

So, if you have an opinion, let someone know. Please don't just take my opinion but read about this thread on the Adobe SDK Forum and form your own. If you feel that the Fx prefix to all components is a bad idea once you understand all the viewpoints, then consider voting for this bug on Jira, which is to eliminate the prefix (and to use namespaces as we do now).

Flex is a great product that may become a great open source product. Let's all take that seriously and take some ownership of the issues, bugs and direction.

Happy reading,
Labriola