Megnyomkodták

Szoftverfejlesztőként, technológusként rendkívül érdekesnek tartom a Surfacet, de egyszerű emberként, felhasználóként még nem igazán hozott lázba. Ettől függetlenül szerintem nagy jövő áll előtte. Az Indexen megjelent egy egész jó cikk annak alkalmából, hogy megérkezett Magyarországra is az első Surface példány.

 

"Kipróbálom, tényleg nagyon intuitív az egész. ‘Mint az iPhone’, mondom, de a szakember [Kőnig Tibor] csúnyán néz rám, és emlékeztet rá, hogy a Surface már jóval korábban kész volt."

 

Részletek itt.

Déjà vu 2.0

Hát ilyen nincs, és mégis van! Három napja szóvá tettem ezt az ügyet és most erre tessék. Újabb felvonás következik, de már más szereplőkkel. Csak tessék, tessék, EU-cirkusz, világszám! A bohócok már a színpadon vannak!

 

"A T3 Technologies panasza szerint az IBM visszaél piaci helyzetével azáltal, hogy csak a saját mainframe gépeivel együtt árulja az operációs rendszerét, amivel akadályozza a konkurens hardvergyártók piacra jutását. A panasz szerint emellett az IBM nem teszi lehetővé a szabványainak és más szellemi termékeinek felhasználását, amivel kárt okoz az európai mainframe vásárlóknak."

 

Részletek itt.

AOP

AOP, vagyis Aspect Oriented Programming paradigma. Ezidáig nem sokat foglalkoztam vele, de az elmúlt hónapban egy általam olvasott könyv felkeltette az érdeklődésemet iránta. Ezen nekibuzdulva gondoltam leírom mit értettem meg belőle, illetve mit is értek alatta.

 

Részletesen utána nézve meglepően tapasztaltam, hogy milliónyi fejlesztői portál foglalkozik Aspect Oriented Programming témával olyannyira, hogy most készülnek a 8. nemzetközi konferenciájukra. Az AOP szemléletmód egyébként annyi más jó ötlettel együtt (egér, ethernet, lézernyomtató ) a 90-es években az OOP – Object Oriented Programming ígéretes kiegészítéseként jött létre a Xerox SPARC laboratóriumban.

 

Az egész módszer lényege – szerintem – az, hogy bizonyos programkódok nem a programozó által, hanem később, a  fordítási,  linkelési vagy futtatási időszakban végrehajtódó folyamat által kerülnek bele a végső futtatandó kódba. Ezt a technikát hivatalosan „cross cut concern” megvalósításnak nevezik. Ezt elég nehéz lenne magyarra jól lefordítani, de nagyjából talán annyit tesz, hogy: ”modulokat keresztirányban átszövő, utólag automatikusan beillesztett kódészlet” (vagy valami hasonló).

 

Az AOP paradigma szerint egy rendszer forráskódjában gyakran vannak olyan jól elszeparálható, független, önmagukban is működőképes kódrészek (ezeket nevezik itt angolul concern-eknek), melyek az érdemi munkát végrehajtó kódok között sokszor ismétlődnek, ugyanakkor ezek az ismétlődések valamilyen szempontból jól leválaszthatók az érdemi (base) kódról. Ilyen leválasztott kódok lehetnek mondjuk az olvasást és megértést rongáló, általános célú, gépiesen leprogramozott…
  – naplózási utasítások,
  – hibakezelések,
  – munkamenet (session) kezelések,
  – biztonsági és jogosultsági ellenőrzések,
  – egységesített adatbázis-kapcsolatok kezelése,
  – egységesített tranzakció állapotok menedzselése.

 

Csupa-csupa olyan dolog, amik nagyon sokszor és sok helyen szükségesek a kódban, ugyanakkor a programozók néha vagy elfelejtik lekódolni, vagy ha nem felejtik el, akkor épp utálják begépelni (mindig ugyanazt, minden metóduson belül). Az említett kódokra mégis szükség van, ezért nem utolsó sorban a végső, futtatandó kódban már szerepelniük kell.
 

1. példa (minta):

public void SzamlaRogzites(int parameter)
{
    Trace.EnteredMethod("SzamlaRogzites elindult…", parameter);
    SecurityCheck();
    if ( SzamlaszamEllenorzes() )
    {
      SzamlaszamKepzes();
      SzamlaFejRogzites();
      SzamlaTetelRogzites();
    }
    Trace.ExitMethod("SzámlaRogzites befejeződött.");
}

A fenti példán látszik, hogy a „SzamlaRogzites()” eljárás három olyan más függvényhívást is tartalmaz (kékkel jelölve), amik bár nagyon fontosak (hiszen naplózási és biztonsági műveleteket hajtanak végre), de az üzleti logika szempontjából, a kód olvashatósága, illetve a kódolás sebessége szempontjából viszont kifejezetten „haszontalanok”. Mennyivel kényelmesebb lenne, ha a programozónak ezekkel nem kellene foglalkoznia, hanem csak a megoldandó üzleti feladatokra  kellene koncentrálna (azaz kihagyná a feladat megvalósítása szempontjából – aspektusából – lényegtelen kódrészeket). Ha ez tenné, akkor a lenti példához hasonlót kellene kódolnia.

 

