szakdolgozat vedes

8ra megyek megvedeni. kivancsi leszek, mennyit fognak kotozkodni... ha elfogadjak, akkor diplomas ember leszek :-)

update: programozo matematikus lettem en, meglepetes e koltemeny.. ;)

( bird v | 2010. 06. 24., cs – 00:42 )

8:00? "Az még hajnal szinte." Hajrá!
_______
Powered by Áram // Nem vagyok annyira kocka, hogy napfényt is csak HDR-Renderingen keresztül lássak.

van egy olyan sanda gyanúm, hogy az csak addig működik jól, amíg nincsenek spéci igényeid (amelyek szakdogavédésnél szvsz. előfordulnak… ;))

int getRandomNumber() { // ←ez itt már az aláírásom
	return 4;//szabályos kockadobással választva.
}		//garantáltan véletlenszerű. xkcd

( persicsb | 2010. 06. 24., cs – 18:32 )

Gratulalok!
SZakdolgozatod, vagy legalabb a vedes prezentacioja elerheto valahol? Szerintem vagyunk paran, akiket erdekelne.

A LaTeX alapja fél nap alatt megtanulható, kb annyi az egész hogy végigkattintod az első pár fejezetet itt: http://en.wikibooks.org/wiki/LaTeX aztán utána, ha kell valami (pl. kép beszúrása) akkor a megfelelő linkre kell nyomni a tartalomjegyzékben. :)

De vigyázz, sima egyszerű "szkriptnyelv", semmi objektumorientáltság, meg hasonlók. ;)

Érdekes, jó, meg minden.
Nekem egy konstruktív kritikám van: a nyelvezete kicsit felületes, nem elég "hivatalos", gyakorlatilag "alap" angol nyelvet használsz.
Angol tudás magasabb szintre fejlesztése nem árthat, bár természetesen bőven jó az angol tudásod, csak mondom, mint konstruktív kritika, hogy van fejlődési potenciál ebben is.

Igazából nem az van, hogy rosszul lenne bármi is megfogalmazva...
Nem nagyon tudom megfogalmazni, hogy mire gondolok, sőt igazából nincs is semmi probléma vele.
A nyelvezete "egyszerű", érted, nem tudom jobban megfogalmazni.
De nyelvtanilag, meg stilisztikailag is helyes (szerintem), hanem csak konstruktív kritika volt részemről, hogy lehet még jobbra fejleszteni a dolgot.

peace amúgy, no offense! :)

"az angol szokincsemmel/nyelvtani tudasommal nem hiszem"
Nem erről van szó, mondom, hgoy rendben van az anyag, na. :)
Mondjuk az lehet, hogy én rengeteg hivatalos levelet, szerződést, meg ilyen szarságokat írok/olvasok angolul, és azoknak más a nyelvezete (sok bővített kifejezés, magázódó, hivatalos stílus, etc.), azért hatott talán nekem ez "egyszerűnek".
De mondom, végülis rendben van a dolog teljesen!

Gratula a munkához.
[gonoszkodás on]A következő angolságán például lehetne javítani >-)
"which implies many restrictions regarding both the architecture of your application and what and what can’t you do."[/off]

Psc talán a választékosabbnak ható hosszabb alakokra ill. latin eredetű megfelelőkre gondolhatott; ill. ha egyes mondatokat nem tagolsz ponttal, hanem tagmondatként összeilleszted őket, akkor kevésbé hat "alap" angolnak (bár én sokkal érthetőbbnek találom szaknyelvi szövegben a szárazabb, tagoltabb megoldást). Vagy egy egyszerű példa: if you... helyett in case of szerkezet stb.
De szerintem a nyelvezete alapvetően developer-like, semmi gond vele.

koszi, a kodot is kipattintom majd.

magabol a dolgozatbol sok minden kimaradt az ido rovidsege miatt - keson jottem ra, hogy "oh bazz, mindjart le kell adni". ezek TDK anyagkent mennek tovabb, jovo honap vegeig irunk belole egy hasonlo dolgot, ott jobban igyekszunk formalizalni a dolgokat.

