James Cortada IBM istorija

James Cortada dirbo IBM berods 45-erius metus ir, išėjęs į pensiją, parašė virš septynių šimtų puslapių knygą apie šios kompanijos istoriją. Nemanau, kad „IBM: The Rise and Fall and Reinvention of a Global Icon“ pretenduoja būti labai objektyvi – tai žvilgsnis į IBM ilgamečio darbuotojo akimis, be didelės kritikos, daugiausia tik su nuomonėmis „iš vidaus“. Tad nereikia stebėtis, jog kompanija piešiama beveik vien tik teigiamomis spalvomis: inovacijų lyderė, technologijų etalonas ir panašiai. Net ir paskutinius tris dešimtmečius vykęs IBM nuosmukis nurašomas nekompetetingiems vadovams, kurie tik norėjo mažinti kaštus ir pasinaudodami finansų inžinerija išspausti kuo didesnę akcijos kainą. Bet IBM nuosmukis prasidėjo žymiai anksčiau, dar tada, kai jiems puikiai sekėsi ir kompaniją pradėjo valdyti pardavėjai bei „procesų vergai“, o ne technologijų žmonės. Su biurokratija ir per dideliais pažadais klientams toli nenuvažiuosi, net jeigu ir turi kone monopolinę rinką.

Nors tikrai ilgai tai buvo sėkminga strategija. Nuo pat 1940-ųjų IBM nesistengė būti inovacijų smaigalyje. IBM stiprybė buvo pardavėjai ir „customer service“:

Technology turned out to be less important than sales and distribution methods. Starting with UNIVAC, we consistently outsold people who had better technology because we knew how to put the story before the customers, how to install the machines successfully, and how to hang on to the customers once we had them.

James Cortada, „IBM: The Rise and Fall and Reinvention of a Global Icon“

Geras servisas ir puikūs pardavėjai leido IBM susikurti labai patogią rinkos poziciją: IBM buvo sinonimas žodžiui „patikima“. Padėjo ir tai, kad dėl didelės rinkos dalies visi imdavo laikyti IBM rinkos standartu, o tai padėdavo uždirbti krūvas pinigų iš visokiausių priedų, perfokortų (kurios, aišku, buvo patentuotos) ir panašių papildomų prekių ir paslaugų. Tik ši komfortabili pozicija neleido jiems greitai judėti naujose rinkose: stalinių kompiuterių era buvo beveik pražiopsota (o juk IBM turėjo tapti Microsoftu, tačiau negalėjo perlipti per save ir imti konkuruoti su savo didžiųjų serverių verslu, kuris ilgą laiką buvo aukso kasyklos), „debesis“ irgi visiškai pragrotas Amazonui, Google ir tam pačiam Microsoft. Prieš penkiolika metų kiek gyvybės įpūtė IBM noras tapti konsultacine programuotojų bendrove, bet pradėjus taupyti kaštus ir perkelti viską į Rytų Europą ir Indiją IBM prarado savo patikimumo veidą – ar bent jau taip mano autorius James Cortada: daugelis jo brangiai kainuojančių bendradarbių buvo atleisti taupant kaštus.

Knyga baigiasi ties 2018-ųjų pradžia ir ji vis dar kupina vilties, kad IBM renesansas jau čia pat už kampo – Watson ir dirbtinis intelektas viską išgelbės. Bet tai tik dar vienas pardavėjų, o ne inžinierių sukurtas produktas: IBM nuosmukis tęsiasi, o Watson neatrodo, jog pateisino viltis.

Kur Lietuvoje tolimiausia iki ežero?

Kartais būna taip, kad kažkur netyčia nugirsti kokią minties nuotrupą ir po to ji vis tavęs nepalieka. Taip ir man nutiko: prieš kokį pusmetį ar net metus kažkas kažkur paklausė, kaip būtų galima sužinoti, kur yra artimiausias ežeras. Pagalvojau, kad atsakymą nesunku surasti šiek tiek pakračius atvirus geografinius ežerų duomenis. Bet tada pradėjo kirbėti nauja mintis: o kuri Lietuvos vieta yra toliausiai iki bet kokio ežero? Aišku, bėgo mėnesiai, programuoti nesiėmiau, bet klausimas vis tiek niežtėjo. Šiandien pasikasiau.

