Digital Primates» codeslinger

Talking Trash – An overview of Player GC

codeslinger — Tue, 11 Oct 2011 17:42:16 +0000

Okay, so, I have been a little behind schedule actually posting content. Here is my first attempt at reconcilliation. These are the slides from my garbage collection talk at flash and the city this year. They go into moderate depth about the internals of garbage collection on the Flash Player and AIR along with some speculation about where things may be going. The speculation is based off of commits happening on the tamarin project from our friends at Adobe.

Cheers, Labriola

Catching up

codeslinger — Thu, 23 Sep 2010 19:23:02 +0000

360|Flex is officially over and my slides are finally available. It was another great conference but I am officially wiped out. Three full days of content and wonderfully geeky discussion have left me looking forward to the weekend.

For any who asked for my slides, they are included below. Thanks so much for the great feedback and being a wonderful audience. I really enjoy doing these deep-dive style talks and so long as 360|Flex keeps inviting me back and all of you keep attending, I promise to try to keep them fresh and interesting.

Flex 4 components from the firehose

View more presentations from michael.labriola.

P.S. If you didn’t get a chance, check out my featured opening over at http://www.weheartdoug.org for Nate’s masterful prank.

Cheers,
Labriola

Wanted: Technical Writers with Free Time and an Altruistic Spirit

codeslinger — Thu, 08 Jul 2010 13:07:00 +0000

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

codeslinger — Mon, 07 Jun 2010 13:06:00 +0000

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. Parameterized testing in FlexUnit works by allowing you to specify arguments to be passed to a constructor (we call it JUnit style), or arguments which will be passed to a method (TestNG Style). Here is a quick sample of the approach:

Constructor (JUnit Style):

 [Parameters]
public static function data2():Array {
return [ [ 3, 6 ], [ 4, 8 ], [ 5, 10 ], [ 6, 12 ] ];
}

private var _input:int;
private var _expected:int;

public function TestParameterized( param1:int, param2:int ) {
_input = param1;
_expected = param2;
}

[Test]
public function doubleTest():void {
assertEquals(_expected, _input*2);
}

Method (TestNG Style):

 public static function dataThree():Array {
return [ [ 0, 1, 1 ], [ 1, 2, 3 ], [ 2, 4, 6 ] ];
}

[Test(dataProvider="dataThree")]
public function addTwoValuesTest( value1:int, value2:int, result:int ):void {
  assertEquals( value1 + value2, result );
}

Parameters are defined by static properties containing arrays of arrays. The framework iterates through the array, calling your methods with the parameters of each inner array. Parameterized testing can be combined with the asynchronous testing for very complex testing. At first glance, those of you familiar with theories might see a lot of similarities to parameterized testing; they also allow a developer to create methods and a constructor that accept parameters. A theory is different in how the data is defined and in the way a test fails. A theory is akin to a mathematical theory wherein any failure means the whole theory is bad. Further, theories are often reversible. For instance, a valid theory might entail testing a math class by first multiplying two numbers and then dividing the product by the first number. If your code is valid, you should get the second number back. Testing this across a potentially infinite number of values is the real of a theory. Whereas theories see all of the datapoints as input to a single test, which passes or fails as a whole, parameterized testing expands your set of parameters to individual tests allowing you to understand which cases fail and succeed individually. Parameterized tests are more useful in cases where you have a fixed data set with known specific values which represent a valid outcome.

External Data for Parameterized Testing and Theories

Executing tests across large data sets necessarily involves maintaining that data. FlexUnit 4.1 allows the data for Theories and Parameterized tests to be loaded from an external source.


public static var dataRetriever1:IExternalDependencyLoader = new ParamDataHelper( "PurelyFakeExample.xml" );
[Parameters(loader="dataRetriever1")]
public static var someData:Array;

The IExternalDependencyLoader interface works with the Theory and Parameterized test runners to facilitate asynchronous loading of data points before testing begins.

Rules Implementation

