Tényleg a papír ami számít?...

 ( lajos22 | 2013. április 26., péntek - 2:19 )

...Tettem fel magamnak a kérdést a minap.
Történet a következő. Meglepett egy ismerősöm, aki egy pár fős webfejlesztő csoportban tevékenykedik. A csoport főnöke egy hihetetlenül beképzelt, ehhez mérten irtózatosan hülye egyén, aki akut papír függőségben szenved és csak felsőfokú végzettséggel vesz fel embert kávéfőzésre is... Ezt bebizonyította is, mikor az ismerősöm többszöri ajánlására nagy nehezen behívott, majd azzal indított, hogy "Miért is kéne fontos fejlesztői munkára olyat alkalmaznom, akinek WC pucoláshoz sincs képesítése?" tette ezt úgy, hogy 3 szakmám van, amiből 2 informatikai területen...

Na mármost. Az említett ismerősöm a minap sírva küldött egy kódrészletet, amit az egyik újonnan bekerült idióta adott be egy projekt kapcsán. Mely a következő:

// securty function no implement
$db -> query('select name, pass from user where name=' . $_GET['user'] . ' and pass=' . $_GET['pass']);

Na már most. Hogy a faszba kaphat valaki diplomát, pláne munkát egy ilyen egyszerű dolog ilyen szarul megoldása után??? Könyörgöm, ilyen baromságot még a legutolsó lepukkant Indiai koszfészekben sem követnek el.
A másik pedig a kommentezés. Nem vagyok Angol expert, de szerintem az a mondat úgy szar ahogy van...
Nem tudom, hogy most én reagálom-e túl, de tényleg ennyire hülyék jönnek ki diplomásként??

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

A diploma melle intelligencia nem jar. Mar sokadszorra tapasztalom meg.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

hozzaertes sem

--
Live free, or I f'ing kill you.

De a diploma hiánya mellé se jár intelligencia, ha jól tévedek.

Szerk.:
Magánvélemény következik, annak megfelelően is kell kezelni:
Az, aki csak a papírt nézi a tudás helyet, szimplán hülye. Tehát, ha valaki a papír megléte/meg nem léte alapján ítéli meg a jelentkezőt a tudása helyett, az nem való vezető pozícióba.
Másrészt ugye ez egy cifrább kérdés, mert ha egy cég meghirdet 1 pozíciót, amire van 1000 jelentkező, akkor vagy behívnak mindenkit, vagy megpróbálnak valami alapján szűrni. A papír lehet egy szűrő, bár illene figyelembe venniük a korábbi munkatapasztalatokat, referenciákat is.


"If you must mount the gallows, give a jest to the crowd, a coin to the hangman, and make the drop with a smile on your lips" The Wheel of Time series

A kettő közötti megoldás, hogy kiküldenek egy körlevelet, hogy mondjuk két héten belül küldjenek egy megoldást adott nyelven (amire felvételiztetnek) adott problémára. Amire mondjuk 20 sorból ki lehet hozni a megoldást. Lesz, aki ez alapján azonnal nem válaszol ("mit képzelnek, hogy a jelentkezéshez dolgozzak is nekik"), lesz, aki küld egy 20 megás zipet, mert framework-fétise van és ehhez behúz öt keretrendszert, de a lényeg, hogy a válaszolók esetében azonnal látni lehetne, hogy hogy oldaná meg, mennyire "kompatibilis" a kódolási stílusa a céggel (kódolási stílus alatt itt azt értem, bele teszi-e az SQL injection vulnerabilityt a fenti kódba) stb. (és leír-e olyat, hogy "No no. Mr. Security Function no es here").

BlackY
Szerk, ui.: És igen, a végzettség és az intelligencia/tudás között semmiféle korreláció nincs, de nem csak programozói állásoknál (sok-diplomás emberekkel találkoztam már, akik nem tudtak mit kezdeni azzal, hogy egy form-on a (kötelezőnek jelölt) Vezetéknév mezőt üresen hagyták és a teljes nevüket a Keresztnév mezőbe írták, aztán megjelent felette a piros felirat, hogy "Kérem töltse ki...". Többen, többször.)

Jogos, volt is részem ilyenben, nem ugrott be, pedig teljesen jó megoldás szerintem.


"If you must mount the gallows, give a jest to the crowd, a coin to the hangman, and make the drop with a smile on your lips" The Wheel of Time series

Épp most volt egy beszélgetésem egyik főnökömmel egyik kollégáról. Abban maradtunk, hogy a hölgy új funkciója biodíszlet.

Ezt most nem sikerült értelmeznem.
1) Ez megerősítő példa, tehát a hölgynek nincs diplomája, és nem ért a feladatához.
2) Ez ellenpélda, tehát a hölgynek van diplomája, de nem ért a feladatához.


"If you must mount the gallows, give a jest to the crowd, a coin to the hangman, and make the drop with a smile on your lips" The Wheel of Time series

szerintem a második:)

+1

A post elejéről a vadászos vicc jut eszembe. Ha előre tudnám, hogy a leendő főnököm hülye, akkor el se mennék az interjúra. Legfeljebb akkor, ha más lehetőségem nem lenne.

-----
A kockás zakók és a mellészabások tekintetében kérdezze meg úri szabóját.

"ilyen baromságot még a legutolsó lepukkant Indiai koszfészekben sem követnek el"
Hát őőőőő....
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods
Get dropbox account now!

Megelőztél...

Egyetemi diplomával, szakmai vezető, külső partneres megbeszélésen, ahol ha jól emlékszem egy webes rendszer jelszókezelése került szóba, volt szíves megkérdezni, hogy mi az az md5... IT-s diplomával. Még jó, hogy nem vegyészként végzett ugyanott...

meg kell hogy nyugtassalak, de a válasz: nem, nem te reagálod túl. Sajnos személyes tapasztalatom az, hogy egyetemről, diplomával, ennél hülyébbek kerülnek ki mint a postod tárgya. Kevés kivétellel az összes környezetemben lévő jó fejlesztő papírmentes, akinek van, azoknak javarésze előbb volt jó programozó, mint diplomás.
Az ilyen helyeket meg célszerű helyből elkerülni:)

"Miért is kéne fontos fejlesztői munkára olyat alkalmaznom, akinek WC pucoláshoz sincs képesítése?"

Ha ezt szó szerint mondta, akkor elmehet a búsba a tahó paraszt mucsai stílusával. Én biztos hogy felállok és otthagyom.

--
http://neurogadget.com/

...a ráborult asztal alatt :-P

Manapság egyre gyakoribb az az arrogáns stílusú interjúztatás, amikor a jelölt stressztűrő képességét is tesztelik, szándékos bunkósággal. Szóval ilyen esetben inkább érdemes az interjúztató szemébe nevetni. (vagy "uram, egy ilyen remek cégnél, mint az öné, bizonyára még a vécét is kész megtiszteltetés pucolni."
--
#conf t
#int world
#no shut

tehat nyaljunk, ha semmibe veszik az emberi meltosagunkat? nem hsizem, hogy erdemes ilyen helyen munkat vallalni

--
NetBSD - Simplicity is prerequisite for reliability

Irónia órákon bizonyára hiányoztál.
--
#conf t
#int world
#no shut

Ebben en sem latom az ironiat. Tahoval minek finomkodni? Valoszinuleg nem is ertene az "ironiat".
Romaban, mint a romaiak...

--
http://www.micros~1

Nem tudom, en igyekszek nem lesullyedni a szintjere, mert meg legyoz a rutinjaval.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

kovezzetek meg nyugodtan, de szerintem egy nyomoronc BSc elvarhato barkitol. nem muszaj informatikaban dolgozni, ha meg igen, fel kene fogni, hogy kell hozza legalabb egy BSc.

kepzeljetek, vannak olyan helyek, ahova MSc nelkul fel sem vesznek, a PhD megszerzese pedig kivanatos. OMFG! micsoda vilagban elunk! URISTEN!

(mert ugyan szakmai tudast nem ad egy diploma onmagaban, viszont hogy magamtol nem ultem volna neki absztrakt algebrat illetve analizist tanulni, az hetszentseg. meg valahol -legalabbis szeretnem ezt hinni- bizonyitja, hogy az ember nem ad fel valamit, csak azert, mert neha nehez)

Sokáig te is bsc nélkül dolgoztál, gondolom nálad is kiverte volna ez a wc-pucolós securty function..

igy van, en is sokaig a nelkul dolgoztam, _mikozben_ egyetemre jartam. es igen, a wc pucolos fazon nalam is kiverte volna a biztositekot, valszin raboritottam volna az asztalt. ezt nem is vitattam :-)

En egyebkent azt latom problemanak, hogy a diploma gyakorlatilag az erettsegit valtotta ki az allashirdetesekben. Egy rendszergazdatol is siman elkovetelnek bizonyos helyeken diplomat, pedig annak aztan tenyleg semmi szuksege ra. Nem devoprol beszelek, sima rendszergazdatol is.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

+1
--
ne terelj

Hát, ha ez egy épen fejlesztés alatt álló kód, akkor még elnézhető a dolog. Főleg, hogy megpróbálta oda kommentelni is, hogy még nincs implementálva a biztonsági funkció :)

Én is szoktam kommentet csak úgy odarittyenteni, nyelvtanilag nem feltétlenül helyesen. Bár én is csak magamnak, aztán amikor olyanom van szépen végigkommentelem a kódot.

A papárminis manusz, meg nc...

Angolból jó vagyok, kódrészlet-elemzésből pedig nem vagyok jó.

Inkább:
Function not implemented [security].

Mi a hibás a kódrészletben? Mit csinál rosszul? Hogyan lehetne jóra megírni?
______________________
this comment is cc by-nc 2.5

SQL injection

Eleve a Pass nincs is lezárva idézőjellel, emellett az SQL injection elkerülhetetlen... És ez egy security function? :D
--
Coding for fun. ;)

Köszi mindenkinek, aki válaszolt!
______________________
this comment is cc by-nc 2.5

Ahogy mondtak: SQL injection ES nem szokas user-pass -t GET -el atadni.

Az SQL injection nem biztos, hogy ebben az esetben _nagy_ gaz, mivel lehet, hogy az elso dolog egy foreach ( $_GET as $kulcs => $cur_get ) { $_GET[$kulcs]=tisztito_fgv($_GET[$kulcs]) } es minden valtozot tisztit, ezt nem tudhatjuk, de a GET hasznalatara akkor sem nagyon van bocsanat ( kiveve ha az app SSL only )

"( kiveve ha az app SSL only )"

Akkor sem.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

"sem nagyon van bocsanat"
Nem azt mondtam, hogy el lehet nezni, csak akkor nem egy akkor lyuk tatong az app -ban mint Magyarorszag, hanem csak kb mint a Balaton.
Rosszul fogalmaztam :)

De miért? SSL-nél nem ugyanúgy egy mozdulat átírni az url-t?

BlackY
ui.: Ami igazán katasztrófa, hogy ennyire tight coupled a rendszer, hogy az auth-ot végző kód közvetlenül a request-hez kapcsolódó cuccokat olvasgatja

Ha jol tudom, akkor SSL eseteben maga a request is titkositva lesz. Mind1, _NEM_ vedeni probalom a "szerzot", szerintem is enyhen szolva szar ...

Akkor sem, ha SSL-es az app. Nem illendő dolog plaintext-ben jelszót tárolni, még saját appon belül sem. Olyan, hogy "de csak átmenetileg" olyan nincs, az ilyen "átmeneti" megoldások azok, amik túlélik az eredeti appot is, "átmennek" a következő teljesen újraírtba is. (Abba most ne menjünk bele, hogy szemantikailag a GET vagy a POST a helyes(ebb..).)

"Nem illendő dolog plaintext-ben jelszót tárolni" lehet, hogy a kedves "programozo" JS -el - a form onsubmit -jaban AES -el titkositotta a jelszot, tehat az meg az elkuldes elott levedte azt. :)))

Mármint arra gondolsz, hogy JS-sel csinált belőle a kliens oldalon egy hash-t? Az lehet. Bár a kódrészletet látva kötve hiszem...

Igen, arra ertettem. Azert tettem a smiley -t a vegere, mert en sem hinnem. Tudom, hogy nagyon sokat nem segit, de en szoktam hash -elni kuldes elott a jelszavakat. Ha valaki csak akkor kezd el "hallgatolozni" miutan a felhasznalor mar megnyitotta a login oldalt, akkor nem fogja megtudni a jelszot ( legalabb is nem igy ).

Ezt sosem tudtam belátni, hogy miért jó. Ha a hash-t hasonlítod össze a DB-ben tárolttal, akkor valóban nem látod a plaintext jelszót, de legalább van egy fix hosszúságú másik jelszavad, amit ugyanúgy lehet küldözgetni a szervernek.
Persze lehet én nem látok valamit. Nem lennék meglepődve. :)

A kuldott hash nem egyezik a DB-ben tarolttal. Amit a kliens kuld az pl AES, amit a megfelelo kulccsal vissza lehet fejteni es a visszafejtett jelszot hasheli egy mas metodussal ( pl. csak rainbow -al visszafejthetovel ) es azt hasonlitja ossze a DB -ben levovel.
A kulcsot a kliens akkor kapja meg amikor megnyitja a login oldalt.
Tehat:
login.php lekeres => a server general egy random hash-t es elkuldi a kliensnek az oldallal egyutt => a felhaszalo post -olja a form -ot, akkor csak a hash lesz kuldve amit a jelszo,kulcs parosbol general. A szever amikor megkapja, akkor a _SESSION -ban tarolt kulcs alapjan megtudja a jelszavat amit ujra hash -el.
Tudom, szarnak egy pofon, de ha 10 perccel megroviditem egy betoro eletet, mar megerte :)

Így már világos. Tehát nem hashelés megy, hanem valamilyen titkosítás.

Igen, rosszul fogalmaztam. Titkositas lesz az :)

Valami hasonlót csináltam anno én is, 3DES-sel:
-szerver generált egy random kódot, DB.ben lerakta a kliens IP-jéhez kapcsolva.
-Kliensen a jelszó mezőből MD5, ezt az MD5-öt meg a random értéket 3DES-sel titkosítottam a jelszó MD5 hash-ét használva kulcsként(!), onSubmit()-ra ennek a kimenete került a jelszó mezőbe (célzott mellékhatásként a böngészős jelszómentés használhatatlan lett, ahogy az elő volt írva).
A szerver megkapta hidden mezőben a random értéket meg ezt a des-elt kimenetet. A randomot megnézte, hogy jó helyről jött-e, és törölte a DB-ből. A következő lépésben az userid-hez tartozó, DB-ben tárolt jelszóhash-ből meg a randomból legenerálta ugyanúgy a des-elt kimenetet, ahogy a kliens - ha a kettő egyezett, akkor sikeres volt a bejelentkezés.
Jelszócsere során a régi hash lett a kulcs, amivel a régihash+random+újhash lett titkosítva és a szerverre felküldve. Ott userid alapján a régi hash rendelkezése állt, kicsomagol, randomot és régi hash-t ellenőriz, majd az új hash-t a db-be beír. Első jelszó meg mobilon ment a usernek.

A lényeg: a jelszó, illetve a hash önmagában sohasem ment át a dróton, és az adatfolyamból értelmes időn belül visszaállítani sem igazán lehetett.

Lehet nem jól értelmezem, de akkor így az adatbázisban nem voltak salt-al ellátva a jelszavak, nem? (azt nem tudhatta a kliens, vagyis nem tehette bele a kulcsba, viszont a szerver meg nem tudta a salt nélküli hasht kulcsként használni, mert az meg azt nem tudta) Így viszont ha kikerülnek a jelszó hash-ek, akkor még szivárványtábla / brute force sem kell, mivel elég a hash az authentikációhoz.

BlackY

Valóban, nem volt sózva a DB-ben a jelszóhash (de implementálható lett volna). A userek alapadatait tartalmazó tábla védettségéről másképp (is) gondoskodtunk (külön séma, csak alaposan körbejárt tárolt eljárásokon keresztül ment be kérdés és jött ki jo/nem jó válasz, audit dolgok) úgyhogy ez a kockázat vállalható volt - annak fényében pláne, hogy az eredeti megoldásban plain text jelszó, direktbem a táblát matató egybenőtt kód volt...

Úgy azért más :) (Security by let's hope that we never have to lay off our sysadmins thus making them make a copy of the users table to take revenge on the company later on :) )

Off: A random és salt (szervertől kapott) mellé még mondjuk bele véve egy időbélyegzőt is (mondjuk dátum + időpont 20 perces felbontásban, hogy ne kelljen teljesen szinkronban lenni a szerverrel) még a brute force replay attack ellen is védene.

BlackY

Igen, volt azért benne még néhány trükk :)

egyebkent minek feltalalni a spanyolviaszt, amikor ott van pl. a http://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange

Baráti nehezítésként a kliensen csak js volt használható, kellőképp ratyi gépeken, és ilyen szempontból a szerveren is egészen korlátozott funkcionalitással lehetett számolni.

