1. Head to Peachpit.com (almost all of my books are published by Peachpit Press)
2. Click on Account Sign In at the top of the page.
3. If you don’t already have an account with Peachpit.com, click the Create a new one… link to register.
4. After you have registered, login.
5. On your account page (after logging in), click Registered Products.
6. On the Registered Products tab, click Register Another Product.
7. Follow the instructions to register the book.
8. Return to the Registered Products page.
9. For the book in question, click the Access Bonus Content link. That will take you to a page with all the bonus content for a given book.

Besides being able to access bonus content, there are other benefits to registering at Peachpit’s site. And while you’re there, you can also check out my author page, which lists the books I’ve written for Peachpit, the articles I’ve published there, and the blog postings I’ve published there. Both the articles and blog postings are viewable without registration or logging in.

I hope that helps anyone having trouble finding the material they’re looking for.

The first is an Introduction to Computer Science and Programming, from an instructor at MIT. It’s definitely for beginners and although it uses Python as its primary language, the goal is to convey the fundamentals and the theories involved. It probably gets a bit too high-end for some, but worth taking a gander at regardless.

The second series is programming literacy’s Core units. This series is much more broad and covers a range of languages and topics. As I write this, the first six units have been completed and are available as YouTube videos, with downloadable PDFs (and other formats) for the slides and notes. On the other hand, the last one was finished about 20 months ago, so there may never be more in the series. Still, it’s approachable and I like that the materials are available for viewing separately. And the price is right!

• About This Newsletter
• On the Web => Colibri for Windows
• On the Web => “Learning the Yii Framework” Series in French!
• On the Blog => Creating Forms with the Yii Framework
• On the Blog => Markdown and MultiMarkdown
• Q&A => What happened to Ruby on Rails?
• Q&A => What is the Benefit of the Model in MVC?
• What is Larry Thinking => Becoming a Better Programmer
• Larry Ullman’s Book News => “PHP for the Web”, “PHP and MySQL for Dynamic Web Sites”, and More!

About This Newsletter

No real theme to this newsletter: a couple of links to interesting things online, recommendations of two blog postings to consider, answers to two recently submitted questions, and some news. I turned a frequently asked question into a “What is Larry Thinking?” topic: how to become a better programmer. I’ll follow up on that topic in a future newsletter, too. Other forthcoming subjects include: starting a new Web site/business, making a career out of programming, and how to organically grow a Web site.

As always, questions, comments, and all feedback are much appreciated. And thanks for your interest in what I have to say and do!

On the Web => Colibri for Windows

As you may know, I primarily use a Mac, so I tend to be less aware of the good stuff available for those of you—okay, the majority of you—on Windows. One Mac product that I used to rely heavily upon is QuickSilver. QuickSilver is an application and document launcher, system navigator, utility, jack-of-all-trades. QuickSilver is free, extendable, and quite excellent. Unfortunately, or fortunately for him, the developer that created QuickSilver was hired by Google to create a somewhat similar product for them called Quick Search Box for Mac. So I have since returned to LaunchBar, with which I’m also quite pleased. But this blip isn’t about good Mac software, this is about Colibri for Windows.

I have no idea where or how, but I recently came across Colibri as a Windows equivalent to QuickSilver. Naturally this caught my attention. And although I haven’t used it myself, I thought it worth mentioning, because if it’s anything like QuickSilver or LaunchBar, some of you Windows power users will really appreciate it. With Colibri, you can control iTunes, interact with Firefox, perform Web searches, launch applications, and more, all from an interface that appears by pressing the right key combination. Oh, and it’s free! One negative from the research I’ve done is that the documentation isn’t great, at least not online. But still, Colibri may be worth considering.

On the Web => “Learning the Yii Framework” Series in French!

Nico, from Mémorandom, recently contacted me about translating my popular Learning the Yii Framework into French and publishing it on that site. I’m pleased to say that the first five parts of the series have already been translated and are available online:

