Mekl.io - ehk norra keeles "vahendaja"

Mekl tegeleb andmete vahendamisega, töötlemise ja uurimisega nagu nimest võib välja lugeda. Tegu on kolme mehe poolt asustatud idufirmaga, mis on saanud oma juured New Yorgist. Idufirma idee on pakkuda analüütikutele tööriistu, mis teeksid analüütikute elu lihtsamaks. Rakenduse kasutamine võimaldab analüütikutel andmestest kiiremini ülevaade saada ning selle võrra teha ka paremaid otsuseid. Tegu on väga aktuaalse probleemiga, kui arvestada asjaolu, et iga päevaga tekib juurde 2500000 terabaiti anmeid. Lisaks kasvab andmete suurus iga päevaga aina rohkem, võttes arvesse asjade interneti ning elektroonika pidevad odavnemist.


Firmast

Firma ise on asustatud Ameerikas, kuid praeguses faasis tehti otsus liikuda Eestisse, et valideerida ideid ning pikendada runway'd, ehk pikendada aega, mille jooksul saab ideid valideerida, sest Eestis on tunudvalt odavam seda teha kui Ameerikas. Praeguseks kontori asukohaks on Lift99, mis asub telliskivis ning on koduks paljudele teistelegi idufirmadele.

Firmal on kaks põhilist suunda -

  1. Stuudio pool, mis tegeleb konsultatsiooniga, põhilisteks ülesanneteks on teha lahendusi, mis aitaks andmetest paremini firmadel aru saada.
  2. Oma toote arendus, mida saab litseneerida ja väja müüa.

Esimene nädal firmas.

Mina olin kõige esimene töötaja, kes firmasse palgati. Seega oli kohati tunda, et kõik asjad polnud veel lõpuni läbi mõeldud. Esimene päev oli päev pärast jaani päeva. Esimesel päeval tutvusin firmas kasutavate tehnoloogiatega, seadsin üles oma töökeskkonna - (konfigureerisin terminali, tekstiredaktori ning laadisin alla muud tööks vajalikud rakendused). Esimeseks ülesandeks oli üles seada repositoorium Azure DevOps keskkonnas, kuhu hakkasime koodi üles laadima. Teine ülesanne oli üles seada CI/CD (Continous Integration/Continous Development) pipeline. See kujutab endast, siis lahenudst, kus arendajad saavad pidevalt koodi repositooriumisse koodi üles laadida, kasutades selleks mingit versioonihaldusvahendit, meie puhul on see git. Iga kord kui kood üles laetakse, käivituvad automaatselt testid, mis kontrollivad koodi ning testide eduka läbimise korral tehakse muutused avalikuks ehk kliendid saavad kohe muutust näha. Versioonihalduse ülesseadmisel on palju inspiratsiooni saadud siit. Lühidalt kokkuvõttes on meil kaks haru, kuhu koodi laadimisel avalikustatakse need vastavalt klientide poolt kasutatavale rakendusele või test keskkonda, kus testijad saavad veel enne muutuste avalikustamist kindlaks teha, kas muutused midagi veel katki pole teinud.

Võrgustiku (Pipeline) üles seadmise õppisin palju ning tutvusin ka Yaml faili laiendiga, mis on de facto standard selliste asjade üles seeadmisel. Yaml faili laiendit kasutatakse ka Docker failide kirjutamisel. Esimese nädala jooksul sai mitu korda veel olemasolevat pipeline muudetud ja parandatud senikaua kuni tegu oli ideaalselt töötatava lahendusega. Yaml fail võib välja näha nagu allpool olev näide.

trigger:
  branches:
    include:
      - master
      - develop
  paths:
    include:
      - /frontend

variables:
  - group: ${{ variables['Build.SourceBranchName']}}

steps:
  - task: Npm@1
    displayName: Installing dependencies
    inputs:
      verbose: false
      workingDir: frontend
      command: install

  - task: Npm@1
    displayName: Deploying website
    condition: or(eq(variables['Build.SourceBranchName'], 'master'), eq(variables['Build.SourceBranchName'], 'develop'))
    inputs:
      workingDir: frontend
      command: custom
      customCommand: run deploy

Lisaks pipeline ülesseadmisega kaasati mind ka tootega seonduvatele koosolekutele, kus arutati, mis võiks olla järgmised sammud toote arendusel ja kas potentsiaalseid kliente teenindada võtta või mitte. Küsiti palju ka minu arvamust ning sain mängida rolli otsuste tegemisel. Ülejäänud ajast firmas tutvusin olemasoleva koodiga (codebase) ning tegin koodis mõningaid ümberkorraldusi( Refactoring), et muuta olemasolev kood paremini loetavamaks ja hallatavamaks. Koodiga tutvumisel sain ka hea ülevaate kasutatavatest tehnoloogiatest firmas -

  • React
  • Typescript
  • NodeJS
  • NestJs
  • Kotlin
  • Objective C
  • Java
  • SQL

Kokkuvõtvalt

Esimese nädala jooksul tutvusin tiimiliiketega, õppisin kasutusel olevaid tehnoloogiaid, ümberkorraldasin koodi ning seadsin üles pipeline. Reedesel koosolekul panime kirja, mida tuleb teha järgmisel nädalal ning seadsime üles Kanban tahvli, mis aitab visualiseerida meie progressi paremini. Sellega sai selleks nädalaks tööga seonduv läbi. Üllatusin eelkõige sellest kui palju vabadust mulle anti valida, kuidas asju lahendada ning kui palju ka minult arvamust küsiti firmaga seonduva kohta.


Teine nädal

