Skip to main content

Posts tagged with 'or'

Vance Feldman is a developer and an artist who faced technical challenges when bringing his ForeverScape artwork to mobile devices.

Show notes:

If you're interested in Henry Darger, check out this clip from NPR's All Things Considered. If you're interested in SuperJail, you can watch it on Adult Swim.

Want to be on the next episode? You can! All you need is the willingness to talk about something technical.

Theme music is "Crosscutting Concerns" by The Dirty Truckers, check out their music on Amazon or iTunes.

Because Akismet has been letting me down recently on this site, I've decided to 'outsource' the commenting and spam checking to Disqus.

Installing Disqus is a piece of cake. You sign up and drop some JavaScript onto your site. Even the "# comments" that you see near the top of this post is taken care of by just pasting some JS.

But there are two things that I would potentially lose that I was concerned about:

  1. My "legacy" comments
  2. My Latest Comments widget (which I'll cover in part 2)

If I were migrating from WordPress or some other well-known blog software, it would have been really easy. WordPress->export, Disqus->import.

However, this site runs on my own home-grown blog engine (for better or for worse). I could have just left my legacy comments alone, and let them exist side-by-side on older blog posts. I called that "plan B".

But once I knew that I could import from other engines, well, I assumed there must be a way for me to "fake" it. It was a little bit of work, and it still might not be perfect, but it worked.

I researched the formats that Disqus can handle. One of them is the WordPress WXR format, which is based on RSS, which is based on XML. So, all I had to do was figure out how to generate the right XML. There isn't really a "spec" on the WXR, at least not one that I could find. Luckily, Disqus publishes specs for their own Custom XML Import Format, which is a version of WXR. Once I had that, it was a piece of cake to create an "Export to WXR" button on this very site. Here's roughly what it looks like in an MVC Razor View:

Some notes:

  • I used generated Guids for the comment_id. I'm not sure if it makes any difference from an import perspective, other than they should probably be unique.
  • I put both comment_date and comment_date_gmt. I don't believe that comment_date is actually used, but I put them both in there just in case.
  • Notice the <![CDATA[ ... ]]> within the comment_content. The CDATA is a way to encode data within XML tags that an XML parser might otherwise attempt to interpret.
  • The BlogPostName is the friendly English version (e.g. "I like balloons"). The BlogPostSlug is the URL-friendly version (e.g. "I-like-balloons").
  • I used Html.Raw because otherwise Razor seemed to have trouble parsing what I was generating. I'm not worried about any sort of DOM injection, since this export utility is behind auth. But generally, you should be wary of using Html.Raw in Razor

To import, I just saved the output of this view, and went to Disqus Import, and uploaded the file. It goes into a processing queue, and the time it takes with vary depending on how many comments you are importing and (I assume) how many other workloads that Disqus is trying to process. I imported 86 comments multiple times, and it generally took about 5 minutes at most.

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.

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

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.

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.

Matthew D. Groves

About the Author

Matthew D. Groves lives in Central Ohio. He works remotely, loves to code, and is a Microsoft MVP.

Latest Comments

Twitter