Banter bloguje

Silné stránky programátorů

Wed, 18 Mar 2026 00:00:00 +0000

Miloš Čermák přišel s trefným shrnutím: „AI je dnes v podstatě tři věci najednou: obtěžující, znepokojující a fascinující.“ I bez toho jsem již dřívě uvažoval, čím bych se živil, kdybych zrovna nebyl programátorem. Pokusím se co nejméně plivat síru na AI a najít důvody, jak bych mohl obstát.

Kdysi jsem napsal pro Heroine článek o kroužku programování, jako titulek si vybrali: „U budoucích ajťáků je nejdůležitější touha nespokojit se s prvním řešením.“
Ano, mimo jiné, ale kdybych měl jmenovat superschopnosti programátorů, co by to asi bylo?

Psaní kódu versus řešení problémů

Nejsme placení za psaní kódu (i když nás to baví), ale za řešení problémů. Hned mi vytane scéna z Pulp Fiction: „Jsem pan Wolf, řeším problémy.“

Pokud jste si mysleli, že vaším problémem je rychlost psaní kódu, máte mnohem větší starosti.

Analytická mysl

Klademe otázky, na které nikoho jiného nenapadlo se zeptat, a rozbíjíme špatná zadání.

Aby bylo možné nahradit programátory roboty, budou muset zákazníci přesně popsat, co chtějí.

Martin Fowler a jeho kolegové se zamýšleli nad strojovou migrací COBOLu

Přímý překlad by v nejlepším případě věrně zachytil stávající architektonická omezení, nahromaděné technické dluhy a zastaralá projektová rozhodnutí. Neřešil by slabá místa; pouze by je převedl do jiného jazyka.

…

V praxi modernizace málokdy spočívá v zachování minulosti v nové syntaxi.

Hravost a odvaha

Richard Stallman se zamýšlí nad původním významem slova Hacking.

Je obtížné napsat jednoduchou definici něčeho tak rozmanitého jako je hacking, ale myslím si, že společným znakem těchto aktivit je hravost, chytrost a objevování. Hacking tedy znamená zkoumání hranic možného v duchu hravé chytrosti.

Programátoři jsou podle mě troufalí až drzí, ve stylu Pipi Dlouhá punčocha: „To jsem ještě nikdy nedělala, to mi určitě půjde!“ Naučit se nový framework, opravit myčku, debuggovat kotel či postavit dům svépomocí? Pusťte mě k tomu!

Myšlení

Budu citovat Frantu Řezáče:

Umět programovat znamená ve své podstatě umět myslet. Kdo to neumí sám, toho LLM nezachrání.

Post by @calavera@witter.cz

View on Mastodon

A mě baví myslet.

Zodpovědnost

Programátoři jsou za svoji práci zodpovědní. AI agenti zlevňují výstupy. Nezlevňují však odpovědnost.

Závěr

Tento výčet superschopností programátorů jistě nebude kompletní. Věřím, že bychom je uplatnili i jinde, kdyby nás náhodou nahradily stroje.

Související

Zastav Lego Pybricks na čáře

Sat, 24 Jan 2026 00:00:00 +0000

Stejně jako minulý rok se i letos zúčastníme soutěže FIRST Lego League Challenge. Tentokrát už jsme si vyzkoušeli Pybricks. Nečekejte ode mě shrnutí nebo nějakou recenzi, ale děti se mě zeptaly na jednu úlohu, kterou jsem v tom mumraji neodbavil okamžitou radou na místě. Takže si plním za domácí úkol. Jak zastavit Lego robota na černé čáře pomocí Pybricks?

Pybricks

Již loni se nám Pybricks dostal do hledáčku, že bychom tím nahradili prostředí Lego Spike. Má nějaké zajímavé API jako například udržení rovného směru pomocí gyroskopu. Varianta s Python kódem je zdarma, ale tím děti zatím trápit nechci. Umožňuje používat i grafické bloky, na které jsou zvyklé, bohužel mi licence nepřijde zrovna levná. I když použijete bloky, projekt si vyexportujete do Pythonu, což může v učení pomoci.

Zastavení

Úloha „zastav se na čáře“ je velmi praktická. Ostatně na herní plánu je několik čar, které můžete (ale nemusíte) k orientaci využít. Lego má barevný senzor a k němu existuje Pybricks API.

Neuvědomil jsem si, že přesnost měření barvy bude záviset na okolním osvětlení a při použití hodnoty odrazivosti nebude černá nikdy nula (přece jen něco odrazí). Chvilku jsem debugoval, jaké hodnoty naměřím na různých površích. Nakonec jsem pro sebe použil hodnotu 20 (20 % odrazivosti).

A pak už se k výslednému programu dostaneme poměrně přímočaře. V blocích to může vypadat takto.

V Pythonu takto.

# pybricks blocks file:{"blocks":{"languageVersion":0,"blocks":[{"type":"blockGlobalSetup","id":"bjK,wS1MYO7aiYkFSwd{","x":4,"y":51,"deletable":false,"next":{"block":{"type":"variables_set_prime_hub","id":"{)WuTTGMSJwLS.H*~PKI","extraState":{"optionLevel":1},"fields":{"VAR":{"id":"0ac8)M*M0@okqL6j*T]k"}},"inputs":{"AXIS_TOP":{"shadow":{"type":"blockParametersAxis","id":"G~~=qPiIM)z4Qy;ugq.J","fields":{"VALUE":"z"}}},"AXIS_FRONT":{"shadow":{"type":"blockParametersAxis","id":"=O,F=r_j:y!5C6~`*A2D","fields":{"VALUE":"y"}}}},"next":{"block":{"type":"variables_set_motor","id":"S?(a.C=~LVoJ~3YRo;}.","fields":{"VAR":{"id":"9-KY1{EjNJxUixuEoYJ?"}},"inputs":{"PORT":{"shadow":{"type":"blockParametersPort","id":"pE~{$Zwzpz`i_VDqm^ab","fields":{"NAME":"A"}}},"POSITIVE_DIRECTION":{"shadow":{"type":"blockParametersDirection","id":"VrW-zLpmx[j,+8v+,L[1","fields":{"SELECTION":"Direction.COUNTERCLOCKWISE"}}}},"next":{"block":{"type":"variables_set_motor","id":"3,Y?*Mn1@v9fJ`yYW6Sf","fields":{"VAR":{"id":"@(Mc?VKF9P+IVA!,)0R;"}},"inputs":{"PORT":{"shadow":{"type":"blockParametersPort","id":"r`9bbROX1dwatV7O$.:`","fields":{"NAME":"E"}}},"POSITIVE_DIRECTION":{"shadow":{"type":"blockParametersDirection","id":"Fk;M%s,~BY}0ww1j30bP","fields":{"SELECTION":"Direction.CLOCKWISE"}}}},"next":{"block":{"type":"variables_set_motor","id":"^b]cQj|TmdV%cZJhl0gI","fields":{"VAR":{"id":"#~*U;Y3)}OaA),GbQ/cW"}},"inputs":{"PORT":{"shadow":{"type":"blockParametersPort","id":"?.^x_gX%wU.Xv.#3wRPP","fields":{"NAME":"D"}}},"POSITIVE_DIRECTION":{"shadow":{"type":"blockParametersDirection","id":"0Np/F+n#MjwgBk{6MrPK","fields":{"SELECTION":"Direction.CLOCKWISE"}}}},"next":{"block":{"type":"variables_set_motor","id":"I#`Wxj%/1]|h{X+ZQ;3Y","fields":{"VAR":{"id":"xE_y9@2/n%+##W#h*hFj"}},"inputs":{"PORT":{"shadow":{"type":"blockParametersPort","id":"j1eKhU`bdoHdh)~]Hl2b","fields":{"NAME":"C"}}},"POSITIVE_DIRECTION":{"shadow":{"type":"blockParametersDirection","id":"|$c/*_TuT!~8{cQFN{[f","fields":{"SELECTION":"Direction.CLOCKWISE"}}}},"next":{"block":{"type":"variables_set_drive_base","id":"B@6q{(N{H$OlQN@o(=#7","fields":{"VAR":{"id":"/@.Q%T4BjtqKCq7$UAbr"}},"inputs":{"VAR":{"shadow":{"type":"variables_get_motor_device","id":"h-`^(Zu#NTvZ*mW#2vcD","fields":{"VAR":{"id":"9-KY1{EjNJxUixuEoYJ?","name":"kolo leve","type":"Motor"}}}},"VAR2":{"shadow":{"type":"variables_get_motor_device","id":"CD5,af-R[yO,bE]-?Uf_","fields":{"VAR":{"id":"@(Mc?VKF9P+IVA!,)0R;","name":"kolo prave","type":"Motor"}}}},"VALUE0":{"shadow":{"type":"unit_distance","id":"GNgo@U(M|24Obsy~%4x{","fields":{"VALUE0":88}}},"VALUE1":{"shadow":{"type":"unit_distance","id":"cIT+~l^nylC1%}(,bsKB","fields":{"VALUE0":144}}}},"next":{"block":{"type":"variables_set_color_sensor","id":"0]Gny{r@pu-me0u.qL+H","extraState":{"optionLevel":0},"fields":{"VAR":{"id":"4q7cl%:FR{.%!.~b;=4j"}},"inputs":{"PORT":{"shadow":{"type":"blockParametersPort","id":"HrOt9)|o*,]VPV8SDZ9E","fields":{"NAME":"B"}}}},"next":{"block":{"type":"variables_set_color_sensor","id":"x.AGwFp0|}^R*%F(%TcG","extraState":{"optionLevel":0},"fields":{"VAR":{"id":"^z-R_D5t#~Oky5)7@fjS"}},"inputs":{"PORT":{"shadow":{"type":"blockParametersPort","id":"I!+TlWLqzTDYY6^$uKdf","fields":{"NAME":"F"}}}}}}}}}}}}}}}}}}}}},{"type":"blockGlobalStart","id":"3tJe|AWl0baN(wH9a$@.","x":990,"y":44,"deletable":false,"next":{"block":{"type":"blockDriveBaseUseGyro","id":"W=Lm:RpeA}v?nKUf*^6.","fields":{"METHOD":"DRIVEBASE_USE_GYRO_TRUE"},"inputs":{"VAR":{"shadow":{"type":"variables_get_drive_base_device","id":"i{6(E*p~D3tY|M-^UtvG","fields":{"VAR":{"id":"/@.Q%T4BjtqKCq7$UAbr","name":"drive base","type":"DriveBase"}}}}},"next":{"block":{"type":"blockDriveBaseConfigure","id":"g3I/xPp1/oeRSee5-LA^","extraState":{"optionLevel":1},"fields":{"METHOD":"DRIVEBASE_STRAIGHT_SPEED"},"inputs":{"VAR":{"shadow":{"type":"variables_get_drive_base_device","id":"Z+6V|uC*Z3_Z4Pd$0di/","fields":{"VAR":{"id":"/@.Q%T4BjtqKCq7$UAbr","name":"drive base","type":"DriveBase"}}}},"ARG0":{"shadow":{"type":"unit_speed","id":"oc%m!QtUlj%nS}0wUkdH","fields":{"VALUE0":500}}}},"next":{"block":{"type":"blockFlowWhile","id":"^w![3wsmge-,nl%)9)_2","fields":{"MODE":"WHILE"},"inputs":{"BOOL":{"shadow":{"type":"blockLogicTrue","id":"|%RuaCQaVxPi_*BB*Hea"},"block":{"type":"blockLogicCompare","id":"0-l;i-(OX+f@B$[%Nv?7","fields":{"OP1":"GT"},"inputs":{"A":{"shadow":{"type":"blockMathNumber","id":"0R9k4vfG#^mUZ#xuV!Yy","fields":{"NUM":3}},"block":{"type":"blockLightReflection","id":"xPaTrirocgrfw:z($hfN","inputs":{"VAR":{"shadow":{"type":"variables_get_light_intensity_device","id":"DOR_9uhk=S}7mpH~6ny:","fields":{"VAR":{"id":"4q7cl%:FR{.%!.~b;=4j","name":"senzor levy","type":"ColorSensor"}}}}}}},"B":{"shadow":{"type":"blockMathNumber","id":"=Fis}(OW{eVsQ%GL+Xv?","fields":{"NUM":20}}}}}},"DO":{"block":{"type":"blockDriveBaseDrive2","id":"e!qh#u{yRC]5T}d88!wD","extraState":{"optionLevel":2},"fields":{"METHOD":"DRIVEBASE_DRIVE_STRAIGHT"},"inputs":{"VAR":{"shadow":{"type":"variables_get_drive_base_device","id":"Fn3J0txHNG:z99+vK!pI","fields":{"VAR":{"id":"/@.Q%T4BjtqKCq7$UAbr","name":"drive base","type":"DriveBase"}}}},"ARG0":{"shadow":{"type":"unit_distance","id":"Zf;zZ*m@T_Mm5%_U]r.u","fields":{"VALUE0":50}}},"ARG1":{"shadow":{"type":"parameters_stop_4","id":"m4%XtpLADnb=l]x@*bmt","fields":{"VALUE":"Stop.NONE"}}}}}}},"next":{"block":{"type":"blockDriveBaseStop","id":"FQcgVD9TN#4W;ib{Q}Dj","inputs":{"VAR":{"shadow":{"type":"variables_get_drive_base_device","id":"sJ%~bnFg:!9s?/VX*/M(","fields":{"VAR":{"id":"/@.Q%T4BjtqKCq7$UAbr","name":"drive base","type":"DriveBase"}}}},"VALUE0":{"shadow":{"type":"parameters_stop_3","id":"ELOu@BWpK(Ie4(+d)AL_","fields":{"VALUE":"Stop.HOLD"}}}}}}}}}}}}}]},"variables":[{"name":"red","id":"^TRnlnrf1|b]54?=RSAE","type":"ColorDef"},{"name":"orange","id":"T/Ga=6s={mOa/4,vyj]{","type":"ColorDef"},{"name":"yellow","id":"z6p)=?w#+g|y@lU:VFt*","type":"ColorDef"},{"name":"green","id":"PQR$ys-f%#*T_4`Rx0fH","type":"ColorDef"},{"name":"cyan","id":"n3GEOv6@N!|xg_x}=GL+","type":"ColorDef"},{"name":"blue","id":"G_|mnBi;ov8st$C/z;$W","type":"ColorDef"},{"name":"violet","id":"MMX}YsyH/D)kVHpH2a/t","type":"ColorDef"},{"name":"magenta","id":"@4TT%Ad^Qyn!IQ9HhF{H","type":"ColorDef"},{"name":"white","id":"Yknl*y[~$s;/3RGi{ju1","type":"ColorDef"},{"name":"none","id":"e|_}L8nQoa5[!)|??9+L","type":"ColorDef"},{"name":"prime hub","id":"0ac8)M*M0@okqL6j*T]k","type":"PrimeHub"},{"name":"drive base","id":"/@.Q%T4BjtqKCq7$UAbr","type":"DriveBase"},{"name":"kolo leve","id":"9-KY1{EjNJxUixuEoYJ?","type":"Motor"},{"name":"kolo prave","id":"@(Mc?VKF9P+IVA!,)0R;","type":"Motor"},{"name":"motor predni","id":"#~*U;Y3)}OaA),GbQ/cW","type":"Motor"},{"name":"motor zadni","id":"xE_y9@2/n%+##W#h*hFj","type":"Motor"},{"name":"motor","id":"4f^oLh]vR?;f9cEyqLvm","type":"Motor"},{"name":"senzor levy","id":"4q7cl%:FR{.%!.~b;=4j","type":"ColorSensor"},{"name":"senzor pravy","id":"^z-R_D5t#~Oky5)7@fjS","type":"ColorSensor"},{"name":"sensor","id":"-BWH)YE(r`_KzM)7#.kx","type":"ColorSensor"}],"info":{"type":"pybricks","version":"1.3.2"}} from pybricks.hubs import PrimeHub from pybricks.parameters import Axis, Direction, Port, Stop from pybricks.pupdevices import ColorSensor, Motor from pybricks.robotics import DriveBase # Set up all devices. prime_hub = PrimeHub(top_side=Axis.Z, front_side=Axis.Y) senzor_levy = ColorSensor(Port.B) senzor_pravy = ColorSensor(Port.F) kolo_leve = Motor(Port.A, Direction.COUNTERCLOCKWISE) kolo_prave = Motor(Port.E, Direction.CLOCKWISE) motor_predni = Motor(Port.D, Direction.CLOCKWISE) motor_zadni = Motor(Port.C, Direction.CLOCKWISE) drive_base = DriveBase(kolo_leve, kolo_prave, 88, 144) # The main program starts here. drive_base.use_gyro(True) drive_base.settings(straight_speed=500) while senzor_levy.reflection() > 20: drive_base.straight(50, then=Stop.NONE) drive_base.straight(0)