Bő egy éve az egyik magyar bank kártyás fizetőfelületén kerekedett ki a szemem, amikor a kártyaszámot, a ccv kódot és a lejárati időt (meg még pár apróságot) GET-ben küldött a form. Természetesen a böngésző historyban ottmaradt (volna) a https-es URL. Úgyhogy azonnal ment a levél nekik, hogy kezdjenek vele valamit. Szerencsére azóta már javították.

SSL-ről: a sok kretén azt hiszi, hogy az SSL az titkosít és ezután már gondolkozni sem kell.

Nos, sajnálatos módon nem így van:

- ha a repóban tárolod a privát kulcsodat, akkor gyk. plain-text-ről beszélünk
- semmit sem jelent, ha egy titkosított XML-t elküldesz a szervernek, amiben benne van, hogy <User="pistike">. Fél óráig magyaráztam, hogy bárki képes ilyen csomagot SSL-lel a szerverhez beküldeni.

:)

Még jó, hogy nem orvosnak tanult...

Miert gondolod hogy az orvosoknal nincs ilyen?

Biztos is,hogy van ilyen....

No, szép sorban reakció mindenre

Amikor ajánlott az ismerősöm a főnökének, akkor még csak annyi volt a gond vele, hogy papír fétise van. "megnyugtatnék" mindenkit, a bizonyos főnök, szó szerint azzal a kérdéssel indított. Aztán csak azért nem borítottam rá az asztalt, mer le volt csavarozva... (gondolom már volt hasonló eset.)

A fenti kódrészlet sajnos egy már késznek jelölt fájlban volt. A GET-es küldésen túl a másik "ijesztő" dolog, hogy valószínűleg az adatbázisban a jelszó tárolást is plain-text formátumban gondolta az illető. mert hogy nincs még csak egy hash függvénynek sem átadva a pass. Ezenkívül a szükséges idézőjelek is hiányoznak, mert elvileg így kéne kinéznie: pass=\'' . $... a szükséges \' nélkül simán szájba vág az SQL egy laza syntax error-ral...

Ezen kívül anno nekem azt tanították, hogy az SQL foglalt szavait illik nagy betűvel írni, még akkor is, ha kisbetűvel is lefut. Mert úgy jobban néz ki.

Annyi azért szóljon a kód mellett, hogy legalább object van függvény hívogatás helyett. de lehet csak azért, mert mások már így kezdték el...

és akkor most egy kicsit rólam. Nekem nincs diplomám, sem érettségim, csak 3 szakmám. Ez azért van így, mert anno úgy döntöttem, hogy felesleges papír helyett, inkább a tudást választom. Mára azonban odáig jutott az egész rendszer, hogy még levegővételhez is érettségi kell. Pedig attól sem lesz valakiből jobb szakember, pláne, hogy ilyen baromságot csinálnak diplomásként is...

--
openSUSE 12.2 x86_64

Bocs, hogy meg kell kérdeznem, de én vagyok a hülye. Szóval már harmadszorra mondod, hogy három szakmád van. Hogy ezen konkrétan mit kell értenem? Tényleg ne vedd sértésnek. Szakmunkásképzőben is lehet szakmát szerezni. Vagy OKJ-ra gondolsz? Vagy egyszerűen csak értesz hozzá? Komolyan nem csesztetni szeretnélek, csak hogy értsem.
Amit írtál az egyébként tényleg durva... Hasznos lenne publikálni, hogy hol mehet ki ilyen kód.

A másik, ami eszembe jutott:
Nem lehet, hogy egy hacker verseny kezdő szintjére kódolnak példa feladatokat? :-D

Ha tudod, hogy hol lehet kinn ilyen éles kód, akkor tök jókat lehet vele poénkodni...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Szakiskolában szereztem "bolti eladói" papírt, aztán még mellé OKJ-s tanfolyamokon 2 informatikusit is. PHP progger és "dizájner". Ezeken 2 vizsga volt, egy sima amit mindenképp megtehettem, illetve egy másik, amihez kell majd az érettségi. Mindegyik egyébként önálló szakmát jelent. (elvileg...) Aztán úgy döntöttem, hogy akkor legyen érettségi is, mert basszák elfogadni a papírjaim. Jelentkeztem műszaki szakközépbe ott az eladóiból 2 évet beszámítottak, így csak 2 év kell érettségihez. Most májusba meglesz felsőfokú (úgy döntöttem, hogy az...) Aztán pedig mehetek vissza az OKJ-s képzésre a második vizsgát is letenni.

Szerencsére a kód nem ment ki, csak készként jelölték. Van minőség ellenőr. Így derülhetett fény az esetre...

Kiröhöghettek, de ha tudom, hogy x oldalon van hiba, akkor sem szoktam visszaélni vele. Ignorálom, max. jelzem, hogy "papi ez így nem oké"

--
openSUSE 12.2 x86_64

Előbb hirtelen majdnem az jutott eszembe, hogy mi van ha ez egy nagyon okos ember és direkt helyezte el ezt a kódrészletet? De végül mégis úgy gondolom, hogy egy okos backdoor nem így néz ki...

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Az említett ismerősödet hamar ki fogják rúgni a cégtől, mert kiadott részleteket a forráskódból egy idegen embernek. Reméljük szerencséje lesz és a főnök nem olvassa.

Időnként nálam is elpattan a húr, de kódrészletet akkor sem adok ki.

Bocs.

Másik: mi gátol abban meg, hogy más céghez menjél dolgozni?

Harmadik: aki kezdő egyetemistára bízza a security tervezését, az meg is érdemli.

Szerintem te is megértheted miért, de Ő is azt várja, hogy mikor mehet el onnan.

