Yeah, that’d be my fault. Sorry.

See, I’ve been resisting a major change on my site for years. I start on a design, moving a new direction and quickly back-peddle on it and go with what’s typical, expected. However, by refusing to move posts and move on to what I want, I’m quickly dissatisfied with my design and build a *new* one that’s the same old site with new graphics.

This design changes this. But in the mean time, lots of posts will be lost in the never-never until I get them moved to their new home, and some redirection-logic built — and I’m not sure how I’m going to handle that little bit of work.

So, in the meantime, some things might be missing while I figure out how to implement them. Again, I’m really sorry. If there is an article or piece you need, hit me up on twitter ( @aut0poietic ). I’ll either make the article available elsewhere, send it to ya in email, or direct you to the materials you were looking for.

And, uh, let me know what you think of the design.

So I decided to try to implement one of my older demonstrations of Dijkstra’s Algorithm in JavaScript, but one demo using Canvas to render the interaction, and one demo using divs, and CSS. I personally like Dijkstra’s because of how useful it is and because it’s one of those algorithms I’d heard about over and over, but no one could show me the code in action.

Up front: I’d like to point out that the code is not 100% efficient. Clarity was the goal, and I have to admit that the canvas example could likely be optimized ( and, cleaned up in general ) quite a bit. Heck, If I were doing this in any other language I’d be using multi-dimensional arrays and skip the whole string indexes, but MDArrays make me nervous in JS ( fodder for a future experiment, maybe ). That said I won’t get my feelings hurt if you show me how it could be better — Just don’t get your feelings hurt if I say “but that’s not as clear as my example.”

For some background, Dijkstra’s Algorithm is a variant of the well-know A* ( a star ) algorithm. A* is used to find the most efficient path between two objects on a map and can be modified to consider things like terrain, enemy line of site, etc.

Dijkstra’s uses similar logic to find all possible paths from a current position given a movement-per-duration. In plan english, if a person can move 10 feet in one “turn,” Dijkstra’s can tell you everywhere it’s possible for that person to move during that term. If you’ve played Disgaea, Fire Emblem or any other turn-based tactical game, you get the idea of how this works.

The above simulation creates 400 span tags styled to create a grid, with some tiles having a higher “Terrain” cost — they’re harder to walk over. If you click the blue square in the center — the character ( I was too lazy to create little stick-figure art ). The code will calculate the area the character can move over the terrain. If you pull up your JavaScript console, you can see the amount of time it took to perform the calculation and render the grid.

I rebuilt this demo twice before I was happy with the way it ran. The first time, I used jQuery to create and reference elements — and paid a high price: Render time of 72 – 86ms per map. That’s astoundingly high, but fairly obvious. I removed jQuery and found another opportunity for optimizing: my implementation used the DOM to store the cost and terrain values in attributes of each span.

This final version uses an array for all grid data, divorcing the implementation from rendering and allowing us to use the same function (“showMovement( )”) in both the HTML and Canvas versions. So the only difference in performance will be the rendering.

As stated above, I literally copied and pasted the showMovement( ) and getAdjcent methods and all the properties from the previous demo and pasted them into this second demo – the only additions were the X & Y values in the data objects and the canvas rendering. Early on, I added a simple layered design to the demo by pre-rendering the map ( grid lines and terrain ) into a canvas stored in memory ( never added to the DOM ) so I wouldn’t have to re-render the grid every time — hey, HTML didn’t have to either, why should canvas be so hobbled.

The results were inconclusive. In my non-scientific testing, the canvas version ran about 1-3ms faster on average, but this is not nearly enough to write home about. Even worse, the terrain map is random, making accurate comparisons difficult ( if not impossible ). However, my guess is that the canvas buffering technique would quickly become significantly faster if we were using complex graphics — like a real terrain map with alpha’d overlays for movement as well as alpha’d characters. I believe the when it came to rendering multiple images and applying effects to those images to each span multiple times, the canvas’ pre-rendered map would be a big boost in performance.

The irony ( to this old Actionscripter anyway ) is that my extremely inefficient ActionScript version of this same simulation runs in between 1-3ms in a larger field. And when I say inefficient, I mean “I used a Flex DataGrid Object and the display list for data storage.” Yeah, pathetic code, but really shows off Flash’s speed. JS, for all it’s openness, can’t touch it.

Like almost everything I do, the source is here for the playing with. If you come up with some modifications you’re proud of, share em over on http://jsbin.com/ so we can all play.

I also learned that you need to embrace the corrugation on a project like this. Don’t half or miter cut the cardboard in any way to assist in folding. Instead, us one of your metal rulers and crease the cardboard along an existing channel in the corrugation and fold into that channel. This has become very important as I’ve made progress.

But for now, I’ve got the first two U sections of the first shelf built. This is the true prototype and I’m going to spend a few minutes creating the charts for what I’m doing, no so much to show anyone reading ( though I want to do that too ) but to validate the plan I have in my head with some actual geometry, if only on the computer.

The idea is to create two interlocking “U” shapes, each out of two thinner, offset U Shapes. It’s hard to describe, but the geometry works a little something like this:

This structure forms the core of the shelf. It’s important to note that the corrugation runs AROUND the core structure — Not parallel.

The next piece will be four additional “U” shapes desgned to wrap around the base and top to provide a clean, continuous finish. Those should look something like this before they’re folded:

Now, if you’ve been paying attention at home, the corrugation in this piece is running horizontal ( because that’s where the folds are ). This will have it running perpendicular to the corrugation in the core. The plan is for the alternating corrugation to create a very strong structure. It  should also create a very smooth edge. I’ll wrap two more of these around the sides ( but without the tabs ), to create a very tight seam.

Once the entire structure has been built and secure, I’ll use some form of filler ( Wood, apoxy filler, bondo, drywall compound ) to hide the edges. Sand, then paint and it’ll be a finished shelf!

Here’s the plan. Hopefully it all works like I think it should. Feel free to poke holes in the idea.

Here’s the first two “U” shapes, drying.

I’m woried about the weight of the final sculpture, and the cost to create — not to mention the cost of my mistakes, of which there will be many.

So the idea came to me that it was theoretically possible to build this project out of cardboard. I’d been looking at projects like this for months, and with the long weekend coming, I’m gonna give it a whirl.

Here’s what I’ve assembled for starters to do this:

• 1 yard and 1 foot metal rulers
• 1 metal ‘L’ square
• blue painter’s tape
• Gorilla wood glue
• a backing — in this case an old pergo floor board
• 4 woodworking clamps
• misc wood blocks/boards (prevent clamp impressions in the cardboard)
• 6 Cardboard Project boards

I’m using the project board this time because I wanted “clean” cardboard for the first few experiments — I want to know what the basic problems will be before I introduce those involving cleaning and squaring the cardboard.

Now, the project for the final design is FAR too complex to experiment with. To begin this, I’m going to make a few floating box shelves ( like these on Amazon ) in various rectangluar shapes to produce floating De Stijl shelves, much like these, but not inter-connected.

I’m going to be trying multiple methods of construction and finishing, hopefully over the course of the weekend.

Wish me luck, and I’ll update both facebook and twitter when I have time. Those of you on G+ will see my pics appear as I take them.

I’m building a canned Multiple-Choice question for courses we use here at OU. My prototype got dinged in QA because you couldn’t tab to the buttons nor select them with space. Pretty big bug that I couldn’t believe I missed. I just assumed that because jQuery UI made everything accessible nearly automatically, I didn’t have to handle it directly.

Yeah, they don’t, and I do.

Issue is, if you create a button out of a checkbox, you can still tab to the checkbox (thus set focus to it, thus making it accessible to screen readers) but there is no visual indication that the item is focused. Here’s an example — try tabbing to the buttons and see what happens.

Here’s how I’m solving the issue. It is not perfect, but it’s what I’m doing for the moment. If I come up with something better, I’ll update the post.

var o = $("#myCheckbox").button() ;
if(o.attr("type") == "checkbox" || o.attr("type") == "radio")
{
o.bind(
"focus blur",
function( event )
{
$("label[for='" + event.target.id + "']").toggleClass("ui-state-hover") ;
}
) ;
}

Obviously I’m hoping for comments here, so if you know a better solution or a better direction, please, let your voice be heard.

I *think* I may take the time to turn this into a plugin if it turns out that I’m not missing the painfully obvious step to make all this work. Comment too if you want the plugin code.

Edit: okay, the plugin tool like 30 seconds. Here ya go: jquery-ui.checkbox.button.focus. Include this file after jquery-ui.*.js and use it like this:

$("#myform input[type='checkbox']").button().checkboxButtonFocus( ) ;

In a project, I’m using a TextArea control because it’s better at displaying images inline using the htmlText property — the Text control completely failed. But once I did this, I kept finding the text getting clipped.

TextArea controls expect that they’ll have a fixed or percentage width and height. Most of the suggestions I’ve seen require the use of getTextMetrics() for the mx_internal textField control of the TextArea. This fails miserably if there is any font sizing or inlined images in the html.

This (placed in creationComplete) works nearly perfectly:

protected function onCreationComplete(event:Event):void
{
	//textAreaControl is the id of the control you want to resize to contain it's text.
	textAreaControl.validateNow() ;
	textAreaControl.mx_internal::getTextField().autoSize = TextFieldAutoSize.LEFT ;
	textAreaControl.mx_internal::getTextField().validateNow();
	textAreaControl.height = textAreaControl.mx_internal::getTextField().height ;
}

It would be just as easy to subclass the TextArea control and apply this on set htmlText().

One minor error with this is that before creationComplete is run, the text is briefly visible in it’s unsized state. If you’re using this in a subclassing situation, no worries, but if you’re applying this from a parent->child situation, you’re going to have to handle the appearance changes (but that’s fairly obvious — just felt it needed qualifying).

Hope that helps someone out.

Update:

Created the class in the comments below, figured I’d update the article:

package us.aut0poietic.controls.text
{
	import flash.text.TextFieldAutoSize;
	import mx.core.mx_internal;
	import mx.controls.TextArea;
;

	public class AutoSizeTextArea extends TextArea
	{
		public function AutoSizeTextArea()
		{
			super();
		}
		override public function set text(value:String):void
		{
			super.text = value ;
			updateSize() ;
		}
		override public function set htmlText(value:String):void
		{
			super.data = value ;
			updateSize() ;
		}
		override protected function commitProperties():void
		{
			super.commitProperties() ;
			updateSize() ;
		}
		protected function updateSize():void
		{
			if(mx_internal::getTextField() != null)
			{
				validateNow() ;
				mx_internal::getTextField().autoSize = TextFieldAutoSize.LEFT ;
				mx_internal::getTextField().validateNow();
				this.height = mx_internal::getTextField().height ;
			}
		}
	}
}