Jul 202010

I spent the better part of a week or so adding support for polylines into Flagship Geo.  The hard part wasn’t the data structure development, it was the ability to easily edit the lines in a way that made sense.

Google Maps works as a great User Interface control for maps, but its just a control.  You have to tell it what to do when someone drags a marker around or clicks on the map, there is no automatic way to tell it that the person is trying to edit the line.  All the objects people can interact with need event handlers written for them, which reminds me a lot of regular desktop application development.  I usually take for granted the fact that a tag like <a href=”#”></a> will automatically know what to do when clicked.  Tools like jQuery make it easily to build on those actions, sending that a href into a AJAX library or something.  Building the polyline editing interface was much more like building a desktop application in C, Python, or alike where you have to bind everything yourself.

Looking back on the past week, the hardest part was the ability to delete a point from your line.  This kind of reminded me of my days in Data Structures or Algorithms at RPI when you’re manipulating nodes in a tree or a list (a polyline is just an array of latitudes & longitudes) except unlike C, JavaScript doesn’t have any notion of pointers.

I got stuck trying to do have my markers (the icons you drag to manipulate the map) both update the visual line you see AND update the hidden HTML fields that store the latitudes and longitude for the point.  I found that replacing the event listeners with code that contained the update line point weren’t working correctly, so I ended up building my own pointer-esque data structure that contains id numbers to match up markers, polyline points, and html points.  While I try and minimize my use of global arrays, I couldn’t find any decent way around JavaScript’s (and Google Maps event listener) limitations.

You can take a look at the commit where most of this code was sent along here: http://github.com/bamnet/flagship_geo/commit/f2e8e113bcaef2a78573d8f5569e10f18bc8de4a

Jul 112010

One of my biggest complaints about Ruby on Rails relates to the environment needed to develop an application.  Last Wednesday I took-off for a few days of holiday up in Vermont.  Internet access is limited to my mobile phone while I’m in Vermont, so I have to take development as “offline” as possible while I’m up there.  Doing this with my Rails applications is a mess.

If I was doing PHP development, things were pretty straightforward for me to setup my laptop as a mobile development environment.  I could download XAMPP, or another all-in-one Windows-AMP stack, to a USB drive and copy all the source code I needed.  I guess I would also need to export a copy of a MySQL database as well, but that’s a pretty quick step.  After running the XAMP installer, I could drop all my source code into the folder and presto! things would be working good as new.

Ruby on Rails doesn’t afford me those kind of luxuries.  My laptop runs Windows 7, so I can’t just `gem install rails` and call it a day.  I’d never setup a local development environment on Windows (I always use a Linux server), so my plan was to download a few different packages and see what I could make work.  Since I was in a rush to depart, I downloaded as much as I could under the premise that I would be able to install things later.  Hopefully I would have enough pieces.

I found two common approaches out there to quickly setup a development environment on Windows.  The first involved virtual machines, where you would run your own Linux server within Windows.  I tried downloading 2 (or maybe 3) different server images, none of them would boot correctly in VirtualBox.  My second plan was to install a XAMP-like environment but with Ruby on Rails instead of PHP.  I was able to get this to install, but it seemed the stack I downloaded included some strange version of Ruby that wasn’t compatible with my application.

Nevertheless, I realized that regardless of what I did while “offline”, I wouldn’t have been able to get my applications up and running without internet access to install the different gems and plugins I require for my applications.  I had probably downloaded enough pieces to patch together a framework/Rails-stack, but that wouldn’t include the externally referenced modules in my code.  Gems and plugins (and by plugins I mean git submodules) are great, but you need to plan for them first when you’re going offline.

In a deployed, production-level application, gems and plugins might be frozen or bundled with your application, but that doesn’t fit well with the development of an application.  It would be really handy if the “download” button on Github automagically included all the git submodules you would need for an application, and I’m optimistic bundler will help solve some of the gem-deployment issues Rails applications face.

Now that I’m back “online,” I’m going to stick with my trusty development servers.  They might not be easy to carry around with me, but at least I don’t have to worry about keeping their configuration up to date or taking them offline.