Archive for the ‘programming’ Category

Compiling PHP

Monday, August 4th, 2008

I didn’t realize that there was a project underway to allow developers to compile their PHP code, but I’m glad to hear of it.

Compiling your first script


This script takes a source PHP script called in.php, and outputs a compiled PHP script called out.php

<?php

$fp = fopen(”out.php”, “w”); // Create the destination PHP file (in this case called out.php)

bcompiler_write_header($fp); // Write a bcompiler header in the destination file

bcompiler_write_file($fp, “in.php”); // Compile the contents of the source file and place in destination file

bcompiler_write_footer($fp); // Write the bcompiler footer in the destination file

fclose($fp); // Close the destination file

?>

A rule for user interaction: keep debugging information out of error messages

Sunday, February 10th, 2008

Yet another example of bad web programming. I was researching the subject of cancer and followed a link on a government site that gets me to this page:

Error message on government site: debugging information should be kept off of live sites

I think its fine to print debugging information to the screen when a website is under development, but on a live site, I think the error messages should try to be more helpful. Perhaps the error message can suggest the average speed it takes the site’s sysadmins to fix problems of this time. Or the error message can suggest that the visitor go get the page out of the Google cache. Even the cutesy error message that Stikipad used was more reassuring than this.

Someday, I will learn the ‘bash’ scripting language

Thursday, November 15th, 2007

Found this useful tutorial: Advanced Bash Scripting.

I’ll post it here so I can find it later. I’ve promised myself that one day, I shall be able to write all kinds of shells scripts. I’d like to be able to automate any kind of activity that we need to have happen on the server.

Microsoft’s website is broken

Monday, October 1st, 2007

 Yes, that is a broken image link on the Microsoft website (I hit refresh a few times and it was still there). Ironically, the page is talking about a new technique for debugging.

Error on the Microsoft page about KISS debugging

Part of what is becoming a continuing series on the subject of broken web pages.

Old Navy website is broken too

Sunday, September 30th, 2007

Well, maybe “broken” is too strong a word. The CSS failed to load. Which happens sometimes. Which is part of why semantic markup is important. How much does the user experience survive the lack of style sheets? This from the front page of Old Navy:

oldnavybroken.jpg

Just curious, but does anyone know some common reasons why the CSS files might fail to load?

Also curious about the marketing. The front page of the site is aimed entirely at women. Do women buy clothes online more than men?

Sprint PCS is even more broken than before, thanks to its merger with Nextel

Monday, September 24th, 2007

I’ve written before about the error messages I’ve encountered on the Sprint PCS website. I’ve been unable to log into the Sprint PCS website this month - I get some bizzare error messages instead.

Today I figured I’d try to use my phone to pay the bill. I hit “*2″ which dialed customer service for me. I reached an automated voicemail system. It asked me to type in my phone number, so it could look up my account information. I did so. It then told me that I owed Sprint $513. I was stunned. By my calculations, I owe something like $200. I pay about $97 a month, and I owe last month and this month. I’m not sure how the amount doubled.

Eventually, the automated system gave me the option to talk to someone. I pressed the button.

A pleasant, helpful woman got on the line and asked for my telephone number, so she could look up my account information. I gave her the number and she said they had no account information for me. I explained that I’d had this account with Sprint since March of 2001. She explained that she worked for Nextel, she didn’t have account info for Sprint customers (the two companies are merging).

This is puzzling. If Nextel doesn’t have any of my account information, then why should my phone auto-dial Nextel when I press the buttons for customer service? Also, if Nextel has no information about me, how did the automated system tell me that I owed $513?

What happened next is also puzzling. I said, “Okay, can you transfer me to Sprint Customer Service?” She said she could not transfer me there. She could, however, give me the phone number. Why can’t the phone company transfer me to the number they want me to go to? I find that confusing.

I dialed the number she gave me.
Sprint PCS also had an automated system. It asked me to type in my telephone number, so it could look up my account information. I typed in my telephone number. It said there was no account with that number, and it suggested I type it again. I assumed I’d mis-typed it, so I tried it again, carefully. Again, the automated voice system told me that there was no account with that number. I didn’t know what else to do, so I typed in the number a 3rd time. Again it told me there was no such telephone number.

