Connect the dots.

Hazaérni, nekiugrani a hobbiprojektnek, majd lefeküdni korán... hogy aztán egész éjszaka ne hagyjon nyugodni, hogy még mit lehetne megcsinálni nagyon hamar, és tudni, hogy ha felkelek és bekapcsolom a laptopot, akkor nem fogok aludni egész éjszaka egy szemet sem.

 

Ébben ezért kimosva ébredni.

 

Hülyeinfós.

 

Az utóbbi időben hobbiból foglalkoztam Win32 programozással, és megállapítom, hogy találtam még egy randa API-t. A Win32 API úgy néz ki, hogy van párezer rendszerhívás, tök véletlenszerű névvel, összelapátolva egy namespace-be, mindenféle elnevezési konvenció nélkül. Mondjuk tök jó lenne, ha az azonos területhez tartozó függvények ugyanúgy kezdődnének – ezt általában be is tartja az API, viszont van, amikor nem (a több monitor kezelésével foglalkozó GetMonitorInfo(), EnumDisplayMonitors() és MonitorFromWindow() függvények ugranak be).

Összeszedtem néhány gyöngyszemet. Csemegézzetek!


WM_RASDIALEVENT

Ez egy olyan esemény, amit akkor küld a Windows egy meghatározott ablaknak, ha egy RAS esemény (Remote Access Service – ilyesmi történt). Tök szép dolog, hogy van ilyen, de egy ennyire speciális dolog így belehányva egy operációs rendszer API-jának a közepébe...

AddFontMemResourceEx()

Ez a rendszerhívás arra szolgál, hogy egy fontot töltsön be nem fájlból, hanem a memóriából. Kellett, mert a szoftveremet egyfájlosra szerettem volna megírni. Szépen működik is, és van neki egy visszatérési értéke, ami egy handle a betöltött fontra.

Adódik a kérdés, hogy ezzel a handle-vel mit lehet csinálni. Semmit. Nem, hazudok, mert ezzel lehet kirugdalni a fontot a memóriából, de tényleg csak ennyi. Nem lehet megtudni a nevét, nem lehet megtudni azt, hogy alá van-e írva, nem lehet róla megtudni semmit. Ha ezzel a fonttal szeretnél kezdeni valamit, akkor szépen hivatkozz rá a neve alapján, amit természetesen nem tudsz megkérdezni senkitől, hanem bele kell drótozni a szövegfile mellé.

32 bites bitmapek kezelése

Van egy rendszerhívás, bizonyos UpdateLayeredWindow(), ami arra szolgál, hogy átlátszó ablakokat lehessen vele csinálni. Ez egy 32 bites RGBA bitmapet vár inputként. Gondoltam, tök jó, van egy LoadBitmap() hívás, azzal majd biztos be lehet tölteni ilyet fájlból. Nem. Sajnos a LoadBitmap hívás nem kezeli a 32-bites BMP-ket. A megoldás: betölteni a fájlból a BMP header-t, létrehozni egy üres bitmapet ez alapján (mert erre van rendszerhívás), aztán bitmap memóriaterületére beolvasni a fájlból a pixeleket. Szép.

SystemParametersInfo()

Ez egy olyan rendszerhívás, amivel a nevéhez hűen rendszerparamétereket lehet lekérdezni. Hogy mi az, hogy "rendszerparaméter"? Minden, a képernyő felbontásától kezdve a képernyővédő timeout-ján keresztül a StickyKeys, FilterKeys, és hasonló accessibility feature-ökön át a billentyűzet ismétlési sebességéig. Megint találtam egy szemetesvödröt, amibe mindent belelapátoltak, ami csak belefért...

A programozási nyelvek egyik osztályozása a sok közül az, hogy a fordító mennyire ellenőrzi szigorúan, hogy a szoftver helyes-e. Erre két példát szeretnék hozni a skála két oldaláról: az egyik a Java. Itt egyszeres öröklődés, szigorú tipizálás, és deklarált kivételek vannak, és a fordító minden kis hibáért szól, a és a szerkesztő olyan, hogy a legtöbb szintaktikai hiba elkapásához le se kell fordítani a szoftvert, mert tudja az editor, hogy az úgy rossz, A másik a Lisp, ami ennek a tökéletes ellentéte: az objektum-orientáltság gyökeréig le lehet nyúlni, mindent lehet módosítani, viszont cserébe az editor nem sokkal okosabb egy sima szövegfájl-szerkesztőnél.

