Just a quick reminder to the programmers out there: make sure you write unit tests from the beginning!
I’ve recently been working on a NHibernate/ActiveRecord class library that’s fairly complex. When finished, it will wrap 125 database tables into C# classes. At the moment, it’s approximately 20% complete and I only just started writing unit tests yesterday. What happened when I ran the tests?
They bombed. It seems there is a class somewhere that has a table name misspelled. Unfortunately, the tables I have wrapped have a ton of BelongsTo relationships, so the SQL statements generated are massive (lazy loading doesn’t seem to fix this, for some reason). It’s going to be a huge headache to track down the spelling mistake since the database driver doesn’t provide any useful error information.
If I had written a unit test every time I added a new table mapping, I would have caught my spelling mistake almost instantly. But, since I waited until the library was 20% finished, I just made my job that much harder.
So, who wants to guess what brand of soda I drink every day? That photo happens to be the contents of my trash can at the office. The whole place is practically paper-less, as you can see.
The web application I’m working on comes in two parts: the API and the Interface. The API is an ASP.NET application. The interface is written entirely in Javascript (using ExtJS) and one very simple HTML page.
Hosting the Javascript interface in IIS was simple. The ASP.NET application, however, needs to be run in debug mode from Visual Studio 2008. Unfortunately, since I’m on Vista Home Premium, this just doesn’t work (the patch released by Microsoft was apparently for a pre-release version of Vista, and is therefore not installable on the retail version). That’s all fine and good. I can live with using the ASP.NET Development Server for now.
There’s a problem, however. The interface needs to make AJAX calls to the API application. The application runs on port 8888, rather than 80, so any XMLHttpRequest calls will be denied because a change in port number is classified as a change in domain. How do I make AJAX calls to the API application during development, then?
The answer: a proxy. I wrote a very small Classic ASP script (because who needs an entire ASP.NET application for 5 lines of code?) and placed it in the same directory as the Javascript interface:
1
2
3
4
5
6
| Set req = Server.CreateObject("WinHttp.WinHttpRequest.5.1")
req.Open "GET", Request.QueryString("url"), false
req.Send
Response.ContentType = req.GetResponseHeader("Content-Type")
Response.Write(req.ResponseText) |
Now, I make AJAX calls to /proxy.asp?url=http://localhost:8888/customers/list. The result is returned as XML which can be gobbled up by ExtJS and used for whatever I want. Of course, there’s no way I would recommend this for a production instance of the application. Ever.
For development purposes, however, it works pretty well. The only thing it needs is a way to preserve the query string. MonoRail throws a fit when I try to add that feature, however.
While working on a simple web API, I needed a way to serialize an object (using the XML serializer) to a string so I could return it as an API response. Unfortunately, there’s no Serialize() override for returning a string value. Instead, you’ll have to use a MemoryStream object and the System.Text.Encoding class.
1
2
3
4
| XmlSerializer xs = new XmlSerializer(typeof(YourObject));
MemoryStream ms = new MemoryStream();
xs.Serialize(ms, instanceOfYourObject);
Console.WriteLine(Encoding.UTF8.GetString(ms.ToArray())); |
Perhaps an extension method would be good in this case.
1
2
3
4
5
| public static string GetXmlString(this XmlSerializer xs, object obj) {
MemoryStream ms = new MemoryStream();
xs.Serialize(ms, obj);
return Encoding.UTF8.GetString(ms.ToArray());
} |
1
2
| XmlSerializer xs = new XmlSerializer(typeof(YourObject));
Console.WriteLine(xs.GetXmlString(instanceOfYourObject)); |