Příspěvky

16

Studium a uplatnění / Re:Home Office po pandemii

« kdy: 29. 06. 2021, 12:21:13 »

protoze nechapu, jak rodicovstvi koreluje s nadsenym vitanim navratu do office.

Dva malí caparti, co buď ještě nechodí do školky, nebo mají školku zavřenou a nepomůžou ani kvalitní sluchátka a samostatná místnost na práci, abych se aspoň přiblížil k předpandemickým výkonům.

17

Hardware / Re:PC na vývoj

« kdy: 25. 06. 2021, 13:27:31 »

Jedu už 3 roky na notebooku, kvůli ergonomii s externí klávesnicí a 3 monitory. Notebook je pořád zavřený a připojený do dokiny. Celkové vím jenom o dvou výhodách tohoto řešení: 1. můžu jet někam pryč a nemusím řešit synchronizaci prostředí 2. při výpadku proudu to podrží baterka, takže nepotřebuju UPS, abych to otevřel a vypnul. Jinak samé nevýhody. Za stejné peníze nižší výkon, většinou se to moc nepozná, jestli kompilace trvá 4s nebo 9s je celkem jedno, ale např. u linuxového jádra už je to opruz, tam ten výkon citelně chybí (na dnešní poměry). No a hlavní nevýhoda je hluk a to je ntb. přizvednutý, aby měl dost vzduchu, a chladič s větrákem čistý. Jen co se ustálí situace kolem grafických karet, pořizuju stolní PC.

18

Server / Re:Sběr dat z louky

« kdy: 10. 06. 2021, 10:31:17 »

Dělám teď na projektech na NB-IoT a to je z hledsika spotřeby velice zajímavé. Mezi odesíláním má zařízení <100uA (stále měří) a při odesílání je na cca 3-4s nárůst na cca 35mA. Vhodným nastavením periody odesílání lze na 1 D-size LiSOCL článek provozovat několik let. LoRa u ČRa stojí na provoz podobné peníze, ale spotřeba vychází o něco vyšší - při odesílání cca 120mA, ale zase na kratší dobu. Proti klasickému GSM modemu je výhoda v absenci špiček velkých proudů (u GSM cca 2A).
U SigFoxu mi přijde jako velká limitace délka zpráv, 12B je pro mnoho aplikací prostě málo.

19

Vývoj / Re:Zlepšení čitelnosti vlastního kódu

« kdy: 03. 06. 2021, 19:39:41 »

Na jednom kontraktu nás bylo v týmu 5 programátorů + leader a code review dělalo většinou ještě víc lidí, než programátorů. Typicky ale byli alespoň 3 programátoři z týmu + leader + architekt. Jelo se podle přísných regulí (MISRA a další), takže něco jako vlastní code style každého jednotlivce neexistovalo, možnost poznat autora podle kódu byla velice omezená. Konkrétně tento projekt nebyl life-critical, ale společnost takové produkty dělá, takže byla laťka dost nahoře.

Pro aspoň 95% programování je tento režim overkill, ale něco to do sebe mělo. Každý pár očí vidí něco jiného, každý vidí různá úskalí - složitost algoritmu v různém zatížení, paměťová náročnost, rizika při paralelním přístupu, priority vláken atp. Pokud se má dělat code review v pravém slova smyslu (ne pečlivý git add -p, když člověk dělá solo), tak osobně bych po výše uvedené zkušenosti šel alespoň na 2:1, protože ten vícenásobný pohled na věc je něco, co se většinou vyplatí a ten čas tím strávený není promrhaný - viz zmiňované distribuované povědomí o kódu, odhalení chyb před začleněním atp. Něco pokryjí testy, ale obecně je kód pouze tak dobrý, jak dobré jsou testy a pokrytí kódu testy ještě nic neříká o tom, že se otestují všechny okrajové podmínky, které v nasazení mohou nastat.

20

Studium a uplatnění / Re:Stát se programátorem po čtyřicítce

« kdy: 30. 04. 2021, 21:13:13 »

Znám lidi, co programují, ale programátoři v tom smyslu, jak to chápu já nejsou, protože nerozumí tomu, jak to funguje vevnitř (nebo rozumí, ale ignorují to). Nerozlišují, co je na stacku, co je v heapu. A to nemluvím o nějakým z donucení převeleným HW chlápkovi, ale o člověku s titulem z IT oboru, co je od školy na pozici progamátor.

