Good morning. I'm happy to be here to tell you all about the Leopard Server and how it's an excellent web platform. It's got an unprecedented level of integration between Apache, MySQL, and PHP. So let me get right to it. I'm a senior engineer in the server and storage technologies group. This session is for anyone with an interest in web server on our Leopard Server platform. Server administrators, because we're going to be talking about our server administration application. Web application developers, we've got some very exciting things there. And database administrators, we're focusing on MySQL database server.

I'm going to tell you about some of the general platform architecture issues, talk specifically about Apache, PHP. I'm going to talk about scalability because the emphasis has previously been on development. But we're very interested now in the deployment of web services. So we have some scalability solutions for you here that we're excited to tell you about. MySQL and Ruby on Rails are now on our platform. And we have some special guests here, so we're going to have an extended Q&A to take advantage of the opportunity.

These special guests, William Rowe representing Apache, Rasmus Lierdorf representing PHP, and John David Duncan representing MySQL. We're very happy they could take the time to come here and join us, and we're very happy for their contributions to the open source portfolio of projects that are out there. These are some of the most important open source projects that we have.

So first some background about web platform architectures. You typically, the simplest case, the sort of degenerate case, is serving static web pages. That's not very interesting, but it's sort of the step zero. A front end web server serving static content. It gets a little more interesting when you add serving dynamic content, serving data from the file system, servicing put requests instead of just get requests. And as your sophistication level increases, it's common to add a database manager to the mix.

And it gets really interesting when there's too much load to handle on one machine. In that case, you typically set up some sort of a proxy mechanism, a load balancing mechanism so that you can offload some of the requests from the primary machine to secondary requests, or offload the request to secondary servers on the same host. So there's a proxy mechanism for that.

These technologies for web services fall into clusters, I guess you could say. LAMP is probably the one that has the most recognizable name, Linux, Apache, MySQL, PHP, or maybe sometimes Perl. But there's also a J2EE cluster, sort of a Java enterprise cluster. And then of course, Microsoft has its own view of the world with their .NET architecture. And Apple has its own solution in this space, as for many years, WebObjects. These are just different ways of packaging.

So we believe that our platform now with Leopard Server has the strongest web stack available. Not only does it have web objects, but it has Mac OS X, underlying platform, Apache, MySQL, PHP. It has load balancing, it has Mongrel, it has Ruby on Rails. It has our world class graphic user interface for administering the web service and the things related to it. And it has 64 bit support, so if you want to run your services in 64 bit mode, you have that option now. So let me go into some detail about this platform integration.

Apache, you have your choice of Apache 1.3 or 2.2. PHP, you have your choice of PHP 4 or PHP 5. We have a portfolio of scalability solutions. We have language plugins that I'll be talking about. We have FastCGI and we have Load Balancer. We have the spectrum of scalability solutions.

We have a plan for Leopard to upgrade MySQL to version 5 and I'll be telling you about some of the features of MySQL 5. We have Ruby on Rails and we have the Mongrel Web Server which really works nicely with Ruby on Rails. The last bullet here though is perhaps the most important. It's running on top of our Mac OS X platform.

This is a rock solid, Unix based, secure platform. It has a server administration applications and it has 64 bit support. And the message that you should take away from here is this is all pre-installed, it's all integrated, you don't have to download this and download that. You certainly can of course, but we want to make it so easy to use out of the box that you can just turn it on and have access to all these services.

So I mentioned the two versions of Apache and two versions of PHP. We give you a primary flavor with Apache 2 and the PHP 5 module. We also give you the legacy flavor with Apache 1.3 and the PHP 4 module. And of course, either of these or both of these can talk to PHP 5. A little bit more about Apache now.

We know that some of our customers require the legacy web server. We can't force them to move to Apache 2. There are various reasons. First of all, it's good enough for a lot of applications. It's running about two-thirds of the world's web servers. It has enough features for most users, will probably for some time to come.

And the thing that is going to keep some customers on that platform, and something that we certainly respect, is that some of the third party Apache plug-in modules have not been ported to the Apache 2 API. So we respect that requirement and we're going to support Apache 1.3 in Leopard Server.

But we know that most of our customers will prefer the leading edge web server. So we offer Apache 2.2 as the default and primary web server on Leopard Server. It has built in memory caching, it supports large file downloads, it has support for 64 bit executing that continues to improve.

