Příspěvky

1

Hardware / Re:Co by měl umět váš notebook?

« kdy: Dnes v 07:44:11 »

Pánové, všichni zapomínáte na vodotrysk! A taky, že musí stát jako hedvábný šátek (t.j. korunu). 

Jinak celkem souhlasím se vším, co tu zaznělo. Až na ty větráčky (pokud fakt nepotřebuji hodně výkonu, tak ať tam větráčky nejsou vůbec) a dokovací konektor (dokem je dneska monitor, stačí jeden Cčkový kabel do něj na napájení i periferie, tak proč mít na stole další krám).

2

Hardware / Re:Mají smysl disky z bazaru do NAS?

« kdy: 26. 04. 2026, 07:08:26 »

Disky zásadně nové a ne bazarovky, kde člověk vůbec neví, co jim je.

Nicméně NAS za skoro 5t. Kč jako pouhá záloha, když originály budou v PC, to moc nechápu? To je snad levnější k PC připojit externí HDD a zálohu mít na něm...

Automatická záloha každé změny vs připojování disku "když si vzpomenu," a podle "rodinných věcí" v OP asi jde o víc zařízení a lidí, takže se ta manuální otrava násobí.

3

Software / Re:Licencování softwaru s výjimkou nedemokratických režimů

« kdy: 24. 04. 2026, 05:53:02 »

Co vím, tak hlavní důsledek podobných "speciálních" licencí je, že na skutečně seriózní použití se tomu lidé (firmy) často budou vyhýbat.  Protože by to pro ně bylo riziko nebo komplikace po právní stránce.  Nechtějí se tahat po soudech a tam řešit, zda třeba USA neporušuje lidská práva...

Třeba to je taky záměr. :-) Ale v dnešní době poněkud zbytečný, stačí si zaplatit trochu tokenů a budu mít alternativní implementaci toho stejného api s vlastní licencí. A ty opravdu velké firmy něco takového dělaly už předtím i bez AI - viz třeba Google vs Oracle.

4

Vývoj / Re:Jak děláte code review?

« kdy: 06. 04. 2026, 11:35:52 »

Muzes mit automatizovane testy, ktere ti otestuji jestli mas testy a jestli ty testy testuji co maji testovat viz napr. mutation a coverage testing.

To co popisujes ty znaci, ze nemas dostatecnou duveru v pipelinu.

Pokud je to na produkci a funguje to tak je to v poradku a muze to tam byt.. .proc bych travil cas na code review kterym budu blokovat merge?

Review ale nemá primárně chytat nějaké testovatelné bugy, jak už tu zaznělo několikrát. Review potřebuješ dělat i u 100% covered codebase, protože jen neuronka (ať už biologická, nebo umělá) může posoudit, jestli jsou věci smysluplně pojmenované, rozdělené, jestli je to udržitelně napsané, jestli ty testy jsou napsané tak, aby reálně detekovaly chyby a přitom nezávislé změny nevyžadovaly hromadu oprav testů...

Jasně, mutation a fuzzy testing je v principu super, ale pokud i bez nich plný test suite běží hodiny a hodiny, tak plošná mutabilita to násobí, takže se to dá používat jen cíleně.

Pokud je to hnusno-kod kterej tam nechci i kdyz funguje tak ho proste oznacim jak technical friction ktery je potreba resit a udelam ta to ticket do pristiho sprintu... S nikym nemusim diskutovat jestli se to udela nebo ne... projektova kultura proste rika, ze tohle se bude resit... A navic muzu pridat automatizovanej test na to aby uz se to priste nestalo...

Pokud není čas na "udělat to pěkně už na prvním MR", tak stoprocentně nebude čas na přepsání později, kdy to začnou používat další věci. Tyhle tickety se přištích pár měsíců přesouvají ze sprintu do sprintu, pak se to přesune na plán na příští rok a pak se zavřou jako "not relevant after 5 years".

Casem se muze stat ze ta pipelina sama bezi moc dlouho tak se musi resit ktere veci se budou kontrolovat s kazdym MR a ktere veci pobezi prez noc...

Ano. To má být jako nějak špatně, nebo co?

#MoveFastAndBreakThings

