Category Archives: software development

image

A UI lesson: do not ask users to choose between Register and Login

I am developing a web site for playing bridge, a project which kicked off in March when lockdown caused bridge clubs everywhere to close. There are lots of sites where you can play bridge online, but not many options (particularly back in March) for clubs that wanted to run their own online sessions.

It’s going OK with a number of clubs now using it every week, though it is still in development. I have learned a painful lesson though. In order to proceed as quickly as possible, I started my project with the Visual Studio template for an ASP.Net Core application with ASP.NET Core Identity – the latter an easy decision since it handles all the complications of registration, password reset and so on. (I did end up having to re-plumb it to use int rather than GUID for the primary key but that is another story).

The default home page the template generates looks like this, with options in the menu to Register or Login.

image

Registration and login are fundamental concepts that have been part of the web forever. It’s simple for a developer to understand: you register to create an account, you login if you already have an account.

The painful discovery is that this is not obvious to everyone, particularly to an older demographic that did not grow up with computers. Another factor is that cookies, browser-saved passwords and single sign-on with Google/Facebook etc means that this whole area is a bit of a mess and there are people who just kinda expect web sites to know who they are (which in one way horrifies me but I do see the massive convenience).

The consequence is that a surprising (to me) number of people had difficulty knowing whether Registration or Login was what they needed. They would Register, then return to the site and hit Register again. Why is this site asking for my details again? Maybe a security thing? Oh no, why does it now say username not available?

This is because asking the user to make this choice is not good design. Registration is rare, login is common. Further, Register is a confusing word. We sometimes use the word register when accounts already exist. Create Account is better. And a better UI is just Login. I need to access this website. Then, underneath the username/password request, an option that says “I need to create an account”. The two options should not be equally prominent; and if you look at how many prominent sites design this, that is what they do:

image image

Lesson learned; but I wish this had occurred to me sooner!

Point-in-time restore: a handy built-in feature in Azure SQL

I am working on a project that is hosted in Azure and I made a mistake, running a SQL script that was dependent on another SQL script that I had forgotten to run. It messed up the foreign keys and I would have to restore a backup … but my most recent backup was from the day before. Annoying.

But wait. Looking the Azure portal I saw this:

image

This is a plain Azure SQL instance with no extras, but look, you can restore the database from 6 minutes ago.

I did it; it restored to a second database. I deleted the bad one, renamed the restored one, ran my scripts in the right order, and all was well.

I recommend you do not run scripts in the wrong order … but if you do, or make some other error, this is a handy feature of Azure SQL which I was not aware of before.

Developing software for playing bridge

I am a duplicate bridge player in my spare time and enjoyed playing in my local club once or twice a week. That was before COVID-19 and then, in March this year, lockdown. Bridge clubs were no longer able to meet. There are more important things in the world; but bridge is both a lot of fun and a welcome distraction from weightier matters, and my thoughts soon turned to what we could do to continue playing in these new circumstances.

The answer was to play online; but while there are plenty of ways to play bridge online, the existing systems were not designed with the idea of being a way for bridge clubs to meet in a new context. If anything, the reverse is true: online bridge site were designed for people who could not easily get to a club or wanted to play at any time with whoever else happened to be available. Clubs like my own, by contrast, wanted to replicate their face-to-face meetings with an online equivalent. A further complication back in March was that the biggest online bridge site, called Bridgebase, was immediately overloaded and declared that it was unwilling to allow new people to qualify as directors, people allowed to run online bridge sessions.

My immediate instinct was to build a new site for playing bridge. I was not quite starting from scratch. Back in the early days of Windows 8, I started work on a bridge game for Microsoft’s new and as it turned out ill-fated platform. I had got some way with it; I had created a bridge engine that understood about cards and hands and tricks and shuffling and scoring and all the various elements that go into playing bridge. It was written in C# and what is now UWP XAML. It is designed of course for a solo player. Here is the bidding screen:

image

and the play screen:

image

This is how it looks on Windows 10; it looked a bit better on Windows 8 though it would not win any prizes for design. My software could play bridge though; the reason I never finished it was that I never cracked getting the AI working. But for human to human play that did not matter. A weekend or two coding, I thought, and I could have a website up and running so our club could play bridge online. I made an immediate start, registering the domain name YourBridgeClubOnline.co.uk.

Well, three months later and here we are.

image

image

It is, I have to say, still under development. But it works and we have been able to play bridge again, as a club.