It's much easier to piece together. The webdav and SSL modules are now bundled with it instead of being separate installs. And perhaps most importantly, the Apache organization, very energetic, very capable organization, they're putting their resources into the future as we would expect them to. They're adding new features to the Apache, to the trunk version, and they're backporting most of those to the 2.x series. Of course, Apache 1.3 is out there as I mentioned, and it will continue to be supported with security fixes and major bug fixes. But the real action is in the Apache 2 world, so that's where we're putting our resources as well.

So some detail about this Apache 2. It has an improved architecture relative to Apache 1. They basically rewrote it from the ground up is what I understand and it shows because the feature set is really growing rapidly. One of the key features of Apache 2 is it supports different MPM or multi-process model options. So you can have a threaded version or a pre-forked version which doesn't use threads but rather uses processes to serve multiple requests like Apache 1 did.

And we looked at these alternatives and we looked at the threading, not so much the threading of PHP but some of the libraries that different PHP extensions depend on. Until those are universally thread safe and until we become more comfortable with the threaded implementation of those versions on our platform, we're going with the pre-fork model of Apache 2. Which, as I said, it's similar to the Apache 1. In some ways it's a less than a pre-forked version. It's a less drastic transition from Tiger to Leopard because of this.

And we will continue to look at the libraries that PHP needs in order to consider sometime in the future switching to one of the threaded models. Perhaps the worker MPM, perhaps the event MPM which is coming along. So for now you have the pre-fork model. And this evolved Apache 2 API. It does require porting of modules, but it has a bucket brigade model which allows those modules to participate more closely in the processing of requests and to gain access to the request as it works its way through Apache with more comprehensive control.

More details about Apache 2. It allows more flexible deployment. It separates the proxy mechanism from the caching mechanism. So now you can administer the memory cache or the disk cache, the HTTP 1.1 compliant memory cache. That's turned on by default. You may notice that the web proof cache is no longer part of the picture with Apache 2. Apache 2 has its own built in memory cache.

Improved proxy mechanism allows load balancing as well and we are very excited about the load balancing mechanism, and I'll be talking about that and showing you that a bit later. Finally Apache 2 as I mentioned has improved 64 bit support. It has this support mainly by improvements in the Apache portable runtime layer, the layer that sits underneath Apache. And protects it from the details of what particular machine it is running on. So we're excited about the performance opportunities that are available with 64 bit.

So Apple has for many years had its own set of authentication and authorization modules running within Apache 1. These generally allow you to authenticate someone who's, a user who's defined in the directory rather than being defined in a file like an htaccess file or an htdigest file. We let you get these out of the directory, the open directory.

And we've ported all those to Apache 2, the basic authentication module. And in that particular case we added authentication caching because it really speeds up performance for certain network based users where the user has to go to the network to authenticate as opposed to being a local user. That can take several tenths of a second per authentication so by adding the caching we have really sped that up.

Digest authentication, we've not only ported that but we've re-ported it to the server. We've ported it to the server but we've re-implemented it on top of mod auth digest. Apple's authentication module for digest used to be implemented on top of the older mod digest but now there's mod auth digest.

It was experimental with Apache 1 but now it's a fully supported module in Apache 2. So we have re-hosted our implementation that supports directory based authentication on top of mod auth digest. And finally we've ported our Kerberos. The Kerberos authentication was new in Tiger with Apache 1. And that is now available with Apache 2.2 as well.

Moving on to some additional modules that Apple has written to extend the functionality of Apache. There's the web based searching of local documents, spotlight connection, we've ported that. The Mod Bonjour to allow the website to register itself and be browsable by Safari on the network without typing a URL, that's ported.

The secure realms, we expect that that will be fixed inside of the Apache 2 core. The deal there is that in a case sensitive file system like HFS, there's a potential security exposure if we didn't have this module, where a user could bypass the security realm by typing the URL with a variant case, typing an uppercase X instead of a lowercase X to get around this. Well, Mod HFS blocks that and we expect that that will not be necessary with Apache 2, because they are doing some good work to handle canonicalized file names in Apache 2, so we expect that that will be unnecessary in the future.

The next module grouping is mod encoding and a customized version of mod_dav called mod_dav encoding. We've replaced that, actually we've sort of evolved that with Apache 2 to do the same thing that it did back in Tiger. And what it does, it allows you to access the web_dav with file names that are fully internationalized instead of requiring a specific ASCII or Latin style characters. And finally, we had mod_mac_binary which used to allow you to type a URL slash dot bin and that would automatically mac binary encode the download. We don't see a demand for that anymore so we did not port that over to Apache 2.

