I recently wrote about performing local timezone lookups with PostGIS. While this has been working well for me for many months, it requires that I keep an instance of PostgreSQL running just for this one purpose. At the time of that post, the spatial support in MySQL was pretty broken, but this should be fixed in the recent stable release of MySQL 5.6.11 (I haven't tested it).
I've been paying more attention to MariaDB recently, which is an enhanced drop-in replacement for MySQL. (Wikipedia recently switched over to it from the facebook fork of MySQL). It is appealing to me for a couple of reasons: First, it uses the performance enhanced fork of the InnoDB engine, XtraDB. Also, it has had spatial support in a couple of stable releases already (introduced in MariaDB 5.3). So I decided to move to MariaDB 5.5.30, the current stable release as of this writing.
Today is the last full day of our vacation to Hawaii. In a couple of hours, we are heading up to the summit of Mauna Kea to see the telescopes and do some star gazing, something I've really been looking forward to given how amazing the night sky has been this week down here at sea level. In preparation for the trip, I've been reading through some things I picked up at the Keck Observatory Visitor's center yesterday, and was struck by an article in the 2011 Annual Report titled "Reflections on 25 Years at Keck Observatory". It was written by Deputy Director Hilton Lewis, who started at Keck in 1986 as a young telescope designer, and recalls the two fundamental decisions they made that led to its prominence. First,"make the world's largest aperture telescope using a hexagonally tiled primary mirror", and second, "build it fast".
For my project "Where the ISS at?", I rely on a few external services for GIS related data. For example, when a browser gets permission to determine the end user's location coordinates, a call is then made to Google to look up the local name of that location, such as San Francisco, CA, based on those coordinates. This is so that I can determine the upcoming ISS passes for the user's location. But to show that data in their local time, I need to know what timezone they are in. Unfortunately, this isn't included with the data I get back from Google. So I need to make a second call to Geonames for this data. Since this is a small, non-commercial project I do for fun, it gets expensive quickly to pay for data. And understandably the Geonames API has a lower SLA for their free service, resulting in occasional outages for timezone lookups. What would be really handy is a way to look this up locally.
Seeing something in space fly overhead with the naked eye is pretty awesome. It's not only a technical marvel to enjoy, but for me it helps keep things in perspective and my thoughts on the big picture. Ever since the first time I saw the International Space Station fly by, I've felt that it is something everyone should experience. I started looking at existing software to help remind me (and others) when the next pass of the ISS would be, and while there are a few good websites out there for satellite prediction, none of them did exactly what I wanted. So a few months ago I decided to try and build my own. The biggest piece of my project was going to be getting the actual satellite data. So I looked around for existing data APIs that I could use, but couldn't find anything other than scraping existing sites (which is not only fragile, but some have no published data policy). So, the first step was to figure out how to to generate the predictions myself.
When developing a web application, it's common for your feature development to be ahead of any data administration tools you might need. While some frameworks, such as django, have built in admin tools for managing your application's data, many don't. At my current job we use Zend Framework, and have rolled our own lightweight model layer which does not have any fancy automatic admin tools. In addition to supporting database pools and selectors for partitioning of data, it also has transparent caching of data. While this is good for speed, it precludes you from making any data storage changes without going through this model layer or the cache will get out of sync. For now, rather than doing any DB queries directly, we do them through CLI jobs built for a specific task (batch updates, etc). This works fairly well, but often things come up that aren't yet supported in the application's admin tools, such as changing a user's status bits, etc.. Things that a CLI console would be useful for.