SpiffyStats Revision History

Why? Why Make a History?

Well, actually, the answers kind of simple, because I wanted to.

Also because it's nice to be able to look and quickly see the progress SpiffyStats has made in the short time it's been being developed. Besides, how else could I generate enough web-pages to fill up the web server's hard drive?

Pre-Final Versions

These versions are released because when I develop the initial core it only makes sense to release versions at certain logical points (or turning points). Out of the goodness of my heart these versions are released to the public so they can see just where exactly I'm going with SpiffyStats. This also allows me to see how it performs under real world conditions. The number scheme is completely made up, and was actually applied retroactively from Beta 3, up until that point there were no version numbers because no-one ever used it.

If and when SpiffyStats ever reaches a point I'm ready to call "Release Ready" the versions numbers will likely start again from 1. Why? Just because I can, and it'd confuse the heck out of everyone.

Many software developers today seem to enjoy sticking to small version numbers (e.g., at or about 1 or smaller). I personally don't agree with this, there's a number before the decimal point, might as well use it. I tend to number things in the order a.b.c where a is the major release number (in this case indicative of a core change), b is the minor release version, maybe a GUI update, or the addition of more stats, and c is used solely to denominate bug-fixes or other really minor changes (such as maybe a change of web-address, or the updating of some of the included packages)

1.0.x

This core was really more of just a playful attempt at generating stats. Originally I abandon the idea of writing SpiffyStats (not that it was called that at the time) after writing this core because it seemed like an impossible task. The source code for this core was actually lost long ago (not too long after the first time it was abandoned). The basic concepts behind the HTML engine is still seen in the hourly/weekly load graphs present in the current version, it was basically the last attempt I ever made to deviate from what now seems to be the "standard" form for a stats page, whether this is a good or bad thing I don't know, but it was most unquestionably an ugly and hefty thing.

The basic idea behind it was just to strip the time codes off of every line and total them up in 10min intervals, this gave me a MASSIVE array of channel load/10min intervals. This data was then summed up into 1hr intervals (why I gathered it in 10 minute intervals is beyond me) and output into a cool looking graph, that still to this day remains my preferred format for the day/line graphs, not too informative, but it looks damned cool.

This is also where I made one of the key mistakes that will likely live to haunt me for many years yet. Instead of naming the images by either of the pre-established naming conventions (either mIRCStats' pipe__.gif or the PISG system of color_orientation.png) and proceeded to quite dumbly use my own system, that means that every time I want to place the pages from more then one program into the same folder I either need to copy BOTH sets of images or rename all of one page. On the other hand this means it's just one less link between SpiffyStats and every-other parser.

There was no real information to store for this one beyond maybe the hour data which is simply kept in a rather mundane 2 dimension array (days wide and hours long). No sorting or other mechanism need take place, which makes it the most simplex the engine has ever been.

2.0.x - 2.1.x

The original v2 core was REALLY simplex, the basic premise was to load every line into ram in a semi-intelligent way, and then file it off into individual users by going through the new array of lines and checking it against a huge unsorted array of users. If it didn't match any of the existing users a new user was added. Otherwise the info for that line was just added to the user totals. This is by and large how PISG works (I didn't know that at the time), it's far from the most efficient means, but it's simple to think about, for instance, the random quote was generated by picking a random value and then moving past that number of the users lines in ram.

In terms of page layout, it's just plain scary. The basic color scheme consisted of a dark grey background, black text, and BRIGHT colored cells for tables. The theft of the mIRCStats color scheme seen in later versions is a vast improvement. The interface is little better, in it's most advanced form it has one button and one massive green light. Mostly this is due to the fact that it was most never seen by the public, and any configuration changes were hard-coded into the source. This however was my view of a "clean" interface at the time.

