The mod7 team has been super busy lately (which meas I've been super busy), I'll have some new stuff up (not so)soon-ish :)

In the mean time check out this new game The k-Crew Detectives: Case of the English Bay Bandits! and the companion site: vblearn.ca which will teach you a little about a lot of fantastic art around Vancouver.

vblearn.ca

I just wanted to document this as I'm sure someone else will run into the problem, and there isn't much information out there. Here's the details:

Situation: Your using Google Apps mail to grab emails from some.address@mysite.com. The server running mysite.com is using Qmail as your MTA. (As Plesk servers do)

Problem: When you generate email from a script running on the same server, and send it to an address at the same domain, Google Apps fails to to pick it up. It picks all other email up fine.

Quick solution: In your Qmail config file, disable mail for mysite.com. (In Plesk, this file can be found at: /var/qmail/control/virtualdomains)

Semi-long winded answer: Qmail handles local mail differently than outgoing mail. So if you send mail to foo@mysite.com, from a script running at www.mysite.com, it bypasses the mail queue entirely (so Google Apps can't pick it up), and just directly delivers it, (locally). By disabling mail handling for that domain, it's not recognized as being a local address, and is placed into the queue., and Google can pick it up!

It's quite simple, once you know what to do.

Fall'n Blocks is a Tetris-like game (you can't call it Tetris, for obvious reasons) written in AS3. This is just for fun, no real motive behind it. It just seemed like a good way to spend a free Saturday! And of course, the source is included below. Have fun!

Get the source.

A note about the code: The source code is by no means the cleanest, nor is it the best implementation. This was a fun project exploring a few specific areas of personal interest. It's not the worst, but be warned. (and have fun with it)

Here's a quick tip that you can file under "good to know."

I typically end up using regex's at some point in most projects. Anything with user input is pretty much a guarantee. Recently when adding some new functionality to a strip tags util I came across a situation I've never encounter before in ActionScript. As the title suggests I wanted to use a variable value in the expression, while this isn't typically an issue, I came a across a situation where it didn't work. Here is the real world example.

Original regex¹:

/<("[^"]*"|'[^']*'|[^'">])*>/ig

This nifty expression works like a charm. But I wanted to update it so the developer could limit which tags it stripped to those specified in a array. Pretty straight forward stuff, to use a variable value in a regex you first need to build it as a string and then convert it. Something like the following:

var exp:String = 'start-exp' + someVar + 'more-exp';
var regex:Regexp = new RegExp(exp);


Pretty straight forward. So when approaching this small upgrade, that's what I did. Of course one big problem was pretty clear.

var exp:String = '/<' + tag + '("[^"]*"|'[^']*'|[^'">])*>/';


Guess what, invalid string! Better escape those quotes in the string. Whoops, that will break the regex! I was stumped. So I opened up the language reference to see what I could find. The "source" parameter, (which I've never used before,) caught my eye. It returns a String described as "the pattern portion of the regular expression." It did the trick perfectly. Here is the solution:

var start:Regexp = /;
var end:Regexp = /("[^"]*"|'[^']*'|[^'">])*>/ig;
var complete:RegExp = new RegExp(start.source + tag + end.source);


You can reduce it down to this for convenience:

var complete:RegExp = new RegExp(/+ tag + /("[^"]*"|'[^']*'|[^'">])*>/.source, 'ig');


Anyways, put that away into the old memory bank, it might come in handy.

¹Original expression from Mastering Regular Expressions, by Jeffrey E.F. Friedl

Steve McConnell sets up the dream perfectly:
With stable requirements, a project can proceed from architecture to design to coding to testing in a way that's orderly, predictable, and calm.¹

Of course anyone who has worked on anything knows this is exactly that, a dream. (He agrees) Changes are inevitable. They happen for a variety of reasons, and almost always² results in a better end product. You know they are going to happen, so you you need to plan for them from the start. You should have a change procedure clearly outline with the client, and account for them in the initial budget. Here's why:

A project change that takes 8 hours for a developer to implement, can easily require 16 man hours from a project budget, and cause a 5 day disruption in the production schedule.

Whoa! What? That's right. Changes aren't limited to the time a developer spends implementing, it can affect a big chunk of the production. Budget needs to be set aside for handling requests, because even if the change never gets implemented, there is a cost associated with it. Before you can budget for it, you need to understand it. Lets look at the anatomy of a change request.

1. A problem is flagged.
Change requests always begin with a problem being identified. Problems vary greatly, from "User flow is confusing" to "We forgot about X, which our funding requires." These can originate from the client or internally.

