Yes, this update is very cool. Three lines of code added to my little Ruby application with XML builder to support it:
xml.TimeStamp do
xml.when(event_date.strftime('%Y-%m-%d'))
end
gets added to every xml.Placemark do
makes:
<when>2006-08-28</when>
</TimeStamp>
that animates your map view. This was in the old enterprise client, but a little buggy and nowhere near as pretty. In a word...wow!
Joel Spolsky, famous for the Joel on Software blog, is a funny old man. He's been doing a lot of hating on Ruby and Java for a while now. His latest complaint about Ruby is idiotic...it comes down to the fact that it's not fast enough for big calculations. I guess we are all missing something- but what big calculations is his bug tracking software doing? Does it fix the bugz in your code?
Most Rubyist use c extensions in those cases. I used to drop out of Avenue to call signal propagation algorithms written in c++ rather frequently. Even in Java, we used JNI calls in various places for image processing code. And then the c and c++ programmers drop into assembly for the truly ludicrous optimization requirements. And then we buy an FPGA and do it in hardware. Has anyone tried orthorectification with this stuff from Cardio Logic?
In his quest to have a flexible high performance language, Joel is actually using a custom language based on VBScript (that compiles to...VBScript) for his little web app. To ease deployment. And it's called Wasabi.
Dion's satire is amusing but I have to point all to Jeff Atwood's excellent deconstruction over on Coding Horror. A snippet:
"For instance, two weeks ago we found out that Joel's company wrote their flagship product, FogBugz, in a proprietary language they created themselves.
FogBugz is written in Wasabi, a very advanced, functional-programming dialect of Basic with closures and lambdas and Rails-like active records that can be compiled down to VBScript, JavaScript, PHP4 or PHP5. Wasabi is a private, in-house language written by one of our best developers that is optimized specifically for developing FogBugz; the Wasabi compiler itself is written in C#.
You couldn't possibly have heard it, but that was the sound of fifty thousand programmers' heads simultaneously exploding.
Writing your own language is absolutely beyond the pale. It's a toxic decision that is so completely at odds with Joel's previous excellent and sane advice on software development that people literally thought he was joking. He had to write an entire follow-up post to explain that, no, he wasn't kidding. "
So, should we all continue to pile on poor old Joel? I have been looking at his stuff with a much more sceptical eye this year, but I am thinking about not looking at all anymore...sigh.
If you haven't read Scott Ambler's Agile Database Techniques, I recommend it. I didn't realize how spoiled I was to work on projects where the database could be create by scripts, until I worked on projects where an evil DBA controlled all access to everything. It was some small comfort to see "all access to database through stored procedures" as one of the problems to be handled with legacy systems in the book. I haven't read Refactoring Databases yet, but it's somewhere on my todo list....
The next step, once you have the database scripted is scripting the changes to the database. The Rails ActiveRecord migrations approach is really cool for this, and there is no reason it should be applied outside of Rails, as Dion points out... Basically it gives a way to step back from any change, in addition to scripting each changeset to the database. Beyond all of that, it gives you a database neutral method for describing the database itself, making migration to another database platform more of a possibility.
Is the biggest danger of having a DBA on an Enterprise Application that they are going to write code that locks you into a technology? No- I think the bigger danger is that they are non agile and that they won't know how to deal with changes to the database that occur at the rate agile projects demand.
Spammers are apparently now creating spam tickets in open online bug tracking systems, and then linking to those spam tickets other places. Justin's bug tracking system is being hit by this...it really sucks. Everything Web 2.0 style, with users adding content to your site, is going to need a Captcha system, in addition to all of the cross site scripting and other security measures.
The whole Captcha thing, it is an inverse Turing Test- one where people are trying to prove they are people to programs (versus programs trying to prove they are people to people). It's getting pretty hard to do- machines are getting better at reading those fuzzy images. I don't know when they'll be able to solve the hot or not one though. I have trouble with those... Even crazier is that people are solving Captcha for spammers to get access to porn...crowd sourcing. I wonder if people are using Amazon's Mechanical Turk for this?
I am saddened to be getting more traditional spam slipping through my GMail filter. First it was complete nonsense, now it's idiotic pump and dump stock schemes and the usual prescription drug and sex stuff. It's making email far less relevant to youngsters that prefer chat- it's harder to spam, for now. Pervasive advertising...bleeaaurrgh.
I love this quote from Ian MacKaye, as quoted by Salon.com, as quoted by the 37 signals guys in Getting Real:
The bakery
American business at this point is really about developing an idea, making it profitable, selling it while it’s profitable and then getting out or diversifying. It’s just about sucking everything up. My idea was: Enjoy baking, sell your bread, people like it, sell more. Keep the bakery going because you’re making good food and people are happy.
–Ian MacKaye, member of Fugazi and co-owner of Dischord Records
( from Salon.com People | Ian MacKaye)
I enjoy baking (software). I think if you are running a services company- you basically have to like it. Now that we've built up our little business to a fair number of people on staff, why would we sell it so that everyone could go back to working for a big company that didn't appreciate them? I'd rather buy up someone else's business.
There are a few results on google for "GIS cookbook"- not much of substance.
A rundown of a couple...
I did find this CSISS cookbook: It's got separate recipes for ArcView 3.x, 8.x and 9.x, and not really a cookbook, as noted by a slashgeo commenter. However, it's about the best there is and widely referenced.
There's an Arc/INFO one:=Slightly dated and very small. But still good
There's a Swedish/Phillipine one being put together for Local Govt Units...can't find the actual book, but it sounds like something useful.
There was ESRI UC paper in 2003...
I have some ideas about what might be good to have in such a cookbook- having enjoyed a few selections from that O'Reilly series, including the recent Ruby one. Maybe a collaborative web site would be a good start. Several promising places to stick such a thing.
Are your users stuck in "P" mode?:
For most of us, the problem was NOT that we couldn't learn how to use anything but automatic "P" mode. The problem was that we didn't know why or when to use anything else.
It wasn't simply a camera problem--it was a photography problem. The camera manuals describe precisely how to turn the dials and push the buttons, but never tell us why we'd want to. They focus on the tool rather than the thing the tool enables (taking pictures). What good does it do to master a tool if we haven't understood (let alone mastered) the thing we're using the tool for?
Sounds a lot like some of the new ESRI effort around documentation that was announced at the GIS Faire/User Conf...I think the user community aspect is big too, whether it's a conference or a BBS to share data on, community builds that common knowledge amongst users that can grow far beyond what the actual creators of a product know about what can be done with it...I have been using Google Earth Enterprise for a while- mostly from a consulting/developer/support role, not as someone that keeps a system running on a day to day basis. I also have to be careful with what I can and can't say about these things due to various agreements under which I am signed up.
Thus, it is cool to see someone who is a daily user blogging about it on a regular basis.
A recent post over there was asking about differences between working with GEE, versus other server GIS applications.
One point that I would add as a difference that takes a while for people that have a lot of experience in the ESRI world is that the build process is quite extensive. It takes quite a large amount of CPU cycles and disk space to build the base map data into the database- hence the reason for building the base data on some kind of weekly or greater frequency. (You use KML for stuff that changes frequently.) The payoff for this increased build time is the remarkable performance that users experience with the Google Earth application. Everything is really well precalculated for display, so you end up with a great user experience, at the cost of a not insignificant amount of labor on the back end to keep things moving. Still, it is something a lot of customers have taken some time to get their heads around, because they are used to expecting real time data in the base map. It's a very interesting architectural tradeoff analysis.
I know people in the GIS community have been talking about the Digital Globe data deal with Google for a while, but it is interesting to see it begin to intersect with Tim O'Reilly's Open Data concept... One thought- at least when Google licenses data they show it to you- when the govt gets its hands on things. Still, an exclusive license on data does sound somewhat monopolistic. Will a future Google anti-trust case be fought over data?
"....portions of DigitalGlobe's imagery data has been licensed by Google for exclusive use in Google Earth/Maps.
...reminding us of Tim's argument that Data is the next Intel Inside -- a source of competitive advantage. The question is of course whether this competitive advantage should be granted for exclusive use or whether the data itself will eventually be regulated by anti-competition laws."
The killer advantage of Google Earth is the data. It's a great application, but the cheap data is key.
Google has lots of data. In one of my previous jobs in computational linguistics- we would have had a lot of fun with their release of n-gram data *really it's 1,146,580,664 5-grams. I have been quite impressed with Google's statistical machine translation... I am looking forward to what they do with information extraction. Hey- at least the data is free. (And it's not the personal data AOL is giving out. Poor old AOL...trying so hard to get "with it". bye!)
[long linky post...] I've reading/trying out the Ruby Cookbook this week. It's pretty amazing, and keeps getting in the way of the boring parts of my life, like the rest of my todo list. 850+ pages of cool stuff. Just the list of things you can do on the "Offical Unofficial Site" should give you a good idea of what it is capable of...
My KML Builder script keeps getting better and better- I am feeling confident enough now to build a GML script...okay, not that good yet. For the unitiated, Builder is a cool library that lets you write XML like this:
x.date {
x.year "2006"
x.month "01"
x.day "01"
}
which makes:
<date>
<year>2006</year>
<month>01</month>
<day>01</day>
</date>
The guy who wrote Builder, Jim W., it got the idea from Groovy, the Java scripting language, which has something quite similar. Fortunately not patented... Anyway, while the above example is really simple, just having it in idiomatic Ruby makes a lot of other cool things possible.
Speaking of things possible, Joel S. just wrote an interesting article which has pointed out some of the cool features of JavaScript (and ActionScript!), amongst other languages that treat Functions as Real Things. It's kind of like function pointers, but more flexible.
One of the upshots of this that Joel points out is that this kind of knowledge is required to understand things like Google's MapReduce (nothing to do with Cartography, btw)- which is why he is dismayed that Java is the instructional programming language of choice at the university level. Hey Joel- at least it's not PASCAL and Modula-2, not that I don't have a soft spot for TurboPascal. I know we can't all go to MIT and learn LISP, but maybe we should, now that this is available... I am thinking about recommending this to every developer in my company, am I nuts?
On that note, as Stu Halloway pointed out in a Ruby class that I scheduled for my company and my clients this week- Ruby is getting close to meeting Paul Graham's ideal programming language that has all of the nine ideas of LISP. By the way, Stu is an amazing instructor. If there is something that he knows about that you want to know about, I would make all efforts to get him to teach it to you. His knowledge of subjects is quite deep- and he brings all of that depth to the surface.
So, what does it all mean? We are approaching VB for the Web- Dabble DB is hot stuff, as is Rails, of course. We are are figuring out the basic operations of the current technology wave. It is getting to the point where the code that you actually need to write is potentially expressed in the language of the business- aka Domain Specific Languages, DSLs. Was the Arc/Info command line a DSL for GIS?
I spent all of this time trying learn "the right way to do things", which was about formalism and complexity, and now I am back to striving towards simplicity and writing things in scripting languages. The subtitle of the Ruby Cookbok? Recipes for Object-Oriented Scripting. My life is getting easier. Is it getting so easy that I am going to be redundant? This is how not to get outsourced- learn about what the mission you support is really trying to do- this technology stuff is going to be in the box soon! (hahahaha)
It's also about marketing yourself. I don't have much of a brand yet. Anyone want to write a book on Google Earth with me?
