I am just debugging a few small problems with Apple machines and then there will be a release. Apparently the Mac does not like to handle AIR apps the same way Windows does so there are a few things I have to sort out. Luckily though, I have the AIR updater installed into F4D.

The AIR updater will automatically check the server for differences in your version and the latest version. It does not necessarily check for an entirely new release, but it looks for any differences. This way, if there are a few UI changes, or subtle changes in an external file, those will be taken care of automatically without updating anything else. When a new release of F4D comes out, yours will automatically be up-to-date upon launch. These updates are practically instant. It is not like other apps where you sit there and wait for the download, then install, then relaunch… It literally downloads it fast, then launches… No installations.

This can be turned on and off incase you do not want to always be up-to-date. If you are not online, it will skip the update process.

This was essential to put in before I release it so I do not have to constantly announce “Small fix necessary in section X”. Now, you can just download it and always have the fixes without even knowing. You should be able to see something this week!

Security Note: This does NOT affect anywhere on your computer except F4D’s personal directory. It also will not load your computer up with junk. The current installation size is approx 300k and I do not see it needing to go over 500k.

I was a little tired when recording this one.

There are a lot of really good developers out there. I feel some of them climb the ladder and either hit the “great” category, or the great category. I use one in quotes to represent the same area of expertise but with a slight difference that means a lot. I will relate this area to design patterns for this example.

A “great” developer knows the ins-and-outs of OOP, knows design patterns, knows how to implement them properly, and follows the rules of the pattern strictly.

A great developer knows the ins-and-outs of OOP, knows design patterns, knows how to implement them properly, and follows the rules of the pattern loosely.

Design patterns are not laws. There are things you can do in your coding that will go against the the pattern definition, but leave the heart and idea in tact. I have seen some pieces of code get criticized because they are not a “proper singleton” pattern or … whatever the excuse is. The truth is that the “great” developers are either not good enough to actually bend the rules or they have nothing else going for them except perfection in patterns.

Patterns are great because they are a universal concept to an approach and they have been proven to organize code, but these are not restrictions as some people seem to think we are bound to. It is okay to bend concepts of a pattern if it fits your application more or makes more sense. I have seen situations where actually implementing the pattern to perfection is more confusing then taking a small detour. Knowing when to use a proper pattern and when to bend the rules a little is what separates a “great” developer from a truly great developer. When you are a young programmer, you are afraid to stray far from what you know so you do it strict and to the point. As you gain more experience, you realize that being so strict was never necessary. That concept applies further and further.

( When I say “bend” the rules, I do not mean tearing them to shreds and doing your totally own thing and claiming to be something else. )

Design patterns, and most concepts in developing, are not rules… They are more like guidelines.

I apologize about the lack of quality. GoogleVideo certainly compresses uploads very heavily. Here is the cast (go fullscreen): Video if below doesn’t play

Features Shown:

• Foreground / Background color
• Line staggering / Line opacity
• Motion recording / playback (+options)
• Effects
• Stage transparency (draw directly over Photoshop)
• Live layers preview ( hard to see due to quality )
• Save file

Features Not Shown:

• Line thickness
• Catchup speed
• Fullscreen
• Save Transparent PNG Layers
• Save document merged
• Clear all layers
• Color Shifting+Selection

There is a lot you can do here. I will release this app soon. Send in any requests. I have confirmed that I will be doing an export for Illustrator.

Next V Ideas: Color Shifting Points (pause at color, key command to start shift)

Screens:

Thanks to Jason over at FlashDen.net for writing up a little piece about my PORT project. It may be interesting, and very valuable, if we can collaborate on implementing certain components from the FlashDen repository into some PORT projects.

I would just like to respond to this article a little.

PORT will be released with a focus at Actionscript developers as mentioned. Depending on how things go, it may expand to other aspects of web (design, other languages, etc). My goal is to keep this service free for all users. I am not making any money from this project. I feel that the education system for our field needs to start a reform and I have not seen it happening, but one of us has to start it… Simply throwing funds at your problems will not fix them.

