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
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
This was the first paid conference I have attended so I was expecting big things. By big things I mean lots of free stuff and nice food, oh and some good talks. I didn’t finish the first day empty hearted. There were lots of good talks, two memory sticks of unknown size, two pens and some nice food.
Death by dogma versus assembling agile - Sander Hooendoorn
This guy is a fantastic speaker. Funny, informative and really gets his point across.
The talk centred on the fact that agile is everywhere nowadays. It’s huge buzz word. Everyone has to be seen to be doing agile, whether they really are or not. With that comes a host of problems, not the least of which is that agile, or in particular Scrum, can be seen as a silver bullet. It’s not. There’s also a lot of people getting certified as Scrum Masters then being thrown into a project, which can lead to a very dogmatic approach. Everything must be done to the letter because that’s what the “certified process” says and Scrum Master doesn’t know another way.
Sander’s main point was that if you take this dogmatic approach to agile, it’s not really agile. In fact it’s the opposite of agile. He suggested you should assemble your own method, find something that works for your team and stick to the basic principles of agile:
- Work iteratively
- Have small units of work
- Plan continuously
- Deliver early and get feedback
- Simplify communications
Integrity driven development - Roy Osherove
Roy is another absolutely cracking speaker and not a bad singer (the talk ended with a song). Unfortunately I’m finding it difficult to summarise the gist of his talk so I’ll pick out a few interesting points.
One subject which struck a chord with me is was what Roy called survival mode. Essentially this is a team that is overloaded so they are too busy to learn and practice. Obviously this is incredibly bad. It’s bad for the developers because they’re stressed and the work is less gratifying because there’s pressure to cut corners. It’s also bad for the employer because developers will be less happy and so more likely to look elsewhere for employment. Roy suggests a couple of ways to get a team out of survival mode; remove over commitments and increase time estimates to include quality.
Another interesting technique cover was using a decision matrix. Surprise, surprise, this is used to make decisions. In short, you list our options along the top and your values down the side then rate each one between 1 and 5. The option with the highest total is the one your use. Simple.
The final point I want to cover from this talk is this; “great teams are grown, not hired”. I’m not sure I agree 100% but I really like the principle. To me this says focus on building the skills of your current team and be willing to invest time and money. Roy suggested several ways of doing this:
- Challenge your team
- Give them the time to practice
- Include learning time in estimates
Obviously this is easier said than done, but as I said I like the principle.
Introduction to the reactive framework - Richard Blewett
The Reactive Framework (Rx) is all about providing a powerful wrapper around IObservable and IObserver. The interfaces are also fluent, making it very easy to read. Another particularly useful application is to wrap events. Rx provides various extension methods for handling events.
To be honest, this is a very difficult thing to explain without examples. The talk was essentially one big demo with a few slides thrown in so did a very good job of explaining things. Unfortunately I don’t have those samples so the Rx getting started page is probably a good place to find out more information.
Individuals and interactions over processes and tools - Kevlin Henney
Again this is a talk which is difficult to summarise as a huge amount was covered. Kevlin is one of those speakers who gives the impression they could speak for hours and hours on their chosen subject. So again I’ll pick out a few points that stood out.
Many of the points made in this talk were along similar lines to the assembling agile keynote. Agile should be flexible. There is no one way to rule them all. It was also pointed out that the idea of being a certified Scrum Master is a little ridiculous. What’s the point of being certified in a process that shouldn’t be defined rigidly?
Estimates are tricky. One figure, for example three weeks, is not sufficient. There is a probability associated with an estimate being correct so it’s better to suggest a time period. E.g. Two to three weeks. Also units should be chosen with care. Fifty two weeks sounds much more precise than one year. If a team member estimated a project would be completed in fifty two weeks, how much time either side would you give them? One week? Two weeks? If they said the project would take a year, it’s sounds much more fuzzy, much more imprecise, so it’s natural to assume there are bigger inaccuracies in the estimate. Perhaps you would allow one or two months leeway.
Apparently a study has been done about what motivates people. For us knowledge workers the top motivator was not money or recognition, it was progress. Now that is interesting.
Practice programming, what’s the point? Ben Lambert
I’ve been a fan of this idea for a while now. The idea is you practice programming in much the same way as you’d practice a sport, or playing a musical instrument. Why would you do this? To improve your skills, to learn something new, to challenge yourself. This can be done at work, but ideally it’s done in a no pressure situation. Then you can take your time and have fun. But, saying that, Ben pointed out that it is important for your employer to give you the time to practice. To understand something fully you need to take your time, which can be difficult at work.
- What kind of thing can you do to practice programming? Ben gave a few examples:
- Write the same task in different languages
- Solve the same problem in several different ways
- Learn something completely new
- Write a simple game, or anything else you find interesting