Lietuvos taškas, labiausiai nutolęs nuo bet kurio ežero yra šiek tiek į rytus nuo Pašvitinio link Peleniškių kaimo (56.16N, 23.84E). Artimiausias jam – Pasvalyje esantis Šilo ežeras, kuris yra už 35.5 km (kaip varna skrenda).

Taškas (burbuliukas), kur toliausia iki ežero. Paspaudus galima didintis.

Techninės detalės

Naudojausi Overpass Turbo užklausa ežerams atrinkti, tad kaip ir norėjau, visokie tvenkiniai, prūdai ir marios į duomenis nepateko. Tiesa, gali būti kad ir ne viskas pateko, ko reikėjo: tarkim, ne visi Vilniaus Gulbinų ežerai atsirado duomenyse.

[out:json][timeout:50];
// gather results
(
  // query part for: “lake”
  way["natural"="water"]["water"="lake"]({{bbox}});
  relation["natural"="water"]["water"="lake"]({{bbox}});
);
// print results
out body;
>;
out skel qt;

Atstumams nuo taško iki pakrantės taškų naudojausi beveik visu kodu iš šio įrašo. Nedaug ir tereikėjo ką pakeisti.

Ką rinkčiausi duomenų ūkyje

Kuo didesnis klientas, tuo mažiau laisvės technologijų pasirinkimui – dažniausiai dirbi tais įrankiais, kurie jau naudojami organizacijos viduje. Naujų programavimo kalbų, operacinių sistemų ar duomenų bazių klientams nesinori, nes kažkam organizacijos viduje tas naujas technologijas reikės prižiūrėti. Jei visas tavo lėktuvų parkas sudarytas iš Airbusų, įsigyti vieną Boeingą „pažaidimui“ nelabai protinga. Tačiau kartais sveika pagalvoti, kokias technologijas rinktumeisi, jeigu viską darytum nuo nulio.

Duomenų bazė

Anksčiau buvau pratęs dirbti su MySQL – greita, paprasta, lengva administruoti. Šiuo metu rinkčiausi Postgres, nes nebegaliu gyventi be Common Table Expressions, o MySQL jų palaikymas dar tik labai šviežias. SQL kodas, rašomas su WITH ... AS ( ... ) yra žymiai lengviau skaitomas, o tai labai svarbu, jeigu tenka rašyti sudėtingas ne vieno šimto eilučių SQL užklausas. Be to, Postgres turi begales papildomų funkcijų ir galimybių – kuo reikia sudėtingesnės verslo logikos, tuo mažiau pradeda tikti MySQL.

Savaime suprantama, galima naudotis ir MS SQL Server ar Oracle, tačiau lemiamas argumentas visgi yra kaina.

Programavimo kalba

Pradėjęs nuo Perl, jaunystėje daug ko daręs su PHP, po to perėjęs prie Ruby, kažkiek krapštęs R, nesusigyvenęs su Scala, šiuo metu viskam rinkčiausi Python. Daug reikiamų bibliotekų duomenims maigyti, nuo paprasto ETL iki dirbtinio intelekto ir beveik bet kokio machine learning (na, galbūt dar vis kokiais specifiniais statistiniais algoritmais čia jį lenkia R, bet universalumu R tikrai nusileidžia). Be to, python kuo toliau, tuo labiau populiarėja – tai ne eksperimentinė nišinė kalba, kurią gerai supranta tik sauja žmonių: tai svarbu, norint užtikrinti, jog kažkada kas nors iš tavęs galės sklandžiai perimti projektą.

Operacinė sistema

Labai dažnai dirbant Microsoft ekosistemoje tenka dirbti su Windows serveriais – nieko labai blogo, bet žymiai labiau esu pratęs prie Linux (ir daugiausiai Debian / Ubuntu). Konsolėje jaučiuosi kaip namie, juodas ekranas man jaukus ir savas, todėl rinkčiausi būtent jį. Bet kartu labai suprantu, kad administruoti naują operacinę sistemą to niekad nedariusiam yra labai sudėtinga, tad jei visi kompanijoje naudoja Windows, naujų žvėrių zoosode matyt nereikėtų.

