“mert nem biztos, hogy a főnöködről, pasidról, akárkidről írnál névvel, de néha jó, ha ki tudod adni magadból néhány sorral”
“véleménynyilvánítás, tanácskérés, ilyenek”

@Midnite_:
“mert lehet anyázni én épp ezért szeretek inkább teljes névvel intézni mindent. komoly visszatartó erő.”

A fenti válaszokat arra kaptam, amikor megkérdeztem Twitteren, hogy miért jó, mire jó az anonimitás az interneten. Az ismerősök, érezvén, hogy komoly a kérdés, nem csak vitát akarok provokálni, szívesen segítettek.
Ez az egész kérdéskör persze igen messziről ered. Úgy tűnik, egyre többen teszik le a nagy cégek közül a voksukat amellett, hogy az internet nyújtotta lehetőség a kilétünk eltitkolására inkább káros, mint hasznos. A Facebook privacy változásai, a Google Buzz magától értődő nyitottsága, a Blizzard lépése a Real ID-k használatára csak egy-egy példa arra, hogy ilyen irányba haladunk. Ezzel többnyire magam is egyetértek, de – amint a fentiekből látható – igenis vannak olyan esetek, amikor a valódi kilétünk felfedése kifejezetten káros lehet. Vegyük pl. az anonim alkoholistát, akiről megtudja a főnökének a főnöke, hogy alkoholproblémái vannak. Személyesen nem ismeri, de máris eldöntötte, milyen karakter, holott az illető azért jár az AA-ba, mert meg szeretne változni.
Könnyen mondhatjuk, hogy akkor figyeljen jobban a kiléte eltitkolására, de ez nem olyan egyszerű. Az emberek nagy része nem informatikus, számukra még azt is nehéz megérteni, hogy mi az a cookie, például.
Nézzünk egy példát:
Itt egy 16+-os, NSFW oldal: http://www.nuts.co.uk/covergirls. Csinos lányok, rajtuk a [Like] gomb. Megnyomnád?
Talán igen. Aztán eszedbe jut, hogy a főnököd is lát a facebookon. Meg az édesanyád. Valamint a 12 éves lányod. Neked eszedbe jut. Valaki másnak nem, aki, pusztán azért, mert férfi, és szeret csinos lányokat nézegetni, és nem gondol bele a like gomb működésébe, most igen kellemetlen perceket szerzett magának.
De tegyük fel, hogy nem nézel csinos lányokat, viszont prosztatagyulladásod van. Google-n titokban rákeresel, majd találsz egy jó linket, és bookmarkolod. Amit elfelejtettél, az az, hogy van egy extension-öd, ami automatikusan felrakja a del.icio.us-ra a bookmarkokat. Ahol egyébként ugyanazt a becenevet használod, amit a facebookon is feltüntettél, hiszen ez a beceneved. A kollégád pedig, aki nem kedvel, véletlenül ráakad erre, és másnap elterjeszti. De lehet, hogy az inkontinenciára kerestél rá..

Olvastam ma valahol, hogy hamarosan majd biztonsági szakembereket fogunk felfogadni, hogy ellenőrizzék le és óvják meg a magánszféránkat. Nem is annyira képtelenség ez az ötlet.

Egyszer egy palyazatra kezdtem el irni egy novellat Spiral cimmel, amit vegul nem fejeztem be. Nemreg megtalaltam a vinyomon egy takaritas alkalmaval, es ujraolvastam.

A tortenet a kozeli jovoben jatszodik, ennek megfeleloen megprobaltam nehany trendet megjosolni. Egy igen erdekes otlet, amit akar mar jelenleg is konnyen meg lehetne olvasni, egy hirolvaso agent.

A tortenetben a fohos elokap egy kis kutyut (kb. okostelefon) es elkezd rajta hireket olvasni. Az agent (bocs, nem akarom a ugynok vagy az agens szot hasznalni) pedig – on the fly – a fohos olvasasi szokasai es mas, kezzel hozzaadott kriteriumok alapjan atszinezgeti bizonyos hirek (valojaban focimek) hatteret, kiemelve azokat, amik erdekesek lehetnek.