• Introduction to the Yii Framework

• Getting Started with the Yii Framework

• Configuring Yii

• Defining Databases for the Yii Application

• Creating Models, Views, and Controllers in Yii

The posted translation should hopefully help expand Yii’s international influence. My thanks to Nico for the nice words on my series and for the work in translating it!

On the Blog => Creating Forms with the Yii Framework

HTML forms are one of the key pieces of any Web site, providing an easy way to get data from the user. But, as is the case with many things, creating forms while using a framework such as Yii is significantly different than creating forms using standard HTML alone. In a recent post, I covered what you need to know to get started creating HTML forms when using the Yii framework.

On the Blog => Markdown and MultiMarkdown

In previous newsletters I’ve made reference to Markdown and MultiMarkdown, two of my favorite new technologies (well, new to me). The one is an extension of the other and both allow you to write more naturally, without concern for formatting, and then output that text in HTML and other formats. I’ve been using Markdown for my newsletter for a couple of months now and plan on using MultiMarkdown when I begin self-publishing books this year.
You can read a quick introduction to both technologies, and see where to head for more information, in this blog post.

Q&A => What happened to Ruby on Rails?

Jason sent me this question, pointing out that “It was all the rage a while back”. True, true. So what did happen?

First, I’ll say that I adore Ruby. It’s a beautiful language, odd as that may sound. If I need to create non-graphical utilities or scripts to be executed via a command line, Ruby is my language of choice. Ruby has great power yet simplicity, and is more object-oriented than most (e.g., any number in Ruby is itself an object). And Rails is a great framework for doing Web development. It does a lot of the work for you and has outstanding features. In fact, Rails recently came out with version 3, which was a major revamping, integrating features that cropped up in Ruby-based alternatives to the Rails framework.

Anyway, I suspect part of the reason that Rails doesn’t get the attention it once did is that it’s no longer “new”. Secondarily, I think the impression of Rails was severely damaged by what happened with Twitter. Twitter was originally written using Ruby on Rails but Twitter got to a point where the site wasn’t able to handle its demand. Rightly or not (probably some of both), Ruby on Rails took the brunt of the bad press for the outages. I would argue that one can’t use Twitter as a reasonable benchmark, though, as very few—perhaps only a handful—of sites have the same level of activity as Twitter. I suspect that most sites would crash if they started seeing that kind of demand. Poor scalability is not a problem of Ruby on Rails. In fact, honestly, I don’t know that any technology has inherently poor scalability, but that all technologies will degrade under high loads, if not optimized for demanding conditions.

To be fair, performance is a concern whenever you use a framework. Framework-based applications, by definition, are going to be more bloated and slower than non-framework applications. That’s just the way it is and will be. In turn, one gets much faster development with a framework. In any case, I know Twitter eventually replaced their Ruby on Rails code with something else (written in Scala, I believe), but Groupon and Hulu use Ruby on Rails, and these are also very demanding sites.

Finally, as for myself, despite my affection for Ruby and Ruby on Rails, the reason I don’t regularly use RoR for Web sites is because there’s now a good, comparable PHP framework (for me, that’s Yii). I had been programming with PHP for several years before learning Ruby and Rails. When I came across RoR, there was no PHP framework like it. But I’ve since found, and grown quite fond of, Yii, so my need for a quick development Web framework has been met, allowing me to use PHP, the language that I’m still most comfortable with.

Q&A => What is the Benefit of the Model in MVC?

The MVC design pattern, short for “Model, View, Controller”, has become an extremely common way to write software and is used by most, if not all, major frameworks. But the MVC approach is not necessarily intuitive and can be confusing, or simply hard to properly implement, for beginners. Brett, for example, sent in this very reasonable question:

“Views and Controllers make sense to me, but have a Model to pull out data and then to have a
View call it, doesn’t seem to flow that well in my head. What are the benefits of using Models?”

