DEV Community: Peter Grainger

Microsoft Build 2020- working at home edition

Peter Grainger — Wed, 20 May 2020 13:11:45 +0000

I'm a little sick of reading about "the virus that shall not be named". However, if I wasn't home-bound along with the whole world I very much doubt I would be listening to Microsoft employees and partners talking about what's new with Microsoft. I'm not that interested in flying half way across the globe for a two day conference, there are enough great options in Europe.

I go to quite a few in person conferences normally and over the past few weeks I've been to a few online ones too. Hopefully I'm in a good position to give a balanced review.

So what's new in Microsoft?

Most of my work is either in C++, web development or Azure, so I didn't care about anything to do with office365, teams or Business Intelligence. If you want to know about those products the independent has an OK write up https://www.independent.co.uk/life-style/gadgets-and-tech/news/microsoft-build-2020-announcement-cloud-conference-news-windows-10-new-features-a9524441.html

As I'm in the UK I wasn't watching any of this live. Watching a repeat of a live broadcast is not fun. It's like watching a repeat of a football game, you don't feel like you are involved at all. However, the live chat at the side saves it a little bit as you can sometimes get a response to your questions. There seems to be quite a few people in a hoodie, which seems a little forced, I think they are trying to appeal to developers.

Most of the new features I cared about were first announced were at GitHub Satellite. Which is OK but for the fact I watched GitHub Satellite last week so already knew half of what they were announcing. The rest of the time was spent talking about how Microsoft are working towards having a complete developer system from build to deploy with minimal configuration. There were no bombshells.

So the "new" features that they kept going on and on about were:

Codespaces

Nearly every talk had something to say about codespaces. They take the headache out of setting up your system to work with a repo you don't normally work in. This is great and probably around 90% of slack messages in my organisation. Sign up for the beta here, https://github.com/features/codespaces.

WSL2

Windows Subsystem Linux (WSL) 2. Microsoft are backtracking on the WSL1 which didn't work as well as they expected. WSL2 is pretty much a linux VM that is accessible easily from the terminal.

DevOps Tooling

Not to be confused with the product Azure DevOps but they kept going on and on about how they are doing everything they can to make the feedback loop of coding to deploy to getting feedback on your system as small as possible. Not really an announcement but probably news to some.

What I'm liking about Build

Unlike most of the other online conferences it was over 48 hours with content relevant to different timezone and representatives from those timezones. I really appreciate this as most of the online conferences are in American timezone and I need my sleep :)

I also like how all the talks have a toggle to enable american sign language to accompany them.

There are different live tracks which are amusingly through teams. All of the presenters are really professional with very little stuttering or awkward pauses that I'm so used to now watching other conferences.

I had a one-on-one consultation on Azure DevOps which was really useful to get some feedback on one of the applications I'm working on for work.

The moderators are unbelievable. They answer your questions almost faster than you can write them. There must have been an army behind this conference.

The recordings are available immediately after broadcast. I always wonder why all the conferences take ages to do this...

Made me dive deeply into Blazor

I'd never heard of Blazor before today--not to be confused with Razor the template language. It's a way to make web pages using C# compiling to WASM so it can be ran on a browser. But not only web pages, you can use the framework to create a static front end and linked backend services at the same time.

I've played with WASM before but I think this is the first time it's been easy. This is one session that I think will have a direct impact on projects I'm working for. Most developer's I'm working with know C# and would probably enjoy writing in it more than JavaScript.

The Most confusing part is that there is also a project called Razor that is a template engine.

Well written learning modules

Microsoft have really well written learning modules, very up to date and thourogh. You can have a look at https://docs.microsoft.com/en-us/learn. I'm going through a collection on languages and frameworks that I'm really enjoying.

The Best Part was a Session on MakeCode with Minecraft

The best part for me so far was the talk on Microsoft MakeCode with Minecraft Blocks. It may be because I have a small child but it was a really good fast paced talk and the presenter Salaman Chishti seems very genuine. Also MakeCode Arcade looks really good and I could probably waste many an hour making sprites.

Also nearly missed the talk by Gene Kim, author of pheonix project. He seems like a really nice guy and I always take something from his talks. Go see that one.

And the Worst Part was the Lack of Interactions

