Enable MvcBuildViews using TeamCity if a view is changed

At work we recently switched from using SVN to Git and GitHub. There are many advantages but there's one in particular I want to talk about. 

Using TeamCity you can automatically build all pull requests. This is incredibly useful as it ensures only code that compiles successfully and passes all unit tests gets back into master. If the build fails you are notified in GitHub.

But, there's a problem. View errors are not reported because MvcBuildViews is off. One solution is to enable MvcBuildViews for all web projects but in our case this is best avoided as it roughly quadruples compile time. The ideal solution is to enable MvcBuildViews only if a view has been changed in the current build. Unfortunately I struggled to work out how to do this. So I asked a question on Stack Overflow and the first answer I received pointed me the right direction.

I've managed to improve on my Stack Overflow answer. It simply enables MvcBuildViews for all .csproj files if a view has changed, but this is still quite slow. It's much faster to only enable the setting for projects in which views have changed. This may be overkill for many solutions but for ours it's not.

A few things to bear in mind:

• I'm no PowerShell expert
• You'll probably what to change the Get-ChildItem command in step one to point directly at your web project .csproj files rather than all .csproj files
• The Write-Host commands must be formatted in this way so they appear in the TeamCity build log
• By default TeamCity does not do a clean checkout of the source code (although this can be enabled). Instead changes are applied incrementally meaning that alterations to .csproj files are not undone on each build. So MvcBuildViews should be reset on every build
• %system.teamcity.build.changedFiles.file% - This file lists all the changes in the current build in the format [fileName]:[status]:[commitHash]. E.g. Home/Index.cshtml:CHANGED:1400ea14c3196abbfd8de3ab6fe0a902be2ccad8
• %teamcity.build.workingDir% - This is the directory that contains all the files to be built

Code also available on GitHub.

I've made a game - what did I learn?

I've made a game for iPhone, it's called Rebounder. This is a series of blog posts about it.

1. I've made a game
2. Why?
3. How?
4. Some of the challenges
5. What did I learn?

It works in my head

Before starting Rebounder I came up with a few other game ideas and made a few prototypes. Each one was great when I imagined it in my head but sucked when I made a prototype. It really underlined the importance of getting software into people's hands as soon as possible.

There's no such thing as simple

Okay so Flappy Bird was pretty damn simple, but generally speaking there's no such thing as a simple game. When the idea popped into my head for Rebounder it was something like "draw lines on screen to bounce balls to a target, simple!". Unfortunately when you give it more thought and started building something, it's rarely simple.

Programmers can't make games by themselves

I have zero graphic design skills yet I still tried to create some graphics. It was a total waste of time, you need someone with graphic design skills. In fact I'm going to go as far to say that making a game by yourself is a bad idea. I think sharing work, sharing ideas, sharing enthusiasm, sharing testing and everything else would help a great deal.

Don't throw away your prototype

My prototype was terrible. Once it had served it's purpose, to prove that Rebounder would work, I had to start from scratch because the code was so bad. In doing so I reintroduced bugs I'd fixed and introduced new bugs, plus it took ages. In hindsight I feel that had I spent maybe 30-40% more time on the prototype I could have reused much more code and saved quite a lot of time.

Time management

Games take time and time is often in short supply. I realised during the course of development that I need to make better use of my time.

• Prioritise - Only do what really needs to be done. Aggressively slim down your task list. For example split tasks into essential and nice to have
• Discipline - When there's a lot of work to do I find it's important to find regular time, however short, to complete a few tasks so you feel like you're making progress
• Focus - I spent a lot of time working in front of the TV, only half concentrating on the task at hand. Big mistake. It resulted in poor code and poor solutions. I really should have worked somewhere quiet with no distractions

Unity specific stuff