Všimněte si, že bloku pohybu lze v then nastavit, co dělat na konci bloku, což ovlivní, jak (ne)plynule pojede. Stejně tak na konci nastavuji způsob zastavení.

Závěr

Pybricks nabízí pokročilejší funkce oproti Lego Spike prostředí. Varianta psaní v Pythonu je zdarma, za grafické bloky si připlatíte. Spouštění programů ve fyzickém světě dokáže vždycky něčím překvapit, třeba zjištěním, že i černá barva odrazí nějaké světlo.

Související

FIRST Lego League Challenge

Jak zkoušíme bicí

Sat, 27 Dec 2025 00:00:00 +0000

Na skautský tábor s námi jezdí jeden rodič, povoláním profesionální muzikant. Už druhým rokem jsme tedy založili táborovou kapelu i z naprostých začátečníků, bylo to skvělé. Dcera se vrátila s přáním, že chce začít hrát na kytaru. Syn se přidal, že by taky rád něco zkusil, ale neví co. Nakonec jsme vybrali bicí. Máme už je doma od léta, tak sepisuji několik postřehů.

Proč zrovna bicí

Při výběru nástroje jsem bral v potaz, že syn na tom není nejlépe s motorikou. Zároveň jsem si nebyl jistý, jak pečlivě a pravidelně bude cvičit.

První volbou bývá zobcová flétna a jelikož jsem na ni sám začínal, tak říkám, že to není volba ideální. Vyloudit čistý tón dá práci.

Navrhoval jsem piano, tam máte tón vždy čistý. Případně foukací harmoniku, kde máte jistotu, že cokoliv zahrajete, je v tónice.

Mám dojem, že bicí neprávem stojí trochu stranou. Tak schválně. Jak se jmenuje zpěvák a kytarista vaší oblíbené kapely? A jak jejich bubeník?

Přitom Iggy Pop začínal na bicí. Nebo koukněte, jak válí Mag White.

Pohled hráče na baskytaru

Začal jsem hrát baskytaru a od té doby si víc všímám bicích. Koukněte třeba na super lekci How to Play Bass with a Drummer (Foolproof Beginner Blueprint).

Zlý jazykové o mně tvrdí, že dělím věci na dvě kategorie: co jsem dělal a co teprve budu dělat. Jo, chtěl jsem si bicí taky zkusit. I proto, aby mě to posunulo jako basáka.

Bavil jsem se s jedním bubeníkem, který mi opakoval mantru, že baskytarista klidně může zahrát špatnou notu, ale musí to být ve správný čas. Jasně, ale kontroval jsem, že je to přece nástroj na pomezí rytmické a melodické sekce. Načež se mi dostalo odpovědi: „Jsem byl na jednom jazzovém workshopu a pro ně je rytmické všechno od piana dál.“

Výběr nástroje

Předně jsem chtěl elektronické bicí. Nezabírají tolik místa. Nadělají méně hluku, ale nenechte se zmást, že vás nebudou rušit vůbec.

Už jsme kdysi jeden neúspěšný pokus učinili. Jednak byly děti ještě příliš malé, jednak jsme měli „jen“ nástroj z Lidlu, u kterého jsem narazil na limit, že jsem nedokázal pro výukový program správně namapovat MIDI signály pro tom bubny.

Tentokrát jsem sáhl po serióznějším kousku, Yamaha DD-75. Tahle firma dělá dobře všechno od motorek po kytary.

Pedály, které k tomu dostane, jsou spíš tlačítka. Na pár první hodin to stačí, ale pak vám to začne lézt na nervy. U hi-hat necítíte, zda vám nesjela noha a najednou hrajete open hi-hat. U kopáku chybí pořádná odezva.

Za dobré pedály dáte víc než za samotné bicí. Yamaha HH-65 Hi-Hat Controller je super. Bez pořádné přípravy jsem koupil Yamaha KU100 Silent Kick Pedal, který je sice tichý a lepší než pouhé tlačítko, ale odezva taky příliš lehká. Trochu kraválu snesu, takže pro mě je vítěz Roland KT-10 Kick Trigger Pedal. Býval jsem se měl podívat na recenzi od 65 Drums.

Výukový program

Vybíral jsem elektronický nástroj i z důvodu připojení na výukové nástroje přes MIDI. Můžu doporučit Melodics.

Několik večerů jsem byl úplně marný. Je to samá ruka, samá noha, a všechno zkoordinovat je fakt fuška. Vzpomněl jsem si na jeden článek od Duolingo: What makes Arabic hard (and why that shouldn’t stop you from learning it).

Když dospějeme, mluvíme svým jazykem (nebo jazyky) jako mistr kytarista hraje na svůj nástroj: plynule, automaticky a velmi krásně. Proces učení se novému jazyku je jako když se mistr kytarista učí hrát na nový nástroj. Pokud dáte kytaristovi mandolínu, mnoho z dovedností, které již má, mu pomůže: ladění nástroje, brnkání atd. Flétna však vyžaduje zcela nové dovednosti. A bicí? Náš kytarista prakticky začíná od nuly, když se učí hrát na bicí.

Jakmile se z prvního šoku vzpamatujete, tak jejich program oceníte. Dnešní didaktický standard je gamifikace, oslavování několikadenních řad a gratulace k dosaženému pokroku. Dostáváte zpětnou vazbu, zda jste udeřili brzy, pozdě čí víckrát, než bylo třeba. Lekce jsem zábavné a už od začátku hrajete muziku.

Ukázka jedné lekce.

Závěr

Určitě doporučuji vyzkoušet si bicí. Samo o sobě je to zábava a velká výzva pro motoriku. I když hrajete na jiný nástroj, tak vás to hudebně posune. Elektronické bicí jsou méně hlučné, ale ne úplně tiché. Bez pořádných pedálů to není ono, ale nejsou úplně levné.

Související

Ať žijí timeouty

Thu, 27 Nov 2025 00:00:00 +0000

Žil byl, nebo tedy právě spíš nebyl, jednou jeden timeout (ono jich vlastně nakonec chybělo dokonce víc). Stalo se to už před nějakou dobou, tak snad je to částečně odžité. Na testovacím prostředí všechno vyzkoušené a krásně funguje. Z produkce jsou hlášené divné chyby, které postupně vedly až ke zhroucení komponenty. Dlouho se mi nedařilo bug reprodukovat natož odhalit příčinu. Nakonec jsme na to samozřejmě přišli, proto si zapisuju poučení. Stejně jako v případě leteckých havárií, se sešlo víc věcí najednou.

Expozice

Java backend provolával službu třetí strany přes REST API. Daná servisní metoda běžela úmyslně v databázové transakci i s vědomím, že REST volání může trvání neúměrně prodloužit. Nicméně konzistence dat byla v tomto případě naprosto klíčová. Tak klíčová, že bylo dokonce nezbytné použít pesimistické zamykání databáze.

Co by se asi tak mohlo pokazit

Tak já vám povím, co by se asi tak mohlo pokazit.

Upřímně, vůbec nemám rád aplikační servery, ale jednu věc jim nemůžu upřít. Mívaly výchozí nastavení timeoutu databázové transakce. Spring má výchozí timeout -1, tedy nekonečno.

PostgreSQL nepodporuje lock na úrovni statementu a tudíž nefunguje Hibernate JPA hint spring.jpa.properties.jakarta.persistence.lock.timeout. Můžete to nastavit globálně pro celou databázi pomocí ALTER DATABASE powerauth SET lock_timeout=10000;, ale jednak to musíte vědět a jednak na to nesmíte zapomenout.

Spring WebClient postavený na Reactoru nenastavuje response timeout, výchozí hodnota je nekonečno.

Takže se to pokazilo

Nepřekvapivě tedy zásek na volání REST API vyžral celý db connection pool. Když se něco může pokazit, tak se to zaručeně pokazí, a je naší zodpovědností to ošetřit. Byla to tedy naše chyba, že jsme správně nastavili všechny timeouty. To přišlo opravit. Ale proč situace nastávala opakovaně?

Co se vlastně pokazilo

Služba třetí strany běžela za Azure Load Balancerem, který ukončoval idle TCP connection po čtyřech minutách. K čemu tedy došlo na produkci jinému než při testu?

Provolá se REST API, naváže se nové TCP spojení, odbaví se request, a spojení se vrátí do poolu. Má se znovu provolat REST API, vyzvedne se spojení z poolu, které nikdo víc jak čtyři minut nepoužil. Spojení je vadné, ale pool se mylně domnívá, že je stále živé. K naší smůle není nastavený timeout. Tady se dostávám na tenký led síťování, kterému nerozumím. Spojení pravděpodobně nevypadlo z poolu, protože nebyl zapnutý TCP reset, ale i kdyby byl, tak na něj stejně nemůžeme spoléhat. Nabízí se ladit keepAlive, ale to nechávám zvídavému čtenáři k nastudování,

Závěr

Spring Boot není jediný a nebyl ani první, kdo razí přístup convention over configuration a kdo přináší smysluplné výchozí hodnoty. Tedy neměň, co nepotřebuješ. Když není důvod něco specificky nastavovat, tak spoléhám na výchozí hodnoty. Ale některé výchozí hodnoty jsou méně či více nebezpečné a je bezpodmínečně nutné vědět, co člověk dělá.

Související

IDDQD

Fri, 17 Oct 2025 00:00:00 +0000

Jedná se o textový přepis přednášky, kterou jsem měl na nekonferenci jOpenSpace 2025, video záznam ke shlédnutí. Je mi ctí, že jsem mohl dělat předskokana Tomuchovi a jeho povídání o shaderech (náhodička, vůbec jsme se nedomlouvali předem, jako fakt). Nepřináším žádné závratné novinky, nýbrž tichou, ale naléhavou, touhu po úniku z drsné přítomnosti do idylického bezpečí minulosti. Ostatně už jsem vzpomínal na počítač Commodore 64.

Videozáznam

Knihy

Z nostalgie jsem si koupil si knihu 50 let videoher. Ideální dárek pro starý fotry. Sbírka článků z časopisu Level. Úžasné provedení na křídovém papíře. Kromě samotného úniku do dětství mě fascinují technologie, která stojí za skvělými produkty, stejně tak mě fascinují podmínky, které k tomu vedly.

Mezi hrami samozřejmě nesměl chybět Doom. A když jsem hledal téma svůj letošní příspěvek, tak jsem si konečně přečetl knihu The Game Engine Black Book: DOOM, Fabien Sanglard (k dispozici legálně zdarma).

A ohledně názvu přednášky se nakonec ukázalo, že znalost IDDQD není úplně stoprocentně sdílená. Tak vězte, že se jednalo o cheat nesmrtelnosti.

Hře Doom předcházela hra Wolfenstein 3D, které se tu nehodlám podrobněji věnovat. Ostatně Fabien Sanglard o ní vydal samostatnou knihu. Nicméně ve zkratce, zlí jazykové tvrdí, že šlo o 2,5D hru. Stěny jsou pravoúhlé, podlahy a stropy bez textur. Pohybujete se po jediné výškové úrovni, chybí výtahy. Sprity jsou vykresleny 2D.

Rok 1993

archiv ČT24

Píše se rok 1993. Zeman už je v politice. Rozděluje se Československo. Já chodím do třetí třídy.

Mezitím tvůrčí duo John Romero (25 let) a John Carmack (22 let) vydávají ambiciózní tiskovou zprávu, že za 11 měsíců máme čekat převratnou novinku. Romero Doomem dodnes žije a vyjadřuje se k němu, takže nemohl chybět ani v dokumentární seriálu High Score, kde mimo jiné tvrdí, že na konzolích funguje plynulý scroll, to tehdejší PC hry neuměly. Konzole tou dobou znamenalo například Super Nintendo v ceně 199 USD (přepočteno na dnešní inflaci 446 USD).

Když jsem slyšel scrollování, tak jsem si vzpomněl na hru Duke Nukem 2D, známou svým dual-parallax scrollingem, ale vyšel až v prosinci 1993. Ta doba byla těhotná pokrokem.

O hry s 3D grafikou se snažili i na konzolích, první slavná je Star Fox. Nedostatek výkonu mohli dohánět čipem v cartridge.

PC

Platforma PC byla zamýšlená pro textové editory, tabulkové procesory, sem tam zobrazit graf a ne animaci se 70 snímky za vteřinu. 4MB RAM, 14” CRT monitor 320 x 200, bratru za 3000 USD (přepočteno na dnešní inflaci 6726 USD).

Tou dobou máme procesor Intel a ne Pentium, ale 486. Když jsem viděl digramy pipelingu, otevřely se mi staré rány z ČVUT. Na škole mě to deptalo. S příběhem mi to přišlo srozumitelné a bavilo mě to. Jako děti jsme porovnávali jen taktovací frekvence, čím víc herzů, tím víc adidas. Ale je potřeba koukat na změny v architektuře. Procesor 386 například potřeboval dva takty na dekódování instrukce. A přestože procesor 486 s matematickým koprocesorem (takže spíš 487, ale to už nechci zabíhat do detailů) zrychlil operace v plovoucí desetinné čárce až na třetinu, stále to bylo zoufale pomalé oproti celočíselným operacím. Proto Doom zůstává u integerů.

Procesory se vyvíjely rychlejším tempem než paměti. Paměť DRAM byla levná, buňka obsahovala kapacitor a jeden tranzistor. Po přečtení bylo nutné znovu zapsat. Zápis bylo potřeba opakovat i bez čtení, protože kapacitor se vybíjel.

