Stonefield Article on SoftwareCEO

Stonefield Software is the subject of an extensive article on SoftwareCEO.

Stonefield Profile in the Financial Post

The Financial Post published an article profiling Stonefield Software yesterday.

Prairie firm finds its markets

Stonefield Profile

An article profiling Stonefield Software, the company I work for, was on the front page of the business section in the Leader Post. The article is available on the Leader Post website.

Stonefield Software the little Regina company that could

Exposition Problems

Recently, there was a blog post on my feed reader, referencing a recent paper on the topic of Open Exposition Problems in mathematics. To introduce this term, I'll use the same quote from the paper as was given in that blog post:

All mathematicians are familiar with the concept of an open research problem. I propose the less familiar concept of an open exposition problem. Solving an open exposition problem means explaining a mathematical subject in a way that renders it totally perspicuous. Every step should be motivated and clear; ideally, students should feel that they could have arrived at the results themselves.

This is an interesting idea, and I think it has applications in software development as well. The normal approach when explaining an algorithm is to just explain its steps. For any reasonably complex algorithm, it's also required to give some justification for why these steps achieve the desired result. Generally, the idea is that the student obtains enough of an understanding of the logic to produce a working version of the algorithm, and to extend it if need be.

That's fine, but the quoted text above goes further. It talks not only about the problem itself, but also about the motivation behind the steps of the solution, and about the student's feeling they could have constructed the solution themselves. This is something else entirely. We're now talking not just about explaining an algorithm, but explaining the process through which the algorithm was devised.

When writing code, we are always encouraged to add comments explaining how the code works. When the code needs to be maintained later, it's helpful to have these comments rather than having to work out what the code is doing. But, if someone's maintaining the code, it seems likely that they may be needing to write some similar code of their own. Maybe they need to extend this piece of code, or write a similar method in another language. In such a case, "exposition" comments might be useful as well, talking about how the code came about, other options that were rejected, and so on.

In any case, it's interesting to think about, both in terms of mathematics and software development. If nothing else, I learned the word perspicuous, and got a bit of a laugh that it was the word chosen to explain about making ideas completely clear.

Owen at 2 months

Here are a couple recent photos of Owen. Yesterday was his two-month birthday!

13 is worth more than 14

In the NFL it is, anyway. Maybe.

I read a fair bit about sports, and in particular I have an interest in the statistics that people use to try to analyze them. One thing I've heard a few times as an example of a counter-intuitive stat is this: NFL teams scoring 13 points in a game win more often than teams scoring 14 points. I've recently come into possession of a database of game data, so I thought I'd have a look at this for myself.

My data contains all the regular-season and playoff games back to the 1978 season, so it's a pretty good sample size of about 7500 games. The first item to look at is the 13 vs. 14 thing, and sure enough:

13: 225-562-2 28.6%

14: 144-670-2 17.8%

There you have it - teams scoring 13 win significantly more often than teams scoring 14. Of course, the real question is what (if anything) this means. The most likely cause for this effect is the unusual way points are scored in football. Almost all scoring is through 3-point field goals and 7-point touchdowns. This means that 13 can really be thought of as 2 field goals and 1 touchdown, and 14 as 2 touchdowns. Maybe field-goal-heavy scores outperform touchdown-heavy scores in general. Let's see:

6: 18-307-0 5.5%

7: 16-621-2 2.7%

16: 249-256-0 49.3%

19: 160-129-0 55.4%

20: 543-432-2 55.7%

21: 308-405-0 43.2%

27: 568-176-0 76.3%

28: 328-152-2 68.3%

That certainly seems to support the FG vs. TD explanation, and in fact it's quite striking how poorly the multiples of 7 perform. 7 points wins 3% of games; it performs worse than 5, 6, 8, and 9 points. 14 wins 18%; it performs worse than 11, 12, and 13. 21 points is the highest score that loses more than half its games, and it performs worse than 16 (!). 28 does worse than 23, and so on.

The FG vs. TD explanation makes sense for a few reasons. First, the time one team is scoring is time that the other team isn't. 3 successful possessions, for a TD and 2 FGs, will generally take more time than 2 successful TD possessions, leaving the opponent with less time to score their own points. Second, teams that are trailing by a large amount won't try for field goals. That is, a team losing 20-7 will have to go for a touchdown, while a team losing 10-7 is more likely to take a field goal. Finally, there may be game conditions making certain games conducive to more field goals. For instance, a game with heavy snow or fog might reduce offense, causing both teams to score few TDs.

I must admit, though, that this effect doesn't last forever. Teams scoring 49 or 56 points have won 100% of their games since 1978. I guess the lesson is that if you're going to score touchdowns, you should try to score 7 or 8 of them, not just 2 :).

FileSystemWatcher

I recently came across the interesting FileSystemWatcher class in the .NET Framework. It's pretty cool; the class will watch a folder, and raise events when there are changes to the files in that folder. You can specify a filter (like "*.txt") to only watch for certain files, and react when files are created, deleted, and modified.

It's pretty easy to come up with possible uses for this class. Maybe you have an old process somewhere that produces data files at irregular intervals; you could watch the output folder, and immediately act whenever one of those files is added. You could create a kind of auto-publishing system; let your users know that any file they save in a certain folder will automatically be posted for them. You could set up a mechanism for communicating between processes.

This last one is something that I've seen done before in VFP. A timer is set up to repeatedly check a certain location for a "message" file from another process, and then the app can react accordingly. A FileSystemWatcher makes this kind of setup simple - just set properties specifying the files to look for, and the file system events to watch.

Implementing this is straightforward as well. Create an instance of the class:

FileSystemWatcher fsw = new FileSystemWatcher();

Set its properties, and hook up an event handler:

fsw.Path = "C:\\SomeFolder\\WatchFolder\\";
fsw.Filter = "*.txt";
fsw.NotifyFilter = NotifyFilters.LastWrite;
fsw.Changed += new FileSystemEventHandler(this.OnFileChange);

Write the handler to do the work:

private void OnFileChange(object source, FileSystemEventArgs e)
{
// ...
}