-- Část 1
Ahoj, děkuji za spoustu relevantních poznámek, odpovědí a rad! Všechny jsem je pomalu ale jistě pročítal a bral v potaz, aby však v této diskuzi nevznikl "chaos", tak jsem se rozhodl místo toho, abych vytvářel na každou odpověď nové "vlákno", že shrnu a odpovím na posledních +- 34 zpráv v jedné zprávě. Nutno podotknout, že nebudu reagovat na všechny, vzhledem k tomu, že není úplně potřeba vždy na vše reagovat, ale stačí si to přečíst a vzít k srdci
(jo a pokud by se vám zdálo, že je něco vytaženého z kontextu, ozvěte se prosím v další konverzaci! Citace zkracuji čistě protože jich v této odpovědi je hodně)
Tak mě napadá, nezvládl bys třeba toho bakaláře si napráskat do jednoho/dvou let, odchodit si přednášky, co tě zajímají, a ostatní projekty/úkoly jen formálně odevzdat.
- @hmmmw
> Zajímavé.... O něčem takovém jsem slyšel a trochu jsem nad tím přemýšlel, avšak nevím jak se to dá / nedá, nebo celkově jak to funguje?
.... možná přijde technokolaps ; zrušena hotovost ....
- @technomaniak
>
dej tomu pár let ;
Monero (celá tato odpověď je sakrasmus)
že jsou oblasti, kde to bez školy nejde a nebo jen s velkým úsilím
- @JaaSt
> Tohle je právě to čeho se tak trochu bojím... Bohužel moje aktuální zkušenost je to, že když se jednou za čas kouknu na nabídky, které by mě zajímali (něco více než řadový programátor), tak VŽDY vyžadují vysokou školu.
To ze neplatis skolny neznamena, ze to je zdarma
Nase skolstvi je cely koncipovany tak, ze se vzdy zacina od nuly
- @jjrsk
> "zdarma" bylo myšleno ve smyslu, že máme v Čechách tu výhodu, že pokud bych chtěl studovat, tak se
nemusím do konce života zadlužit, i když co přinese budoucnost
nikdo neví :/. Každopádně po tomto komentáři jsem si šel přepočítat kolik by mě +- stálo žít, a je pravda že realita je výší než jsem původně předpokládal
> Nevím přesně proč, ale přijde mi to špatně a správně zároveň. Polemizovat bychom tady o tom mohli dalších X hodin, ale stejně to asi nic nezmění, tudíž je to nejspíše fakt s kterým se budu muset smířit
ted jsi praktik, na vysce k tomu muzes ziskat teoreticke podklady.
- @alex6bbc
> Jenže, já nevím co to znamená? Co si pod tím mám představit? Jak je možné prohloubit teoretické chápání něčeho jako jsou například sítě, či architektury počítače? Protokoly a procesy se přece tak často rapidně nemění (
counterpoint, za chvíli pojede internet na UDP místo TCP, ale celý proces stejně trval okolo 12ti let)? Všechny tyto teoretické věci mám nastudované, vzhledem k tomu, že opravdu nerad pracuji "nad" technologiemi, kterým nerozumím. Například dneska jsem do jednoho mého projektu implementoval icmp ping request (ano, používá to knihovnu pnet, ale to kvůli tomu, že potřebuji aby byl projekt cross-platform + ji využívám na více místech programu), pointa je čistě to, že tyhle teoretické věci již mám projduté, ať už v rámci samostudia, či střední školy, kde se právě i takovéto teoretické věci učíme (
CCNA ;
Networking Essentials)
use std::{
net::IpAddr,
sync::{Arc, Mutex, RwLock},
thread,
time::{Duration, Instant},
};
use anyhow::anyhow;
use log::error;
use rand::random;
use pnet::packet::{
icmp::{
echo_reply::EchoReplyPacket,
echo_request::{IcmpCodes, MutableEchoRequestPacket},
IcmpCode, IcmpType, IcmpTypes,
},
ip::IpNextHeaderProtocols,
util::checksum,
Packet,
};
use pnet::transport::icmp_packet_iter;
use pnet::transport::TransportChannelType::Layer4;
use pnet::transport::{transport_channel, TransportProtocol};
const ICMP_SIZE: usize = 64;
pub const DEFAULT_PING_ENSURED_CONNECTIVITY_TIMEOUT_MS: u64 = 5000;
pub const DEFAULT_PING_ENSURED_CONNECTIVITY_CHECKUP_MS: u64 = 20;
struct PingStatus {
got_reply: bool,
reply: Option<EchoReplyInfo>,
stringified_err: Option<String>,
}
#[derive(Debug, Clone)]
pub struct EchoReplyInfo {
pub addr: IpAddr,
pub rtt: Duration,
pub identifier: u16,
pub icmp_code: IcmpCode,
pub icmp_type: IcmpType,
pub raw_packet: Vec<u8>,
pub raw_payload: Vec<u8>,
pub checksum: u16,
}
// Could be optimized by sending multiple pings at once, but I don't really care about perfomance atm
// Pro forum.root.cz:
// Vím že to není úplně nejoptimálnější řešení, ale funguje :D. Ideální by bylo místo spawnování threadu udělat to asynchronní,
// ale to je bohužel (aktuálně) poměrně těžké v kontextu celé aplikace -- jedná se o egui (což je immediate ui), tudíž musím spawnout nový thread
// abych neblokoval renderování + kdyby to hodilo error tak aby nespadla celá aplikace, tak celá tato funkce je volaná ještě z dalšího threadu, tudíž na jeden ping spawnuju 2 thready,
// což je extrémní neefektivní blbost, ale kvůli rychlosti vývoje je to aktuálně preferované řešení a abstrakce je psaná tak aby to v budoucnu byl jenom implementační detail.
// V budoucnu to plánuju sepsat tak že spawnu na začátku druhý thread a tomu budu do queue posílat async tásky, a potom budu na output reagovat na začátku/konci každého re-renderu
pub fn send_icmp_echo_request_ping(
address: IpAddr,
ping_timeout_ms: u64,
ping_checkup_ms: u64,
) -> anyhow::Result<Option<EchoReplyInfo>> {
let protocol = Layer4(TransportProtocol::Ipv4(IpNextHeaderProtocols::Icmp));
let (mut tx, mut rx) = match transport_channel(4096, protocol) {
Ok((tx, rx)) => (tx, rx),
Err(e) => return Err(e.into()),
};
let mut icmp_header: [u8; ICMP_SIZE] = [0; ICMP_SIZE];
let icmp_packet = create_icmp_echo_request_packet(&mut icmp_header);
let sent_at = Arc::new(RwLock::new(Instant::now()));
tx.send_to(icmp_packet, address)?;
let status: Arc<Mutex<PingStatus>> = Arc::new(Mutex::new(PingStatus {
got_reply: false,
reply: None,
stringified_err: None,
}));
let closure_status = Arc::clone(&status);
let closure_sent_at = Arc::clone(&sent_at);
thread::spawn(move || {
let mut iter = icmp_packet_iter(&mut rx);
match iter.next() {
Ok((packet, addr)) => {
if let Some(echo_reply) = EchoReplyPacket::new(packet.packet()) {
let mut new_status = closure_status.lock().unwrap();
new_status.reply = Some(EchoReplyInfo {
addr,
rtt: Instant::now().duration_since(*closure_sent_at.read().unwrap()),
identifier: echo_reply.get_identifier(),
icmp_code: echo_reply.get_icmp_code(),
icmp_type: echo_reply.get_icmp_type(),
raw_packet: echo_reply.packet().into(),
raw_payload: echo_reply.payload().into(),
checksum: echo_reply.get_checksum(),
});
new_status.got_reply = true;
}
}
Err(e) => {
error!(
"An error occurred while reading icmp echo request ping: {}",
e
);
closure_status.lock().unwrap().stringified_err = Some(e.to_string());
}
}
});
let ping_timeout = Duration::from_millis(ping_timeout_ms);
let ping_checkup = Duration::from_millis(ping_checkup_ms);
loop {
thread::sleep(ping_checkup);
let status_lock = status.lock().unwrap();
if let Some(err_text) = status_lock.stringified_err.clone() {
return Err(anyhow!(err_text));
}
if status_lock.got_reply || Instant::now() - *sent_at.read().unwrap() > ping_timeout {
return Ok(status_lock.reply.clone());
}
}
}
fn create_icmp_echo_request_packet(icmp_header: &mut [u8]) -> MutableEchoRequestPacket<'_> {
let mut icmp_packet = MutableEchoRequestPacket::new(icmp_header).unwrap();
icmp_packet.set_icmp_type(IcmpTypes::EchoRequest);
icmp_packet.set_icmp_code(IcmpCodes::NoCode);
icmp_packet.set_identifier(random::<u16>());
icmp_packet.set_sequence_number(1);
icmp_packet.set_checksum(checksum(icmp_packet.packet(), 1));
icmp_packet
}
Pokud se vážně zakousnete do low-level věcí a embedded vývoje, jako že mezi hardwarem a co se děje v kernelu, napadá mě jeden konkrétní potenciální zaměstnavatel, se kterým byste výhledově mohl mít společné zájmy: Sysgo
- František Ryšánek
> Sysgo vypadá hooodně zajímavě! Upřímně jsem měl trochu v plánu se příští rok před vysokou hlásit na nějakou delší embedded, nebo security code auditing stáž, aktuálně si znalostmi ještě nevěřím, protože jsem ještě ani nesestavil svoji vlastní funkční desku, ale určitě to tam na příští rok zkusím!
.... Ako spolupracovat s ludmi, ktorych nemas rad .... Kedze ale za sebou uz nieco odrobene mas, tak mozno toto ani nepotrebujes
- @Halofon
> Upřímně tohle je něco co mi chybí. Aktuálně jsem měl zatím pořád štěstí spolupracovat pouze se super lidmi a v jednu chvíli jsem pracoval v max 3 členném týmu, tudíž i to je důvod proč tam jít. Je pravda že jsem snad na každé škole viděl nespočet skupinových projektů.
Najít člověka bez VŠ vzdělání, který by znal rozdíl mezi joiny u SQL, který by uměl vyhodnotit latency systému v čase (vlastně správně počítání percentilu a směrodatné odchylky bývá velký problém), který by dokázal popsat běžné komunikační protokoly a jejich vliv na bezpečnost, dostupnost, latency a propustnost, který by chápal rozdíl mezi heapou, stackem a různýma datovýma strukturama v javě je prostě problém.
- @_Tomáš_
> Uf, to jsou docela základy no... Druhá věc je, že je důležité vědět kdy jaké abstrakce
SPRÁVNĚ aplikovat (to je naopak něco co jsem si všiml že často neumí lidé z vysokých škol, kteří se látku nadrtili)! Je sice pravda že věci jako Hashmapa mají hledání v čase O(1), avšak 90% času je rychlejší normální array (čistě kvůli tomu že procházet hodnoty poskládané za sebou v paměti je milionkrát rychlejší než kalkulování daného
hashe v konstantním čase)! Velká "O" notace označuje to jak roste počet operací na základě počtu prvků, ne to jak rychle algoritmus běží! Například
toto je dle mého názoru jedno z správných míst, kde použít hashmapu. Tím se snažím naznačit, že je často důležité uvědomit si s kolika prvky reálně budu pracovat, jelikož pokud vím že budu pracovat např s
klávesami a vím že čísla kláves se pohybují od 0 do 256 tak je možná jednoduší předalokovat prázdnou array a jednotlivou klávesu reprezentovat jako index, než vymýšlet jak to budu dělat přes nějakou datovou strukturu, jelikož direct access do paměti je a vždy bude rychlejší než složité algoritmy (nehledě na to, že použití těchto datastruktur vypadá dobře na papíře, avšak v realitě za použití těchto algortimů dochází ke spoustě
CPU cache missům. Co se tím snažím říct je to, že je extrémně důležité znát
VŠECHNY tradeoffy daných datových struktur a algoritmů.
Zde je docela zajímavý poslech na toto téma od Bjarne Stroustrupa (tvůrce jazyka c++). A tato myšlenka by mohla pokračovat dál na programovací koncepty, například pokud mi někdo řekne že leakování paměti nemá své využití, předem mohu říct že pořádně neví, jak funguje paměť, jelikož leakovat paměť je velice užitečné, pokud máte např program který potřebuje něco extrémně rychle udělat a potom se vypnout (hint: při vypnutí systém stejně paměť uvolní, takže pokud jí leakuju po krátkou dobu životnosti programu, nemusím řešit cleanup, který je poměrně drahý, co se operací týče). TLDR; ano, je dobré znát teoretickou část datastruktur, algortimů, komunikačních protokolů a atd, ale zdá se mi že je v dnešní době extrémně málo známá praktická část těchto témat. Spoustu lidí prostě řekne že je to rychlejší a konec, i když to tak nemusí úplně být. Vlastně celý tento odstavec byl o tom že s Vámi souhlasím, ale měl jsem potřebu k tomu dodat pár mých názorů
. PS: Zkuste si rozjet
quick sort VS
counting sort na N množství prvků v hodnotách do u8max
. Prostě se snažím říct že je důležité vědět jak správně dané algoritmy uplatnit a né že vidím search mezi hodnotami a hnedka na to
mrdnu Hashmapu.
První taková aproximace je přečíst si Průvodce a měl bys tomu rozumět.
- @_Jenda
> Za odkaz na průvodce děkuji, určitě ho přidám do seznamu budoucí četby! Jak jsem ho ale trochu proletěl očima, tak rovnou vidím, že s ním budu mít ten samý problém co jsem vypíchl výše, a to je to že určuje účinnost algoritmu na základě "O" notace, což není špatně, ale celou problematiku cache misů, toho že konstantní neznamená vždy rychlejší, a podobě (se zdá že, ještě jsem to nepřečetl, ale jenom proletěl očima) smete ze stolu prvními dvěmi odstavci na stránce 42, viz citace:
Dejme tomu, že chceme změřit dobu běhu našeho příkladu „Hello world“ z předchozího
oddílu. Spustíme-li ho na svém počítači několikrát, nejspíš naměříme o něco rozdílné časy.
Může za to aktivita ostatních procesů, stav operačního systému, obsahy nejrůznějších
vyrovnávacích pamětí a desítky dalších věcí. A to ještě ukázkový program nečte žádná
vstupní data. Co kdyby se doba jeho běhu odvíjela od nich?
Takový přístup se tedy hodí pouze pro testování kvality konkrétního programu na konkrétním hardwaru a konfiguraci. Nezatracujeme ho, velmi často se používá pro testování
programů určených k nasazení v těch nejvypjatějších situacích. Ale naším cílem v této kapitole je vyvinout prostředek na měření doby běhu obecně popsaného algoritmu,
bez nutnosti naprogramování v konkrétním programovacím jazyce a architektuře. Zatím
předpokládejme, že program dostane nějaký konkrétní vstup.
programátoři jsou buď Umpa-lumpové nebo Vonkové, první jsou divní trpajzlíci, řadová omáčka, kterou řídí Vonkové....no a Vonka byl původně Onka, než si udělal VŠ
- @CPU
> Za komentář a odkazy na Karlíka a továrna na čokoládu děkuji, takhle dobře jsem se dloooouho nepobavil xDD. Pokud bych měl být úplně upřímný, mám docela problém s tím že nechci být řadový programátor, jelikož mám docela problémy s tím pracovat jak někdo píská. Zároveň ale aktuálně postrádám zkušenosti a možná i sebevědomí na to dělat managera. Můj hlavní problém je v tom že doslova úplně všechny (školní i volnočasové) projekty, které jsem v minulosti vedl bych kategorizoval jako osobní selhání, jelikož jsem nebyl schopný donutit ostatní pracovat (doslova 0 commitů od mých "spolupracovníků" po X týdnech, když jsem jasně přiřadil práci, samozřejmě i SOBĚ), takže to vždy skončilo tak že jsem to stejně udělal sám (nejenom že to nakonec bylo Xkrát rychlejší, ale to mě od managementu poměrně odradilo). Od té doby většinou skupinové projekty dělám sám, nebo pokud jsem donucen spolupracovat, řeknu něco ve stylu: "Udělám tohle a tohle (většinou okolo 50% celkové práce), zbytek je na vás, GL HF". Naopak co mi extrémně vyhovovalo bylo, když tým vedl někdo velice zkušený, ale zároveň mi dával insight a probíral se mnou další vývoj po technologické i business stránce, tudíž jsem vždy mohl lépe chápat a ovlivnit budoucí dění a vývoj. Takovouto spolupráci jsem měl v AKAENE pod Ing. Martin Ledvinka, Ph.D. a nemůžu si to vynachválit! Myslel jsem si že bych se mohl v něčem takovém zlepšit tím, že bych vedl kroužek, což jsem udělal, ale líp než
poslední věty tohoto blog postu kde jsem o tom psal, bych to popsat nemohl (hodím sem jako quote, ať nemusíte chodit na jinou stránku):
Personally, I really enjoyed and am thankful for this experience / opportunity, truth be told, it gave me a lot of insight to see the process of teaching from the other side, however, I do not feel like I would like to repeat it in the near future again. It was fun and all, and the students were more than amazing, however, it was very, I mean VERY, hard. I always questioned myself if the lessons were enjoyable, whether I explained something correctly, and whether I communicated the knowledge the way I intended it. I like explaining stuff I know a lot about, and sharing my knowledge with the people that ask me in general, however, 90 minutes is a bit too much (even for me ). Another thing I did not like was the position of authority. I usually prefer more leveled / equal work-related relations. Don't get me wrong, I am able to respect and acknowledge that something / somebody is an authority, but, I feel like I don't have it in me to BE the authority at the moment (like come on, I'm 17 ).
Nějaké rady, tipy, triky a názory? Nejenom že mám problém když někdo píská a neříká mi proč a nedá mi možnost do toho vstoupit, ale mám zároveň i problém být v pozici kdy pískám, jelikož extrémně nerad otravuju lidi. Pozice toho kdy jsem někde "mezi" těmito rolemi mi tak nějak zatím vyhovuje (DevOps zní docela hezky? Docela, jak toto píšu, přemýšlím že DevSecOps by nemuselo být úplně špatný, jelikož to splňuje všechny moje požadavky?). Chápu že management je asi "další krok" pro většinu programátorů a osobně si dokážu představit že bych přes den dělal management a po práci bych si dělal svoje programovací projektíky, ale trochu se bojím že by ze mě tuny byrokracie pomalu ale jistě vysáli život. Další věc je, že se dnes bohužel i programátor potýká s
tunou byrokratických procesů....projektové řízení se musíš pořádně naučit jako programování, jinak to bude daleko větší dřina...
- @CPU
> Nojo, jenže učit se programování je o tom že nad tím při nejhorším ztratím svůj čas. Učit se projektové řízení je o tom, že potencionálně ztratím čas X lidí, financování které do projektu padlo a pokud nebudu dostatečně rychlý, tak projektu peníze dojdou nebo to nestihnu dotáhnout dostatečně rychle na market. Hlavně, jako programátor vím, že jakýkoliv odhad který mi programátoři dají je nereálný, jelikož odhadnout vývoj softwaru je extrémně těžké! Na projekt působí X neznámích proměnných, které se mohou změnit nebo
posrat N různými způsoby. Jak se to potom člověk má naučit!
58 Odpovědí
20790 Zhlédnutí