Coding and Cooking

Korma and Tikka Masala Paste

2019-09-29T09:00:00+00:00

Intro

I was on trying to find a great mango chicken recipe. So I read a few recipes and found out that they are mostly identical. The biggest difference seemed to be the used curry paste. Some used a Korma style paste whereas others used a Tikka Masala. I decided to prepare both pastes and just cook the same mango chicken recipe twice simultaneously and find out what I like better.

Korma

Korma is a mild paste with an almond and coconut taste to it. Perfect for those who don’t like their dishes to be spicy.

Ingredients

1/2 teaspoon coarse sea salt
2 gloves of garlic
piece of ginger (thumb-sized)
1/2 teaspoon cayenne pepper
1 teaspoon garam masala
2 tablespoons of oil (e.g. groundnut)
1 tablespoon tomate puree
1 fresh green chili
3 tablespoons dried coconut
2 tablespoons ground almonds
15g fresh coriander
1 teaspoon coriander seeds, toasted

Tikka Masala

Tikka Masala is a slightly more spicy paste and has much less coconut to it compared to the korma paste.

Ingredients

1/2 teaspoon coarse sea salt
2 gloves of garlic
piece of ginger (thumb-sized)
1 teaspoon cayenne pepper
1 tablespoon smoked paprika
2 teaspoon garam masala
2 tablespoons of oil (e.g. groundnut)
2 tablespoon tomato puree
2 fresh red chili
15g fresh coriander
1 tablespoons dried coconut
2 tablespoons ground almonds
1 teaspoon coriander seeds, toasted

Process

The process for the two pastes is similar, first toast the coriander seeds in a dry pan on medium heat for a couple of minutes until they smell deliciously. Peel ginger and garlic and cut them and the chili(s) in small pieces.

Use a mortar to grind the roasted seeds
Add the coarse sea salt and the fresh coriander. The coarse salt helps to grind the fresh coriander
Add the garlic and the garam masala
Add the ginger and rest of the spices
Add the ground almonds
Add the tomato paste and the oil
Add the chili pieces
Add the dried coconut

For the lazy ones: You can also put all the ingredients in a food processor and let it run until you have a smooth paste. But where is the fun with that?

Tikka Masala processing

Salt Fat Acid Heat - Mastering the Elements of Good Cooking

2019-08-13T00:00:00+00:00

“Commit to mastering salt, fat, acid and heat and you can become a great cook.”

Salt Fat Acid Heat is probably the cookbook that changed the way I approach cooking the most.

I own various cookbooks from different authors, but usually they “just” contain a list of recipes alongside some super beautiful photos of the result.

Samin Nosrat puts the focus somewhere else.

She boils good dishes down to 4 main ingredients: Salt, fat, acid and heat. When, how long, how much and in what form any of these ingredients are added, is what can bring an ordinary dish to the next level.

Also she explains what any of the ingredients does to a dish, wish helped me to better understand how to cook.

While reading the book I thought multiple times: “I would really like to cook now.”

One of Samin Nosrat’s mantras is, that you have to taste again and again while your are cooking. And that this is much more important than strictly following a recipe. This is also one reason why there are no glossy food photos in this book.

And even though this sounds a little bit strange it totally works out. You’ll get some nice illustrations by Wendy MacNoughton and for the rest Samin Nosrat encourages you to find your own style.

There is also a Netflix show inspired by the book and produced by Samin Nosrat

Below you can find my highlights from the different chapters.

“Salt brings food to live”

One major thing I immediately changed while reading the book was my usage of salt.

I increased for example the amount of salt I put in water to cook noodles. It should taste like the memory of sea water. So quite salty. At first I thought this might be too much. But most of the water and therefore the salt ends up in the drain anyway. However I had to learn the hard (or salty) way, that the same does not apply to rice - obviously.

Another thing literally blew my mind. Mainly because it’s so simple and should be obvious: When you are not sure if you should add more salt (or basically any spice) to a dish, just take a spoon of your dish and salt on the spoon. Does it taste better? Add more salt to the pot. So easy, so helpful!

