Software, Fitness, and Gaming – Jesse Warden

Blog

  • Flex & Agile Software Development

    I took a stab at Agile Software Development on my latest Flex project. I haven’t read much on Agile Software Development. I really didn’t have to. Many blogs I read pretty much summarized it into “weekly builds”. Those 2 words don’t do it justice, but they certainly imply the “release early, release often” mentality. This greatly changes the way I’m used to doing things.

    First, I’m used to coding a bunch of classes; compiling them to ensure my ideas work. If they do, then I start building an architecture of code I’ll learn to live with, start bringing in the ARP classes, and building my Views first since View’s are easy, and pretty much drive HOW you use the app. From there, it’s building Commands that equate to “doing” things, and finally the dreaded Delegates. They contain all your server methods, data mangling… er, I mean handling, and call your back-end via Remoting (CFC’s, PHP methods, Java methods, etc.). Finally, you start wiring things together… and do your first big compile.

    All of that crap above usually equates to a 2 weeks to a month. You don’t ever really see your software taking shape until you get true data coming in from the back-end.

    Not with ASD.

    Instead, every week, I complete some milestone through a series of goals. By Friday, you can not only compile, see your targeted functionality working, (damn this is a good mix, rave, rave, rave…), but you can more quickly tell if the functionality is “right”. Meaning, you can throw it in front of a user or your client, and go “What do you think?”. Suddenly, that’s one less thing to worry about prioritizing. You either were madly successfully, or screwed up big time. Screwing up early on the main functionality is fantastic! You can more quickly make it right, when it matters most. You can either wax the functionality, mark it off on your list as done, or tweak it next week.

    The trade-off? You have to write code that compiles. Suck. I know, right? Writing code that compiles… imagine that. Seriously, though, you can flesh a TON of stuff out, and more easily see your designed masterpiece more quickly and easily if you pretty much tell the compiler required code to f’off for a few days/weeks while you flesh out your ideas. Getting something compile-able, especially in a larger project even with a framework takes a lot of finishing touches, final nuts and bolts details to be written, and overall a lot of duct-tape that is a pain in the ass to write.

    Granted, it doesn’t take all of that long to write, but it is very volatile code, doesn’t flow from your fingers, and you are definitely not emotionally attached to it. After all, it is not what makes your architecture a masterpiece… it just allows the compiler to understand it. Examples include THE import statement that runs attachMovie on your main component, or the code that throws fake data at your view to show it’s working… crap like that that is usually a lot more involved and larger in scope that what you use to initially test. All of that to compile.

    Again, however, the results are well worth it. You suddenly aren’t recoding functionality milestones. You very quickly know whether or not they hold up in terms of being useful to the user, or liked by the client. They are done. The d-word is the hardest thing to say in software development. Seriously, how many times have you cheapened that word’s meaning by saying it so many times, thinking that if you repeat it like Dorthy repeated being home, that it would actually manifest its details and happen.

    So, seriously, you’re done… and if your not, you know usually exactly what NEEDS to be done to make it so. Good feeling.

    The down-side, is, someone either needs to update the wire frames after doing the iterative sweep, unless it’s a minor tweek, or there aren’t many developers involved.

    The other benefit, at least I thought, was “proof of progress”. As I recently told someone via email advice, design projects are more subjective & visual, thus visual changes delivered via a calm, positive voice imply progress. You do the same thing with 50,000 lines of brand new code, but no one gives a shit if nothing changed visually. With a working build, however, you can clearly click the same button 50 times and go, “SEE!!! A new error alert comes up; I worked all weekend for that error checking… my alert dialogue will p@wn you client! IT’S MODAL… IT MUST BE OBEYED!”

    Since code, while objective to track, is subjective to show, it suddenly becomes more objective; you can clearly show something working that wasn’t working last week. The cool thing, too is that ALL of your other stuff usually doesn’t break. Why would it? You’re already “done” with it. See where this is going?

    However, I’ve found in practice this didn’t hold up. nTier development usually consists of a server that doens’t truly work without a client, and a client that doesn’t truly work without a server. Both have to be developed to their extent, and tested in concert.

    Regardless, weekly builds, while not getting the proof of progress emotional effect I wanted, clearly smoothed communication between my boss and I. We can waaaaaaay more easily judge what was completed, what wasn’t, and where we needed to go specifically. Anything that helps communication in software is a good thing!

    So, in conclusion, while it was hard writing code that was compile-able more early than I’m used to, as well as ensuring it compiled every week to working state to ensure a feature did in fact work as the client intended, it was REALLY nice to never touch a specific command, delegate, and view (mvc basically) again, unless something needed to be changed because of scope creep or it needed to be changed because it was looked at the very same day. That made me feel like I was actually making progress.

    I think a lot of developers feel like they coded something, only to write 10,000 lines of code that equate to 100; since they’ve written that many lines just to change the same 100 through the course of a project’s lifecycle.

    Second, while perceived progress didn’t give the emotional effect I wanted, it certainly made me feel good about how the project was going, and helped communication with my boss.

    Finally, it was a lot easier to project time-frames; I knew what was truly “done” so could clear my mind of other concerns when calculating timeframes of what needed to be done for the next milestone.

    I guess I was under the impression that ASD would give my clients a warm feeling that we were truly making progress because they could “see it working” but that is a false perception. Live and learn. It’s really for me, the developer, to be more successful, not to make people feel good. Bottom line, I’m successful when my software is done.

    So, where does Flex fit into this? This is the first project where less than 10% of my problems where related to the tool I’m using to complete my task. The rest were coding & testing errors on my part. This 10% included undocumented lower level classes dealing with the Flex framework, lack of true strict typing to catch misspellings resulting from more dynamic ways of coding, and extra time that it took to debug using FlexBuilder.

    My experience in the past has been 30 to 40% when dealing with Flash. That portion of your time is figuring out “wtf Flash is doing” vs. “wtf is my code doing”; which a lot of time one blurs into the other, mainly in regards to use of components.

    This time, however, Flex came through and I felt like I had very little problems when doing this project from a coding standpoint. The only problems I DID have were communication wise, and that’s pretty good considering I telecommute.

    I think I’ll use Agile Software Development on every project from now on, from big to small in scope. It feels like I’m building pretty prototypes, and I have the option to use the word “beta” in a pinch during client/user testing. Overall getting more done, and getting it done better. I know for damn sure I’ll be using Flex; she came through like I expected her to.

    …this assumes my definition of what Agile Software Development is, let alone my implementation, is even accurate. Even if it’s not, it’s certainly better compared to “the big compile”.

  • Financially Justifying Speaking at Conferences

    Flash conferences are fun. WebDU (formerly MXDU) is fun because you have an international crowd & speakers, it’s in a warm climate in an awesome country, Australia. I’ve heard great things about Flash in the Can, Flash Forward, and MAX. I was planning on speaking at Flash in the Can & Flash Forward in 2006… but plans have changed.

    Not only have I waited too long to submit proposals, but I suddenly am finding it hard to financially justify speaking in the first place.

    Why do I speak? I love to speak about what I love, and what I love is the technology I use, namely Flash and its brethren. I also love meeting people I’ve known online for years, but never met in person. I enjoy seeing those I have already met, and hanging out again.

    I cannot, however, justify them financially anymore. Now that I’m a contractor, even if travel & accommodations is paid, that is still time I am not working, and thus making no money. The first 2 MXDU’s did wonders as additions to my resume, while the networking contacts went deeper than business. Capitalizing on them seems fruitless, however. My plans to relocate to Australia never panned out, so I’m apparently in the states for good.

    All of the potential work I receive is through networking contacts, my blog’s high page rank, and referrals. No one has specifically mentioned they heard me speak at MXDU and want me for a project. While many assumed I’d be at MAX, most were friends & professional colleagues.

    I know a lot of people who are speaking, some personally, and I guess I really don’t understand how you all financially justify speaking at them. It’s easy to emotionally justify them; they are extremely fun and rewarding, and sometimes you even learn something during chats, or the odd chance you’re a speaker and actually attend a session.

    Obviously, this point is moot if you are an attendee; I’m referring specifically to speakers.

    If you are a speaker, not an attendee, how do you financially justify it?

  • Calling Functions Repeatedly in ActionScript 2 & 3: setInterval, setTimeout, and Timer

    Pre-ActionScript 3, Flash could use setInterval. This method allows you to have a function called at a recurring time frame. So, you could have a “hello” function called ever 3 seconds.

    setInterval(hello, 3 * 1000);