Az alkalmazas technikai resze, eltekintve a szakertoi rendszer / AI vonulattol, aranylag konnyen megirhato lenne. Atszinezni a hattereket a szovegelemzes eredmenyetol fuggoen nem egy bonyolult dolog a html-ben.
Az agent lehetne egy bongeszoben futo – akar javascript alapu, vagy greasemonkey – kiegeszites, vagy egy webes app, ami egy sima formazo/rendezo filterkent mukodne, es egyebkent csak a normalis hirolvaso oldalunk tartalmat szurne at magan. Es termeszetesen hasznalhatnank pl. a google readerben felvett feed-eket alapul.

Ehhez valamennyire hasonlo – amennyit tudok rola – a reader-nek a magic alapu rendezese a google readerben. Alapvetoen csak ket problemam van vele: a sorrendet nem szeretem megvaltoztatni, raadasul az egesz eleg homalyos, nemigen van kozvetlen rahatasom arra, hogy miket szeretnek es nem szeretnek latni – eltekintve a like es not interested gomboktol, amik az egesz cikkre vonatkoznak, nem egy adott, specifikus, altalam meghatarozott temara.

Ha idom es kitartasom lenne, szerintem neki is allnek megirni ezt az alkalmazast. Erdekelnek az AI vonzatai, es hasznos tool is lenne.

Minap hallottam pár informatikust beszélgetni az utcán. Az egyik mondott egy olyan mondatot, amivel csodálatosan le lehet írni egy csomó régi projektet:
“Persze ezt a változtatást alaposan le kell tesztelni. Hálistennek ott van az az állandó tesztrendszerünk, amit élesnek hívunk…”

Azért ez egyre ritkább. Jó irányba halad a szakma.

Ma egy nagyon erdekes, gyakorlatilag elkerulhetetlen hibaba futottam bele. Persze, elkerulheto, de ahhoz mar paranoiasnak kell lenni.

A lenyeg: harom, egymastol fuggetlen resz osszejatszasabol adodott a dolog:

• Van egy checkbox, amit alapbol ugy hozunk letre, hogy be van kattintva
• Van egy vizsgalat a kodban, ami megnezi, hogy a checkbox be van-e kattintva, es ha igen, kigyomlal par elemet a listabol
• Es van egy olyan kepernyo, ahol ezt a checkboxot elrejtjuk

Az eredmeny: azon a kepernyon a listaban nem jelenik meg par elem.

Egy ilyen hibaba nagyon konnyu belefutni. Ha latjuk a harom dolgot egyszerre, akkor konnyu kiszurni, hogy hol a hiba a logikai lancban, de ha pl. az egyik programozo megcsinalja az elso ket dolgot, majd nehany honappal kesobb egy masik programozo egy hibajavitas alkalmaval beleteszi a kodba a harmadik reszt, akkor maris kesz a hiba, pedig kulonosebben nagyot senki nem vetett. Azt pedig szerintem lehetetlen elvarni, hogy egy fejleszto vagja az egesz kodot – meg ha az is lenne az idealis eset.

Mindenesetre a tanulsag: Ha egy feluleti elemet vizsgalsz, ne felejtsd el megnezni, hogy egyaltalan lathato-e az elem. Mert ha nem, akkor konnyen belefuthatsz hasonlo hibakba.

Megint egy szakmai jellegu bejegyzes, mivel ilyen mar reg volt.

Egy ideje mar gondolkoztam a megfeleloen alkalmazott Listenerek elhelyezesen a kodban, ahelyett, hogy oda nem illo responsibility-t kezeljek a kodot teljesen elcsufito felteteles elagazasokkal. Ma reggel azonban a vonathoz setalva egy konkret pelda kapcsan egy – az eddiginel is otletesebb – megoldas jutott eszembe.

Eloszor, fejtsuk ki az alapproblemat. A MindGraph szandekaim szerint alkalmas lesz tobb, egyidejuleg megnyitott dokumentum kezelesere. Nyilvan lesz mindig egy aktiv, meg nehany masik a hatterben, amiket megfeleloen navigalva aktivva tudunk tenni, az aktualis aktivat passzivalva. Amikor “uresen” elinditjuk a MindGraph-et, letrehoz nekunk egy uj, ures dokumentumot. Mi tortenik azonban, ha ekkor betoltunk egy masik dokumentumot?

Szandekaim szerint ekkor az uj, ures dokumentum bezarodik, es a frissen betoltott dokumentum lesz az egyetlen megnyitott, aktiv darab. Ellenben, ha mar van egy megnyitott, nem ures dokumentumunk, es akkor toltunk be egy korabban lementettet, akkor nem akarjuk bezarni az elozot, csak passzivalni. Ergo, kepesnek kell lennunk arra, hogy megmondjuk, ez a dokumentum volt-e mar szerkesztve, vagy meg nem.

