Vectors of trust: Simplify validation for secure transactions

A few weeks ago, the Internet Engineering Task Force (IETF) introduced a new Request For Comments (RFC) document about Vectors of Trust, the RFC8485. It is the work of  Leif Johansson from the Swedish University Network. The original draft went through 15 iterations since 2015 and Justin Richer from Bespoke Engineering edited the current version.

Enough with the credits, what issue the Vectors of trust document is trying to solve? It seems that the purpose is to bring an effective method to measure the trust of credentials for digital transactions. The two main approaches at the moment are known as Level of Assurance (LoA) and Attribute-Based Access Control (ABAC). Let me try to introduce these to you first.

Continue reading “Vectors of trust: Simplify validation for secure transactions”

Hacktoberfest 2018: write 5 pull requests for a free t-shirt

Hello Mishamigos, in a week we will be the last day of October. The day where ghouls and demons will sprout and throw one more spell at us humble coding people. The day where until the last second you will look at your inbox petrified waiting for the next jump scare. As you guessed, in case you were oblivious to the post title, tomorrow is the first day of the last week of Hacktoberfest, 2018 edition.

Continue reading “Hacktoberfest 2018: write 5 pull requests for a free t-shirt”

Git squash merge: non, no, nein, nee, na, nej, não, net

Today I will tell you why you should say no to git squash merges. Even better I will show you. First, I will explain what lead me to write this post. Then, I will provide you with steps to reproduce a problem that seems ignored. A problem that will eventually bite you if you keep using git squash merges. No spoilers until you get there. Hopefully, you will get my point. Since the aim of this post is to save you time in the future or even now this will also be the latest entry of my future-proof series.

Continue reading “Git squash merge: non, no, nein, nee, na, nej, não, net”

Help, often accepted, sometimes rejected, always okay

Help (verb) make it easier or possible for (someone) to do something by offering them one’s services or resources

Today we will talk about help, more precisely helping people who refuse help. However, before I delve any further, you should have a quick read at the Agile Manifesto.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

As I go through the (true) stories I am about to tell, it will be up to you to figure which principles tie in the way I tackle today’s topic. That way we both put the work in one of my posts. I’ll do the same for yours if requested. The stories will be told in chronological order so you may even notice changes in reactions from on end. Talking about ends…

Continue reading “Help, often accepted, sometimes rejected, always okay”

Refactoring: break your code fast, fix it faster

everything

About a year ago, I wrote a really short post about failing fast not meaning that we should not think first. Now that I think about it, I don’t believe I was fully in the right. The saying about failing fast was never about not thinking too long. It seems to be about experimenting with what you have in mind. We all have great ideas 24/7, cool software designs, new paradigms to try and so on. The point is to try to make things work in your first try, and the next one and so on. Which makes me think about refactoring.

Continue reading “Refactoring: break your code fast, fix it faster”