Pak znám testery, co si sami leccos naskriptují v bashi nebo týpka, co navrhuje HW, ale zvládne si sám udělat device tree.

Na jednom kontraktu jsem v týmu spolupracoval s klukem, který v jeho 44 přešel z pozice IT support na pozici programátora. Za dob v iT supportu si tu a tam slepil nějakou MCU věc, takže k programování trochu přičichnul. A v týmu byl rozhodně víc platný, než človek z prvního odstavce.

Takže si myslím, že při dobré motivaci má šanci. Už se asi nedostane do top 1% možná ani do top 10%, pravděpodobně při nástupu půjde s výdělkem dolů, ale šanci má. Zejména pokud bude první rok, dva brát jako stáž a ne hamon mamon honbu za výdělkem. Když bude chtít vstřebávat znalosti, pak být v týmu schopnějších, ho hodně rychle posune vpřed.

Git ať se určitě naučí předem, to přece musí uplatnit jako IT i teď, pokud neřeší jen vytržené napájecí kabely a vadné disky.

21

Odkladiště / Re:Setkáváte se z "updatofobií"?

« kdy: 16. 04. 2021, 18:07:37 »

Jelikož jsou uživatelé čím dál více jen hříčkou technologií a technologických firem, tak se jejich odporu k updatům ani nedivím. Základní potřeba uživatele je mít technologii pod kontrolou, tedy vědět co mi update přinese, možnost update odmítnout případně určit čas, kdy k němu dojde.

Stanovisku vývojářů nicméně také rozumím, sám jako vývojář chci, aby měl uživatel pokud možno poslední verzi. Takže je to o budování důvěry a  loajality...

Taky rozumím oběma stranám. Jako uživatele mě ale pekelně štve, že si ze mě M$ dělá pokusného králíka, co vydržím, aniž bych notebook roztřískal o zeď. A to nemám Home edici, kde se toho dá uživatelsky ovlivnit ještě o řád méně. Problém je, že vedení si osobní wiki, jak opravit to či ono po aktualizaci, samo o sobě nestačí, protože jsou věci, které se vrací s železnou pravidelností a nastavení (např. deaktivace telemetrie ve W10) je platné jen do další aktualizace, ale jsou i věci, které se po jedné dvou aktualizacích přestěhují, takže je třeba znovu hledat, nastavovat jinde, vracet změny v ovladačích a podobně. Hledání, opravování a nastavování po aktualizacích mě stojí asi dva dny ročně, na můj vkus tedy opravdu hodně, navíc to přichází vždy v nejméně vhodnou dobu - finiš projektu a po obědě je PC po resetu a začne padat na BSOD. Na linuxu obecně je problémů této závažnosti výrazně méně, ale už se mi rozsypala instalace eclipse aktualizací nějakého doplňku tak, že to vytvořilo nekompatibilní pavučinu závislostí a nakonec jsem vzdal pokusy o opravu a nainstaloval vedle novější od píky.

Jako vývojář se snažím neměnit uživatelské chování, místo změny chování v existujícím protokolu jej rozšířím, abych udržel zpětnou kompatibilitu. To samé u knihoven - stávající API ponechat, byť bude třeba interně využívat nové komponenty. Když se najde chyba, snažím se před opravou implementace dopsat test, který tu chybu bude detekovat i ve všech budoucích verzích, aby nedošlo k regresi.

22

/dev/null / Re:Práce pro české společnosti

« kdy: 01. 04. 2021, 17:08:42 »

K fungování úřadů: Dva roky zpátky jsem posílal na FÚ přiznání elektronicky, nějaký problém, musím tam přijít. Přijdu tam, všechno vytištěné na papíře. To samé žena. K čemu potom ty miliardy za IT projekt byly, to netuším.

Ohledně práce, jak už psal Cent2x, strašně záleží na regionu. Pokud v kraji není automobilka nebo nějaká velká pobočka velké firmy s rozumnou pověstí (ne low-cost montovny), celý region je s ohodnocením práce o desítky procent níž, pak ani v IT není běžné nadprůměrné ohodnocení. A dojíždět do Prahy/Brna jde jakž takž když je člověk single, ale s malými dětmi doma je to už problém, když se tráví desítky hodin týdně někde ve vlaku.

