Apologies in advance if the title is totally unoriginal.

Nathaniel Jones recently posted a blog on his experiences with Azure. Unfortunately he had a pretty bad experience.

I checked, and all of my azure sites were down. I logged into the portal, and discovered that all of my databases, backups, instances, and websites had been terminated and deleted. There was nothing left. In fact, everything had been deleted at midnight, 8 hours prior to the first (and only) notification of the action taken.

All too often, security is treated as an afterthought in our models. I’m as guilty of this as anyone. :) Now that HTTP is becoming the most popular protocol inside the enterprise, sending bad data across the wire becomes much easier. A hidden input field is not all that hidden.

Let’s take everyone’s second favorite fake business problem: Enrolling Students in Classes. Let’s take it further and say we want to develop this as a SaaS product. It’ll need to be a multi tenant application. There are lots of independent community colleges (Institutions) out there and we don’t want to run a VM or process per Institution.

Recently a question came up in the CQRS chatroom on Jabbr: 

Here’s the situation. New command comes in, They can sometimes be missing some info (for daft reasons), if it is missing info then I need to call off to an external api to get the info back. This external api is unreliable so it would be better to supply the information upfront if possible.

There are a couple of ways to do this.

I’ve been taking a bit of a coding vacation. Before I jump back into things, I decided to do a little housekeeping and clean the cobwebs from my interwebs. Specifically, reducing the level of annoying coming out of Facebook.

Look at this nonsense right here:

Wow, what a great user experience! Having to un-check 60-odd check-boxes individually is just great. I’m sure the team of 15 out of 1,000 Facebook engineers that built this page thought this was really clever. We’re using javascript to enhance the page! Weeeee!

The fastest information can ever travel is 3*10^8 m/s - in a vacuum. It’s 2/3rds that in a copper wire. In the ideal case.

Imagine two observers in the milky way galaxy, one at Terminus and the other at Star’s End. They will observe events from all over the universe at different times - they will not agree on the order of events. What they can agree on is that eventually they will see all of them.

Word on the street is value objects have been getting the short stick in DDD ORMS. That’s too bad. Value objects should be first class citizens because like aggregates their role is to enforce invariants. e.g.

DateTime.Parse("NOPE") // <-- nope
DateTime.TryParse("NOPE", out date) // <-- still nope

What about something like an address? Is a part of your core domain ‘validate this address?’ Or can you delegate to a generic domain, and implement with SmartyStreets or Melissa Data? These are economic decisions. I imagine you can present their price calculator and your own estimate to the man and see what she says.

We’ve all built applications that look like this:

There’s a bit of a problem here. What does Exception Reporting have to do with Validation? Or the Home Page? Mostly nothing, other than these classes perform the same kind of function.

Wouldn’t it be easier to organize everything by feature instead? Views, View Models, scripts, stylesheets, everything?

This is my second attempt. :)

About a year ago I made an attempt to wire Nancy together with RavenDB and failed miserably. Needed a break from businessy coding last night so I decided to work on something fun instead.

The ability to see what’s going on in your application is so important when it comes to performance tuning. Yes, there’s that old adage about premature optimization. IMO this phrase is taken out of context. To me 97% of the time means 97% of the code in your face, which is doing stuff in memory. The other 3% of your code is doing I/O of some sort. Minimizing the use of I/O will provide the biggest performance gains for most applications.

Sage advice. I almost made a huge mistake this sprint, but thankfully caught it because I had one last conversation with the domain expert before I deployed anything.

As we’re using eventing / event sourcing this would have been bad as events are immutable. You can always fix bugs later but that is just more code to write which can introduce more bugs and… you get the picture.

Sometimes our model can’t be as pure as the driven snow. Sometimes we have to use a really crappy external model because replacing it outright would be too expensive. Typically we deal with this in our tests with some kind of mocking framework.

Example,we have a use case for ‘creating’ an item in the ERP system. Of course in real life nothing ever gets ‘created.’ Instead our inventory items are ‘created’ upstream in the product development context. Once the product has reached a certain point of development, they are released to manufacturing. They must go into the ERP system which is where purchase orders originate.