Előző bejegyzésem második fejezete szintén a Postán kezdődik, és két szállon fut - össze. Egy postás nagy köteg pénzzel indul borravaló-gyűjtő körútjára: a nyugdíjat viszi a munkában megöregedett néniknek, bácsiknak. Kapuról kapura, lakásról lakásra jár, kétszer csenget, és kiszámolja  kinek kinek a havi nyugellátmányt.

De miközben pénzes postásunk a várost járja, egy másik postás-táskában sárga csekkre írt követelések szelik a várost, egy egy címre akár fél tucat is érkezik: víz, gáz, fűtés, villany, telefon, internet... A postaládában lapulnak, majd borítékjukból megszabadulva elmarasztalón várják beteljesülésüket az íróasztal sarkán, a kredencen, a kis polcon.

Amikor a sárga csekk, és a nyugdíj találkozik, összefut a két szál, és hármasban a nénivel megy a postára. A pénz boldogan ugrik a kasszába, a csekket pedig utóléri szomorú végzete, megcsonkítva utazik haza az irattárcában, hogy egy fiók mélyén leljen örök békességet.
 

Mennyi felesleges munka az infrastruktúrának, és felesleges fáradozás a felhasználónak.

Nemrég olvastam Doransky blogjának legújabb bejegyzését. Felháborított. Még hogy humán erőforrás kizsákmányolása, alkalmazottak kisajtolása?! A blogger szerintem hibás következtetést vont le, amiért nem hibáztatható, hiszen az által hivatkozott BBC cikk forrás  két ponton is téved.

Az egyik, a munkaidő felmérése. A munkavállalók tudják mennyi fizetést kapnak, és érzik, hogy mennyit ér a munkájuk. És elvégzik az órabér-kompenzációt: hosszabb kávé- és ebédszünet, lassabb ügyintézés, több felesleges levél, Facebook, és még jópár eszköz biztosítja, hogy a munkavállaló a megemelje a nettó órabérét.

A másik, hogy a munkavégzésnek emelnie kell a GDP-t. A közigazgatásban dolgozók által végzett munka eleve nehezen számítható át Domestic Product-tá. Amikor emeli az életminőséget, akkor valahogyan számszerűsíthető, de ha hozzátesszük, hogy Magyarországon az állami szervek egy része a nap végén semmilyen hasznos szolgáltatást nem nyújtott, akkor hamar érthetőbbek lesznek a BBC számai.

Egy tegnapi esettel szeretném illusztrálni állításomat. Két történet fonódik össze, a találkozási pont a Posta, az egyik legnagyobb magyar foglalkoztató (2008-ban a legnagyobb volt, 35000 alkalmazottjával magasan előzve meg a MÁV-ot és a TESCO-t)

Szükségem volt egy születési anyakönyvi kivonatra. Ehhez el kellett mennem a VI kerületi önkormányzatra. Ott öt(!) lebzselő biztonsági őr közül kettő viszonozta köszönésemet. Beljebb egy alkalmazott szédítette a két recepcióst, akik kedves mosollyal útba igazítottak a második emeletre. A két anyakönyvvezető hölgy közül (az újszülötteknek külön ügyfélfogadásuk volt) az egyik átvette a kitöltött kérelmet, és megkaptam a küldetést: szerezzek 2000Ft-os okmánybélyeget. El a postára, megvártam, míg az ügyfélszolgálatos befejezi a palacsintáját, természetesen csúcsidő, hatalmas sor, ketté tép egy papírköteget, elsétál vele a szemeteshez, vált néhány szót a kollégájával, visszaül, kezet töröl, mély lélegzetet vesz, és kinyitja végre az ablakát. 2000Ft be az ablakon, bélyeg ki az ablakon, vissza az okmányirodához, a bélyeget átadva már enyém is a papír.

Mennyi termék keletkezett? Egy színes A4-es lap. Mennyi idő alatt? Ha az én ráfordításomat nem nézzük, akkor 1 perc a postán, 2*5mp a biztonsági őröktől, 3*10mp a recepciósoktól (Don Juan kolléga is meghallgatta a kérdésemet), 2*4 perc az okmányirodában, összesen kb 10 percnyi aktív humán erőforrás használat, valamiért, amit akár a Magyarország.hu-ról is le lehetne tölteni, ha komolyan vennék az online ügyintézést.
 

Kaptam egy érdekes levelet. A számomra ismeretlen feladó feladó: 

David Juhasz <bunnyis2003@freemail.hu>

A levél:
 

Szio,
Iszonyat hideg van odakint, ugyhogy termeszetjaras storno, de helyette mozizhatunk otthon:
http://www.tiny9.com/u/rush
Atyauristen, ezt meg kell nezd!
Bye!

Az első gyanús jel, hogy nem rémlett a srác neve. De hát ha valaki népszerű blogot vezet akkor rajongók ezrei küldenek levelet neki. Perszre nem beszél meg mindegyikkel esti programot, főleg nem természetjárást egy Dáviddal. Második intő jel volt, hogy nem én voltam a címzett :). Nem tudom, hogy a Yahoo miért engedte mégis be a levelet. De ettől eltekintva nagyon szabályos levél volt. Egy link a szöveg közepén, a magyar átlagnak megfelelő nyelvhasználat, megfelelő nyitó és záró formula.

Ha kicsit ügyesebb lenne a spammer, és megszerezne egy Facebook kontaktlistát, akkor hasonló levelet küldve egy ismerős nevében, valószínüleg elérné, hogy az ember a linkre kattintson.
 

Lassan már komoly szellemi feladat lesz a postafiókban kiválogatni a szemetet, még akkor is, ha az ember az ismerőseit úgy válogatja, hogy azok ne bombázzák digitális hulladékkal.

Ha valaki a régmúlt időkben tanulni szeretett volna, beállt inasnak egy mester mellé, elindult világot járni, bölcs tanítókat keresett fel, kitanult egy iskolát, később elment egyetemre. A jó iskolák, mesterek, nagy gondolkodók híresek voltak messze földön, aki a legjobbat szerette volna, áldozatokat hozott, utazott, vándorolt, maga mögött hagyta hazáját, családját.

 Aztán zsugorodni kezdtek a távolságok, fejlődött és ocsóbb lett az utazás, az egyre olcsóbb nyomdák nagy példányszámban nyomhattak könyveket, melyek metalálták olvasóikat a világ túlsó végén is. Majd a rádió, a TV az információt a fény sebességével szállította a háztartásokba. És végül az Internet az időtől is függetlenítette az információt.