So we give you your choice now. If you've attended some of the other sessions, the server overview yesterday, you saw that we have two kinds of clean installs now with Leopard Server. We have a clean install, an advanced clean install, and we have a standard clean install. So when you did a clean install for Tiger, that was very similar to what we now call the advanced install experience.

But we've given you, for people who don't need all these decisions to be made, who just want to have a turnkey system with a small number of services, we have now something called a standard install. So you don't get Apache 1, you don't get PHP 4, you don't get any config translation from Apache 1 to Apache 2. It gives you just a very simple, basic Apache 2 service.

How do we make both versions of Apache 1 and Apache 2 coexist in the file system? We just simply segregate them. If you're familiar with Panther or Tiger, you saw Opt Apache 2, which contained a sort of evaluation version of Apache 2.0 off to the side in its own subdirectory. We've now integrated, obviously, Apache 1 and Apache 2 into the file system. They coexist and as you see on the slide, they just have different file names.

different different names for folders and files and binaries and so on so if you've if you've got an apache one configuration and you don't want to undo all the virtual hosts that you've created and all the security realms that you've set up all the special configurations that you've taken care of in apache 1 on tiger we provide you an automated way to translate that from apache 1 to apache 2.

there are some syntax differences between apache 1 and apache 2. we have a little ruby script that manages that for you so when the administrator is ready i mean you can you can do a clean install or you can do an upgrade install and pick apache 1 and stay with it for as long as you run leopard server but when you decide to make the change we trigger this translation script and And I'll show you how that works in a few minutes.

One thing to note about this translation process, it's a little bit dangerous to translate people's config files. And we do not do that irreversibly. We leave the old configuration unmodified in place. And we also provide a log because not all translations are going to succeed if you do certain things.

We try to support all the different things that we anticipate, but we know that administrators will do things that none of us can anticipate with a script to translate config files. So we provide a log that you can use to go back and look and piece together what happened during the translation attempt and recover.

So this is a view of one of the panels of the Service Configuration Assistant. And it's a very simple panel. It just gives you a choice between Apache 1 and Apache 2. So when you select in this user interface Apache 2.2 and you're already running Apache 1, it will run the script transparently and you'll be translated.

And if it fails, the little button If it fails to do the translation, the button won't change to 2.2, it'll stay on 1.3. And that'll be the cue that you need to go look at your log files and see why the translation did not occur. And then at some later date you can do the translation and hopefully it will work. But we expect that for the overwhelming majority of configurations the translation will simply work and you can run Apache 2.2 when you're ready.

So now I mentioned scalability a bit earlier, I'm going to give you some detail about that now. We know that scalability The first thing that comes to mind is to, instead of running a CGI script separate from Apache, to put the processing for that language inside of Apache. That's what ModPerl and ModPHP do. They speed up the execution of Perl and PHP dramatically by putting it right inside Apache.

You don't have to start up a separate process. Another mechanism for scalability that was kind of popular in the mid 90s or late 90s and is getting some renewed interest now is FastCGI. So we give you ModFastCGI on Leopard Server and we also provide the various libraries and bindings that things need in order to take advantage of that.

Finally, there's a much more mature and much more powerful scalability mechanism, the reverse proxy mechanisms. And ModProxy Balancer, now for the first time with Apache 2.2, enables us to really manage that and it's very powerful and we'll show you a bit of that later. So let me talk about these languages that can be embedded into Apache, or that are candidates anyway, for embedding into Apache.

First, PHP. We're putting PHP 5 on Leopard Server. It has quite a few features relative to PHP 4. Maybe the best one is the better object model that you can take advantage of. There's improved error handling, more flexibility when talking to MySQL, improved XML, better performance, the Zend engine has been improved, and the language has some nice features that make writing and reading code easier, exceptions and iterators.

If you have PHP 4 scripts, there are several options that you have. Most of them will just work in a PHP 5. And if for some reason you want to, you know, you may have valid reasons for staying with Apache 1.3, PHP 4 is available in the Apache 1.3 side of things.

And I think a final option is that PHP 5 has this PHP 4 compatibility mode, so if you set this Zen Z1 compatibility mode directive in your PHP.ini file, that should allow PHP 4 script to run with full PHP 4 script. So you can have PHP 4 compatibility even though it's being interpreted by the PHP 5 Apache module.

