Software, Fitness, and Gaming – Jesse Warden

Blog

  • Diffing on a Mac Resolution

    I have everything I need on a Mac now after finally getting svnX to work, and thus justifying it’s existence (still doesn’t work with Google Code, though… must need more practice). Subversion client? Check.

    All that’s left is a diffing tool that is comparable to BeyondCompare for the PC. I hit Google, and read this blog entry as well as every single comment.

    Subclipse? Negative, Ghostrider.

    1. I do not work from my code base. SVN goes into 1 folder and my local copy into another. I then shuttle back and forth using BeyondCompare. Subclipse forces you to work in your checked out files. There are a lot of advantages to not do this.
    2. Diffing tool is a joke when you’ve used BeyondCompare.

    Guiffy? Nope.

    1. I have to know Regular Expressions to exclude things? Um… no. I’m too dumb to use that feature, or is that I’m not smart enough to take advantage of it?
    2. I only gave it 1 hour, and got frustrated. Unfair, but I’m a user. I’ve got another month with the trial, so I’ll definately give it a ton more tries.

    BBEdit? Haven’t tried it yet. I couldn’t find anything describing diff stuff in their docs, so didn’t bother. Someone know more?

    FileMerge? A C guy I respect swears by it. I didn’t like it. It doesn’t (as far as I could find) support comparing file structures. This is an EXTREMLY important feature for me. The diffs do that same thing the others do where they have the strechy line things… dude, just f’ing point to the difference lineary, and I’ll fix it, you don’t need to kick it Sportacus style with the arrows for me to clearly see where the difference is.

    Solution? Purchase CrossOver, use BeyondCompare. 2nd day in a row and I’m not looking back. It just works.

  • Flex Chronicles #23: Compiling Modules on a Mac & Code Gen

    Modules don’t extend Application, but rather Module, which is basically a Container. As such, you can’t “preview” modules in Flex Builder like you can Applications. You instead have to load them into a ModuleLoader. A ModuleLoader has to then be placed in at least an Application container. Therefore, you can’t really develop with Modules in Flex without using Ant. You can, but it sucks.

    Ant, the build automation tool that comes with Eclipse, allows you to define a bunch of XML tags that encapsulate a task. A task can “compile my module” and “compile my app” as well as “launch my app”. You then chain them together in an uber task like “compile my module, compile my app, launch my app”, all with 1 click. Dope.

    Although Ant comes with Eclipse, it doesn’t come all mxmlc friendly. The free Flex compiler, mxmlc, unfortunately is usually launched via the exec tag in Ant. While Ant is nice in that it comes with simple tags, thus making it easy to read and learn, anything complicated is extremely frustrating. Combined with compiler parameters, linked tasks and resource files, this spirals out of control pretty quickly. Not to a Java developer mind you, just me.

    Thankfully, Adobe has provided some Flex specific Ant tasks which you can get at the labs. Rad.

    They didn’t work for me. Got weird errors. Problem? I’m a PC user, not a Mac user. However, I take my Macbook with me on client visits to force myself to learn it. Nothing like trial by fire I say. Long winded way of saying that spaces in your directories cause weird problems. In this case, the compiler will spit out this error:

    [mxmlc] command line: Error: default arguments may not be interspersed with other options

    Which is totally off base of what the real problem is. Thankfully, Google pointed me here.

    While I like how Ant works out of the box, and requires no configuration on my part with regards to the Flex Ant tasks (copy a jar, reboot Eclipse, copy files, mod provided build script)… it doesn’t scale well with customizations. While the Java kids have moved onto Maven, I’ve had it with XML coding. While Ant is doing a pretty good job at code generating my Cairngorm event, command, delegate, callback, and test cases per use case, build wise it just isn’t “easy” to do builds the way I want to.

    For example, some of my past build scripts with Flashcom (Flash Media Server) projects have involved an Ant build launching a Zinc wrapper SWF that did advanced build tasks. Ant’s build.xml files are nice if I need to tweak a build script; I can do so right from Eclipse in a text editor whereas my SWF uber-builders have to be “recompiled in Flash, and then post-processed in Zinc”. Sounds complicated, but it’s not. Code JavaScript ‘esque code, compile, and I have a fully customized build.

    Anyway, I’m this close to just demanding the next developer who inherits my code base deal with the fact I’ve implemented Rake (Ruby’s version of Make) as the standard build environment, even if it’s not the best in working with Eclipse.

    Bottom line, if someone utilized that new Java 6 feature, and wrote a JavaScript based build library, it’d be the coolest thing on the planet.

    …well, next to Bruce Campbell of course.

  • How big are my Flex classes?

    Joe Berkovitz has an entry here about a Java class in the free Flex 2 SDK that exposes how big each of your compiled ActionScript classes are in a given SWF. When an ActionScript class is compiled, it goes through a series of steps to become bytecode, a smaller size, more machine friendly format called “abc”. So, your 6k ValueObject could become 1k, not including the additional LZW “ZIP” compression that the Flash Player has built in for it.

    For Flex Developers, this is valuable if you are trying to reduce the file size of your Flex app, usually in the case of a publicly accessible application. If 9 million people a day are accessing your SWF on 12 Akamai servers, it behooves you to make her as small as possible, even if money is no option. However, one of the biggest problems with modules, a feature in Flex 2.01 that allows you to separate parts of your application out into “dynamically loadable DLL’s”, is there really isn’t a straightforward way to understand what parts of your application could benefit from modules.

    For example, as a GUI developer, I can pretty easily look at a design comp, and identify which parts would benefit from being loaded on the fly, and which are fine to just keep in the main SWF given the file size and performance requirements. If file size is important, later forms I can “load later” via a module so the larger PNG graphics don’t get included in the initial download. The user doesn’t need to see that form immediately, so I won’t make them download it immediately. The same goes for classes that aren’t seen. The code that makes up the form, for example, can only be download when the graphics that make it up are downloaded as well. Both of these can be packaged up in a module, and loaded on the fly later.

    Regardless, that’s good foresight, but extremely subjective. I have no solid evidence of the classes size, including dependencies, just the PNG graphics size once I rip them out of the PSD /AI file. Furthermore, if the form has an initial transition, and it is choppy because the form has to load a lot of assets into memory when it downloads and then plays, the designer will give me hell. Thus, we are back to having very subjective decisions guide our choices of which classes / assets go into modules, and those who stay in the main SWF. Not a very good way to make software.

    Another example is, “He’s over 2000 lines long and the user barely ever hits this complicated form until the very end of this wizard… let’s invest time making this part a module because we ‘guess’ it’ll help.”

    Joe Berkovitz’s Apollo app should help change that. Using the Java class in tandem with a Flex Tree and WebKit HTML control, you can get a visual breakdown of how big each class AND package is in your code base. Joe wants to code some additional “smarts” into the code to proactively identify some key bloat areas that could be broken down into modules (if I read his entry correctly). Even if he doesn’t, just a Tree with file sizes like he shows on his blog is enough for me to make more informed architecture decisions.

    Send Joe cookies so he finishes this app.

  • Flash Player 8 Effects in Flash Lite 3?

    Alessandro posted a Flash Lite 3 video example shown at a financial meeting. Sharp-eyed Zeh wondered if he saw a motion blur. A lot of video codecs will compensate for fast-motion by blurring so you don’t get the hardcore pixelation from a non-keyframe, and all in all smaller file size. However, the phone ISN’T moving and since that appears to be some form of component with dynamic content in it, that means they couldn’t have done it by hand (say, using Photoshop or After Effects). I say it’s a motion blur. Good eye Zeh!

    If what we are observing is accurate, that means Flash Lite 3 will have the Flash Player 8 effects. Furthermore, that also means it’ll most likely have the new Garbage Collector that they put in Flash Player 8 with mark & sweep in addition to reference counting. That’ll help kill the unintentional circular references, and give us more reliable memory usage on an already constrained set of devices.

    That still leaves the new AVM and ActionScript 3. I made an effort, although not a huge one, to mention Flash Lite 3 around any Adobe employee at WebDU 2007 who had any association with alcohol. The general plan of attack is you start a conversation with them, start bitching about some of the design challenges you have with the current technology (in a positive way, not annoying) so they feel the need to satiate your concerns with hints at future technology solutions… say, new features in Flash Lite 3. Once you get that, you then go find another Adobe employee near alcohol, and do the same thing. The goal is corroboration. If you can get 2 unrelated employees hinting at a new feature, you can pretty much be sure… as sure as one can be anyway if you don’t work for Adobe and aren’t on any beta’s.

    Nothing. I got nothing. In fact, I think they were making with the local “take the piss out of Jesse” culture and screwing with me. Either that, or it was my approach. ::shrugs::

    If one were to levitate up to 30,000 ft, it seems to me all the engineering efforts around AS3 and the new AVM with focus on developers are going towards Flex 3 & Apollo. On the designer front, they are all going towards Photoshop, Flash, and Flash Lite since more designers are employed in the Flash & Flash Lite arena. Lame, I want both. Anyway, at least Moxie will hopefully address some of the designer / developer work flows as well as making Flex’ Design View a little more extensible. Wish I could say some more concrete things about Flash Lite 3. Video’s neat, but I STILL need to code those solutions. I’m sure the cliche response by now from experienced Flash Lite dev’s is, “No you don’t…”.