(pl nincs leirva magaban a dolgozatban, de a lokalis allapotter-kiertekelo fuggvenynek disztributivnak kell lennie a particionalo operatorra nezve... most erted, ilyet egy atlag developer meglat, menelkul :), holott ez van az egeszben).

ami otletek vannak me'g:
- statisztikai analizis a jellemzok mintavetelezese alapjan a rendszer throughputjara nezve, majd ez alapjan a disztribucios metodus hangolasa
- graceful shutdown tamogatasa nodeonkent
- particiok ujrarendezese cluster-bovites/csokkenes eseten
- remote task scheduling direkt tamogatasa (Callable<T> x = container.run(new RemoteRunnable<T>(...)), es valahol majd landol, aztan visszakapod)

Belepillantottam, és szerintem a fő stílusbeli furcsaság a rengeteg: "you"

A szakmai angol szövegekben nem szokás az olvasót "szólítgatni".
Ahol csak lehet szenvedő szerkezetet szokás használni, különösen ha az alany ismeretlen (az olvasó).

Vagy kitalálható (előző mondatokból következik), ilyen pl. általában a saját munkáról való beszámoló, az első mondat egyértelművé teszi az alanyt. Pl. We present a novel..blabla
A többi meg már lehet szenvedő: It has been designed to...blabla

( foofighter | 2010. 06. 28., h – 06:13 )

Lefordítottalak :D

A skálázhatóság és a rendelkezésre állás növelése
a "vezérlés megfordítása" mintával

Konklúzió:
Ha meg akarjuk érteni egy komplex rendszer működését, legjobb ha felbontjuk kis részekre: ha az összes kis rész érthetővé válik, a kép világosabb lesz. Persze a Sparky-t nem lehet összehasonlítani a Spring-gel vagy a teljesen kifejlett Java EE stack-kel, nagy előnye viszont, hogy a kódmérete még kezelhető a tanulók számára.

Kitűnő gyakorlat lehet hallgatóknak egy új üzenetküldő protokollt implementálni vagy a meglévő implementáció szűk keresztmetszeteit vizsgálni.
Azt hiszem, hogy a Sparky pehelykönnyű, ennek ellenére számtalan hatékony funkcióval bír. Nem a legjobb megvalósítás és rengeteg dolog van, amit fejleszteni lehetne:

* konténer megszakítás támogatása
* egy példány konkurrens másolatainak felső határa a klaszterben
* round-robin ütemező helyett, adaptívabb kiválogatása a konténereknek, mondjuk statisztika alapján
* feladatok migrációjának támogatása csomópontok(node) között

Mintahogy a téma áttekintésben megemlítettem, számtalan más gráftípust ki lehetne próbálni az üzenetküldés alapjának. A prototípus Kautz-gráfra lett készítve, de még a JMS-alapú üzenetküldésnél is lassabb volt, köszönhetően az üzenettovábbítás magas költségének. Nagyon magas komplexitás/haszon mutatója miatt az ötlet el lett dobva.

Transparently enhancing scalability and availability
using inversion of control techniques

Conclusion
When someone tries to understand how complex systems work, it’s best to start at the small
parts: if once all the small parts are understood, the picture will become clearer. Of course
Sparky cannot be compared to Spring or a full-blown Java EE stack, but there is a clear
advantage: it’s code size is manageable for students.
Creating a new messaging implementation, or trying to evaluate the current code’s
bottlenecks can be good exercises in the classroom.
I believe Sparky is very lightweight, yet it supports many powerful features. The
implementation of these features aren’t the best, and there are many things which could be
improved:
- container disconnection support
- upper bound of a single instance’s number of concurrent copies inside a cluster
- instead of round-robin, use a more adaptive way to select the container to use, like
statistics
- job migration support between nodes
As it’s mentioned in the topic overview right after the front page, there are several other
graph-types that can be tried to form a logical network to base the a messaging
implementation on. A test implementation was made for the Kautz-graph, but it was even
slower than JMS-based messaging, due to the high cost of message distribution. It had a
very high complexity/benefit ratio, so it was abandoned.