Planeta OpenAlt

Dnes vyšel můj nový příspěvek na stránkách SANS Internet Storm Center. Podíváme se v něm na aktivně zneužívanou zranitelnost ve službě Google Travel, která umožňuje škodlivým aktérům vytvářet odkazy směřující na www.google.com, po jejichž otevření bude uživatel přesměrován na libovolné URL…

Nabízím služby v oblasti IT, umím Linux, FreeBSD, BTRFS, ZFS a MIN.io. Umím i elektřinu včetně zkoušek 1f/3f do 400V/32A. Je potřeba jen zajistit síť.

Takže zájemci, nabízím tuto službu za nízkou cenu. Nabídky pouze emailem: tomas@heronovo.cz. Veškerá dokumentace bude vaše. Potom si domluvíme záruku na 5 let.

Drobné programování zejména evidence v PostgreSQL je jen vítané.

Svět a především všechny věřící zasáhla během velikonočního období smrt papeže Františka, jehož následného pohřbu se zúčastnili mimo jiné i světoví politici. Tyto události včetně krátkého jednání amerického a ukrajinského prezidenta v bazilice sv. Petra, jež bylo prvním setkáním po únorové roztržce v Bílém domě, ovlivnila růst kategorie Zpravodajství. Kategorie Zpravodajství rostla na obou...

Zdroj

Tak jako každý měsíc, i v květnu je tu nová epizoda speciálu podcastu ALEF SecurityCast. Najdete ji na YouTube a na Spotify a podíváme se v ní na únik dat Správy služeb hlavního města Prahy při ransomwarovém incidentu, potenciální kompromitaci účtu premiéra Fialy na sociální síti X, schválení novelizace zákona o kybernetické bezpečnosti Poslaneckou sněmovnou i řadu dalších aktuálních témat…

Zveme Vás na pátý letošní sraz spolku OpenAlt, který se uskuteční v tradiční třetí pátek v měsíci květnu 16. 5. v 18:00.

A jelikož se Brno stalo jedním z hlavních míst, kde se vyvíjí open source knihovna OpenSSL, domluvili jsme se, že se tentokrát OpenAlt komunita potká s komunitou OpenSSL! OpenSSL Corporation bude zrovna hostit Business Advisory Committees (BAC) a budete mít tak příležitost setkat se s vývojáři a vedením projektu OpenSSL!

V rámci srazu Anton Arapov z OpenSSL Corporation krátce představí projekt a jejich snahu o větší zapojení komunity do vývoje knihovny skrze nově založené OpenSSL Corporation a OpenSSL Foundation.

Zázemí nám opět poskytne Studentský klub U Kachničky na Fakultě informačních technologií Vysokého učení technického na adrese Božetěchova 2/1.

We would like to invite you to the fifth OpenAlt meeting of the year, which will take place on the traditional third Friday in May, 16th May at 18:00.

And since Brno has become one of the main places where the OpenSSL open source library is being developed, we have agreed that this time the OpenAlt community will meet the OpenSSL community! OpenSSL Corporation will just host the Business Advisory Committees (BAC) and you will have the opportunity to meet the developers and the leadership of the OpenSSL project!

During the meetup, Anton Arapov from OpenSSL Corporation will give a brief introduction to the project and their efforts to get the community more involved in library development through the newly formed OpenSSL Corporation and OpenSSL Foundation.

We will once again have the facilities provided by the Student Club U Kachničky at the Faculty of Information Technology of the University of Technology at Božetěchova 2/1.

Poslední dobou mi spousta lidí píše o radu, jak začít s cyber security. A protože přesně proto vznikl tento blog – jako můj poznámkovník a míst, kam mohu lidi odkazovat, abych nemusel věci opakovat a vymýšlet znovu, rozhodl jsem se to …

Příspěvek 🛡️ Jak začít s kyberbezpečností – stručný rozcestník pochází z Spajk

Není to sice úplně horká novinka, tohle je tam už asi rok, ale scrub by měl probíhat lineárně (výhodné pro HDD) a je to skutečně mnohem rychlejší:

scrub in progress since Sun May 4 15:57:40 2025
38.3G / 12.9T scanned at 1.46G/s

Pole typu RaidZ1 z 5 Seagate NAS disků. Tedy cca 300MB/s disk, všechny disky současně. Před tím to nebylo nijak zvlášť pomalé, pamatuji se na 600MB/s, takže jsme skoro na dvojnásobku. Rychlost čtení disků NAS je cca 200MB/s, takže se do toho může počítat i zstd komprese.

Doplnění po 4h (18TB NAS, 12TB zaplěneno):