2. példa (minta):

public void SzamlaRogzites(int parameter)
{
  // Ide fordításkor, linkeléskor vagy futtatáskor fog bekerülni automatikusan a szükséges kód
  if ( SzamlaszamEllenorzes() )
  {
    SzamlaszamKepzes();
    SzamlaFejRogzites();
    SzamlaTetelRogzites();
  }
  // Ide fordításkor, linkeléskor vagy futtatáskor fog bekerülni automatikusan a szükséges kód
}

Látszik, hogy (a példát magyarázó megjegyzésektől eltekintve) nincs semmilyen „zavaró” tényező, csak az üzleti feladat megoldása szempontjából fontos kód. A naplózó és biztonsági ellenőrzést végrehajtó kódot viszont nem kellett leprogramozni. Ez akkor válhat érdekessé, amikor belegondolunk abba, hogy milyen sok metódushívásban szerepelhet az 1. példában megadott, kékkel jelölt utasítások, és mennyi időt spórolunk azzal, ha ezeket a programozó nem gépeli le (a már említett, zavaró utasítások nélküli kódról, vagyis az „igazi” forráskód olvashatóságról nem is beszélve).

 

Igen, de akkor hogy fog mégis végrehajtódni az eredeti forrásból kihagyott, de amúgy szükséges kódrészlet?

 

Hát úgy, hogy egy megfelelő pillanatban automatikusan, az eredeti forráskód változtatása nélkül majd jól beillesztődik a helyére. Ez az automatikus kód beillesztés három szinten történhet meg:

• Fordítás közben: Amikor az eredeti forráskód és egy úgynevezett deklaratív, „Aspect” kód segítségével egy AOP fordítóprogram beteszi a szükséges kódokat a megfelelő helyekre, majd az így létrejött köztes forráskódot adja tovább a végleges fordítóprogramnak.
  vagy…
• Linkelés közben: Amikor a már lefordított forráskód és egy úgynevezett deklaratív, „Aspect” kód segítségével egy AOP modul beteszi a szükséges kódokat a megfelelő helyekre (.NET esetén a fordítóprogram által előállított köztes „IL” – Intermediate Language kódba, Java esetén pedig feltételezem, hogy a bájt kódba).
  vagy…
• Futtatás közben: Amikor a már lefordított köztes kód (IL vagy bájt kód) és egy úgynevezett deklaratív, „Aspect” kód segítségével a JIT – Just In Time modul beteszi a szükséges kódokat a megfelelő helyekre, még mielőtt a végrehajtás (vagyis a vezérlés) ezeknek az automatikusan a beillesztett kódnak átadódna.

AOP foglalatosságaink alkalmával a következő fogalmakkal találkozhatunk:

• base-code: az eredeti kód, ami soha se fog megváltozni,
• join-points: azok a pontok, ahova a beillesztés majd megtörténik (tipikusan eljárások, property-k eleje és/vagy vége, feltételes utasítások eleje és/vagy vége, kivételkezelések, metódushívások, mező hozzáférések, bármi más…),
• point-cut: a beillesztés helyének és módjának logikai leírása (deklarációja),
• advice: az előzőleg meghatározott point-cut szerint beillesztendő kód,
• weaver: az eredeti vagy „base”, és az ”Aspect” nyelven leírt „point-cut” összefésülése (végső kód előállító).

3. példa (a fentiek alapján):

 

• joint-point helyek a „base” forrásbank (két osztály definíció Java nyelven megfogalmazva)

