1 - 5   [5]

Google Search History

Relates to SEO and Firefox and Co

A little behind the competition, Google has just rolled out My Search History Beta which saves your search beahviour and provides quick access to previous searches using a clustered interface. Chris Sherman discusses My Search History in detail over at Search Engine Watch. If like me your requests from the Firefox searchbar are redirected to your locality (eg google.co.uk), the magic variable seems to be lr. So the following src file (in the searchplugins directory of your Firefox installation directory) will ensure all searches go through the MSH application:

  name="Google History"
  description="Google Search with History Enabled"

<input name="q" user>
<input name="hl" value="en">
<input name="lr" value="">
<input name="btnG" value="Search">


I look forward to seeing how well the clustering engine works as my search results grow…

Posted on Apr 21, 2005 at 12:29:22. [Comments for Google Search History- 1]

Resequence a MySQL column

Relates to MySQL and PEAR

The other day I was asked if I knew a way to resequence a column in a MySQL table. For example if a record were removed from mid-table, how to collapse all the ids above that record to avoid gaps. Of course this would be highly undesirable and potentially destructive if relationships exist, but made an interesting little problem.

The initial solution I suggested, utilising the PEAR_DB package as abstraction layer for the PHP MySQL API, was as follows:

$id = {num}; // the id of the record that was deleted
$pr = $db->prepare('UPDATE table_name SET col_name = ! WHERE col_name = !');
do {
  $res = $db->execute($pr, array($id, ++$id));  
  if (DB::isError($res)) {
    // handle error
} while ($db->affectedRows() > 0);

Errors are trapped to allow break-out from the loop, and, since $db->affectedRows() can return -1 if the query fails, look for at least one (will be only one per loop execution) affected row.

While this seemed like a nice simple solution, it doesn't account for a column that AUTO_INCREMENTs, so assumes that values for col_name are entered manually. Then, courtesy of the MySQL cookbook, I stumbled across a more efficient solution that takes into account just that by utilising the DDL component of the MySQL query language:

$query = "ALTER TABLE table_name "
       . "DROP col_name, "
       . "AUTO_INCREMENT = 1";
$res = @mysql_query($query, $conn);
if (!$res) { // handle errors }

For simplicity, this just uses the standard PHP MySQL API. This will recreate col_name placing it first in the schema order (FIRST). Thus recreating the sequence starting the increment from 1 (AUTO_INCREMENT = 1 - prior to 3.23.39 only). Finally, there is no need to redefine the PRIMARY KEY if it is col_name, since MySQL does not drop the key during the execution of a single ALTER statement.

Personally I cannot think of any reason I would have to resequence a column, especially if it were the PRIMARY KEY, but nice to know it is possible?

Posted on Apr 16, 2005 at 14:51:16. [Comments for Resequence a MySQL column- 0]

Brainbench Games Winner

Relates to Accessibility

With recent distractions from the Severn bore (and the usual run of work) out of the way, I finally got round to following up on the recent Brainbench games results to discover that I scored highest in Web Design for Accessibility, winning a years subscription to all online tests and practice tools. I have never been too convinced by how much weight is put on the results of these online tests, but they do provide a nice way to progress my personal development, and I will certainly be making use of the practice tests to help further my knowledge of the web developers arsenal.

Posted on Apr 13, 2005 at 23:37:13. [Comments for Brainbench Games Winner- 0]


Relates to Apache and PEAR, Blogging

Trendalicious provides a nice way to keep track of popular links in the del.icio.us database of social bookmarks. Unfortunately trendalicious does not come equiped with syndication, but it only takes a bite of the PEAR to put a simple request page together with HTTP_Request, Cache_Lite and an RSS builder.

// code snippet
$cache = new Cache_Lite($cache_options);

if (! $data = $cache->get(TRENDALICIOUS_URL)) {

    $r = new HTTP_Request(TRENDALICIOUS_URL);
    $page = $r->getResponseBody();

    // create rss content from data in $page



header('Content-type: text/xml');
echo $rss_content;

Since I intended on plugging this into Firefox live feeds, I gave the cache file a lifetime of 60 minutes to avoid bombarding the trendalicious page. Also I wanted to keep the feed private (need to keep personal bandwidth down as well), so I set up some basic security measures with mod_rewrite, a subdomain?

RewriteCond   %{HTTP_HOST}       !^subdomain
RewriteCond   %{REMOTE_ADDR}  !^xxx\.xxx\.xxx\.
RewriteRule .* -  [F,L]

? and a directive in robots.txt file.

Posted on Apr 06, 2005 at 01:53:39. [Comments for Trendalicious- 0]

Timewatch Kills the Wave

Relates to Science and Meteorology

While I had high expectations for a rigorous and hotly contested debate on the cause of the 1606/07 Great Flood in Timewatch's The Killer Wave on Friday evening, the title really gave away little hope of anything other than a glorified disaster flick with very poor CG animation.

Media science has evolved a new method of historical analysis - brute force belief through re-enactment. The endless reels of tiresome recreations leave little time for the scientific facts and any form of historical method. But of course ratings are the key, and if that means objectivity is left in the green room, so be it!!

As for the actual debate itself, since the programme was filmed in the summer of last year, no new evidence was elucidated. The tenacious arguments touched upon from Bryant and Hasletts' academic paper did little to further the argument for a Killer Wave. While the first-hand evidence from the 1981 flood demonstrated how devastating a storm surge can actually be, and quite possibly the only potential tsunami invoking cause - a landslide off the continental shelf - was quickly rejected.

This debate has really been discussed enough previously and elsewhere. Storm surge, tidal bore or tsunami? The debate continues. But exploiting the current climate with claims of Killer Waves, the recreation of a 12m wall of water and even the reworking of historical sources to create drama does little to futher our understanding of the past. IMHO, it is destructive to the continued preservation of historical method - especially when such brute force propaganda appears to be so hartily adopted by the academics. Disheartening? :(

Posted on Apr 04, 2005 at 02:32:11. [Comments for Timewatch Kills the Wave- 1]

Breadcrumbs Trail

[ Home ] -> TW Blog -> Archives for April 2005
Site Map

The Severn Solutions website achieves the following standards:

[ XHTML 1.0 ] [ CSS 2 ] [ WAI AA ] [ Bobby AA ]

Page compiled in 0.009 seconds