Moje zkušenost:
malá česká firma - NOK, vedení pozadu, peníze špatné, spousta práce, nic moc vybavení, bez procesů
střední česká firma - NOK, super kolektiv programátorů, vedení pozadu, peníze špatné, ne tak moc práce, nic moc vybavení, špatné procesy
pobočka zahraniční firmy - NOK, super kolektiv programátorů, pro vedení jsi jen číslo, peníze OK, ne tak moc práce, dobré vybavení, až moc procesů - nejde inovace
IČO pro české firmy - většinou OK, protože se přeskočí mezivrstva nedůvěřivého středního managementu, dobrá zkušenost se startupy - vědí co chtějí a proč, ale nevymýšlí si blbosti, protože by to pro ně byly peníze navíc

23

Hardware / Re:PLC pro domácí použití

« kdy: 14. 02. 2021, 14:38:36 »

xPoli: co je prosím IPE2? Nějak se mi to nedaří dohledat. Díky.

koukám, že zdroj http://nutcom.hu/ipe2 je již neaktivní. Bylo to založeno na buildroot prostředí, vypadl z toho jeden soubor (image karty), který se pomocí dd hodil na SD kartu a karta byla připravená k použití. Poslední, co jsem k tomu dohledal u sebe v archivu je soubor IPE2builder-140122.tgz. Toto jsem bral jako výchozí inspiraci, přidával balíky, upravoval konfiguraci, připravený obraz na SD kartu pak obsahoval např. klíče k VPN, nastavení IP adresy...
Dnes bych se pro podobný projekt vydal asi spíš v diskuzi zmiňovanou cestou s použitím btrfs, ale v roce 2014/15 byla toto pecka, po zapnutí napájení bylo vidět GUI po cca 8s, plně funkční se sítí a USB po cca 12s.

24

Hardware / Re:PLC pro domácí použití

« kdy: 14. 02. 2021, 11:40:45 »

Můj postřeh k SD kartám a RPi: Nasadili jsme desítky RPi s běžnými Kingston SD kartami, dokud se to provozovalo s raspbianem v rw režimu, objevovaly se problém. Pak se přešlo na vlastní obraz odvozený od IPE2 distribuce provozované v režimu read-only, do RW se to přepíná jen při aktualizaci aplikace nebo pro zaznamenání kritické chyby, od té doby problémy s kartami spíš nebyly a pokud ano, nebyly způsobeny režimem karty, ale mechanicky - držáky v RPi1 (na velké SD karty) kartu nepodpírají uprostřed, prostřední kontakty pak byly "ve vzduchu". S microSD sloty tyto problémy nebyly.

25

Hardware / Re:Vývojářský počítač: notebook vs. stolní PC

« kdy: 12. 02. 2021, 08:53:21 »

Já mám stolní počítač a k němu velký 4K monitor + jeden běžný.

Tohle se dá zase řešit dokinou. Mám k NTB přes dokinu připojeny tři 4k monitory. Nicméně pro generační obměnu plánuju stolní, resp. podstolní PC. Moderní NTB to výkonově zvládnou bez problémů, 24-32GB RAM není problém, NVMe SSD taky, ale problém s notebookem je fungování v zátěži, byť kvalitní, tak v zátěži je prostě slyšet a čím delší je zátěž, tím je to protivnější, s nějakým 120mm větrákem ve stolním PC točícím pár set až lehce přes tisíc otáček se to nedá srovnávat.

26

Vývoj / Re:Jak posunout vývojáře k CI/CD

« kdy: 29. 01. 2021, 09:06:57 »

POKUD NA TO MUSÍ NĚKDO MYSLET A VĚNOVAT TOMU 1 a více sekund je to ŠPATNÉ(NEVHODNÉ) ŘEŠENÍ.

Jejich postupy mohou být třeba vhodnější(efektivnější) pro jejich způsob práce.

