Celebrating my 27th birthday this Saturday at Eleven50 with my favorite DJ, JunkieXL. Tickets are $15. Hope to see you there!
Blog
-
Flash & ARP Widget: DDO Server Status
Preface
Beautiful weekend here in Atlanta, Georgia, USA. Sunny, no clouds, and up to I believe 80 degrees (26 Celsius) this weekend. Naturally, I spent most of it indoors. Part of Friday evening and Sunday I spent creating this application just to see if I could do it. It pings the gaming servers for Dungeon & Dragons Online every minute, a massively multiplayer online roleplaying game. It solves 3 extremely niche problems:
- You need to have the DDO game installed on your computer to get server status updates. This is a web application (or a executable widget); no installation necessary.
- You need to login before you can see them. Using this app, you just visit whereever this app is hosted or double-click the executable on your desktop.
- You need to have 51 megs to spare. This app takes 11 (less in a browser).
Why You Should Care
Like I said; extremely niche. That wasn’t the point, however. The goal was to set a challenge for myself, and learn in the process. A nice side-effect is some code I feel others can learn from.
Key takeaways:
- This is a pefect example of how to over-architect an application. This is a widget, not even an application, so the need for an Application Framework such as ARP was definately not needed and major overkill.
- Same code, 2 different runtime environments: Desktop and Web.
- Using a business delegate to handle all the “crap” involved with getting the business rules working.
- Using a business delegate to handle the security context. (Not sure if this was a good idea yet or not).
- How to get the new version of mProjector to handle Flash Player 8 filters plus transparency.
Digital Thorns in My Side
There were 2 things that really bothered me during and after development. The first, which I already mentioned, was allowing the business delegate to handle the security context. Basically, Flash Player running as a projector is not bound by the Flash Player security sandbox. When the Flash Player is not running in an executable, it is. The way I know is by checking for the existence of mProjector API’s. They are baked in when the mProjector exe file is made; stuck on global as static level objects with methods I reckon. If they aren’t there, you aren’t running in an mProjector created exe file, and thus are probably running as a SWF file, usually on the web in a web browser.
While I agree that the business delegate is the correct place to handle coverting the XML received from the server into a usable ActionScript class value object, I don’t necessarely agree it is the best place to handle security context. I DO agree that it certainly the easiest. Since he’s already making asyncronous calls to the server for specific data, why not just put it there? :: shrugs :: For me, the jury is out on that one.
The second was how I’ve allowed Commands to call a callback function. To me, you’re code that is calling a command usually wants:
- something to happen
- to know when it’s done
- to get the data from the operation if any
Getting something to happen is easy; that’s what Commands do. Chunks of code usually responsible for getting or modifiying data, whether that be from local classes, firing other Views to do things, or making server calls via a business delegate (if applicable).
To know when it’s done is accomplished by my CommandRegistry; you can specify a callback function that the Command calls when it’s completed. This is called whenever the Command feels like it. This could be immediately, or after the business delegate has returned a result or fault… or never if you so choose; it is optional after all.
That last part, however, has got me stumped; mainly because I haven’t really thought through how to solve it. How does your result function “know” what it is getting back? It doesn’t, and that sucks. ResultEvent has a property called “result”. This property is not cast on purpose; this allows anythng to be passed into a ResultEvent. That way, if you talk to PHP, Java, Perl, Ruby, ColdFusion, or who the heck ever, you can throw that result into a ResultEvent, and you’re business delegate will get it and know where to look for it. But it’s the business delegate’s job, if your Command decides to use one, to massage and/or convert that into something usable and pass it back to the Command to handle. The Command can then easily pass this back to the result function.
The problem is, how does the instance invoking the Command know what the Command returns? Cairngorm users would argue, “A Command doesn’t ‘return’ anything; merely sets data on the ModelLocator, and bindings fire, and everyone’s informed and happy.” Uh…ok… so do we now declare that all Commands return true or false in their result functions? That certainly brings some order and understanding here, but greatly limits the functionality that result handlers provide. Remember this is Flash, we don’t have bindings like Flex does. There are some binding classes, sure, but they aren’t implemented as thoroughly nor as transparently as they are in Flex. Thus, it’s typically easier to get a result function and handle View updates manually. To me, this is justified since Flash projects aren’t as large in scope so this is more realistic a scenario anyway. Besides, making other datatypes act like Array’s do via DataProvider where changing an array via the DataProvider API methods dispatches a modelChanged event isn’t that diffucult to do.
So yeah, you could do boolean return values, but that is limiting. How about Event objects like ActionScript 3 does? Flex Builder 2 will actually give you compile error if the event type your event handler defines is the incorrect type. So, if you register for a MouseEvent, but define this in your event handler function:
function onPressed ( event : KeyEvent )
Flex Builder 2 will throw a compiler error.
However, you don’t register for Command events, you fire them off, and register a callback. I’m finding it hard to find some strongly typed way of “knowing” what a Command returns in it’s result function.
Anyway, I really had fun over-doing this widget and having it work in 2 runtime contexts (desktop vs. web) and 2 security contexts (desktop vs. web). It uses my modified version of ARP. Hopefully you can learn something from the code!
*** Warning: Currently, the web app utlizes a PHP proxy script on my server to get around Flash Player’s security sandbox. My suggestion is to host the PHP script on your own server, assuming you deem it secure enough, or some other proxy, and point your ddo_server_status_config.xml config file to have the proxy point to your server. I have no problem with you using mine (if you do nothing or don’t know what I’m talking about, it does by default), but if mine goes down (meaning they ban my server’s IP or my host bitches about bandwidth), then you’ll be forced to use your own, someone elses, or the exe instead. ***
To utilize the exe, just double-click the “DDOServerStatus.exe”.
If you wish to host the DDO Server Status app on your own site, simply do the following:
- upload the “DDOServerStatus.swf” to your site
- upload the “ddo_server_status_config.xml” next to the SWF
- put this HTML code in your webpage, ensuring the 2 paths to the SWF are correct:
<embed src="DDOServerStatus.swf" quality="high" bgcolor="#ffffff" width="136" height="330" name="DDOServerStatus" align="middle" allowScriptAccess="sameDomain" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer"></embed>—
—
Dungeons & Dragons Online: Server Status – Download It | Source
-
What I Miss About Being Paid Salary
When I worked salary, one of things I liked, but didn’t realize at the time, was the ability to solve a problem no matter how long it took. Granted, when it got out of control, my manager and team would find ways to bring it under control, but bottom line I’d be pointed at a challenge, let go, and I’d update my superiors on my progress.
I have a high willpower; it’s the only way I’ve been able to compete in this industry. It serves me well in solving challenging problems because the obvious is not always obvious, and you are constantly challenging your assumptions, testing hypothesis, and following stringent logical workflows… or not, depends on my mood. Typically, you are supposed to rule out the most obvious & likely problems first in any debug session. For example, some example code you try doesn’t work. More than likely, it is faulty documentation vs. the actual Flash Player not working… unless you are using an alpha build of the Flash Player.
Those 2 paths of debugging above can lead to further steps, and other test cases that can drag on your morning. Other problems can drag on for days, even weeks. A lot of times, you can only spend small chunks of random time throughout the day, never really being able to focus exclusively on the bug. Sometimes it has a lower priority, and you merely put it in the back of your daily queue, in hopes that other development will spark a reason for why it is happening.
All those things and more can either be full force, or backburner type tasks. Bottom line, you are paid whether you fix it or not, and the time isn’t really a big deal vs. the resolution. Depending on scope, the point of no return is measured in days or weeks, not hours.
Getting paid hourly, however, changes the rules. I cannot go off for days at a time trying to solve a problem. I need to document what I am doing, minute by minute, always needing to be aware of what I am doing, how long it is taking me, and how long it’ll take to get to a resolution.
Those of you who have been in software development for any length of time know that if you knew how long it was going to take you to solve the problem, then you’d know what the problem was. Debugging, however, is about finding the problem. You can’t solve a problem until you’ve found it, and if it were that simple, then application development wouldn’t always be over budget.
The solution is to keep an accurate assessment of progress, well spoken hypothesis on what the problem(s) could be, and put it in the client’s lap to decide on if you should keep going, or focus on other tasks. Before, it was, "Jesse, solve this issue, and report back to me when you’ve found it. If you don’t find it by lunch, let me know. We’ll discuss and see if we can’t try a few more ideas."
Now, it’s kind of like that, but with a lot more documentation, self-awareness, and less emotional investment. I guess that last part is what really irks me. I can no longer dive in head first. As a contractor, I’m now constantly nagged by my own psyche to remember to keep track of my time of how long I’ve spent, and being able to clearly articulate where I am at with the bug at the drop of a hat.
-
Movement Mystique & Meetings are Bad for You
I go to pay for my sandwhich in Subway wearing my “wasd” shirt with shoulder length hair, and the cashier, a petite, older teen asks, “Are you a hacker?”.
I smile and reply, “I try.”
Apparently the console has a stranglehold on the gaming market vs. the pc if “wasd” isn’t widely known. The gender card is bs because when I spoke at a middle-school 3 years ago for career day, every girl in every class I spoke to raised their hand when I asked who played video games.
Also, my man Steven Sacks, the deep house DJ, pointed me to this article briefly describing a study showing that meetings are bad for your health. The article has a sarcastic feel, I don’t know the authenticity of the researchers, nor if this is an accurate portrayal of their research methodology, so much of it I question. Still, like most studies, while they usually result in a unified, “Duh!” from most of us, at least you have “scientific study & research” to point to now.