The worst part so far is the lack of interaction. Other conferences have gone to great lengths to get participant conversation. Sometimes it feels like I'm just watching videos rather than getting involved in a conference.

I would like to see more breakout sessions where participants get involved.

Plus... no swag. Disappointing.

Build is Probably the Best Organised Remote Conference

Probably the best organised remote conference I've been to yet. Really embracing the benefits of online. It still felt a little corporate and rehearsed but I didn't expect anything else--I actually expected it to be much worse.

Some pretty weak announcements compared to those at AWS:Reinvent but the amount of content they put out was really impressive and well organised.

The fascinating world of git cherry-pick

Peter Grainger — Fri, 28 Feb 2020 16:34:00 +0000

The following is taken directly from the wikipedia article about Git and pretty much sums up my week.

The name "git" was given by Linus Torvalds when he wrote the very first version. He described the tool as "the stupid content tracker" and the name as (depending on your way):

random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant.
stupid. contemptible and despicable. simple. Take your pick from the dictionary of slang.
"global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
"goddamn idiotic truckload of sh*t": when it breaks

I love Git

Like many of my friends and coworkers, I have a love and hate relationship with Git--mainly hate. However, Git is probably the best and most used source control system out there so we have to use it :)

Apply Changes Introduced by Some Existing Commits.

According to the Git docs the action of the git cherry-check command is to "Apply the changes introduced by some existing commits". Notice the use of the phrase apply changes rather than merge changes. Cherry picking will not preserve history exactly how it is represented from the source. This will record a new commit SHA.

Avoid Cherry Picking Commits if you can.

Using the git cherry-pick command should be a last resort and should be avoided if you can use merge. Cherry picking should only be done either if the source has a completely different history and you want the changes from a single commit and don't care about preserving the history.

The Syntax for Cherry Pick is straight forward

If you are still keen to go ahead with the cherry-pick the syntax is straight forward.

git cherry-pick <commit>

That's it--as long as you don't have any conflicts or if it's a merge commit.

Using Cherry Pick on a Merge Commit

If the commit you want to cherry-pick is a merge commit then add the flag --parent-number

What is this number I hear you ask? The short answer is--always make it 1. The long answer is in this SO post.

But just use the number 1. It has never failed me :)

git cherry-pick -m 1 <commit>

Pick More Than One Commit

If you are feeling more adventurous you can Cherry Pick a range of commits.

git cherry-pick <oldest-commit>..<newest-commit>

This will cherry pick each commit from the one after the oldest-commit to the newest-commit. The cherry-pick will not include the oldest-commit but will include the newest-commit--confusing :s

Just Touched the Surface of What is Available

I've just touched the surface of what git cherry-pick can do, setting up how merge conflicts are handled deserve their own post!

Git Merge: friend or fiend?

Peter Grainger — Sat, 15 Feb 2020 06:32:43 +0000

A little knowledge is a dangerous thing. When I first learnt to drive, I thought I was a 17 year old version of Michael Schumacher, one of the best formula one racers of the time. I look back on those years of driving around with my friends and I'm terrified! How did I survive!

I feel a little like that now looking back on what I "knew" about Git last week and what I know now. git merge started out on Monday as a fiend but on Friday I welcomed it into my life like a long lost friend because of some great power features that make my life much easier now I understand it a little better.

Git Merge Comes As Standard

git merge is a command that comes as standard when you install git. It's used for merging one or more commits into the branch you have currently checked out. It's most commonly used for merging one branch into another one. For example merging your feature back into the master branch.

Merge Lots of Branches At the Same Time

git merge <commit-sha-1> <commit-sha-2> will merge as many commits as you like! This uses the merge strategy octopus, by default. You'll probably not need to know what it does exactly, but it's the default-and it sounds cool.

Use the Branch or Tag Identifier Instead of SHA

You can use a branch identifier like develop or a tag like v1.0.0 instead of going to the trouble of finding a specific commit SHA :)

git merge v1.2.3

I needed to merge multiple tags together and it would have been a real pain if this feature wasn't there.

Specify Different Merge Strategies

By default git merge uses a recursive merge. All you need to know is that it is the one that avoids the most conflicts.

