Smartphones: Psychology of product design

A picture speaks louder than 1000 words.

Above is a size comparison of iphone 5, iphone 11 pro, google pixel 4 xl. 

How did they become so big?

Why did they become so big?

When did they become so big?

Who made them so big?

It was a gradual, progressive change by the manufacturers which no user asked for. How are they
justifying it? That is the main question.

This is how they normalized big phones.

1. Same phone size but bigger screen (by reducing the bezel) to make us get used to the big screen
2. New phone with the previous screen but with some added bezel on top and bottom

Repeat the steps 1,2.

Most often they say that to accommodate bigger battery we need bigger phones but we only need
bigger battery if we have a bigger phone which eats a lot of battery. Now let us come to the icon
placement of applications and OS (android, iOS).

Most use their phones with one hand and mainly and only they use thumb. If that is all you use then
you probably hate using a bigger phone and want a smaller phone, so they forced users to use two
hands by placing action items of OS and application at top and bottom, mostly top because if you hold
your phone from the bottom and if the action items are on top then you use other hand to activate them (by touch)

On top you have OS items like notification, settings etc.,. At the bottom you have some other stuff.
In the middle you just have empty space. What if all of it was at the bottom? Then you can use it with
just one hand and a thumb and realize that you don’t need a huge long phone. Why aren’t app
developers placing their action items all at bottom too? Well most app developers use templates
given by OS (apple iOS , google android) makers and these templates force you to have such layout. 

Psychology of a big phone

1. If a phone is small and you are using it with only one hand then your other hand has something else or doing something else. Then you have two choices; Phone at hand 1 and something else at hand 2 (may be TV remote or a book). The chances of you leaving your phone for something else are now 50%. When the phone is big and you have to use both hands to use it then you have only 1 choice forward in your hand. Your phone. So the chances of you not leaving your phone for something else are reduced by 50%. 
2. A smaller phone fits into your pockets and thus it is out of your sight. A bigger phone does not fit into your pocket, especially when you are sitting down, it presses against your thighs and makes it very uncomfortable. So at work or at home when you are sitting you take it out of your pocket and keep it in your hand. So a bigger phone essentially makes you to always hold it in your hands and keep it in your sight which exponentially increases the chance of you using it now since you are always seeing, touching and holding it.
3. Across cultures humans have always joined their palms to show submission. Whether it is the namaste of hindus, budhists, jains, sikhs, the open palm towards the sky of muslims, or joining hands with crossed fingers for christians or any other faith. A bigger smartphone requires you to join your hands in similar fashion resembling as sign of submission to a higher being.
   

   

Jenkins dev environment in one line

So I wanted a jenkins environment to play around with. Luckily I am using RHEL 7.x as my daily desktop at office and it helps.
OS : linux
prerequisites: docker
Just run this and you are good to go. The data btw persists across reboots of your system.

docker run \
  --rm \
  -u root \
  -p 8080:8080 \
  -v jenkins-data:/var/jenkins_home \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v "$HOME":/home \
  jenkinsci/blueocean

Getting started with operators using operator-sdk

Operators? What are they? Operators is a better way to do kubernetis native deployment of applications. You can read all about it here. I am using RHEL desktop so this is for rhel/centos linux.
There are few ways that you can do it. The hard way is be an expert in golang and write from scratch.
Easiest way for now is use the operator-sdk (by coreOS > redhat > IBM) and there is another way by the kubernetes itself.
Let us stop talking and do it.
1. Install, configure go for operator development
2. Install operator-sdk

Install configure Go

Here I am getting the golang 1.12. You can get the link for the version that you desire from here.

1 2 3 4 5 6

# download go wget https://dl.google.com/go/go1.12.7.linux-amd64.tar.gz # extract go binaries from archive tar -xzf go1.12.7.linux-amd64.tar.gz # place go binaries appropriately mv go /usr/local

We have to setup
- GOROOT - location of go binaries
- GOPATH - Go project location
edit your ~./bashrc and add the following

1 2 3 4 5 6

# go binaries location export GOROOT=/usr/local/go # go project location (your's varies) export GOPATH=$HOME/Projects/Proj1 # add to system's path export PATH=$GOPATH/bin:$GOROOT/bin:$PATH

Now save and do

1	source ~./bashrc

to load the new system variables.
Now a command from your terminal 'go version' command will reveal the version of go.