Az egyik lehetseges megoldas az, hogy fogjuk az aktualis aktiv dokumentumot, es megnezzuk, hogy van-e benne content. Ennek a megoldasnak tobb elonye is van, es siman lehet, hogy ezt valasztom, de azert kifejtem a masik megoldast is, ami eszembe jutott.

A programlogika, ami a scene-t modosithatja, be van csomagolva egy action osztalyba. Az osztalyoknak nyilvan egysegesitett interface-e van. A trukkos megoldas, amit kitalaltam, egy nagyon kulonleges wrapper osztaly.

A wrapper lenyege ugye az, hogy ugyanolyan interface-t biztosit, mint a becsomagolt osztaly, es annak is passzolja tovabb a fuggvenyhivasokat, csak ad hozza valami kis extra funkcionalitast. (van egy masikfele wrapper is, de en most erre gondolok)

Kitero: Ez kicsit olyan, mint egy peldanyra kihegyezett AOP, ahol a wrapperbe agyazott logika maga egy Aspect. De nyilvan az AOP ennel sokkal tobb, es nem veletlenul vannak teljes retegek kiemelve aspektusba.

Az en wrapper osztalyom egy dologban mas, mint a normalis: Az elso hivas utan “kicsomagolja” magat, azaz a logika vegrehajtasa utan kicsereli onmagat a becsomagolt osztalyra. Ezzel azt erjuk el, hogy a wrapperben hivott kod csak egyszer tud lefutni, es onnantol gyakorlatilag nem letezik a kodban, azaz nem is lassitja a futast.

Nyilvan kell egy kis trukkozes, hogy a sorrend megorzesevel ki tudjuk cserelni az akciot egy masikra, es nem is biztos, hogy szukseg van egy ennyire bonyolult kodra, hiszen ha egy sima feltetelvizsgalatot teszunk be helyette, a JIT alapu virtualis gep ugyis gondoskodni fog rola, hogy az elagazas megfelelo aga fusson, elhanyagolhato overhead-del. De azert erdemes elgondolkozni rajta, hogy milyen lehetosegek szuletnek egy ilyen megoldassal, hiszen az egesz programunk sokkal dinamikusabba valik. (hiszen nem csak onkicsomagolas lehet, hanem on-the-fly factory, meg onbecsomagolas, es hasonlok)

Ha lesz konkret kod ra, lehet, hogy bevagok par reszletet.

A Google kiadta az Androidhoz az App Inventort. A szoftver lenyege, hogy az alkalmazasodat nem “programozod”, hanem epitoelemekbol illeszted ossze. A reakciok meglehetosen vegyesek voltak, sokan amiatt aggodnak, h elarasztja az app store-t a gagyi, 12 evesek altal osszetakoltak kisalkalmazasok tomege, mig masok orultek a lehetosegnek.

A blokkokbol epitkezes nagyon regi otlet a szoftverfejlesztesben. Amikor 13 eve a foiskolan tanultam rola, mar akkor is tortenelmi multu gondolatnak szamitott, ambar akkor meg a gepek kepessegei joval alatta maradtak annak, amire ma kepesek, gondolok itt elsosorban a grafikus UI-ra. Azonban szamtalan okbol eddig mindig meghiusult az, hogy ebbol olyan termek legyen, amit nem programozok is kepesek hatekonyan hasznalni. En a palyam soran nemegyszer belefutottam ezekbe az alkalmazasokba, es nehanyat volt is szerencsem hasznalni munkam soran – ergo nem csak az otthoni kiprobalas jellegu jatszadozasok alapjan van tapasztalatom veluk. Az App Inventort meg nem probaltam ki, de ki fogom mindenkeppen. Egyelore csak az altalanos gondolataimat irom le, aztan ha lesz konkret tapasztalatom, akkor majd azt is.

A programozas alapallapotban ugy mukodik, hogy a programozo ismeri a nyelv alapveto konstrukcioit: ertekadas, felteteles elagazas, ciklus, stb. Ehhez hozzacsapodnak a keretrendszer elemek: Az objektumok, pl. a String, azok fuggvenyei. Az alkalmazas UI elemei is ilyenek. Ezekbol a programozo ossze tud rakni egy programreszletet, ami megcsinal valamit, amire neki szuksege van: pl. hatulrol elkezd bejarni egy listat, es osszeszed ot elemet, ami megfelel egy adott feltetelnek. Ezt egy atlagos felhasznalo azert nem tudja megtenni, mert nem ismeri az alapelemeket, nem ismeri a keretrendszer elemeket es nincs birtokaban a programozashoz szukseges gondolkozasi strukturaknak, azaz meg ha ismerne az elemeket, akkor sem tudna oket megfeleloen sorba tenni.

