agitcraft

Yet another edition of “What am I working on?”

This time around I’m actually trying to design an experiment.  A real experiment. I think. Allow me to explain.

The Example

Example 1

First of all, let’s call this what it is: a cropped selection from the wonderful “The Joy of Life” by the also wonderful Henri Matisse, duplicated side by side three times. Here’s what you may not have taken note of: Each of the images above was originally compressed at a different “quality” level according to Photoshop’s “Save for Web” feature. The cell on far right is has a quality of 100 (the maximum), the cell in the middle is 50, and the cell no the left is 0 (minimum).

The Explanation

At this size it is probably very hard to tell, but when you look at the images themselves it’s another story.

Quality of 100

The above is the same clip  (not scaled) presented at 100 percent quality.

Quality of 0

Here’s the same image presented at 0 percent quality. It should be easy to see the difference. The lower quality image (which has a higher compression and therefore a smaller file size) is noticeably grainy, muddy, and washed out.

Clearly the lower quality image would be unacceptable for use in any real project, but what about this one?

Quality of 50

I would feel fairly comfortable using the above in a project. We may even be able to reduce the quality even further and still end up with something acceptable.

Why would we want to do that?

The Problem

As I see it, the problem is that as developers we have two competing interests at play here:

1. Our work needs to look good. If we’re using images, this means that we must keep them to a certain standard of quality.
2. Our work needs to arrive fast. That is, we need to minimize the size of our projects to guarantee that when people consume them they don’t get bored waiting for them to load or display and go away.

The tension between these demands has been around for as long as people have been doing work online.

We may have preconceptions about how to best balance these demands (“I just export at the default”), but perhaps we can find an answer.

Perhaps we can figure out the optimal compression level for an image according to the needs of both file size and image quality.

The Project

I’m working on a web application right now that will attempt to discover that very thing. It’s evolving into the form of what I hope will be a formal experimental study.

I’m building it with the MultiCore edition of PureMVC. I’m using the wonderful Pipes and AsyncCommand utilities. Those are my shout outs.

I’ll announce it when it comes out. I expect to be done with it whenever.

Also, because Technorati is a hater, here’s a token: Z3A58QAU6DU6

Lately I’ve been familiarizing myself with the MultiCore edition of PureMVC in the hopes of doing some larger, more modular applications. I decided my first MultiCore project (my learning project, as it were) would be a very large application I was tasked with developing at work. Furthermore, I decided that the best way to handle communication among the various cores of my application would be to use the heavily promoted pipes utility available alongside the MultiCore class files.

The application is largely built (I’ll let you know when it goes live), and I have some comments to make regarding the use of both the MultiCore edition of PureMVC and the pipes utility.

• The MultiCore edition of PureMVC is very easy to use in place of the Standard edition. In fact, whether you intend to have multiple cores or not, you may as well just use the MultiCore edition. It contains all the functionality of the Standard edition.
• Attention to naming conventions is key when working with multiple cores. Your file system in a medium sized application will become intimidating and unnavigable faster than you think if you don’t make especially sure to distinguish one module from another.
• It is equally important to pay attention to the values of your notification/message constants.
• Though the pipes utility touts its ability to easily be added on top of an existing project, this is only half true.

I should elaborate on the final bullet above. While it was relatively easy to allow the core of my application to send messages to modules, it was not quite as simple getting modules to correctly communicate back to the core. I encountered Pipe errors for which, as far as I could tell at the time, there was no obvious reference.

If you find yourself working with PureMVC MultiCore and the pipes utility, you might consider some of the following references, which I found useful while developing my application:

1. Understanding PureMVC Pipes by Joshua Ostrom: This tutorial is referenced everywhere as a good starting point for understanding the pipes utility with regards to PureMVC MultiCore. There are some good conceptual diagrams here and a few meager code samples.
2. A basic PureMVC MultiCore AS3 example using Pipes Utility and Modules by Jens Krause: The “HelloPipes” project files provided here were essential to helping me understand where to place my pipes code and how to structure it. This was really instrumental.
3. Unit Tests – AS3/Pipes at PureMVC.org: The unit tests were recommended in most forums I visited. There are plenty of real-use code samples here to get you started.
4. Pipes API Documentation: Anytime I work with new code I always start with the API Docs. There’s no better way to familiarize yourself with the code you’ll be using as you try to learn something new.

