Iată o afirmație pe care probabil nimeni nu a formulat-o vreodată: Integrarea unui serviciu a decurs fără probleme pentru că fiecare detaliu despre fiecare posibilă cerință actuală și viitoare este de la început bine precizat, astfel încât să putem planifica, estima efortul și livra totul la timp. Și să nu uităm că documentația a fost grozavă.
Realitatea, în cea mai mare parte a cazurilor, nu ar putea fi mai diferită decât atât.
Toți anii de dezvoltare software i-au învățat pe managerii de produs și echipele de dezvoltare că aplicarea metodei Waterfall nu poate funcționa pentru tot. De ce? Iată câteva motive destul de semnificative care se aplică în orice situație "suficient de sofisticată":
Inițial, singurul lucru este, de obicei, o idee, o viziune pentru rezolvarea unei probleme existente, care trebuie implementată înainte să o facă concurența. Toate detaliile conexe low-level încă trebuie clarificate, dar asta e în regulă.
Trebuie să validăm ideea în practică cu un cost inițial minim și cu un randament rapid al investiției pentru a evita aventurarea în direcții fără ieșire și risipirea resurselor.
Pe baza celor de mai sus, este clar că software-ul este o entitate vie și ar trebui să evolueze în timp, pe măsură ce cerințele și tendințele se schimbă.
Integrarea unui serviciu 3rd party nu este diferită față de a începe de la zero în termenii discutați mai sus.
Foarte potrivită pentru a descrie această situație este sentința formulată de filozoful Heraclit, acum 2500 de ani: Singura constantă în viață este schimbarea.
În ingineria software de astăzi acest adevăr este perfect confirmat: cerințele se vor schimba, API-urile se vor schimba, vor fi descoperite probabil erori care trebuie remediate pe parcurs și, în cele din urmă, s-ar putea să avem nevoie chiar să schimbăm furnizorul de servicii.
Trebuie să ținem cont de aceste aspecte pe tot parcursul procesului.
Prima întrebare pe care, în calitate de ingineri software, trebuie să ne-o adresăm este: să scriem propriul serviciu sau să folosim un furnizor deja existent? În acest articol, ne vom concentra doar asupra integrării unui serviciu 3rd party.
Așadar, să vedem la ce ar trebui să fim atenți, atunci când trebuie să alegem un furnizor de servicii de geomapping.
Acesta este primul nivel pe care furnizorul nostru de servicii ales trebuie să-l îndeplinească. Unele dintre cele mai comune caracteristici pe care un furnizor de servicii de geomapping este așteptat să le aibă sunt una sau mai multe dintre următoarele:
Acesta este probabil cel mai simplu use case și cu funcționalitate foarte limitată. Este cel mai des utilizat pentru secțiunea de contact a afacerii noastre. Cel mai important avantaj al acestuia față de utilizarea unei capturi de ecran cu un marker pe ea este că va ține evidența schimbărilor în vecinătăți/străzi și ar putea reacționa chiar la tema de lumină/întuneric a utilizatorului.
Aceasta este o caracteristică foarte evidentă pe care oricine ar putea să o aștepte de la o hartă non statică. Cu toate acestea, trebuie să ne amintim că nu toți furnizorii de servicii susțin smooth zooming, ceea ce ar putea fi o condiție eliminatoare.
Pentru a înțelege această limitare, trebuie să înțelegem mai întâi cum sunt randate hărțile. Există două abordări majore:
Raster tiles - datele hărții sunt alcătuite din imagini mici (mai mici);
Tile-urile de tip raster nu sunt concepute pentru scalabilitate în ceea ce privește dimensiunile; prin urmare, nu sunt destinate unui zooming smooth și continuu.
Prin definiție, o hartă Choropleth este folosită pentru a prezenta informații codate în culori pentru diverse regiuni. Caracteristica este exprimată foarte clar, dar definiția unei "regiuni" este destul de complexă. Mai multe despre acest aspect vor fi menționate mai târziu când vom aborda subiectul așa-numitelor boundaries.
Este o altă caracteristică fundamentală a unui furnizor de servicii de geomapping. Adăugarea de markere este, de obicei, o sarcină ușoară, dar adăugarea lor dinamică, cu codificare a culorii personalizate și o formă/contur personalizat poate fi o provocare pentru anumiți furnizori. E nevoie să planificăm în avans, dacă vreodată avem nevoie de această funcționalitate și să ne asigurăm că avem suportul corespunzător din partea bibliotecii.
Aceasta este o zonă mare de aplicare a hărților, folosită de un număr mare de industrii pentru a optimiza timpul și/sau costul deplasării vehiculelor, persoanelor etc.
Este o caracteristică foarte complexă care, atunci când este realizată corect, este însoțită de:
Date de trafic în timp real;
Geocodificarea directă este procesul de transformare a unei adrese citite de om într-un cuplu de coordonate de latitudine și longitudine. Geocodificarea inversă este opusul.
Acesta desemnează, de exemplu, ceea ce face posibilă căutarea pe o hartă.
Adaptarea aspectului oricărei aplicații este o parte importantă a experienței utilizatorului. Așadar, oferirea unei variante bune de teme și posibilitatea de a adăuga altele noi sunt atractive atât pentru utilizatorii finali, cât și pentru dezvoltatori.
Cum clienții noștri sunt utilizatorii finali ai hărților noastre, de ce să nu le oferim posibilitatea de a aplica teme personalizate în ceea ce privește look-and-feelul și accesibilitatea?
Pentru a înțelege acest aspect, va trebui să căutăm mai adânc în standardele de reprezentare sau, mai ales, în lipsa lor. Fiecare țară folosește un standard puțin diferit pentru organizarea și reprezentarea entităților lor subregionale, aplicând o taxonomie diferită.
Doar pentru a avea o idee, iată câteva dintre taxonomii:
Administrativă,
Legislativă,
Localitate,
Poștală,
Există subniveluri ale taxonomiilor de mai sus, denumite, de obicei, prin numere, cum ar fi administrativ 0 - reprezintă întreaga țară, iar administrativ 1 reprezintă subnivelul pe care țara îl definește pentru sine.
Formele acestor entități se numesc boundaries.
Câteva exemple de diferențe:
| Țară | Numele entității (dacă există) | Numărul boundary-urilor | |
|---|---|---|---|
| Admini- strative 1 | România | București + județe | 42 |
| USA | States | 51 | |
| UK | Countries | 4 | |
| Postal 4 | România | Cod poștal cu 4-6 cifre | Aproximativ 14 mii |
| USA | Cod poștal cu 5 cifre | Aproximativ 40 mii | |
| UK | - | Aproximativ 1.7 milioane |
În plus, nu există absolut nicio garanție că toate combinațiile de taxonomie și subnivel există pentru fiecare țară, făcând mai dificile întreținerea și integrarea uniformă.
Cunoscând toate acestea, este clar că nu dorim să întreținem toate datele care țin de formă pentru combinația masivă a taxonomiilor. În consecință, dacă avem nevoie de aceste date, ar trebui să le obținem de la un furnizor de servicii.
If the amount of combinations wasn't enough, add world views on top.
Dacă gama actuala de combinații s-ar fi dovedit insuficientă, luați în considerare și integrarea perspectivelor globale asupra hărților. Acesta este un lucru pe care majoritatea tind să-l uite, deoarece este natural și firesc să presupunem viziunea SUA asupra lumii, care este într-adevăr folosită de majoritatea țărilor.
Există însă unele excepții, întrucât nu întreaga lume este de acord cu privire la unde sunt granițele țărilor. În funcție de locul în care se află clienții noștri, prezentarea unei hărți conform viziunii lor asupra lumii este vitală. În concluzie, este important să ținem cont de acest aspect când alegem un furnizor.
În general, furnizorii pot fi clasificați în două categorii: B2B (business to business) sau B2C (business to consumer). Pentru o aplicație destul de complexă, merită să luăm în considerare un furnizor de tip B2B pentru că oferă unele avantaje cheie.
În calitate de client B2B, probabil vom primi suport specializat pentru incidente de producție și/sau ghidare de la expertul furnizorului, pe întregul proces de integrare.
Furnizorii de tip B2B garantează un SLA, fiind mult mai dificil să întrerupă serviciul dacă decid să o facă. Faptul de a fi client B2B ne oferă liniștea că nu va trebui să acționăm brusc din cauză că serviciul de care depinde afacerea noastră va fi întrerupt.
Acest avantaj nu este garantat pentru furnizorii de tip B2C.
Acesta este sau poate fi un subiect sensibil. Curățarea datelor care apar pe hartă este o parte vitală a serviciului furnizorului, pentru că, asemănător oricărei alte dependențe, nu vrem niciun fel de vandalism pe hărțile noastre.
Din păcate, acest lucru se întâmplă de nenumărate ori, așa că unii furnizori au încetat să mai fie "deschiși" (în sensul în care oricine poate contribui cu orice la hărți) și au stabilit procese semiautomate pentru a se asigura că datele pe care le primesc sunt lipsite de discursuri de ură.
Acest aspect este destul de evident, dar merită menționat deoarece este un factor important în alegerea unui furnizor de geomapping. Este în întregime la latitudinea furnizorului ce modele de tarifare oferă. Unele pot fi gratuite.
După ce am terminat evaluarea de mai sus și știm ce furnizor să alegem, probabil vom trece la faza de implementare.
Dintre toate principiile întotdeauna valabile ale programării, merită să ne amintim de "L", cel al substituției Liskov, unul dintre principiile SOLID, inventate de Unchiul Bob.
Aceasta înseamnă că noi, ca dezvoltatori, trebuie să menținem o interfață neutră față de furnizor pentru funcționalitățile noastre și să ascundem toate detaliile de implementare în spatele ei.
Ai putea întreba pe bună dreptate de ce răspunsurile s-ar putea să nu fie evidente? Există câteva motive.
Cel mai important este evitarea fenomenului numit "vendor lock-in". Eșecul în acest sens ne-ar face incapabili să schimbăm furnizorul din cauza:
Serviciul devenit prea scump;
Apariția unui furnizor de servicii mai bun;
Respectarea principiului Liskov ne deschide, de asemenea, ușa pentru a ține mai mult de un furnizor, dacă ne dorim vreodată asta.
Nu este posibil să trecem peste acest subiect fără a menționa cunoscuta librărie open-source, Leaflet.
Pe scurt, Leaflet depinde de un serviciu extern de tiles pentru a afișa conținutul unei hărți, iar restul (desenarea formelor pe hartă, adăugarea de markere etc.) este gestionat de librărie, care poate fi deja considerată ca un cod independent de furnizor.
Unul dintre dezavantaje poate fi că nu suportă straturi vectoriale din start, însă există module suplimentare pentru aceasta.
Mai mult, în cazurile în care principalul nostru motiv pentru integrarea soluției de geomapping este de a putea afișa o cantitate masivă de boundaries (care au tendința de a proveni din surse comerciale ce vin deja cu propriile lor librării client-side), atunci Leaflet s-ar putea să nu fie cea mai bună opțiune.
În cazul în care serviciul pe care l-am ales se facturează folosind un model "pay as you go", trebuie să ne asigurăm că utilizarea este corectă în cadrul bazei noastre de clienți.
Monitorizarea în timp real trebuie să fie disponibilă pentru a vedea statistici privind utilizarea și detectarea suprautilizării.
În caz de suprautilizare, ar trebui întreprinse unele acțiuni (preferabil automate), cum ar fi încetinirea răspunsurilor serviciului pentru o perioadă limitată de timp pentru părțile vinovate.
Ca ultim resort, ar trebui implementat un control de urgență în sistemul nostru, care să poată închide serviciul într-un mod elegant, preferabil pentru un utilizator sau grup de utilizatori, în loc să fie oprit pentru toți utilizatorii în același timp.
Acesta este ultima linie de apărare pentru a evita scăparea de sub control a costurilor la sfârșitul perioadei de facturare.
În mod ideal, furnizorul de servicii ales ar trebui să acopere tot ceea ce nu dorim să implementăm și să menținem, fie că este vorba de codul sursă real sau de întreținerea datelor de boundaries.
Planificarea în avans și proiectarea software-ului și a integrărilor având în vedere posibile schimbări sunt cruciale pentru ca orice proiect software să reușească pe termen lung.
Există o multitudine de furnizori de servicii de geomapping disponibili pe piață chiar acum. Important este că, ținând cont de cerințele și limitele noastre, cercetarea noastră ne va ajuta să alegem instrumentul potrivit pentru rolul și responsabilitatea noastră.