{
    "href": "/post/2006/06/14/no-more-loners/",
    "relId": "2006/06/14/no-more-loners",
    "title": "No More Loners!",
    "author": "pmjones",
    "markup": "html",
    "tags": [
        {
            "href": "/tag/php/",
            "relId": "php",
            "title": "PHP",
            "author": null,
            "created": null,
            "updated": [],
            "markup": "markdown"
        }
    ],
    "created": "2006-06-14 16:16:22 UTC",
    "updated": [
        "2006-06-14 16:16:22 UTC"
    ],
    "html": "<p>Read and heed the latest from Clay Loveless:  <a href=\"http://www.killersoft.com/randomstrings/2006/06/14/stop-writing-loner-applications/\">Stop Writing Loner Applications</a>.</p>\n<blockquote>\n<p>After nearly a decade in web application development, I continue to be dumbfounded by how many applications are built and released by the open-source community that apparently believe that they'll be the only complex, user-database application I'll will want to run.</p>\n<p>...</p>\n<p>In nearly every case, these loners have been built with no apparent concern for the fact that the person or company involved may already have a database of users, or that one of the other applications may be installed alongside it. Hard to believe, but true.</p>\n<p>The result is that the guys in the trenches trying to put together a cohesive whole have to spend a great deal of their cycles writing and maintaining \"bridge code\"\u00c2\u009d to allow site visitors to register and authenticate against all of the chosen applications at once. ...</p>\n</blockquote>\n<p>Right on, Clay.  Authentication and user-profile support in particular are a real burden to bear.  I've tried very hard to make my apps (such as <a href=\"http://yawiki.com\">YaWiki</a>) authentication-system agnostic, and the user-info related classes in <a href=\"http://solarphp.com\">Solar</a> are read-only for exactly that reason.</p>\n<p>One of the nice things about Solar-based authentication is that it is adapter based: you can change the backend from an LDAP server to an email server, or to a .htaccess file, and you never need to change your application code.  (<a href=\"http://pear.php.net/Auth\">PEAR Auth</a> also provides decent tools for this if you need PHP4 support.)</p>\n<p>I have one other major criticism of most public code:  classes are not generally namespaced properly.  It's as if project managers think theirs is the only \"User\" or \"Member\" class in the world.  All classes need, at a minimum, a project-name or vendor-name prefix.  (Consistency in naming is a related issue, but I'll save that for another time.)</p>\n<p>This is one thing the Zend Framework gets right, although it was against their will for a very long time.  (All Zend classes are prefixed with \"Zend_\" so they automatically deconflict with all other userland classes.)  That's one thing I'm glad I kept yammering about while I was at Zend; it took months to get the managers to accept that as a naming convention, and even then it was only through the combined efforts of numerous developers to push it through.</p>\n"
}