Poslední příspěvky

Stran: [1] 2 3 ... 10
1
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od BoneFlute kdy Dnes v 21:03:54 »
Už se mi několikrát vyplatilo si ten parser psát ručně (vlastně už to ani jinak nedělám - napsal jsem si na to knihovnu se kterou se to dělá snadno). Prvotním důvodem bylo, že XSD generátory generovaly typy, co se těžko používají (tehdy jsme měli Kotlin a používali data classy a XSD generátor uměl jen tradiční Java classy s gettery a settery bez null anotací). Takže bylo vlastně míň práce parsovat XML ručně, navíc jsme díky tomu objevili, že z té služby chodí i data mimo specifikaci.

Já na jednu stranu mám rád používání různých těch automatický generátorů, ale je fakt, že ve výsledku je to kolikrát úplně stejné množství popisného kódu, protože různé výjimky a hacky. Pro mě je to sympatické, že je to alespoň deklarativní. A třeba naopak, nad XSLT jsem zlomil hůl. Je snazší a čitelnější to parsovat a serializovat v Rustu.
2
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od BoneFlute kdy Dnes v 20:59:11 »
Ale vysvětli mi, proč bych měl tím dictem něco ztrácet? Nevidím proto jediný důvod...

Protože ne všechny formáty jsou jako dict. Některé serializační formáty např. nemají názvy polí, nebo mohou vzít kus paměti, kde je struktura (s definovaným layoutem) a nic dalšího s ním nedělat. Nebo dokoknce větší blok paměti, kde je více struktur, které na sebe odkazují (třeba pomocí relativních offsetů).
Já ti nerozumím. V čem, že je ten problém?

Navíc často ten dict může obsahovat jen omezenou množinu typů, takže třeba neomezeně dlouhé číslo do něj nejde uložit přímo jako číslo, ale jako řetězec a pak se bokem serializátoru do JSONu musí říct, ať to uloží jako číslo, ne jako řetězec (i když to tak je v tom slovníku).
No a? To je správně.
3
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od BoneFlute kdy Dnes v 20:52:05 »
Ale vysvětli mi, proč bych měl tím dictem něco ztrácet? Nevidím proto jediný důvod...

Tohle už jsem komentoval někde výše. Když už se to tedy bude řešit takhle ručně (osobně bych spíš použil spíš tu reflexi a anotace nebo kód generovaný ze specifikace), tak bych tam nechal normální datové typy toho programovacího jazyka – a jejich mapování na datové typy formátu, ať si řeší ta serializační knihovna (specifika se dají upravit konfigurací, ale nevidím důvod, proč by někdo měl být nucen to ručně programovat).

Proč už nikdy nepoužiju reflexi na serializaci: To takhle jeden kolega v kódu, který jsem přebral použil reflexy nad Enum, což ve výsledku znamenalo, že pro každou hodnotu Enumu do dalo jeden int. Hezké, krásně se to namapovalo do databáze. Pak někdo přidal nový záznam do Enumu. A první odstranil, protože ten se už neměl nikdy použít. A najednou si klienti stěžovali, že se nám mrší data.

Druhá věc je ta, že pointa není zda ten serializační systém psát ručně, generovat podle wsdl, nebo jakkoliv jinak. Pointa je v tom, že já vytvořím interface, a pak mohu s maximální jistotou de/serializovat předenm neznámý objekty, stačí, když splní kontrakt.

Řeč byla o OOP.

Samozřejmě, že v praxi se hřeší. Protože výkon. Protože neznalost. Protože lennost. Protože cena.

Automatická serializace pomocí reflexe je snadná, rychlá a křehká.

Serializace podle kontraktu je bezpečná, rozložitelná do týmu, flexibilní.

Serializace objektu přímo do cílového stavu je pracná, výkonná, neflexibilní, nevhodná pro knihovní kód.
4
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Filip Jirsák (forum) kdy Dnes v 20:50:01 »
Už se mi několikrát vyplatilo si ten parser psát ručně (vlastně už to ani jinak nedělám - napsal jsem si na to knihovnu se kterou se to dělá snadno). Prvotním důvodem bylo, že XSD generátory generovaly typy, co se těžko používají (tehdy jsme měli Kotlin a používali data classy a XSD generátor uměl jen tradiční Java classy s gettery a settery bez null anotací). Takže bylo vlastně míň práce parsovat XML ručně, navíc jsme díky tomu objevili, že z té služby chodí i data mimo specifikaci.
Dělám to stejně, protože ono se to nakonec vyplatí vždycky mít to napsané ručně. Třeba když při integraci zjistíte, že protistrana posílá formát, který není v souladu se specifikací (třeba se mají posílat prázdné hodnoty jako element s nil, ale oni ten povinný element vůbec nepošlou). A když to reklamujete, dozvíte se, že jim to ale generovaný kód dělá takhle a nic s tím neudělají. Tak jsem to jednoduše vyřešil u sebe a upravil jsem parsování, a ten povinný element nebyl zas až tak povinný.

