In my last post, I showed how to flow claims from an external identity provider (also referred to as a login provider) to your application. My post walks through how to bring over the claims every time the user logs in. But why would I want to do this?

I love it when a website lets me use my Google, GitHub, or Facebook account to log in. Chances are, I’m already logged into those sites, so it’s one click to log into a new site. This is a great experience for users. It reduces the friction to registration and loggin in to your site. They’re less likely to clam up.

Azure has a neat feature that runs Azure Functions from a package file (aka a zip file). This same feature also applies to Azure Web Apps, though you wouldn’t know it from the documentation. The Run from Package docs only mention Azure Functions. The GitHub issue that announced the feature makes it clear this also applies to Web Apps.

When you merge two branches, there may be conflicting changes between the branches. Git can often resolve these differences without intervention. For example, when each branch has changes to different files or lines of code.

Raise your hand if you enjoy merge conflicts. I’ll go out on a limb and guess that nobody has a hand up. If you do have your hand up - first, you look silly right now. I can’t see you. And second, you’re being contrarian. Nobody likes merge conflicts. They’re a hassle.

It happened again. A group of hackers targeted another cryptocurrency wallet via a malicious NPM package. The good news is that this attempt was foiled.

When I ran the Client Apps team at GitHub, I wrote a weekly “newsletter” to the team. I named it the CACAW which stood for Completely Awesome Client Apps Weekly. The name gave me an excuse to highlight each letter with a crow themed image.

When you see a small bug or error in a repository, a common refrain is to submit a pull request to fix it. To submit a pull request with a correction is an act of kindness to the maintainers. It allows the maintainers to review the change and accept it with a click.

Millions of years ago, Zach Holman gave a great talk about How GitHub uses GitHub to build GitHub. The talk focused a lot on GitHub’s approach to coordinating work on github.com, the software.

I ended my last post on package security through fingerprints with this ominous note…

My head is crammed with ideas just jostling to see the light of day. I imagine them pounding the inside of my cranium screaming LET US OUT!. And in response, I say the same thing I always say. Not yet. It’s counter productive.

It seemed like an innocuous enough update. Someone yanked bootstrap-sass ruby gem version 3.2.0.2 and published 3.2.0.3. Ruby gems more or less follows the SemVer versioning scheme (albeit with an extra version number). An increment of the patch number communicates that this release should be a safe bug fix update. The command, bundle update --patch, should be safe as it updates to the next patch version which should be safe.

In my post on Why NuGet Package Signing Is Not Yet For Me I noted…

Strap in for a rollicking exploration of the NuGet package signing feature. What is the feature and what is it good for? And does it live up to its purpose? Yes, my friends, I know how to party.

Every project risks failure to some degree or other. There’s the risk of delivering late. The risk of not being able to deliver at all. Or the risk that when you do deliver, it solves the wrong problem. It’s a risky business, but not the kind with Tom Cruise lip-synching in his underwear. When you work on a project, it’s important to be aware of and manage risk. There are several good tools for doing this.

I’m a big fan of Git aliases as a means of improving your developer workflow when using Git. They are great for automating common tasks. They also can help make sense of the byzantine set of options Git has.

For several years now, I’ve been the maintainer of the SemVer specification. It’s been an honor and privilege to be in this position. But I’ll be honest, it’s also an enormous responsibility and a big pain in the ass. This is why I’m happy to say that I am stepping down as the maintainer of SemVer and passing the torch to a team of maintainers better suited to direct its future. Now the pain (and honor, don’t forget the honor) can be distributed among multiple people, and not focused on just one.

GitHub had about 50 employees when I joined back in December 2011. Seven years later, it blew past 950 people and Microsoft acquired it for $7.5 Billion. What would you say if I told you it could have been way more valuable than that?

What if I told you there’s a way you can increase your giving by up to 50% or more (depending on your tax bracket) at no cost to you? For every dollar you put in, you’d have $1.50 to give to a charity of your choice? Interested? Read on then.

It used to be a tradition at GitHub to announce new hires with a blog post with the pattern, “So and so is a GitHubber.” Each post would be accompanied by an image.