dojo7

WallMap: Building a huge Google Maps poster

2012-01-17T00:00:00+11:00

With a new apartment comes new projects! There’s a spare wall near the build space that could do with something useful on it. We decided a map would be good. Now to render the map!

I used the excellent Google Static Maps API, the JS API, some CoffeeScript and a static website to create the map.

Getting the tiles

Google provide a scale control for their static maps, which means we can get nice large images that are viewable from a distance. Cranking the scale to 2 gives us double the DPI. The API docs mention 4 is available for business customers. This feature was introduced for hi-res handsets and the like.

Requesting scale=2&size=640x640 (the maximum size for free-use), we get a 1280x1280 image of the target area.

Click on the image below to see the full sized tile.

Pan-tiling in Javascript

There are mathematically nice ways of doing things and easy ways to do things. The fastest route was to use the Google Maps Javascript API to do the geo-math for us. Specifically, we’re able to pan by pixel amounts rather than degrees. We also get a nice UI for defining the approximate poster bounds.

Here’s the demo :D

The green overlays drawn are the frames for our tiles. We worked out where the tiles should be by zooming in (to the detail zoom level), panning pixel distances (to the next tile) which now fills the map window, then fetching the map bounds to get our tile image coordinates.

You can now run this generated convert command (if you have ImageMagick) to fetch and combine the images.

Source for WallMap is available on GitHub.

Tile zoom level

The detail zoom level controls the size of features like roads, building boundaries and areas. Scale controls the size of map text, symbols, stroke line widths and other details.

Figuring out which zoom level is desired requires some experimentation balancing desired coverage area and available wall space. Printed out, the first batch of tiles looked like this.

Printing it…

Once the PNG is built, the next step is to use software like posterazor to cut it up and print it out. It’s a work in progress. More to come.

Cracking Station Upgrade

2012-01-16T00:00:00+11:00

More work on the hashing supercomputer.

I’ve been transforming my NAS box into a hash-cracking station. I acquired a Gigabyte HD 6770 SC, a high performance, high frequency AMD GPU that’s OpenCL friendly. This card is cheap (and quiet) for its computational power because it has less RAM than competing graphics cards in the same bracket (graphics RAM speed matters for this application, but capacity has minimal impact).

For comparison, here’s the Gigabyte HD GV-R797D5-3GD-B. One of the most hard-core graphics cards available when this was written.

HD 6770 price/performance
Aspect	6770	GV-R797D5-3GD-B	% inc.	Relevance
Price	$139.00	$793.00	+471%	6770 is near the sweet spot
Core Clock	850 MHz	925 MHz	+9%	We care about this
Memory Clock	4800 MHz	5500 MHz	+15%	This too
Memory Size	1024 MB	3072 MB	+200%	This can be flexible

For basic OpenCL based number crunching, the 6770 has some pretty decent specs for the price.

Well, today was a hot one in Melbourne and after testing out the card with OCLHashCat the rig nearly melted, reaching a GPU temperature of 90°C.

There are reports of these cards running hot. The fanless design may account for that, and they probably had to accept certain trade-offs when designing the thing. The weird thing was, just replacing the factory thermal grease with some Arctic Silver 5 dropped the idle temperature from 65°C to 52°.

I’ve moved from 2 to 4 silent fans for good measure, taking the full-load temperature (92% GPU utilization for 30 minutes) down to a stable 71°, and idle temperature down to 43°.

Here’s the Pyrit benchmark of the continuously achievable WPA2 hash-rate (4,096 iterations of HMAC-SHA1 per WPA2 PMK).

Around one hundred million HMAC-SHA1s per second (leveraging SSE2 on the 2.4GHz Athlon II does about 2% of that). Nice.

BitCoin Mining Test

Using poclbm with the DeepBit minding pool. This low-cost experiment rig achieves around 120 MH/s.

UPDATE 2012/01/17:

Using cgminer with OzCoin increases that to 168.1 MH/s steady.

Hardware shots

The HD 6770 SC: Heatsink removed: The card that hides underneath: Re-installed with two extra fans (airflow from bottom to top):

Site relaunched. The power of MM!

2012-01-15T00:00:00+11:00

This site was re-built over a weekend. Static site generators are the new black amongst Ruby developers at present, and from my experience with Middleman it’s easy to see why. In this article I’ll briefly discuss this site’s rebuild and the gains made from taking the static approach.

The basics

A static site is “is a web page that is delivered to the user exactly as stored, in contrast to dynamic web pages which are generated by a web application”.

The benefits

The idea has been around a while. In the Ruby community alone there are several good static site generator solutions. I went for Middleman for a number of reasons:

It was created to work for the general-case
There are a number of extensions, but most of the useful stuff is built-in
Support for Asset Pipeline style script management (Sass, CoffeeScript)
It’s just damn good design
Rack support if you really really need it

What you’ll gain with using an SSG are mostly performance boosts. Given the site only needs to be generated once per deploy, as opposed to every pageview, you’re able to deploy on much lighter-weight platforms and enjoy the reduced cost.

The tradeoff

Of course, the flipside of this scenario is there’s no longer an app-server sitting there ready to generate responses based on the context of the request. Though it’s becoming a trend to move more toward client-based apps that link to remote data-sources, rather than essentially running the app for everyone on a central server.

Most of the client-side technology required to making this de-centralized transition is supported by Middleman. Tools like CoffeeScript, Sass and Backbone.js are doing for client-side development what Ruby on Rails did for server-side development. The gap is closing and I wouldn’t be surprised if 2012 marks the year where we change our architectural preferences en masse toward client-based approaches. There are so many advantages.

This site

I really enjoyed re-writing this site in Middleman, familiarizing myself with the different available solutions and finding a git-based deployment strategy that worked for me.

I’ve published the source-code for the dojo7 website on Github.

Formatting currency in JavaScript