Next, Perl. We have Perl version 5.8.8 on the platform now, and we have a plugin for Apache 1 and a plugin for Apache 2. So Perl is going to be fully supported for Leopard Server for both platform variants. Python is fully supported on the platform. We do not have a mod Python plugin. One reason is that Apache 2.2 is not supported by the existing stable mod Python. We're looking at how that evolves. And if it does evolve to be a stable mod Python for Apache 2.2, we will look closely at putting that on our platform.

It's important to note that we have added to the underlying Python language, we added a couple of plugins. A SQLite plugin, a plugin that allows XML parsing to be easier, and a plugin that lets you get at Apple's extended file system attributes like file system ACLs, for example.

So the last language I'll cover here is Ruby. We have 1.8.4 on Leopard at this point. We have not incorporated mod Ruby. We believe that the people who run Ruby are more interested in the proxy based options for scalability rather than having a mod Ruby built into Apache. So I'll be talking about the proxy based options. There are bindings for fast CGI so you can achieve scalability for Ruby applications.

and David Schmuck, and the team that's been working on this project for a long time. And finally, and perhaps most exciting, is we have the Mongrel Web Server, which is written mostly in Ruby, but pieces that are really, the HTTP parser part is written in C. It's a very fast, very nice web server, it's very new, but it's on your platform, and I'll be talking more about Mongrel in a bit.

Mongrel is one of several web server choices. Most of these are on our platform. Let's talk about different web servers and their different attributes. Apache is the known quantity here. It's got some happy dogs and some unhappy dogs as you see in this graphic. It's not lightweight by any means.

It's not easy to configure, except to the extent of course that in our graphic user interface we hide a lot of the gory details of configuring Apache from administrators. But as a standalone web server, Apache is not known to be easy to configure, whereas it is a scalable, mature, and very flexible web server.

Light PPD, another option for people. It's not currently installed on our platform. It's not the most mature and it's not nearly as easy to configure as some of these other options. Webbrick comes with Ruby on Rails and it may not be as scalable, but as you see, you see how it stacks up relative to these other web servers.

But the thing we are most excited about is Mongrel. It's only a disadvantage right now that we can see is that it's new, but aside from that it's very flexible, very scalable, it was written mainly to be fast, and it was written to be easy to configure, and because it's so natural for Ruby on Rails and because we're very excited about the amount of interest in Ruby on Rails, we've added Mongrel to your platform.

So, Leopard Server now contains Mongrel. A little bit more about it. It's really perfectly suited for Ruby on Rails web applications. It's gaining a lot of support. It's bundled as a gem, which is how you bundle extensions to Ruby. And this is the version that we have on our platform.

So another scalability option is FastCGI or Fast Common Gateway Interface. I mentioned this was sort of a 90s technology. It's interesting again for a lot of people because it's a way to talk to web applications and people with Ruby on Rails and other web based applications have been using it so that Basically what it does, as the graphic shows, it allows you to keep a daemon running and talk to that daemon from Apache instead of having a CGI launching every time a request comes in. So it's a form of a fast CGI protocol. And we pre-install ModFastCGI on the platform now so you can use that if you want. But the most exciting one is this balancing architecture. Yak, yak, yak, I need water.

So this works in a couple ways. The web interface, Apache 2, using Mod Proxy Balancer as sort of the switching point here, it farms requests out to multiple instances, either running on one machine or running on a bank of, you could have a bank of XSERVs in a closet, providing these web applications on the back end. They could also be running web objects, so Mod Proxy Balancer is a crucial mechanism now going forward for balancing requests across multiple web objects servers.

This is a screenshot from Server Admin. It's not on the DVD that you have, it's too new. This is part of the Server Admin web application. and it shows a panel that's brand new. It's on the per virtual host section. It's called the proxy, the reverse proxy. You have for many years been able to manage a conventional or forward proxy and you can still do that with server admin on a global basis but we've added it as a capability on a virtual host basis to manage reverse proxy. So how does it look up close? A checkbox to enable it, a path that indicates where in the URL space are requests coming to trigger the proxying.

and the, probably the most important section is this table in the middle, the Balancer members. So these are the things, these are the URLs of back end web services. In this case they're running on the same machine at 127.0.0.1, just listening on different ports, multiple rails applications running on the same machine.

And if you want to edit one of these URLs, you get a sheet that drops down, and you can configure that specific member, change its URL. And by the way, we discovered these by way of Bonjour. So we've tweaked Mongrel a little bit to register with Bonjour, and we have a Bonjour browser built into the backend of Server Admin Web. So this pop-up, which shows URL candidates, is populated by way of Bonjour.

