Optimizacija razvojnog okruženja za 95% slučajeva umjesto za preostalih 5%

Nedavno sam naletio na ovaj vrlo zanimljiv tekst što me navelo na razmišljanje jer sam se prepoznao u tome.

Autor gore navedenog teksta naišao je na vrlo zanimljiv naslov “Why I wrote 33 VSCode extensions and how I manage them” gdje se među komentarima moglo vidjeti sljedeće:

My problem with adding plugins or extending my environment much past the default is that eventually I have to deal with a co-worker’s non-extended default installation. I end up relying too much on the add-ins.

Shvatio sam da sam i ja do nedavno na takav način, za onih “što ako” 5%, donosio odluke. Komentar koji mi je posebno “zapeo za oko” kaže:

I strongly dislike the reasoning that suggests you should hamstring yourself 100% of the time to accommodate a potential situation that may affect you 5% of the time.
“I don’t use multiple monitors because sometimes I’m just with a laptop”.
“I don’t customize my shell because sometimes I have to ssh to a server”
“I don’t customize my editor because sometimes I have to use a coworkers editor”.

Sada vidim koliko takav način razmišljanja nije imao smisla, ali tada mi se sve to činilo sasvim logično i vrlo sam odlučno branio svoje stavove.

Sjećam se da dugo vremena nisam htio koristiti nikakvu drugu temu niti većinu proširenja za Visual Studio Code ili Sublime Text jer što kada budem morao koristiti PC od kolege, a on koristi zadanu temu ili nema određeno proširenje.

Znači u startu sam se ograničavao i umjesto da sebi olakšam 95% slučajeva ja sam više razmišljao i radio na preostalih 5% jer tada nisam shvaćao sljedeće – optimizacija za 5% je primjer optimizacije za scenarij “što ako”.

Činio sam sve što je u mojoj moći da svoje razvojno okruženje učinim dovoljno generičkim da može raditi svugdje i da mogu biti spreman za onih 5%, ali sam zapravo otežavao sam sebi 95% vremena, a to je vrijeme koje je najvažnije.

Takve vrste odluka ne utječu samo na razvojno okruženje nego i na kod.

Personally, I often try and over optimize before I’ve even begun. Consequently I get overwhelmed and rarely build any of the ideas I was thinking about. – izvor

Ako se nešto ide programirati da bi odgovaralo “što ako” scenariju to znači da vjerojatno u potpunosti ne odgovara traženoj specifikaciji. Možemo mi kao developeri misliti što god hoćemo i htjeti unaprijed napraviti pripremu za sve moguće scenarije, ali ako to nije traženo po specifikaciji može doći samo do još više grešaka koje će samo oduzimati dodatno vrijeme za rješavanje, a do tih grešaka nije niti trebalo doći.

Premature optimization is the root of all evil.

Ipak, kada vidimo na koji način radi Google i druge velike tvrtke opet je moguće doći do izgovora za “što ako” scenarij i raditi nešto što nam realno nije potrebno pri čemu fokus opet odlazi na dio od 5%.

Ako neka velika tvrtka nešto koristi na određeni način to ne znači da taj način odgovara svim ostalim tvrtkama.

Instead of just getting your app up and running and seeing how it goes, you try to make decisions so that your application can be developed by 100 different teams sprawling across 5,000 developers.

Do 5% može doći i prilikom procesa implementacije tj. postavljanja aplikacije u produkciju.

To često može uključivati mjesece potrošene na detalje poput savršenog skaliranja, automatizacije određenih procesa i sl. što na kraju ne dovede do očekivanih rezultata jer sva dostupna rješenja, ma koliko tvrdila drugačije, ne mogu dati odgovor za sve vrste scenarija. Velike tvrtke koje su ta rješenja kreirala i koje ih koriste iza toga skrivaju mnoštvo specifičnih prilagodbi da bi sve radilo na određeni način.

When you try to optimize your deployment strategy to handle a billion requests a second from day 1, you’re just setting yourself up for an endless loop of theory based research.

Zaključno, energiju je pametnije usmjeriti prema 95% i vidjeti kako će se stvar ponašati. Ovisno o povratnim informacijama raditi dodatne optimizacije. Drugim riječima, raditi optimizaciju onda kada postoji realna potreba za tim, a ne zbog “što ako” slučajeva.

Pregled 2018. godine

2018. je stigla svome kraju što znači da je pravo vrijeme za razmisliti o svemu što se tijekom godine događalo i možda postaviti temelje za 2019.

Jedan blog post tjedno

Ukupno sam ove godine objavio 53 blog posta.

Nije uvijek bilo jednostavno, ali već dvije godine se držim odluke da objavljujem jedan blog post tjedno, vikendom.

Inspiration is for amateurs – the rest of us just show up and get to work. – Chuck Close

Najveća greška što se ovoga tiče je činjenica da 99% blog postova nisam pripremio unaprijed nego bi ih pisao upravo tijekom vikenda. Najčešće bi to bilo nedjeljom jer bi subotom imao nekog posla koji ne mogu ostaviti za nedjelju. Sve to znači da nije bilo dana u tjednu kada ne bi mislio o developmentu – od ponedjeljka do petka na poslu, subotom radim nešto drugo, ali razmišljam o temi koju ću objaviti na blogu kasnije tijekom dana ili u nedjelju, a onda u nedjelju poslije ručka se ide u razradu teme i sastavljanje blog posta. Nakon toga opet dolazi radni tjedan i tako u krug.