Also I now take into account the saltiness of other ingredients when thinking about the amount of salt I add. For example olives, cheese, capers or anchovies are great suppliers of salt for a dish.

“Fat makes food delicious”

The choice of the fat has a significant influence on the taste of a dish. Olive oil will for example always give a mediterranean flavor whereas the french cuisine is more based on butter as fat supplier.

But the fat chapter had one more special revelation for me: The reason why my favorite cake is my favorite cake. I already knew that one of the ingredients in my favorite cake is oil but as I’m not so much into baking I didn’t know - or care - if this makes a difference to butter. Now I know that oil coats flour proteins and therefore prevents strong gluten networks leading to a more tender texture in the cake.

“Acid balances flavors”

Acid was the element which was the hardest for me to grasp and understand. But the book contained some interesting examples that helped understand the importance of acid in a dish.

The acid of tomatoes for example prevents onions from getting tender and soft. That’s the reason why recipes usually tell you to first cook only the onions and then add tomatoes do it.

Another thing I learned from the chapter on acid was the maceration of onions. Before using raw onions e.g. in a salad, you should let them soak for about 15 minutes in some acid (e.g. vinegar or citrus juice). It will soften the onions and remove some of the acrid taste.

“Heat: The element of transformation”

Cooking does not start with turning on the stove. Ingredients cook differently if they just came out of the fridge or if they already have room temperature. Meat should always have room temperature before being put in a pan.

Also cooking does not end when turning off the stove. Residual heat trapped within food lead to continued cooking, the so called carryover effect. A roast for example can carry over - or rise in temperature - up to five degrees celsius after being removed from heat.

Another important takeaway from the heat chapter is the strict order of pre-heating the pan, adding the fat only when the pan is hot and only then adding the meat (at room temperature).

Conclusion

I can give you only a glimpse of what you fill find in the book. I strongly recommend the book (personalized link) if you want to upgrade your cooking.

It opened my eyes in various different ways and helped me to better understand what makes a great dish.

I want to close with a small personal anecdote:

We have clearly separated the tasks in the kitchen for years. My wife does everything related to baking and I’m responsible for cooking (we share the eating part ;) ). Since I started to read “Salt Fat Acid Heat” my wife says more than ever before things along the lines: “This tasted so good, you should cook this recipe more often.”. And I can clearly attribute that to small changes I’ve done to my cooking because of this book.

Accelerate - The Science of Lean Software and DevOps

2019-07-12T12:30:00+00:00

Introduction

My first contact with the book “Accelerate - The Science of Lean Software and DevOps” was at the W-Jax conference in 2018. I think it was Eberhard Wolff who mentioned something in the lines of:

There are “good” organizations/teams, they deliver (to production) at least once per day and then there are the “bad” organizations that fail to do that.

He used Accelerate as reference for that statement.

That statement triggered something in me. On the one side I found it pretty hard to call organizations that are not able to deliver to production everyday “bad”. On the other hand I thought it might be necessary to be this hard in the communication just to ensure people are actually listening. It’s like if Robert C. Martin would state “It would be nice, if you as professional programmer, could be so kind and write some unit tests for your code” instead of “You should not write a single line of prodction code without prior writing a failing unit test for it”.

Software Delivery Performance

Now I finally had the time to read Accelerate.

Accelerate is a write-up of the “Accelerate - State of DevOps” researches from 2013 - 2017 along with a deep-enough dive into the scientific methods used, to collect and interpret the data, to give confidence in the findings.

The first question answered in the book is how to actually measure software delivery performance. The 4 measures selected by the researchers are:

Lead Time (“The time it takes to go from a customer making a request to the request being satisfied”)
Deployment Frequency (“A software deployment to production or to an app store”)
Mean Time to Restore
Change Fail Percentage

Lead Time and the Deployment Frequency are considered measures of the tempo of software delivery performance.

Additionally the researches wanted to investigate if tempo gains happen at the expense of the stability. Acknowledging that failures in rapidly changing complex systems are inevitable the question “How long it generally takes to restore service in case of an incident” was preferred to the standard measure of reliability (time between failures).

The final metric is what percentage of changes to production (software releases or infrastructure configuration changes) fail.

The analysis of the collected data regarding the software delivery performance revelead significantly different categories of performances:

2016	High Performers	Medium Performers	Low Performers
Lead Time for Changes	Less than one hour	Between one week and one moth	Between one month and six months
Deployment Frequency	On demand (multiple deploys per day)	Between once per week and once per month	Between once per month and once every six months
Mean Time to Restore	Less than one hour	Less than one day	Less than one day
Change Failure Percentage	0-15%	31-45%	16-30%

One of the most interesting points I found in this book was that not only there is no trade-off between improving performance and achieving higher levels of stability and quality, but high performers do better at all of these measures.

Key Drivers for Software Delivery Performance

Based on these findings the researchers were looking for key capabilties that drive software delivery performances.

What they found are 5 categories with a total of 24 key capabilities detailed below.

Overview

Continuous delivery
- Use version control
- Automate your deployment process
- Implement continuous integration (CI)
- Use trunk-based development methods
- Implement test automation
- Support test data management
- Shift left on security
- Implement continuous delivery
Architecture
- Use a loosely coupled architecture
- Architect for empowered teams
Product and process
- Gather and implement customer feedback
- Make the flow of work visible through the value stream
- Work in small batches
- Foster and enable team experimentation
Lean management and monitoring
- Have lightweight change approval processes
- Monitor across application and infrastructure to inform business decisions
- Check system health proactively
- Improve processes and manager work with work-in-progress (WIP) limits
- Visualize work to monitor quality and communicate throughout the team
Cultural
- Support a generative culture
- Encourage and support learning
- Support and facilitate collaboration among teams
- Provide resources and tools that make work meaningful
- Support or embody transformational leadership

Continuous delivery

Use version control for all production artifacts

Although it might seem obvious to use version control for source code nowadays the researchers specifically mention to also have any configuration (system / application) and build or environment automation scripts under version control.

Automate your deployment process

Computers should perform repetitive tasks so people can focus on solving problems. Therefore the less manual effort for deployments is needed the better it is. Also together with everything stored in version control it should be possible to easily replicate the production environment (without production data) in testing to be able to investigate errors.

Implement continuous integration (CI)

Integrating each persons work at least daily with a following build including tests reduces the risk of integration problems compared to long lived feature branches and allows teams to develop cohesive software more rapidly. See also Martin Fowler on Continuous Integration.

Use trunk-based development methods

There should not be more than 3 active branches at a time and the branches should only live for a very short time (e.g. 1 day). This reduces the risk and time needed for merging. It also seem to encourage refactorings.

Implement test automation

Again repetitive tasks should be done by computers. A reliable test suite gives teams confidence that their software is releasable. It’s worth investing ongoing effort in a reliable test suite (see also Eradicating Non-Determinism in Tests. Another important note here is that acceptance tests should primarily be created and maintained by developers. Tests created by QA or an outsourced party is not correlated with IT performance. Testers are still essential though by performing exploratory, usability and acceptance testing and helping developers evolve the test suites. Once automated tests should regularly be run to give developers feedback.

Support test data management

To be able to run the automated tests it is important to have the correct test data. The management and the collection of necessary test data is therefore vital for smoothly running automated test suites.

Shift left on security

Integrating feedback from information security teams early in the process e.g. during design or demos reduces the time needed to spend later on to fix security issues.

Implement continuous delivery (CD)

continuous delivery has positive impact on various aspects: delivery performance, quality, culture, reduced burnouts and deployment pain. Although of course this comes not for free. A lot of things have to be automated, team interaction and ways of working have to be rethought.

Architecture

The study found two architectural characteristics to be important for achieving high performance:

Can most of the testing be done without an integrated environment?
Can an application be deployed independently of other applications/services it depends on?

Use a loosely coupled architecture

Design systems that can be changed and validated independently. High performance teams require little communication between delivery teams to get their work done.

Architect for empowered teams

Having teams to choose tools and frameworks from an approved list prevents teams from choosing technologies that will be most suitable for their practical needs and from experimenting (learning) with new approaches and paradigms.

What tools or technologies you use is irrelevant if the people who must use them hate using them, or if they don’t achieve the outcomes they care about.

On the other side when tools provided make the engineers life actually easier, they will adopt them of their own free will.

Product and process

Gather and implement customer feedback

It is important to software delivery performance to actively gather customer feedback and to incorporate this in the design of the product.

Make the flow of work visible through the value stream

Having a good understanding and visibility of the flow of work from business all the way to the customer has a positive impact on performance.

Work in small batches

Work should be decomposed in small features that can be completed in a week or less. This enables short lead times and faster feedback loops.

Foster and enable team experimentation

Development teams shouild be empowered to try out new ideas and create or update specifications during the process without requiring approval from outside. When combined wuth working in small batches, custoemr feedback and making the flow of work visible this can have a huge impact on performance.

Lean management and monitoring

Have lightweight change approval processes

A change approval process based on peer review (code reviews / pair programming) results in a better performance than using change approval boards.

Monitor across application and infrastructure to inform business decisions

Use monitoring data from infrastructure and applications to drive business decisions.

Check system health proactively

Rate-of-change and threshold warnings in monitoring systems allow teams to preemptively detect problems.

Improve processes and manager work with work-in-progress (WIP) limits

Visual WIP limits help drive process improvements, increase throughput and makes constraints visible.

Visualize work to monitor quality and communicate throughout the team

Software delivery performance is affected by visually displaying quality and WIP metrics.

Cultural

Support a generative culture (as outlined by Westrum)

A culture with good information flow, high cooperation and trust, bridging between teams and conscious inquiry is predictive of IT performance. Check here for more on the cultural model defined by sociologist Ron Westrum.

Encourage and support learning

A job is satisfying if it makes good use of skills and abilities. In an ever changing environment, with a lot of tasks being automated more and more, it is important to build new skills, learn new approaches and paradigms.

Support and facilitate collaboration among teams

Improve the interaction of previously siloed teams like development, operations and information security.

Provide resources and tools that make work meaningful

Another important point in job satisfaction is that the tools and resources needed to do the work are provided.

Support or embody transformational leadership

Amplify the technical and process work which is essential in DevOps. Five factors are key to this: Vision, intellectual stimulation, inspirational communication, supportive leadership and personal recognition.

The illustration of all the impacting factors can be seen below. (taken from Overall Research Program)

Teaser Photo from Chuttersnap@Unsplash

FriendLib - Intro to my current side project

2019-01-10T19:50:00+00:00

Since August 2018 I’m working on a new side project called FriendLib. The basic idea about the app is that you can check which books your friends own and instead of buying the books you ask you friends if you can lend the book. The name is a portmanteau of friendship and library.

I don’t remember exactly how I came to the idea, but I remember that I read something about the book Thinking, Fast & Slow* by Daniel Kahneman and I thought it might be interesting to read (that’s how it found it’s way on my Reading List for 2019. The next day at the office, by chance a colleague started to talk about that new book he just bough and started to read. Guess what he was taking about Thinking, Fast & Slow. So instead of buying the book myself I now knew that he owns it and asked if I can lend if once he has read it. Easy.

So I thought is there an app for that? And apparently there isn’t. So I decided to use this use case for a (not so) little side project. There are a few tools, frameworks, architectural styles that I want to try out anyway and I like rather to have a meaningful (aka real world) example than a Todo List App.

Using the Event Storming technique, the awesome RealTimeBoard and the help of some friends I quickly outlined the basic functionalities of the app.

These are:

Registration / Login
Management of the own library (how else could your friends know the books that you own)
Managing Friendships
Browsing the library of friends
Searching books (with an indication if any of your friends has an exemplar of it)
Managing book lendings (accept lend requests, follow-up the status, reminders …)

Turns out its quite a lot of functional stuff to do. Additionally I have some learning goals for that project.

For example:

Angular 2+ and Ionic
Serverless using AWS (I already did things with ClaudiaJS before)
App Store deployments for iOS and Android (automated using tools like fastlane)
- the iOS part already looks quite good as you can see here
Documenting the whole solution using the arc42 template and the docs as code philosophy using the docToolchain
- A first result can already be found here

Ideally I find the time to write a few posts during the development. So far (since August 2018) I was not so successful with this intend.

So as you can see a lot of plans for 2019. Stay tuned for updates.

Teaser Photo by Alfons Morales on Unsplash

* personalized link

A simple Web API using Claudia.js, AWS and DynamoDB

2017-11-27T11:00:00+00:00

Abstract

Recently I played around with Claudia.js and AWS Lambda. And I thought that could be a good technical stack for the “Illegal or frowned upon” api. So I gave the Claudia.js API Builder a chance – and it was so easy that I want to quickly write this up here.

Claudia.js

In the first place Claudia.js is a deployment tool for Node.js based projects and eases the use of AWS by abstracting a lot of configuration and deployment steps.

On top of the deployment tools Claudia.js offers an API Builder and a BotBuilder API (which I will cover in another post).

The API Builder allows it to easily build serverless Web APIs using the AWS API Gateway. For the very basic examples please refer to the very good Tutorials and Documentation on the official site.

Hands-On

While writing this post I’ll build the Web API for this example live, I hope that by doing this I will not forget any crucial point. You can find the link to the code at the bottom.

As example I’ll take the statement class from “Illegal or frowned upon”.

export interface Statement {
  id: number;
  text: string;
  illegalVotes: number;
  frownedUponVotes: number;
}

Step 1 – create the DynamoDB table

Create an DynamoDB Table for the statement as shown in the screenshot.

DynamoDB config.

Step 2 – initialize the project

Create a empty directory. Init a new npm project. Install claudia-api-builder and aws-sdk and save them dependency.

mkdir iofu-aws
npm init 
npm install claudia-api-builder -S
npm install aws-sdk -S

To be able to access DynamoDB the service needs special permissions. These can be passed to Claudia.js so that it is applied to our lambda function when deployed.

Create a access-dynamodb.json inside a policy folder.

  
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Action": [
        "dynamodb:DeleteItem",
        "dynamodb:GetItem",
        "dynamodb:PutItem",
        "dynamodb:Scan"
      ],
      "Effect": "Allow",
      "Resource": "*"
    }
  ]
}

Step 3 – Implement the API

Create the entry point for the api (app.js). For the moment it will provide the possibility to POST a new statement and store it in the DynamoDB and a GET for all stored statements.

const ApiBuilder = require('claudia-api-builder'),
    AWS = require('aws-sdk');

const table = 'statement';

var api = new ApiBuilder(),
    dynamoDb = new AWS.DynamoDB.DocumentClient();

module.exports = api;

// Create new statement
api.post('/statement', function (request) {
  'use strict';
  console.log(request);
  var params = {
    TableName: table,
    Item: {
      id: Date.now(),
      text: request.body.text,
      illegalVotes: request.body.illegalVotes,
      frownedUponVotes: request.body.frownedUponVotes
    }
  };
  // return dynamo result directly
  return dynamoDb.put(params).promise();
}, { success: 201 }); // Return HTTP status 201 - Created when successful

// GET all statements
api.get('/statement', function (request) {
  return dynamoDb.scan({ TableName: table }).promise()
      .then(response => response.Items)
});

Step 4 – Deploy

Now to the deployment capabilities of Claudia.js come into play. Note: Before this will work you’ll need to perform some general configuration that can be found in the Claudia.js documentation.

claudia create --region us-east-1 --api-module app --policies policy

What happens when executing the above statement?

Claudia.js will first build the code and create a zip file with all the contents. It then creates the initial lambda function and also the necessary role. And finally uploads/deploys the created zip.

The –region option tells Claudia.js in which region to deploy the function (Thank you, Cpt. Obvious!).

The –api-module defines the main module of our function. As we exported the built api in the app.js file we give it the name of that file.

The –policies option is a directory or file pattern for additional IAM (Identity and Access Management) policies to be included in the role that is created to run the lambda function.

As a result of the create command Claudia.js prints us the configuration (and stores it in a file called claudia.json in the project root directory).

{
  "lambda": {
    "role": "iofu-aws-executor",
    "name": "iofu-aws",
    "region": "us-east-1"
  },
  "api": {
    "id": "2hmzoogb6l",
    "module": "app"
  }
}

Step 5 – test it

Now we can add a test statement using curl from the terminal. And afterwards retrieve all statements with.

curl -H "Content-Type: application/json" -X POST -d @./test/test.json https://2hmzoogb6l.execute-api.us-east-1.amazonaws.com/latest/statement

curl https://2hmzoogb6l.execute-api.us-east-1.amazonaws.com/latest/statement

And thats it.

Conclusion

I think ClaudiaJS is pretty handy. The abstraction it provides for the AWS stuff is quite nice, especially when starting with the topic. You don’t need to understand everything whats happening under the hood. Also the Api builder is quite easy to use and the examples provided on the website and the different example projects on GitHub are easy to comprehend.

The Duties of a Software Architect

2017-10-03T11:00:00+00:00

Last week I had the opportunity to attended the workshop “Mastering Software Architectures” by Gernot Starke and Peter Hruschka. If you ever have the chance to have a training with the two you should take the opportunity!

In this post I want to recap the 6 duties that form the software architect role:

Clarify requirements
Communicate
Design Structures
Design transversal concepts
Accompany the implementation
Evaluate Architectures

These tasks do not follow any specific order are related to each other. During the project or rather product lifecycle they repeatedly occur.

Clarify requirements

If you work in the software industry you will not be surprised that requirements are not always clear. You might ask why it is the architects task to clarify these. Don’t we have functional experts or similar which can nail the requirements? Generally yes. But thats no always the case. And also in good requirement documents there will be room for for assumptions. Its the task of the architect to actively clarify and make things explicit.

Also software architecture should be adequate. To fulfill this the architect needs to clearly understand the requirements and then derive quality goals from these. The quality goals can later help to evaluate the architecture.

Communicate

The architect is the role in a development team with the most interfaces/connections to other stakeholders. Therefore he needs to be able to communicate in a variety of “languages” and ways. Being able to analyze a bug together with the developers in the code and then communicating the results to management is one example. The way the architect needs to talk to these different stakeholders are very different.

With the developers everything revolves around code. In which component/class is the bug? How can we fix it?

Management is (usually) not interested in the component that causes the bug. They need to know how much it costs. How many customers are concerned and how long it will take to fix it.

Also the architect should keep an eye on a up-to-date list of the stakeholders. So that he is aware of who to talk to for different topics. This list can and will evolve over time. I already mentioned two stakeholders but the list can be very long. Additionally to the management and the developers there usually are testers, operation people, security officers, customers, external partners and so on. Each of those should to be addressed slightly differently. This aspect should also be reflected in the architecture documentation. A good architect clarifies with the relevant stakeholders what information they expect from the documentation and tailors the different parts to their needs.

Design structures & transversal concepts

Designing the structure and finding/defining transversal or cross cutting concepts in the system is probably the main duty of the architect and has many dependencies to there other activities.

There are many ways to find out how to structure the system. None of them is the “correct” one, instead you should use multiple approaches and actively switch between those to see things from a different perspective. It can help to first start with a rough first idea about technical aspects and refine this over time iteratively. Also it can help to keep the quality goals in mind that have been deducted from the requirements, often these can give an orientation.

Some keywords that might help for the structure design process are:

Top-Down, Bottom-Up
Quality Driven Design
Domain Driven Design
Patterns

Concepts are aspects that affect multiple building blocks of an application and guide the implementation. They give a more general solution approach. Sometimes selected tools or frameworks come already with a set of concepts. The areas where concepts are applied are diverse. It could be the way persistence is handled in the system, or logging, transactions, security and many more. The documentation for concepts should answer the following questions:

Why is a problem solved using a distinct concept? ** Show the purpose
What is the concept? ** Be very detailed
How is the concept applied? **Show examples, a prototype, code snippets

Accompany the implementation

A critical duty is to accompany the implementation in order to ensure that the decisions taken are also reflected in the code (at different levels). A close follow-up also allows to adjust when it shows that decision should be reconsidered. Generally the architectural tasks are to be handled iteratively. Trying things out, gathering feedback and then (if necessary) adjusting is important. There are a lot of ways for the architect (or the team) to follow-up during the implementation:

Code reviews
Code analysis
Pair/Mob Programming
A Definition of Done
Coding guidelines
…

Evaluate Architectures

The evaluation of software architecture can either be done quantitatively or qualitatively.

Quantitatively means that the software is mapped to numbers. There are different measures that can be chosen. Lines of code, complexity, coupling of different components, resource consumption and many more. It is advisable to combine multiple measures to find hotspots in the code.

Qualitative evaluation tries to identify risks regarding the quality goals of an architecture and the interplay of different quality goals. Therefore the chosen quality goals are refined with concrete scenarios. For each of the quality goals a possible implementation approach is selected. Then the documentation and the code of the software is taken and evaluated against the scenarios and implementation approaches. The outcome of this is a subjective evaluation which should help to identify which of the quality goals might be at risk.

The overall outcome of the assessment can be taken as input for other architectural tasks.

Two more things

To conclude I want to highlight not all of the different duties need to be done by the same person in the team. The role of the architect can (and should) be spread across the team. Generally there will still be one person that takes the responsibility for the taken decisions – you could call that person the “Chief Architect”.

As the architect should take responsibility for the system (that it is build correctly and with the correct quality measures), he should also be involved (or involve himself) in different processes. For example the employee or tool selection processes. Furthermore he should have the competency to take design decisions – how can he take responsibility for decisions otherwise.

Teaser Photo from Pexels

I bought a cow

2017-09-10T11:00:00+00:00

Ok not a complete cow but some parts. The idea is called cow sharing or crowd butching/butchering.

I was made aware of that concept by a tweet of @andreasdotorg – who I follow since I heard a german podcast featuring him talking about the history and process of brewing beer – which actually made me starting brewing beer, but this is a different topic.

Es ist Rouladentag! (Hab ich euch schon https://t.co/dfXdTco2AR empfohlen?) pic.twitter.com/lSevbCECBS
— andreasdotorg (@andreasdotorg) 22. Juli 2017

The idea is to have a more sustainable stock breeding. To know where your meat comes from and also to foster animal welfare. I think I would have problems completely living vegan or even vegetarian, but I like the idea to know that the animals have been raised well and that also the farmers can make a living out of it.

While researching I came across different sites and finally decided to try kaufnekuh.de* . It not only appealed to me because of their interesting graphic on their website to show how much of the current cow is already sold. But also because they offer a small package with about 3,6 kg of meat, which I liked to test the whole thing.

When I finally decided to try it out, the cow on sale was DE 8418 from Joseph and Thomas Pfaff from Ravensburg.

I decided to go for the small package without the BBQ option. If you choose the BBQ option some parts that are not ideal for the BBQ (e.g. the goulash) is turned into burgers or sausages.

This package contains the following parts:

Roastbeef (300g)
Roulade (2x 180g)
Steak (2x 160g)
Strips (1x 240g)
Brisket (1x 350g)
Soupmeat (1x 250g)
Ground Beef (2x 240g)
Goulash (2x 240g)
Burgers (4x 120g)
Chipolata Sausage (6x 75g)

Some people who I told that I bought (parts of) a cow wondered why I couldn’t directly choose the parts that I want. I think this is part of the whole idea as a cow consists of way more than just steaks. That’s something I personally like about this concept. As it brings me to try out new things. There are parts in my package that I have never cooked before and where I don’t know yet what I can make out of them.

After buying I was constantly kept up-to-date via mail about the current status. I was for instance informed when the cow was completely sold, when it was butchered, and when it was ripe and prepared for shipment. This was pretty good as it took around 3 weeks for the cow to arrive and every mail fed my anticipation.

The Cow – or better my parts – where delivered in a thermo bag which I could directly put into the fridge…

What I also liked was the list included in the package that you can pin to your fridge and mark what meat you took out, so that you can easily keep track of what you still have.

Photos

Vegan Mousse au Chocolat

2017-08-26T11:00:00+00:00

Today I had a small dilemma. I could not decide if I want to continue programming to process on the coding-related blog series or if I should finally add a cooking related post to my site.

As so often my wife helped me decide. She wished to try the vegan mousse au chocolat that I learned about last week in a cooking class.

Neither me nor my wife are vegan (or even vegetarian) but nevertheless we like to look beyond horizons and see different things. I was lucky to get that vegan cooking class as a birthday gift from my family and was generally be interested what we will be cooking.

I was quite surprise when I saw mousse au chocolate in the recipe booklet. I was even more surprised by the main ingredient which is called Aquafaba. Something I had never heard before. So I asked the cooking instructor what Aquafaba is:

Aquafaba is the name for the water in which chickpeas have been cooked.

This blew my mind.

Wait what? You can turn the water from the chick peas can into mousse au chocolat? Me – and also the other participants – where really surprised. Afterwards I checked on the net and probably one could have known Aquafaba before, as especially in the vegan cuisine it seems to be pretty common – as it works as a good replacement for egg white. The name is latin “Aqua” – water and “faba” – bean.

If you want to learn more about Aquafaba check out Aquafaba.com.

So how does this work? Pretty much how you would make standard mousse au chocolat actually.

Ingredients for 4 small servings:

125ml Aquafaba (e.g. from one 400gr can of chick peas)
1 tsp Winestone baking soda
0,5 tsp Lemonjuice
120gr dark chocolate
30gr powdered sugar
pinch of salt

First the chocolate is chopped in fine pieces and then slowly melted in a water bath.

In the meanwhile add the lemon juice and baking soda to the Aquafaba and put it in the kitchen machine to stiff. This may take a few minutes. But in the end it will look just like stiffed egg white.

After a few moments you can add the powdered sugar (sift it before adding) and the little salt.

When the chocolate is melted turn the heat off and let the chocolate cool down a little bit. It is important that the chocolate cools down so that it is nearly hard again before you can fold the stiffed Aquafaba with the chocolate.

Once the Aquafaba is stiff and the chocolate cooled down carefully mix everything.

Then fill the mass in 4 bowls and put them in the fridge. Leave them in the fridge for at least 2 hours ( thats the time we gave it in the cooking class while eating the other dishes). If you can cool them even longer to have better texture.

Photos

Coding and Cooking

Korma and Tikka Masala Paste

Intro

Korma

Ingredients

Tikka Masala

Ingredients

Process

Salt Fat Acid Heat - Mastering the Elements of Good Cooking

“Salt brings food to live”

“Fat makes food delicious”

“Acid balances flavors”

“Heat: The element of transformation”

Conclusion

Accelerate - The Science of Lean Software and DevOps

Introduction

Software Delivery Performance

Key Drivers for Software Delivery Performance

Overview

Continuous delivery

Use version control for all production artifacts

Automate your deployment process

Implement continuous integration (CI)

Use trunk-based development methods

Implement test automation

Support test data management

Shift left on security

Implement continuous delivery (CD)

Architecture

Use a loosely coupled architecture

Architect for empowered teams

Product and process

Gather and implement customer feedback

Make the flow of work visible through the value stream

Work in small batches

Foster and enable team experimentation

Lean management and monitoring

Have lightweight change approval processes

Monitor across application and infrastructure to inform business decisions

Check system health proactively

Improve processes and manager work with work-in-progress (WIP) limits

Visualize work to monitor quality and communicate throughout the team

Cultural

Support a generative culture (as outlined by Westrum)

Encourage and support learning

Support and facilitate collaboration among teams

Provide resources and tools that make work meaningful

Support or embody transformational leadership

FriendLib - Intro to my current side project

A simple Web API using Claudia.js, AWS and DynamoDB

Abstract

Claudia.js

Hands-On

Step 1 – create the DynamoDB table

Step 2 – initialize the project

Step 3 – Implement the API

Step 4 – Deploy

Step 5 – test it

Conclusion

Links

The Duties of a Software Architect

Clarify requirements

Communicate

Design structures & transversal concepts

Accompany the implementation

Evaluate Architectures

Two more things

I bought a cow

Vegan Mousse au Chocolat