1
Bazar / Re:Sháním notebook s Windows 98
« Poslední příspěvek od balkovic kdy Dnes v 00:56:51 »Chceš to k nejakému zariadeniu, ktoré má obslužný softvér pre win98, na retrogaming, alebo na čo?
Poslední příspěvky
2
Vývoj / Re:Jak děláte code review?
« Poslední příspěvek od LeosB kdy Dnes v 00:32:49 »"Ex post" code review absolutně nefunguje, protože pak už nikdo nemá žádný důvod se mu věnovat. Jediné co funguje je vydírání tím že nebude povolený merge dokud se nedořeší code review.
3
Bazar / Re:Sháním notebook s Windows 98
« Poslední příspěvek od RDa kdy Dnes v 00:23:55 »Tak na to mas dost veliky rozsah.. od prvnich P1 az po P3, a ten vykonovy rozdil je znacny.
Co to trocha vice specifikovat co mas za pozadavky?
Jinak si na aukru vyber jeden ze sta, ktery se ti libi.
Co to trocha vice specifikovat co mas za pozadavky?
Jinak si na aukru vyber jeden ze sta, ktery se ti libi.
4
Vývoj / Re:Používáte LLM při vývoji?
« Poslední příspěvek od balkovic kdy 05. 04. 2026, 22:50:02 »u nás je to taky, ale je to klasickej hype cyklus. Potkalo to kdysi mě s Clojure, potkalo to lidi okolo Rustu a teď prostě máme k dispozici vhodnej nástroj, ale zase je dobré znát jeho limity (a to jsem trávil dnešek reviewingem slope kódu od našich mladších kolegů :/)
Rust by som vylúčil z výčtu, to nie je hype, ale prirodzená evolúcia. Sú tam vyriešené veci, po ktorých sa 20 rokov volalo v akademických kruhoch. Ale Rust má veľkého kostlivca v skrini - mikrozávislosti. Môj brat na to nadáva, lebo keď mu dajú nejakú aplikáciu napísanú v Rust na review, tak proste musí riešiť zanzilión knižníc miesto pár. A všetky majú svoje bezpečnostné riziká, svoje licencie. Ten jazyk to len podporuje, keď ťa skoro nič nestojí pridať ďaľšiu závislosť, tak ju pridáš .... Tam Rust môže padnúť na hubu.
A čo sa týka AI, tam som trochu optimista. AI sa akosi nedarí vyprostiť z juniority, bude to chcieť skokové zlepšenie a to bude neviem kedy. Stále musí byť primát prítomný, aby to dirigoval a mikromenežoval.
5
Bazar / Re:Sháním notebook s Windows 98
« Poslední příspěvek od Ledmed kdy 05. 04. 2026, 22:46:36 »Jen takovy napad - nestacila by virtualka s w98? Ve virtualkce by snad w98 mohly bezet OK. HW s w98 se bude hledat hodne tezko.
6
Vývoj / Re:Jak děláte code review?
« Poslední příspěvek od listoper kdy 05. 04. 2026, 22:32:51 »Jeste je zajimave se na to podivat z jineho pohledu.
Delate code review pred merge nebo az po nem?
Protoze tzv. gatekeeping code reviews ktere nedovoluji neco mergnout dokud nebude approvnuto jsou trochu dvojsecna zbran (jako vsechno... .)
1. Vede to na to, ze lidem se nechce a zacnou delat formalni approvaly.. nebo approvujou podle toho od koho je MR...
2. Vede to na to, ze si clovek rekne ze to po nem nekdo jeste zkontroluje takze je to sdilena odpovednost a treba nedava takovej pozor... ("Stejne mi to na poprvy vratej s poznamkama tak co bych se s tim drbal")
3. Vede to na to, ze se tolik netestuje a automatizace je na druhe koleji...
4. hrozne to zpomaluje flow... (mam treba rozdelany 3 pull requesty zaroven a tlacim je prez code review 3 dny nez si lidi udelaji cas na review zapracuju pozadovany zmeny apod.. )
Pokud naopak mam takovej test suite, ze tomu verim a mam v pipeline lintery a vsechny mozny udelatka co kdyz jsou spravne nastaveny tak spravne shodi build... A pak mam spravne nastavenej deployment a observability stack kterej sam zareaguje treba uz pri nasazeni na 10% podu ze nejaka metrika vykazuje anomalie a udela automatickej rollback... Tak muzu mit duveru v to, ze to proste pustim az na prod. A pri prusvihu mam zase tooling abych mohl rychle jit zpet.. nebo rychle zafixovat...
Zalezi na tom... pokud mas mission critical systemy (treba vesmir a letectvi) nebo dokonce life-critical (skoro cokoliv ve zdravotnictvi) Tak se to musi hodne zvazit treba ten cas a energii do toho dat... ale jinde muze byt vyznamne levnejsi to proste "poslat"
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...
U me na tom PoC co rozebiram v jinem tematu je zajimave jak se CR posouva do SR(Spec review).
Uplne krasny je, kdyz dokazu dodat tu specku ktera ma v sobe u kazdeho usecase tlacitko ktere spusti odpovidajici test case. Na to si uzivaci hrozne rychle zvykaji a pri dostavam krasnej feedback a kutej mi tam corner cases kde to zkousej rozbit..
Delate code review pred merge nebo az po nem?
Protoze tzv. gatekeeping code reviews ktere nedovoluji neco mergnout dokud nebude approvnuto jsou trochu dvojsecna zbran (jako vsechno... .)
1. Vede to na to, ze lidem se nechce a zacnou delat formalni approvaly.. nebo approvujou podle toho od koho je MR...
2. Vede to na to, ze si clovek rekne ze to po nem nekdo jeste zkontroluje takze je to sdilena odpovednost a treba nedava takovej pozor... ("Stejne mi to na poprvy vratej s poznamkama tak co bych se s tim drbal")
3. Vede to na to, ze se tolik netestuje a automatizace je na druhe koleji...
4. hrozne to zpomaluje flow... (mam treba rozdelany 3 pull requesty zaroven a tlacim je prez code review 3 dny nez si lidi udelaji cas na review zapracuju pozadovany zmeny apod.. )
Pokud naopak mam takovej test suite, ze tomu verim a mam v pipeline lintery a vsechny mozny udelatka co kdyz jsou spravne nastaveny tak spravne shodi build... A pak mam spravne nastavenej deployment a observability stack kterej sam zareaguje treba uz pri nasazeni na 10% podu ze nejaka metrika vykazuje anomalie a udela automatickej rollback... Tak muzu mit duveru v to, ze to proste pustim az na prod. A pri prusvihu mam zase tooling abych mohl rychle jit zpet.. nebo rychle zafixovat...
Zalezi na tom... pokud mas mission critical systemy (treba vesmir a letectvi) nebo dokonce life-critical (skoro cokoliv ve zdravotnictvi) Tak se to musi hodne zvazit treba ten cas a energii do toho dat... ale jinde muze byt vyznamne levnejsi to proste "poslat"
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...
U me na tom PoC co rozebiram v jinem tematu je zajimave jak se CR posouva do SR(Spec review).
Uplne krasny je, kdyz dokazu dodat tu specku ktera ma v sobe u kazdeho usecase tlacitko ktere spusti odpovidajici test case. Na to si uzivaci hrozne rychle zvykaji a pri dostavam krasnej feedback a kutej mi tam corner cases kde to zkousej rozbit..
7
Bazar / Sháním notebook s Windows 98
« Poslední příspěvek od Andrisek50 kdy 05. 04. 2026, 21:56:17 »Dobrý den potřebuji notebook s windows 98 funkční Děkuji
8
Distribuce / Re:Distro pro 13letého kluka na herní PC
« Poslední příspěvek od Karmelos kdy 05. 04. 2026, 20:06:47 »Pokud kluk není Linux pozitivní už teď, tak mu tam dej Windows, legální verze stojí pár stovek. Nic jinýho nemá smysl.
9
Distribuce / Re:Distro pro 13letého kluka na herní PC
« Poslední příspěvek od hlp84939 kdy 05. 04. 2026, 17:10:02 »Třeba tak, že MS Office je nativně podporován jenom na Windows.Přesně tak. Nehledě na to, že ten PC tutově nebude používat jenom na hry, ale třeba taky na office (Word, Excel, PowerPoint), takže Windows jsou jasná volba.Jak souvisí kancelářský balík s Windows?
10
Vývoj / Re:Jak děláte code review?
« Poslední příspěvek od Pavel Tišnovský kdy 05. 04. 2026, 14:50:24 »Ahoj.
Zejména (ale nejen) v souvislosti s nástupem LLM generátorů kódu mi vrtá hlavou, jak přistupovat ke code review. Jak je děláte u Vás?
Je to jenom formalita, kdy to bezmyšlenkovitě odbouchnete?
Procházíte každý řádek změněného kódu a zamýšlíte se nad tím, jako byste to psali sami?
V našem týmu se to bere spíš jako formalita vynucovaná architekty, takže si to většinou bez čtení schválíme a jdem dál. Je to norma?
Máte nějaký metody jak si code review zefektivnit či zrychlit?
Záleží, k čemu se code review dělá. Jestli je to "jen" kvůli zajištění nějaké maintainability nebo i proto, aby se junioři něco nového naučili. U nás se snažím už jen o to první, protože předávání informací k juniorům přestalo (i "díky" LLM) být funkční a ani to asi není vyžadované. Takže: zapnuté všechny možné lintery s docela přísnými pravidly, definované agent.md s poměrně přesnou speckou, jak má kód vypadat, skills pro vývojáře, první nástřel kontroly je přes LLM a potom nastupuje ruční review, které je hodně časově náročná a vlastně i nevděčná činnost.