• Don't use Vector2D to position your sprites - As far as I'm aware Unity has no mechanism for controlling sprite order so you have to set their Z co-ordinate so one is in front of another in the scene. This means you need Vector3D
• Be careful when updating plugins - Make sure everything is committed to whatever source control system you're using before updating. In particular NGUI cause me some difficulties
• Use Force Text asset serialization - The alternative, Force Binary, leaves you clueless as you what you've changed when committing to source control
• Don't fight MonoBehaviour - By default all script components attached to GameObjects inherit from MonoBehaviour. When I started development I wanted to write POCOs so my classes were easier to unit test but I found many tasks were hard work because of the missing inherited functionality. In the end I gave in and wrote all my components that way. It was much easier
• Keep your script components as small as possible - I found it's better to attach several small scripts to a GameObject rather than one massive script. In hindsight this is fairly obvious, it's just the single responsibility principle. The only downside to this a bit of extra code so the components can communicate
• Events are invaluable - When I started writing Rebounder I had a lot of initialisation code that looked like this someObject = (SomeObject)FindObjectOfType(typeof(SomeObject)); This is really bad news because many of my classes ended up with unnecessary references to one another. Then, since I had a reference I would start calling the referenced classes methods and I moved closer to spagettiville. Using events these problems disappear. You simply fire off an event and any classes that need to know about it implement event handlers. The class firing the event and the class handling the event have no knowledge of one another. For event handling I used the Messenger Extended code on Unity3D wiki. I highly recommend it if you want a simple, easy to understand code that is up and running within minutes
• Playmaker isn't particularly useful if you're a programmer - Playmaker is a popular plugin described as "visual scripting for Unity". What that means is you can make games without any programming knowledge. I attempting to learn it hoping it would speed up development time but ended up being frustrated because I could achieve things much quicker using code. Perhaps if I'd persisted with it Playmaker it would have been very useful, but then I would have probably had less Unity API knowledge. It's not black and white. Anyway, I gave up on Playmaker

Get lots of people to test

When I was ready to send Rebounder out for wider testing I asked on facebook and received what I thought was plenty of replies. I distributed copies of the game to less people than offered because I had enough testers. In hindsight this was a bad idea. Some testers didn't install the game and quite a few testers didn't offer any feedback at all. Perhaps they were busy or perhaps they didn't like it and were embarrassed to say. Don't get me wrong I appreciate everyone who gave up their time to test, but testing without feedback is totally pointless. So my point is, if you make a game or app, send it out to every single person who offers to test it.

I've made a game - some of the challenges

I've made a game for iPhone, it's called Rebounder. This is a series of blog posts about it.

1. I've made a game
2. Why?
3. How?
4. Some of the challenges
5. What did I learn?

Learning Unity3D

Unity provides a very high level environment for making games, however that doesn't make it simple. Unity is a huge package with a steep learning curve for someone with no experience of making games. In addition to this it's not just Unity I was learning. Each plugin must be learned and I used several including 2D Toolkit, NGUI, Game Analytics and iTween. All but iTween required a significant time investment to get up to speed with.

Fortunately there are many great resources for learning Unity.

Different aspect ratios

There are a bunch of different aspect ratios being used by various phones on the market. Usually this isn't a problem. For example a 16:9 iPhone 5 will simply show a bit more on the left and right when compared with a smaller 3:2 iPhone 4 screen. Unfortunately the core gameplay mechanic of Rebounder is angles so that extra bit of screen means that sometimes a solution that will work in one aspect ratio won't work using another. The problem gets worse as the number of aspect ratios increases. This is one of the reasons I decided to stick with iPhones and avoid Android devices.

3:2

16:9

In my head this problem could be solved by using some clever maths to calculate the angles required and adjust elements of the level accordingly. One small problem, I'm not that clever. Another solution I came up with involved attaching a script to each target that stored positions per aspect ratio. So the co-ordinates could be (-10, 10) for a 16:9 screen and (-8, 10) for a 3:2 phone. I binned this solution because most of the levels worked fine in various aspects so I was duplicating lots of co-ordinates. 