Jo, při rozhlédnutí se je vidět, kolik lidí a firem za tuhle myšlenku schovává nekvalitní práci a věčně akumulující se technický dluh.

5

Vývoj / Re:Jak děláte code review?

« kdy: 06. 04. 2026, 09:02:57 »

Jak se firma rozrůstala, tak se přidalo code review, ale commitovalo se pořád rovnou do masteru. Výsledek: junioři se toho báli a stejně si věci dělali ve větvi a nechávali schválit před mergem, master byl věčně rozbitej (padaly testy nebo vůbec nešel zkompilovat)

Jinak řečeno, sice byly testy, ale lokálně neužitečné, protože sis je stejně nemohl pustit, dokud někdo jiný neopravil svou kupku hnoje.

My máme mergnutí do masteru/release větví podmíněné nejen review, ale i zelenou CI a approval od statické analýzy, která mimo jiné například hlídá zakázané patterny, použití ne-cryptograficky-bezpečných funkcí , nebo detekuje nové použití označených deprecated tříd a v tu chvíli vyžaduje na review approval od teamu, co vlastní tu deprecated třídu. Výsledek je ten, že k rozbití masteru prakticky nedochází (vždycky se můžou sejít dvě navzájem nekompatibilní změny dřív, než vyprší životnost CI buildu, ale to je výjimka). Ale taky je fakt, že nejsme startup a máme týmy lidí na věci, které ve startupu dělá jeden člověk, když mu zbyde prostor v pátek odpoledne.

6

Vývoj / Re:Jak děláte code review?

« kdy: 06. 04. 2026, 08:04:41 »

Delate code review pred merge nebo az po nem?
1. Vede to na to, ze lidem se nechce a zacnou delat formalni approvaly.. nebo approvujou podle toho od koho je MR...
...

Uáááá! Pokud to mergneš před review, tak všechny ty body, co vypisuješ, jsou úplně nic proti "však to už je na produkci a funguje, tak proč bych na tom review trávil půl dne." Review je buď požadavek na merge, nebo nemá smysl.

A pak to "ex post" code review muze naopak mit velky prinos.. udela se jednou za cas meeting kde se posedi a dohromady se probere co jde spravnym smerem a co jsou veci ktery by se radsi meli opravit... a vysvetli se proc a treba se to muze zdokumentovat pokud jsou v guidelines nejaky diry...

To není code review, to je možná tak architecture review, long term planning, nebo něco takového. Code review má chytit problémy (a problém není vždy jen bug zachytitelný testem) PŘED tím, než se ten kód oživí na produkčním prostředí. Ostatně, jak bez code review víš, že ta nová funkcionalita vůbec má nějaké testy a ty testy reálně něco dělají? Pak už je na to pozdě. Prevence lepší lékaře a tak.

7

Vývoj / Re:Jak děláte code review?

« kdy: 05. 04. 2026, 11:37:11 »

U LLM, ale i non-LLM kódu je potřeba hlavně pochopit, jak daný commit řeší zadaný problém. Dělá to, co má? Nedělá to něco navíc, co nebylo v zadání (pochopil pisatel kódu zadání, bylo jasné, co má dělat)? Nedělá to moc složitě (z výpočetního hlediska, struktury)? Drží to guidelines pro psaní kódu? Je kód srozumitelný, dobře okomentovaný, používá smysluplné identifikátory?

To zní, jakože na tom review musíte strávit snad stejně času jako původní řešitel, ne?

Vůbec ne. U review nemusím vymýšlet, jak to celé poskládat, nemusím si projít těch 10 slepých cestiček, a tak dál. Pokud kód následuje mě známé vzorce, tak typicky nepřemýšlím řádek po řádku, ale po blocích. Podobně jako text nečtu slovo po slově, ale jako větu (dyslektici prominou). Například ohledně zmiňované výpočetní složitosti typicky budu chytat jen vnořené smyčky, častý opakovaný un-boxing při práci s jednoduchými typy, a takové věci. Ve většině případů ale nebudu řešit, jestli tohle je o 10% rychlejší, nebo pomalejší výpočet.

Některý commit lze schválit "formálně", když člověk na první dobrou vidí, že je vše v pořádku.

