Andrew Rollins

It took me a couple days on my current PHP/MySQL project to get the DB abstraction with proper error handling, input validation, and relational support coded to the point where I’m happy with the model. This was after trying Zend_Db, Doctrine, and Propel, which are all good libraries, but I hit points where the work of getting it to do what I wanted efficiently just wasn’t worth it. I decided it would be faster to just roll my own slim library.

I’m always mystified at why DB models are such a hassle to code, so I spent a little time reading. I think I get it now. It has to do with the mapping problem between relational systems and object oriented systems.

Ted Neward, writer of several books on C# and Java, calls this “The Vietnam of Computer Science“. What he’s saying is that object-relational mapping (ORM) quickly reaches a point of diminishing returns. The problem stems from the conceptual disconnect between the language and the data store.

Hoping to shed additional light on the subject, I went looking for alternative perspectives to my PHP/MySQL solution. Since it’s all the rage for ease of use, I was mostly curious about Ruby, the Rails framework, and object oriented databases.

Ruby is certainly different, but after some reading, I’m starting to understand why the language lends itself better to the OO style of DB abstraction. On top of that, Rails has powerful scaffolding that lets you flesh out pieces very fast without the code getting ugly. With ActiveRecord in mind from the ground up, things can be pretty elegant some times.

I also found some really cool systems for bridging the gap between languages and data stores. For instance, check out MagLev for Smalltalk/Ruby. Imagine using an OO DB so you don’t have to do the relational mapping, doing it in a distributed fashion, and using things like shared memory more efficiently as an object staging area between your running site scripts and the DB. That’s kind of MagLev.

All of this is interesting, but for the current project I’m sticking with PHP. However, on the next project I might try Ruby on Rails. I want to see first hand if and how it overcomes some of the challenges.

On a slightly tangential subject, a part of me really dislikes the weak typing of both Ruby and PHP. The net effect in PHP is that you pretty much end up using arrays for everything, making it hard to keep track of structure. Ruby on Rails does get around some of the weak typing issues with some better built-in validation, scaffolding, and member attributes (I’m not sure if that’s what they call them). Sometimes I’d rather be doing C#.

Share This

I spent this last weekend attending Barcamp Boston 3, a two day grassroots technology event on Saturday and Sunday, as well as the Barcamp pre-event party at Betahouse. I put some pictures from Barcamp up on Flickr, and here are pictures from everyone.

Barcamp is best described by the following snippet on their web site:

BarCamp is an unConference, organized on the fly by attendees, for attendees.

There is no registration fee, but you don’t just attend a BarCamp — you can participate in discussions, demo your projects, or join into another cooperative event.

Topics may include, but are not limited to: open source software, startups, UI design, entrepreneurship, AJAX, hardware hacking, robotics, mobile computing, bioinformatics, RSS, Social Software, programming languages, and the future of technology.

Barcamp Boston is just one instance of Barcamp - there are other Barcamps all over the world. You can find them on the main Barcamp web site.

(For those of you who aren’t programmers, “Bar” in Barcamp doesn’t refer to a place where alcoholic beverages are served. It comes from Foobar, a common placeholder name in programming.)

For a list of sessions, I took pictures of the Saturday and Sunday session boards from both days. Flickr displays them out of order, so I marked them with numbers.

Sessions I attended:

• Saturday
  • Visualization at an Internet Scale by Matt McKeon from IBM’s Many Eyes project
  • Distributed Twitter by Joe Cascio
  • Git as a subversion replacement by Josh Nichols
  • Google App Engine by Shimon Rura and Brian Olson (shown in picture)
  • iPhone Development by Dan Grover
  • Viral Marketing by Matt Peters from Pandemic Labs
  • Open Source Backup and Recovery Discussion led by Joe Slag
• Sunday
  • Code Secrets
  • Build your own wireless router
  • Ubuntu Discussion
  • PHP Development Discussion led by me

Here are some links to products and web sites I learned about:

• Career Numbers - career analytics currently in stealth mode
• Wonder Warp - iPhone and Mac applications from Dan Grover. He did a talk on iPhone development.
• Draconis Software - web application development
• Diet.com - nutrition information with access to info over SMS
• My Punchbowl - party planning and invitations, fairly well known and funded. He hosted a discussion on hiring people in tech.
• Gigafloat - social messaging, link sharing, etc.
• Babbledog - social bookmarking and news.
• Many Eyes - data visualization research from IBM

This is just a small sample. The Barcamp Boston 3 wiki has a much more comprehensive list of attendees with links to their sites.

