First day impressions…quite REST-ful

Excellent first day at the ESRI Dev Summit.  The big story from my persepective was a pair of sessions summarizing the REST and JavaScript APIs being released at 9.3.  Dave has already provided a pretty good summary of the plenary, REST, and JavaScript API stuff over here so I won’t reiterate or reinvent the wheel. Suffice it to say that I echo the comments of others in that I’m impressed with this latest stuff from the dev team. DOJO based, Web 2.0, HTTP Goodness…it’s all there.

While I didn’t make the dev summit last year, I can say that this year’s message in terms of interoperability and integration so far has been entirely different from what I heard at the first conference. The first year that ESRI held this event I asked a lot of questions about OGC and interoperability and got some pretty non-commital answers. This year at the summit I’ve been here a day and we’ve had all sorts of mashups (VE, Google, Yahoo Pipes, etc.) as well as a demo viewing Image Server in a bona fide OGC client from Carbon Tools. This combination of ESRI technology with other vendors and standards within the Web 2.0 paradigm is frankly pretty exciting.

Other good news…there is no charge for using the REST or JavaScript APIs.  You do of course need an ArcGIS Server instance to leverage the REST stuff and to have a base map, but assuming you have access to map data, you could still roll your own REST API for whatever technology you are using (SQL 2008 Spatial comes to mind) and leverage the JavaScript API with no problems.  All good…

ESRI dynamic display…some limitations

Recently I was working on a portion of a large ArcEngine development project in which we had requirements to draw a large number of point features in the map at changeable time intervals as short as ½ second in such a way as to avoid the map flashing or blinking at the user.  A brief look out on the ESRI site pointed me to the IDynamicMap interface and a pretty comprehensive example of how to use the dynamic map to rapidly render dynamic features.  There’s a whole nifty little dynamic display API that supports rendering in this environment.So off I went, charging down that alley and I subsequently bothered to carefully read the “destructions” as well as the limitations page describing what the tradeoffs are that you make when using it.  The two biggies that stood out immediately were the diminished rendering quality and the lack of support for labeling/annotation.  Sacrificing map quality and labeling for speed makes sense on an intellectual level , but wasn’t going to make the client happy because the maps that were being published for consumption by ArcEngine featured labels and annotation as a prominent part of the map content and the user base wasn’t going to accept funky looking maps.  Several other things that weren’t on the list reared their ugly heads only after I’d done some development and testing and were even bigger deal breakers for me…just thought I’d call them out here in case anyone else is evaluating this approach.

ESRI Dev Summit Day One…all checked in and ready to go

Day one here in Palm Springs and I’m all checked in and got my “bag-o-swag” for the ESRI Dev Summit and am looking forward to the week’s events.  It’s been good to reconnect with a few colleagues that I haven’t seen in awhile and meet a few new folks.  Having been away from the Geospatial realm for a year or so before landing in my current position, it’s good to come back to the well and drink the kool-aid every once in awhile.  Attended the blog meetup last evening which provided a good opportunity for those of us who are constantly cross posting and tracking back to each other to put names with faces.

Lots of ArcGIS Server goodness on this year’s conference agenda which will be good for me.  I’ll be focusing primarily in the AGS realm; specifically on the SOAP and REST API topics in anticipation of several projects we have on the horizon.  We’ve got some mobile work on the docket as well so I’m encouraged to see a few sessions focusing on that.  The projects I’ve been on of late have been primarily ESRI desktop and Engine based so I’m looking to refine my skills in the web realm and brush up the rusty spots.  I’ll try to post several times over the course of the conference with random thoughts and impressions so stay tuned…

My boss is on the internet…

Yeah, I haven’t been real regular about posting here lately, but we’ve been overrun with conference prep and putting out fires and the blog has taken a back seat. 

Speaking of conferences…here’s a shot of some of my crew at the GITA conference in Seattle. 

http://virtualearth4gov.spaces.live.com/Blog/cns!369B39F890CE30C1!779.entry?wa=wsignin1.0

We’re sharing a booth with the VE guys at Microsoft.  Sorta funny to be able to call your sales manager and tell her to tuck her shirt in…

Next week we’re off to the ESRI conference so its a busy travel month for all.  More to follow…

Agile evangelism for my own team

So about once every quarter we try to get our entire geospatial development staff together in the same room for a couple of hours to catch up with everybody.  It’s a “dinner-n-learn” type of thing after hours where we might cover new projects and developments within the company, recognize heroic acts by team members, and one member of the team will give a presentation on new technology or some hot topic that they care about.  Well it was my turn at the pulpit this week and so I worked up a presentation introducing agile software development approaches focusing on Scrum. 