Darbų dirigentas

Manau, kad įvairiems ETL darbams planuoti ir diriguoti naudočiau Apache Airflow. Rašyta python, turinti daug galimybių, aprėpianti beveik visus įmanomus poreikius, po truputį tampanti industrijos standartu (bent jau atviro ir nemokamo kodo ekosistemoje). Taip, reikia rašyti kodą, bet tai, mano nuomone, privalumas. Daug programuotojų gal ir nustebs, bet labai dažnai drag&drop įrankiai didelėse organizacijose labai vertinami, nes jie suteikia (dažniausiai nepasiteisinančią) viltį, jog duomenų ūkį lengvai galės administruoti koks nors net SQL nemokantis stažuotojas iš finansų analizės poskyrio. Paprastiems dalykams gražūs pele stumdomi daiktai gal ir veikia, bet kai viskas susivelia į vieną didelį neišnarpliojamą kamuolį… (taip, piktai žiūriu į tave, Alteryx).

Kiti būtini dalykai

git. Būtina naudoti git. Bet kokia forma (github, gitlab, bitbucket, savo pačių daryta, bet kokia…), bet būtina naudoti kodo versijavimą. Niekaip nesuprantu, kodėl didelėse organizacijose kodo versijavimas toks retas. Vis dar kodas taisomas tiesiai serveryje, vis dar dažnai kokioje nors direktorijoje kaupiasi programos pavadinimu load_foo_v12.192_final_do_not_use.sql. Tikriausiai kultūriškai tai ateina iš Excelio ir įvairiausių „vartotojui draugiškų“ drag&drop įrankių – lengvai jų į versijavimo sistemą nesudėsi.

Testai. Jeigu versijavimo sistemas tai dar pas klientus galima kur nors rasti, testus duomenų bazėms bei ETL programoms labai mažai kas rašo. Kuo mažiau kompanijoje inžinierių, tuo mažesnė tikimybė, jog kodas bus tikrinamas testų pagalba.

Duomenų bazių testavimas

Prieš keletą dienų užtikau patikusį straipsnį apie automatizuotus duomenų bazių testus. Programiniam kodui jau senokai tapo įprastinė praktika rašyti testus, bet duomenų bazių struktūra testuojama ne visada. Tiesa, gerai sutvarkytoje duomenų bazėje įmanoma sudėti daug saugiklių: stulpeliams uždėti apribojimus, išorinius raktus ir panašiai, tačiau bendras požiūris į duomenų teisingumą bei validumą vis tiek reikalingas.

Autorius siūlo duomenis testuoti trijose vietose: pirminių šaltinių lygyje, tik juos sukėlus į duomenų bazę ir jau po verslo logikos transformacijų. Šis testų sąrašas atrodo visai nebloga pradžia:

  • Ar visi pirminiai raktai lentelėse unikalūs?
  • Ar [svarbiame stulpelyje] nėra null reikšmių?
  • Ar visi išoriniai raktai egzistuoja lentelėse kaip pirminiai raktai (be dublikatų, ir pan. – referencinis integralumas)?
  • Ar skaitinės duomenų reikšmės neiššoka iš tikėtino reikšmių rėžio?
  • Ar agreguoti duomenys atitinka detalesnių duomenų informaciją (ar čekio suma atitinka atskirų prekių sumai čekyje)?
  • Ar yra visi stulpeliai, kurie bus naudojami galutinėse lentelėse?
  • Ar įmanoma be klaidų paleisti dažniausiai pasitaikančias verslo užklausas?

Dar prie šio sąrašo pridėčiau patikrinimą, ar eilučių kiekis įvairiose duomenų bazės lentelėse yra toks, koks ir tikėtasi – labai dažnai dėl kokios nors lentelių jungimo klaidos duomenys susidublikuoja.

Rožės monitoringas su Raspberry

