Booky is a bookmark manager which allows you to store and search your favorites by tags rather than browse a huge folder hierarchy as is (unfortunately) the standard in current browsers. It sits in the system tray and thus works independently of your browser choice.

The new version is much improved and is now what I would call a stable program. The first difference one will encounter is the addition of an installer. This is a very simple installer, one I aim to improve a lot in the future when I learn more about the WiX toolset. Continuing with the more obvious improvements, a number of nifty features have also been added to the interface, including a drop-down menu for matching tags and a context menu for the systray icon for quickly relaunching bookmarks. Apart from that, a number of smaller fixes to the interface and stability fixes have been introduced.

For a look at what the next version of the program will bring, I plan on improving the installer in a number of ways (e.g., integrate the installation of the .NET framework) and to introduce an options dialog for different settings and bookmark exporting.

Don't forget to report any bugs or other feedback you may have to withoutprecedence@gmail.com.

There was no information to be had from Needhost itself and it seemed that all data was lost. I must admit I was a little  panicked at this point, after establishing that I could find no backup of any of my data, not to speak of the website code itself. Before continuing this tale of woe, I should point out that this old website code was anything but pretty. It was my first ever attempt at a non-static website and it showed. With the exception of a few includes for a page header, footer and menu, the code consisted of one huge php file with a lot of conditional statements in it. Ugh.

Anyways, I decided that the time was due for a new foundation to be built. Having just finished another website project, I was ready to get my hands dirty and from those efforts did this page appear. I have built the entire page from the ground up, avoiding existing frameworks and components. One might argue that this is an unnecessary effort but it's a good learning experience and the freedom it provides is not to be scoffed at either - I only hope that it hasn't resulted in too many bugs.