In case you’re not familiar with MVC, the View is what the user sees and interacts with. On a Web site, this means HTML, with a dab of PHP embedded as necessary (e.g., to echo the value of a given variable). The Model represents a set of data. Often a Model corresponds to a particular database table, with an instance of the Model representing a particular row from that table. Models can also represent data sets not being permanently stored, such as the contents of a contact form, which get emailed instead. The Controller is the agent between the View and the Model. The Controller responds to user actions, such as requesting a specific page (in which case the Controller loads any necessary Model and then renders the proper View) or handling a form submission (in which case the Controller may create a new instance of a Model based upon the submitted data, then save the Model, and then render a different View). An important aspect of MVC is that Controllers should actually be lightweight, in terms of code. The applicable adage is “thin Controllers, fat Models.” The most common design error by beginning MVC-ers (?) is to put too much logic and functionality into the Controller, instead of in the Model where it belongs. But why?

Let’s quickly think about the Controller. The Controller responds to user actions and quite frequently then loads an instance of a Model which the Controller then passes to the View. Much of the Controller logic is not really particular to a given application, but rather slight variations on common themes. With a site for managing employees, the Controller’s actions would entail: listing all employees, viewing a particular employee, searching for employees, adding a new employee, updating an existing employee, and deleting a particular employee. Now say the site is for managing an inventory of products (like on an e-commerce site). In that case, the Controller’s actions include: listing all products, viewing a particular product, searching for products, adding new products, updating existing products, and deleting existing products, among others. As you can see, there’s a lot of repetition here, the only difference being the swap of “employee” for “product”. This is to say, the only difference is the Model itself. And that’s why the Model is so critical: because it is the heart of an application. When you’re deciding what a site is about, and when you’re designing the database, you’re dealing with the Model. The same Model will be used by many different Controller actions and View files. So let’s look at the Model in detail…

The Model represents the data, but what does that mean? It means, for one, that a Model defines the properties for an object, like a “user” object has a first name, last name, email address, password, etc. The Model also defines the validation routines that any data set must pass: the email address must be a valid email address, the user level must be an integer, the date entered value is the current moment upon insert, etc. Whether a new Model is being created or an existing Model is being updated, the same validation rules will apply.

Models also sometimes have custom functions for returning formatted properties. Models shouldn’t output HTML, but a user Model might have a function that returns the user’s name in the format Last Name, First Name MI.. Or a user Model might have a “member since” function that returns the user’s registration date in a particular format (not the database timestamp). By putting this functionality in the Model, any View can make use of it. If that functionality were defined in a Controller or View, then only that Controller or View could benefit.

Just as the majority of Controller code may be the same from site to site, some of the Models can be exactly the same from one site to another, or just slightly different. If you’ve created a user Model that does everything you need it to do, it’s likely that the same Model can be used on multiple sites (this, of course, is a benefit of object-oriented programming in general). With the MVC architecture, the biggest differences from one project to the next are therefore the Models you define and the corresponding Views.

Coincidentally, the Yii framework’s site just posted a nice article titled Best MVC Practices, which you may benefit from reading, whether you use Yii or not.

What is Larry Thinking => Becoming a Better Programmer

How one becomes a good programmer is one of the most common questions I see, especially from those just getting started. A reader purchases one of my books because they want to learn X, and then they want to know how long before they’re an expert programmer. The answer to that particular question—how long—is short and sweet: I have no idea. It really depends upon who you are, what you already know, how you learn, and so forth. But many people, when they ask you a question, don’t care for the “I have no idea” answer, even if, or especially, if that’s the correct answer. So rather than answer that question, I thought I’d take a moment to discuss the more appropriate question of “How do I become a better programmer?” The key is “better” as opposed to “good,” “expert,” “master,” and the like.

Perhaps it’s merely semantics, but one shouldn’t aspire to be a good programmer, but rather a better programmer. Like, well, almost every job, a programmer does not have a fixed end that one gets to. I’ve been programming actively for going on 12 years now and, whether I’m currently a good programmer or not, my hope is that next month I’ll be a better programmer than I am today. So how do I, or anyone, work towards being a better programmer?

