Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - xPoli

Stran: [1] 2 3 4
1
Jen se zeptám, co je to za firmu, že nemáte agile a denní statusy?
Freelancuju vývoj embedded, nejčastěji v režimu mám desku, mám zadání na FW, vím, kdy to má být hotové. Když je urgentní problém, nečeká se na meetingy a řeší se to hned. Když je potřeba se na něco vyptat cílového zákazníka, řeším to přímo s ním, není potřeba, aby mi někdo překládal z češtiny do češtiny, aby se po cestě něco ztratilo.

S narůstajícím počtem hlučnost dětí obecně výrazně roste.
Je to logické, s vyšší hladinou rodinného šumu to ten nejmenší musí přerazit, aby se dostalo na jeho potřeby, když není v jeho schopnostech to vyřešit jinak.

Nad tím právě žasnu, že kravál od dětí vám nevadí ale vadí vám, že někdo tiše chodí po kanceláři. Nechápu.
Nikde nepíšu, že mi hluk od dětí nevadí. Vadí a pozornost to narušuje, ale ne tolik, jako srozumitelná řeč kolegů, kde se podvědomí chytí některých slov a ignorovat ten hovor mi potom nešlo. Aspoň částečně se to dá tlumit sluchátky nebo jinak reprodukovanou hudbou nebo špunty do uší. Ale v zorném poli normálně doma pohyb není, ten filtrovat nedovedu vůbec a třeba toulavá kočka na kopečku za oknem si strhne pozornost i teď, jenže s klapkama na očích pracovat opravdu nemůžu. A pracovat čelem do kouta nechci.

2
Pracuju full remote doma 5,5 roku. Samostatná pracovna v RD. Meetingy nemám s výjimkou koordinačního telefonátu na čtvrt hodiny 1x týdně. Když jsme měli jedno dítě, bylo to super. Když jsme měli dvě, úvahy nad kanclem ve městě byly poměrně časté, protože druhé, aby se dožádalo svých potřeb, bylo hlučnější. Nejhorší to bylo, když druhé dorostlo na odrážedla. To je jedno, kde je to v domě, nese se to konstrukcí. Na to nepomůžou ani špunty do uší, ani ANC sluchátka. Třetí dítě je vyloženě křikloun, hlavně když jsou doma všichni. Frustrace z absence klidu, jaký bych si já představoval, se ve vlnách objevuje a pak zase mizí. Nějak jsem se vnitřně smířil s tím, že i to třetí nakonec půjde do školky a pak bude doma zase klid. Když bych šel do kanclu, musel bych si spoustu vybavení pořídit 2x, protože někdy je objektivně potřeba být doma.

Na pracovním výkonu se to samozřejmě projevuje, ale se třema malýma dětma už se výrazně projeví i jiné vlivy než jen klid na práci. Logistika kolem takové rodiny alespoň v našem případě nejde dlouhodobě zvládat v jednom, takže jsem se smířil s tím, že pracovní den začáná kolem deváté, když ty větší jsou ve škole/školce a končí kolem druhé. Pak rychlý oběd a zase odpolední logistické kolečko. Večer se pak k práci na hodinu až dvě vracím.

Udělám méně, než na začátku remote režimu, ale pořád mnohem víc a s menší frustrací než v kanclu. V kanclu nás bylo 5-7 a stačí aby každému z nich jednou za den zazvonil telefon, každý si šel 2x na svačinu, párkrát na záchod a ve výsledku se pořád někdo někam courá a ruší i když se snaží být potichu. Někdo tohle dokáže ignorovat, já ne. Potom i žena, když přijde 3-4x "za směnu" za mnou do pracovny je méně rušivý element než toto. Nejhorší v kanclu bylo, když si někdo dole na chodníku zapálil. Jednou za týden by se to dalo, ale když je to potřetí, počtvrté, posedmé za den, od pondělí do pátku... Tohle doma nemám a možnost od jara do podzimu mít celý den otevřené okno je k nezaplacení.

Úplně ideální to s rodinou v domě na práci není, ale v kanclu to taky ideální nebylo. Je potřeba si to někdy připomenout, stavit se za bývalýma kolegama na pokec, chytit chvilku čmudilů po okny a najednou je to doma zase fajn, i když tam není ticho.

3
Hardware / Re:Aky setup na stole pouzivate pre notebook?
« kdy: 22. 04. 2024, 10:44:44 »
Několik let jsem měl zavřený NTB položený zadní hranou na podstavci monitoru, aby se lépe chladil. Připojené k dokině a 3x 4k monitor - jeden na šířku, dva na výšku. Loni jsem přešel na (pod)stolní PC, zavěšený na popruzích pod stůl. Zavládlo ticho a násobně stoupl výkon.

