GradleFx: Multiple Configurations

There has been some discussion lately about how we might be able to allow for custom configurations in GradleFx. Such a custom configuration would allow a user to:

  • generate different outputs from a single code base
  • use specific dependencies for each of these outputs
  • hook up any other custom task to a particular configuration

As these discussions illustrate it is not currently possible to do so. And though we are looking into some possible solutions, they may not be implemented soon. So here I am to save the day and provide you with a viable workaround, until we get the matter sorted out.

Use case

This solution is heavily based on mrhaki’s excellent article, but it is tailored specifically for the Flex developer that needs to generate multiple outputs for different environments from a single project. I created this when facing a real-world issue and the solution is being used in production right now, so it’s been tried and tested.

The specific situation I was facing was that I needed mock services and embedded mock data, in such a way that the application could run in standalone mode (i.e. without a server) and give a realistic feel to the users testing the UI. Of course in the production build I did not want to include all the additional classes and certainly not the embedded data. So here’s how I created a “clean” production output and a heavyweight development output including the mocks.

A groovy configuration

Let’s start by stubbing out our config file for two different environments.

config.groovy
1
2
3
4
5
6
7
8
9
10
11
environments {
    dev {
        //development specific stuff goes here
    }

    production {
        //production specific stuff goes here
    }

    //all that is shared by both configurations simply stays in the build.gradle file
}

Good, that’s how mrhaki described it. Now lets add some properties that we can use in a GradleFx build. Note that I put all the mock-related code and the resources (the data files) in a separate source tree (src/mock/), which allows me to easily add/remove that part when needed.

config.groovy
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
environments {
    dev {
        //I added the resources folder to the 'srcDirs' because the files had to be embedded
        srcDirs = ['src/mock/actionscript', 'src/mock/resources']

        //fx-mocks is a library that helps with simulating data from services
        //fx-users-dev is a special build of the fx-users lib that also includes mock services and data
        dependencies.merged = [
            'net.riastar.lib:fx-mocks:1.0-SNAPSHOT',
            'net.riastar.lib:fx-users-dev:1.0-SNAPSHOT'
        ]

        //it's gonna run in standalone mode so we set a bigger default window size
        //mock services are injected, so they're never referenced explicitly;
        //that's why we have to add them through the 'includes' option
        additionalCompilerOptions = [
            "-default-size=1024,600",
            "-includes=" +
                "net.riastar.myapp.service.impl.UserMockService," +
                "net.riastar.myapp.service.impl.MyValueObjectMockService"
        ]
    }

    production {
        //in production we don't use the mock classes and resources,
        //we don't use the mock library and we use the production build of the fx-users library.
        srcDirs = []
        dependencies.merged = ['com.trasysgroup.lib:fx-users:1.0-SNAPSHOT']
        additionalCompilerOptions = []
    }
}

Note that in production I mirrored every property that I declared in the dev block, if only to set its value to an empty array. This is not strictly nesessary, but it will make the code in the build file a lot more readable later on.

Use it in a build script

So we’ve configured our two environments. Next I will show you how to modify the Gradle(Fx) build script to leverage it. As in mrhaki’s post, this script reads the custom env property from the issued command and processes the config file accordingly. Hence you’ll be able to initiate the build of a specific build like so:

1
$ gradle clean build -Penv=production
build.gradle
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
buildscript {
    repositories.mavenCentral()
    dependencies.classpath 'org.gradlefx:gradlefx:0.6.4'
}

apply plugin: 'gradlefx'
type = 'swf'

//'development' build by default if the 'env' argument wasn't set
//I'm not gonna explain this code: read mrhaki's post
def environment = hasProperty('env') ? env : 'development'
ext.config = new ConfigSlurper(environment).parse(file('config.groovy').toURL())

//add our custom srcDirs to the default ones
srcDirs += config.srcDirs

dependencies {
    //add our custom libraries; swiftsuspenders will be used both in production and development
    merged 'org.swiftsuspenders:swiftsuspenders:2.0.0-rc1',
           config.dependencies.merged

    flexSDK 'org.apache:apache-flex-sdk:4.9.1'
}

//add our custom compiler options
additionalCompilerOptions = config.additionalCompilerOptions

