Melyik barom találta ezt így ki?

 ( cus | 2019. március 16., szombat - 2:22 )

Szerintem mindenki futott már bele olyan jellegű programműködésbe, ami lehet hogy nem bug, de ettől még marhára nem intuitív, vagy olyan tervezte, akinek fingja nem volt a valódi használat által támasztott követelményekről.

Indítónak legyen itt két példa, amiért nem keveset anyáztam:

MySQL max_prepared_stmt_count globális limit

A MySQL-ben az egyidejűleg használható prepared statementek száma csak globálisan korlátozott. Így akár egy rosszul működő kliens amelyik nem szabadítja fel az általa létrehozott prepared statementeket is SQL hibákat okozhat akár más adatbázisok más sessionjeiben is.

https://dev.mysql.com/doc/refman/8.0/en/server-system-variables.html#sysvar_max_prepared_stmt_count

UDP multicast feliratkozás nem szűr interfészre

Ha multicast csomagokra szeretnél feliratkozni, a cím és port mellett ugye megadhatod a hálózati interfészt vagy akár a multicast forráscímét is. A meglepetés akkor jön, amikor annak ellenére, hogy konkrét interfészre vagy konkrét forráscímű multicastra iratkoztál fel megjelennek a socketedben csomagok más forráscímről vagy más interfészről is.

Miért? Azért mert a specifikált hálózati interfésznek vagy forráscímnek csak a feliratkozás szempontjából van jelentősége, vagyis ez csak azt mondja meg a kernelnek hogy engedje be a multicastot azon az interfészen (illetve iratkozzon fel IGMP-n).

Ha tehát egy másik processz feliratkozik ugyanarra a multicast címre egy másik interfészen akkor egyből ott is bejönnek a csomagok, és mindkét processz megkap minden csomagot bármelyik interfészen is jött az be...

https://rg3.name/201504241907.html#_relationship_between_the_multicast_address_the_port_and_the_interface_address

Hát kezdetnek ennyi, folytassátok a sort ha van hasonló élményetek :)

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ő.

MySQL-hez egy csokorra való: https://hup.hu/node/148653#comment-2007059

Meg még ez bónusznak:
Applications that use UTF-8 data but require supplementary character support should use utf8mb4 rather than utf8mb3 ... utf8 is an alias for utf8mb3; the character limit is implicit, rather than explicit in the name.
Forrás: https://dev.mysql.com/doc/refman/5.7/en/charset-unicode-utf8mb3.html

Szerencsére egy ideje már nem dolgozom MySQL-lel így a listám bővülése lelassult. :)

off: bocs, nem értem, mi is a gond az utf8mb3-mal?

Nincs benne emoji support :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ez mondjuk igaz. De igazából azt a kontextust nem értem, amivel a kolléga ezt leírta, mintha ebben valamiféle szembeszökő hiba lenne, amit nem is kell megmagyarázni. Talán az a gond, hogy egy részhalmaz (BMP) hogy merészeli azt, hogy kevesebb eleme legyen, mint a teljes halmaznak (BMP+SMP)?

Nem a részhalmaz a probléma, hanem az "utf8 is an alias for utf8mb3;"

Amúgy meg a témához, JavaScript? Most olvasok egy könyvet továbbképzés gyanánt és néha ökölbe szorul a kezem.

"Nem a részhalmaz a probléma, hanem az "utf8 is an alias for utf8mb3;""

+1 :)

JavaScripthez kapcsolódóan, nyilván vannak hülyeségei, mint minden más nyelvnek. De sok esetben a nyelv rossz ismerete okozza a problémát és a hibásnak gondolt viselkedés valójában teljesen logikus, csak más, mint más nyelveken.

Ja, hát az történelmileg így alakult. Ez nem olyan, mint a hobbyprogramozás, ahol tök oké kirántani a szőnyeget egymás alól, itt a már meglévő neveket nem lehet átdefiniálni, csak újakat bevezetni. (Egyébként lehet, hogy az utf8mb3 tudja a CESU8-at is, ki kellene próbálni.)

az a baj, hogy az 'utf8' valojaban nem utf8-at hanem annak egy subsetjet jelenti mysql-ben. lattam mar jira-t fejreallni attol, hogy valaki egy olyan karaktert irt egy hibajegybe ami nem fert bele a mysql utf8-aba...

Google cloud java sdk, azt hiszem bigquery. Kis túlzással minden évben behoznak valami nagy breaking changet, ezért a statementen be kell állítani, hogy legacy vagy új legyen. Updatelnem kellett más projectjét, persze migration guideban csak a legalapabb példák vannak. Már önmagában szép menet volt, de amin órákat anyáztam az az, hogy - követve a meglévő mintát - a query stringet a végén kapta meg, előtte kapcsolókat állítottunk method chaininggel. Na valamiért a query string beállítás a korábban beállított kapcsolók közül az új sdk-ban felülírt defaulttal. Nem, nem az objectben voltak default értékek, hanem úgy gondolta, hogy ő ott nekiáll sideeffectezni, és átállít dolgokat. Persze se a metódus neve nem utalt erre, se dokumentálva nem volt, 5 hívás mélyen kellett a borzalmas minőségű kódjukban kibogarászni. Az már csak apró adalék, hogy a query első sorában elvárják, hogy ott legyen a #verzió, de külön is be kell adni az apinak, mert miért ne

well, it's a bad idea to have it designed that way then, isn't it? https://youtu.be/Fe-Zeg6cjz0

Something something random oracle application

pythonban az stdin/stdout (es a file i/o is valamennyire) kodlap (us-ascii/utf8/iso8859) kezelese. szerintem senki se tudja hogy mukodik, eleg kiszamithatatlan, es python verziotol, LANG envvartol stb is fugg.

a masik pythonos kedvencem, hogy a binaris file olvasas 2.x-ben stringet, a 3.x-ben byte array-t eredmenyez. de ilyet mondjuk a mysql is tudott, valamikor regen egy alverzional megvaltozott, hogy a BLOB olvasas eredmenye tobbe nem string hanem byte array lett (nem szerver oldalon, hanem az odbc driverben).

Ez a kis prezentáció kötelező darab a témában :)