My final solution was the simplest. If a level worked in all aspect ratios it would be loaded as normal. If a level was different for each aspect ratio the level name would include the aspect ratio. E.g. Level2-16by9 and Level2-3by2. The aspect ratio would be calculated when the game started up and appended to the level name where appropriate. 

2D graphics

Unity3D is primarily a 3D graphics engine. No really, it's in the name. When I started development Unity did not have:

• A Sprite GameObject
• Collections of sprites
• A sprite animation editor
• Support for different resolution textures on different devices

Fortunately a great plugin exists called 2D Toolkit which has all of these features. Probably the most useful feature I found was the Sprite Collections.

You simply drag all your sprites into the editor and 2D Toolkit automatically squishes them together to form a large texture atlas containing all your sprites.

Even better, for each sprite in the collection you can specify things like anchor position, the which point it rotates around; and the collider type, such as sphere, box or you can draw your own. If that wasn't enough 2D Toolkit also supports different resolutions so you can display sprites of an appropriate size for the device. For example x1 on iPhone 3, x2 on iPhone 4 and iPad 1/2 and x4 on iPad Retina.

The only feature I wasn't impressed with was the GUI system. For that I used NGUI. It's not cheap but worth it if you need a complex GUI or can pick it up in a sale.

I've only scratched the surface of what 2D Toolkit can do in this blog. Without it I'd probably have given up way before Rebounder was finished. 

Massive self doubt

I've never made a game before, I've never been involved in any game development and making games is really, really difficult. Because of this I went through periods of time when I thought creating a game was incredibly exciting and periods of time when I thought what the hell am I doing, this is a complete waste of time. 

What kept me going was taking breaks when I got very frustrated/bored/despondent and taking encouragement from positive feedback I received from friends having played Rebounder.

Time

Making a game takes time. I, like every other software developer who ever lived, massively underestimated the time it would take to complete all the tasks and massively overestimated what I thought I could achieve. At some point I stopped and thought, this is getting ridiculous, I'm never going to finish, I need to cut down my work. So I did.

I used Trello to organise my tasks.

I divided my remaining tasks into two lists, one contained nice to haves and the other required tasks without which I wouldn't have a game. I ended up sacrificing:

• Sound
• Music
• More levels
• Game Centre integration
• Push notifications
• Minor improvements suggested by testers
• Android and iPad support

If I hadn't done this I'd still be working on Rebounder now, with no end in sight.


Next blog post - I've made a game - what did I learn?

I've made a game - how?

I've made a game for iPhone, it's called Rebounder. This is a series of blog posts about it.

1. I've made a game
2. Why?
3. How?
4. Some of the challenges
5. What did I learn?

An idea

Before you can start making a game you need an idea. Ideas are easy, good ideas are difficult and being able to see an idea through is even more difficult. Anyone can come up with ideas on a very ad hoc basis but I wanted a more structured approach. So I did what comes naturally to me, I read a book on coming up with ideas.This helped me create a process. Essentially I would think of as many ideas as possible then iterative through them, giving promising ideas more thought then discarding them when I deemed them not good enough. Did it work? Difficult to say really. You could argue, quite rightly, that my idea is hardly genius, but hopefully it was one of my better ones.

Research frameworks

Once I had an idea I was reasonably happy with I needed to find a framework to help me build the game. There are a lot around. The frameworks I researched included Unity3D, Corona SDK, Marmalade, edgelib and ShiVa3d. Obviously there are pros and cons of each but Unity stood out because I could write in C#, you could deploy to mobile devices for free, it's Stack Overflow style answers site is great and the asset store is invaluable. The main con was that the pro version is very expensive and Unity say that the free version isn't designed to build professional games. Fortunately for me this wasn't the case and I didn't need any pro features.

Build a prototype

The next step was to build a prototype. I really wanted to throw together some code as quickly as possible to:

• Prove that a simple game could be created quickly using Unity
• Prove that the game idea worked by getting a people to play it
• Prove that puzzles could be created of varying difficulty
• Prove that the idea worked on mobile devices
• Work out how to build the 2D graphics using a 3D game engine
• Get some idea of how to structure a Unity project
• Prove that enough levels could be created to make a game (as a side note I found an iPhone app called InkFlow which was great for sketching level ideas)

