I’ve attached my modified version of the qTip library (based on v.1.0.0-rc3 — current at the time of writing) which solves these issues.

Changes

Here’s what I had to fix in order to make this compatible:

1. There’s a bug in qTip that is still lingering. It only becomes an issue when using a recent version of jQuery. I had to make the modifications described in the link mentioned previously.
2. WordPress can’t give jQuery exclusive usage of the “$” variable, so all “$” references must be changed to “jQuery.” This script has been updated to reflect those changes.

Download

As promised, the modified Javascript file is available here: Wordpress-Friendly qTip Library (388).

Usage

To use this (or any) Javascript file in WordPress, you’ll need to add a few lines to the “functions.php” file of your active theme.

//make sure we've loaded jQuery
wp_enqueue_script('jQuery');

/*
* Adds the qTip javascript library.
*/
function addQtip() {
 wp_enqueue_script('qtip',get_bloginfo('template_directory') . '/js/jquery.qtip-1.0.0-rc3.min.js');
}
add_action('init', 'addQtip');

This script assumes that you’ve uploaded the attached Javascript file in the “js” directory of your active theme. If you have it elsewhere, you’ll need to adjust the reference in the “wp_enque_script” line.

And that’s it! You should now be able to use qTip within WordPress.

1. Use R 2.12 (under development, at the time of writing) and execute the following two commands:

source("http://bioconductor.org/biocLite.R")
biocLite("MBCB")

2. Manually install the packages into older R version available here.

Sample data files are still available in the previous announcement.

Photos #7, 8 taken by Dave Allen.

12►

Complete paper available here: Genetic Engineering from a Christian Perspective (1170)

1. It could lower the entry barrier to the field. Individuals interested in developing an algorithm but without the means to collect a significant amount of data will be able to use this data to experiment. Also, most researchers don’t have access to pressure-sensitive keyboards when developing their algorithms. This data will allow researchers to test their algorithms and consider this extra dimension of typing data.
2. I hope that this dataset could become a standard for the field of keystroke dynamics. One thing which I felt was substantially lacking in my literature review was any basis of comparison when analyzing different approaches. My hope is that researchers can, after developing an algorithm, measure their results on this dataset as a way to objectively compare performance.

The data is currently available in two formats, with a third in the works.

A MySQL database dump is available here: Public Keystroke Dynamics SQL (18615). The structure of the database is depicted in the figure to the left.

The same data is also available is a series of Comma-Separated-Value (CSV) files and can be downloaded here: Public Keystroke Dynamics CSV (3520). The same structure and relationships apply, though they’re obviously not enforced in CSV files.

The data was collected over a period of a few months in 2009-2010 on over 104 different users. “Extensive” data was collected on 7 of these users – who entered between 89 and 504 entries total.

The rest of the users just entered each password between 3 and 15 times to provide a substantial amount of “impostor” data on each password.

Three different passwords were tested to try to cover the range of different approaches in KD:

1. pr7q1z – a password of gibberish meant to test the performance of Pressure-Sensitive KD on modern “strong” passwords.
2. jeffrey allen – the use of personal information (such as a name) has been recommended in KD before. By using my own name and recording my typing habits on it, the performance of using personal information can be measured.
3. drizzle – a word meant to test the use of normal dictionary words which likely have no personal significance to any user.

In total, 2,739 entries were collected — over 900 on each password.

Please feel free to use this dataset for any non-commercial purposes. I do ask that you let me know if you use this dataset and please use the following citation (for now):
Allen, Jeffrey D., An Analysis of Pressure-Based Keystroke Dynamics Algorithms, Computer Science and Engineering, Southern Methodist University, 2010.

If you’re interested in contributing more data (pressure-sensitive or not), please contact me as well; I’d love to incorporate more datasets into this one.

Another dataset is available at http://www.cs.cmu.edu/~keystroke/

Many WordPress sites use a page-based layout (meaning that the tabs in the header represent static pages, one of which is generally the “blog” or most recent posts). However, I use a category-based layout; clicking a tab leads you to a dynamically-generated page which contains the most recent posts within that category. I quickly found that the WordPress.com Stats plugin doesn’t track such views (as well as search results, and some other dynamic page views). I just implemented a hack to get around this and allow tracking of category (or any other type of) pages which just involves a few changes to a PHP file.

This write-up will assume that you have WordPress installed and setup and have installed and enabled the WordPress.com Stats plugin.

Background