As a result of this effort I have produced a sort of lightweight website framework, slightly influenced by CakePHP (which I spent about 30 minutes finding out I din't want to use). As I get the framework code cleaned out I will be posting it here so that others might get some use out of it.

This whole experience has given me the kick needed to produce a proper website and it has also given me a chance to revisit the purpose and focus of the site. And of course, I have learned the timeless lesson of the value of backups.

In all fairness to my old web host, I should mention that they later not only offered access the people's data but had also made a transition deal with another host, which would allow you to transfer your lost subscription fee and forego the initial signup fee. But alas, this news came too late for me to take advantage of.

For any website beyond the most simple, you are bound to be doing a lot of database queries to present the website data. This can quickly grow to become a large mess of database connections, SQL query strings, sanitizing and result sets. When I began work on the project, I hadn't worked with SQL for some time and I couldn't remember any but the most simple queries. To solve this I would wrap SQL queries into PHP objects and functions for easy access. Perhaps inspired a bit by LINQ I decided on a composable set of query functions on an SQL object which can be called thusly:

1. //(SQL): SELECT name, age FROM users WHERE age = 18;
2. $result = SQL::select("name","age")->from("users")->where("age","18")->query();
3.  
4. //(SQL): INSERT INTO users VALUES ('John', 'Doe', '23');
5. SQL::insertInto("users")->values("John","Doe","23")->query();

$result is a standard MySQL result set as returned by the mysql_query function. Alternatively, you can fetch a row of the result set with the query:

1. $row = SQL::select("name","age")->from("users")->where("age","18")-> queryRow();
2. $name = $row['name'];
3. $age = $row['age'];

Each method (except the query methods) returns an object which aggregates the query data. If you have an editor which supports intellisense this will allow you to easily compose many different SQL queries without having to remember the exact syntax. While it is infeasible for me to support all possible SQL queries the most common are supported and the model can easily be expanded. Below you can see a simple example of how a method on the InnerHtml class can decorate a query with the FROM clause:

1. function from($table){
2.     $this->sql .= " FROM ". $table;
3.     return $this;
4. }

What we have now is a simple model for constructing SQL queries but it gives us something even more powerful. We are now free to incapsulate all the details about such issues as connection management and parameter sanitization. Management of the connection to the database (MySQL in this case, but it should be simple to change due to the isolation) is provided by the singleton class DatabaseConnection.

1. class DatabaseConnection{
2.     private static $dc = null;
3.     private static $connection = null;
4.    
5.     private function __construct(){
6.         self::$connection = mysql_connect(Settings::$dbPath, Settings::$loadUser,Settings::$loadPass);
7.         if (!self::$connection)
8.         {
9.           die('Could not connect: ' . mysql_error());
10.         }
11.         mysql_select_db(Settings::$dbName, self::$connection);
12.     }
13.    
14.     static function get(){
15.         if(self::$connection == null){
16.             self::$dc = new DatabaseConnection();
17.         }
18.         return self::$connection;
19.     }
20.    
21.     //Call this at the end of each page using DB calls
22.     static function close(){
23.         if(self::$connection != null){
24.             mysql_close(self::$connection);
25.             self::$connection = null;
26.         }
27.     }
28. }

This code is used by the query methods of the SQL query object.

1. function query(){
2.     DatabaseConnection::get();
3.     return mysql_query($this->sql);
4. }

To dispose the connection the close function must be called at the bottom of every page (using DB queries). The result of the above code is that as long as you can remember to include the DatabaseConnection::close() call at the bottom of each page you never have to think about connections again. With regards to sanitizing the input this is just a question of cleaning any function parameters before they are added to the inner SQL string.

1. //Params: Arbitrary number of field-value pairs
2. function where(){
3.     $firstWhere = true;
4.     for ($i = 0; $i < func_num_args(); $i += 2) {
5.         $field = func_get_arg($i);
6.  
7.         //Cleaning the input values
8.         $val = Database::cleanInputString(func_get_arg($i+1));
9.         if ($firstWhere){
10.             $this->sql .= " WHERE ".$field." = '".$val."'";
11.             $firstWhere = false;
12.         }else{
13.             $this->sql .= " AND ".$field." = '".$val."'";
14.         }
15.     }
16.     return $this;
17. }
18.  
19. ...
20.  
21. class Database{
22.     static function cleanInputString($string){
23.         if (get_magic_quotes_gpc())
24.         {
25.             $string = stripslashes($string);
26.         }
27.         $string = mysql_real_escape_string($string, DatabaseConnection::get());
28.         return $string;
29.     }
30. }

I hope that I didn't miss anything critical in that sanitizing function since I don't have web security 100% down in PHP yet. The only problem (or maybe not?) with relying on the database classes to handle input cleaning is that if you end up constructing your own SQL strings for the more advanced queries this code can't handle, you must manually clean all the input. I find that this code has really made database operations much easier but you don't have to take my word for it - go check it out yourself. The file will be expanded to contain the other features of the framework as I get it cleaned up.

Rather than having the url hiearchy of the website map directly to the server-side file hierarchy, all requests are routed through a single php file using url rewriting. This can be done simply by modifying the .htaccess file like this:

1. #Options +FollowSymlinks
2. RewriteEngine on
3.  
4. RewriteRule \.(js|ico|gif|jpg|JPG|png|css|txt|xml)$  -  [L]
5. RewriteRule ^(.*)$ index.php

The .htaccess file is configured to allow image files and other such resources through as normal. You can also allow other types of files to be treated as normal by adding their extension to the list. For a great introduction to all the useful things you can do with the .htaccess file, click here.

The main purpose of the dispatcher is to pick the requested url apart and ask the proper components to construct a response view. Speaking of views, I use the MVP pattern to split up the responsibility of the components. Thus, each first level subdirectory of the website matches a controller instance which handles validation and presentation of the view. When you request an url, the dispatcher checks for the existance of a controller class with the name of the subdirectory. If one such exists, the remainder of the url is passed to it as a parameter to validate whether it is a legal url. To illustrate how this work, consider the following url to a blog post on this site:

1. http://www.without-precedence.dk/blog/01-02-09/renaissance

The blog part of the url tells the dispatcher that it should look for a class called BlogController in a file called blog.php. All controllers implement the IController interface which provides a method for validating the url and presenting the view.

1. interface IController{
2.     public function show($param);
3.     public function validateParam($param);
4. }

The rest of the url contains a date and an url-encoded blog title. These are first passed to the validateParam method to make sure the post exists and then to the show method to render the blog post.

If no controller is found or the controller does not validate the url, the standard error page is shown - which is just another controller being invoked. Controllers can also be made to handle urls which does not correspond to normal pages such as AJAX requests and file downloads. This design is what I was referring to when I was talking about the RESTful API, where each url request can be seen as an API call that can be handled in an arbitrary fashion.

Whenever you want another sub-page or provide some service (such as RSS feeds, the creation of which I will be blogging about in the not too distant future) you must simply create a controller with the proper file and class-names and you're in business. This might be simplifying things a bit, as you would most likely need to also create a model class and a view class to interact with the database and construct the page view, respectively, but I'm sure you'll forgive that minor slight.

On a final note, this design might not be ideal for handling deeply nested urls, as the controllers can become very complex but there's nothing stopping you from implementing a nested controller structure. I ran into a spot of trouble when I attempted to create a sub-hierarchy of admin pages within a single controller, which I can't recommend.

The framework code has been updated to contain the functionality described in this post and it can be found here.

Creating a language is an interesting experience and it is not often an excuse comes along for making one. After long discussions about whether and how to include loops and such, you get a certain amount of appreciation for the work that has gone into the languages you use on a daily basis. It is a balancing act to get all the factors right, especially if you both want an expressive and elegant language which also facilitates efficient writing of code.

In the case of our language, I had come up with the initial idea which was to describe the card game as closely as possible to how you would think about a real card game. This meant that you would designate card piles, events for clicking them and rules for moving and turning cards. In essense we maintain a state machine for the playing field with legal state changes matching those of the real world; in other words, you cannot magically conjure up new cards and otherwise create a game state which does not make sense. I quickly grew attached to this idea and envisioned the language as a conceptually pure language which would more or less only use these card abstractions to define behavior. The others group members, on the other hand, looked at the language with more practical eyes and wanted more traditional control logic to be included as well such as conditional branching and looping structures. After much discussion and arguing we settled on the practical version of the language which, in hindsight, I think was a crucial choice.

Dusting off the old bits

Recently I got it into my head to bring out the interpreter again, shine it up and repackage it in some Silverlight goodness. I hadn't tried Silverlight yet but I've made another program in WPF and that's close enough I guess.

The original code was some dusty old C# 2.0 code which I merrily began refactoring away at and I have now brought it up-to-date with shiny C# 3.0 features. To be honest, it was quite easy to port the code to Silverlight, though not without a couple of strange bugs. The biggest hurdle was to replace the legacy code which no longer worked in Silverlight. Who needs ArrayLists anyway? Here, you can see how the Card Game Simulator shapes up:

The simulator is in a constant state of change as I work on improvements and you can always find the current version here. I will be posting a guide to develop your own card games in the near future, so stay tuned.

After several different fonts and going through most of the possible build actions for them I gave up, attributing it to some strange fluke in my particular development environment. A little later I figured I should go over one of the tutorials one more time to see if there was some tiny point I'd missed. It turned out there was.

All the tutorials which I'd followed instructed me to add the font file to the project using the Add New Item option shown above. Not giving this much thought I just dragged the font file unto the project which seemed to work fine. While there is no apparent difference between the two methods, switching to the prescribed approach solved my problems. Who would have known?

An unfortunate side effect of this theme is that it about tripled the download size to over 1.3 megs but I hope you'll manage. For more information about the Card Game Language, click here.

1. The show method on the controller gets called with any supplied parameters.
2. The controller retrieves the model of the page to be shown.
3. The controller uses the model to create a view of the page.
4. The view is used to create a page object, which can be customized as needed for the page (This step only applies if the page is an ordinary HTML page).
5. The page source is sent to the client.

The show method handles all the steps involved in constructing the requested page. While the process differs somewhat depending on the page to be shown the above steps describe the typical case.

The first task when constructing the page is to retrieve its model. This model is the model-part of the MVC pattern used by the framework to separate data, presentation and control logic. The model contains information which is to be presented on the website. This could include such information as blog posts, news items or user-generated content, all of which is normally stored in a database. The model class is named similarly as the controller class only it is stored in the model directory instead. The job of the model class is to create a PHP object representation of the data to be shown.

So far the show method in the controller could look something like this:

1. public function show($param){
2.    $posts = MainModel::read();
3. }

The next step is to create a view of the page which is the main content that the client will recieve. Similar to the model, there is a view class which is used to generate the code to send to the client, usually HTML. The view class extends a class called Template which just specifies a member called html and a method, get, to retrieve it.

1. class MainView extends Template{
2.     public function MainView($posts){
3.         $html = Header::create();
4.         $html .= MainContent::create(PostList::create($posts), ItemList::create());
5.         $html .= Footer::create();
6.        
7.         parent::Template($html);
8.     }
9. }

View templates use a number of modules to build up the page; Header, PostList, ItemList and Footer in the above example. These modules make up different parts of a page and can take parts of the model as parameters as is the case here. Combined, the modules produce the desired HTML for the page. It should be mentioned that there is no specific reason that the view must output HTML, it can just as well be XML of some format.

With these additions the show method in the controller now looks something like this:

1. public function show($param){
2.    $posts = MainModel::read();
3.    $template = new MainView($posts);
4. }

The next step only applies if you're constructing an ordinary HTML page. If not, you can just return the code generated by the view. The framework has a utility class called Page which makes it easier to create all the parts which make up a standard HTML page, including meta tags, styles and scripts. You might want to modify the class to suit your needs as it is not prepared for all possible contingencies. The class uses the template created by the view to create the page:

1. public function show($param){
2.    $posts = MainModel::read();
3.    $template = new MainView($posts);
4.    $page = Page::create($template,"Demo Page")
5.       ->addStyle("default.css")
6.       ->setDescription("This is a default page description.")
7.       ->setKeywords("these, are, example, keywords");
8.    echo $page->getHtml();
9. }

This example creates a page with the title "Demo Page" and sets the stylesheet as well as the meta information for description and keywords. Each of the functions on the page returns the page object so you can easily chain the page configuration calls as done above.

This is basically what it takes to create a page, though as I hinted at, it is possible to change the approach for special types of views such as XML feeds or an AJAX API. Some pages might not need a model or even a view and as such the term 'page' applies in a very loose sense. In upcoming posts I'll provide examples of alternative page types.

I've updated the framework code to use the example used in this post and the style for it is now based on one of the free styles from Free CSS Templates, which also supplied the style for this site.

Mostly ray tracing is done in C++ these days as it is a very compute intensive task but you can get equally beatiful images in C# with but a bit of patience. If you can tolerate a some trigonometry and vector math and have the least bit of interest in computer graphics I cannot recommend it enough to try and build your own ray tracer. The central rendering algorithm is not very complex and beyond the math it is easy to integrate different effects into the engine.

For Rend I have set up a project page where I will be maintaining a list of its primary features as well as a showcase of the most interesting effects I have rendered with it. I plan on making a version of Rend available for download but I don't feel it is quite ready for public scrutiny at the moment.

For a peak at what you can do with Rend, here is an image:

If there's one thing you need to realize it's this: the more you think you know, the less you really know. You may think that some clever little hack or algorithm you make will increase performance but there is only one way to tell - measure! I cannot recount all the times which I thought I had made an optimization only to discover that performance was the same if not actually worse. How can this be? You might see a piece of code which appears to have some obvious optimization but the thing that will catch you unaware in many (and surprisingly subtle) cases is CPU cache. Cache stores the most recent data you've accessed very close to the CPU. It has this wonderful ability to make performance tuning seem a very non-deterministic job at times, when something you just did a few lines of code earlier indirectly affects the performance of the executing code. At the level of micro optimizations, cache makes the abstraction that each instruction has a specific cost leaky, along with other features of modern CPUs such as out-of-order execution and branch prediction.

The most important aspect of performance tuning, and you'll hear this advice again and again, is that you have to measure the actual performance. You can single out different operations and measure them in a tight loop but what I find the most useful is using a profiler. This allows you to get the most realistic image of the performance of the application where different pieces of code gets to influence how the cache is populated which will cause unforeseen side effects. I use the profiler shipping with the Visual Studio Team System edition and I'm afraid I have to point you to Google for any free alternatives.

Regardless of whether you have access to a profiler, there is a point  which you have to keep in mind when you use Visual Studio. There are basically three modes to run your program in during development: debug mode, release mode and outside Visual Studio. For some reason it took me a while before I realized the obvious fact that running in release mode was faster than debug mode, where a lot of optimizations are disabled and debugging code is inserted into your program. This switch alone almost doubled the performance of my ray tracer. What I didn't realize was that release mode still has some performance impacts, such as the lack of method inlining. This little fact had caused me to make some optimizations which would turn out to be redundant once the code ran outside of VS (where the performance about doubled once again). For ray tracing I have a Vector class which I use very heavily during computations and I had found that turning public properties into read-only fields to avoid the extra layer of indirection gave about 10-15% increase in performance. Do not waste your time with such optimizations which the compiler will do for you (and that without hurting the design of your application).

There is a particular downside when optimizing .NET code, an aspect which is also one of the strengths of the platform. There has been much discussion on the web regarding the speed of .NET code vs. C++ code and it turns out that in some cases .NET code runs just as fast if not faster than the native C++ code. This is due to its use of JIT compilation which allows the runtime to optimize for the specific PC as well as perform increasingly better optimizations as the framework is improved. This essentially means that you get continous free optimizations of all your .NET applications with each realease of the runtime. The reason this can be a bit of a pain is that it makes it difficult to tell how relevant older articles regarding performance tuning are. I have experimented with different performance techniques which appear to no longer have any effect, probably because the problems they were supposed to solve have been fixed. To make a concrete example, in Service Pack 1 for .NET 3.5, a lot of optimizations were introduced for structs such as inlining of functions which the compiler, previously, only did for classes. This change made any prior articles on the performance characteristics of structs, if not worthless, then at least unlikely to be accurate.

When developing a ray tracer, you sometimes need to face the reality that the precision of floating point values is finite and at a time I was experimenting with the use of doubles rather than floats for most of the operations in the engine. There was a clear performance penalty for for this (around 25% if I recall correctly), and the main reasons for this are that the memory bandwidth and cache size is effectively halved when dealing with doubles. Other factors such as the different instructions used for operating on floats and doubles affect the performance as well but here I must admit my knowledge of the subject comes up a bit short.

One of the casualties when you wage the war for performance long enough inescapably seems to be the design and readability of your code. For my ray tracer I have on numerous occasions found myself having to make the choice between good, high-level abstractions and performance. Each layer of indirection you create in your system to increase readability and maintainability has an adverse effect on performance. Since their introduction, I have been very fond of lambda expressions in C# and these are a prime example of how you can keep your code clean and succinct at the cost of performance. I admit that in this case I have been sinful and haven't acutally tested their performance but tests I have read indicated a not insignificant penalty for calling delegates compared to ordinary function calls and therefore I have tried to avoid them in the more trafficked parts of the engine.

To keep your code clean an elegant while still keeping a strong focus on performance, my main advice would be to isolate the more arcane optimizations to very specific places that other code only interacts with indirectly. Also, make sure to identify the hot parts of your code and optimize them aggresively while being more lax in other parts. For example, most of the execution time in my ray tracer somehow concerns the Vector class so this is were I have kept a lot of focus. One common thing to do with this class is retrieving the value of a specific axis so to get a bit of performance increase I turned to unsafe pointer arithmetic:

1. public float this[byte axis]
2. {
3.    get
4.    {
5.       unsafe
6.       {
7.          fixed (float* pX = &_x)
8.             return *(pX + axis);
9.       }
10.    }
11. }

This is not the most pretty and readable code you're likely to find in any C# program but it is isolated in the Vector class and other classes remain unaware of the implementation since it does not change the interface of the class.

To round off this lengthy article, I recall a story I read somewhere about a team who weren't happy with the performance of their application. Profiling the application led them to a peice of code which took up a huge amount of the CPU time. The team really labored to optimize this code as best they could, with unrolling and inlining and the like until someone realized their folly - they had been optimizing the idle loop!

The tips are ordered by how interesting and useful people have found them so you get a huge amount of value for the time you spend reading it. I'm sure you will find that you know many of the provided tips, but I doubt that few programmers, even experts, would know (or at least remember) all the advice gathered there. But enough talking, go check it out.

It is a strange feeling, as if bursting through some invisible membrane protecting me from the worries of the future and the difficulties that lie ahead. In fact, the day after my final exam I was more worried than I was on the actual day, as it turned out I had postponed quite a lot of worries. The bulk of these revolved the business I have planned on starting with some of my fellow students. Will we make it? Can we make enough money? Can we make a good product? How should we proceed? These are just some of the questions that troubled me. It has been a couple of days now and I've managed to calm myself dow a bit as things have become a bit more clear.

One thing is certain, though, and that is an uncertain future. It goes without saying that none of us have experience with the type of venture we're about to undertake so there is really no knowing where it will take us. Perhaps we strike gold and become the newest in Internet fame, or perhaps we won't make a dime and shamefully be forced to go find some real jobs. However it turns out, it will be an interesting ride I'm sure. I will report our continued experiences and progress, though it is unclear how much time I will have for my usual hobby projects.

Obviously it's no fun just looking at your pictures all by your lonesome so I had to upload them to the web. Flickr seemed a natural choice and I've been uploading the most interesting photos from each set. Now if you go look at them you might notice a pattern in the size of the images, namely that the maximum dimension of each picture is 1200 pixels. This is just a measure to keep the file size down but it is something of a bother to do and while it's not a huge issue it did prompt my Coder's Laziness. Coder's Laziness is what I call that useful feeling a good programmer will get when he is faced with a repetitive task that leads him to code up an app or script to do it for him. And that is what I did.

I find the ability to just sit down and create a tool that will bend the computer to my will and solve some problem I have to be one of the greatest rewards of being a programmer. Taking the case of the resizing app I needed, I ended up with a working solution after about 30 minutes work - it even had a few bonus features such as a progress bar and settings for compression quality for the Jpg encoding. In fact, the C# code is so small and simple I provide it to you in its entirety:

1. public partial class ResizeForm : Form
2. {
3.    public ResizeForm()
4.    {
5.       InitializeComponent();
6.    }
7.  
8.    private void resizeButton_Click(object sender, EventArgs e)
9.    {
10.       progressBar.Value = 0;
11.  
12.       string url = urlBox.Text;
13.       int maxDimension = int.Parse(dimensionBox.Text);
14.       int quality = (int)qualityScale.Value;
15.  
16.       var dir = new DirectoryInfo(url);
17.       if (!dir.Exists)
18.       {
19.          MessageBox.Show("No such directory exists!");
20.          return;
21.       }
22.  
23.       var resizedDir = new DirectoryInfo(Path.Combine(url, "resized/"));
24.       if (!resizedDir.Exists) resizedDir.Create();
25.  
26.       var jpegs = dir.GetFiles().Where(file => file.Extension == ".jpg").ToList();
27.  
28.       int current = 0;
29.       foreach (var imageFile in jpegs)
30.       {
31.          var original = new Bitmap(imageFile.FullName);
32.          Image resized = ResizeImage(original, maxDimension);
33.          string savename = resizedDir.FullName + imageFile.Name;
34.          SaveJpg(resized, savename, quality);
35.          current++;
36.          progressBar.Value = (int)(current / (float)jpegs.Count) * 100;
37.       }
38.    }
39.  
40.    private static Image ResizeImage(Image originalBitmap, int maxDimension)
41.    {
42.       float aspectX = maxDimension / (float)originalBitmap.Width;
43.       float aspectY = maxDimension / (float)originalBitmap.Height;
44.       float actualAspect = Math.Min(aspectX, aspectY);
45.  
46.       int sourceWidth = (int)(originalBitmap.Width * actualAspect);
47.       int sourceHeight = (int)(originalBitmap.Height * actualAspect);
48.  
49.       var resized = new Bitmap(sourceWidth, sourceHeight);
50.  
51.       Graphics g = Graphics.FromImage(resized);
52.       g.DrawImage(originalBitmap, new Rectangle(0, 0, resized.Width, resized.Height));
53.       return resized;
54.    }
55.  
56.    private static ImageCodecInfo GetEncoderInfo(String mimeType)
57.    {
58.       return ImageCodecInfo.GetImageEncoders().FirstOrDefault(codecInfo => codecInfo.MimeType == mimeType);
59.    }
60.  
61.    private void SaveJpg(Image image, string fileName, long quality)
62.    {
63.       EncoderParameters parameters = new EncoderParameters(1);
64.       parameters.Param[0] = new EncoderParameter(System.Drawing.Imaging.Encoder.Quality, quality);
65.       ImageCodecInfo codecInfo = GetEncoderInfo("image/jpeg");
66.       image.Save(fileName, codecInfo, parameters);
67.    }
68. } 

If you want to look at the GUI or just play around with the code you can download the project and do with it what you want. Enjoy.

Update: The project has been replaced with a newer version.

The reason I've been looking for another way of parsing the Card Game Language is that it relies on the generation of code files from a grammar file which is not very flexible when you want to make small changes to the language. This new approach, however, works all in C# code which seems to be much easier to work with - of cause there is more to running the code than just parsing it, but I'll have to look into that later.

To illustrate how the code works, take a look at the following code:

1. public class PhoneGrammar : Grammar
2. {
3.     public PhoneGrammar()
4.     {
5.         var number =
6.             Rep(Ch(char.IsNumber))
7.             .Build(hit => new string(hit.ToArray()));
8.  
9.         var localNumber =
10.             number.If(hit=>hit.Length == 3)
11.             .And(Ch('-'))
12.             .And(number.If(hit=>hit.Length == 4))
13.             .Build(hit => new PhoneNumber
14.             {
15.                 Prefix = hit.Left.Left,
16.                 Body = hit.Down
17.             });
18.  
19.         var longDistanceNumber =
20.             Ch('(')
21.             .And(number.If(hit=>hit.Length == 3))
22.             .And(Ch(')'))
23.             .And(localNumber)
24.             .Build(hit => new PhoneNumber
25.             {
26.                 AreaCode = hit.Left.Left.Down,
27.                 Prefix = hit.Down.Prefix,
28.                 Body = hit.Down.Body
29.             });
30.  
31.         ParsePhoneNumber = localNumber.Or(longDistanceNumber);
32.  
33.         var phoneNumberIgnoringWhitespace =
34.             Rep(Ch(' '))
35.             .And(ParsePhoneNumber)
36.             .And(Rep(Ch(' ')))
37.             .Build(hit => hit.Left.Down);
38.  
39.         ParsePhoneNumberList = Rep(phoneNumberIgnoringWhitespace);
40.     }
41.  
42.     public ParseAction<PhoneNumber> ParsePhoneNumber;
43.     public ParseAction<IList<PhoneNumber>> ParsePhoneNumberList;
44. } 

The code defines a grammar for parsing phone numbers. The way the grammar is constructed is by building up the patterns describing a valid phone number, starting from the definition of a number and then adding structure to the formatting of the number based on whether the phone number is long distance. Each pattern maps the matched string to the desired object it represents. In the blog post Louis also demonstrates how a grammar can be created to parse XML code. This is actually the basis for the parsing code found in the Spark View Engine which uses XML notation.

I find this approach very interesting and I'm looking forward to seeing how well it will work as a replacement for the Grammatica library I'm currently using. Now I just need to find that extra spare time it requires. If you find this stuff interesting you should definitely go check of Louis' blog post.

In the video he gives a host of tips and tricks on how to be more effective and  efficient with your time and how you process information. The tips include tools for managing information and measuring how much time you spend on unproductive websites during the day as well as techniques for information filtering.

It clocks in at just under an hour but it's well worth the time - and Scott's a great presenter to boot. So go check it out.

Personally, I have three core shows I follow as well as a couple of others when I'm out of content. They've helped me get to know about all sorts of different technologies I would never have heard of otherwise and to hear other people's perspective on the stuff that I think I know provides tremendous value as well.

The Stack Overflow Podcast 

The Stack Overflow podcast is a weekly hour of random chat between the two founders of Stack Overflow, Jeff Atwood and Joel Spolsky. The seriousness and level of actual content varies but its fun and interesting to listen to none the less. It leans a bit more towards entrepreneurial stuff than the other shows as it has been used to document the thoughts and ideas behind the development of the Stack Overflow site itself. They are mostly just the two of them but they occasionally bring in a guest to interview.

The .NET Rocks! Podcast 

 Second, there is the .NET Rocks podcast which deals with all things .NET related, each week seeing one or more guests. This show is hosted by Carl Franklin and Richard Campbell, two very experienced and entertaining guys. They are currently at their 498th show, so they know how to handle a technical interview. This show is highly recommended for anyone working with the .NET stack or who are just interested in seeing what it is all about. More exotic topics such as GPU computing, robotics and home automation are also covered.

Herding Code

Herding code is a weekly  discussion between K. Scott Allen, Kevin Dente, Scott Koon, and Jon Galloway. They discuss all sorts of interesting technologies with their guests, with no particular technology or company bias. They provide a lot of interesting views on practical things from working in the industry - to a greater degree than other shows with fewer hosts.

The Rest

Other interesting shows include Hanselminutes and Spaghetti Code and for a more comprehensive list, go here.

As with the previous CGL implementation, I'm working towards three specific end products:

• An improved version of the CGL
• A Silverlight environment for executing CGL games
• An environment for writing CGL code (Either a Silverlight application or something else)

While one of the motivations for the project is simply because its fun, there are a couple of goals I have in mind:

• Being able to easily change the language, both for the current implementation but also for future work
• Make the language simpler, more streamlined and more intuitive (facilitated by the point above)
• A richer development experience though intelligent error messages, syntax highlighting and other improvements possible when reimplementing the compiler for the bottom up
• Fewer runtime errors due to compile-time type checking
• Improved performance (this isn't really needed, but a very nice bonus we get for free)
• A reusable tool set for developing future language parsers
• A more polished game experience

It should be clear that there are a lot of benefits to this new implementation, but also that most of them are to the advantage of the developer and not the players. As the last point states, I plan on polishing up the game graphics and UI to some unknown extend, just to make the whole thing feel new. We don't want to make the mistake they made with Microsoft Calculator in Vista, where they rewrote the guts of the application but 'forgot' to change the UI. The result? No one noticed, and people complained that Microsoft kept shipping the same crufty, old apps.

The first article, which is to follow soon, gives an overview of the language itself and, as such, does not contain any implementation details, but I feel that it is necessary to better understand the big picture, going forward. Links to all the articles will be posted on the project page for CGL.

As other small issues had appeared I figured that I might as well fix them all up and publish the new version.

Version 1.1 changelog:

• Option for copying all meta data to new image.
• Button for setting the active directory to the app directory.
• Fixed issue where the jpg extension had to be all lowercase.
• Options used are now saved and automatically carried over between each use of the app.

As before, you can get the source code to play around with here. If you don't want to compile the code yourself you can get the binary here. Enjoy.

For you to get a sense of the project I'm undertaking, i'll start out by stepping through the language. At this point in time the language hasn't been fully implemented so there's bound to be a number of changes to it before the end of this project, but I'll make sure to keep this article up to date as a reference document for anyone wanting to learn the language.

The approach taken in CGL is to describe the structure of a card game, as one would see it if observing the game being played with real cards, with snippets of behavior logic imbedded in different areas. In this sense it actually resembles the structure of an XML document, as the game is built up of a tree structure of areas and piles with a number of attributes.

The first bit of code you will need for any game is a game declaration inside which all the content will go:

1. game:Solitaire
2.  
3. game

All the structural declarations follow this syntax, where the name becomes a variable reference you can use later (this becomes relevant with areas and piles).

The first thing found inside the game declaration must always be the info and the init declarations:

1. game:Solitaire
2.    info "Classic Solitaire game, with one card turned from the pile at a time."
3.  
4.    init sourcepile:mainDeck = GetShuffledDeck();
5. game

The info declaration specifies a descriptive string which can be presented to the player of the game and has no impact on the game itself. The init declaration is used to declare source piles to be used during the initialization phase of the game. They simply represent the cards available for the setup of the game, and would typically consist of a single shuffled deck. This is the only point at which cards can be created from nothing, as an important principle of the language is to follow the same restraints as a normal game where cards can't just disappear or appear out of nowhere. This should also serve to make the code easier to follow, and not result in very confused players. The init declaration is actually a block which means that it would normally also end with init, but some blocks types doesn't need the closing tag if there is only a single statement in the block.

Moving on, we come to our first part of the actual playing setup. To define common logic for a set of related piles, you group them into an area. Areas doesn't have to match any physical or logical layout but they make it easier to define related types of piles. So lets take a look at the code for declaring an area:

1. area:deckArea
2.    Position = {10, 10};
3.    <- mainDeck;
4.  
5.    pile:deck
6.       CardOffset = {1, 10};
7.    pile
8.  
9.    clicked
10.       // snip
11.    clicked
12. area

This code captures the three types of declarations you can make inside an area: initializers, pile declarations and event handlers. Initializers take the form of property assignments, functions and card movements that apply to all the piles in the area. Property assignments take the form of integer pairs in brackets as they represent positional logic such as pile offsets (between each pile). The arrow <- is an operator for moving cards from one pile to another. It generally has the form of target <- source but when used in initializers the target is implicitly resolved. When using the move operator as an area initializer, the cards are distributed across all its piles. Other ways to use the move operator are introduced later in the article.

After any initializers, an area must always have at least one pile declaration, though it needs not have any body as is the case above. Piles can have most of the same types of initializers as areas, though if a property has been specified in both a pile and its parent area, the pile property either takes precedenc or becomes relative to the property on the area. If more than a single initializer is used in the pile declaration, a closing pile tag is required.

Finally, an area can implement one of two event handlers, clicked and doubleclicked. They are executed each time the user interacts with pile elements of the area and provides access to the three variables Hand, ClickedCard and ClickedPile. The hand is a virtual pile type that also acts much as a card and is used as a means to select one or more cards for performing some action. The other two variables are just what they seem. A clicked event handler could look like the following:

1. clicked
2.    if deck.Size != 0
3.    {
4.       ReturnFromHand();
5.       theTurnedCards <- deck : 1;
6.       theTurnedCards.TopCard.Turn();
7.    }
8.    else
9.    {
10.       deck <- 1 <- theTurnedCards;
11.       deck.Turn();
12.    }
13. clicked

This code checks whether there are any cards left in the clicked pile (In this case deck and ClickedPile will always refer to the same instance as there is only one pile in the area). If there are, a single card is moved from the top of the pile to the pile theTurnedCards. The additional parameter to the move operator : 1 specifies the number of cards to move. The default is just to move all the cards. ReturnFromHand() takes any cards put into the hand and removes them (Note that they are not actually moved, just no longer registered as being stored in the hand). If the pile is empty, all the cards are returned to the deck pile and turned backside up. Instead of just moving the pile ordinarily, the optional extra pile operator specifies how many cards to move at a time. In this case we only move a single card at a time, effectively reversing the order of the pile.

If we take a look at the game declaration again we get the full picture of how a game can look:

1. game:Solitaire
2.    info "Classic Solitaire game, with one card turned from the pile at a time."
3.  
4.    init sourcepile:mainDeck = GetShuffledDeck();
5.  
6.    area:area1
7.       // snip
8.    area
9.  
10.    area:area2
11.       // snip
12.    area
13.  
14.    end
15.       // snip
16.    end
17. game

As you can see, the game consists of some initializations, a number of areas and something called the end block. This block contains code that is executed much like the event handlers inside areas. The difference is that it is executed each time another event has finished to determine if the end conditions for the game has been met. There is nothing special about the code that is performed here except that you cannot move cards (This would effectively mean that cards would move themselves, which users would not expect). You just need to call one of the functions Win() or Lose() to end the game, as shown below (You might not need a condition for losing, but you should always have a winning condition).

1. end
2.    if hearts.Size + spades.Size + diamonds.Size + clubs.Size == 52
3.       win();
4. end

The philosophy behind the executing code in event handlers and the end block is to keep it as simple and readable as possible and stay close to the concepts of real card games. I want the developer to be thinking in terms of how he would play the game and it should be easy to identify what parts of the game rules a specific line of code represents. Because of these requirements you will find that common operations and control structures are not included in the language such as local variables and looping control flow. Hopefully, all the places you would need these types of constructs, I have managed to create functions and operators that can replace them. The truth is, only through creating many, many card games would I know if this is the case, and I may be forced to introduce them again (the examples both existed in the previous version of CGL, but I found no need for them to stay).

An interesting feature of the language that I haven't found anywhere else (hopefully not for a good reason) is the ability to write the following and having it evaluate as you would logically think:

1. if 10 < deck.Size < 20
2.  
3. // Equivalent C# version
4. if (10 < deck.Size && deck.Size < 20)

I can't count the number of times that I've cursed other languages for not working this way, so I'm happy to introduce the feature into CGL. It's not that I've actually found a need for it in the language, I just couldn't let the opportunity pass by :) Of course, changing the behavior of known constructs and introducing new operators such as the move operator all makes it harder for people to get into the language, but I hope they prove to be worthwhile. After all, you only have to learn them once but can benefit from them countless times, thereafter.

This should cover the structure of a game and the only thing missing, except perhaps for some semantic details here and there, is a reference documentation for all the properties and functions supported. These are still a bit into the air right now, so I won't add them here but when they're done I'll put them up in their own document and link to them.

Resources:

• The source code for a simple solitaire game I've invented, called Gypsy Eye
• Solitaire terminology: http://en.wikipedia.org/wiki/Solitaire_terminology
• List of solitaire games: http://en.wikipedia.org/wiki/List_of_solitaire_card_games

In the next article we'll take a look at how to put together a grammar and parse a piece of source code.

In this article I'll introduce the concepts used as building blocks for the compiler and how they can be composed to match complex textual patterns. At the end of this article we'll be able to parse ordered bits of text and turn them into managed objects.

There are a number of ways to approach creating a compiler, but the one we'll be exploring here is a simple recursive decent parser where the grammar for the language is encoded in C# code rather than being described using formats such as EBNF. This is not really a theoretical series so I won't be going into detail on the type of compiler or discuss topics such as formal semantics, just the practical bits.

The main concept I'm building my compiler around is a delegate for parsing source code which returns a parse result of an arbitrary C# type. A number of these can then be composed together to match complex patterns and create a whole object graph. This concept is not something I've invented myself, it's based on a blog post by Louis DeJardin, the guy behind the Spark View Engine for ASP.NET MVC. This post is very similar to Louis', which can be found here, but in the next article and forward we use it for our own specialized grammar.

To get started we'll define the interfaces of the basic concepts we're going to need:

1. public delegate ParseResult<TValue> ParseAction<TValue>(Position position);
2.  
3. public class ParseResult<TValue>
4. {
5.     public Position Rest { get; }
6.     public TValue Value { get; }
7.     public ParseError Error { get; }
8. }
9.  
10. public class Position
11. {
12.     public int Line { get; }
13.     public int Column { get; }
14.     public string Context { get; }
15.  
16.     public char Peek();
17.     public string Peek(int length);
18.     public Position Advance(int offset);
19. }
20.  
21. public class ParseError
22. {
23.     public int Line { get; }
24.     public int Column { get; }
25.     public string Message { get; }
26. } 

The ParseAction delegate is a function which, given a position in the source code, yields either a result of the generic type or a parse error if the pattern did not match. The result of the parser is stored in a ParseResult object which hold either of the possible outcomes. It also contains the position in the source code where a subsequent parser would start off from. The Position object is an immutable description of a point in the source code and it can potentially wrap a source that is more complex than a string if needed.

Using these classes we can begin to create a Grammar class where we define the most basic patterns we want to match.

1. public class Grammar
2. {
3.     public static ParseAction<char> Ch(char match)
4.     {
5.         return delegate(Position input)
6.         {
7.             if (input.Peek() == match)
8.                 return new ParseResult<char>(input.Advance(1), match);
9.             return new ParseResult<char>("Encountered unexpected char", input.Line, input.Column);
10.         };
11.     }
12.  
13.    public static ParseAction<IList<TValue>> Rep<TValue>(ParseAction<TValue> parser)
14.     {
15.         return delegate(Position input)
16.         {
17.             Position rest = input;
18.             List<TValue> list = new List<TValue>();
19.             var results = new List<ParseResult<TValue>>();
20.             results.Add(parser(input));
21.             while (!results.Last().HasError)
22.             {
23.                 list.Add(results.Last().Value);
24.                 rest = results.Last().Rest;
25.                 results.Add(parser(rest));
26.             }
27.             return new ParseResult<IList<TValue>>(rest, list);
28.         };
29.     }
30.  
31.     public static ParseAction<TValue> Or<TValue>(ParseAction<TValue> parser1, ParseAction<TValue> parser2)
32.     {
33.         return delegate(Position input)
34.         {
35.             var result1 = parser1(input);
36.             if (result1.HasError) return parser2(input);
37.             return result1;
38.         };
39.     }
40.  
41.    public static ParseAction<Chain<TValue1, TValue2>> And<TValue1, TValue2>(ParseAction<TValue1> parser1, ParseAction<TValue2> parser2)
42.     {
43.       return delegate(Position input)
44.         {
45.             var result1 = parser1(input);
46.             if (result1.HasError)
47.                 return new ParseResult<Chain<TValue1, TValue2>>(result1.Error);
48.             var result2 = parser2(result1.Rest);
49.             if (result2.HasError)
50.                 return new ParseResult<Chain<TValue1, TValue2>>(result2.Error);
51.             var value = new Chain<TValue1, TValue2>(result1.Value, result2.Value);
52.             return new ParseResult<Chain<TValue1, TValue2>>(result2.Rest, value);
53.         };
54.     }
55. }

Each of the above methods generate a ParseAction for a specific, useful purpose. The first matches a specific char while Rep matches a repeated sequence of a pattern. Using these, we can write the following code (I've removed the references to the Grammar class from the method calls to simplify the example):

1. var parseChar = Ch('c');
2. var parseChars = Rep(parseChar);
3.  
4. var result1 = parseChar(new Position("c"));
5. var result2 = parseChars(new Position("cccc"));

As you can see, we used one parser to create another. The Rep function keeps using the Ch('c') parser to match characters, which it stuffs into a List<char>. The methods Or and And does the same for matching one pattern or another, or one pattern followed by another, respectively. As a side note, you can see that I have supplied none of the type arguments for the generic function. This is because of the powerful type inference capability of the C# compiler.

1. var parseAnotherChar = Ch('k');
2. var parseEitherChar = Rep(Or(parseChar, parseAnotherChar));
3. var parseBothChars = Rep(And(parseChar, parseAnotherChar));
4.  
5. var result1 = parseEitherChar(new Position("kkkckckc"));
6. var result2 = parseBothChars(new Position("ckckckckck")); 

Here, we define two parsers that matches series of characters. The one using Or matches a sequence where each char can either be c or k where the one using And matches only sequences of cs followed by a k. To end up with more fluent code, we can define a few useful extension methods:

1. public static class GrammarExtensions
2. {
3.     public static ParseAction<TValue> Or<TValue>(this ParseAction<TValue> parser1, ParseAction<TValue> parser2)
4.     {
5.         return Grammar.Or(parser1, parser2);
6.     }
7.  
8.     public static ParseAction<Chain<TValue1, TValue2>> And<TValue1, TValue2>(this ParseAction<TValue1> parser1, ParseAction<TValue2> parser2)
9.     {
10.         return Grammar.And(parser1, parser2);
11.     }
12. }
13.  
14. // Allows for the following
15. var parseEitherChar = Rep(parseChar.Or(parseAnotherChar));
16. var parseBothChars = Rep(parseChar.And(parseAnotherChar));

As you might have noticed, the And parser returns an object of the type Chain. This is simply a container for the results of the two parse actions. However, it introduces the problem of creating increasingly complex result types as your parsers become more complex. To reduce this problem we introduce the Build function which translates a complex result into a simpler one. It basically just takes the result of a parser and applies a function to it.

1. public static ParseAction<TValue2> Build<TValue1, TValue2>(ParseAction<TValue1> parser, Func<TValue1, TValue2> builder)
2.  {
3.     return delegate(Position input)
4.     {
5.         var result = parser(input);
6.         if (result.HasError) return new ParseResult<TValue2>(result.Error);
7.         try
8.         {
9.             return new ParseResult<TValue2>(result.Rest, builder(result.Value));
10.         }
11.         catch (ParseException e)
12.         {
13.             return new ParseResult<TValue2>(e.Message, input.Line, input.Column);
14.          }
15.     };
16. }
17.  
18. var parseBothChars = And(parseChar, parseAnotherChar).Build(hit => hit.Left + hit.Down); 

In this case, we use Build to change the result type from Chain<char,char> to string. Once again, the type inferral of the C# compiler comes to our rescue, providing us with proper intellisense on the properties on the Chain object. This will save your sanity when building from more complex chains. Also notice that we catch ParseException errors, a custom exception type which we can use to signal that some parse rule was broken when trying to build the object.

These, and more, are common building blocks for any grammar and, therefore, our primary job is now to create a Grammar class which holds all the basic parsers. To create a more specialized grammar you simply inherit from Grammar and add new parsers.

We're getting to the end of this article but hopefully you got the idea of how this all works. If not, I urge you to go read up on Louis' blog on the same topic. I've also uploaded some of the code from my compiler so you can see some of the other parsers to put in the Grammar class. The code won't compile as it relies on some other code of mine, but it should be possible to understand it regardless.

In the next article we'll begin to create a more specialized grammar for the CGL language using the building blocks presented here.

Clean Code is one of the best programming books I've read in a long while. It is based on many of the same guiding principles I have for software development, such as the central role of readable code and the need to continually improve yourself as a craftsman, beyond the standard requirements of your job.

Some of the practices presented in the book weren't new to me and, indeed, some of them were a bit too idealistic, but apart from that it was truly an insightful read.

One of the more eye opening concepts was a way to write code so that it can be read much like you would read a newspaper. The first step in this process is to separate your code into lots of small functions. Essentially there should be no functions larger than about 4 lines and they should do one thing and one thing only. This thing should be captured accurately and unambiguously in the function name. A function should read like a sentence - to do x (the function name), you must do a, b and c (lines of code). Note that it is important that the contents of the function should be at the same level of abstraction and that this level of abstraction should be one level lower than that of the function name. The point to all of this is to make it trivially easy to see what a function does. Consider the following code I recently wrote for resizing images:

1. public enum ResizeStrategy
2. {
3.     Stretch,
4.     BestFit,
5. }
6.  
7. public static class ImageFormatter
8. {
9.     public static Image ScaleImage(Image originalBitmap, int maxDimension)
10.     {
11.         float aspectX = maxDimension / (float)originalBitmap.Width;
12.         float aspectY = maxDimension / (float)originalBitmap.Height;
13.         float actualAspect = Math.Min(aspectX, aspectY);
14.         int sourceWidth = (int)(originalBitmap.Width * actualAspect);
15.         int sourceHeight = (int)(originalBitmap.Height * actualAspect);
16.         var resized = new Bitmap(sourceWidth, sourceHeight);
17.         Graphics g = Graphics.FromImage(resized);
18.         g.DrawImage(originalBitmap, new Rectangle(0, 0, resized.Width, resized.Height));
19.         return resized;
20.     }
21.  
22.     public static Image ScaleImage(Image originalImage, float scale)
23.     {
24.         int width = (int)(originalImage.Width * scale);
25.         int height = (int)(originalImage.Height * scale);
26.         var resized = new Bitmap(width, height);
27.         Graphics g = Graphics.FromImage(resized);
28.         g.DrawImage(originalImage, new Rectangle(0, 0, resized.Width, resized.Height));
29.         return resized;
30.     }
31.  
32.     public static Image ScaleImage(Image originalImage, float scaleWidth, float scaleHeight)
33.     {
34.         int width = (int)(originalImage.Width * scaleWidth);
35.         int height = (int)(originalImage.Height * scaleHeight);
36.         var resized = new Bitmap(width, height);
37.         Graphics g = Graphics.FromImage(resized);
38.         g.DrawImage(originalImage, new Rectangle(0, 0, resized.Width, resized.Height));
39.         return resized;
40.     }
41.  
42.     public static Image ResizeImage(Image originalImage, int width, int height, ResizeStrategy thumbnailFormat)
43.     {
44.         Image thumbnail = new Bitmap(width, height);
45.         switch (thumbnailFormat)
46.         {
47.             case ResizeStrategy.Stretch:
48.                 RenderStretchedThumbnail(originalImage, thumbnail);
49.                 break;
50.             case ResizeStrategy.BestFit:
51.                 RenderBestFitThumbnail(originalImage, thumbnail);
52.                 break;
53.             default:
54.                 throw new ArgumentException("Thumbnail format not valid");
55.         }
56.         return thumbnail;
57.     }
58.  
59.     private static void RenderBestFitThumbnail(Image originalImage, Image thumbnail)
60.     {
61.         float aspectX = thumbnail.Width / (float)originalImage.Width;
62.         float aspectY = thumbnail.Height / (float)originalImage.Height;
63.         float actualAspect = Math.Max(aspectX, aspectY);
64.         int sourceWidth = (int)(thumbnail.Width / actualAspect);
65.         int sourceHeight = (int)(thumbnail.Height / actualAspect);
66.         Graphics g = Graphics.FromImage(thumbnail);
67.         g.DrawImage(originalImage, new Rectangle(0, 0, thumbnail.Width, thumbnail.Height), new Rectangle(0, 0, sourceWidth, sourceHeight), GraphicsUnit.Pixel);
68.     }
69.  
70.     private static void RenderStretchedThumbnail(Image originalImage, Image thumbnail)
71.     {
72.         Graphics g = Graphics.FromImage(thumbnail);
73.         g.DrawImage(originalImage, 0, 0, thumbnail.Width, thumbnail.Height);
74.     }
75. }

I don't consider this code bad in any particular way, but lets see what happens if we rewrite it, using the above guidelines:

1. public enum ResizeStrategy
2. {
3.     Stretch,
4.     BestFit
5. }
6.  
7. public class ImageFormatter
8. {
9.     private Image _workingImage;
10.     private Image _originalImage;
11.  
12.     public Image ResizeImage(Image originalImage, int width, int height, ResizeStrategy resizeStrategy)
13.     {
14.         _originalImage = originalImage;
15.  
16.         PrepareImage(width, height);
17.         switch (resizeStrategy)
18.         {
19.             case ResizeStrategy.Stretch:
20.                 RenderStretchedImage();
21.                 break;
22.             case ResizeStrategy.BestFit:
23.                 RenderBestFitThumbnail();
24.                 break;
25.             default:
26.                 throw new ArgumentException("Thumbnail format not valid");
27.         }
28.         return _workingImage;
29.     }
30.  
31.     private void PrepareImage(int width, int height)
32.     {
33.         _workingImage = new Bitmap(width, height);
34.     }
35.  
36.     private void RenderStretchedImage()
37.     {
38.         Graphics g = Graphics.FromImage(_workingImage);
39.         g.DrawImage(_originalImage, GetTargetDrawingRectangle());
40.     }
41.  
42.     private Rectangle GetTargetDrawingRectangle()
43.     {
44.         return new Rectangle(0, 0, _workingImage.Width, _workingImage.Height);
45.     }
46.  
47.     private void RenderBestFitThumbnail()
48.     {
49.         float scale = CalculateMaximumScaleNotCroppingBothDimensions();
50.         Rectangle source = CalculateRectangleFromScaledWorkingImage(scale);
51.         RenderPartialImage(source);
52.     }
53.  
54.     private float CalculateMaximumScaleNotCroppingBothDimensions()
55.     {
56.         float xScale = _workingImage.Width / (float)_originalImage.Width;
57.         float yScale = _workingImage.Height / (float)_originalImage.Height;
58.         return Math.Max(xScale, yScale);
59.     }
60.  
61.     private Rectangle CalculateRectangleFromScaledWorkingImage(float scale)
62.     {
63.         int width = (int)(_workingImage.Width / scale);
64.         int height = (int)(_workingImage.Height / scale);
65.         return new Rectangle(0, 0, width, height);
66.     }
67.  
68.     private void RenderPartialImage(Rectangle source)
69.     {
70.         Graphics g = Graphics.FromImage(_workingImage);
71.         g.DrawImage(_originalImage, GetTargetDrawingRectangle(), source, GraphicsUnit.Pixel);
72.     }
73.  
74.     public Image ResizeImage(Image originalImage, int maxDimension)
75.     {
76.         _originalImage = originalImage;
77.         float scale = CalculateScaleForFixedMaxDimension(maxDimension);
78.         return ScaleImage(originalImage, scale);
79.     }
80.  
81.     private float CalculateScaleForFixedMaxDimension(int lengthOfMaxDimension)
82.     {
83.         float xScale = lengthOfMaxDimension / (float)_originalImage.Width;
84.         float yScale = lengthOfMaxDimension / (float)_originalImage.Height;
85.         return Math.Min(xScale, yScale);
86.     }
87.  
88.     public Image ScaleImage(Image originalImage, float scale)
89.     {
90.         _originalImage = originalImage;
91.         PrepareScaledImage(scale);
92.         RenderStretchedImage();
93.         return _workingImage;
94.     }
95.  
96.     private void PrepareScaledImage(float scale)
97.     {
98.         int width = (int)(_originalImage.Width * scale);
99.         int height = (int)(_originalImage.Height * scale);
100.         _workingImage = new Bitmap(width, height);
101.     }
102.  
103.     public Image ScaleImage(Image originalImage, float widthScale, float heightScale)
104.     {
105.         _originalImage = originalImage;
106.         PrepareScaledImage(widthScale, heightScale);
107.         RenderStretchedImage();
108.         return _workingImage;
109.     }
110.  
111.     private void PrepareScaledImage(float widthScale, float heightScale)
112.     {
113.         int width = (int)(_originalImage.Width * widthScale);
114.         int height = (int)(_originalImage.Height * heightScale);
115.         _workingImage = new Bitmap(width, height);
116.     }
117. }

One of the first thing you might notice is that the code has grown from 75 lines to 117. This is just a price you have to pay, but I believe that readability should almost always outweigh brevity.

In the first method, I violate the principle of function size, but that is, unfortunately, necessary when using switch statements. You'll notice that the actions performed in the function is relegated to other functions, which is the main way this technique requires code to be structured.

The functions are topologically sorted, such that a given function is directly followed by the functions used in its body, which again are followed by their own dependencies, etc. Think of it as a stack that, as you read through the file, pushes the most relevant functions to the top as needed. Thus, the first ResizeImage function is followed by the function PrepareImage, which is its first dependency. If this function had had any dependencies, they would have followed immediately after before continuing with the dependencies of ResizeImage.

Apart from creating a very literate piece of code, the transformation also revealed a few cases of repeated code which was turned into reusable functions. Where before I might not have bother with looking for such similarities in the code, it becomes more obvious when splitting everything into its essential parts.

When I read about this approach, it struct me as a very clever way to structure your code, but there are a few caveats that I'm not too sure about, yet. I find that the resulting code can be a bit overwhelming to look at as its structure has become more homogeneous and, as mentioned above, there are just more lines of code to read. It might help, though, if the IDE would highlight the public functions, so you could quickly navigate to the part of the code you need. Regardless of these issues, I find the approach very interesting and I'm looking forward to seeing how well it works for me.

If you found the technique interesting, I'm sure you'll love the book, as it's filled with little nuggets like this.

Version 1.2 changelog:

• Added options for setting length of the minimum, vertical and horizontal dimensions, instead of just the maximum dimension.
• The resizing work is now done in a background thread making the UI responsive while working.
• Added support of cancelling work.
• Removed a bug preventing the progress bar from being updated properly.

Recently, I've been very interested in architectural patterns for improving modularity, testability and other such desirable properties. The Model View Presenter pattern (The Supervising Controller variant) is one of these, and after reading an introduction to it by Phil Haack, I've been playing around with it for the GUI of my card game compiler. It provides a great way to keep the UI classes very thin and only deal with UI business, allowing us to maintain the single responsibility principle.

While it was hardly necessary, I implemented the MVP pattern for the single view in the Resizer app but I'm beginning to get the feeling that it will grow a lot in the future.

For those who are interested in architecting better apps, the Composite Application Guidance for WPF (Code named Prism) is also a good read. Actually, it's more than just guidance, it's also a library that can help you get up to speed on these practices in no time and it includes very helpful code samples for all the important points. The project comes out of the Microsoft Patterns & Practices department which provides guidance for all sorts of .NET development.

As usual, you can get the source code here and the binary here.

Apart from having it's guts totally replaced, the application has also recieved a graphical overhaul. It now features more and better animations and a new card design. The cards look a bit similar at the moment but I'll be making them a more distinguishable in the future. I'm still trying to figure out the best way to represent the face cards without ruining the style. As you can see I'm going for a worn, kind of old school look.

You can try out the new version here. If you feel like it, you can also compare and contrast with the old version 2. As I mentioned, there are some performance issues with the new version and it actually loads games much slower than the old one. It appears that the strategy I'm using for the compiler is not very efficient and it already begins to show when compiling games of a few hundred lines of code, possibly due the massive amounts of recursion or the heavy use of reflection. When time permits, I'll scour the web for a good profiler and see if it seems fixable.