Sådan bestemmer du teknisk gæld i dine systemer | Version2
— Read on www.version2.dk/artikel/saadan-bestemmer-du-teknisk-gaeld-dine-systemer-1088770
Review: Cube Attain GTC Pro Disc 2017 | road.cc
Endurance road bike that offers a smooth ride, stable handling and the all-weather reliability of Shimano’s hydro disc brakes
— Read on road.cc/content/review/223182-cube-attain-gtc-pro-disc-2017
Mountainbike tur ved Holbæk
Idag en tur i Dragerupskoven nær Holbæk. Kort tur på ca 20 min og ruten bød på på små sjove og nogle få svære forhindringer.
The Best Ways to Store and Organize Board Games
You keep buying board games and you swear you’ll play them some day. But before you go all Marie Kondo your pile, get your collection sorted with some proper organization tools.
— Read on theinventory.com/the-best-ways-to-organize-your-uncontrollable-board-gam-1831876838
Example on adding a few common files to host with ansible
– hosts: all
vars:
user: maca
tasks:
– template:
src: ./templates/settings.xml
dest: /home/{{user}}/.m2/settings.xml
owner: “{{user}}”
group: “{{user}}”
mode: 0644– template:
src: ./templates/.bash_aliases
dest: /home/{{user}}/.bash_aliases
owner: “{{user}}”
group: “{{user}}”
mode: 0644– template:
src: ./templates/client.ovpn
dest: /etc/openvpn/client.opvn
owner: “{{user}}”
group: “{{user}}”
mode: 0644– template:
src: ./templates/hosts
dest: /etc/hosts
owner: “{{user}}”
group: “{{user}}”
mode: 0644– name: autoremove unused packages
apt:
autoremove: true
Access your vagrant box from other machines
In order to access your vagrant box from other machines you need to add this to your Vagrantfile
config.vm.network “public_network”, :bridge => ‘eno1’, use_dhcp_assigned_default_route: true
This was tried on an ubuntu 16.04 host
Scrum is a learning framework not a planning tool
I see that most people perceive the scrum framework as a planning tool. I think that it is wrong and I think it is a learning tool. You create a plan in order to learn new stuff when something did not happen according to the plan.
This is also supported be the agile manifesto that states you should “Responding to change over following a plan”
Download missing file in bash script
#!/usr/bin/env bash
function downloadIfMissing {
if [ -f $1 ]; then
echo "File $1 exists."
else
wget $2
fi
}
Search for file content in a linux shell
Command: grep -rnw '/path/to/somewhere/' -e 'pattern'-ror-Ris recursive,-nis line number, and-wstands for match the whole word.-l(lower-case L) can be added to just give the file name of matching files.
Product backlog and Technical depth
I see a lot of product backlogs with both business related issues and technical depth issues. The technical issues often has lower or no priority.
It is hard to explain the business value of solving technical depth issues. From the product owners point of view I can understand why these technial items get lower priority, when they see no real business value in solving these issues.
What is causing technical depth to build up?
The usual development process is somekind of micromanaged and product owners or managers want to know whats going on in a development team. So issues to work on is written with e.g implement something in the backend and write some automated test in the backend.
Usually a part of definition of done states that there should be an automated test when business issues are put into production.
The implementation may take longer than expected and the development team don’t have enough time to test. Management decides, by e.g putting pressure on the development team, that the development team should only do a manual test and automate the test later on. Now technical depth has occurred and each time the development team has to complete another issue it has to decide to do a manual test of the old feature.
So I think that technical depth occurs because af pressure on the development team and management are making priorities on the technical stuff instead of business isusses.
What is the business value of solving technical depth?
Technical depth slows the development team down by giving unpreditable side effects when implementing issues like bugs or rollbacks in production. If this proces goes on for sometime there will be lots of bugs and technical issues in the backlog and the product will eventually die.
So the business value of solving technical depth is actually the value of the product it self.
Should technical depth issues be a part of the product backlog?
It depends on if technical depth gets the proper priority and does not build up over time. I think that a product backlog should contain issues that concentrates on what should be done to evolve the product and not how it should be done.
So technical depth should be on the impediment backlog and priority should be decided by the development team and is therefore not up to the product owner to decide if a technical depth issue should be solved.