I recently read a blog post by Gilad Bracha, I know, late to the party, but here’s said post: http://gbracha.blogspot.com/2011/06/types-are-anti-modular.html

I whole-heartedly disagree with him, and I will try to explain why. I am a huge fan of type-casting, it is one of the reasons I enjoy writing AS3 a lot more than I enjoy writing JavaScript. Even if the statement “Types Are Anti-Modular” were true (it’s not), there are way more pros to type-casting than that one con:

a) Type casting makes things make sense.

At any point in a project you can map out all dependencies, see which modules interact with each other and essentially, you could, with only parsing through code, print out a meaningful diagram of your entire application.

We’re talking Hansel and Gretel here. What happened when the birds ate the breadcrumbs? They got lost. No type-casting, means lost developers.

Type-casting gives you structure, meaningful tangible structure. Especially important if you are working on a project with more than one developer involved.

b) Type casting saves development time.

Anybody that has written code with any level of IntelliSense knows how much easier it can be to code with a type-casted language. I write code so much faster and efficiently in AS3 because I can type out 3 or 4 letters of a given method, rather than all 15 characters. Not only that, it significantly cuts down on the frequency of typoing your variables or method calls.

Hitting CTRL+ SPACE gives you an easy way to reference all variables and methods on a given type of object. This is huge, especially when working with Classes that were written by another developer, or Classes that you wrote a while back that are no longer fresh in memory. In JavaScript, with no type-casting, I not only have to track down the file said Class is declared in, but I have to scroll through hundreds of lines of code just to see what variables and functions exist in said Class, and if I want to know what functionA or functionB return, I have to read through the entire function to determine a return type.

c) Type casting polices proper structure.

With type-casted languages you get early warnings of, “No, you’re doing this all wrong!” By expecting classes of IFruit, if a developer tries to pass a non IFruit type object to a method expecting an object of IFruit, it will throw a fit, even if the method does not use methods explicity available to IFruit type Objects. Such as Obj.eat(), which could exist on objects inheriting IMeat, IVeggie, IPerson.

b) Types are not anti-modular

Rather, the problem lies in the structure of a given application, or more specifically the problem lies in the developer(s) who don’t know how to properly structure an application.

Interfaces exist for a reason, there is no reason to compile ObjectA-ObjectZ into your module, instead you use interfaces. Interfaces should be created, not for every Object, but for groups of Objects, i.e. Apple, Banana, Orange, Mango all inherit from IFruit, and your only dependency in the Smoothie Class, is IFruit, you don’t depend on Apple, Banana, Orange, Mango, etc… The footprint is low, for a lot of gain.

Interfaces act as blueprints, and really they are well worth the effort to be able to benefit from the rest of the pros of type-casting.

Interfaces, when used properly totally negate the “Types are Anti-Modular” argument.

Apparently, I’ve been living under a rock as I just heard wind of the fact that Adobe is planning on renaming Flex Builder to Flash Builder. Is this change a good or bad thing? I’m personally indifferent, but I can see how to certain people such as headhunters, recruiting managers and clients this might cause some confusion as a lot of people may thing of Flex as a whole different technology.

I started reading some blog posts on the subject and some of the discussions/arguments ensuing over this change, and came to the conclusion that people seem to have quite a few misconceptions and false ideas on this whole subject, “Flex Developers” included.

I’m sure this is covered elsewhere somewhere, but I felt like writing about it anyways.

So, first things first, what is Flex? At it’s simplest definition, the Flex SDK is an AS3 framework, that’s all it is. What tool you use to develop Flex apps in is entirely up to you, it’s not tied to any program at all. Sure you can use Flex/Flash Builder, or FlashDevelop or even Notepad for that matter, but no it’s not it’s own “technology” per se, it’s a framework, and it’s only AS3. By calling yourself a Flex Developer, you are not saying you know x and y programs, instead you are saying you’re an AS3 developer with a coherent understanding of the Flex SDK.

Yes, there is MXML, which is a markup language, and there is an MXML compiler (included in the SDK), so maybe the SDK is a bit more than just a bunch of AS3 classes, but nonetheless MXML compiles into .swf form, which is played back by Flash Player. If your content is viewed in Flash Player, then the tool you use to build it being called Flash Builder is completely understandable, and makes perfect sense.

Basically what I’m trying to say is that I don’t see why some people are almost up in arms over this whole thing, as looking at the name change logically, it all checks out fine.

Like me, you might have realized that events in AS3 are quite restrictive — they can never leave their heirarchy and thus they promote tight coupling. Why is this? Let’s look at an example:

Let’s say I have a button that I when clicked I want to change the background color of another MovieClip and the background music track that is playing. Using Flash’s built in event handling, I would have to do something like this:

myBtn.addEventListener(MouseEvent.CLICK, myBtnClick);

function myBtnClick(e:MouseEvent):void{
  this.root.backgroundMC.changeColor(0xFF0000);
  this.root.musicPlayer.changeSong("newSong.mp3");
}

This, ladies and gentlemen is bad software design. Why? Because everything becomes so tightly coupled. Now, if you decide to remove musicPlayer (even if you’re just guiding it out temporarily), you have to go into the myBtnClick function and comment out the line that references it. For small projects, this isn’t really a big deal but when you start building out games, intricate websites with a lot of components and pages, it gets to be quite a mess.