I couldn’t think of what to do then. The automated voice system did not give me any other option. It kept asking me to type in my telephone number. It asked me 4 more times, and then, when I did nothing, it hung up on me. It never offered to transfer me to a human operator, who might have been able to resolve the situation.

I’ve had this account for 6 and half years. Right now, I seem to be completely locked out of it. The computer at Sprint PCS claims my account doesn’t exist. At Nextel, the computer says I owe the incredible amount of $513, and then the operator says she has no access to my account information because it is over at Sprint.

I don’t need to know many of the details to tell that the merger of Sprint and Nextel databases is going badly. If I had stock, I’d sell it. This is the worst customer service experience I’ve had in many years.

The Sprint PCS website is still broken

Monday, September 24th, 2007

I’ve already written about Sprint PCS and its broken website. I’m now visiting the site ten days later, and I’m surprised to see the error isn’t fixed yet. This is from today:

Sprint PCS error message, 10 days later

You’ll recall from my previous post that Sprint PCS wrote me on the 17th and said they’d contact me within 3 business days to follow up regarding this matter. I’ve yet to hear from them. Of course, my phone service just got cut off because I have not been able to pay the bill. So maybe they tried to call but couldn’t get through. Ironic, yes? If only they’d let me into their site, I could activate my phone and they could call me to tell me, no doubt with great sincerity, that Sprint PCS really cares about its customers.

Badly done error messages from GoDaddy

Sunday, September 23rd, 2007

I was helping a client move their site from GoDaddy to another web server. I logged into GoDaddy and found the MySql database and made a backup. Then I got sidetracked for 15 minutes. When I started working again, I got this error message (screenshot below). GoDaddy is right to log me out after 15 minutes of inactivity, that much is good security. But they tell me where I am suppose to go in the text, without providing a hyperlink. I can only get out of this page by hand editing the URL in the address bar. Badly done.

Godaddy Error Message - you’ve logged out!

Apologies allow for simpler systems that may fail more often

Thursday, September 20th, 2007

I find this quote very interesting:

Business realities force apologies. To cope with these difficult realities, we need code and, frequently, we need human beings to apologize. It is essential that businesses have both code and people to manage these apologies.

…

We try too hard as an industry. Frequently, we build big and expensive datacenters and deploy big and expensive computers.

In many cases, comparable behavior can be achieved with a lot of crappy machines which cost less than the big expensive one.

That’s from Pat Helland an ex-Amazon architect. His point is that businesses can get way with building imperfect systems that will occassionally fail, so long as the business realizes that sometimes it will have to apolgize. The simpler systems will be much cheaper than a complicated system that will offer a higher rate of reliability.

SprintPCS has a broken website (Updated)

Friday, September 14th, 2007

Yet another story about a badly programmed website, with really bad error messages.

I went to pay my monthly cell phone bill. Just last month, SprintPCS instituted a new policy, requiring stricter passwords with more letters and numbers in them. So I was forced to change my password. Perhaps I was also in a hurry, as I did not write it down in the usual place.

Today, unable to remember the new password, I clicked the link they offer for “Forgot your password?” I came to the screen you see in the first image.

this is the form on SprintPcs.com where I request my password

I typed in my “username”, which is simply my telephone number. When I hit the submit button, I got, in response, a blank white page with the text “Error: 500″. That’s it. Nothing else. Just that text on a blank white page. You can see it in this second image:

This is the error message I got from SprintPCS. Not very helpful, is it?
I offer this anecodote as one more small piece of evidence for the case that most web sites are horribly programmed and poorly tested. I don’t mean to pick on SprintPCS, since there are many sites that are just as bad, but this just happens to be the broken website that I interacted with today.

Mind you, the above incident happened this morning, around 11 AM, and now it is 11 PM. I just went back to get screenshots. Twelve hours later, the problem is still there.

I sent SprintPCS an email about this. I have not yet heard back from them. I’ll update this post if I do hear from them.

UPDATE: wonderful response time. I just got this, on the 17th. The irony:

