Enjoy Baking

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.

Cookbooks...

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.

Documentation and Doing Something

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 think about the tutorial style of books with a big example to follow, versus an API reference. Or the cookbook approach...how to X. Have any GIS books come out with a Cookbook approach? The closest thing I have seen is GoogleMaps Hacks- a neat collection of things to do with maps.

I think it is useless to argue about what is or isn't a GIS. For example, I have seen it written in a couple of places that Google Earth isn't a GIS. It certainly seems to meet the literal definition. I think Google Maps is a GIS as well. Why waste time with the label when you can just talk about specific capabilities?

Google Earth Enterprise...

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.

Data Monopoly, but open n-grams

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!)

Ruby Cookbook, Joel, Google, LISP, Stu, Scripting

[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?

Information Week on Flex...

Charles Babcock in Information Week wrote a horrible article on Flex2 last month that I just got around to reading...I love the use of the word "cranky" in relation to JavaScript. I have heard about cranky developers- but the language has always seemed rather good natured to me, although I can't say the same of the IE engine it runs in. The bit about the proprietary version of the international standard is also nice- reminds me of J++.

....Flex 2 implements a new version of the Flash scripting language, ActionScript 3.0, a proprietary version of the international standard EcmaScript. ActionScript competes with Ajax' notoriously cranky JavaScript and surpasses it when it comes object-oriented behavior...

And then they drag Mr. Raad into the debate- where he bluntly displays his view on the whole static vs. dynamic typing debate. I like Pragmatic Dave Thomas' thought on the matter- "once code hits the network, all typing is dynamic."

"ActionScript is a much more powerful language," said Mansour Raad, chief architect for a unit of ESRI, the supplier of geographic system services and software. ActionScript in its third version traps programming errors and enforces variable typing, which lead to clearer runtime results and avoids some tampering exposures. JavaScript, in comparison, "is kind of strange and loose. It let's you do anything you want and continues on its merry way."

Mr. Babcock didn't interview the pragmatic one, of course. But then, he's got think of the advertising dollars.

Don't get me wrong- I think the Flash player is very cool, and a good thing overall- see AFLAX, the various JS wrappers, using it to do XML parsing, etc. I think adding ActionScript and Adobe's XML variant into the development mix makes it not something I would want to do. I wouldn't touch the server side stuff.

I also like seeing Flash inside of an html container, interacting with the page. Having your whole app be a .swf seems silly. I think we should see more widgets like Adobe's cool charting widget- and less of the rest of it.