What took you so long? Ha! Much of my old bridge engine code remains untouched and has proved useful; it all runs fine on .NET Core. Even the (useless) AI has been handy, as I can test the mechanics of play without involving others. But I had, of course, wildly underestimated the problem of converting a game for solo play on Windows, to a multi-player web application. There is much to think about:

The UI. I am not a designer (I am sure you can tell) but spent ages puzzling over how to get a workable user interface in the browser for everything from tablets to desktops. Not smartphones yet but it is coming. I decided early on to take a view on compatibility. No Internet Explorer. JavaScript fetch API is required. When time is against you, it is easier to say, just use another browser, than to waste too much time supporting old browsers.

Messaging – both the API kind, and the chat kind. I am using C#, ASP.NET Core and SignalR. In general it works well. SignalR uses WebSockets as first preference, but falls back to Server Sent Events or long polling where necessary. In my first experiments I did my own polling and switching to SignalR was a great relief.

Registration and login. I am using the stuff that comes in the box, ASP.NET Core Identity. It has saved me a ton of work. It’s a bit annoying and not too well documented. I don’t really like using GUIDs for the primary key, for example, and I believe there is way to avoid it, but it isn’t top priority when you are going for Minimum Viable Product.

JavaScript. I’ve written tons of it and I don’t even like the language. I have a new respect for it though. The thing is, it is very fast and there is nothing you cannot do. The worst thing is the friction of doing some debugging in the browser, and some in Visual Studio. I am thinking of switching to VS Code for development since it works nicely with ASP.NET Core and is better for JavaScript than Visual Studio.

Scoring. My Windows software could score a hand of bridge. But duplicate is different; you have to compare the scores with others who played the same hands and work out the percentages, then export the results to standard formats for display on club websites and submission to the English Bridge Union. It was more work than I had expected and I am not done yet; the system only understands Pairs at the moment, not Teams (a different way of scoring).

Directing. Someone has to manage an online bridge session, settle any arguments, and fix errors like cards played by accident. It all needs coding and there was nothing like it in the Windows version.

Movements. Imagine you have 28 people playing bridge (or 14 pairs). They need to all play the same hands, but never play the same hand twice, and it has to be so arranged that each pair plays against other pairs in a defined sequence so it is balanced and fair. We call this the movement. Online, you have a bit more flexibility because you don’t need to share physical cards: everyone can play the same hand at the same time if you like. It is still quite fiddly though, and I did not do any of this in the old Windows version. I saved some time by writing an import function to enable re-use of movements made for EBUScore, a widely used scoring and bridge session management application. There is more to do though.

Claims. This is where, half way through the hand, a player says, “There’s no point in playing on, I’m obviously going to win all the remaining tricks.” A trick is a sequence of four cards played one from each hand, which is won by one of the pairs. This statement is called a claim, and has to be agreed by the other players. Getting this working was more difficult than I had expected – because built into my bridge engine was the idea that you could score by counting the tricks each side had won. But claimed tricks are never played. With hindsight, I should have allowed for this from the beginning.

Database. Every detail of play has to be stored on the server. I am using Dapper and SQL Server currently, though it is possible that PostgreSQL would work just as well. I started with Entity Framework Core, still there as it is used by ASP.NET Core Identity, but I am happier with Dapper.

Things that worked well

Three months is longer than I had thought it would take to get to a playable system, but I suppose as a spare time project it is not too bad. It would not be possible without the likes of ASP.NET Core and Dapper and SignalR doing so much for you. C# is a delight for coding. I am also using an Azure App Service for all this test and development and that has worked well. I am deploying to a Linux container of course; but the nice thing about App Service is that it will scale to a considerable extent without the hassle of Kubernetes. If the project succeeds and needs to scale up, there is an Azure SignalR service ready and waiting. I was nevertheless interested to see that AWS now offers .NET Core on Elastic Beanstalk, complete with some nice Visual Studio integration. Trying it there would be an interesting experiment, though I’m not sure AWS is so savvy about SignalR.

Open Source?

Could this have been done quicker by making it open source and seeking collaborators early on? Will it become open source? I need help for sure, though I also feel the code needs some cleaning up before it is fit to share more widely. You will recall though that I had started out thinking that it would be a small matter to convert my solo bridge game to an online multiplayer web application. I figured it would be better to get something working and then ask for help. But I am open to offers! Note: this is not a commercial project.

