So you want all the advantages of logging to the console without all the headaches of IE throwing errors if you happen to forget to remove them? Easy. Override the console object and replace whatever methods being used with placeholders. If you want to debug to console, just add “?debug” to the url.

// cancel console unless “debug” exists in the url query string
console_debug = window.location.search.indexOf(“debug”)>=0 ? true : false;
if (!(console_debug)){
console = {};
console.log = function(){};
console.error = function(){};
}

Wow, I’m impressed with PhoneGap. Converting Qwikstant from a mobile un-hostile website to an Android app took a couple days. A couple days. That’s with absolutely no phonegap experience.. Granted I’m no fan of eclipse, but I can understand the decision to focus on one editor. Anyways, if you want to give the Android version a shot, just search “qwikstant” out in the market.

After a last minute name change (previously watchinstantaneo.us), Qwikstant is finally up and running. Qwikstant is an attempt to make Netflix Watch Instant searching faster and easier. Using advanced filtering tools similar to the Drink Maestro, you can filter by rating, genre, format, and more. I’m still working out some kinks, but it’s 100% functional on the desktop – android and iphone testing to come. Give it a try..

.. and while I appreciate the option for 2-step verification, I’d even more appreciate the option to stop from being continually prompted about it.

Over the past year, I’ve been busy at work and haven’t had much time to focus on personal web projects. During that time performance on my VPS gradually eroded as I added a few domains and generally ignored system administration. Given none of them have a whole lot of traffic, or pay the bills for that matter, I was okay with dismissing the upkeep. In any case, over the past couple months it started to become unbearable. I ended up rebuilding the server from scratch and the result has been more than satisfying, on the near order of magnitude level of response speed. Here’s how I did it (and so can you!).

First off, I kept the software running on the server to a minimum. This may sound obvious, but during the first build I’d overestimated the headroom I had in terms of CPU and IO. For example, why not run a mail server? Of course on Linux, a mail server is no simple matter – you got your Sendmail, Dovecot, Spam Assassin, MySQL or BerkleyDB. All these processes add up to a giant leech on system resources, just don’t do it. Set an MX record to a third party mail service and save yourself the trouble. Only install what you need. Again it may sound obvious, but you will be tempted at some point to disobey this best practice.

Secondly, if you’re using Apache, be smart about it. I had been using mod_wsgi in embedded mode, which is fine if you’re dealing with a fair amount of RAM. However, as the number of virtual hosts grew, the performance decreased – and not in a manner consistent with traffic. The rebuild utilizes one WSGIDaemonProcess/WSGIProcessGroup, which reduced the memory footprint of Apache quite a bit. Secondly, I’ve set up an nginx front end to proxy Apache/mod_wsgi as well as serve static content without any need to hit the Apache machinery for requests 9 out of 10 times. Additionally, proxying https through nginx seems to have helped, and is dead simple to configure. Remember that when running an nginx proxy, you will not need to gzip/expire/etc. twice – you can shut those features off in Apache and just let nginx handle it.

I initially built my VPS as 64bit. That way I can scale up to a larger VPS easily, I thought. Stupid. Unless you have more than 4 gigs of memory or an application that truly benefits from 64bit, just use 32bit and bank yourself some extra headroom.. Lets face it, if you need to scale up to more memory, that’s a happy problem which will only take one day to solve..

Beware of crons, especially ones that expand into cpu/memory and stick around for a few minutes at a time or that run frequently. I set each and every cron to use ionice which sets the process to a specified priority. Adding “ionice -c 3? prior to the script will set it to low priority. This may not be desirable in all cases, but should be the default unless a higher priority is what you really need.

5 */2 * * * ionice -c 3 /usr/bin/python /path/to/cron.py

In Django, I’m not going to touch on caching – my old build was caching fine so it wasn’t an issue. If your not caching (cacheable) pages, you’re going to want to look at that. What I did do was audit my indexed fields. When I had initially built out the server, some of my databases were much smaller than they are presently. With a small database, it’s easy to overlook indexing fields. Basically, what you want to do is look at all your queries and determine what you are looking results up off of. The big offenders tend to be DateTimeFields and SlugFields. In the field definition, just pop a “db_index=True” in and rebuild, then load the fixture back into the table. If the table is too big to work with a fixture, simply manage.py sqlreset the app, copy out the indexes and paste them in via the dbshell.

Just to give you an idea of what these changes applied to, my VPS was running 8 small sites (+6 https VitualHost clones).

I’ve just uploaded my android cocktail app, aka Drink  Maestro, to the Android Marketplace – If you’d like to give it a test drive on your Android phone, just search the marketplace for “Drink Maestro”, there’s a free version available. Cheers!

After a number of weeks hacking away at a mobile port of drink maestro in anticipation of the Air for Android release, I’ve learned a few lessons regarding flash performance on mobile that are worth sharing.

lesson #1: alpha is bad news

If you’re like me, you may use alpha to transition from one screen to the next, or to introduce new elements to the stage.  I’ve never encountered much of an issue on the desktop with using alpha, even going back 10 years. On mobile flash, however, use of alpha will kill the framerate cold. It’s best just the avoid alpha completely if you can, and find a different way altogether.

lesson #2: GPU acceleration may not help matters

