Tuesday, June 25, 2019

How much code is there? (Counting lines of code)

Lines of Code (LoC) isn't the greatest of metrics (and definitely not a sign of productivity) but sometimes it can be interesting to know.

Last week, after giving a demonstration of the Rapid XAML Toolkit someone asked me just how much code I'd written.

I didn't have a way to quantify this so I said I didn't know. "What counts as 'quite a lot'?"

Later I was thinking about the question and it made me wonder "What even is a quick way to count LOC in Windows?"

I didn't know.

Then I remembered that it's something I used to do regularly in Linux with one command. This was probably prompted as I gave a talk about Windows Subsystem for Linux (WSL) earlier that day.

WSL makes it easy to do things on Windows that are easy on Linux.

So, to count the lines of code in a project on Windows.

  1. Open the folder, with the code in, in Windows Explorer.
  2. Open WSL there (Shift+Right click and select 'Open Linux shell here', or type 'wsl' in the address bar.)
  3. Type `find . -name '*.cs' | xargs wc -l`  (assuming you're using C#)
  4. Look at the number

Screenshot of output from the command

Wow, that's 33463 lines of code in RXT.
Much more than I would have guessed.
Ok, so it includes blank lines and lines that only include curly braces but it's still quite big.

I wonder how many lines it will be by the time we release the preview...

Tuesday, June 18, 2019

What’s New for the Command line and Windows Subsystem for Linux #InsiderDevTour

Today at the #InsiderDevTour in London I gave a talk about WSL and the new Terminal.

Here are some useful related links that might be useful if you want to learn more about this.

Monday, May 20, 2019

UWP Terminology

The Universal Windows Platform (UWP) has never been just one thing.
As a "platform" it incorporates many elements. There was the UI (which was a new "flavor" of XAML.) There were all the new platform APIs. And there was a new application isolation and packaging capability.
With a new operating system, designed to work on lots of different devices, you'd expect a lot of new functionality and capabilities.
Having a single term for all these capabilities that's different from the OS itself (which could still support old development capabilities as a way of maintaining backward compatibility) was a useful shorthand. "UWP" was that term.

UWP had some limitations as a term. That many people wanted "Universal" to mean any device or OS, not just Windows was one of them. Those people missed the second word in the term though. It meant "universal" across Windows devices. As a counterpoint, at the time Apple was using "Universal" to mean iOS apps built to run on both the iPhone and iPad.
There was also uncertainty as it was clear what made an app a UWP app. Even on Microsoft's own page explaining this, I don't think it's clear to be able to say if something is a UWP app or not.

Here's the thing though, it doesn't matter.
An app can be a UWP app regardless of the technology the UI is created with.
Any app which uses Windows 10 specific APIs can be a UWP app.
Any app can be packaged as a UWP app.

So, as the term loses its meaning, the need to use it diminishes as well.

WinUI covers everything to do with creating a modern, fluent, Windows 10 related interface.
Any app can use Windows [10] APIs.
And any app can be packaged with MSIX.

Maybe we'll need to use these terms in combination with "UWP" for a while (I've used "WinUI/UPW" to connect the two ideas in what I hope is just a transition phase) but hopefully not forever.
This isn't the "death of UWP", this is just an acknowledgment that the term isn't all that helpful and we can use other terms for more specific aspects instead. The underlying technologies aren't going away and there's no value in arguing over if an app is a UWP app or not.

Thursday, April 25, 2019

The one certainty I have about open source software

Photo by Hanny Naibaho on Unsplash

This is the short version of something much longer I have been thinking about.

Many things are currently being said about Open Source development, its maintenance, and how people who contribute towards it are supported.
It's a big, complicated subject with lots of strong opinions and no easy solutions.

I do, however, think there's one simple thing that anyone who uses open source software can do to help.

Say Thank You.

How do you say thank you?
Here are a few ways:

  • Send them a thank you tweet or email.
  • Leave a review or rating in the store/marketplace/repository where you got it from.
  • Donate, if/where appropriate.

Here are a few links to a few of the places you may be getting the results of the hard work of other developers.
Visual Studio extensions | VS Code extensions | Azure DevOps extensions | NuGet | Chocolatey | NPM

Help make open source developers feel happier and more appreciated by finding something you use at one of the links above and saying thank you.

You benefit too. Being grateful makes you happier. Harvard medical school say that's the case so it must be true.

Have you thanked an open source developer today?

Tuesday, April 23, 2019

Can I put the best parts of a user group/meetup in a podcast?

tldr: I'm going to start a new podcast that will just be developers talking about what they've developed. If you want to be on it get in touch.


I organized and ran user groups for the best part of ten years. Firstly, I took over DevEvening, and then I started the Windows Phone User Group which eventually became Windows Apps London.

Of these groups, one of the things I was most proud of was the ability to get regular attendees to talk about what they were working on or had built. Many group organizers will tell you that this can be very hard to do.
Having people talk about their actual experiences was also one of the most requested things whenever I asked attendees about what they wanted at future meetings.

My family circumstances changed a couple of years ago and we now live in a remote area that makes hosting in-person user groups/meetups difficult. However, recently, I've been thinking about how I can take some of the best parts of the groups I used to run and do something that would work regardless of location.

So, I'm going to try this:
I want to take the short, simple demos that were so popular at in-person events and create audio versions of them and package them like a podcast.

Yes, a visual format might be better for some things but I'll start with just audio and maybe extend to video in the future based on feedback.

It will be simple.
For many people, standing up and giving a talk can be daunting. I made it simple by asking the speaker to answer three questions:

  1. What have you built?
  2. Why did you build it?
  3. What did you learn in the process?

I'm hoping this structure will work for a podcast/audio version too, as it's simple but provides opportunities to develop in different ways as appropriate.
As with the short demos people used to give, it will be between 5 and 15 minutes long. Anyone can talk about what they've made for 5 minutes and will easily find they can say much more.

Talking for 5-15 minutes about something you are an expert in is easy. (If it's software that you developed, I consider you an expert in it.)
I'm also hoping this will avoid people being put off by not requiring a lot of preparation or being worried about "filling an hour".

If you've developed something, however big or small, other developers want to hear about it.

Expect lots of links in the show notes.

For now, I'd like to just focus it to Windows. Hey, it's what I know a bit about and having a level of targeting/focus will, hopefully, help with finding an audience and setting appropriate expectations.

If you've built something for Windows (however you define that), be it an app, a tool, a library, a service, or something else and would like an opportunity to tell people about it, then I'd love to have you on my new podcast.