Mike Childs

Common Libraries – How to avoid Premature Optimisation

Common Libraries can be a great way to get a new project started and productive quickly, particularly for teams, or companies with a broad set of services on their books.

They can also be the source of a great amount of friction when done too early.

Premature Optimisation is the Root of all Evil – Donald Knuth

Before diving in and creating a new “Common” project ask yourself a few questions:

Do you understand the problem well enough to define an API appropriate for use across multiple projects?
Without anecdotally requiring a solution to a problem across multiple projects the answer to this is no. This is your starting point. Understand your requirements.
Do you understand the solution to your problem well enough to create an implementation that’s genuinely fit for purpose, won’t change every time a new project comes along, and is appropriate to cover the use case(s)?
Implement your solution at least twice alongside the problem. First time through by nature isn’t shared, second time through, tackle it in isolation to the first. Apply lessons learnt and refactor accordingly. Don’t create common projects with only one consumer, YAGNI (You aren’t gonna need it).
Code should follow the DRY (Don’t Repeat Yourself) Principle where possible, but do you understand whether the Repetition is truly a Repetition, or is it coincidental?
Microservice architectures aim to create isolated deployable units, be mindful of binding solutions together at points that shouldn’t be there through shared code artefacts. Understand your service architecture and adhere to their interface.
Do you have a clear way to deploy change to your common code? Should your update be implicit or explicit?
Internal Nuget Feeds are a great way to share code, less great ways could be SVN Externals or sharing DLL’s, wouldn’t advocate this but it does happen. Understand what will work best for your environment. Should your changes be rolled out across the board, or should they be opted in for through a new version of a package?
Do you understand the impact of change on consumers? Will “just” adding an extra enum value cause all of your other consumers to come grinding to a halt? What will happen if you add an external dependency?
A healthy set of unit tests should go some way to covering this. Always be mindful of supporting the lowest common denominator and plan an integration strategy accordingly. Nuget is great at managing version mismatches across dependencies, and takes away a lot of the pain, this doesn’t mean it shouldn’t be a consideration.

Common Libraries, when done well, can enhance efficiency. They can also easily get out of hand. All code is Legacy Code once it’s been committed, it’s crucial that shared components be maintained and understood by the team, both in their implementation and integration to the services they’re used in.

Have you ever found yourself slowed down by attempting to share code? What issues have you experienced?

Local Project with Nuget Package References – System.IO.FileNotFoundException

One of the features introduced with .Net Standard Projects was the definition of Nuget Package Dependecies via Package Reference tags in the csproj file and the removal of the packages.config. There are however some issues when referring to a local project via a Project Reference using the packages.config (.Net Framework app using the legacy csproj), where the referenced project has dependencies on a Nuget Package via a Package Reference.

System.IO.FileNotFoundException: 'Could not load file or assembly 'Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed' or one of its dependencies. The system cannot find the file specified.'

The dependent DLLs aren’t where the Application expects them to be because they aren’t being referenced consistently throughout the application.

Scenario

SolutionStructure — Nuget Package Reference

NugetPackageReference.Console – .Net Framework Application referencing local project NugetPackageReference.Dependent

NugetPackageReference.Dependent – .Net Standard Project referencing Nuget Package Newtonsoft.Json

DependentClass.cs – uses anything from Nuget Package

namespace NugetPackageReference.Dependent
{
    public class DependentClass
    {
        public string NewtonsoftJsonNull()
        {
            return Newtonsoft.Json.JsonConvert.Null;
        }
    }
}

Program.cs – calls method referring to Nuget Package

using NugetPackageReference.Dependent;

namespace NugetPackageReference.Console
{
    class Program
    {
        static void Main(string[] args)
        {
            var dependentClass = new DependentClass();

            var nullString = dependentClass.NewtonsoftJsonNull();
        }
    }
}

This will give you…

File Not Found Exception — System.IO.FileNotFoundException

Resolution

Option One – Reference Package

Add a Nuget reference to the Root Project to the missing Package.

Option Two – Migrate Packages.config to PackageReference

There is a tool in Visual Studio to migrate package references to the csproj file, however it doesn’t currently work for all Project Types, (Service Fabric applications using .Net Framework, WPF for example). This method is preferable. If your project falls into this category the only way I know of to resolve the issue is Option One.

Right Click the packages.config file and select Migrate packages.config to PackageReference…

Having done this the root project will now resolve dependencies further down the tree through the PackageReferences.

Summary

Microsoft have given us a great way of migrating towards .Net Core while being able to retain business logic from existing .Net Framework applications. The integration of these components can be complex however and initially, isn’t quite foolproof.

What issues have you faced migrating towards .Net Core?

Do you know of a better way to solve this for legacy projects?

Adventures : Snowdon

This year I’ve decided to become more active.

Since the turn of the year I’ve been going to the Gym most days. It’s a bit of a cliché but it has noticeably made me feel more energetic and affords time for reflection.

Anyway, this weekend my friends invited me to go on a trip up Snowdon. Having never really done anything like this before it was a good opportunity to get outdoors.

