Monday, 7 April 2014

Devweek 2014 - Day 3


Already familiar with ASP.NET Web API? You sure? - Ido Flatow

I had no idea Web API was so extensible and configurable. You can change pretty much everything in it’s pipeline; message handlers, filters, parameter binding, formatters and so on. 

Turns out Web API can be cached, but you have to do a bit of manual coding to enable it. Essentially it’s a case of using max-age or expires headers as appropriate. Or, ETag headers can be used to version your cache. I can see this being quite a clever way of caching but it requires more setup.


Culture of review - Austin Bingham

I’m very much sold on the benefits of reviews so much of this talk was familiar. But, saying that, I’d forgotten a few important things.
  • Research has been done in this area. All the research mentioned in the talk suggested that code reviews are a effective way of finding code defects
  • Taking your time is important. Don't review in a rush
  • 200-400 lines of code per review is optimal based on research done at Cisco


Better code through bugs - Seb Rose

The question this talk was trying to address was how do you know you have a high quality test suite? In short, you don’t, there isn’t a reliable way to measure. This is where mutation testing comes in. Mutation testing is a fascinating concept. The framework being demoed, pitest, introduces bugs, called mutants, into your code. There are several different types of mutations. Examples include conditions boundary mutator, which changes conditional operators; increments mutator, which changes increments to decrements and visa versa; math mutator, which changes math operation operators. 

For example, the conditions boundary mutator can change a >= to a >. Once the mutation is made your unit tests are run. If at least one test does NOT fail, you have a problem. It may be that you need another test case or there may be some other issue which needs to be fixed.

It sounds like a really interesting and potentially useful technique, but, there are problems. 
  • It can be slow
  • You may not be able to achieve 100% pass rate. Some issues cannot be fixed
  • There’s no good .NET mutation testing framework

Devweek 2014 - Day 2


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.

Fill_CupIsFilled_IsEmptyReturnsFalse

 A_cup_filled_with_water_is_not_empty


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