state: ONLINE
12.9T / 12.9T scanned at 1.01G/s, 7.02T / 12.8T issued at 950M/s
0B repaired, 99% done

Jo, je to rychlé a už to kleslo na reálnou rychlost disků.

Největší český Maker Faire zamíří opět na pražské Výstaviště a to už 10. a 11. května!

Do Křižíkových Pavilonů na Výstavišti Praha se sjede několik stovek českých i zahraničních makerů, kteří představí více než 140 projektů.

Osmý ročník Maker Faire Prague opět nabídne pestrý program plný nejnovějších technologií, workshopů, interaktivních aktivit a přednášek.

A [...]

Digitální komunikační režimy zažívají na krátkých vlnách skutečnou renesanci – nejen mezi technickými nadšenci, ale i v prostředí připravenosti na krizové situace. Jako aktivní radioamatér jsem měl možnost prakticky vyzkoušet tři z nejzajímavějších programů pro digitální provoz v pásmu KV: JS8Call, VarAC a FreeData. Každý z nich má své přednosti, ale jedno mají společné – umožňují spolehlivou výměnu zpráv i při slabých signálech a minimálním výkonu.

JS8Call – FT8 s mozkem

http://js8call.com/

JS8Call vychází ze známého a velmi rozšířeného režimu FT8, ale přidává mu schopnost volného textového provozu. Oproti původnímu FT8, který je určen pro automatickou výměnu minimálních informací, JS8Call umožňuje odesílat a přijímat celé zprávy, a to i v automatickém režimu. Skvěle funguje v podmínkách slabých signálů, a přitom je velmi jednoduchý na obsluhu.

Mezi zajímavé funkce patří:

• Možnost relé (retranslace) zpráv přes jiné stanice
• Ukládání zpráv pro pozdější doručení (i přes několik stanic)
• Sdílení polohy pomocí APRS
• Využití nízkého výkonu (QRP) – běžně komunikuji s 5–10 W

Program je zcela zdarma a open source, k dispozici pro Windows, Linux i macOS. Pro nouzovou komunikaci (EMCOMM) je JS8Call díky své soběstačnosti a decentralizaci mimořádně zajímavý.

VarAC – chat s chutí profi sítě

https://www.varac-hamradio.com/

VarAC je elegantní program, který používá VARA modem, známý z prostředí Winlink. Na rozdíl od běžného "psaní přes zvukovku" však nabízí propracované GUI připomínající chatovací aplikaci. Výhodou je reálný dialog v reálném čase, velmi dobrá přenosová rychlost (hlavně s licencovanou verzí VARA modem) a funkce jako:

• Zprávy offline (store and forward)
• Předávání zpráv přes jiné stanice
• Přenos souborů
• Možnost integrace s e-mailovým systémem Winlink
• APRS pozice a beaconing

Základní VARA HF modem je zdarma, ale pro vyšší rychlosti je potřeba zakoupit licenci (cca 69 USD). VarAC jako takový je zdarma a neustále se aktivně vyvíjí. V prostředí nouzové komunikace má VarAC velký potenciál – přenos je rychlý, stabilní a zároveň nevyžaduje přístup k internetu.

FreeData – minimalistický, ale schopný

https://freedata.app/

FreeData je méně známý, ale přesto pozoruhodný projekt. Zaměřuje se na přímý přenos krátkých zpráv přes audio kanál, a funguje s velmi nízkou šířkou pásma. Nevyžaduje komplikované nastavení a běží i na slabším hardware. Je ideální pro experimentování i jako záložní kanál komunikace. V současnosti není tak rozšířený jako JS8Call nebo VarAC, ale je open source a zdarma, takže pro bastlíře a EMMCOM scénáře může být zajímavým doplňkem.

A co Winlink?

https://winlink.org/

Nelze nezmínit Winlink, robustní systém pro odesílání a přijímání e-mailů přes krátké vlny. Často se využívá v námořním prostředí a při krizovém řízení (včetně integrovaného záchranného systému v USA). Winlink lze používat i v kombinaci s VarAC, nebo samostatně přes VARA modem, PACTOR či ARDOP.

Využití v terénu: QRP i vysoký výkon

Všechny výše uvedené programy jsem zkoušel jak s výkonnější stanicí (100 W), tak i s QRP zařízeními (5–10 W) – a právě v QRP režimu exceluje JS8Call. VarAC je trochu náročnější na podmínky, ale s dobrým nastavením funguje spolehlivě i při nižších výkonech. Pokud jde o nouzovou komunikaci, je klíčové mít možnost provozu i bez připojení k internetu, s malým výkonem a...