Jak tohle jste schopen posoudit na první dobrou? Nebo to je myšleno spíš v kontextu triviálních změn?

Za mě tohle jsou triviální změny (ale definuj triviálnost ), nebo reviews, kde já jsem jen pro formální approval ("jo, může se použít tahle naše deprecated věc, protože to je jen přesun funkcionality z jedné třídy do druhé a existuje ticket na odstranění").

V dnešní době by ale každopádně měl první kolo code review dělat nějaký LLM, odhalí toho docela dost a rychle.

JJ, na tohle jsou ty plechovky super. U vygenerovanýho kódu jim pořád úplně nevěřím, ale review je možnost napáchat škody minimální, ale většinou něco odchytí.

+1, a z mojí zkušenosti mají větší šanci si všimnout chybějící změny, než člověk. Například přidal se nový volitelný field, to zahrnuje změnu 5 různých DTO, ale změnily se jen 4. Testy nepadají, protože se to taky přidalo jen do 4 testů z 5.

8

Distribuce / Re:Distro pro 13letého kluka na herní PC

« kdy: 05. 04. 2026, 09:19:04 »

To mi připomíná... Ještě bych doplnil otázku: Co ten kamarád, je na stejné vlně, bude motivovat syna, aby hledal cestu bez Windows? Nebo tohle jde úplně mimo něj, tobě ten Linux sice odkýve, ale jak za ním syn příjde s prvním problémem a on uvidí neznámý systém, tak ty Windows bude iniciovat sám a ještě u toho bude nadávat?

9

Distribuce / Re:Distro pro 13letého kluka na herní PC

« kdy: 05. 04. 2026, 08:42:43 »

Dřív, než tam něco nainstaluješ, se zeptej, co hraje. Protože i když spousta her už přes Proton/Steam jede krásně, tak jestli hraje třeba Fortnite, tak máš s Linuxem utrum - anticheat ochrany u tohoto typu her v lepším případě nedovolí hru na Linuxu spustit, v horším ho rovnou označí za cheatera a dají ban.

Jo a jestli má/chce třeba gamepad, tak to taky může být zábava. Například rozchodit Xbox controller s jejich 2.4GHz wireless USB donglem vyžaduje kompilaci jaderného modulu, který hledáš někde pod GitHubech, DKMS, a tyhle srandy, a jednou za čas se to rozbije.

10

Vývoj / Re:Používáte LLM při vývoji?

« kdy: 30. 03. 2026, 13:41:39 »

To se ale nevylučuje. Každý task, který řeším rozdělím na podtasky, ty řeším jednotlivě a samozřejmě v rámci toho řešení nejdřív proběhne research, pak iterace nad plánem a ještě pak fine tuning nad výsledkem. Když to tak ale čtu, je klidně možné, že mluvíme úplně všichni přesně o tomtéž.

Jo, když je to napsané takhle, tak to vypadá jako jen různé variace téhož. Můj původní komentář byl myšlený ve stylu že "přijdu z oběda, plácnu 'počítači, udělej mi logování' a jdu čučet na YouTube" nejspíš skončí tím, že se vygeneruje hromada polofunkčního bordelu, který loguje nedůležité věci, neloguje to, co jsem chtěl, ukládá logy do databáze s login údajema uživatelů místo do Elasticu, ... a tedy ve výsledku to bude čistá ztráta času oproti ruční práci.

11

Vývoj / Re:Používáte LLM při vývoji?

« kdy: 30. 03. 2026, 12:27:33 »

Nyni se LLM kodovani treba v Antigravity dela dvoukrokove. Nejprve se ve spolupraci s LLM sestavi plan, ktery se iterativne doladi a ulozi jako *.md soubor primo do projektu, pak se s LLM postupne implementuji kroky planu, onen MD soubor je soucasti kontextu.

Jo, přesně to mám na mysli tou přípravou plánu.

vyžaduje větší časovou investici hned na začátku -> horší učící křivka

Nesmysl. Nainstaluju přes npm a okamžitě jedu kompexní tasky klidně i s free modelem. Je to přebrandovaný opencode a ten není tak oblíbený bezdůvodně.