A Java-oldal varázsa az, hogy a szigorú struktúra miatt nagyon sok segítséget kap a programozó: az editor tud ezerféle refaktorálást, go to definition-t, sokféle breakpointot, syntax highlighting-ot, object browser-t – nagyon sok segítséget megkap a programozó, hogy átlássa a kódot. A Lisp világában a legtöbb ilyen eszköznek nincsen meg a megfelelője – nem is lehet, hiszen például egy szimbólum átnevezésekor gyakorlatilag lehetetlen kideríteni, hogy a forráskódban hol hivatkozunk rá, mert a lefordítandó "forráskód" felhasználói kód futtatásával áll elő. Viszont nem is kell: ugyanaz a rugalmasság, ami lehetetlenné teszi, hogy az editor "megértse" a kódot, lehetővé teszi azt, hogy a fejlesztő minél inkább a gondolkodásához közeli módon fejezze ki azt, hogy mi szeretne, hogy a számítógép csináljon.

Tehát a Java "szabályainak" betartásával meg lehet venni az editor által nyújtott sokféle segítséget. Lisp-ben sokszor azt érzem, hogy a sokféle editor-segítségre nincsen szükség, hiszen annyira formálható a nyelv, hogy ha ötnél többször írom le ugyanazt a szimbólumot, akkor valamit elrontottam --- ezért aztán átnevezéshez nincsen szükség editor-segítségre, mert egy search-and-replace tökéletesen megteszi.

Az a döntés, amit a fejlesztőnek meg kell hoznia (bár a legtöbben, mikor nekiállnak Javában fejleszteni, ezt nem tudják) az az, hogy vajon melyik utat szeretné választani: elfogadja az előredobozolt szabályokat, beletölti őket a fejébe (pl. egyszeres öröklődés van csak, és ha a probléma mégis többszörös öröklődést követel meg, akkor valahogy megpatkolja a dolgot), és megpróbál azok szerint dolgozni, ily módon a gondolkodását szabja a rendszerhez, vagy pedig bízik magában, és inkább a rendszert szabja a saját gondolkodásához. Ez hasonlít az eggyel nagyobb szinten fellépő "build or buy" dilemmához, hogy az adott szoftverkomponenst házon belül érdemes-e kifejleszteni, vagy pedig jobb megvenni egy dobozos terméket. A döntés során is ugyanúgy érdemes eljárni: ha bízik az ember a saját képességeiben, és van elég ideje, akkor jobban jár az erősebb eszközzel, ha viszont nem áll fent ez a két feltétel, akkor jobb elfogadni az előregyártott megoldást.

Örvendetes dolog, hogy az említett két nyelv közeledik egymáshoz: a Javának egyre erősebbek a Reflection-ra való képességei (és a C# oldaláról történő nyomás miatt egészen biztosan a jövőben is erősödni fognak), illetve a gyengén típusos nyelvek osztályába tartozó Python-hoz is láttam már olyat, hogy a kódban megtartott néhány szabállyal meg lehet venni a néhány hibalehetőség elkerülését. Azért örvendetes, mert egy idő után lehet, hogy mind a két világ ugyanoda érkezik meg, és abban lesz "igazság".

És akkor már nem lehet elkerülni, hogy fejlesztés közben az ember a saját hülyeségével nézzen farkasszemet :)

Mostanában nagyon fejlesztő vagyok...

 

Elharapóznak a különféle frameworkok – mindegyik egy adott területre kínál all-in-one megoldást, tud mindent, ezer indok van arra, hogy miért jobb, mint az összes többi versenytársa, némelyik még ingyen is van, némelyik másik pedig marketingdumával megtámogatva... és valahogy mégsem teszik egyszerűbbé az ember életét.

 

A felszínes jelenség az, hogy két pont között ingadozok: az egyik, hogy jaj, de hülye ez a szoftver, mert még ezt sem tudja, a másik pedig, hogy mennyi mindent kell megtanulni, pedig csak én ezt a kis dolgot szeretném.

 

There is no silver bullet. Arra jöttem rá – illetve mondták idáig is, de most már el is hiszem – hogy minden problémának van egy komplexitási szintje, ami alá egyszerűen nem lehet menni, mert ennyi ész kell hozzá és kész. És hál'Istennek fejlődik a technológia, ezért ahogy jönnek ki az új fundamentális technológiák (nem a legújabb csodalibrary, hanem az új feature-ök programozási nyelvekben, garbage collection, minden olyasmi, ami alapot ad) – és ahogy egyre fejlődök! – úgy egyre kisebb az "accidental complexity", egyre kevesebbet kell gondolkodni nem releváns dolgokon, és egyre inkább a problémára lehet koncentrálni.

 

Azért van ilyen sok framework, mert amikor valaki "feltöri a diót", meglátja a Probléma egy megoldását, azt hiszi, hogy ezt tök egyszerű, csak még senki nem találta fel a spanyolviaszt, de ha majd az ő ötletét lekódolja, akkor szép lesz a világ, pedig ez illúzió: a megértést nem lehet megspórolni sehogyan sem.

 