setInterval(someScope, "hello", 3 * 1000);

    Both forms invoke the function “hello” every 3 seconds. I personally always used the 2nd form to avoid any weird scope issues and EXTREMELY easier to debug; there is no confusion over what scope the function is being invoked in.

    You can stop the interval from calling your function over and over by clearing it. All intervals created return ID’s, which are a unique number identifying the interval. If you want to clear an interval, you have to keep the number around to clear it later. This number is returned when you call setInterval.

    theID = setInterval(this, "hello", 3 * 1000);
clearInterval(theID);

    Intervals are dangerous. If you forget to clear one, it can continue running in the background, leading to memory leaks and performance issues. Since there is no visual indication for intervals that do not call GUI related functions, and the API for them is small, they are hard to track down.

    The 2 main ways to ensure in ActionScript 2 that you never have problems is to always call clearInterval right before you call setInterval with the same ID, or use Kenny’s interval management class.

    Flash Player 8 introduced the setTimeout function. Most uses of setInterval were really for delaying the calling of functions. Because Flash is all about events, and programming in it is very asyncronous in nature, one tends to adopt the calling of functions in a similair fashion; you wait for other things to happen before you yourself call functions rather than immediately. Such as waiting for the screen to refresh, giving a CPU intensive operation additional time to cool down, or launching a hyperlink when your content is loaded. There are some issues in using it in a class, and it was mysteriously not documented, but Guy has some good info on it’s usage in the comments. You can also clear a timeout just like clearInterval via clearTimeout.

    As of Flash Player 8.5, and thus ActionScript 3, setTimeout is relegated to being depreciated already. Damn… that function only lasted HALF a player version. That’s a first.

    Both setInterval & setTimeout were moved to the flash.util.* package.

    The new class to use for both use cases, repeatedly called functions and post-poned one shots, is the Timer class, also defined in the flash.util package. Both intervals and timeouts tended to pollute your class in their usage, more so intervals than timeouts. You usually had to not only keep a property that held your interval id, but also all the management code for making sure the interval was cleared, mixing both the function that’s run and the interval management in one.

    Now that Timer is it’s own class, this is a lot cleaner. On the flip-side, it knows nothing of your code, however, so it’s up to you to call the function, which actually adds more de-coupling; you can choose to call the function or not, and still let the timer continue running. Or, you can just do it the old fashioned way, and have the listener function BE the function you want called.

    One thing I don’t really like about it however is its name; it’s not really a Timer in the general sense of the word because it isn’t timing anything, at least that it exposes to you. Rather, it’s more of a beacon, and fires off just 1 event, “timer”. Granted, you could use the Timer class to create a timer.

    Here’s a code snippet example from the docs commented:

    // create a timer with a 1 second
