CartMetrix - Do you know yours?

3/17/2006

UploadTo Shell Script

Try this quick upload-to shell script to easily upload files to any server running an ssh daemon.

Create a new shell script called uploadto_hostname.sh with the following two lines:

#!/bin/bash
scp $@ username@host.domain.com:

Set username and host.domain.com. Create one for every frequently used server.

To use simply pass the name of the file(s) to be uploaded:

# uploadto_myserver.sh file1 file2 file3

If you are using secure key authentication, you won’t even need a password!

Popularity: 10%

Share This

3/15/2006

Scintilla

n.

  1. A minute amount; an iota or trace.
  2. A spark; a flash.

Popularity: 5%

Share This

Caching Remote RSS Feeds With PHP

Previously I noted how Wordpress' admin main page took forever to load because of the remote RSS feeds it checks on every page load. After wading through the code I found that the Magpie RSS parser Wordpress uses does have a caching system built in but it doesn't appear to be enabled. The Wordpress Trac system contains a ticket saying this should be included in WP 2.1.

I wrote a snippet that can be integrated into any remote fetching system to cache the resultant fetched data transparently.

<?php
$fetch = true;
$cache_file = './.news_rss';
if(file_exists($cache_file))  {
   $mtime = filemtime($cache_file);
   // if file is older than 2hrs refetch
   if($mtime > (T_STAMP - 7200)) $fetch = false;
}

if($fetch)  {
   // fetch the remote file
   $url = 'http://domain.com/rss.php';
   $fp = fopen($url, "r");
   if(! $fp)   return false;
   while (! feof($fp)) {
      $str .= fread($fp, 80);
   }
   fclose($fp);
   
   // cache result
   $fp = fopen($cache_file, 'w');
   fwrite($fp, $str, strlen($str));
}  else {      
   // read from the cached file
   $fp = fopen($cache_file, "r");
   if(! $fp)   return false;
   while (! feof($fp)) {
      $str .= fread($fp, 80);
   }
   fclose($fp);      
}
?>

Popularity: 10%

Share This

Setting Timezone on Linux

Find your timezone in:

/usr/share/zoneinfo/
ln -sf /usr/share/zoneinfo/your/zone /etc/localtime

Popularity: 6%

Share This

3/10/2006

Tired of Waiting on Wordpress Admin Main Page

The Wordpress admin main page contains several blocks of content retrieved via RSS from Technorati and the Wordpress site itself. The content itself is a useful addition to the admin panel as it is used to post news, security alerts and development information. The problem I find is my main admin page takes up to a minute to load while these links are fetched. Reload the page and we wait again while same data is re-fetched.

While the feature is worthwhile, the implementation is broken. Not only do I (and every other WP user) have to wait eons for the page to load, the servers the data is being fetched from are needlessly overtaxed by all of this redundant fetching. A waste of resources on both sides. The data could be fetched once and cached for hours, saving local wait time and load on the Wordpress servers.

On one recent software project I was involved with, the vendor was using their blog to post a changelog, news and security alerts for their software. I wrote a simple RSS fetcher that saved the retrieved information to the database to be reused for up to a day before being refreshed.

Maybe the next time I have a weekend afternoon to kill, I’ll work out something similar for Wordpress.

Popularity: 10%

Share This

3/8/2006

Why Do People Ask Dumb Questions?

I have two clients who have recently noticed their sales contact queues were increasingly filling up with questions and information requests concerning information readily available via their websites.

Why?

It’s so much easier to pop off a quick email than actually read. If you don’t read, how do you know what you are buying? Forget the small print… many people don’t seem to be reading the normal-sized (and even bold) print.

Good customer service dictates trying to answer all questions promptly, but that only feeds this behavior.

What to do?

My first instinct was to optimize pages and design to make sure that the data is easily available. We found a few small tweaks to make some of the information more easily found, but the two sites were already very well laid out.

Discussions with colleagues led to some other interesting options:

Prepare a form response stating the information is available on the site. Some provided a place for support personnel to provide a link and others left the requester to let their fingers do the clicking.

Sit on the request for a day, allowing them time to find their own answer (and perhaps feel stupid). This may seem like a good idea, but you still end up spending the same amount of support time fielding the request (eventually), and your customer receives a subpar customer service experience. I might suggest holding on to any dumb requests until the end of the day and sending them all out at once with a form response as above. This won’t interrupt meaningful support functions and the customer shouldn’t perceive a bad experience. Specific support procedures is a whole other post though.

File 13 the requests. Trashing the requests may seem harsh, but if your business requires after sale support (such as a web application) these kind of clients are expensive to support. Are the worth it?

If you site hasn’t been optimized by a professional (and best a fresh set of eyes) don’t even think about these ideas. The problem could be your fault.

Popularity: 13%

Share This

« Previous Page • Next Page »


damonparker.org is proudly powered by WordPress
Entries (RSS) and Comments (RSS).

copyright © 2002-2009 damonparker.org. all rights reserved.

Close
E-mail It