There are other strategies. Using the strategy ours uses the current branch changes over the one being merged in if there are any conflicting changes.

git merge --strategy ours

You can also specify theirs as a strategy to take the changes from the incoming branch.

Merge Branches That Have No Common History

Most of the time you will be using git merge inside one repository but you don't have to limit yourself. By adding a second remote you can merge any branch from any other repository with the flag allow-unrelated-histories. One caveat, if you have the same filenames in both repositories get ready for lots of merge conflicts. :)

git remote add other-repo git@github.com:peterjgrainger/other-repo.git
git merge other-repo/master --allow-unrelated-histories

Loads More Great Features

I realise now that I know nothing about git, I've only scratched the surface. If you want to read more about git merge see the documentation https://git-scm.com/docs/git-merge. It's not the most interesting read but a good reference.

Monorepo: How to keep your history in order

Peter Grainger — Fri, 07 Feb 2020 14:10:27 +0000

Can you really rely on history to be accurate? History is written by the winners not the losers. I'm a massive fan of the Vikings. I love historical TV series but the more I looked into the actual facts about the time the more I realised much of the series was based around rumours and myths. There is a distinct lack of paper and pens in the fiords of Norway in that time period. Even if they had the equipment, I doubt they would care that much to write down every detail. So who writes the history then? The conquering nations who do care about writing things down, that's who!

So like those conquers of the past we are going to re-write history--Git history :)

In this post I'll explain how I converted multiple Git repositories into one repository by gluing together two different solutions.

My project

My current setup consisted of multiple repositories with a few characteristics that caused a few headaches in this process:

Most of the repositories had 2000+ commits in each
Repositories were reliant on each other and had branches with the same name that related to each other, e.g. release-123
There were about 20 different repositories
The history was important
There were lots of branches, most stale.

Reusing Others Hard Work

The first thing I did when approaching this task was to re-use as much from others who have attempted this before.

There are some great tools to convert the structure of your repos from multi to monorepos. I'll discuss tomono and ShopSys. Tomono is simpler but shopsys has fuller features, both didn't really work for me.

Tomono

The tomono script is first. I noticed late on that the history wasn't actually being re-written (by design) and was relies on the built in mechanisms of git merge. I would probably agree with the maintainer that this is a bug in git not the scripts but it doesn't help me right now.

Shopsys

Next to the shopsys tools. These scripts do re-write history but they only merge the master branch. As my setup is weird and I need to merge any branch that has the same name. I can't use these scripts out of the box either.

Creating a Monster

Like Frankenstein my requirements were for something that didn't exist. I've got a good start but need to take the best parts from each script and combine them to create a monster script. I'll warn you now--like Frankenstein's monster this script is not the prettiest or most efficient but it gets the job done.

It's alive

The magic from the shopsys script comes from the script rewrite-history-into which uses git filter-branch to rewrite the Git history to move everything into a subfolder.

I call the shopsys script from a modified tomono script to re-write the history for each branch. I've shown the interesting parts below:

# tomono.sh
git checkout -q $name/$branch # checkout the remote branch which will be a subfolder
../monorepo-tools/rewrite_history_into.sh $name # re-write the history
git switch -q -c temp-munge-branch # make a temp branch to store the changes
git checkout -q $branch # Go back to the base repo
git reset -q --hard # get rid of any changes
git merge -q --no-commit temp-munge-branch --allow-unrelated-histories # Do the merge!

Now for the downside

This script is painfully slow. It takes hours to run. I'm sure there are optimisations I can make but as I'm only running this once i don't really care.

My script also includes some logic around which branches to move over. You might want to clean up your branches before the move but I'm lazy and just avoided transferring those branches.

Expectation vs Reality

Current scripts are good but can't account for every scenario. If you are in the same scenario as me I hope this helps. There is a high chance you have a slightly different use case so be sure to allow enough time for your transition so you don't rush it and make a mistake!

Found a typo?

If you've found a typo, a sentence that could be improved or anything else that should be updated on this blog post, you can access it through a git repository and make a pull request. Instead of posting a comment, please go directly to https://github.com/peterjgrainger/dev-to-posts/blob/master/blog-posts/monorepo-keeping-your-history-in-order/monorepo-keeping-your-history-in-order.md and open a new pull request with your changes.