NDC Oslo
Make your code more beautiful with the Fira Code typeface
Beautiful code: typography and visual programming by Peter Hilton was one of the best talks at NDC Oslo this summer.
Peter talked about how layout and typography can make code beautiful and improve code readability. After all, as Knuth pointed out:
Programs are meant to be read by humans, and only incidentally for computers to execute.
So how can one improve a monospaced programmer focused typeface?
By utilising ligatures of course!
NDC 2013 session videos are up
The videos of the sessions during NDC 2013 is now up on NDCOslo's Vimeo channel.
You can use the agenda to find more interesting topics.
I've updated my previous posts to include links to the videos of the discussed sessions:
- Day 1, high performing teams
- Day 2, architecture
-
The worst first world problem during NDC was deciding which sessions to watch live. Now I'm finally able to see what I missed.
NDC 2013, Day 3
Aka. the day of automated testing.
Sharing C# across Windows, Android and iOS using MvvmCross
MvvmCross is an excellent framework for data binding ++ on Xamarin's supported platforms. Stuart Lodge gave a talk explaining the motivation, history, philosophy and current state of the framework.
MvvmCross makes it easy to implement the MVVM-pattern on iOS, Android, Windows Phone, Mac, Win RT and others, and facilitates code sharing of the ViewModel logic across all the supported platforms. With the help of PCL (Portable Class Libraries), you can achieve code sharing in the upper 80%s of your code base. Even more if you use little custom UI. The view itself cannot be shared, and that is as it should be.
Properly decoupled view models are easy to test and with the code shared across all your platforms, the tests will have high value.
MvvmCross enables cross platform development with native UI and performance, together with easily testable code. I've used MvvmCross myself and highly recommend it to everybody interested in multi-platform development. For an introduction, check out the MvvmCross N+1 video series.
Succeeding with TDD: Pragmatic Techniques for effective mocking
Venkat Subramaniam gave an introduction to mocking in C# and helpful pointers when working with test-driven development (TDD).
- If your code is not testable, your design sucks. Separation of concerns, dependency inversion and the single responsibility principle helps with both design and testability.
- TDD takes you from unknown to known, one small step at the time.
- Start with your needs and map the world to you.
- Use mocks sparingly and keep them simple! Never make a mock more complex. If you hear "Do we need to write unit tests for the mock?" you have failed in this regard. An example:
[TestClass]
public class MockExample
{
/// <summary>
/// An interface for an imaginary stock service.
/// </summary>
public interface IStockService
{
double QuoteForTicker(string ticker);
}
/// <summary>
/// Class representing an application model.
/// Utilizes the IStockService in its implementation.
/// </summary>
public class SampleApplicationModel
{
private readonly IStockService stockService;
public SampleApplicationModel(IStockService stockService)
{
this.stockService = stockService;
}
public string CurrentTicker { get; set; }
public string LatestQuote { get; set; }
public void GetQuote()
{
var quote = stockService.QuoteForTicker(CurrentTicker);
LatestQuote = quote.ToString();
}
}
[TestMethod]
public void GetQuoteMustSetLatestQuoteForTicker()
{
// Simple mock, using an appropriate tool
var stockServiceFake = new Mock<IStockService>();
stockServiceFake.Setup(s => s.QuoteForTicker("AAPL")).Returns(700D);
var model = new SampleApplicationModel(stockServiceFake.Object) { CurrentTicker = "AAPL" };
// Mock with internal logic
//var model = new SampleApplicationModel(new StockServiceFake()) { CurrentTicker = "AAPL" };
model.GetQuote();
Assert.AreEqual("700", model.LatestQuote);
}
[TestMethod]
[ExpectedException(typeof(InvalidOperationException))]
public void GetQuoteLFailsMustSetErrorMessageAsQuoteValue()
{
// Simple mock, using an appropriate tool
var stockServiceFake = new Mock<IStockService>();
stockServiceFake.Setup(s => s.QuoteForTicker("AAPL")).Throws(new InvalidOperationException());
var model = new SampleApplicationModel(stockServiceFake.Object) { CurrentTicker = "AAPL" };
// Mock with internal logic
//var model = new SampleApplicationModel(new StockServiceFake(true)) { CurrentTicker = "AAPL" };
model.GetQuote();
}
/// <summary>
/// Complicated mock. Hard to understand, must be maintained
/// together with the interface it's implementing.
/// </summary>
private class StockServiceFake : IStockService
{
private readonly bool throwException;
public StockServiceFake(bool throwException = false)
{
this.throwException = throwException;
}
public double QuoteForTicker(string ticker)
{
if (throwException)
{
throw new InvalidOperationException();
}
return 700D;
}
}
}I would have stressed more that you don't start with TDD, you start with unit tests. Understanding how to write relevant and well designed tests are a precursor for a successful application of TDD.
C# 5
Jon Skeet, best known from Stack Overflow and as an author of the books C# in Depth, talked about async await in C# 5.
His focus was somewhat different from Venkat's previous talk. Rather than starting with C# threading basics, Jon made the case for async and await using metaphors and code examples. As we've previously learned, asynchrony does not equal parallelism.
C# in its current iteration has many different APIs for dealing with asynchrony. Your code will be easier to develop, understand and extend if you stick with one of these paradigms. Switching points between synchronous and asynchronous code can be painful.
Jon stressed the need for giving the user early feedback. For example, show items in a list as they come in. Don't wait for all the items before giving the user the option to work with the data. Also, validate input as early as possible so that exceptions caused by bad input do not happing during the asynchronous operations.
Testing was the last topic:
- Keep tests for plain business logic and asynchronous operations separate.
- Take control of time and consider using an abstraction so that the ordering of execution can be controlled from the tests.
- Test for different permutations of completion order for the different asynchronous tasks. The tests should still pass even if the code is run synchronously.
C# 5 lets you focus on the difficult bits... And that's good!
NDC 2013, Day 2
If the theme for my first day at NDC was high performance teams, the second day was all about architecture.
Asynchronous Programming on the .NET Platform
Venkat Subramaniam showed the evolution of asynchronous programming on the .Net platform. He started with "old school" manually created threads, and ended up using async and await from C# 5.
How does the user know your app is busy working and not broken?
I was reminded that about 250 ms are the longest an application should go without giving feedback to the user. This also applies to the application's startup time, which can be tricky in some situations. If startup performance cannot be increased within your development budget, a splash screen is your friend.
Seeing the differences between the asynchronous techniques in one coding session, made C# 5's improvements to clarity obvious. Thinking at a higher level of abstraction can be very powerful, but it also raises the bar for new users. However, every programmer today must learn to utilize more than one processing unit. C# 5's implementation of async and await is the most elegant I've seen so far in an imperative language.
People, Process, Tools – The Essence of DevOps
Richard Campbell gave me an introduction to DevOps. The discussion touched on some well known issues within a software organization, but it was still a useful introduction to the term DevOps.
This is the definition from Wikipedia:
DevOps (a portmanteau of development and operations) is a software development method that stresses communication, collaboration and integration between software developers and information technology (IT) professionals
People, Processes and Tools, in that order, is the well known agile mantra and very much common sense. Richard talked about the challenges of cross-department and cross-team communication, and stressed the necessity of framing discussions constructively.
The one tip that stand out for me, was to focus on ROI (Return Of Investment) when discussing issues with stakeholders. For instance, if you cannot get managerial approval for faster hardware, document how much money the new hardware will save for the organization. Make it easy for others to make the right decision! Sun Tzu figured this out some time ago.
Other takeaways were:
- Document every project. Do not let problems or work go unnoticed.
- One step environment creation! Utilize virtual environments, preferably configured like production.
- Shorten and amplify all feedback loops.
- Take ownership of numbers that matter to you.
The Architecture of Uncertainty
Kevlin Henney is one of my favorite speakers, and I've been to many of his talks in the past. He has impressed me before by being one of the few speakers using sources from the scientific literature and not just anecdotes from his own experiences. If our field is to mature and improve, more educators outside academia must do this.
What is software architecture? Kevlin has previously used the definition put forth by Grady Booch:
All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.
Therefore, we should
Avoid decisions at the point of most ignorance.
This have profound consequences. Don't lock in your decisions to early! We can use the stuff we are unsure about to help us define our architecture. Every point of uncertainty is a chance to introduce an abstraction such as an interface, enabling us to continue working without having to consider every detail all the time.
Partition the application along the lines of which you are uncertain.
Such thinking can improve the quality and speed of our work. It makes the gaps in our knowledge apparent and enables us to move forward in a constructive manner. As we come to know our project and domain better, the quality of our decisions will improve and it will be easer to fill in the gaps from before.
NDC 2013, Day 1
NDC (Norwegian Developer Conference) is a yearly developer conference taking place in Oslo, Norway, with a focus on agile methodology and Microsoft technology. However, a lot of talks are technology agnostic, and the attendees are a diverse group of people.
Day 1 of the conference had some real gems and here are some highlights.
Accelerating Agile: hyper-performing teams without the hype
The first talk I attended was Accelerating Agile: hyper-performing teams without the hype by Dan North. Despite the hyper title, Dan delivered anecdotes from his work in the trading business with confidence and flair. He had many valid observations (IMO) regarding what drives effective teams. Some examples include:
- Train the developers in the domain og the business and have domain experts connected to or be part of the development team.
- Don't be afraid to try something new, be it technology or process. A corollary is: Be OK with "failure". Product development is not project delivery.
- Prefer simple over easy. Simple is the buzzword of the day, but it is still underrated. Easy can lead to more problems down the road. Think frameworks that do to much or taking on to much unnecessary technical debt.
Clean Architecture and Design
Next up was Robert C. Martin with his talk Clean Architecture and Design. As usual he started with a fun fact, then a history lesson. What followed was a good talk regarding components, their boundaries and responsibilities and unnecessary complexity in systems.
- "Architecture is about intent". You should be able to discern the purpose of your system by looking at your architecture. Think normal architecture blueprints.
- Inputs and outputs should be plugins to your system. That includes the GUI and the database.
- Wrap external dependencies such that they can "easily" be replaced.
- A good architecture allows you to defer decisions.
Patterns of Effective Teams
Patterns of Effective Teams, another excellent talk by Dan North.
This talk was even better than his last one. Dan described patterns he and his teams have found useful, describing the situations and the persons involved. The patterns included:
- Dreyfus squares, pair developers of compatible skill levels.
- Make new hires feel welcome. Take care to introduce them to the organization, give them task related to their skill level and make sure they get some early wins.
- Keep your daily Scrums (or equivalent meetings) effective and useful for the whole team. If the team thinks of the meetings as energy drainers, change the meetings make them useful for your team and situation!
- Code critique. Learn from other peoples code, and give the team opportunities to learn from each other. Code reviews should be an energizing and positive experience. Make the novice review from code from an expert to facilitate learning and teaching.
Edit: I've added links to videos from the sessions.