Implementing a stand-in "loading" image in javascript

First of all Happy Bike to Work day (BTW DAY)!

This is something like my 12th BTW day and I love seeing the masses of bicyclists out on the road especially on this day.

Now on to the subject of this post...

This had me a bit flummoxed, until I nailed down the magic way to set this up. Basically what I wanted to be able to was insert a stock image in place of a slower loading image. This slower loading (well, technically stream) ends up taking seconds to bring up after the page has finished rendering.

What was happening without this was I was staring a big empty rectangle after loading of the page, and thought it would be much much nicer to put in a pretty, albeit temporary, image in place.

The solution involves setting two image tags in the same div section. One visible and one hidden. Something like this:

<div id='stream_temp' style='visibility:visible;'>
  <img height=450 width=600 src='img/camera.jpg' alt='videoFull' border='4' >
  </img>
</div>

<div id='stream' style='visibility:hidden;display:none;'>
  <img onload='displayStream()' height=450 width=600 
    src='my_stream&scrH=450&scrW=600'
    alt='videoFull' border='4' ></img>
</div>

Generating a random key

I want to keep this little block of code around as it might just come in handy in the future, not that it's terribly complex.

The key generator relies on /dev/urandom to help generate a random key. There's another file on the system call /dev/random. The difference between these two is that the command to open and read from /dev/random will block until enough system entropy has occurred on the system, whereas a call to open /dev/urandom will immediately succeed regardless of the entropy on the system. Meaning your key may not be secure at the point the value is read.

This should only really be of concern if the key is being generated somewhere close in time during the boot process.

Real live plotting in your browser

Here's how to generate nice and pretty live plots in your browser. Even turns out to not be too much of a hassle (by relying on the correct library that is). First you need to grab the following javascript files from here.

And reference the relevant plotting support libraries in the html code (as below):

<script type="text/javascript" language="javascript" src="js/jquery-1.2.3.js">
</script>
<script type="text/javascript" language="javascript" src="js/jquery.flot.js">
</script>

Then set up the location you want the plot to appear on the page via a div section:

<span style="padding:0px;"><div id="plotter" align="left">
</div></span>

VT100 in your browser

This is pretty cool. I was searching for this and guess what? It's possible to bring together an unholy marriage between the browser and the command line interface. It's actually so uncool that it's cool.

And it works pretty well too...

There's a VT100 emulator written in javascript (shellinabox), that is fairly well developed. There's even an implementation you can play with just to kick the tires a bit so to speak. It's even well developed enough that it seems completely usable with some limitations. Performance ain't too bad either. The primary limitation is obviously the delay in the request/response (or latency).

This implementation works by running a parallel shell process on the server and sending keystroke by keystroke back to the server for interpretation. There's some performance penalty with this approach, but it does promise to be a faithful representation of a linux cli session.

On the other hand I've had a chance to subvert this library even more by wiring it up to the Vyatta REST API--the nice thing about this is that commands can be sent when completed (thereby avoiding the keystoke by keystroke roundtrip). And guess what? It works pretty well too. Very nicely.

Now with this your imagination can run wild with the possibilities....

Woo-hoo! Maybe an upcoming re-release of the hp-15c?

I'm not usually into rumor mongering and the like, but there's a tantalizing tidbit just released here.

Set your alarm for June.


UPDATE (6/9/11):

Just saw that a supposedly email from the *inside* stated that the RUMORED hp15c won't be released on January 2012. In order to align with the 30th anniversary of the original release.


Hold tight.

A place in my heart for Reverse Polish Notation

No explanation really, but I'm still fascinated by the old RPN line of HP calculators. There's a bit of joy every time I find a use for one--which these days mostly consists of helping with my kids homework. And it's as much about the hardware as the software--a real RPN calculator beats any emulated alternative any day. Handsdown. And I guess that's why I throw an old HP-12c in with my gear each morning.

My first handheld was the HP-25c. To me that was my pda. Through the years I've managed to misplace about a half-dozen models along the way (always upgrading to the newer model).

There's a great site that still covers technical details in minutia (hp-museum) with a pretty active forum. And it's a must visit site if you are considering collecting these relics.

I now have the following tucked away (an hp 16c, 32s, 42s, 41c, and 12c).

Here's to the hope that HP would someday redo the HP-15c scientific (sign the petition here).

Load-Balancing network traffic when it gets hot in Winnemucca (i.e. User defined load balancing)

OK--a tad bit facetious. But I just want to make a point that given a new hook in the Vyatta wan load balancing feature it's now possible for users to define custom health-checks. Before going further this post does assume that the user has some familiarity with the Vyatta router and configuration.

This new "knob" allows for user defined interface health tests. In the past there has been icmp echo support (i.e. ping), and more recently a time to live (ttl) expired test--both of which are supported directly via the implementation in the feature. And this got me thinking a while back that perhaps load balancing based on other criteria could be even more useful (i.e. user-defined criteria). This other criteria could be defined by the deployment (i.e. within a virtualized environment), or other network data or statistics (i.e. flows and rate).

What has now been added to the interface is the ability for the user to now define their own test target (or health-test) script. This means that you can define the success/failure criteria for each outbound interface. A few examples of the types of tests that can be performed are:

- test whether an http server is reachable
- disable interface after 6 pm
- enable additional interfaces based on traffic load
- disable interface based on virtualized host cpu loading