A kódrészlet azért kerülhetett ki, mert az egész megy a kukába, tehát lényegtelen, hogy kilátja. Az említett 2 soron kívül egyébként semmi egyebet nem kaptam, azt sem mondta meg, hogy mire lenne ez használva.

Semmi sem gátol, nem is vagyok ott...

Kezdő egyetemista megnevezés ellenére, azért illene egy ilyen egyszerű dolgot helyesen megcsinálni... Nem nagy "securty" tudás kell ahhoz, hogy ráküldjön egy-egy real_escape_stringet a beillesztés előtt.

--
openSUSE 12.2 x86_64

Nekem villamosmérnök diplomám volt, amikor kikerültem az egyetemről. Ez fél év Pascal és fél év C programozást takart. Eme programozási karrier után túl sokat nem is vártak tőlem, teszteket írtam, utána újraírtam.

Lehet, hogy ha lenne egy elméleti türk nyelvész diplomád, a főnök is megenyhülne.

:)

Nem tudom, hogy a villamosmérnöknek miért kéne programoznia. Nem hinném, hogy az lenne a dolga egy villamosmérnöknek, hogy csapasson össze egy PHP-s valami beléptető rendszert...
Egyébként meg valami programozó diplomás ipséről van szó. többet osztán én se tudok róla.

Nem túlságosan hat meg, mert szükség esetén a megbízási szerződésekkel 2x-3x annyit lerántok róla, mint ha ott melóznék állandóra, és kevesebbet kell a baromságát hallgatni. :-D

--
openSUSE 12.2 x86_64

> Nem tudom, hogy a villamosmérnöknek miért kéne programoznia.
Fail.
> Nem hinném, hogy az lenne a dolga egy villamosmérnöknek, hogy csapasson össze egy PHP-s valami beléptető rendszert...
Ez már nem.

Villamosmérnök = hardver és/vagy szoftver

A munkáltatók az ÉS kapcsolatot jobban szeretik.

Idézet:
A Békéscsabai Járási Ügyészség vádirata szerint dr. T. Veronika békéscsabai sértett egy hirdetési újságban olvasta a vádlott hirdetését, miszerint jóslást és rontáslevételt vállal. A fiatalasszony részletekben 28 millió 130 ezer forint készpénzt adott át a vádlottnak, amelyet a vállalkozásából takarított meg.

Egyéb kérdés a diplomásokról? :)

(akit érdekel, a cikk itt)

Én kérek elnézést...

--
openSUSE 12.2 x86_64

:)
Ez kesz :)

--
http://www.micros~1

Volt nálunk próbaidőn valaki, kb. az államvizsga volt hátra neki. Annyi volt a feladata, hogy az

id;szoveg;kapcsolt1;kapcsolt2;...;kapcsoltN

formátumban érkező CSV-t

id;kapcsolt1
id;kapcsolt2
...
id;kapcsoltN

formában betúrja egy adatbázisba, annyi nehezítéssel, hogy ha már egy létezik, azt értelem szerűen figyelmen kívül kell hagyni. Ez volt szerda közepén. Csütörtökön nem voltam benn, pénteken rákérdeztem, hogy hogy áll, azt mondja nem tudja megoldani. És nem az volt a baja, hogy a keretrendszer, amiben dolgozott új volt neki, hanem magát az algoritmust képtelen volt megírni.

Azóta lediplomázott.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Wow.

Ezt meg valami rettento hatekonytalan algoritmussal is konnyu megoldani.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Ha csv-ben is elég a kimenet, akkor egy kb. 60 karakteres awk parancs elég.

Írtam mi volt a feladat: adatbázisba betolni, még a keret is meg volt hozzá (azon mutattam neki, hogy mi merre hány méter), és PHP volt a feladat.

Értem én, hogy az awk roppant hasznos meg minden, de nem lehet odapancsolni mindenhova, csak mert létezik. ("Kedvenc" érvem a text formátumok mellett a "csak mert van tool hozzá".)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

'"Kedvenc" érvem a text formátumok mellett a "csak mert van tool hozzá"'

Nem tudom, hogy ezt hogy értetted, de szerintem ez erősen valid érv. Nem véletlen része a Unix filozófiának az is, hogy minden legyen/lehessen egyszerű szöveg. És ha úgy nézed, ez valami, ami a 70-es évek óta bevált és működik a létező összes területen.

(Feladathoz meg: PHP-ban is kb. ugyanolyan könnyű stringet tokenize-olni vagy explode-olni, mint awk-ban).

Azért a minden szöveg dolognak is megvannak a maga jelentős hülyeségei/problémái - az "a" program kimenetét a "b" bemenetéhez igazítani az esetek döntő részében kell valamilyen szövegszabdaló/manipuláló cuccot használni - eklatáns példa szokott lenni az ls kimenetéből a fájl dátumának (bármelyiknek) a kezelése...

"az "a" program kimenetét a "b" bemenetéhez igazítani az esetek döntő részében kell valamilyen szövegszabdaló/manipuláló cuccot használni"

Még mindig jobb stringet manipulálni az évtizedek óta erre fejlesztett eszközökkel, mintha reverse engineeringelni és hexeditorozni kellene ugyanezért a célért (aminek az adatait és a kimenetét szintén át kell szabni a két program inkompatibilitása miatt a végén).

