BGAFC Vendégkönyv

Σ: 1 post

TCH (statz)

#1, Főfasz (10443)

12974 | #1c5c | ^ | Idézet | Mon, 07 May 2012 00:31:24 +02

46.107.*.*

*.catv.pool.telekom.hu

djpety írta/wrote:
Chuck Norris végigvitte a Máriót... balra.

Jézus jár a vizen, Chuck Norris úszik a szárazföldön. :)

saxus írta/wrote:
A ganyolok nem ugy lesznek. A ganyolok ugy "lesznek", hogy az egyebkent total leszarom hozzaallasu billentyuzetet csapkodo majmot beultetik kodot lapatolni mindenfele osszebaszott, struktura nelkuli, atgondolatlan, barmifele tervezest es tudatossagot nelkulozo, try-and-error modszerrel keszult spagetti kodot anelkul, hogy tudna mit csinal. Ebbe beletartozik az is, hogy tudja, hogy a fordito/VM/interpreter mit muvel(het) azzal, ami kodot osszelapatol. (es most mindegy, hogy statikus, JITter vagy nativ kodrol/JVM/CLR/PHP interpreterrol).

Ez igaz, de azért tegyük hozzá, hogy az általad említett total leszarom hozzaallasu billentyuzetet csapkodo majmok nem C-ben, Delphiben vagy ASM-ben nyomják, hanem dzsuvában vagy cisztában/vizuálbuzikban/egyébfosnetes nyelvben. :P

saxus írta/wrote:
Es egyebkent igen hamarabb biznam ra az optimalizalast egy -O2 -re barmely random C fordito eseten, minthogy kezzel nekialljak minden mikroarchitekturara leoptimalizalni *HA NEM MUSZAJ*.

Ácsi, itt most nem arról beszélek, hogy az adott algoritmus gépi kódú implementációjának az optimalizációját bíznád rá, hanem magának az algoritmusnak a kioptimalizásáról. Értsd: az nem optimalizáció, hogy itt is, meg ott is megspórolok egy órajelet; az az optimalizáció, hogy a feladatra ír az ember egy hatékonyabb algoritmust. A fordító csak az elsőt tudja nyújtani pl. adott architektúrán van bizonyos összetettebb műveletekre is utasítás és azt használja ahelyett, hogy a BIS-ben található parancsokkal valósítaná meg.

saxus írta/wrote:
Mert amikor valamivel dolgozni akarok, nem mindenfele low level optimalizaciot akarom fejben tartani (valoszinuleg soha az eletben nem lennek kepes az osszeset fejben tartani. Szerintem az Intelnel sincs mar olyan ember, aki mindent tudna, egyszeruen tul komplexek es tul sokretuek ahhoz a mai rendszereink).

Ez igaz, de nem is kell egyszerre mindet fejben tartani, csak azt amin épp dolgozol, továbbá alapvetően olyan kódot kell írni, ami CPU szemszögből "ehetőbb".

saxus írta/wrote:
De ez olyan, hogy most minek talaljam fel a spanyol viaszt es irjam meg mondjuk ujra egy Stack<T> osztalyt? Megirtak egyszer, ki is optimalizaltak azokat, en minek irjam meg minden egyes alkalommal ujra es ujra es ujra?

Ebben is van igazság, de sajnos vannak olyan technológiák, amik annyira fosok, hogy jobb kikerülni őket és saját implementációt írni.

saxus írta/wrote:
Azert van a gep es azert vannak a szoftverek, hogy a mi eletunket konnyitsek meg. Egy fordito miert ne konnyitse meg a fejleszto eletet? Elvegre is, azert van, nem?

Ez enyhén csúsztatás; mi nem a komfort, vagy nem az intelligens cuccok ellen ágálunk, hanem a hülyebiztosítottak ellen! Nem az a baj, ha egy környezet sokat tud, hanem az a baj, ha azt hiszi, hogy többet tud a használójánál és ennek megfelelően olyan dolgokat tesz, amit nem kértem. Egy gép (program) ne cselekedjen önhatalmúlag. Magasról, vastagon, folyékonyan és jó nagy ívben leszarom, hogy vannak emberek akik ezek a hülyebiztosítások hiánya esetén katasztrófákat okoznának és ezért pakolják bele ezt a sok túlintelligens, "mindenre" felkészített védelmi mechanizmust, hogyha a hülye programozó ezt vagy azt nem csinál meg, akkor megcsinálja a program. Csakhogy én az ilyen emberek esetén nem a hülyebiztosítást választanám, hanem a balfaszok elhajtását; hiszen egyáltalán: mi a fasznak engedték őket egyáltalán gépközelbe?! Most mutogathatnék megint bilgécre, de megint csak azt mondanád, hogy már unalmas...

saxus írta/wrote:
Maximalisan egyet tudok erteni ezzel a kijelentesseddel.

Remélem ez nem szarkazmus volt, örülnék, ha végre egyetértenénk valamiben. :P

saxus írta/wrote:
(Egyebkent nagy osszegben mernek fogadni, hogy
- vagy valami eltero nyelvi beallitas lesz a hatterben
- vagy valami felesleges whitespace karakter (miez bazdmeg, python, hogy ezen hisztizzen?)

Nem tudom, lehet, hogy igazad van, de már leadtuk a projektet, így nem tudom kipróbálni. A problémáink túlnyomó részére hipergusztustalan workaroundokat voltunk kénytelenek tákolni Mcloaddal. Felsorolom mitől hullott ki a hajunk. De mielőtt kiröhögnél, most toltuk először szarákülben és meg is mondtuk a főnöknek, hogy kurwa nagy rizikót vállal azzal, hogy a mélyvízbe dob minket.

De lássuk a kecskét.

• fetch_assoc uppercase.
Mivel az elején nem volt szarákülös gép, addig elkezdtük MySQL-ben és gondoltuk majd átkonvertáljuk utána a táblákat meg a kódot is, ha összerakta a rendszergazda a szarákülös gépet. Aztán a legelső probléma amibe belefutottunk, hogy a szarákül fetch_assoc esetén a field neveket csupa nagybetűvel adja vissza! Ezt mégis ki a faszom kérte! És ha már caseconvert, akkor legalább miért nem lower?! Hogy az ember taposhassa a capslockot vagy a shiftet, ha mezőnevet használ?! Írhattuk át a mezőneveket mindenütt a PHP kódban! (Egy array_keys_to_lowercase func nem játszott, így is egy csomó CPU zabáló fasság került bele.)

• Nincs integer adattípus.
Ez igazából gondot nem okozott, csak egy fészpalmot, hogy miért kell nekem egy 8 bites integert kötelező jelleggel 128 jegy pontosságú lebegőpontoson (~160-192 bit) ábrázolni. Persze már megint hazudok, mert igenis van integer szarákülben...tárolt eljáráson belül, szarákül powa, yeah! Illetve ha a NUMBER típusnak nem adok skálát, csak precíziót, akkor elvileg integer a számunk, gyakorlatilag viszont a tárolás ugyanúgy nem.

• LIMIT vagy ekvivalens parancs hiánya.
Én értem, hogy ez nincs benne az SQL szabványban, de sajnos a szabvány írói is kifelejthetnek dolgokat, nem tilos a szabványok tetején saját kiterjesztéseket alkalmazni. LIMIT nélkül iszonyatos SQL-ben programozni, nézzétek meg ezt a "lapozó" kódot (http://stackoverflow.com/questions/241622/paging-with-oracle):

SELECT * FROM
(
    SELECT a.*, rownum r__
    FROM
    (
        SELECT * FROM ORDERS WHERE CustomerID LIKE 'A%'
        ORDER BY OrderDate DESC, ShippingDate DESC
    ) a
    WHERE rownum < ((pageNumber * pageSize) + 1 )
)
WHERE r__ >= (((pageNumber-1) * pageSize) + 1)

Miért?! MySQL-ben, SQLite-ban és PostgreSQL-ben ez:

LIMIT pageNumber * pageSize, pageSize

Vagy:

LIMIT pageSize OFFSET pageNumber * pageSize

Hát nem igaz, hogy a szarákül fejlesztői ennyire nem jönnek erre rá! WTF?!

• Autoincrement bajok.
Oké én értem, hogy a MySQL ainc az nem szabványos és szekvenciák vannak rá, ezzel semmi baj sincsen, most próbálgatom a PgSQL-t és abban fasza is. De itt csak a szopás volt. Pl. példában írták, hogy a megfelelő mezőnél

sequence.nextval()

és csá. Oké, mondom legyen így.

ora-02287: sequence number not allowed here

WTF?! Ask Google. Oké nem használhatok sequence-t selectben, group by-ban, distinct kapcsolatban, stb. stb. de bazdmeg én egy kibaszott INSERT parancsot akarok futtatni! Erre sem találtam választ.

• CLOB sorozat.
Szarákülben nincsenek TEXT típusok és a VARCHAR2 is max 4000 karakter lehet, vagyis hosszú szövegeket tárolni benne nem lehet. Vagy mégis? Hát persze, hogy de, hiszen erre való a CLOB! Vagy mégsem?

• CLOB #1.
A CLOB PHP-ban nem stringként jön vissza, hanem objektumként, amit loaddal kell betölteni. Überfasza volt, hogy a tömbökkel operáló db függvényeinkben mindenütt rakhattunk bele egy foreach-et, ami fetch_assoc/fetch_row után véigigment a tömbön és

if (is_object($row[$key]))
{
	$row[$key] = $row[$key]->load();
}

Fájna, ha egy szaros string stream lenne, mint MySQL-ben vagy PgSQL-ben? Nagyon fájna?

• CLOB #2.
A CLOB-ban nem lehet keresni LIKE paranccsal! (?!) Felejtsd el az oldal tetején lévő keresőmezőt, vagy írd meg PHP-ban foreach-el az id kigyűjtést! 10 tartalmi oldal esetén még oké, de 10000 esetén mi lesz?

• CLOB #3.
A CLOB-ot nem lehet JOIN-olni!!! (?!!!) Vagyis, ha a nyelvi adatok külön táblában vannak, ahonnan JOIN by lang_id and by primary_table_id, akkor bármi ami 4000-nél hosszabb (vagyis must be in CLOB) az nem kérhető le, vagyis ami minden tisztességes nyelvben egyetlen JOIN-os SQL kérés és voila, azt itt lehet mezőnként plusz subselectekkel, vagy újfennt PHP-s taknyo... workarounddal!

• CLOB #4.
A CLOB 8 TeraByte adatot tud tárolni. Ez egyszerűen lenyűgöző. Tényleg. Képes a legnagyobb ma létező winyó kapacitásának kétszeresét is eltárolni. Zzzigen. VISZONT ADATOT BELETÖLTENI EGYSZERRE MAX. CSAK 4000 KARAKTERT LEHET!!! KHÚÚÚÚÚÚÚÚÚÚRWAAAANYÁÁÁÁÁÁÁÁÁD!!!!!!!! Én azt hittem, ott helyben kettéfejelem az asztalt! Ilyen nincs bazdmeg! Egy ultragány workaround volt helyette, amit csak INSERT után lehetett futtatni; az ember beszúrta a sort mint egy normális DB nyelvben - csak üresen hagyta a CLOB mezőt. Utána lefutott egy ciklus ami annyiszor UPDATE, ahányszor 4000 karakter volt a beszúrandó adat... Kb. ez:

function store_text_in_CLOB($table, $field, $text, $idn, $idv)
{
	$l = strlen($text);
	for ($i = 0; $i < $l; $i += 4000)
	{
		query("UPDATE $table SET $field = $field || '".substr($text, $i, 4000)."' WHERE $idn = '$idv'");
	}
}

• CLOB Σ.
Persze mindez csak szemét csúsztatás, hiszen minek kellene ilyen fasságokkal foglalkozni, kit érdekel, hogy ezek nincsenek se PgSQL-ben, se MySQL-ben, se SQLite-ban; hiszen itt vannak nekünk a tárolt eljárások! A tárolt eljárások segítségével kedves programozó, írhatsz Te is iszonyatosan bonyolult és konvulens lekérési eljárásokat, miknek segítségével a CLOB-ot 4000 byte méretű darabonként VARCHAR2-be konvertálhatod...egészen 32000 byte méretig bezárólag!
http://oscomp.hu/depot/uristen_bazmeg.jpg
Most inkább nem kísérleteznék azzal, hogy olyan SQL eljárásokat írok, ami többszörösen egymásba ágyazott subselectek végtelen sorozatával és konkatenációk egész hadseregével lehetővé teszi azt, hogy helyettesítsem a LIKE vagy a JOIN parancsot, inkább beismerem, hogy nem tudok ilyet, nem megy ez nekem, leülök elégtelennel és elmegyek kapálni...vagy használok PgSQL-t, vagy MySQL-t, a szarákül meg szopjon le!

• Karakterkódolás és entitások.
Hogy a karakterkódolást képtelenek voltunk beállítani és mindig hieroglifák jöttek vissza az ékezetek helyén az egy dolog. Viszont mivel ezt nem sikerült szolválni, így workaround gyanánt HTML entitássá alakítottuk az ékezeteket és úgy tettük be a DB-be. Viszont lekéréskor ezek egyszerűen átalakultak ékezet nélküli karakterré! Úgyhogy kénytelenek voltunk HTML entitás helyett befelemenetelkor saját "entitássá" alakítani (pl. ó = __o__, ö = _*o*_, ő = **o**) és kifelemenetelkor meg vissza. Fuck yeah!

• Tisztességes kezelőfelület hiánya.
Többet is nyomtak a neten. Mind fos volt. A szarákül sajátja pláne.
Szerencsére az Adminer nevű univerzális SQL csodatool a segítségünkre sietett. Jakub Vrana Bůh vám žehnej! És a lófasszopó büdös kurwa anyja szarszeplős picsáját a szarákülnek.

• Rejtélyes csakazértseműködök megdöglések.
Amik aztán vagy meggyógyultak, vagy nem, vagy kódátíráskor tűntek el. Had no idea, de amit írtál - hogy még a whitespace-eken is beszarik ez a hulladék foskupac - nem jutott az eszünkbe, szóval lehet, hogy fején találtad a szarva közt a tőgyit.

• Értelmetlen és értéktelen hibaüzenetek.
Pl.: tábla létrehozásakor bármit írunk be DEFAULT kulcsszó elé, akkor ORA-00907: missing right parenthesis. Miféle zárójel, a kurwa anyád?

• Nincs üres stringre lehetőség. (!!!)
Ez a balfasz "adatbázismotor" nem tud üres stringet kezelni, hanem NULL-t használ helyette, amivel nem lehet komparálni. Szopjál paraszt, mire rájössz.

(Utólag még két röhejentry-t hozzáadtam.)

Hát ennyit tudtam összeszedni emlékezetből. Én nem tagadom, hogy első próbálkozás lévén kurwa sokat összebénáztunk és lehet, hogy az itt felsorolt fasságokra van épeszű megoldás is, de csak a guglira támaszkodhattunk. De azért azt leszögezném, hogy a MySQL-el sosem voltak ilyen gondjaink és most nekem a PgSQL-al való ismerkedés közben is csak pozitív tapasztalataim vannak, a szarákült meg csak szapulni tudom.

U.I.: Mcload szerint ilyen fost véletlenül nem, csak szándékosan lehet írni, ezt készakarva basszák így el, hogy az alapfunkciók hiányát pótló, kötelező jelleggel megírandó tárolt eljárások mennyisége és komplexsége elrettentsen mindenkit attól, hogy bepróbálkozzanak vele és inkább megvegyék az überdrága, seggkinyaló fejlesztőeszközöket...