class Line implements FigureElement
{
  private Point p1, p2;
  Point getP1() { return p1; }
  Point getP2() { return p2; }
  void setP1(Point p1) { this.p1 = p1; }
  void setP2(Point p2) { this.p2 = p2; }
  void moveBy(int dx, int dy) { p1.moveBy(dx,dy); p2.moveBy(dx
}

class Point implements FigureElement
{
  private int x = 0, y = 0;
  int getX() { return x; }
  int getY() { return y; }
  void setX(int x) { this.x = x; }
  void setY(int y) { this.y = y; }
  void moveBy(int dx, int dy) { x += dx; y += dy; }
}

• Egyszerű point-cut utasítások („AspectJ” nyelven megfogalmazva)

call(void Point.setX(int))
call(void FigureElement.moveBy(int,int))
call(void Point.setX(int)) || call(void Point.setY(int))
call(void java.io.PrintStream.println(*))
call(public * Point.*(..))
call(public * Line.set*(..))

• Összetett és elnevezett point-cut utasítások („AspectJ” nyelven megfogalmazva)

pointcut stateChange() :
  call(void FigureElement.moveBy(int,int)) ||
  call(* Point.set*(*)) ||
  call(* Line.set*(*));

A fenti példákban csak metódushívások szerepelnek, mert ez a tipikus, de természetesen más is lehetne. Mint látszik a point-cut deklarációkban különféle * || && jelek is bekerülhetnek, melyek a helyes mintaillesztésre szolgálnak.

 

• advice utasítások („AspectJ” nyelven megfogalmazva)

before(): stateChange()
{
  System.out.println("about to change state");
}

A végső, futtatandó kódba, az összes „stateChange” nevű point-cut mintára illeszkedő join-point helyére, a megadott metódushívások elé (before) fog bekerülni a „System.out.println("about to change state");” utasítás.

 

• after() returning: stateChange()
  {
    System.out.println("just successfully changed state");
  }

A végső, futtatandó kódba, az összes „stateChange” nevű point-cut mintára illeszkedő join-point helyére, a megadott metódushívások után (after) fog bekerülni a „System.out.println("just successfully changed state");” utasítás.

4. példa (esettanulmány):

 

Az Apache Tomcat (Java alkalmazásszerver) terméken belül kielemezték, hogy mindössze egy osztály foglalkozik az XML elemzéssel, két osztály az URL link mintakereséssel és kiértékeléssel, de majdnem mind a 42 osztály foglalkozik naplózással, sőt a 42 osztály szinte mindegyik metódusa akár többször is végrehajt ilyen tevékenységet. Ezesetben az AOP alkalmazása rendkívül hasznos és előnyös lehet.

 

További információk:

• AOP programozás C# nyelven (mindössze két cikkből álló, rövid de igen jó magyarázat)
• AOP keretrendszerek C#-hoz
• AOP keretrendszerek Java-hoz
• AOP – Radical Research in Modularity (Google video)

Hát ennyi. Remélem nem voltam túl összefüggéstelen.

Déjà vu

Van egy ismerősöm, aki egy pici kis szoftvercég ügyvezetője, és grafikus ablakkezelő rendszereket készít. A minap mondta, hogy szívesen beperelné a Microsoft-ot, mivel az a Windows operációsrendszerét a saját ablakkezelőjével szorosan összeépítve árulja, és ezzel csökkentik az ő piaci lehetőségeit, illetve a fogyasztók választási esélyeit. Egy másik ismerősöm is hasonló csónakban evez, csak az ő vállalkozása fájlkezelő szoftvert gyárt, és egyébiránt pont ugyanilyen panaszokkal állt elő a minap. Szintén felháborítónak tartja, hogy a Windows-nak van saját fájlkezelője, amit ráadásul a Microsoft (velejéig gonosz mivoltából következően) pofátlanul be is integrált az operációs rendszereibe.

 

Az említett cégek összefogtak még egy önálló, extragyors és hatékony hibrid kerneleket fejlesztő kompániával, illetve egy kiemelkedő képességekkel rendelkező ACL (Access Control List) megoldást nyújtó szoftvervállalattal. Mindannyian elfogadhatatlannak tartják, hogy a Microsoft, monopolista törekvéseit erősítve ugyanolyan megoldásokat készít, mint ők, azt meg különösen nehezményezik, hogy ezek a szoftverek elválaszthatatlanul a Windows részét képezik.

 

Kiadtak egy közös nyilatkozatot, miszerint a Microsoft azon cselekedete, hogy a saját fejlesztésű szoftverében integrált (huhh, e szót még kimondani is borzalom) megoldásokat alkalmaz, az bizony példátlan és egyedüllálló dolog a világban. Jóérzésű ember az ilyent, egyenesen emberiségellenes bűntettnek tart, ami valójában még egy közismert ország politikusai által támogatott Endlösungnál is galádabb cselekedetnek számít. Ezért lógniuk kellene! Vagy legalábbis jó lenne felnégyelni őket, de ha azt mégse, akkor mindenkit dutyiba zárni. Esetleg… hohóóó, nem is… humánus okokból talán legyen mégis csak inkább pár milliárdos pénzbírság. Minimum.

 

A céljaik eléréséhez találtak is egy kiváló inkvizíciós szervezetet, amelynek nagy gyakorlata van az efféle ügyek diszkrét intézésében. Nos, meglássuk mire mennek. Szurkoljunk nekik mi is, mert most ez a divat. Győzzön az igazság!

 

***

 

A fenti történet csak a képzelet szüleménye. Senki egy másodpercig se gondolhatja komolyan azt, hogy ilyen a XXI. században még előfordulhat.

 

Ui.: Mások is rágódnak a témán.

Application Architecture Guide 2.0

A CodePlex portálon elérhető a legújabb Application Architecture Guide 2.0 doksi végleges verziója. Az 1.0 változatot olvastam, már az is nagyon jó volt. Szoftvertervezőknek (divatosan architekteknek) kötelező olvasmány.

 

Letölthető innen.