Posted on May 3, 2012, 1:31 pm, by Jimmy Bogard, under
Architecture.
Back in college, where I was an Electrical Engineering undergrad, I had an especially difficult professor for my microcontrollers course. In this course, we would hand-roll assembly language instructions and upload them to the 68HC12 testing board. (Side-note, I never, … Continue reading →
Posted on November 28, 2011, 5:05 pm, by Jimmy Bogard, under
Architecture.
In the last post on NServiceBus, I got quite a few comments that one way to fix the problem of dealing with non-transactional operations that must happen if some transaction succeeds is to simply move the non-transactional operation after the … Continue reading →
Posted on October 26, 2011, 1:17 pm, by Jimmy Bogard, under
Architecture.
I got a bit of a chuckle from Ayende’s post on time traveling emails. In it, he shows messages in his email inbox received out of order chronologically from when they actually occurred in the real world. That’s one of … Continue reading →
One item to keep in mind when investigating consuming or exposing REST APIs are the fallacies of distributed computing: The network is reliable. Latency is zero. Bandwidth is infinite. The network is secure. Topology doesn’t change. There is one administrator. … Continue reading →
Posted on April 22, 2011, 1:12 pm, by Jimmy Bogard, under
Architecture.
Ayende had a post on how to handle race conditions and unbounded result sets, describing a problem where you needed to perform transactional work against a set of entities. A bad solution would be: var subscriptions = session.Query<Subscription>().Where(s=>s.NextCharge < DateTime.Now); … Continue reading →
Posted on November 30, 2010, 1:53 pm, by bogardj, under
Architecture.
For the vast majority of systems I’ve been involved with, transaction isolation levels were never something I really had to worry about too much. The number of reads on these systems overwhelmingly outnumbered the number of writes. But ev…
Recently, we’ve started migrating our application to more of a message-based architecture. This will be part of a bigger series on migrating to a messaging-based architecture, but one rather funny (or not funny, since we were in production) sid…