Please also do

1 2 3

go get github.com/golang/dep cd $GOPATH/src/github.com/golang/dep go install ./...

to install the dependency manager.

Install Operator-sdk

1 2 3 4 5 6 7

mkdir -p $GOPATH/src/github.com/operator-framework cd $GOPATH/src/github.com/operator-framework git clone https://github.com/operator-framework/operator-sdk cd operator-sdk git checkout v0.4.0 make dep make install

and you are good to go.
Sometimes you might notice that you will find 'dep' package was not found at your $PATH. Just do this.

1 2 3 4

mkdir -p $GOPATH/bin cd $GOPATH/bin curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh dep

If your $GOPATH changes then you might have to do this again.

Now we get into the operator-sdk directory and start with our project/operator.
1. create new project
2. add api
3. add controller

1 2 3 4 5 6 7 8

# make sure you are the in the right directory cd $GOPATH/src/github.com/operator-framework/operator-sdk # new operator project operator-sdk new podset-operator # add api to it operator-sdk add api --api-version=app.example.com/v1alpha1 --kind=MyOperator # add controller operator-sdk add controller --api-version=app.example.com/v1alpha1 --kind=MyOperator

Now that the api and controller are in place. Now check out the pkg/apis/app/v1alpha1/myoperator_types.go here is where you define the spec. To begin with just add this

type PodSetSpec struct {
  Replicas int32 `json:"replicas"`
}type PodSetStatus struct {
  PodNames []string `json:"podNames"`
}

 Whenever we make change to the structure, we have to generate the k8s code by doing
operator-sdk generate k8s
Now we want to build the image and push it to a registry. Currently here I am going to use a public repo, you might want to use your own.

operator-sdk build quay.io/ambig/myoperator
docker push quay.io/ambig/myoperator

Now update our yaml files to use this image.

sed -i 's|REPLACE_IMAGE|quay.io/ambig/myoperator|g' deploy/operator.yaml

Let us deploy it now

1 2 3 4 5 6 7 8 9 10 11

# Setup Service Account $ oc create -f deploy/service_account.yaml # Setup RBAC $ oc create -f deploy/role.yaml $ oc create -f deploy/role_binding.yaml # Setup the CRD $ oc create -f deploy/crds/app_v1alpha1_myoperator_crd.yaml # Deploy the myoperator-operator $ oc create -f deploy/operator.yaml # Deploy the custom resource oc create -f deploy/crds/app_v1alpha1_myoperator_cr.yaml

Terraform or Cloud Native Templates ?

What is terraform?
tldr. Terraform is a yaml templating engine which does infrastructure as code. You can have an entire or part of your IT infrastructure as some yaml code and deploy it to your private or public cloud.

What is Cloud Native Template?
Azure Resource Manager (ARM), AWS Cloud Formation (CF), Google Cloud Deployment Manager (CDM) are native templating engines just like terraform but mostly in json format.

Psql steps:

1. provision an sql database
2. Store secrets generated to some vault (ex:- credentials for the database)
3. apply a custom configuration
4. create few users and roles
5. create few tables
6. run pre defined psql commands against it
7. connect it to some application

Endpoints:

1. AWS
2. Azure
3. GCP

Now let us say you are asked to develop 1 terraform template for each of the above endpoints (cloud providers) and also the Cloud Native Templates too.

Why Terraform?

86% Common Code and thus

• 86% Faster design and discovery
• 86% Faster development cycle
• 86% Faster testing
• 86% Faster deployment
• 86% Faster UAT (User Acceptance Test)
• 86% greater mobility between cloud vendors
• Greater community support
• Greater availability of code
• Can write custom features, resources or providers if you are know go very well.

Why not terraform?

• There are some features of cloud vendors which are not yet exposed in terraform by the vendor

Why Cloud native templates?

• You are not planning to move your work load to another cloud or you don't mind vendor lock in.
• You are looking for some features of the cloud providers which aren't yet available on terraform.

Why not Cloud Native Templates?

• 86% slower design and discovery
• 86% slower development cycle
• 86% slower testing
• 86% slower deployment
• 86% slower  UAT (User Acceptance Test)
• 86% lower mobility between cloud vendors
• Lower community support
• Lower availability of code
• Can't write custom features, resources or providers if you are know go very well.

Python - OOP - Inheritance, Override and super() [3.7]

get code