A vizualis kodepites egyik alapveto problemaja a kodgranualitas eltalalasa: A legegyszerubb epitoelemeket adjam oda a felhasznalonak, vagy valamivel bonyolultabbakat, vagy egeszen osszetett epitoelemeket, amiket csak konfiguralnia kell, vagy valami vegyesfelvagottat a fentiekbol? Mindegyiknek megvan a maga problemaja: Ha nagyon egyszeru elemeket adok, a felhasznalonak gyakorlatilag ugyanugy programoznia kell, csak nem gepelessel, hanem dobozokat osszehuzva. Raadasul igy mindent maganak kell megirnia. Ha csokkentem a granualitast, es haladok az osszetettebb elemek fele, akkor a usability-be futok bele: adok peldaul egy blokkot, amivel be lehet egy listat jarni, de akkor a felhasznalo azt akarja majd, hogy hatulrol elore, vagy csak minden masodikat, vagy eppen hatulrol elore minden masodikat…  Ez hasonlo ahhoz a problemahoz, amibe belefutottam a MindGraph kapcsan mult heten, amikor egy apro valtoztatas miatt at kellett irni egy egesz osztalyt, csakhogy erre altalaban nincs lehetoseg. Persze megtehetjuk azt is, hogy csak egy blokkot adunk a felhasznalonak, amirol tudja, hogy ez egy ciklus, am a belsejet neki kell leprogramoznia scriptnyelven. Ezzel persze gyakorlatilag semmit nem haladtunk elore a sima programozashoz kepest, a felhasznalonak meg kell tanulnia, hogyan kell egy programot osszerakni. Ha egesz nagy blokkokat akarunk hasznalni, pl. “Beleptetes”, “Vasarlolista”, “Fizetes”, akkor abban a szituban leszunk, hogy barki ket perc alatt ossze tud rakni egy webshopot az elemeinkbol, de Solitaire-t soha nem fog csinalni vele. Persze megprobalhatunk mindenre adni egy ilyen blokkot, de ez kvazi lehetetlen. A hibrid megoldasok gyakran azt eredmenyezik, hogy mindket megoldas problemai megjelennek, am emellett meg az is jelentkezik, hogy tulzsufolt lesz az elemkeszlet. En pl. a Visio-val vagyok mindig igy: borzaszto jo tool lenne, ha tudnam, hol a feneben van az az elem, amit hasznalni szeretnek.. ha van egyaltalan.

A masik, egyaltalan nem megoldhatatlan feladat, amivel megis problema szokott lenni, az a kod ujrahasznalas. Ez reszben kapcsolodik a kod attekinthetosegehez is. Konnyu belatni, hogy egy alkalmazas diagramja nagyon osszetett lehet. Van benne egy udvozlokepernyo, ami pl a fomenu, egy “about” kepernyo, egy toltes kepernyo, ahol kivalaszthatjuk, hogy melyik mentett dokumentumunkat akarjuk megnyitni, egy hasonlo a menteshez, plusz az osszes koztes kepernyo. Ha mar csak azt felrajzoljuk, hogy melyik kepernyorol melyikre lehet eljutni es milyen modon (ha van aktualisan szerkesztett dokumentum, akkor load elott ajanlja fel a mentest..) mar az onmagaban atlathatatlan. Azonban mi most arrol is beszelunk, hogy a kepernyon beluli kodot is vizualisan megalkotjuk.

Nyilvanvalo a megoldas, hogy akkor a kepernyokhoz csatlakozo kodokat szeparaljuk el kulon, csak adott kepernyonel lathato diagramra. Am itt jon a kepbe a scope: Mi van akkor, ha a kod egy resze olyan logikat valosit meg, amit szeretnek ujrahasznositani? Atnyulhatok az egyik kepernyorol a masikba? Vagy kirakhatom egy kulonallo valamibe, ami nem kepernyo? De egyaltalan, hogyan azonositom, hogy en oda akarok most menni, ezzel-es-ezzel az adattal, es utana ide akarok visszajonni? Egy mondatban: hogyan rajzolok publikus fuggvenyeket es hogyan hivom meg oket?