SRAM byla výrazně rychlejší, ale dražší, jelikož konstrukce vyžadovala minimálně šest tranzistorů. Využívala se pro cache. Cache má další rychlostní výhodu, protože procesor s ní komunikuje přímo a nemusí přes sběrnici.

I sběrnice se dočkaly vylepšení. VESA byla asi desetkrát rychlejší než ISA. Zvýšila se přenosová šířka na 32 bitů i frekvence.

Sound Blaster přináší zvukovou kartu s CD kvalitou.

A aby to nebyly jen nostalgické kecy, tak nějaké architektonické poučení. Trh se zvukovými kartami byl značně fragmentovaný. Tehdy sáhli po knihovně DMX, o které se dnes Romero vyjadřuje, že nebyla dobrá, že by si to býval napsal sám. Ale už nepřipouští, že by to nejspíš za 11 měsíců vůbec nestihli.

Můžete si připomenout loňskou přednášku Zákony SW architektury (Lukáš Křečan).

Všechna rozhodnutí v architektuře jsou kompromisy a žádné řešení není dokonalé

Paralelní programování se realizovalo pomocí IRQ (Interrupt Request, signál požadavku na přerušení) a DMA (Direct Memory Access, přímý přístup do paměti).

NeXTSTEP

Ač byll Doom cílený na platformu PC, tak samotný vývoj probíhal na superpočítačích NeXTSTEP. Slavný příběh by vydal na samostatnou přednášku, Steve Jobs byl odejit z Applu, ten pak NeXTSTEP později kupuje atd.

8MB RAM, 17” displej 1120 x 832, volitelně CD ROM bratru za 6 500 USD (přepočteno na dnešní inflaci 14 573 USD)

Programování

Spojenectví mezi Sunem a Nextem symbolizují písmena NS, které dodnes vidíte v API. Je velmi pravděpodobné, že kód, který kdysi běžel na NeXTSTEP a přispěl ke stvoření Dooma, nyní běží na mnoha milionech Apple počítačích nebo telefonech.

Doom byl napsaný v C++. Kolem toho jsem se mihnul. C/C++ pro mě znamená pointery. Když slyším pointery, vybavím si tento vtípek a můj mozek vypíná. Musíte se starat o pamět. Funkce Malloc způsobovala fragmentaci paměti, tak si museli vyvinout vlastní Zone memory manager.

Na PC měli v DOS Borland C++ editor, který měl sice zvýrazňování syntaxe, ale na obrazovku se nevešlo moc řádek a údajně neustále padal. TextEdit na NeXTSTEP neuměl zvýrazňovat, ale zobrazil víc řádek, uměl je zabalovat a hlavně byl stabilní.

Zatímco C++ dával na první místo výkon, tak Objective-C, ve kterém se programovalo na NeXTSTEP, upřednostňoval programátorskou produktivitu. Nikdy jsem v něm nepsal, ale Objective-C pro mě znamená message passing, pro nás Java programátory dodnes něco převratného. Přitom když budete děti učit Scratch, tak je to něco přirozeného.

Doom to jsou brokovnice, démoni a dynamické světelné podmínky. A jak toho dosáhli bez 24 bitové barevné podpory? Připravili si 32 palet o 256 barvách.

Doom přináší multiplayer, hru více hráčů proti sobě, tehdy ještě bez centrálního serveru. My jsme se propojovali přes sériové a paralelní kabely.

Distribuce

Doom distribuovali na dvou disketách jako shareware. Tedy první epizoda zdarma, pokračování k zakoupení.

Plná verze byla menší než 12 MB. Samotný engine něco málo přes 700 KB a data ve WAD souboru (Where’s All the Data?) něco málo přes 11 MB. Toto rozdělení usnadnilo hráčům pozdější vlastní úpravy. Stejně tak umožnilo naportovat engine na současné architektury, viz GZDoom.

Jak jsem již zmiňoval, Romero Doomem dodnes žije. K 25. a 30. výročí vydal Sigil I a Sigil II. Chtěl, aby úrovně působily, jako by patřily k původní hře, jako by to byla skutečná pátá epizoda. Osobně mi přijdou obtížnější než tehdejší úrovně.

Dodnes se hračičkové trumfují, na čem Dooma rozeběhnou.

Závěr

Doom znamenal naše mládí. Ve srovnání s tříáčkovými hrami za nimi stálo několik málo, pravda geniálních, lidí, kteří z tehdejšího hardware vyždímali naprosté maximum. Magie, která za tím stála, je v dnešní Unity/Unreal engine době nepředstavitelná. A proto je dobré si ji připomenout.

Měli jsme vlastně štěstí, že jsme zrod takových legend zažili. Dnes už se nepovažuji za hráče, tak nevím. Vznikají podobně přelomové tituly definující nový žánr?

Související

Pocta C64

Kniha Real-World Cryptography

Tue, 16 Sep 2025 00:00:00 +0000

Kniha Real-World Cryptography od David Wong je to nejpřístupnější, co si můžete o kryptografii přečíst, alespoň co je mi známo. Dostatečně jednoduchá, abych ji pochopil. Dostatečně složitá, abych se k ní musel vrátit. Dál byste v podstatě nemuseli číst tento příspěvek a mohli si jít knihu rovnou koupit. Nicméně uvádím, jak jsem ke svému závěru došel.

Úvod

Posledních dvanáct let se motám kolem software, který se více či méně týká počítačové bezpečnosti. Aby bylo jasno, nejsem kryptolog a nikdy jím nebudu, ale podílel jsem se například na vydávání biometrických pasů. Každopádně se snažím v oboru celou dobu vzdělávat. No a není to snadné. Obor je to komplexní. Že jste udělali chybu, se může projevit až později jako obrovský průšvih. Když věci ladíte, někdy stačí jediný bit jinak a celé je to špatně, ale nevíte proč.

Co jsem zatím četl

Naprostá nutnost je Kniha kódů a šifer od Simon Singh (překlad Petr Koubský). V roce 2022 vyšel dotisk (již 4. české vydání), tak by měla být k mání. Je to populárně naučné, velmi čtivé. Pracovně si s tím však nevystačíte.

Kdysi jsem četl Java Cryptography (Jonathan Knudsen). Dnes už prehistorie z roku 1998, popisující Java Cryptography Architecture (JCA) v Java 1.2 Dlouho jsem to neměl v ruce. API asi ještě bude platit. Ale úplně chybí knihovna Bouncy Castle a píše se tam ještě o SHA-1.

Sáhl jsem tedy po Java Cryptography: Tools and Techniques. To je extrém z druhé strany, já bych to pojmenoval Bouncy Castle Recipes, tedy ukázky kódu, jak používat Bouncy Castle. Chybí vysvětlení konceptů. Pro mě těžko přístupné. Zkrátka moc velký znalostní skok.

Kurzy

Na Coursera jsem před lety absolvoval kurz Cryptography I. Očekávaná zátěž sedm hodin týdně. Zvládal jsem jen teorii, praktické úlohy už ne. Dan Boneh je skvělý lektor, kurz je kvalitní, ale dost zaměřený na formální matematiku, což možná není to, co právě hledáte.

Real-World Cryptography

Konečně se dostávám ke knize Real-World Cryptography, kterou považuji za poklad. Vyšla v nakladatelství Manning, což už je záruka samo o sobě.

Většina zdrojů je poměrně náročná na matematiku a většina vývojářů, kteří se zabývají kryptografií, se nechce zabývat matematikou.

Didakticky mě velmi oslovila. Staví znalosti od základních kamenů po složitější. Přijde mi, že vysvětluje principy a vykládá jen tu nejnezbytnější matematiku. Nezahlcuje, ale nechává prostor k dalšímu samostudiu.

Věnuje se dokonce kryptoměnám i FIDO2. Vysvětluje protokol Signal (který používá i WhatsApp). Popisuje i post-quantum cryptography, tedy kryptografii odolné vůči útoku za pomoci výpočetního výkonu kvantových počítačů. Ač kniha vyšla v roce 2021, kdy tyto algoritmy ještě nebyly standardizované, nijak vás nesvede na scestí.

Dál obsah pitvat nebudu, můžete si udělat představu sami.

Chci, abyste si uvědomili, že jste v privilegované pozici. Kryptografie začala jako obor za zavřenými dveřmi, omezený pouze na členy vlády nebo akademiky udržované v tajnosti, a pomalu se stala tím, čím je dnes: vědou otevřeně studovanou po celém světě.

Závěr

Doporučuji všem (nejen programátorům), kteří potřebují kryptografii nějak používat (což jsou stejně všichni). Dostatečně jednoduchá, abych ji pochopil. Dostatečně složitá, abych se k ní musel vrátit a pak pokračoval ve studiu jinde.

Související

Maven Daemon

Sat, 23 Aug 2025 00:00:00 +0000

Abych udržel tempo publikací na blogu, tak každý článek nemůže přinášet zásadní téma. Zůstaňme tedy při zemi, u něčeho staršího. Ač jsem někdy Maven haněl, tak tentokrát bych se ho rád zastal. Doporučuji paralelní build a použití démona, který (dle mého pozorování) není tak rozšířený, jak by býval mohl být.

Přehled buildovacích nástrojů

Doporučuji k přečtení článek My final take on Gradle (vs. Maven). Nechci papouškovat celý, ale stručné shrnutí.

Ant

Ant taky pamatuju, takže můžu potvrdit, že neřešil závislosti a chyběla konzistence mezi projekty.

Maven

Maven přináší závislosti a konvence. Dnes už se jedná o běžný přístup konvence před konfigurací (convention over configuration, není nutné explicitně konfigurovat, máte implicitní smysluplné nastavení). Pro specifické úpravy si můžete napsat vlastní plugin, což není zase tak snadné. Nemá podporu paralelního build a i ve verzi 3 stále označen jako experimentální. Očekávané zrychlení paralelního buildu je 20 až 50 %.

Nicolas Fränkel v odkazovaném článku tvrdí, a já s ním souhlasím, že málo flexibility není bug ale žádoucí vlastnost.

Gradle

Gradle využívá Maven závislosti a přidává flexibilitu, které se až vymyká z rukou. Od začátku myslí na rychlost buildu a systém cachování. Prsí se, že oproti Mavenu jsou v některých případech až 100 krát rychlejší.

Maven Daemon

Maven Daemon je dlouhodobý proces běžící na pozadí. Start JVM není úplně zanedbatelná operace. S démonem tedy ušetříte start JVM při každém buildu a hlavně nepřijdete o JIT (Just-In-Time) optimalizace. V neposlední řadě dostaneme vylepšený výstup paralelního build na konzoli.

Vlastní pozorování

V současné době mimo jiné přispívám do open source projektu PowerAuth. Níže naleznete dobu buildu na MacBook Pro s M1 procesorem. mvnd je příkaz pro build pomocí Maven Daemon.

Příkaz	Čas buildu	Poznámka
`mvn clean package`	46,6 s
`mvn package`	30,6 s
`mvn clean package -T 1C`	40 s	Paralelní běh, 1 thread na dostupný core.
`mvn package -T 1C`	28,6	Paralelní běh, 1 thread na dostupný core.
`mvnd clean package`	37,9 s	Démon, paralelně spouští by default.
`mvnd package`	26,4 s	Démon, paralelně spouští by default, první běh.
`mvnd package`	22,8 s	Démon, paralelně spouští by default, po zahřátí.

Úskalí paralelního buildu

Jak jsme si již řekli, paralelní build v Mavenu stále není plně podporován. Kromě problémových pluginů můžete narazit i na problémy ve svém kód, který třeba nezvládne paralelní běh integrační testů, takže si budete muset zamést i před svým prahem.

Závěr

Ač zrychlení paralelního buildu v Mavenu nedosahuje hodnot, jaké reklamuje Gradle, tak přesto by byla škoda toho nevyužít. Když už se dáte cestu paralelního buildu v Mavenu, doporučuji využít Maven Daemon. Při práci ve větších týmech a v situaci, kdy programátoři přechází mezi projekty, dávám přednost předvídatelnosti před rychlostí.

Související

Konflikt tranzitivních závislostí

Úskalí GHA runneru

Wed, 30 Jul 2025 00:00:00 +0000

Měl jsem takovou tvůrčí krizi. Můžu to alespoň svádět na dobu LLM. Má dneska vůbec smysl něco tvořit? Jenže stroje vám, zatím, odpoví jen na to, co jste se zeptali. Proto čtu online články i časopisy, které mi rozšiřují obzor, protože mi podsouvají informace, na které bych se býval nezeptal. Jednak mám puzení něco psát, jednak je blog z velké části deník pro mě samotného, jako si psal Kocour Modroočko, co všechno zažil (kdo neznáte zhudebněnou verzi s Dejdarem, pusťte si, je to poklad pro děti i dospělé).

Pojďme se rozehřát něčím jednoduchým až banálním.

Jeden z nejznámějších build nástrojů Jenkins se dříve konfiguroval jen klikáním v GUI. Bylo to nepohodlné, špatně se to verzovalo, zálohovalo a možném code review ani nemluvě. Naštěstí tu je s námi už nějakou dobu Jenkinsfile, který leží v repozitáři vedle zdrojového kódu.

Vedle toho existuje lákavá alternativa GitHub Actions (dále jen GHA). Představte si, že byste se nemuseli starat o vlastní build server, jaká pohoda. Do jaké pasti byste se asi tak mohli dostat?

Problém s GHA

Jenkins buildy jsme dávno přenesli na GHA. Jeden z nich pouštěl baterii integračních testů vůči dev prostředí. Neříkám, že je to vzor hodný následování, ale v Jenkins to fungovalo a nějakou dobu i v GHA.

Pak začaly testy padat na Connection timed out. Nějakou chvíli to ignorujete, prostě síť je nespolehlivá, ale testy musí být přeci zelené.

Z výše popsaného je patrné, že testy a server běží nezávisle na sobě. I když je server v Azure a GHA je od Microsoftu, nic nezaručuje, že poběží ve stejném regionu.

Hypotézu je potřeba ověřit.

Ověření hypotézy

Do konfigurace GHA přidáme

steps:
  - name: Log runner IP and region
    run: |
      echo "Public IP:"
      curl -s https://ifconfig.me
      echo -e "\nRegion info (GeoIP):"
      curl -s https://ipinfo.io

Výsledek

Public IP:
135.232.177.160
Region info (GeoIP):
{
  "ip": "135.232.177.160",
  "city": "Chicago",
  "region": "Illinois",
  "country": "US",
  "loc": "41.8500,-87.6500",
  "org": "AS8075 Microsoft Corporation",
  "postal": "60666",
  "timezone": "America/Chicago",
  "readme": "https://ipinfo.io/missingauth"
}

A sakra, dev server běží ve West Europe. Dle této diskuse region u GHA nastavit bohužel nelze.

Nikdy se nedozvím, proč se to rozbilo až po čase. Možná Trump uvalil clo i na TCP spojení, nebo GitHub prostě jen čaroval s regiony runnerů.

Řešení

Jak z toho ven?