Rewarding

Most of the software projects I have been involved in have been business applications. Bridge is a lot more fun. I do see software development as a creative act. I recall starting work on the bridge game back in 2011 (I think); starting a new blank project in Visual Studio and thinking, hmm, I had better write a class to represent a pack of cards. From that beginning I ended up with an application that could play bridge, after a fashion, and now one that multiple people can play concurrently. It is rewarding and I will not regret the time spent on it, irrespective of how much actual use it gets.

StackOverflow survey 2020

The StackOverflow developer survey 2020 is out – surveys come out constantly but this one is worth more than most because of the huge reach of StackOverflow among developers. This one has 65,000 responses.  Every survey also has reasons why it is unrepresentative; there is no such thing as a definitive survey because you can never precisely compare like with like, humans are unreliable, and every sample has its biases. Every wondered what a survey of “developers who never respond to surveys” would look like, if you could cajole them into answering questions? I have.

image

Imperfect then, but still interesting. What is notable in this one? The questions that interest me are those in the technology section. I am also more interested in trends than in absolute rankings, because it is the trends that might tell us something about the future. So let’s have a look.

In “Most popular programming languages” the interesting stuff is well down the rankings, since the top places are little changed. Dart has gone from 1.9% last year to 4.0% this year; still small, but that is more than 100% growth, thanks no doubt to Flutter. Rust has also grown, from 3.2% to 5.1%. Swift has fallen slightly, from 6.6% to 5.9%. This no longer seems likely to become a top programming language, important though it is for macOS and iOS. Objective-C is down a bit too (4.8% to 4.1%) and I wonder if this suggests greater interest in cross-platform toolkits and/or web technologies for Apple platforms. Such as Flutter, of course.

What about web frameworks? React.js is up a bit, from 31.3% to 35.9%, and to my mind it does look all-conquering at the moment. jQuery is above it, but that is nonsense really, as jQuery is not an alternative to React.js, being more a low-level plumbing thing. The figures for both Angular and ASP.NET are confusing as hell, since last year there was no separate entry for ASP.NET Core, but this year there is; and this year Angular is split between Angular and Angular.js. So we cannot conclude anything about these technologies. There are signs of growth in JAMstack frameworks. Vue.js is up from 15.2% to 17.3% and Gatsby makes an appearance this year at 4.0%

In “Other frameworks” we see .NET down a little but .NET Core up a little, so probably no change there. Flutter up from 3.4% to 7.2% as noted above. Xamarin down a bit, from 6.5% to 5.8%. Xamarin has not been as popular as I had expected it to become when Microsoft acquired it; the reason seems obvious, which is that Microsoft has given developers mixed messages about whether to use it, with the Windows and Office teams seemingly preferring React Native.

In databases, PostreSQL had another good year, rising from 34.3% to 38.5%. More than MySQL, it seems a natural destination for those migrating from Microsoft SQL Server or Oracle. Though note too that SQL Server is up, from 32.8% to 34.8%. Microsoft pushes developers strongly towards SQL Server in its developer tools and frameworks, and the strategy seems to work (plus it is a pretty good database manager).

In platforms, both Linux and Windows have increased use among developers. Not so surprising when you consider that Microsoft now ships the Linux kernel with Windows 10. MacOS is going in the right direction too, from 22.2% to 24.0%.

StackOverflow stuffs cloud platforms into this part of the survey too, as well as things like WordPress (talk about not comparing like with like!). Still, note that AWS is up from 26.6% to 26.7% (well, hardly moved); Azure is up from 11.9% to 14.5%; and Google Cloud (GCP) from 12.4% to 14.1%. Oh yes, and Kubernetes is here too, up from 8.5% to 11.5%. All of this chimes with my perception that GCP is doing pretty well from a developer perspective, now only just behind Azure in this particular community.

Then there is the entertaining most loved, dreaded and wanted. Rust is still move loved by miles (86.1%, up from 83.5% last year). Not much else I want to say about this section, other than to note that Python tops the “most wanted” list by a bigger margin (30.0% up from 25.7%); and poor old VBA continues to be “most dreaded”, again by a bigger margin (80.4% up from 75.2%).

In web frameworks, the good news for .NET developers is that ASP.NET Core now tops the list of “Most loved”, whereas ASP.NET is well down the list (36.9%). Again you cannot really compare with last year. Angular.js (the old version) tops the list of “Most dreaded”.

