Google Nexus 6 - dupa o luna

Am un Nexus6 (cu Lollipop la pachet) in folosinta de o luna. Mai jos o sa detaliez chestiile pe care le-am retinut ca si plusuri/minusuri in "colaborarea" cu acest device.

Plusuri :
- Lollipop
- OS fara bloatware ("curat" , de la Google) - pe viitor, updates "as quick as possible"
- interfata mult mai eficienta (mi-a luat 5 min. sa ma obisnuiesc cu noua interfata si inca 5 sa fiu maxim de eficient folosind-o)
- ecran (mai) mare
- rezolutie (mai) mare
- sunet (2 difuzoare - stereo - amplasate pe partea frontala a telefonului)
- metal - carcasa, capac imovibil, sturdy feel
- nu lucreaza cu Gear2 (adica, trebuie sa renunt la ceasul smart -> nu mai am _inca_ ceva de incarcat)
- nu mai folosesc tableta
- batery life (insa dupa schimbarile descrise mai jos)

Minusuri :
- cpu power - poate fi o impresie, dar cred ca se misca mai prost la cpu_intensive stuff
- a trebuit sa schimb cartela (este una si mai mica decat cea mica pe care o foloseam deja la Note3)
- "alunecos" - este facut din metal (in afara de sticla din fata si cea de la camera, totul e metal) si aluneca usor (din mana, de pe suprafete inclinate, etc) ; "ajutat" si de forma rotunjita a spatelui
- buton (hardware) pentru $home/answer_phone/etc
- nu lucreaza cu Gear2 (a fost "interesant" in primele zile, cand la fiecare notificare a telefonului eu ma uitam la ceas - un ceas standard/normal)
- nu mai folosesc tableta (s-a si descarcat intre timp ; nota bene - s-ar putea sa fie si din cauza ca telefonul e "inca nou" - as in "new toy")
- batery life (initial, telefonul "tinea" mai putin de 1 zi; am aplicat 2 chestii de bun simt - control manual al luminozitatii ecranului + disable "location" (care la lollipop inseamna serviciu de localizare, dar si GPS - nu le poti controla separat)
- unele buguri (cand disablez serviciul "location", cateodata nu mai pot porni wifi)

Google nu "a demonstrat" niciodata pe partea hardware, nu isi propune (cel putin pana in acest moment) sa se pozitioneze strategic pe aceasta piata. Dar a cumparat Motorola (producatorul acestei versiuni Nexus) si alte entitati focusate pe zona hardware - acizitii notate de media ca si "de portofoliu" si "pentru patente". Dar nu i-as crede 100% ...

Concluzie : sunt multumit de alegerea facuta.

Note :
- "mai" <ceva> - e intotdeauna in comparatie cu device-ul anterior (Samsung Galaxy Note3), dar si cu restul deviceurilor din aceeasi categorie pe care le-am detinut (am o istorie destul de lunga in zona "phablets")
- nu credeti benchmarks (deja unii stiu asta) : majoritatea sunt "sponsorizate", astfel incat (de exemplu) note3/note4 au performanta mult prea mare pentru restul telefoanelor (si fata de realitate)

The Hunters (2013)

http://www.imdb.com/title/tt2963232

Un film care porneste de la idee puerila, o dezvolta pe niste linii usor de prevazut, are dialoguri cretine si aritmetici gresite (vezi filmul, ~ min. 65 - combinatii de 3 luate cate 3 e "one thousand").
Daca vrei sa calci pe unul cu masina, cand aproape il lovesti tragi de volan in partea opusa. Cand cineva are o mini-arbaleta tintita spre tine, cel mai bine joci un "magarusul" cu pantoful Cenusaresei (care, btw, probabil era realizat mai bine la fabrica care produce sticlele pentru berea Suceva/Bermas). Si la o petrecere "black tie" oamenii care servesc biscuiti si caviar (sau dulceata de cirese, ce aveau aia acolo) sunt prinsi in discutii cu invitatii - that happens every day!

Decoruri ieftine, scenaristi idioti, idee cretine - 4.9 IMDB rating. Merita mai putin, dar poate mai vrea cineva sa se distreze. E atat de prost incat va invit sa-l vedeti. E categorisit drept aventura, dar va asigur ca e comedie.

Tunel IPsec & why I'm too old for this sh*t

In opinia mea exista o varsta dupa care nu este indicat sa mai faci "tunele". De ce?
"Tunelul" (orice fel de tehnologie, nu conteaza) implica un task/proiect care are, cel putin 1 data, o faza de "la mine merge, problema e la tine" (in cazul special al "tunelelor ipsec", aceasta se intampla de mult mai multe ori decat 1 data...). Ergo, I'm too old for this sh*t.
Un caz real, ultimul dintr-un istoric lung de astfel de interactiuni (pe durata carierei mele), va fi povestit in cele ce urmeaza.

Niste unii trebuie sa acceseze o resursa interna. Bineinteles ca vrei sa limitezi accesul la plaja de resurse interne si in acelasi timp sa ai un minim de control asupra comunicatiei (care trebuie sa fie si criptata, datele fiind sensibile in unele cazuri). Bun, veti spune, e zona propice sa inseram un cuvant care denumeste tehnologia ca si solutie in aceste tipuri de cazuri : tunelul.
In acest caz special, premisa era ca totul va merge "din prima" din 2 motive :
1. am facut asta de mult prea multe ori
2. oamenii ceilalti aveau experienta (cel putin declarativa) cu tehnologia asta (si variatiunea (adica, IPSec) a fost aleasa chiar de ei, pentru ca "deja avem N tunele de acest fel")
3. initierea "proiectului" a inceput cu un email care continea configul folosit de ei in situatii similare (copy&paste, engage!)

De ce nu ar fi mers "din prima" / "simplu" si "rapid" :
1. inca caut sysadmin (suplinesc acest rol in acest moment)
2. vorbim despre "tunel" (vezi primul si al 2-lea paragraf)

Bun.
Am primit emailul initiator, am facut copy&paste-ul de rigoare, am pornit ipsec. Succes - nimic gresit in loguri (ba mai mult, zicea ca merge), "ipsec status" zice ca e up&running, testez din capatul de tunel si raspunde IP-ul de test din capatul celalalt (via tunnel - discutam aici de clase private, in ambele parti, routate prin tunel - nu avea cum sa mearga _decat_ prin tunel).
Wow, cool! Merge din prima! Raspund mailului, tunelul e up, case closed.

But wait. Vine primul raspuns - "la noi nu se ridica tunelul". Wait, what?
Tunel = o gaura / canal prin pamant, cu 2 capete; teoretic, daca bagi ceva prin tunel (like, tren) si iese prin capatul celalalt si apoi il intorci prin tunel si ajunge in "gara initiala", tunelul merge, right? Nu exista "capatul nostru e down". Adica, cum? Ca la mine a ajuns "trenul"! Prin tunel!

Si de aici incepe circul tunelului, asa cum il stiu, il stii si il stim :
- verificare versiune software
- discutii despre filtrarea din firewalls
- de ce e bine sa nu-ti dai cu parerea despre ce ar putea (sau nu ar putea sa aiba) celalalt in retea
- contrarieri despre cum se fac testele
- schimbari (nenumarate) in config
- "va dau acces teamviewer pe masina mea, sa va uitati daca e ceva gresit" <- huh?

- trimis set de date, primit raspuns la cu totul altceva
- intrebari scurte si la obiect, raspunsuri "pe campii"
- insistente de a discuta "telefonic" (*)
- "cu altii merge, acelasi config"
- diferente de sintaxa
- "nu putem da jos doar capatul vostru de tunel" & "nu putem da jos toti clientii conectati" => wtf?
- "nu se poate ridica tunelul doar din capatul nostru?"
- etc
Invariabil, cineva cedeaza. Ca de obicei, eu. Si pun capat balamucului - "am investit destul timp intr-o solutie care se pare ca nu ni se potriveste" - traducere : nu stiti sa va setati porcaria pe care ati cerut-o tot voi, hai sa vedem daca putem face altceva.
Si trece ceva timp. Eu stiu ca asta nu e sfarsitul - niciodata nu e sfarsitul.
Suna "seful" din partea cealalta, cateva zile mai tarziu (v-am spus ca nu e sfarsitul, nu?). "Daca ati putea sa discutati cu noi 20 minute, se rezolva cu siguranta". Nu am 20 minute full pe care sa le petrec, legate, discutand despre ... <bleah> ... un tunel. "Ok, am inteles, revenim noi cu o alta solutie".
Cateva zile mai tarziu (doar nu credeati ca s-a terminat, nu?) vine un email (NB : niciodata un email intr-un thread de emails legate de un "tunel" nu vine singur - vine cu alaiul de calls & missed_calls din jur) cum ca au ajustat $stuff si acum mai trebuie sa schimbam "doar ceva" (in email exista un text de cateva zeci de randuri cu configuri, diferente, markup rosu, concluzii, todos, unde e problema/vina si ce trebuie sa facem noi ca sa mearga - NB : la mine merge din emailul no. 1).
Ok, schimbam acel "doar ceva". Tunelul se comporta la fel, "la mine merge" (toate testele sunt trecute si outputul este frumos impachetat, ca de fiecare data (ca sa ma creada lumea) in email si trimis).
"Tot nu se ridica capatul nostru".
Mai trec zile, mailuri, telefoane (unele cu ton plangacios - "sper ca nu aveti ceva cu mine" like self-flagellation "I have mamma issues" type of stuff). Tunelul e tot acolo, cu ambele lui capete, cu trenul care circula din ambele parti si cu gara din partea cealalta care spune ca nu a vazut trenul niciodata si doar a auzi povesti cum ca ar exista un tren, un tunel si-o gaura.

Sumar :
- start -> $now = 2 saptamani (and counting)
- telefoane pe aceasta tema : ~20 (din care missed vreo 15)
- emailuri in thread(s) (pentru ca "gaura din capatul celalalt de tunel" a rupt threadul la un moment dat (are acelasi subiect insa)) : 45 (and counting)
- clase IP routate prin tunel (incercari) pana in acest moment : 3 * /24, 2 * /32, 1 * /16
- status tunel : LA MINE MERGE

(*) Urasc :
- sa mi se raspunda in "conversatii" folosind un alt mediu decat cel pe care a fost initiat (adica : daca-mi scrii un email, nu ma suni sa-ti raspund la acel email)
- sa folosesc metode de comunicare sincrona (telefon, par example) ; timpul este limitat, planningul nu functioneaza daca poate orice "gaura de tunel" sa te intrerupa oricand
- sa fac TUNELE

DevOps - sau "sunt programator si am "root" pe servere"

DevOps - unul din multele cuvinte "magice" care au intrat in vocabularul nostru in ultimii ani, odata cu "continous integration" (putin mai vechi, dar inteles abia acum), "cloud", "test driven development" si asa mai departe.

Totusi, nimeni nu are o explicatie standard pentru termen si interpreteaza acest rol contextual.
Ceea ce e bine si corect - DevOps este termenul, rolul insa se defineste in functie de nevoile companiei, a workflowului, modalitatilor de lucru, arhitecturii, tehnologiilor, etc.
Ce am intalnit insa, irefutabil si periodic ca si neclar referitor la acest concept este legat de accesul privilegiat pe servere - eternul "root debate", care e vechi de cand exista "root" si de cand exista "dev".

Din experienta, exista o curba Gaussiana in istoria unei companii / unei echipe IT / de tehnologie - care deseneaza relatia intre acesul programatorilor "pe servere, ca root" si timp.

Adica, cand compania este tanara, "toata lumea" are acces privilegiat la infrastructura existenta. Mai apoi, odata cu cresterea generata de succesul produsului creat si cu cresterea echipei (in stransa relatie), apare separarea (clasica) a rolurilor in echipele tehnice. Adica, apar roluri ca : sysadmin, QA, integrator, release master, etc.

Surpriza insa vine dupa ce compania trece la maturitate - intervine o "democratizare" a structurilor echipei, cu scopul principal de a imparti cat mai mult din ownership. Da, ownershipul este principala problema cu care se bat echipele pe schema clasica de functionare si discutii de genul "QA nu a gasit problema asta cat a fost la ei?", "DBA nu mi-a spus ca selectul meu este gresit si puteam folosi index acolo" si asa mai departe. In afara de neproductivitatea acestor discutii, problema majora este spargerea echipelor in boxuri de responsabilitate, care genereaza de fapt o scadere drastica a ownershipului si implicarii. Ceea ce este riscant sa se intample si dramatic daca chiar se ajunge aici.

Si aici intervin o serie de concepte noi, printre care si DevOPS. Care, de fapt, inseamna extinderea ownershipului pe arii cat mai mare din procesul de dezvoltare. Adica, DEV este responsabil cu etapa de codare, de testare unitara, de testare functionala si chiar de release/maintenance. Full stack!

Si asta, dragii mosului, inseamna DevOps : devii care au acces ca "root" pe masini pentru ca nu exista rolul de sysadmin, dar si programatorii/sysadminii (seniori/experti) care au destule cunostinte tehnice pentru a putea fi responsabili pe o zona extinsa (poate chiar toata!) a procesului de dezvoltare.

Nota :
Ce nu inseamna DevOps?
- "sysadmini care stiu php"
- "testeri care stiu coding"
- "programatori care pot da restart la apache"

Da-mi legatura cu tehnicul!

Ieri mi s-a intamplat. Am fost summonat intr-un thread de email intre product_managementul nostru si marketingul unui furnizor. Threadul era despre erorile de conectare ale "sarvarului" furnizorului la platforma noastra via FTP.
First WTF.
Directorul de marketing isi dadea cu multiple pareri despre comunicarea noastra interna, despre procese si proceduri care tin strict de tehnic/PM. Mi s-a parut un moment bun sa intervin, mai ales ca acel furnizor era "implementat" inca de acu' cateva luni. Problema este ca atunci cand s-a remarcat prima data issue-ul, feedbackul a fost dat de catre tehnicul (90% e un singur om) lor (outsource-at) catre marketingul lor, care le-a scris un frumos mail departamentului nostru de ... achizitii.
Second WTF.
Le-am explicat pe scurt (si a fost interpretat ca si raspuns taios si orgolios - ghinion, eu-l categorisesc ca si eficient) cum ca despre probleme tehnice + proiecte diverse (inclusiv marketing - pun intended :) ) sa contacteze dept. PM, achizitiile urmand a fi contactate pentru ... (surpriza maxima, drum roll) ... achizitii! In sfarsit, am concluzionat ca ar fi (totusi) bine ca "tehnicul sa vorbeasca cu tehnicul"...
Incomming tehnicul_lor - paste din email :