A gyors fejlődés kis, de annál jelentékenyebb láncszeme lett a Google, aki az üzleti sratégiájának részeként az információ minél nagyobb szegmensét tette és teszi rendületlen buzgalommal ingyenesen elérhetővé. Ez neki mindenképpen jó: az információból reklámhordozót csinál, majd a felületet adja el. De ez egy másik írás témája lesz.

Szóval a helyzet mai állása szerint a világon fellelhető tudás ingyenesen elérhető mindenki számára. A nagy kérdés, hogy okosabbak lettünk-e ezáltal?

A Wikipedia lehetővé teszi, hogy rendszerezetten osszuk meg szakmánk szépségeit. Nem kell más, mint egy szakmai cikket kivonatozni, és feltölteni. A sok kis szakterületből pedig összeállhatna a világ tudása.

A Facebookon lehetőségünk van arra, hogy különböző szakemberekhez jussunk el ismerőseink ismerősein keresztül, így nem csak a fizikai, de a szociális távolság is csökken, vagy legalábbis felmérhető.

Technikai, filozófiai, politikai, közéleti, történelmi, szépirdalmi, orvosi, gazdasági blogok milliói segítenek eligazodni a világ dolgai közt. A tárgyterületi fórumok mellett külön fórumok szakosodtak kifejezetten kérdések megválaszolására.

És mindezeket több hatékony keresőmotor fogja össze, hogy a számunkra szükséges információ-morzsákat a lehető legrövidebb idő alatt megtaláljuk.

És okosabbak lettünk? Ha a válaszhoz az országos felmérések, az Érettségi vizsgák szinvonala, a felvételi eredmények nem lennének elegendőek, vessün egy pillantást magára az internetre! Ne is menjünk messzire, keressük a legolvasottabb blogokat itt a blog.hu-n.

Fundamentális hiba van az Internetben, és feladatomnak érzem, hogy kijavítsam :)

Minden cég költ kereső-optimalizálásra, aki egy kicsit is ad magára. Aztán költ Ad-sense re, adMob-ra, adWords-re. És évről évre többet költ.

Elgondolkodva a jelenségen néhány érdekes analógiát találtam. A legelső ami eszembe ötlött a fegyverkezési verseny volt - van. Nagyhatalmak versengenek azért, hogy ki a világ legnagyobb hatalma. Ennek a versenynek haszna is van: a hadiipar felveszi az esetleg más iparágakban már foglalkoztatni nem tudott munkásokat, mérnököket, kutatókat. A katonai fejlesztéseknek pedig hasznos mellékhatásai lehetnek a lakosságra. A másik oldalon viszont kockázatos, mert mi van, ha valaki úgy dönt, hogy ki is próbálja, vajon ő-e a legerősebb.

Egy másik példa, immáron a pénz világából az 1 dolláros licit. Egy társaságban kikiáltanak eladásra egy dollárt. A kikiáltási ár egy cent. Van azonban egy érdekes szabály: akárki is viszi a dollárt, a két legnagyobb licitet ki kell fizetni. Tehát ha 75 centre valaki 76-ot mond és ez az utolsó licit, akkor ő 24 cent nyereséggel távozik, a második helyezett 75 cent veszteséget könyvelhet el. A kisérletek során 3 dollár fölött álltak meg a licitek.

A fenti példa analógiájára, a kereső-játékhoz sokkal közelebbi példa a manapság terjedő 15mp-es licit-oldal. A liciteket egységnyi lépésekben lehet megtenni. Egy egység - legyen cent - költsége 10 cent. A végén a győztes megvásárolhatja a terméket az elért áron. A licitnek akkor van vége, ha 15 mp-ig nem érkezik új licit.

Hasonló történik a Google által egységesített online reklám világában is. Az egymással versengő cégek játékkörönként korlátlan mennyiségű pénzt dobhatnak a kalapba. Aki a játék-körben több pénzt szórt a kalapba, a következő körben első lehet a listán, miközben indul a pénzdobálás előről.

Hogy a kicsik és nagyok egyenlő esélyeket élvezhessenek, végtelen sok versenypályából lehet választani, minden szóra lehet licitálni. Hasonlóan magas a versenyzők száma is. Aki nyulaknak végez hajfelvarrást, az minimális befektetéssel a nyúlhajfelvarrók listájának elejére kerülhet. Aki gáz és víz szerelő, annak már magasabbra tornászták a már versengők a lécet.

A fentieket átgondolva egy gyors kisérletet végeztem el egy hozzám közel álló céget mérve, aki úgy döntött, hogy az "adótanácsadó" pályán indul.

Az RSM DTM Kft nagyon lelkiismeretesen idomul az online világ kihívásaihoz. Szinvonalas szakmai blogot vezetnek, megjelentek a Facebookon, hírlevelük, Twitter-oldaluk van. És az "adótanácsadó" pályán nagyon jól futottak. Száz meg száz, a témával foglalkozó oldal közül a második odlalon hozta őket a Google.

A kisérlet folytatásaként az ezzel ekvivalens, de a cég online stratégiájában kevésbé fajsúlyos "adótanácsadás" kifejezésre is megvizsgáltam az eredményeiket. Majdnem feladatam, amikor a 19. oldalon rájuk találtam.

Gondoltam, ez nincs így jól. ELindítottam a két keresést az általam ismert két nagy konkurens oldalán. Bing - 4 / 10, Yahoo - 6 / 14. Ez szerintem sokmindent elárul a keresőoptimalizálás hatékonyságáról: a keresőoptimalizálás hatékony. Egy keresőre egy ilyen kis országban bármit fel lehet optimalizálni az első oldalra. És ezzel aki teheti vissza is él. Ezért az igazán értékes találatok egyes területeken nagyon mélyen lapulnak. Így 19. oldalon osztoznak a kevésbé marketinggelt releváns, és az erősen marketingelt irreleváns oldalak is.

Egy javaslat: ha olyan témát keresünk, ahol a keresett félnek közvetlen anyagi érdeke fűződik ahhoz hogy sokan megtalálják, ne Google-t használjunk. Az azt fogja megmutatni, hogy ki mennyit költött marketingre. Használjunk Bing-et. Először is, egy szép képpel fogad minket. Másodszor pedig még nem sikerült olyan mértékben korumpálni, mint nagy testvéreit.

