Kian Ryan (.NET, Android, Geekery)

I was up til 2am on this one.

A client’s relatively shiny-new SQL Server 2008 R2 Reporting Services Express install was failing to start. Pinging the relevant URLs:

http://server/reports


http://server/reportserver

Was continually responding with a 503 error. No further detail, just a HTTP 503 response, which translates to “Service unavailable”. The Windows “Report Server” service was running, and started/stopped just fine. My normal response to this kind of problem is to start looking at logs – Windows logs were all clear. I googled around the subject, which gave several “poke and pray” solutions, not too helpful.

To fix a problem like this, you need logs. Every single StackOverflow, or forum response to this problem should read “check what’s going on in your logs”. You don’t diagnose a medical condition without some evidence to back it up. You need data.

A few responses pointed to this MSDN article which gives you details for turning on HTTP event logging. Genius! Except that all you get is a line which reads:

2012-02-17 17:51:38 192.168.23.204 1222 192.168.23.240 80 HTTP/1.1 GET /Reports 503 - N/A -

Not very helpful. Eventually, after ingesting far too much caffine and having to dig around in Reporting Services textbooks, I found a reference to the Reporting Services log files, in this case located here:

C:\Program Files\Microsoft SQL Server\MSRS10_50.SQLEXPRESS\Reporting Services\LogFiles

From there I was able to diagnose the problem as relatively trivial and fix the configuration problem. In my case (yours will most likely be different), the problem was related to an empty RSWindowsExtendedProtectionlevel XML tag in the rsreportserver.config file. For your own individual problem – READ YOUR LOGS.

Today I feel it is appropriate to finish with:

I am learning Ruby and Vim. I’m also attending the Preston Codejo hosted by Magma Digital, where were using Ruby as the driver.

As I am wont when learning a new platform (or new techniques on a new platform), there is a build of Conway’s Game of Life on GitHub:
https://github.com/kianryan/RubyGameLife

This is a curses based implementation which can run with either the defaults, or run with parameters:

ruby life.rb [rows] [cols] [num_pos]
where:
rows - Number of rows to display
cols - Number of cols to display
num_pos - Number of initial positions to set.  This is done randomly, so you are likely to get less positions than specified.

Press q to quit when you’re bored. Feel free to fork, make changes, ideas, pulls, etc.

It’s all Aquarion’s fault.

While down in London last, Mr Aquarion introduced me to Tiny Towers, a tower building game. I played it for a few hours and decided what I really wanted to play was Sim Tower. Running OS X, and Sim Tower being “of an age”, this left me with a platform challenge to overcome.

Despite running Windows VMs for work, I didn’t fancy running a Windows VM for play, so my first attempt was to run the game using WINE. This failed miserably, with my machine turning in to a scorching, flaming, fireball of pain (ow hot, ow hot). For a game involving 2D graphics released in 1994, not the best of success.

My second attempt involved finding a port of Sim Tower built and tweaked against WINE libraries as a nice and tidy application package. I’m usually a fan of this approach – it makes life easy-ish for the user and most of the hard work has already been done by other developers. Same problem again – aircraft carriers ahoy, burning lap syndrome and a battery with less staying power than Usain Bolt running a marathon.

At this point, I fell in to an air of despair. Here was a game from my childhood, the only Sim-type game I truly enjoyed, and nothing (sensible) would work (I’m still not building a Windows 98 VM). I then remembered that Maxis were developers of Awesome, and lots of their games worked on both MacOS Classic and Windows. Indeed, the SimTower CD works for both platforms – FANTASTIC. All I need is a Mac Classic environment running on top of OS X. In comes SheepSaver a MacOS emulator. A bit of juggling to find compatible ROM images and a copy of MacOS 9 and I had a working Mac Classic environment. To boot, it only takes a few second to … boot. From there, SimTower took the whole of 2 minutes to get up and running.

Once I decided I was switching to running on MacOS, I was surprised how easy it was. Back in the day, I didn’t own a Mac, I spent too long hacking around with Windows in its various flavours (and a few flavours of Linux). Installing SimTower consisted of dragging a package to the hard disk and running it. No, “missing DLL” errors, no “incompatible DirectX” malarky, no “where’s DOS 6.22?”, the bugger just worked. There are days when I wonder how the smurf Windows ever managed to get a stranglehold on the market (yes, I know) when the alternatives were so much easier to use.

Oh look – 4 Stars!