Příspěvky

211

Software / Re:Opatrná synchronizace dat mezi třemi systémy

« kdy: 10. 03. 2022, 08:14:50 »

Sycthing má v sobě webové UI, jsou k tomu i další GUI.

Opatrnost – přímo jak píšete asi ne, ale podporuje několik variant koše. Možná by to stačilo.

SSH – přímo ne, IIRC to používá TLS. Šlo by to dohackovat přes nějaké autossh, port forwarding a statickou IP adresu počítače. Ale toto už nebude čistě o naklikáni.

212

Studium a uplatnění / Re:Průměrná doba pracovní neschopnosti za rok?

« kdy: 24. 12. 2021, 23:18:06 »

Víkendy tam (aspoň v ČR) počítány být mohou a nemusejí, záleží, jak se to vykáže. Započítat do pracovní neschopnosti i přilehlé víkendy asi vyjde lépe finančně (podpora se počítá po kalendářních dnech, ne po pracovních), ale znamená to i delší „domácí vězení“. (Věřte mi, přes měsíc s rukou v sádře na nemocenské je opruz…)

213

Vývoj / Re:Rust - serde/bincode serializacia/deserializacia dat

« kdy: 18. 12. 2021, 17:47:50 »

Však; chtěl jsem odporovat tvrzení, že pak je lepší sáhnout rovnou po C.

214

Vývoj / Re:Rust - serde/bincode serializacia/deserializacia dat

« kdy: 18. 12. 2021, 16:07:24 »

Ad unsafe – je pravda, že tím dělá člověk z Rustu Céčko. Na druhou stranu, pokud bych měl mít kousek unsafe a zbytek ± idiomatický Rust, stále v tom vidím smysl.

Záleží, co od toho očekáváte. Ona low-level serializace a deserializace v podstatě bez unsafe nejde, protože tam narážíte na problémy, které jsem popsal. (Pravda, část z nich nesouvisí tolik s unsafe, ale stačí jeden, který souvisí.) Bez unsafe je několik možností:

A. Jak jsem psal v tom prvním příspěvku, zbavil bych se nadbytečného fieldu a hledal, jak ten enum tag serializovat do jednoho bytu. Možná bude fungovat to, co jsem poslal. Možná s tím bude problém, že budete serializovat jen ten tag bez dat,  ale to.snad zjistíte velmi rychle při pokusu o deserializaci.
B. Ty flatbuffers by taky mohly jít
C. Když všechno ostatní selže, můžete si udělat serializaci a deserializaci posvém.

215

Vývoj / Re:Rust - serde/bincode serializacia/deserializacia dat

« kdy: 18. 12. 2021, 12:35:47 »

Normální neznamená, že je to dobře. Ale OK, tady je to takové hraniční. Vidím trochu potenciál k flamewar.

Ono by se něco podobného jako v C dalo udělat i v Rustu. Je to ale za cenu raw unionů, transmute a unsafe. Pak se na libovolnou strukturu lze dívat jako na [u8]. Tím ale v podstatě z Rustu stává tak trochu C, a přináší to nevýhody s tím spojené:

* Výstup bude fixed-length.
* Pokud budou různé varianty unionu různě dlouhé, je tu asi riziko neinicializované paměti a úniku dat.
* Nepůjde použít pokročilejší (de)serializaci. V případě referencí výsledek asi nebude žádoucí…
* Little vs. big endian
* Nic nekontroluje validitu dat; pokud enum má dvě platné hodnoty, může dostat něco úplně jiného. Toto zavání nedefinovaným chováním.

Jinými slovy, i v Rustu to můžete udělat jako v Céčku, ale pak to máte jako v Céčku se vším všudy.

216

Vývoj / Re:Rust - serde/bincode serializacia/deserializacia dat

« kdy: 18. 12. 2021, 11:29:41 »

Bych na to možná reagoval, ale úplně nechci z diskuze o řešení serializace v Rustu dělat vlákno Rust vs. C.

217