Végre elindult az Edudroid, a tanszékünk Androidos kutató- és fejlesztőcsapata. Sikerült benne előkelő helyre szert tennem, hála a Droidfocinak, a két demo-alkalmazás egyikének. Azért demo-alkalmazás, mert a hivatalos bemutatkozásra szerdán kerül sor a szakiránybemutatókkal egybekötve a TMIT tanszék standján. Akit érdekel a mobilfejlesztés, a mobilplatformok kicsiben (Android, Widows 7 Mobile...) és nagyban (3G, UMTS, BlueTooth, WiFi...) az mindenképpen jöjjön el, nem csak egyetemistáknak!

Drupalos kalandozásaim során eljutottam a CCK modulig. Már nem a szerveremen kisérletezek, hanem Xampp-pal, ahova frissen feltettem egy 6.17-es Drupal-t. Azért kezdtem el foglalkozni a CCK-val, mert saját node-típusok és mezők definiálása közben nehézségekbe ütköztem.

Egy Kezdőoldalt szerettem volna készíteni, ami a böngészők "Bookmarks" funkcióját helyettesítette volna online, hogy géptől, böngészőtől függetlenül ugyanazokat a linkeket találjam. Eddig is használtam egy ilyen oldalt, ami plain html volt, ezért nehézkes volt a szerkeszése, főként az, hogy a megfelelő helyre szúrjam be a linkeket.
 

A problémám az volt, hogy hogyan vegyek fel tetszőleges számú új linket az oldalra. A CCK erre a problémára elegáns megoldást szolgáltat: definiálhatunk saját mező típust, majd ezt hozzáadhatjuk valamelyik node-típushoz, és megadhatjuk, hogy hány példányban lehet jelen az adott node-on (1-10 vagy tetszőleges). A mező típus bevitele egy URL és egy cimke, megjelenítése pedig a generált link. Sok tutorial tartozik a régi CCK-hoz. Azonban a CCK2-vel több hook is megváltozott, ezért a legbiztonságosabb egy létező modulból kiindulni (pld. Text), én az alábbi mintakódból dolgoztam. Bár az elnevezések ("value") nehezítették a munkát, végül sikerült átalakítanom a kódot oly módon, hogy két mezőt kezeljen, és azokat szépen fel is cimkézze. Az eredmény azonban nem volt kielégítő.

A Kezdőoldalon most már tetszőleges számú linket fel tudtam sorolni, azokat sorba tudtam rendezni. De a linkek ömlesztve nem valami hasznosak. Ugyan csoportosíthatóak, group-ok felvételével, de a group-ok számát a tartalom típus szerkesztése közben kell meghatározni. Ez közel sem olyan dinamikus, mint a böngészők könyvjelzői, ahol ráadásul tetszőleges mélységben lehet könyvtárakat - csoportokat - létrehozni.

A CCK hiánypótló modul, de az első tapasztalataim szerint nem varázsszer, így már egy olyan, alig specifikus tartalomtípus esetén, mint a Kezdőlap sem tartom kifizetődőnek a használatát. Hatalmas mennyiségű kódot kell írni a tartalom létének definiálásához is. És csak ez után következik az egyedi működés, tárolás, megjelenítés programozása. Természetesen ha nem igénylünk efféle működést, akkor a CCK egy remek eszköz arra, hogy elfedje az adatbázist, a szerkesztést, megjelenítést, hook-jaival támogatja a validációt és a megjelenítésre való felkészítést, a fent említett számossági problémát. De mint minden keretrendszer, kereteket szab, amiket ha át is lehet lépni, annak a költségei jelentősek.

A Kezdőoldal modult a Form API segítségével fogom megvalósítani (egy jóképű és érthető tutorial itt), erről majd később.

Mivel már egyszer elvesztettem, és csak szerencsével sikerült a levelezőmből előbányásznom, most itt kőbe vésem, hogy UML rajzoláshoz a legkényelmesebb ingyenes eszköz a Dia. Mivel tud EPS-t exportálni, ezért cikkek írásakor is nagy segítséget jelenthet, és van néhány egyszerű könyvtári eleme, amivel megfelel a hobbi-szintű modellezéshez.

Szóval: Dia.

Annak ellenére, hogy a hétvégén elsősorban a tanulmányaimra szántam azt az időt, amit nem a családommal töltöttem, és emellett teljesen át kellett alakítani - most már a végleges formájára - ahonlapot, amit megrendeltek tőlem, maradt egy kis időm foglalkozni a saját oldalammal is.

A cél az volt, hogy egy Page-en megjelenjen a blogok listája. Sajnos csak utóbb derült ki, hogy a hook_load a saját tartalom-típusoknál hívódik csak meg, és nem minden csomópontra. Nem tudom, hogy ez mennyire jogos, mindenképpen biztonságosabb, és kevesebb erőforrást igényel. Mivel nem akartam belepiszkálni a core-ba, ezért úgy döntöttem, hogy legyen akkor saját tartalom-típusom. Erre is biztosított a Drupal.org tutorialt, úgyhogy semmi perc alatt készen voltam. Annyi módosítást eszközöltem a kódban, hogy a form nem tartalmaz body elemet, ehelyett a teaser-t lehet szerkeszteni, mivel a body-t dinamikusan generálom.

Először azt gondoltam, hogy a hook_load csak a megjelenített tartalmat változtatja meg, ezért azt találtam ki, hogy a csomópontom kap egy egyedi nevet (blog_list_562123) és ez alapján fogom keresni. Sajnos ez nem működik. Bár a csomóponthoz nem kerül elmentésre a _load-ban beállított body, elmenti a title mező tartalmát felülírta, így első betöltésnél elrontotta az azonosítót. Más utat kellett választani.

Mivel úgyis ott van a MySQL adatbázis, ezért adódik, hogy abban tároljam a kiválasztott csomópont azonosítóját. A natív elérés helyett a Drupal Schema modulját használtam, mely félig meddig elfedi az adatbázis-hozzáférést (a táblák létrehozását-törlését és a rekordok írását meg tudja valósítani objektumokból, de olvasásra nem találtam metódust, ilyenkor csak a táblanevek feloldásával segít). Ehhez létre kell hozni egy .install file-t is, és abban definiálni kell a hook_schema, hook_install és hook_uninstall függvényeket. Itt egy buktatóval találkoztam: ha a modul már installálva van, akkor hiába változtatjuk a .install file-t, a modul újra-aktiválásával nem kerül újra-installálásra a modul, ehhez uninstallálás után kell újra aktiválni.