Když už jsem to napsal na ABCLinuxu a vyřešil všechny problémy, tak to dám i sem a kdo chcete novou Teslu, tak nechoďte do Rožnova, ale do Srbska, tohle vám ani sám velký Musk neprodá. :-D

světě měl dělat, jak by to mělo vypadat na Ukrajině, co práva toho či onoho v nějaké odlehlé zemi atd. ale vůbec jí nedochází, že aby ji bral někdo ve světě vážně a vůbec se s ní bavil, tak je potřeba mít silné hospodářství tzn. mít i ten průmysl.

Rozumím a chápu, že ti to vadí. Proto jsem ti uvedl několik případů špičkové vědy, práce, technologie přímo z ČR abych tě neprovokoval EU, ze které chceš vystoupit a máš právo to požadovat. V ČR je aktuálně 3.5% nezaměstnanost, možná nejnižší na světě (tedy krom států, kde je to povinné, sice se tam vůbec nic nevyrábí, lidé nemají co jíst, nemají na čem vařit a nakazili celý svět včetně ČR virem, který by v ČR vůbec nevznikl, protože tady máme EU, sice jakkoliv špatnou ale stále nejlepší na Světě, přímo tady v česku jsem potkal tebou nenáviděného inspektora jak kontroluje víza pasy a všechno u prodejce Tureckého (NATO a kandidát do EU a člen EU celní unie) kebabu, což je sice z Německa, ale dá se jíst za 109 Kč tady v Česku. Prostě cla, měnová politika, neexistující pravidla pro průmysl USA z USA aktuálně a dnes dělá horší stát než nestát a ne-federace EU. V EU se mluví tolika jazyky, že si na to v USA museli udělat Google Translator a díky EU je možná nejlepší na světě a Musk a aktuální prezident USA se jen snaží dohnat EU a mít alespoň nějaký průmysl v USA, když ho má Evropa a minimálně i Čína (ale v podobě, že si stejně kupuju primárně Evropský a sekundárně USA HW do počítače, protože 1mld lidem v Číně trvalo tak dlouho udělat 1Gbps síťovku, že jsem si raději koupil drahý Intel, tak konečně po 25 letech mám opět Realtek a skutečně i funguje, tak já nic z toho za ohrožení EU vůbec nepovažuji, naopak USA se bude muset vypořádat s Intelem, bude muset konkurovat ARMu a RISC-V (ARM je UK, to už sice není EU, ale pořád je to Evropa) a RISC-V je projekt znuděných profesorů, kteří i Intelu chtěli ukázat, jak se dělá procesor a Intel se z toho sice poučil, x86 je stará ale stále funkční ISA (s velkou pomocí AMD, Ati z Německa a Kanady) je x86 64 Intel procesor, který se ale nemůže rozhodnout, jestli tam chce nebo nechce dávat AVX, tak to AMD udělalo za něj a Ryzeny pro desktop už mají AVX-512 a dle někoho na root.cz už je to rychlejší než Intel a staré dobré AES-NI), tak tohle všechno má původ v Evropě, takže dívat se na Muska, který má sice dobrá auta, která se někde i sama řídí a je to úspěch, ale jinak vůbec nic (Space-X používal motory nakoupené v Rusku a jsou to motory pouze do boosterů), takže ani Space X dlouho nemělo vlastní motory a to se jim už nějak podařilo, takže USA NASA už má jak dopravovat astronauty na ISS, kde se dlouho létalo jen na Sojuzech (a velmi dobře, i když velmi nepohodlně), tak Musk má Dragon Crew a lítá to tam, stejně jako Progres a Sojuz. Na Tesly z USA se čeká měsíce a na opravu jsou tam fronty (ale OK) a chodí se dívat do Německa, jak se dělají auta, vyráběná v ČR ve Škodovce, která levou zadní ještě navíc vylepšuje Temelín a pomáhá celému světu modernizovat Jaderky (kromě zbraní, za což dík). Takže Muskova teatrálnost a sem tam nějakého produktu, který funguje, tak v Číně se sice něco vyrábí ale vůbec neopravuje a elektromobily z Číny sice i jezdí, musí se řídit, ale je to prakticky jen těžko opravitelné. Lithium máme vlastní, máme vlastní akumulátory vlastní konstrukce a Škoda je zkouší montovat do vlastních holdingových aut (údajně docela OK), nabíjí se to vlastní elektřinou klidně doma v garáži a řidiči se jen bojí toho, aby to co nejdéle vydrželo, protože jim někdo říká, že EU je skanzen. 

ČEZ dodává, ČEPS funguje, jasně, rozpad EU gridu není sranda, ale i to se i díky Siemens řeší celkem přijatelně. A ještě si z toho tady celou noc můžeme dělat srandu, nikdo nás nečte, nikdo kromě anonymního admina ABCLinuxu to nikdy nemaže a nikdo nic takového ani nenavrhuje. Takže nadávat na EU jde jedině v EU a dokonce to dostane překlad do američtiny pomocí EU a Google Translátoru. Ve které zemi, kromě těch, na které a ve kterých si nemůžeš stěžovat, tohle všechno máš? Musk kromě toho, že se bojí o dodávky dalších motorů pro „jeho“ boostery a proto podporuje / nepodporuje UA (zatím spíše ano), tak nechce naštvat Putina, protože ten si taky s jeho vlastní válkou a zemí neví rady, stejně jako Trump (který teda zatím neválčí zbraněmi, ale jen řečmi). Mě by v práci nejvíc pomohl překladač Angličtina – Čeština a paralelně Ukrajinština, protože nic z těch dvou posledních fakt neumím a do Bruselu to posílat pro úřední překlad opravdu nebudu a nemůžu. To je asi tak jediná chyba, kterou jsem na EU za tyto diskusi našel. Nasadit AC-DC kapelu a k tomu 1MV vedení přes hranice (na západ), protože DC se lépe syncuje než AC na 50Hz, umíme to vyrábět tady u Olomouce, ale je to prostě drahé. Takže překladač na standardní zásuvku DC 1MV a překlad do češtiny a ukrajinštiny, pokud možno tajně a šifrovaně. Tohle jestli někdo zařídí, tak ho volím. A jako volební písničku něco od ACDC-DCAC 

Hmm, Švédské Spotify taky neumí 1MV, tak nic, nevolím EU, už ani ten Thunder nefunguje:

https://www.youtube.com/watch?v=gqs8bRMhBgA

Alespoň k něčemu je je Tesla 1MV ACDC dobrá, ehm, to je vlastně Jugoslávec. Tak nic, nejdu k volbám :-D

Koupil jsem si dvě 2.5Gbps síťové karty Realtek za velmi dobrou cenu, namontoval do dvou počítačů a propojil měděnou kabeláží CAT5e o délce cca 3m. Funguje to, rychlost kopírování (Samba a SCP) mezi dvěma stroji je reálně na SSD vs NVMe oběma směry cca 220MB/s. Realtek tedy v roce 2025 funguje!

Poznámka: Kabel jsem si krimpoval sám dvěma nestíněnými RJ45 konektory. Nejedná se o žádný kabel s certifikací na 2.5Gbps, ale i tak to funguje, linka je na obou stranách (Windows 11 a Debian 12) detekována jako 2.5Gbps a data tečou 2.5x rychleji, než na předchozím gigabitu. Do důchodu jde tedy síťová karta Intel Pro Desktop 1Gbps. Zatím není na prodej.

Stejně jako v každém zaměstnání tak já jako řadový zaměstnanec hodnosti Vyšší Referent IT na MPVS, pracoviště Olomouc, jsem musel projít vstupním školením a takzvaným adaptačním plánem. Tento článek nebude nudný ani pro IT v soukromých firmách a ani pro ostatní zaměstnance.

Součástí nástupu na Ministerstvo je vstupní školení, které probíhá týden, reálně jsem to měl za dva dny, tedy 4. 12. 2024. Ve vstupním školení se dozvíte, co se od vás chce za práci, jaké výkony máte podávat (počet opravených počítačů a tiskáren za měsíc) a kolik za to dostanete peněz. Tohle se vyhodnocuje (a termíny budou v tomto článku nutné pro pochopení závěru pro IT) do 1 pracovního týdne od nástupu zaměstnance, u mě to vycházelo na 10. 12. 2024. To jsem splnil, měl jsem osvědčení o nástupu a absolvování kurzu, měl jsem řidičský test, ověřili si řidičák a měl jsem tedy možnost řídit firemní motorové vozidlo. To jsem reálně využil až v březnu 2025.

Následuje seznam dokumentů, které jste povinni přečíst, zapamatovat a prokázat v testu. To znamená znalost prostředí, adres, jednotlivých oddělení na pracovišti (všechny budovy MPSV v okresu Olomouc, zejména 3x lokalita Vejdovského 4, Kosmonautů 8, Litovel, Uničov, Šternberk). Všechna místa mi můj mentor ukázal osobně a seznámil mě s vedoucími pracovníky. Do Litovle, Uničova (dvě budovy) i Šternberka jsem jel v prosinci 2024 dvakrát a cca 25x jsem prošel všechny lokality v Olomouci. Takže do 31. 12. 2024 splněno a tento adaptační plán byl splněn a ověřen mým mentorem. V Lednu byl celkem klid, protože jsme byli připraveni s bývalým kolegou již v na konci prosince, takže ani nová digitalizace Jenda (oblast zaměstnanosti) a asistované podání nepřineslo v práci oddělení IT žádné komplikace, jen se za leden vytisklo více papírů a vyměnilo více tonerů. Všechny tiskárny byly koncem prosince opraveny v záruční lhůtě, takže tisk byl od 1.1. 2025 zcela v pořádku a každý úředník měl kde a na co tisknout i se záložní tiskárnou (tedy každý úředník má primární, sekundární a v některých místech i terciální tiskárnu – bude velmi důležité pro ajťáky dále, ukážeme si to na datovém úložišti).

Únor celkem pohoda, v březnu jsem si udělal servisní výjezd do Litovle a Šternberka. Včera posledního dubna 2025 se tento adaptační plán ukončil, podepsal jsem jej já, přidělený mentor i vedoucí.

Zpět do IT

Nemám v popisu práce a v některých případech mám přímo zakázáno zkoumat a uchovávat některé dokumenty, které nepatří do IT. Což nedělám, nepotřebuji mít kolem sebe tunu papírů, já rád tunu disků.

Krom práce pro Ministerstvo jsem také předseda SVJ a předseda Spolku. Tohle chci ukončit letos, aktuálně je vývoj spíše pozitivní, termín je 29. května, kde rozhodnou vlastníci a zákonný termín pro ukončení vyúčtování do 31. 8. 2025 (já vám říkal, že termíny jsou důležité). Co to znamená pro Herona? Celkem nic. Roznést, poslat emailem nebo doporučeným dopisem 32 vyúčtování. Do konce dubna hotovo cca 90%, do konce května bude 100% (dostal jsem to ve středu). Dále je 30 dnů na reklamaci a následně zákonný termín 31. 8. 2025 pro výplatu a výběr přeplatků nebo nedoplatků. To je na velmi dobré cestě, lidé očekávali své částky na vyúčtování, takže počet reklamací je zatím nula, ale jsou na to stále dva měsíce a do konce srpna 4.

Co to teda znamená pro ajťáka?

No jednoduše, dokumenty mají svou dobu platnosti a následně je daná osoba musí buď skartovat nebo archivovat. Já archivuji vše na HDD, pro pracovní data slouží NVMe nebo SSD. V papírové podobě to archivuje účetní nebo dodavatel tepla a elektřiny. Pro mě to v zásadě znamená, že vyúčtování o velikosti 2MB na bytovou jednotku, tedy cca 70MB na celý dům musím archivovat minimálně do 31. srpna 2025, tedy zákonného termínu pro reklamace, vyplacení a výběr od vlastníků. Takže do 31. srpna 2025 musím nutně držet buď v papírové, nebo v mém případě samozřejmě ideálně digitální podobě šifrovaný archiv. A ten mám. Mám stále hromadu (16) funkčních zdravých HDD a data ukládám minimálně na dvě offline zálohy. Nutně tedy potřebuju tři disky: NVMe pro živá data a dva HDD pro archiv do konce srpna. 70MB se tam zcela bez problémů vejde, jsou šifrovaná 256b klíčem přes AES-256. Potom je můžu smazat a případně si uchovat jen výsledky reklamací.

Co to znamená jinak, já přece fotím.

Ano fotím a celý můj archiv RAWů je cca 600GB ve formátu CR2 (Canon Raw 2) nebo otevřeného DNG. Jako dlouho je musím držet? Nemusím vůbec fotit, takže nula. Jak dlouho je chci mít? Minimálně do doby exportu (Darktable nebo LightRoom) do jpeg nebo webp. Což je tak maximálně týden. Fotky v RAW mají průměrně kolem 25MB, export do 1500×1000 (Canon je 3:2 foťák) se vleze do 3MB (ve webp ve větší kvalitě než jpeg). Kolik jich tak musím držet? – no nemusím nic, ale chci držet cca 10% těch nejlepších fotek.

Fotím tak, že si vyberu vhodnou lokalitu a vyfotím celou CF kartu (8GB), což je cca 305 fotek v RAW (číslo udávané přímo foťákem Canon 50D, občas je to 400 fotek na kartu). Export 10%, tedy 800MB RAW se do webp vleze do 61MB. Jak dlouho je potřebuji držet, kromě odpovědi vůbec? No co nejdéle. :-) Mám fotky z Panasonicu z roku 2004. Všechny fotky z Canonu (tedy cca 24 000) chci mít, jak v RAWu, tak v exportu jpeg/webp. Kolik disků potřebuji? No … jeden HDD a jeden NVMe. A oba mám. Kromě dalších 15HDD a 3SSD. :-D

