Programozót keresek oldalam magyarítására, és kisebb átalakításokra mint bejelentkezés Microsoft, Googleplus fiókkal beépítése, stb. Szabad kapacitással rendelkező gyakorlott programozó jelentkezését, referenciáit várom erre a címre alexx@citromail.hu
Mivel új topikot nem tudok nyitni. Ezért ide linkelem. ( http://index.hu/gazdasag/2017/04/06/tanuljon_ingyen_informatikusnak/ ) Valaki tudna erről bővebb tájékoztatást adni. Pár link is megtenné. Elvileg áprilisban már indulnak képzések. De neten, sehol sem találtam, hogy hol lehetne jelentkezni.előre is kösziüdv
Nálunk egy csatornán mennek a kérdések, egy másikon jönnek a válaszok, és közben van egy Cisco PIX, aki, ha rossz kedve van, elbontja az egyiket vagy mindkettőt
Kiirhatom, de ha minden egyes hiba utan emberi beavatkozas kell, hogy peldaul az adatszerkezetek konzisztenciajat visszaallitsd, akkor az mar nem olyan nyero.
Nem teljesen értem ezt a szemléletet. Miért ne írhatnád ki egy on-line rendszerben azt, hogy "Hiba történt", ha egyszer tényleg hiba történt?
Ha hiba történik, akkor nem szabad elfedni a hibát, mert az csak nagyobb galibát tud okozni. Az űrszonda programozás persze más műfaj, de mezei programoknál szerintem ez a követendő elv. Nem kell ezen lelki életet élni, hogy "de ez nagyon-nagyon fontos lenne". Ha nagyon-nagyon fontos neki, akkor majd nagyon-nagyon gyorsan hívja az operátort. ( meg annak a főnökét, meg annak is főnökét, és jó hangosan panaszkodik majd, hogy szar az egész.)
(Amúgy a http tényleg sokkal megbízhatóbb, mint az MQ.)
HTTP-nel gyakorlatilag nem tortenik ilyen. (Persze elvileg elofordulhat, de ezerszer ritkabban.), az MQ-val meg gyakorlatilag igen.
Ilyenkor nem sokra megy az ember az elveivel, neki kell allni kodolni es egyre bonyolultabb strategiakat alkalmazni a kulonbozo esetekre. (Pl. kulon mokas egy olyan uzenetvaltas kezelese, amikor valamit beregisztralnal valahova, es a valaszban kapnad meg az azonositot, amivel kesobb el tudod erni az objektumodat.)
Az operatorok meg emberek, aszinkron hatterfolyamatok felugyeletere alkalmasak, de egy online rendszerben nem irhatom ki, hogy "Az adatok megerkezeseig kerjuk, igyon egy kavet, az operator is epp ezt teszi."
Ha adott időn belül nem érkezik meg a válasz, akkor mindenképp hibát jelzel a felhasználónak. Ezután az operátor dolga, hogy kinyomozza, hogy mi is történt valójában. (Nyilván nem szabad kicentizni a timeout-ot, hogy tényleg csak akkor fusson timeout-ra, ha valami gond van.)
És itt jön be az MQ értelme, mert ha http-n küldözgetnéd az üzeneteket, akkor nem tudnál nyomozni.
Es ha kozben megtortent a muvelet, csak nem kaptam meg idoben a valaszt? Kozben meg azt jelzem a usernek, hogy nem sikerult a muvelet, ezzel jokora kalamajkat okozva.
Egyaltalan nem olyan egyertelmu a dolog, mint az elsore tunik, hidd el.
És mi van, ha nem jön meg az, hogy "rendben, átutaltam a pénzt" ?
Akkor most átutalta vagy nem?
MQ-nál ez úgy néz ki hogy, "az üzenet itt még megvolt, még itt is, a szerver ideadta a választ, amit ide átküldtem, de e között a két pont között nem ment át."
Mindkettobol lehet masikat csinalni, csak maceras. (Mostanaban pont az aszinkron->szinkron vonallal szivok es _rengeteg_ problema van vele. Kezdetnek itt van egy: bedobok egy uzenetet a feneketlen kutba es nem kapok valaszt. Ilyenkor mi a teendo?)
Úgyértem hogy ha mondjuk a szerver visszaküldte a kliensnek, hogy "rendben, átutaltam a pénzt", az nagyobb biztonságot ad, mintha egy közvetítő gép küldi azt, hogy "ígérem hogy meg fogom kérni a szervert, hogy küldje át a pénzt".
Nem sokat. Nem vagyok egy nagy MQ guru. De az tudom, hogy az üzenetek route-olását elég jól lehet szabályzoni. Ez alapján nem nehezé kisakkozni, hogyan működhetne.
Ez a "magas szinten döntöntték el" című történet úgy szokott zajlani, hogy amikor megmutatjuk a terhelési teszt eredményeket, akkor legondolkoznak, hogy talál mégsem kéne mindent naplózni.
Ilyenkor jön az előrelátó programozó bűvészmutatványa, és hip-hop átkapcsol egy opciót, és megmutatja, hogy milyen gyors lenne, ha csak az update-eket naplóznánk. (Persze ez közben kicsit több munka, de ha az ember valamiről eleve is tudja, hogy hülyeség, akkor célszerű ilyen rejtett funkciókat beleépíteni. )
1. aszinkron kommunikációból lehet szinkront csinálni, de fordítva nem.
2. a http egy csomó mindent nem tud, amit az MQ igen. (pl. naplózás)
Az MQ nem a TCP-t vagy HTTP-t alternatívája, hanem egy arra épülő magasabb réteg.
Mondjuk azt nem tudom, hogy hogy mukodik az MQS clusteres kornyezetben. Errol tudnal meselni valamit? Mert az egesz rendszerintegracionak szerintem valahol ez a lenyege: a skalazhatosag es a stabilitas.
Na ja, mondom, hogy a konfigolassal is vannak gondok. (De azt, hogy minden uzenetnek perzisztensnek _kell_ lenni, magas szinten dontottek el.)
Az is oke, hogy kell egy "kozos uzenetkozvetito reteg" (bar oszinten szolva errol sem vagyok szaz szazalekig meggyozodve, de ebbe most en menjunk bele). Viszont a QS _nem_ alkalmas szinkron kommunikaciora. Pont. Ha arra hasznalod, akkor millionyi problemaval kell megkuzdened, amelyeket mind megsporolhatnal, ha parasztos modon ugyanazt az xml uzenetformatumot hasznalva egy http szerverrel kommunikalnal.
Tehat nem ot-hat kell, hanem kell egy szinkron es egy aszinkron uzenetek kiszolgalasara alkalmas rendszer.
Ha nem perzisztens, akkor a szerver csak memóriában tárolja, és rohadt gyors. Persze ennek az az ára, hogyha megdöglik a szerver, akkor vaesztek az üzenetek is. Természetesen ha a winchester meg tönkre, akkor mindenképpen elvesznek az üzenetek... tehát sohasem lesz olyan biztos a dolog, mint ha közvetlen kapcsolat lenne a két végpont között...
Én azt tenném szóvá, hogy nem lehet Windows-ban (tudtommal) azt beállítani, hogy ha jön egy üzenet, akkor PostMessage-oljon egyet a felhasználói programnak...
Bocsi, az MQ-nál is me lehet állítani (akár üzenet szinten is), hogy perzisztens legyen-e vagy sem. Ha nem perzisztens, akkor a szerver csak memóriában tárolja, és rohadt gyors. Persze ennek az az ára, hogyha megdöglik a szerver, akkor vaesztek az üzenetek is. Érdemes úgy szevezni a rendszert, hogy amit nem kell naplózni (például lekérdezések), az ne legyen perzisztens.
Amúgy meg teljesen rendben van, hogy egy nagyobb cégnél kell egy egységes üzenetközvetitő réteg, egy "lingua franca". (A sima TCP/IP sok esetben még kevés)
És az is teljesen renben van, hogyha valhol már döntöttek az MQ mellet, akkor ennek a támogatását várják el az új alkalmazásoktól is.
Abban természetesen nem foglalok állást, hogy az MQ jobb-e, mint a konkurens, szoftverek, de abban biztos vagyok, hogy teljesen baromság, hogyha egy cégnél, öt-hat "álalános célú integrációs szoftvert" üzemeltetnek. [Pedig ez a gyakorlat]
Maga a Queue Server otlete remek, az altalad leirt dolgok figyelembevetelevel. Namost amelyik cegnek en dolgozom, ott kitalaltak, hogy mindenre ezt kell hasznalni.
Na de.
Az IBM MQS (aminek a jelenlegi uzleti neve a Websphere MQ, ha jol tudom), nem arra valo, hogy egy sorra sokfele listenert akassz ra kulonbozo selectorokkal. Megpedig azert nem, mert az uzeneteket file-ban tarolja, tehat a selector futasakor jo kis vinyokerregtetes van, es minel tobb uzenet van a sorban, annal jobban belassul a rendszer (Graceful degradation is for wimps.)
Persze ez nem az eszkoz hibaja, hanem azoke, akik bekonfigoltak, es "megterveztek" az architekturat, de akkor is maga ez a file-ba tarolos modszer nem az igazi.
(Cserebe ott van az Oracle AQ, ami ertelemszeruen db-ben tarol minden cuccot, indexeket lehet ra definialni es igy igazan gyors tud lenni meg akkor is, ha sok selectorod van.)
A WebSphere egy brand név, ami alá több önálló termék tartozik. Ezek közül legfontosabb a WebSphere Application Server (rövidítve: WAS), és általában erre hivatkoznak úgy, hogy "a WebSphere". [Valójában a WAS-nak is kismillió változata és kiegészítő komponense van.] Az hogy több termék neve elött is ott szerepel a "IBM WebSphere" string, önmagában még jelent semmit, legfeljebb sejtetni engedi, hogy milyen témakörbe tartozik a cucc.
Pár éve találták ki, hogy (akkor még négy, ma már) öt brand alá szervezik a teljes IBM-es szoftver skálát. (Kivéve az op.rendszerek, mert az az IBM-nél a vas része.)
Ezek a brand-ek (IBM-es terminológiában "software pillar"-ek ), ahogy nekem sikerült felfognom:
WebSphere: Különféle alkalmazás és kommunikációs szerverek, köztes szoftwerek
Tivoli: Rendszer menedzsment eszközök
DB2: Adatkezelés
Lotus: Csoportmunka, felhasználói felület
Rational: Fejlesztői és modellező eszközök
Ja, és kínosan ügyelnek arra, hogy minden termék hivatalos neve IBM-mel kezdődjön, utánna jön a brand név, majd a tényleges neve, az egyes változatokra utaló szavak, és végül a verziószám.
Például: "IBM WebSphere MQ Workflow V3.5"
(És ez egy igen egyszerű név volt.)
Az IBM-esek gyakran poénkodnak azzal, hogy valahol az IBM szervezeti struktúrájának a mélyén, valahol a marketing közelében dolgozik, egy "IBM Renaming Group", ami erősen megnehezíti az egyszerű bithuszárok életét, és jól összekavarja az ügyfeleket. Persze ez nincs így, de azért az igaz, hogy IBM termékneveknek nem sok köze van a termékhez, sokkal inkább ahhoz, hogy szerintük, az adott terméknek mi lenne a szerepe egy teljes vállalati szoftver architektúrában.
Ide kívánkozik még egy IBM-es szleng, ami tömören jellemzi ez az egészet: "Sell the vision, deliver box!"
Heh, nalunk olyan xml-ek vannak, es ugy megy a konverzio hogy egyszer egy nativ adatstruktura->DOM->string konverzio folosleges lefutasa miatt (debug log) elszallt OutOfMemory-val a webszerver :)
A Websphere-t nem tudom, az MQS régebben önálló termék volt, tkp egy üzenetközvetítő rendszer ami gépek közötti üzenetsorokat menedzsel, a filozófiája az, hogy az üzenet biztosan eljut a címzetthez, ha nem most (pl mert most nincs is bekapcsolva), akkor később. Nem teljes képtelenség a dolog, csak meg kell találni azt a feladatot, ahol erre van szükség... nálunk rendszerint olyan feladatok vannak, hogy itt az ügyfél, prompt kellene neki az adat, ha most nincs meg a válasz, akkor öt perc/ öt óra/ öt nap múlva már ne is jöjjön, mert minek
Mi az a Websphere MQ és miért agyhalál? Érdekel, mert hallottam már a nevet, viszont nincs türelmem az IBM marketingszarából kihalászni a lényeget (és ott nyilván nem írják le hogy miben nem jó).