Ha a telepítőben létrehoztuk a táblát, a következő lépés a node létrehozása, és az azonosító elmentése az adatbázisba. Ezt a hook_enable-ben valósítottam meg. Először ellenőrzöm, hogy létezik-e az adatbázis-bejegyzés. Ha igen, akkor megkeresem a hivatkozott node-ot. Ha ez nincs meg, akkor létrehozom, és frissítem az adatbázis-bejegyzést. Ha megtalálom, akkor tétlenül fut le a hook, egyébként létrehozza a node-ot, és vagy frissíti a hivatkozó bejegyzést, vagy létrehoz egy újat, szükség szerint [forráskódot majd a saját oldalamra töltök fel].

Ezután már csak a tartalmat kell betölteni az oldal törzsébe, amennyiben a hook_load észleli, hogy a node azonosítója megegyezik az adatbázisban tárolttal. Ehhez a korábbi blog-lista kódját használtam fel, elé emelve be a teaser szövegét, és egy elválasztó <h3> címet. az eredmény teljességgel kielégítő, még annyiban kell finomítani, hogy mindenkinek csak azokat a blogokat mutassa, amelyekben van általuk is látható bejegyzés.

Átugorva néhány oldalnyi elméletet, a 6. fejezetet dolgozom fel, a tanulmányaimhoz elsősorban ez a rész szükséges. A szerzők egy egykiszolgálós, diszkrét idejű FIFO rendszerű, nem prioretizált modellt tekintettek. Két valószínűségi változó Xi és Yi az i. időpillanatban beérkező és kiszolgált igények mértéke. Qi jelöli az éppen kiszolgálásra váró munkamennyiséget.

Ezen a ponton a modell egyszerű, a sor hossza Qi megegyezik az (i-1)-beli sor hosszának és az (i-1)-ben beérkező munkának az összegével, levonva belőle az (i-1)-ben kiszolgált munkát. Természetesen a sor hossza sosem negatív. Ez Lindley egyenlősége. Először bevezetjük Zi-t a 0-i. időpont munak-növekményeként (itt fordul meg az idő), majd Wt-t a Z1...Zt növekmények összegeként.

Végül ida jukadunk ki, hogy Q0-ban a várakozási sor mérete a Wi-k maximuma (0-t indexekre), amennyiben Q-t -ben a sor nem volt üres, akkor Wt-t Qt-vel meg kell növelni. A maximumképzés azért kell (ahelyett, hogy Q0=Q-t + Wt lenne a képlet), mert Wi-k értéke lehet negatív is, és ha a sor ezáltal kiürülne, majd újragyűlne, akkor a síma összeadásnál nem vesszük figyelembe, hogy a sor egy ponton üres volt, így nem csökkent. Feltételezve egy kezdetben üres sort, Q0 értéke a Wi-k maximuma lesz. Ugyanez a helyzet, ha kellően hosszú futást feltételezünk, és egy egyensúlyi sorhosszt keresünk. Egyensúlyhoz természetesen feltételeznünk kell, hogy mind Xi, mind Yi stacionárius folyamatok, és az adott időpillanatban kiszolgált munka várható értéke nagyobb, mint a beérkező terhelés várható értéke.

A kérdés, amely a hálózattervező mérnökben felmerül: mekkora buffert építsek? Mennyi a valószínűsége annak, hogy a sor hossza egy bizonyos q értéket meghalad? A kérdés ismerős, a válasz adódik: a valószínűség kellően nagy q esetén q értékében exponenciálisan csökken.

Hogy a nagy eltérések elméletében megismert alakra hozhassuk a képletet, bevezetve a ráta-függvényt, P(Q>q) helyett a P(Wt/t >q/t) alakot kell használnunk, mert ekkor Wt/t valószínűségi változók átlaga lesz. A ráta-függvény paramétere így (q/t) lesz.

Mivel Q = max(Wt), ezért a P(Q>q) < P(W1>q) + P(W2>q) + ... 

Ezek után a képletből kiemelnek egy domináns tagot, melyre az exponens a legkevésbbé negatív, és azzal becslik felülről a valószínűséget.

A nagy eltéréseknek van információ-elméleti vonatkozása is. A szerzők Cramér szabályából kiindulva bizonyítják be az Asszimptotikus Ekvipartíciós Tulajdonságot. Ennek lényege, hogy a sztohasztikus forrás által generált karaktersorozatok lehetnek ugyan sokfélék, de jellemzően a karaktersorozatok egy szűk halmazából fognak kikerülni.

Ennek bizonyítására egy olyan példából indulnak ki, ahol egy nyelv szövegei az a1...ar karakterekből állnak. Feltételezik, hogy a nyelvben nincsenek jellemző karakterláncok, minden karakterlánc olyan gyakorisággal fordul elő, mint ami a karaktereinek együttes előfordulási valószínűsége - az egyes karakterek p1...pr előfordulási valószínűsége a nyelv ismert jellemzője. A nyelv n hosszúságú szövegei tehát n független és egyforma eloszlású valószínűségi változó sorozataként fogható fel.

Shannon észrevétele arra vonatkozott, hogy n növelésével a nem olyan gyakori karakterekből álló szövegek előfordulásának relatív gyakorisága exponenciálisan csökken. Ezt mondja ki az Asszimptotikus Ekvipartíciós Tulajdonság. Shannon azt is megfigyelte, hogy a csökkenés mértéke függött a karakterek előfordulási valószínűségének eloszlásától. Ennek mérésére bevezette a Shannon Entrópiát. Ezen entrópia mértéke akkor a legnagyobb, ha a karakterek egyforma valószínűséggel fordulnak elő.

Hogy a tételt visszavezethessék a nagy eltérések elméletére, a szerzők a következő jelöléseket definiálták. Az Xi valószínűségi változó az n hosszúságú szövegek i. karaktere. Bevezettek egy dirac mértéket is a karakterekhez, és az empirikus disztribúciót, melyet Ln-nel jelöltek. Az empirikus disztribúció képletében egyetlen karaktert helyettesítve be a B halmaz helyére a karakter relatív előfordulását kapjuk az adott w szövegben

// Itt elvesztettem a fonalat, ahogy a szerzők a Sanov tételhez bevezették az M(A) valószínűségi mértéket., és az alfa függvényt.

Chernoff egy módszert ad a ráta-függvény kiszámítására. Az ötlet alapja, hogy megpróbál a farok valószínűségére felső becslést adni. A bizonyításhoz bevezet egy indikátor függvényt. Az indikátorfüggvény 1 értéket vesz fel, ha az x paraméter eleme az indikátorfüggvény A halmazának, és 0 értéket minden egyéb esetben. Belátható, hogy tetszőleges egész számra az exponenciális függvény egy erős felső közelítése az indikátor-függvénynek. A levezetésben ezt a felső becslést használja fel arra, hogy egy teta paraméterű becsléssel majorálja a farok valószínűséget. A bizonyítás kulcslépése, hogy az indikátorfügvény várható értékérére tér át a farok valószínűségről, ami magától értetődő, hiszen az indikátor-függvény azokban az esetekben értékelődik ki 1-re, ahol Mn > a, és így a várható értéke pont az esemény valószínűsége lesz.

