Though this will be a busy week it won't be an exceptionally busy one. I generally hold that if you have to do more work when you come back than you normally would something is wrong - coming back from a vacation to a higher stress level than when you left is bad.

But, back to the grindstone - and Beverage Subgroup on Tuesday! See everyone there!

This often manifests itself in a lack of comments, or in some sort of "hack" that got tacked on at the last minute to make the code work for what was needed "now." Methods interact with each other in specific ways and there is limited modularization of classes. Procedural code is hard-coded with SQL statements and there's limited room for future development.

This is an easy trap to fall into. When presented with a clear and concise requirements document, it's easiest to build to the spec. But it's not always best.

Continue Reading...

Lots of people figure that the public facing portion of the website is the most important. And for the most part, they'd be right. The public facing portion should be clean, streamlined, and intuitive. But forgetting the administration interface is like having a sleek sportscar with absolutely no controls. Wouldn't make much sense, would it?

The administrative interface of any website is the steering wheel that drives the site. The sheer cost of creating the interface is far less than the total cost over time of asking a developer to update content each time you wish to change it.

I've had a number of clients who opted not to build administrative interfaces, opting for the lower out-of-the-box cost. What they came to realize was that the higher administrative costs were the trade off they faced by their decision.

When building something as critical and expensive as a full website, it is critical too that there be investment into the infrastructure for maintaining it. Anything less is simply throwing good money after bad; the cost may be lower at the front end, but later on down the road the cost will be astronomical.

I'm certainly no Apple fanboy, and though I use a Mac and prefer it to Windows, I am keenly aware of its numerous flaws (try compiling PHP or ask Tony Bibbs). But I do concede that Apple is winning the usability war. So, what can we learn from Apple when it comes to usability?

There are three key components that make Apple products easy to use:

Continue Reading...

Keith Casey mentioned to me one day that he could turn on "commit messages" and I inquired as to what this was. He explained that he could have Subversion mail him every time someone committed to a repository. Being someone who works with others, I thought I'd give it a shot.

Implementing the feature was actually not as hard as I thought it might be. I wrote a short script that simply got the last log entry (in verbose mode) and e-mailed it to myself with a nice wrapper. I also set it up to e-mail a member of my team. So far it looks promising; we'll see if I need to tweak it as time goes on.

As someone who likes user-friendly design, subversion never ceases to please me with its elegance and simplicity, yet its seemingly endless power.

The art of letter-writing has seemingly gone out of style. Instead, we write e-mails, composing our missives in digital form. We store them on electronic devices. But the leading researchers say that digital media will only last about fifty years at the most. Every single hard drive in existence today will fail. It’s not a question of if, it’s a matter of when. As inherently mechanical devices they’re destined to fail.

It’s not as though the pen and paper are somehow a more long-term storage device. Indeed, papers can be destroyed by fire, flood, or carelessness. But we do not yet know the impact of an increasingly digital world on the history writers of 2208. We have no way of determining what, if any, information they will be able to recover about us.

The truth is that our very file structures will not exist in two hundred years, or our method of encrypting and decrypting data. While I would like to presume those of the future to be smarter and more sophisticated than we are today, I have no way of knowing that this will be the case.

As a technologist, I am a fan of digital collections. My music is stored that way, and so are a good number of my most precious memories as photographs and writings. I have no intention to print them onto paper for posterity. And the judge of history will have to make do with the digital records of my life, plain and simple.

I just hope there’s enough information left to make a good accounting.

I've often debated this myself, and I've wondered whether or not charging by the job was better than by the hour. When a person charges by the hour there's always an unknown for the client, and always a question about whether or not the contractor should be efficient and get the job done quickly, to their detriment financially.

I debated this with a few people, including Keith Casey, who seemed to think that being efficient for a client was a benefit in that they would see the developer as an efficient, honest individual. After my discussions I think I've devised a method.

I think it might be best on some projects to charge by the hour. I think that the points mentioned in the Freelance Switch article are reasonable. I don't favor abandoning the by-the-hour model entirely, since some clients will prefer it or demand it, but I think that if we as developers start charging based on value (which is what every retailer does) rather than by the hour, we may see our business increase.

Tell me what you think in the comments.

PHP 4 was a great improvement in PHP, allowing for a number of important features that made PHP a great language, including instituting superglobals like $_SESSION and $_POST, implementing the CLI and CGI, and object oriented programming (such as it was). But with all software, it has reached its effetive end of life, and has been retired.

For those in the DC Metropolitan Area, there is a special wake tonight for PHP 4 where we'll share our most horrific PHP 4 battle stories. We're meeting at Four Courts at 2051 Wilson Blvd. Arlington, VA 2220 at 6:00 PM. Look for a bunch of PHP people.

The six areas of focus that I will be discussing and debating (in no particular order):

• How to make software more innovative, powerful, and easy to use.
• LAMP (Linux, Apache, MySQL and PHP).
• Linux-based systems and software like Subversion, OpenSSH, Postfix, Fetchmail, etc.
• All things Apple (I'm a shareholder, not a fanboy; my support and criticism has a different tack).
• The PHP community in the greater DC area, and the larger community (when I go to conferences).
• The nuances of operating a technology-based business, based on my experiences.

Along the way we may find other topics and that's fine. But for now, those are the main areas I've chosen to focus on. I hope you'll join me in that focus.

Over the past few weeks, I've redeveloped the site to focus on a few key areas of PHP and technology that matter to me, personally.

I believe that there is much to be said about making powerful applications that are easy to use. As a self-described "usability evangelist" I want to see to it that applications are intuitive, easy, and smart. And to that end, I will explore the benefits of smart design here, on this blog.

So take a load off, and poke around. I think you'll decide to stay.

Some housekeeping matters:

• If you'd like to comment, you're welcome to do so. As a primitive spam prevention technique, I've made it so that all comments have to be approved once you sign up. However, if I know you or you post an intelligent comment, you'll be able to post comments without being approved.
• This site is in progress, as is every codebase. Some features are in development, and others haven't been thought of. I take suggestions and you can use the Contact tab above to get in touch with me.
• I hope that you enjoy the site. I've worked hard on it and I'm proud of how it has come together. Thanks all of you for your support...you know who you are.