See why we declared empty arrays in the production block? It would’ve required some conditional logic if we hadn’t, leaving the result much less elegant and readable. Especially the merged dependency would’ve been butt-ugly; believe me, I tried.

Conclusion

Well that’s about it. It’s not extremely complicated and it’s fairly elegant. I know it’s not exactly the Gradle way, but it gets the job done without too many compromises. Hope this helps someone.

Moving to Octopress and Pagodabox

It was bound to happen at some point: I got hacked. Don’t know when, don’t know why. I only know that someone broke into my server, replaced the index page with a nice picture of the Koran and some Engrish proze praising the love of God. My islamist visitor was kind enough to leave the rest of my content untouched - for all I know, that is.

Now how could this happen?

Well, since I can find the time to write on this blog - say - once a year, how often do you think I applied security updates to my WordPress blog?

Right!

So, because a Wordpress engine was overkill for my requirements anyway, not to mention slooooooow, I went CMS hunting and found the perfect solution with OctoPress. This is a perfectly geeky CMS that generates static html pages. You write your posts in MarkDown - oh yeah, pure text, no WYSIWYG involved; then you execute the generate command on the command line; your site is generated and ready to deploy.

Its main advantages over my previous situation:

  • I love the geekyness of the whole concept
  • It’s blazing fast: no database queries, no script processing, no nothing
  • It’s way more secure: try injecting this, m*th*f*ck*r
  • It generates perfect semantic markup
  • So far it’s been fairly easy to customize

Main downside at this point:

  • I had a pretty hard time getting it to run on my Windows box: it’s written in Ruby which doesn’t like Windows very much. And I had no luck at all installing it under Cygwin, so for the time being I’m stuck in a DOS shell to issue my commands.

New server

By chance I came across PagodaBox just about the same day. It is to Php what Heroku is to Ruby: a scalable hosting service in the cloud. Fortunately they had a free offering that - though limited - allowed me to play around. And I really love it, mostly for its Git deployment interface.

The result is that I ended up with a workflow to write a new post and deploy it to my PagodaBox instance, that goes like this:

1
2
3
4
5
$ vim 2013-03-11-my-new-post.md
$ rake generate
$ git add .
$ git commit -m 'created new blog post'
$ git push

Just lovely!

GradleFx Committer

Today I’ve taken my first steps in the open-source world: I became a committer to the GradleFx project.

What project say you?

GradleFx is an automated build tool for building Flex and ActionScript applications. It’s a plugin for Gradle, which is an alternative to the ubiquitous Maven. Actually calling it an alternative would not be doing it justice: it’s Maven, Ivy and ANT mixed up and put on steroids.

Until GradleFx came to the scene, us poor Flex developers only had FlexMojos (a Maven plugin with the same goal) at their disposal. And truth be said: it has some very annoying bugs. So when I discovered GradleFx I was delighted.

When I first gave GradleFx a try, I got a few builds up and running in no time. Unfortunately, I soon found out that GradleFx - being a fairly young project - was missing a few pieces. But since Gradle was designed to be an easily extensible framework, I worked my way around those shortcomings with some custom tasks.

First steps

I soon discovered that GradleFx’ codebase was fairly transparent (as opposed to FlexMojos’). So I forked the project on GitHub and I started adding some minor features. Yennick, one of the founders and currently the only active committer, seemed to like my ideas. He merged them into the codebase rather quickly, encouraged me to keep on contributing and before I knew what happened, I became part of the ‘team’.

Contributions

So far I’ve added only a few minor improvements:

  • a theme dependency scope: well, it was missing
  • localization conventions: use localized .properties files with zero configuration
  • the frameworkLinkage convention: a possibility to determine how the Flex framework is linked into the application

Coming up:

  • a flashbuilder plugin that generates a FlashBuilder project with all the dependencies on its build path

RIA Utilities: Copying Instance Properties