4
Studium a uplatnění / Re:Jak začít jako Embedded developer
« kdy: 11. 03. 2024, 21:36:13 »
Upřímně, embedded je těžké. To nepíšu proto, abych tě od toho odradil, ale aby bylo jasné, že toho musíš znát dost, abys byl v embedded dobrý. Je potřeba orientovat se v hardware i software.

Z hardware je dobré vědět něco o logických obvodech, mít představu o tom, jak funguje CPU a velké plus je vědět něco i o analogu, když třeba potřebuješ řídit motor.

Ze software je potřeba C(++). C se používá hlavně na malých MCU s pár KB RAM a FLASH (ne že by se nedalo použít C++, ale častější je C) a C++ využiješ na nějakých větších embedded ARMech.

Takže je spíš otázka, kde ty vidíš prostor ke zlepšení? Když půjdeš na pohovor na embedded software developera, tak je primárně bude zajímat C(++) a asi i něco z hardware.
Pod tohle bych se podepsal.

Pokud chceš dělat vývoj embedded na úrovni jednočipů, tak v menších firmách musíš být samostatný. Pokud budeš brzdit od práce mediora/seniora dotazy proč mi tohle nefunguje, proč mi tohle nejde přeložit, proč ... (dosaď si sám), pak firmu stojíš zhruba 2x tolik, co ten senior. Abys byl pro firmu zajímavý, musíš prokázat nějakou elementární úroveň dovedností, abys alespoň jednoduché úkoly zvládnul sám.

V korporátu jsi míň vývojář, víc programátor - dostaneš ohraničené zadání až např. na úroveň, že píšeš jen implementaci funkce, jejíž název, vstupy i výstupy jsou dané. Ale omezují tě věci jako MISRA, podpora pevně daného překladače atp.

Výčet toho, co bych já považoval za elementární dovednosti: základní práci s osciloskopem - alespoň nastavit trigger a změřit délku pulzu; čtení schemat; čtení a porozumění dokumentaci anglicky - datasheety, manuály; datové typy, limity, přetečení, znaménkové / neznaménkové; bitové operace; co je to přerušení; znalost základních komunikačních rozhraní - UART, SPI, I2C

Poznámky z reálného života: zadání se mění často a hodně; některé výpočty v MCU mohou trvat i dost dlouho; HW není bezchybný - někdy udělá chybu HW vvýojář - typicky prohození RX, TX, jindy je chyba v komponentech, některé vybrané errata sheety jsou doslova hororové čtení; unit testy se vyplatí; když to jde, debugger je tvůj kamarád;

5
Co za gui toolkit v Pythonu používáte?
PySimpleGUI

Díky za tip na fltk, podívám se na to, mohlo by se to někdy na něco hodit. Nicméně pro moje potřeby bych musel ještě řešit sériový port a zajistit extra překlad pro cílové platformy.

Asi budu za kacíře, ale asi bych ji udělal jako online (JavaScript/Web Serial API) s výstupem do DB.
Díky za tip, ale nezdá se mi to zatím použitelné. Jednak výstup do DB - DB musí být někde nainstalovaná a běžet, správa, zálohování - to vše přináši další komplexitu. Navíc jak jsem se díval, tak Web Serial API není univerzálně podporované, u Firefoxu je potřeba add-on s předem nainstalovanou samostatnou aplikací. Proti pip install serial...

6
Fakt to musí být multiplatformní? Fakt to musí mít GUI?

Ano a Ano. + ostatní zmíněné požadavky (sériový port, síť, práce se soubory). Jde o pomocné jednoúčelové aplikace, primárně pro testování/oživování HW nějakou (neIT) tetou nebo študákem na brigádě. Nemůžu trávit týden vývojem takové aplikace. Pokud bych neměl přístup ke svým starším výplodům, tak v pythonu toto realizuju cca za den. Díky recyklaci přechozích projektů je to v reálu méně. Díky tomu se taková aplikace vyplatí už od ~200ks sérií HW. Pokud by něco jiného splnilo požadavky výše uvedené se srovnatelnou časovou náročností, pak by to stálo za zkoušku, ale zatím jsem na to nenarazil.

Příklad s len() je sice trefný, ale neovládám tím jadernou elektrárnu, takže akademické otázky jdou stranou, ekonomika rozhoduje.

7
Mám dotaz na ty, co tu haní python: V čem jiném udělat jednoduchou multiplatformní (Linux a win) GUI aplikaci, která bude umět komunikovat se sériovým portem, po síti a s výstupem záznamů do souborů.