Noriu pasigirti: žmonos paskatintas pirmą kartą su Raspberry Pi nuveikiau kažką sudėtingesnio nei vien tik pajungiau prie jo kamerą. Jai paklausus, ar nebūtų įmanoma sukonstruoti kokio nors prietaiso, stebinčio rožės dirvos temperatūrą, suėmė savotiškas azartas, ir jau kitą dieną stovėjau prie visiškai neaiškių daiktų kupinos vitrinos elektronikos komponentų parduotuvėje. Kažkokie sensoriai, laidukai, mikroschemos, montažinės dėžutės, rezistoriai ir kiti ten parduodami dalykai – nieko nesuprantu, nieko nežinau. Ar čia man reikia to, ar kito, ar skiriasi kuo DHT-22 nuo DHT-11, kokių ir kiek man reikia rezistorių (o jų iš vis pasirodo reikia?), o jei neturite BCM3008 mikroschemos kur Youtube mačiau kad man reiks, tai ar tiks kas nors kitas? Sakot ADC1115? Jei reiktų apie Hėgelio filosofiją pasikalbėti čiuvašų kalba, manau, kad jausčiausi pasimetęs mažiau nei toje elektronikos parduotuvėje atsakinėdamas į konsultanto klausimus.

Sistemos bandymai

Visgi nukovęs glėbį keistų komponentų, pergalėjau save, praleidau kelis vakarus prie įvairiausių forumų bei straipsnių internete ir sukonstravau kažką veikiančio. Prie Raspberry prijungiau oro temperatūros ir drėgmės jutiklį (net kažkiek apygraibomis supratau, kodėl dar prie jo reikia pajungti rezistorių) ir dirvos drėgmės sensorių. Pastarasis duoda analoginį signalą, tad reikėjo prijungti ir analoginio-diskretinio signalo konvertavimo mikroschemą. Kol kas dar jos nelitavau, tad bet koks sujudinimas dažniausiai reiškia, jog vėl kažkas nusimušė. Buvo šiek tiek vargo.

Nustebau, kad visgi tie visokie su geležimi ir mikroschemomis susiję dalykai buvo ganėtinai nesudėtingi – programavimas tikriausiai sunkiau įveikiamas niekada su tuo nesusidūrusiems. O čia tik reikia teisingai sujungti laidukus, nieko sudėtingo. Ir dar gauni tam tikrą pasitenkinimą, kai matai, jog fiziškai tavo padarytas daiktas veikia.

Viso to pasekmė: rožės monitoringo svetainė, kurioje beveik realiu laiku galima matyti balkone esamą oro temperatūrą, santykinę drėgmę ir dirvos „prilaistymo“ procentą. Pastarasis kol skaičiuojamas gana komplikuotai, mat daviklis duoda įtampą, pagal kurią sukalibruoti drėgnumą reikia pačiam: 100 proc. buvo tik dirvą paliejus, o 0 proc atitiko sensoriaus įtampą jį ištraukus iš dirvos. Tikėtina, kad kažkur ties 50 proc drėgnumu jau galima bus siųsti įspėjimą, jog rožę reikia vėl laistyti. Matyt, reikės ir kitų korekcijų: dieną kylant temperatūrai, dirvos pralaidumas elektrai didėja, tad sensorius mano, jog dirva tampa drėgnesnė.

Sujungtos mikroschemos

Naudotos detalės: ADC1115 mikroschema, DHT–22 temperatūros sensorius, YH–69 dirvos sensorius, Raspberry Pi B series.

Nick Bostrom: „Superintelligence“

Kai perskaičiau Max Tegmark’o „Life 3.0“, buvau piktas – tema įdomi ir aktuali, bet skaitai ir supranti, kad autoriui kompetencijos dirbtinio intelekto klausimais mažokai. Tad ėmiausi Nick Bostromo knygos „Superintelligence“, nes ją dauguma laiko žymiai rimtesne.

Šioje knygoje esminiai skyriai yra patys pirmieji, kuriuose diskutuojama apie tai, kada (ir ar iš vis) įmanoma pasiekti dirbtinio intelekto sprogimą: kada jau turėsime tokį dirbtinį intelektą, kuris pats besimokydamas mus aplenks savo protu. Visi kalbinti ekspertai teigė, jog arba po kokio šimtmečio, arba niekada. Likusi didžioji knygos dalis yra „kas būtų, jeigu būtų“ pasvarstymai, kurie gal ir įdomūs ir arčiau žemės nei Max Tegmarko svaičiojimai apie Daisono sferas, bet vis tiek palieka intelektualinio savismaginimosi prieskonį.