I’ve lost count on how many times I’ve needed this in RIA development with Flex or ActionScript: the possibility to quickly copy property values from one class instance to another. The two most important uses I can think of right now are these:

  • You send a value object (VO) to the server. It comes back with a bunch of additional data. So far so good. But what you get back is another instance than the one you’ve just sent up the wire. Since the original instance may already be referenced somewhere in the application we do not want to simply replace it. We want the original instance filled with the new property values.
  • You show the user a form with which he can edit a VO. After he’s changed some values he can either commit his changes (‘OK’ button) or discard them (‘cancel’ button). In this scenario you’ll usually keep a copy of the original VO somewhere handy because you want to be able to restore it when needed. Now the story is the same as the previous one: we want to restore the values of the original instance, not replace it entirely.

So I finally made this convenience method that uses describeType() for introspection as an addition to my ObjectUtil class:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
public static function copyProperties(source:Object, target:Object):void {
    if (!source || !target) return;

    //copy properties declared in Class definition
    var sourceInfo:XML = describeType(source);
    var propertyLists:Array = [sourceInfo.variable, sourceInfo.accessor];

    for each (var propertyList:XMLList in propertyLists) {
        for each (var property:XML in propertyList) {
            if (property.@access == undefined || property.@access == "readwrite") {
                var name:String = property.@name;
                if (target.hasOwnProperty(name))
                    target[name] = source[name];
            }
        }
    }

    //copy dynamic properties
    for (name in source)
        if (target.hasOwnProperty(name))
            target[name] = source[name];
}

I have needed this so many times I find it hard to fathom why something similar is not included in the mx.utils.ObjectUtil class. It marries perfectly with ObjectUtils.clone().

A simple example:

1
2
3
4
5
6
var editableItem:MyClass = ObjectUtil.clone(originalItem);

//the user edits editableItem
//if he cancels we just discard this instance
//if he commits his changes we copy the new values
ObjectUtil.copyProperties(editableItem, originalItem);

Gigs - Easier ActionScript Event Handling

Some time ago I created Protection. It was a library intended to help me write more readable ActionScript code without breaking out of the paradigms that were set out by Adobe. You can find a more thorough explanation and motivation in an article I wrote earlier this year. I have been using it a lot now and as much as I like the basic idea, I came to realise that I had made a few wrong decisions. Most importantly:

  • overcomplicated nomenclature: in a silly attempt at originality I used military metaphors throughout the library (Sentries, Captains, Spies, etc.). These names make the code actually less transparent to someone who doesn’t know where they originated (i.e. anyone but me). This is in clear violation with my original intent: more readable code.
  • too many optional arguments: a lot of different configuration was passed through one method with a bunch of optional arguments. Again, this would not be transparent to someone who read such code for the first time.
  • used inheritance (instead of composition) to add the functionality to custom components
  • string-based conditionals: "r:propertyA", "f:propertyB" to pass ‘propertyA’ to the result handler and ‘propertyB’ to the failure handler? Not so pretty.

Enter Gigs (a.k.a RIAstar events)

So I decided to rethink the whole thing. To start with, the library name will remain my only attempt at originality. But let’s get down to the real stuff. This is how you use Gigs for tracking native Events:

1
2
3
4
5
follow(submitButton).by(MouseEvent.CLICK).handle(submit);

private function submit():void {
    //do some submitting
}

You can also join a ‘gigs.properties’ file to the application in which you can associate default event types to specific classes. For instance 95% of the time on Buttons we listen for CLICK events. So we register a default for that:

1
spark.components.supportClasses.ButtonBase = click

And then we can write the following to do the same thing as before:

1
2
3
4
follow(submitButton).handle(submit);
//we can still explicitely listen for
//another event than the registered default
follow(submitButton).by(MouseEvent.MOUSE_DOWN).handle(startDrag);

Passing property values

The ‘handle’ method takes one additional …rest argument to which you can pass all the event properties you want pass to the result handler. For example (I’ve registered the ListBase class with the IndexChangeEvent.CHANGE event type):

1
2
3
4
5
follow(itemList).handle(editItemAt, "newIndex");

private function editItemAt(index:int):void {
     //open item editor
}

Unfollowing (a.k.a. removing event listeners)

There are three ways to stop following Events.

Very specifically:

1
unfollow(submitButton).by(MouseEvent.CLICK).handle(submit);

Somewhat specifically (this will remove all event handlers that react to a CLICK event):

1
unfollow(submitButton).by(MouseEvent.CLICK).all();