Vývoj / Re:Rust - serde/bincode serializacia/deserializacia dat

« kdy: 18. 12. 2021, 00:49:50 »

Aha, tak s tím řešením délky tagu si nejsem jistý, to možná ořeže ten enum do podoby bez dalších dat. Ale nevím, až tak sběhlý v tom nejsem.

218

Vývoj / Re:Rust - serde/bincode serializacia/deserializacia dat

« kdy: 18. 12. 2021, 00:22:05 »

Možná pro to bude nějaký dobrý důvod, ale ten kód mi přijde příliš komplikovaný. MessageBodyType je již informace obsažená v MessageBody. Pokud se zbavíme MessageBodyType, zbývá snad už jen jeden problém, a to, že ten tag zabírá 4B a ne jen 1B. IIUC, to by mělo jít nastavit vhodným nastavením serde: https://stackoverflow.com/a/64512528

Drawback samozřejmě bude zpětná nekompatibilita, pokud by ten enum měl přes 256 variant. To plyne ze způsobu kódování. Pak by se jeho tag nevlezl do u8, a byla by to komplikace. Samozřejmě by to šlo řešit ála UTF-8, mít 256 variant enumu, z toho jedna bude Other, která bude kódovat ty zbývající. Hlavní by ale bylo si na to vzpomenout při přidání 256. varianty. Pokud si na to vzpomenete u 257. varianty, bude už z hlediska kompatibility pozdě.

219

Studium a uplatnění / Re:Mzda v ČR a v Evropě

« kdy: 17. 12. 2021, 12:05:15 »

Já jsem nepsal, že Indové jsou špatní programátoři. Nepochybně část tu bude špatná, možná (nemám statistiky) i více než je světový průměr, nevím. Nicméně Ind prostě může být snadno v horší pozici, právě kvůli pověsti Indů. U krátkodobé spolupráce je potřeba rychle vyhodnotit protistranu (větší vliv předsudků, nevýhoda pro šikovné Indy, zvlášť v začátcích), u dlouhodobé spolupráce je více času posoudit schopnosti individuálně (předsudky nemají tolik důvod se projevit).

220

Studium a uplatnění / Re:Mzda v ČR a v Evropě

« kdy: 13. 12. 2021, 09:43:38 »

Full remote může s cenou práce zahýbat. Zaměstnavatel najednou není omezen lokální pracovní silou a zaměstnanci nejsou omezeni lokálními pracovními příležitostmi. To nepochybně povede ke globálnějšímu trhu práce. Nicméně:

1. Není to čistě jen i tom, jak to máte vy osobně. Pokud by full remote bylo málo nabízené, bude to hrát do karet spíše zaměstnavatelům.
2. Někteří chtějí občas udělat team building. To s full remote moc nejde. Vám se to možná jedno, ale #2.
3. Jazyková bariéra. Ano, angličtina pomůže, ale nevyřeší vše.
4. Časová pásma mohou taky mít vliv. Pracovat pro firmu v Evropě je asi bez problémů. V případě USA nebo Austrálie to ale může nést různé praktické komplikace jako meetingy po večerech, a i to bude kompromis. Intenzivnější interakce možná nebude.
5. Mohou tu být různá právní, byrokratická a daňová omezení.
6. Ne všude mají programátoři stejnou pověst – zeptejte se někoho na Indy. Na druhou stranu, tam, kde půjde o dlouhodobější spolupráci, asi budou dělat detailnější průzkum, kde budou více řešit individuální schopnosti a vlastnosti a méně pověst skupiny lidí, kam patříte.

Tím neříkám, že nic takového jako globalizovaný trh práce s globalizovanějšími mzdami tu nebude. Myslím, že to půjde tímto směrem, ale omezeně.

221

Studium a uplatnění / Re:Oracle Brno

« kdy: 13. 10. 2021, 10:59:29 »

Strašně široce položený dotaz. I v Brně je možné být v různých týmech s různými šéfy, a fungování v GraalVM, OCI a NetSuite může být diametrálně odlišné.

