Archive for September, 2008

Why anonymous functions are cool

A few months into learning about Actionscript, I started playing around with anonymous functions.  I found them to be a convenient way to do some basic event handling quickly and easily while reducing the complexity of the code.

For review, an anonymous function in Actionscript looks something like this:

foo.addEventListener(EVENT, function (event:Event):void { bar++ } );

When you use an anonymous function in this way you gain two major advantages that I can see

  1. You are handling your event in the context of the request.  The code for the handler is in the same place as the code for the request.  This helps you to understand how your request will be handled when debugging
  2. The context of your request is held in the closure for the anonymous function.  This is a big point.  A closure makes is so that the variables which are in scope for the enclosing context will be available to the anonymous method.  This means that when your anonymous function is called back you have access to the variables which probably caused the method to be called.  Very helpful since otherwise you might have to preserve that context on your own.  much better to have the language do it

As I became more familiar with anonymous methods I started to use them in different ways to help me write more compact code (although it doesn’t always help readability).  For example, I often will create factories that output functions (along with their respective closure) to help reduce the amount of code I write.  Again and example:

public class Function Factory
{
    public static functionGenerator(foo:String, bar:int):Function
    {
        return function(woot:String):String
        {
            return foo + bar + woot;
        }
    }
}

Okay, so clearly a trivial example. Why was this worth the effort?  It was worth the effort for two big reasons:

  1. Because this generated function is now wrapped in a closure with the values that were passed in by the caller, we’ve just created a function that – while it looks the same to a future caller – is imbued with metadata that we inserted at runtime.  This means that the caller of this method didn’t have to worry about holding onto that metadata
  2. While what we did is semantically equivalent to instantiating a class and returning a member function of that class, the effect is less code and fewer files to clutter up a clients understanding of the API.  For a client, as long as they understand how to call the method (one of the downsides.  i wish there was a good way to typedef a function in Actionscript) they don’t have to worry about anything else.

So, I hope that was a brief but useful look at why anonymous methods in Actionscript are cool and useful.  I will warn however, they can be dangerous if used too much.  The closure can consume memory, and if you are not careful when doing event handling you can end up with some nastly leaks on your hands.  So all in all, be careful, but go ahead and use anonymous methods.  They help you out a lot!

ps.  This is my first post with the Code Markup plugin.  So if this doesn’t work right away, i’m still learning :)

Obama Rally in Greensboro

[photoxhibit=2]

We just got back from an Obama rally in Greensboro.  It was a lot of fun.  The speeches from Obama and Biden were nothing extraordinary or groundbreaking, but it was just amazing how many people were there!  I think the most inspiring thing of the whole morning was just seeing how many people from so many different walks of life are getting excited about our country again.

I hope that for all of our sake this energy can be sustained and directed for positive change.  While Obama can inspire, it is the people at the rally who need to be the real agents of change.  I hope that we (those at the rally) can channel this passion not just toward one man, but towards the difficult problems of our times

Who, not just What

It never ceases to amaze me how easily teams can get distracted by what they are doing and never really stop to ask who is doing it and why.  This really should go without saying, but different individuals on every team have very different skills.  For simple things this is obvious: you generally don’t want to have programmer writing help documentation.

But there is another level to this axiom that I think goes unnoticed too often: What you do, must be informed by Who is doing it.  It is flat out wrong to decide what your team should be doing without taking into consideration who will be doing the work.

I have seen this play out countless times before.  Someone decides that we need to accomplish some goal.  Let’s say it is writing an app extension.  So we decide to write an app extension and then we turn around to our app team.  Oops! we don’t have any time on this team.  Okay, no problem we’ll just give it to this team over here.  Nevermind that this team has 0 experience with any of the tools or technology or process for writing an app extension.  We decided that this needs to be done, so lets get it done.

This just makes no sense.  What if that other team happens to be really good at building engineering tools?  Because an app extension was your first choice you’d rather have an extension that takes 2x as long to build and has 1/2 the quality over a great set of developer tools that boost the productivity of all the other teams in the organization?

Of course this is a contrived example, but I’m sure you can think of many situations like this.  When designing and prioritizing you should do at least one of these two things: Either you should know your team well enough that you can envision who will be doing the work before you decide to do it, or you should give your team members the freedom to push forward the ‘Whats’ that they are most passionate (and skilled) at solving.  If you miss these things, then you might be setting yourself up for some serious disappointment.

Flex. The Good and the Bad

Over the last two years, I’ve had the opportunity to build up relative expertise in Adobe’s Flex framework.  I’ve mostly been working on flex’s middle tier, tying the flex client to our JEE backend.  It’s been a pretty crazy journey and i’ve learned a lot along the way.  This post is a long overdue review of my impressions about the Good and the Bad with Flex.  I hope it is useful to someone making the choice to use this technology


The Good

  • Looks good with little effort.  Looks amazing with more effort.  Out of the box UI controls that look good and just work
  • Actionscript.  The flexibility of Javascript with a typesystem that works when you need it and gets out of your way when you don’t
  • Powerful, efficient remoting with BlazeDS



The Bad

  • Binding, especially initialization of it, generally only works well for the simplest cases.  As you create more abstraction and complexity in your models, I have generally found that binding becomes a royal pain
  • It is very easy to bloat your SWF with images, resources, and other misc things that create a subobtimal initial load time.  You can fix this problem, but, in the beginning it was too easy to do things the ‘wrong’ way
  • The designer in Flex Builder is bordering on completely useless.  I find that it really only works in the simplest cases.  As soon as you have a complex, dynamic UI, the designer is done.  Not that this is all bad of course.  I have a quite positive impression of Flex Builder as a whole.

Overall

On the whole, i must say that i have really enjoyed learning and working with flex.  The ultimate question of course is:  “Would i use it again?”  I’m not sure.  Like all things, it depends on the project.  My current project is attempting to do an entire application in one SWF.  I’m not sure i would do that again.  I would, however, like to take the approach of injecting some flex here and there in an otherwise ‘standard’ web app.  Using the JS bridge that comes with flex, I think you could build some very cool experiences that are both fast for the user but also rich in content.