When creating large suites of unit tests, you could find yourself duplicating complex setup code many times. Rules offer the ability to factor this code into a separate class and specify logic that will be invoked before or after each test method call, allowing you to alter how a method is called, perform additional setup or even examine and change the result of a test runner.

 [Rule]
public var rule1:IMethodRule = new SomeRule();
[Test]
public function test1():void {
}

This feature can be used to create new types of test runners through composition instead of inheritance, allowing more flexibility, less code to maintain and the ability to reuse the rule across many types of runners. The first application of this technology was the auto-creation and verification of Mocks for test cases, however, the next application is a Rule to inject dependencies into cases.

Directory Scanning and Test Loading

Using the FlexUnit Ant tasks, you can point FlexUnit at a directory, which it will recursively scan for tests, build a temporary suite and execute on your behalf, removing the need to maintain static lists of tests in many cases.


 haltonfailure="false" verbose="true" localTrusted="true">

Performance Improvements

FlexUnit 4.1 now executes FlexUnit 4.x style metadata tests approximately 60% faster than before. New logic that directly monitors the progress of tests throughout the Flash Player frame allows the framework to better utilize the available time, resulting in an additional significant performance boost. Collectively these improvements can halve the execution time on very large suites over previous versions.

UIImpersonator for AS or Flex

Flex developers have had the ability to use the UIImpersonator classes to allow components to interact with the display list since version 4.0. Version 4.1 extends that coverage and allows ActionScript only projects the same access. A new property on FlexUnitCore allows developers to indicate the visual display root of the application, thereby allowing this access.

 var core:FlexUnitCore = new FlexUnitCore();
core.visualDisplayRoot = this;

Asynchronous Functionality now Available in Parameterized Testing and Theories

The ability to test asynchronously is imperative in Flash, where operations are often broken across frames. FlexUnit Asynchronous methods are now available in Theories and Parameterized Tests.

Package level assertions

You may have noticed that throughout these examples, we have simply said assertTrue() instead of Assert.assertTrue() Package level assertions now exist for all assertion methods, minimizing typing and porting from previous versions of FlexUnit or Fluint.

Timing information during test run

Timing information is gathered internal to the framework during test run, allowing for more accurate measurements of test execution time. Now, go download the latest bits from the flexunit.org download site and give us some feedback.

VectorCollection

codeslinger — Tue, 18 May 2010 09:05:00 +0000

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();

File Available Here Cheers, Mike

360| Flex and WorldWare Ahoy

codeslinger — Wed, 06 Jan 2010 09:01:00 +0000

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

codeslinger — Mon, 28 Dec 2009 15:12:00 +0000

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.

That means that, to perform optimally, I really should set all of the properties and make all of the changes I can to a component before it is on the display list. After I do, every property change that happens can have a much bigger impact. This all gets even worse once data binding figures into the mix. Now changes to public properties of my component may very well end up causing other components to redo this same work and lay out their interface again. It can all get bad, and quickly.

Okay, a bit more info. When you declare a bunch of components in MXML, the Flex precompiler actually creates an array of something called component descriptors. Component descriptors basically indicate the class you wanted to build (e.g. VBox), any properties or styles you want set on the VBox (e.g. width, backgroundColor) and then it holds an array of the descriptors for any children of the VBox. So, basically, your MXML becomes a big set of arrays of descriptors. The interesting words I said above are ‘properties and styles’. You see, Flex already injects properties and styles into new instance during the creation process. In fact, if you look at the code for Container, you will see that it creates a new instance of whatever class you need (e.g. VBox) and then loops through all of the properties and sets them on the component. This all happens, very wisely, before the component is added to the display list and before any bindings on the child are initialized and executed. All that means that the way the components are created by Flex allows you to inject properties at runtime but do it in a way that does not cause unnecessary refreshes of the display, resizing or other such malicious actions.

Wouldn’t it be nice if you could tap into that code? Well, you can of course, because this is Flex and with enough desire you can basically do anything. That doesn’t mean, of course, that our good friends at Adobe couldn’t make this a whole lot easier if methods that can be overridden weren’t touching properties that can’t be… but that is another issue for another time.

