| |
The semantic web is often made of little things:
Web namespace design: de facto standards. As the strengths of the Web's URI-oriented model reassert themselves, some longstanding issues of namespace management return to the fore. [..] you can see that we have sort of, but not really, standardized on a URI format for search queries.
It seems pretty clear looking at this sample that Google's style is the de facto standard, namely: http://domain/search?q=...
I've often thought more standardization in this area would be useful. In general, there's no reason why names like "search.pl" or "query.html" or "search.php" need to exist, or why the root pattern "/search?q=xx" can't be supported. Usually it's possible to control the namespace in the Web server, using mod_perl or an ISAPI filter to map the standard pattern into something site-specific -- and ideally, to hide that site-specific pattern from the user. [..]Some other de facto standards that could benefit from direct or indirect standardization: /about, /products, /faq, /press, /news, /developers, /jobs. [Jon's Radio (full-length descriptions)]
12:09:54 AM 
|
|
Speaking of Joel in italian and serendipity kicked in. New version of his Bug Tracking Package:
November 04, 2002. FogBUGZ 3.0 is now shipping! This is a really huge upgrade; FogBUGZ moves up from being a simple bug tracking package to a rather robust management system that handles the entire development process. [..]
there are some other things that FogBUGZ intentionally does not do.
For example, inspired by software testing guru Cem Kaner and of course Dr. Deming, FogBUGZ does not provide individual performance metrics for people. If you want a report for which programmer makes the most bugs, or the infamous "which programmer has the most bugs that they allegedly 'fixed' reopened by testing because they were not really fixed," FogBUGZ won't give it to you. Why? Because as soon as you start measuring people and compensating people based on things like this, they are going to start optimizing their behavior to optimize these numbers, and not in the way you intended. Every bug report becomes an argument. Programmers insist on recategorizing bugs as "features." Or they refuse to check in code until the performance review period is over. Testers are afraid to enter bugs -- why antagonize programmers? And pretty soon, the measurements give you what you "wanted": the number of bugs in the bug tracking system goes down to zero. Of course, there are just as many bugs in the code, those are an inevitable part of writing software, they're just not being tracked. And the bug tracking software, hijacked as an HR crutch, becomes worthless for what it was intended for.[Joel on Software]
12:03:30 AM
|
|
|