Az eredményben a valószínűségi változó mellett egy tetszőlegesen választható teta paraméter is bekerült. Hogy a közelítés minél pontosabb legyen, a kapott becslőt minimalizálhatjuk teta-ban. Chernoff formulája azt mondja ki, hogy a ráta-függvény megegyezik a levezetésben kapott kitevővel. Ennek kapcsán bevezeti a kumulatív generátor-függvényt. Ezt a pénzfeldobásos példára alkalmazva visszaadja a korábban kiszámolt ráta-függvényt.

Ezt követően a kumulánsok és a momentumok közti párhuzamra világítanak rá a szerzők.

A szerzők ezen a ponton a központi határeloszlás tételét veszik elő, amely az átlag közelében ad jó becslést valószínűségi változók összegének eloszlására. A központi határelsozlás által adott becslés a sűrűség-függvényre a Crémer szabályban megismerthez hasonló exponenciálist ad, itt az Crémer szabályban eloszlás-függő ráta-függvényt egy kizárólag az eloszlás momentumaitól fúggő x-ben másodfokú kifejezés veszi át. A szerzők rámutatnak arra, hogy a pénzfeldobásos példában kapott ráta-függvény Taylor-sorának első tagja pontosan a Központi Határeloszlás képletében szereplő kitevő.

Általánosságban megjegyzik, hogy a központi határeloszlás azokban az esetekben ad jó becslést a farok súlyára, amikor a ráta-függvény jól közelíthető x másodfokú polinómjával, ez - mint az eloszlás neve is mutatja - a központban, az átlag közelében fordul elő. Távolodva az átlagos értéktől, a Nagy Eltérések területére tévedünk.

 Ez a fejezet Harald Cramér-ről szól. Cramér svéd matematikus volt, aki egy biztosítótársaság alkalmazásában próbálta meg finomhangolni a biztosítási díjat annak érdekében, hogy lehetőleg minél kisebb legyen annak a kockázata, hogy a biztosítótársaság likviditás nélkül marad - gyengébbek kedvéért fizetésképtelenné válik, és csődöt jelent. Munkájának eredménye a róla elnevezett szabály, mely általánosítja az első részben ismertetett empirikus eredményt. Hogy a biztosítótársaság hogyan profitált matematikai eredményeiből, arról nem szól a cikk. És most lássuk a feladatot!

A biztosítótársaság mérlegét a következőképpen egyszerűsítette: a bevételi oldalon csak a tagdíjak szerepelnek:a biztosítottak naponta összesen p összeget fizetnek be. A t. napon a biztosítót terhelő kifizetések mértéke Xt. Annak a valószínűsége tehát, hogy a társaság a T. napon csődbe megy, annak a valószínűsége, hogy valamely T napig bezárólag a kifizetendő kártérítések összege meghaladja a befolyó biztosítási díjak összegét, másszóval, hogy a kifizetett kártérítések napi átlaga magasabb, mint a naponta befolyó tagdíj. A nagy eltérés tehát a napi kártérítés várható értéke és a napi kártérítés átlaga közt vizsgált, és a farok kezdetét a tagdíj mértéke adja meg.

Ha feltételezzük, hogy minden nap ugyanolyan veszélyes, és a különböző napokon történt káresetek függetlenek egymástól, ezért alkalmazható Cramér szabálya a csőd valószínűségének becslésére. A gyakorlati haszon abban rejlik, hogy a biztosítótársaság által vállalt kockázat (és a tervezett T üzemidő) ismeretében kiszámolhatóvá válik a beszedni szükséges napi biztosítási díj, amennyiben az adott problémára ismert a ráta-függvény, aminek kiszámításához szükséges a kártéritési igények eloszlásának ismerete.

// A hivatkozott ábrák a cikkben találhatóak, lsd. Nagy eltérések elmélete 0.

A nagy eltérések elmélete ritka események előfordulásának kutatásával, azok valószínűségének modellezésével foglalkozik. Itt jellemzően nem olyan ritka eseményekre kell gondolni, mint egy földrengés vagy tözsdei események, napkitörések előrejelzése: a nagy eltérések elméletének célja nem idősorok előrejelzése, hanem különböző hosszú-farkú eloszlásfüggvények farkának vizsgálata.

Egy viszonylag egyszerű hosszú-farkú eloszlás a binomiális eloszlás. Ennek gyakorlati előfordulása a pénzfeldobás. Ha egy szabályos érmét n-alkalommal feldobunk, akkor annak a valószínűsége, hogy a dobások során átlagosan 0<=k<=1 fejet kapjunk, binomiális eloszlás szerint alakul.

Hol a nagy eltérés? A pénzfeldobásos példában a nagy eltérés a várható érték (szabályos érme esetén 0.5) és egy konkrét kisérlet során n dobás átlagaként kapott M érték között fordulhat elő. A dobássorozatok nagy részében M a nagy számok törvénye alapján közel lesz 0.5-höz, de valamilyen valószínűséggel előfordul, hogy M nagyobb lesz tetszőleges 0.5<x<1-nél.

Ha annak a valószínűségnek a logaritmusát akarjuk ábrázolni n függvényében, hogy M nagyobb, mint valamilyen választott x, akkor egy zajos lineárisan csökkenő függvényt fogunk kapni (Figure 2.). A görbe meredeksége x értékétől függően természetesen változik (Figure 3.).

Ha a görbe meredekségét x függvényében ábrázoljuk, akkor egy nevezetes függvényt, a ráta-függvényt kapjuk (Figure 4.). Pénzfeldobás esetén megfigyelhető, hogy a farok eltűnésének mértéke n-szerint exponenciálisan csökken a farok definíciójának (x értékének) függvényében. Tehát a farok-definíció megválasztásának függvényében exponenciálisan csökken annak a mértéke, hogy a kísérletek számosságának függvényében hogyan csökken a farok súlya.
 

A nagy eltérések elméletének célja, hogy különböző esetekre meghatározza a ráta-függvényt. A pénzfeldobás esetén a grafikusan ábrázolt ráta-függvény megegyezik az x*ln(x) + (1-x)*ln(1-x)+ln(2) függvénnyel, erre a cikk a mellékletben szimbolikus bizonyítást is ad.

