Travelling home after another fantastic DDD; an annual UK development community held at Microsoft Reading. A big thanks must go to all the organisers and speakers that have yet again made this a fantastic day.
Some of the topics were a bit techy so I am using this blog to attempt solidify the notes I made. If you see any mistakes or oversights please please please get back to me so I can rectify them.
I managed to cover Liam's talk and the basics of the other talks, I had planned to do more but I have been ill this week. I may try to fill it out with more details if I time this weekend, or if someone gets back to me with a suggestion.
Liam went through one of the headline new features that is coming in C# 5.0 (also in vb.net 5.0), which was announced at PDC 2010 last year. The New async keyword and its sister keyword await, are two new keywords in the language that simplify the way we perform asynchronous operations. In this world of multi-core processors and responsive handheld devices we need to be able to do several things at the same time more efficiently without making an accidental mistake that brings your code crashing down. Liam demonstrated the problem we face by offering three members of the audience hot drinks. If you want to do three things at the same time, (make three hot drinks), there is a temptation for a developer to start up three threads, the analogy Liam made was this is like getting three kettles out and making three hot drinks at the same time. Its not sensible, it uses too many resources and it will take you longer! Its better to do it in a more controlled way, but in c# 4.0 (and other languages) the extra code needed to achieve this will add extra lines to your code that muddies the water hiding the detail of what we want to achieve.
Async and Await are two words that we will use to manage the complexity better, enable use to boil hot water and make drinks quicker without hiding the complexity involved in asking people what drinks they want. The process of making three hot drinks is pretty simple so if we can describe it in a simple way but include markers to say how we are going to achieve this asynchronously we are onto a winner.
The two new keywords means we are able to write asynchronous code but it looks like single threaded code in your source file. By placing the Async and Await Keywords in the right places the dotnet compiler will take your essentially single threaded code and construct call backs in the right places at compilation!
Async – We use this keyword to mark a method, its a statement of intent to say we may be performing asynchronous operation.
Await – Await can only be used within a method that has already been marked with an Async keyword. If you place the word Async before you call a method you want to be run asynchronously the compiler will ensure the code that is after the keyword will be executed on a Callback without you having to write any extra code.
The code looks amazing but there appear to be a couple of gotchas:
- You have to be really careful not to use the word await in your method names, you need to check your naming conventions before you implement.
- A method marked with the async keyword can only return void, task or Task<TResult>
- The naming convention seems a little off, as await doesn’t wait. It is a request to continue running on a callback
- Exception handling looks a bit funky less than clear in some scenarios which could get confusing.
It looks fantastic, and I look forwards to using it but it almost needs a health warning because it so much easier to write asynchronous code, i can see that lots of people may start using the keywords everywhere. When they start getting weird exceptions they can’t fix there will be the temptation to swallow them. Obviously this can happen today in our current callback centric world, but there is a smallish barrier to entry. I’m looking forwards to seeing this in the framework, if the names will stick, and what if anything will change with the exceptions. If you want to look at this now you can grab the CTP here, but be warned its not compatible with MVC3 or VS2010 SP1. Liam mentioned that as this is a CTP we as developers have a chance to get back to MS to ask for features or changes we want to see in c# 5.
Mike Hadlow is one clever bloke, I got to the end of the talk and I wasn’t even sure if the questions I had were valid. I thought I knew what monads were by the end of the talk but looking at my notes its still not clear. In summary most developers probably shouldn’t care unless they are really interested in it. From what I understand monards are used all over the dotnet framework, LINQ, IEnumerable<T> by understanding the concept you will better understand what is going on under the seams. I need to see this again, and probably again and do some sample coding to get my head round it before I can put together a sensible overview.
But it does beg a bigger question, does the average developer need to know what a monad is? A developers job is to create software that solves a problem quickly and cheaply, it doesn’t really matter how this is done. It goes back to my previous post on what is Lean. The customer couldn’t care less if you know about monads, they don’t even want a piece of software, they just want there life to be easier/nicer. If knowing monads helps developers achieve this; great. Its one for my list of things to read about.
DRY stands for Do Not Repeat yourself. As a developer if you find yourself writing the same code, or even doing the same thing over and over again your doing something wrong. Mark Rendle showed us some ways we can use Functional Tricks to reduce the amount of code we write and reduce repetition. Mark made a great point that using an OO language is can be like using a Hammer to crack a nut, not everything is an object. Mark then went through some code, I especially liked the functional catch and the cached dictionary looked useful, although the lock looked a little dangerous for my liking.
Again in my mind software development is getting something done as quickly and as simply as possible, not having to write the same line of code over and over again is an advantage, and I loved the extra readability some of the sample code added.
Kind of, but it could be alot better. I loved this talk, Nathan took a pretty dodgy asp.net project which had inline SQL and transformed it into a thing of beauty. He showed how you can take any dotnet code and make it much better using SOLID principles.
SOLID is a set of principles about class design, they are principles to consider not rules to apply. Each letter of SOLID stands for a different concept which is designed to remove the nasty ‘Design Smells’ that infect code bases.
|Nasty Code Smells
||Nice SOLID Principle
- Rigidity – Cant Change
Fragility – one change will break other things
- Viscosity – changes are too much work, and a dirty hack is preferable
- Complexity – Makes it difficult to change in future
- Repetition – Waste of time writing the same thing over and over again
- No Opacity – lines are code are confusing, do different things
- Single Responsibility – Each object has a single responsibility
- Open/Closed – Software is open for extension closed for modification
Liskov substitution – objects can be swapped out for different reasons, ie testing, for different database back ends etc etc.
Interface Segregation – Lots of client interfaces are better rather than a single fat interface
Dependancy Inversion – Dependencies are turned on there head so objects are loosely coupled
After whistling through the concepts Nathan then dived into code taking a legacy application and applying each of the SOLID principles in turn to refactor the solution into a much cleaner, more testable manageable project. Nathan covered alot in this presentation and I was glad I took notes so I could look into it further when I got home. I’m looking forwards to going to the next talk that Nathan gives.
Unfortunately I made it to this session a little late, because I had got myself into a table tennis match on xbox kinect! Unfortunately as soon as I made it to the session I found that StyleCop is of no use to our business because it doesn’t support vb.net. A bit of a surprise as StyleCop is open source, might take a peek if I ever get any time!
I have recently implemented TeamCity in our organisation, CI is life changing. It fits in with the DRY principle, developers should be aiming to automate any repetitive tasks and for many organisations software Builds, Testing and Release take an inordinate length of time. Paul covered the basics of what CI is, how you should pick a CI and did a quick demo, a nice taster session for anyone who hasn't thought about CI. It didn’t cover anything really new for me but it was nice to see a different perspective., and I liked the presentation style. I was set next to a guy who got really interested and ended up giving him a link to my blog so he could take look at my beginning TeamCity blog series. I think this session interested alot of people; who just want to save time and .’. save money. The advantages to CI are clear, reduced risk, reduced bugs better testing, faster release, you can take it to another level it has even been joked on twitter that ideally your CI system should order you a pizza if you break a build