Na svůj věk máte na spoustu věcí překvapivě jasný názor. Jako že když se nezadaří dokonale skloubit práci a zábavu, tak v práci vydělávat peníze a hezkou tvorbu si řešit ve volném čase (než přijde rodina, a pokud zaměstnavatel dovolí). Nebo to věčné dilemma, zda "jít šéfovat" znamená pro schopného codera cestu někam vzhůru.
Můj subjektivní názor: nejlepší budete v tom, co Vás baví. Pokud NEjste ten typ, který ví jistě, že chce co nejdřív šéfovat, tak si s tím možná teď nelamte hlavu. To rozhodnutí může přijít později, v práci, ad hoc. Pokud máte určité podezření, že to tak časem může dopadnout, tak v tuhle chvíli chybu neuděláte, pokud na vejšce absolvujete pár kurzů o project managementu, řízení vývoje SW apod. Netroufnu si tvrdit, zda je pro tenhle směr lepší VŠE, FIT ČVUT nebo která škola. Pokud budete nějakými školními vědomostmi v tomto směru poznamenaný, tak to z Vás bude na pracovišti určitým způsobem vyzařovat, i pokud zůstanete nominálně na čistě technické pozici. A můžete třeba citlivě inspirovat svoje šéfy, když vidíte, že zkoumají slepé uličky, které vy ze školy znáte předem, nadšeně objevují kolo apod.
Jak při vedení projektu odhadovat pracnost / časovou náročnost: na tohle téma jsem před nějakou dobou viděl povídání uncle Boba Martina.
https://www.youtube.com/results?search_query=uncle+bob+martin+on+estimationStručně: ono to bolí, nejde to přesně, a v průběhu projektu se ten odhad bude upravovat, ale je třeba mít aspoň něco. Zákazníci jsou vděční za aspoň nějaký odhad, a za včasné upozornění, pokud odhad bude nutné upravit. Popisoval tam metodu s kartami, já bych k tomu přidal Ganttův graf. Vlastně mám z blízkého okolí takový příběh i z praxe. Když se bavíte s novým potenciálním zákazníkem o případném projektu nějakého vývoje, tak v momentě, kdy vytáhnete aspoň Ganttův graf, a je jedno co v něm je, najednou zmizí pochybnost o tom, zda na to máte.
Ve škole nám říkali, že databáze reálných průběhů a časových náročností předchozích softwarových projektů je největším bohatstvím projektového managera :-)
Jak již výše zmíněno, otázka je, zda by Vás tahle práce jednou bavila. Šéfování znamená řešit lidi a jednat s nimi, být ve dvojím ohni (zdola i shora), komunikovat se zákazníkem, věčně řešit že je někde skluz / průser, uklízet po ostatních když udělají chybu, chodit na porady...
Jsou lidi, kteří přesně tohle chtějí, a třeba jdou "cestou rychlokvašky" = vystudují šéfování a jdou rovnou ze školy šéfovat.
A znám taky firmy, kde někdo na úrovni generálního ředitele na část úvazku dělá softwarový vývoj nebo něco na ten způsob. A třeba si i nechá v tomto dílčím oboru šéfovat od svého jmenovitého podřízeného (šéfa vývoje softwaru).
A ještě jiná otázka je, zda se dokážete dostat na šéfovskou pozici někde, kde pod sebou budete mít lidi natolik schopné, že se Vám nebude neustále otvírat kudla v kapse, že byste jejich práci nejradši udělal sám.
Naprosto s Vámi souhlasím v jedné věci: není větší žůžo, než mít šéfa, který rozumí svojí práci a je to "člověk na svém místě". Mě se to párkrát poštěstilo (jsem stárnoucí umpalumpa, ovšem nikoli programátor).
Na úroky jsou primitivní hotové vzorce. Úročitel / odúročitel / střadatel / fondovatel / umořovatel / zásobitel. Ne že bych si je pamatoval, jenom vím, že když budu potřebovat, stačí si to nalistovat. Jinak prosté složené úročení je trapná N-tá mocnina (exponenciála podle času). A ty pojmenované vzorce do toho přidávají různé varianty průběžného spoření/umořování nebo čerpání jistiny.
Clean code: už máte dost vlastního rozumu, než abyste skočil na špek youtuberovi, který si zvyšuje počet zhlédnutí provokativním obsahem. (Vyfabuluje falešnou modlu a pak ji půl hodiny horlivě vyvrací.) Mimochodem... za mých mladých let býval na ekně předmět, kde se bazírovalo na strukturovaném programování a studenti byli nuceni, používat jednoduchý grafický editor vývojových diagramů, ze kterých měl padat hotový strukturovaný kód v Pascalu... fungovalo to bezvadně jako lekce "tudy cesta vážně nevede, tzn. přinejmenším nic se nesmí přehánět". Naštěstí to tak chápali nakonec i vyučující. Tolik k různým idealismům.
Ještě k té low-level problematice a kam se "studijně zaměřit", ať už ve škole nebo na vlastní pěst:
Obecně v dnešní době nemohou umět všichni všechno. Osobně razím zásadu, že o co jsem si prakticky nenatloukl nos, tomu nemohu pořádně rozumět. Zároveň ten proces praktických pokusů a omylů vždycky trvá nějaký nenulový čas, přestože máte třeba předem teoreticky nastudováno. A času máme všichni stejně. Z toho právě plyne, že nemůžete umět všechno, protože to prostě nejde stihnout. A od toho máme dělbu práce. I ve firmách, které vyvíjejí embedded věci, pro automotive nebo jinam, existuje dělba práce minimálně na návrháře desek a programátory softwaru (ti se dále člení). Není špatné, pokud programátor blízko hardwaru třeba někdy držel v ruce páječku nebo si navrhl plošák, ale asi není úplně vhodné, aby dělal oboje. U projektu většího než triviálního to není časově možné.
Bohužel český domácí trh, tím že je malý, je zřejmě odsouzen do role "téměř čistého konzumenta integrovaných řešení". Není tu až tolik fajnové vývojářské práce pro globální trh - většina firem v širším oboru IT skládají dohromady stavebnici, kterou vyvinul a vyrábí někdo jiný. To co tady tvoříte, tvoříte často jednorázově nebo pro relativně malý počet zákazníků. Čest výjimkám, které se uchytily se svým produktem na globálním trhu.
Sysgo jsem zmínil hlavně kvůli jejich projektu PikeOS. Je to zajímavý kus softwaru, na kterém pracují špičkoví programátoři. Popravdě třeba nevím, jaký s tím mají úspěch na trhu... I v téhle firmě bude řada různých pozic s různou náplní práce.
Pokud pomineme programování MCUček přímo na holém železe, jsou v "embedded" oblasti populární různé RealTime operační systémy (RtOS). Tzn. tu nejtěžší dřinu už někdo odvedl. Pokud byste se motal kolem nějakého RtOS, tak nejspíš jako údržbář kernelu / tvůrce ovladačů pro periferie / tvůrce "aplikačního" softwaru. Nemám ale o tomhle trhu valný přehled. Různých malých RtOS je spousta a podle mého zdaleka ne všechny jsou kdovíjak úspěšné. Takže je otázka, čeho se chytit, co je perspektivní.
Hardware vespod může být PCčko nebo ne-PCčko.
Osobně znám z práce především x86 PC hardware. Jakožto profesionální průserář hlavně hledám mouchy na věcech, které navrhl někdo jiný - což není úplně tvůrčí práce, zcela jistě nikoli pro globální publikum. Snažím se problémy řešit přednostně v technické rovině, takže se občas o hardwaru něco dozvím...
Napadá mě nějaké prázdninové čtení na pomezí oborů PC HW / OS, případně o x86 asm/disasm...
Nevím, zda je zrovna tohle Váš obor zájmu, nebo jestli třeba nejste dávno úplně jinde...
berte nebo nechte bejt :-) a přeskakovat termíny či pasáže, kterým zatím nerozumíte, to jistě ovládáte dávno. U mě je to vždycky otázka motivace. Nejlíp se mi študuje nějaká neznámá oblast, pokud narazím na praktický problém, který mě k tomu poňouká. Číst to jako beletrii mi moc nejde.
Tak tedy:
Vynechávám letitý materiál, jak se daly PCčka programovat v éře MS-DOSu, jak si napsat holý DOSový exáč v ASM, jak sahat na paralelní port apod. Ta doba je pryč, pro Vás mladé už to nemá ani tu nostalgickou hodnotu.
Vzpomněl jsem si na pár článků od Michaela Kourdakise - začnu zprostředka článkem, který načrtává, jak na holém x86 hardwaru odstartovat SMP. V úvodu jsou tam hned odkazy na předchozí díly, které se více věnují základům.
https://www.codeproject.com/Articles/889245/Deep-inside-CPU-Raw-multicore-programmingZkusil jste si stáhnout nějaký disassembler? Třeba free edici IDA Pro.
https://hex-rays.com/ida-free/A loadnout nějaký binár, a koukat, jak vypadají funkce disassemblované z bináru, který původně vypadl nejspíš z Céčkového kompilátoru.
Nedávno jsem narazil na webíky jedné paní z Polska, která se věnuje hlavně analýze malwaru a napsala pro tyto potřeby i nějaké jednoduché pomůcky (software).
https://hshrzd.wordpress.com/how-to-start/https://hasherezade.github.io/https://www.youtube.com/@hasherezade/videoshttps://twitter.com/hasherezadeFormáty binárek:
https://en.wikipedia.org/wiki/Comparison_of_executable_file_formatshttps://en.wikipedia.org/wiki/Portable_Executablehttps://en.wikipedia.org/wiki/Executable_and_Linkable_FormatK nahlédnutí do hlaviček PE binárů existují editory.
Klasiký byl LordPE, který je ale tuším 32bit-only.
Aktuálně mi Google našel toto:
https://github.com/petoolse/petools/releasesOhledně RtOSů... měl jsem v úmyslu, navrhnout nějaké čtení ohledně RTAI, protože je z toho hezky vidět některé problémy, které se různé RtOS snaží řešit... ale boužel RTAI vypadá poněkud polochcíple :-) Hrál jsem si s tím asi před 15 lety a tehdy mi nějaké základní examply fungovaly.
RtOS může existovat buď samostatně jako plnohodnotný OS na holém železe, nebo může tvořit nějaký "hybrid" se stolním OS. Viděl jsem zřejmě cca následující hybridní varianty:
a) na holém železe RtOS mikrokernel, normální OS běží jako jeden z jeho tasků. Takto funguje RTAI a další.
b) na holém železe běží normální OS, který se ale dá přesvědčit, aby se vzdal jednoho konkrétního jádra CPU (nebo i více jader) a na těchto jádrech se zahnízdí "real-time exekutiva". Koordinací s "hostitelským OS" lze nalinkovat doručování IRQ od konkrétní periferie na procesory zabrané RtOS. Tady mě napadá B&R ARwin, který jsem viděl na vlastní oči.
c) RtOS má svůj vlastní hypervizor, normální OS běží vlastně ve virtuálu
Nicméně je třeba říct, že na spoustu "real-time" věcí vlastně stačí standardní Linux :-)
Možná bych na závěr ještě k PCčkům zmínil pár svých tlejících starších spisků:
http://support.fccps.cz/download/adv/frr/MSI/PCIe-MSI.htmlhttps://stackoverflow.com/questions/27470885/how-does-dma-work-with-pci-express-deviceshttps://electronics.stackexchange.com/questions/76867/what-do-the-different-interrupts-in-pcie-do-i-referring-to-msi-msi-x-and-intx/343218#343218
Zobrazit příspěvky
