Mikel has posted a how-to on how he made the OSM Nestoria Tiles for the recently released upgrades.

It’s a really good how-to for making your own maps from your own data, and also an excellent idea for brain-dumping after a big project. Whenever I do a large project, I learn a lot of useful tips, strategies, what worked/didn’t work, etc. that is probably useful to a larger group of developers and users (for knowing what’s going on underneath). Not only for my own notes, but also anyone wanting to improve upon my work, or go and fix parts of it.

Documentation in engineering and software development is always emphasized and always a battle to get done. Inline documentation using something like Doxygen really helps, but then also putting together a single, simple overall report, especially on an editable format like a Wiki, can really make a big difference.

I just had a really interesting brainstorming session on a possible future of commodity computing.

I carry around many processors, a cellphone, tablet, laptop, camera. These are all just processors, running an operating system and waiting to execute some code. Currently they run application/device specific code, designed for their single use lives. Any of the devices could really be application independent and dynamically perform whatever operation I want to give it. My cellphone breaks, so I just make my computer as a cellphone, or my tablet.

Let me illustrate with an example: All of my devices run Python, so I write a Python video player. So then I can load it onto my cellphone and boom my cellphone is now a media player, or my tablet is now the media player, and so on. The device itself is irrelevant, it is a packaged form factor that I as the user/developer decided what it was going to do now.

So then carry it forward a little bit to where I go into my local hardware shop and buy a slew of “processors” or devices. Generic devices with several interpreters or OS on it that I can drop an image to it. I may buy a couple of matchbox bricks with no display, and once that is a soapbar size with a screen and some buttons. Oh, and another screen with keyboard. I then drop a “cellphone device image” or application on the soapbar device, and perhaps a Word Processor application on the keyboard/screen, and so on. Think of it like Amazon’s EC2 computing cloud, but in the palm of your hand.

stack’em

Now the matchbox devices, they can be simple devices, or maybe they’re even like Lego bricks, where I can snap them together for easy parallellization. The processors start communicating and sharing data and code between them, without any intervention from me the user. Maybe some of these small devices then snap into larger devices with a screen, so I can make my tablet device now have 3, 4, or 8 processors in it. Perhaps the devices communicate via exposed connectors, or wirelessy using RF, or even some kind of optic communication.

I may even put 100 of these in as a small stack of cards in my computer. Over time, they slowly start “wearing out”, so after a year or 2 I only have 80. So what, some programs run a little slower, or I can’t do as many actions on the device. I swap the broken ones out, toss in some more, or even just pick up a new device and interface.

bucket o’ computing

Now what if the processors were just small amounts of silicon, like sand. I have a pile of these “sand processors” that communicate omni-directionally with other processors near them, not just the ones touching it, but any within a short spherical range. They would share data, hand off programs and provide me with a compact, parallelized, mobile, amorphic computer.

And if the sand computer can react to visible and non-visible light, I could show it a picture and it is instantaneously processed.

the future is now

While I really think there is a future in “sand computing”, I don’t think I’ll be able to buy my “Pail o’ Processing” after WWDC’07. However, we have reconfigurable devices now. Linux has pushed for this for a long-time, a single operating system running on consumer and embedded devices. Even easier is to run an interpreted language like Python or Ruby. Right now I can run a GPS program, MP3 player, or any other number of desired functionality on a handful of devices. Using open-standards I can then share the data between devices, so I can take my GPS waypoints off of my receiver and load them onto my cellphone.

The future is now, and it’s fun.

I learn best by picking a project and learning a new technology by applying it to the project. This is how I originally learned PHP, MySQL, and various web technologies when developing the Detroit Curling Club site/portal. Looking back, it’s amazing I got done what I did with what I knew. I implemented a Wiki, CMS, user management, uploading, RSS, and so forth, from the ground up, with no frameworks .

However, the result also means the code is, shall we say, “spaghetti”. And is really no fun to maintain and add to. Since then, I’ve learned Ruby and Rails and really enjoy working in the language and framework and wanted to reimplement the site. With so many other projects going on, I was concerned about the time necessary to get the site migrated.

Actually, it was rather easy. by stroke of fortune. Here is how the work went.

On the catwalk…

By similar mindset, when I designed the original database schema, I used “rails-esque” naming: tables are plural, columns are simple singular names. Join tables are alphabetical of the two tables they are joining. I just had to migrate the names of a couple of tables and columns to mee the rails standard configuration. I could have overriden the table/column names, but didn’t want to deal with maintaining that. I really wanted the site to work like it was originally written with Rails in mind.

You’ve obviously created a Rails application by now, so I’ll skip that. Now, I have my database (with backups). Setup your config/database.yml to point to the database and then run rake db:schema:dump to create the schema.rb of the database. If you want, you can copy this to a migration file.