A setkávám se s tím snad pokaždé, že někdo přijde s tím, že to přece nebude psát ručně a nechá si to vygenerovat, a pak si mi chodí stěžovat, že v tom vygenerovaném kódu nejde něco vyřešit. I když teda pro JSON většinou používám automatické mapování hodnot, jenom strukturu objektů si dělám vlastní.
5
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Radek Miček kdy Dnes v 20:10:14 »
Smyslem té serializace je, že chci s někým komunikovat – typicky s nějakým externím systémem nebo třeba s jinou instancí svého programu. Proto si dohodneme nějaké rozhraní, kontrakt, který budou obě strany dodržovat, a který popisuje logickou strukturu předávaných dat případně i protokol jejich předávání. Ten koncept IDL nevznikl jen tak pro nic za nic…

A proto má smysl, aby ty objekty vygenerované z téhle specifikace jí odpovídaly 1:1 – abych mohl ve své aplikaci mohl vytvářet nebo číst libovolné struktury, které jsou dle té specifikace validní. Tady není moc prostor pro kreativitu a nemá smysl si to dělat po svém a jinak.

Už se mi několikrát vyplatilo si ten parser psát ručně (vlastně už to ani jinak nedělám - napsal jsem si na to knihovnu se kterou se to dělá snadno). Prvotním důvodem bylo, že XSD generátory generovaly typy, co se těžko používají (tehdy jsme měli Kotlin a používali data classy a XSD generátor uměl jen tradiční Java classy s gettery a settery bez null anotací). Takže bylo vlastně míň práce parsovat XML ručně, navíc jsme díky tomu objevili, že z té služby chodí i data mimo specifikaci.
6
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Radek Miček kdy Dnes v 19:52:10 »
Ale vysvětli mi, proč bych měl tím dictem něco ztrácet? Nevidím proto jediný důvod...

Protože ne všechny formáty jsou jako dict. Některé serializační formáty např. nemají názvy polí, nebo mohou vzít kus paměti, kde je struktura (s definovaným layoutem) a nic dalšího s ním nedělat. Nebo dokoknce větší blok paměti, kde je více struktur, které na sebe odkazují (třeba pomocí relativních offsetů).

Navíc často ten dict může obsahovat jen omezenou množinu typů, takže třeba neomezeně dlouhé číslo do něj nejde uložit přímo jako číslo, ale jako řetězec a pak se bokem serializátoru do JSONu musí říct, ať to uloží jako číslo, ne jako řetězec (i když to tak je v tom slovníku).
7
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Franta Kučera kdy Dnes v 19:34:27 »
Přijdete o zapouzdření, takže si zabetonujete vnitřnosti.
Jak jednou objekt serializujete, tak už takřka nemůžete překopat vnitřní reprezentaci. Nějaká aktualizace pak obvykle něco rozbije.

Ve výsledku pak občas máte vnitřnosti objektů dvakrát. Jednou pro sebe, jednou pro serializátor a přesypáváte je tam a zpět.

Smyslem té serializace je, že chci s někým komunikovat – typicky s nějakým externím systémem nebo třeba s jinou instancí svého programu. Proto si dohodneme nějaké rozhraní, kontrakt, který budou obě strany dodržovat, a který popisuje logickou strukturu předávaných dat případně i protokol jejich předávání. Ten koncept IDL nevznikl jen tak pro nic za nic…

A proto má smysl, aby ty objekty vygenerované z téhle specifikace jí odpovídaly 1:1 – abych mohl ve své aplikaci mohl vytvářet nebo číst libovolné struktury, které jsou dle té specifikace validní. Tady není moc prostor pro kreativitu a nemá smysl si to dělat po svém a jinak. Ty objekty/třídy nemám pro nějaký serializátor, ale pro podporu toho formátu a jeho logického modelu. Slouží to jako most mezi mým programovacím jazykem (abych používal normální třídy, struktury, konstanty, volal metody, funkce…) a tím formátem nebo protokolem. A tady je žádoucí dodržovat správnou úroveň abstrakce a nedovolit těm strukturám specifickým pro daný formát, aby prosakovaly do zbytku programu, který už je obecný. Takže ano, budu tam ty třídy mít dvakrát, nebo třeba jedenáctkrát, pokud budu pracovat s deseti formáty. Ale pokaždé to jsou trochu jiné struktury a data (pokud by tomu tak nebylo, tak by to znamenalo, že ten program je nejspíš vcelku zbytečný a nic moc nedělá). Tzn. mám nějaké jádro programu a v něm používám nějaké entity-třídy – to je můj datový model, který odpovídá mému záměru logice toho programu. A pak tam mám moduly pro napojení na různé externí systémy a v nich se používají třídy specifické pro dané protokoly nebo formáty. V těchto modulech je pak nějaká obchodní logika, která na jedné straně pracuje s mými entitami a na druhé straně se strukturami specifickými pro ten formát nebo protokol.