// delay, that fires twice
var myTimer:Timer = new Timer(1000, 2);
// have your onTimer function listen
// for the timer event
myTimer.addEventListener("timer", onTimer);
// unlike an interval & timeout,
// she doesn't start ticking
// until you start it
myTimer.start();
// this function will run twice,
// every second,
// starting 1 second after you call start
function onTimer(event:TimerEvent)
{
        trace("onTimer: " + event);
}

    The 2nd parameter to Timer, and also a public property, is the repeat count. This allows finer grained control on how many times the timer event is generated. You can set it to 1, 20, or 4,294,967,295 times… which would take 7 weeks assuming your function took 0 milliseconds to run.

    What’s special about it, though, is 2 things. First, you can set it to 0, which is infinity. Basically, it’ll keep going until you stop it.

    Second, it’s a public, writable property. Meaning, you can change the speed it goes WHILE it’s going, or while it’s stopped.

    This goes for the delay as well. It, too, is a public property that you can change, speeding up or slowing down the running timer.

    Frankly, I don’t think setTimeout is deprecated as they say it is. It feels a lot more elegant to me to just use 1 function to make an intentionally prolonged function call. Still, Timer is a, if not aptly named, pretty bad ass new class.

  • Bluetooth Wireless Keyboard for my Nokia 6680 Phone


    My Nokia Bluetooth Wireless Keyboard arrived today for my Nokia 6680 cell phone. Retails for $199, but I got it for about $139 at Mobile City Online. It’s only fitting that I get a keyboard for a phone that boots. There is definately a line a device crosses, more so a phone when the words “boot” and “shutdown” enter your vocabulary when describing its functions as opposed to “on” and “off”.

    While wireless itself isn’t new, the fact I can blog from my dining room via tools that fit in both pockets is just wicked. All I need to do is make a lighter weight interface in HTML since the current MoveableType one is too heavy for this phone’s browser…at least, I think it is. I can already email my pictures to Flickr, so once I get cellblogging on this mofo, I’m set!

    The last trip I took, I didn’t have a laptop, just my Nokia 3300 which had text & multimedia messaging which doubled surprisingly well as email. Flickr worked the same, although the camera wasn’t near as good.

    Now, I can check real email as this one suppports POP and IMAP; she’s slow, though, because I usually get like 200 emails an hour, and the phone’s MEdia net connection certainly isn’t broadband.

    :: back on computer ::

    MAN, my next keyboard will definately be an ergo… geez, I certainly couldn’t make my living coding on that mofo in a coffee shop.