It's feature set was limited to a lines/day graph, a lines/hour graph, and the "Top 12 most talkative Nicks" section (yes, with capitalization that bad). Days could only be delaminated by day #, no dates, and for shear weirdness days were labeled starting at 0. Sorting through the list of users for each line meant that it's speed could quite easily be described by the equation ([time] = [number of lines] x [number of users]) in a straight plot. Which means that it behaved nicely for small channels with a small amounts of users, or really big channels with a small set of users.

2.2.x/FIRCS & PabUK Beta

Known as both beta 2.2.x and PabUK beta it was released both to a small circle of friends under the name FIRCS 2.2 or Free IRC Stats (pronounced furks) and almost simultaneously released to the PabUK community as SpiffyStats 2.2.1 PabUK Beta. The only real difference was the PabUK beta had some hard-coded nick-name linking for the nick-names commonly used by the PabUK community, and it lacked the nag/contact the author screens of FIRCS.

The minor version increment was done in the interest of the addition of the "minor nicknames" table, and the addition of dates to the day parsing system.

2.3.x - 2.7.x

Version numbering is inconsistent as I switch back and forth between the FIRCS and SpiffyStats labels, at one point it jumped from 2.4 to 2.7 in one fell swoop. During this development time the engine sees of it's first "Big Numbers" section, longest lines, and the first deviation from the standard form with a "charecters/line" graph displayed for each user in the "top users" section. Mass smiley spam on several key beta-testing channels leads to the inclusion of the first user-configurable statistic, minimum line length to be counted. It also is the version series that started the rather useless "count actions as lines" check-box that managed to sneak it's way into every version for another two inter-face redesigns yet. The check-box was created for a feature that looked easy to make, and then turned out to well, it turned out to be rather boring too, easy, but boring.
The beta 2.x series was fast approaching the end of it's days, as the log files used to test it grew the speed at which it parsed steadily slowed, and the amount of ram it required continued to grow, until the point it no-longer ran comfortably on my IRC logger.

The Configurator

