Welcome to another "Weekly Concerns". This is a post-a-week series of interesting links, relevant to programming and programmers. You can check out previous Weekly Concerns posts in the archive.

• 5 Things You Should Stop Doing With jQuery. It's a sensational title, but read all the way to the end before you judge.
• PostSharp 3.2 Preview 2 is available, with improvements that help you write multi-threaded code (among other things).
• Direct casting vs "as" casting in C#
• Check out the new and improved WordPress Code Reference.

If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.

I've recently wrapped up work on a project, so I thought I'd share what I've learned, specifically in regards to Fluent Migrator (which I introduced in a previous post).

Mostly, it went pretty good, but there were a few bumps along the way, and a few things that still aren't as elegant as I'd like. As always, your mileage may vary.

1) Fluent Migrator and Entity Framework do okay together. I'm sure that Entity Framework Code First Migrations probably make a little more sense, but this project wasn't exactly using EF in a textbook fashion anyway.

2) Fluent Migrator works great with Octopus Deploy. But maybe not for rolling back. I've found that rolling back is typically something I only do when I'm developing. By the time I check in a migration, it's pretty much not getting rolled back, and certainly not by Octopus. There are a handful of migrations where a rollback doesn't really work anyway (how do you rollback making a varchar field bigger, for instance?) So, my thought with rollbacks is: do the best you can, don't worry if your rollbacks aren't perfect, and after the migration is committed and/or deployed, consider "rolling forward" instead of rolling back.

3) Fluent Migrator is great for tables. It is not so great with views/sprocs/functions/etc. I didn't really have a plan for these when I started. Fluent Migrator can use embedded script files--that's the direction I went with it. But I'm not terribly happy with it: seems like a lot of repetition and/or ambiguity.

4) Similarly, I didn't have a plan in place for dealing with test data or sprocs/views that use linked servers. I explored using profiles for these, but again, I'm not terribly pleased with the result. I think, generally, it would be nicer to avoid the views/sprocs as much as possible.

5) My strategy of creating a bunch of bat files is okay, but it would be really nice if there was some sort of little UI tool for running migrations. Something where I could select (or enter) a connection string, specify a couple of flags with dropdowns/checkboxes/etc, and a button to run the migration. I think this would be preferable to having to look up all the command line flags each time (which I did often enough to annoy me, but not often enough to commit them to memory) and/or save a whole bunch of batch file variations. Maybe a standalone WinForms app, or maybe a VS plugin.

I think one of the challenges with Fluent Migrator was demonstrating its value to the rest of the team at the beginning. It seemed like a lot of extra and/or unnecessary work and bookkeeping. However, once we got a build server and deployment server running, it really paid off. Deployments became much easier: there was no more asking around and trying to figure out which versions of the database were being put where. It was one less strain towards the end of each sprint.

Welcome to another "Weekly Concerns". This is a post-a-week series of interesting links, relevant to programming and programmers. You can check out previous Weekly Concerns posts in the archive.

• You're doing everything wrong (NSFW language). But are you really? Or are you just doing it different?
• Some free icons from GitHub.
• An infographic about new syntax in C# 6.0.
• Did I do this one already? Well I'll list it again, because I like it so much. A dress that contains all the most commons passwords on it.

If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.

Of all the blog post titles I'd like to write, "Parsing XML in ASP classic" is definitely not at the top of my list. But sometimes you just have to suck it up. So here we go...

Given a string that contains XML (maybe the result of an Ajax request or the contents of some config file), let's get some values out of it.

Here's some sample XML that I'll be using:

Create a MSXML2.DOMDocument.6.0 object. Use its LoadXML method. You can then use the selectSingleNode and XPath to get values out. For instance, if I wanted the value for ShoeSize in the above XML, I could use an XPath of //@ShoeSize to get a node. Then use the text property of that node to get the value.

There ya go. If you aren't an XPath whiz, you can use this XPath tester to help you through it.

Welcome to another "Weekly Concerns". This is a post-a-week series of interesting links, relevant to programming and programmers. You can check out previous Weekly Concerns posts in the archive.

• The EFF is trying to make emails to Congress more effective. Traditionally, hand-written letters have always been seen as more effective. Let's see if this has any effect.
• WatchMojo's Top 10 Business Killed by the Internet.
• 8-bit maps of cities.
• Some rants about potentially inflammatory words or phrases when talking about software, from Jeremy Miller

If you have an interesting link that you'd like to see in Weekly Concerns, leave a comment or contact me.