Takže nakonec možná trochu nudné, ale proč to píšu. Stejně jako se u nás v práci něco archivuje celý život (rodný list apod), něco po dobu platnosti (OP a Pas a Vízum mají omezenou dobu platnosti známou už při vydání průkazů), tak stejně soubory a je jich většina, má omezený život. Fotografie desky plošných spojů nefunkčního mikrofonu Sennheiser je dobrá tak hodinu, protože si najdu vadné součástky, najdu si je v obchodě a po odeslání objednávky už tu fotku nepotřebuju, protože ten mikrofon tam leží několik let, takže stejně si jej budu fotit znovu při opravě a testech. Životnost této 7MB fotky z dobrého foťáku je tedy cca 1hodina. Potom může jít do koše ve Windows tedy 30 dnů. Na to fakt stačí jeden NVMe levný disk. A když ten disk selže, tak fotka je stále v koši ve foťáku. Netřeba archivace tohoto konkrétního souboru, stejně jako si nenechávám propadlou občanku, pas a řidičák.

Takže pro mé vlastní RAWy z Canon 50D to sice znamená nekonečno, ale pokud někdy umřu, na což to zatím nevypadá, tak to budu držet. Disky mám na dvou lokalitách, je to na kartách které nějak moc nemažu, je to často na Google Photos a je to na serveru u Hetznera ve Finsku. Takže jedna primární lokalita (Finsko), druhá pracovní lokalita (ČR) a jedna dočasná lokalita (CF karty). Vše mám, vše funguje, Finsko je ve velmi dobrém stavu a snad to tak zůstane co nejdéle. A jestli někdy Rusové přijedou do Finska, tak už budu dávno mrtvý rukou ruského vojáka nebo českého trolla podporujícího Rusko. Takže o fotky je postaráno. A moje vlastní TTL je dle aktuální statistiky cca 39 let.

Původně jsem plánoval poněkud obsáhlejší článek na téma HiFi na PC, začnu ale rovnou od prostředka. Jednou z mimořádně důležitých věcí v audio řetězci je kvalita DAC převodníku.

Všude jen Realtek

Situace s audio technikou na trhu PC byla dost tristní. Každé PC má integrovaný zvukový čip (většinou Realtek HD Audio), takže tlak na další zvukové karty ze strany uživatelů PC prakticky neexistuje. Prodejci nabízejí jen pár kusů (a to ani ne skladem) a výrobci vymýšlí všechno možné (čím víc efektů tím víc Adidas – už hodně dlouho různé vylepšení jen pro hraní her) jen ne karty pro poslech. Aby toho nebylo málo, tak skutečné HiFi zvukové karty se omezují na USB nebo FireWire rozhraní se software především pro MacOS. Pro PCI-E neexistuje téměř nic.

Čip Realtek HD Audio není špatný. Papírově umí 192kHz a 24b, reálně to opravdu umí (změřeno) a to ještě na 9 výstupech. Jenže tento DAC není na základní desce sám, ba právě naopak. Není prostor pro dostatečně kvalitní napájení (DAC a hlavně ADC si umí říct o pěkný proud až jednotek ampér špičkově a je přirozeně citlivý na stabilitu napětí), dále zde často není žádné stínění a do zvuku se tak dostávají ruchy z ostatních komponent počítače. Kdyby tento čip někdo dal do vhodného prostředí, mohla by z toho být dostupná zvuková karta.

Někde i ti TI

Dostupné jsou USB DAC. pěkný kousek s DAC od Burr-Brown (dnes Texas Instruments) vyrábí Behringer, např UCA222) jsou většinou omezené pouze na 44.1/48 kHz. (Na druhou stranu inženýři B-B z toho dokázali vytěžit úplné maximum a tyto DAC jsou i na 44.1kHz opravdu poslouchatelné.)

Na firewire jsme na tom mnohem lépe, alespoň co se výběru hardware týče. Nahrával jsem na M-Audio FW Solo, což je, dle mého názoru, ideální zvuková karta pro HiFi PC, jenže ta má ovladače (kromě obligátního MacOS) jen pro Windows. Takže taky nic.

Ano ale nikdy není tak dobře, aby nemohlo být ještě líp:

Audioquest DragonFly

Existuje několik projektů, které tuto nelehkou situaci se zvukem na PC chtějí řešit. Jedním z nich je Audioquest DragonFly. V Linuxu (Debian toho času Jessie) funguje bez problémů, ovladače jsou přímo v Alsa. Na otázku zda to funguje ve Windows neumím odpovědět, nezkoušel jsem (tam mi funguje M-Audio).

Trochu špinavý denně používáný DAC DragonFly. Vejde se do kapsy džínů ke sluchátkům Behringer InEar 32ohm. Je trochu tišší, ale to je do sluchátek na cesty na kole jedině dobře.

DragonFly je jednak špičkový DAC (umí i 88.2 a 96kHz v 24b rozlišení) a také a hlavně předzesilovač schopný přímo budit měniče ve sluchátkách i s vyšší impedancí (nemá žádný problém ani s 250ohm Beyerdynamic T70). Výstup z DF lze samozřejmě použít i jako linkový vstup do zesilovače.

Něco novějšího pro Windows na USB

Používám HiFi zvukovou krabičku (to už fakt není karta) Roland Rubix 44. Po stránce signálové je vše ve studiové kvalitě a po stránce software tak jednoduché, jak je to jen možné. Přes USB Audio standard se OS dozví, že to má 4 vstupy a 4 výstupy, nemá to žádné softwarové ovládání hlasitosti, takže k tomu nemusí být žádný ovládací panel. Rubix funguje ve Windows 11 a Linuxu Debian 12 prostě po zapojení do USB-2.

Má to signálové vstupy pro mikrofon – kondenzátorový nebo dynamický, pro kondenzátorový to má vypínatelných 48V, které naopak dynamický vůbec nepotřebuje. Je výhodné to mít vypnuté ne proto, že by to mikrofon zničilo, ale proto, že se tím vypne zdroj rušení a to je 48V zdroj. Dále je možné zapojit kytaru, dokonce i na vysokou impedanci (to nemám, takže bez ověření a vyzkoušení). Kondenzátorový mikrofon Behringer C3 funguje a profesionální dynamický Rode Procaster funguje ještě lépe. Obé připojené pomocí XLR konektorů a do toho kondenzátorového jde i 48V.

Výstupy jsou potom klasické 4x XLR (symetrické i nesymetrické), potom 4x Jack 6.3mm přímo do zesilovače. Na přední straně krabičky je výstup na sluchátka 6.3mm stereo. Umí to hrát do 250ohm Beyerdynamic 990Pro a Beyerdynamic 250ohm T3. Někdy až moc hlasitě (na tohle jsem si stěžoval už v článku před 10 lety, nemá to žádnou možnost automatické potlačení výstupní hlasitosti, tak s volume control do sluchátek velmi opatrně – pro dynamickou nahrávku od skupiny Dire Straits je potřeba opravdu nejít ani do 25% volume, protože na profi sluchátkách to stačí).

Tolik revize článku po 10+ letech, stejně jako kontrola nových mikrofonů pro kolegu z práce. Tak dobrý poslech všem. Mikrofon Sennheisser sice nefunguje, ale to se vědělo a v kanceláři je další bezdrátový plně funkční. Já mám pro dnešek splněno. :-)

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.

Tisková zpráva Praha, 28. dubna 2025 – Online reklama v roce 2024 dosáhla 64 miliard korun, což představuje meziroční nárůst o 7,5 %. Nejvíce k tomuto výsledku přispěla display reklama (+9,5 %) a programatický nákup display reklamy (+11 %), mírný růst zaznamenala i reklama ve vyhledávání (+3 %). Odhad růstu pro rok 2025 je 6,7 %. Zadavatelé v roce 2024 investovali do internetové...

Zdroj

Na portálu Root.cz byl dnes publikován můj nový příspěvek do seriálu Postřehy z bezpečnosti, v němž se podíváme schválení novely zákona o kybernetické bezpečnosti, novou verzi rámce MITRE ATT&CK nebo pokračující podporu cookies třetích stran v Chromu…

Jsem administrátor databázových serverů od roku 2009 a vše výhradně na PostgreSQL. Je to skvělá databáze, Pavel Stěhule o ní píše perfektní články na root.cz i do různých diskusních webů. Pavel píše zejména o velmi složitých SQL dotazech a jejich optimalizacích. Já jsem napsal více než 10 článků o nastavení serveru (HW), virtuálních serverů (vmware), kontejnerů pro Linux (nspawn) a pro FreeBSD (jail).

Jenže pro další appku už mi stačí interní věci ve standardní knihovně v Golangu, data ukládám pomocí GOB a pokud je vyloženě potřeba načíst velký SQL soubor, tak používám SQLite a v Golangu je pro SQLite k disposici knihovna.

Velké soubory už se do PostgreSQL nevejdou, datový typ BYTEA má velikost pouze 1GB. Proto jsem chvíli (no už to budou také 4 roky) používal projekt MIN.io (aktuálně asi 2TB dat, zejména vlastní fotky v RAW). Uloženo na dvou discích typu mirror. Už nepotřebuji ani FreeBSD ZFS pole. Dneska stačí 2x SSD 2TB.