Összességében tehát elmondható, hogy a farok súlya exponenciálisan csökken n függvényében (Figure 2.) és a csökkenés mértéke szintén kvázi exponenciálisan (lsd fentebb I(x) definíciójában) függ a farok hosszának (x) megválasztásától.

A cikk ezek alapján levezeti a nagy számok gyenge törvényét a nagy eltérések elméletének alapjából.

A webes bejegyzések közé becsempészek egy rövid sorozatot egyetemi tanulmányaimmal kapcsolatban. Szabadon választható tárgyként vettem fel a "Nagy eltérések a tömegkiszolgálásban" kurzust. Sajnos egészségi állapotom miatt nem tudtam bejárni, ezért most gondban vagyok a vizsgára készüléssel, jövő kedden kell bizonyítanom a területen szerzett tudásomat, szerencsére csak egy prezentáció és kötetlen beszélgetés formájában.

Egy átfogó bevezető cikkből készülök, és gondoltam, ahelyett, hogy magamnak jegyzetelnék, megpróbálom közkinccsé tenni a kinyert tudást. A sorozat úgy bővül majd, ahogy én haladok az olvasással és megértéssel. A képletekre csak hivatkozni fogok, nek akarom kép-másolgatással húzni az időt.
 

Nemsokára jön az első fejezet a nagy eltérések elméletének első példájával: a pénzfeldobással.

Elkészült az első Drupal modulom: mivel az oldalamon már ketten is blogolunk, ezért felmerült az igény egy blog-választóra, mert a Drupal beépített blog-motorja ömlesztve tálalja a bejegyzéseket. Első körben egy blokkot hoztam létre, amiben fel vannak sorolva a bloggerek, és a nevek linkek a blogokra. A következő lépés az lesz, hogy a taxonómia alapján is lehet majd listázni a bejegyzéseket, és harmadik lépésként a felhasználók lesznek taxonómia alapján aláosztva, és viszont. De lássuk, hogy készült a modul!

A tutorial alapján nem volt nagy ördöngősség. Azt nem ismétlem meg, ami a tutorialból kiolvasható, azt olvassa ki mindenki maga. Egy gondolatot azért kiemelnék, ami talán kezdőknek nem egyértelmű: annak ellenére, hogy a Drupal-os kódrészletek általában szépen <?php?>-be vannak keretezve, valójában file-onként egyszer kell csak szerepelnie a tag-nek, és akkor is csak a nyitó (<?php) felének, lezárni nem szabad.

A fejlesztés a segédletek alapján egyszerű volt, főleg, hogy találtam mintakódot a blokk testéhez :). Az SQL alapján úgy látszik, hogy a Drupal adatbázis elég szép, tiszta, majd azért ránézek ha lesz egy kis időm. Az egyetlen gondot az jelentette, hogy elgépeltem a .info file nevét, és ezért az nem jelent meg az admin felületen. Ezzel elment majd egy óra, közben a .info file tartalmát szépen konformizáltam, a tutorial-ban nagyon keveset írnak a file-ról, úgyhogy egy másik modulból emeltem át a kódot.

Mindezek ellenére a modul már tegnap este működésnek indult. Következő lépés az lesz, hogy létrehozok egy dinamikus node-ot, ami tartalmazza a blogokat, és némi bevezetőt, meg egy "indíts saját blogot" linket.

Talán sokaknak mást jelent a három betű. A Google keresője számára mindenképpen. Talán vicces, talán egy érdekes kihívás volt, egy flame, de nem elfogadható, hogy a három betűt, mely minden távközlési protokol alapját képezi ily módon sajátítsák ki. Minden eszközzel küzdenünk kell az állapotgépek jogaiért. Kérek minden jóérzésű informatikust, matematikust, processz vagy logisztikai tervezőt, hogy álljon mellém e modellezési eszköz méltó helyének visszaállításáért folytatott küzdelmemben!

Jelenjen meg minél több helyen az FSM és a Finate State Machine összefüggés, hogy a buta Google-robotok által trónra emelt gasztronómiai szörnyeteg - kinek nevét kimondani és leírni vétek - elbukjon!

Egy másik blogról szeretném tájékoztatni az esetleges olvasóimat. Tudom, hogy hatékonyabb egy olvasott oldalról hivatkozni azt az oldalt, ahova látogatókat küldene az ember, de most ezek a lehetőségeim.

Szóval akinek elege van már az Indexes (Privátbankáros, Portfóliós...) gazdasági elemzőkből, és kiváncsi azoknak a véleményére, akik abból élnek meg, hogy tanácsaikkal segítsék szilárd talajra a gazdaságpolitika zavaros vizein evezőket, azok lessék meg az RSM DTM Zrt frissen indult blogját!

Ha jól sejtem, a blog-motor a jól bevált World Press, a bejegyzések sorrendjén még remélem igazítanak kicsit a rendszergazdák, jobb a FILO blog (kevésbbé műszakiak kedvéért First In, Last Out, blogos értelmezésben: az a bejegyzés kerül legkésőbb olvasásra, tehát kerül legalulra, amelyiket legkorábban írták). Jó olvasgatást, és ha érdekel, amit, ahogy csinálnak, akkor lehet őket twitteren is követni.

A webfejlesztés egyik legalattomosabb buktatója az egyedi fontok használata. A fejlesztő gépén jellemzően hemzsegnek a különböző fontok, elég csak feltenni egy Adobe terméket. De mi a helyzet az irodai gépekkel? 6-8 éve ott csücsül a gépen egy Windows, amit a rendszergazda telepített valószínüleg az Office egyik többé kevésbbé legális példányával meg esetleg egy könyvelőprogrammal. Aztán a felső vezetés utasítására biztonságossá tette a gépet. Ez általában gátat szab programok telepítésének, de könnyedén lehet a procedúa kellemetlen mellékhatása, hogy a felhasználók fontokat sem tudnak telepíteni - nem mint ha a nagyrészük tudná mi az.

Ilyen környezetben a mindenhol jól mutató honlap úgy fest majd - természetesen IE 6 alatt megnyitva -, mint egy world dokumentum. Ezt elkerülendő lehetőség van betűtípusokat ágyazni a CSS-be. Ennek eszköze a @font-face. Meglepő módon ezt a funkciót a Microsoft vezette be, így már IE 4 -ben is elérhető, míg a két fontos Windows konkurens csak a 3.5 (Firefox) és a 10 (Opera) verzióktól támogatják. A @font-face használata meglehetősen egyszerű

