How frameworks can kill your projects and patterns to prevent getting killed - Sander Hoogendoorn

This talk wasn’t entirely about bashing frameworks but the speaker was keen to point out numerous problems associated with their usage:
  • Cost
  • Learning curve
  • Convincing management it’s a good idea
  • Convincing other developers it’s a good idea
  • Finding the right one
  • Missing features
  • Changes between releases
  • Development may be stopped at any time
A further point was that people often think of the frameworks they use as their architecture. This shouldn’t be the case. You should work out the requirements of your architecture and choose frameworks to fit.

Test smells and fragrances - Kevlin Henney

Must of the information in this talk was fairly familiar. Don’t reassert anything that has already been asserted, test only one behaviour in each test, when using the SetUp method ensure tests remain individual, tests should accurately describe the code, that kind of thing.

One very interesting point was made about test naming conventions. Kevlin is particularly keen to make the test names as descriptive as possible. To this end he suggested avoiding using “should” as it’s unnecessary, it doesn't add any useful meaning to the name. Also it’s uncertain, unsure, not definite. There is no “should” in tests, it either passes or fails. The speaker also favoured descriptive names with underscores rather than camel case names because they’re easer to read. I have to agree. 

For example a simple test class was created called Cup. It could be drunk and emptied. Here is an example test case using our current naming convention and the one Kevlin suggests.



Applied NoSql in .NET - Michael Kennedy

The big take away from this talk is that while I’m convinced NoSQL is an good solution in certain scenarios, you really need to understand your chosen framework before you start.

It turns out MongoDB, the subject of this talk, is not capable of cross document transactions, which could be extremely problematic. Take the following scenario; an application successfully takes payment from a user. Two things must occur now, firstly the details of the payment must be recorded and secondly the user’s balance must be updated. Both of these must occur otherwise your data will be inconsistent. The only way to ensure these two actions are completed as part of the same transaction in MongoDB is to include them in the same document. I.e. The same object. Further explanation here. It occurred to me that you really need to know this before designing your object model.

IIS for developers - Ido Flatow

This talk contained a bunch of useful information about IIS I wasn’t aware of.
  • Feature delegation allows you to choose what features can be controlled in your web application’s web.config
  • Various useful options exist on app pools
  • CPU limiting. E.g. Limit the app pool to 25% of the CPU
  • Process orphaning. This allows process to be kept in memory after they have crashed. It is then possible to create a script to save the dmp file to disk. In addition this dmp file can be opened in Visual Studio and you can debug it to find out exactly where it crashed. I had no idea
  • Dynamic compression isn’t enabled by default, but is potentially very useful. Ido demonstrated a 1MB JSON file being compressed to around 270KB
  • Default IIS logging is rubbish. The IIS advanced logging module is much more useful as it logs more information. IIS 8.5 comes with this as standard
  • Log Parser Studio is a great app for parsing IIS logs and other logs

Day 3 >>