Date: Mon, 17 Sep 2007 14:08:18 -0500 [02:08:18 PM CDT]

From: Sprint Customer Solutions <ecare@cc.sprintpcs.com>

To: LAWRENCE@KRUBNER.COM

Subject: Re: Subject: ID # 20070914212929 (KMM38317571I123L0KM)

Hello Lawrence Krubner,

Thank you for contacting Sprint.

A ticket has been submitted in reference to the difficulty you are experiencing logging into your account online at Sprint.com. The ticket number is 16880851.

A follow-up call will be made to you within 36 business hours.

Thank you again for contacting Sprint. We appreciate your business.

Mary O.
E-Care
Sprint
“Where our customers come first!”

Refer someone to Sprint and get $25.

So after 3 days, they send me an email in which they promise to contact me within 3 days. Then they close with “Where our customers come first!” Hate to think how we’d be treated if we came second.

Software engineering is a young profession

Sunday, August 19th, 2007

Taylor’s career was 30 years old when “management” became a recognized profession during the 1920s. Likewise, people have been software engineers for the last 50 years, but the field has been slow to coalesce the practices and disciplines that one associates with a profession. Jeff Atwood has a nice piece on the youth of computer science. My favorite part:

As in all programming, the idea is to notice when the same solution is appearing repeatedly in different contexts and to understand the commonalities. This is admirable and valuable. The problem with the “Design Patterns” movement is the use to which the patterns are put afterward: programmers are trained to identify and apply the patterns when possible. Instead, the patterns should be used as signposts to the failures of the programming language. As in all programming, the identification of commonalities should be followed by an abstraction step in which the common parts are merged into a single solution.

Multiple implementations of the same idea are almost always a mistake in programming. The correct place to implement a common solution to a recurring design problem is in the programming language, if that is possible.

The stance of the “Design Patterns” movement seems to be that it is somehow inevitable that programmers will need to implement Visitors, Abstract Factories, Decorators, and Façades. But these are no more inevitable than the need to implement Subroutine Calls or Object-Oriented Classes in the source language. These patterns should be seen as defects or missing features in Java and C++. The best response to identification of these patterns is to ask what defects in those languages cause the patterns to be necessary, and how the languages might provide better support for solving these kinds of problems.

MySpace continues to fail to get basic programming right

Sunday, July 29th, 2007

When I log into MySpace, I’m told that I’m part of my extended network:

Myspace has a lot of errors

This is idiotic. I’m me, my friends are my network, and their friends are my extended network. Yes, because I am one of my friend’s friends, I can see why the code might initially think of me as part of my own extended network. However, it is confusing, and it speaks to really poor programming. After all these years, with all their money, can’t they get something so obvious fixed?

Database war stories

Sunday, July 29th, 2007

This article regarding data storage and its use is a goldmine of information. The comments that follow are also excellent. The article is focused on Bloglines and Memeorandum, but the comments evolved into a “flat files versus databases” debate. Some choice excerpts from both the article and the comments follow:

[For Bloglines] As evidenced by our design, traditional database systems were not appropriate (or at least the best fit) for large parts of our system. There’s no trace of SQL anywhere (by definition we never do an ad hoc query, so why take the performance hit of a SQL front-end?), we resort to using external (to the databases at least) caches, and a majority of our data is stored in flat files. Sure, we could have just gone with Oracle running on a big SAN, but that would have been very expensive overkill, both on the hardware and on the software licenses (and features, for that matter). And relational databases oftentimes are not the most efficient mechanism to store data, so we’d still most likely have to resort to using memcacheds.

In the comments, a fellow named Phil Swenson said that using flat files, instead of a database, was always a terrible idea. Many comments then followed, offering opposing views.

John Hart said:

Databases are useful for ad-hoc queries, schema flexibility, transactional semantics, and flexible indexing.

If you don’t need these things, you can get a _lot_ of wins by not using a database. If you’ve been developing within a database for a long time, seeing the performance you can get from flat files will blow you away. You realize, “oh, wow, computers are a lot faster than I realized because the database has been in my way for so long.”