Manau, kad didžiausia problema, jog į dirbtinį intelektą žiūrima kaip į technologinę problemą, neturint filosofinio pagrindo. Vien dėl to Asimovas robotizacijos klausimais gali pasakyti žymiai daugiau nei Bostromas – ir Asimovo apysakos net po penkiasdešimties metų atrodo aktualesnės. Dirbtinio intelekto suvaldymas nėra vien tik mechaninis technologinis sprendimas – tai žymiai gilesnė problema. Mes juk net nežinome, kaip dirbtiniam intelektui suformuluoti optimizacijos uždavinį: nepakanka pasakyti, jog norime, kad žmonija būtų laimingesnė, nes iš karto kyla klausimas, kaip tą laimę apibrėžti ir išmatuoti. Ir čia algoritmai bejėgiai.

Knygoje yra ir daug keistokų bei naivokų svarstymų apie žmoniją: kaip čia juos suvaldyti, kad kas nors piktybiškai neimtų kurti pavojingo dirbtinio intelekto. Sako, tereikia tik tvirto susitarimo ir melo detektoriaus, tik skaitant neapleidžia toks jausmas, kad autorius nelabai supranta, kaip veikia pasaulis, ir iš istorijos nėra daug ko išmokęs: galėjai tartis kiek tik nori, bet atominę bombą vis tiek visi susikūrė, kas tik labai norėjo. O melo detektorius, kaip techninis sprendimas irgi itin naivus – ar bent įmanoma tiksliai apibrėžti, kas yra melas, o kas tiesa?

Lietuvos miestų gatvės pagal pasaulio šalis

Neseniai užtikau įdomią JAV bei kitų pasaulio didmiesčių gatvių orientacijos analizę, darytą vienu mano mėgstamiausių python modulių osmnx. Kadangi kodas viešas, tai buvo nesunku tą patį padaryti ir Lietuvos miestams.

Kaunas ir Vilnius – gana chaotiški, o kitur vyrauja aiški kvartalinė sistema

Kuo senesnis miestas, tuo didesnis senamiestis, o šie dažniausiai būna chaotiški. Naujesniuose miestuose daugiau vyrauja aiški kvadratinė kvartalinė sistema. Buvo įdomu tai, kad dažniausiai ji ne tiksliai šiaurės-pietų bei rytų-vakarų krypties, o apie 20 laipsnių pasukta pagal laikrodžio rodyklę (Alytus, Gargždai, Kretinga, Kėdainiai, Marijampolė, Mažeikiai, Neringa, Palanga, Telšiai – ypač Žemaitijoje). Tobulai pagal pasaulio šalis orientuoti Elektrėnai (kuo tikriausiai nereiktų stebėtis) ir Utena, Visaginas ir Šiauliai išsidėstę įstrižai žemėlapio šalims.

Robotas irgi žmogus

Iš pažiūros duomenų analizė yra labai nešališkas ir objektyvus reikalas: paimi krūvą duomenų, perleidi per sudėtingą statistinių algoritmų mėsmalę ir gauni kažkokias įžvalgas. Mūsų produktą labiau mėgsta Marijampolėje, brangesnius produktus moterys perka savaitgaliais, socialiniuose tinkluose sekantys veikėją X skaito portalą Y, bent tris kartus gavę labai didelę mėnesinę sąskaitą yra linkę perbėgti pas konkurentus. Su regresijomis (ar sudėtingesnėmis analizėmis) ginčytis sunku, nes duomenys lyg ir kalba už save. Nebereikia spėlioti ir remtis dažnai mus pavedančia intuicija. Bet algoritmai nėra jau tokie neutralūs: jie klysta visai kaip žmonės, nes jie mokosi iš tų pačių žmonių jiems pateiktų duomenų. Tad aklai pasitikėti algoritmų sprendimais nereikėtų.