Build the game

Making the prototype didn't take a huge amount of time because I wasn't concerned with graphics, menus, quality code, project structure etc. Not so much when building the final game. Most of the prototype code couldn't be reused so I essentially rebuilt Rebounder again from scratch, and this time do things right, well, better than before.

Testing

Manual testing is boring. Unfortunately I ended up doing quite a lot because automated testing was one of the many things I cut from the game due to the decrease in my time/motivation and increase in my children. Other than myself I mostly relied on a few others to test for me. I used TestFlight to distribute development builds, it's great, I highly recommend it.


Next blog post - I've made a game - some of the challenges

I've made a game - why?

I've made a game for iPhone, it's called Rebounder. This is a series of blog posts about it.

1. I've made a game
2. Why?
3. How?
4. Some of the challenges
5. What did I learn?

Why?

1. First and foremost I wanted to make something. Software development is about creating stuff. Most developers, including myself, spend their lives creating software for other people, making other people's ideas. I wanted to come up with an idea of my own and then create it. In my opinion this one of the most rewarding and exciting things you can do as a software developer
2. It's a challenge like nothing else I've done before. I wanted to prove to myself that I could do it
3. I've been a gamer for a long time. I've spent a long time talking about what makes games good and what makes games bad. Part of me has always wanted to try and make a game
4. Lastly I thought there was a small chance of making some money. I know, I know, pretty unlikely, but I would rather try and fail than not try at all

Next blog post - I've made a game - how?

I've made a game

I've made a game. It's called Rebounder, it's a puzzle game for iPhone and it's available on the App Store right now unfortunately not on the app store right now because iOS8 broke the game and I've yet to fix it. The aim of the game is to get the balls to the target(s) by drawing lines on the screen. Each target must be hit five times to complete each level. In typical mobile puzzle game fashion each level is short and new mechanics are introduced as you progress.

This project has taken me a long time and has thrown up a lot of challenges for someone who has no experience making games. I'm going to write a series of blog posts about why I did it, how I did it, how solved some problems I faced and what I learned. Hopefully it'll be interesting.

Thanks to everyone who helped test and gave feedback. Thanks to my wife for giving me a lot of time to work on Rebounder. Massive thanks to Fin Costello for giving up his time to create the graphics.

Next blog post - I've made a game - why?

Prioritsing personal development and personal projects

I have a problem. I feel like my software development knowledge is poor and must be boosted. Which bit? Errmmm…all of it. Everyone knows more than me, I know nothing. That’s what my brain tells me. Learn all the things, right now! But, I can’t do that. Like other people, I have a full time job. I have a family, I can’t just ignore them. But I want to learn stuff, I want to improve myself, how do I do it? There’s so much to learn, how do I decide what is most important right now?

This is what runs through my head almost daily. My first thought is make a list. Lists are great, they mean you don’t have to remember stuff. Before I had a kid I used to have a fairly long list of stuff I wanted to know more about, books I wanted to read, technologies I wanted to play with, projects I wanted to undertake. That was fine, I had lots of time I thought, I’ll get to them eventually. Then my son appeared and my time disappeared. I made the sensible decision to kill the list. Well, everything but the top most item, the task I wanted most to complete. This worked well for a while, but then my free time and energy creeped up again. I started adding more things to the list. Arrggh! How to I prioritise this stuff? My free time is way more important that it used to be, I need to prioritise. This is where I stumble. I still want to complete all the things on my list but I can’t decide which is most “important”. Note the quotes. I’m using these to suggest that none of the tasks are really important, I just convince myself they are. Also it's worth clarifying that I'm talking about non trivial tasks, something that I would at least have to put at least few hours into. 

So, I need to find a better way to prioritise right? Off the top of my head there are a couple of ways I could go about this.

Method 1 - A system

