Monday, April 18, 2005

Language culture and the Ruby-on-Rails phenomenon

Ruby-on-Rails has been making a lot of noise lately, and a lot has been written about that. What I find interesting, though, is the varied reactions to RoR success that the different language communities have.

I follow a number of language specific blogs, and I think I at least have a decent sample of some of the web's most read bloggers in each of the Python, Java and Smalltalk communities, at least those involved in some way with web application development. For what is worth, I also follow a number of .net related blogs, but I am really not that well informed about the .net community. All I can say is that it seems from what I read that they rarely write about stuff not directly related to Microsoft development tools.

The Java bloggers have written a lot about this subject. For a couple of weeks, a blog post featuring RoR was almost guaranteed daily. Most of these posts also were commented on abundantly. What I found very interesting here is that very few people seem to really, really love Java. When confronted with Rails, many Java developers assumed that to work with a tool like that, they would have to switch languages. Some proficient J2EE developers mentioned that they were considering using Rails for their next project. As an example, David Geary and Bruce Tate, both of them authors of at least two Java books, will be teaming up to write a RoR book, after Geary initially dismissed Rails as just a CRUD scaffolder. That's a heck of a conversion!

Of course, a lot of Java coders were quick to dismiss RoR as a simple tool for simple web sites that never would scale. After all, they say, the first 'E' in J2EE stands for Enterprise. To them, Rails is ok for small, simple developments, but for large applications, well, only J2EE (ok, maybe also .net) is worth considering. Other than the charge that it won't scale, most arguments from this group against Rails focus on the low numbered current version (0.12.1), which to them speaks of immaturity, and the lack of static typing. It doesn't help to warm them up to RoR that David Heinemeier Hansson takes frequent shots at the J2EE community and is continually (and successfully) hyping his web framework. He also is not shy about constantly self-congratulating himself.

Over at the Python community, it seems that what truly bugs us is all that popularity Rails is enjoying. Many think that there should be a single greatest solution for all our web programming needs, like RoR is characterizing itself to be in the Ruby world. The feeling is that there is nothing that Rails does that more than one Python framework can accomplish, but that we should learn from the RoR guys about neatly packaging and presenting our efforts. But other than this, few Python people see Rails as such a big threat or think it is very innovative. The Rails folks claim 10x productivity over other web frameworks, but that is clearly referring to Java or .net frameworks, since Python frameworks also posses the single most responsible element for making RoR so formidable: a powerful, object oriented, dynamic language at its core.

Smalltalk web developers take it even easier than that. They applaud Rails success and are maybe just a little envious of its popularity, but they know that the key element there is Ruby's dynamic nature and in that regard they consider Smalltalk superior. Besides, one of the truly innovative web frameworks right now, Seaside, is done in Smalltalk. One thing is for sure, this crowd really love their language.

I think it is no coincidence that dynamic language programmers, even if they see in Rails a nice example of a web framework and perhaps something to emulate in their own languages, seldom consider a switch of development language or feel as insulted and threatened by Rails as their Java and .net counterparts. We know that what really makes us productive is the language underneath the framework.

Out of shape

I have been gaining weight lately. I don't feel I'm eating too much, but too little exercise and too much sitting in front of a computer reading blogs does this to you. Today I decided to go for a jog. I ran for about 10-15 minutes; took me 45 to get my breath back. I'm closing in on forty and feeling it. But I intend to persevere.

Friday, April 15, 2005

Compiling DCOracle2 for Oracle 10g

I finally decided to bite the bullet and find out how to compile DCOracle2 with the Oracle 10g client libraries. Turns out it wasn't that difficult, all I needed to do was to change all three occurrences of the word "dword*" to "dvoid*" (I learned about the required changes from this post from the Zope DB list) and then it compiled without problems. To avoid further connection problems, it is best to install Oracle's client libraries with the same user that the Zope instance has assigned.

Thursday, April 14, 2005

Database adapter trouble in Zope land

My company recently worked out an agreement with Oracle to port some of our products to the Oracle Database and I was assigned to the project. After examining the involved applications, I was happy to find out that the changes to the SQL used in them were few and prepared myself to do the work and finish it as soon as possible.

It turns out that the work was harder than expected, not because of the code, but because of the lack of a decent adapter for the Oracle Database. We need to use Oracle 10g for this project and DCOracle2, the only Zope DA that can work with a version of oracle higher than 7, is not being developed at the moment and the last update came in 2003. That means it doesn't work with versions of Oracle greater than 8. Well, according to what some people say on the mailing lists it can be made to work, but you have to tinker with the make file.

I am not sure I want to invest a lot of time fighting with the DCOracle2 setup, specially since opinions at the Zope DB mailing list lead me to believe that it is somewhat buggy and has trouble supporting some features. There is another adapter for Python, cx_oracle, and this one works with Oracle 10, but there is no DB adapter for Zope. I decided I would at least find out how hard it would be to write a Zope DA for cx_oracle, but it turns out that there is almost no information on that subject. If you search the zope.org site you get no results for this (which is kind of odd because the one article that I finally found was there), but if you are patient and dig into the mailing lists you can find an introduction to writing a DA, authored (I think) by Chris Petrilli. These seems to be the only information available on the subject.

I decided writing my own DA would not be a good idea for this project, given my time constraints, so my other option is to use an ODBC adapter instead. There is a ZODBC adapter available from Zope, but it is Windows only and also unmaintained. The only other option is mxODBC Zope DA, a commercial adapter by Egenix. It seems to be a good solution to the problem, but it requires an existing ODBC driver. That's certainly no problem in Windows, but for Linux you probably need another commercial product, so the cost is not small.