Multi-threading musings

Recently, my team and I have been working on an SOA implementation that uses some relatively “expensive” ESRI COM objects within the services tier.  For example, instantiating an IWorkspace can take a long time, relatively speaking.  Since ArcObjects are COM-based, clearly multi-threading isn’t going to solve all of our problems due to the thread affinity of STA objects, however if there is a long running WCF service that uses these expensive objects, we can create a “pool” of service connections complete with cached objects and have them ready for use by consumers of the service…effectively front-loading the performance hit to the service startup process.

So what we wanted was a managed thread pool…separate from the default thread pool so we’re not stealing resources from the core application…and nobody really relishes the opportunity to build their own thread pool from scratch.  At least I don’t. For info on when not to use the default system thread pool, check out Chris Mullins’ excellent post over here.  Here’s a couple of options we explored in the hopes that someone may find them useful.

Agile in your architecture process…where to put it?

Of late, I’ve been struggling with how to integrate formidable architecture tasks for large projects within the Agile process.  Small projects, maintenance work, pretty much anything that is well understood is OK for “Design as you go” or “Design only what you need” type approaches.  But a ground-up design and build of a large system really almost requires that some general patterns and principles be set forth in advance. 

• “ArcGIS Server will support the need for spatial data in the web tier”
• “Does the client have an ESB in place?”
• “We’re going to have a provider pattern for the data tier….”
• “We’re going to use a service broker…”
• “We’ll use SODA for data access…”
• “The UI will be Microsoft CAB…”

…are all the types of examples I’m thinking of.   

Clearly doing a full on discovery and architecture for 6 weeks defeats the point of agile processes by hamstringing your ability to evaluate and adapt on down the line. Plus it’s a waste of time…you haven’t done stories yet, you haven’t prioritized features and functions with the client, and you’re likely to either miss something or design for an eventuality that will be tossed out later.  You’ve also short circuited the effectiveness of iterations and sprints by hopping in your ivory tower and demanding all the information up front.  So what’s an architect to do?  Well, first thing’s first…you need to remember your core values of courage and humility.  If you can do that, then read on…

Plug it in! Configurable plug-in execution…code

Last week I posted a rather verbose discussion of some modifications to a PlugIn pattern that  I made to make each plug in configurable at run-time, accepting different parameters as inputs to discrete running instances of a plug-in.  The point being, rather than having plug-ins that do repetitive tasks with little or no run-time customization, I wanted users to be able to tell the system exactly what the plug in should do through some sort of configuration UI. For example, “Send Message” wasn’t good enough…I wanted the message to be sent to a configurable address (or fax number, or MSMQ) with a personalized subject and message. My goal was to build out a test project and provide it all here but I’m swamped right now so I’ll provide some of the API mods and code examples here and maybe get back to a more complete implementation later on (in all my free time).

Since my IPlugIn interface and the method for fetching plug in information using System.Reflection largely follows the example that I found here, I won’t delve to deeply into that. But let’s look at some of the mods I did make…

2008 ESRI Developer Summit…anticipation

Got the go-ahead last Friday and booked my travel for the 2008 ESRI Developer Summit.  And I managed to get a hotel to boot! Pretty excited to be going this year…for one it’ll likely be a good ArcGIS Server brush up for me…I spent about a year away from the geospatial industry and only recently leapt back in so I missed the 9.2 goodies. For another, it’ll be a good break toward the end of the winter to renew old friendships, and make a few new introductions.  In contrast to the user conference I really feel this event is great not only for its technical education aspects and face time with the ESRI tech folks, but also for getting exposure to how others do things, getting new ideas for upcoming projects, and generally putting yourself and your skills out there for a sanity check every once in awhile.

Looking for work? Think I’m full of malarky? Just want to say hi? If you recognize me flag me down in March…

Musings on offshore development

The last few large projects that my team and I have worked on have involved the use of offshore development resources as a supplement to the onshore (stateside) development team.  I can see why companies lean toward the relatively economical pricetag of offshore developers, but the results I’ve seen are so varied that I’m still not convinced that this approach is for everyone, despite the fact that the industry seems to be rushing headlong in this direction.

Back in 2006, Martin Fowler published a good article on how to make the most of your offshore development resources here. In addition, Stephanie Moore, Liz Barnett, and Kimberly Dowling have collaborated on a well thought out article on how to leverage Agile processes and offshore development resources effectively.  Despite the dates on these articles, I think their points still hold, but in cases where my teams have had the most success, I’ve noticed some distinct trends. In addition to the advice given in the articles above (and the advice of others too numerous to list…just go a google’n) I’d add (or re-inforce) the following: