Resurrected! If you’re reading this, and you have visited my blog before, you are probably noticing changes. My blog was suffering from technical debt for years and I finally dealt with it. When I addressed the technical problems of my blog, I wanted to make something that could last without me putting an effort in. I think this is a useful lesson in software longevity. This blog used to be running on WordPress.

This site under construction I had a failure scenario with WordPress and PHP versions. As I think a static site should be created statically, I’ve decided to export the current content and create a new web site with Hugo.

(Technically, this is a blogpost about Oauth2 and not OpenID Connect) Are you using Slack as a central communication tool? Did you know that you can also use it as your identity provider for other apps you make or buy? For informal organizations like user groups and volunteer based conferences, Slack is perhaps already your communication hub. This means that the information you have about your users here is as good as you have anywhere.

The advantage of OpenID Connect is the fact that it’s standardized and widely adopted. This means that a library or tool designed to work with, e.g. Google accounts, can easily be adopted to work with e.g. Microsoft’s Active Directory or the Norwegian national ID provider ID-porten. Different Identity providers can support different levels of trust between you and your users. In my next few blogposts, I will explore different OpenID Connect providers and what they can offer you as an application developer.

The advantage of OpenID Connect is the fact that it’s standardized and widely adopted. This means that a library or tool designed to work with, e.g. Google accounts, can easily be adopted to work with e.g. Microsoft’s Active Directory or the Norwegian national ID provider ID-porten. Different Identity providers can support different levels of trust between you and your users. The protocol is perceived with an air of mystery by many developers, but it’s surprisingly simple to master.

This Norwegian language blog post summarizes my talk at Oslo Agile Meetup in the beginning of October. Jeg tror ingen egentlig vet hvordan de skal få til bra utviklingsprosjektet. Selv når vi lykkes så er det veldig mye flaks. De fleste av oss tror vi kunne gjort mye bedre. For de fleste av oss holder tilstanden til kodebasen oss tilbake fra det vi synes vi burde ha fått til. Vi har lært en del ting om hva som i teorien skal være løsning:

Lately I’ve been thinking about how easy it is to fall into the trap of not challenging our ideas about the code we’re working on. In order to challenge the default mindset of Clean Code, I recently proposed to institute Dirty Code Monday (a proposal that sort of got me into a bit of a big discussion). Anyway, here is the report from the first successful Dirty Code Monday one week ago:

I recently did a few days of TDD training for a client. They asked me to help them test and refactor a class that created XML from an internal domain model. This gave me the opportunity to examine a bigger pattern. I wondered where the domain model came from. Looking through the code base, I found that the same or similar data structures were dealt with many places. As often is the case, I also found a bit of code that parsed an XML structure and output the domain model.

My previous blog post took off on Twitter. It pointed out a problem: Insisting on the obligation to follow certain rules at all times isn’t actually helping people work better. The most common question (or objection) I got to the blog post was: So how do we teach new coders how to code well. This blog post is about that topic. First learn to collaborate The most important skill we should teach is how to work well with others on a shared code base.

When your heroes start acting weird, you reexamine their influence on your life. I’ve long been learning, demonstrating and teaching clean code through TDD, patterns and so on. But when I look back, I am now worried that the ideas negatively influence my life and my work and that of others. Many who know me consider me an exceptionally skilled programmer. I got that way because I have often spent my evenings practicing programming techniques and technologies.