And finally, the checkbox at the bottom of this new panel in Server Admin to manage proxies, reverse proxies. This checkbox, Allow Dynamic Balancer Administration via Web. This enables administrator access with proper authentication to this, which is a special URL, something something slash balancer dash manager. This is a panel provided by Apache in their mod proxy balancer module and it lets you dynamically configure these things that we've talked about.

So if you click on one of the URLs, you'll get the ability to edit the details about that. That's actually the balancer group that we see editing here. So characteristics of the Balancer Group like a session ID, timeout and so on. And if you, actually that's actually a better view of what I just talked about.

If you select a specific worker, one of these 127.001 balancer members or workers, You get this panel. It lets you control the load factor and that's kind of a cool thing. And that was also on our server admin panel. If you decide that one server is more capable or more deserving or should be punished more, you can give it more load.

And you can say give 90% of the load to this member of the group, give 10% of the load to this other member of the group. That's especially useful if you have your balancer group distributed across multiple physical machines. Now a bit about MySQL. We're going to cover some of the new features and talk about 64-bit MySQL. So MySQL 5 adds quite a few new features. Tiger, as you know, contained MySQL 4.1.

And the reason that that's so appealing is because of the new features that MySQL 5 has. Stored procedures, here's a hello world script that's written as a MySQL stored procedure. Here's an example of a trigger so you can watch what's happening to a table and take some action when something, in this case, before an insert happens on this account table. It will start calculating a sum.

A view is simply a shorthand way of, it's like a handle for a query. So in this case, or a handle for a part of a query. So in this case the bottom line is select star from v, where v is sort of the view or handle for a lengthier query, a select statement.

The last thing about MySQL is that it is now manageable within Server Admin. So, MySQL is a fully supported service within the Server Admin application. No more stand alone, separate MySQL Manager application, which you could only use locally. It's now part of Server Admin, therefore it uses our authentication mechanism, our model, our nice user interface, and it's usable remotely. And it manages the pre-installed MySQL as it always has. So now I'm going to introduce my fellow software engineer Lionel Desai. He will tell us about 64-bit MySQL performance and some of the things that we've learned about that.

Thank you. So I'm Lionel. I helped out a bit with the MySQL thing. So what is DemoBath? Demo is basically to showcase the flexibility of 64-bit MySQL and the performance that you can gain when you use this flexibility. The basic, or the main advantage that everyone knows about moving to a 64-bit process model is that you have a larger process virtual address space. What does that mean? Basically you get an easier access to a really, really large amount of physical memory.

So the server that I'll be using, for example, has 8 gigabytes of memory. Why did we choose MySQL to do the 64-bit demo? MySQL ships with a number of caches and somewhere around, I think, version 4 and onwards, MySQL ships with a query cache. The main job of this query cache is to cache the query statement and the associated result set.

There are two limits you need to know about this query cache. One is the query cache size, which is self-explanatory. It's the size of the query cache. And then there's the query cache limit, which basically dictates the maximum size of a result set associated with a single query.

So, you know, a single query doesn't just blow your query cache. But since we want to keep the demo small, I'll be running the same query, a simple select query, twice. And so I'm going to set the query cache limits to the query cache size. So let's start with... MySQL 32-bit.

And I'll just show you the config file. As you can see, on the left hand side, the query cache is set to 32 meg. The query cache limit is set to 32 meg. The config file I'm using is the my-huge.cnf. It ships standard with MySQL, and this machine has enough RAM, 8 gigabytes, as I said earlier, to support this configuration. Nothing much has changed. Here it is. And I'm going to run a simple monitor script over here to show what we can see. There we started. And I'll start the query. And I'll show you what the query looks like.

The query is a simple Connect query. As you can see, select nothing big. Ah, OK. So being a simple select query, if you look carefully, you'll see that the query cache size is decreasing, and you have a query cache insert. So basically, for statically served web pages, this is a good thing, right? The query cache is full. Next time around, you'll get a faster result. This query should last somewhere around less than a minute.

Oh, yeah, that's the MySQL D and the PHP CP utilization. Look at the virtual size of MySQL. It's 537 meg, not big enough. So there we are, 35 seconds. But what's strange about this table? It was reducing, it went reducing, suddenly the query cache size rolled over, it's 32 meg again. Query cache inserts, deleted, it's zero. What happened? I'll start the query again just to see.