Similarly, .NET Core tops the list of most loved “other frameworks, libraries and tools” at 71.5%, though it only manages  8.3% in “Most wanted.” Translation: .NET Core developers love it, but it is still not doing that well in terms of appeal to those not currently using it. Chef should be asking itself why it is top of “Most dreaded” for two years running, in fact more dreaded than last year (72.4% up from 66.7%). Puppet is not far behind. Ansible seems both better liked and less dreaded by developers.

The “Most dreaded platforms” list is also notable, with WordPress at the top (PHP spaghetti anyone?) and IBM “Cloud or Watson” second, both positions unchanged from last year.  Android as overtaken Windows as the most dreaded operating system. All the top cloud platforms are more dreaded than last year, and so is Kubernetes.

Make of all that what you will. The survey seems to me valuable as evidence of things we already know, but there are no huge surprises – and why should there be?

The future of WPF for developers who need to support Windows 7

If you talk to Microsoft about what is new for Windows Presentation Foundation (WPF), a framework for Windows desktop applications, the answer tends to revolve around the Windows UI Library (WinUI), user interface controls for the Universal Windows Platform and therefore Windows 10, which you can use with WPF. That is no use if you need to compile applications that work on Windows 7. Is WPF on Windows 7 in effect frozen?

Not quite. First, note that WPF (and Windows Forms) was updated for .NET Framework 4.8, with High DPI enhancements and bug fixes. The complete list of fixes is here. So there have been recent updates.

Microsoft says though that .NET Framework 4.8 is the “last major version” of .NET Framework. This suggests that WPF on .NET Framework will not change much in future. WPF is open source; but the open source project targets .NET Core, the cross-platform version of .NET. In addition, there are a few features in WPF for .NET Framework that will never be ported, including XBAPs (XAML Browser Applications) – probably not something you care about.

The good news though is that .NET Core does run on Windows 7 (currently SP1 is required). You can see the progress of WPF on .NET Core here. It is not yet done and there are a few things that will never be supported. But when this is production-ready, it is likely that the open source WPF will run on Windows 7 and thus benefit from any updates and fixes made to the code.

From what I have learned here at Build, Microsoft’s developer conference, it is that .NET Core work that is currently top of mind for the WPF team. This means that WPF on Windows 7 does have a future – provided that .NET Core continues to support Windows 7. This proviso is important, since it is the decision of a different team. At some point there will be a version of .NET Core that does not support Windows 7, and that will be the moment when WPF cannot really progress on that operating system.

There may also be a special case. Presuming Edge Chromium runs on Windows 7, WPF may get a new Edge-based WebView control that runs on Windows 7.

Summary: WPF (and Windows Forms) on .NET Framework is not going to change much in future. If you can transition to using these frameworks on .NET Core though, there is more hope of improvements, though there is no magic that will make Windows 10 features available on Windows 7.

Stack Overflow survey shows leap in popularity for Visual Studio Code

Stack Overflow has released the results of its annual developer survey. I took a quick look, comparing the figures to those for 2018.

The survey is based on results from 88,883 developers from 179 countries. 400 responses were excluded because they took less than 3 minutes to complete!

A few things caught my eye.

Visual Studio Code is the most popular development tool, with over 50% of developers saying they use it. This is up from 34.9% last year. Visual Studio (which I guess includes Visual Studio for Mac) is second but has gone down from 34.3% to 31.5%.

image

Visual Studio Code is an amazing success; it is only four years old. What is the benefit to Microsoft though? There must be some benefit via the branding and gentle steers towards Microsoft services such as Azure; but this is mainly about Microsoft delivering a great free and open source developer tool and getting kudos in return.

Few other technologies have moved by such a dramatic amount. JavaScript remains top in languages but slightly down, 69.8% to 67.8%. Python is gently up, 38.8% to 41.7%. C# slightly down, 34.4% to 31%. Swift is down a bit, 8.1% to 6.6%, which is a little surprising to me.