Vienas to pavyzdys yra JAV naudojamas algoritmas, sprendžiantis apie nuteisto nusikaltėlio polinkį dar kartą nusikalsti. Neseniai buvo pastebėta, jog šis algoritmas turėjo rasistinių polinkių: jeigu esi juodaodis, jo nuomone, tavo recidyvizmo tikimybė didesnė. Kadangi tokiais algoritmais naudojamasi sprendžiant, kokio dydžio bausmę skirti, juodaodžiai už tokius pat pažeidimus automatiškai baudžiami stipriau nei visiškai toks pats baltasis kaimynas, kuris gyvena beveik identiškomis socialinėmis sąlygomis. Su panašiomis diskriminacinėmis problemomis susiduria ir moterys: algoritmai mano, kad jos turi žymiai mažesnę tikimybę uždirbti aukštesnę algą, todėl net joms net nerodo gerų darbo pasiūlymų. Jei tik keliolika procentų vadovų yra moterys, tai net neverta švaistyti lėšų joms rodant vadovų darbo skelbimus.

Tokią algoritmo klaidą ištaisyti nėra taip paprasta, kaip gali pasirodyti. Net jei įstatymais uždrausi kuriant algoritmą atsižvelgti į žmogaus lytį ar odos spalvą, yra daug kitų su šiais dalykais koreliuojančių faktorių. Jei 82% namų ūkių su nepilnamečiais ir tik vienu suaugusiuoju sudaro vieniša mama su vaikais, tai iš šeimos sudėties nesunku atspėti suaugusiojo lytį. Juodaodžius galima atskirti pagal vardus, o Lietuvos atveju, tautybę tikriausiai nesunku suprasti pagal pavardę. Žmogaus gyvenamosios vietos pašto indeksas irgi labai daug ką pasako.

Dirbtinio intelekto algoritmai yra kaip vaikai, kurie mokydamiesi iš aplinkos pradeda suvokti ryšius tarp kintamųjų. Lygiai taip, kaip svarbu, jog vaikas bendrautų su tinkamais žmonėmis ir augtų ne asocialioje aplinkoje, taip ir algoritmo negalima lengvabūdiškai tiesiog paleisti mokytis į platųjį pasaulį. Tai pernai suprato Microsoft, paleidusi savaime besimokantį Twitterio botą Tay, kuris per kelias valandas iš interneto vartotojų išmoko daug rasistinių frazių ir tapo piktu keikūnu. Net ir akylai prižiūrint dirbtinio intelekto mokymosi procesą, mokymosi pavyzdžių imtis turi gerai atitikti realaus pasaulio proporcijas (o tai nevisada lengva pasiekti). 2015-aisiais Google išleistas atpažįstantis objektus nuotraukose algoritmas sukėlė skandalą, mat juodaodžių nuotraukas klaidingai klasifikuodavo kaip beždžiones: jis mokėsi daugiausiai iš baltųjų nuotraukų. Panašiai, kaip Delfi žino apie automobilius tik tiek, kad jie dažnai patenka į avarijas.

Galų gale net jei ir labai atsargiai suformuosi duomenų imtį algoritmo mokymuisi ir atidžiai prižiūrėsi visą procesą, mūsų visuomenėje yra tam tikrų stereotipų ar šališkumų, kurie atsispindės duomenyse. Jei dirbtinio intelekto algoritmą mokysi naudodamasis 1870-ųjų studentų duomenų baze, tikėtina, jog jis į magistro programą siūlys priimti beveik vien tik vyrus. Jeigu algoritmas išmoksta tavo keistumus ir atsižvelgdamas į tavo iškreiptą pasaulio vaizdą tau siūlo skaityti tik straipsnius apie konspiracijos teorijas, tai tik padidina tavo tikėjimą jomis – algoritmai ne tik kad nepadeda objektyviau suvokti pasaulį, bet vis labiau jį iškreipia. Klaidingi įsitikinimai sustiprinami ir daromos vis didesnės klaidos.

Ar yra išeitis iš šios spiralės? Vargu, ar visiškai įmanoma sukurti idealius algoritmus, nes jie tėra mūsų visuomenės atspindys. Kritinis mąstymas ir skeptiškumas tampa labai svarbiais įrankiais atskiriant tiesą nuo melagingų naujienų, tik šiais hiperaktyviais laikais, kai dėmesį gali sukaupti tik kelioms sekundėms, tai tampa brangu ir nemadinga.