It was reducing, it went reducing, suddenly the query cache size rolled over, it's 32 meg again. Query cache inserts, deleted, it's zero. What happened? I'll start the query again just to see. It was reducing, it went reducing, suddenly the query cache size rolled over, it's 32 meg again. Query cache inserts, deleted, it's zero. What happened? I'll start the query again just to see. It was reducing, it went reducing, suddenly the query cache size rolled over, it's 32 meg again. Query cache inserts, deleted, it's zero. What happened? I'll start the query again just to see.

Okay, and I'll start the same query again. And I will start this. One thing that you didn't notice is this. I have set the query cache limit to 4 gigabytes. The query cache size to 4 gigabytes. I have 8 gigs of RAM. This is not even counting the other cache sizes. So what does the virtual memory look like? Oh, 8.12 gigabytes. That's what MySQL is doing.

And you can see the query cache size is decreasing. The query cache insert has been done. Let's see how much time it takes. This is the first time around. should be approximately the same, maybe a little bit more because of the overhead of 64 bit, but nothing big. Yeah, pretty much the same. OK, second time around.

Wow, MySQLD, down by 50% CPU utilization. PHP, up by 50% CPU utilization. And we have a hit in the query cache. What happened? So we expect the time to go down, definitely. But this is a classic producer-consumer problem, right? Your consumer can run only as fast as the producer can produce data. 26 seconds.

So in this case, just doing a clever tweak over here, I was able to get a 50% reduction in CPU utilization and a 25% reduction in the time taken to execute the query. Many of you will say this is, you know, basically just a skewed up benchmark. It's 32 meg.

I could have set the query cache size to one gigabyte in 32-bit MySQL and I would have got similar results, probably better. You're right. But how high are you going to go? On a 32-bit system, even with 16 gigabytes of RAM, you cannot keep increasing the query cache size or any cache size. You have the stack segment.

You have the text segment. You have the data segments. You have whatever MySQL is going to allocate other than that. The most in practice I've been able to push up the query cache size, the most is two gigabytes. On an eight gig system, I cannot use more than that. So that seems unfair. I'll switch over the slide. Yeah.

So this is what you saw, right? And the next slide. Should everyone switch to 64-bit? Probably, probably not. What you need to be aware of, 64-bit is not a magic bullet. It comes with its overheads. Your pointer variables are larger. Your long variables are going to be larger. Your cache footprint is larger.

Your process image size is larger. But you need to evaluate 64-bit. You need to look at your application and your application with MySQL and try to leverage this additional power that you get. The theoretical limit is as far as your machine can handle. That's a great place to be in. Thank you.

Thanks Lionel. That's really good solid evidence that for administrators who want to have a choice to optimize their systems, they now have this tool in their arsenal, the 64-bit services. Next, I'm going to bring up Dr. Ernie Prabhakar to talk about Ruby on Rails. All right, thank you all very much.

We're very excited with the inclusion of Ruby All Rails. How many people have been doing at least a little bit with Ruby On Rails? How many people have never heard of Ruby two years ago? Yeah, and so it's a really interesting thing. And as most of you know, the Rails community have been very aggressive adopters of Mac OS X, and the Mac community has also been very excited about embracing the power of Ruby on Rails.

And with Mac OS X and Leopard and Leopard Server, we're really trying to make it even easier to develop full-flown web applications and not just develop them, but also deploy them, which has historically been a greater challenge in the web development community. And in order to demonstrate the power of this, we were gonna bring up a trained monkey to show you that they could build a Rails application in five minutes, but we thought that would be too easy, so we're gonna have a marketing person build a Rails application in a few seconds.

So this is Leopard Server, and I'm just gonna go ahead, and as you know, Rails uses a generational approach where it generates scaffolds and code. Now, this is not the evil code generation which creates code you cannot look at or touch. It's the good code generation that gives you a starting place to build your own application functionality. So I'm gonna create a Rails application that I'm gonna label cars.

And this creates a bunch of files for me, and if I open that up in the finder I can see and David P. I'll go ahead and change into there. And then I'll run a generator and I'll create my model objects. And Rails subscribes to the model view controller paradigm that's very popular in web objects and Cocoa. And it'll build my model objects for me. Actually, I should build a model object for the car.

and that creates a series of files including this thing called a migration. In order to make it very easy to work with databases, Rails uses the concept of a migration, not just for translating between one schema and another, but also in creating the schemas in the first place. So what I'm gonna go ahead and do is go into the database.

If people can read that or not, let me just bring up a font panel and make that a little easier for people to see.

