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 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.

Ben Curtis recently released Tesly Jr., is a great web service that runs through your Rails tests, formats the output, displays them, and allows you to share them with other people. It installs as a plugin in your Rails application. Whenever you run rake to test your app, it uploads the results automatically to the Tesly Jr. server.

Using Tesly Jr., its very easy to keep your development team up to date with the status of the project. Combine this with runing tests on deploy with Capistrano (via Jamis Buck) and you have a that much better integration of testing into your development and release cycle.

Tesly Jr. is free when using the hosted service, and available for just $24 if you want your own copy to run on your own systems.

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.

I put together a presentation that didn’t get time at the first AnnArbor.rb meeting. The topic is “Ruby & Hardware” and is a quick rundown of some cool devices that can run (or be interfaced by) Ruby, such as NabazTag, SqueezeBox, Nokia 770. They’re all at various levels of support and functionality, but you can run Ruby on all of them.

Check out the presentation here: Ruby & Hardware.

I’ll be talking about them at the November AnnArbor.rb/RubyMI meeting if you want to come by.