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.

• I've been exploring the Command/Query Objects pattern, specifically with the idea of replacing the repository pattern. I've started with Dustin's Brown post about Command/Query Objects with Dapper.
• How to setup Twitter Cards for your site (specifically WordPress, but blog post is helpful for everyone else too).
• Rob Gibbens posted about using Fody.PropertyChanged (an AOP plugin to the Fody IL rewriting framework) with Xamarin to use the MVVM pattern.
• EconTalk is one of my favorite podcasts. Check out this episode about the "sharing economy", in which they discuss the impact of technology like Uber, AirBnb, and so on, featuring my favorite guest: Michael Munger. Especially interesting to me is the discussion about taxi medallion investments.

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.

I took a long break from ORMs in my career: about 4 years. I was working on a reporting product, and an ORM is just the wrong tool for that. Before that, I worked with ORMs here and there: NHibernate and another ORM I don't even want to mention by name for fear of being associated with it in public. For some of my own projects like the next version of EZRep and this very blog site, I've switched to a so-called micro-ORM, specifically Dapper.

Now that I'm back to consulting, I'm back into the ORM game. This time, it's Entity Framework. Early in this project (that uses EF), I've been experiencing quite a bit of frustration. It seems like I'm swimming upstream while jumping through hoops to accomplish really simple things that wouldn't take nearly as much work in Dapper. Maybe this is just me getting back into the habit, but it's also got me thinking: why do I really need a "full" ORM anymore? Abstraction and indirection are important tools, but perhaps full ORMs aren't the least leaky abstraction anymore in many cases?

Yes, a full ORM is sometimes RTRJ. However, I think micro ORMs (Dapper, PetaPoco, Massive) and document databases (Raven, Couch, Mongo) have taken a big bite out of the pool of possible use cases, and that a lot of full ORM and/or RDBMS usage in projects is really used not because it's the best tool, but because of the sheer momentum of the status quo. Imagine a snapshot of a Venn diagram taken 5 or 10 years ago compared to one I made up to represent a snapshot of today.

There might be missing bubbles like "RDBMS + no ORM" or "Json string in text file", and the exact proportions are open to interpretation. But the point I'm trying to make is this: the number of use cases that are best served by RDBMS + full ORM is shrinking, and will continue to shrink.

Based on a Twitter conversation with Seth Petry-Johnson about mocking/faking SqlException objects in .NET, I decided to go ahead and put what I had written into an open-source project on GitHub. I didn't spend much time on the name: I thought about Sharp Stick and Pointy Stick, but those repo names have already been taken! So, I thought about "stick" some more and remembered the famous line from Lady Macbeth: "screw your courage to the sticking place". Well, I guess I don't have much of a future in professional naming.

Since I was creating a repo anyway, I thought I'd throw a couple of other helpers in there. I put in some of my favorite ASP.NET / ASP.NET MVC helpers and an obscure little string helper. I'm not trying to remake PGK Extensions or anything--just putting some stuff out there that might help someone.

I should also note that the SqlExceptionHelper stuff isn't entirely original: I borrowed some code from a 2006 blog post by Rido, and just updated the reflection code since the private constructor has changed since then (and could possibly change again, since it's a private constructor in a sealed class).

Anyway, go check out Sticking Place on GitHub and let me know what you think.

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.

• Why Your Previous Developer was Terrible - I tend to lash out emotionally when I see bad code, but I always feel uncomfortable blaming the previous developer, since I have no idea what kind of constraints (personally and professionally) they were working under. It's not always possible, but I try my best to seperate the art from the artist (and the code from the coder).
• Learn CSS Layout is an interesting CSS tutorial, that kinda reminds me of the various koans and git immersion types of tutorial sites.
• Did you see that "Everything from a 1991 Radio Shack ad is now done on your phone" thing making the rounds recently? Here's another analysis of technology costs then and now. Very roughly, the equivalent technology is not the $3000 nominal price in the Radio Shack ad, but at least $3.56 million.
• In MySQL, there's a sometimes handy GROUP_CONCAT function built in. Pete Shearer shows a way to accomplish something similar using FOR XML PATH and Microsoft SQL.

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