Pokud by ta aplikace měla nějaké extrémní nároky na výkon nebo požadavek, že se data nemají v paměti kopírovat, tak bych se na nějaké objekty a konstruování jejich stromu úplně vykašlal a z parseru bych emitoval události, které by se průběžně zpracovávaly… případně bych vyrobil ukazatele na části dat v té původní paměti, aby se to nikam nekopírovalo a zpracovalo rovnou na místě.
8
Sítě / Re:Metronet končí, ke komu přejít?
« Poslední příspěvek od ripper6 kdy Dnes v 19:14:56 »
Jinak co ctu smlouvu JON, casto nesedi ceny, treba castka 702czk mesicne, ale v jejich systemu ze je faktura na rok a castka 632czk mesicne.
Dal v papirech je treba cena za modem 1400czk, modem ale zadny jsem neobjednal a ani nedostal.
Je to logicke, protoze davno u nich funguju a mam i novej Terminator co umi 35b bonding.

9
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Franta Kučera kdy Dnes v 19:06:41 »
Ale vysvětli mi, proč bych měl tím dictem něco ztrácet? Nevidím proto jediný důvod...

Tohle už jsem komentoval někde výše. Když už se to tedy bude řešit takhle ručně (osobně bych spíš použil spíš tu reflexi a anotace nebo kód generovaný ze specifikace), tak bych tam nechal normální datové typy toho programovacího jazyka – a jejich mapování na datové typy formátu, ať si řeší ta serializační knihovna (specifika se dají upravit konfigurací, ale nevidím důvod, proč by někdo měl být nucen to ručně programovat).
10
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Franta Kučera kdy Dnes v 18:55:22 »
Pokud to jazyk podporuje, tak se k tomuto účelu použije spíš reflexe + případně anotace, kterými se dá upravit specifické chování a mapování.
Serializace reflexí má své mouchy. A jak je ten serializátor psaný někým jiným, jsou z toho pěkně vypasené masařky.

1) Navrhujete vnitřnosti podle toho, co umí serializátor.
Když máte štěstí dostanete třeba nekonečno a nan. Na denormály ani nemyslete. A na inty větší než 48b bych taky raději slepě nespoléhal.
Pokud serializátor není součást jazyka, tak určitě nedostanete všechny standardní knihovny.

2) Přijdete o zapouzdření, takže si zabetonujete vnitřnosti.
Jak jednou objekt serializujete, tak už takřka nemůžete překopat vnitřní reprezentaci. Nějaká aktualizace pak obvykle něco rozbije.

Ve výsledku pak občas máte vnitřnosti objektů dvakrát. Jednou pro sebe, jednou pro serializátor a přesypáváte je tam a zpět.

Tak přesně tohle je ten případ, kdy by mne zajímalo, na základě jakých zkušeností a projektů se takový komentář a názor vznikl. Nikdo z mých zákazníků bohužel (bohudík?) nechce platit za ruční implementaci de/serializátoru a za to, že se o ten nadbytečný kód budou další generace programátorů starat. Ale možná je to někde běžná praxe - právě proto bych rád věděl kde a jaké k tomu vedou důvody.

Moje zkušenost vychází hlavně z bankovních projektů. Tam serializujeme objekty do XML, JSONu případně do Avro nebo nějakých specialit typu ISO 8583. Nebo jsem dělal projekty v oboru telekomunikací a tam to bylo trochu pestřejší, formáty byly často binární, bylo tam hodně ASN.1, Radius, Diameter, SMPP atd. A prakticky vždy je snaha tuhle práci automatizovat a minimalizovat množství kódu, který se musí napsat. Takže buď se do tříd dopíší anotace nebo, lépe, se vychází ze specifikace (XSD, WSDL, Swagger/OpenAPI, Avro schéma, definice ASN.1 modulů, slovníky atd.) a z ní se generují třídy nebo něco jiného. V obou případech ale tu práci za nás dělá nějaká knihovna. Ručně jsem to řešil jen párkrát u hodně malých projektů, kde toho ručně psaného kódu bylo tak málo, že převládl užitek ze snížení komplexity závislostí.

Napadají mne ještě takové věci jako multimediální kodeky nebo implementace síťových protokolů v operačním systému nebo nějaké firmwary… ale tam se spíš než vyrábění stromů objektů ta data namapují přímo, aby se nemusela vůbec kopírovat, maximálně se narovná endianita číselných typů, ale jinak data leží pořád na stejném místě v paměti, a buď se na ně 1:1 napasuje nějaká céčkovská struktura, nebo se vyrobí ukazatele, které ukazují na části dat na tom původním místě nebo se to zpracovává proudově a parser generuje události / volá funkce a ty se průběžně odbavují.
Stran: [1] 2 3 ... 10