Lessons in the Fundamentals of Go

Lessons in the Fundamentals of Go (Beginner and Elementary Go Books)Lessons in the Fundamentals of Go by Toshiro Kageyama
My rating: 5 of 5 stars

It’s hard to say what I like best about this book. The style is very entertaining; it’s like hanging out with an incredibly wise and goofy old man. The humor and sarcasm is no distraction from the lessons, either, but rather serve to underscore the points he’s making.


I’m looking forward to re-reading it again. I’ve already re-read several chapters, and feel like my game has benefited each time I’ve opened it up.

It’s maybe not the first book you should buy about go, but once you understand the basic rules and have a number of games under your belt, and are ready to start improving your game, this book will be well worth your time.

Comments

Review of "Musashi"

MusashiMusashi by Eiji Yoshikawa
My rating: 5 of 5 stars

This book is probably not one I would’ve picked up on my own, since I have no special interest in samurai, and the book is large. It was given to me by a friend.

I was sucked in to the book quickly; the writing is clean, and moves at a good pace, which I didn’t expect for a japanese translation. The book is action-filled, and really fun to read.

The romantic storylines in the book bewildered me somewhat, but perhaps that’s just a cultural gap.

There are a wide array of characters in the book, and it can be difficult to keep track of them and their allegiances, but it is important to do so to understand the context that this takes place in. I was hoping for some references to the game of Go, as it was flourishing at this time in Japan’s history, but was left empty handed.

Overall, I really enjoyed this book. Although it does deal with deeper topics such as honor, the samurai’s code, the history of a nation emerging from civil war into peace, the essence of the book was an adventure tale, spun around a very interesting historical character, Musashi.

View all my reviews

Comments

GDAL: Swiss Army Knife for Geospatial Data

GDAL is a ‘translator library for raster geospatial data formats’, according to the modest website, but that doesn’t begin to cover how many useful tasks this library and set of command line utilities can accomplish.

One of the core duties it performs is reprojecting geospatial imagery, and it does that very well, but it can also do things like contouring elevation data, burning in vector data from geospatial databases into raster images, and cutting up images into tiles for serving up over the web.

An Example: Display Radar Data on Google Maps

13

I’ll walk you through an example of using the gdal2tiles.py utility to generate a set of tiles from the NWS national radar mosaic. We’ll generate the tiles then add them to a google maps display. I use this same process to generate the radar layer for OMG Rainbows.

The National Weather Service has a useful page that details how to use radar data for GIS applications. It has links to the radar imagery as GIF files, and also (importantly), the world files, which have a .gfw extension. These world files specify the information necessary to describe what area of the earth an image covers.

The files we are interested in are the latest_radaronly.gif file and it’s corresponding world file. Download them to a working directory.

Tiling the Image

gdal2tiles.py is a python script that iterates over the image and uses the GDAL library directly to extract a pyramid of tiles for use in Google Maps, OpenLayers, or even KML for Google Earth.

The radar image first needs to be turned into a truecolor (non-palette) image, and the world file renamed to something that gdal will pick up:

convert latest_radaronly.gif -type TrueColor -depth 8 latest_radaronly.png
mv latest_radaronly.gfw latest_radaronly.wld

Here we call gdal2tiles.py, passing it options to generate tiles for google maps, only zoom layers 2-7, and to mark the color white (255,255,255) as transparent. The output will go into output_tile_dir

gdal2tiles.py -s WGS84 -z 2-7 -a 255,255,255 --webviewer=google -v \
latest_radaronly.png output_tile_dir/

Viewing the Result

You should now be able to view the result in your web browser by pointing it to your local output_tile_dir, and opening up the googlemaps.html file. Those files could be edited and copied over to your web server to easily share it with the world.

This is just the tip of the iceberg of what GDAL can do. The utilities documentation is a good place to find more about what’s included. Thanks to all the developers that have put time into this powerful toolkit; it’s a testament to the power of open source.

Comments

iPhone MVC for Rail devs

There are a good number of Rails developers becoming interested in iPhone development recently. At first glance, it is hard to imagine what would cause a sane programmer to leave the expressive and enjoyable Ruby for some strange version of C with even more punctuation.

But after diving in to the code, you’ll notice there are clearly some shared values. The Model/View/Controller pattern shows up often in the cocoa documentation and samples.

So what are the key differences between Rails & iPhone MVC?

One immediately apparent difference is that storing model, view, and controller classes in separate directories does not seem to be standard practice. XCode will allow you to organize your classes into “Groups”, and some apps do utilize this to organize separate the three (see the LocateMe sample app), but you’ll mostly be using the filename to determine if something is a view, controller or model. In some of the samples you’ll just see all the code put into a view, which might be ok to illustrate a particular feature, but I wouldn’t recommend for the maintainability of your code. This is the Cocoa equivalent of putting all your application logic in your ERB templates.

Views in Cocoa Touch are usually subclasses of the UIView class. You render into a view by implementing the drawRect method, or by adding other elements (subviews) into your view. Cocoa touch provides a nice set of UI elements, from the sophisticated UIWebView, which is essentially an embedded Safari widget, to simpler control elements like labels and switches. Very loosely, UIView superviews translate to html pages and subviews to partials.

The second member of the triumvirate, the controller, is played by UIViewController. Typically called ‘view controllers’, they separate the details of the models from the views, just like controllers in Rails. Each view controller is responsible for one ‘page’ or full screen of your application, so they’re more granular than Rails controllers, which typically control many pages/actions. You can set up view controllers manually, or use Interface Builder, which lets you place and arrange GUI elements graphically. Actions (called ‘outlets’) from GUI elements are connected to methods the view controller, which then updates the appropriate models.

The place for all the core logic of your app is, of course, the model. Model objects can be objective C objects, or even plain old c++ objects, and are responsible for the actual work of the application, such as storing/retrieving data, making network requests, interfacing with other aspects of the iphone, such as core location, audio, or the accelerometer.

The ostensible goal of MVC is to make your code more reusable and adaptable to change, and I think it succeeds for the most part on both platforms. At the very least, it’s a small amount of familiarity for the Rails coder new to iPhone development.

Comments