Ilyen értelemben a kód nem más, mint kikristályosodott gondolat -- nem teszi egyszerűbbé a probléma megoldását, csak arra ad bizonyítékot, hogy a dolog megoldható, és a szerző a saját megközelítését fogalmazza bele. Kódot olvasni valójában emberek közötti kommunikáció.

 

Újabban fejlesztek Python-ban. Egyrészt azért, mert a Csodaprojekt csodaguruja a Python-t szereti, másrészt azért, mert az tök jó. Alább leírom, hogy mik az első tapasztalataim a nyelvvel.

Először is a pozitívumok: nagyon dinamikus nyelv, könnyen alakítható – nem kell szenvedni hülye interfészdeklarációkkal és típusokkal, nem kell hülye módokon megkerülni azt, hogy csak egyszeres öröklődés van, és a legtöbb szoftver nyílt forráskódú, ezért ha valami gond van, nincs dokumentáció, bugra gyanakszom, egy perc alatt mélyre lehet ásni a forráskódban, és ki lehet deríteni, hogy tényleg bug van-e.

A könnű alakíthatóság miatt nem kell leírni ugyanazt ezerszer, nem kell "boilerplate" kódot írni. Ugyan nem fejlesztettem sokat idáig, de még nem fordult elő, hogy copy-pastelni kellett volna. A legtőbb érdekes ponton módosítani lehet az interpreter viselkedését: lehet definiálni, hogy mi történjen objektumok attribútumának lekéréskor, példányok létrehozásakor, lehet kódot kiértékelni sztringből, és általában mindent, ami "izgalmas", és ami egy elborult hekkernek az eszébe juthat.

Előny továbbá, hogy a gondolkodási idő/gépelési idő hányados nagyon magas: a tegnapi túra közben néha elkalandoztak a gondolataim, és amit egy nap alatt a néhány perces holtidőkben sikerült végiggondolni, azt lekódoltam nagyjából negyedóra alatt. Illetve... az a baj, hogy ilyenkor nem lehet az automatikus gépelés mögé húzodni, hanem szembe kell nézzek a saját hülyeségemmel :)

És akkor most a hátrányokról. A legelső, ami eszembe jut, az az, hogy nem értem, hogy Guido bácsi miért írta meg a Python-t, mikor van már, ami közelebb van az Igazsághoz (és Lispnek hívják). Úgy érzem, hogy ami Lispben a negyvenvalahány éves múltja miatt jól végig van gondolva, majdnem matematikai alapokra helyezve, azt a Pythonban úgy implementálták meg, hogy leült egy kóder, és ahogy eszébe jutott, megcsinálta.

Ezer helyen kilóg ez a dolog: a decorator-szintaxisnál (miért nem lehet osztályokra decoratort akasztani, és dekorátor futása közben miért nem lehet elérni az éppen deklarálandó függvény nevét, meg esetleg az osztályt? Sírok egy jó kis makróért...), abban, hogy a dokumentáció tele van olyanokkal, hogy ne csináljak körkörös referenciákat, annak ellenére, hogy elvileg már meg van oldva, hogy a GC-t ne zavarják (Még jó, hogy! Hadd ne kelljen már nekem ezzel törődni 2007 alkonyán!), abban, hogy most már, a Python legújabb verziójában végre lehet egy try blokkban kivételkezelő és finally blokk is egyszerre (mert idáig választani kellett).

Szépen szivárognak be ide a Lisp-es szokások: a Twisted framework manhole nevű fícsörjével elkezdődött a fejlesztési és futtatási idő összemosása, van lispes REPL, a decoratorok felteszem, hogy a makrók megfelelői akartak lenni... szép, szép, csak hosszú lesz az út, míg a Lisp kényelméig elér.

Viszont a Lisppel szemben előny, hogy van közösség, ami elérte a kritikus méretet, és gyakorlatilag minden feladat megoldására van legalább egy, de inkább több lehetőség. Igaz, néha nem túlságosan dokumentáltak... :) Azt kell mondjam, hogy valódi problémák megoldására, ami nem ötéves projekt, a Python szerintem alkalmasabb: a Lisp világában mindig attól félnék, hogy kell valamit megcsinálni, amire nincsen kész termék, pedig elvileg lehetne.

Amiért viszont sírok, az a fejlesztési segítése: nem találtam még értelmes Python IDE-t. Nem csilivili kell, hanem használható – a SLIME a Lisp-hez tökéletes (annak ellenére, hogy pilótavizsgás), de úgy láttam, hogy például azonosítókiegészítést nem nagyon csinál semmi IDE. Debugolni is fájdalmas. Leginkább az, hogy nem találtam remote debuggingra lehetőséget (pedig ez nagyon fog fájni), úgyhogy úgy néz ki, hogy marad a jól bevált naplófájl írása-aztán a két szememmel elolvasása rendszer.