Read. Do. Review.

Pithy things are easier to remember and just sound more true, so I’ve assembled all my thoughts into those three words: Read. Do. Review.

Read.

There are plenty of tasks you can pull off without reading a thing, such as changing a tire or unclogging a sink, but you can’t learn to program without reading something: a book, a manual, articles, whatever. Programming simply does not allow for blind guesses. Now clearly, my books are the best way to learn anything and should always be your first stop on a new path. This cannot be denied. (I really am joking.) But even after reading all of my books multiple times over, there’s probably a benefit of reading other writers’ books (blasphemy), to get a different perspective. Assuming you’re a book-reader type, that is.

Books do three things well. First, they can teach beginners effectively. Second, they can show how to apply knowledge. Third, they provide a cohesive body of information. I’m a book person and a book writer, so I’m completely biased, but I think that reading books about programming is always for the best. I still read books by other writers, even if they’re on the same subject and targeting the same audience as some of my books. Always good to see what others are thinking!

I mention manuals second for three reasons. First, not all programming languages or technologies have actual manuals, let alone good ones (the PHP manual is pretty good, in my opinion). Second, manuals tend to promote syntax and functionality above real-world implementation. Third, manuals tend to be written by committee, thereby lacking cohesion. On the other hand, in theory, manuals will always be the most up to date of the available options.

Articles are a great way to learn new tricks, of course. You might think this means reading an article on a specific subject only if you want to learn about that subject, but you might get some value by seeing tangential code. For example, say an article is on creating an RSS feed using PHP and MySQL. You might not need to do this, but in reading the article, you could learn something about PHP and MySQL, about XML, and so forth. And again, you’d get a different writer’s perspective and approach.

Do.

The second step is to simple: program. You can’t really learn or improve without doing. If you don’t have actual programming work to do, then come up with your own idea and implement it. In a way, programmers, Web developers, and the like are quite fortunate, as they can practice, learn new things, create functional projects, etc., without spending a dime (or without spending much money). Many other professions, such as architects, don’t have that luxury. So take advantage of that freedom!

Review.

I suspect most programmers focus on the “doing” and spend very little time on the “reviewing,” which I believe is probably more important in the long run. I don’t mean testing, which is necessary, too, but actual code reviews. Are the comments still thorough and accurate? Does the code make assumptions? Are errors handled gracefully? Is the code properly formatted? Is it consistent in terms of formatting, syntax, variable names, and the like? Most programmers, in time, can make things work. It’s these other points that differentiate the average programmer from a better one. But don’t stop after reviewing your code…

You should review other people’s code. See what they did. Does it make sense? Does it adhere to the same principles just outlined? What does that code do differently than the code you’d write? Is one approach better? If so, why? I’ve become a better programmer (and a better writer) by providing support in my forums. In looking at what other people did, and helping them solve problems, I’ve learned a ton. And I know that the handful of other people that are kind enough to donate their time to assist feel this way as well (and my unending gratitude to them).

A key learning tool when reviewing code is explaining what code does. There’s a related debugging approach called rubber duck debugging that’s similar to what I’m suggesting here. One level of programming knowledge is getting something to work. A higher level is understanding why it works. An even higher level is being able to explain why it works. I know I’ve become a better programmer by writing books, although that’s a pretty steep and unreasonable step for many to take! A few times, though, as I write a book I’m explaining why I used such and such code, and in the process of explaining, I realized that the approach could be improved. You don’t actually have to write a book or sit someone down, but go through code some time and try to explain why it’s doing what it’s doing. You’ll learn a lot.

And…

