Posts in the Tools Category

HYDEsim Update

Published 18 years, 9 months past

I’ve updated HYDEsim to include a key explaining the various overpressure effects—it’s at the bottom of the page—as well as to use generally improved code, having discovered the joys of for (var x in y).

I’ve also been pounding my head against the Google Maps API as I try to figure out how to read and set the map type correctly, so I can include the map type in the link parameters.  What’s in the documentation seems wildly different from what I’m getting.  When I query map.getCurrentMapType(), for example, I don’t get a type, I get a whole array of stuff that looks insanely cool and useful but is all apparently undefined and therefore useless.

On an even less happy note, the tool has completely broken in IE/Win.  Given the lack of anything resembling a useful JavaScript console in Explorer, I have no idea what’s happening, or why.  Sorry about that, IE users.  It works fine in Firefox and Safari.  If someone figures out the problem, let me know in a comment.

In the meantime, here are some approximations of a few famous historical high-yield explosions:

And, just for extra fun, here are two fictional explosions.

That last one assumes I got the yield right, which I may not have, since I don’t own the book and haven’t read since it came out in hardcover.  If I remembered incorrectly, let me know what the actual yield was (not the incorrect yield that was first estimated, but the correct one that came later in the book) and I’ll correct the link.  Thanks.

Update: thanks to assistance from some helpful folks and some fun hacking around IE/Win’s flaws, the tool is back to working in IE/Win.  Yay.

Working With Google Maps

Published 18 years, 9 months past

As I worked on HYDEsim, I discovered some interesting things about the Google Maps API.  Well, let’s call them what they are: limitations.

(And let me say right up front that if I missed ways to get around these limitations, then I’ll happily be corrected.  Either way, these are the impressions of someone whose first project in the API took about two days, and was in the end basically a success, which speaks volumes to the quality of the API.)

The first and most important limitation was that the Google Maps API permits the creation of two types of objects.  The first type is icons, the most obvious example of which are those little push-pin symbols in Google Maps that mark locations.  The second is polylines, which are how Google Maps draws the “get from here to there” routes on the maps.  You get both any time you ask for driving directions, like these from Norwalk, CT to New York City, NY.

Note that they’re polylines, not polygons.  You could certainly draw a polygonal shape using a polyline, but you couldn’t easily fill it with a color, let alone a translucent color.  And as for a circle… well, if you want to draw enough line segments so that you approximate the roundness of a circle, you certainly can.  It just doesn’t seem like a great idea.  Plus there’s no simple way to fill it in.

So in order to draw the overpressure rings, I created a 1000×1000 pixel 24-bit PNG of a circle.  To create a ring, I first used the Google Maps API to figure out the latitude and longitude boundaries of the map.  From that, I determined the number of miles per degree based on the latitude, and then calculated the number of miles per pixel (mpp) within the view.  From there, I determined how wide a ring needed to be to be the right size, created an icon at that size using the big PNG, and added it as an icon.

Whew.

Okay, so that solved the problem of putting the rings on the map.  What it didn’t solve was what happened if the zoom level changed, because icons (being raster images) don’t zoom with the map.  By default, you wouldn’t want them to: if the pushpin kept growing with the map as you zoomed in, eventually it would get huge and blocky and obscure half the view.

Therefore, the upshot was that every time the zoom level changed, I had to rip away the rings and rebuild them entirely, based on the new mpp value.  It was easy to trigger the process: 

GEvent.addListener(map, "zoom", zoomLimit);

That’s the API at work for me.  I just tack a listener onto the zoom event, and I’m ready to go.  Cool.  Rebuilding the icons—well, not so cool, although it doesn’t seem to kill the tool’s performance.

All this zoom handling was necessary because icons, as you might expect, are given dimensions in pixels.  Polylines, on the other hand, have each point defined with longitude/latitude coordinates.  That’s why polylines do scale with change in zoom level—as, again, you’d want them to do by default.  If I could have defined my icons’ sizes using longitude/latitude measures instead of pixels, I could have avoided the whole “recalculate the ring sizes every time the zoom level changes” bit and shaved two or three hours off of my development time.  (Which was, in total, 12 hours or less.)