Dosud se celá debata odvíjela celkem správným směrem, ale výše citovaný příspěvěk jako celek je podle mě agresivní útok hlupáka. Nejde pro jeden dílčí krok zahodit přínos celé pipeline. Udělat commit v gitu, zvlášť aby k něčemu byl dá určitě víc práce, než na složce se zdrojáky udělat alt+f5 a odzálohovat to někam na server. Git workflow je třeba se trochu naučit, nedělat commit 1x za měsíc, ale ideálně vždy po uzavření nějaké nové/upravené funkcionality, případně i v mezikrocích ("WIP: ..."). To je ta práce navíc. Na druhou stranu to ale lidem může ušetřit spoustu času. Proč se dělala tahle změna? git blame, git log, git diff - aha, proto. A není potřeba se někde prohrabovat zip souborama na sdíleném disku ve firmě a hledat, kdy se tam tohle vlastně dostalo, pokud to vůbec někde je.

Vysvětlit přínos téhle práce navíc jednak vedení a jednak těm vývojářům může být náročný úkol, ale je potřeba argumentovat právě případy, kdy kvůli nějakému pochybení v deploy procesu to ty lidi/majitele stojí násobně víc času. Takhle potom jde třeba odpovědět - nevím, teď nemám čas ti to hledat, najdi si to v gitu a mám klid na další práci.

Z vlastní zkušenost znám případ, kdy majitel firmy vzal notebook nemocného zaměstnance a vezl mu ho domů, aby se dostali k aktuálním zdrojákům a překladu.
Jiná (odstrašující) zkušenost: Zaměstnanec v pracovní době vytvoří něco, co bere jako svoje know-how a nechce ho předat dál. Jakkoliv strastiplnou cestu musel projít a mentální úsilí vyvinout, pořád je to práce zaměstnance pro zaměstnavatele a tak by s tím mělo být nakládáno.

Vztaženo na původní dotaz za mě takto:
Krok jedna - všechny zdrojáky musí do repozitáře, bez debaty, klidně befelem. V první fázi tak jak jsou, klidně i s různými balasty typu vcproj.sln, .cproject a podobně. V tomhle by měl mít tazatel podporu vedení, je to práce zaměstnanců firmy v pracovní době, tedy majetek zaměstnavatele a zaměstnavatel by k tomu měl mít přístup. Částečně se tím eliminuje bus faktor.
Krok jedna a půl - vysvětlit základní git workflow. Návod velkým písmem na A5 max, na to klíčové to stačí. Musí tam být init, add, .gitignore, remote add, commit, reset, push, s velkým varováním commit --amend (pro situace a ještě jsem zapomněl upravit tenhle řádek v readme) s tím, že commit --amend nelze po push, pak už je třeba nový commit a případně stash. S tim si lze běžně vystačit. Podrobnější návod může být k ruce, kde bude návod na řešení dalších základních situací (branch, checkout, clone, pull, merge), ale git cook book na začátek je moc.
Krok dva - tazatel bude postupně automatizovat build systém tak, aby se buildovalo z toho, co je v repozitáři. Ideálně přes dvě větve, kdy do master větve jde jen to, co jde mergovat a zkompilovat, ale jde to i tak, že vše může být v masteru, ale pokud commit message nezačíná "WIP:" musí to jít kompilovat. Následně se nasazují jen verze, které splňují výše uvedené pravidlo, ideálně v help-u těch aplikací je uveden commit (např.

Kód: [Vybrat]

git describe --match=NeVeRmAtCh --always --dirty=M

), ze kterého se to sestavilo. Tím se předejde pěti různým verzím aplikace, shodně označeným 1.2. Podmínka kompilovatelnosti zabrání tomu, že se např. v commitu zapomene na nově vyvořené soubory.
Krok tři - postupovat v automatizaci - ideálně každý problém v produkci přetavit v další test, automatizovat reportování chyb z testů zpět vývojářům, zpřísňovat parametry překladu např. -Werror atp.

Štábní kultura zdrojáků s tím sice souvisí taky, ale pokud jsou jednotlivé projektíky one-man-show, pak bych to případně tlačil až v pozdějších fázích.

Jo a nezapomenout na zálohování repozitáře!

27

Studium a uplatnění / Re:Pohovory po letech freelance

« kdy: 15. 01. 2021, 12:01:46 »

Za juniora bych se už snad po 4 letech zkušeností (+x let na škole) nepovažoval, obzvlášť když poslední 2 roky dělam 12 hod denně pravidelně i víkendy, takže těch zkušeností získám o něco víc, než normálně.

