Software, Fitness, and Gaming – Jesse Warden

Blog

  • How to Pause a Flash Movie: Part Deux

    Found a better method than the PrintJob.send way thanks to Darron Schall. Going off of his suggestion to use ExternalInterface.call per this LiveDoc’s entry, I found it does the same thing as PrintJob.send. It will pause:

    • Animations
    • onEnterFrame
    • intervals

    However, sounds (streaming or event) don’t stop, don’t resume upon unpausing, and getTimer keeps on trucking. Additionally, streamed sounds keep animation in sync with them by dropping frames if the animation cannot keep up. Thus, those animations will appear to jerk upon unpausing if the sound has already played past a certain point. This is the same behavior you get with the PrintJob.send method.

    At least, in this case, you can customize the popup to be a JavaScript one with a label; that’s a lot better than a mysteriously appearing print dialogue when someone hits the pause button. You could use JavaScript’s prompt function instead.

    Both methods are modal, meaning the user cannot interact with the Flash movie while the dialogues are open.

    *** Warning: Loud Sound ***

    Pause Example – Alert | Prompt | Source (ZIP)

  • Please embed Flex in LiveCycle PDF’s

    I downloaded a sample that Mike Potter’s blog pointed me to, and started filling out the form. I have Acrobate Reader 7. I nearly laughed it was so pathetic.

    Easily fixed; allow Acrobat Reader to embed SWF’s as native pages, and I’ll show you forms done right… you know, like tabbing that actually visually shows you where you are, not having 3 annoying dialogues pop up in your face, etc.

    Anyone do LiveCycle for a living? Do they (LiveCycle customers) even have a clue what Flex is? Potential for growth?

  • Occasionaly Paid

    Occasionally Connected is a term used to describe the growing model in which technology users’ live. With the proliferation of gadgets to empower us to have mobile offices with have the capability of communicating and receiving information the world over, the connected & disconnected state are now disassociated with location, which itself isn’t always connected to being with.

    Back in the day (like 2002), I’d go to my desk upstairs in the cabin in the woods, fire up the computer, connect the modem, and be connected. I could use email, surf the web, and generally be productive.

    Today, I can do the same in my house, only, I’m always online. My DSL + Router ensures 2 desktops are always online, and my laptop and phone can always access my wireless inside and out of my house. Getting connected is analogous to turning on, and proximity is no longer a limiting factor (beyond my property). If I do extend the bounds of my house with my laptop, I need to go only 1000 yards before I run into the local coffee shop that has free wireless… and I live in a remote area. Atlanta city proper has a lot more hotspots.

    Additionally, the software has changed. Connected apps usually had pretty acceptable to atrocious handling of the connected to disconnected stage, as well as the return to connectivity. Outlook Express informed you that you were offline, but you could still read email. The worst would be some apps wouldn’t function, others would crash or lock up your system. Sometimes the act of re-connecting was a self-induced death sentence for the application.

    Nowadays, a lot of programs handle things extremely slick. Firefox will keep data in web forms if you hit the back button. Macromedia Central would physically change color and save data locally as a copy. Trillian has visual states indicating which services are working and in what connected state they are. The program itself will attempt to reconnect with no involvement from you (optional) and minimal interruption to your focus. Even iTunes will attempt to re-connect if your internet radio goes down, all without a window focus change.

    Get it done, don’t distract me, and do what you can without internet access. I love the progress I’m seeing across the board.

    There have also been discussions about the location of your data. In the case of my email, it’s on my machine since I use POP3, with the option to act like IMAP where copies are kept on the server.

    However, with the increase of web applications furthering productivity (or not), a lot more of our data is stored online, under different rules. For example, if Flickr ever goes down, so too do access to your pictures. And yes, Flick goes down a lot.

    Same for services. TypePad, SixApart’s online blogging solution is tied to the server. When the server goes down, or your internet connection, you cannot blog. Even so with the MoveableType version. I install on my server, but when my server goes down, I have to rely on Word or Notepad until my site comes back up.

    This too, will be solved, although, I think more slowly than the connection model has merely because more litigation is needed vs. clever coding. With concepts like Flash & Flex‘s local Shared Objects (Flash cookies), browser cookies, and other state-full clients with the ability to save data locally as well as server-backups, technically this is solvable in the near future somehow, someway.

    Exchange of data, too, has improved. Almost every blogging software I know supports importing of existing blogging information. MoveableType to WordPress, and a plethora of other options, making it easy to divorce your old solution, and try a new one without anything to lose but time. Time lost to trying out new things is usually not really cried about for geeks anyway.

    The point here is giving users control of their data. You can import and export your web browser bookmarks to make them portable or use them elsewhere. You can save documents in a variety of formats. You’re internet presence can work in multiple programs and on multiple devices.

    The point here is as the net becomes an extension of ourselves, it only feels natural if it’s in harmony with us. Ease of use, portability, reliability, and over all (a sense of) control. The more in-tune we are with the network, the more useful it is to us, and the more productive and content we can all be (in theory. I’d still rather have your machine lock up on you because I owned you in Quake 4).

    There is still one area, however, I see major problems with people becoming in tune with the network.

    Payment.

    My computer is always connected, providing a firm base. I have wireless to roam the house, and assorted hotspots to connect when I need. My phone allows email checking, and itself can provide internet to devices nearby. My programs are more and more capable of sharing data in languages each can understand, and understand well that nothing is lost in translation. Data location, integrity, and access is getting there in terms of all the web applications popping up.

    …but when you don’t pay, you’re screwed.

    To me, this is the most ignored area of user experience in technology. If you don’t pay, your trial runs out. You can sign up for cable service online, but can’t cancel it. When you leave an online game, the data you spent a year on has no guarantee of existing tomorrow after your account is cancelled. Google’s cache or archive.org have no guarantee that they’ll have the data you need, nor is in an acceptable and prompt to get format, let alone context (site was generated from MySQL by PHP, thus no HTML-cacheable content). If you’re late on your phone bill, you’re entire local network goes down (thankfully, programs are learning to compensate). You miss a power bill because of some online payment fluke that wasn’t your fault, and all juice is gone. Even Eifel can’t throw (and catch) an exception for that.

    And my lovely weekend experience. Apparently I received 5 emails saying my credit card had expired, and that I needed to update my hosting account. I didn’t receive the 5 emails, nor did I receive a phone call. And yes, my web hosting provider is capable of having an American, native English speaker utilizing the phone to call me because they did last year when blog spam was pummeling their server because of my blog. You’d think after 3+ years of a loyal customer which originally evangelized their service via an un-paid logo on his site would get at least a phone call.

    Nope. To add insult to injury, my name servers changed the same day.

    I make my living off of my online presence, as well as my ability to connect with individuals from around the world on a 24 hour basis, mainly through email. Some depend on my content being accessible to them, as well as me being accessible to them via email. I was made invisible to that world for 4 days solid because of $20.

    No program could re-connect my last website. Google’s cache, while surprisingly fast and thorough, still loses valuable context. While Outlook Express still worked, it was still handicapped beyond usage since my host cut me off from the online world. While I have money, I couldn’t make more by sending out invoices because my email was down.

    Thankfully, presence is not controlled by Mediatemple. I could connect with online associates via instant messaging, inform them of my situation, and keep tabs on the online world, more so as an observer vs. an active participant. If you want to play, you have to pay, and pay steadily with no lapses.

    Separate email accounts and separate email programs provided an alternate way to continue my day, but the dependence on a specific online projected persona prevented much from getting done.

    While one could hearken this to irresponsibility on my part, I will admit that I did not follow up with all pertinent accounts when I get my new card this new year. However, I stand firm that user experience can be improved via payment methods for services, not just taking care of keeping us connected and keeping our data integrity safe & portable. I’ve seen plenty of good examples where you can separate yourself form a service financially, so I know it can be done.

    How old is the phone again? 130 years-old? Surely it’s proven it’s usage in not just solving problems, but solving them via assertive usage as well, yes? If we’ve solved the user experience with application connectivity in less than a decade, we can definitely solve the payment contracts we users engage & disengage in as well.

  • Prototype Solutions

    Reading the Pragmatic Programmer on and off for the past few months. I have an extremely short attention span, so when I’m burnt out of coding, the History Channel, and the Legend of Dragoon all at the same time, that’s when I read. Fallen tree in my backyard, bills, sending invoices, laundry, and the rest are only done in dire circumstances.

    I haven’t gotten all the way through it, but I managed to hit the part about “Tracer Bullets”. They discuss the two traditional ways of developing (enterprise) software (as of 2000).

    The first is where you gather a few non-specific lists of requirements from the customer, document it to hell in the form of “business requirements”, sign off, code for years in a dark cave, bring all the modules together, fix the bugs enough to get a working build, and deliver to the customer. Naturally, there are tons of problems with this approach, but I see this repeated time and time again in larger companies.

    The second is their tracer bullet approach. You basically build a shell of the app you think will work, get enough of the skeleton working so you can compile, and show to the user to get feedback as well as understand any performance issues (if any). While slower on the uptake for the developer since you’re building the real framework, it’s quicker for the user & management to actually see progress. The user’s can more quickly give feedback, and you can more accurately see if you are “on target”, and where you should adjust accordingly, with real, already working code. You continue with the same code base you started and the user accepted the first initial build. Sounds a lot like Agile Development.

    The third is the prototype. Disposable code, written for the sheer point of proving, or disproving, theories. Will this design work? Will this algorithm scale?

    Prototypes are great to get a design in front of a customer with fake data to see if the wire frames/storyboards accurately depicted what the user wants without spending copious amounts of time implementing the GUI. This plays more of role in things like C or Java where GUI work is more time intensive than something like Director or Flash, which buys you more time to try more ideas, or further refine existing ones at a cheaper cost.

    The second is to test your algorithms. Whether that be in the same language (ActionScript) or you’re just using AS1 because it’s lighter weight and quick, like JavaScript just to do a proof of concept. Strict data typing, classes, and the like get in the way if getting something done quickly. They help you during debugging & maintenance, that’s why you use them. If you want something done, and done fast, using a loosely typed language frees you from unnecessary restraints to get a prototype done quickly.

    It can also be said that prototypes offer a low-risk entry point to software. If you spend 2 weeks of balls-to-the-wall development to get a prototype in front of a potential client, and it fails, you only lost 2 weeks vs. 3 months. If however your client wants tons of features for v1 and expects them to happen in another week, you’ll have a tough time explaining why it’ll take 3 months just to get to the point where you are now so you can then spend another month adding those features. Thankfully, that’s not my job… yet.

    Game development is another potential area which can benefit from prototypes since you have to be pretty much half-done to pitch an idea, even when applying for a license to an existing brand.

    Now, in my profession I do everything in the same environment and language. I code in Flash or Flex Builder, usually in AS2. ActionScript is flexible enough of a language to allow you to write both the quick stuff, and the more time consuming strict typing stuff. Apparently in other professions, you realize that you can spend 3 days writing your algorithm in something like Python vs. C, and save that much more time down the road. When comparing AS1 to AS3, I can understand why.

    Spending copious amounts of time writing:

    en override public function getName ( id : Number ) : String

    vs.

    function getName ( id )

    …or a 500 line app that you have no intentions of maintaining, debugging, nor putting into production. Not to mention the fact AS1 is case-insensitive if compiled in Flash Player 6 or below.

    I think a lot of my career was built on prototypes… at least, according to the Pragmatic Programmer.

    Yes, I’ve written software that was not a prototype, but I still think the majority of my work, even if not viewed as a prototype, was if using the above criteria. Now, hindsight is 20/20 (to the beholder anyway), this doesn’t mean me, my former teams, or any of the companies I’ve worked for could of done anything different at the time. It’s just an reflection I have finding commonalities with my experiences and the concepts in the book.

    Adobe (at the time Macromedia) once akin Central to having the aptitude for disposable apps. At the time, there were 2 specific applications for Central that had a warm reception for the most part. One was an application for conference information on MXDU 2004. The second was one for MAX.

    When you look at it from the 30,000ft. view, it makes sense. You code a minimalist back-end to get just enough working data, bust out a design, implement in Flash, code enough to get her working, and deploy for a hard deadline. Hard meaning, non-negotiable, non-changing. After the deployment date, the app has exceeded it’s usefulness, and thus its lifespan. At that point, it’s merely a point in history with which to use for reference in essays like this.

    It’s disposable. It’s a prototype.

    …but it’s also a solution. It worked, satisfied the goals of the project, solved the problems the software was created to solve, and was successful. There were no tracer bullets fired, business requirements were 1 page or less, consisting more of a contract-to-hire and days of furious coding.

    I’ve seen that same scenario played out over my technology tenure, except with non-hard deadlines, particularly with Flash projects. One of the reasons I transitioned from Director to Flash for my multimedia projects was because it was faster to get things done, and I could have my entire team work with me. It was RAD, rapid application development, to a point. Flash empowers you to get things done, and get them done quickly with a lower barrier of entry (unless you’re a server-side, anti-GUI/pro-AJAX Java developer, in which case when you wake up in a cold sweat, know that the timeline is out there… in the dark… waiting…).

    I’ve seen cases where documentation was done out of sheer CYA (cover yer arse) from past negative experiences. In the end, it didn’t help. All that mattered was how fast you coded, and how well she worked. If the user didn’t like it, you either re-coded, or spent long nights & mornings untangling spaghetti code to “friggin’ work!”.

    The point of a prototype is to challenge assumptions, identify risk(s), and confirm good technical decisions. The point is not to deliver software because of the results of the above described process.

    From a business retrospect, I don’t think it’s sad. If you look at a lot of some of the older projects that have been done with Flash, from movie websites, games, e-learning, and modules into larger applications… they were launched, the customer was happy, and people got paid. Flash, for those who were in the know, got a great reputation. I don’t think all were developed as prototypes by the Pragmatic Programmer’s definition, but I know many that were, and the untrained eye wouldn’t know the difference on most (aka, the user).

    Still, I think it de-values good software in a way. I’ve made the comment copious amount of times about how, “I never ‘maintain’ Flash projects I’ve created. Preposterous, just re-write!”. While true, I’ve also found re-writing easy and fast, mainly from the tool & language, but also from a development perspective; developers like to create, most don’t like to maintain, and we all always hate our work and want to do it over, better the next time.

    That attitude has actually served me well, but only because I’ve been mainly in the service industry vs. the product industry. Meaning, every job I get, full time or contract, is always something new for a new client rather than a software product I create on my own terms and maintain.

    The mere fact I know OOP, MVC, ARP/Cairngorm, and other design patterns, while having everything to do with wanting to do things “better”, has resulted in usually larger scope prototypes rather than converting me to product work where such things are more applicable. I am merely more adept at handling & reacting positively to scope creep. Granted, a lot of service work is to create enterprise solutions for large customers which have long life spans… but I’d argue those are products. Still, it can go both ways. You can use Cairngorm in a Flex prototype as well as in a finished product.

    Is this bad? Do customers really know they are getting prototypes? Do they care?

    For most projects, I’d say no. Working software is working software. Given the challenges, that right there is success. A lot of the smaller scale Flash projects I’ve seen or done aren’t usually maintained, or changed a whole lot later in life. This could mean a lot of things, like they got it right the first time, the goals need to be hit one time, or there really isn’t room to grow (room meaning budget), etc.

    Do customers care? Don’t think so. I do think however clients I work for do. 3 months up front costs you less after the fact vs. 2 weeks. The project will still take 3 months no matter what resources you throw at it. If you want it done faster, you have 2 options:
    – create a prototype in a short timeframe knowing that the cost of changes & maintenance will be astronomical in the time they take post-deadline. Therefore, you’re better off coding from scratch after you hit the deadline. (See the pattern?)
    – hire some serious bad-asses who can create prototype code, using existing portable classes from their repertoire, and pass it off as a product vs. a prototype. This’ll cost you more bling as well.

    So, if customers are users, no. If customers are clients you are coding for, yes.

    I haven’t gotten to the chapter of “Good Enough Software”, so maybe that will provide more insight. I will say, though, that the only reason I’ve been able to survive this long is because of Flash & Flex’ flexibility combined with my learned skills to manage scope creep. If I were trying to do the same career over, except in something lower level like Java, I think I’d kill myself. Not on purpose, mind you, just because of the stress my body would just shut down. Object.prototype, MovieClips, and a portable runtime (Flash Player) have gotten me out of more jams under insane timelines.

    If I ever start a company, I’ll clearly articulate the difference between a prototype and a product to my customers since I still feel it is not within an engineer’s decision jurisdiction to make the call on what is more appropriate for a project; prototype of non. Sometimes deadlines are make or break, non-negotiable, failure is not an option endeavors. In that case, there is no question, only action.

    The prototype is cheaper and faster to build, and time has shown prototypes can function quite well in deployment. The trade-off is they don’t scale (sometimes), and the change & feature addition cost is extremely expensive.

    A product on the other hand takes more time to build, and time has shown that visually & functionally it nigh impossible to tell the difference between a prototype and product to non-developers; if it works, it works. The gain is more scaleable code, and shorter timelines to make changes & add features.

    After reading Web Development 2.0 from Web-2.0-Propaganda-Central, it seems like a combination of the above techniques is needed to be successful in the ASP model; software as a service.