I sam vidim da bi trebao promijeniti ritam, da mi se ne bi dogodio burnout, ali mi je taj tempo do sada toliko prešao u naviku da ne znam kako ću se odlučiti preskočiti neki vikend. Posebno kada vidim koliko su neki od blog postova pomogli kolegama s posla koji su na taj način brže i jednostavnije mogli obavljati svoje radne zadatke.

Ono što mi nije uspjelo ove godine je paralelno održavanje bloga na engleskom jeziku gdje bi obrađivao iste teme kao i na ovom blogu. Objavio sam nekoliko blog postova i onda je sve stalo jer nedjelja kasno poslije podne, kada bi objavio blog post na ovom blogu, jednostavno nije bilo pravo vrijeme za ponavljanje svega toga na engleskom jeziku.

Imam osjećaj da bi ova godina mogla biti odlučujuća za ovaj blog. Ili ću sve dići na jedan viši nivo ili drastično smanjiti ulaganje resursa. U prosjeku mi godišnje ode cca 300 sati na blog. Da sam nastavio sa blogom na engleskom to bi se poduplalo, a da sam uz to radio i video tutorijale pitanje je kako bi više išta stigao raditi u životu.

Kako god bilo za sada još uvijek uživam u ovom blogu i svaki put kada kliknem na “Objavi” imam osjećaj da sam nešto dobro napravio.

Planovi za 2019.

Nastavljam s objavom barem jednog blog posta tjedno. Još moram odlučiti hoće li to i dalje biti vikendom ili ću objavu ostaviti za npr. ponedjeljak. Što se tema tiče fokus će i dalje biti na razvoju za web koristeći JavaScript (Angular, Ionic Framework, NodeJS).

Također, unatoč velikoj količini besplatnih dev resursa koji su na internetu dostupni svake godine odaberem nekoliko premium tj. plaćenih resursa koji će mi na strukturiran način dati temelje za područje koje me u tom trenutku zanima. Uskoro počinjem s jednim NodeJS tečajem, a paralelno uz to ide i CSS tako da će nešto o tome uskoro biti i na ovom blogu.

2017. i 2018. godine objavio sam blog postove sa popisom pročitanih knjiga jer nisam htio ovaj blog pretvoriti u knjižnicu.

U 2019. godini svaka će knjiga dobiti svoj blog post. Tako ću imati priliku više se posvetiti svakoj knjizi, izvući više citata, pokazati naslovnicu i sl.

Ionic 3 – uspostavljanje telefonskog poziva

Iako se poziv može uspostaviti i korištenjem

ipak je korisno imati više mogućnosti koje pruža Call Number plugin.

Kreiranje aplikacije

Kreiram novi Ionic projekt i odmah dodajem Android platformu.

Call Number

Plugin Call Number dodajem sljedećim naredbama:

Naravno, nakon toga ovaj plugin deklariram unutar app.module.ts datoteke.

Ekran za uspostavljanje poziva sadržavati će samo jedan gumb.

Funkcionalnost se sastoji od pozivanja call() funkcije.

Kao što se može vidjeti u dokumentaciji https://ionicframework.com/docs/native/call-number/ dva su parametra koja mogu koristiti prilikom uspostavljanja poziva.

Param Type Details
numberToCall string The phone number to call as a string
bypassAppChooser boolean Set to true to bypass the app chooser and go directly to dialer

U mojem primjeru koristio sam false zato što želim da me aplikacija puta putem koje aplikacije želim uspostaviti poziv.

Nakon klik na gumb za uspostavu poziva napuštam Ionic aplikaciju.

Ionic 3 – uspostavljanje telefonskog poziva

U tom trenutku prvo što se događa je to da Ionic aplikacija traži dozvolu za korištenje te funkcionalnosti. Nakon što se dobije dozvola biti će mi ponuđene sve aplikacije koje imam instalirane na mobilnom uređaju, a koje imaju mogućnost uspostavljanja poziva. Da sam u gornjem primjeru koristio true umjesto false u tom mi se slučaju ne bi prikazao taj popis aplikacija nego bi se poziv uspostavio odmah.

Ionic 3 – uspostavljanje telefonskog poziva

Zaključak

Struktura aplikacije prema package.json

Ionic – kako odrediti minimalnu verziju Androida

Jedan od detalja o kojemu je potrebno razmišljati prije nego se krene s razvojem Ionic aplikacije za Android platformu je minimalna podržana verzija Androida na kojoj će se Ionic aplikacija moći pokrenuti.

Ionic – kako odrediti minimalnu verziju Androida

To se može postaviti unutar config.xml datoteke, a izgleda ovako:

U primjeru iznad stoji <preference name="android-minSdkVersion" value="19" /> što znači da se ta Ionic aplikacija može pokrenuti na verziji Androida KitKat (4.4 – 4.4.4) ili novijoj.

Na Google Play Storeu to će izgledati ovako:

Ionic – kako odrediti minimalnu verziju Androida

Ako sam aplikaciju testirao na raznim verzijama i zaključio da se najbolje ponaša na verziji Lollipop (5.0 – 5.1.1) ili novijoj onda ću postaviti sljedeće:

U tom će slučaju ta informacija na Google Play Storeu izgledati ovako:

Ionic – kako odrediti minimalnu verziju Androida