És mindkettő rosszabb annál, mintha -a példánál maradva- az egyes fájlok tulajdonságai (a'la stat kimenete) utaznának egy objektumként a csőben, aztán ami kell, azt ebből lehet szimplán, célzottan kimazsolázni.
A tapasztalatom az, hogy egy-egy shellscript munkájának a nagyját az teszi ki, hogy a kimenetet a bemenetnek megfelelőre mogyorózza az ember.

Igen, nyilván, de az nem mindig lehetséges.

Ismerős sztori. Kb. egy éve segítettem az egyik barátomnak a számlázója által a terméklistából generált csv-t átalakítani és feltölteni egy vonalkódos árellenőrzőre. Ott majdnem megvolt már a végén a hexeditor, mert az árellenőrzőhöz használható doksi nem volt.

Aki CSV-t explode-al dolgoz fel, az sikeres ember nem lehet. (FYI: többsoros stringek CSV-ben is többsorosak, plusz létezik ám olyan is, hogy escapelés.)

Egyébként meg itt összefoglaltam, hogy mi a bajom az egésszel: http://hup.hu/node/123916

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ha tudhato, hogy nem kap problemas bemenetet, miert ne? Amikor biztos, hogy csak ket, szamokat tartalmazo oszlop johet be, minden mas invalid input, akkor miert ne lehetne explode-t hasznalni?
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Mert aztán jön az első német által készített törtszám, ami így fog kinézni (ha szabványos CSV-ről beszélünk":

"12,34",56

Ezért. Ne hogy azt hidd, hogy nem szívtam meg egy-két csodás megörökölt rendszerben, csak mert egy hasonló mentalitású ember készítette.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Csak azért írtam példának az awk-t, mert a kérdéses probléma talán abban oldható meg a legrövidebben. :-) Nyilván a jelöltnél algoritmikus probléma (is) volt.

Egyébként meg a klasszikust idézve: "Minden nyelven lehet Fortran programot írni."

Na és milyen CSV? A több soros stringek is le vannak kezelve helyesen escapelésekkel, mindennel?

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Még mindig ezen lovagolsz? :-) De úgy valóban több egy picivel, mint kb. 60 karakter. Egyébként azért hoztam fel az awk-t, mert php-ben túl könnyű/egyszerű lenne.

Ha tudnád, hogy mennyit szívtam azzal, mire kidzsuváztam mindenhonnan az ilyen "okosban" megoldott "parsereket" (komplett blogsorozatot lehetne írni), akkor te is lovagolnál azon, mikor valaki terjeszti azt, hogy de mennyire jó, hogy CSV-t ezekkel fel lehet dolgozni. Hja, az általa elképzelt CSV-t, nem azt, amit valójában CSV-nek hívnak.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Én ezért szoktam bekérni minden ilyen problémánál legalább egy példafájlt és lehetőség szerint egy leírást, hogy egy-egy mező kb. mit tartalmaz (vagy fog tartalmazni). A korábban említett vonalkódos árellenőrzőnél például bizonyos mezőket ki kellett egészíteni adott szélességűre.

Detto, bár ahol lehet, használok XML-t. Hála istennek, az jóval szigorúbb, bár ott is vannak egyesek és sok esetben sokkal-sokkal-sokkal egyszerűbb (főleg C# alatt) XDocument-el és Linq2XML-el dolgozni, mint az egyéb szirszarokkal.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

És milyen jó is az, amikor 1234 bájt értelmes információt 23456 bájtba csomagolsz bele... :-P

Es ez kit erdekel? Nem beagyazott rendszeren kell feldolgozni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Akkor 123456kB információt 1234567kB-ba (egy nagyságrenddel többe) csomagolsz. Igen, a memória, a CPU, az i/o véges erőforrás. Az ilyen "kit érdekel..." hozzáállás terméke szerintem az a find parancs is, amivel a közelmúltban találkoztam: find . ( -name *.valami -o -name *.valamimas -o -name *.satobbi meg még vagy két tucatnyi hasonló) -mtime +123 -exec rm {} \; És csodálkozás volt, amikor felzabálta a gépet 2-3, párhuzamosan "futó" förmedvény.
Logikusnak logikus a megadott kiterjesztésű, 123 napnál régebbi fájlok törlésére, de hogy erőforrásbarátnak nem mondanám, az biztos.
De jöhetek xml-es példával: alkalmazás 1500-2000 bájtos xml-eket küldözget, amiből 100-150 bájt az értelmes adat. Lefordítva hálózati forgalomra, két csomagban megy át az az adat, ami egyben is igencsak lötyögne...

Senki nem beszelt egy nagysagrendi kulonbsegrol, ezt te huztad elo a hajanal fogva. Az XML-ben valo utaztatasrol van szo, annak pedig nincs egy nagysagrendi overheadje akkora adatfolyamnal, amirol szo van. Ketszeres? Lehet. De az meg mindig kevesnek szamit. A fenti peldanal durvan husszoros meretrol volt szo, de 23 kilobajt feldolgozasa azert meg mindig kevesnek szamit. Ha 1 es 10 giga kozotti ertekrol lenne szo, igazad lenne, igy nincs. A halozatos peldadra is ugyanez a valasz: az 1 es 2 csomag feldolgozasa kozott _nincs_ ertekelheto idobeli kulonbseg.

Egyebkentm egg a CPU meg a memoria veges eroforras, ebben igazad van, de akkor szuntessuk meg a nyiltszoveges protokollokat, es menjen minden binaris adatfolyamban, stopbit, startbit, 4 byte mezomeret, adat, stopbit, startbit, s.i.t. Baromi jo, csak valoszinuleg nem veletlenul lettek az XML-szeru szabvanyok kitalalva. Mert nem minden a CPU es a memoria.

Egyebkent pedig ez foleg eszkozfuggo is. Nekem is volt kozom manualisan irt XML parzeres szornyedvenyhez, lassab kodot talan sose lattam, ki lett cserelve standard parzerre es lecsokkent a teljesitmenyigenye ket nagysagrendet. Ha valaki szarul valasztja meg az eszozeit, az ne csodalkozzon a szar teljesitmenyen. Ez igaz a find-es peldadra is.

Probald meg mar kontextusaban ertekelni, amit irok. Megfigyeltem, hogy abbol, amit mondok, mindig valami altalanos ervenyu kinyilatkoztatast akarsz faragni, es ez altalaban messze nem igy van. En mindig arra reagalok, amit mondanak, nem pedig masra. Nem baj, csak magadnak csinalsz teljesen feleslegesen problemat.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

"Az XML-ben valo utaztatasrol van szo, annak pedig nincs egy nagysagrendi overheadje akkora adatfolyamnal, amirol szo van. Ketszeres? Lehet. De az meg mindig kevesnek szamit. "
LOL Elmesz te telleg a pics@ba.
Tobbszor konstataltam mar, hogy egy hozzanemerto kokler vagy, de azert ez mar megiscsak sok.
Ketszeres az overheadje valaminek, de ez neked kevesnek szamit?! !#234%+!"!

No meg ez is:
" A halozatos peldadra is ugyanez a valasz: az 1 es 2 csomag feldolgozasa kozott _nincs_ ertekelheto idobeli kulonbseg."
GIGALOL, ocsem, bazzeg.
Eppen ketszer annyi ideig tart, h_lyegyerek.
Ja, lehet, hogy te meg csak olyan rendszert lattal, amin ketto user van, es orankent kuldenek egy emailt, de nem csak ilyen letezik, ocsisajt.
Abba kene ezt hagynod, nagyon gaz vagy. Allandoan olyanba pofatzol bele, amihez fongod sincs, es allandoan akkora baromsagokat, hogy mindenki a fejet fogja.

lock

lockolhatod, fenntartom.

Gondoltam, csak azért jobb az ilyet nem a véletlenre bízni. ;)