As a funny example, what’s the quickest way to get a sorted 1TB dataset from Oracle? No matter how you define your indices, it’s still quicker to export unsorted data via SQL*Loader and then sort it yourself. Crazy, but (in my experience) true.

Scott Lewis:

Part of Phil’s point may be that databases provide a consistent, highly-referenced system for storing and retrieving data, whereas flat-file systems tend to be idiosyncratic. This affects not only ongoing support issues, but the actual value of a product, potentially. New purchasers of an online site, for example, would want surety that the data can be easily and reliably managed in the future. Databases tend to be better at providing that than flat-file systems, no matter how robust or fast.

Patrick Tufts disagreed with Phil’s assertion that “if you ever wants to extract/analyze data it will be painful.” Patrick wrote:

In my experience, doing very large-scale data analysis at Amazon and IBM, this is not the case. I prefer to work with flat files (either logfiles or full database extracts) because I’m going to do multiple passes over nearly every record, and most databases, while great for random access to records, are terrible when you just want everything.

Andy writes:

I have a huge directed graph stored in MySQL as a single table with (parent, child) relationships. As an optimization for other purposes, this gets flattened into a complete mapping of all ancestors to all descendents. The graph is maintained in an SQL table for maintenance reasons (we already have the tools that can manipulate the graph as stored in MySQL). The graph, and thus the table, is relatively small, 4000 nodes and 2000 edges.

Traversing the entire graph using SQL queries in sequence (query each node when it is reached) took 25 minutes. Selecting everything from the table and generating the same data structure (parent->child relationships, not nested structures) in perl cut the run time down to 45 seconds. That’s 45 seconds to traverse the entire graph. Of course, once it’s all in memory, that kind of speed is to be expected.

Chris M writes:

one advantage of a database is it makes it easy to change your schema, as phil pointed out. If your project is at all visionary or cutting-edge, that freedom is indispensible, since you never know what direction you’ll be going in next. What kind of relationships will be the most important ones, etc.

If you’re lucky though, and then smart, you’ll be able to cache essentially all of your application in “flat” html files in front of your database. You regenerate only the ones you need to when the database is modified, which should be infrequently. This is the approach Rails takes. Then also your pages can be comprised of up to dozens of small bits and pieces, so that when a master page is invalidated, the database is only hit to regenerate just the part that was changed and the regeneration only takes a half second or something.

Gavin writes:

The time to learn a relational db and then special cases to back up, etc., are big time inputs needed for rdbms. Do not forget that in the ‘against’ category..

YouTube Scalability

Sunday, July 29th, 2007

How does YouTube deal with the huge amounts of data that it must manage?

I found it interesting in light of my own comments on YouTube’s 45 TB a while back.

Here are my notes from his talk, a mix of what he said and my commentary:

In the summer of 2006, they grew from 30 million pages per day to 100 million pages per day, in a 4 month period. (Wow! In most organizations, it takes nearly 4 months to pick out, order, install, and set up a few servers.)

YouTube uses Apache for FastCGI serving. (I wonder if things would have been easier for them had they chosen nginx, which is apparently wonderful for FastCGI and less problematic than Lighttpd)

YouTube is coded mostly in Python. Why? “Development speed critical”.

They use psyco, Python -> C compiler, and also C extensions, for performance critical work.

They use Lighttpd for serving the video itself, for a big improvement over Apache.

Each video hosted by a “mini cluster”, which is a set of machine with the same content. This is a simple way to provide headroom (slack), so that a machine can be taken down for maintenance (or can fail) without affecting users. It also provides a form of backup.

The most popular videos are on a CDN (Content Distribution Network) - they use external CDNs and well as Google’s CDN. Requests to their own machines are therefore tail-heavy (in the “Long Tail” sense), because the head codes to the CDN instead.

Via Sam Ruby.

If you are successful on Facebook, then you will fail

Saturday, July 28th, 2007

A very interesting take on the Facebook platform:

Translation: unless you already have, or are prepared to quickly procure, a 100-500+ server infrastructure and everything associated with it — networking gear, storage gear, ISP interconnetions, monitoring systems, firewalls, load balancers, provisioning systems, etc. — and a killer operations team, launching a successful Facebook application may well be a self-defeating proposition.