I need a system. I like having a system. I used to have a system for stacking dishes on the draining board, before I got a dish washer. Find the most efficient method and stick to it, that’s me. 

One way to make decisions is using a decision matrix. List the options, list the factors and rate each factor against each option, using an optional weighting. The option with the highest total is the winner. This is so me. 

What factors are applicable here. After some light brain activity I came up with the following:

1. Is it fun? E.g. Do you enjoy doing it? Is it something that you can’t wait to get your teeth into?
2. Is it useful? E.g. Is this something that will make your life easier, or your colleague’s lives easier?
3. Is it important? E.g. Will your career suffer without this? Can you work without this? The distinction between useful and important is a bit hazy. Something useful could save you time day to day but something important you’ll struggle to do without
4. Is it difficult? E.g. Creating a game from scratch is difficult, reading a book is not
5. How long will it take? Pretty obvious this one. If you’re going to spend a long time doing something it had better be worth your while in some way

Scores are between 1 and 5, 1 is low, 5 is high. E.g. 1 means something isn’t fun, 5 means it’s super fun.

Mostly there’s no need to be specific, just a gut feeling will do, with the exception of duration which I feel the need to be a little more explicit. 

• 1 - years
• 2 - months
• 3 - weeks
• 4 - days 
• 5 - hours

Here’s an example of the kind of things floating round my head right now.

	Fun?	Useful?	Important?	Difficult?	How long?	Total
Weighting	5	2	3	3	5	N/A
Learn about .NET vNext	4	3	5	5	5	81
Investigate UA feature and work out how to upgrade	2	5	3	4	4	61
Write a Hubot script	5	5	1	4	4	70
Write a Resharper plugin	4	5	1	3	3	57

I think this is potentially pretty useful. Here are the hard facts, based on the gut feeling values, with which I can work out the most “important” task.

The results are interesting. vNext stands out because while it’s not that useful right now it is really important to know how to take advantage of it down the line when it’s released. Plus it won’t take very long, I can watch a few videos and blogs to get a feel for it.

At the other end of the spectrum is the Resharper plugin. I’ve wanted to try and write a plugin for ages. There are some tasks at work that I could automate using Resharper. After giving it some thought, it would be really useful, but, it’s utterly non essential, it’s probably not going to be particularly easy, therefore will take weeks if not months and I imagine it’ll be a very steep learning curve which will take the edge off the fun factor. 

Method 2 - Throw out the system

While doing a little reading around this area I stumbled across Jeff Atwood’s blog post todon’t. In it he makes the point that collecting tasks is bad and todo lists are bad. I get this. I look at my list of stuff I want to learn and I think crap, I’ve not got enough time! Someone create me a Time Turner already! 

So, method two is bin my todo list. But, if I do that, how will I remember what I want to learn? Well, as Jeff Attwood and Adam Wozniak point out you can just go with the flow. Act on what excites you right now, what interests your right now. Everything else is irrelevant. 

In one respect this approach scares me. I strongly believe there’s no point remembering something that can be remembered by something that doesn’t forget, usually Evernote. So if I don’t write down all the things I want to do, how will I remember them? On the other hand this feels like a breath of fresh air, like a release, like a weight off my shoulders. This way I can be rid of the physic weight of unfinished tasks and just work on what interests me, and that's a big deal.

Here's another way of thinking about it. In on task hoarding and todo bankruptcy the author talks about a hoarder named Richard Wallace. 

"Despite his incredible existence (he slept in a chair, his bed was covered in ceiling-high junk), he didn't see see that he had a psychological syndrome. Pay attention to this, because it's kind of the point: He didn't believe he had an excessive hoarding habit, he felt his real problem was a shortage of storage."

I'm the same as the author of that blog post. I don't believe I have an excessive task hoarding habit, I believe I have a shortage of time. I don't want to live like that. 