Hopefully these resources will help you as well. I look forward to showing off the finished project once it’s ready to go live.

I’m pleased to formally announce the relaunch of my portfolio at www.agitcraft.com. It’s been a long,  winding, mostly poorly organized effort on my part consisting of numerous missteps and restarts. I’ve technically been working on this iteration of the site for about 4 months (from scratch), although I’ve been grinding away at redesign efforts both with this domain and with my previous portfolio at altpixel.net for well over two years now. To give you a vague idea of how long this has been brewing, the svn I’ve been working out of is currently in revision 381 after going through at least 4 branches, and I’m the only person developing this.

I’d also like to take this opportunity to give credit where credit is due:

• Jack Doyle for the greensock tweening platform (which makes all the animation in the site possible), without which I’m sure I would have gone crazy long ago.
• The entire Papervision3d team for their excellent 3D package, which powers the 3D “solar system” motif that I use to display my interface.
• The team of developers who’ve thus far worked on as3syndicationlib. There were a couple issues I ran into, but they were minor in the long run and they certainly don’t take away from the fact that I was able to parse and consolidate 5 feeds in real time with only a few lines of code. Awesome!
• The developers of PureMVC, for making a framework that has literally changed the way that I work on large projects and made my site possible.
• Matt McInerny at the League of Movable Type for providing the fantastic “Raleway” typeface I’m using both in my logo and for section headers.
• An anonymous sound fx provider at flashkit.com for providing the ominous intro tune that plays when the site loads. I say anonymous because I was inattentive when I grabbed the audio and forgot to take note of the name/location of the file I snagged. I dug around today but could not, for the life of me, find the file on there. If anybody recognizes it let me know and I’ll give a proper shout out.

The wealth of libraries and tools freely available is part of what makes Flash such an exciting platform to develop for. I certainly could not have completed a project of this scale without them.

Anyway, if you like the site let other people see it. If you have problems with it let me know. I’m hoping this remains a growing work rather than a one-off showpiece.

For well over a year now, I’ve been engaged in the process of moving and redesigning my professional portfolio. The current (a term I use loosely…) version is over 3 years old, and it’s sitting at a domain I don’t really use anymore. I initially began work on a relaunch almost immediately after my portfolio landed me a permanent job, but over the years I’ve been indecisive, full of excuses, and just generally unable to commit to any planned redesign.

I’m sure you know the cycle: You come up with a great design concept, plan about 80% of it, and jump excitedly into development. You make rapid progress initially, but as you delve deeper into the project you come across roadblocks and development stalls. After hammering away for weeks at a time on bugs that seem to multiply faster than you can fix them, you eventually come to consider the project too flawed to complete and scrap it.

Where do these flaws come from? In my case the culprits are poor planning, over-ambitious development goals, and lack of a consistent process for developing large scale applications.

What I once considered the “Redesign Cycle,” I will now be calling the “No-Design Cycle,” as the use of the prefix “re-” vaguely implies that eventually some new design is produced and launched.

This post, however, is not just about my failure to produce a new portfolio in several years, or about my enthusiasm for the current draft I’m working on. It’s about what, thus far, is proving an effective solution to this terrible problem. It’s called PureMVC. Perhaps you’ve heard of it?

The claim made by proponents of PureMVC is that it allows you to program “at the speed of thought.” Outrageous, right? After picking the framework up several weeks ago and developing with it in the time since, I can mostly agree.

If you’d like to start working in PureMVC, you can download the AS3 port, check out the full API documentation, and follow the tutorial I used to get started learning the framework, courtesy of Ahmed Nuaman.