David Gardiner - Software Engineering

Get programming in F#

2018-06-11T20:35:00.000+09:30

I’m really interested in learning more about functional programming. It isn’t something I knew much about, but the benefits of reducing mutability (and shared state) promoted by functional languages and functional style are enticing.

To that end, I recently bought a copy of Isaac Abraham’s new book “Get programming in F#. A guide for .NET Developers”.

I have no background in functional languages at all, so I was looking for a “gentle” introduction to the F# language, without getting hung up on a lot of the functional terminology that seems to make learning this stuff a bit impenetrable for the newcomer. This book delivers.

The structure of the book is in 10 “units”, which in turn are broken down into separate “lessons” (each lesson is a separate chapter).

Here's my notes from each unit:

Unit 1 – F# and Visual Studio

Introduces using the Visual Studio IDE for F# development, and recommended extensions. Surprisingly for a book published in 2018, most of the book is based on using Visual Studio 2015. I can only presume this is an artifact of the time it takes to write a book. I understand the initial release of 2017 did have some tooling regressions for F# but I am under the impression those are now resolved, seeing at my time of writing the 7th update for 2017 has just been released, including specific enhancements for F#.
Throughout the book, comparisons are made to equivalent C# language constructs, and here too, the text is already a bit dated. An unfortunate downside of a printed book I guess.
One thing to note that is different from many other languages – the file order in F# projects is significant. You can’t reference something before the compiler has seen it, and the compiler processes files in project order.
The REPL is also a big part of F# development.

Unit 2 – Hello F#

The ‘let’ keyword is introduced. It’s more like C#’s const than var, seeing as F# defaults to things being immutable rather than mutable.
Scoping is based on whitespace indentation rather than curly braces.
Diving into how the F# compiler is much stricter because of the way the F# type system works, and how that can be a good thing.
A closer look at working with immutable data, and how you can opt in to mutable data when absolutely necessary, and how to handle state.
C# is statement based, whereas F# likes to be expression based.
The ‘unit’ type is introduced. It’s kind of like void, but is a way for expressions to always return a value (and means the use of those expressions is always consistent).

Unit 3 – Types and functions

Tuples, records
Composing functions, partial functions, pipelines,
How do you organise all these types and functions if you’re not using classes? Organising code through namespaces and modules

Unit 4 – Collections in F#

Looking at the F#-specific collection types – List, Array and Seq, the functions you can use with those collections. Immutable dictionaries, Map and Sets. Aggregation and fold.

Unit 5 – The pit of success with the F# type system

Conditional logic in F#, pattern matching
Discriminated unions

Unit 6 – Living on the .NET platform

How to use C# libraries from F#. Using Paket for NuGet package management
How to use F# libraries from C#

Unit 7 – Working with data

Introducing Type Providers. Specific use cases with JSON, SQL and CSV.

Unit 8 – Web programming

Asynchronous language support
Working with ASP.NET WebAPI 2
Suave – F#-focussed web library
Consuming HTTP data

Unit 9 – Unit testing

The role of unit testing in F# applications
Using common .NET unit testing libraries with F#
Property-based testing and FsCheck
Web testing

Unit 10 – Where next?

Further reading and resources to take your next steps.

Richard’s Technical Debt

2017-02-25T11:39:00.001+10:30

These are my notes from listening to the recording of Richard Banks’ talk The Technical Debt Prevention Clinic that he gave recently at the Microsoft Ignite Australia 2017 conference.

TL; DR - This is a really compelling talk. Go watch it, and share it with your colleagues!

My notes and highlights follow. These are not a substitute for watching/listening to the talk, and the best thing (if you ever get the opportunity) would be to see Richard deliver this in person.

Technical debt

Is design complexity + cognitive load. Is NOT quick & dirty code
Bad code is not technical debt, it’s just bad code
Quantifying – look at trends over time
Don’t
- do a “technical debt sprint”
- Rewrite
Do
- “Boy Scout Rule”

Refactoring

Micro-refactoring – do anytime
Macro-refactoring – plan and only do one at a time to limit disruption to team
Both should have tests in place – ideally behavioural tests (so you’re testing the behaviour not the implementation)

Feature flags

Really useful
Still need to be managed properly

Preventing

Be Professional – you don’t need permission to do your job properly
Have a Definition of Done and stick to it.
Automate everything you can
- tests
- code styles/rules
Change Team Culture

Code Reviews (suck)

Traditional code reviews often don’t work well for a number of reasons
Try doing peer refactoring
Or pair programming when it is “strong-style” where both people are engaged.
- Put the mouse away!
Mob programming – maximise team intelligence
Experiment and find out what works for your team

Other tips

Avoid branching if possible. If not possible make it short-lived. This is because merging is costly
Premature optimisation
Resist temptations
Shared learning
Run hackathons
Adhere to that Definition of Done

Conclusion

Technical debt can be a good thing, but bad code never is.

Adelaide CodeRetreat

2016-10-23T09:54:00.001+10:30

Earlier this year I’d been contacted by Rachelle (Community Manager at Reinteractive) asking if I could promote a CodeRetreat Event that she was organising in Adelaide to ADNUG members. Not only was I was more than happy to do this, but I decided to go along myself and find out what it was all about.

The day-long event was held in the _southstart (formerly Majoran) office space in Grenfell St. 20 had registered, but somewhat disappointingly only 6 of us showed up (I say “somewhat” as in some ways having a smaller group actually worked better, and not just because there was more food to go around!)

The day was also facilitated by Adam Davies (who also helps run the Adelaide Ruby Meetup group). The structure of the day was based on the one from Coderetreat.org. After a welcome and introduction, we paired off with another attendee, worked on implementing Conway’s Game Of Life for around 40 minutes, then all came back together as a group for a ‘retrospective’ review and discussion of how we felt that session went. This was then repeated for most of the day, with a few challenges thrown in just to make it interesting, like “only commit code to version control when all tests pass, and use a 4 minute timer that you revert all uncommitted code when the timer expires” (that one was stressful!), “ping pong” (one person writes the test, and the other has to implement the code for the test) or “avoid using a mouse”.

Most of these sessions operated in pairs and promoted using test-driven development (writing the test first, confirm that the test fails, now write the smallest amount of code to make the test pass). I really do like the practises of pair programming and TDD, and it reminded me that it would be good to use these more in everyday work.

One rule of the day was “delete all your code at the end of each session”. It was curious how ‘wrong’ that felt. You are so used to saving and keeping stuff. It was probably a bit liberating too – after all while the code had gone, the experience and learning from the pairing session had not.

Even in such a small group there was a good mix of programming languages – Ruby, Java, JavaScript, C# (obviously) and even Elm. Sitting down with a fellow developer and working in an unfamiliar language was also both a challenge and a highlight.

Lunch was provided, and was a step up from the usual pizza fare. Very nice!

The most awesome lunch courtesy of Red Star Catering. #coderetreat #southstart pic.twitter.com/I4NMOb2BYL

— reinteractive (@reinteractive) October 22, 2016

After lunch we did more of a ‘mob programming’ style session lead by another attendee Richie. Still using the Game of Life problem, it was a great illustration of how important communication skills are, as we worked through coming to consensus on not only how we could approach the problem, but what were good names for things and what did those names actually mean (not surprising, considering naming is one of the two hard things in computer science).

Following that we did one more pairing session. This time each pair got to choose from a list of limitations. My partner had commented when we sat down together how much he appreciated his mouse and that was probably what prompted me to suggest we try the “only use your keyboard” challenge. We used Java in Eclipse and apart from an annoying splash screen that we had to resort to the mouse to make go away, we managed the rest of the session to stick to just typing. Not easy though.

The day ended with a final group review. I really enjoyed the day, appreciated learning some new skills and practising some old ones, and getting to know a great bunch of people.

NDC Sydney–Day 3

2016-08-06T16:10:00.001+09:30

Friday, the final day of NDC Sydney. I was rostered in Room 2 all day, so got to see these speakers/presentations:

Roslyn is @filip_woj's middle name #ndcsydney pic.twitter.com/cUe4msM4Xr

— David Gardiner (@DavidRGardiner) August 4, 2016

Micro services with @rachelreese. Did she fly here with https://t.co/JycJa6pQXP :-) #ndcsydney pic.twitter.com/5Fk6Rribz4

— David Gardiner (@DavidRGardiner) August 5, 2016

Micro services are the next big thing @samnewman #ndcsydney pic.twitter.com/xkW3DcoUbc

— David Gardiner (@DavidRGardiner) August 5, 2016

This talk from @JamesNK could make a good serial #ndcsydney pic.twitter.com/QYevNUNVDp

— David Gardiner (@DavidRGardiner) August 5, 2016

Me, me, me, me with @hhariri #ndcsydney

— David Gardiner (@DavidRGardiner) August 5, 2016

And then a late flight home to Adelaide Friday night.

NDC Sydney–Day 2

2016-08-04T21:42:00.001+09:30