An external application designed to write what I had hoped to eventually use as config files in the almost standard windows INI file format. It sported a cool interface, but it never really progressed beyond that, it did however force me to remove many values from being hard-coded into the code to being variables coded into the program (for those who aren't programingly inclined, just assume it makes things easier later on in our story).

Version 0.4

A very hard concept to describe, this should likely have been rightfully called beta 3 (or something along those lines), instead it saw the (brief) return of the FIRCS name and well, four was a cool number. It was actually a good concept, but far too advanced at the time for my level of thinking at that point, it had the groundwork for automatic nick-name linking and it also finally contained a version of the code that didn't require the MSCommonDialog control to be added. It also showed a much advanced interface over previous versions. The nickname linking relied on the basic premise of that every time it saw "[xx:xx] *** NICK1 changes name to NICK2" nick1 and nick2 were the same person. Although this works in theory, many times two people would change there name to one thing (e.g. lots of people might at one point or another be known as "fishing", this meant everytime someone changed there name to fishing it would associate all of their nick-names with fishing, and this could lead to 1/2 the channel being known as one person (which I suppose isn't a problem if there's only 2 users on a channel). The other problem was this tended to lead to a very slow time for parsing log files because of the inefficient way information was stored. Basically nicknames were stored in a massive two dimensional array, where you can think of each row as a new user, and then the columns going across would be the user names of that user. A quick example would be as follows:

User 1222	John	John\|Fishing	John-Work
User 1223	Nicky	Nickette
User 1224	Typed-Out	Jane	Haddock_Master	johns_little_baby

The only easy means to find a user was to search through the entire listing, this (due to the nature of 2d arrays) took even more time then beta 2 to search for each nickname. This particular version of FIRCS/SpiffyStats was stopped dead in it's tracks after a wee bit of thinking.

2.8.x

Just to confuse everyone the version that follows 4 is 2.8, why? because it happened to be the order they were developed in. This version saw very little amercements, a major bug was fixed that was plaguing the proper tracking of time, and the "überPoint" system was introduced to help combat the problems with speed, how it works, I can't say, partially because I don't entirely remember, and partially because it was useless. That aside, überPoint saw it's existence toted clear into the end of beta 3.2. Despite any attempts the beta 2 system was still slower then a hog-tied pig, and wasn't really acceptable for heavy usage.

3.0.x

Yes, the version after two is three, oddly the version after 4 is also 3, that has more to do with luck then anything, I have no idea why FIRCS 0.4 wasn't actually called SpiffyStats Beta 3, but it wasn't, so this is called SpiffyStats Beta 3 instead. Beta 3's major change from every version it predated was that the log itself wasn't loaded into ram, instead it was analyzed one line at a time, and only the summative totals were stored in ram. This allowed the almost 1,000,000 users to be stored in the same space where less then 1000 were stored before, and an infinite number of lines, as opposed to the previous hard limit. The lack of ram overhead also resulted in a much faster parse-speed (about 150%). Still, compared to today, this is a very rudimentary version. The other large change was the usage of the mIRC color scheme instead of the one invented by me so long ago. Also added were a few extra "big-numbers" sections. The biggest justification of the version increment was the change from caching the entire log to line by line parsing.
Unfortunately due to the more advanced concepts behind storing information (at this time) I couldn't figure out how to store the random quote, so it simply read "feature disabled in this beta" where there should have been a random quote.

2.9.x

Now it's just weird, the version history to date is 1,2,4,3,2, mostly this is due to the fact that beta 4 was a failed concept, and beta 3 currently has a broken random quote feature. Beta 2.9 adds various cool features, but the most notable by far is the inclusion of the manual nick-name linking system, fed a file of nickname connections (nick.txt) it'll creatively link those nicks togeather. I really have no idea how I ever dreamed this up, it uses some really backward thinking, but it works flawlessly for the most part. It's the best example of "black box" programming I've ever seen, on the very detailed mental flow chart I have of SpiffyStats there's a box in the middle that just says "manual nickname linking" raw nicknames go in one end, linked nick-names come out the other, beyond that it just works.
This is also the last release in the beta 2 series, which is good, because after this I'd need to do something crazy like beta 2.10.1, or something else equally crazy. This will also be the last version to feature a revision of the classic SpiffyStats Interface (as well as the last version to ever see light under the co-name of FIRCS).

3.1.x & Winamp/AVS Beta

Implemented in this version is manual nick-name linking, as well as a working random quotes. The nickname linking is based almost entirely on the nick-name linking from beta 2.9, while the random quote really just came to me while I was waiting on public transit. As much as those were a reason to roll up a new version number, the biggest was the addition of a new interface from the great folks at PawSoft. This interface helped to set a new standard for the up and coming interface re-designs. It also brought an end to the concept of the "configurator" as it was built into this interface. This also marked the first (and only) time the source was released to an outside source.
It further became known as the Winamp Beta because it was released to the "winamp forums" community in the interest of broadening it's install base.

3.2.x

Another key stepping stone in the life of SpiffyStats this is the first version to ever be able to hold it's own against stats parsers. User data was moved from being stored in 1 massive unsorted list, to being stored in 27 different unsorted lists. The 27 lists represented the first letter of the users nickname, or that it started with a letter not between A and Z. This sped up the parsing speed by almost 300%. Which made it about 240% faster then mIRCStats when nick-name linking was enabled on both, and both supplied with the same manual nick-name linking files. Much of this speed gain can be safely attributed to mIRCStats nick-linking overhead, as well as that the comparison was made vs mIRCStats 1.18. This version also brought the concept of multi-log processing to the table.

3.3.x

What should be the last of the beta 3 core it sports a new interface inspired partially by the multi-paned interface of mIRCStats. This new interface left MANY more things up to the user. (which is why the tabs were needed) It also brings the concept of Cascading Style Sheets and more user-configuration to the HTML pages. Finally, it adds the w3c certification logos to the bottom of the page to show that the stats output is both HTML and CSS certified.

5.0.x

By far the largest revision of SpiffyStats so far, not a complete code over hall like the failed beta 4, but very close to a complete overhaul. The code has moved from a straight execution path to procedurally based with recursion and other "real" concepts. The best change of all is the move from the old unsorted linear lists to the VERY powerful sorted binary tree. Also included for the first time ever is multi-language support (for the HTML output, not the program). mIRC 6.x support and Anonymous usage tracking round out the package for the largest update so far.

5.1.x

5.1.x is mostly just a "polishing" version, really it doesn't include too many features that weren't already in SpiffyStats, what it does do however is make them much more powerful or easier to use

The manual nick-name linking was re-written to be unofficially compatible with mIRCStats 1.19, you can use the nicks.txt file from mIRCStats seemlessly with SpiffyStats 5.1.x and vice-versa (so far as my tests go anyway). The nick-linking system also performs like the mIRCStats version of it as well, allowing the user too, allowing the user to simply specify a set of filters ("directives") and have the program pick the displayed name according to which nickname that user used the most.

Also included for the first time ever was the "dynamic help system" which allows the user to get help simply by holding there mouse over a control in the program (inspired by Apple's nice, if seldom used, balloon-help system).

This was also the first version to really include a working language system, allowing the end-user to actually create pages in more then one language.

The file-name handling was severely beefed up with the introduction of dynamic output file naming and greater control over the selection of multiple logs for input. Finally 5.1.x included several different speed-enhancment techniques, the most noteable of them being dynamic memory allocation and alphabetized binary trees (so there were 27 separate binary trees, one for each letter of the alphabet).

TR6

Although SpiffyStats 5 still holds the title of the largest revision from the users point of veiw TR6 is the greatest revision from a developers standpoint. To say the least TR6 has a different name then all the versions to precede it, wearing the 'TR' designator instead of 'Beta' one of past versions. 'TR' stands for 'Testing Release' and is my opinion far more acurate and proper then beta. That and it's hard to release a file called 'beta6a5' (or beta 6 alpha 5).
TR6 was also the first version to go through the 'pre-release' phase, a practice I hope to continue for quite a while yet. The old method of releasing versions was to code like mad to create the features of a new release, release a very buggy, but functional version, then fix bugs as people noticed them. With TR6 the rather stable 5.1.x was left as the main version of SpiffyStats while TR6 was shown off under a different area of the web-site called 'pre-release'. Once I'd created a version of TR6 that actually did something I put a copy up on the website for the curious to play with, it was devoid of features, had no GUI, and more bugs then I could hope to count, but it was available for people to use. Everytime I coded a new set of features for TR6 I released a new version, while makeing bug-fixes based on reports from people using the current TR6 version. So far this has resulted in a much stabler version being released as the 'release' version of SpiffyStats.
From a development standpoint developing TR6 was a huge change compared to my previous development methods. For starters TR6 was developed using CVS for revision control instead of my usual method of simply creating a new folder on the shared fs for each major version. I can't stress how much CVS has been of help in the development cycle. TR6 is also a complete source rewrite, the only thing that remains are the status window and the automatic-run-mode window, it's also a complete change of format as far as the source code goes. In previous versions every part of the stats process has been closely integrated togeather, changing one portion of the process involved changing every other part aswell. With TR6 on the other hand every part of the stats process is seperated from the rest, the portion of the system that retreives the data out of the log no longer deeply effects the portion of the program that generates the HTML page. Actually, the portion of the program that generates the HTML for each section and the portion that lays those sections out on the page aren't in anyway dependant on each other either.
On a different note the generic output of the stats pages was also changed from the typical colourful mIRCStats colour scheme and format to a somewhat more unique blue format, vaugley reminisent of PISG. The nameing scheme of the images also changed, back to the pipeXx.gif of mIRCStats and IRCStats.

This page and all information here-in ©2002 Fundamental Logic.
Any questions or comments can be directed to Kevin Bralten.