Of course, if the API provided polygonal primitives, I’d have avoided even more hackery.  If I could have just drawn the circles as circles, using longitudinal degrees as the unit of sizing, then there’d have been even less work and a shorter development time.  Something like this: 

var base = new GShape();
base.type = circle;
base.anchor = new GPoint(-73.9971, 40.7223);  // longitude,latitude
base.radius = 0.0273548;  // degrees of latitude

…or something to that effect, with properties for the color and thickness of the outline, and also for the color and transparency of the interior.  And so on.

By doing it this way, the shapes (and there could easily be many other types) would be like filled polylines, and would scale in size along with the map.  That would have made HYDESim a whole lot easier to create.

You might say, “That’s all well and good, Eric, but how many reasons are there to draw circles on a map besides charting widespread destruction?”  I thought of a few possibilities:

  • Explicitly showing the scope of a “show me hotels within this many miles of the specified address” type of request
  • Someone looking to recreate the WIMPUR map in Google Maps
  • Plotting Iridium flare intensities

I’m sure there are countless more.  As well, allowing for actual filled polygons would add extra possibilities to applications like chicagocrime.org, which uses polylines to draw ZIP code boundaries.  With filled polygons, they could shade the ZIP code in question… or shade all other ZIP codes while leaving the current one unshaded, in order to give it some extra visual pop.

There was one other thing I encountered that’s either a limitation, or I just couldn’t figure out how to deal with it.  If you click on a detonation point in HYDESim, it pops up a “blowup” window (their term, not mine!) that shows a zoomed-in view of that point on the map.  The overpressure ring overlays are faithfully reproduced on that map, but they aren’t scaled to its zoom level.  They exactly match the overlays on the main map, and zooming in and out in that window has no scaling effects.

Ideally, I’d just remove the overlays from the zoom window while leaving them in place on the larger map.  I couldn’t find a way to do it.  Failing that, I wanted to have the overlays correctly scaled.  No dice there either.  If there is a way to do either of these and I missed it, hopefully someone will let me know.  If not, it’s something I hope the API adds in the future.

The final observation has to do with the icons and interactivity.  I wanted to set the overpressure rings to be event-transparent.  In other words, I wanted to make it so that the rings didn’t exist as far as the event model was concerned.  That way, you could click-and-drag the map even if there’s a ring underneath the mouse pointer.  This didn’t appear to be possible, although again, maybe I just couldn’t figure out how.  I did play around with the imageMap property, but it didn’t seem to have much effect.  Figuring that out would be nice, though.  I could leave the detonation point active for popping open the blowup window, and make the rest inert.

Other than that, things went as smoothly as you might expect they would for someone with limited JavaScript skills and no prior experience with the Google Maps API.  The examples provided by Google on the documentation page helped immensely, actually, especially the AJAX example.  That let me split the city list into a separate file, thus making it much easier to maintain, and get my first hands-on experience with AJAX programming.  (I’ve seen AJAX applications before—as long as three years ago, actually—but never written any code along those lines.)

Oh, and one more thing—the fact that the Google Maps API key only works for a specific directory, and not any of its subdirectories, drove me up the wall.  Instead of generating a key for meyerweb.com that would cover anything I might do on the site, I’ll have to generate a new key for every new directory.  This is why I set up the directory /eric/tools/gmap/, but that just seems so… confining.  Similarly, it was annoying that the key was completely bound to the full address.  I generated the key for meyerweb.com/eric/tools/gmap/, so if anyone types in www.meyerweb.com/eric/tools/gmap/ they’ll get a key error.  It would be nice if at some future time the keys were a little more flexible than they are now.

Mapping Doomsday

Published 18 years, 9 months past

This past Friday night, in conversation with a couple of our friends, the subject of high school fears of annihilation came up.  Ferrett said he’d done a class project showing how, if New York City got hit with a nuclear warhead, his home town of Norwalk, CT would be destroyed as well.

“Wait a minute, that can’t be right,” I said.  “How far is it from Manhattan to Norwalk?”

He didn’t know for sure, so we went to Google Maps for a rough estimate.  49.2 miles, it said, although of course that’s a driving distance, not a straight-line measure.