The Stats plugin counts hits by loading a Javascript file from the WordPress servers and tracking the subsequent function calls. In this way, they don’t count  hits from robots and web-crawlers (or any other non-Javascript-enabled device). Note that this Javascript isn’t loaded if you’re logged in, but try looking at the source of your page from another computer (or another browser) and you’ll notice some Javascript code at the bottom of the page that looks something like:

<script type="text/javascript">
   st_go({blog:'yourBlogID',v:'ext',post:'yourPageID'});
   var load_cmc = function(){linktracker_init(yourBlogID,yourPageID,2);};
   if ( typeof addLoadEvent != 'undefined' ) addLoadEvent(load_cmc);
   else load_cmc();
</script>

The Stats plugin basically reduces to this Javascript code. Every time the function is called for a certain blogID and pageID, the hit counter gets incremented. Typically, when a Category or Search page is loaded, the pageID in that code is set to 0, which tells Stats not to increment the hit count of any particular page. The idea is simply to change that 0 to something meaningful on special pages which aren’t typically tracked.

Creating Fake Pages

The first step was to create a Page representative of a category. On my site, I have a category entitled “Professional.” So I created a Page called “Professional” and set it to Private. Whenever you create a Page or a Post, it will be assigned a unique ID (at the end of the URL will be something like ?p=125, which means that the ID for this post is 125). By setting it to Private, this page doesn’t get shown on my site and it won’t interfere with anything; I’m just using it as a placeholder.

I repeat this step for every one of the new pages I want to track (in my case, there were just 4 category pages). As you create the Pages, take note of the ID of each one. So now we have Private Pages that correspond to the pages we want to track. These pages will never get any visits of their own merit, as they’re private. So if we were to count any hits from our category views as hits on these new Pages we just created, then we’d know that every visit credited to those pages was actually a visit to the category page.

Edit the PHP

So how do we change those 0′s in the Javascript to the new Page IDs we just created? We’ll just need to modify one PHP function.

In your admin panel, click on the Plugins tab and find the “WordPress.com Stats” plugin. Then click “edit.” This will open up a huge PHP file called stats.php; this is all the code used by the Stats plugin.

You can scroll through this file, or just search for the text “function stats_footer”‘; this is the function used to create that Javascript we mentioned earlier. In the middle of the function, you’ll see

if ( $wp_the_query->is_single || $wp_the_query->is_page )
   $a['post'] = $wp_the_query->get_queried_object_id();
else
   $a['post'] = '0';

which controls the pageID printed in the Javascript. Essentially, it’s saying, “if we’re currently on a Page or Post, use the ID, otherwise use 0.” We just need to modify that logic to consider whatever type of pages we want. In this case, I’m interested in the Category views, so I add in the following conditional:

else if ( $wp_the_query->is_category ){
     //manually translate category codes into private page views.
     $catID =  $wp_the_query->get_queried_object_id();
}

Now, if we’re on a Category page, we have the opportunity to manually set a new ID to use instead of 0. We’re given the category ID (in the variable $catID). You can find the Category ID for a given Category by looking at the address for the Category. For example, my ‘Professional’ Category is at http://jdadesign.net/?cat=3, so I know the Category ID = 3. So we just need to translate those category IDs into the corresponding pageIDs using the format:

if($catID == 3){ //professional
   $a['post'] = 81;
}

Where ’3′ is the category ID for the ‘Professional’ category and ’81′ was the ID of the private Page I created entitled ‘Professional’.

Complete Example

We’ll put one of these conditionals for every page on which we want to track the stats, so the final code will look something like this:

   $a['blog'] = $options['blog_id']; 
   $a['v'] = 'ext'; 
   if ( $wp_the_query->is_single || $wp_the_query->is_page )    
      $a['post'] = $wp_the_query->get_queried_object_id();
   else if ( $wp_the_query->is_category ){
       //manually translate category codes into private page views.
       $catID =  $wp_the_query->get_queried_object_id();

       if($catID == 1){ //personal
          $a['post'] = 82;
       }
       else if($catID == 24){ //photos
          $a['post'] = 83;
       }
       else if($catID == 25){ //thoughts
          $a['post'] = 84;
       }
       else if($catID == 3){ //professional
          $a['post'] = 81;
       }
    }
    else
       $a['post'] = '0';
?>

And you should be up-and-running! You can test it by visiting your Category (or search, or whatever) pages on a browser on which you’re not logged in. You should see hits appearing for your Private pages which you’ve so wisely titled to correspond to the category page which you actually care about tracking.