Entries from Oct 2005 ↓
Oct 30th, 2005 | Web
I just found a blog post by Shirley E. Kaiser at her blog entitled Brainstorms & Raves containing an awesome collection of links and related discussion about Apache’s .htaccess.
While admittedly I write mostly for an audience of developers that use Microsoft-technologies, many of the items discussed apply to Microsoft’s IIS if you use a 3rd party tool named ISAPI Rewrite. This tools provides many of the same features of Apache’s .htaccess on IIS via the httpd.ini config file and implements most of its functionality in a manner identical to mod_rewrite on Apache. I absolutely love this tool and I’ve previously blogged about ISAPI Rewrite as well as The Importance of Well-Designed URLs, the latter of which is IMO the most important reason you absolutely need ISAPI Rewrite if you are hosting a website on IIS.
Anyway, the blog post covers topics and links to articles that:
- Explain how and why to rewrite and/or redirect URLs,
- Discuss techniques for reducing hotlinking and bandwidth theft,
- Talk about blocking bad bots and comment spammers,
- Covers regular expressions needed to match the URLs to rewrite or redirect,
- Explains Robots.txt files,
- Lists which bots are good and which are bad, and
- Covers HTTP error code.
A great resource!
Oct 30th, 2005 | Web
I recently came across a free service I’ve been using for about a week, and I’m finding I really like it.
This free service is called RssFwd, as in "RSS Forward", and it’s totally simply to use. Just type an RSS URL into the text box on the RssFwd home page and click sumbit, then key in your email address and click submit again and you’re done!
And you don’t even have to remember a password to list or unsubscribe from your feeds; just follow one of the links provided in any email RssFwd sends you; nothing could be easier!
Oct 30th, 2005 | Opinion, Software
I just read an editorial that peaked my interest because the concept has been in back of my mind for a while.
The editorial was entitled "Microsoft Should Make Servers Compelling" and is rare for a Dave Coursey editorial in that it was not just a soap-box rant. David basically stated that Microsoft’s cash cow Office is running out of milk and it’s time for Microsoft to look for money elsewhere. And he thinks they should look for money in servers. But not servers purchased by and for IT; instead
"Servers Microsoft can sell to users, or at least servers with such compelling benefit that users demand their IT department install and support them. Better, Microsoft could sell entry-level servers that users could "sneak" onto the network by running it on a spare PC in their workgroup."
He goes on to say:
"The ideal "server for the people," besides being right-now useful, would be able to harness the power of an older PC to help make better use of the hardware customers already own. Microsoft’s hardware OEMs could also sell standalone network appliances or other ready-to-run hardware to implement these services."
I think David’s hit the nail on the head, especially now that most people have access to at least one older PCs and/or they can buy a new PC so inexpensively. More and more I’ve recently felt the computer industry underutilizes agents and service processes in home and small business/departmental computing.
Many apps run as a "service" on your Windows XP computer, such as Google Desktop, but most people don’t think of their desktop computer as also being an "always-on" server running agents for them, and software companies don’t release products like that either.
Heck, a home server could even be a $100 appliance running Window CE 5.0 ($100 if mass-produced, of course.)
If Microsoft would make server-based network software that is iPod-simple to set up, if they released an agent server as a software product, i.e. a batch server designed for grandma, if the agent server was designed to support any number of 3rd party agents, I think we’d see an explosion of innovation (and revenue for Microsoft) in "Servers for End Users."
Oct 28th, 2005 | Opinion
Some people just don’t get it. They are so caught up in their own blind ideology they won’t consider alternative views.
I’ve been looking for a reasonably-priced web-based project management system for quite some time, and yesterday I thought I found it: BaseCamp from 37Signals. Problem is, after an email exchange with the founder Jason Fried, they don’t now and won’t ever (he claims) support a visual view of a project in the form of a GANTT chart.
Why won’t BaseCamp ever support GANTT charts? Maybe it’s BaseCamp’s competitive positioning, or maybe it’s because of ideology; based on BaseCamp’s Manifesto, Jason just doesn’t believe in them. From my email conversation with Jason, is seems to be the latter. Plus, isn’t a manifesto ideological by definition?
Why do I need GANTT charts? Because I’m a visual learner and I need a GANTT chart to be able to see the big picture related to a large number of parallel projects that all share resources. I need this so I can keep from missing deadlines when I’m bombarded with almost literally 100 choices for how to spend my time each day. I even proposed I could try to put BaseCamp and DBI Technologies together for DBI to provide optional GANTT charting of BaseCamp projects via DBI’s Solutions::Schedule product, but Jason wasn’t even interested in entertaining the idea, even if someone else was doing the work.
It’s a damn shame to find a product like BaseCamp that does 90% of what I need but, because of IMO blind ideology, its owner Jason Fried won’t even consider adding a feature for which arguably 65% of people would benefit. Jason’s last comment to me was: “Look at it this way… Go use another tool, get the Gantt charts, but miss the other 90%. Which tradeoff is worth more to you?“ The sad thing is, if it were not for blind ideology, it wouldn’t have to be either/or. :-(
Oct 25th, 2005 | Opinion
I really love using Google for search, for news, and for my default home page. I think they’ve done an awesome job of really meeting users needs when many others can’t or won’t. I also expect to see them rapidly grow and expand into new lots of areas. As a technologist, I’m really looking forward to the many cool things they are going to make available for everyone to use.
On the other hand, Google scares me to death. People love to hate Microsoft because of it’s marketshare in O/S and office suites with Windows and MS-Office, but I don’t think Microsoft controls the fortunes of so many small and medium-sized businesses nearly as heavily as Google. In terms of total number of businesses, at least in the USA, most live or die by their Google traffic today. We had a glitch at Xtras.Net that caused Google to remove us from their index for a few days, and our sales dropped by over 40%!!! Many also hate WalMart because of how they have crushed most local businesses replacing them with a behemoth that is locally ubiquitious and pays practically slave wages.
However, I’m thinking people will soon look back on Microsoft and WalMart as a very benevolent dictators when compared with the future of Google. Google’s mantra may be "Do no evil", but I’m pretty sure the truth contained in the old adage "Power corrupts, and absolute power corrupts absolutely" will prove to be undeniably intoxicating when compared to the early ideology of a few idealists who where at the time isolated from reality.
How soon will it be before we hear the calls to investigate Google on grounds of anti-trust? I for one am starting to believe that sooner is better than later.
I guess time will tell…
Oct 16th, 2005 | Programming, Software
DevSource has another article Will VB 9 Win Over the VB 6 Faithful? where the .NET advocates sing the praises of VB9 and the VB6 faithful bemoan how VB9 will be even worse for them than VB7 and VB8. Problem is, this entire issue has been clouded with emotion, like so many other issues as of late (For example can you say "Iraq War" or "Gay Marriage?" I thought you could.)
What I’d like to know is this: What are the real reasons why VB6ers feel they still need a new VB6 five+ years later? What tangible problems are they having that they can’t get solve by continuing to use the old VB6 for one set of problems and the new VB.NET for everything else?
BTW I’m not taking sides here; I honestly want to see if I can spawn a productive dialog per change to identify viable solutions Microsoft might consider implementing to make everybody happy. FWIW!
P.S. And please don’t say "I don’t want to/have time to learn it" because that’s just unrealistic in the technology industry. Welcome to the real world, after all.
Oct 16th, 2005 | Programming
Blake Watson talks about RemObject’s Chrome, a Pascal that’s not Delphi, on DevSource. There he talks about “class contracts“, a concept I’ve liked since I first read Bertrand Meyer’s Object-Oriented Software Contruction, 1st edition back in the late 80’s back, and a feature I’d love to see in VB.NET. Whaddayasay Mr. Vick?
Oct 10th, 2005 | Programming
After seeing Eric Pascarello’s thread at ASP.NET forums entitled “AJAX - Is it Hype? Is it for you?” I decided to post a thread at ASP.NET forums with a reference to my post from July entitled “AJAX: A Panacea, or a Pending Train Wreck?” UkBtlog responded so I’m blogging my reply below:
I think there needs to be a big distinction between web applications (gmail, google maps, online banking) and web sites (msdn, wired, www.asp.net. AJAX is primarily useful for web applications. AJAX has limited use for web sites.
I’ll agree there is a big distinction in some ways, but that’s part of the point. Most web developers will be drawn to AJAX because it’s the “next cool thing” and you’ll see AJAX on practically every site, and in most cases very badly done. This is no different from when people went crazy with desktop publishing software using tons of fonts and colors in a document! But bad AJAX on the web will have a much more profound negative impact than ugly flyers posted on a light pole.
I’m not arguing that web developers can’t use AJAX well, I’m arguing that AJAX opens a pandora’s box where most web developers will use AJAX and few will do it well.
I don’t believe that AJAX is actually useful for things that search engines are best at searching. To use the example of MapQuest and Google Maps, I have never searched for London Bridge and had MapQuest come up as a result in a search engine. This although it uses query string parameters to be deterministic it isn’t something that is searchable. I can also use the robots.txt to stop search engines and google even tells me how.
Again, we mostly agreed, but UkBtlog again missed my one of my points; web developers will use AJAX badly on web sites that should be searchable.
This is the same as restarting an application and isn’t really a suprise to developers. Sure this may not be the expected user experience, but perhaps the dom standards should give web application developers a way to stop the use of refresh if web apps are to mature.
It’s not a surprise for web developers, but it’s a huge surprise for web users! And a bad one at that!!! One of the reason for the success of usability on the web has been the consistent and constrained UI. Web usability guru Jakob Nielsen quotes in The Top Ten New Mistakes of Web Design (May 30, 1999):
Jakob Nielsen states:
1. Breaking or Slowing Down the Back Button
The Back button is the lifeline of the Web user and the second-most used navigation feature (after following hypertext links). Users happily know that they can try anything on the Web and always be saved by a click or two on Back to return them to familiar territory. Except, of course, for those sites that break Back by committing one of these design sins:
- opening a new browser window (see mistake #2)
- using an immediate redirect: every time the user clicks Back, the browser returns to a page that
- bounces the user forward to the undesired location
- prevents caching such that the Back navigation requires a fresh trip to the server; all hypertext
- navigation should be sub-second and this goes double for backtracking
Further, from Why Frames Suck (Most of the Time) (Dec 1996):
Jakob Nielsen states:
13% of users are still using Netscape 2 which had one of the worst usability problems to be seen on the Web so far: the BACK button in the browser simply didn’t work with framed sites. The BACK feature is an absolutely essential safety net that gives users the confidence to navigate freely in the knowledge that they can always get back to firm ground. We have known from some of the earliest studies of user navigation behavior that BACK is the second-most used navigation feature in Web browsers (after the simple “click on a link to follow it” action). Thus, breaking the BACK button is no less than a usability catastrophe.
And I wouldn’t attack the sources for being old; usability is based on the way humans process information and that doesn’t change rapidly just because someone coined a new term and all the bleeding edge web developers have jumped on it!
Also, Jakob hasn’t written about AJAX, yet, probably because he writes about his usability research results, not just his opinions (like you and me :), but I’m sure he will as soon as he has solid data to back him up.
Developers of web application spend a lot of effort and tears trying to remove the problems of back buttons and refresh behaviour. The web browser shouldn’t be trying to hold state, although it happens to cache the previous page, as HTML is supposed to be stateless. So if I want to buy into implementing state into a website such as using cookies or hidden fields or fancy frameworks like ASP.NET I don’t want the browser interferring with my application state. If I am writing a web site for a company that informs the world on what they do, then I am not keeping any state and the back, forward and refresh buttons hold no fear. Your view is a little simplistic for the variance in reasons for developing for the web.
The criteria for expanding web functionality shouldn’t be about how to make it easier for the developer!!! The web should be about making it easier for the user, and about empowering solutions that were previously unavailable. The stateless web addressable via URL with a well defined content set (HTML, GIF, JPG, and now PNG and PDF, DOC, XLS, etc.) is the technology that has empowered so much economic expansion and functionality on the web. Making it easier for the developer while ignoring other goals will just drag us down into the new dark ages; the dark ages of the web.
AJAX maybe abused as it is the new cool feature, but using framesets or domain rewriting can lead to similar problems. I can also use pointers without correctly releasing the memory, but I don’t.
And you’ll note most web developers have finally stopped using framesets (thank god!) I had some of the same issues with them. (I don’t know specifically what UkBtlog meant about domain rewriting.)
Any of the technologies developers are presented with can be used in a way that is not best practice. If you do this with an information website such as Wired.Com or MSDN the information will not be found and your business will suffer. I only see this “misuse” of AJAX existing in proof of concept and misinformed developers.
This isn’t about what one developer such as UkBtlog does. It is about the health of the web. Many cities have ordinances that say you can’t have a grill on the balcony of an apartment or condo for the same reason. I can make sure I don’t burn down the building with *my* grill, but what about my neighbor? If he doesn’t use his grill safely, he’ll affect *me*. Albeit an extreme analogy, the same is true for AJAX and web developers for the web.
Perhaps we should encourage article writers to discuss best practice use of AJAX to help remove your fears.
Now with *that* I complete agree! So why do you think I am writing these blogs? :-)
But not only writers. We should also encourage tool vendors like Microsoft with their Atlas, and anyone making AJAX toolkits to really think through the issues and make sure their tools encourage best practices.
But what are those best practices? Thus far, I’ve only complained about AJAX. When I have time, hopefully soon, I’ll make some recommendations as I see it for minimizing the threat and maximizing the benefit of AJAX.