If people can read that or not, let me just bring up a font panel and make that a little easier for people to see.

And that'll give me a URL and I will go ahead and bring that up, pull that into my web browser, and you'll see here I've got my basic web application. You can see here it's running on Mac OS X Server.

And then I can go ahead and go to my new controller that was automatically generated for me. And I have my full blown web application running in Ruby on Rails on Mac OS X Server. And to show you that I can generate real code in that, I'll go ahead and create my own favorite car.

And that's being built automatically and you can do all your standard CRUD, create, retrieve, update, delete operations directly using the scaffold and then I can go in and modify the RHTML templates to add specific lookup and HTML wizardry or Ajax functionality. Or I can edit the Ruby files in the backend to do business logic of various kinds. Now this is the development side and this is what has made Rails such a popular web application framework.

And with tools like TextMate and things like that, it's made it a very popular tool on the Macintosh for developing Rails applications. Historically though, people who had to deploy Rails applications had to use various different tools and various other platforms. What we've done with Mac OS X Server is make it as easy to deploy Rails applications as it is to develop Rails applications.

So what I'm gonna do is show you the new feature of Server Admin that Al just talked about and I've never used this before so let's see how well it works in real time. And you may need to walk me through-- My web server here, let's see, we have our web server, we have our settings, and we have... So I saw an invalid serial number message there. Let's switch to the backup demo machine if we can. That's our laptop. This is demo 3, I believe it is. - Okay, there we go. So, let's go back to the beginning.

Up to my demo here. And so we have enabled the reverse proxy and we want it to be on the cars application path. And let's go ahead and press the plus button which should bring up our server URL browser. and we'll see here... So you're not running Mongrel on this machine, so let's start Mongrel. Oh, okay, so I'll go ahead and start Mongrel Rails. Tell it to start and I'll give it a separate port so I can find it easily enough.

So it's bringing up Mongrels in a port and we've added a five line patch to Mongrel Rails to allow it to register on Bonjour. And we'll be sharing that with the Mongrels community if they want to pick that up since there's very good Ruby bindings for Bonjour and Bonjour now that it's Apache licensed should be available on even more platforms going forward.

And then with that, then I can go ahead and bring up my proxy and It might need a minute or a refresh in order to find it. Okay, we've got a second to refresh. Build the suspense. And there is my server URL. And let's bring up another window.

And having a second proxy since you can't do proxy balancing with only one proxy. And that's all there is to it. There's nothing fancy I have to do. I just give it a different argument to the mongrel rails. The exact same web server I'm using for my development and testing purposes I can use as my gateway for proxying, making it very easy to do debugging and evaluation. And if I go ahead and search here and give it a few seconds, let's see how long it takes for that to show up.

And there we go. Both proxies are sitting there live. Let me go ahead and save that. And then bring up my web browser. In this case now, I'm not going to go to the, specify a port number, I'm just going to go directly to my standard Apache web server, which is running on Mac OS X Server. And we see it there, and then I just go ahead and tell it to go to the cars path. And let me bring up, move my proxies side by side so you can see what they're doing.

And when I hit that URL, you'll see it first hits one, And it should be, and then the other. So you can see that as we switch back and forth between repeated instances, we are automatically with essentially zero effort setting up a fully distributed multi-host web application server in a matter of minutes using Ruby on Rails on Mac OS X Server. Thank you.

and I'll just go right into the next slide and show you so we can introduce David. All right. Are the slides OK? Oh, yes. We're now going to have a special surprise for you. Creator of Ruby on Rails, David Heinemeier Hansson is going to be giving us a brief video presentation here.

Hi everybody, my name is David Heinemeier Hansson. I am the creator of Ruby on Rails and I'm a partner at web application firm 37signals. I'm here today in absence, kind of, to talk to you about Ruby on Rails in Leopard. First a moment or two about Ruby on Rails, how we've gotten to where we are and the kind of success we're seeing. Ruby on Rails is of course a web application framework built for developers who enjoy beautiful code and like to take pride in what they do.

And quite a few developers seem to have picked up on that notion of beautiful code, motivation and happiness. So far we've had a lot of success with Ruby on Rails. We've had over half a million downloads of the Ruby on Rails system. And that's of course drawn in a lot of excellent support from other areas of the industry, especially from publishers. The first Ruby on Rails book, Agile Web Development with Rails, has already sold over, I think it's almost 50,000 copies by now. Which is pretty amazing.

