On Saturday 5th June, DDD South West was held at UWE Bristol. There are not many opportunities for a DDD event so it is always very busy. There were 6 tracks and 5 sessions in each track. A wide and diverse range of talks were given by dedicated speakers.
I started the day going to a session on the Task Parallel Library by Steve Strong. I had been looking into the TPL recently and thought this may be a good idea to go to to help me learn about it. There was an amazing amount of content that Steve tried to cover. I learned an awful lot and since then have implemented come concurrency in some of my applications. I recommend anyone to see Steve talk on this as he really does know his stuff.
I decided to attend the Alternative track for my next session. This track was a balloon debate on ORM vs SQL vs Entity Framework 4 vs NoSQL. Basically the speakers had to argue their corner in order not to be voted off the “balloon” by the attendees. First up, Eric Nelson from Microsoft to speak on Entity Framework 4. Liam Westley on traditional SQL. Steve Sanderson gave a well researched piece on NoSQL then finally Gary Short gave a very good overview of the use of ORM – it actually enlightened me to how wide a range of things that ORM’s can be used for
It then came to a session i was looking forward to, Crap Code and the Disasters it Causes by Phil Winstanley. I am very passionate about this subject so i was hoping that it would help me to improve the way i work. I wasn’t disappointed – Phil pointed out some truly awful code and sorted the code samples into the types of developers who made the errors. The one thing i took away from this session – I didn’t know you could put a GOTO inside a SWITCH statement [WTF???]
Grok talks were given over lunchtime – the ones of interest to me Cyclomatic Complexity and DotLess Css – i think ill make some future blog posts about these. Sorry to Silverlight 4 and BlogEngine.net but next time maybe :)
Code Contracts with Barry Carr was the next session. This was a truly heavy session to get my head around. I understood the concept of it – to make sure that the code does what it says it does and that the client will do what they says they will. But i couldn’t understand why you would do this as in massively overinflated the code base. I'm sure there are ways to do this and i will definitely be looking into this in the future as its a real extension of testing inputs and outputs [as well as lots of other stuff]
Last session of the day was CQRS with Neil Robbins. Bad start to the session of Neil as his laptop gave way and he had to borrow one to give the presentation. He gave an excellent talk on CQRS. It really made me see that the work im doing currently is very basic in comparison to this type of architecture. I didn’t understand this thoroughly but i think another talk or 2 on this [hopefully skillsmatter will come through for me on this :)] and i reckon i’d be very much taken by this
Overall a great day. I met a lot of people and there are others i really wished i had a chance to see or meet. Next time though. I shall definitely be at the next DDD event – talks are currently for Ireland on 25th Sept :) – and id recommend this to anyone.
Fingers crossed i get a chance to make some further posts on this :)
Tonight i seen, via Twitter, that it was potentially faster to iterate through a collection with a For loop rather than a For Each loop. I didn't believe this [being my usual sceptical self]. Therefore i thought i'd write some sample code to either support the theory and prove it right or to quash it.
static void GetIEnumberableResults()
{
//Small Method call in order to get an IEnumerable
//Then parse this IEnumerable firstly over a For Loop
//Then over a ForEach Loop - Each Method Returned a TimeSpan
var strings = GetStrings();
var forLoopElapsedTimespan = GetForLoopElapsed_ForStrings(strings);
var forEachLoopElapsedTimeSpan = GetForEachLoopElapsed_ForString(strings);
Console.WriteLine("Results For IEnumberable");
CreateResults(forLoopElapsedTimespan, forEachLoopElapsedTimeSpan);
Console.ReadLine();
}
I started with a simple IEnumberable<string> and iterated over this. I expected this to tell me that ForEach was faster than a For loop as this is what i was expecting. The results are below:
I was then told that the size of the collection being iterated over was a char[] of approx 65000. There was a challenge if ever i needed one. I created a char[] of a huge size [6
8000+] ad ran the same iteration over the array.
static void GetCharArrayResults()
{
//Small Method call in order to get char[] of size 68000 +
//Then parse this char[] firstly over a For Loop
//Then over a ForEach Loop - Each Method Returned a TimeSpan
var chars = GetChars();
var forLoopElapsed = GetForLoopElapsed_ForCharArray(chars);
var forEachLoopElapsed = GetForEachLoopElapsed_ForCharArray(chars);
Console.WriteLine(string.Format("Results for char[] of size {0}", chars.Length));
CreateResults(forLoopElapsed, forEachLoopElapsed);
Console.ReadLine();
}
Again i expected the ForEach loop to be faster. The results are below:
i have absolutely no idea what's causing this - so if any of you can let me know that would be fantastic. This has really brought out the proper geek in me :)
Very simple tip i found at DevEvening tonight from Mark Rendle
To create a new IEnumerable<string> and add items to that IEnumerable<string> then something very small along the lines of:
private static IEnumerable GetStrings()
{
yield return "a";
yield return "b";
yield return "c";
yield return "d";
yield return "e";
yield return "f";
yield return "g";
yield return "h";
yield return "i";
yield return "j";
yield return "k";
yield return "l";
yield return "m";
yield return "n";
}
I'm sure most of you knew this but it was never something i knew how to do. i usually ended up doing something along the lines of
private static IEnumerable ConvertListToIEnumberable()
{
var> listStrings = new List();
listStrings.Add("a");
listStrings.Add("b");
listStrings.Add("c");
listStrings.Add("d");
listStrings.Add("e");
IEnumerable ienumString = listStrings;
return ienumString;
}
Possibly useful to you, possibly not as you may already know it :)
There seems to be a misunderstanding between continuous integration (CI) and build automation. I was confused with this until recently when i looked deeper into the concept.
Build Automation: The process of automating a build process, on a nightly bases for example, as well as doing it manually when writing an application.
There tools that i use commonly for this are as follows:
Continuous Integration: This is the process of using “triggers” to listen to various events in order to perform some tasks. e.g. a developer checks into SVN CAUSING A TRIGGER to fire that will run a build of the solution and also will run the unit tests or automated acceptance tests.
The confusion seems to occur when CI tools are used for build automation but are not configured to use triggers to perform events
CI Tools:
TeamCity is not one i have used but it seems to be easier to configure tasks than CCNET as CCNET requires everything to be configured via huge XML files .
This is apparent in my current employment setup :
On a nightly basis we schedule CCNET to automate builds via NAnt scripts. These are performed via NAnt scheduling and NOT via triggers. These CCNET scripts are pretty awful as they require configuration without a UI.
This has lead me to understand now that i currently perform build automation and NOT continuous integration. I guess the next step for me now is to start to use TeamCity in order to understand CI better and potentially use it on a small project at work
Received some great feedback/ advice for this:
"There is confusion, I would advise people to get to grips with nant first and when they have the build script working then try cc.net after. Trying to do both together before you understand the theory and technology can be very confusing and strange."
Paul Thorrington