Loose cannon (removes all event listeners for all event types for the given IEventDispatcher):

1
unfollow(submitButton).all();

To be continued

That’s it for now. I have yet to recreate all functionality that existed in Protection, but I will hopefully get to that soon.

CFInvoke With a Custom Endpoint - ColdFusion

Consuming web services in ColdFusion is easy - at least since CF9, because it used to be a PITA in previous versions for some kinds of services (e.g. SOAP).

You can even write it in one line - woohoo! -, like this:

Default cfinvoke usage
1
2
3
<cfinvoke webservice="http://www.riastar.net/service/?wsdl"
          method="remoteMethodName" someArgument="hello"
          returnvariable="result" />

CFInvoke assumes that the url of the service and its endpoint are the same. As usual with ColdFusion, this is all very nice and handy as long as your situation matches the default. But from the moment you have to customize a bit, you can start pulling out your hair. And the fact is that the real world has this tendency not to match the default situation.

For example: if the service you want to access has an endpoint that differs from the service url, you’re out of luck. I found the following - completely undocumented - solution to use a custom endpoint:

cfinvoke where endpoint != service url
1
2
3
4
5
6
7
8
9
10
11
<cfset service = createObject(
          "webservice",
          "http://www.riastar.net/service/?wsdl"
) />
<cfset service._setProperty(
          "javax.xml.rpc.service.endpoint.address",
          "http://www.riastar.net/service"
) />
<cfinvoke webservice="#service#"
          method="remoteMethodName" someArgument="hello"
          returnvariable="result" />

Notice the underscore? That means you should probably not be using this.

Anyway, while researching this I also figured out the cfscript syntax to do the same thing.

cfinvoke where endpoint != service url as cfscript
1
2
3
4
5
service = createObject("webservice",
                       "http://www.riastar.net/service/?wsdl");
service._setProperty("javax.xml.rpc.service.endpoint.address",
                     "http://www.riastar.net/service");
result = service.remoteMethodName(someArgument="hello");

You can also find this snippet on Gist.

RIAstar.children = [New Lena()];

My five-week old daughter is lying next to me on the couch and is telling me that I ought to show the interwebs the beautiful birth card I made to announce her arrival in this world. Or at least, that’s what I gather from her babbling. So without further ado:

Pixelate Filter With Pixel Bender

Well, I finally found some time to dive into the Pixel Bender pool and start playing around with that new technology that came from Adobe-land. And this is what I came up with for my very first attempt: nothing too fancy, just the Pixel Bender version of the well known ”Pixelate” PhotoShop filter. Give it a whirl by adjusting the pixel size with the slider. Flash Player 10 required of course.


Here’s a working example. Just play around with the Pixel size slider.

Please install latest Flash Player Plugin.

You can check the ActionScript source code and here comes the Pixel Bender kernel source:

Pixelate kernel
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
<languageVersion : 1.0;>

kernel Pixelate
<
   namespace : "net.riastar.shader";
   vendor : "RIAstar";
   version : 1;
   description : "pixelates an image";
>
{
   input image4 src;
   output pixel4 dst;

   parameter float size
   <
      minValue: 1.0;
      maxValue: 20.0;
      defaultValue: 4.0;
   >;

   void evaluatePixel() {
      float2 pos = outCoord();
      float center = (size + 1.0) / 2.0;

      dst = sampleNearest(src, float2(
         pos.x - mod(pos.x, size) + center,
         pos.y - mod(pos.y, size) + center
      ));

      //make sure not to sample outside the borders
      if (dst.a &lt;= 0.0)
         dst = sampleNearest(src, float2(
            pos.x - mod(pos.x, size),
            pos.y - mod(pos.y, size)
         ));
   }
}

I had quite a hard time getting it to work in ActionScript, apparently because I installed the Flex 3.3 SDK just a week ago. Just putting a declaration of a flash.display.Shader class in my code, was sufficient to stop all code from executing, although the VM did not crash. I also got no error message whatsoever.

So after a whole hour of trying everything I could think of, I told the compiler to use the old 3.2 SDK and tadaa: working like a charm. Is it a bug in 3.3 (which was meant to be a bugfix release in the first place) or did I do something wrong?