The solution to this is to take a different approach and build out a class to handle these types of things. This class is called EventManager and what it does is act as a liaison between components. This class is quite simple and only has 3 methods: registerInterests(), unregisterInterests() and fireEvent(). I’ve stripped down my EventManager class (the one I use in my AS3 framework) and pasted it here: http://pastie.org/528406. Take a looksie, you can even use it and modify it if you want.

So… what does this mean? Let’s take the same example above and using EventManager, do it the right way:

myBtn.addEventListener(MouseEvent.CLICK, myBtnClick);

function myBtnClick(e:MouseEvent):void{
  EventManager.fireEvent("myBtnClicked");
}

Okay, so it’s not much shorter, in terms of amount of code, but what this does is enable myBtn to not have a care in the world. All it does now is say “I was clicked!!”; it is no longer responsible for making sure that all of the necessary components that care about it being clicked do their business.

Now, of course, the background still has to change and the music still has to change, and those are handled within their respective components. Thus, backgroundMC would look like this:

EventManager.registerInterests(this, new Array("myBtnClicked"));

function catchEvent(e:String, args:Object) {
  if (e == myBtnClicked){
    changeBGColor(0xFF0000);
  }
}

And musicPlayer would look like this:

EventManager.registerInterests(this, new Array("myBtnClicked"));

function catchEvent(e:String, args:Object) {
  if (e == myBtnClicked){
    changeSong("newSong.mp3");
  }
}

Now, if you guide out musicPlayer or backgroundMC, everything else works as expected, no errors. It also makes all of your components very self-centered and independent. Another benefit to this approach is that it sets things up very nicely for good and proper unit testing.

All of this is “Timeline” code for simplicity’s sake. But I’m sure you’ll find that adopting this approach into your classes is very easy. This is also a very simple example and there are a lot more practical demonstrations of this concept, however I hope this sheds some light for you and you see the benefits of taking this approach.

I’d be more than happy to share some more on this subject if anybody is interested.

So, I inherited a project from a contractor that was supposed to help me out by writing all the code for a Tournament Brackets project we’re (or should I say I’m) working on over here at the Berg. After several weeks of slow progress, we finally let him go and I decided to finish the project myself. When I finally got around to opening up the main TournamentBrackets.as class, lo and behold I found out that finishing this project would be quite an adventure. And I would have to brush up on my knowledge of ancient Africa in the process… Here’s the code that I found in that class: http://pastie.org/522429

Now, onto my rant:

I have high standards for myself and others. I write clean, understandable code, I use consistent syntax, and I comment where necessary. I also program considerately, I don’t use abstract or foreign words/concepts and I put extra effort into naming variables and functions. However, on the other side of the spectrum, I don’t obsess over doing things exactly this way or exactly that way. I adapt to situations and mold a solution around a problem; I don’t try to shove the problem to fit into my solution.

Why do I do this? Because I think it’s necessary, and it helps me sleep better. I take great pride in my work and I don’t find it acceptable if others have to point out flaws in my code or correct anything I do. As a matter of fact, I refuse to let other people fix my code (unless absolutely necessary due to a looming deadline or something). I do this not because I think they are going to screw it up, but because if I did something wrong, I am responsible and obligated to fix it.

I’m not trying to say I’m perfect or talk down to others, but I feel that a lot of developers are too lax and casual about the code they write; leaving temporary variables and methods inside of Classes, hacking something together “just to get it working” only to not fix it later, etc. The bottom line is that more developers need to take the “perfectionist” approach towards programming. A lot of people would benefit from it, especially in tightly nit groups and large projects.

And if you’re solely working on things that only you will ever have to touch, then do whatever you want to do, code how you want to code and utterly disregard what I’m saying (unless you are as self-obsessed as I am).

Alright, so I have a week to write an AS3 chat client that uses jabber.

I have just finished setting up the Jabber server so now it’s time to start hacking away — I’ll keep you posted on the status.

For the server, I am using OpenFire, which turns out to be pretty nifty (and did I mention free?).

And I’m using the XIFF API from Ignite Realtime as well. So without them, I’d be going down a path that I would feel much less confident about. Using something like Unity2, or even building my own retarded backend for serving chat, which would inevitably bog down due to server load from the retardedness of constantly hitting the server every 2 seconds to check for updates. I could probably come up with a decent solution if I had more time, but 1 week isn’t enough to write your own chat server, I don’t care if you’re Superman (or Superwoman).

However, now this is interesting — the XIFF API is only supported for Flex, and though I have tons of experience in Flex, this is something I really have to accomplish outside of Flex. I think I have a really good solution to this without even having to touch any of the API code itself, if it all works out I will post the solution. If all goes as planned, and I do get this working, I will post a mini-tutorial/how-to on how to get a jabber flash client set up, from start to finish using the Flash IDE (not Flex).

So, I feel good, I’m curious to see how this will progress and turn out in the end.

Yes, I know the XIFF API is still in Beta, but so what? I’ve come to realize that most of the sites I build get a lot less testing than any of these API’s and still they get pushed live.

As long as it works consistently and stable in the end, I’ll be happy.

Happy coding,
Taka