@font-face {
   font-family: myFont;
   src: url(my_font.ttf);
}Érthetetlen módon azonban míg az Opera, Firefox és Webkit a TrueType/OpenType TT (.ttf) formátumot használja, addig a Microsoft a saját Embedded OpenType (EOT) szabványához ragaszkodik. Az átjárás - a licensz-problémáktól eltekintve - egyszerű, ttf-ből eot-et akár a weben is lehet csinálni. Mivel azonban két url-t nem lehet megadni a @font-face-ben, ezért két font típust kell importálni, egyet ttf-ből, egyet pedig eot-ből. Ahol az adott fontot használjuk, ott pedig mindkét típust fel kell sorolni. Hasznos trükk hogy ha sok fontot szeretnénk használni több stíluslapon keresztül, akkor a @font-face definíciókat érdemes kiszervezni egy külső CSS file-ba.
 

A fontok másik hátulütője a dollár, az ingyenesen elérhető fontok nagyrésze ugyanis nem tartalmaz ékezetes karaktereket, viszont az igényesebb teljes készletekért akár $100-t is elkérhetnek. Kinek van pénze 3-4 betűtipus megvásárolni a honlapjára?! Ráadásul ezek webes használatkor nem is tölthetőek le, a böngészőnek mindig a szolgáltató szerveréről kell előkeresnie majd a font-file-t, és igen kellemetlen, ha ennek elérhetősége korlátozott.

Még egy jó ok arra, hogy amíg az IE (és Opera és FireFox és Safari...) nem támogatja a CSS3-at neki se fogjunk webfejlesztésnek. Ki gondolná, hogy a "balról jobbra sorban, amíg van hely, majd a következő sorban folytatva" irányelv a listák (<ul> / <li>) esetében csodaszámba megy.

A CSS3 természetesen erre a problémára is elegáns megoldást ad: a listáknál megadható a renderelni kívánt oszlopok száma, vagy a szélessége, így akár fix szélességű táblázatban, akár szabadon szélesíthető listaként lesznek megjeleníthetőek a listaelemek. (Ezt a viselkedést a firefox korlátozottan már támogatja)

De miből gazdálkodhatunk most? Sok tutorialban olvashatjuk, hogy a float:left megadásával a listaelemek szépen egymás mellé csűsznak majd. Mellette mélyen hallgatnak a float kellemetlen mellékhatásairól. Ha nem akarjuk, hogy a következő elem is befurakodjon a listaelemek közé, akkor vagy az elemnek kell megszüntetnie a lebegést, vagy az utolsó lebegő elem mögé kell tenni egy clear:left tulajdonsággal bíró üres, láthatatlan <div>-et. Utóbbit sajnos nem lehet a CSS :after pszeudo-elemmel elővarázsolni, mert hiába adunk meg content:url(clear_div.html); -t, ezt a böngészők egy része egyáltalán nem, az Opera pedig képnek próbálja értelmezni, nem meglepő módon sikertelenül. A content:"<div></div>"; sem vezet sikerre, ekkor a karakterlánc közvetlenül kerül kiírásra. Egyik megoldás sem kielégítő tehát, mert az módszernél a következő elem stílusába kell belenyúlni - mely elem kiléte változhat fejlesztés közben - , a második módszer használatakor pedig a markup sérül.

De jobb választásunk nem nagyon akad, a lehetőségek közt a lista tördelése, és <div>-be csomagolása, valamint a margókkal való pozícionálás szerepel. Esetleg a elővehetjünk a hanyagolt <table>-t. És közben álmodozhatunk a CSS3-ról, ahol a grid-box layout natívan támogatott. Persze akkor meg sírhatunk majd amiatt, hogy az elemek balról jobbra, majd fentről lefelé lesznek indexelve, és nem választható a fentről lefelé, majd balról jobbra.c

Egy kicsit igazgattam ma a blogomat, hátteret cseréltem, húzogattam a dobozokat: berendezkedtem. Ennek eredménye a Twitter doboz is, ami az oldal jobb szélén kapott helyet. A kódot a Twitter generálja egy webes wizzard segítségével, egyszerűbb, mint a Dreamweaver.

Modernizálódás közben ráakadtam még egy gyöngyszemre, egy 3rd party megoldás, mely egyszerűbbé teszi a tweet-ek írását. Mostantól ha szeretnél az egyik bejegyzésemről írni, nincs más dolgod, mint az oldal alján lévő linket kattintani.

A mai reggel eredménye, hogy egy kezdetleges Drupal oldal már elérhető a lajthabalazs.com -on. A tárhely, amit a Terra Server biztosított, PHP 5.2.3-al és MySQL 5.0.45-tel van felvértezve. Első lépésként "telepítettem" egy phpMyAdmin-t. Ez az eszköz egy PHP alapú webes felület MySQL adatbázisok kezelésére. Azért a phpMyAdmin-t választottam az asztali kliens helyett, mert a Terra Server-nél, és gondolom, sok más web-host-szolgáltatónál az adatbáziselérés a szerverre van korlátozva Az adatbázis-adminisztráció a Drupal telepítéshez nem szükséges, de előbb utóbb úgyis kellett volna, ráadásul szerettem volna megváltoztatni az alapértelmezett adatbázis jelszavamat.

Ezután a Drupal telepítése meglehetősen egyszerű volt. Ugyan a settings.php-t létre kellett hozni egy egyszerű másolással, és néhány hozzáférési jogot át kellett állítani - FTP-n keresztül a Total Commander ilyent nem tud, de a FileZilla klienssel könnyen ment - de talpon volt a site fél órán belül, az installerek le, majd feltöltésével - nem biztosított a Terra Server parancssori hozzáférést, úgyhogy minden file FTP-n ment.

Egyenlőre egy csomaggal egészítettem ki az alap-installációt: fetettem a Content Access modult. Ez lehetővé teszi, hogy a hozzáférési jogokat node-onként állítsam. Erre szükség is lesz, mivel az oldal egyszerre fog szakmai, baráti és személyes célokat betölteni, utóbbi kettőt pedig nem feltétlenül szeretném megosztani leendő kollégáimmal, munkaadóimmal, üzletfeleimmel. Több site-ot adminisztrálgatni pedig nem szeretnék, az az érzésem, hogy meg fog gyűlni a bajom ezzel az eggyel is. Egy próbán már túl vagyok, meglehetősen egyszerű a modul használata, és megfelel az elvárásoknak. A teszt kapcsán több más szolgáltatást is kipróbáltam: átállítottam a regisztrációt oly módon, hogy mindenképpen adminisztrátori jóváhagyás legyen szükséges. Felvettem a jövőben szükséges felhasználói csoportokat. Regisztráltam egy tesz-felhasználót. Itt érdemes megemlíteni, hogy az adimin felületen nem jelzi semmi, hogy jóvá kell hagyni egy regisztrációt. A jóváhagyás módja, hogy a user részleteit megtekintve a "blocked" állapotból "active" állapotba helyezzük a felhasználót. A módosítások mentése triggereli a jóváhagyást, és küldi ki az e-mailt az aktivációs linkkel.

