g33ker címkével jelölt bejegyzések

The only thing they didn't see was the irony

Kvmellé Weekly, olvasnivalók a kávé-vaníliás karika killer combo mellé.

The only thing they didn't see was the irony
The only thing they didn’t see was the irony

Politika, közélet, #seggszag

Geekdom Bővebben…

Új Instagram for Android: óriási lépés – oldalra.

Minden másirányú törekvésem, meg holmi Facebook-féle felvásárlás ellenére még mindig Instagramot használok fotó-mikroblogolásra (aka. hipszterfotózás), úgyhogy nagy örömmel olvastam tegnap @hh-nál, hogyaszongya

Úgyhogy megnéztem, és hát nos… Bővebben…

Kvmellé Weekly, a hét linkjei egyben.

Cameramen shooting and recording the lion roar for the MGM logo

Mert az oké, hogy KVM, de ki az az ellé?

Közélet – még mindig a Krím

Geekdom Bővebben…

Élet-architektúra, 2. rész: alapelvek.

<< Előző (első) rész

Bevallom, az Élet-architektúra előző (első!) részében kicsit előreszaladtam — nagyjából a legizgalmasabb részénél csaptam bele a lecsóba, pedig a TOGAF szerint ez (mármint egy ilyen komponens katalógus) csak valahol később (Phase C, data architecture-nél) zajlik le rendesen.

Az előző rész végén is hinteltem már, most menjünk hát bele kicsit részletesebben a scope, és az alapelvek nem kevésbé izgalmas kérdésébe.

(Kis kitérő, hogy valós életből vett okot említsek ezeknek a fontosságára: amikor a minap átálltam Kolabra, nagyon gyorsan realizáltam, hogy hoppá, a chatem, nevezett Hangouts is Google, azt is weben használom, következésképpen valami Google szolgáltatásnak így is, úgy is nyitva kell lennie… Hümm-hümm, tisztán látható, hogy nem volt ez jól megalapozva, a chat is személyes adat, azzal is kezdenem kell valamit — kimondani hogy marad a Google-nél, vagy kimondani hogy implementálok egy saját Jabber servert… De egy lépést hátratéve: kimondani azt az alapelvet, ami mentén ezt, és a hasonló kérdéseket (mert biztosan lesznek még) meg tudom gyorsan, elfogulatlanul válaszolni!) Bővebben…

Jegyzetappgate.

Egy ideje már, hogy feltűnt: a Google, gondolván a felhasználókra, a Google Keep-et akksi benchmark funkcionalitással bővítette. (Gyanúm szerint egyébként egy Google Play Services frissítésen keresztül, because fuck you.) Ez praktikusan annyit jelent, hogy időnként (úgy napi kétszer, ha nem figyelsz) a Google Keep elszáll, wakelockot okoz, folyamatosan küldi a procit a telefonban — és kb. 5-6 óra alatt 100%-ról 0-ra degradálja az akkutöltést. Amikor kedden 3 óra alatt lement 54%-ra az akksim és emiatt aztán alig bírta ki hazáig, betelt a pohár és lehenteltem a telefonról az appot. (Persze nemodabuda, mert ez Google app én meg jelenleg stock, locked Androidon vagyok, szóval maradjunk annyiban hogy uninstall updates és disable app megvolt.)

Ez viszont érdekes problémát hagyott maga mögött: mi a pöcsöt fogok használni jegyzet appnak?

A Catch, a korábbi favorit, bezárt — ezért maradt akkor a Google Keep. Nekem meg igazából nem kell más, csak egy app ami weben is van, Androidon is van, egyszerű hozzáadni jegyzetet, bevásárlólistát. Todo-t nem kell kezelnie, egyáltalán nem kell bloatware-nek lennie. Nem árt, ha a webes verzió billentyűzetről is vezérelhető, á la Trello. És mindenek fölött: egyszerű használni.

És akkor ezzel szemben kb. van a sípolóseggű lovacskákat csapatokban felvonultató két piacvezető: a SpringPad és az EverNote, ahol a jelek szerint a jegyzetelés erősen másodlagos feature a sok haszontalan baromság között. És béna a webes felület, és nem vagyok meggyőződve az Android appokról sem.

E? – kérdem tanácstalanul, de nem minden reményt feladva.

Élet-architektúra projekt, 1. rész: belevágás.

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:

  1. 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.
  2. 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.
  3. 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:

  1. 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.
  2. Szépen tegyük oda mindegyik entitás mellé hogy milyen rendszerben generáljuk az adatot, ő a master adatkomponens, logikai.
  3. É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!

Következő rész >>

Exchange in a bottle.

Felpoppant ma egy “DS Architects Infoshare Session” reminder a naptáramban, tentative el volt fogadva, nyilván valamikor tavaly elfogadtam vakon, mert benne volt hogy Architects — gondoltam.

LiveMeeting link katt, access denied, meeting has ended. Invite-ban background material&agenda link katt, no access, or moved.

Írtam hát a meeting organisernek, hogy “is this session on?”, mire a következőt kaptam:

Gergo,

If you’re referring to the DS Infoshare, than I’m afraid that series was cancelled about 2 years ago

2 years, érted… MS Exchange never ceases to amaze me!

Blackphone: az egymondatos vision, ami működik.

Érdekes kezdeményezés a Blackphone. A vision szerint

Blackphone is the world’s first smartphone which prioritizes the user’s privacy and control, without any hooks to carriers or vendors.

És így tovább, és így tovább. A helyzet az, hogy bár ez a mondat kb. minden, amit jelenleg tudni a projektről, illetve azt, hogy a hardver elvileg csúcskategóriás lesz, és lesznek rajta “eszközök”, amik a fenti egy mondatot támogatják.

Mindenesetre a konkrétumok nélkül is izgalmas a sztori, elég volt arra, hogy feliratkozzak a hírlevélre.

Két dolog jut még eszembe így gyorsan:

  1. Majdhogynem hálásak lehetünk az NSA-nek hogy kiváltja a világban ezt a yoyo-effektust a felhőben tárolt adatok kapcsán, és felnyitotta valamelyest az internet népének szemét. Nyilván nem ez a mobileszköz lesz az utolsó ilyen “vissza a jogaidat” kezdeményezés, és látni fogjuk ezt több iparban is, nem csak a mobiloknál.
  2. Cory Doctorow Homeland-jében is Android alapokon építkezik a szubkultúra, csak ott nem Blackphone, hanem ParanoidAndroid a neve.

És persze jegyezzük meg gyorsan, hogy egy eszköz önmagában messze nem csinál nyarat, jönnie kell az alternatív szolgáltatásoknak, amik a privacy-t tartják szem előtt, amik (mint pl. a Kolab) felhőszolgáltatásokat tesznek elérhetővé saját vason, vagy egyszerűen csak per definitionem követhetetlenek harmadik személy számára.

Érdekes idők elé nézünk, na!

Kolab status.

Ezennel akkor újfent átállok Kolabra a személyes levelezésemmel:

  • SSL: check
  • naptár: check
  • HTML email bug megoldás: check
  • keyboard shortcuts: korlátozottan, de check
  • ActiveSync: egyelőre rá se néztem
  • TTL: uncheck, illetve 3 óra és annyi
  • Personal cloud file storage: nem check

Incidentally, a Kolab jobban működik Firefox alatt, mint Chrome alatt, ergo nagy örömmel akár át is állhatok egyúttal arra is.