In a subsequent newsletter, I’ll write a bit about what general and specific skills are critical to being a better programmer, but I wanted to just focus on the process of improving here. What did I omit? Formal training and certification. Formal training, be it a school course or not, is a great way to become a better programmer, which I think goes without saying. Or it should be a great way, as not all classes or teachers are alike (true for books, as well). As for certifications, I understand they can help you get a job, but I don’t put much faith in passing a certification test as a way of becoming a better programmer. You can certainly learn some technicalities that way, but I doubt you’ll learn that much in terms of real-world knowledge and the ability to apply information.

Larry Ullman’s Book News => “PHP for the Web”, “PHP and MySQL for Dynamic Web Sites”, and More!

As mentioned in my previous two newsletters, I’ve been writing some articles and blog posts for Peachpit Press’s Web site, all supporting my Effortless E-Commerce with PHP and MySQL book. I’ll post links to them on my Web site, and in future newsletters, as they go live.

I’ve wrapped the first draft of the the fourth edition of “PHP for the Web: Visual QuickStart Guide” and am almost through with the rewrites. Along with fixing any minor problems, updating the code for the latest version of PHP, and adding a “Review and Pursue” section to the end of each chapter, I’ve been able to add a new chapter. That chapter will replace the original Chapter 13, “Regular Expressions,” as the ereg() function has been deprecated in PHP 5.3. The new chapter is called “Putting It All Together” and will show how to use everything covered in the book to assemble a mini-Web application, with authentication and full CRUD (Create, Retrieve, Update, and Delete) functionality. The chapter is similar to the three popular example chapters in my “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” book, although using a different example.

In February, I start writing the fourth edition of my “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide.” It will also have a “Review and Pursue” section added to the end of each chapter. I’m also going to clean it up a bit, and remove references to PHP 6, which, in the time from when I started writing the third edition to started writing the fourth edition, went from about 50% complete to limbo to non-existent. So that’s the last time I’m going to try to be that far out ahead of the curve.

I am also planning on working on my self-published JavaScript book starting in February as well. I’ll try to dedicate some time to it and, as I’m publishing it myself and writing it using MulitMarkdown, I’ll be able to post free, HTML sections from the book online as I go. Thanks to everyone for their continued support and interest on this new book!

The problem in properly executing the MVC architecture for many people is that it runs contrary to what they’ve done thus far. If you’re a PHP programmer creating a page that lists every department (in an employees-departments application), you’d likely have a PHP script that:

1. Generates the initial HTML, including the HEAD and the start of the BODY
2. Connects to the database
3. Queries the database
4. (Hopefully) confirms that there are query results
5. Retrieves the query results in a loop
6. Prints the query results within some HTML, perhaps a table or a list
7. Frees the query results and closes the database connection (maybe, maybe not)
8. Completes the HTML page.

And that’s what’s required in a rather basic page. Even if you use included files for the database connection and the HTML template, there’s still a lot going on. And if you link those department pages to another page that shows more information about the department, passing along the department ID in the URL, that other page will need to add some data validation steps. And if you have a page that both displays and handles a form, like for adding an employee, there’s way, way more code and logic to add. Not that there’s anything wrong with this, mind you—I still program this way  as warranted—but it’s the antithesis of what MVC programming is about. You can think of MVC programming like a pyramid, with the Model at the bottom, the Controller in the middle, and the View at the top. The code should be distributed appropriately, with most of it in the Model, some in the Controller, and very little in the View.

From a programming standpoint, a View should do very little, mostly just echo out the values of variables. The most logic a View should have is using a conditional to confirm that a variable has a value before attempting to print it or creating a loop to print out all the values in an array. The View generates what the user sees, that’s it. The Controller has more logic and code to it, as it responds to user actions, and acts as an interface between Models and Views. But it’s a common mistake to put code in a Controller that should really go in a Model. A guiding principle of MVC design is “fat model, thin (or skinny) controller”. This means you should keep pushing your code down to the foundation of the application (aka, the pyramid’s base, the Model). In a post I saw about the MVC architecture, they describe the Model as “maintaining state” between HTTP requests. I think that’s a good way of describing it because it encompasses both stored data and processed data that doesn’t necessarily get stored. So a departments Model represents stored data that is added, updated, and retrieved in multiple requests, while a contact Model represents data entered by a user in a form, validated, and sent in an email.

