A Kolab project kapcsán eszembe jutott, hogy le kell porolnom a saját életem architecture capability-jének megvalósítását célzó törekvéseimet.
Elmagyarázom. (És ha eddig nem volt világos: kőkemény geek, illetve architecture post következik.)
Adott ugye egy ember, aki idejének jelentős részét tölti a neten, ennek során különféle webes appokat használ. Ezek tipikusan egy kialakult core körül mozognak, de szintén tipikusan vannak „szatelit” webappok, amiket váltogatunk — ki többet (pl. aki félévente átáll blog.hu-ról Tumblr-re, onnan Postr-re, majd amikor az bezár, valami másra stb.), ki kevesebbet (pl. én, aki 2002 óta blogol és 2, azaz kettő platformot használt ezalatt; és egy domaint).
A probléma: a szolgáltatások jelentős része átfedésben van, mármint ami a funkcionalitást, és főleg a tárolt/átvitt adatot illeti. Az Instagramról átkerül a fotó a blogra, onnan Facebookra és Google+-ra, meg Twitterre, és kész a baj, egyrészt három helyen van meg a fotó ami architekturálisan ugye botrány, másrészt három külön like- és kommentfolyam van, ami szintén.
A probléma persze az, hogy a fenti jelenség a jelenlegi világrendből fakad: a walled garden szolgáltatásoknak nyilván pontosan az a célja, hogy minél több adatot magánál tartson, sőt, minél több adat „mastere” legyen. A Facebook nem fog Google+-nak kiadni kommentfolyamot, mert az az ő üzletüket rontja, pedig lehetne. („Minden adat metaadat” — lehetne.) A vesztes természetesen a felhasználó, nem csak az, aki létrehozza a tartalmat, hanem az is, aki fogyasztaná, de egyszerre csak egy bizonyos vetületét látja. Írtam erről a problémáról már a Miért Firefox OS? posztomban is, talán látható, hogy több aspektusból is foglalkoztat, hovatovább: zavar a jelenség.
A probléma tehát adott, viszont több síkon létezik:
- Felhőszolgáltatások esetén nem nagyon tudjuk kontrollálni, hogy mi történik. A Twitter, a Facebook, a Google+ nem fognak a kedvünkért hajlani, ha úgy döntünk, hogy fontos ott a jelenlét, el kell fogadnunk az adatduplikálás tényét, és az ezzel járó kavarodást. Maximum ki tudjuk találni, hogy kit tekintünk (mi, a felhasználó; nem a szolgáltató!) master adatforrásnak, és pl. IFTTT segítségével megoldjuk a webappok közti reshare-láncot.
- Személyes jellegű adatok esetében már (elvileg) jobb a helyzet: a levelezésünkre, naptárunkra, címjegyzékünkre tipikusan egy szolgáltatást használunk, és ideális esetben ezt a master forrást tudjuk használni több helyen is. Vannak persze kivételek, amikor pl. egy termék nem API-n, hanem fix időközönkénti importáláson kersztül éri el a címjegyzékünket (ezáltal ugye beépített lemaradással duplikálva a mastert, brr), vagy amikor POP3-mal használjuk a levelezést, amit remélem 2014-ben már senki sem csinál.
- Aztán pedig vannak a „határon mozgó” adatok: ilyennek tekintem a chatet, a blogot, személyes fotókat, jegyzeteket, stb. Ezeknél fennáll a választás lehetősége, nem is feltétlenül vagyunk egy-egy társadalmi elvárás diktálta walled gardenbe kényszerítve, mégis megvan bennük a walled garden veszély, a felhő jelenség (pl. megszűnő Catch Notes, ugye), a duplikálás veszélye — ha nem vigyázunk, összekutyulódik az egész.
Attól függetlenül (persze majd erre is kitérek), hogy adott feladatra felhő- vagy „vasalapú” szolgáltatást használunk (vagyis pl. levelezésre Gmail vagy saját szerver), és talán itt következik a posztom témamondata:
Fontos, hogy feltérképezzük az online életünket felépítő komponenseket, építőkockákat, és meghatározzuk ezek magasszintű architektúráját.
A Kolab projektben felmerült egyik probléma kapcsán jöttem rá, mennyire fontos ez: bár a levelezésem Kolabon van, a Gmailemmel (korábbi levelezés megoldás ugye) együtt jött a Hangouts, amit jelenleg Kolabon nem tudok duplikálni. Miért fordult ez elő? Mert eszembe se jutott. Miért? Mert nem voltam felkészülve a létem adatmodelljével, amikor belevágtam a projektbe! Az ember nem is látja, hogy mennyire függ egyik adata a másiktól, amíg el nem kezdené őket szétválasztani valami mentén.
Ennek kiküszöbölésére hétköznapiasan fogalmazva a következő lépcsőket kell végigjárni:
- Gondoljuk át hogy milyen fajta adat entitások fordulnak elő az életünkben (pl. „levél”, „tweet”, „fotó”, „kontakt”, stb.), írjuk le amennyire teljesen csak lehet.
- Szépen tegyük oda mindegyik entitás mellé hogy milyen rendszerben generáljuk az adatot, ő a master adatkomponens, logikai.
- Érdemes azt is feltérképezni, hogy adott masterről milyen más rendszer készít másolatot, transzformálja, vagy egyszerűen csak transzferálja.
Ha ezzel megvagyunk, kész van életünk adat entitás/komponens katalógusa, és kezdődhet az érdemi munka:
- az adatfolyamok, ha úgy tetszik: saját folyamataink tisztázása, a mastership-ek definiálása;
- a fölöslegek, duplikát masterek eltávolítása, kiküszöbölése;
- és ami miatt számomra az egész gyakorlat jelenleg fontos: annak felmérése, hogy milyen adat esetében tudok esetleg szabadabb, biztonságosabb, nyíltabb alternatívát felhasználni.
Azt hiszed ez pikk-pakk megvan? Nos, akkor vágj bele! Én legalábbis ezt fogom tenni, aztán haladok tovább: meghatározom az alapelveket, a komponens interakciókat, létrehozok mátrixokat, mely kaland végén egy jól definiált szolgáltatáskészletet fogok tudni használni mindenféle adatigényem kielégítésére. Épül-szépül a capability!
akkor ez tényleg azt is jelenti, hogy az instagramos fotókat nem tolod ki a blogra, g+-ra, facebookra, twitterre és linkedinre egyszerre? :)
ha ha szeretnéd mi? :-D
Ezen már magam is morfondíroztam. Sőt mi több eszembe jutott, hogy egyszer tuti el fogunk oda jutni, hogy valaki elkezd ‘metaadat tárház’ szolgáltatást nyújtani (egy gyönge pillanatig az is megfordult a fejemben, hogy majd én – höh ). Ahol a user eldöntheti, hogy az egy helyen tárolt adatai közül, milyen adatához milyen felület férhet hozzá.
Tehát ha holnap bezár a facebook (ok nem túl életszerű – de tételezzük fel) mert nem lesz elég mókás és változatos már a felhasználóknak – akkor nyit majd egy másik cókmók amibe ha regisztrálsz akkor a régi adatfolyamaidat átrugdoshatod ha akarod cakk-pakk ha nem akkor szűrve.
Mennyivel egyszerűbb lenne, ha pl nem lenne LinkdIn meg Facebook meg G+ accom hanem lenne egy metaadatbázisom (nyilván itt az adatbiztonság aztán 1000x nagyobb kérdőjel lenne) és én eldönteném, hogy abból mihez fér hozzá melyik felület.
Vagy ha RSS olvasót, böngészőt cserélek akkor nem kéne importálni-exportálni össze vissza a favoritokat.
Ha blogmotort cserélek (ok – értem én mit mire … de tételezzük fel) akkor nem kéne konvertálni adatbázisokat jobbra-balra.
Gyakorlatilag az online életemet nem kötném más programok szolgáltatási köréhez, hanem csak a „skint” és a „feature listát” választanám meg. Az adatok egy helyen egy szabvány szerint lennének amit mindenki kezel … Akár nem csak online aplikációk hanem OS -ek is … mindegy, hogy éppen milyen interfacet használok.
Persze vannak kérdések :
-amit felhasznál a felület azt miért nem tölti le is – mondván, hogy cachel nekem, hogy gyorsabb legyen
– ki merné vállalni a rizikót, hogy olyan szolgáltatást nyit amiben minden benne van de senki se fúrja meg soha … mert valószínűleg azért előbb utóbb titkosszolgálatok kopoktatnának az „információ szabad” feliratú hippikommunánk ajtaján …
@Saimonsais Ha emlékszel, anno volt egy ilyen irány. „Minden adat metaadat”, mondtuk, ma meg már csak az NSA mondja (nekik tényleg az), és ezt tényleg komolyan is gondoltuk, amikor a read-write web még csak cseperedett, a webkettő meg még nem hogy elcsépelt, de létező kifejezés se volt.
Ma ezt nem tudnád megtenni, mert silósodva van az egész net. A szolgáltatók jelentős része megnehezíti vagy meggátolja, hogy rendesen kinyerd az adatodat, vagy pl. egy másik szolgáltatásból használd. Facebook postokat akarsz kommentelni egy blogról? Fasza, add nekik az összes kommented, és megteheted. Ja, hogy ettől nem a tied az adat, illetve pl. kizárod a Google+ felhasználókat? Ohwell…
Szerintem egy teljesen pozitív jövőkép (lenne) az általad említett metaadat tárház, mert azt jelentené, hogy a szolgáltatók felismerték a felhasználók saját jogainak fontosságát a szolgáltatások közötti átjárásra… (Mellékszál, illetve továbbgondolásra: többek között erről az irányról is azt gondolom, hogy jelenleg legjobban egy Mozilla tudja képviselni.)