Jimmy Bogard Blog - Latest Comments

Re: The case against Interfaces in TDD

Robert — Thu, 23 May 2013 19:40:13 -0000

The title of your article doesn't match your articles. I want my five minutes back.

Re: Eventual consistency in REST APIs

jbogard — Wed, 22 May 2013 09:39:54 -0000

Isn't that the same as option 5?

Re: Eventual consistency in REST APIs

Srdjan — Wed, 22 May 2013 09:05:32 -0000

nice article Jimmy, as always.

I would add one more option though:

6) use modern databases that are consistent
For example:
HyperDex (http://hyperdex.org/consistenc...
NuoDb (http://www.nuodb.com/explore/s...
...

nothing wrong with that. :)

Re: Eventual consistency in REST APIs

AquaBirdConsult — Thu, 16 May 2013 21:06:05 -0000

I'm a long time RavenDB user, and with the latest versions (2.0) of RavenDB the indexing is so fast I doubt you would be able to query fast enough to hit a stale index (although it is possible). It is even harder to hit a stale index if you are doing basic map indexes. Map/Reduce indexes is where you might hit stale results. Another approach to keep your data from getting stale is to leverage RavenDB's Ids heavily, since loading a document using its Id is not bound to indexing.

User's don't realize wether you are serving them stale data or not, so I would probably ignore it in the case of Octopus deploy. I wonder what version he is using?

My choices would be Option 1 or Option 5. But I really do love RavenDB.

Re: Building forms for deep View Model graphs in ASP.NET MVC

Jalpesh Vadgama — Thu, 16 May 2013 09:19:24 -0000

good work!! I found what I was searching for.. Thanks for sharing!!

Re: Eventual consistency in REST APIs

Jonathan Oliver — Wed, 15 May 2013 23:43:10 -0000

I like option 2+3 the most: 202 on writes and "last modified" on reads. The last-modified information could even be returned as a response header (please use ISO 8601 for dates) rather than cluttering up the response body.

Re: Ditching two-phased commits

jbogard — Fri, 10 May 2013 09:30:11 -0000

Most queueing technologies provide acknowledgements that a message has been accepted (handling is a separate deal). That's why you have "at least once" supported by just about everyone.

Re: Ditching two-phased commits

Mark Allen — Fri, 10 May 2013 07:53:03 -0000

Ultimately, the question I'm trying to answer is without DTC, how are you assured that you are not losing messages, hence having to deal with none-or-at-least-once messaging rather than at-least-once messaging?

Re: Ditching two-phased commits

Mark Allen — Fri, 10 May 2013 07:13:30 -0000

Great post. We leverage NServiceBus quite heavily, and while we bask in the convenience of 2PC exactly-once messaging, we anticipate that as we scale this is going to break down due to performance issues.

So without DTC, how do you ensure that a message sent to a queue actually makes it? Is the Bus.Send basically an atomic operation, whereby if it succeeds then you are assured it has made it to the destination queue? I understand the notion of at-least-once messaging, but am nervous about the scenario where the sender thinks the message is delivered, but it actually never makes it to the intended target queue.

Re: Messages, data and types

Dale Anderson — Fri, 10 May 2013 03:54:40 -0000

I'm currently looking at using pure interfaces as message types. NServiceBus supports interfaces as messages, and JSON.NET combined with ImpromptuInterface works really well for wrapping interfaces around JSON. It allows you to compose your message schemas from many simple structures.

Requires a bit more exploration, but on the surface it seems like a really good compromise between the implicit / dynamic nature of JSON and the explicit nature of the CLR.

Re: Ditching two-phased commits

Dale Anderson — Thu, 09 May 2013 23:12:54 -0000

A good article. I've always kinda known 2PC is not worth worrying about, but you gave me a bit of an "aha" moment, that idempotence is the key.

Re: Ditching two-phased commits

jbogard — Thu, 09 May 2013 09:28:48 -0000

Nope, that's right. Maybe I needed more coffee when I was writing this!

Re: Ditching two-phased commits

Jonathan Oliver — Thu, 09 May 2013 08:31:39 -0000

Welcome to the new world. Things are more wild out here in this untamed land, but you have the freedom to do anything you want since throwing off the shackles of tyranny.

Re: Ditching two-phased commits

Viktor Nordling — Thu, 09 May 2013 06:58:21 -0000

I couldn't make sense of this sentence: "And since downstream systems can deal with at-least-once messages through our idempotency guarantees."

Should it be, "And since downstream systems can deal with at-least-once messages through our idempotency guarantees, we can always retry the operation if there is a failure down the stream.", or do I just need more coffee?

Re: Messages, data and types

Raymond — Thu, 09 May 2013 06:43:15 -0000

@Steve I use meta data "type" on my external events. Clients have to know the context of the information. How else would clients be able to process information correctly in their context?

Re: Messages, data and types

Steve — Mon, 06 May 2013 17:10:44 -0000

If you are using types as a blueprint for your messages that works great for the producer side of the equation. But what about the consumer? Won't you have to include some metadata on the message to give the consumer a hint as to how to interpret the message? I assume from the above that you would consider metadata regarding the type to be too leaky.

It seems that many .NET frameworks use the type not only for serialization at the producer and consumer, but for routing of the messages to the appropriate handler within a consumer (IHandle<t> or similar). It seems you wouldn't be able to do this type of routing w/o passing/sharing a hint as to the type that was encoded in the message?</t>

Re: Analyzing AutoMapper performance

jbogard — Sun, 05 May 2013 14:55:49 -0000

Just used JetBrains' dotTrace product.

Re: Analyzing AutoMapper performance

bayram — Sat, 04 May 2013 14:15:35 -0000

Which tool did you use to get performance reports?

Re: IKEA stand up desk: two months later

Cliff-Rich — Wed, 01 May 2013 13:19:41 -0000

A good anti-fatigue mat will go a long way. However, I'll take some sore feet over chronic back pain caused by an office chair any day. Here's mat option http://www.amazon.com/Standee-...

Re: Git workflows with git-tfs

Ag — Wed, 01 May 2013 11:31:08 -0000

is there any way to diff after "git tfs fetch"? how do you do that, git doesn't see tfs branches as remotes. And if there's no way, what's the use of "git tfs fetch"?

Re: Scaling NServiceBus Sagas

jbogard — Tue, 30 Apr 2013 21:28:08 -0000

Try deploying this. It's not automatic. The handlers are still in one class.

Re: Scaling NServiceBus Sagas

Tim — Tue, 30 Apr 2013 19:42:03 -0000

I try to think of a Saga as just like any handler for a type of message. If you follow NSB recommendations then you should one message type per queue. So you deploy an instance of a (saga) handler for each message type with its own input queue.

I guess that is what you mean by " to set this up ourselves".

Re: IKEA stand up desk: two months later

Caroline — Mon, 29 Apr 2013 23:30:41 -0000

I absolutely agree on the programmable memory. In fact, if you use them often as I do, you are really missing out if you don't have have this option. Its annoying having to adjust the height to your ergonomic position all the time. If you are doing that, you might as well go for a manual "hand crank" option: http://www.jpofficeworkstation...

Re: Why I’m done with Scrum

Arnis Lapsa — Mon, 29 Apr 2013 07:59:36 -0000

Software development is a fight against chaos. Software is direct reflection of what's happening in our minds just like as music is a reflection of musician's emotional state. Tricky part is that there's a feedback loop that triggers once you stop **thinking** which throws you into abyss of more chaos. And since software brings order, more things can be automated - thinking devalues and getting into chaos abyss gets more and more inevitable. "there is no one-size-fits-all for software process" is indeed a way to go - but repeating this statement is already a contradiction to itself. I see Scrum as a tranquilizer that creates illusion of rapid thinking for those that are aware that they don't - in some way that's just giving up.

Re: Saga alternatives – routing slips

jbogard — Fri, 26 Apr 2013 17:49:05 -0000

For that, you'd look at either a state machine or true "saga" pattern. That's next on my plate! For my routing slip handlers, I explicitly handle failures and indicate it on the attachments. Unfortunately I can't "cancel" an exception on failure, so it's just manual right now with the slip's attachments.