Poslední příspěvky

Stran: [1] 2 3 ... 10
1
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.

2
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).
3
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í.
4
Sítě / Re:Jak získat přípojku od Cetinu
« Poslední příspěvek od Martin-2 kdy Dnes v 18:48:10 »
Ono by to i šlo, ale jako vždy tam bude že to celé zaplatíte, celá přípojka bude ve výhradním vlastnictví cetinu (prakticky jim to odevzdáte) a bude tam smlouva na odběr po dobu např 2-3 roků od jejich smluvní partnera (nepřekvapí že se jedná o O2).

Tak nějak to posledně stálo v dokumentech co řešil kolega (už je to nějaká doba).
.
5
Sítě / Re:Metronet končí, ke komu přejít?
« Poslední příspěvek od ripper6 kdy Dnes v 18:33:09 »
Jo a jen detail, JON CZ dava podepsat novou jejich smlouvu, pokud pozadate jen o navyseni rychlosti.
Je to standardni postup u operatoru?  :)
6
Sítě / Re:Metronet končí, ke komu přejít?
« Poslední příspěvek od ripper6 kdy Dnes v 18:20:19 »
Jen uvaha, mam mit fakturu od JON cz, takze zaplatit na rok?  :)

PODA je znama, pokud to vezme, pojede to tam.
Zaroven ale jestli transakce nepadne, PODA nedela VDSL, je znama ze dela optiku a 60Ghz ci wi-fi internet vzduchem  :)

7
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od BoneFlute kdy Dnes v 18:15:42 »
Nebudu ho učit serializovat se do Jsonu, nebo do Databáze, ale obecný serializování musí umět on.

Ale i obecných serializačních formátů existuje mnoho. Jeden například povolí 64-bitová celá čísla a druhý povolí celá čísla bez omezení velikosti. Jiný povolí čas na mikrosekundy, další na pikosekundy. Některé mohou řešit, jak jsou data uložena v paměti, jiné se od toho snaží abstrahovat.

Bavíme v kontextu OOP.
Serializační formát je jen jeden, ten dict, což bude nějaký slovník.
A starostí toho objektu právě je, že když používá například čísla s nekonečnou délkou, tak je napasovat do toho interface. O tom byl právě ten příklad.

Pak je další vrstva, že chci serializovat do jsonu. Která umožní přidávat další věci.

To mi nepřijde jako dobrý návrh - protože to, co už ztratíte tím dictem, se bude dost těžko rekonstruovat v další vrstvě. Proč prostě nemít jen jednu vrstvu. Bude to určitě srozumitelnější a rychlejší.

Ten příspěvek byl jako vysvětlení kdy udělat metodu a kdy ne. Ale budiž.

Srozumitelnější a rychlejší bezpochyby ano.

Nevýhoda je neflexibilita.

Ale vysvětli mi, proč bych měl tím dictem něco ztrácet? Nevidím proto jediný důvod...
A o jaké rekonstrukci to mluvíš? Přeci v rámci rozdělení zodpovědnosti já v té druhé vrstvě nic rekonstruovat nebudu. Prostě převedu co mám na to co mám. Dostal jsem dict, převedu ho na json, a json převedu na dict.

8
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od Radek Miček kdy Dnes v 18:03:37 »
Nebudu ho učit serializovat se do Jsonu, nebo do Databáze, ale obecný serializování musí umět on.

Ale i obecných serializačních formátů existuje mnoho. Jeden například povolí 64-bitová celá čísla a druhý povolí celá čísla bez omezení velikosti. Jiný povolí čas na mikrosekundy, další na pikosekundy. Některé mohou řešit, jak jsou data uložena v paměti, jiné se od toho snaží abstrahovat.

Bavíme v kontextu OOP.
Serializační formát je jen jeden, ten dict, což bude nějaký slovník.
A starostí toho objektu právě je, že když používá například čísla s nekonečnou délkou, tak je napasovat do toho interface. O tom byl právě ten příklad.

Pak je další vrstva, že chci serializovat do jsonu. Která umožní přidávat další věci.

To mi nepřijde jako dobrý návrh - protože to, co už ztratíte tím dictem, se bude dost těžko rekonstruovat v další vrstvě. Proč prostě nemít jen jednu vrstvu. Bude to určitě srozumitelnější a rychlejší.
9
Vývoj / Re:Přechod z Javy na Rust. Ano či ne?
« Poslední příspěvek od BoneFlute kdy Dnes v 17:50:54 »
Celkem jsem to musel čtyřikrát přepisovat prakticky od nuly, neboť jsem narazil na okamžik, kdy už jsem se v kódu sám nevyznal. Četl jsem, že dobrou věcí v programování je určit si nějaký svůj "styl" a toho se pak držet.
Programování už není zábava pro nerdy. Dneska je to business. Takže:
- kolik bude stát programátora číst existující kód?
- kolik bude stát kód napsat?
- kolik bude stát přidání nové funkcionality?
- cenu snižuje znovupoužitelnost
- kdy a kde nastanou chyby a kolik nás to bude stát?

Proto se vymýšlí nové jazyky, jinak by nám ten Assembler bohatě stačil.


Co vývojář, to originální osobnost. Co zadání + vývojář, to originální výsledek zpracování toho zadání. Nikdy jsem nepracoval ve vývojářském týmu. A dotaz zní: Máte také podobnou zkušenost s originalitou každého vývojáře? Mohu veřejně říci, že zpracování zadání (vývoj, programování atd.) je velice osobní záležitost?
Ano, a je to špatné. Protože to jde proti výše uvedenému.

Třeba mě se stalo, že jsem předělal nějakou část kódu a pak jsem se zamyslel nad tím, kolik práce s adopcí těch změn bude mít kolega. A nakonec jsem to zahodil jako neefektivní. Přínos mých změn byl menší jak nutnost kolegu přimět ho adoptovat.
10
Hardware / Re:Zapnutí úsporných režimů pro NVMe
« Poslední příspěvek od xnd kdy Dnes v 17:48:43 »
...
Ale už se mi stalo, že jsem koupil vážně hřejivé SSD pro PCIe 5.0 (že sice nepotřebuji PCIe 5.0, ale myslel jsem si, že rychlosti budou lepší). No a to topilo i v idle jako **** a horký to bylo i s chladičem....tak letěl.

Ve zkratce, pokud je to horké už v IDLE, měl bys uvažovat o výměně disku.
...

Plne suhlasim!
Z mojich (nie vela) skusenosti som mal raz jeden m.2 SSD disk - nejaky Adata ... ktory mal v idle 50+ stupnov.
Potom som si urobil mensi research a zistil som, ze Samsung 980 Pro, resp. vseobecne rada "Pro" ma lepsi power management a nizsiu spotrebu - a teda aj teploty v idle.

Ja uz vsade (asi v 3 miniPC/homeserveroch) pouzivam Samsung 980 Pro 2TB.
Vo svojom hlavnom desktope mam po novom aj 990 Pro, ale ten hreje o dost viac, je to PCIe 4 disk v PC co ma iba PCIe 3 tak som myslel, ze nebude az tak hriat. Radsej by som ho vymenil za starsi model.


Stran: [1] 2 3 ... 10