Archive for February, 2008

Frameworks

Over the years I’ve written a number of web applications basically from scratch.  I almost always use PEAR and other libraries, but for the most part I’ve always used my own code as the basic framework.  Last year I started building a number of modules for Drupal, including some that automate business processes (such as inventory and producing PDF documents for brochures based on live business data).  This is convenient because these modules fit nicely into  larger intranet type sites for the organizations that use them.  But Drupal isn’t really designed to be an application framework.  Since it isn’t intended to be that, they apparently feel free to completely redesign key parts of the API between versions, which really makes upgrading expensive.

So more recently I’ve been looking again at a couple of  the frameworks that are available for PHP, this time Solar and Zend Framework.  I’ve looked at these before, along with Cake.  I didn’t care for Cake, and ZF and Solar weren’t ready yet last time I looked.

Solar and ZF are much closer to ready for real use now than they were last time I looked closely at them.  Over the weekend I built a few simple prototype level things from both Solar and ZF.  The short of it is that I really like Solar.  It is very easy, and I found it very intuitive.  I shouldn’t be surprised, Paul M Jones has a history of writing good stuff.  I had a site running in very short order with Solar.

I think that the main problem with Solar is the size of the community.  I need a number of the features that Zend Framework provides, but aren’t available for Solar yet, like SOAP, XMLRPC, RSS, support for MS SQL server connections (I’d rather not need that, but I do), and others.  I could write them for Solar, but most of what I need is already available from ZF.

Zend Framework doesn’t have the conceptual consistency and elegance of Solar, and I’m having a hard time piecing together the bits of it that I need.  Its sort of like building your own Linux from scratch, maybe something every Linux geek should do at least a couple of times but not something you want to do when all you need is a working computer to get stuff done.  When you just need to get work done you want a Ubuntu or OpenSuse to package it for you so you can just get to work.

In the end, ZF is more like PEAR on steroids than it is the framework I want to save me time in piecing something together.  Still, I think its the closest to what I need, and it has the momentum and support behind it to have a rosier future.  So I guess the best approach would be to build my own blank application from the pieces I will commonly use, with all of the components I commonly will need bundled in already, and archive that as an application template.

Or maybe I’ll try Solar some more.

Or maybe I’ll just keep cooking my own.

Test first or test later

A lot has been said about test driven development.  While I am a proponent of testing, I am not a fan of test driven development.  I could go on at length about it, but actually somebody else has already said it clearly, so here’s a link to what Paul M Jones said about it instead of boring everybody with a retelling here.  I’m pretty sure he’s smarter than I am anyway.

Prettify code blocks

Google has a project to do “syntax highlighting of code snippets in a web page” using javascript.  Its here:

http://code.google.com/p/google-code-prettify/

Safely mashed

I’m working on a mashable page for FH’s intranet, and one of the potential issues is safety if we allow content that isn’t on some “approved list”. That’s exactly the point of Caja (from Google) – “A source-to-source translator for securing Javascript-based web content.”

The Caja page also links to some other pages of groups working on other problems. Most notably:
The Caplet Group (on Yahoo tech groups) : The Caplet Group is discussing the situation of the web browser, in particular the Mashup Problem, and the possibility of using a capability messaging system to allow safe and useful communication between frames, worker pools, and other client technologies.

Dynamically add fields to forms

On my old site I had an example of adding fields to forms dynamically, which continued to get hits even long after I had forgotten it was there. The example looked like this:

City
Address1
ZIP
Phone Number
Name

The code looked like this:

[cc lines="20" lang="html"]

function forminsertrow(theForm) {
var insertHere = document.getElementById(\’cloneme\’);
var newElement = document.getElementById(\’cloneme\’).cloneNode(true);
insertHere.parentNode.insertBefore(newElement, insertHere);
}

Search For:

City
Address1
ZIP
Phone Number
Name

[/cc]

This leaves you with kind of an ugly array that looks something like this:
[cc lang="php"]
$_REQUEST['search'][0]['field'] = ‘address:city’;
$_REQUEST['search'][0]['value'] = ‘Phoenix’;
$_REQUEST['search'][1]['field'] = ‘name:full’;
$_REQUEST['search'][1]['value'] = ‘David’;
[/cc]
You generally need to do something with this to make it more usable. A loop like this one transforms it into a more nicely formatted array:

[cc lang='php']
foreach($_REQUEST['search'] as $key => $value){
$search[$value['field']] = $value['value'];
}
[/cc]
I have used this approach quite successfully, and visitors seem to find it easy to work with. If I was doing this now, I would probably use a javascript library to do the clone part. For example, with jQuery, you don’t need the function at all. Just change the onclick on the button to this:
[cc lang='javascript']onclick=’$(“#cloneme”).clone().appendTo(“#cloneme”);’[/cc]
In fact, that’s what the working example above actually does.

/proc

A long time ago in another job far far away I was responsible for managing system administrators, and for ensuring the eternal availability of all network services. As is the wont of people trying to make sys admin jobs more efficient and tolerable, I wrote a number of automation scripts to collect information from servers and report it centrally. The actual sys admins in the department at the time had their hands full with their day to day work, so I dedicated some of my time building automation tools for them (at the expense of other things on my to do list, I’m sure). Now there are lots of projects you can borrow other people’s hard work to accomplish this, but back then there was less and I did it myself.

During that time I became way too familiar with the /proc directory on Redhat servers. I have since forgotten most of what I knew at the time, but this nice article by Federico Kereki on Linux.com brought quite a bit back for me. Everything you ever wanted to know and more about a host you can get from /proc.

More than the actual results, I remember going through source code figuring out what the information in the /proc files actually meant, and which information could be reliably used to provide which results. Its easy to misuse statistics, as much so on understanding system health as in any other arena.

Anyway, nothing productive to say here, other than the article is worth reading.

Drupal 6

I have quite a bit of experience using Drupal, at this point more than with any other CMS platform. In the past I’ve run a variety of others, but by a good margin most of my development on these types of things has been on Drupal. I’ve written several modules for Drupal 4.7 and 5.  Of course, I’ve also developed a number of apps and sites that were built from scratch, or on my own code base, or on miscellaneous other products that someone else implemented and then I got to fix, but those are a different issue altogether.

I have been facing the release of Drupal 6 with some trepidation. I have a number of deployed Drupal 5 modules out there (I think all of the 4.7 sites that use my modules have been updated by now), and the job of updating the modules is daunting. There needs to be a pretty compelling reason, I think, to update them, considering the amount of work that is going to be required.

I should probably say that none of these modules are released publicly. They were all to solve specific business needs, mostly of my primary employer (Food for the Hungry). Updating the modules would mean updating the private sites that use them to Drupal 6 as well.

Now that Drupal 6 has been released, I don’t see any compelling reason to bother. Yes, Drupal 6 has a number of very good improvements. Its a good product, and they are continuing to take it in a very promising direction. But the improvements for an established site don’t rise to any huge reason to spend significant time updating these sites. And it would take quite a bit of effort, since the changes are considerable.

I also considered moving this blog back to Drupal, since that is the software on which I base so much of my ongoing work. There is little chance that my development work will stop emphasizing Drupal. However, Drupal does not do anything like the nice job on basic blogs that WordPress does. I guess that’s partly a difference between a more generalized content system (and for me framework for business process automation oriented modules) and a more specialized blogging package like WordPress. I’m fairly confident I would not try to do the things with WordPress that I can do with Drupal. On the other hand, for a basic blog, WordPress is much nicer.

Why design matters

This morning I was reading Jeffrey Zeldman’s article on A List Apart.  The article has a number of quotable lines, but in addition to being quotable, this is one to be remembered:

Web design is the creation of digital environments that facilitate and encourage human activity; reflect or adapt to individual voices and content; and change gracefully over time while always retaining their identity.

The point of the article is that web design is a different thing than other mediums, like posters or other print, or like TV, film, or games.  Web design is more analogous to a building architect, or a typeface.  It is about making an environment that lets other people’s content get communicated effectively without getting in the way.

The things I build are slightly different from the design that gets discussed much on A List Apart.  My work is mostly in applications and conveying business information.  But the basic thrust of this article still applies.  The interfaces I build need to be easy to navigate, make it very easy to find what you’re looking for, make the process of entering information as straight forward and painless as possible, and generally keep out of the way of whatever the user is really trying to accomplish.  The goal of the design isn’t the design itself, or the tool, but to effectively convey information that I don’t have any real control over, or to facilitate a business process.  The goal is the business goal, and the web is the tool rather than being the goal itself.

Then there’s this:

Madame Butterfly is not less beautiful for having no car chase sequence, peanut butter no less tasty because it cannot dance.

Ticket/task systems

Over the years I have worked with a number of ticket systems. They can generally be grouped like this:

  • Systems that are designed for support requests (Request Tracker, many commercial helpdesk products)
  • Systems that are designed to track bug and feature requests for software development projects (bugtraq, eventum, mantis)
  • Systems for projects that emphasize stuff that management wants but don’t really help with actually getting work done.

Quite a few of the bug tracking systems lack user friendly features needed by support departments. Many of the nicer helpdesk products lack basic funcationality needed to track tasks. I haven’t found any products that really do what I want to do with them. What I want them to do is treat tasks like they are tasks, and give them workflows depending on their type but still keep my task lists completely integrated as “the things I’m supposed to do today and over the next two weeks”.

I’m mostly convinced that even as common as these systems are, there is money to be made in developing a system that tracks tasks in a way that supports the variety of different activities that IT departments and other support and development teams regularly do. It basically needs to treat tasks as tasks, and let you manage them with customizable workflows depending on whether they are support or development or recurring kinds of tasks. And it needs to do it without making everybody feel like they are working with software developed by a perl programmer.

reCAPTCHA

If you are looking for a way to prevent post/comment spam, account request spam, or to obscure email addresses, one of the better options at the moment appears to be reCAPTCHA.

There are several reasons to choose reCAPTCHA, some of which are outlined on the web site. Aside from having this done by someone who knows what they are doing and do it pretty well, one of the key benefits I see of using this particular system is that the text is fairly easy for a human to read. Recently on another site that used some other captcha system it took me three or four tries every time I had to solve the “puzzle.” reCAPTCHA doesn’t have that particularly annoying problem. You want to keep the spammers out, but you also want to avoid being so annoying to legitimate posters that they find some easier place to post.

Next Page »