Ez a lockolás az új divat? Legalább szólnál hozzá valami hasznosat! :)

Egyébként elmondanám, hogy annyiban igaza van, hogy 1 és 2 package között igenis érdemi a különbség. Ha hatszázezer user küldi el ugyanazt a 2 csomagot 1 helyett, akkor 600000 csomag helyett 12000000 csomag megy át. Akkor ez hogy is van?

Annyit tennék hozzá esetleg a dologhoz, hogy a CSV vs XML kérdésben ez pont nem az (elsődleges) szempont, mert az XML-t nem azért találták ki, hogy kisebb legyen a fájl.

Tudom, hogy igaza volt.

amugy neked ez miert is jo?

Hogy holnap is ott legyen az a komment, amin ma jól szórakoztam. :P

írjál magadnak.

this^^ GNU/Linux filozófia!
Jól megmondtad, értesz hozzá.

Zellernek +1.
______________________
this comment is cc by-nc 2.5

Majd a bXML! :)) Ó várj, az bináris... :(

Komolyra fordítva: SOAP-ban az a szép, hogy maga a koncepció jó, WSDL leír mindent, többnyire nyelvfüggetlen (használtam már PHP-Java-.NET között majdnem minden féle felosztásban) és ha nem egy okádék implementációt kell használni (PHP plz), akkor pikk-pakk megy az egész. Amit elcsesztek benne az az, hogy nem feltétlen az XML a legjobb transzport formátum (na meg a külön kedvencem, amikor SOAP-on keresztül string-ben egy XML dokumentumot küldenek.), bár ezzel egy ügyes trükkben megoldották a schema validálást is.

Egyébként maga a transzport formátum minden további nélkül le is cserélhető lenne, (azt hiszem, az MS-nek van is ilyen megoldása a WCF-ben, ahol nem XML, hanem serializált .NET objektek közlekednek) akár mehetne egy sima binárisan serializált formánál, aminél némi header infót leszámítva közel nulla overhead lenne. Alapvetően senkit nem kellene, hogy zavarjon, hisz normális, kitesztelt SOAP lib mellett totál érdektelen, hogy miben is küldi.

Az egyetlen ok, ami miatt nem lehet megtenni az az, hogy terjed a text-file fetisizmus, mert meg kell nézni kézzel. Na itt a baj, mikor ahelyett, hogy megoldanánk egy problémát, inkább a feladathoz alkalmatlan eszközökhöz igazítjuk azt.

Egyébként azon nem akarsz kiakadni, hogy a weben a képeket leszámítva HTML minden? :)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

A weben a forrásod valóban szimpla szöveges, viszont értelmes környezetben teljesen természetes dolog az átvitel során ezt tömöríteni.
Explicit "xml mert az jó" problémába úgy futottam bele, hogy a webes app monitoring adatait egy megadott url-en xml-ben adta vissza. By design egy darab oldal, 123k. Ebből kellett 2-6 darab kulcshoz kinyerni a hozzájuk kapcsolódó 1-3 számláló értékét. Ez maximum 18 darab előjel nélküli integer, ha mindhez hozzárakok 2 bájton azt, hogy micsoda, az összesen (2+4)*18=108 bájt - aminek a feldolgozása is messze egyszerűbb, mint xpath-szal matyizni. (De ha értelmes módon, karakteresen csinálom, akkor sem több, mint 2-300 bájt)

Az xml van, amire jó, de a mindenhova azt erőltetni nem jó.

En peldaul orulnek, ha a nagios kepes lenne xml-t kikopni. Egyebkent pedig megertem a masik oldalt is, az XML jo valasztas akkor, ha egy barki altal feldolgozhato kimenetet szeretnenk. Bar egyebkent a JSON most mar egyre inkabb alkalmasabb lesz az ilyesmire, mert az majdnem egy az egyben lekepezheto valami asszociativ tombre, kevesbe szoszatyar, es konyebb parzolni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

A Nagios webes trutymót köp ki, szerintem amire te gondolsz, az az agent, ami ha xml-t köp ki, akkor a szervernek kéne xml-t feldolgozni. Ez apróbb rendszereknél nem lenne probléma, de nagyobb (ezres nagyságrendű eszközpark esetén) környezetben már erőforrásigényben nem biztos, hogy vállalható.
JSON-t használ pl. a Zabbix az agent-tel való kommunikációra, ebben (is) bőven a Nagios előtt jár :)