Připravit si self-hosted runner, s tím ale padá ona výhoda, že se nechcete o nic starat.
Přesunout server do jiného regionu (což se zase nemusí hodit pro jiné scénáře, kdy tam přistupujete z Evropy).
Vytvořit další instanci jen pro testy (v regionu, kde dle logu runner s testy běží).
Ideální, zato nejsložitější cesta, vytvořit image, který bude obsahovat jak server, tak testy, což zaručí, že všechno bude na jediném místě.

Závěr

I když jste nečetli knihu The Mythical Man-Month (Frederick P. Brooks), jistě vám bude znám koncept No Silver Bullet. Je lákavé, že se nemusíte o nic starat, ale když už se o něco postarat potřebujete, tak je to pak komplikované až nemožné.

Vietnam informatiky

Tue, 29 Apr 2025 00:00:00 +0000

Mým oblíbeným článkem, hlavně kvůli analogii z historie, je The Vietnam of Computer Science, který před již mnoha lety napsal Ted Neward. S jeho laskavým svolením přináším překlad. Dlouho jsem si na něj netroufal, ale nakonec jsem učesal výsledek z DeepL. Překlad uvolňuji pod licencí Creative Commons BY-NC-SA 3.0, nicméně autorská práva stále náleží Tedu Newardovi.

Nabízím analogii k objektově-relačnímu mapování a problémům, které představuje

26. června 2006

