Not really what I had expected based on the title alone...

After introducing functional programming as a language with first class functions (can be created during execution, passed/returned etc), immutability, lazy evaluation, recursion and pattern matching Mark proceeded to demo 'Transformational' instead of imperative thinking using the linq implementations of a variety of 'functional' principles: Map = Select, Filter = Where, Reduce ≅ Sum.

Usage of such extensions on IEnuemerable allow code to be more declarative - with the statement of the desired result being specified as opposed to the exact process to undertake.

Although Mark did make some good points in reference to realising linq can easily lead to duplication (reminding me of jquery selectors being used multiple times because they look small, irrespective of the actual work they are doing), the content generally had a low difficulty level feeling (which could have been enhanced perhaps by focusing more on the design patterns content that was briefly touched on), with a chunk of the questions at the end critiquing the examples rather than drilling down into the subject.

Probably my favourite talk of the day Andrea gave an excellent fast paced intro to Unit Testing using Xunit and Moq. With the example of testing an OrderService we saw how to use consistent, verbose naming of tests for clarity/ease of use and were reminded that a unit really does mean a small unit. For example multiple tests of the save method of OrderService were used to illustrate a first simple 'does not throw' test, through using a stub of an invalid object to check the 'if not valid return false' nature of save to using a mock of an email sender to check that a 'send email' call is sent.

By using mocks and stubs the testing of the order service is contained only to the logic within the service and not to any of it's dependencies - any repository related aspects should be tested separately.

The phase 'be super paranoid about your tests' enforced the idea that test code is no smaller matter than production code, and if anything should be treated even more thoroughly.

A general rule given was that behaviour tests end in a Verify on Mock whereas state tests end in an Assert and that tests follow an Arrange, Action, Assert (or verify) flow. The final golden rules were: tests should not involve conditionals, should not depend on other tests and should not assess multiple expectations.

Although pointed to during the talk it would be interesting to hear more about unit testing in the context of Test Driven Development.

Having previously seen Jon Skeet recreate linq to objects in 60mins this was undoubtedly going to be a good session.

Jon covered the main 'newness' coming in C#4.0

Optional parameters

As in VB C# can now provide optional parameters with default values (referencing libraries will need a rebuild if the optional parameters are changed as they are copied in - similar to consts)

Named arguments

Arguments can now be named allowing the order to not matter - playing nicely with multiple optional parameters

Generic variance (interfaces and delegates only - reference not value types)

Co-Variance: Specific to general - used when returning out (IList<Circle> assigned to IEnumerable<IShape>)

Contra-Variance: General to specific - used when sending in (IComparer<IShape> used as IComparer<Circle>)

Dynamic typing (implemented as a library on top of CLR)

Variables can be statically typed as 'dynamic' and then have properties added using dot syntax

Better COM interop

The combination of named optional parameters and dynamic objects makes COM a lot less painful.

As with most developers I have been concerned by the use of ORM's such as Linq2Sql and EF in terms of the 'auto generated' sql that they produce. Simon allayed some of those concerns by running a number of test queries, using instrumentation such as 'SET STATISTICS TIME ON' to compare the differing sql between manually and EF created, with mostly good results. There were a few specific examples of weakness in EF1 however the speed of application construction must be balanced against the speed of direct ADO.NET queries (which vastly outperformed the ORM queries - with no overhead for mapping etc).

A couple of important things to remember are that when you construct a sql statement you are asking SQL Server for the result not telling it exactly what to run and it will often reorgnise queries before execution. Additionally the old argument between stored procedures and text queries was touched upon with the only benefits really being the amount of text over the network and the security issues of allowing direct modification of tables. Performance is not an issue as compiled plans of text queries are cached in SQL.

The underlying theme was to check your queries using tools such as SQL Server Profiler in order to hone your query performance (whether it be through direct SQL, EF, Linq2Sql, nHibernate..).

As Barry is soon to be moving to Microsoft in the states his talk was somewhat hijacked by the DDD team with various videos leading to a rather jovial atmosphere for the final talk of the day.

The content itself was very factual rather than contextualised to the day to day in the sense that the presentation did not really go in to real world examples, prefering instead to describe the variety of encryption/hashing options available to developers.

• Hashing: One way reducing (∴ collisions are possible) algorithm used for passwords/checksums (MD5 and SHA1 to be avoided)
  • Always salt a hash (include a random piece of data in the plain text before hashing) to avoid dictionary attacks
• Symmetric Encyption - uses a single key for encrypt/decrypt (Rijndael is most used algorithm)
• Asymmetric Encryption - uses public/private key but is computationally expensive so often used only initially to transfer/protect a symmetric key