Zatim jsem totiž nenarazil na nic, kde bych byl alespoň podobně efektivní. Dřív jsem zkoušel wxWidgets, QT a pár dalších. Ale časová náročnost byla vždy minimálně o řád vyšší než u toho pythonu, nutnost extra překladu pro tu kterou platformu... Jak u učicí křivky, tak u samotného vývoje.

8
a ty děláš čistě vývoj FW nebo i návrh HW od schématu po layout?
Jak kdy, nejčastěji do toho ale vstupuju už ve fázi specifikace se zákazníkem, interně pak na úrovni blokového schematu. Pak znovu MCU pinout. Pak oživení, ověření prototypu a ostrý FW, případně někdy ještě tester k oživování sériových výrobků. Layout a výrobu neřeším.

Dá se freelancovat/"švarcovat" jenom na to, že ti ta firma pošle prototyp?
Ano dá. Nešvarcuji, freelancuji, okruh zákazníků je sice už delší dobu uzavřený, protože nemám další kapacitu, ale pro každého z nich dělám postupně nové a nové projekty. Často to jsou deriváty předchozích designů, často to běží paralelně, takže jeden FW pak obsluhuje několik řad výrobků. Kde samodetekce není možná, tam se alespoň sdílí codebase.
Je 10000MD realný?
V tom co a pro koho dělám není.

9
4-5MD? To se asi nevyplatí, ne? :D

Nezávislý projekt na 4-5MD pro nového zákazníka by se nevyplatil, administrativa s jednáním apod by z toho ukousla moc. Pokud je to ale stabilní zákazník, pro kterého dělám třeba 4 velké projekty za rok od nuly, pak i takovýhle drobek navíc dává smysl, protože je to jenom jeden řádek na faktuře navíc, kterým se vyplní třeba čekání na prototyp.

Nechápu tady tu diskuzi o městech, regionech, dělám devops z domova, klidně můžu v regionu za stejné peníze vzdáleně, stejně nechci denně chodit do kanceláře. A pokud embedded nejde dělat vzdáleně, tak bych to určitě zahodil, alespoň já.

Vzdáleně to dělat jde. Ale znovu se dostáváme k tomu, co jsem psal předtím. Většina mých zakázek jde do Brna a do Prahy. A potřebuju na to vlastní vybavení, které bych jako zaměstnanec někde v kanclu řešit nemusel. Mně to tak vyhovuje, ale naprosto rozumím i těm, co radši budou jako zaměstnanci chodit do kanclu, protože to má i své výhody. A alespoň v mém případě jsem na začátku freelancování musel přesvědčit zákazníky, že to plnohodnotně zvládnu i ve full-remote režimu.

10
V embedded se pohybuju celou dosavadní kariéru. Posledních 5 let jako freelance. Zlatý důl a automat na peníze to není. Dostat se na 100K lze, ale průměr je výrazně, výrazně níž, alespoň v regionech. Je taky problém najít něco smysluplného mimo Prahu, Brno a možná Plzeň. Vstupní investice do plnohodnotného freelance (ne švarc u někoho v kanclu) není jen o počítači, je potřeba nějaké základní vybaverní pro vývoj - jako takové základní minimum pár měřáků, zdroj, 4ch osciloskop, logický analyzátor, kvalitní debugger a výbava na pájení. Není to katastrofa, proti třeba autodílně je to míň, ale je třeba počítat s tím, že takových 100K do začátku na vybavení mimo počítač padne.

Otázka je, co si představit pod "samostatně fungovat a dodávat výsledky" a jak daleko je okolí, které tě může rychle táhnout nahoru. Samostatně fungovat můž být "už neotravuju kolegy, když mi kompilátor vypíše chybu" a dodávat výsledky může být "za měsíc uplácám misku špaget, ve které se za půl roku nevyznám ani já sám, když se k tomu budu muset vrátit". Nechci se tazatele nijak dotknout, předpokládám, že taková katastrofa to není. Ale když si zpětně vezmu svoji cestu kvalitou nahoru, vezmu v úvahu, jak fungovali kolegové kolem mě na různých úrovních seniority, tak o schopnostech po půl roce fungování mám celkem kritickou představu. I po >>10 letech praxe, když se vrátím k projektu třeba dva roky nazpět, vnímám, že se pořád posouvám dál, ale pořád nemám pocit, že bych byl tam, kde bych si přál, pořád to není úplně ono. Když si vezmu první MCU projekt, který jsem dělal v rámci zaměstnání, tak jsem nad tím tehdy spálil cca měsíc času. Dnes bych si za to samé zákazníkovi nedovolil říct o víc než 4-5MD a kvalita by byla tak o dva řády výš.