(As a a complete aside, there are some very well done, very funny videos on MVC available at RailsEnvy.com. In particular, watch the ones called “Controller Obesity” and “Keeping Views Stupid”.)

So what does this mean in actual code? Well, to start, if your View contains more than echo/print, and the occasional control structure, you’re possibly doing something wrong. If you’re creating new variables in a View, you’re probably doing something wrong. In fact, so little PHP code goes into a View, that even printing out something in a loop is normally done like this, with the emphasis on the HTML:

<?php foreach($departments as $n=>$dept): ?>
<li><?php echo $dept->something; ?></li>
<?php endforeach; ?>

This is opposed to what one might do in a common PHP approach, with the emphasis on the PHP:

<?php
foreach($departments as $n=>$dept) {
    echo '<li>' . $dept->something . '</li>';
}
?>

Now the code in the Controller is largely about…um…controlling the action, i.e., delegating responsibilities and reactions, responding to user input, etc. Controllers are classes, filled with methods that do the actual work. The work is largely retrieving specific Models (e.g., one record from a table or every record), calling upon a Model to be inserted, updated, or deleted, and calling upon a View to be rendered. The Model does everything else, like running the actual queries, validating the data, and so forth. However, in a framework, most of that code is built into the framework itself, so you can call a save or delete method on a Model, but the Model itself doesn’t have any such method defined (the Model inherits those methods from a framework class on which it’s derived).

Going back to an employees-departments example, say you want the page that lists the departments to also display each department head’s name. Presumably the employee ID of the person that is the department head would be stored in the department Model, like employee #14 is the head of Human Resources. To start, the Controller retrieves all the departments using that Model (this is Yii framework syntax):

$departments = Departments::model()->findAll();

The $departments variable gets passed along to the View so it can print them all out. This is basic MVC using Yii where, again, the departments Model doesn’t actually define a findAll() method, it just inherits one.

Now you also need to find the department head’s name for each department so that the View can display that. To find that person’s name, you’d need to fetch an employee Model whose employee ID matches the stored ID in the department Model. Using the Yii PHP framework, that code is

$emp = Employees::model()->findByPk($dept->departmentHeadId);

There you’re saying that you want to find the employee Model whose primary key value is the same as the departmentHeadId value in a given department Model.

What you absolutely don’t want to do is run that code or any similar query in the View. Very bad! Now, you might be inclined to put that code in the Controller, but in order to do that, you’d need to loop through each retrieved department, fetch the departmentHeadId, find the employee with that primary key value, and then associate the retrieved info with the department. Or you could retrieve all the employees and have the View find the corresponding employee record. In either case, it’s way too much code and logic to be outside of the Model.

To be clear, Yii, and other frameworks, support joins across Models, so in Yii, you’d do this (after identifying the relationship between the models):

$departments = Departments::model()->with('employees')->findAll();

But if that wasn’t an option in your framework, or if the two Models didn’t have a real, defined relationship, you could add this method to the department Model:

function getDepartmentHead() {
    $emp = Employees::model()->findByPk($this->departmentHeadId);
    if ($emp) {
        return "$emp->lastName, $emp->firstName";
    } else {
        return 'unknown';
    }
}

Once this is defined, you still wouldn’t need to add any code to the Controller, you could just do this in the View, within the foreach loop:

echo $dept->getDepartmentHead;

As another example, say you want to display employees names in the format LastName, FirstName, or something more elaborate. If you write a method that does that, defined in the employees Model, you can call that method anywhere that uses an employees Model and that might require showing the person’s name. This would include the page that lists all employees, the page that shows the information for just one employee, and the page that shows the head of a department. For example, in the above getDepartmentHead() method, you could return $emp->getFormattedName().

