Příspěvky

napsal jsem ti.

To máte poněkud vlastní definici slova pattern. Mícháte jabka s hruškama.

A kde je ustálená definice? Můžeš odkázat?

Pattern je v překladu vzor a znamená způsob/princip jak v kódu řešit opakující se problém/postup, tuhle definici najdeš ve spoustě vysokoškolských skript už desítky let. Já záměrně nezmínil třeba sousloví design patterns, který asi myslíš ty.

Zralý programátor má právě v hlavě spousty šablon, principů, vzorů jak řešit ten a ten problém v daném jazyce nebo prostředí. To získáš buď neúnavným biflováním, čtením cizích kódů nebo programováním různých věcí. V tom se ukazuje praxe a zkušenost.

Klasický problém, který opakovaně zažívám je třeba počítání s finančními hodnotami, v sql to definuje rozdíl mezi double a decimal, v javě to je double a bigDecimal. Při výpočtu trasy taxikáře použiji double, při výpočtu ceny za jízdu bigDecimal. Bys ani nevěřil, kolik programátorů v tom je schopné udělat chybu a při velkém objemu udělat opravdu velký problém. A nejen programátoři, tohle se nám znovu dostává do popředí kvůli AI, dělá úplně stejné chyby, řeší kód a ne kontext kolem něho a klidně na vytěžování faktur použije double.

... než že zná různé paradigma a patterny z hlavy.

No zrovna znalost patternů z hlavy je důležitá. Patterny jsou často se opakující boilerplate kód. Není to žádná business logika, nic co ta aplikace "dělá" z pohledu užívání. Je to nutné zlo, které je potřeba aby se ty zajímavé části daly poskládat dohromady.
A u téhle nezajímavé vaty chcete, aby vývojář koukl, viděl a a dál o tom nemusel přemýšlet a nijak to řešit.

Já to nechtěl zbytečně více rozepisovat, ale patterny nemusí být jen třeba decorator, adapter, composite, singleton, ale třeba i to jak správně pracovat s proměnnými, kde je cena a desetinná čárka, ják psát konkurenční, paralelní nebo asynchronní kód atd.

Btw, pokud něco pokazí vývojář, a přetíží to v produkci databázi, tak je samozřejmě vždy vina na tom vývojáři, pokud devops něco nepokazil. Jestli v tom týmu toto není jasně dané, tak jsi v blbém týmu, který je vedený nějakými pitomci v případě, že jim nedochází, a šmejdy v případě, že jim to dochází (a dělají ti to tím pádem schválně).

v realitě to je ale deleko komplexnější, z venku totiž jen tak nevidíš, jestli vývojář dělá 3 sql dotazy na stránku nebo 10, jestli si znovu načítá věci vícekrát nebo prostě je špička, protože děti mají prázdniny atd. Nebo klasická chyba, retry, který při delších problémech či špatném použití ti znásobí tok dat. Na tohle už musíš udělat analýzu, ale viník se zpravidla označuje v podstatě v prvních minutách problému a ne až po dnech zkoumání. To už se spíše dělá nějaké nápravné opatření nebo limity a jak to tak bývá, to implementuje svědomitě devops a pokud vznikl problém, devops musel na něj vynaložit čas, aby se už příště nestal a vývojář nemusel nic změnit hned, protože opravu udělá při další implementaci, je každému výš velmi rychle "jasné", že problém byl u devops, že jo.

Ano, u devops jde vidět přidaná hodnota jen, když se řeší nefunkčnost, jenže nefunkčnost je buď věcí náhody nebo neschopnosti. Málokdo oceňuje funkční systém jako přidanou hodnotu, ale bere to jako standard, bohužel.

Vlastní vývojáře nemáš od toho, že potřebuješ udělat jednorázovou aplikaci, ale že jí potřebuješ udržovat roky. Tam AI dnes také pomáhá, ale vývoj aplikací přes AI jde spíše proti dlouhodobému provozu a údržbě. Velmi rychle se to začne lámat a náklady zvyšovat.