I enjoyed the event, met a lot of great people, and received many clever suggestions for my company.

Some events on the horizon include:

• Ignite Boston - sponsored by O’Reilly
• Mobile Monday Boston - mobile technologies and development

Share This

A few days ago, I started development on the web site portion of one of my new projects. The project is comprised of mobile applications working in tandem with a main web site to deliver a service. However, this post isn’t about the specifics of that project. It’s about a paradigm shift in web development that I have noticed upon returning to the space.

I started development as I always have: prototyping a MySQL database and then constructing PHP pages to flesh out an experience. There would be one PHP script per user facing page, and each would be rife with HTML, include statements, session checks, database queries, display logic, and so on. A library directory would contain includes with common procedures.

Then it hit me: this is exactly how I would have done it five years ago. Web development has changed in that time, and surely I am wiser now. How can I do this better?

The approach I just described is what I refer to as the traditional PHP approach. There may be more official terms, but that’s what I think of it as. Data, presentation, and procedural logic are all intertwined. You write a set of library procedures for manipulating data, all following the create, read, update, delete (CRUD) model, and then call these procedures within PHP/HTML pages for each user facing page.

You usually end up with files like this:

<?php
    require_once('config.inc.php');
?>
<html>
<head>
<title>Search</title>
</head>
<body>
 
<form action="" method="post" name="searchform">
Search <input name="search" type="text"/><br/>
<input name="search_submit" type="submit" value="Search"/>
</form>
 
<?php
 
if (isset($_POST['search']))
{
    require_once(LIB_DIR . '/Db.inc.php');
    require_once(LIB_DIR . '/Search.inc.php');
 
    $db  = DbSingleton(MY_DB_STRING);
    $res = Search($_POST['search'], $db, 'table');
    while (($row = $res->fetchRow()))
    {
        PrintRow($row);
    }
}
 
?>
 
</body>
</html>

This is a simple abstraction for a search page using the traditional approach. An included config file defines the location of the library and a database connection string. There is some HTML for the form and a PHP block for querying the database and displaying results.

As you can see, logic, data, and presentation are all in one file. Think about this for a moment, and you’ll realize that this approach is going to get real ugly, real fast. Without clean separation, it becomes harder to isolate tasks such as web design from tasks such as business logic and data manipulation.

Addressing this problem is the whole point of hot, new frameworks like Ruby on Rails. Rails separates data, presentation, and logic, and it achieves this through the use of the Model-View-Controller (MVC) paradigm.

MVC is a design pattern for structuring applications. How you interpret that pattern is up to you, but in general, the pieces are:

• Models are objects that abstract away your data.
• Views are objects that handle the presentation layer.
• Controllers bridge the gap between models and views with logic based on user input.

In other words, the controller interprets a request, instantiates the appropriate models and gets the data, then it packages the data up and hands it to the requested view for presentation.

MVC makes sense as a good paradigm for developing a web site, and Ruby on Rails is the predominant example. However, that doesn’t mean one should drop their favorite language in favor of Ruby on Rails. I like PHP, and PHP can do the MVC pattern just fine. To that regard, I found 7 reasons I switched back to PHP after 2 years on Rails by Derek Sivers to be enlightening. Here is a quote:

I spent two years trying to make Rails do something it wasn’t meant to do, then realized my old abandoned language (PHP, in my case) would do just fine if approached with my new Rails-gained wisdom.

The “Rails-gained wisdom” - the MVC paradigm that I’m talking about - is really what’s important, not the language you do it in. As Derek found out, Rails still has some drawbacks despite all the buzz. You might be better off applying the “Rails-gained wisdom” to a language you are more comfortable with.

If you are a PHP person like me, you don’t have to roll your own framework. The PHP community has joined the MVC bandwagon with projects like Zend Framework, Symfony, and CakePHP.

I recommend trying Rails or one of the PHP frameworks before trying to write your own. People interpret the MVC pattern differently. Trying other frameworks will help you discover which interpretation style works best for you.

I like the Zend Framework the best, and this article pretty much explains my reasons. Plus, it’s sponsored by Zend Technologies, the creators of PHP. Some resources I’ve found helpful are:

• Zend’s Tutorial Screencast Videos - basic stuff to get you started.
• Understanding the Zend Framework - on IBM’s site.
• Zend Developer Zone - has links to some great tutorials and examples.
• Choosing Your Application’s Directory Layout - some examples on how to structure the files for your Zend based web site.

This is the extent of my discoveries so far. I hope this post helps someone else thinking of starting a web project. I’ll be using the Zend Framework in my new project, and we’ll see how it goes.

Share This