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.

A windows 7 kapcsan leginkabb a fenti harmas tunik helyenvalonak. A Vista bukasa utan a Windows 7-et sokan fenntartassal fogadtak, ugy gondolva, hogy a MS nem a hibakat fogja orvosolni, hanem csak lenyuz meg egy bort a mar regota doglott lorol, mig masok azert lelkesedtek, hogy a Vista potencialjat fogjak megkapni egy sokkal stabilabb formaban.

Ugy tunik, a masodik csoportnak lett igaza. Megjelent a Windows 7 oktoberben, majd az azota eltelt fel ev alatt (a Net Applications meresei szerint) 10% folotti reszesedest ert el. Nincs olyan sirankozas, mint a Vista utan, alapvetoen senki nem beszel rola. Elfogadtak, hasznaljak, nincs hype.

Ugy tunik, a Microsoft tanult a hibajabol. Remelem, ez igy is marad, es nem lesz tobb Vistahoz hasonlo bukasuk.

Az iPadet, vagy gyakorlatilag akármelyik slate-et (hm, tömb? mafasz ennek a magyar neve?) okostelefonhoz, ebook readerhez vagy netbookhoz hasonlítani hiba. Tévútra visz, kategorizál és limitálja a képzeletet. A slate egy újdonság, kézbe fogható internet.

Az elmúlt héten jópár cikket elolvastam róla, magam is megemlítettem két helyen a blogon. Ma azonban rájöttem, hogy mit hiányoltam ezekből az írásokból. Mindenki kizárólag a személyes oldalára koncentrál az iPad-nek, ami, például esetemben, értelmetlen, mert én magamnak nem vennék iPadet. (sem másmilyen slate-et). A cégnek azonban, ahol dolgozom, simán szüksége lenne rá.

Nézzük meg, én, mint programozó, mire használnám az iPad-et a munkahelyen. Az teljesen nyilvánvaló szerintem, hogy programozásra nem. Gyenge proci, kevés memória, relative kis felbontás (viszonyításként: én négy monitorral dolgozom, és mind a négyet használom is). Ám a törpök élete nem csak.. akarommondani a programozó nem csak programozással foglalkozik napi nyolc órában.

Az első dolog, amire nagyon jó lehet, az a párprogramozásnál másodlagos – böngésző – gép. Gyakran van olyan, hogy egy olyan libet kell használni, amit a pár egyik tagja sem ismer, vagy éppen elő kell ásni egy mintaprogramot a netről. Ilyenkor nem arra van szükség, hogy egy izmos fejlesztői gépen kezdjünk el böngészni; egy slate tökéletesen megfelel ehhez. Jóval kisebb fogyasztással, tenném hozzá. Ráadásul elég mobil ahhoz, hogy a pár egyik tagja minden további nélkül átpasszolja a másiknak, nem kell a monitorokhoz tapadni, hogy mindketten lássanak.

A második dolog, ami beugrik, a scrumban megszokott standup meeting. Triviálisan nem lehet ilyenkor PC-t, de még laptopot sem használni, ellenben a slate tökéletes arra, hogy a webes alapú felületen (Jira, Rally, etc.) aktualizáljuk a story-k és taskok pillanatnyi státuszát. Dolgoztam már olyan helyen, ahol erre a célra hatalmas falitáblák voltak bevezetve, amin gombostűkkel rögzítettük a papír alapú story/task kártyákat, amit aztán a PM később arra használt, hogy update-elje vele a story követő rendszert. Error prone és nehézkes.

Három: tudunk vele rögzíteni és élvezhető formában visszajátszani egy meetinget. Akár videokonferenciára is jó kis csapatok esetén.

Négy: tökéletes bemutatóeszköz egy webes felülethez (ma becslésem szerint az újonnan készült céges rendszerek 90+%-a webes alapú). Az ügyfél kézbe tudja venni, tud játszani a felülettel, szó szerint Hands-on-Experience. Továbbá kikényszeriti a jó designt, mivel a touchscreen ritkán engedélyez olyan pixelvadászatot, amit az egér, ergo nem lehet túlzsúfolni a felületet.