This seals it for me. As of now I'm deleting my home dev todo list and I'm deleting my work dev todo list. I'm going to trust that everything I want to learn will be suitably interesting and exciting that it will be at the forefront of my mind. What if this approach doesn't work? That's fine, I can always change my mind somewhere down the line. But for now I'm not going to miss the constant reminder that I don't know enough.

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

Day 3 >> 

Devweek 2014 - Day 1

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

Day 2 >>

Possibly the best description of why programming is fun

This is possibly the best description of why programming is enjoyable I've ever read. It's taken from The Mythical Man Month by Frederick P. Brooks, Jr.

"Why is programming fun? What delights may its practitioner expect as his reward?

First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. 

Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child's first clay pencil holder "for Daddy's office."

Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in
from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate.

Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both.

Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air,
from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. 

Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separate from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be.

Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men."

Why I don't trust code coverage

I had a discussion with a colleague about code coverage the other day where I suggested that 100% code coverage meant very little because you may have covered every line of code, but not necessarily every path through the code. After the conversion ended I thought I'd better check I wasn't talking utter nonsense.

Here is a contrived method and two unit tests.

Here are the code coverage results.

As you can see, 100% code coverage is reported but not all paths through the code have been tested. Yes, the code is dreadful but I think it makes my point. Just because every line of your code has been tested, it doesn't mean that your code has been thoroughly tested.

To make matters worse, lets say 90% code coverage is reported by whatever tool you use, there's no indication of the importance of the code that has been tested. What if the 10% of code that has minimal coverage is the most critical part of your application?

Don't get me wrong, I'm not saying code coverage is a complete waste of time. As a general indication that an area of code needs a few more tests it's great. But other than that, not so much.

Other people's code - Suteki Shop

It occurred to me a while ago it would be a good idea to have a dig through some open source code. Why? Primarily because in the last few years I've spent the majority of my time working on two codebases, one at home and the other at work. I feel very much in my own little code bubble. Working with the same code day in day out you become familiar with the conventions and patterns chosen and you can get into a rut. 

So, the point of this exercise is to get me out of my comfort zone and learn something new. How have other people solved problems I've faced? What is their code like? How to they handle errors? What new ideas or ways of working can I apply to my code?

Suteki Shop

Suteki Shop, written by Mike Hadlow using NHibernate and .NET MVC, is an open source eCommerce site aimed at the fashion and retail industry. I figured it was a good place to start because looking through an unfamiliar codebase is difficult but.NET MVC is my day job so that will give me a head start.

Observations

• The UnitOfWorkAttribute is a great way of encapsulating all database operations in a single action into a transaction and committing on success or rolling back on exception
• Exception handling is minimal. It seems to only be added where it's really required resulting in really clean code
• Really nice use of fluent interfaces to create more readable code when mapping data to view models 
• Generic repositories make CRUD operations ridiculously simple
• On the whole the controllers are short. Unnecessary code hasn't leaked into them which I find often happens in my work codebase
• Some domain objects fire events whose handlers call methods on services classes, which is a mechanism I've never considered using. E.g. The Order object has no dependencies on any other class, but if you call Confirm() it will set OrderStatus to OrderStatus.Created and fire an OrderConfirmed event whose handler calls EmailService.SendOrderConfirmation. It's a nice way of running non critical tasks
• Object values can be retrieved from the database as if by magic using the power of the EntityModelBinder

ScaffoldController<T>

This is really interesting. It's CRUD done right. Several controllers inherit from this and they contain a couple of attributes and no other code. 

Repository operations are possible because the generic class that applies to the controller also applies to the repository. That generic class is also used to build the view which can store a single item, list of items or return data for a drop down list.

Obviously there are down sides to this approach. It can't be used if you want to do any non standard operations and you still need to create the view.

What can I take from this?

• Chaining methods with fluent interfaces is great for creating readable code, I don't use it enough
• There's really no reason to put any kind of logic in the controller, it can always go elsewhere
• I don't understand generics quite as well as I'd like 
• Model binding is something I should read up on
• Not all actions in a web application need to be done synchronously. If something isn't critical it can be carried out using events or some other async process