Next, install Dr. Nic’s Magic Models, which automagically give you your model files, associations, basic validations, and so forth with no coding. Magic just begins to describe it. You can verify this by bringing up script/console and toying with your models and associations.

Testing is good

A good idea at this point is to load Selenium, a web user-interface testing application, and walk over your original site to create user interface requirements based on current site design. This should stand as your base-line specification. In the end, your Rails app should act like your current application.

You can also check out the work of Josh Susser who has a ruby script that will validate all the records in your database using your model validations.

Define your application test specification using RSpec and BDD. Again, you already have an existing web application to help define your desired functionality.

The View, the View

Now you have a your base application done. You should start migrating your views. Fill in your layout/application.rhtml with the base layout from your original HTML files.

You’ll now need to start actually defining your controllers for various functionality: calendar, users, leagues, etc. Along the way, run your tests you defined with RSpec and verify operation. This is where the actual work comes in. Overall though, I find the design of Rails to make this very easy going. I just have to deal with various legacy functionality.

I’m also looking more at Unobtrusive Javascript for Rails (ujs4rails) at how to handle graceful degradation (or is it graceful upgrading) to browsers that may not support javascript.

Work in Progress

That all said, migrating the site has been very easy. So easy I’m looking at migrating other projects to Rails. Of course, deploying Rails applications to shared hosts is not nearly as easy as deploying PHP ones. Especially with applications that are meant for other users to easily install on their own hosts. But the ease of development and maintenance is not easily overlooked.

If only Apache supported a built-in Rails module.

There is a good article on Developers are from Mars, Programmers are from Venus. Comparing the two terms that are often interchanged, but really imply different meanings.

I first noticed this when deciding what I wanted to do in Undergraduate studies. Computer Science was hot stuff in the late ’90’s, but it really seemed like companies weren’t looking for Computer Scientists, they were really looking for Software Engineers, Developers, and Programmers (all different jobs with different skills, personalities, and types of work).

Computer Scientists really should be developing “formal specifications of a programming language”, whereas Software Engineers should be figuring out how to scale out a database, or apply domain specific solutions.

Of course, I ended up doing Aerospace Engineering, but with a Computer Science Minor. The CS minor let me take C++ instead of Fortran, and also have courses where I actually learned how to do requirements documentation, work in a team, design and build large scale systems in a single semester – all skills I didn’t learn in the Aerospace department but have since applied to my work.

I firmly believe that in the near future, all engineers/scientists should/will learn how to program. It is becoming a basic skill necessary to do proper analysis. Given a little bit of programming ability, an engineer can relieve themselves of copying & pasting from Excel to MatLab or other such silly things. Teach them good programming and software design techniques, in a modern and easy to use language with good tools, like Python (and then SciPy and NumPy) and they can be much more effective designers and analyzers. Also, if they learn general, good technique, they can apply that ability to learning other languages that may be specific to their domain.

And no, learning Fortran (or Java) is not going to cut it.

All the emerging standards for simple markup and syndication of location are Earth-centric (and sometimes just US/North American-centric). Granted, most people are probably only interested in locations that they can actually go to anytime soon.

However, with the increasing number of interplanetary rovers, observations of moons, and perhaps future excursions, it is still useful to define how to properly handle these other reference frames. Luna and Mars are two suggested Microformats that are starting the discussion on how one might mark locations on the two bodies. Additionally, the OGC is working now on determining standards for scientists and developers to publish and share data sources of planets, moons, asteroids, comets, ‘oh my’.

And why does the Earth have to be the only one with cool, “slippy maps”. I quickly put together a map of Mars. It uses the powerful OpenLayers Javascript mapping library to display the tiles from a NASA WMS server.

To produce the locations for the map, I put up a Space Blog, using WordPress and a slightly modified GeoPress to publish Mars lander locations and landing dates. I altered the published Microformats produced by GeoPress to make the class “geo mars” as a suggested way to markup Mars coordinates. The published GeoRSS feeds from the Space Blog then produce the locations and layers automatically on the OpenLayers Mars Map.

To Do: CRS and You

So this is all very neat, and in the end, really easy to setup. However, this is just a demonstration and in no way should be construed as “the way to do it”. Specifically, there are these questions left unanswered:

1. How to define the Microformat and GeoRSS for non-Earth (and non-WGS84) reference frames
2. How to define the Microformats and GeoRSS/Geonames location for non-Earth locations (like “Ares Vallis”)
3. More sources for interplanetary map servers
4. Ways to syndicate, and subscribe to, specific bodies
5. Support for publishing, consuming, and drawing lines – in order to plot out mission profiles
6. Support for publishing, consuming, and drawing areas – in order to plot out mission profiles, landing sites, and expected areas of “mission failures”

I’m sure there are more issues, so please speak up. You know who you space geeks are.