2. Communication
Once a problem has been flagged, all stake holders need to be updated on the situation. This happens through emails, phone calls, and meetings (internal and external). If a developer is currently build what has been flagged, they may need to stop and wait for a solution.

3. Exploration
Once everyone agrees that the problem is legitimate, and a solution needs to be found, options need to be explored. This can be anything from a meeting to user-flow diagrams and wireframes, there might be prototyping and multiple explorations. The bigger the change, the longer this will take.

4. Spec out the solution
Once a solution has been found it needs to be spec'd out for everyone. This should be in the form of a document that a client can sign off on and the developer can use to build from. It should clearly out line the problem, solution, and affect on the project cost/schedule.

5. Approval
Approvals typically have turn around time to them where everything is in limbo. Nothing can be done between the time the spec is sent out till approval. Typically there is a fair bit communication that happens here as everyone makes sure they understand the changes. This step will have one of 3 outcomes:

6. Implementation
The process doesn't end with approval, the team now must make the change. This means undoing any of the original implementation that has changed, and then building what's new.

7. Test
Testing! Every change needs to undergo rigorous testing. Is it a web based application? You need to test in all supported browsers/versions.

8. Bug fixing
Changes introduce new bugs. When you fix a bug you have 20-50% chance of introducing a new one.³ For every bug fix you'll need to retest all the browsers.

Even if the change doesn't go through, there is a cost attached to it. You need to stop productivity and spend man hours before you can even decide if there is going to be a change. If there is, you might add additional cost to the project, if not it falls into just part of the production process.

This will happen to some degree on every project, so you need to account for it. Both in your time line and budget.

¹ Steve McConnell, Code Complete - Second Edition, page 39
² I've worked on projects where changes happen for the wrong reasons. Internal disputes, lack of experience, "absolute" orders from higher up, have all caused changes for the the wrong reasons leaving the end user to suffer. Sometimes you have to bite the bullet, but you don't have to work with the client again.
³ Stat from The Mythical Man-Month, page 122, 1995 print

I suck at search, YOU suck at search, everyone sucks at search. Accept it. (unless your the Google bot indexing this page) YOUR sucky search skills are killing usability on the web! But it's ok, there are people who don't suck, and they'll let you drink the kool-aid for free.

I recently updated this site to use Google Custom Search. It took me 5 minutes to setup, and now anyone can search for all the everthing that rocks on this site. I was so impressed I recommended it for a client project, now their search doesn't suck either.

It actually gives you quite a bit of style control. You've got full CSS control over the search box (minus a little bit of Google branding), plus color/font choices on the results page, which you can display in site. Sure the Google results page isn't the prettiest thing you've seen, but it's usable, fast, and familiar to your audience (no matter who they are.)

If you need more control, you can upgrade to their very reasonable paid service. It'll take years for the cost of the basic plan to reach what it'll cost you to pay a developer to build you a bad search system. And by that time you'll probably be 2 site revisions down the road and still have crappy search. So go for it, admit that you suck, and give your users something they can actually use. I'll be doing it whenever I can.

Now if we could just stop people from using IE.

Continuing the effort to clean up some of my code, I've just added a logging system to my open source code, found on the code page. This logger is designed to be easy to use, Flexible, and extendable. It uses writer objects to handle the message logging. Writers can be added or removed at anytime to change what types of log outputs you want, without modifying the actual log calls. Here is a quick rundown of the key features:

With this release I'm also doing some new things that I will be carrying into future code releases as well. These are:

Unit Tests
I will be including my unit tests from now on. Because of the nature of unit tests (simple, clear, and to the point) they make for excellent usage examples that cover all aspects of a code base.

Formal Documentation
I will be releasing more formal documentation from now on. This will include more detailed information, including topics on usage and extending. It should make the code more accessible. Click here to see the ones included in the logger.

More Focused ASDocs
I've included ASDocs in the past, and will continue to do so. These will be focused on what they really are, (which is a language reference), and will not include anything beyond that.

If you find it useful, and create some custom writers or filters please share!

I'll be doing some more posts in the future about this project, but I wanted to put up a quick note about it. Titanium Chef is an Flash Based role playing game that we (mod7) have been developing with the BC Dairy Foundation. The game will run 6-10 hours in length, features fantastic artwork, an engaging story, awesome sound, and subtle humour that spanes across a wide range of ages.

