Beginning modern application development with .NET Core – Part 0: What is .NET core?

This is the first post in a free series of tutorials on “Beginning modern application development with .NET Core”. To view the series, click here:

.NET Core is an exciting open source project from Microsoft that brings the power of the .NET development environment to all platforms without having to make use of a third party tool (like Mono). It is relatively new, with version 1 released in June 2016, and is fully supported by Microsoft as one of their first-class products.

The release of .NET Core brings with it a re-architected platform for creating modern applications that consists of the following components:

  • CoreCLR – the core compiler and base types for .NET programming languages (mostly written in C++).
  • CoreFX – the standard libraries, consisting of the main packages used in most applications.
  • DotNET CLI – a command line interface that brings powerful development tools to your favorite shells such as Bash and Powershell.
  • Roslyn – .NET compilers and code analysis platform that allows IDEs other than Visual Studio to provide a better development experience.

What’s different from the regular .NET Framework on Windows machines?

Well, to start with, .NET core runs on nearly all modern operating systems (including Mac, Linux, BSDs and Windows); so you can easily develop your software on Windows and deploy it to a Linux server (or vice-versa).

Secondly, .NET core applications are package based – so you pull in the libraries you need from a package manager and you don’t have to worry about installing the full .NET framework. Everything you need to run your application is shipped with it, making deployments easier to predict and making it simpler to keep all environments the same.

Finally, every component from the compiler to the standard library is open sourced; meaning if you face an issue you can very quickly raise it with Microsoft and community developers.

I’ve heard a lot about different “target platforms” – what are they?

When you develop a .NET core application or library you have the ability for it to target different platforms. There are three main ones, and each has a slightly different meaning or benefit to it than the others.

  • .NET Framework target – this targets the full .NET framework (i.e. .NET 4.6/7) that is only available on Windows operating systems and will therefore only run on environments where that runtime is present.
  • .NET Core target – this targets those applications that run on the .NET Core runtime.
  • .NET Standard target – (libraries only) this targets any runtime that is .NET standard compliant – if you’re using the most up to date frameworks, then you’ll be able to use projects that target this platform anywhere.

For example, if you created a .NET Core class library, you would only be able to use it in other projects that also target the .NET core platform.

However, if you created a .NET Standard class library, you would be able to use it within all projects that target a platform which complies with the .NET Standard.

I thought .NET core had migrated to using JSON files instead of .csproj files?

In the first few versions of .NET Core, the project setup and structure was indeed described within a project.json file. However, as .NET Core was adopted more widely within the eco-system, Microsoft needed a way for all platforms to work together, sharing one project file layout.

It was therefore decided that instead of modifying the tooling for all of these platforms to work with the new JSON format, the ones currently using it would be rolled back to utilise a modified .csproj XML format: one where the pain points experienced by many had been removed.

What will I miss if I migrate to .NET core?

