One of the things that I've always liked to have on my blogs over the years is a "latest comments" widget. I like to leave all my blog posts open for comment indefinitely, and this gives users a way to see the latest comments, even if they are on very old blog posts.

Disqus doesn't have a "drop-in" JavaScript snippet to do this, but Disqus does have an extensive HTTP API that allowed me to build my own.

The terminoloy that Disqus uses was a little confusing for me, but by reading some of the docs and trying a few tests in Fiddler, I was able to see that the forums/listPosts API endpoint was the one I wanted. You'll need to make sure that you have a public key generated in order to use the endpoint. Here's the widget I wrote:

Some notes:

  • Disqus rate limits you to 1000/requests per hour. For my blog, that's probably more than enough.
  • This script depends on jQuery, but you can use something else for your DOM manipulation, even plain JavaScript if that's your jam.
  • I was at least partially inspired by Raymond Camden blogging about something similar.

Joining Couchbase

April 22, 2016 mgroves 0 Comments
Tags: personal career

Short version: My new job title is Developer Advocate, and I am working for Couchbase.

Long version: Being a developer advocate / developer evangelist is something that I've been considering for a long time. I've enjoyed speaking, blogging, writing, screencasting, teaching, helping, networking for a while now. But until now, I had always done these things only in my spare time. The thought of making those activities into my full time job appealed to me. But, there are a lot of developer advocate positions out there, and most of them don't appeal to me, because the product or the company doesn't appeal to me. The few times I managed to get interviews with really awesome companies with great products, it didn't work out, and I thought that maybe it wasn't meant to be.

But I'm very excited to announce that I finally found a DA opening with a great company with a cool product (a NoSQL database company based in Silicon Valley!).

I've done a lot of thinking this year about my career, and what direction I want to go. I've been a coder for my entire career. Some of the best parts of being a coder is sharing knowledge with other coders: teaching, writing, and expanding my own knowledge in the process. As much as I enjoyed working for my previous employer, they make a product that isn't developer-facing, and therefore a developer advocate position just wasn't going to happen for me there.

I'm ready to begin a new chapter, and I'm looking forward to reaching out to developers and helping to build the Couchbase community.

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.

Leaving Heuristic Solutions

April 19, 2016 mgroves 0 Comments
Tags: personal career

After working at Heuristic Solutions for 2 years, I've decided to take my career in a new direction.

I started at Heuristic Solutions with big plans and big expectations (both from myself and from others). Things did not pan out as well as I hoped, due to a combination of factors, both professional and personal. But, I made the transition from consultant to the LearningBuilder product team, and that's where I've spent most of my time while employed there. It's been an immense and enriching challenge working on a very complex piece of software; perhaps the most complex (in a good way) piece of software I've ever had the honor to work on. Sure, it's not perfect, no code base is, but it has consistently provided a canvas to apply and grow my skills as a developer.

Everyone I've worked with, and especially the Central Ohio-based members of the product team, I highly recommend to anyone seeking out a team that works hard, thinks hard, and cares about what they're building and how they're building it.

So, you might be asking, if it's so great, why are you leaving? Well, I think that will be clear in the next blog post. In the meantime, it just remains for me to thank:

  • Seth - for being a great technical leader, and for originally recruiting me to join Heuristics
  • Calvin - for pairing with me over the last 2 years, and coding circles around me while doing it (bada bing bada boom)
  • Brian - for helping to beat me into shape as a QA lead and playing those bongos congas so well (I hope you get that island in the sun)
  • Michael - for hanging out with me and becoming an excellent coder, and automater of everything
  • Scott - for always answering the call, pushing the technology limits, and just being there in the consulting trenches at the beginning
  • Sara - for being a passionate UX and UI whiz, and for talking Star Wars (I've stlil not met her in person but would like to!)
  • Glen - for allowing me to open up on a personal level, and providing much-needed guidance
  • Christopher and Ali - for being generous, kind, and fair
  • Steve, Tom, Robert, and the rest - for helping me whenever I needed it, and for your hard work accomodating customers and building relationships

A special thanks goes out to:

  • Gate 35X
  • No Winning
  • Kuli Loach
  • A closet-sized office

Thanks for reading, and stay tuned for what's next.

RabbitMQ is a "message broker". Your program gives it messages. Other programs can come along and retrieve those messages and then do something with them. It sits in the middle, so it's often referred to as "middleware".

Why would you want a middleman? Haven't a lifetime of mattress commercials shown that cutting out the middleman is always better?

Not always. Let's build an online store that takes orders and has to tell a warehouse to process the order. Consider these three designs:

  1. Your website does the work itself.
  2. Your website passes a message to another program directly.
  3. Your website passes a message to a broker. Another program picks up messages from the broker.

These are the questions I asked, and below are the conclusions I've come to. If I'm missing anything, please add to the discussion in the comments.

#1 Your website does the work itself

A customer places an order. Since your website is doing all the work itself, it has to: email the customer, charge a credit card, and tell the warehouse to ship the item. What if the warehouse doesn't have the item? Now you have to check another warehouse. While your website is doing this, it has fewer resources available to process other customer's browsing and ordering. So it could become a performance problem as well as a complexity problem. Instead...

#2 Your website passes a message to another program directly.

Let's just tell a warehouse program to do the work, and the website will go about its business. The warehouse program can figure out which warehouse, and send the appropriate information. If it has a web service, we can just push the information. But what if something goes wrong? What if the service is down, or busy, or overloaded? Now we need to build in a retrying mechanism into our website, and we're still managing complexity and putting strain on the website. But what if...

#3 Your website passes a message to a broker. Another program picks up messages from the broker.

Our website just records all the information that the warehouse needs to a message. That message goes on the broker and waits. Once the website dumps the message, it's done, and can go about serving other customers. The warehouse program can ask the broker for messages. It gets a message, does the processing. If it goes well, then the broker can forget the message. If something goes wrong, it's up to the warehouse program to figure out what to do. It could keep retrying, send an email, call a web service, or whatever else you need. If the warehouse program gets overloaded, you can spin up another warehouse program that talks to the same broker. If the warehouse programs crash, the messages will wait on the broker.

It might seem that the middleman's job is very simple, it's very important to ensure that complex operations can be broken down and processed smoothly.

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