(Na Microsoft TechEd 2004 v San Diegu, jsem se na akci po konferenci účastnil rozhovoru s Harrym Piersonem a Clemensem Vastersem, a jak je typické, když se my tři sejdeme, předmětem našich diskusí byla architektonická témata. Kolem nás se shromáždil dav lidí stejných zájmů. Přišla řeč na technologie objektově-relačního mapování a tehdy jsem poprvé použil větu: „Objektově-relační mapování je Vietnamem informatiky“. V mezidobí jsem obdržel řadu žádostí o upřesnění diskuse, která se za tímto výrokem skrývá, a vzhledem k nedávnému oznámení Microsoftu ohledně „podpory entit“ v ADO.NET 3.0 a přijetí Java Persistence API jako náhrady za EJB Entity Beans i JDO se zdálo, že je čas přesně to udělat.

(2022 Poznámka: Tento článek je již patnáct let starý. Několikrát jsem byl v pokušení historickou část zkrátit - to je jedna z nejčastějších výtek k tomuto dílu -, ale v zájmu toho, aby po světě nekolovalo více jeho kopií, jsem ji zde ponechal. Pokud chcete lekci historie přeskočit, zde je rychlý odkaz na technologické kousky.)

Žádný ozbrojený konflikt v dějinách USA nestrašil americkou armádu více než Válka ve Vietnamu, známá jako Vietnam. Tolik odlišných prvků se spojilo, aby vytvořily nejrozhodnější bod obratu v moderních amerických dějinách, že se vzpírá snaze jakéhokoli laika je od sebe oddělit. Přesto je příběh Vietnamu v podstatě prostý: Spojené státy zahájily vojenský projekt s jednoduchými, ale nejasnými a protichůdnými cíli a rychle se zapletly do šlamastyky, která nejenže svrhla dvě vlády (jednu legálně, druhou silou zbraní), ale také hluboce poznamenala americkou vojenskou doktrínu na další čtyři desetiletí (přinejmenším).

Ačkoli se to může zdát banální, Objektově-relační mapování je Vietnamem informatiky. Představuje šlamastyku, která začíná dobře, postupem času se komplikuje a zanedlouho své účastníky uvězní v závazku, který nemá jasné ohraničení, jasné podmínky vítězství ani jasnou strategii úniku.

Historie

PBS má dobré shrnutí války, ale pro ty, kteří se zajímají spíše o informatiku než o politickou/vojenskou historii, je stručná verze následující:

Jižní Indočína, dnes známá jako Vietnam, Thajsko, Laos a Kambodža, má dlouhou historii bojů o autonomii. Před francouzskou koloniální nadvládou (která začala v polovině 19. století) bojovala Jižní Indočína o regionální nezávislost na Číně. Během druhé světové války oblast dobyli Japonci, aby ji později „osvobodili“ spojenci, což vedlo Francii k obnovení koloniální nadvlády (stejně jako Brity na jejich koloniálních územích jinde v Asii a Indii). Po Druhé světové válce však obyvatelé jižní Indočíny, kteří se zbavili jednoho utlačovatele, rozšířili své protiokupační úsilí na boj proti Francouzům namísto Japonců a v roce 1954 Francouzi kapitulovali a podepsali Ženevské mírové dohody, které Vietnamu formálně poskytly nezávislost. Bohužel globální tlaky toto úsilí poněkud zvrátily a místo trvalé mírové dohody vzniklo dočasné řešení, které rozdělilo zemi na 17. rovnoběžce a vytvořilo dva národy tam, kde dříve žádné takové rozdělení neexistovalo. V roce 1956 se měly konat volby, které měly zemi znovu sjednotit, ale USA se obávaly, že by těmito volbami získala příliš velkou moc Komunistická strana Vietnamu, a místo toho podpořily protikomunistický stát jižně od 17. rovnoběžky a vytvořily kolem něj řadu mnohostranných dohod, například SEATO. Zrodil se nový stát Jižní Vietnam a jeho prvním (pochybně) zvoleným vůdcem se stal Ngo Dinh Diem, přesvědčený antikomunista, který téměř okamžitě prohlásil, že jeho země je pod útokem komunistů. Eisenhowerova administrativa Diemovu vládu nadále podporovala, ale Diemova loajalita u lidu byla od počátku téměř nulová.

V době nástupu Johna F. Kennedyho z Demokratické strany USA do Bílého domu se situace v Jižním Vietnamu začala vyhrocovat. Kennedy vyslal do Vietnamu tým, který měl prozkoumat tamní poměry a pomoci formulovat strategii v této otázce. V dokumentu, který je dnes známý jako „Bílá kniha z prosince 1961“, byly předloženy argumenty pro zvýšení vojenské, technické a ekonomické pomoci spolu s rozsáhlými americkými „poradci“, kteří měli pomoci stabilizovat Diemovu vládu a zlikvidovat Frontu národního osvobození, kterou USA nazvaly Vietkong. Není však tak všeobecně známo, že řada Kennedyho poradců argumentovala proti tomuto navýšení a označila Vietnam za „slepou uličku“.

Tváří v tvář dvěma diametrálně odlišným cestám zvolil Kennedy, jak bylo pro jeho administrativu typické, střední cestu: místo masivního angažmá nebo úplného stažení se Kennedy raději rozhodl usilovat o omezené urovnání, vyslání pomoci, ale ne velkého počtu vojáků, což byla cesta, která byla od počátku téměř odsouzena k zániku. Řadou strategických omylů, včetně nuceného přesídlování venkovských vesničanů (tzv. strategický program Hamlet), byla Diemova podpora tak hluboce oslabena, že Kennedy váhavě a nejistě podpořil převrat, během něhož byl Diem zabit. O tři týdny později byl Kennedy rovněž zavražděn, což vyvolalo zmatek i na domácí politické scéně USA. Ironií osudu je, že konflikt, který Kennedy zahájil, bude ve skutečnosti později nejvíce spojován s jeho nástupcem.

Johnsonova válka

V době atentátu na Kennedyho působilo ve Vietnamu 16 000 amerických poradců, z nichž většina nebyla zapojena do každodenních bojových operací. Kennedyho viceprezident a jeho nový nástupce Lyndon Baines Johnson (LBJ) však nebyl přesvědčen, že tato cesta vede k úspěchu, a dospěl k názoru, že je třeba jednat agresivněji. Johnson využil pochybného incidentu, při němž vietnamské hlídkové čluny zaútočily na americké torpédoborce¹ v Tonkinském zálivu, a využil proválečných nálad v Kongresu ke schválení rezoluce, která mu dávala pravomoc provést vojenskou akci bez výslovného vyhlášení války. Jednoduše řečeno, Johnson chtěl tuto válku vést „chladnokrevně“: „To znamenalo, že Amerika bude válčit ve Vietnamu s přesností chirurga a s malým dopadem na domácí kulturu. Omezená válka si vyžádala omezenou mobilizaci zdrojů, materiálních i lidských, a způsobila jen malé narušení každodenního života v Americe.“ (zdroj) V podstatě by se jednalo o válku, jejíž dopad by pocítili pouze Vietnamci - americký život a společnost by pokračovaly bez jakéhokoli povšimnutí událostí ve Vietnamu, a Johnson by se tak mohl věnovat své první velké lásce, své „Velké společnosti“, domácímu programu, který měl napravit mnoho neduhů americké společnosti, například chudobu². Historie to samozřejmě ví lépe a - možná krutě - nazývá vietnamský konflikt „Johnsonovou válkou“.

Na úvod je třeba poznamenat, že Vietnam jako katastrofa je vnímán až v poslední době; Američané byli v průzkumech veřejného mínění ještě v roce 1967 přesvědčeni, že válka je dobrá věc, že je třeba zastavit komunismus a že Vietnam, pokud padne, bude prvním z řady států, které podlehnou komunistickému rozvratu. Tato „teorie domina“ byla běžným refrénem americké politiky druhé poloviny 20. století. Obavy tohoto druhu sužovaly americkou zahraniční politiku od doby, kdy komunisté úspěšně nebo téměř úspěšně rozvrátili několik evropských vlád v druhé polovině 40. let a poté Čínu v 50. letech. (Je třeba poznamenat, že Eisenhower a John Foster Dulles, kteří formulovali tuto teorii, nikdy nezařadili Vietnam do svého kruhu domina, které je třeba zachovat, a ve skutečnosti byl Eisenhower během některých svých setkání s Kennedym při přechodu do Bílého domu vůči Vietnamu překvapivě apatický.)

V roce 1968 se však situace ve Vietnamu výrazně změnila, protože Severovietnamci a Vietkong zahájili ofenzívu Tet, kampaň, která zmařila veškeré ujišťování americké vlády, že ve válce ve Vietnamu vítězí. Paradoxně, stejně jako po většinu války, ztratily síly NVA/VC značný počet vojáků, mnohem více než jejich američtí protivníci, přesto je ofenzíva Tet historiky všeobecně považována za bod zlomu americké vůle ve válce. Po této události se veřejné mínění obrátilo proti Johnsonovi a ten na dramatické tiskové konferenci oznámil, že nebude usilovat o své znovuzvolení. Dále oznámil, že bude usilovat o vyjednávání s Vietnamci.

Nixonův slib

Naneštěstí byla americká vyjednávací pozice vážně oslabena právě těmi protesty, které Američany k jednacímu stolu vůbec přivedly; vedení NVA/VC uznalo, že síly NVA/VC, navzdory ohromujícím vojenským ztrátám, které je téměř zlomily (několikrát), mohou jednoduše pokračovat v tom, co dělaly, a vymáhat od Američanů ústupky, aniž by nabídly nějaké na oplátku. Johnsonův nástupce, republikán Richard Nixon, kandidující s programem, který se skládal převážně ze slibu „dostat Ameriku z Vietnamu“, se pokusil o několik taktik, jak vyvinout tlak na síly NVA/VC, aby vyjednávaly, včetně zvýšené přítomnosti vzdušných sil (například vánoční bombardování a operace Menu) a pravidelného narušování nedalekého Laosu a Kambodže, sledování linie zásobování ze Severního Vietnamu k buňkám v Jižním Vietnamu. Nic však nepomohlo a v roce 1973 Nixonova vláda podepsala Pařížskou mírovou dohodu, která ukončila americkou účast v tomto konfliktu. O dva roky později byl jižní Vietnam ovládnut a 30. dubna 1975 se komunistické síly zmocnily Saigonu, hlavního města Vietnamu, což si vynutilo evakuaci amerického velvyslanectví a nejpamátnější obraz války - proudy prchajících lidí, kteří hledali místo ve vrtulníku Huey umístěném na střeše velvyslanectví.

Konec války

Druhá válka v jižní Indočíně skončila, Amerika zažila svou nejhlubší porážku v historii a Vietnam se stal synonymem pro „šlamastyku“. Její dopad na americkou kulturu byl nezměrný, neboť naučila celou generaci Američanů bát se své vlády a nedůvěřovat jí, naučila americké vůdce obávat se jakéhokoli množství amerických vojenských obětí a přinesla slovní spojení „jasná strategie odchodu“ přímo do amerického politického slovníku. Teprve když Ronald Reagan použil americkou armádu k „osvobození“ malého ostrovního státu Grenada, začali američtí prezidenti považovat americkou vojenskou intervenci za možný nástroj diplomacie, a i tehdy jen s velkým citem pro domácí obavy, jak zjistil Bill Clinton během svých mírových misí v Somálsku a Kosovu. Také z vyčíslitelného hlediska dopady Vietnamu zjevně nedosáhly Johnsonova cíle „chladnokrevné války“. Konečný součet: Ve válce sloužily 3 miliony Američanů, 150 000 jich bylo vážně zraněno, 58 000 mrtvých a více než 1 000 nezvěstných, nemluvě o téměř milionu obětí z řad NVA/Vietkongu, 250 000 jihovietnamských obětí a statisících - ne-li milionech, jak tvrdí někteří historici - civilních obětí.

Poučení z Vietnamu

Vietnam představuje pro studenty vojenských a politických dějin zajímavý problém - co přesně se pokazilo, kdy a kde? Je zřejmé, že neochota americké vlády přiznat svá selhání během války z ní činí snadného obětního beránka, ale žádná vláda v dějinách moderní společnosti nikdy nebyla vůči svému obyvatelstvu zcela upřímná, pokud jde o její válečné štěstí; jedním z takových příkladů je (ale nejen) pečlivá cenzura činnosti téže americké vlády během druhé světové války o padesát let dříve, známé v americké historii jako „poslední ‚dobrá‘ válka“. Je také lákavé poukázat na absenci vojenského cíle jako na zásadní selhání Vietnamu, ale jiné nevojenské cíle byly úspěšně realizovány vládami USA i jiných zemí, aniž by došlo k takovému kolosálnímu selhání, které provází vietnamský příběh. Navíc je důležité poznamenat, že USA měly ve skutečnosti jasný cíl v tom, co chtěly z konfliktu v jižní Indočíně vytěžit: zastavit pád jihovietnamské vlády, a pokud se tak nestane, zastavit „šíření“ komunismu. Byla to neochota americké vlády nasadit armádu naplno, jak vždy tvrdil generál William Westmoreland? Jistěže neúspěch ve Vietnamu nebyl vojenský; počty obětí jasně ukazují, že USA podle jakýchkoli jiných měřítek jasně vítězily.

Jaké byly tedy hlavní neúspěchy ve Vietnamu? A co je důležitější, co to všechno má společného s O/R mapováním?

Vietnam a O/R mapování

V případě Vietnamu se politický a vojenský aparát Spojených států potýkal se smrtelnou formou zákona snižujícího se mezního produktu. V případě automatizovaného objektově-relačního mapování jde o stejnou obavu - že počáteční úspěchy přinesou závazek používat O/R na místech, kde se úspěch stává nepolapitelnějším a časem není vůbec úspěšný kvůli časové a energetické režii potřebné k jeho podpoře ve všech možných případech použití. V podstatě největším poučením z Vietnamu - pro jakoukoli politickou či jinou skupinu - je vědět, kdy „sbalit fidlátka a zmizet“. Příliš často, jako tomu bylo ve Vietnamu, je snadné ospravedlnit další investice do určitého postupu naznačováním, že opuštění tohoto postupu nějakým způsobem znehodnocuje veškerou práci - nebo v případě Vietnamu životy amerických vojáků -, které již byly zaplaceny. Fráze jako „Došli jsme tak daleko, jistě to dotáhneme do konce“ a „Vycouvat teď znamená zahodit vše, co jsme doposud obětovali“ se stávají běžnými. Přinejmenším v pozdějších, hluboce rozhořčených letech druhé poloviny Vietnamské války přišly na přetřes otázky vlastenectví: pokud jste válku nepodporovali, byli jste zjevně zrádce, komunista, zjevně „neameričan“, neuctivý ke všem americkým veteránům jakékoli války vedené na jakémkoli území, ať už z jakéhokoli důvodu, a pravděpodobně jste kopali do svého psa. (Protestujícím nepomohlo ani to, že z války obviňovali vojáky a činili je odpovědnými - někdy i osobně - za rozhodnutí vojenských a politických vůdců, z nichž většinu vojáci ani protestující nikdy nepotkali).

Při vědomí toho, že všechny analogie nakonec selžou a že téma Vietnamu je hlubší, než může tato esej zkoumat, lze se zde přesto poučit ze zcela jiné oblasti. Jedním z klíčových poučení z Vietnamu bylo nebezpečí toho, čemu se hovorově říká „šikmá plocha“: že určitý postup může přinést určitý počáteční úspěch, avšak další investice do tohoto postupu přináší stále méně úměrné výsledky a stále nebezpečnější překážky, jejichž jediným řešením se zdá být větší a větší nasazení zdrojů a/nebo opatření. Někteří to nazývají „lékovou pastí“, podle způsobu, jakým mohou léky (legální nebo nelegální drogy) po delším užívání vykazovat snížený účinek a vyžadovat zvýšené dávkování, aby přinesly stejné výsledky. Jiní tomu říkají „problém poslední míle“: s blížícím se koncem problému je z hlediska nákladů (peněžních i abstraktních) stále obtížnější najít stoprocentní řešení. Všichni v podstatě hovoří o tomtéž - o obtížnosti nalezení odpovědi, která by našemu hrdinovi umožnila „dokončit“ daný problém úplně a uspokojivě.

Analýzu objektově-relačního mapování - a jeho vztahu k druhé válce v Jižní Indočíně - začneme především zkoumáním důvodů pro jeho vznik. Co vede vývojáře k tomu, že nepoužívají tradiční relační nástroje pro přístup k relační databázi a místo toho dávají přednost nástrojům, jako je ORM?

Nesoulad objektově-relačních impedancí

Říci, že objekty a relační datové sady jsou nějakým způsobem konstruovány odlišně, obvykle nepřekvapí žádného vývojáře, který někdy používal obojí; s výjimkou extrémně zjednodušených situací je poměrně zřejmé, že způsob, jakým je navrženo relační datové úložiště, se jemně - a přesto hluboce - liší od způsobu, jakým je navržen objektový systém.

Objektové systémy jsou obvykle charakterizovány čtyřmi základními komponentami: identita, stav, chování a zapouzdření.

Stav je celkem srozumitelný pojem, který se nejvíce blíží pojmu „data“.
Identita je ve většině objektově orientovaných jazyků implicitním pojmem v tom smyslu, že daný objekt má jedinečnou identitu, která je odlišná od jeho stavu (hodnoty jeho vnitřních proměnných) - dva objekty se stejným stavem jsou stále samostatné a odlišné objekty, přestože jsou bitově zrcadlovými obrazy jeden druhého. Jedná se o diskusi „identita vs. ekvivalence“, která se objevuje v jazycích jako C++, C# nebo Java, kde vývojáři musí rozlišovat mezi a == b a a.equals(b).
Chování objektu je poměrně snadno viditelné, jedná se o soubor operací, které mohou klienti vyvolat, aby nějakým způsobem manipulovali s objekty, zkoumali je nebo s nimi interagovali. (Tím se objekty liší od pasivních datových struktur v procedurálních jazycích, jako je C.)
Zapouzdření je klíčovým detailem, který zabraňuje vnějším stranám manipulovat s vnitřními detaily objektu, a poskytuje tak klientům evoluční schopnosti rozhraní objektu.³

Z toho můžeme odvodit další zajímavé koncepty, jako je typ, formální deklarace stavu a chování objektu, asociace, která umožňuje, aby se typy na sebe navzájem odkazovaly prostřednictvím odlehčeného odkazu namísto úplného vlastnictví podle hodnoty (někdy se nazývá kompozice), dědičnost, schopnost propojit jeden typ s jiným tak, že propojený typ zahrnuje veškerý stav a chování propojeného typu jako součást svého vlastního, a polymorfismus, schopnost nahradit objekt tam, kde se očekává jiný typ.

Relační systémy popisují formu ukládání a vyhledávání znalostí založenou na predikátové logice a pravdivostních výrocích. V podstatě každý řádek v tabulce je prohlášení o skutečnosti ve světě a jazyk SQL umožňuje operátově-efektivní vyhledávání dat těchto skutečností pomocí predikátové logiky k vytváření závěrů z těchto skutečností. [Date04] a [Fussell] definují relační model jako charakterizovaný vztahem, atributem, tuplem, hodnotou vztahu a proměnnou vztahu. Relace je ve své podstatě pravdivostní predikát o světě, výkaz faktů (atributů), které predikátu dodávají význam. Můžeme například definovat relaci „OSOBA“ jako {SSN, Jméno, Město}, která říká, že „existuje OSOBA s číslem sociálního pojištění SSN, která žije ve městě a jmenuje se Jméno“. Všimněte si, že v relaci je pořadí atributů zcela nespecifikované. Tuple je pravdivostní výrok v kontextu relace, množina hodnot atributů, které odpovídají požadované množině atributů v relaci, například {PERSON SSN='123-45-6789' Name='Catherine Kennedy' City='Seattle'}. Všimněte si, že dva tuply jsou považovány za identické, pokud jsou identické i hodnoty jejich relací a atributů. (To je opět na rozdíl od objektového systému, ve kterém jsou dva objekty identické pouze tehdy, pokud mají stejný jedinečný identifikátor - obvykle paměťovou adresu.)

A hodnota relace je tedy kombinací relace a množiny tuplů, které této relaci odpovídají, a proměnná relace je stejně jako většina proměnných zástupcem dané relace, ale může v průběhu času měnit hodnotu. Proměnná relace Lidé tak může být zapsána jako držitel relace {Lidé}, a skládat se z hodnoty relace

{ {PERSON SSN='123-45-6789" Jméno="Catherine Kennedy' Město="Seattle"},
  {PERSON SSN='321-54-9876' Jméno='Charlotte Neward' City='Redmond'},
  {PERSON SSN='213-45-6978' Jméno='Cathi Gero' City='Redmond'}. }

Tyto pojmy se běžně označují jako tabulky (proměnná vztahu), řádky (tuply), sloupce (atributy) a kolekce proměnných vztahu jako databáze. Tyto základní typy prvků lze vzájemně kombinovat pomocí sady operátorů (podrobně popsaných v kapitole 7 v [Date04]): restrict, project, product, join, divide, union, intersection a difference, a ty tvoří základ formátu a přístupu k SQL, všeobecně uznávanému jazyku pro interakci s relačním systémem z operátorských konzolí nebo programovacích jazyků. Použití těchto operátorů umožňuje vytvářet odvozené hodnoty relací, relace, které jsou vypočteny z jiných hodnot relací v databázi - například můžeme vytvořit hodnotu relace, která demonstruje počet lidí žijících v jednotlivých městech využitím operátorů project a restrict napříč výše definovanou proměnnou relace Lidé.

Již nyní je poměrně jasně vidět, že existují výrazné rozdíly mezi tím, jak relační a objektový svět nahlíží na „správný“ návrh systému, a postupem času se ukáží další. Je však důležité poznamenat, že dokud budou programátoři pro přístup k relačním datovým skladům preferovat objektově orientované programovací jazyky, bude vždy docházet k určitému druhu objektově-relačního mapování - oba modely jsou prostě příliš odlišné na to, aby je bylo možné tiše překlenout. (Pravděpodobně totéž platí pro objektově orientované a procedurální programování, ale to je jiný argument na jindy.)

ORM může probíhat v různých formách, z nichž nejjednodušší je rozpoznat automatizovaný nástroj pro ORM, například TopLink, Hibernate / NHibernate nebo Gentle.NET. Další formou mapování je ruční mapování, při kterém programátoři používají relačně orientované nástroje, jako je JDBC nebo ADO.NET, pro přístup k relačním datům a jejich „ruční“ extrakci do podoby příjemnější pro objektově orientované vývojáře. Třetí možností je jednoduše přijmout tvar relačních dat jako „ten“ model, z něhož se vychází, a objekty kolem něj tomuto přístupu podřídit; tento přístup je v lexikonu vzorů znám také jako Table Data Gateway [PEAA, 144] nebo Row Data Gateway [PEAA 152]; mnoho vrstev pro přístup k datům v Javě i .NET tento přístup využívá a kombinuje ho s generováním kódu, aby se zjednodušil vývoj této vrstvy. Někdy kolem relačního/tabulkového modelu postavíme objekty, kolem nich umístíme nějaké další chování a nazveme je Active Record [PEAA, 160].

Po pravdě řečeno, tento základní přístup - zotročení jednoho modelu podmínkami a přístupem druhého - byl tradiční odpovědí na nesoulad impedancí, která efektivně „řeší“ problém ignorováním jeho jedné poloviny. Bohužel, většina vývojových snah, podobně jako Kennedyho administrativa, není ochotna dotáhnout to do logického konce s plošným upřednostněním jednoho přístupu před druhým. Například zatímco většina vývojových týmů by ráda přijala přístup pouze „objektový“, na úrovni úložiště to předpokládá použití objektově orientovaného systému správy databází (OODBMS), což je téma, které často nemá žádnou odezvu ve vyšším managementu nebo v týmu správy podnikových dat. Opačný přístup - přístup „pouze relační“ - je vzhledem k tehdejším technologiím v době vzniku tohoto textu⁴ téměř nesmyslné zvažovat.

Vzhledem k tomu, že tedy není možné „uvolnit objekty na maximum“, jak by to nazval generál Westmoreland, zbývá nám nějaký hybridní přístup mapování objektů na relační, nejlépe takový, který je co nejvíce automatizovaný, aby se vývojáři mohli soustředit na svůj doménový model, a ne na detaily mapování objektů na tabulky. A tady bohužel začíná potenciální šlamastyka.

Problém mapování objektů na tabulky

Jedním z prvních a nejsnáze rozpoznatelných problémů při používání objektů jako front-end k relačnímu datovému skladu je problém, jak mapovat třídy na tabulky. Na první pohled se zdá, že jde o poměrně jednoduché cvičení - tabulky se mapují na typy, sloupce na instanční proměnné. Dokonce se zdá, že typy proměnných přímo odpovídají relačním typům sloupců, přinejmenším v poměrně izomorfní míře: VARCHAR na String, INTEGER na int a tak dále. Je tedy logické, že pro každou třídu definovanou v systému je definována odpovídající tabulka - pravděpodobně se stejným nebo příbuzným názvem -, která ji bude doprovázet. Nebo třeba, pokud se objektový kód zapisuje do již existujícího schématu, pak se třída mapuje na tabulku.

Je však přirozené, že s postupem času se dobře vyškolený objektově orientovaný vývojář bude snažit využít dědičnost v objektovém systému a hledat způsoby, jak totéž provést v relačním modelu. Relační model bohužel nepodporuje žádný druh polymorfismu ani vztah typu IS-A, a tak se vývojáři nakonec ocitnou v situaci, kdy přijmou jednu ze tří možných variant mapování dědičnosti do relačního světa: table-per-class, table-per-concrete-class nebo table-per-class-family. Každá z nich s sebou nese potenciálně významné nevýhody.

Přístup table-per-class je asi nejsnáze pochopitelný, protože se snaží minimalizovat „vzdálenost“ mezi objektovým a relačním modelem; každá třída v hierarchii dědičnosti dostane svou vlastní relační tabulku a objekty odvozených typů jsou sešity z relačních JOINů napříč různými tabulkami založenými na dědičnosti. Pokud má tedy například objektový model základní třídu OSOBA, od ní odvozenou třídu STUDENT a od ní odvozenou třídu ABSOLVENT, pak budou k uložení tohoto modelu zapotřebí tři tabulky: OSOBA, STUDENT a ABSOLVENT, z nichž každá bude obsahovat proměnné odpovídající stejnojmenné třídě. Vztah těchto tabulek k sobě však vyžaduje, aby každá z nich měla nezávislý primární klíč (takový, jehož hodnota není ve skutečnosti uložena v entitě objektu), aby každá odvozená třída mohla mít vztah cizího klíče k tabulce své nadtřídy. Důvod je jasný: objekt Absolvent je na základě svého vztahu IS-A ke třídám Student a Person kolekcí všech tří sad stavů a rozdíl mezi třídami je v okamžiku vytvoření objektu tohoto typu do značné míry odstraněn - například v Javě i .NET je samotný objekt kusem paměti, který obsahuje instanční proměnné definovaná ve všech jeho třídách a nadtřídách spolu s pointrem na tabulku metod definovaných stejnou hierarchií. To znamená, že při dotazování na konkrétní instanci na relační úrovni je třeba provést nejméně tři JOINy, aby se do pracovní paměti objektového programu dostal veškerý stav objektu.

Vlastně je to ještě horší - pokud hierarchie objektů dále roste, řekněme tak, že zahrnuje třídy Professor, Staff, Undergrad (dědí od třídy Student) a celou hierarchii AdjunctEmployees (dědí od třídy Staff), a program chce najít všechny Persons, jejichž příjmení je Smith, pak je třeba provést JOINy pro každou odvozenou třídu v systému, protože sémantika „najít všechny osoby“ znamená, že dotaz musí vyhledat data v tabulce PERSON, ale pak provést nákladnou sadu spojení JOIN, aby získal zbytek dat z celého zbytku databáze, přičemž pro získání zbytku dat je třeba vytáhnout tabulku PROFESSOR, nemluvě o tabulkách UNDERGRAD, ADJUCTEMPLOYEE, STAFF a dalších. Vzhledem k tomu, že JOINy patří mezi nejdražší výrazy v dotazech RDBMS, je zřejmé, že se do toho nebudete brát na lehkou váhu.

V důsledku toho vývojáři obvykle volí jeden ze dvou dalších přístupů, výhledově složitějších, ale efektivnějších při práci s relačním úložištěm: buď vytvoří tabulku pro každou konkrétní (nejvíce odvozenou) třídu a raději přijmou denormalizaci a její náklady, nebo vytvoří jedinou tabulku pro celou hierarchii, přičemž často v obou případech vytvoří diskriminační sloupec, který označuje, do které třídy patří každý řádek v tabulce. (Možné jsou i různé hybridy těchto schémat, ale obvykle nevytvářejí výsledky, které by se výrazně lišily od těchto dvou). Bohužel náklady na denormalizaci jsou u velkého objemu dat často značné a/nebo tabulka (tabulky) bude obsahovat značné množství prázdných sloupců, které budou potřebovat omezení NULLability na všechny sloupce, což eliminuje výkonná omezení integrity, která nabízí RDBMS.

Mapováním dědičnosti to nekončí; asociace mezi objekty, typické asociace s kardinalitou 1:n nebo m:n, tak běžně používané v SQL a/nebo UML, se řeší zcela jinak: V objektových systémech je asociace jednosměrná, od asociátora k asociovanému objektu (což znamená, že asociované objekty netuší, že jsou ve skutečnosti asociovány, pokud není vytvořena explicitní obousměrná asociace), zatímco v relačních systémech je asociace ve skutečnosti obrácená, od asociovaného objektu k asociátorovi (prostřednictvím sloupců cizích klíčů). To se ukazuje jako překvapivě důležité, protože to znamená, že pro asociace m:n musí být použita třetí tabulka pro uložení skutečného vztahu mezi asociátorem a asociovaným a dokonce i pro jednodušší vztahy 1:n nemá asociátor žádnou vlastní znalost vztahů, ke kterým se asociuje - zjištění těchto údajů vyžaduje v určitém okamžiku JOIN proti některé nebo všem asociovaným tabulkám. (Kdy tato data skutečně získat, je předmětem diskuse - viz níže Paradox načítání).

Konflikt mezi schématem a vlastnictvím

Diskuse o schématech mapování dědičnosti na tabulky a asociací také odhaluje základní chybu: V jádru mnoho nástrojů pro objektově-relační mapování předpokládá, že schéma je něco, co lze definovat podle schémat, která pomáhají optimalizovat dotazy ORM vůči relačním datům. To však popírá základní problém, že samotné databázové schéma často není pod přímou kontrolou vývojářů, ale je vlastněno jinou skupinou ve firmě, typicky skupinou správy databáze (DBA). Komu náleží odpovědnost za návrh databáze - a rozhodování o tom, kdy jsou změny schématu přípustné?

V mnoha případech začínají vývojáři nový projekt na „zelené louce“, s prázdnou relační databází, jejíž schéma mohou definovat podle svého uvážení. Brzy po dokončení projektu (někdy i dříve, kvůli politickým problémům a/nebo „válce o území“) se však ukáže, že vlastnictví schématu vývojáři je přinejlepším dočasné - různá oddělení se začnou dožadovat reportů k databázi, DBA se zodpovídají za výkonnost databáze, což jim dává důvod volat po „refaktorování“ a denormalizaci dat, a ostatní vývojové týmy se mohou začít zajímat o to, jak by mohly využít data v ní uložená. Zanedlouho musí být schéma „zmrazeno“, čímž se potenciálně vytvoří překážka pro refaktorování objektového modelu. Kromě toho budou tyto další týmy očekávat relační model definovaný v relačních termínech, nikoliv takový, který podporuje zcela ortogonální formu perzistence - například sloupec „diskriminátor“ z problému mapování dědičnosti na tabulky bude pro relační generátory sestav, jako je Crystal Reports, představovat obtíže a pravděpodobně bude zcela nepoužitelný. Pokud nejsou vývojáři ochotni psát všechny sestavy (a jejich uživatelská rozhraní, a jejich tiskový kód, a jejich ad-hoc možnosti…) ručně, bude to obvykle nepřijatelný stav.

(Abychom byli spravedliví, nejedná se ani tak o technický problém, jako spíše o problém politický, ale stále představuje vážný problém bez ohledu na jeho zdroj - nebo řešení. A jako takový stále představuje překážku pro řešení objektově-relačního mapování.”

Problém dvojího schématu

S otázkou vlastnictví schématu souvisí i to, že v řešení ORM jsou metadata k systému uložena zásadně na dvou různých místech: jednou ve schématu databáze a jednou v objektovém modelu (chcete-li, dalším schématu vyjádřeném v jazyce Java nebo C# namísto DDL). Aktualizace nebo refaktorování jednoho z nich bude pravděpodobně vyžadovat podobné úpravy druhého. Refaktorování kódu tak, aby odpovídal změnám schématu databáze, je obecně považována za jednodušší - refaktorování databáze často vyžaduje určitý druh migrace a/nebo úpravy dat již v databázi, kdežto u kódu takový požadavek není. (Objekty, alespoň v této diskusi, jsou efemérní instance v paměti, které zmizí, jakmile proces, který je drží, skončí. Pokud jsou objekty uloženy v nějakém druhu objektové formy, která může přetrvat napříč prováděním procesu - například serializované instance objektů uložené na disku - pak se refaktorování objektů stává stejně problematickou.)

Důležitější je, že ačkoli není neobvyklé, aby byl kód nasazen specificky pro jednu aplikaci, často jsou instance databáze využívány více než jednou aplikací a pro firmu je často nepřijatelné vyvolat celofiremní refaktorování kódu jen proto, že refaktorování v jedné aplikaci vyžaduje podobné refaktorování řízené databází. V důsledku toho bude s postupným růstem systému narůstat tlak na vývojáře, aby „odpoutali“ objektový model od databázového schématu tak, aby změny schématu nevyžadovaly podobné refaktorování objektového modelu a naopak. V některých případech, kdy ORM takové odpojení neumožňuje, může být nutné nasadit zcela soukromou instanci databáze s přesným schématem, na kterém bylo postaveno řešení založené na ORM, čímž vznikne další datové silo v prostředí IT, kde sílí tlak na redukci takových sil.

Problémy s identitou entit

Jako by tyto problémy nestačily, narážíme na další problém, a to identitu objektů a vztahů. Jak bylo uvedeno výše, objektové systémy používají implicitní smysl pro identitu, obvykle založený na umístění objektu v paměti (všudypřítomný ukazatel this); alternativně se někdy označuje jako OID (Object IDentifier), obvykle v systémech, které přímo nevystavují umístění v paměti, jako je například objektová databáze (kde je ukazatel v paměti jako identifikátor mimo proces databáze celkem k ničemu). V relačním modelu je však identita implicitně obsažena v samotném stavu - dva řádky s naprosto stejným stavem jsou obvykle považovány za poškození relačních dat, protože dvakrát tvrzená stejná skutečnost je nadbytečná a kontraproduktivní. Abychom byli spravedliví, měli bychom zde být trochu explicitnější; relační systém může ve skutečnosti povolit duplicitní tuply (jak je popsáno výše), ale to je často explicitně zakázáno explicitními relačními omezeními, jako jsou omezení PRIMARY KEY. V situacích, kdy jsou duplicitní hodnoty povoleny, neexistuje pro relační systém žádný způsob, jak určit, který ze dvou duplicitních řádků je načítán - neexistuje žádný implicitní smysl pro identitu relace kromě toho, který nabízejí její atributy. Totéž neplatí pro objektové systémy, kde dva objekty, které obsahují přesně identické bitové vzory na dvou různých místech paměti, jsou ve skutečnosti samostatné objekty. (To je důvod, proč se v Javě nebo C# rozlišuje mezi == a .equals().) Důsledek je zde jednoduchý: pokud se mají oba systémy shodnout na smyslu identity, musí relační systém nabídnout nějaký jedinečný pojem identity (obvykle automaticky se zvyšující celočíselný sloupec), který bude odpovídat pojmu identity objektu.

To vyvolává vážné obavy, pokud jde o automatizované systémy OR, protože smysl identity je zcela odlišný - pokud dvě samostatné uživatelské relace interagují se stejným vztahem v úložišti, nastupují systémy souběžnosti relačního databázového systému a zajišťují určitou formu souběžného přístupu, obvykle prostřednictvím transakční metafory (ACID). Pokud systém O/R načte relaci z úložiště (v podstatě vytvoří „pohled“ na data), máme nyní druhý zdroj identity dat, jeden v databázi (chráněný výše zmíněným transakčním schématem) a jeden v objektové reprezentaci těchto dat v paměti, která nemá žádnou konzistentní transakční podporu kromě té, která je zabudována v jazyce (například koncept monitorů v jazycích Java a .NET) nebo knihovny (například System.Transactions v .NET 2.0), které mohou být - a bohužel často jsou - vývojáři snadno ignorovány. Správa izolace a souběžnosti (concurrency) není snadno řešitelný problém a bohužel jazyky a platformy běžně dostupné vývojářům zatím nejsou tak konzistentní a flexibilní jako metafora databázových transakcí.

Tento problém dále komplikuje skutečnost, že mnoho systémů O/R zavádí do vrstvy O/R významnou podporu cachování (obvykle ve snaze zvýšit výkon a vyhnout se obcházení databáze), což zase přináší určité problémy, zejména pokud systém cachování není cache pro zápis, kde dochází ke skutečnému zápisu databáze; a co to vypovídá o transakční integritě, pokud se aplikační kód domnívá, že k zápisu došlo, ačkoli se tak ve skutečnosti nestalo? Tento problém se zase jen prohlubuje, pokud systém O/R běží ve více procesech před databázovým strojem, což se běžně vyskytuje ve scénářích clusterových aplikačních serverů. Nyní je identita dat rozložena do n+1 míst, přičemž n je počet uzlů aplikačního serveru a 1 je samotná databáze. Každý uzel musí nějakým způsobem signalizovat svůj záměr provést aktualizaci ostatním uzlům, aby získal nějakou konstrukci souběhu, která zabrání současnému přístupu (jinou instancí stejné relace nebo instancí jiné relace přistupující ke stejným datům), což zabere čas a zabíjí výkon. Dokonce i v případě cache určené pouze pro čtení musí být aktualizace datového úložiště nějakým způsobem signalizovány cache běžící v uzlech aplikačního serveru, což vyžaduje komunikaci mezi serverem a klientem pocházející z databáze; podpora tohoto postupu není v současných moderních relačních databázích dobře pochopena ani zdokumentována.

Obavy z mechanismu získávání dat

Jakmile je entita uložena v databázi, jak ji přesně získáme? Čistě objektově orientovaný přístup by pro vyhledávání využíval objektové přístupy, v ideálním případě pomocí syntaxe ve stylu konstruktorů identifikujících požadované objekty, ale bohužel syntaxe konstruktorů není dostatečně obecná, aby umožnila něco tak flexibilního; zejména jí chybí možnost inicializovat kolekci objektů a dotazy často potřebují vrátit kolekci, nikoli pouze jednu entitu. (Vícenásobné cesty do databáze za účelem načtení jednotlivých entit jsou obecně považovány za příliš neekonomické, a to jak z hlediska latence, tak šířky pásma, než aby se daly považovat za věrohodnou alternativu - více viz níže Paradox času načítání.) Výsledkem je obvykle jeden z přístupů Query-By-Example (QBE), Query-By-API (QBA) nebo Query-By-Language (QBL).

Přístup QBE spočívá v tom, že vyplníte šablonu objektu typu objektu, který hledáte, přičemž instanční proměnné jsou nastaveny na konkrétní hodnotu, která se použije jako součást procesu filtrace dotazu. Pokud se tedy například dotazujete na objekt/tabulku Osoba na osoby s příjmením Smith, nastavíte dotaz takto:

Person p = new Person(); // předpokládá, že všechny instanční proměnné jsou ve výchozím nastavení nulové
p.lastName = "Smith";
ObjectCollection oc = QueryExecutor.execute(p);

Problém s přístupem QBE je zřejmý: zatímco pro jednoduché dotazy je naprosto dostačující, není zdaleka dostatečně expresivní pro podporu složitějšího stylu dotazů, které často potřebujeme provést - „najdi všechny osoby jménem Smith nebo Cromwell“ a „najdi všechny osoby, které se NEjmenují Smith“ jsou dva příklady. Ačkoli není nemožné vytvořit přístupy QBE, které si s tímto (a složitějšími scénáři) poradí, rozhodně to značně komplikuje rozhraní API. Ještě důležitější je, že to také nutí doménové objekty do nepříjemné pozice - musí podporovat nulovatelné instanční proměnné, což může být porušením doménových pravidel, která by se jinak objekt snažil podporovat - Osoba beze jména není v mnoha scénářích příliš užitečný objekt, ale právě to bude přístup QBE vyžadovat od doménových objektů v něm uložených. (Praktici QBE budou často tvrdit, že není nerozumné, aby implementace objektu toto zohledňovala, ale opět to není ani snadné, ani časté.)

V důsledku toho je obvykle druhým krokem, aby objektový systém podporoval přístup „Query-By-API“, v němž jsou dotazy konstruovány pomocí dotazovacích objektů, obvykle něco ve tvaru:

Query q = new Query();
q.From("PERSON").Where(new EqualsCriteria("PERSON.LAST_NAME", "Smith"));
ObjectCollection oc = QueryExecutor.execute(q);

Tady není dotaz založen na prázdné „šabloně“ objektu, který má být získán, ale na sadě „dotazovacích objektů“, které jsou společně použity k definování objektu ve stylu příkazu pro provedení proti databázi. Více kritérií je spojeno pomocí nějaké binomické konstrukce, obvykle objektů And a Or, z nichž každý obsahuje jedinečné objekty Criteria pro testování. Další objekty filtrace/manipulace lze označit na konci, obvykle připojením volání jako OrderBy(fieldName) nebo GroupBy(fieldName). V některých případech jsou tato volání metod vlastně objekty zkonstruované programátorem a explicitně zřetězené.

Vývojáři si rychle všimnou, že výše uvedený přístup je (obecně) mnohem více slovní než tradiční přístup SQL a některé styly dotazů (zejména netradiční spojení, například vnější spojení) je mnohem obtížnější - ne-li nemožné - reprezentovat v přístupu QBA.

Kromě toho tu máme ještě jeden subtilnější problém, a to závislost na disciplíně vývojářů: jak název tabulky PERSON, tak název sloupce v kritériích PERSON.LAST_NAME jsou standardní řetězce, které se přebírají tak, jak jsou, a do systému se vkládají za běhu bez jakékoliv kontroly platnosti. To představuje klasický problém v programování, chybu překlepu, kdy se vývojář ve skutečnosti nedotazuje na tabulku PERSON, ale na tabulku PRESON. Rychlý unit-test proti živé instanci databáze sice chybu odhalí, ale to předpokládá dvě skutečnosti - že vývojáři jsou zarytí do testování a že unit-testy jsou prováděny proti instancím databáze. Zatímco první z těchto skutečností se pomalu stává zárukou, protože stále více vývojářů je „nakaženo testováním“ (vypůjčím si terminologii Gama a Becka), druhá skutečnost je stále zcela otevřená diskusi a interpretaci vzhledem k tomu, že vhodné nastavení a rozpojení instance databáze pro unit testy je v databázi stále obtížně proveditelné. (Ačkoli existuje řada způsobů, jak tento problém obejít, zdá se, že se jich používá jen málo.)

Setkáváme se také se základním problémem, že je od vývojáře vyžadováno větší povědomí o logické - nebo fyzické - reprezentaci dat - místo toho, aby se vývojář jednoduše soustředil na to, jak spolu objekty souvisejí (prostřednictvím jednoduchých asociací, jako jsou pole nebo instance kolekcí), musí mít nyní větší povědomí o formě, v níž jsou objekty uloženy, což činí systém poněkud zranitelným vůči změnám schématu databáze. Tomuto problému se někdy vyhýbá hybridní přístup mezi těmito dvěma přístupy, kdy systém převezme odpovědnost za interpretaci asociací a ponechá na vývojáři, aby napsal něco takového:

Query q = new Query();
Field lastNameFieldFromPerson = Person.class.getDeclaredField("lastName");
q.From(Person.class).Where(new EqualsCriteria(lastNameFieldFromPerson, "Smith"));
ObjectCollection oc = QueryExecutor.execute(q);

Což částečně řeší problém s uvědoměním si schématu a problém překlepu, ale stále ponechává vývojáře zranitelného vůči obavám ze slovíčkaření a stále neřeší složitost sestavení složitějšího dotazu, například dotazu na více tabulek (nebo chcete-li více tříd) spojených na základě několika kritérií různými způsoby.

Dalším úkolem je tedy vytvořit přístup „Query-By-Language“, v němž je napsán nový jazyk, podobný jazyku SQL, ale nějakým způsobem „lepší“, který podporuje složité a výkonné dotazy běžně podporované jazykem SQL; dva příklady takového jazyka jsou OQL a HQL. Problémem je, že tyto jazyky jsou často podmnožinou jazyka SQL, a proto nenabízejí plnou sílu jazyka SQL. Ještě důležitější je, že vrstva O/R nyní ztratila důležitý „prodejní argument“, a to mantru „objekty a pouze objekty“, která ji zplodila; používat jazyk podobný SQL je téměř stejné jako používat samotné SQL, takže jak může být více „objektový“? Vývojáři sice nemusí znát fyzické schéma datového modelu (o mapování, o kterém jsme hovořili dříve, se může postarat interpret/executor dotazovacího jazyka), ale budou si muset být vědomi toho, jak jsou v jazyce reprezentovány asociace a vlastnosti objektů a jaká je podmnožina schopností objektů v rámci dotazovacího jazyka - je například možné napsat něco takového?

SELECT Person p1, Person p2
FROM Person
WHERE p1.getSpouse() == null 
  AND p2.getSpouse() == null 
  AND p1.isThisAnAcceptableSpouse(p2) 
  AND p2.isThisAnAcceptableSpouse(p1);

Jinými slovy, prohledejte databázi a najděte všechny svobodné osoby, které se navzájem považují za přijatelné. Zatímco metoda isThisAnAcceptableSpouse je zjevně metodou, která patří do třídy Person (každá instance Person může mít svá vlastní kritéria, podle kterých posuzuje přijatelnost jiného svobodného - zda je to blondýna, bruneta nebo zrzka, zda vydělává více než 100 tisíc dolarů ročně a tak dále), není jasné, zda je provedení této metody možné v dotazovacím jazyce, a není ani jasné, zda by mělo být. I u těch nejtriviálnějších implementací dojde pravděpodobně k vážnému zásahu do výkonu, zejména pokud musí vrstva O/R přeměnit data relačních sloupců na objekty, aby bylo možné dotaz provést. Navíc nemáme žádnou záruku, že vývojář napsal tuto metodu tak, aby byla vůbec efektivní, a nemáme žádný způsob, jak vynutit nějakou implementaci zohledňující výkon.

(Kritici budou tvrdit, že se jedná o řešitelný problém, a navrhnou dvě možná řešení. Jedním z nich je zakódovat preferenční údaje do samostatné tabulky a učinit ji součástí dotazu; výsledkem bude ohavně komplikovaný dotaz, který bude mít délku několika stránek a pravděpodobně bude vyžadovat experta na SQL, aby ho později rozplétal, když bude chtít přidat nová preferenční kritéria. Druhou možností je zakódovat tuto implementaci „přijatelnosti„“ do uložené procedury v rámci databáze, což nyní zcela odstraní kód z objektového modelu a ponechá nás bez jakéhokoli „objektového“ řešení - přijatelné, ale pouze pokud přijmete předpoklad, že ne všechna implementace může spočívat uvnitř samotného objektového modelu, což odmítá předpoklad „objekty a nic než objekty“, kterým mnozí zastánci O/R otevírají své argumenty.)

Problém částečných objektů a paradox času načítání

Je již dlouho známo, že procházení sítě, například při tradičním požadavku SQL, trvá značnou dobu. (Podle hrubých srovnávacích testů se tato hodnota pohybuje v rozmezí tří až pěti řádů ve srovnání s jednoduchým voláním metody na platformě Java nebo .NET⁵; zhruba analogicky, pokud vám ráno cesta do práce trvá dvacet minut a nazýváme ji dobou potřebnou k provedení volání místní metody, čtyři řády k této hodnotě představují zhruba dobu potřebnou k cestě na Pluto, neboli necelých čtrnáct let v jednom směru). Tyto náklady jsou zjevně netriviální, takže v důsledku toho vývojáři hledají způsoby, jak tyto náklady minimalizovat optimalizací počtu síťových komunikací a načítaných dat.

V jazyce SQL se této optimalizace dosahuje pečlivým strukturováním požadavku SQL, kdy se dbá na to, aby se načítaly pouze požadované sloupce a/nebo tabulky, nikoli celé tabulky nebo sady tabulek. Například při konstrukci pečlivě plánovaného tradičního uživatelského rozhranín vývojář předloží souhrnné zobrazení všech záznamů, z nichž si uživatel může vybrat jeden, a po výběru pak zobrazí kompletní sadu dat pro daný záznam. Zaměřme se na příklad relačního typu Persons popsaného dříve, dva dotazy k tomu určené by byly v tomto pořadí (za předpokladu, že je vybrán první z nich):

SELECT id, first_name, last_name FROM person;

SELECT * FROM osoba WHERE id = 1;

Zejména si všimněte, že v každé fázi procesu jsou získány pouze požadované údaje - v prvním dotazu potřebné souhrnné informace a identifikátor (pro následný dotaz v případě, že by k přímé identifikaci osoby nestačilo jméno a příjmení) a ve druhém zbytek údajů k zobrazení. Většina odborníků na SQL se ve skutečnosti vyhýbá syntaxi sloupců se zástupným znakem * a raději v dotazu každý sloupec pojmenuje, a to jak z důvodu výkonu, tak z důvodu údržby - z důvodu výkonu, protože databáze bude lépe optimalizovat dotaz, a z důvodu údržby, protože bude menší pravděpodobnost, že budou vráceny nepotřebné sloupce, jak se budou DBA nebo vývojáři vyvíjet a/nebo refaktorovat příslušné databázové tabulky. Toto pojetí možnosti vrátit část tabulky (i když stále v relační podobě, což je důležité z výše popsaných důvodů uzavřenosti) je zásadní pro možnost optimalizovat tyto dotazy tímto způsobem - většina dotazů bude ve skutečnosti vyžadovat pouze část kompletního vztahu.

To představuje problém pro většinu, ne-li všechny vrstvy mapování objektů a relací: cílem každé O/R je umožnit vývojáři vidět „nic než objekty“, a přesto vrstva O/R nemůže z jednoho požadavku na druhý říci, jak budou objekty vrácené dotazem použity. Je například zcela reálné, že většina vývojářů bude chtít napsat něco ve stylu:

Person[] all = QueryManager.execute(....);
Person selected = DisplayPersonsForSelection(all);
DisplayPersonData(selected);

Jinými slovy to znamená, že jakmile je z pole Person vybrána osoba, která má být zobrazena, není třeba provádět žádnou další akci načítání - koneckonců máte svůj objekt, co víc by mělo být potřeba?

Problém zde spočívá v tom, že data, která mají být zobrazena v prvním volání Display...(), nejsou celá osoba, ale podmnožina těchto dat; zde narážíme na první problém v tom, že objektově orientovaný systém, jako je C# nebo Java, nemůže vrátit pouze „části“ objektu - objekt je objekt, a pokud se objekt Person skládá z 12 instančních proměnných, pak bude všech 12 přítomno v každé vrácené osobě. To znamená, že systém stojí před jednou ze tří nepříjemných možností: za prvé, požadovat, aby objekty Person byly schopny obsahovat „nulovatelné“ proměnné, bez ohledu na doménová omezení, která tomu brání; za druhé, vrátit Person kompletně vyplněný všemi daty, která objekt tvoří; nebo za třetí, poskytnout nějaký druh načítání na vyžádání, které získá tyto instanční proměnné, pokud a kdy vývojář k těmto proměnným přistupuje, a to i nepřímo, třeba prostřednictvím volání metody.

(Všimněte si, že některé objektové jazyky, například ECMAScript, nahlížejí na objekty jinak než jazyky založené na třídách, například Java nebo C# či C++, a v důsledku toho je zcela možné vracet objekty, které obsahují různý počet instančních proměnných. Takový přístup však má jen málo jazyků, dokonce ani oblíbený dynamický jazyk Ruby, a dokud se takové jazyky nerozšíří, zůstává taková diskuse mimo oblast této eseje.)

Pro většinu O/R vrstev to znamená, že objekty a/nebo pole objektů musí být načítány líným způsobem, získáváním dat na vyžádání, protože načítání všech instančních proměnných všech objektů/vztahů osob by pro tento konkrétní scénář „zjevně“ znamenalo obrovské plýtvání šířkou pásma. Obvykle se celá sada instančních proměnných objektu načte při přístupu k jakékoli dosud nevrácené instanční proměnné. (Tento přístup se upřednostňuje před přístupem po jednotlivých proměnných, protože je zde menší pravděpodobnost „problému N+1 dotazů“, kdy načtení všech dat z objektu vyžaduje 1 dotaz na načtení primárního klíče + N dotazů na načtení každé proměnné z tabulky podle potřeby. Tím se minimalizuje šířka pásma spotřebovaná na načtení dat - žádná nezpracovaná proměnná nebude mít načtena svá data - ale zjevně se nepodaří minimalizovat síťové interakce.)

Naneštěstí jsou proměnné v rámci objektu jen částí problému - další problém, kterému čelíme, spočívá v tom, že objekty jsou často spojeny s jinými objekty, a to v různých kardinalitách (jeden k jednomu, jeden k mnoha, mnoho k jednomu, mnoho k mnoha), a mapování O/R musí předem rozhodnout, kdy tyto přidružené objekty načíst, a přes veškerou snahu vývojářů ORM budou vždy existovat běžné případy použití, kdy učiněné rozhodnutí bude přesně to špatné. Většina ORM nabízí nějakou vývojářem řízenou podporu rozhodování, obvykle nějaký konfigurační nebo mapovací soubor, který přesně určí, jaká bude politika načítání, ale toto nastavení je globální pro danou třídu a jako takové ho nelze situačně měnit.

Shrnutí

Pokud je tedy mapování objektů do relací v moderním firemním systému nutností, jak ho může někdo prohlásit za šlamastyku, ze které není úniku? Jako užitečná analogie zde opět slouží Vietnam - zatímco situace v jižní Indočíně vyžadovala reakci Američanů, Kennedyho a Johsonova administrativa měla k dispozici celou řadu reakcí, včetně stejné reakce, jakou vyvolal nedávný pád Suharta v Malajsii, tedy žádné. (Nezapomeňte, že Eisenhower a Dulles v první řadě nepovažovali jižní Indočínu za součást teorie domina; mnohem více je zajímalo Japonsko a Evropa.)

Nabízí se několik možných řešení problému ORM, z nichž některá vyžadují určitý druh „globální“ akce celé komunity, jiná jsou přístupnější vývojovým týmům „v zákopech“:

Opuštění Vývojáři se jednoduše zcela vzdají objektů a vrátí se k programovacímu modelu, který nevytváří nesoulad mezi objektovou a relační impedancí. I když je to nepříjemné, v určitých scénářích vytváří objektově orientovaný přístup více režie, než kolik ušetří, a návratnost investice jednoduše není taková, aby ospravedlnila náklady na vytvoření bohatého doménového modelu. ([Fowler] o tom hovoří poněkud do hloubky.) To tento problém poměrně elegantně odstraňuje, protože pokud neexistují žádné objekty, nedochází k impedančnímu nesouladu.
Celkové přijetí Vývojáři se jednoduše zcela vzdají relačního úložiště a používají model úložiště, který odpovídá způsobu, jakým se na svět dívají jejich zvolené jazyky. Systémy objektového ukládání, jako je například projekt db4o (který je bohužel od roku 2021 v podstatě nefunkční), řeší problém elegantně tím, že ukládají objekty přímo na disk, čímž odstraňují mnoho (ale ne všechny) z výše uvedených problémů; neexistuje například žádné “druhé schéma”, protože jediné použité schéma je schéma samotných definic objektů. Ačkoli mnozí DBA při této myšlence omdlí, ve světě stále více orientovaném na služby, který se vyhýbá myšlence přímého přístupu k datům, ale místo toho vyžaduje, aby veškerý přístup probíhal přes bránu služby, čímž je mechanismus ukládání zapouzdřen mimo dosah zvědavých očí, je zcela reálné si představit, že vývojáři ukládají data ve formě, která je pro ně mnohem snazší než pro DBA.
Ruční mapování Vývojáři se prostě smíří s tím, že to nakonec není tak těžký problém, aby ho řešili ručně, a napíší rovnou kód pro relační přístup, který bude vracet relace do jazyka, přistupovat k tuplům a naplňovat objekty podle potřeby. V mnoha případech může být tento kód dokonce automaticky generován nástrojem zkoumajícím metadata databáze, čímž se eliminuje některá z hlavních kritik tohoto přístupu (a to: „Je to příliš mnoho kódu na psaní a údržbu“).
Přijetí omezení ORM Vývojáři se jednoduše smíří s tím, že neexistuje způsob, jak efektivně a snadno uzavřít smyčku nesouladu O/R, a použijí ORM k vyřešení 80 % (nebo 50 % nebo 95 % nebo jakéhokoli procenta, které se jim zdá vhodné) problému a využijí SQL a přístup založený na relacích (například „surový“ JDBC nebo ADO.NET), aby se přenesli přes ty oblasti, kde by ORM způsoboval problémy. Takový postup však s sebou nese vlastní podíl rizik, protože vývojáři používající ORM si musí být vědomi jakéhokoli ukládání do cache, které v rámci něj řešení ORM provádí, protože „surový“ relační přístup zjevně nebude schopen tuto vrstvu ukládání do cache využít.
Integrace relačních konceptů do jazyků Vývojáři se prostě smíří s tím, že tento problém by měl řešit jazyk, nikoli knihovna nebo framework. V posledních deseti nebo více letech se důraz na řešení problému O/R soustředil na snahu přiblížit objekty databázi, aby se vývojáři mohli soustředit výhradně na programování v jediném paradigmatu (tímto paradigmatem jsou samozřejmě objekty). V posledních několika letech však zájem o „skriptovací“ jazyky s mnohem silnější podporou množin a seznamů, jako je Ruby, podnítil myšlenku, že je možná vhodné jiné řešení: vnést relační koncepty (které jsou ve své podstatě založeny na množinách) do hlavních programovacích jazyků, což usnadní překlenutí propasti mezi „množinami“ a „objekty“. Práce v této oblasti je zatím omezená a omezuje se většinou na výzkumné projekty a/nebo „okrajové“ jazyky, ale v komunitě se zviditelňuje několik zajímavých snah, jako jsou hybridní funkcionální/objektové jazyky, například Scala nebo F#, a také přímá integrace do tradičních O-O jazyků, jako je projekt LINQ společnosti Microsoft pro C# a Visual Basic. Jednou z takových snah, která bohužel selhala, byla strategie SQL/J; i tam byl přístup omezený, nesnažil se začlenit množiny do Javy, ale pouze umožnit, aby vložená volání SQL byla předzpracována a přeložena do kódu JDBC překladačem.
Integrace relačních konceptů do frameworků Vývojáři prostě uznávají, že tento problém je řešitelný, ale pouze se změnou perspektivy. Místo aby se spoléhali na to, že tento problém vyřeší návrháři jazyků nebo knihoven, zaujmou jiný pohled na „objekty“, který je více relační povahy, a vytvoří doménové rámce, které jsou více přímo postaveny na relačních konstrukcích. Například místo vytváření třídy Person, která uchovává svá instanční data přímo v proměnných uvnitř objektu, vytvářejí vývojáři třídu Person, která uchovává svá instanční data v instanci RowSet (Java) nebo DataSet (C#), kterou lze sestavit s dalšími RowSet/DataSet do snadno přenositelného bloku dat pro aktualizaci proti databázi nebo rozbalit z databáze do jednotlivých objektů.

Všimněte si, že tento seznam není uveden v žádném konkrétním pořadí; zatímco některé jsou atraktivnější než jiné, to, které jsou „lepší“, je hodnotový soud, který si musí každý vývojář a vývojový tým udělat sám.

Stejně jako je možné si představit, že USA mohly dosáhnout určitého „úspěchu“ ve Vietnamu, kdyby se držely jasné strategie a chápaly jasnější vztah mezi závazkem a výsledky (ROI, chcete-li), je možné si představit, že objektový/relační problém lze „vyhrát“ pečlivým a uvážlivým uplatňováním strategie, která si je celá vědoma svých vlastních omezení. Vývojáři musí být ochotni brát „výhry“ tam, kde je mohou získat, a nesklouznout na šikmou plochu tím, že se budou snažit vytvářet řešení, která budou stále dražší a méně výnosná. Bohužel, jak ukazuje historie Vietnamské války, ani vědomí nebezpečí šikmé plochy často nestačí k tomu, aby se zabránilo zabřednutí do bažiny. A co hůř, je to bažina, která je prostě příliš přitažlivá na to, aby se jí dalo vyhnout, píseň sirén, která stále přitahuje vývojové týmy všech velikostí korporací (včetně těch v Microsoftu, IBM, Oracle a Sunu, abychom jmenovali alespoň některé) ke skalám, a to s velkolepými výsledky. Přivažte se ke stěžni, pokud chcete píseň slyšet, ale nechte veslovat námořníky.

Poznámky na závěr

[1] Pozdější analýzy zúčastněných ředitelů - včetně tehdejšího ministra obrany Roberta McNamary - dospěly k závěru, že polovina útoku se vůbec neuskutečnila.

[2] Je možná největší ironií války, že muž, kterého si osud vybral do čela během největšího amerického zahraničního angažmá, byl vůdce, jehož hlavní pozornost byla zaměřena výhradně na vlastní břehy. Kdyby se okolnosti nespikly jinak, hippies skandující před Oválnou pracovnou “Hej, hej LBJ, kolik kluků jsi dneska zabil” by dost možná byli Johnsonovými nejvěrnějšími stoupenci.

[3] Ironií osudu se ukazuje, že zapouzdření je z důvodu jednoduchosti údržby hlavní motivací téměř všech významných inovací v lingvistické informatice - procesní, funkcionální, objektové, aspektové, dokonce i relační technologie ([Date02]) a další jazyky uvádějí „zapouzdření“ jako hlavní hnací faktor.

[4] Za „relační“ programovací jazyky bychom snad mohli považovat jazyky uložených procedur jako T-SQL nebo PL/SQL, ale i v takovém případě je nesmírně obtížné vytvořit uživatelské rozhraní v PL/SQL.

[5] V tomto případě jsem poměřoval volání metod RMI v Javě s voláním lokálních metod. Podobné výsledky lze celkem snadno získat pro přístup k datům na bázi SQL měřením volání mimo proces proti voláním v procesu pomocí databázového produktu, který podporuje obojí, například Cloudscape/Derby nebo HSQL (Hypersonic SQL).

Reference

[Fussell] Foundations of Object Relational Mapping, by Mark L. Fussell, v0.2 (mlf-970703)

[Fowler] Patterns of Enterprise Application Architecture, by Martin Fowler

[Date04] Introduction to Database Systems, 8th Edition, by Chris Date.

FIRST Lego League Challenge

Sun, 23 Mar 2025 00:00:00 +0000

Miluju lego, jako dítě jsem si s ním neskutečně vyhrál a moje láska k němu přetrvává i do dospělosti. Nicméně pozorní čtenáři blogu vědí, že kroužek programování se snažím držet nízkonákladový, takže lego robotům jsem se dlouho vyhýbal. Učitel informatiky na naší škole, Matěj Burda, přišel s nápadem, že ho zaujala soutěž FIRST Lego League Challenge. Říkal jsem si proč ne, kroužek stejně potřeboval po letech nový impulz. Domluvili jsme se na tandemové výuce a šli do toho. Jestli soutěž neznáte nebo váháte, zda se příští rok přihlásit, tak vás může následující text navnadit, abyste se příští rok zúčastnili i vy.

Úvod

Jsem si vědom, že existuje Lego soutěž při ČVUT, u které jsem se však osobně zařekl, že se jí nikdy účastnit nebudu. Jednak používají již nedostupné stavebnice Mindstorm a hlavně mají pro mě naprosto nepřijatelné znění pravidel, viz níže. Takhle nepřátelskému prostředí nehodlám děti vystavovat. Pravidlu vyloučení rozumím, ale provedení otřesné. I na vesnickém amatérském běžeckém závodě existuje způsob odvolání.

Organizátor ROBOSOUTĚŽE (Ing. Martin Hlinovský, Ph.D.) může rozhodnout o diskvalifikaci (vyloučení ze soutěže) jakéhokoliv týmu bez dalšího vysvětlení. Jeho rozhodnutí je konečné a nenapadnutelné.

Konec plivání sírý a pojďme se věnovat FIRST Lego League Challenge. Předně jsem rád, že tedy pro lego roboty existuje alternativa. Navíc alternativa mezinárodní. Každoročně je soutěž zasazena do jiného symbolického rámce, letos se jednalo o podmořský svět.

Skládá se ze čtyř disciplín, které jsou v hodnocení ekvivalentní:

Core values, týmová spolupráce
Design
Robot race
Inovační projekt

Jednotlivým disciplínám se ještě budu věnovat, jen jsem chtěl vypíchnout, že mi to přišlo jako hodně práce (a hodně práce to skutečně je) a že je to možná zbytečné. Dnes uznávám, že je to perfektně vymyšlený systém. Děti to může mnohem víc posunout. Klade to požadavky na všestrannost, stejně tak jako běžný život, a zajistí to, že nevyhrají fachidioti.

Robot race

Nejatraktivnější disciplínou je právě robot race, na kterou jsme ostatně soustředili i my. Nejlépe vám to vysvětlí následující video.

15 misí, nemusíte splnit všechny, na pořadí nezáleží. Máte 3 pokusy, na každý 2,5 minuty, počítá se nejlepší výsledek.

Bodování mi přijde geniálně motivační, i když totiž nevyřešíte žádnou překážku, neodcházíte s nulou. Máte nějaké body, které vám zůstávají, pokud něco neshodíte (je to aspekt, který hraje roli u složitějších misí).

Když jsem viděl zadání poprvé, tak mě napadlo, že je to úmyslně navržené tak, aby to nešlo v daném čase dokončit všechno. Ale jde, viz například tohle video, ale nenechte se tím zdeptat.

Netušil jsem, jak řešení misí uchopíme, až jsem našel sympatický youtube kanál, kde mají řešení nastíněné. Tedy nemáte tam přímo zdrojový kód, ale video záznam z plnění mise a taky navržené přípravky.

Inovační projekt

Inovační projekt pro nás byl velkou neznámou. V podstatě si tým sám vybere nějaký problém, který se nějak dotýká daného tématu, a navrhne jeho řešení. Naše děti jely na exkurzi do Mořského světa, ale nakonec tuto aktivitu úplně vypustily, kvůli čemuž ztratily spoustu bodů.

Hledali jsme inspiraci u soupeřů. Jeden tým si například vybral téma odpadků na plážích a následného rozpadání na mikroplasty. Problém popsali a navrhli řešení v podobě robota, který bude prosívat písek. Na 3D tiskárně vyrobili prototyp sít třech zrnitostí a na místě předvedli. Za pomoci robota Meet Edison demonstrovali, že v písku je potřeba se pohybovat na pásech a ne na kolech.

Cena

Jak jsem předeslal, mentální překážkou je pro mě cena. Nemyslím si, že je nezasloužená (bez sponzorů by musela být ještě mnohem vyšší), ale pro někoho to možná může být nepřekonatelná bariéra. Maloobchodní cena LEGO SPIKE Prime je 12 tisíc korun, do soutěže máte 10 % slevu. Není povinný, ale hodí se, Expansion Set za skoro 4 tisíce korun. Začínali jsme se stavebnicí na trojici, ale chce to spíš do dvojice.

Startovné na jeden tým 8 tisíc korun (4 tisíce registrační poplatek, 4 tisíce herní plán). Ceně za startovné rozumím, ale nechápu, proč je povinné kupovat tolik herních plánů, kolik máte týmu (výslovně jsem se na to ptal). No nic, sadu jsme prodali spřízněnému kroužku na hraní, přesto bych firmě Lego tohle plýtvání osolil v ESG 😉.

V neposlední řadě si potřebujete vyrobit stůl na herní plán.

Aplikované přírodní vědy

Na kroužku mě baví to, že si můžeme nejenom hrát, ale že musí uplatnit i znalosti ze školy. Případně si uvědomí, že jim chybí a potřebují si je doplnit.

Jedna matematická historka. Nevím, jestli si ze mě jen puberťáci nedělali srandičky, ale to je vlastně jedno, didaktický úkol splněn. Potřebujete popojet o deset centimetrů. Jak robot ví, co je deset centimetrů? Ovládáte jen otáčky. Pojďme si robota zkalibrovat. Změřme vzdálenost, kterou ujede na 10 otáček. Naměřili 270 cm. Kolik je tedy obvod kola? V pátek odpoledne už někomu dochází šťáva, napovídám dělit deseti. Jak to lze zjistit jinak? Kontrolně měříme obvod svinovacím metrem. Výpočet obvodu z průměru vypadá, že v sedmé třídě ještě nebrali.

Přesah matematiky a fyziky. Potřebuji pohnout ramenem o 90 stupňů. O kolik pootočím motorem? Zkusí o 90 a zjistí, že to nesedí. A nesedí ani směr, protože převodovka. Poměr zubu nepočítají, ale to nevadí, přístup pokus/omyl bereme.

Pro přesné zatáčení si nevystačíme jen s ovládáním motorů. Kola můžou různě prokluzovat, robot má nějakou setrvačnost a tak dále. Rozhodovat se lze i na základě telemetrie, robot má integrovaný třísměrný gyroskop.

Didaktické poznámky

S přípravou na soutěž je dost práce. Jen v kroužku hodinu týdně by se to pořádně nestihlo. A to ještě nemluvím o inovačním projektu. Díky tandemu s učitelem informatiky, jsme měli výhodu, že se děti částečně věnovaly robotům i během vyučování či v družině.

Několik našich zvědů se jelo podívat na finále do Prahy.

Mám dojem, že děti si doma staví z lego technik podle návodu, ale už ne tolik dle vlastní fantazie. Usuzuju tak z pozorování stavby přípravků.

Nemám dostatečný statistický vzorek, ale dívky mi přijdou houževnatější než chlapci, že to u nás víc táhly.

Na příští ročník si musíme cvičně vyzkoušet vystoupení před komisí, aby je to tolik nestresovalo a získali nějakou sebedůvěru.

Rozhraní editoru i návody jsou anglicky, na to nejsou zvyklí. Rozhraní Microbit nebo Scratch jsou přeložená do češtiny. Uchylovali se tedy k automatickému překladu v prohlížeči.

Oblastní kolo Karlovy Vary

Přihlásili jsme se na oblastní kolo Karlovy Vary. Pro nás je to hrozná dálka, skoro tři hodiny autem, ale byl to nejzazší termín, takže jsme získali víc času na přípravu. Přesto za rok pojedeme zase tam. Vládla tam skvělá atmosféra. Rozhodčí velmi vřelí, dokonce i poradili (vůbec jsme si neuvědomili, že na robota se může jednou beztrestně sáhnout, tedy přijdete o jeden žeton přesnosti, ale ne o body). Kolo je takové komorní. Protože se účastní méně týmu, zbyl čas na nadstavbové klání mimo soutěž jen v robot race. Pokusíme si výlet prodloužit a domluvit exkurzi ve Witte (jeden ze sponzorů).

Neměli jsme žádné ambice, jeli jsme na účast. Chtěli jsme hlavně sbírat zkušenosti. Jednu splněnou úlohu bych považoval za úspěch. Nakonec jsme dopadli nad očekávání dobře. Jeden tým exceloval v robot race se získem 205 bodů. Jelikož úplně vypustili inovační projekt, tak je to pravděpodobně stálo postupové místo. Ocenila to i porota, udělila jim diplom „Rising All-Star“. Mně to nervy nedrásá, naopak je to super výchovný prvek, že mají příští rok máknout (naše pobídky během roku nestačily).

Python

Vypozorovali jsme, že některé týmy používaly Python. Po soutěži jse si tedy zkusili i my, ale skok na písmenkové jazyky je veliký. Existuje ještě varianta Pybricks (placené, tedy další zářez do rozpočtu). Jestli tomu rozumím správně, tak se programuje v blocích, ale vidíte výsledný Python kód (který nelze editovat). Nemáme pořádně vyzkoušené, ale na první pohled mají předpřipravené bloky pro přesné zatáčení (berou například v potaz rozvor kol) nebo zapojí gyroskop pro udržení rovného směru. Dále jsem si všiml, že robot umí vykroužit oblouk zatáčky, ne udělat prosté vlevo vbok na místě. Mělo by jít i nastavit poměr počtu zubů jednotlivých ozubených kol.

Do řídící jednotky je potřeba flashnout jiný firmware a do operačního systému nainstalovat ovladač. To je pro děti velká výzva. Co jsme s hardware zažíval jako dítě já, oni už dnes (naštěstí) zažívat nemusejí, ale ani nemají tu znalost. Beru to jako příležitost, že si můžou doplnit.

Závěr

Lego soutěž se mi líbí, příště pojedeme znovu. Příprava zabere dost času, naštěstí máme přesah z kroužku do školního vyučování. Velký úkol pro nás bude inovační projekt. Jako jednu z nevýhod vidím vyšší počáteční investici do vybavení.