There are a number of major items that are not available in .NET core.

  • WinForms – there is no WinForms support in .NET Core, so you will not be able to update your existing projects.
  • WPF – there is no WPF support in .NET Core, so you will not be able to update your existing projects.
  • WCF – it is currently not possible to create WCF services within a .NET Core application. You can still consume them using the WCF client libraries (, but if you want to build them you will need to target the full .NET Framework.
  • SignalR – neither the client or server libraries for SignalR are available in .NET Core (though they are scheduled for release with .NET Core 2.1).
  • AppDomains – AppDomains were discontinued as part of .NET Core.

How do I get started?

This post is the first of many in a series of how to begin modern application development with .NET. Follow along, and you too can build cross-platform applications with the newest framework from Microsoft.

Follow the series by bookmarking this tag. Alternatively, follow me on Twitter, where I will tweet whenever a new post goes live.

How to make your responsive mobile website hurt my heart

I think the most ironic part about responsive websites is that of the first word: responsive. It seems to have become a pattern wherein people take their over-complicated, bloated website: add a few media queries or use a few framework components and hide the elements that do not fit. The concept of optimising the website for mobile (which includes more than just the visible aspect) seems to have been ignored for about 70% of mobile websites I visit.

I was initially going to point out examples of bad responsive website designs: but, I’m not the internet police, nor am I always right; so it feels wrong to victimise websites that have made mistakes. Instead, I hope they read this article and think: “you know what? some of these apply to me”.

The points below are a collection of my most heineous annoyances with some modern, responsive mobile websites.

Unoptimised, image heavy pages

A mobile user’s worst nightmare: a page that loads multiple, large, unoptimised images on the page. Not only does it stop you looking for the content you visited the website for in the first place, it slows down the rendering of the finalised layout AND uses up your data allowance. If the web page has some sort of carousel without lazy loading, it wouldn’t take long to use up 10% of somebody’s 1GB allowance.

Synchronous web-fonts with no backups

Nothing is going to make a user as frustrated as them visiting your website, having the layout load and being unable to read any text. Why? The 23 fonts you are bringing in are done synchronously and without backups, making all text on the page invisible until the font files have finished loading in.

Research and multiple user experience tests online show that you have only a few seconds to capture your user’s interest: why would you waste that improperly loading a bunch of funky fonts?

Post-load DOM manipulation

So, the user waits the 5 seconds your site needs to load. They begin scrolling and suddenly, the entire page layout changes. Why? Because the desktop site that has been converted to a mobile site ends up getting “bodged” through Javascript to accomplish what should have been done properly in the first place.

Doing this is not only harmful for your end-user, but it also shows that you have a severe amount of technical debt surrounding your responsive mobile website (after all, if you’re having to resort to front-end hacks to accomplish something that could easily be done server-side, something is wrong).

Too much going on

The average modern mobile device has a screen size of around 5 inches. That means you have 5 inches of screen real-estate to fit your most important content on, regardless of the resolution of the phone. Too many websites fill this space with advertisements, pointless images and text that is irrellevant. If you purchased an advertisement board in your local super-market, would you waste 70% of your visible canvas on something that no-one will be interested in? No, you wouldn’t. So why should your home page be any different?

Scroll manipulation

Everybody knows their phone’s scroll speed, they know exactly how much of a swipe they need to make to get where they need to go. Websites that override this behaviour cause the user to get frustrated, something you cannot afford when first impressions count.

(this is also ridiculously annoying on desktop, but I’m trying very hard not to rant)

Sticky headers/footers

(thanks to drngdds for reminding me of this)

As mentioned previously, you have a limited amount of screen real-estate in which to sell your product/services/content or inform users of your goals. Having sticky headers or footers can take away this in-demand space and the focal points on your website. This will undoubtedly annoy your users, especially when the content they are trying to view is blocked by the header/footer elements.

This again is down to poor optimisation of the responsive mobile website; where elements are just hidden and no attention is paid to the experience the user will have on the website.

So – what can be done to solve these problems?

I think the solution to having an awful responsive website is to know your limits. If you begin experiencing performance or user experience issues with the “mobile view” of your responsive website: it’s time to make a change. Best practices are only best practices when they are applicable to you and your circumstances; they are not gospel. Release your website, speak to your users and adapt accordingly.

I really like the look of the accelerated mobile pages and the benefits they deliver, though I hate the idea of vendor lock-in and their ability to push their own agenda unknowingly onto their users. Instead, like the Wikimedia foundation are doing, I think it’s a good idea to implement their best practices in your own way. In short:

  • Render as much server-side content as you can.
  • Reduce/remove the third party dependencies you have on your pages.
  • Lazy load images whilst maintaining page layout.
  • Stop hacking fixes for your mistakes with Javascript.






The art of over-engineering your side projects

Many software engineers who develop software as a hobby often have side projects. The sad thing is, those software engineers often have the tendency to over-engineer their side projects, put all of their effort into mundane and, let’s be honest, pointless tasks and burn out before they’ve even finished their MVP.

Now, I don’t want to sound like a broken record, so I’m not going to preach ‘ship often’ to you, but I’m hoping that by reading this post you’ll be able to see the mistakes I used to make (and stop yourself from making them!).

Mistake 1 – Project managing

So, you have a great idea and a view of how you’re going to go about completing it. Logically, you will try to put together some sort of plan of approach. However, focus too much on this initial plan and you risk falling down the ‘project management’ rabbit hole: writing user stories, creating backlogs and finding tools for a project that you haven’t even started, let alone need copious amounts of rigid management for.

Solution: don’t try and project manage a non-existent project. Note down ideas and rough timelines – that’s it. If you start predicting what you’ll be doing in 2 months on the project, you’re not in Kansas anymore Dorothy.

Mistake 2 – Over-architecting infrastructure

You’re so hyped for this project and confident that it will succeed that you start thinking about the future: “how will I scale my application for the millions of users it will have?” “How do I ensure I have multi zoned redundancy?” “How do I keep 100% uptime? ”

“I know: I’ll create a triple zoned redundant architecture with pub/sub database replication, a 32 node Kubernetes cluster and private networking across all regions – that way, I can handle anything!”

Now, reading that – you might think it sounds ridiculous – and you’d be right. Scale the numbers down though and it will probably sound familiar. So many people are guilty of over-architecting their application’s infrastructure before they even have that application in a state for it to be deployed!

Solution: Develop your project. Then, put it on the bare minimum architecture that it can run on (be that a 512MB instance from DigitalOcean or a medium instance on AWS). As you get more users, monitor, and modify the infrastructure appropriately to account for load and redundancy.

Mistake 3 – Worrying about “tech stacks”

The majority of software engineers seem to be under the illusion that potential customers care about the stack they are running. They don’t. A customer will not know or care if you are using Ruby, Go, PHP or any other language as long as what you have written is performant and is fit for purpose (which all modern languages are).

Solution: Write in a language that  suits the task at hand and one that you are comfortable/experienced with.

Mistake 4 – Creating custom frameworks

Bootstrap? Too basic. Materialize? Too fat. Foundation? Nah. Better create my own.

A made up statement, but relatively common nevertheless. I have many-a-time started a new project, thought the statement previously and set out writing my own framework. By the time I had completed it, I no longer had any desire to work on the project I had thought of in the first place.

Solution: Use frameworks and customise them – only refactor/build your own when absolutely neccessary (and when you have appropriate metrics).

Mistake 5 – Continuously delivering nothing

Similar to the way you can easily over-architect your infrastructure, it’s extremely easy to over-architect your continuous delivery practices before you have anything to deliver! Jenkins, Drone, Travis are all great tools – but you shouldn’t spend time configuring them until you have a working MVP.

Solution: Build your project first – then worry about continuous delivery.

It’s easy to believe you’re doing the best for your project by doing the above things but you aren’t. The best thing you can do for your project is to market, market, market, and then do a bit of development.

Edit: as many people on HackerNews are pointing out, this article focuses more on side-projects that people wish to use to generate income or turn into successful lifestyle businesses. If you’re working on something personal (with no plan to monetise it in the short term) or just for fun, then as long as you’re happy doing it – who cares!