Still, I felt confident in asserting that no way would Norwalk be destroyed.  Not even with a 20-megaton warhead, which was what he remembered using in his example.  A few windows might get shattered, and of course if the wind were from the southwest they’d be getting a whole lot of fallout.  But flattened?  No.  I was pretty sure not.

“Hold on,” I said, “I’ll be right back.”

I ran up to the library and went straight to the “military and arms control” shelf, where I pulled out my copy of “The Effects of Nuclear Weapons”, 3rd Edition (1977).  In the back, it has this handy “Nuclear Bomb Effects Computer”, a circular slide-rule type of affair.  You can fiddle with an online version of the calculator from the 2nd Edition (1962) of the same book, and the complete text of the 3rd Edition is also available online.  I went back downstairs and pulled out the calculator.

Humming to myself, I slipped and swished the dials until I came up with the answer a bit more severe than expected, but not terribly far off.  At a range of 45 miles, the maximum overpressure for an optimum-altitude air burst with a 20MT yield would be somewhere around 0.8psi.  The calculator actually doesn’t show overpressure figures below 1psi for optimum-altitude bursts, though it goes down to 0.1psi for ground bursts.  It also doesn’t go any higher than a 20MT yield.  A 0.8psi overpressure would shatter most windows, particularly those facing the shock wave, and might cause light damage to some residential homes.  The direct thermal radiation, even assuming line-of-sight to the fireball, would be less than 1 cal/cm2, which isn’t enough to cause any damage.  Otherwise, there would be a brief pulse of 30-mile-per-hour wind as the shock wave passed, and of course there would be EMP effects.  And, you know, fallout.

So it’s not like things would be all peaches and cream for the folks in Norwalk, but the town would still be standing.

At this point, I wondered if there were perhaps a tool online that would show this sort of information more visually.  I Googled a bit more, and came up with the Nuclear Weapon Effects Calculator, which lets you pick from a short list of cities, dial up the yield of your explosion, and click on the image to change the detonation point.  Guess where they got their data for the thermal ring, as well as the 5psi and 2psi thresholds?  Yep: “The Effects of Nuclear Weapons”, 3rd Edition.

That’s when my inner geek kicked into overdrive.  I’d been meaning to dig into the Google Maps API anyway, so I signed up for a key and developed my own version.  I call it HYDESim, which stands for “High-Yield Detonation Effects Simulator”.  You can pick from a list of cities or input any latitude/longitude coordinates Google Maps covers, set the yield you find most interesting, and see what the effects might be.  Each successive ring marks a successive overpressure threshold: 15psi, 5psi, 2psi, 1psi.  I included 0.25psi in the list because it’s the point at which even windows wouldn’t be damaged, but left it off the map because it was too huge.  (I thought about adding a way to switch psi rings on and off, and in the end didn’t feel like doing the necessary hackery.)  15psi is the point at which reinforced-concrete structures might be able to survive with severe damage; 5psi is where homes might start to survive with severe damage; and 2psi is where home damage drops to light.  Roughly speaking.

I didn’t include rings for thermal effects or electromagnetic pulses: this is strictly about blast wave damage.  It’s also “idealized”, which means that there’s no effort made to account for terrain changes, urban density, ground type, and so on.  The script just uses the formulae and information in the book to calculate maximum-overpressure distances for arbitrary yields, and plops down circles as appropriate.  So the “Simulator” part of the name is probably exceedingly grandiose.  Then again, you never know what a future spate of hacking might bring.

Also: apologies to New Yorkers that your city is the default target, but its destruction and the follow-on physical effects in Norwalk are what got me started on this… and, let’s face it, in any wide-scale nuclear conflict, you’d have been the top city on the target list.

Doing this was an interesting exercise in both Google Maps programming and lightweight AJAX, which I’d also been meaning to investigate; the city list is built from an XML file that sits outside the XHTML document and its scripts.  I’ll have some observations about the Google Maps API in another post— specifically, what I found to be major limitations given what I was trying to do— but for now, here’s your chance to get a slightly more concrete idea of what had us all so scared during the Cold War.  As the simulator demonstrates, even a 1MT (1000KT) device could do a whole lot of damage.

Gatekeeper 1.5 rc4

Published 18 years, 9 months past

