Monthly Archives: September 2012

SublimeText2 as Editor (1) Compile

I have been making a move to sublimetext2 in linux as my primary development environment. This series of posts will look at the editor and various tweaks and addons that are needed to get working with C# code. There are tons of tutorials about sublime online but none seem to cover setting up a C# environment. To start with let’s learn how to be able to compile code.

Go to tools->build->new build. A file will open. Drop in:

“cmd”: [“xbuild”],
“path”: “/opt/mono/bin/”,
“working_dir”: “${project_path:${folder}}”,
“file_regex”: “^ (.*)\\(([0-9]*),([0-9]*)”

Then save this file named xbuild.

Note I run mono trunk built from source which is why my prefix is /opt/mono. Now when you have a folder open for your project it will run xbuild in the root of that folder. This only works if there is only a single solution in the root folder. To build use ctrl+b or f7.

In the next post we will look at switching between code and basic navigation.

Cloud Computing Costs

I was going through setting up the event store on some amazon nodes for a blog post

I worked with a HIGH IO node which is stated to be

High I/O Quadruple Extra Large 60.5 GB memory, 35 EC2 Compute Units, 2 * 1024 GB of SSD-based local instance storage, 64-bit platform, 10 Gigabit Ethernet

In performance benchmarks it came out roughly the same as my zenbook ux21 laptop. Write latency was actually 20ms higher. Given it has 2TB of storage at that latency where as my laptop has 128mb but don’t forget that machines in the cloud are not really equivalent to physical hardware machines!

We Actually Build Stuff

Mentioned that I had more announcements to make. In all of my free time I decided to get together some speakers to do a small conference in Vilnius Nov 30th.

The initial speakers and sessions are up, more to be added later!

Rob Ashton
Johannes Brodwall
Udi Dahan
Sebastien Lambla
Jonathan Worthington
Greg Young

Hoping to see lots of people out!

We Actually Build Stuff

This Fall

Finished up with phase of the Event Store (Second Phase is Appliance first week of November!) and now have to get back to planning everything else so there will be a few announcements coming this week. The first is for some upcoming classes.

Sydney Australia Nov 19-21

Melbourne Australia Nov 28-Dec1

Update! Melbourne Australia Nov 12-14

Vilnius Lithuania Oct 24-27 (videoed class)

I may also do a class on the weekend in Australia if there is interest from people and I have to build up a one day introductory workshop to the Event Store so I will likely do a couple of those over the fall to get the material set (though not sure where).

I currently also have a few days left in the fall that I have availability if anyone wants to chat about them.

Oct 8-10

Nov 12-14

Dec 17-21

CQRS is not an Architecture

Just a quick posting from some conversations that were going around. CQRS is not an architecture.

CQRS can be called an architectural pattern. Just like Transaction Script is an architectural pattern. Event Sourcing is also an architectural pattern (it is also not an architecture or an architectural style).

CQRS and Event Sourcing are not architectural styles. Service Oriented Architecture, Event Driven Architecture are examples of architectural styles. They describe a system of systems (or a system of many components depending on how you express things). CQRS and Event Sourcing describe something inside a single system or component.

This is very important to understand most architectural patterns are not good to apply everywhere. If you see architectural patterns in an architectural guideline you probably have a problem (if you see an architectural style in a guideline its much safer). EG: To say “all components must use active record” = bad. To say “integration between components must be async and done through events” = no so bad. The largest failure I see from people using event sourcing is that they try to use it everywhere.

There is only one architecture. It is the one of the system you are talking about. It is its own set of trade offs and decisions that have been made. It is how it works.

When we talk about your architecture you could have SOA+EDA with ActiveRecord+CRUD in some places and Event Sourcing in others. Your system is unique, you system has its own architecture.

Agile Process

Cutcaster photo 100202812 Frustrated woman with incompetent mechanic in backgroundI was out at Agile Prague earlier this week. There were many great presentations on building up better processes and a particularly interesting one by Linda Rising on the introduction of agile into organizations. However in talking with many of the people during breaks and dinners etc especially attendees I noticed different problems that people were having in real life.

They had the wrong people

No amount of process will fix this problem. If I take a bunch of people that don’t know how to actually produce decent code that works my process won’t fix it. They can’t actually build the wrong thing let alone the right thing if they can figure it out. I might be able to get away with teaching them to actually produce but now I have bigger issues. Can you imagine if you had to teach your mechanic how to change your oil so that he could actually change yours?

Its feasible to train such a team but it will be very expensive and time consuming, this should only be done in the worst case where other options are politically unavailable for some reasons (yes government sector I’m looking at you)

If a team is unable to produce instead of attempting to introduce small incremental changes. Consider making really big changes (like getting rid of a large portion of the team).

I think we should really at conferences be spending more time talking about big changes and how to know when to use them. We should also spend more time talking about how to build a team of the right people. I know this is not as interesting of a topic but it seems there are many more people with this issue than those in cases where they have a well executing team that they want to improve.