A VerySpatial Podcast
Shownotes – Episode 402
April 1, 2013
Main Topic: Our thoughts on geospatial development and some emerging trends
Click for the detailed shownotes Continue reading
Python Scripting for ArcGIS is a new text from Esri Press by Paul A. Zandbergen (2013). It isn’t the first Python book for the geospatial community or even focused on ArcGIS, but it is the first that has the Esri logo on it. Much like other recent books on Geo/Python we have seen, it focuses on integrating an introduction to Python with the industry specific materials. As Frank mentioned when he highlighted the book in a previous podcast, this allows users to gain exposure to Python, but it doesn’t fall back on the (in my opinion) bad habit of most programming texts of spending half of the book on the language and concepts before even getting to the application in the specific area. There is a time and place for that approach in Python specific books. When you add another software library to a book, then use it from the get go.
The text is broken into four parts including 1) learning fundamentals, 2) writing scripts, 3) carrying out specialized tasks, and 4) creating and using scripting tools. As you can imagine each of these parts builds on the previous through the book fourteen chapters. Early chapters take advantage of Model Builder to help the reader get into Python through geoprocessing tools, but by Chapter 4 the focus is on building and running code. The book comes with a DVD which includes data and code samples so that you can use the same data and code that the authors are running.
If you are looking to learn Python for use with your ArcGIS workflow, or a reference on the topic, this book is a good option for a growing bookshelf on the topic. The fact that you are using both Python and ArcGIS all the way through the book gets our support. With an MSRP of $79.95 and a current Amazon price of $48.45 the cost puts it in the range of similar books.
For the last few years, I’ve been doing all my interactive mapping development using ESRI’s Flex API. If you know me really well, you’d realize that’s a pretty big deal. No, wait, that’s the mother of all big deals. Now I should give a little background – no less than five years ago, I once declared that anyone who develops in Flash should be punched in the head, kicked down a hill, and be required to write Assembly for the rest of their professional lives using nothing more than an ZX81 Sinclair Computer. You’d be hard pressed to find a bigger Flash hater than me. Yet a couple of years ago, I found myself turning to the thing I hated most to get my day to day job done. The transition wasn’t easy. I sneered and drug my heals the whole time I was learning it. I said all sorts of bad things about Adobe, about Adobe’s developers, about ESRI’s choices in business partners, even about myself. I took long showers in the morning to attempt to keep the ‘Flash stink’ off of me. I even started avoiding Jesse in the halls because he would just sigh sadly and shake his head (Sue was ok to talk to because she was doing C#, so she knew all about programming in languages nobody likes or uses :). Honestly, it was a mess.
Here’s the thing that really took me by surprise – I found out I kinda like Flex. Strike that – I actually really like Flex. Once I got used to its particularities, the code was actually fairly elegant and simple. Skinning is really cool. I love the theoretical ability to separate form from function. I say ‘theoretical’ because in practice I’ve noticed people tend to just bundle the two together. I like the mix of XML based approaches and actual scripting. The modularization is rather nice. The ability to ‘draw’ my components on the screen is unlike anything I’ve ever used before in web development. I really like the fact there are multiple ways to do things. If I can’t get the skinning to work, I can turn to CSS to get the job done. Don’t get me wrong, there’s a bunch that annoys me about Flex. For instance, datagrids just suck. They’re ugly and annoying and I hate them. And who’s bright idea was it make it impossible to access a pure database via Flex directly? I gotta drop to another language to pull it off? Annoying. But that’s not really the point of this piece. The point is that I found out Flex was actually really powerful and allowed me to quickly create Rich Internet Applications with little to no cross browser testing.
Allow me to digress for a minute and underscore that last point – little to no cross browser testing. Anyone who has developed for the web will tell you the biggest pain in the rear is getting it to work the same way on different browsers. For whatever reasons, the browser people can’t come together and agree on one rendering engine. Really, that’s all we ask as developers – make the thing work the same in all browsers. Is that too much to ask? Every minute of time I spend trying to get things to work the same in four different browsers makes me want to send a bill for my time to Microsoft, Google, Mozilla Foundation, and Apple. I’m doing their work and I’m not happy about it. But as I said, I digress.
Where am I going with all of this? The point I’m trying to make is that we developers have to remain flexible in our approaches. Right now, the whole area of Rich Internet Applications is in turmoil. Silverlight looks abandoned, Flex has been pretty much tossed aside by its creator, Adobe, and HTML 5 isn’t even technically approved as a standard until 2014. We are kind of caught jumping from one cliff to the other. A whole lot of people are talking about HTML 5 as the future, but we aren’t there right now. As of this writing, I have three browsers on my computer. When I do an HTML 5 test (http://html5test.com/), Chrome version 21 gets 437 points out of 500 for HTML 5 compatability. Firefox 15.0 gets 346 points. Internet Explorer 9 gets a depressing 138 points. You can easily see how developers are going to have to fall back into cross browser testing hell fairly quickly. That saps development time and resources that are in scarce supply. My ultimate point is that HTML 5 still isn’t prime time.
Muddying the waters even further is the whole issue of mobile. I’m not sure I’ve been in a development meeting anytime in the last year and mobile wasn’t brought up at least once. It’s out there and it’s something with which we have to contend, like it or not. Do you go HTML 5 on a mobile browser so it works everywhere (in theory)? Do you go native? Do you sink the resources to do Android AND iOS, never mind leaving people like Sue running Windows Phone out in the dark?
What they do is underscore the importance of responsiveness in current and future Internet Mapping projects, and by ‘responsive’, I’m referring to developers and developing environments. We have to remain ever responsive because the world in which we work is ever changing, perhaps more so than ever before. The skills we learn today may serve us little beyond the abstract tomorrow. And that’s pretty darn scary. But it’s also pretty exciting. It’s a lot of work keeping up, remaining flexible, and responding to changes. It’s also kinda rewarding.