Armed with a new(ish) pair of boots and a new coat, off I went.

CarrionBird — From the outset the Carrion birds were circling, but they didn’t get their feast, not from me at least…

It was always going to be a gamble climbing a mountain in Wales in early March, and we did succumb to the conditions in the end. There was still snow at the peak, having passed a sign stating that Crampons and an Ice Axe were “essential”, we went as far as we could without the necessary Adventure Gadgetry, which according to the more prepared climbers coming back the other way was around another half an hour battling through the snow to the summit.

Though we didn’t make it to the top it was still a great challenge, and certainly pushed us. I’m hoping to come back and conquer it some time.

When have you pushed yourself, in work or otherwise? What targets have you set yourself?

Development Team Membership : Part 3 – Competition

There is a thin line between healthy and unhealthy competition. Competition can lead to self-improvement, which is great, but it can also be detrimental. Slow down, ask yourself a few questions:

Who are you competing against?

Competition in the Animal Kingdom is a natural instinct, see tongue in cheek Lion King example. Competition to be King helped no one in this instance. As humans we may feel pushed to tackle those ahead of us in whatever hierarchy situation we may find ourselves in, but we’ve also been blessed with the presence of mind to make a more informed decision about how this will impact those around us. In a team situation Collaboration normally trumps Competition.

What are you competing for and how?

It’s worth getting clear what it is you are competing for, this will be clear in a race where you have defined parameters and a clear understanding of the rules. The same is not true of the workplace where you may be competing (silently) against other people for a promotion. It’s easy for this situation to become unhealthy competition. An unhealthy way to approach this is to belittle others achievements in order to make your own more pronounced. Best case here is that you get the promotion, but your new “team” will know what you did to get there. Impressing through your own abilities, and respect for others is a more noble route to the same thing, there’s no real shortcuts here. It’s good to point out your own successes, but don’t try to tread on others, again, see Lion King.

Does anyone win in your Competition?

Competition can be a catalyst for self improvement, if you’ve picked the what and the how well.

Who can write the most lines of code in a sprint?

Imagine this competition, what are you really achieving? No one wins in a headbutt!

Team Dynamic

Motivation is really closely linked to Competition in many ways, but it can also be a bit of a minefield when it comes to competition within teams. Everyone has their own goals, but it’s great if these personal goals can align with the goals of the wider team. I’ve previously mentioned the idea of letting go. Losing the mental baggage that unhealthy competition carries will let you focus on bettering yourself. I’ve recently been doing this exercise myself.

Agile : The Circuit

Ohm’s law defines the relationship between the voltage, current, and resistance in an electric circuit: i = v/r. The current is directly proportional to the voltage and inversely proportional to the resistance.

Agile from a business perspective is all about zoning in on what it is that is really required to offer the highest business benefit, in the shortest space of time, a.k.a. finding your Minimum Viable Product (MVP).

There can be a lot of ceremony in Agile, I get the impression that this is what takes the front seat in people’s minds, particularly those that would consider themselves “non-technical”.

Agile, to a Developer, should be about far more than just daily Stand-ups and Retrospectives. Agile is a mindset and an approach, focusing on improvement, reducing your resistance.

It’s vital that any improvement you identify gets fed back into future sprints, like electrons flying round a circuit, this is what keeps the lights on.

Your backlog is your potential, like a battery, keep this topped up with ideas, both business, and technical and you will be able to run indefinitely.

Your voltage (potential difference), is what you can achieve between your two fixed points, start and end of the sprint; with your throughput, current, being everything you can potentially achieve, relative to your impedance.

As responsible Developers, we should be maximising output, and identifying and feeding back on anything that can possibly reduce our resistance. Sure there will be no surprises here, but:

Improving build/deployment processes can help greatly, with DevOps as a discipline justifiably being huge business now;
Refactoring our code can make it more malleable and open to change, again another Agile principle, see Software Craftsmanship;
Scope changes mid-sprint can be a huge impact to output, this may not be fully understood by business owners, it’s important to feed this back, we would know about it if we waste their time, the opposite should also hold true (communication, and a good rapport is key here!).

Think about what you can do within your team to reduce your resistance and increase your output. Talk it through with your peers and make a list of improvements you’d like to make, over time it’ll make your bulb glow brighter.

Development Team Membership : Part 1 – Moaning

I recently made the transition from Permanent Employment to the world of IT Contracting. Along with this change, came a different role for me with my new client; a much more hands on position writing a lot more code which is exactly where I wanted to be!

I previously wrote a series of Blog Posts providing tips for Development Team Leadership, this has dried up of late due to my change in circumstance, however I would like to now start sharing some tips for Development Team Membership, having worked on both sides of the fence.

Don’t moan without a resolution

Moaning is great. Everyone loves a good moan, myself included. Moaning can be helpful and healthy, in fact indirectly it’s part of the agile feedback loop, what went well, what didn’t. Accompanying this, should always be next steps; how to negate what grievances you may have.