11
Vývoj / Re:Srovnání algoritmů na prvočísla
« kdy: 07. 12. 2022, 09:48:36 »
pricom jeho otazka je uplne jasna.

Právěže není. Wasper na to upozorňuje taky. Nejsme na webu o matematice, ale na webu o počítačích. Tazatel neumí/nechce konkretizovat zadání. Nevíme, co je cílem, nevíme, jaké jsou omezující podmínky, nevíme, co je k dispozici.

Podstata je že  nezáleží na tom jestli dělení je rychlejší než modulo. Ale kolik operací dělá který algoritmus pro velké vstupní n. Přesněji operací v nejhlubším cyklu. Nebo se pletu?

Podstata je, kolik taktů je potřeba na výpočet. Resp. kolik taktů navíc oproti N je potřeba pro výpočet N+1. A zde záleží na tom, jaké aritmetické operace se budou používat, s jakými datovými typy, na jaké architektuře. "...operací v nejhlubším cyklu" - to chápu jako úvahu o vnořených cyklech (for, while), ale tak to nemusí nutně být.

12
Vývoj / Re:algoritmus na prvočísla - srovnání
« kdy: 05. 12. 2022, 07:22:03 »
Záleží na implementaci a architektuře. Záleží na tom, jestli se bude provádět dělení nebo násobení a porovnání - jestli je celočíselné násobení a porovnání na 1 + 1 takt a dělení na desítky až stovky taktů, pak zdánlivě hloupý algoritmus s násobením a porovnáním může být řádově efektivnější. Záleží na datových typech. Záleží na tom, co se myslí pod pojmem asymptoticky - matematický význam a význam v reálném světě VT je jiný. Záleží na (ne)dostupnosti paměti. Pak se to dá i spočítat nebo ozkoušet a změřit, ty algoritmy nejsou tak složité, aby se nedaly napsat.




13
Kdo se tímhle živí zpravidla už 8bity dávno opustil. Za sebe nevím za posledních několik let, že bych narazil na něco, kde by se mi po nějaké atmeze stýskalo nebo kde by nebyl kdejaký cortex ve všech ohledech lepší.

14
Studium a uplatnění / Re:Zvýšení hodinovky
« kdy: 25. 10. 2022, 14:37:55 »
Jako OSVČ diverzifikuju, tzn. i když mě jeden zákoš umí vytížit na 100%, nespoléhám na to. Aktuálně dělím čas mezi 3. Každý z nich ví, že pro ně nemám 100% času. Každý z nich ví, že nemá tolik provazu, za který by tahali, aby si mohli diktovat podmínky a já na všechny kývnul, protože o ně nemůžu přijít.

Navýšení cen řeším vždy osobně, vždy s nějakým předstihem a vždy jsem připraven na nějaký kompromis - např. stávající projekty dojedou za stávající cenu i kdyby se to protáhlo za termín zdražení atp. Zatím se to daří udržovat tak, že tam, kde spolupráce pokračuje, tam je to win-win. Ani přes win-win vztahy ne každý projekt vyjde hezky a v černých, někde to vyšlo i hodně do mínusu, ale zase je tam rozšíření skill-setu, takže investice do budoucna. A nejpoholnější je oznámení navýšení poslednímu - ostatní už kývli, jestli chceš zachovat nějaký podíl z mého času, tak to bude za tolik.

Nahrazení interním nováčkem za půlku už jsem taky zažil, ale díky širšímu rozkročení mi to vůbec nevadilo, prostě spolupráce na tuhle stranu skončila. Nemá cenu se podbízet cenou a pak se drbat za uchem, že to dělám vlastně zadarmo.

15
Testy by mali prebehnut po merge requeste. Ak nedopadnu dobre, tak to nejde mergnut a autor to musi opravit.
PRED. Testy musi kompletne projit PRED mergem. To co jsi napsal nedava smysl.

Povedz si to este raz pomaly nahlas - "merge request" - "merge". Ak stale ostane zhasnute, tak opakuj...

Moje zkušenost ve "formálnějším" prostředí je taková, že aby vůbec bylo možné udělat merge request, musí být splněný checklist. Checklist obsahuje mimo jiné to, že to projde testy, že to prošlo přes code review atd. Připomínka od to_je_jedno je v tomto rámci naprosto namístě. Setkal jsem se i s tím, že checklist nebylo třeba splinit u commitů, jejichž message začíná na "WIP:", kde se větší featura rozdělí třeba na více commitů, aby byla v několika commitech zdokumentovaná cesta a důvod velkých změn. Jenže na takový commit zase není možné uvalit merge request...

Stran: [1] 2 3 4