I had the pleasure of attending Progressive .Net tutorials last week at skillsmatter. Thanks to my current workplace 15below . The thing I liked best about these sessions is they covered each subject in 3 ½ hours which gave plenty of time to understand some theory, do some exercises and have discussion. On the whole the sessions were really useful and I recommend anyone interested in learning good software practises to look at the website for upcoming talks (plenty are free if you go in evening). Also you can watch the videos of any session from the links.
Information leaves my head as quickly as it enters, so I thought I’d better do a brain dump and summarise what I learnt for future reference.
Day 1 5th Sep
GHERKIN ACCEPTANCE CRITERIA
i.e. specifying requirements as tests.
So we went through some theory with Christian. The following points stood out to me:
- Automate acceptance criteria with stories and a bunch of scenarios showing concrete examples
- Do just enough stories/scenarios for a sprint (i.e. don’t do everything up front). Limit Work in progress
- Examples are good for explaining complexity. We do it every day when talking to people. It’s difficult to explain abstract concepts without examples.
- In order to keep examples up to date, automate them as tests against live code using continuous integration
- Make the examples business readable. E.g They showed a nice dashboard showing progress of specifications etc http://www.speclog.net/
- It is not necessary to replace burndowns and task lists with scenarios but it may be helpful to include a loose link between them (e.g. a task/bug Id referenced in the story title)
- Developed or legacy code is fine to do BDD against, but beware – it will take longer. It is much easier for greenfield projects. We should measure timings against that to get a true idea of the time taken to work in this way.
We then learnt how the Gherkin language can be used to provide scenarios in a formalised manner that is succinct enough to be easily read and tests core business functionality.
We worked through some exercises like the one below (from the presentation slides):
AUTOMATING GHERKIN ACCEPTANCE CRITERIA
In the afternoon, there was some overlap with the first session, but the interesting part was looking at how to integrate the specs with the code. I suggest go to the website www.specflow.org, watch the tutorials, download the plugin and play around. There were some really easy ways to create the fixtures needed to run the scenarios from gherkin feature files. I’m planning to try and use this tool as soon as possible.
Day 2 6th Sep
LOAD TESTING FOR DEVELOPERS
The speaker gave a good talk on how architecture on its own does not solve the problem of scalability. Testing is needed as early as possible as a way of exploring how the application behaves with multiple users and also to prove how it should respond under known loads. There is also a distinction between Load Testing (testing under typical load) and stress testing (seeing how far we can go before breaking it)
Here is the overview of what we did:
http://www.codingthearchitecture.com/2011/08/25/load_testing_for_developers.html
The tools we used to exercise an example application were open source but he explained the UI was very old. Still, it worked and the point of the tutorial was to show the sort of concepts useful for load testing early in a software cycle.
CI TO CONTINUOUS DELIVERY
This was a fun session. The speaker was very enthusiastic about CI and a variety of other topics like TDD coverage and feature branching
Generally the slides showed examples of building and deploying applications using Teamcity (one in less than 7 secs!) and provided the reasons why it is important to have software that is constantly in releasable state.
The core practises were given as follow:
- Continuous Integration
- Configuration Management
- Dependencies
- Documentation
- Environment
- App Configurations
- Data
- Tests
- Unit
- Integration
- Functional/Acceptance
- Performance/Load
- Penetration
Feature switching vs feature branching was a hot topic.
The interesting part was how software was deployed onto staging, UAT and production. The speaker talked about the following flow that allows the build to check in packages that can be installed automatically on the test server via a build agent on every check in:
Day 3 7th Sep
ASYNC METHODS IN C# 5
Jon Skeet is a very entertaining speaker and covered a complex subject with some enthusiasm.
The first part showed how you would use the C#5 Async CTP library to write asynchronous code without having to write too much boilerplate code. The history of async in C# was described – this is the third attempt. It should result in much cleaner code: e.g.
// code to asynchronously determine the size of the Stack Overflow home pageusing System;
using System.Net;
using System.Threading.Tasks;</pre>
class Program
{
// Caller (block 1)
static void Main()
{
Task<int> sizeTask = DownloadSizeAsync("<a href="http://stackoverflow.com">http://stackoverflow.com</a>");
Console.WriteLine("In Main, after async method call...");
Console.WriteLine("Size: {0}", sizeTask.Result);
}
// Async method (block 2)
static async Task<int> DownloadSizeAsync(string url)
{
var client = new WebClient();
// Awaitable (block 3)
var awaitable = client.DownloadDataTaskAsync(url);
Console.WriteLine("Starting await...");
byte[] data = await awaitable;
Console.WriteLine("Finished awaiting...");
return data.Length;
}
}
In essence 2 keywords have been introduced to the compiler – async and await. async explicitly sets up your method as something that is intended to run asynchronously. await informs the compiler that the code following this line (called a continuation) should run after the async method comes back. Thus the compiler hold on to the state and but knows not to wait on the thread.
The second part was a little scary. Bit by bit, the speaker implemented the async functionality using .Net 4 in order to get an understanding of what is going on under the hood. What we could see is that the compiler is making use of delegates and iteration blocks to decide whether to carry on synchronously (if the async task is already completed) or keep the state and hand back control to the thread pool. The full blog posts are here http://msmvps.com/blogs/jon_skeet/archive/tags/Eduasync/default.aspx
YOU THINK YOU KNOW AGILE?
This was a slide show powerpoint presentation. I’ve downloaded the slides – they pretty much reflect the content of the talk..
In summary, the following points were discussed:
· Agile Manifesto
· Concepts
· Team
- Developer
- Tester
- Business Analyst
- Team Lead
- Architect
- Product Owner
· Methodologies
o Scrum
o XP
o Kanban
I think this talk would be really useful if we had had more discussion of some of the pain points in the process and how to deal with the customer who wants a project plan up front. In the break he touched on this, giving example of a scrum master who presented a GANT chart to the client while maintaining sprints internally with story points and factoring in slack.