The service will require registration. The reason for this is because we may need your email for certain projects that require a “client interaction.” Some projects will have updates half-way through or important notifications. If you hand in work without the changes, it will be marked down. Also, it is important to record that ‘John Doe’ sent in Project A, Project B, etc so we can record your grades and give credit where credit is due. Everyone hates registration so I will make it as simple as possible (including implementation of OpenID). The PORT website will proudly be using and supporting the Silverstripe CMS system. Check it out!

More news to come! Thanks for the support so far.

I recently had someone ask me the difference between using:

MovieClip( object );
// and
object as MovieClip


I ran some tests to show the example of what actually happens and here you go:

var o:Object = "test"; 
 
trace( 'MovieClip: ' + o as MovieClip );
// displays: null 
 
trace( 'Array: ' + o as Array );
// displays: null 
 
trace( 'Object: ' +o as Object );
// displays: Object: test 
 
trace( 'String: ' +o as String );
// displays: String: test 
 
trace( 'Boolean: ' + Boolean(o) );
// displays: Boolean: true
 
trace ( 'MovieClip: ' +MovieClip ( o ) );
// generates a TypeError

Using the MovieClip( x ) or Boolean( x ) method tries to do a Type Conversion. The Boolean succeeds because it finds that there IS a value available and converts to true. If the value were NULL, it would read false. MovieClip fails because the type just does not match.

When you cast using “as”, it seems to attempt a Try/Catch basically. It will return a null if unavailable, but will not crash your application.

Because a Sprite is below a MovieClip in the inheritance chain, it cannot cast it’s way up.
Worthy of noting: MovieClips are dynamic classes. Sprites are not. Only dynamic classes can receive custom (dynamic) variables. This means you can assign whatever variable you want to a MovieClip, but do not try that with a Sprite.

var mc:MovieClip 	= 	new MovieClip();
mc.customVar 		= 'matt';
trace(mc.customVar);
// traces: matt
 
var newmc:MovieClip 	= 	MovieClip(mc);
trace(newmc.customVar);
// traces: matt
 
var newsp:Sprite 	= 	Sprite(mc);
trace(newsp.customVar);
// undefined property error

If you try to set a Sprite, then cast it as a MovieClip, you will get a Type Coercion error.

var sp:Sprite 		= new Sprite();
var mc:MovieClip 	= MovieClip(sp);
// error
trace(mc);

What does it all mean?

Type Casting is a one-way trip down the inheritance chain. Your basic MovieClip inherits like this:

MovieClip -> Sprite -> DisplayObjectContainer -> InteractiveObject -> DisplayObject -> EventDispatcher -> Object

This is why a MovieClip can cast down to a Sprite, but a Sprite cannot cast up. You can take something away (cast down)… but you cannot create something from nothing (cast up).

For my new PORT project. ( http://mattkenefick.com/blog/2008/10/port-my-new-project/ )

Needs to be:

•    Well versed in AS 2.0 and AS 3.0
•    Understands good design patterns / practices
•    Good coding conventions
•    Deep understanding of the words “Why” and “Why Not”
•    Interested in helping the Flash community pro-bono
•    Able to work with me in grading submitted projects
•    Has creative ideas for faux-projects

If this is something you might be interested in… leave a comment or shoot me an email ( keneficksays@gmail.com ). I am hoping to launch this relatively soon and could use a hand in getting things moving.

If not, you are still free to participate!

Not physically of course. Except for hookers, I am sure they have their sales.

What I mean is this… Macy’s has a 2-day weekend only sale about every two weeks. Why? It attracts customers because they think that it is the only time they will get a deal on something. If there was no sale, people would go if they wanted to buy something. When there is a sale, people feel the need to buy something for no reason just because it is cheaper.

The limitations, the chase, is always the most interesting part of life. Guys seem to put a lot of effort into getting a woman when he cannot have her. After some time of having her, interests tend to change. This is not always the case, but you cannot deny seeing this. Games are always more fun to play when you scarcely have the opportunity to. As soon as you own it, you hardly ever play it.

Why do we die? Well, there are a hundred reasons. I like to think that one of them is because of how boring it would be to live for too long. If you know your time alive is limited, you put more effort into doing what you want to do. “I have to be married by 35.” Why? Because you are running out of time.

So technically… We are all on sale. For the limited time of 80-90 years. Get what you want out of us before our offer expires. But do not worry, our sale will be back again soon enough.