Showing posts with label Best Practices. Show all posts
Showing posts with label Best Practices. Show all posts

Sunday, January 10, 2010

Phing Build Script

See Phing Build Script at its new home on bradley-holt.com.

I've been experimenting with using Phing to automate building and deploying web applications. I want to share one of my build scripts and perhaps get some feedback from anyone with more experience using Phing. The requirements for the build script are fairly simple:

  • It will not handle deployment. This particular web application is deployed by the client's IT department.
  • It will create a ZIP file (it could just as easily create a tar.gz file) that the client's IT department can extract and deploy.
  • It will rename the document root since the document root is a different directory name in the client's production environment then it is in our development and testing environments.

Next, an outline of what the build does:

  1. Prompt for Subversion credentials (I'd rather not store these in a file).
  2. Prompt for the Subversion tag to build from.
  3. Delete the source directory if it exists.
  4. Export the given tag to the source directory.
  5. Rename the document root.
  6. Create a ZIP file, named after the version, of the source directory's contents.
  7. Clean up after itself by deleting the source directory.

Both of the build files are in the project's root directory (in my project, this is one directory above the document root). The build.properties file defines three properties: document root (so we can rename it to this new name), the source directory (the place to export to and then manipulate folders/files), and the URL to the repository's tags directory.

The build.xml file is the actual build script, performing the actions outlined above. I've obfuscated the project name to be "acme". I could not find a way to create a prompt that hides the Subversion password as it is entered (anyone?). For renaming the document root, I used the exec task to execute a move (mv) command since the move task failed for me (so this script will not work as-is on Windows).

Executing this script is as easy as running phing build-tag (once Phing is installed) from within the project's root directory. Please let me know if you have any questions or see any room for improvement.

Saturday, January 2, 2010

Web Design and Web Development

See Web Design and Web Development at its new home on bradley-holt.com.

Back in October, Jeffrey Zeldman tweeted something that I strongly agree with:

Real web designers write code. Always have, always will. #aea

This sparked many conversations including these two tweets from Chris Shiflett:

According to @zeldman, real web designers write code. (I think he means HTML and CSS, not PHP, Perl, and Python.) What do you think?

I’ve now asked, separately, whether developers and designers should know HTML and CSS. In both cases, most think they should. Interesting.

To which I responded (brackets added):

@shiflett IMHO, the demarcation between web developers and web designers should be POSH [Plain Old Semantic HTML]. That's what both need to know.

I have a pretty strong opinion about this. You could say that I have the luxury of working with an excellent designer who implements all of his own CSS—even tackling much of the JavaScript coding on websites we build. To be clear: he is a designer, not a developer—working in both print (which is more technical than you might think) and web.

The typical process is summarized well in Marco Tabini's PHP Advent 2009 post on CSS and Other People:

From a developer’s perspective, “design work” means having to deal with the often hated, sometimes impossible, and always challenging task of translating a designer’s comp into a combination of HTML and CSS that will render properly on browsers that are often at complete odds with one another.

In my opinion, that process is broken. Why is it assumed that because HTML and CSS are "code" it should be a developer's job to implement these? Any decent designer is already familiar with the concept of separating presentation and content with style sheets (which are supported in Adobe InDesign, QuarkXPress, and even PageMaker and Microsoft Word). Is learning HTML and CSS, both declarative languages, considered too hard for designers?

Let's take a look at comps and the dreaded "s" word—slicing. As Marco pointed out, trying to "slice" a comp into HTML and CSS is "sometimes impossible" and "always challenging." If a designer is only providing a comp, and not the HTML and CSS, it is very likely that the designer does not have a solid understanding of things like progressive enhancement, browser compatibility, and even what is possible on the web.

The use of a comp generally assumes that design is purely visual and that all representations of the web page should look exactly like the comp. How should the content be presented to screen readers, to mobile devices, and in print? Sure, you could provide comps for each of these scenarios but this is not scalable and you quickly risk violating the "One Web" concept. Thinking of a web page through the lens of only one specific visual representation of that page is very limiting.

Do you agree that the typical process is broken? If so, what are the barriers to fixing this process? Do we need better trained web designers? Do organizations need to be educated on how to better structure their web teams? This problem will eventually self-correct. My prediction is that teams with web designers that know HTML and CSS will create better websites and web applications and be more successful than teams using the old process.

Tuesday, April 7, 2009

Open (local) Government

See Open (local) Government at its new home on bradley-holt.com.

Last night I went to the Burlington, Vermont City Council meeting to listen to our newly re-elected mayor, Bob Kiss, give his State of the City speech and watch the City Council attempt to elect a new council president. I said "attempt" because, after 14 rounds of voting, they were still deadlocked 7-7 for opposing candidates. However, that's not what I want to talk about. In Mayor Bob Kiss' speech he made the following statement:

My administration worked closely with the Open Government Committee formed by resolution of the City Council. In response to committee recommendations, we’ve included more information about public meetings on the City web-site and the Planning Department added a new section about proposed and pending zoning amendments. During the campaign it was clear that people want to know more about the activities of each city department. Over the next year we’ll look closely at how to finance and build a more uniform, responsive and user-friendly City website that will keep you better informed about public meetings and how you can participate in the process of government.

I'm all for open government and the City of Burlington, Vermont could certainly use a better website. I'd like to give the city some advice on its priorities in building a better website. This blog post is my first round of advice, but I'd like to hear reactions from other web people in and around Burlington — or anyone else who has an interest in our city having a better website! This advice is based on the goals outlined by Mayor Bob Kiss: that the website is inline with the spirit of Open Government, is responsive, and is user-friendly.

First, the website must be accessible and use open standards. I put these two together because by using open standards the website can be accessible. Specifically, the website should use strictly semantic XHTML. This allows for its use in the widest range of user agents (browsers) by the widest range of user abilities (as opposed to disabilities). Its presentation should be progressively enriched through CSS and its behavior should be progressively enhanced through unobtrusive JavaScript. Progressive enhancement means that the website is useful, at its core, without any CSS or JavaScript. It becomes more useful through the use of CSS and then, perhaps, even more useful through the use of JavaScript. However, neither CSS nor JavaScript should be required to access the website's content.

Second, the website should be built using free (as in freedom, not cost) and open source software. It is our government's responsibility to use non-proprietary software wherever possible. When it comes to building websites and web applications, there are no excuses for not using free and open source software. The capabilities of the open web platforms available equal, or exceed, the capabilities of proprietary web platforms. Any custom software developed for the city's website must be licensed to the city under a free and open source license (this does not mean that the city shouldn't pay for this software to be developed).

Third, the city should embrace the concept of open linked data. This means that the city should publish data, not just content. This data should be both human and machine readable. This allows third parties to access raw data and repurpose this data in new and interesting ways. To this end, data and content should be either put in the public domain (which is probably the case already) or use a Creative Commons license. Where possible, the city's website should consume open data published by others rather than duplicating effort. There are several technical approaches to publishing and consuming open linked data including Microformats and the Semantic Web.

I hope these recommendations are useful. Once I've heard some feedback from other web people, I'll forward these recommendations to my city councilors and the mayor. Hopefully they'll find it helpful in improving the city's website!

Monday, March 16, 2009

The Web Is Not A Visual Medium

See The Web Is Not A Visual Medium at its new home on bradley-holt.com.

A claim you may have heard me make before is that the web is not a visual medium. Some of you know exactly what I mean and some of you probably think I'm nuts. For those of you who think I'm crazy, let me elaborate. You, like most people, probably experience the web visually. However, this visual aspect is only one facet of the web. Underneath the visual aspect you will find that the web is a structured, or semantic, medium. This means that people (or even machines) of varying capabilities (as opposed to disabilities), using all sorts of user agents (a fancy way of saying web browsers) can experience this same web non-visually. If built correctly, the same web page should be accessible to you visually as well as to visually impaired people, search engine robots, people that want to use text only web browsers, people using older versions of web browsers (backward compatibility), people using mobile devices, and user agents that weren't even invented yet when the web page was first built (forward compatibility).

There's one catch. There are many web sites and web applications built on the incorrect assumption that the web is a visual medium. The web designers and web developers who build these web sites and web applications break the web. In order to not break the web, web designers and web developers need to use open standards starting with plain old semantic (X)HTML. This semantic (X)HTML can then be progressively enriched/enhanced using CSS (for presentation) and JavaScript (for behavior). This approach works well with the concept of One Web which "means making, as far as is reasonable, the same information and services available to users irrespective of the device they are using."

Craig Cook has a good article about How to Grok Web Standards in which he addresses many of these ideas and more. If you still think I'm crazy, hopefully it's not because you think I'm wrong about the web not being a visual medium. If you don't think I'm crazy then maybe in another blog post I'll talk about why I think that content management systems (CMSs) in general, and WYSIWYG editors specifically, break the web.

Saturday, January 17, 2009

CSS for Web Developers

See CSS for Web Developers at its new home on bradley-holt.com.

The Burlington, VT PHP Users Group will be meeting Thursday January 22nd from from 6:00 pm to 8:00 pm. Since we (Found Line) recently had some demolition - I mean renovations - done we've got a bit more space so thought we'd finally host the meeting. Here's a description of the presentation, "CSS for Web Developers", that Jason will be giving:

Most web developers don't consider themselves designers—and shouldn't. The reality of working on a website or web app, however, is that developers must either wear the designer hat or must interface with a designer/design team. Having a solid understanding of design best practices makes for a more efficient process and a higher quality product. Come hear more about web design and CSS from a designer's perspective. We'll cover semantic markup and its influence on CSS implementation, reset and debug stylesheets, tools for creating and debugging CSS, coding standards, and maybe even microformats if time allows. The goal isn't to convert developers into design experts, but rather to give an overview of an effective design process that works for designers and developers alike.

Jason Pelletier is Creative Director and Web Designer for Found Line. The Burlington-based creative firm develops standards-based websites, product packaging and marketing strategies for growing businesses. Clients include Seventh Generation, Vermont Public Radio, EatingWell and True Body Products. Prior to co-founding Found Line, he managed creative resources for Seventh Generation, and was a designer for Stonyfield Farm.
More details here. Please pass this on to others you think might be interested. Pizza will be provided and we will be giving away a "please don't hurt the web - use open standards" t-shirt as well as a copy of Jeffrey Zeldman's book "Designing With Web Standards". Hope to see you there!

Saturday, September 27, 2008

Testing Requirements with Unit Tests

See Testing Requirements with Unit Tests at its new home on bradley-holt.com.

I'm currently working on a project where the client is running their own web server that I will not have direct access to. This is actually a good thing in that it is a nice way to enforce the separation of the development and integration environments from the staging and production environments. However, how do I be sure that all of the system requirements will be met so that I can address any potential problems early on in the project? Sure, I could just give them a file with phpinfo() in it and have them send me the results. However, I plan on also shipping them unit tests for the application so why not have the requirements tested through unit tests as well?

My first thought was, since the application is being built in Zend Framework, just ship them the Zend Framework unit tests. It turns out there are a lot of unit tests and they have some heavy memory requirements. So, I decided on a simpler approach. I would run unit tests that simply tested for the requirements outlined in the Zend Framework documentation. Here are the tests:

/**
* The Requirements test case.
*
* @category Requirements
* @package Requirements
* @copyright Copyright (c) 2005-2008 Found Line, Inc. (http://www.foundline.com/)
* @license http://www.foundline.com/legal/software-license/ New BSD License
*/
class Requirements extends PHPUnit_Framework_TestCase
{

public function testVersionOfPhpIs5Dot1Dot4OrLater()
{
$this->assertTrue(version_compare(PHP_VERSION, '5.1.4', '>='));
}

public function testVersionOfPhpIs5Dot2Dot3OrLater()
{
$this->assertTrue(version_compare(PHP_VERSION, '5.2.3', '>='));
}

/**
* @dataProvider requiredExtensions
* @param string $extensionName the name of the extension for which to test
*/
public function testExtensionLoaded($extensionName)
{
$this->assertTrue(extension_loaded($extensionName));
}

public static function requiredExtensions()
{
return array(
'apc' => array('apc'),
'bcmath' => array('bcmath'),
'bitset' => array('bitset'),
'ctype' => array('ctype'),
'curl' => array('curl'),
'dom' => array('dom'),
'gd' => array('gd'),
'hash' => array('hash'),
'ibm_db2' => array('ibm_db2'),
'iconv' => array('iconv'),
'interbase' => array('interbase'),
'json' => array('json'),
'libxml' => array('libxml'),
'mbstring' => array('mbstring'),
'memcache' => array('memcache'),
'mime_magic' => array('mime_magic'),
'mysqli' => array('mysqli'),
'oci8' => array('oci8'),
'pcre' => array('pcre'),
'pdo' => array('pdo'),
'pdo_mssql' => array('pdo_mssql'),
'pdo_mysql' => array('pdo_mysql'),
'pdo_oci' => array('pdo_oci'),
'pdo_pgsql' => array('pdo_pgsql'),
'pdo_sqlite' => array('pdo_sqlite'),
'posix' => array('posix'),
'reflection' => array('Reflection'),
'session' => array('session'),
'simpleXml' => array('SimpleXML'),
'soap' => array('soap'),
'spl' => array('SPL'),
'sqlite' => array('SQLite'),
'standard' => array('standard'),
'xml' => array('xml'),
'zlib' => array('zlib'),
);
}

}

Note that I've checked for both the recommended PHP version 5.2.3 and the required PHP version 5.1.4. Also, I've tested for both hard and soft dependencies for all components. This means that many of these tests could fail and my application could still be OK. I wanted as much information as possible so that I can detect any potential problems before I write too much code. As the specific requirements for this application become clearer, I will update the test to add or remove requirements. Of course, once there is real code and unit tests these requirements tests will become irrelevant. The point is to test for the presence of these requirements before I write the code.

Running these tests with the command phpunit --testdox Requirements.php (I've actually wrapped this into a bigger test suite, but that's outside the scope of this blog post) gives me the following output on one of my development machines:

PHPUnit 3.3.1 by Sebastian Bergmann.

Requirements
[x] Version of php is 5 dot 1 dot 4 or later
[x] Version of php is 5 dot 2 dot 3 or later
[x] Extension loaded with data set "apc"
[x] Extension loaded with data set "bcmath"
[x] Extension loaded with data set "bitset"
[x] Extension loaded with data set "ctype"
[x] Extension loaded with data set "curl"
[x] Extension loaded with data set "dom"
[x] Extension loaded with data set "gd"
[x] Extension loaded with data set "hash"
[ ] Extension loaded with data set "ibm_db 2"
[x] Extension loaded with data set "iconv"
[x] Extension loaded with data set "interbase"
[x] Extension loaded with data set "json"
[x] Extension loaded with data set "libxml"
[x] Extension loaded with data set "mbstring"
[x] Extension loaded with data set "memcache"
[x] Extension loaded with data set "mime_magic"
[x] Extension loaded with data set "mysqli"
[ ] Extension loaded with data set "oci 8"
[x] Extension loaded with data set "pcre"
[x] Extension loaded with data set "pdo"
[ ] Extension loaded with data set "pdo_mssql"
[x] Extension loaded with data set "pdo_mysql"
[ ] Extension loaded with data set "pdo_oci"
[ ] Extension loaded with data set "pdo_pgsql"
[x] Extension loaded with data set "pdo_sqlite"
[x] Extension loaded with data set "posix"
[x] Extension loaded with data set "reflection"
[x] Extension loaded with data set "session"
[x] Extension loaded with data set "simple xml"
[x] Extension loaded with data set "soap"
[x] Extension loaded with data set "spl"
[x] Extension loaded with data set "sqlite"
[x] Extension loaded with data set "standard"
[x] Extension loaded with data set "xml"
[x] Extension loaded with data set "zlib"


There are a couple of potential problems to be aware of. First, PHPUnit will have to be installed on the machine that this will be tested on. This should probably only be done on the staging machine, not the production machine. Second, the CLI version of PHP often uses a different php.ini file then the CGI or ISAPI version. This means that some requirements may actually be available to your web application but they will fail the test when run at the command line.

Monday, September 22, 2008

ZendCon 2008

See ZendCon 2008 at its new home on bradley-holt.com.

ZendCon 2008 wrapped up last week. This was my first time going to ZendCon and it was definitely worth it. There were over 650 people and over 60 sessions at the Santa Clara conference. I'll try to post summaries and highlights from the sessions I attended. It was a great opportunity to attended presentations from some of the most well respected people in the PHP community including Vermont's own Matthew Weier O'Phinney (Zend Technologies), Mike Naberezny (Maintainable Software), Sebastian Bergmann (eZ Systems), Derick Rethans (eZ Systems), Ben Galbraith (Ajaxian.com) , Marcus Boerger (Google), and Ben Ramsey (Schematic).

Zend Certified Engineer (ZCE) in Zend FrameworkLast Tuesday during the opening keynote Zend announced the new Zend Framework certification. I was fortunate enough to get a testing slot on Thursday morning. After reading the 214 page study guide on Wednesday I passed the test, so am now a Zend Certified Engineer (ZCE) in Zend Framework! If you plan on taking the test, I definitely recommend reading the study guide. I've been using Zend Framework since 1.0 and I'm not sure I would have passed if I hadn't read the study guide.

Thursday, July 31, 2008

Development/Integration/Staging/Production

See Development/Integration/Staging/Production at its new home on bradley-holt.com.

I am surprised by how many developers think it's OK to do work directly in a production environment or to deploy to production directly from their development environment. I found a good article today that explains the traditional Development/Integration/Staging/Production practice. The specific setup may be different depending on your environment, but the basic ideas are the same.

Friday, July 25, 2008

Easy Way to Run Web Applications Locally

See Easy Way to Run Web Applications Locally at its new home on bradley-holt.com.

I've been trying out a new way to run web applications on my local machine. Since I work on many different websites I like to be able to run these sites on my local machine. This lets me try out changes locally before committing them to Subversion and rolling them out to a staging or production environment. In the past I've simply created a new virtual host in Apache listening on its own port. The problem with this is that not only do I need to manually setup each new site, I also need to remember which site goes with which port number.

So, I've started using Apache's dynamically configured mass virtual hosting. This gets me two things. First, I don't need to make any changes in Apache's configuration file when I want to setup a new local web application. Second, I now have an easy-to-remember naming convention for sites that are running locally. This works really well for me, but your mileage may vary depending on your specific needs. There are also other tools that can help you accomplish similar results, but I like the simplicity of this in that it doesn't require anything other than Apache and some DNS settings.

Let me explain the end result first, and then I'll explain how I got there. For each website I work on I use the subdomain to indicate the environment it's running in. Using the domain example.org we may have the following environments setup:

  • local.example.org - the local copy
  • beta.example.org - a semi-publicly available beta
  • www.example.org - the live site
The beta and www versions aren't anything special, just normal websites. For local.example.org I need to have a DNS entry that points to the loopback address, 127.0.0.1. This can either be a publicly available DNS entry (which could be a little awkward) or simply set in your hosts file. I've simply made the entry in my hosts file:

127.0.0.1 local.example.org

The downside of this is that you would need to update the host file on each machine that you wanted to run the local.example.org site on. A comprimise would be to run your own recursive DNS service that only your computers used and make the DNS entries there.

This next step only needs to be done once. The dynamically configured mass virtual hosting article explains in detail how to set this up. My Apache configuration looks something like this:

VirtualDocumentRoot /path/to/workspace/%2+/public

Again, your specific configuration may be different. When making a request to http://local.example.org/ the document root would expand to /path/to/workspace/example.org/public. This assumes that you have placed all of your projects in the same location and they all have a similar directory layout (I'm using Zend Framework's directory layout). I think there's a way to do this in a way that's more flexible, but I haven't had the need. Let me know if you have any questions!

Friday, June 27, 2008

Burlington, VT PHP Users Group Meeting Last Night

See Burlington, VT PHP Users Group Meeting Last Night at its new home on bradley-holt.com.

A big thanks to Bluehouse Group for hosting Last nights Burlington, VT PHP Users Group meeting! Both Matthew Weier O'Phinney and Rob Riggen provided some great presentations. Matthew's presentation was a continuation of his best practices series. This one was on documenation. Rob presented the latest installment of his framework series, this one on Zend Framework. I think we had a decent turnout for a summer users group meeting. Any other web developers out there, put next month's meeting on your calendar! We meet the fourth Thursday of every month.