Thursday sees me spending rostered the entire day in room 1. This was actually my preference, as the majority of the talks were already on my wish list. One slightly ‘down’ side of doing room 1 is that the bigger crowds mean counting much larger numbers of eval votes after each session.

Watching @troyhunt getting his son to do all the hard work :-) #ndcsydney pic.twitter.com/Nw6tXfcVsA

— David Gardiner (@DavidRGardiner) August 4, 2016

Cloudy in Sydney, but no rain on @shanselman #ndcsydney pic.twitter.com/27yjcfrlCp

— David Gardiner (@DavidRGardiner) August 4, 2016

ES6 with @rob_rich. It is not 45 degrees C in Sydney today! #ndcsydney pic.twitter.com/GjrNUPLY6a

— David Gardiner (@DavidRGardiner) August 4, 2016

He's being frank, but isn't his name @shanselman ? #ndcsydney pic.twitter.com/zTO5LMLRDM

— David Gardiner (@DavidRGardiner) August 4, 2016

The evening finished off with a hilarious talk from Assoc. Prof. James Mickens, followed by a social evening of food and drinks in the hotel bar – a good chance to meet and chat with other attendees.

One more day to go!

NDC Sydney–Day 1

2016-08-04T21:18:00.000+09:30

The first full day started with Scott Hanselman’s keynote, then straight into sessions. I was rostered to look after room in the morning, with the afternoon free to attend other sessions.

Here’s my photo tweet stream from the day:

#ndcsydney opening keynote with @shanselman pic.twitter.com/Wkyl0HAMYx

— David Gardiner (@DavidRGardiner) August 2, 2016

Omnisharp and Script C# with filip_woj at #ndcsydney pic.twitter.com/12vuNTl82N

— David Gardiner (@DavidRGardiner) August 3, 2016

Good to see @alexjmackey is both performing and stable #ndcsydney pic.twitter.com/26dhpsb2DX

— David Gardiner (@DavidRGardiner) August 3, 2016

I don't think @Aaronontheweb is acting. Talking about https://t.co/iR8Xop5OSH #ndcsydney :-) pic.twitter.com/O1H7BDvk6v

— David Gardiner (@DavidRGardiner) August 3, 2016

Now @Aaronontheweb is doing NBench presses #ndcsydney pic.twitter.com/JJGxLBJQoX

— David Gardiner (@DavidRGardiner) August 3, 2016

Automapped @jbogard solidly into #ndcsydney pic.twitter.com/XSjePDpToB

— David Gardiner (@DavidRGardiner) August 3, 2016

Enter the @OdeToCode dragon #ndcsydney pic.twitter.com/g3y1af0fY7

— David Gardiner (@DavidRGardiner) August 3, 2016

I had a quiet night back in the hotel room, though many attendees went on a harbour cruise. It had been quite wet and rainy, so I didn’t mind missing out on that.

The changing state of installers

2016-07-10T22:26:00.001+09:30

I’ve begun to notice that there’s somewhat of a gradual move away from MSI-style installers. This is an interesting change considering for a number of years now I’ve been a keen proponent of creating an MSI to package up your software and drive the installation process during deployment.

MSI (Windows Installer – previously Microsoft Installer) started life as the Office 2000 installer. Office was (and still is) quite a large and complex piece of software and I guess the development team realised they needed a slightly more reliable way to install all the bits in the right places.

This then evolved into a more general-purpose installer technology and was finally built right in to Windows itself as the preferred way to install applications and services.

So what’s changed?

MSI is great if you just need to install a single instance of an application. It is possible to handle multiple instances – for example SQL Server. If you’ve ever installed SQL you’ll know that you can use the setup program to install multiple instance of SQL Server. I recently learned through a question posed to a Reddit AMA that they use ‘Transforms’ for this. It is possible, but not super easy.

Then there’s Nano – Nano Server to be precise. This is the new super cut-down, minimalist edition of Windows Server, and one of the things that has been left out to keep it as lean as possible is MSI support. To build software for Nano, you’ll be packaging it up in an ‘appx’ file (essentially the same package used for Windows 8/10 UWP).

So who’s changed?

I noticed that JetBrains went to a non-MSI installer with their ReSharper 9.x release. They were already using NuGet packages for managing extensions. I think they’ve kind of gone the whole way with their installer now.

It also appears that Visual Studio “15” (not to be confused with the current 2015 release which is version 14) is moving to a non-MSI installer as part of reducing the install process.

ASP.NET for a while now has had the ‘msdeploy’ packaging. It’s what is used when you choose ‘Publish’ from the context menu in Visual Studio.

So what now?