This is a “success kills” scenario — the good news is you’re successful, the bad news is you’re flat on your back from what amounts to a self-inflicted denial of service attack, unless you have the money and time and knowledge to tackle the resulting scale challenges.

Will every Facebook application go through this?

No, of course not. The ones that nobody uses will not have this problem.

But the successful ones all will.

The implication is, in my view, quite clear — the Facebook Platform is primarily for use by either big companies, or venture-backed startups with the funding and capability to handle the slightly insane scale requirements. Individual developers are going to have a very hard time taking advantage of it in useful ways.

There is so much data on the web that all the rules of databases need to be rewritten

Tuesday, July 24th, 2007

The modern relational database came together around 1970. SQL (Structured Query Language), the language for getting data into and out of databases, was created shortly thereafter. The early relational databases were great for when a company needed to manage a few million records. Banks could keep track of their customers transactions, and airlines could keep track of their customers tickets. But now, it seems, we’ve reached a point where relational databases no longer work. At least, not for the giant stores of data that exist on the web, stores that might have billions, or tens of billions, of records. Apparently the increased speed of CPUs and the much greater availability of RAM has not been enough to give databases the extra speed they need to handle the larger data sets. The implications of that are worrisome.

Joe Gregorio has seen a new pattern emerge for handling very large data sets:

Sure you can store a lot of data in a relational database, but when I say large, I mean really large; a billion or more records. I know we need this because I keep seeing people build it.

He goes on to outline the main features of the new pattern that he sees:

Distributed
The data has to be distributed across multiple machines.
Joinless
No joins, and no referential integrity, at least at the data store level.
De-Normalized
No one said this explicily, but I presume there is a lot of de-normalization going on if you are avoiding joins.
Transcationless
No transactions

Things that inspire envy of computer languages I don’t use

Tuesday, July 24th, 2007

Ruby, Python, Perl, PHP, JSP, etc. For web development, the languages themselves have certain strengths, but they also, eventually, acquire software projects that make them famous. Ruby, of course, has Rails, and through that, all the software of 37 Signals, and also Twitter. PHP, in the early days, was known for projects such as Phorum. Python is known for Zope and the Universal Feed Parser.

I’ve worked with Ruby a little and PHP a lot but I’ve never worked with Python. If I ever learn it, it will be so I can use Venus. Venus uses the Universal Feed Parser to pull in a variety of feeds, and it has a template engine that allows the input to be output in any format: HTML, RSS, Atom, etc.

Sam Ruby explains the role that the Universal Feed Parser plays:

It handles multiple feed formats, date formats, and ill formed feeds. Just one concrete example to illustrate the point: the author name can be obtained from one of eight different places in your feed; and the Universal Feed Parser even handles cases where people simply put names in place of email addresses or tack on names as comments after an email address.

It partially cleans the HTML. It uses SGMLLIB to clean up the tokens, then it removes unsafe constructs (like plaintext), and resolves relative URIs.

“Consider the karma implications of cursing the driver”

Tuesday, July 24th, 2007

Matt Mullenweg has been critical of the PHP core team for abandoning PHP 4. Sam Ruby calls him out and says with open source projects there is no “Us” versus “Them” since you can freely join “Them” whenever you want. Matt replies:

What I think is missing is an understanding of what made PHP 4 such a killer update to 3, where 5 didn’t compel as many people. I also think there is a deeper discussion around language usability from a casual web coder’s point of view. As this comment say there can be a decreasing marginal utility. Every language doesn’t have to do everything. That’s what I was hoping to get people talking about, and it worked.

And Sam replies:

Those that contribute to PHP apparently feel the most pain concerning support of multiple versions. Yes, you can argue that they brought this upon themselves; but it is worth noting that at this point you are along for the ride. When I’m in similar circumstances, I tend to consider the karma implications of cursing the driver.

Read the whole thing, it’s worth it.

What is the correct way to handle errors in PHP 4?

Monday, July 9th, 2007

