David Ruttka

I make computers do things

Little Wonders: Alt+Space, E, P

| Comments

This is why we pair! – Me, many times

Another one. These things are so simple, but they’re only useful if you know they exist. I’ve been planning a post that covers my thoughts on pairing, but (spoiler alert!) this kind of little stuff is one of the great benefits.

I had to reimage a machine, so my console hotkeys are not all the same as they used to be. I usually remap Ctrl+V to paste, since that is consistent with most apps in the Windows ecosystem. Until I do so, it’s Right Click > Edit > Paste.

I was telling Patrick how I love to stay at the keyboard and eschew the mouse as much as possible, and he pointed out that I could just do Alt+EnterSpace*, E, P. This isn’t quite as short as the Ctrl+V remapping, but it works out of the box. I like it!

* Thanks to Michael for noticing that I had this correct in the title, but typed the wrong content in the body.

Little Wonders: Uri.GetLeftPart

| Comments

File another one under learning something new everyday. Patrick was asking me what the best way is to get the scheme + host + port of a Uri in .NET. We discussed a few ways that we’ve done it in the past, but agreed that there must be a better way.

Behold, Uri.GetLeftPart! This will give you everything up to and including the part you want.

Given a new Uri(http://somewhere.com:8080/this/is/path?andQuery#fragment), calling GetLeftPart(UriPartial.Authority) will give you back http://somewhere.com:8080. You can also use Scheme, Path, and Query. There’s a table showing what comes back at each part in the MSDN documentation.

It sure beats the string manipulations I’ve done in the past!

Communication Protip: Be Specific

| Comments

The other day, I says to Michael, I says

We suck so much at communication. Not you and me. I mean, I am including myself, but I mean ‘we’ in the universal human sense.

Today, I sucked again, and I am able to see exactly where I went wrong.

Be Specific

If you have multiple environments being used for development purposes, don’t talk about making updates to “dev.” This is going to confuse people about whether you meant hacky-dev-builds.fancycloud.net or slightly-more-stable-dev.yourdomain.com.

Refer to the environment by something more unique like the URI, and don’t leave room for doubt about exactly what changes you made.

Don’t do this:

I just deployed the latest bits to dev.

Do this instead:

I just deployed to endpoint.host.tld. The changes included in this deployment since the last deployment are X, Y, and Z. [Actions people would need to take because of these changes]?.

Principles of Debugging: A Postmortem

| Comments

The following is a combination horror story and true crime documentary of developers tricking themselves into seeing things that aren’t there, not seeing things right in front of their faces, and breaking various rules of debugging. The faint of heart should close the browser tab now.

No, it’s not a Heisenbug. Heisenbugs don’t repro the same when you’re looking into them. This is…something else. – Actual quote

Wont-Fix

There’s one part of this story that I will not address. We have to use 64-bit integers (C# long) for the ids of one of our resources due to downstream / legacy dependencies. They end up being incredibly large, non-sequential values. That’s not the point here, just some context.

A Problem Is Reported

INT. A developer’s desk, early morning, before coffee, bright blue sunny day.

An email is received reporting an issue where the ids of certain resources are intermittently being returned as two less than the true value. Or one less. Or one or two above. Always “close”, but often incorrect.

There is a Fiddler .saz to prove it, and screenshots of that same Fiddler .saz.

A fearless developer figures this must be something pretty silly, opens up the issue in the issue tracking system, and decides to take it on. There will be much weeping.

Violating All the Principles of Debugging: A Postmortem

| Comments

The following is a combination horror story and true crime documentary of developers tricking themselves into seeing things that aren’t there, not seeing things right in front of their faces, and breaking various rules of debugging. The faint of heart should close the browser tab now.

Wont-Fix

There’s one part of this story that I just will not address. We have to use 64-bit integers (C# long) for the ids of one of our resources due to downstream / legacy dependencies. They end up being incredibly large, non-sequential values. That’s not the point here, just some context.

A Problem Is Reported

INT. A developer’s desk, early morning, before coffee, bright blue sunny day.

An email is received reporting an issue where the ids of certain resources are intermittently being returned as two less than the true value. Or one less. Or one or two above. Always “close”, but often incorrect.

There is a Fiddler .saz to prove it, and screenshots of that same Fiddler .saz.

A fearless developer figures this must be something pretty silly, opens up the issue in the issue tracking system, and decides to take it on. There will be much weeping.

The Plot Thickens

INT. The same developer’s desk. Plus another developer to pair.

The developer has traced through the entire command side of the CQRS system and confirmed that the ID is not strangely mutated before publishing an event to the bus.

Also traced through the read model updaters to ensure no strange mutations occur there.

Queried the read model store directly. Data is correct at rest. It’s got to be in the query side or API itself.

We have some message handlers that fire late in the pipeline, just before the response stream is written. The original dev has set breakpoints there and confirmed the ID is correct before it goes out the door.

Yet, Fiddler keeps showing that odd ids always become even. Even ids always stay even, but sometimes go up or down by two.

And then, on a whim, add Accept: text/xml to the Fiddler composer instead of taking the default json.

It’s correct in the XML.

Wat

INT. Kitchenette. Coffee. Sanity beginning to fray.

That Annoying BAMB BAMB Sound From Law and Order

INT. The same developer’s desk. Plus another. Total of three developers.

The third developer runs through a lot of what we’ve already done, just to make sure we didn’t miss something silly.

It’s only happening to json. Could it be in the serializer? The message formatter? What is going on?

File > New Project. Eliminate all of our code from this and spin up a barebones project. F5 and see the correct values displayed in the browser. Do we have a different version of the json serializer package? A different version of our web api framework package? What else is in the pipeline for json and not for xml?

Lunch

EXT. Beautiful, bright blue day. Sunny. Warm. The opposite of the cold grey oppression of this bug.

Walk to lunch, eat lunch, decide to work from a coffee shop and wrap our heads around this thing.

Frayed Ends of Sanity

EXT. Outdoor tables at local cafe.

We create more reductions. The json serializer and message formatters seem fine, but we still aren’t sure what else is in the pipeline. We start mutating the data store to different ids to attempt to establish a pattern.

We find that id = 7 stays 7, even though it’s odd. Just the big ones go off.

We write a quick script to create 1000 resources with sequential ids starting with one of the large problem ids. Then we request each of them through our API and dump the id we expect, and the id the API gave us. They all match. None are wrong. This was in C#.

But Fiddler is showing the wrong id, even when C# is showing the rig—–

Derp

The raw tab of Fiddler always had the correct id. It was the json tab that looked incorrect. The json tab that you know, handles numbers the way JavaScript handles numbers.

We saw even/odd, but we didn’t see that they were all, for example, multiples of four.

When we started a new Web API project from scratch, we viewed those responses in a browser instead of in Fiddler. We changed all the things at once, including what we used to view the output.

Debug It!

A few years ago, I read this book and recommended it to everyone I worked with. As I look at what we went through in this story, I see that we held fast to some of the principles for good debugging, but got caught out on a couple others.

What Went Well

  • We had good evidence of the problem and quickly established a scenario to reproduce the problem
  • We eliminated the command side, event bus, and read models very quickly. This let us isolate the problem to the response pipeline.
  • We further isolated it to only the json output, further supporting the case that our commands and queries were not the cause of mutation.

Lessons Learned Things We Knew Better But WTH Were We Doing

  • Fiddler is a great tool, but it isn’t showing you the raw response unless you’re actually looking at the raw tab
  • We narrowed the issue down to “the response pipeline” and excluded tools used to view the output after the response was delivered.
  • The prime directive to turn only one knob at a time includes what you’re using to view output. If this had been a CSS thing, we certainly would have counted different browsers as knobs we were turning. Here, we tricked ourselves into thinking the raw text response in the browser was the same as the json tab in Fiddler.
  • JavaScript can’t go full 64-bit on integers. All numbers are 64-bit floating point numbers, so the max “long” is 253.

Fixing the External-url (Linklog) Feature in Octopress

| Comments

The Linklog Feature

Another quick edit that I made to in the theme was to handle the external-url for linklog posts, as described in the Octopress docs.

I found that this feature wasn’t working for me. I couldn’t find anyplace that attempted to use external-url, so I just kind of decided on a place that works for me and put it there.

Show Me The Code

You can check out the pull request or the commit it contains. I cleaned up the unintentional whitespace changes in the follow-up commit.

Basically, I just added a capture for entryhref, using the external_url if present. Later, after the line that handles adding the Comments link as appropriate, I added a line that adds the Permalink as appropriate.

I’m still finding my way around Octopress and am definitely open to thoughts if I’m going about this stuff the wrong way. Let me know.

Updating Octopress to Override the Canonical Rel Link

| Comments

As I’ve continued iterating on the PowerShell script that I’m using to migrate my old WordPress posts, I decided to point the canonical link to the old location. I might choose not to do this once I have a full migration story (redirection of the old permalinks, etc.), but as long as the original location is still up I figure those posts should keep any link juice they have.

So, I can now do this in the yaml on top of a post

1
canonical: http://thedevstop.wordpress.com/whatever

And the generated post will come out with that in the canonical link, instead of the url for the www.davidruttka.com clone.

1
<link rel="canonical" href="http://thedevstop.wordpress.com/whatever" />

All it took was a quick edit to the existing capture in the head.html include. The change is the if page.canonical block, and the full line ends up looking like this:

I’ve opened an issue to discuss whether this is something anyone else would ever use. If it is, it should be a simple enough thing to incorporate. I’ve also sent a pull request for the issue, but derped something up and they didn’t get associated.

Later tonight, or tomorrow, I’ll also share what I did to fix the linklog, external_url feature for my instance.

Exposing Additional Headers in CORS Responses Using the EnableCorsAttribute

| Comments

File under “Learn something new every day.”

Long story short, we have enabled CORS in our API, but today I learned that not all headers are included.

Particularly, like Aaron, we needed to ensure that the Location header came back when a POST request created a new resource. Our solution is a bit different than his. We’re already using the EnableCorsAttribute, so Rob pointed out that we can just do this:

1
EnableCorsAttribute("*", "*", "*", "location");

Like the other constructor arguments, that last can be a comma separated list. Looks legit!