Majd meglátjuk, milyen lesz. Ezerszer jobban élvezem, mint a C# fejlesztést, de fáj, hogy annyival szebb lehetne, ha egy kicsivel több dolgot átvett volna a Lisp világból...

Iszonyúan utálom ezt a dolgot, ebből következően képtelen vagyok értelmes tempóban tanulni. Soha nem éreztem még azt, hogy valami nem akar a fejembe menni...

 

Mikor nekiálltam megtanulni a 3.0-s verziót, hallottam már horrorsztorikat arról, hogy az előzővel miket lehetett szívni. Éppen ezért csak úgy tudtam belekezdeni, hogy meggyőztem magam arról, hogy az Új Verzió sokkal jobb, és teljesen ki van cserélve az alja.

 

Tanultam, tanulgattam, mint a kiselefánt – lassan tanul, gyorsan felejt – és úgy tűnt, hogy igazam is lesz. Egyre inkább kezdett összeállni a kép, egy konzisztensebb lett, álltak össze a puzzle darabjai. Egészen addig tartott ez a viszonylag szép világ, amíg ma este nem ültem le beszélni a kollégámmal, aki már megküzdött a SharePoint 2003-mal. Elkezdte magyarázni, hogy hogyan működik az a verzió, én meg széles vigyorral mondtam, hogy nem, már kicserélték az alját.

 

A vigyor akkor hervadt le az arcomról, mikor a fájlrendszerben rutinos mozdulatokkal megmutatta a – neki – ismerős struktúrát (onet.xml és webtemp.xml, ha ez mond valakinek valamit). És akkor rájöttem: ezek csak húztak egy szép, majdnem összefüggő réteget a szarra. Az jutott eszembe, hogy a 20. század elején lehetett ilyen, amikor megbecsült fizikusprofesszorok mondták, hogy már csak néhány, apró jelenségre kell választ találni, és készen lesz a fizika. Ehhez képest ezekből az apró jelenségekből született meg egyrészt a relativitáselmélet, másrészt a kvantummechanika, a mai fizika két alapköve.

 

Nehéz az élet.

Ha valami nyomja a lelkemet, általában ideírom. Ez pedig elég kemény ütés volt ahhoz – és messze nem járok még az utolsó menetben – hogy megérdemeljen egy cikket.

 

A SharePoint a Microsoft portálkészítő és tartalomkezelő rendszere. Ez a harmadik nagyobb verziója, és én azzal a tudattal vágtam neki a megismerésének, hogy a microsoftos szoftverek a harmadik verzióra már elég összeszedettek szoktak lenni. Az szokott lenni a minta, hogy az első használhatatlan hulladék, a másodikban kijavítják a nagyobb hibákat, de még mindig elég fapados, a harmadik már kezd használható lenni, a negyedik meg teljesen jó.

 

Valamiért (valószínűleg azért, mert úgy gondolták, hogy a SharePoint-fejlesztőtől nem lehet elvárni, hogy ismerje az SQL-t) semmi köze a hagyományos adatbázisokhoz annak a módszernek, ahogy az adattárolását definiálni és lekérdezni lehet. Igazából semmihez semmi köze, a legközelebbi, amihez hasonlítani tudtam, az az ISC honlapján levő XML-karikatúra, amikor úgy kell programozni, hogy az elemzési fát XML-ben fogalmazod meg. CAML-nek hívják, és úgy működik, hogy a feltételeket olyan XML-tagekkel kell megfogalmazni, mint <AND>...</AND>, <OR>...</OR>, a kimenetet pedig olyanokkal kell generálni, mint <IF>...</IF> és <CASE>...</CASE> – felületesen néztem csak meg, de azt hiszem, hogy a kimenetbe az kerül be, ami a két tag között van.

 

Ennek a CAML nevű dolognak a kimenete HTML kell legyen, ami aztán repül a böngészőnek, aki majd kirajzolja, és egy ASP.NET lapba kell beilleszteni. Itt azt kell észrevenni, hogy mindhárom dolog XML alapú. Az XML szabványban ugyan vannak lehetőségek arra, hogy hogyan illesszünk be különféle sémának megfelelő XML-dolgokat egymásba, de itt természetesen ezt nem használták: a CAML-t úgy kell belerakni az ASP-be, hogy escape-lni kell az XML-ben speciális jelentésű karaktereket (pl. csibecsőrök, farkasnyolcas), és a HTML darabkákat meg CDATA szekciókban kell belerakni a CAML-be.

 

XML dolgok hármas egymásba ágyazása. Nagyon finom... azt tudnám, mihez fogok kezdeni, ha majd ezt egyszer debugolni kell.