There’s definitely a right time and a place for ~~moaning~~ sharing your observations in the context of your team, you’ll be best placed to know when this is, but it may typically be a team retrospective, a workshop on where your team is heading or a one on one, planned or impromptu session with your mentor/lead.

As a software professional, keep it impersonal. You won’t want to come across as a bully, picking out specific people’s faults or shortcomings is never helpful. Code reviews should be used to increase code quality, but be cognisant of their feelings and how you may be perceived.

Mr Muscle, loves the jobs you hate

You can’t always have the glamorous roles in the team, sometimes you just need to roll up your sleeves and get stuck in. As a good team player you should have no qualms in doing the grunt work. Grunt work leads to insight, and insight can lead to improvement in process. Developers are lazy, and that’s no bad thing. Do something once, do something twice and automate.

Don’t shy away from hard work.

Improvements Log

You’re the one with the low level knowledge of your application(s), any potential improvements that don’t fit within the confines of the piece you’re working on should be logged, to be addressed at an appropriate time.

This will serve to broaden the teams understanding of how they should all be writing software, e.g. coding standards/patterns, and, in the same way that code reviews serve to manage quality going in to an application. Improvements serve to keep the application up to date. As soon as it’s committed, code becomes legacy, it’s a valuable resource and an opportunity to improve, it, and yourself as time passes.

An improvements log can serve as a satisfying alternative to a good rant. Log it and move on, your lead should be monitoring the situation and pushing things forward.

Holiday Reading : Cyprus

I spent the past couple of weeks in sunny (excruciatingly hot) Paphos, Cyprus. In a similar vein to last year’s Holiday Reading : Lanzarote, I took a lot of reading material with me…

With the exception of Sharp Ends they are all quite old books that I had never got round to reading.

Books

Sharp Ends – Having read all of Joe Abercrombie’s other books this latest collection of short stories was recently released, thankfully in time for my holiday. It didn’t pull me in quite so far as the other books, but such is the nature of the short story beast. It’s always great fun reading about “The Bloody Nine” and the new characters introduced left me wanting more. Hopefully more is in the pipeline.

The Da Vinci Code – I watched the Da Vinci Code film many years back. Aside from vaguely remembering there was a blonde monk who enjoyed whipping himself, all other details had been lost. I read Angels and Demons recently and decided to continue with The Da Vinci Code. It’s fascinating how Dan Brown mixes history with story.

The Moon of Gomrath – This is another old book from the 60s, I read the Owl Service last year, and subsequently Elidor. Fast paced high fantasy, not a long read and won’t be for everyone. If you like Wizards, Cat Armies, Dwarves, Elves, Possession and Witches you’ll like this one.

Adrian Mole – Sparked by a recent conversation in the pub with a couple of friends I decided to revisit Adrian Mole’s Diary. The stories are hilarious and level of detail make it so easy to relate to.

The Restaurant at the End of the Universe (Hitchhiker’s Guide Book 2) – Another Comedy classic, Hitchhiker’s guide will no doubt be familiar with a majority of the audience likely to be reading this blog given the subject matter. The humour is incredibly sharp and had me chuckling to myself (and groaning) throughout.

Web API Tutorials Part 5 : Azure Deployment from Visual Studio

Microsoft have made it extremely easy, almost trivial to deploy your web applications to the Azure cloud from Visual Studio. Cloud capability is incredibly powerful for scalability, particularly in enterprise level applications and affords Developers with the option to make their infrastructure as Agile as their Software.

Outcome

By the end of this tutorial, we’ll have deployed our Web Application directly into a Web Site in Azure using their Platform as a Service offering (PaaS), meaning we don’t need to worry about a Virtual Machine, updates, and a myriad of other concerns. Continue reading “Web API Tutorials Part 5 : Azure Deployment from Visual Studio”

Web API Tutorials Part 4 : Controller Attribute Based Routing

Web API offers some powerful routing behaviour. Let’s look at how we can use this in our app to avoid needing a new Controller for every Translation we wish to offer (again, ignore the fact our sample is likely only ever to require two way!).

We currently have a single AlphabetToMorseController with our old ITranslator implementation. In the previous tutorial we abstracted our service into an extensible dictionary, this should allow us to take our Translator Key as a routing parameter and our string to translate as a parameter in the URI on our API.

Outcome

By the end of the post we’ll have refactored the existing AlphabetToMorseController to a generic TranslatorController, with our ITranslatorService being injected. The Key will be provided through a Web API Route, and the Get Requested to the Controller will return a collection of available Translators. Continue reading “Web API Tutorials Part 4 : Controller Attribute Based Routing”

SqlBulkCopyCat

I set myself a personal goal recently…

…publish a Library on NuGet. So that’s exactly what I’ve done.

SqlBulkCopyCat is a configurable wrapper around SqlBulkCopy in .NET for SQL Server, born out of a personal frustration at work of being pushed towards using SQL Server Integration Services (SSIS) for copying large amounts of data between databases with no real alternative for anything robust without the baggage of taking on SSIS dependencies and the associated bloat in the Development Environment.

Continue reading “SqlBulkCopyCat”