Zylių stebykla

Man patinka vis ką nors naujo išmokti, o mokytis geriausia ką nors darant. Taip visai netyčia užgimė Rube Goldbergiško stiliaus zylių stebėjimo projektas, kuris savyje sujungė norą išsibandyti python kalbos bibliotekas konvoliuciniams neuroniniams tinklams su idėja viską padaryti Amazon AWS debesies infrastruktūroje be jokių dedikuotų serverių vien tik su Lambda funkcijomis. Suprantu, kad tiems, kas su tokiais dalykais nesusiduria tai skamba lygiai tiek pat įdomiai kiek man skambėtų nauja variklio vožtuvo modifikacija paskutiniame BMW modelyje (tikiuosi nesuklydau, kad vožtuvai kažkaip susiję su varikliais, non?), bet trumpai tariant, projektas tapo sudėtingas dėl to, kad norėjosi prie lesyklos atskridusias zyles registruoti automatiškai, o tam vien judesio daviklio neužtenka: kartais dėl didelio vėjo juda pati lesykla, kartais užfiksuojama pravažiuojanti mašina, o kartais vaizdas pasikeičia, nes atidarius balkoną aprasoja stiklas. Taigi, reikėjo sistemą „išmokyti“ nuspręsti, ar kadre šiuo metu yra zylė. Tiesa, pati sudėtingiausia dalis pasirodė esanti zylių atpažinimo funkcijų perkėlimas į debesį: nes juk kam daryti viską įprastai, jeigu galima kuo sudėtingiau. Bet rezultatas mane džiugina: gal ne tiek dėl to, kiek kasdieną priskaičiuoju zylių, o dėl įgytų žinių ir patirties. Apie Amazono debesį ir kaip apeiti jo ribotumus sužinojau tikrai daug.

Keletas detalių tiems, kam jos įdomios: balkone, prie zylių lesyklos, stovi Orange Pi kompiuteris su web kamera, kurioje sukasi motion, o jis veikia kaip judesio daviklis. Atsiradus judesiui, daromos jpg nuotraukos ir siunčiamos į Amazon S3 kibirą, o čia yra trigerinama lambda funkcija, kuri išima iš paveiksliuko jo foną (faktiškai yra paskaičiuojamas skirtumas tarp apdorojamo paveiksliuko ir foninio paveiksliuko, kuriame tikrai nėra zylės). Taip paruoštas ir sumažintas paveikliukas per Amazono SNS servisą atiduodamas kitai lambda funkcijai, kuri perleidžia paruoštą paveiksliuką per ištreniruotą neuroninį tinklą ir išspjauna atsakymą, kiek, jo nuomone, paveiksliuke yra zylių. Šie atsakymai kaupiami SQS eilėje iki tol, kol motion mano, kad judesys baigėsi ir į S3 kibirą įkelia viso judesio vaizdą. Tai trigerina trečią lambda funkciją, kuri paskaičiuoja vidutinį zylių skaičių SQS eilėje, ir, jei jis gana didelis, statinėje svetainėje apie tai padaro naują įrašą. Eilė išvaloma ir viskas prasidės iš naujo tada kai tik bus užfiksuojamas naujas judesys.

Zylių stebėjimo sistema per Amazon debesį

Vilniaus viešojo transporto duomenys

Niekada iki šiol nenaudojau dplyr R paketo, tad norėjau pasižiūrėti, kaip jis veikia (o veikia jis tikrai patogiai!). Kadangi neseniai buvo paviešinti Vilniaus Viešojo Transporto vėlavimų duomenys, tai kaip tik šis duomenų rinkinys pasirodė tinkamas pasižaidimui. Kadangi tai labiau techninis galimybių bandymas, tai didelių įžvalgų ir neieškojau, nors visgi radau, kad privatūs vežėjai vėluoja žymiai rečiau nei VVT, troleibusai yra patikimesni nei autobusai, o savaitgaliais viešasis transportas yra punktualesnis (kuo nereiktų stebėtis – juk eismo mažiau).

Nevėluojančių reisų dalis
Nevėluojančių reisų dalis

Detaliau ir techniškiau, su visu kodu: Notebook: Transportas-vėlavimai