On both a technical and production quality level, this game is impressive. It breaks the notion that Flash based games need to be quick, simple, "casual" experinces.

I highly encourage you to check it out at titaniumchef.ca

Here are a couple in game screens:

Dear reader, this is one of those posts where a lot of readers might be fully educated, however while working with other developers and with various opensource projects, this is an area that repeatedly pops-up as being neglected. Additionally it's not a topic often seen in books or on the web, especially the popular ActionScript resources, so I feel compelled to begin addressing the topic here. I encourage you to contribute additional points and/or suggestions in the comments.

We constantly deal with object lifetimes when we are developing our applications. Evidence of this is making sure we clear all references to an object so it can be cleaned up by the garbage collector. However object lifetime should play a much bigger role in the design of an application then that, and as a result deserves more attention then it gets. In this article we will look at what object lifetime means on a technical level, and then the role it plays in performance and application design.

Object lifetime is the length of an object's existence in an application. Technically speaking, from when memory is allocated (reserved) for the object until it is deallocated (freed for re-use). This process is handled for us in ActionScript, but occurs based on our actions. For example when we use the keyword "new" memory is allocated for the object we are creating, and when the garbage collector cleans it up that memory is deallocated.

Based on the previous definition, we can look at our Flash applications in terms of lifetime. The Stage has a lifetime at the application level, meaning it exists as long as the application is running. An array that contains references to all the children in a DisplayObjectContainer has a instance level lifetime, so it will exist as long as the DisplayObjectContainer exists. Other object's lifetime may be limited to a method call.

Often developers have objects who's lifetimes are too long. I believe a it stems from a number of places, but based on work with other developers a few key place are:

Object creation in ActionScript is expensive, but so is keeping unneeded objects in memory. Managing object lifetimes in an application means creating and destroying objects as needed, allowing us to keep the application running at an optimal speed while using minimum resources.

Take for example a Flash website where all the major sections are created at application initialization. (which puts them all into application level lifetime.) Changing a section simply means changing the visibility property, or adding/removing display objects from the display list. The result is that the entire site is kept in memory all the time, regardless of if the user ever visits each section.

The truth is, that for many Flash sites, "micro sites" for example, you could argue this just doesn't matter. Doing things differently would result in unnoticeable performance improvements on most modern computers, and the end user would not know the difference. This changes however with one particular changing/new (certainly new growth) market that is going to be huge for Flash, that market is cellphones. Cellphones are now starting to to have full Flash support, and we're not talking about Flash light, but full Player 10 support. Suddenly that little bit of memory counts for a lot more.

So how else could you construct your site? The simple solution is to construct the sections as the user requests them, and destroy them when they leave them. You're navigation might be at an application level lifetime, but each page need not be. What about the expense of creating new instances? Changing the section is a limited action, only happening on a user action, so it will not occur at a high rate of speed or necessarily at all, and therefore is not a issue. It becomes cheaper to build on demand and not maintain in memory for reuse. There are several design patterns to assist in the creation of objects, for example the Factory Method.

Looking at another example in a different situation, lets take a general button that offers several methods and properties for styling it, one of which is a label and another is an optional display object to use as an icon. The button uses a TextField object for displaying the label.

A common way of building this button would be to create a TextField in the constructor, add it to the display list, and maintain a reference to it through a private variable for changing the text displayed. The problem with this is that there will be situations where a button has no label, (an empty string), perhaps it's strictly icon based instead. In this case you still have a TextField object in memory that you are not using, that's one for each button instance, so potentially lots of them.  So our label TextField lifetime should not be the same as our button's lifetime. When the label is set, the function handling that process should determine if it needs to create, dispose, or update the TextField object. Construction is not a performance issue because likely the label will only be set once, or not at all.

By paying attention to object lifetime in the design/construction of your application, and keeping objects in the proper lifetime scope, you can gain significant performance increases, especially as the application grows in size, or when targeting power limited devices. While this article only looks at specific examples, this is a topic that applies to every piece of you application, and as a result should be fully considered throughout the construction process. I'll be exploring this topic more in future posts.

additional resources:

Managing Object Lifetimes, by Miško Hevery

ActionScript3 Design Patterns, Bill Sanders & Chandima Cumaranatunge

After working more with Paginator AS3 on client projects I've added a couple of new features to the pagination object and fixed a few minor bugs. The following features have been implemented in the latest update, version 0.6.0.

You can grab the latest version on the Code page.

Version 0.7.0 will feature a simple pagination control view, with the main goal of making prototyping easier.