MSI still has a role, especially for traditional server deployments, but if you want to support deployments to Nano then you’ll need to look at appx. If you have a desktop app that you’d like to feature in the Windows Store, then appx is also a requirement.

There’s currently a couple of options if you want to move towards appx deployments:

Project Centennial – aka the Desktop Converter for Win32 or .NET 4.6.1 apps. This is currently in preview (and requires that you run on a preview release of Windows 10).

WiX AppX Extension – a commercial product created by some of the main WiX developers that lets you leverage your existing WiX projects to produce an Appx package.

Analysing .NET code dependencies–Visual Studio Code Maps

2016-05-12T20:12:00.001+09:30

This is the second in a series of posts on reviewing tools to help analyse code dependencies in .NET

Code Maps is a feature that was first included in Visual Studio 2012 Ultimate. It remains an Enterprise-only feature in 2015, though Professional and Community editions can view previously created diagrams.

Code Maps operate from the cross-project solution level right down to the method level.

Dependencies

To generate a map of project dependencies, go to the Architecture menu, and choose Generate Code Map for Solution.

A new window opens and gradually items appear on the diagram. Usually this will trigger a build of the solution, and then the analysis process will run, eventually displaying the dependencies between the projects.

If your solution uses solution folders to group similar projects, then you’ll see that represented in the diagram (the OLW solution doesn’t currently do this).

You can then expand this out by selecting all the nodes (Ctrl-A) and choosing Group, Expand from the context menu.

You can see two things – the OpenLiveWriter.PostEditor project seems to be the most significant project, and also there’s an ‘Externals’ block with all external assembly references. To just focus on strictly code from the solution, you can select this group and press Delete. This removes it from the diagram.

Editing a Code Map diagram doesn’t mess with your source code, as the diagrams are a bit like a snapshot of your code at the time they were created. In some ways this is a limitation, but one positive aspect is that you can use Code Map diagrams to model or prototype changes to the class hierarchy and dependencies without having to commit those changes in code.

Let’s focus in on the PostEditor project. If we select that node, we can choose New Graph from the context menu. A separate diagram is now displayed with just the contents of the previously selected node. You can use the Filters tool window to select which elements you want to display. I de-selected Assembly so that I can now focus on the namespaces.

Let’s keep going further in. Select the OpenLiveWriter.PostEditor namespace, and open this in a new graph again. To drill down to the class level, select all nodes again (Ctrl-A) and choose Group, Expand again.

Let’s click on that top node – BlogPostEditingManager. Repeating the same process again, and filtering down to just methods, we get the following:

We now have a call graph of the methods inside the class. I also changed the layout for this graph to be ‘left to right’. The two blue nodes represent classes defined inside this class.

Usually, you’d expect to see public methods on the left, and non-public methods going to the right. Unfortunately there’s no way distinguish between them apart from hovering over a node and reading the tooltip that appears, or by selecting a node and reviewing the details in the Properties window.

Debugging

You can also display Code Maps while debugging. If you have stopped at a breakpoint, you can right-click and select Show Call Stack on Code Map.

Basically just a different way see the same info that gets displayed in the Call Stack debugging window, and unless I’ve missed something obvious, I think I’ll stick with the latter.

Summary

That’s a quick overview of some of the things that Code Maps can show you. They are entirely visual, so unlike NDepend, there’s no way to do any custom querying out of the box. On the other hand, the fact that the diagrams use DGML (directed graph markup language), it would be possible to write code that queried the file directly.

Analysing .NET code dependencies–Overview

2016-04-29T07:38:00.000+09:30

How can you tell if modules/components in your application are loosely-coupled between each other, and tightly cohesive internally? You could read the code line-by-line, but that becomes difficult once the codebase becomes large.

It can be very valuable to be able to visualise the the dependencies between the various components that make up your application – both at the class and module/assembly level. These tools analyse code, either by parsing the source code, or by analysing the compiled assemblies to produce various summaries and reports about the state of the code.

I’m planning to spend a bit of time in future blog posts reviewing a number of these tools that can help with this analysis, including:

I’m also interested to hear what you use. Let me know in the comments of your experiences with these or other tools I haven’t mentioned.

How I first heard about Lean

2016-03-15T20:54:00.001+10:30

A quick shout-out to Flinders Medical Centre’s Redesigning Care. They implemented Lean a few years ago to improve how their hospital functioned. After hearing about what Lean was and what they were doing, I then discovered that Lean had been applied to developing software too.

If you’re interested in learning more about Lean in a healthcare setting, contact them via their webpage, or check out their overview video on YouTube