Now out the door: Gatekeeper 1.5 RC4.  It really does (so far as I can tell) allow pingbacks and trackbacks, as this post’s comments show.  So if you tried to ping or track back to a post here in the last three months, and you really wanted it to show up here, you might want to try again.  If you’re running Gatekeeper and want tracks and pings to work, you should definitely upgrade to RC4.

The auto-addition of the challenge to forms that don’t contain the pose_challenge call is still broken.  ‘Jim’ has more information and some examples of forms that fail to get an auto-added comment if you’d like to take a crack at solving that particular puzzle.

Web Page, Mutated

Published 18 years, 10 months past

One of the first rules of life is that first-hand information is always better than second-hand information.  You can be more certain of something if you’ve seen it with your own eyes.  Anything else is hearsay, rumor, conjecture—an article of faith, if you will.  At the very minimum, you have to have faith that your source is reliable.  The problems begin when sources aren’t reliable.

No, this isn’t a rant about the intelligence screw-ups previous to the invasion of Iraq.  Instead, it’s a warning that inspector programs and saving as “Web page, complete” features can lead you astray.

One such example came up recently, shortly after I mentioned the launch of the new Technorati design.  A question came in:

I did want to ask about the use of -x-background-{x,y}-position as opposed to background-position. If I understand correctly, the -x prefix indicates an experimental CSS attribute, so in what circumstances should one use this sort of experimental attribute instead of an official one?

I’d have been glad to answer the question, if only I’d known what the heck he was talking about.  Those certainly weren’t properties I’d added to the style sheets.  They weren’t even properties I’d ever heard of, proprietary or otherwise.

Just to be sure, I loaded the CSS files found on the Technorati site into my browser and searched them for the reported properties.  No results.  I inquired as to where the reporter had seen them, and it turned out they were showing up in Firefox’s DOM Inspector.

Now, the DOM Inspector is an incredibly useful tool.  You can use it to look at the document tree after scripts have run and dynamically added content.  You can get the absolute (that is, root-relative) X and Y coordinates of the top left corner of every element, as well as its computed dimensions in pixels.  You can see the CSS rules that apply to a given element… not just the everyday CSS properties, but the stuff that the Gecko engine maintains internally.

That’s where the problem had come in.  The DOM Inspector was showing special property names, splitting the background-position values into two different pseudo-properties, and not showing the actual background-position declaration.  This, to me, is a flaw in the Inspector.  It should do two things differently:

  1. It should show the declaration found in the style sheet.  There should be a line that shows background-position and bottom left (or whatever), because that’s what the style sheet contains.
  2. It should present the internally-computed information differently than the stuff actually taken from the style sheet.  One possibility would be to show any internal property/value pair as gray italicized text.  I’d also like an option to suppress display of the internal information, so that all I see is what the style sheet contains.

The person who asked why I was using those properties wasn’t stupid.  He was just unaware that his tool was giving him a distorted picture of the style sheet’s contents.

Don’t think Firefox is the only culprit in unreliable reporting, though.  Anyone who uses Internet Explorer’s save as “Web page, complete” feature to create a local copy for testing purposes isn’t getting an actual copy.  Instead of receiving local mirrors of the files found on the Web server, they’re getting a dump from the browser’s internals.  So an external style sheet will actually be what the browser computed, not what the author wrote.  For example, this: 

body {margin: 0; padding: 0;
  background: white url(bodybg.gif) 0 0 no-repeat; color: black;
  font: small Verdana, Arial, sans-serif;}

…becomes this: 

BODY {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px;
BACKGROUND: url(bodybg.gif) white no-repeat 0px 0px;
PADDING-BOTTOM: 0px; MARGIN: 0px; FONT: small Verdana, Arial, sans-serif;
COLOR: black; PADDING-TOP: 0px
}

Okay, so it destroys the authoring style, but it isn’t like it actually breaks anything, right?  Wrong.  For some reason, despite IE treating the universal selector correctly, any rule that employs a universal selector will lose the universal selector when it’s saved as “Web page, complete”.  Thus, this: 

#sidebar {margin: 0 74% 3em 35px; padding: 0;}
#sidebar * {margin: 0; padding: 0;}

…becomes this: 