GPU acceleration is not a silver bullet, and in my case actually ended up significantly reducing the application’s frame rate. I was under the assumption I could tune the code up in CPU default/auto rendering, switch on GPU rendering and expect a boost. This was not a safe assumption. After researching a bit, it’s clear that GPU rendering is fantastic for compositing bitmaps, but that is about as far as it goes. At the very least, try both rendering options with an fps counter in place for validation of the better option for your application. EDIT: The default (auto) rendering is some form of black box that may delegate some tasks to the GPU, I’d assumed the default was CPU.

lesson #3: defer some rendering on user input if response time is lagging

On an event such as a mouse click, there’s a lot you can do on a desktop without the interface showing any sign of slowing down. On a mobile device, if you try to do anything too complex, the application’s response time is going to drop through the floor. When a user taps the screen, it’s important to give them a sign that the input was captured, quickly. The easiest way I’ve found to manage this is to split the rendering, painting something to the screen to signal the user the tap/click was captured, and deferring some of  the render with a timer (therefore picking it up on the next frame). While this may create an html-like feel as the visual elements load over two frames, the user isn’t going to be left confused and frustrated.

lesson #4: background process any cpu intensive rendering

Drink maestro had a list of cocktails 175 entries long that need to be rendered. On the desktop this would render in the blink of an eye, on mobile it takes a second or two. Such an operation needs to build a rendering queue and divide the processing across many enter frame events, otherwise the interface will freeze until the processing is complete. This can be done by capturing time, and exiting a render-queued while loop after a set number of milliseconds has passed. Google “pseudo-threading” for more information.

lesson #5: use bitmap data when tweening

Tweening even mildly complex vector data can slow the frame rate to unacceptable levels. In this case, acceptable performance can be attained by drawing a clip to bitmap (BitmapData.draw()) and swapping the bitmap in place of the vector before tweening it. If you clip contains interactive elements, just swap the clip back when the tween completes (assuming it can deactivate during movement). “cacheAsBitmap” may also work here, but I’ve become a little superstitious of its use lately having seen some memory consumption weirdness – bitmapdata gives the the ability to explicitly dispose() of the data when you’re finished.

lesson #6: the height and width properties can be a bottleneck

Again, not something you’d worry about on the desktop – but getting the height and width of a complex clip is not instantaneous. The getter needs to actually look at the contents and recalculate on every reference. If you use width and height values of any element more than once in a function, put it into a variable so that the getters aren’t getting fired on every reference. On significantly complex clips, you may even want to store the values and only update when you know the clip has been altered. Cache invalidation can be a real pain in the butt, so before going that far – trace some timings and validate that height and width references are the source of a slowdown.

lesson #7: develop on the device

As you work through any mobile development with flash, your best bet is to develop on an actual mobile device. If you develop on the device you’re targeting, performance issues should be obvious the moment you test your code. I ended up in the unenviable position of porting from the desktop to mobile – it was definitely the wrong direction to be going, it would be far easier to port mobile to the desktop.

There’s certainly more I could add, but these nuggets of information are at the top of my list. I should note that optimizing through caching, background processing, bitmap swapping, etc.. is not going to make life easier. Quite the contrary, but if responsiveness and/or frame rate are not at the levels you’d like, the tips above should help.

Adobe has posted their own set of guidelines for optimizing for mobile here.

Over the past 3 months, I’ve been furiously chipping away at drink maestro, a cocktail menu application built using a flash front end and backed with django. It is finally live.

I was digging through some old development and came across some flash slitscan experiments from ages ago. Slitscan is a special effects process of exposing film while moving the negative (or exposure) in a controlled manner, if you’ve seen a few early 80′s movies I can guarantee you’ve seen used it in credits or a special effects sequence. I’m surprised the technique hasn’t been utilized more within flash game development. In terms of a flash timeline, it is very easy to create – on one layer a graphic is either tweened or remains stationary while a layer mask (the slit) is tweened over it. The results are some really cool perspective tricks. The main constraint within flash is that creating the “exposure” requires many frames – and in interactive flash there’s not enough muscle to render a series of exposures in real time (e.g. 20 slit renders per exposure @ 20fps is like running 400 fps, at least using frame based rendering). What you can do with flash is present the actual exposure process, and with a bit of polish make some really neat effects. With pixel level control of bitmaps now available in AS3, there must be some possibility of overcoming the frame based rendering limitation using advanced filtering algorithms – though I wouldn’t say I’ll be experimenting with those any time soon..

Note: source fla files are experimental and way out of date (AS1 from many, many years ago).

“warp” source fla
“text effect” source fla

I’ve recently been working on an image viewer to display local restaurant menus. I looked around for an open source flash image viewer to modify for the development and came up empty handed… The flash community is a little odd in terms of open source. There’s a lot of components out there for sale/license without an open source parallel. This seems very odd after running with the python and jquery crowd where sharing code is a cultural norm. It is, of course, not all that  way with flash – the game developers and graphics tweakers are very active in releasing code, there are a number of fantastic 2d/3d and physics libraries which are extremely impressive. Hopefully the culture will shift with them.

In any case, with the development stable it seems only right to open it up some code for the next developer. I’ve profited immensely over the years from open source, and it feels good to give back – even if with just a tiny contribution as a zoomable image viewer. Take it, modify it, do whatever you need to do to make it work for you.

The source is available at google code, and I hope to have some documentation up before the week is out. In the mean time, here’s a simple example.

keenerview.swf?image_url=[uri or url with cross-domain privileges]

Apologies to the squeamish for the anatomy page, it was the first interesting public domain image I came across.