Anyway, we'll have to make a decision this week, so maybe we'll have to go the commercial route. I just thought by now Zope would have better solutions for this problem, so I am a bit disappointed. Part of the problem is the fact that even if there is an adequate open source solution for Python (which is the case here with Oracle but not with ODBC), there still needs to be a separate solution written for Zope's DA interface. Of course if we use a DA we get automatic transaction support and more from Zope's machinery, so I can't really complain, since I could theoretically modify my software to work directly from Python without using Zope's DAs (but if that's worth it, why use Zope at all?). Also, given that Zope Corporation is a consulting company, they have a lot of pressure to make their developers work on tools that their clients require, not on community member wishes, so I totally understand their decision to stop supporting DA's.

Sunday, April 10, 2005

Squeak or VisualWorks

I have decided to take a closer look at Seaside. I plan to write some application with it to learn Smalltalk and at the same time see if Seaside can be my web application server of the future. My problem now is figuring out which version of Smalltalk I should use for this. My two candidates right now are Cincom VisualWorks and Squeak. I want cross platform capabilities, so Dolphin and Cincom's Object Studio are out. If I missed any important candidate please let me know.

VisualWorks is a commercial product, but you can download a non-commercial version that includes everything. VW is intended for business use, so you get a lot of tools for stuff like database access and COM support. It comes with excellent documentation and includes first rate development tools. Squeak is a free product and has an active user community, it is also the environment on which Seaside was developed.

I have downloaded both of these environments and will post some of my experiences with them here.

Wednesday, April 06, 2005

A little hype never hurt anybody

Just a day after I posted this, Martijn Faassen has some interesting things to say about the lack of attention from the Python developer community to the Zope 3 project:


If we want Zope 3 to be popular, what we need to do is learn the lesson of Plone, learn the lesson of Ruby on Rails, and do presentation well, and attract new people, from outside the immediate Python community, to Zope.


I couldn't agree more. In my experience, even Plone, with its clean and polished look, seems boring and plain to many would be users, but it is clearly the best positioned Zope product right now. I really have heard this claim of a boring design more than once: "Why does every Plone site look the same?", but if you stop to think of it, this is really a compliment to the Plone design team. The Plone look is attractive enough that many users just install their portal and put their logo at the top and then consider it done.

So, a lot of its popularity has to do with the attractive design, but another factor that Plone has in its favor is the user friendly setup executable that allows aspiring content managers to have a fully working (and also clean looking) site in a matter of minutes, together with their cool Windows Plone control panel which lets casual users stay away from configuration files. That's a lesson not lost on the Ruby on Rails camp either, witness their 10 minute setup video. Since learning a development tool really well (even Rails) requires a heavy time investment, you need a quick hook, a gimmick if you wish, to attract a huge prospective audience to that first try. When the hype calms down and the cloud of smoke disappears, what you have left is a user community.

As of now, Zope 3 doesn't seem to have something like this. If anything, its XML based configuration and what to some developers feels like an excessively academic stance on web development, plus the admittedly psychological factor of the memory of Zope 2's huge learning curve, make it seem somewhat daunting to learn.

Anyway, I think it would help Zope 3 a lot to have an easy way to create a first application, automatically generating the required configuration files. That and a cool web site to hype it like crazy all over the net.

I really haven't looked into Zope 3 very deeply, other than read the online book written by Stephan Richter, and the very interesting comments about it made by various Zope and Python luminaries. Still, I think that the lessons learned over nearly 10 years of BOBO/Principia/Zope development and applied to this web development platform by the Zope 3 development team, will result in a very powerful piece of software. I intend to look at Zope 3 in more detail in the next couple of months and post about that in this blog, just in case anyone reading this is interested.

Tuesday, April 05, 2005

Where is Zope going and will we go there too?

I discovered Zope and Python in 2000 and started using them for our company's projects almost immediately. Until then, we had used Perl for most of our web sites, but the only real Perl hacker we had was no longer with us. We had used PHP for a number of internal projects with mixed results. We also had used Java heavily for a desktop application (I know, there's nothing I can say in my defense) and I was very disappointed with it.

In those days, DTML (Zope's templating language) was the preferred way to develop web applications in Zope. Well, maybe not the preferred way, but the only semi-documented one. So we began to create web sites with it and gained some expertise in Zope development.

Over the years, we began to slowly switch from building simple web sites to full fledged web applications. At the same time, we began phasing out DTML in favor of the new Zope Page Templates and dabbling a little with pure Python products. We also began moving code out of the ZODB (Zope's object oriented database) and into the file system. Like other web developers, we really learned Python mainly because Zope was built with it, but looking back I now think it is maybe Zope's greatest asset.

Today our style of development is close to what could be described as Zope best practices. We develop full Python file system based products, use Subversion for version control, document our code with Epydoc and clearly separate the view from the logic using ZPT and its macro support.

However, the time has come when it may be necessary for us to change paths. Zope is near a crossroads with version 3 almost out the door but apparently not many current developers planning to switch very soon. Meanwhile, Ruby has been gaining the spotlight with its Rails web development framework. Rails seems to have a huge advantage over Zope in ease of use, specially for first time developers. It has also generated a lot of hype, perhaps a bit unfairly to such a well thought out project as Zope 3. Of course Rails is not the only cool web development technology out there. It certainly isn't the most innovative either. For my money, Seaside, a web development framework for Smalltalk, is the most interesting and innovative tool on the radar.

Basically then, those are my three candidates for web development framework of the future at our company. Zope 3, Rails or Seaside. Of course, it could also be a wise decision to stick with Zope 2 for the time being. What I would really hate to do, though I know it is a distinct possibility because of market forces and current management here, is to switch to J2EE development. That's why I want to take these other tools for a ride before it's too late. I better start learning.