Když se řídím pravidlem podle sebe soudím tebe, tak po 4 letech komerční praxe člověk nemůže být senior, ale někde na cestě junior-intermediate. Zejména v této fázi považuji za vhodné dostat se do týmu, kde jsou o kus dál, protože tě to může hodně rychle posunout hodně vpřed. Znám lidi, kteří jsou jednoznačně junior i po víc jak 10 letech, opakují stále stejné chyby, jejich kód stále není znovupoužitelný, srozumitelný atp. Mně hodně posunula změna zaměstnavatele a potom neúspěšné pohovory, když jsem u druhého zaměstnavatele nasál, co šlo a utíkal jsem. Bez těchto zkušeností bych se nedokázal posunout o tolik potřebný level výš.

A poměřovat to odsezeným časem je taky špatně (to z mého pohledu vypovídá o ne-senior úrovni). Jako junior jsem vzal zadání, za 10 minut se pustil do práce a týden bušil do klávesnice. Teď bych u stejného zadání strávil hodinu čtením dokola, pak maloval na papír, pak udělal odhad náročnosti (=rozpad prací), pak bych si nasimuloval klíčový problém na nějakém MWE, po necelém dni bych tak měl jasno, že jsem na správné cestě a nechal bych to být, ať si mezitím hlava odpočne u něčeho jiného. Druhý den bych udělal jádro celého řešení, ale bez ošetření všech krajních podmínek, které si průběžně píšu do todo listu nebo do ignore testů. Třetí den bych vypulíroval kód a testy. Druhým přístupem bych měl víc souborů, míň řádků efektivního kódu, který ale bude čitelnější a budu mít mnohem větší jistotu ve výsledek.

28

Hardware / Re:Výběr monitoru k práci (2K/4K rozlišení)

« kdy: 25. 11. 2020, 20:15:19 »

Je to o nárocích a požadavcích a pak taky o kondici oči. Já jedu na 3ks 4K 27" monitorů. Produktivita práce je násobně vyšší než s 2x FHD i za cenu toho, že při dynamických změnách je viditelná komprese delt - monitory jsou připojené do USB-C dokiny připojené k ntb. Škálování všude zakázáno, kdybych to chtěl vidět velké, nebudu pořizovat 4k, pro mě je důležité, že vše co potřebuju k práci vidím najednou bez přepínání oken.

29

Vývoj / Re:Jake používáte prostředí pro vývoj (C++)_

« kdy: 31. 10. 2020, 15:47:53 »

Já jedu v Eclipse CDT, dřív jsem pro nějaký projekt zkusil Cevelop (lépe oskinovaný Eclipse s nějakými doplňky), ale pro zachování jednoho IDE na co nejvíc věci jsem zpátky u Eclipse s pár doplňky, remote debug embedded věcí je perfektní - běžně aktivní disassembly, memory, peripherals, variables, debugger console a kód, ve VIMu jsem to uměl spustit, ale je potřeba víc znát GDB a víc psát, nejde debugovat a rovnou psát úpravy do zdrojáků pro příští spuštění, v Eclipse stačí v debug perspective najet myší nad řádky a už se zobrazují hodnoty proměnných. Ve VIMu jsem toho naprogramoval spousty, ale traverzování skrz nějaké neznámé SDK v tom dost dobře nejde, v Eclipse to mám jen F3, F3, F3, F3 ááá, tady je ten šotek, tak přeložit a znovu. To samé autocomplete, ve VIMu funguje omnicomplete nebo něco podobného, ale efektivity zejména s neznámým cizím kódem jako u plnohodnotného IDE jsem v tom nikdy nedosáhl, přesto vim stále aktivně používám třeba v RPi, když potřebuju rychle něco ozkoušet a nechce se mi přepínat z terminálu nebo na desktopu, když se mi na nějaký pokus na pár desítek řádků nechce zakládat v IDE projekt.

30

Hardware / Re:Ergonomicky vyskovo nastavitelny stol na homeoffice

« kdy: 28. 10. 2020, 11:17:19 »

Mám rovný sit2stand (tuším 180x70) a jsem s ním maximálně spokojený, je opravdu robustní, pohyb je tichý, tlačítka s pamětí, jen se tlačítko předvolené polohy musí držet až do dojetí do polohy. Cena oproti konkurenci možná o něco málo vyšší, ale je to výrobní prostředek, takže nemůže rozhodovat nějaká ušetřená tisícovka. Přivezou domů, složí, zprovozní. Co víc si přát.