Over at comp.lang.php I asked how best to handle errors in PHP 4:

I’m working in PHP 4. Even if a parameter is mandatory, I nearly always give it a default value of “false”. Then I print an error message if someone who is calling my function forgot the mandatory parameter:

function outputHtmlToShowFile($fileName=false) {
if ($fileName) {
// code goes here
} else {
echo “In outputHtmlToShowAFile() the code expected the first
parameter to be a file name, but instead the value was false”;
}
}

How do others handle default parameter values?

I’ve been assuming that relying on the PHP parser to write my error messages for me is unprofessional. I was wondering if other programmers felt that way. I got mixed reactions from others. (I unfortunately used the phrase “professional PHP programmer”, and every respondant made fun of me for that. I apologize for using the phrase)

Iván Sánchez Ortega wrote:

[Catching ever error this way ] is over-engineered and unneccesary.

If “someone” forgets to pass you a parameter, it is because:

- They haven’t looked at your function definition (they are bad programmers)
- You haven’t specified that they have to pass you a parameter (*you* are a
bad programmer)

So:
- Document your code (use doxygen/phpdoc/whatever)
- Tell other programmers you work with how your code works, and what they
can expect from it.

The “professional” way to go is to write specs on paper, then have everyone
read them, then assume everybody will be following them.

Ben Conley had the most interesting response:

My post got longer and longer as my thoughts came together on this subject. The gist of my claim is that you shouldn’t build something as FRAGILE as a function that breaks if there are argument variations, when you can simply build a more robust function in the first place. The final answer? Pass in a structure rather than require ongoing maintenance of all references to a function so as to avoid an error you never should have gotten in the first place.

There are two options here. You can create your function with a static set of arguments that fails when it is called with missing parameters, then counter with the retort that the dude who called it was a “bad programmer.” This is totally useless when your production sites are throwing unnecessary errors. The second option is to pass in a structure and simply check for various optional arguments.

Any “professional” programmer who relies on the vast repository of *documentation* present in most projects in industry is either an idealistic novice, or EXTREMELY fortunate for the places they’ve worked.

I have fantasies that someday I will collect all the good ideas I’ve heard and combine them into the world’s most amazing framework. I admire the way every method in JQuery always returns the object that it is acting upon, and therefore you can chain method calls together. That is an idea I’d like to see in a PHP framework. I love the way all parameters passed into a method in Ruby are automatically what (in PHP terms) amounts to values in an associative array. I’d love to see something like that in a PHP framework. Conley is suggesting something even better than passing in an associative array (which has the weakness that it is a primative), he’s suggesting that we always pass in an object with a particular structure. (Or perhaps there is a base class that gives certain properties to all classes in the system.)

However, Gosha Bine summed up a thought I’ve been having a lot for the last year:

You do test your software before it goes production, don’t you?

That’s exactly right. All that is needed in a system, in terms of error checking, is tests. If you have tests, you don’t really need error checking. And if you find yourself still needing error checking, it probably means you have not yet written enough tests.

When your code generates HTML, you rob designers of their ability to innovate

Friday, June 29th, 2007

Some fellow posted a commerical notice to the comp.lang.php newsgroup. For a mere $79 per developer, you can get a PHP framework that does all the same stuff as the free, open-source PHP frameworks. And it has all the same problems, too. In an old post on the Category4 weblog I was ranting about the problems that stem from generating HTML from inside of PHP code. When a PHP framework generates HTML and CSS from inside the PHP code, then programmers end up working on problems that designers could solve much faster. Consider this problem, which the PHP Developers Kit offers as an example of all the wonderful things you can do if you use their $79 framework:

The workhorse of PHP Kit is the container class . It is a box containing other objects, like text, links, paragraphs and even other containers. It is under CSS control so you may create a container using several dozen options, like background color, border style, border color, font size and font color.

Note: the containers above displayed correctly in Microsoft IE when displayed inline (left to right). However, Mozilla Firefox version 1.5.0.4 displayed them left to right but with no width or height except for the width of their borders. When displayed as block (one above the other), Mozilla displayed their size correctly. The display property (inline or block) is not suppose to effect an element’s assigned width and height.