Lisaks pipeline üles seadmisele tuli üles seada ka lintimine ehk koodi kirjutamise reeglid. Kuna kasutame Reacti, NodeJs'i ja Typescript'i, siis tuleb üles seada standardid, mille järgi arendajad hakkavad koodi kirjutama. Selleks on olemas tööriistad nagu TSLint ja ESLint, mis automaatselt faili salvestamisel muudavad koodi standardile sobivaks. Lihtne näide on allpool ka välja toodud.

"rules": {
    "quotemark": [true, "single"]
}

Teine nädal mõõdus töökalt, sest eelmisel nädalal sai kokkulepitud koosolekul, et turul on praegu tühik tööriistade poolt, mis visualiseeriks päringute tulemusi ja annaks tagasisidet, millal viimati teatud tabeleid on kasutatud. Seega oli minu ülesandeks luua autentimislahendus, mis autendiks kasutaja ning pärast seda suunaks kasutaja rakendust kasutama. Autentimiseks kasutasin Google OAuth ja Auth0, et kiirendada arendusprotsessi ning ühtlasi olla kindel, et autentimine oleks tehtud valdkonna standardite kohaselt. Serveri poolse arenduse kohaselt tähendas see seda, et tuli kasutaja suunata Auth0 kodulehe, kus tuvastati kasutaja ning seejärel sain Auth0 käest JWT tokeni, kus oli kirjas kõik kasutajaga seonduv ning seejärel saatsin saadud info Firebase, mis on Google toode, mida nad ise promovad BAAS ehk Backend as a service. Kuna Frontend rakendus on majutatud (hosted) Firebase serverites, siis on mõistlik kasutada Firebase Autentimisteenust. Kogu see protsess, millest ma just rääkisin, seda nimetatakse mintimiseks.


Kui autentimine oli üles seatud, hakkasin seadistama Reacti rakendust. Selle alla kuulusid järgnevad tegevused.

  1. Routimine
  2. Veateadete kuvamine
  3. Päringute tegemine BigQuery API pihta.
  4. Monaco-editor ülesseadmine
  5. Profiili vaate tegemine
  6. Ant Disaini lisamine rakendusele.

  1. Routimise kõige raskem osa oli ilmselt privaat ja avalike routede ülesseadmine ehk inimesed, kellel polnud kasutatajat polnud õigust rakendust kasutada.
  2. Veateadete kuvamine on hetkel üsna primitiivselt lahendatud ehk kui päring mingil põhjusel ei töötanud, siis kuvasin kasutajale punast teksti, mis ütles vaid et oli probleem päringuga, kuid mitte midagi rohkemat. Järgnevate iteratsioonide jooksul on kindlasti üheks eesmärgiks parandada veateadeid, mis annaks rohkem informatsiooni probleemi kohta.
  3. Päringute tegemine on lahendatud hetkel Serverless arhitektuurina, mis kujutab endast seeda, et kuigi on olemas füüsiline server, siis tegelikult maksame ainult reaalsete päringute eest.
  4. Monaco editor üles seadmine kujutas endast hetkel seda, et on võimalik editori sisse kirjutada päringuid ning seejärel päring teha, kuid mitte palju rohkemat.
  5. Profiili vaate tegemine kujutab praegu endast seda, et kasutaja saab oma konto kustutada või väljja logida. Lisaks näeb ta oma profiilipilti.
  6. Ant disain on raamistik, mis aitab kiiresti tooteid itereerida, oma minimaalse disaini poolest on see ideaalne raamistik, mida kasutada, sest tulevikus on võimalik väga lihtsalt lisada omanäolusist lisada.

Kokkuvõtlikult

Tegu oli järjekordselt väga sisutiheda nädalaga, mille tulemusel sai päris palju tehtud. Nädala lõpuks tundsin juba, et olen ka üsna hästi ka seltskonda sisse sulandunud.

Kolmas nädal

Sellel nädalal läks CTO puhkusele, kes oli ka minu peamine juhendaja. Seega sain ülesandeks üles seada CRUD funktsionaalsus rakendusel. CRUD (Create Read Update Delete) funktsionaalsus pidi võimaldama kasutajatel salvestada, kustutada, uuendada ja luua päringuid, mida kasutajad on juba varem teinud. Funktsionaalsuse loomisel kasutasin Firebase Firestore, mis on järjekordselt üks Firebase pakutavatest teenustest. Tegu on NoSQL andmebaasiga. Firebase SDK ja dokumentatsioon on väga hea ning selle funktsionaalsuse üles seadmine polnud teps mitte nii raske. Natuke keerulisel oli aga mõelda, kuidas struktureerida andmeid ja teha kindlaks, et kasutajatel on ligipääs ainult enda andmete ja mitte kõigile. Tulevikus on teha ka superkasutajad ehk admin, kes võivad näha kõiki tehtud päringuid. Lisaks sellele pidin tegema rekursiivse funktsiooni, mille abil oli võimalik kuvada päringust saaduid tulemusi tabelis. Viimaks oli jäetud mulle vabad käed, kuidas ülejäänud aja veedan. Otsustasin uurida erinevaid avatud lähtekoodiga andmetöötlus tööriistu. Üheks silmapaistvamaks, mille esile tõtsan on Lyfti poolt tehtud Amundsen, mis on suunatud ka analüütikutele ja andmeteadlastele, et nad saaksid teha oma tööd paremini ja effektiivsemalt.

Kokkuvõtvalt

Sain omal käel hakkama CRUD funktsionaalsuse üles seadmisega ning oli väga põnev ringi sobrada Lyfti pool avatud tarkvaraga rakendustes.