balkovic: no, samozřejmě toho devops musíš naučit nějak rozumně programovat, ale to, že aspoň tuší, že linux na na fs fsync, že thread není zadarmo a python má GIL a java GC je daleko přínosnější, než že zná různé paradigma a patterny z hlavy.

jenže devops je prostě takový školník/opravář, bez něj to nefunguje, ale nepřináší velkou přidanou hodnotu (když je dobrý, tak věci fungují plynule). Naopak vývojář právě primárně dělá ty věci, co jdou vidět, dává přidanou hodnotu.

Devops je nevděčná pozice. Když aplikace je rychlá a stabilní, je to zásluhou geniálního vývojáře, když nefunguje, může za to neschopný devops, který není schopný vyřešit saturovanou databázi, když jí aplikace šikanuje.

Sice si můžeš myslet, že jako devops máš těch zvířátek strašně moc, ale u vývojářů to je ještě horší, zejména, pokud přechází mezi projekty nebo firmami, mění se toho strašně moc a pořád něco dělají znovu nebo se musejí lameři v tunách cizího "špatného" kódu.

Devops oddělení, počty pozic a agenda je relativně stabilní proti tomu co vidím u vývojářů, tam se to mění snad na týdenní bázi a pořád někde plaveš. Přibývají a mizí celé týmy jak nic. Na tohle bych se spíše zaměřil, pokud si najdeš jako vývojář stabilní tým a dlouhodobý projekt, bude ti hej.

Za mě nejlepší vývojáři jsou právě ty, kteří přešli z devops, protože aspoň tuší jak věci fungují.

Běžné fluktuace napětí v síti (podpětí, přepětí) odnese spínaní zdroj, který máš před notebookem, stejně tak vykryje výkyvy a po nějaké době ti může přestat fungovat, notebook to ale zpravidla vůbec neovlivní.

Pokud ti do budovy přímo uhodí blesk, tady situace může být jiná a může to notebook schytat dost silně, záleží jak jsou udělané bleskosvody, jak jsou dimenzované a jestli náhodou někdo neporušil normy a netáhne elektrické vedení kolem nich.

Ve firmě na tohle děláme revizi každých 5 let, občas nějakou úpravu/opravu nám to vygeneruje a hlavně to je vždy souladu s normami. Kdy jsi ale naposledy dělal revizi doma? Běžně lidé to mají desítky let bez revize, pak opravdu při zásahu bleskem (klidně i v okolí) to mohou odnést tvé spotřebiče. Notebook je drahý a pojišťovny uplatňují amortizaci po letech dost silně.

přejdi na jiný email, řešit to s nimi je těžké, tohle je jen špička ledovce, jsou roky pod finančním tlakem na provoz.

Oni to individuálně moc upravit neumí, používají Cisco Secure Email a nechce se jim do toho individuálně sahat, můžeš zkusit na ně tlačit, za to nic nedáš, ale bojím se že neuspěješ.

Jenomže to železo je dávno za zenitem, takže i kdyby byla SW podpora ještě dalších 10 let, tak už dneska je to stejně o ničem. Asi jako s Ubiquiti UniFi nebo Nanostation, což taky lze najít funkční ve stejném stáří, ale kdo by dneska na takových krumplech chtěl fungovat...

a co je na tom železe špatného? Na co nedostačuje?

víte co na těch všech hotových síťových prvkách nesnážím? Je možnost jejich testování a testování nových konfigurací. V práci mají klienti lab, kde v jsou stejné prvky jako na produkci. Co ale doma?

S pf na freebsd je to naprostá lahoda.

AI pomůže mikrotik nastavit, ale děláš jí testovací opičku a pak se na to bojíš šáhnout, protože netušíš, co se kdy rozbije.

Když MikroTik, tak otázka na životnost. Přijde mi, že odcházejí do věčných lovišť moc často. Zejména v bouřkově zasažených oblastech.