Eztán jött a tartalom. Először bekapcsoltam a Content Access modult, és beállítottam, hogy a tartalmi elemekhez egyenként is lehessen jogosultságokat csatolni (kis pipa-doboz az oldal legalján). Ezután az új Page létrehozásakor már megjelent a Content Access fül, ahol be tudtam állítani, hogy csak az egyik csoport olvashassa az adott Page-t. Az új user-emmel kipróbáltam a csoportban, majd áthelyeztem egy másik csoportba, ahonnan természetesen már nem látta az oldalt. Elégedett vagyok a Drupal jogosultság-kezelésével, és alig várom a felhasználókat!

Az oldal nyelve egyenlőre angol, de tervezem bevezetni az Internationalization modult is, hogy egymás mellett lehessen angol és magyar nyelvű tartalom is. Persze kérdéses, hogy miért is kell magyar nyelvű tartalom, mivel jelen blogot nem fogom átvezetni a személyes oldalamra, ne kelljen friss olvasótáboromnak rögtön az elején szembesülnie a váltással, más témákban pedig vagy angolul írok (research page) vagy egyáltalán nem (fotógalériák). Nem szeretnék a szükségesnél több energiát fektetni a Drupal oldalba, szeretnék megtanulni saját modult írni, de annak sok értelme nincs, hogy l'art pour l'art megtanuljak kezelni egy modult hogy kikerüljön az oldalra egy zászlós nyelv-váltó meg néhány címke két nyelven.

Bár másféle költözést terveztünk, úgy tűnik, hogy be kell érnem egy új domain-nel és tárhellyel. Az elkövetkező postokhoz már működő minta-oldalakat is fogok feltenni, melyek a http://lajthabalazs.com oldalon lesznek elérhetőek. Egyenlőre az új hon-lap nagyon csupasz, tervben van egy Drupal alapú portál.

A Drupal-t most fogom elkezdeni harmadszor. Először nem értettem, és már az adminisztrációval elakadtam. Nem vagyok büszke rá. Második nekifutásra már sikerült látrehoznom egy kifogástalanul működő oldalt a saját gépemen futó xampp-on, és hála a támogatás vagy jómagam fejlődésének elindultam a tudás útján. Aztán idő hiányában meg is álltam. Talán harmadjára nagyobb lendületet véve végre sikerül elindítanom egy rendes oldalt.

Ma Tömegkiszolgálás házit csináltam, és elkezdtem a kutatást, úgyhogy a webezéssel nem haladtam, és hétvégén Nagy Eltérésekkel fogok foglalkozni, úgyhogy egy ideig pihen a blog, ahogy számoltam max 1 olvasóm lehet, tőle elnézést kérek, hogy 2-3 napra utánpótlás nélkül marad, remélem, feltalálja magát, nagy az Internet.

Lassan lassan az IE is beáll a szabványos böngészők sorába. Igaz, mindíg egy lépéssel lemaradva követi a trendet, de ahogy beérnek a szabványok úgy az az egy lépés egyre kevésbbé fog számítani.
 

Ennek egyik előnye, hogy nem 2-3 hanem csak egyetlen weboldalt kell programoznunk. Nem elhanyagolható következmény azonban az sem, hogy ahogyan túlléptünk a tradicionális <table> és <frame> alapú honlapokon, most már a <div>-ben <div> struktúrákra sincs szükség, hogy egyben maradon a tartalom.

A tisztuló markup, melynek köszönhetően az adat és a tartalom végleg szétválik, megnyitja a lehetőségét a stíluslapok közti szabad váltásnak. Arra azonban ügyelni kell, hogy hogyan választjuk meg a CSS osztályokat! Sajnos a CSS nem támogatja az öröklődést a szó objektum orientált értelmében, pedig most nagyobb szükség van rá, mint bármikor.

Vegyük az alábbi egyszerű esetet:

<div class="centered funny_border">

Látszólag a fejlesztő szétválasztotta a megjelenítést és a tartalmat: a formázási információ átkerült a CSS definíciók közé. De valójában a formázási utasítások még mindig benne vannak a kódban! A div osztálya azt mondja: igazíts középre és adj nekem vicces keretet. Pedig azt kéne mondania, hogy "én egy vicces doboz vagyok":

<div class="joke_box">

És ezen a ponton kezdenek el hiányozni a CSS objektum orientált tulajdonságai, aminek következtében a stíluslap tele lesz ismétlésekkel. Például ha a designer ugyanazt a keretet szánta a vicc-dobozoknak, mint a hozzászólásoknak, csak előbbit középre rendezte, utóbbi pedig egy színsémát kapott, akkor a keretet két helyen kell definiálnia.

div.joke_box {
   .... /* Mindenféle vicc-doboz tulajdonság*/
   border: .......;/* Egy vicces keret nagyon sok tulajdonságból állhat, és a CSS3-mal etz csak bővül majd*/
}
div.comment {
   .... /* Mindenféle hozzászólás tulajdonság*/
   border:........; /* A fenti keret pontos másolata, minden időben. Brrrr......*/
}

Megoldást jelenthet, ha a keretre jellemző tulajdonságokat kiemeljük:

div.comment, div.joke_box {
   border:........; /* Így már nem kell másolgatni */
}

De ekkor azt lesz gondunk számon tartani, hogy hány helyre is szóródott szét a joke_box definíciója. Milyen szép lenne a joke_box-on belül hivatkozni néhány másik stílusra, majd igény szerint kiegészíteni, valahogy így:

div.joke_box {
   @import funny_border;/* Lehet, hogy azt sem kellene kikötni, hogy csak div-ek közt lehessen megosztani stílusokat? */
   .... /* Mindenféle vicc-doboz specifikus tulajdonság*/
}

Remélem nem sokára nem csak a lapok szintjén lesz kaszkádosítás, illetőleg az általánostól a specifikusig haladva, hanem tetszőlegesen definiált sorrendben.