Proto jsem si napsal poslední projekt (domácí TODO list místo Google Keep) v čistém Golangu (webová appka) pomocí pouze standardní knihovny aktuálně verze 1.24. Moje potřeba jazyka SQL je nulová a znalosti mi stačí na vytvoření schématu s 20 tabulkami a zajištění referenční integrity. To umí SQLite také a hlavně to umí Golang sám.

V práci používáme komerční Oracle, vědí o free PostgreSQL, ale zatím stále máme zaplacený Oracle.

Já osobně tedy po 17 letech PostgreSQL opouštím. Na příští víkend mám ve svém TODO listu již naplánovanou migraci dat z PostgreSQL do SQLite a v projektu je cílem se zbavit i SQLite (do dvou let – stihnu to pravděpodobně do konce června 2025).

Díky tedy PostgreSQL i Pavlu Stěhulemu za jeho články a i panu Vondrovi za pořádání skvělých konferencí na MMF UK v Praze, kde jsem mohl fotit a psát články na LinuxEXPRESS a ABCLinuxu. Díky moc.

Asi 20 let trpím alergií na pyl ze stromů, především z břízy. Minulý týden jsem ležel v nemocnici, v čistém pokoji s filtrovaným vzduchem a dostával jsem prášky na spaní. Za týden cca 100h spánku a k tomu první dva dny maska s lékem prostřednictvím aerosolu. Tento týden už jsem v práci a čistím si vzduch doma pomocí PC. A takhle to tam teď vypadá.

Určitě vy ostatní ajťáci také chcete mít PC bez prachu, takže používáte filtry. Stačí dva 12cm ventilátory nastavené na 600rpm, takže jsou tiché a mohou běžet celou noc (PC Windows 11 na sleep a UEFI nemusí vypnout ventilátory v bedně). Spotřeba cca 5W a za noc je vzduch čistější než venku!

Mám tu klasickou PC bednu a má vlastní filtry pro zdroj a nasávání vzduchu přes přední masku. Za ní dva 12cm ventilátory. Přední masku lze snadno vyjmout a 2x denně vysprchovat pod studenou vodou. Uschne do 30 minut a lze jí dát zpět do PC. Pro zvýšení účinnosti lze přidat HEPA filtr ze sáčků do vysavačů.

Vyrenderoval jsem si úvodní scénu pro aktuální Blender LTS. Poslední verze je 4.4, ale ta bude pouze update a není to long time support.

V 23. dubna 2025 19:00 se v Olomouci blížila krásná bouřka. Blesky večer jsem nefotil, tolik jich zase nebylo a oblaka-země ani jeden viditelný z mého místa. Foceno na Canon 50D, objektiv Canon L 200mm F4. ISO 100. Export v Darktable.

Tento týden se Praha stává centrem evropského hnutí za svobodné znalosti. V pátek 25. dubna se ve večerních hodinách uskuteční panelová diskuze „Wikipedia meets AI: Online communities and their approaches“, kterou pořádají Wikimedia Europe a Wikimedia Česká republika. Debata se koná v Galerii České spořitelny v Rytířské ulici od 18:00 do 20:00.

V rámci diskuze vystoupí zástupci evropských poboček Wikimedia i externí hosté, kteří se zaměří na dopady generativní umělé inteligence a velkých jazykových modelů (LLM) na komunitní projekty jako Wikipedia. Témata budou sahat od přínosů AI pro efektivitu a správu komunit až po výzvy v oblasti důvěryhodnosti informací a podpory lidské kreativity. Pozornost bude věnována také roli Evropské unie v regulaci AI a ochraně veřejného informačního prostoru.

Mezi potvrzenými hosty jsou:

• Elisabeth Carrera, výkonná ředitelka Wikimedia Norsko
• John Cummings, konzultant Wikimedia Švédsko
• Franziska Heine, výkonná ředitelka Wikimedia Německo
• Rebecca MacKinnon, viceprezidentka pro advokacii ve Wikimedia Foundation a členka představenstva Wikimedia Europe
• Věra Jourová, prorektorka Univerzity Karlovy pro rozvoj lidských zdrojů a nových technologií

Debatu pořádá Wikimedia Europe ve spolupráci s Wikimedia Česká republika jako doprovodný program k Valnému shromáždění Wikimedia Europe, které se letos již potřetí koná v Praze. Shromáždění sdružuje zástupce evropských Wikimedia poboček a partnerských organizací a bude probíhat od 26. do 27. dubna 2025.

Kontakt:

Hynek Kaplan
PR specialista WMČR
hynek.kaplan@wikimedia.cz
+420605039405