Querying XML with namespaces in PowerShell

Apparently it's ridiculously easy to parse XML in PowerShell once you have the right objects set up:

[xml] $xml = Get-Content .\DeploymentProfile.PRODUCTION.xml
$ns = new-object Xml.XmlNamespaceManager $xml.NameTable
$ns.AddNamespace('dns', 'http://www.mycompany.com/Some/Namespace/Deployment/DeploymentProfiles.xsd')
$xml.SelectNodes("//@dns:ServerHostName", $ns) | ForEach-Object { $_.Value } | sort | Get-Unique

In this example, I query a deployment configuration for attributes called "ServerHostName" within the XML namespace "http://www.mycompany.com/Some/Namespace/Deployment/DeploymentProfiles.xsd". This was exceptionally useful today when I quickly needed to figure out what servers my system was using and send that information to others to configure those servers.

Journey to robust Windows Services: NHibernate throws with System.InvalidOperationException: Unable to generate a temporary class

Recently I've been trying to deploy a new web application to an old machine running Windows Server 2003 (not by choice). When I would start the application, NHibernate would thrown in its class constructor with a message along the lines of :

System.InvalidOperationException: Unable to generate a temporary class (result=1).
error CS2001: Source file 'C:\WINDOWS\TEMP\wz58eig4.0.cs' could not be found
error CS2008: No inputs specified

The problem was caused by the fact that the user under which I was running the application didn't have access to the 'C:\Window\Temp' folder where the temporary folder was being created. The solution was simple: update the security settings of that folder to allow Read and List for the Users group. The idea was given to me by answers to this question on Stack Overflow.

Composing XML in C# 2.0 or later

When testing some custom XML serialization I was writing for a project, I ran across a quirk of the XmlWriter created by XmlWriter#Create() : The writer that gets produced by this method doesn't actually write out XML to whatever stream or file you've given it in the Create method until Close() is called on the generated writer. This means that if you've been using the XmlWriter along with a using() statement, you're fine, but if you haven't been using it, as I have in the unit tests I've been trying to write, you're going to get some unexpected results. Something to pay attention to.

Generating XML objects from a schema in .NET

In my last job, I frequently made use of the JAXB library provided with the Java SDK for object de/serialization. I chose to generate my schemata from objects back then because I started off with the business objects and I knew how I wanted to serialize them to XML. Now I have the reverse situation, and I'm using a new language. As it turns out, generating classes from XML schema is dead easy : use the xsd.exe tool. It comes with .NET.

Staying on the ball

If you know me, then you've seen my analogy with two fists to staying on the ball. If not, just know that it's a great analogy. The real topic of this post is that as a software developer, during the course of your education (if you have one beyond high school) you can't help but have this one idea beaten into you: you have to stay current with trends in software development and you have to be on the ball with learning new tools to get the job done quicker, otherwise you will find yourself out of a job.

As I read through blogs, articles, newsfeeds, etc, I'm learning more and more how behind the times I really am. I think part of that is due to my education, ironically enough: there's enough out there that you need to know to be truly effective in the workplace that they can't possibly keep up in universities and colleges, which makes it all that much harder to get a really good job that's going to pay you a lot of money. As a result, you have to find a way to keep up and stay current on your own or risk being left behind in a heap of a job with shit for pay. I don't want to do the latter. It's with that in mind that I realize there are some buzzwords / buzztechnologies that I should at least be familiar with if not know intimately and use on a day-to-day basis:

1. .NET / C# / ASP.NET : There's an assload of jobs out there that use this rather than Java or any of the popular open-source technologies. And unless you go a technical institute, they don't teach you this; it's something you have to learn on your own. The need to learn .NET and other Microsoft technologies has recently been burnt into my own mind after I went for a job interview and they went with somebody else, not because I didn't know .NET (but could learn it very rapidly given my existing experience) but because they could get a technical institute (*cough* NAIT *cough*) grad with maybe a tenth the software development experience far cheaper than a university-educated developer.

<interlude>
My experience is mainly with free and open source (FOSS) technologies like Java, Spring, Hibernate, Javascript, XML, HTML etc with a fair bit of Ruby and some Perl / Python / BASH scripting thrown in. While certainly very interesting and academically stimulating areas of software development, they unfortunately don't look nearly as good on a resume as does Microsoft technologies, which a majority of companies are very much locked into.
</interlude>

2. XQuery, XML databases, XSLT, Atom/APP, XForms, AJAX: All XML related technologies, their goal is to make web development easier and make web-based applications more robust and usable. I think it's important I at least get familiar with these technologies, if not use them on a day-to-day basis for my projects at work.

<interlude2>
As somebody who's graduated from a Canadian university with a degree in Engineering, I have the chance (and desire) to get my PEng designation. However, due to certain restrictions of my local engineering association, I have to meet certain strict requirements with regard to the work that I do. Some of those restrictions include having to work on engineering-related software (ie essentially engineering software for other engineers and engineering projects).
</interlude2>

3. Embedded devices / Device drivers / System-level development: this is something that has long garnered my interest, but that I've never had the time to devote to learning. I'll especially need it if I'm to accomplish certain career objectives as mentioned above.

There's a number of other technologies / etc, whatever that I can go on about that I need to learn, but it's really too numerous to mention in a single blog post. I've enumerated three balls that I want to be on, and to accomplish that, I'm going to have to jump from ball to ball on a constant basis and hope I don't fall flat on my ass.