#sidebar {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px;
MARGIN: 0px 74% 3em 35px; PADDING-TOP: 0px
}
#sidebar  {
	PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px;
MARGIN: 0px; PADDING-TOP: 0px
}

Oops.  Not only can this mean the local copy renders very differently as compared to the “live” version, it’s also very confusing for anyone who’s saved the page in order to learn from it.  Why in the world would anyone write two rules in a row with the same selector?  Answer: nobody would.  Your tool simply fooled you into thinking that someone did.

Incidentally, if you want to see the IE-mangled examples I showed in a real live set of files on your hard drive, go save as “Web page, complete” the home page of Complex Spiral Consulting using IE/Win.  And from now on, I’ll always put “Web page, complete” in quotes because it’s an inaccurate label.  It should really say that IE will save as “Web page, mutated”.

So if you’re Inspecting a page, or viewing a saved copy, remember this:  nothing beats seeing the original, actual source with your own eyes.  If you see something odd in your local copy, your first step should be to go to the original source and make sure the oddness is really there, and not an artifact of your tools.

Gatekeeper 1.5 rc3

Published 18 years, 10 months past

It’s update day!  I just pushed WP-Gatekeeper 1.5rc3 into the public eye.  The major change in this version is that Gatekeeper no longer prevents trackbacks (or pingbacks) from ever reaching your site.  See, before, it was effectively destroying all those without notice or appeal.  Now it just lets them through, whatever their content.

What this means is that Gatekeeper is, as it always was meant to be, a way to prevent comment-form spambots from succeeding.  Trackbots will now get through unless you take other steps, like disabling trackbacks or running another spam filter or something.  I’d actually like to see WordPress split tracks/pings apart from comments, and let you set their “always moderated” flags separately.  Thus you could set things up so all tracks and pings are moderated, but comment-form comments are not.  That would work great for me.  Maybe not so well for others, though.

Unfortunately, rc3 still has that problem where it doesn’t always automatically add a challenge to your comment forms, though you can still get the challenge by manually adding gatekeeper_pose_challenge to the comment forms in your theme.  My grep-fu (or maybe it’s my PHP-fu; or, hell, both) is weak; I can’t figure out why the routine fails.  Anyway, head on over to the Gatekeeper page if you’re interested, and especially if you can figure out why the auto-challenge routine is failing.  Thanks.

S5 1.1rc2

Published 18 years, 10 months past

Thanks to a comment from Pritt, the Safari arrow-key bug in S5 1.1rc1 has been, so far as I can tell, fixed.  I’m therefore releasing S5 1.1rc2, which will be the final release candidate unless any major bugs are encountered.

Also new to this revision are some slight modifications to the CSS that drives the system’s presentation.  The changes were all in the vein of changing div.slide to .slide.  Why bother?  Because with these slightly more generic rules, it’s now possible to create your slide show using a XOXO format instead of the OSF-compatible div-based markup.  (And the XOXO version may be OSF-compatible; the only real difference is that you’re using a list instead of a series of divs, but I’m not sure how much OSF cares that each slide be in a div instead of some other element with the appropriate class.)

I’ve included a XOXOized version of the testbed slideshow in the rc2 package, so feel free to check it out, if you’re interested.  Long-delayed thanks to Tantek for helping me work out the few changes that needed to be made to the CSS, and providing me with an example XOXOized S5 file so I could use it as a reference.

S5 vs. BBEdit 8.2.1

Published 18 years, 10 months past

Just a quick note for any of you who might be both a BBEdit user and an S5 author:  BBEdit 8.2.1, the latest update, will crash if you try to open any valid S5 presentation (I don’t know what happens with invalid files).  Apparently there’s a bug in BBEdit’s XHTML scanner that the S5 file structure triggers.  Version 8.2, which you can get from the Barebones FTP site if you don’t still have it locally, does not have the same bug, and will edit S5 files without any trouble.

The folks at Barebones are aware of the problem and have indicated that a fix will be in the next maintenance release of BBEdit.  For now, if you want to edit S5 files in BBEdit, stick to 8.2.

(And if anyone wants to take a crack at helping out with the problems in S5 1.1rc1, see my earlier post on the subject.  Thanks!)

Browse the Archive

Earlier Entries

Later Entries