Až na to, že dostat stejnou úroveň výsledků se stejným modelem v KiloCode vs Codex vyžaduje víc babysittingu, než v Codexu a mnohem hůř to zvládá start-to-end samostatnou práci. Srovnával jsem si to tenhle měsíc, vidím, s čím a jak bojují kolegové v jednom i v druhém...

KiloCode je nutně pay-per-token api

Nesmysl, mám v tom předplatné a podporuje se nejen kilo cloud, ale i další provideři jak s předplatným, tak volitelně pay per token.

Tak to mi prosím ukaž, jak v KiloCode můžu použít to svoje $20 Gemini předplatné. Já tam totiž nic jiného, než nacpání API klíče z Google Studio AI, prostě nevidím. Jo, jasně, můžu si platit pět různých předplatných u pěti providerů, k tomu občas něco přes tokeny, a používat tím pořád ty stejné tři modely - nebo si můžu vystačit s jedním univerzálním předplatným, jen za cenu toho, že můžu použít jen aplikaci/plugin přímo od Google, protože cokoliv jiného bude chtít ten API klíč. Dtto OpenAI.

Pro jistotu, tohle není o tom, že by ten který klient něčeho nebyl schopný, tohle je o tom, že ten který AI provider má nějakou obchodní politiku.

Zkus do Codex app dostat Claude nebo Gemini.

Zase nesmysl. Běžně používám v claude code modely MiniMax a GLM. Existují i různé lokální proxy a "orchestrátory", které umožňují jednotlivé tooly a modely efektivně kombinovat (teď myslím ofic povolené postupy, nikoli vyzobávání interních oauth tokenů).
Codex CLI to umí taky.

Ok, když se chce člověk hrabat v configu, tak to tam dodat asi jde, jsem poučen. Ale pořád platí námitka o předplatném.

12

Vývoj / Re:Používáte LLM při vývoji?

« kdy: 30. 03. 2026, 09:48:57 »

Ale pokud tomu dám z prstu vycucané zadání na půl odstavce, tak to nejspíš bude odpad,

To není nutně pravda. Já osobně jsem prakticky nenapsal prompt delší než pět vět. Jenomže pak je třeba postupovat iterativně.

Z mojí zkušenosti je právě lepší udělat větší zadání hned na začátku, protože to dost oseká potřebu iterací, kde se půlka vygenerovaného kódu musí přepsat, protože něco. Nebo potřebuji mít hodně dobrou představu, kam a jak se chci dostat hned od začátku - ale to pak ten implementační plán máš už v hlavě a jen mikromanažuješ ten model podle toho plánu. Což už ale celkem slušně zvládají ty modely samy - když mají podle čeho.

Z toho pojmu "agent" se jednou zcvoknu. Ten termín mohl vymyslet jen nějaký AI hujer.

Souhlas, ale když už se to používá, tak ať aspoň lidi ví přesně, co to znamená.

Marně přemýšlím, co je na Kilo Code obecného. Jen je ho třeba nakonfigurovat, poskytnout mu dobrý index a nainstalovat potřebná MCP s nástroji. Nemá vestavěný tooling. S kvalitním modelem pak výsledky nejsou o moc horší a vlastně mohou v některých ohledech být klidně i lepší.

Obecné = nesvázané s konkrétní  sadou modelů. Zkus do Codex app dostat Claude nebo Gemini. Což zároveň znamená, že ten Codex je víc šitý na míru GPT modelům a dává lepší výsledky na první dobrou. KiloCode prostě vyžaduje větší časovou investici hned na začátku -> horší učící křivka -> když chce někdo začít, tak ho odkážu na ten ucelený balíček, který dělá víc věcí sám.

(Plus tyhle vlastní aplikace, jako Codex nebo Antigravity, jsou součástí $20 předplatných, zatímco KiloCode je nutně pay-per-token api - což pro člověka, který si to chce používat pro vlastní nevýdělečné projekty, je další faktor.)[/list]

13

Vývoj / Re:Používáte LLM při vývoji?

« kdy: 29. 03. 2026, 13:38:59 »

Postupně používám víc a víc. Je to nástroj, co může hodně pomoct, ale taky spálit hromadu času a práce. Základ je:

• Není to magie, platí, že kvalita vstupu odpovídá kvalitě výstupu. Když budu nejdřív půl hodiny přemýšlet, pak hodinu strávím chystáním implementačního plánu a požadavků, jako bych to chystal pro juniora, ve spolupráci s tou LLM, tak to potom za deset minut často udělá to, co by mě trvalo tři hodiny. A i pokud ne, tak mám aspoň užitečný plán pro sebe, protože během toho plánování si všimnu spousty speciálních případů, nejednozačností, a tak dál. Ale pokud tomu dám z prstu vycucané zadání na půl odstavce, tak to nejspíš bude odpad, ty tři hodiny strávím snahou se k něčemu dostat, a pak to stejně budu muset udělat od nuly.
• Dokumentace, dokumentace, dokumentace. Pokud to nemá dost ukazatelů a popsanou strukturu, tak si to nebude nic pamatovat, propálí hromadu tokenů na čtení existujícho kódu, a pak to stejně udělá blbě. Protože tomu bude chybět klíčová informace, co není z kódu očividná (například "k čemu ten program reálně je používaný"), nebo něco půlce práce vypadlo z kontextového okna. Naštěstí ty LLM si tu dokumentaci umí připravit - když jim to člověk řekne.
• Obrovsky záleží na tom, co za klienta používáš, a na cokoliv složitějšího, než izolovaných pár řádků, je potřeba lokální agent, ne webový chat. Stejný model, stejné zadání, ale ty řídící prompty (které nevidíš), nástroje, které ten agent má k dispozici, ... To udělá fakt velký rozdíl. A agenti na míru konkrétnímu providerovi (Google Antigravity, OpenAI Codex, ...) z mojí zkušenosti udělají lepší práci (nebo aspoň snáz to dokopeš k užitečné úrovni), než obecní agenti typu KiloCode. Nepřizpůsobíš si je tak na míru, ale to na začátku ani dělat nechceš.

* Agent = stručně řečno, klient na steroidech, který ten model diriguje do zjisti-přemýšlej-vykonej-znovu smyčky a dává tomu nástroje.

14

Hardware / Re:Zalohovanie dat na Blu-ray

« kdy: 23. 03. 2026, 09:53:31 »

S HDD (mechanické) mám takovou zkušenost že odcházejí tak po 3 až 5 letech provozu (. Další disk ať už je rotační či SDD je sázka na stále stejnou technologii a tím zvyšování rizika.

Co s těmi disky, proboha, děláte? V desktopu, který používám jako NAS mám disky staré i deset let a fungují úplně normálně. Jako ano, ty disky se tak 98 % času netočí, ale to bych od HDD používaných jen k zálohování fotografií tak nějak očekával také.

Já jednou udělal tu chybu, že jsem chtěl šetřit elektriku i disky, a nastavil jim uspávání po 10 minutách neaktivity. No, výsledkem bylo, že za den naakumulovaly desítky power cyklů a umřely do roka. Od té doby je naopak nechávám točit furt, a zatím jsem měnil jen při zvyšování kapacity a staré disky deleguju do role záloh (po kompresi se tam věci pořád vlezou).

Ale disk, co se jednou za měsíc připojí do USB, ten by měl vydržet věčnost, to souhlasím.

15

Sítě / Re:Jak spojit dvě budovy optikou?

« kdy: 11. 03. 2026, 07:32:42 »

Konektory se vaří až na konec.
Chtít protahovat zavařený kabel je totální úlet.

V případě, že je to něco firemního, co má vydělávat peníze, tak asi jo. Pokud jde o roztáhnutí internetu na velkém pozemku na chalupě, tak se počítá každá koruna. Takže pokud si to člověk neumí už navařit sám a nemá výbavu, tak objednávat si technika se svářečkou, aby dojel do Horní Dolní, vyjde na tolik, že otravovat se trochu víc s protahováním koncovek smysl dává.

Nabízí se otázka, proč to rozdělovat v místě vstupu do budovy. Proč to nenatáhnout rovnou do rozvaděče s jedním ze switchů, a z něj nepokračovat do druhého switche. Vždyť to není hydraulika, pro světlo pár desítek ani stovek metrů nehraje roli.

+1