Cserebe a zabbix felulete egy iszonyatosan tulbonyolitott valami. En legalabbis 3x ugrottam neki a konfiguralasanak, es mindig valahol feluton adtam fel, hogy ezt itt most nem. Eleve nagyon nehez az autodiscoveryt eletre lehelni benne, ha sikerul, akkor meg az ertelmes kepernyok osszerakasaval megy el temerdek ido, feleslegesen. Akkor mar inkabb egy Observium, ugyan eleg pocsek, de legalabb valami. Vagy a masik, amit meg el tudnek kepzelni, az az OpenNMS. Az tetszos.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

A monitoring, a _jó_ monitoring tervezése, kialakítása, hangolása nem "next-next-finish" kattogtatás, kiegészítve (utána) egy README.1ST elolvasásával. Sok-sok papír-ceruza munka kell hozzá, utána -ha jól csináltad- az egész üzemeltetést, statisztikázást, erőforrás-tervezést és optimalizálást rettentően meg tudja könnyíteni.
Anno 100+ gépet, meg a rajtuk futkorászó nagy rakás alkalmazást meg DB-ket monitoroztuk Zabbix használatával. Elég volt ránézni a jól összeválogatott grafikonokat tartalmazó képernyőkre, hogy tudjam, hogy érzi magát az egész motyó, hol kell majd rövid időn belül beavatkozni, van-e valamilyen para, amit kezelni kell. Nekem bejött - összetett, sok-sok dolgot tud, meg kell érteni a működés, az adatok rendszerezésének a "filozófiáját" (nagyon más, mint a Nagios és leszármazottai), akkor menni fog.

Nem next-next-finish cuccra gondoltam en sem, de azert egy monitoring rendszertol azt igenis elvarom, hogy ertelmes defaultokkal jojjon. Tenyleg olyan nagy keres, hogy minden gephez alapertelmezetten jojjon letre egy ruhes display benne a gepre vonatkozo grafikonokkal? Utana en majd csinalok magamnak sajat displayeket, de hadd lassam mar addig is, hogy mi tortenik a rendszerben. Tudom, lehet erre automatizmust csinalni, de ez annyira alap dolog - miert nem tudja alapbol? Mondjuk akar alapbol letiltottan, ha ennyire felnek tole.

En is sokat tiprodok, mire osszerakok egy monitoringot, hogy mit erdemes mit ne, de epp eleg ezeket beloni, nem kell, hogy a monitoring rendszer meg kulon szivasson is.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

miből tart azt a két-három hiányzó grafikont berakni a template-be?
ebből a szempontból is előrelépés szerintem a 2.0-s zabbix a korábbiakhoz képest, ha szabad ilyet mondanom egy szoftverre, intelligensebb lett, mint az elődei :-)
nem akarok arcoskodni, de telepítéssel együtt 1-2 óra alatt össze tudok állítani egy jól működő zabbixot, amit max. finomhangolni kell a következő 1-2 hét adatai alapján (lassan 5 éve használom, ragadt rám pár dolog...)

nekem a nagios lenne büntetés

+1.

Szerintem eltero dolgokrol beszelegetunk.

En Cacti iranybol jovok, ott tudok olyat mondani, hogy egy screenre (oke, itt faszerkezetben vannak ezek) radobok egy hostot, es annak minden ismert grafikonja megjelenik. A zabbixben nem talaltam ilyet.

Jo cucc a zabbix, es nagyon szeretnem is hasznalni, de nem ertek hozza, es a dokumentacio nem nagyon segit a homaly eloszlatasaban, nincsenek step-by-step tutorialok, hogy hogyan kell kezelni mondjuk egy haromgepes rendszert benne. Raadasul a felhasznalo felulete kivulrol nezve baromira nem intuitiv, a szovegezes pedig gyakran felrevezeto, vagy nem informativ.

Tapasztalatbol tudom, hogy aki egyszer egy ilyen cucc megtanulasat vegigszivja, annak utana furcsa az, aki most kezd hozza, hogy bizonyos dolgok miert nem nyilvanvaloak szamara. De ettol meg nekem nem lesz jobb, en jelenleg hasznalhatatlanul bonyolultnak erzem, mert nem vezeti a kezemet sem a felulet, sem a dokumentacio.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

amikor belebotlottam a zabbixba, én sem értettem, hogy ki kivel van (ez lehetett kb 6-7 éve)
le is tettem róla, mert ahol akkor dolgoztam volt egy működő nagios

aztán céget váltottam, és nyakamba varrtak egy felkonfigurált zabbixot, amit sokkal könnyebb volt megértenem, hiszen minden be volt benne állítva, egy új host felvitele max 2 percig tartott

persze ha az időm engedi, rápillantok más szoftverekre is, de eddig nem találtam megfelelőbbet/jobbat a zabbixnál

az fsf konfra jössz? esetleg megmutathatnánk egymásnak a kedvenc monitoring rendszerünket

Mikor/hol lesz? Regen voltam mar ilyen esemenyeken, jo lenne megint menni, de elore biztosat igerni nem tudok.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

-- visszavonva --

Polisor László gumisműhely vs inviteles értékesítő

[spoiler]
"Azért tök hülye nem vagyok, várjál, valamire vittem. Van érettségim. Nincsen diplomám mint neked, de nekem van érettségim"
"Nekem sincs diplomám uram"
"Nincs diplomád? Akkor mi a sípszómért hívogatsz sípszó? Legalább egy diplomával hívogassál érted. Hogy tudjunk közlekedni, meg kapcsolatot teremteni"
[/spoiler]

Klasszikus :)