TypeScript is up from 17.4% to 21.2%. Another impressive open source project from Microsoft and the great Anders Hejlsberg (Object Pascal, Delphi, C#, TypeScript).

In frameworks, last year StackOverflow had a single category for .NET Core (27.2%) while ignoring .NET Framework. This year it has 23.7% for .NET Core and 37.4% for .NET – no trends are therefore visible but next year perhaps.

There is an overly broad platform category including everything from Raspberry Pi to WordPress to AWS. I do not have much confidence in these figures, but notice that AWS is up from 24.1% to 29.5%, Google Cloud Platform up from 8% to 12.8%, and Azure up from 11% to  11.9%. Not good figures for Azure, now third behind AWS and Google. But Microsoft can take comfort from Windows, supposedly up from 35.4% to 50.7%.

Both Android (29% to 27%) and iOS (15.5% to 13%) are down slightly. I do not think this is meaningful movement but it does suggest that mobile app development is not longer a big growth area; perhaps there is more attention being paid to server apps.

Progressive Delivery: the next step in DevOps?

I attended the always-excellent QCon developer conference in London earlier this week. James Governor from Redmonk what there, presenting what he calls Progressive Delivery, the idea being that rather than rolling out continuous and (mostly) small changes to everyone, you segment your deployments. Progressive deployment, see.

image

It is not really a new idea and might even be considered a rediscovery of what we already knew: that it makes sense to deploy new stuff to a small sample first. However it is true that tools are constantly evolving, and Progressive Delivery is perhaps best seen as a necessary refinement to the Continuous Delivery concept. In particular, LaunchDarkly exhibited at QCon; the product is a feature management platform which lets you create groups of users and toggle features on or off for particular groups. Needless to say, the LaunchDarkly folk love the Progressive Delivery concept.

Why Progressive Delivery? My first reaction is that this is about caution: if stuff breaks, let us make sure it only breaks for a few users. Then I saw that it can be equally about bold experimentation, trying new ideas with small groups so you can observe what works and what does not.

Of course you can do this anyway and in the end there is no magic in LaunchDarkly; it is still down to the developer to write the code:

image

This stuff can also easily become non-trivial; one attendee asked about managing database structure and it is obvious that not all features are equally amenable to being switched on or off for groups of users.

Still, I reckon “how do you manage features?” is a good question to add to the list when considering DevOps tools.

You can read most of what Governor talked about in his post from last year here.

Adding a Visual Studio code workspace to a GitHub repository

Rather to my surprise, I am currently spending more of my development time in Visual Studio Code than in Visual Studio. There are a few reasons:

– I am working on a Java project and chose to use VS Code in part as a learning exercise

– I have a PHP website and have worked out a nice debugging environment using VS Code and WSL (Windows Subsystem for Linux)

– I am finding VS Code handy as a general-purpose editor

How about source control though? I guess as you would expect from Microsoft (which now owns GitHub) the git support is built in. So this is how I moved my PHP website, which was not under source control, to a private GitHub repository:

1. In VS Code, open the workspace and press Ctrl-Shift-G or click the Source control icon. Click the repository icon for Initialize Repository:

image

Then select your workspace from the dropdown and the local repository is created.

Initially all your files are in an unstaged state. Staging in git is where you define which changes will be committed in your next commit. We want to commit everything to form the initial repo, so drop down the git menu (three dots to the right of the source control pane) and choose Commit all, click Yes.

image

Type a commit message and go.

Now go to GitHub and create a new repository.

image

This is a private repository as nobody else needs to see the code for my website.

The repository is created, and right there on the default help page is the command for pushing your existing repo to GitHub.

Just open a terminal and paste the command:

git remote add origin https://github.com/[your repo name]

git push -u origin master

After the second command you will be prompted to login to GitHub. This creates an access token.

Done! If you go back to the repo on GitHub you will find it populated with your files.

A similar workflow applies if you use Azure DevOps. The choice is yours; the features of the two services are different but if all you want is source code management GitHub seems the obvious choice.

Which application platform for desktop Windows apps? Microsoft has stated its official line, but UWP is still not compelling

One year ago I wrote a post on Which .NET framework for Windows: UWP, WPF or Windows Forms? which is still the most popular post on this site, indicating perhaps that this is a tricky issue for many developers. That this is a live question is a symptom of Microsoft’s many changes of strategic direction over the last decade, making it hard for even the most loyal developers to read the signals.

I was intrigued therefore to note that Microsoft has an official Choose your platform post on this subject. There is something curious about this post. It covers three frameworks: Universal Windows Platform (UWP), Windows Presentation Foundation (WPF) and Windows Forms (WinForms). Microsoft states:

UWP is our newest, leading-edge application platform.

implying that if you have an unconstrained choice, this is the way to go. Yet if you look at the table of “Scenarios that have limited support”, UWP has the longest list. It is not only Windows 7 support that you will miss, but also something called Dense UI, along with other rather significant features like multiple windows and “full platform support”.

What is Dense UI? I presume this is a reference to the chunkiness of a typical UWP UI, caused by the fact that it was originally optimised for touch control. This matters if, for example, you are writing a business application and want to have a lot of information to hand in a single window. It may not be ideal for cosmetics, but it can be good for productivity.

With respect to all three of these limitations, Microsoft does note that “We have publicly announced features that will address this scenario in a future release of Windows 10.” I am not sure that they are in fact fully addressed; but it is clear that improvements are coming. In fact, the promise of further active development is perhaps the key reason why you might choose UWP for a new project, that is, if you do not learn from the past and believe that UWP will still be core to Microsoft’s strategy in say five years time.

Take a look at the strengths column for UWP though. Anything really compelling there? To my mind, just one. “Secure execution via application containers.” Yet the security of UWP was undermined by Microsoft’s decision to abandon its original goal of restricting the Windows Runtime API (used for UWP) to a safe subset of the full Windows API. You can also now wrap WPF and WinForm applications using Desktop Bridge, getting Store delivery and a certain amount of isolation.

At the time of writing, Microsoft is still displaying this diagram in its guide to UWP.

image

This is now somewhat misleading though. Windows Mobile is on death row:

Windows 10 Mobile, version 1709 (released October 2017) is the last release of Windows 10 Mobile and Microsoft will end support on December 10, 2019. The end of support date applies to all Windows 10 Mobile products, including Windows 10 Mobile and Windows 10 Mobile Enterprise.

Windows 10 Mobile users will no longer be eligible to receive new security updates, non-security hotfixes, free assisted support options or online technical content updates from Microsoft for free.

As a developer then, would you rather have PC, Xbox and HoloLens support? Or PC, Mac, iOS and Android support? If the latter, you would be better off investigating Microsoft’s Xamarin Forms framework than UWP as such.

The truth is, many developers who target Windows desktop applications do so because they want to run well on Windows and are not concerned about cross-platform. While that may seem odd from a consumer perspective, it is not so odd for corporate development with deskbound users performing specific business operations.

I was at one time enthusiastic about Windows Runtime/UWP because I liked the idea of “one Windows platform” as illustrated above, and I liked the idea of making Windows a platform for secure applications. Both these concepts have been thoroughly undermined, and I would suggest that the average developer is probably better off with WPF or WinForms (or other approaches to Win32 applications such as Delphi etc), than with UWP. Or with Xamarin for a cross-platform solution. That is unfortunate because it implies that the application platform Microsoft is investing in most is at odds with what developers need.

If UWP becomes a better platform than WPF or WinForms in all important respects, that advice will change; but right now it is not all that compelling.

Unlimited free private repositories come to GitHub

When I was looking for an online code repository some years back, I picked Visual Studio Online (now called Azure DevOps) over GitHub. The main reason was the ability to host private repositories with a free account. The projects I work on typically only have one or two developers.

Microsoft acquired GitHub last year and has now announced free private repositories on GitHub – provided you have no more than three collaborators. You can see all the plans here.

image

There is still a bias towards open source, in that open source developers can use the Team plan for free. This is essential for GitHub to fulfil its role as the home of many widely used open source projects.

The addition of free private repositories is significant though. There are plenty of developers like myself who will now look again at hosting code on GitHub.

What is Microsoft’s strategy? There seem to me two important reasons why Microsoft acquired GitHub. One was as a defensive measure. Microsoft now has a ton of open source projects that are critical to its platform, things like .NET Core and now most of the .NET frameworks as well. It would have been uncomfortable if a rival like Google had acquired GitHub.

The second is to promote Azure. GitHub’s infrastructure will no doubt move to Azure, and all going well the service will promote Azure both as an example of a successful at-scale service, and by little ads and signposts that Microsoft can include. The developer audience is influential when it comes to platform choices.

Microsoft therefore does not need GitHub to be profitable, which is just as well having now removed one of the main incentives to get a paid account.

I will be interested to see how the company moves to further integrate GitHub and Azure DevOps. There is currently quite a lot of overlap and it would make sense to streamline the offerings to share the same back-end technology, or even to fold Azure DevOps services into GitHub.

There is no hurry. Microsoft’s priority will be to keep existing GitHub developers happy and to convince them that the acquisition will do no harm.