Software Development with a Spatial TwistJust a quick note that we seem to have finally hassled Mike to the point he’s started blogging – he’s our resident Dojo and Virtual Earth guru, so I expect he’ll be spreading some of that goodness around.
Check out his first post on Accessing ASP.NET Web Services with Dojo, and add his RSS feed into your reader. Now we just need to lean on Jeff to actually post more often!
So this is a little off topic, but I thought I’d share a little about what I’ve been up to this summer. Aside from the occasional barbeque, and camping trips, most of my free time has been spent on my bike, training for a little event called the "Laramie Enduro". The basic details go something like this: 70 miles, 8900 feet of climbing, all above 7500 feet of elevation. And it was last Saturday.
Needless to say I’ve been doing a lot of riding over the last few months – first some 25 mile rides, then 40 mile rides, and finally some 50-60 milers – all told about 1000 miles since early April. I have to say that the training for the race was much more enjoyable than the actual event. Like any endurance event, this thing is as much about keeping yourself fed and hydrated as it is about trail riding, and it’s one of the things I had to work on during training. After gobbling something in the area of 10 gel packs, dozens of electrolyte tablets, and several hundred ounces of water / cytomax, I found myself rolling across the finish line in 7:38, with just over 7 hours of actual riding time. All-in-all pretty good, as my goal was to break 8 hours. The first 50 miles to aid station 3 were actually pretty fun, the 10 miles to aid station 4 were tough seemed to last for ever, and the last 10 to the finish were easier but at that point I was pretty exhausted. For comparison, the first pro racer crossed the line in just over 4 hours and 30 minutes – ouch! But I guess that’s why they are pro bike riders, and I’m a software developer!
I’m not enough of a geo-geek to carry a GPS on this, but someone was – you can view the course in Google Maps or in Google Earth
So – now that this event is over, I should actually have some time to get back to some blogging!
Today I needed to get a country name from the lat, long of a point, ideally in a stored procedure.
Getting the country name is just a matter of calling the geonames web service via a handy dandy GET…
http://ws.geonames.org/countryCode?lat=47.03&lng=10.2&style=full&type=XML
which returns the following xml…
<geonames>
<country>
<countryCode>AT</countryCode>
<countryName>Austria</countryName>
<distance>0.0</distance>
</country>
</geonames>
Great, but how do we call this from inside a stored procedure? Initially I thought of looking at using .NET in the SQL CLR, but found some other code snippets that use OLE Automation in T-SQL to create an instance of ‘MSXML2.XMLHTTP’ to pull data. I thought I’d share since it could be pretty handy. Here’s the stored proc.
CREATE PROCEDURE GetCountry Declare @Object as Int; select @Url = 'http://ws.geonames.org/countryCode?lat=' + CAST(@lat as varchar) + '&lng='+ cast(@lon as varchar) +'&type=xml' Exec sp_OACreate 'MSXML2.XMLHTTP', @Object OUT; --load into Xml END
-- Add the parameters for the stored procedure here
@lat as float,
@lon as float
AS
BEGIN
Declare @ResponseText as Varchar(8000);
Declare @Url as Varchar(MAX);
Exec sp_OAMethod @Object, 'open', NULL, 'get', @Url, 'false'
Exec sp_OAMethod @Object, 'send'
Exec sp_OAMethod @Object, 'responseText', @ResponseText OUTPUT
Exec sp_OADestroy @Object
Declare @XmlResponse as xml;
select @XmlResponse = CAST(@ResponseText as xml)
select @XmlResponse.value('(/geonames/country/countryName)[1]','varchar(50)') as CountryName
The basic idea is to construct the Url, then use the MSXML2.XMLHTTP object to make the request and get the response. From there, we then cast the response into Xml, and pull out the values of interest via xquery.
Since this sproc relies on OLE Automation, you will need to enable this on your SQL box:
On the SQL Server box go to…
Close the tool and then the sproc should work.
As an example, running the stored procedure (i.e. exec dbo.GetCountry 47.03, 10.3) will return "Austria".
This could be easily extended to call any of the GeoNames web services, or any other REST service based on a GET. Heck, if you really get after this, you could do anything you want – you are working with the full blown MSXML2.XMLHTTP object which does all the Ajaxy goodness for Internet Explorer. Have fun!
I’m doing a technical review for some chapters on the Dojo Toolkit for an upcoming Wrox Press book on Javascript Frameworks. I suppose not surprisingly, the sample code for the server side code is php.
So, in order to be a good reviewer, I’m jumping into the PHP pool. I have to say that in reading the sample code, it’s a lot "closer to the metal" then ASP.NET, so this should be interesting to say the least.
So – should you want to embark on a similar journey, here’s the best info I could find on installing php as an ISAPI extension.
If you are running Vista SP1 or Server 2008, you can install FastCGI support and run PHP that way. The basic steps are outlined here.
Looks like things are up and running – php here I come!
It’s looking really dark outside and the trees are whippin around, so I brought up the weather channel’s radar map to see this…
Time to hunker down!
A reader recently asked me to expand upon the “Keep it Simple” advice in the fundamentals section of my web site. Just like my advice, I had kept this section pretty lean…
Keep it simple
Anybody can build complex software. Creating simple software that can accomplish the same task is much more difficult. In the end though, the simpler it is, the easier it is to test, which makes it easier to maintain, and easier to extend.
To illustrate the idea, I’ll talk about a project that I’m working on right now. Basically I’m helping / mentoring a team through a short term project to build a data viewer application based on Virtual Earth, Dojo, ArcGIS Server (9.2) and ASP.NET.
One of the user stories in this project is:
As an administrator I want the Data Viewer to be database agnostic so that I can easily configure it to pull point data from SQL Server, Oracle or file based data sources.
Now, this is a great idea, and certainly possible. In fact it ends up being very interesting to design (plug-ins, configuration sections and Inversion of Control oh my!).
In looking at the project (it’s very short term) and the team (new to web development) and the current problem they are trying to solve (display data from SQL Server), my recommendation to the team is that we “keep it simple” for now, and just address the SQL Server data source.
While we could define a set of interfaces, build out a whole configuration model, and create the actual data access objects for these various data sources, in the context of this project it’s extraneous. To be “successful”, we need to display the current data in Virtual Earth. With tight time frames and limited resources, I believe the tradeoff between building for an unknown complex future need, and applying time and effort to the core objective, is a good one. The team will be able to get the database access tier of the system completed in a short time, and it will be very simple to understand – parameters are passed to a class, which calls a stored procedure, which returns the point data. Simple, clean, and working.
But what about the “can accomplish the same task” bit? Good question – I’d suggest that in this situation, with the current data is in SQL Server, you are doing the same task – just using a simpler design to achieve the goal.
If / when a need arises to add data from Oracle, it will be a very simple task to create another class which mimics the SQL Server class, with the only difference being that it uses the Oracle data connection classes. Should this Data Viewer become a huge hit, and is used so extensively that it must become configurable by non-developers, it could then be refactored to add in the additional complexity required to support configuration sections and a plug-in data provider model. But for now, the much simpler solution works just fine.
So – to summarize: Make choices which trend towards keeping the code as simple as possible. Don’t add extra features or design elements to handle unknown or fuzzy future requirements. Add complexity only when it’s really needed. While it’s fun to monkey with internal design optimizations etc, keep your eyes on the prize: software that works for the user. And keep in mind who will be maintaining the software over the long haul – while you may be a whiz at generics (for example) keep in mind that for many people they tend to make understanding the code more difficult.
That’s pretty much my take on this, but I’d love to hear your thoughts on keeping software “simple”. How do you decide when to add complexity? How do you define complexity?
The Fourth Law of Software Design: Complexity vs. Ease of Maintenance