Tetris with Javascript

Lately I've been learning a bit of Javascript and trying to put it into practice. The problem always seems to be coming up with an interesting way of using something new. So I decided it was time to write my first Javascript game and Tetris was the obvious choice.

It's amazing how something so small and simple can remind you how much you enjoy programming. It took less than a day and I managed to get a basic implementation of Tetris up and running. Simple problem solving and logical thinking but so much fun! I used an HTML canvas and 5 javascripts files / classes and hey presto, Tetris.

I've got a long way to go before I can call myself Javascript proficient. I'm finding it a challenge to adapt to a dynamic language after so many years of C# and I'm definitely still wrapping my head around Prototypal Inheritance. But if I keep having this much fun, I should be there in no time.

If you want to have a quick play of the game you can go here and if you want to look at the code you can go here.

Share the knowledge

Everyone has their list of technical sites / blogs they enjoy visiting from time to time. I think it's imperative to get yourself (and sometimes force yourself) to read something technical, even if it's something you think you already know. It's always a chance to fill any gaps or simply refresh your knowledge.

I've found some sites that are great, especially when it comes to the refreshing what you know. There are a lot more blogs I regularly visit but I like these 3 when I just want to quickly learn/review something.

• 2,000 Things You Should Know About C#
• Dot Net Perls 
• WPF Tutorial.net

Please feel free to share any of your favourites.

Guard yourself

It's often handy to have "Guard" logic in your code to validate expectations. It's an integral part of the code and is generally used to throw exceptions when something does not meet expectations. The bulk of the Guard code would live at the beginning of methods to validate arguments, but in theory it could be used anywhere for anything.

There are a large number of open source libraries that provide this functionality (try a nuget search for guard). While it's always nice when somebody else has already done the hard work, in this case the work isn't really that hard. So you might, for reasons of flexibility, want to write your own. Here is a very simple example that I think gives full flexibility and allows you to add any bespoke checks you may need.

First we have a very simple static class that is the heart of the implementation.

I told you it was simple! This would allow you to validate anything and throw any exception. I've gone for "Ensure.That()" so there is less likelihood of naming conflicts and I really like how it reads, "Ensure that ...".

Next, I've created another very simple static class with the validations.

This is a very small subset of the methods you might require (although it would probably cover the bulk of your validations). You would be able to add as you go. Obviously you don't need to use methods from this class to do the validation but it is handy having everything in one place.

Here is an example of it in action

Very simple and again I like the way it reads, "Ensure that value is ...".

Small Things - Recursive Lambda

In hindsight recursive lambda is obviously possible, but it's nothing I've ever come across and nothing I'd ever tried. I think it has a very high coolness factor! But not entirely sure how often it would be useful.

Anybody have any interesting examples of actual use in the wild?

Nicely Dynamic

The dynamic keyword scares me. I understand why it exists (interaction with COM and scripting languages like IronPython) but I know what developers are like. Dynamic used everywhere for no apparent reason other than to try it, resulting in code that is hard to read and maintain. OK, probably not that bad, but I think it's fair to say that under normal circumstances a developer should not use dynamic. Unless...

I think I found a justifiable use of dynamic. Consider a Dictionary<Type, IConverter<T>> where Type and T should be the same. But how would you manage the dictionary. Dynamic to the rescue.

I really like this approach. The use of dynamic is nicely abstracted within your class so nobody ever needs to know. And because you're managing the getting and setting you can be very confident that the dynamic value extracted from the Dictionary is always what you expect.

UX Smoke and Mirrors

I recently had to implement a requirement where the specification was (roughly):
1. Take a table of data and print it using a FlowDocument
2. The font size must decrease to fit as many columns as possible up to a minimum font size.

(Just a heads up, the next part is a bit boring. Feel free to skip to the last paragraph if you want to get to the point of the post quickly)

At first it seemed like a not very trivial thing to do. One approach I thought of was to loop through each column and each row, calculating the width of the text when rendered, therefore the expected width of each column. Then repeat that process, decreasing the font size, until all the columns fit or the minimum font size is reached. It's possible to calculate the expected rendered width of the column by creating a FormattedText object and getting the Width property.

This works, but it is immensely slow. If we have 100 rows with 100 columns, we're measuring the width of 10,000 strings, as many times as it takes to fit the data to the page. Not ideal.

Then I hit on a winner. What if I measure everything just once at the default font size and calculate the widths of each column. I have the width of the document so I know how many columns can fit. Here's where it gets interesting. A WPF Grid can be added to the document (it's possible to add a UIElement to a FlowDocument by adding it to a BlockUIContainer) and a scale transform can be applied to shrink it to fit the page (or as many columns as possible).

The scale ratio can be calculated by comparing the document width with the total column widths. There must be a minimum scale ratio (to ensure we don't minimise the font size too much) which can roughly be calculated by comparing the default font size and the minimum font size (took a bit of trial and error). So our scale ratio is the bigger of the calculated scale ratio and the minimum scale ratio.

Now it becomes relatively easy to add columns one at a time until no more columns will fit, using the column width and the scaling ratio in the calculations. Then create the Grid with the columns, apply the scale transform using the calculated ratio and add it to the document.

This worked like a dream. It was however still a bit slow for my liking. So I added logic to find the longest string in the column and calculate the width of that text. This made it lightning fast. Unfortunately it turns out not all text is created equal. Upper-case characters take up more space than lower-case so sometimes the data in a column was being truncated. To solve this I gave upper-case letters a slightly higher weighting than lower-case, compared the summed weightings of the text of each column to find what "should" be the longest text when rendered, then calculated the column width with that text.

All of that obviously super exciting for the reader. Maybe. And means very little to you with no code to look at. But the point I'm trying to make in this post is that with UX development, smoke and mirrors can sometimes be your best friend. If you can use a bit of magic to deliver your requirement and it does what the user expects, mission accomplished. And if your smoke and mirrors helps considerably with performance, even better.

Small Things - String Indexer

Great software doesn't just happen. It's a result of very many decisions of which some are small, others more vital, but all of them incrementally adding to the final solution. Any decisions taking you in the wrong direction (i.e. away from an amazing end product) is a poor decision. Even the small, seemingly insignificant ones. Here's one that I've seen recently.

String literals should be replaced with a string constant declared somewhere and re-used.

I realise this may seem pedantic and in a way it is. But this simple act of laziness (yes, lazy) is a decision taking you in the wrong direction. It results in code that is less robust. But almost more importantly it's a sign that bad decisions are being made. Be a good citizen and keep making good decisions.

(Now please look away as I dismount from my high horse)