Whew! So, per my usual habits, this post has become far longer than I expected. I hope that I achieved my goal of explaining MVC using real-world examples, in a way that illuminates and clarifies this approach. If I haven’t, let me know and I’ll expand upon this in a subsequent post. As a postscript, a few hours after originally posting this, I touched up the last few paragraphs, adding more code to better illustrate the point (perhaps).

On the other side of the equation, you can perform benchmarks on the server. Finding, and later improving upon, these measurements will improve the experience for all clients, regardless of download speed, computer, or browser type. This is particular important when using server-side technologies like PHP.

Among the many utilities available to benchmark a Web site is Siege, from Joe Dog Software. One of the nice things about Siege, besides it being free, is that it tests a Web server under duress, something that’s impossible for a single individual to replicate. So you can tell Siege to access your site using X number of simulataneous connections and then see the result. On the downside, you have to compile it on Unix-like systems, including Mac OS X, in order to use it. For more, see the Siege Web site and it’s simple-to-follow manual.

The hope is to have a beta of Rails 3 ready by the May 2009 RailsConf in Las Vegas, although the developers think that’s “probably-overly-0ptimistic”. The next minor release of Rails, 2.3, will come out in January 2009, and Merb will continue to be supported for those currently using it.

For more information from the people behind both frameworks, and to get a sense of how big this is in the Ruby community, see:

• http://yehudakatz.com/2008/12/23/rails-and-merb-merge/
• http://weblog.rubyonrails.org/2008/12/23/merb-gets-merged-into-rails-3
• http://brainspl.at/articles/2008/12/23/merb-is-rails
• http://splendificent.com/2008/12/the-merb-rails-merger-announcement-an-inside-opinion/

Some people have asked if Ruby on Rails really is better than PHP. This isn’t an appropriate question, however. PHP is a programming language that can be used for many purposes, by far the most common of which is development of dynamic Web sites. (PHP can be used for other purposes, including creating command-line utilities or even graphical applications; it’s just not used for those purposes nearly as often.) Ruby is also a programming language that can be used for many purposes, perhaps most commonly for command-line and system utilities. In part thanks to eRuby (Embedded Ruby), Ruby can also be used for Web sites. Conversely, Ruby on Rails is a framework written in Ruby. A framework is simply a library of existing code that can be used to facilitate application development. Ruby on Rails is Ruby’s most popular Web development framework, although not the only one. For PHP, popular frameworks include PEAR and PECL (depending upon how you define “framework”), Symphony, Cake, and Zend. So any comparisons to be made aren’t between PHP and Rails but rather PHP and Ruby or the Zend Framework and Ruby on Rails. Over time I’m going to make this second comparison myself and post the results here.

As for PHP versus Ruby, I’ll say that subjectively, PHP is my first love and is still the language I turn to for updating existing Web sites (rather than rewrite them in Ruby) and for creating simple Web pages. I think PHP is really easy to learn and use, especially for those purposes, and both writing in it and debugging it is rather easy.

Ruby is kind of amazing. It’s a pretty impressive language with lots of great features. As an object-oriented language, PHP can’t really compare. The ability to alter existing classes–even those built into Ruby, like String or Array–on the fly is fantastic. And I find installing and using RubyGems to be easier than PHP’s PEAR or PECL. When I’m working with PHP, one thing I miss is Ruby’s irb, the command-line Ruby interpreter that can be used to test small bits of code.

I’ll add some more specifics in future postings but I wanted to put this basic info out there immediately. I will also say that I put little faith in discussions of security or performance when making comparisons. A bad programmer can make really insecure applications using a very secure technology so I think that saying any language or technology is more or less secure is inappropriate. As for performance, there are so many variables there that, again, just saying X is faster than Y is not often meaningful. One of the argument’s for using Ruby is that it’s very quick for you, the developer, to use, and your time is far more critical than the computer’s.