So, um, you really should be able to control these containers from your code, but when you run into a problem, such as different browsers interpreting your CSS differently, you (the programmer) are stuck solving it. The designer, who specializes in CSS, can not solve your CSS problem for you, because they don’t know how to edit the PHP code that generates the CSS. Ideally, all CSS issues should be the domain of your designers, not your programmers, but when all the CSS is controlled by PHP code, then solving this problem is shifted from the designers to the programmers. This leads to workflow problems - in too many web design shops the programmers have too much work to do and the designers too little, and frameworks such as this are to blame. This is bad economics - to the extent that your programmers are paid more than your designers you should be trying to shift work from programmers to designers.

Concentrating all of the important design work into the hands of the programmers is also bad for morale - I’ve worked in shops where the designers had no work to do because they were waiting for the programmers to finish a bit of PHP/CSS template code. It is demeaning and embarrassing for the designers to have no work. I’ve seen them try to make busy work for themselves and they always look a little embarrassed and ashamed. A well-run web design shop will strive to avoid this.

Designers are focused on communicating with other humans, programmers are focused on communicating with machines. One’s users and clients suffer when the actual power to design is taken away from designers and given (even accidentally) to programmers. It is a rare programmer whose insight into user behavior matches that of a highly skilled designer. An intuitive sense of the user experience is the most important skill that a good designer brings to their work. If all the real design power is in the hands of the programmers, one’s websites and web software are likely to be less intuitive than what might have otherwise been achieved. By contrast, a framework that maximizes the power of the designers is a framework that maximizes the chances of a great user experience being achieved.

Again, let me repeat (as I said in that previous post), frameworks like this (I mean the one I’m criticizing) are fine for the individual freelancer who does all their own programming and design work. But these frameworks are harmful to web design firms that work on large sites and who, therefore, need programmers and designers to work together. As soon as you have a division of labor, you need a framework that facillitates workflow, rather than blocks it.

The last time I wrote on this issue (back when I still worked at Category4) a fellow named Matt responded:

While I generally agree on your view of no html in your php, I think there are exceptions. It’s really about choosing what for when and where. For example, form elements being generated by code is acceptable to me. Even as a designer, I would think that looking at a page with a few php/template tags would be better than a page with lots of html; it’s still code. Less control, but as long as the code is doing what you want then there is no worry. And you could always either override/extend the classes generating the code or hack it…. I think that my point is that one could continue to mull over what to use and prematurely optimize resources to the point of getting nothing done.

I’ll say again, if an individual is doing both the programming and the designing, then putting HTML into the PHP might speed things up for them, but as soon as the jobs of programmer and designer are split, then anything that robs designers of their power is likely to lead to work-flow problems. And those cost money, time, morale and sometimes management focus. They also limit the ability of the designers to achieve a great user experience. Matt suggests that form code can be generated by PHP code, but if you do that, you will very likely get cookie-cutter forms. Forms are the single most important area for designers to innovate a great user experience, but the ability of designers to innovate is wiped out if the HTML is generated by PHP code.

As to “you could always either override/extend the classes generating the code or hack it”, only a programmer can do this. Designers can’t do this on their own. If the designers need this done, then they need to wait on the programmer to do it. And then, once again, you end up with a work-flow problem that damages the productivity of the firm. Either the firm’s profits will be reduced or the costs must be past along to the client, driving up what they must pay for the project.

As to “one could continue to mull over what to use and prematurely optimize resources to the point of getting nothing done”, I’m sorry I haven’t stressed this, but the opinions I’m expressing have grown up on me slowly over the last 5 years. In 2002 I started work on a PHP/MySql content management system and I made every mistake that I’m now critical of. Back then, I wrote functions to simplify my forms, such as:

textInput(”author”);

All the HTML was in the function. It’s exactly what I’m now critical of. So what I’m expressing in this post isn’t premature optimization. It’s way-overdue optimization. I’m looking back at the mistakes I’ve made over the last 5 years and I’m trying to express what I’ve learned so others might now avoid making the same mistakes I’ve made.