And it's been around for a little unknown, at least at the time, language like Ruby and even less so something like Rails. But the success of that book and other books in the same vein has brought on amazing publisher support from people like Tim O'Reilly and most of the other major publishers out there.

So we're seeing a lot of uptake among regular programmers who are just trying to get their hands on Ruby. And that's a big thing. And we're seeing a lot of programmers who are just picking up Ruby on Rails because they really like it. And we're seeing a lot of awareness being spread from all of these books being published and all of the articles we're seeing and so on and so forth.

And I think that's a really interesting notion and plays very well with the recent, or perhaps not so recent, but enormously strong uptake of the Apple development platform within programming circles. And especially within web programming circles. I see a lot of similarities between the reasons why people choose to use a Mac and the reasons for why people choose to use Ruby and Rails. And I think a part of that is just the same sense of shared aesthetics. Apple cares deeply about the user experience of the systems they build.

And we've kind of tried to take the same kind of mentality, the same kind of consumer. It just works. Everything is included in the box approach to web development. Which, at least in the past, used to be way more of a geeky, engineering, it has to be hard to be right approach to things.

So it's really quite natural for us in the Ruby and Rails camp to see Apple as something that's very similar to what it is that we're doing. And thus it's also that much more... rewarding to see Apple today. And yesterday announced that Ruby and Rails is going to ship in Lepid. Both the client and the server versions as part of the development toolkit.

And just as an example of how the uptake of Apple is within the Ruby and Rails community, all of the 12 core contributors to Rails are running on Macs. And the vast majority of all developers so far who've been picking up Ruby and Rails have been running on Macs too.

We recently held the RailsConf conference in Chicago and I think we had something like a 95% adoption of Apple in the audience. So really, really strong Apple commitment from within the Rails camp. So that of course makes us all the more happy to see Apple re-prossecate and ship Rails with the next upcoming OS release.

So the parts of dealing with integration i was excited about it is that Apple is not just choosing to jump on Ruby on Rails and just throw it in there, and then you can figure out the rest. They're actually actively engaged in picking the best practices of right now. What is the preferred way of getting Ruby on Rails up and running in both development environment and in a deployment situation? And that's something recently in the Rails community have started to focus a lot on.

There's a new Ruby-based web server called Mongrel, which is showing a whole new way for us in terms of how do we get these services up and running. It used to be in the past that fast CGI and similar somewhat outdated protocols were necessary in order to get the speed we needed for Ruby on Rails. But Mongrel is just as fast as fast CGI, and it's much easier to deal with because it's just all HTTP.

And that's the big message that we want to send out and help spread is that HTTP doesn't necessarily just need to be an external format. It can also be an excellent way of communicating inside of your application between various components. So the fact that Lepid ships with Apache 2.2 and the Mach proxy balancer plays right into that vision. It plays right into the vision that proxies are the way to go. HTTP is the new pipe.

Not just for the external web, but for the internal web as well. And thanks to all the work the guys at Apple have been doing for making this a lot easier to set up, it also drastically reduces the barriers of entry for setting up a world-class, scalable cluster for a Rails application. It makes it much easier for somebody to take something they've developed on their own, throw it on.

And then they can just go and get it up and running in a Mac box and get it up and running in something that's just as good as all the huge deployments we've been seeing of Ruby and Rails so far. That has really been a sore point for Rails for some time. The fact that we make development so incredibly easy, and then you get shell shock basically when you try to jump back in the old world of deployment. Because deployment on Rails is in some parts just as deployment on every other platform. Terribly complicated.

So the fact that we now have Mongrel, the fact that Apple and others are doing such great work of endorsing this vision of HTTP being the premier way of getting your application up and running internally, is just awesome. So hopefully all of this support in Lepid will mean that even more people will pick up Rails development on the Mac.

And it'll hopefully also mean that Apple will get more... limelight in the deployment scenario. So far there hasn't been too many deployments of major Rails applications on Apple hardware. But thanks to the new XSERVs, which proved to be an excellent performance to price ratio, and also thanks to the new features in Lepid, I'm really hoping that we're going to see a lot more uptake on deployment on the Lepid server. So with that, I'd just like to end my little speech here and say thank you all for coming. Thank you all for coming to this session.

And thank you for showing interest in web development on the Apple computer. And thanks to Apple for being such a great support of the Ruby on Rails framework. Thanks and enjoy the conference. So now we're ready for some QA. We'd like to thank David Heinemeier Hansson for providing that video for us and we're very happy that he's as enthusiastic about the platform.