Performancing Stats for Blogsome
-
Comments:
- here.
This post is a Blogsome specific post with information gleaned from HOWTO: Wordpress Visitor Count Plugin Using Metrics API. If you aren’t using Blogsome, then you’ll be better off visiting there. If you are using Performancing Metrics as your system for tracking usage patterns, you may wish to have a counter of some sort. It’s possible to do this, safely and securely with just a little bit of Smarty. First, you’ll need to get your current Performancing Authorisation Key. This will not change unless you change your password, so keep that in mind if this stops working at some stage… To get your API key, you’ll need to visit a URL like the following, but with your username and password. http://performancing.com/perfstats/api.php?action=getauth&uid;=some+user&pwd;=mypass If you put this into a Firefox address bar, it will display the XML, but the only part we need is the part inside the <auth> tags. Don’t give this to anyone, else they can see all of your Performancing stats. You can now use this key to get some stats. As a test, we’ll get the basic stats of your blog. Copy and paste the URL below, and insert it into the address bar. Then, replace KEY with your authorisation key, and schinckel with your blogsome ID:
http://performancing.com/perfstats/api.php?action=getvisitorstats&auth;=KEY&blog;_domain=schinckel.net
You’ll be presented with some XML that looks like:
<response>
<request>
<auth>KEY</auth>
<blog_domain>schinckel.net</blog_domain>
<action>getvisitorstats</action>
</request>
<ChartURL>
http://performancing.com/perfstats/api.php?action=getchart&blog_domain=schinckel.net&dtype=visitor_stats&ctype=line&m=today&d1=2006-04-17&d2=
</ChartURL>
<Visits>20</Visits>
<AverageVisitsPerDay>20.0000</AverageVisitsPerDay>
<AverageVisitLength>517.9500</AverageVisitLength>
<RepeatVisitors>0</RepeatVisitors>
</response>
You can then use the ChartURL to see a nice graph, something like: If this doesn’t work, then check your API key, and all of the URLs you’ve typed in so far. Now, let’s imagine we just want a counter for total blog views. The URL will need to look a bit like (I’ve broken it onto seperate lines first to help you understand it): http://performancing.com/perfstats/api.php?action=getvisitorstats &auth;=KEY&blog;domain=_blogname.blogsome.com&m;=date_range &d1;=start_date&d2;=end_date We’ll look at how to get the current date a bit later: for now, put a date at some point in the future. Mine, sans the authorisation key was: http://performancing.com/perfstats/api.php?action=getvisitorstats&auth;=KEY&blog;_domain=schinckel.net&m;=date_range&d1;=2006-01-01&d2;=2007-01-01 Which generated the following XML:
<response>
<request>
<auth>KEY</auth>
<blog_domain>schinckel.net</blog_domain>
<action>getvisitorstats</action>
</request>
<ChartURL>
http://performancing.com/perfstats/api.php?action=getchart&blog_domain=schinckel.net&dtype=visitor_stats&ctype=line&m=date_range&d1=2006-01-01&d2=2007-01-01
</ChartURL>
<Visits>9204</Visits>
<AverageVisitsPerDay>271.3529</AverageVisitsPerDay>
<AverageVisitLength>289.5818</AverageVisitLength>
<RepeatVisitors>242</RepeatVisitors>
</response>
It’s possible to use the {fetch file="URL" assign="stats"} to grab this data and store it in a variable, so the whole lot isn’t displayed. You may have noticed that the Auth Key is included in the response! Now, the only bit we are really interested in is the
<Visits>9204</Visits>
section, so we need some way to extract this. Smarty allows for Regular Expressions, and we want to use one that will match everything up to and including
{$stats|regex_replace:"/[\r\t\n]/":""|regex_replace:"/.*<Visits>/":""|regex_replace:"/<\/Visits>.*/":""}
Thus, my final data is:
<li>{fetch file="http://performancing.com/perfstats/api.php?action=getvisitorstats&auth=KEY&blog_domain=schinckel.net&m=date_range&d1=2006-01-01&d2=2007-01-01" assign="stats"}
{$stats|regex_replace:"/[\r\t\n]/":""|regex_replace:"/.*<Visits>/":""|regex_replace:"/<\/Visits>.*/":""} Post views.
</li>
Of course, that’s with a hard-coded finish date. What if we want to finish on today? Again, there’s a way to do it in $smarty: {$smarty.now|date_format:"%Y-%m-%d"} To add this to the end of the URL, use:
{assign var="URL" value="http://performancing.com/perfstats/api.php?action=getvisitorstats&auth=KEY&blog_domain=schinckel.net&m=date_range&d1=2006-01-01&d2="}
{assign var="today" value=$smarty.now|date_format:"%Y-%m-%d"}
{fetch file=$URL|cat:$today assign="stats"}
It’s also simple to get a current day’s post hit count, using single_date instead of date_range. I’ll leave that one up to you.
The next two came from 
Each pixel also has a colour, as indicated above, but it’s a little more complicated than that. An image can also have a “bit depth,” which is how many colours are “in” the picture. For a purely black and white image, this bit depth is 1 - this is how many “bits” of information are required to store the colour value, and eeach pixel is either black or white, so a bit, which can store a value of either 0 or 1, can accomodate this. For images that can have up to 8 colours, a bit depth of 3 is required. 8-bit images can store 256 colours, but even these are obviously not photographs. Full image quality is 24-bit, which can store around 16 million colours, about as many as the eye can distinguish. With 8 bits making up a byte, a full colour image from a 4 megapixel camera would take up around 12Mb in a raw format - 3 bytes for each pixel, 4 million pixels. Obviously, this is not a good way to store images. Even with cheaper memory storage, most cameras would not be able to store more than a few images. This is where Lossy compression techniques come in. JPEG, the format most people are familiar with, allows an image of this size to be compressed by around a factor of 5. That is, with an acceptable image quality, I can store 4MP images from my camera in files a bit larger than 2Mb. Note that these numbers are approximate - the quality of JPEG files can be altered by changing the compression rate. Higher compression results in smaller files, but poorer quality images. The main thing to note is that the compression technique is called Lossy for a reason. To save bytes, some image information is discarded. With a high quality setting, you might not notice it, but each time you modify and then re-save a file, you will lose some more quality. JPEG is really only designed as a final format. If you are planning on modifying files, save them in another format! Because the format is lossy, the image may not look exactly like the original. For instance, the compression algorithm isn’t designed to work with large areas of flat colour adjacent to other colours. It’s designed to cope with gradients and ranges that might appear in real life photographs, and can save heaps of space by compressing these well, but does a very poor job of compressing images that have a constant colour next to another colour, due to the way it averages out the colours in this border area. Areas of fixed colour can, on the other hand, be compressed very well by non-lossy, or lossless techniques, such as those used by PNG. Remembering that an image is a series of pixels, the compressor can instead of storing 150 bytes that are the same, store one copy of the bytes, and state that it is repeated 150 times. This is a simplification of the process, but it’s fairly representative. Lossless techniques are also found in ZIP archives. After all, when you decompress an archive of a program or text document, you want the data exactly the same, not just pretty close. The main place I see JPEGs being used where they shouldn’t be used is in screen captures. When you Cmd-Shift-3 on a Mac, or Alt-PrScr on a PC, there is a very good reason that the computer doesn’t save the image as a JPEG. For example, a screenshot from the iTunes source window, stored first as a PNG, and secondly as JPEG: 
Granted, the PNG file is 8,271 bytes, and the JPEG is 4,777 bytes, but the quality difference is obvious. The fuzziness you can see around the JPEG image is called artifacts, and I hate it! So, the moral of the story is: only use JPEGs when you really need them. Most definitely not for screenshots. I’m not bagging lossy compression. It has it’s place: it’s also very useful in music files. MPEG Layer 3 audio, or MP3, allows for about 10:1 compression, meaning files can be compressed to around 3-4Mb per song, which is very acceptable for transfer over most networks. Transferring the full amount would mean that home networks would struggle to cope with even one computer playing a song stored on another machine. Similarly, with a high quality, it’s possible to have screenshots that look acceptable. But file size savings are then not so great. 
As Jason says: