Wednesday, November 17, 2021

Set default python version in ubuntu

ls -al `which python3`
sudo update-alternatives --install /usr/bin/python python /usr/bin/python3 1
python --version

Tuesday, July 06, 2021

Getting Permission denied (publickey) ?

Error looks like:
$ git pull Permission denied (publickey). fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.
Assuming that you aready confirmed that you added your ~/.ssh/ or similar to bitbucket personal preferences and that did not help, then you might want to to just try to connect via SSH to bitbucket with the below command which tries to connects to via SSH with user git without allocating a TTY and in verbose mode:
ssh -Tv
You should get something similar to the below:
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 logged in as git You can use git to connect to Bitbucket. Shell access is disabled
If that is the case then you you should retry your git commands again because they should work now.

Sunday, May 30, 2021

Friday, April 30, 2021

Unmet dependencies - you have held broken packages

This issue happens when dependencies get messed up at least in Ubuntu. Here is an example that I corrected today when I could not install vim:

sudo apt-get install vim
The following packages have unmet dependencies:
 libpython3.8 : Depends: libpython3.8-stdlib (= 3.8.5-1~20.04.2) but 3.8.6-1 is to be installed
E: Unable to correct problems, you have held broken packages.
To resolve it you need to clean, autoclean, autoremove, update, upgrade, remove, and retry install while removing any further broken dependencies:
sudo apt-get -y clean
sudo apt-get -y autoclean
sudo apt -y autoremove
sudo apt-get -y update
sudo apt-get -y upgrade
sudo apt-get remove -y libpython3.8-stdlib # game me unmet dependency on libpython3.8-minimal
sudo apt-get remove -y libpython3.8-minimal
sudo apt-get install -y libpython3.8-stdlib
sudo apt-get install -y vim

Friday, April 16, 2021

From fullstack developer (FSD) to fullstack engineer (FSE)

If a fullstack product owner (FSPO) cannot be found, then try to find a fullstack developer (FSD) that wants to become a fullstack engineer (FSE).

FSEs write brainstroming documentation, wireframes and end to end specifications. They interact directly with the stakeholder. They save a whole layer of transaction costs when compared to FSDs, so productivity should be increased at a minimum by 100%. Yes that is right, it doubles (at a minimum) your productivity when it comes to the traditional Stakeholder+PO approach.

But what is needed for an FSD to become an FSE? First, attitude. This professional is eager to see financially tangible results. Second, skills. This professional strives for writing specifications and code as Jorge Luis Borges would write a story, as Albert Einstein would pursue his quest to discover the laws of nature, this professional will be simple and precise.

And what are the rewards? Did I say that such company will be saving a minimum of 50% on the cost to deliver software? Furthermore isn't it clear the reliance of such company on the unmatachable attitude and skills of such Engineer?

FSDs and FSEs out there: I leave the math to you.

Wednesday, January 20, 2021

Why quality first is the only effective approach to delivering software?

To answer this question we must ask first a related question: Why any new functionality should affect any previous functionality with which apparently there is no relationship? Because software is a whole instead of just individual parts. The simil here is the human body.

When you change something that you might think is not related to something else and suddenly you realize that something else failed, it requires an Engineer if we are talking about software or a Doctor if we are talking about health to actually give you response.

Yes, software must be seen as a whole and this is the reason why we have automated tests that look for regressions in the software world, the same way ideally a Doctor will follow up with tests across your body looking for signs of problems after prescribing a solution for any other problem.

Lean software teams should recognize that anything we do anywhere can have an effect somewhere else. Whether that is incomprehensible for some or not is irrelevant because it is simply a fact of life.

And this is why quality-first is the only effective approach to delivering software. Without it you are probably facing a 45% to 65% defect ratio which is holding your team from delivering more features as you keep fixing the problems you keep introducing as you go. I have found that e2e test driven development is an effective way to deliver quality-first software products.