Z mé zkušenosti hlavní příčina je potenciál přes metalické vedení v ethernet kabelech, zejména, když se to tahá přes více fází. (rozvod v domě nebo po bytě, klasika). Bouřka problém může pak umocnit, ale dřív než mikrotik by měl umřít ten spínaný zdroj, protože ten schytává ty výkyvy, usměrněné napětí na výstupu bývá stabilní. Pokud by pak přepětí (blesk např.) prorazil izolaci, odejde ti oboje. Pokud zdroj je ok, ale odchází mikrotik, problém je s napětím na jednotlivých portech (pokud je dlouhé vedení a bouřka, tak se ti na tom ethernet kabelu může naakumulovat dost vysoké napětí). U SOHO routerů jako je mikrotik nemůžeš čekat nějak vysokou izolační pevnost ethernet portu proti šasi, hlavně v enterprise tohle se vše měří a certifikuje, u mikrotik a jiných SOHO řešení to prostě spojíš neizolovaným kabelem.

Dříve jsem dělal vždy jeden PoE switch/router, z kterého jsem tahal ethernet pro všechny aktivní prvky všude, dlouhé kabely je potřeba zemnit. Pokud musel mít nějaký aktivní prvek vlastní napájení, tak jsem tam musel strčit galvanické oddělení, třeba přes trafo.

Dnes to je jednodušší, natáhnu optiku a mám po problému s napájením a vedením.

když to funguje, tak nešahat .

S mikrotikem jsem snad od jejich počátků, nastavoval jsem a řešil ho u spouty těch lokálních wifi providerů, všude po kancelářích toho byly tuny. Čím méně jsem toho věděl o sítích, tím více mi mikrotik vyhovoval, ale se znalostmi začaly přicházet i bugy, v každém kousku/verzi/typu úplně jiné, je to chaos.

U těch vyšších řad se má smysl o tom bavit, u těch domácích krabiček, pokud funguje, nech to. V posledních letech jsem ale domácnost (a hlavně místa, která jsou pro ostatní a ne pro mě) zmigroval na turris a hlavní důvod je, dlouhá podpora, automatické aktualizace a relativně dostačující funkce.

Když potřebuji mesh, tak ubiquiti mám pořád rád, ikdyž s výhradami, velkými. Ta situace je strašně marná do doby než se dostaneš na nějakou arubu nebo nižší řady cisco, což v podstatě musíš být malá firma.

Všichni po okolí jedou na tp-link/deco a podobných řešeních z eshopů, teda pokud jim nestačí ten jediný router od poskytovatele internetu.

Pokud máš rád pořádek, nevadí ti se to naučit, tak svatý grál je na dosah, freebsd a jeho pf (případně jako placený opensense s webui), dnes mi na tom běží i wifi 6 mesh. Čistá pravidla, předvídatelné chování a cpu to bez problémů upočítá i pro 10GbE linky a pořád spotřebu měřím ve spodních desítkách W. Hlavní výhoda je dlouhá podpora, přehledný man, málo změn, které ti něco rozbijí.  Když to srovnám s openwrt, kdy při každém snaze něco změnit jsem musel překonávat milion překážet a pak jsem se bál do toho šáhnout, tak tohle je naprosto nesrovnatelné, spolehlivé, čisté, dokumentované a plně automatizovatelné.

je to vtipné, ale ty paměti nejspíš znásobily svoji cenu jen tím, že zůstaly v krabici.

prodáváš jako celek nebo to umíš rozdělit? Máš představu o ceně jako za celek?

ano, není to moderní novinka, je to spíše odklon od objektového pekla.

Tazatal má správný čich. Na volbě topologie dat v paměti a na disku prostě záleží. Velmi záleží. A musí se to volit velmi pečlivě, v počátku počítačů triky s datovými strukturami a přístupů k nim umožňilo vznik všech těch legendárních programů a her. Dnes už naštěstí nemusíme dělat takové vylomeniny.

hlavně dnes ve velkém počítačové součástky skupují překupníci s drahými kovy, protože se tak nějak zjistilo, že v tom šrotu, v těch kabelech je toho opravdu spousta.

Myslím, že tenhle segment postupně vymizel.