A megoldas itt nyilvan az lenne, hogy ezek az altalam irt publikus fuggvenyek is uj epitoelemkent jelennek meg, valamint az alkalmazasom elszeparalt reszei (kepernyok) is megjelennek epitoelemekkent – pontosabban azon reszeik, amiket publikusan kiajanlok. Innen persze a felhasznalonak ertenie kell a scope kifejezest is.

A scope kapcsan nyilvan megemlithetnem itt a valtozok atadasat is: hogy oldom meg azt, hogy a kepernyom at tudjon passzolni ertekeket a kovetkezo kepernyonek, aki aztan majd felhasznalja? Valamint pl. hogy oldom meg azt, hogy ha a felhasznalo a vissza gombot nyomja meg, ki legyen toltve a form, mig ha a tovabbi elemek hozzaadasa akciot valasztotta, akkor ne? Ezek mind olyan kerdesek es problemak, amivel egy vizualis tervezo keszitesenel talalkozunk, es a megoldasra olyasmit kell kitalalnunk, amivel a programozni nem tudo, alapvetoen egeret hasznalo felhasznalo boldogul, es amitol nem lesz olyan erzese, hogy ez most rocket science.

Gyakorlo programozokent az az erzesem, hogy a programozasnak ez az aga vagy zsakutca, vagy egy olyannyira limitalt lehetoseg, amivel nincs ertelme foglalkozni addig, amig nincsenek mesterseges intelligenciak, akik az egyszeru abra moge, amit te lerajzolsz, kepesek maguktol kitalalni a tartalmat. Maskulonben, akarmilyen jo is az eszkozunk, elobb-utobb vagy olyan problemaba fut bele a felhasznalo, amit nem lehet benne megoldani, vagy programoznia kell.

Tovabbiakat majd akkor, ha kiprobaltam az App Inventort.

Szerencsere nem sajat tapasztalatok alapjan, de sikerult egy ujfele feloldast talalni az OO Design roviditesre. Ez pedig az “Objection Oriented Design”.
Lenyege: Csinalunk valami szar designt, aztan ha valaki panaszkodik valamire benne, azt kijavitjuk.

Dobbenetesen sok architect hasznalja.

Szeretnem, ha az Eclipse IDE kovetkezo verziojat Twilight-nak neveznek..

Ma harom tipikus programozasi hibaba is beleszaladtam, alljon itt egy memento roluk:

1. Factory keszitette ojjektum: Ha egy objektumot Factory-val vagy Factory metodussal keszitesz, az nem ekvivalens a new Objektumneve() hivassal, ugyanis lehet null, anelkul, hogy hibat dobna. Az ilyen modon elkeszitett objektumokat erdemes ellenorizni, hogy ne valahol a hivaslista melyen kapjunk egy nullpointer exceptiont. (vagy az adott nyelvi megfelelojet). Ez kulonosen igaz, ha a Factory-t egy kulso file-bol inicializaltuk.
2. Nem szamlalo alapu ciklusban (pl. while, foreach) szamlalot hasznalni oke. A szamlalot az elejen megnovelni, majd a vegen egy feltetelvizsgalat eseten (valami nem kovetkezett be) csokkenteni nem oke. Csak a legritkabb esetben nem lehetseges a szamlalot magasabb ertekrol inditani, es forditott feltetelvizsgalattal novelni a ciklus vegen. Konnyebben kovetheto logika es kevesebb hibalehetoseg az eredmeny.
3. Egy ciklusban ugyanazt a erteket tobbszor kiszamolni gaz. Ha ezt raadasul rosszul teszed (pl. copy paste hiba miatt) akkor meg nehezen kinyomozhato programhibat is okozol.

I am playing with the idea of Test Driven Builds for a while now. This is ultra-agile.

But let me explain it first: A Test Driven Build builds your application based on your Functional and Integration tests (but not the Unit tests!). For each test the compiler looks up and compiles the required classes, and only those. Obviously, it keeps the previously compiled ones as well, and after running all your tests it packs all of them together, so you would have the application which can run your tests.

I don’t usually take this idea seriously, but actually this can be the next step on the agile path. Should I have the knowledge to create such a build tool, I would. Just for fun. It would be interesting to see whether people would try to use it.  I’d be curious about their experience and opinion.