Sunday, December 18, 2005

Ruby updates

Even though I should probably be coding, or doing the books, or something else useful, Andrew Glover's basically hype-free Ruby off the Rails (an good intro for Java developers) is up on IBM's developerWorks.

There's also a new Manning book, Ruby for Rails coming out in April that focuses on learning Ruby as you build with Rails.

Finally, this isn't anything new, but the Ruby Scripts for SketchUp page is full of cool stuff, but I am still waiting for them to release some things related to their Google Earth integration. You can find some references in their forums. If you have seen those really cool 3D models of buildings that people have been throwing together, you may not realize that building models is pretty easy compared to other 3D tools.

I think if the decision had been made this year, ESRI might have chosen Ruby over Python for ArcGIS scripting. As it is, I am glad they have kept a simple language in there, even if it isn't Avenue...

5 comments:

Sean Gillies said...

Doesn't ESRI ship Python 2.1? That seems to imply that they made the decision over 4 years ago. I bet Ruby is still at least a year from being on the radar of anyone at ESRI.

Anonymous said...

Ruby may be on the radar, but not as a scripting tool. I know with 9.2 they are supposed to have their own Python compiler, rather than use PythonWin or ActiveWin. As soon as they bother with PythonESRI, you can be sure they ain't worrying about Ruby any more than they are about Perl or PHP.

Matt M said...

sean, that's what I think...Python was probably on a similar adoption curve then, and popular with lots of Linux hackers, which means it will be around for a while. It's interesting to hear that they are doing their own Python compiler...but not entirely surprising.

Sean Gillies said...

Their own compiler? What problem are they trying to solve? As I understand it, people find geoprocessing in Python to be slow. I've looked at some of the scripts people hold up for help in the support forums. It seems to me the problem is that people are processing feature-by-feature, and possibly incurring some overhead for each feature. Maybe all they really need is a way to process lists of features in one go. The geoprocessing object could take an iterator, for example, instead of single features.

Steven Citron-Pousty said...

I am speaking on this one who has joined ESRI WAY after they made the decision to add python. Back when they added python, it was still in the stage (maybe a little more mature) that Ruby is now. And as someone who is at ESRI now, there are people talking about Ruby. That's about all I know on the subject.