Öt: Sokkal kevésbé zavaró egy meetingen, ha valaki egy slate-be jegyzetel, mintha telefonba vagy notebookba.

Pillanatnyilag ennyi jutott eszembe, de szerintem még csak a felszínt karcolgatom. Úgy érzem, ezek a gondolatok mindig távol fognak állni a döntéshozóktól (akik céges pénzen legfeljebb maguknak vesznek iPad-et, mert az cool) ami azt eredményezi, hogy a slate-ek nem fognak betörni a munkahelyekre. Pedig…

I’ve just read two articles about how programming seems to be different these days:  Whatever happened.. and Whatever happened .. Redux the second being a reflection of the comments on the original article.

I was a bit shocked after the first one, because the author seemed to be very pessimistic and narrowminded. Still, I was curious enough to read the second one, which gave me a much better insight of what he intended to say in the first one. (also I realized that the guy is far from narrowminded and has a quite good sense of humour) Altogether the two articles describe an existing and probably serious problem – or an opportunity.

There are three things I want to write down reflecting on these articles: scripting enterprise, frontier development and standards.

Standards for me starts with W3C. Although their specifications – which in a strict sense are not standards, by the way – are heavyweight, and unusable if you are still learning about that field, they are very good as reference materials. I often go there and browse a specification to find out how should I use this or that. It’s in one place and uses the same format and markup. It’s usable once you get used to it.

There are a lot of libraries for a lot of problems, quite often there is a handful for the same problem. But the interfaces are as diverse as they can be. Why is that so? Because no one cares to create a unified description for the problem. Why? Because there are too many problems out there? I don’t think so. The root cause is that people quite often don’t think that they are actually creating a library.

In an ideal world there would be a place, much like Wikipedia, where programmers could – virtually – get together and make conversations about library interfaces, creating an ad-hoc specification for almost anything. In the real world it’s almost impossible to create and maintain such a place, but still I think that it should exist.

Frontier development is my made-up term for the kind of development when you develop for a new or limited platform, such us creating mobile applications or interactive blueray menus. Usually there are only a very few libraries for these platforms, so when you develop something, you will have a lot to create from the scratch. Still, libraries tend to creep in. Why is that so?

This is software evolution. Usually at first only the brilliant or the desperate start to develop for these platforms. As often as not they will get disillusioned and leave it, but there is a persistent core which stays, waiting for better times to come. And they come, hardware and software becames more powerful and stable, libraries start to grow, and very soon you arrive to a point in time when there is a big developer base, and most of the coding they do is just wiring thing together. Average people like me doesn’t have a lot of talents. Actually, most of us feels lucky if there is one thing that we can do exceptionally well. That is why there are libraries – they are made by people who are talented in that specific area. After a while there will be libraries for everything, so in theory someone with no talent in programming at all can create a new application. In pratice that almost never happens, but that is mainly because of the faulty or hard-to-use libraries.

Scripting Enterprise is another of my made-up terms. I realized this tendency about a year ago. Basically, what happens is that an enterprise application becomes a very big pile of libraries wired together by a very thin layer of application logic. The advantages are trivial: faster, slim, stable, portable applications. But there is a question: if that is so, why do I need to use a heavyweight, very complex and strict language – such as Java – to create that thin layer of application code? I want to use those libraries (which may well be written in java for example) from Ruby. Or Python. Or Scala, Javascript, Lua, whatever. That way I’d have the stable, reliable background to work against with an easy to use scripting language. Is that a bad idea? No. But, to be able to do this, obviously, I’d need a standardized API.

Update: One of my colleagues just pointed out that this is exactly what I am writing about in this section. Thanks, Tom.

All in all, I don’t think we need to go back to the stone age of computing. But we do need to find and eliminate those problems which make program development a pain.