chanson

Programming:WebObjects is an open-content book on WebObjects that's taking shape on Wikibooks.

Pierce T. Wetter III's great mailing list post this past May comparing WebObjects versus Ruby on Rails for Ajax is there as part of a section on comparisons with alternative technologies.

Furthermore, information on the Ajax framework in Project WONDER — the Open Source collection of enhanced frameworks for WebObjects — is also part of the book now. (An overview of Project WONDER is available as part of Wolf Rentzsch's CAWUG presentation. Of course, there's an overview of Ajax in WebObjects too, which will come in handy when additional resources are added.

If you're doing WebObjects development and you're interested in adding Ajax support to your application, check it out! And if you have any tips and tricks for working with WebObjects, why not contribute them?

Ten years ago today, NeXT released WebObjects 1.0: Their new platform for creating object-oriented applications that ran on a server and whose functionality was delivered to client desktops through a web browser. You might have called it an application server.

WebObjects was the first of a category of platforms now worth billions of dollars annually. And it's still one of the most advanced.

If you're running Mac OS X 10.4, WebObjects 5.3 is included with Xcode 2.1 and later. Download Xcode 2.2.1 from the Apple Developer Connection member site — you can do so for free as an Online member — and check it out!

Update: Thanks for the props, Wolf! It's been really cool to see all the great things you've done with WebObjects over the years.

David Heinemeier Hansson, creator of Rails at 37signals, takes James McGovern — some Java/J2EE author — to task for his über-lame rant against Ruby in the Enterprise in a great post titled Boy, is James McGovern enterprise or what!

So by Enterprise, Architect, and Enterprise Architect standards, this gent must be the top of the pop. Thus, allow me to make this perfectly clear: I would be as happy as a clam never to write a single line of software that guys like James McGovern found worthy of The Enterprise.

If Ruby, Rails, and the rest of the dynamic gang we're lumped together to represent, is not now, nor ever, McGovern Enterprise Ready™, I say hallelujah! Heck, I'll repeat that in slow motion just to underscore my excitement: HAL-LE-LU-JAH!

With that out of the way, we're faced with a more serious problem. How do we fork the word enterprise? The capitalized version has obviously been hijacked by McGovern and his like-minded to mean something that is synonymous with hurt and pain and torment.

Indeed, McGovern's rant reads more like a parody of a rant than the real thing:

13. Lets say there is a sixteen week project and the productivity stuff was true and Ruby could save me an entire three weeks which would be significant. Since Ruby is a new vendor and not represented by existing vendors I already do business with, do you think that I will spend more than three weeks in just negotiating the contract?

Yes, because there is some vendor out there named "Ruby that you need to sign a contract with before you can begin a project.

Despite his claims to be agile, McGovern obviously doesn't know the first thing about agile development. People come first, sure, but agile development doesn't say that tools aren't important. Not using good tools makes it harder for good people to do good work.

That's why I love developing software for Mac OS X and why I love helping people develop software on Mac OS X: We have great tools like Cocoa, Core Data, Interface Builder, OCUnit, WebObjects, and Xcode, and these can be used by great developers to do great things.

I just figured I would take some time out for a public-service announcement.

If you're developing Mac OS X software, you should really be on the appropriate developer mailing lists. Apple hosts a number of mailing lists at lists.apple.com and hosts archives there too. The lists are managed with GNU Mailman and have its convenient subscription and administration interface.

In my opinion, the principal lists for application developers are:

carbon-dev	Developing software with the Carbon framework.
cocoa-dev	Developing software with the Cocoa framework.
java-dev	Developing software for Mac OS X in Java.
webobjects-dev	Developing web applications with WebObjects and EOF.
xcode-users	Using the Xcode Tools suite for Mac OS X development.

There are also a whole lot of task- and technology-specific lists, including lists for developers implementing AppleScript support in applications, developers working with networking, developers creating device drivers, developers writing multithreaded applications, developers working with Xgrid...

Be sure to look through the list of lists to see what else you can take part in.

Along with the release of Xcode 2.2, WebObjects 5.3.1 was also released.

Here's some information about the WebObjects 5.3.1 update.

This guy must be kidding. Introduction to Model/View/ViewModel pattern for building WPF apps (John Gossman):

Model/View/ViewModel is thus a refinement of MVC that evolves it from its Smalltalk origins where the entire application was built using one environment and language, into the very familiar modern environment of Web and now Avalon development.

Yeah, because Model-View-Controller is just so inadequate when you're using visual human interface construction tools to create desktop applications or web applications.

I mean, it's not like anyone else has had an "interface builder" as an integral part of their platform. Or tools for creating web applications out of reusable and composable "web objects."

I titled this "Xcode 2.1: WebObjects 5.3 Development" for a reason:

Xcode 2.1, included with every copy of Mac OS X v10.4 Tiger, comes with the WebObjects development tools, including a new version of the WebObjects Builder HTML application design tool and a new Xcode designer for Enterprise Objects.

Yes, that's right. Free in Xcode 2.1.

Jon Rentzsch created an online video tutorial wherein he creates a simple weblog in 15 minutes using WebObjects.

Darrin Cardani has also been putting together online video tutorials demonstrating how to use his Effects Essentials plug-ins for Final Cut Pro and After Effects.

This is a great idea! It really demonstrates the power of the technologies involved and shows you how to harness it yourself in real, practical ways.

I'm going to be talking at the next Cocoa and WebObjects User Group (CAWUG) meeting. It's at 7PM next Tuesday, October 28, at the Apple Store North Michigan Avenue.

Alex Johnson of Site9 maintains an iCal calendar (subscribe via iCal).

Here's the summary of Chuck's IOKit talk and what I'm allowed to say about my talk. I'll post more details tonight about what I'll actually be covering, after Panther's officially released.

IOKit by Chuck Remes

Chuck has worked on an ethernet driver for the DEC Tulip chip set and will discuss IOKit. IOKit provides all the basic services to develop a hardware or software driver for darwin (or OS X). It is a powerful toolkit that let's the programmer bring all the power of OOP to the world of drivers, allowing such things as subclassing, method overload, and driver stacking. This presentation will provide a high-level 45 minute overview of some of its basic features and principles.

Xcode & new Cocoa features in Panther by Chris Hanson

Chris Hanson of bDistributed.com will go over some of the additions to Cocoa included in Panther, as well as the new Xcode IDE and the updated Interface Builder.

Ryan Dawson has a new weblog at LonghornBlogs.com. In his first post, he says:

Apple is shipping, so what? We don't care what is shipping right now; I don't think we need to get into an argument over quality and who will win out. But, from our perspective as designers, we care about what is in the pipeline. Microsoft has longhorn. Apple, show us what you are working on.

Microsoft is showing what they're going to ship in several years in an attempt to head off comparisons of what they're shipping now with what Apple is shipping now.

For example, some features in Longhorn appear to be direct responses to features in Mac OS X. A vector-based imaging architecture with assistance from hardware 3D cards? Mac OS X had the former in 10.0 in 2001 and the latter in 10.2 in 2002. (Actually, it's worse than it appears, NEXTSTEP had the former in 0.8 in 1988.) Avalon, which looks like either a knock-off of either WebObjects' Java Client or Direct to Java Client from 1999 or so (if not earlier). And so on.

Let's say you're a potential customer and you say to a vendor "X does foo. Can Y do foo?" The vendor can be honest and say that Y can either do foo or not. Or, the vendor can dissemble and say "Y+3 will do foo!" They're comparing an existing product to vapor, and vapor is coming out ahead. (What a surprise!) Nonetheless, if the pitch is good enough, you might just decide to go with Y under the assumption that it's moving towards Y+3. Of course, that doesn't get you foo now, but hey, it's coming, right?

That's exactly what Microsoft is doing. Apple's not releasing detailed information on the 2006 release of Mac OS X because they're simply not willing to play that game. Microsoft has essentially infinite resources, and can go tit-for-tat on vapor with any vendor on the market in any software product space. Why would you knowingly play a game you're going to lose? Instead, Apple is countering vaport with real, shipping product — a strategy that has some chance to be effective, especially since Microsoft is both telegraphing and pulling its punches!

Hmm. Microsoft is trying to tell everyone exactly what they're going to release, as if what they eventually release will bear any resemblance to the initial hype, and they're saying it won't be ready until 2006! In that time frame, Apple may have three more major releases of Mac OS X, and each is likely to have amazing new features for both end users & developers and enterprise users & developers. The question isn't whether Mac OS X now is competitive with Longhorn in 2006, it's whether Longhorn will be competitive with Mac OS X in 2006.

Lots of people in the weblog universe are talking about the upcoming Microsoft Professional Developers Conference in Los Angeles. The PDC is where Microsoft is going to be shipping their first development release of Longhorn, their successor to Windows XP.

There are a whole lot of code names being used for various different parts of Longhorn. Aero, Avalon, etc. Just keeping track of the code names is a full-time job.

One of these, Avalon, corresponds to some new application framework that people like Scoble keep hinting will make the browser obsolete. They say it'll do this by turning the operating system into some sort of fancy information environment. Here's my prediction for what Avalon really is...

I think Avalon will do the following: First, it will let developers specify their application's interface via XML, probably through a graphical interface editing utility. Second, it will let developers bind model objects directly to interface elements. Third, it will let these model objects reside — somewhat transparently — on a server, rather than on the client side. Fourth, it will exist as a runtime that is included in Longhorn, so an actual Avalon application will consist of an assembly containing only the XML interface files and the code for the model objects or model object proxies.

In short, Avalon will be an implementation of something Apple has had for several years now: WebObjects Java Client. With Java Client, you build your interface in Interface Builder, which generates an XML file. You use the EOInterface framework to bind interface elements directly to model objects and operations on them (queries etc.). The model objects live on a WebObjects application server, but they can have custom client-side proxies that you can add your own logic to. The Java Client runtime is a jar file that can either be downloaded to the user's machine as necessary via Java Web Start or as a Java applet, or it can be installed directly on a client machine.

There are two twists to this: Java Client works pretty much anywhere you have a Java 2 Standard Edition 1.3.1 or later virtual machine. That means you can deploy Java Client applications to Mac OS X, to Windows, and probably even to Linux and Solaris and all sorts of other platforms. More importantly, though, Java Client is itself just a foundation for Direct to Java Client.

Direct to Java Client automatically generates Java Client applications on the fly from a data model and a collection of business rules. You can customize the objects used in the data model and you can customize the business rule set to customize your application; you don't need to spend your days in Interface Builder laying out interfaces for CRUD (create, read, update, delete) applications.

Avalon sounds like great news for Windows desktop application developers. After all, in 2006 they'll be able to get benefits that have been available since the late 1990s with WebObjects!

What's up with all the people claiming iTunes is Apple's "first Windows software"?

Haven't these people been using QuickTime to watch movie trailers?

Haven't these people heard of ClarisWorks, or FileMaker Pro? Or WebObjects?

Apple has released plenty of Windows software over the years. iTunes is only the latest.

Ian Wij, Writing Code is Stupid

Get thee to WebObjects and take a look at Direct to Web and Direct to Java Client. Oh, wait, he's a "Microsoft Consultant." Never mind.

It's not clear if that means he's a consultant specializing in Microsoft non-solutions, or if he's actually providing consulting services on behalf of Microsoft. Either way, he loses because he's going to continue to wait for Microsoft to slowly reinvent what some of us have been using for a good long while.

One of these days I might just make good on my threat to develop Direct to Cocoa using BDRuleEngine and GNUstep Renaissance. Or maybe if I talk about it enough, someone else will go ahead and do it for me and I can just use it. (Yeah, that's the ticket.)

I just set up Apache name-based virtual hosting on my company's deployment server. The only twist was that you have to specify a port number on the virtual host directives, because SSL doesn't want to play nicely with virtual hosting by default. But other than that, it took a whole five minutes to get working!

There's also an Apache 2 adaptor for WebObjects now, available as a part of Project WONDER. Once I install WebObjects 5.2 on my server, I'm going to try to make it all play together.

But not right now. Now I have far too many other things to do before MacHack and WWDC.

The Enterprise Object technology provides a set of flexible, modular, and mature object-oriented frameworks that allow you to build data-driven applications without needing to worry about an application’s data sources. It allows you to work with objects rather than directly with the data source, which reduces development time, reduces the amount of code you need to write, and allows you to build reusable, portable business objects that can be shared between many different applications.

That's an excerpt from Enterprise Objects, a new bit of WebObjects developer documentation that's been sorely needed for quite a while. Lots of us OpenStep and WebObjects developers rave about how cool the Enterprise Objects Framework was; now there's a good place we can point people to and say "See?"

One thing that's jarring in the document is that Apple is apparently changing the name of EOF: It's now just "Enterprise Objects" and is used as a modifier, as in "Enterprise Objects frameworks." (Yes, they say "frameworks" rather than "framework" — I suppose because EOF is really made up of EOAccess, EOControl, and EOInterface.) This is probably for trademark reasons; trademarks can't be nouns, only adjectives or adverbs. (So that's not a Kleenex® you're using, it's a Kleenex® facial tissue.)

(Thanks to Jim Roepcke for the pointer! I hope we can both make it to WWDC this year, Jim...)

Working from a hint Jon Rentzsch gave me on Wednesday night, I was finally able to get a WebObjects 5.1.4 application to deploy on my RedHat Linux box.

It turns out that WebObjects insists on using hostnames. It was refusing to start the application instances I created because I tried to use the IP of the machine everywhere, rather than the hostname. So I created an entry in /etc/hosts for the machine, assigned a hostname, and restarted, and it all Just Works now like it was supposed to.

It'd be nice if this was documented somewhere easy to find. But hey, now I know. And maybe someone else does too.

My next tasks related to this box: (1) Hot upgrade to RedHat 8. (2) Wipe and reinstall with the latest everything (RedHat 8, WebObjects 5.2, FrontBase 3.6.10). (3) Put the damned thing into colocation already.

Early this morning, I shipped BDXmlRpcForWO 1.0.0, an Open Source framework that lets any WebObjects application vend XML-RPC web services with just a couple lines of code in your application's constructor.

All you need to do is register the XML-RPC request handler, and then register a class whose public methods you want to expose via XML-RPC. In other words, it works almost exactly like the SOAP support in WebObjects 5.2.

BDXmlRpcForWO requires WebObjects 5.1 or 5.2 (though it may work on earlier versions too, I haven't tried) and Apache XML-RPC 1.1.

I wrote it in a couple hours after skimming an article in the January, 2003 issue of Linux Magazine by Rogers Cadenhead. It described how to use Apache XML-RPC. I thought, "Hey this would be easy to wire up to WebObjects!" And it was!

Oh, and AppleScript's web services support is pretty cool, too. It let me test my request handler really easily.

David Simpson, Installing Oracle 9i on Mac OS X, Part 1 (O'Reilly Network Mac DevCenter) Customers who currently host FileMaker Pro Server on Mac systems may now consider upgrading to an Oracle database running on Mac OS X if they need better performance, recoverability, or the advanced replication features available within Oracle.

Uh, what? I'm glad Oracle and Sybase are both supporting Mac OS X, but frankly, we've had a better database avaialble since the Mac OS X Server 1.0 days: FrontBase.

FrontBase has advanced replication features, versioned isolation, full SQL92 compatbility, full Unicode and collation support, no stupid limits on VARCHAR column width or the number of BLOB/CLOB columns in a table, etc. - Big Name Database features - at not only a fraction of the cost but a tiny, tiny fraction of the investment.

I personally wouldn't bother with either the Big Name Databases or the Open Source databases. FrontBase beats either. It's inexpensive - there's a low-end free license, paid licenses start at US$1000 and have great feature sets, and high-end licenses are also very reasonably priced - and the support is better than you'll get from either set of vendors. Plus, to my knowledge it's the only database on the market that's fully SQL92 compliant and the complete Mac OS X package is a 5.6MB disk image. That's right, under six megabytes. And it's feature-competitive with Oracle. And there are former Oracle customers who have switch to FrontBase because it performs better. (The RPM for Linux is even smaller: 3MB! That's because it doesn't include the nice graphical administration application.)

Not to mention it's far, far, far easier to administer. It has a great Cocoa-based administration application on Mac OS X, that can administer both local and remote databases. Oh, and the fine people at FrontBase have created scripts to help you migrate your existing FileMaker Pro and MySQL databases. Oh, and they have great WebObjects and Cocoa supprot out of the box...

Oracle and Sybase are definitely a marketing win for Apple. I'm glad to have them on the platform - more competition will make the market a better place! But for people that are setting up new databases - even enterprise-class databases - or who want to migrate their existing Access, FileMaker Pro and 4D solutions to a higher-end system, I have to recommend FrontBase over the more established players and the Open Source players. It's just that much better than either.

I'm giving a short presentation at the next Chicago Cocoa and WebObjects User Group (CAWUG) meeting this coming Tuesday.

Jon Rentzsch is going to give an overview of Direct to Web, the rule-based system for generating web applications automatically from your data model in WebObjects. Following Jon, I'll be discussing BDRuleEngine, my Open Source framework for building rule-based Cocoa appliations.

More details, including the location, time, and where you need to RSVP if you're thinking about attending are in the meeting announcement at StepWise.

(The RSVP thing is important because the meetings are at Apple's office in the Mercantile Exchange Building in the Chicago Loop, which became access-controlled after September 11, 2001.)

I now have a PC almost ready to put into colocation.

The PC itself is an AMD Athlon XP 1500+ machine I bought from Century Computers. It has a KM266 chipset, 1GB of PC2100 DDR RAM (which I bought from MemoryX and installed myself), and two 40GB disks (7200 RPM). It's a pretty unremarkable machine, really, but it works and it was cheap.

It's running Red Hat Linux 7.3 Professional, FrontBase 3.6a, and WebObjects 5.1.3.

Getting Red Hat Linux set up was a royal pain in the ass. Red Hat's default disk partitioning is utterly screwed up; it didn't give me enough space in /var to actually update all of the packages installed as part of the operating system with up2date! How stupid is that? So I wiped and reinstalled, and had to fight the interface to the stupid disk partitioning tool in order to get it set up how I wanted it. How did I want it set up? On drive 1, I wanted the usual 48MB (or whatever) /boot partition, followed by swap space, followed by a single huge / partition. And that's only because it complained at me about not having a separate /boot partition; I would have rather had just a single partition per disk. Drive 2 is a single partition that's going to serve as backup for the time being.

Also, convincing the machine to start Apache at startup was stupidly difficult. You'd think that since I told Red Hat I was going to use this machine as a web server that it would start it automatically, but that would be too easy. I had to use /sbin/chkconfig --add httpd to add httpd (not apache as one might think) to the startup process. But wait! That didn't add it to the startup process! What did it do? Evidently, it just made it visible to the startup process. To actually add it to the startup process, I had to use /usr/bin/ntsysv -- whatever the hell that stands for -- to go through a little list and put a check next to httpd. Then, finally, it would run at startup.

All in all, the Red Hat installation and administration experience was significantly worse than that of Windows. And I'm a Mac OS X guy, so from my perspective it really sucked!

Getting FrontBase, Java, and WebObjects set up was far, far easier. FrontBase and Java were both utterly trivial, since they were provided as RPMs. (I'm still amazed that the FrontBase RPM is only 3.2MB in size, since FrontBase is such a competitive RDBMS.) WebObjects was a little more difficult to set up, but that's only because Linux isn't a supported deployment platform.

Google pointed me to HOW-TO: Setup WebObjects on Linux by Stefan somebody at TET Labors in Germany. (He doesn't sign it, so I'm just guessing from his email address.) It's based on the journal Jon Rentzsch kept last year when he was putting together a WebObjects deployment server running Linux. Fortunately, life is considerably easier now.

Here's what I did differently than in the HOW-TO: First, I didn't install my own version of Apache. I just used the version of Apache that came preinstalled with Red Hat, so it'll be automatically updated by up2date and because I can't imagine how much my life would suck if I tried to make my own version of Apache interact with the Red Hat startup system. I also installed the Java2 version 1.3.1 (update 04) SDK instead of 1.4, because WebObjects is really only qualified against 1.3.1 right now. (Maybe when WebObjects 5.2 ships it'll be qualified against 1.4, and I can upgrade.) I also had to adjust the instructions to refer to the proper paths:

• Apache's configuration files are in /etc/httpd/conf
  
• apxs is at /usr/sbin/apxs
  
• Apache's header files are in /usr/include/apache
  
• Apache's default cgi-bin is at /var/www/cgi-bin
  
• Apache's default document root is at /var/www/html

I think that was it.

All in all, it didn't take me nearly as much time to get it working as I thought it would, and it seems to be working just fine. There's only a couple more things I want to get installed and configured before I take it to its new home on the South Side: Webmin, Mailman, and some additional security stuff.