In this example I am just overriding the methods of a VBox, but you could choose to extend every container, monkey path Flex, or even recompile the framework should you want this functionality to be part of ever container. Oh, before I even begin, let me just clarify this. I am not showing you a dependency injection framework or even a complete solution; I am showing you a concept. It does work as I have used this inside of my own framework code for the last several years, but the concept is the important part so that’s what I wanted to share.

Okay, first things first, Container has a method named createComponentForDescriptor. This gets called for every single child of the Container when it is time to build that component. So, we are going to override this method. Why? Well, several reasons. We are going to make a hook to modify the component descriptor before it gets created. Perhaps we will also add something in here which decides if the component should even be created at all.


override public function createComponentFromDescriptor(
	descriptor:ComponentDescriptor,
	recurse:Boolean):IFlexDisplayObject {

	var uiCompDesc:UIComponentDescriptor = descriptor as UIComponentDescriptor;

	var permission:String = securityManager.getPermissionsForDescriptor( uiCompDesc );
	
	if ( permission == SecurityManager.NOT_ALLOWED ) {
		return null;
	}
	
	var newDescriptor:UIComponentDescriptor = securityManager.modifyDescriptor( uiCompDesc, permission ); 
	newDescriptor = diManager.modifyDescriptor(newDescriptor ); 
	
	return super.createComponentFromDescriptor( newDescriptor, recurse );			
}

Alright, what in the world is going on in this code. Let me explain a bit. When this method is called, it is passed a descriptor that it needs to build. So, first thing we are doing is calling some fictitious security manager which is going to let us know if we can build the thing at all. How does it figure that out? That’s not up to me. Point is that you have a hook where you can ask some other object if you are allowed to build this new component. If you don’t understand why you would want to do that, no worries, it just means you aren’t writing apps that need that granular control, however, trust me, there are plenty of apps which need this. If you aren’t allowed to build it, you simply return a null. Flex happily goes onto the next component never looking back. In this way, entire branches of components can be created or not.

Next thing that happens is that we pass this component descriptor to a method on our fictitious security manager and ask it to modify the descriptor as needed. What does this mean? Again, it’s a hook for your use. Imagine a scenario where you are asked to render a textinput. If the user has permission, you do so. If they don’t have permission to edit it, you (at runtime) decide to create a Label instead. This is all done without changing your MXML code.

Last thing we do is pass this modified descriptor to our fictitious dependency injection manager. This manager can use things like introspection, lookup or whatever else you might imagine to further modify this descriptor adding new values, removing old ones or doing something I haven’t imagined to the descriptor.

At the end of the method, we simply call our super class and pass along the modified descriptor. This causes Flex to go and execute the code which creates the class, injects the properties and adds it to the display list. So, we get the benefit of runtime modification of the components without the performance overhead of doing it once they are on the display list. If you care about such things, this is pretty cool. If you don’t, I won’t hold it against you.

Now you can do many more things to make this cleaner. Perhaps hide the container if no children are created so it is cleaner on the screen. Perhaps there are other managers or objects which should get a turn messing with the descriptor. Point is that this is a different way of looking at injecting properties by using the code that already existing in the framework to do this, rather than existing completely on the outside. Before anyone chimes in, yes, this is a Flex only solution.. and, as I already mentioned, it isn’t a solution, but an idea I wanted to share.

Final thing, with just the tiniest modifications to the Flex framework, Adobe could provide us the ability to specify things like that DI manager at runtime. Then this could be done generically enough that we wouldn’t be recompiling, monkey patching or maintaining a dozen overridden containers. Food for thought.

Labriola

$10 to advance your career

codeslinger — Fri, 23 Oct 2009 05:10:00 +0000

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

codeslinger — Sun, 13 Sep 2009 15:09:00 +0000

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

codeslinger — Wed, 02 Sep 2009 19:09:00 +0000

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