INCEARCA DIN LINIE DE COMANDA EXACT CUM AM FACUT SI EU (VEZI ATASAT).
IN MOMENTUL IN CARE II DAU COMANDA “MGET” NU AR TREBUI SA-MI DEA TOATA CALEA CATRE FISIER.
PS: CRED CA MI-ATI BLOCAT IP-UL (xxx.xxx.xxx.xxx)
> - serverul de pe care se incearca conectarea este in spatele unui NAT? ( <-- astea sunt zisele mele)DA
> - serverul de pe care se incearca conectarea este in spatele unui firewall?
DA
> - care este mesajul de eroare primit la incercarea de accesare a unui fisier de pe FTP?
ATASAT
> - tu reusesti sa te conectezi pe acel FTP cu credentialele pe care le folositi in productie?
DA
> - se poate ca modalitatea de conectare la FTP sa fie modificata din activa -> pasiva (si invers)?
NU

Third WTF.

Raspunsul meu continea si :

Cred ca ai facut o greseala, uitand CAPS-LOCK apasat - vezi :
http://fabafter40.tumblr.com/post/43530963637/a-bit-of-advice-for-people-who-always-write-in-all-caps(... si alte materiale echivalente).

Note finale :

- tehnicu' lor facea teste pentru conectarea FTP folosind clientul windows din cmd, care NU stie (by design) de passive_mode ; dar nu e blocker, moving along

- tehnicu' lor facea teste folosind comanda "mget" pentru a downloada un fiser de test, care dadea eroare ; moving along

- i s-a sugerat schimbarea sintaxei din "mget file" in "get file" ; a fost ignorata sugestia, moving along

- i s-a sugerat schimbarea sintaxed din "mget file" in "mget file*" (daca tot are o afinitate pentru mget) ; a fost inorata si aceasta, moving along

Conexiunea la FTP functioneaza in orice mod (activ/pasiv), testat din 3 sisteme de operare, 3 ISP diferiti, inclusiv din toate browserele usuale. 

Threadul are si un apogeu, redat mai jos :

Cum am spus si in mailul trimis catre Xulescu: folosesc linia de comanda si “mget” pentru test.
Pentru tot procesul de import comanda si procesare folosesc un program care la randul lui foloseste o librarie de la Microsoft, si functioneaza pentru alte servere de ftp, descarca fisiere fara probleme.

Atentie - el foloseste doar pentru teste, pentru comunicarea inter-platforma se foloseste altceva. Lui testele ii failau ...

Final : nici in ziua de azi nu-i functioneaza "testele" ...