Archive
/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.
David's Tech Blog 