222

Studium a uplatnění / Re:Kolik % marži mají firmy při bodyshopingu?

« kdy: 19. 08. 2020, 11:20:13 »

To záleží:

* Firma na některých věcech může mít úspory z rozsahu.
* Jako jednotlivec si musíte sám shánět zakázky a vyjednávat ceny. Ano, to musí i firma. Otázka je, jak moc je v tom kdo efektivní. Pokud na tom strávíte spoustu času (o to méně času máte na práci, za kterou dostanete opravdu zaplaceno) nebo vyjednáte nízkou cenu, může režie firmy vyjít ještě levně.

223

Studium a uplatnění / Re:Kolik % marži mají firmy při bodyshopingu?

« kdy: 18. 08. 2020, 08:56:10 »

Marže asi není úplně to, co vám někdo prozradí na potkání. A i podle třeba https://www.podnikatel.cz/clanky/neumite-spocitat-marzi-pak-radsi-vratte-zivnostensky-list/ v tom není započítána všechna režie. Ale i kdyby se to OP pokoušel započítat, jsou tu různé otázky:

1. Odkud ty údaje jsou? Ono započítat všechny náklady včetně různých režií a rizik nemusí být snadné, ani když tu firmu provozujete, natož když nemáte k dispozici citlivá interní data. Do nákladů patří i třeba věci jako nábor. A teď započítejte i neúspěšné pokusy a rozpočítejte to do hodinových sazeb různě ohodnocených lidí...
2. Kdyby se někdo náhodou rozhodl podělit se o svoje citlivá firemní data, jak moc to bude porovnatelné? Jak můžete vidět, není tu v diskuzi ani jasná shoda na definici marže, pak ale můžeme porovnávat hausnunera... A my třeba ani nevíme, jak je dohoda nastavena pro případ nemoci...
3. I kdybychom měli započítané všechny další náklady, jsou otázky typu druh vztahu (OSVČ/HPP/dohoda/...) na místě. I když budu počítat s náklady průměrně (po započítání všech rizik) třeba 150 000 CZK, je rozdíl, jestli se mi hýbou v rozmezí 80 000 – 500 000 CZK, nebo jen 100 000 – 200 000 CZK. Statisticky to vyjde nastejno, ale ve druhém případě máte vyšší míru nejistoty, takže je to méně výhodná situace...

224

Studium a uplatnění / Re:Vývojář bez znalostí

« kdy: 03. 08. 2020, 19:22:00 »

Ad (ne)dokončení školy – na to není jednoznačná odpověď. Jedni řeknou, že nemá cenu dokončovat školu, ve které člověk nevidí smysl, druzí budou argumentovat, že to vypadá, jako neschopnost dotáhnout něco do konce. Obojí je pravda, otázka je, co převáží. Nicméně těsně před cílem bych byl spíše pro dokončení, pokud to nebude zásadní zátěž.

Z hlediska získávání zkušeností vidím dvě protichůdné možnosti:

a. Být na úkol sám a nějak se s tím poprat. Je to někdy trochu jako skočit do Vltavy a učit se plavat, ale někdy to může být dost přínosné, zvlášť v ladění.
b. Mít poblíž nějakého zkušenějšího kolegu, který umí poradit. Občas řekne, že něco děláte moc komplikovaně, občas poradí něco dělat přehledněji...

Nejlepší se asi vyzkoušet si časem obojí, každé má jiný přínos.

225

Studium a uplatnění / Re:Mgr štúdium v česku - informatika

« kdy: 03. 08. 2020, 16:53:01 »

Ano, část FI se věnuje i zpracování přirozeného jazyka (aspoň za dob mých studií tomu tak bylo), a možná tam budou i programy pro hendikepované. Ale je to asi jako tvrdit, že se Albert zaměřuje na prodej ovoce. Realita je ale mnohem bohatší. Aspoň pokud fakulta od dob mého studia se nějak výrazně úžeji nespecializovala.