Příspěvky

121

Hardware / Re:Zpomalování procesoru při hře

« kdy: 02. 11. 2020, 10:48:10 »

S příčinou neporadím, ale popisované chování je skutečně podezřelé. Mám i5 9400H (Dell Latitude) a při plné zátěži jede chvíli na plnou frekvenci (4.3GHz) pak po malé chvíli začne klesat a oscilovat mezi nějakými 2.5-3.2GHz. A tam se to drží (s teplotou kolem 90-95stp). Vždy je vidět, že zesílí větráky, tak teplota mírně klesne, frekvence se mírně zvýší, pak zvroste teplota, tak zase mírně srazí frekvence...  Nějak se to stále snaží držet na co nejvyšší frekvenci při tom teplotním stropu. Není moc příjemné na levé straně klávesnice držet ruku nebo tam třeba i mít myš Bohužel se to prostě neuchladí tak, aby to v TB jelo furt. Jeden z důvodů, proč jsem si nepřiplácel za lepší CPU (měl bych větší výkon jenom chvilkově..). Nevím, jestli to vůbec u notebooku (rozumně velkého a těžkého je možné?

Pak mám taky desktop (i7 8600) a tam to jede nonstop na to turbo, i s levným chladičem od SilentiumPC a obyčejnou bednou s jedním 12cm větrákem. S prstem v nose a teplotní rezervou. Ale na záda si to "do terénu" nevezmu..

122

Desktop / Re:Virtuální linuxový desktop ve VirtualBoxu

« kdy: 30. 10. 2020, 11:42:09 »

Pro docker na widlich je par reseni a vsechny jsou na hovno.

Jako ten docker toolbox (distribuce s "nativním" klientem a virtualbox mašinou, kde běží server a nějakými utilitami kolem) mi vcelku funguje, žádné větší problémy neřeším, akorát performance je samozřejmě horší oproti nativnímu dockeru pod linuxem. (virtualbox neumí efektivně používat multithreading, dokonce při nastavení více virtcpu než je fyzických jader hlásí neplatnou konfiguraci, takže cpu jede 50-60%).

 

123

Desktop / Re:Virtuální linuxový desktop ve VirtualBoxu

« kdy: 30. 10. 2020, 10:37:00 »

Čistě laický dotaz k tomu WSL2. Zkusil jsem přes to běžet docker. Vyvíjím několik větších projektů v javě (v IDEA), potřebuju je přes docker compose spouštět a ladit. Pro docker ve windows je víc řešení. Nejstarší - a které se mi osvědčilo a zatím u něj zůstávám - používá virtualbox vm, ve které běží docker server. Klient a všechno ostatní je "nativně". Dál mají docker desktop který běží buď přes hyperv nebo wsl2. Zkusil jsem to a první dojem byl špatný.

Je to hodně pomalé.  Například build docker image přes maven plugin trvá tak 4x déle než u toho legacy řešení s VB a to je u největšího projektu ca 12min vs 3min a v praxi nepoužitelné. Pull je taky pomalejší.

Četl jsem, že problém může být, že soubory projektu jsou na windows filesystému a ne v tom "virtuálním filesystému". Že je tam velká výkonová ztráta. To bych tam ale předpokládám musel přesunout všechno? (git, maven repozitář, IDE?)  V podstatě bych měl udržovat ten virtuální systém spolu se všemi tooly...  a IDE nechat taky běžet linuxové přes ten x.org? Opět, laický pohled - WSL neznám - ale na první pohled je to dost komplikované oproti virtualboxu..

Zajímavé je, že start/běh těch kontejnerů zas tak ovlivněný není. Naopak bych řekl, že je to o fous rychlejší než s tím VB. Problémem tedy budou intenzivní operace s filesystémem (při kompilaci, buildu image atp. se přesýpají stovky mega a hromada filů). Nevím přes jaký protokol komunikuje v tom legacy řešení hostová mašina (kde jsou zdrojáky, tooly a docker klient] s virtuálkou (kde je docker server), ale překvapuje mě, že tam není až tak velká výkonová ztráta (zkoušel jsem celé rozjet i na linuxu nativně a zpomalení tam bylo, možná 20%?? ale nic co by v praxi příliš vadilo). Ten WSL2 engine mi přijde v tomhle ohledu nepoužitelný. Nebo to používám špatně.

Používáte to někdo na vývoj s dockerem v popsaném use casu (velké projekty, java, IDEA)? Jak s tím fungujete?

124

Studium a uplatnění / Re:Jak efektivně studovat programování?

« kdy: 27. 10. 2020, 11:17:43 »

K tématu tazateli: na různé skripty/řádkové tooly se mi nejlépe osvědčil Python. To je také jazyk, který "frčí" ve strojovém učení, big data, v automatizaci atd. Takže se znalost určitě neztratí. Syntax je elegantní, čitelná (i pro laika nebo člověka přicházejícího z jiného jazyka). Dají se v tom dělat i weby (django, flask) ale s tím nemám zkušenost.

Web má backend (práce s databází, business logika) a frontend část.

Pro backend  je moje volba Java. Jak bylo řečeno, ekosystém a komunita jsou obrovské, vyspělé, mnoha lety utvářené. IDE pro javu od IntelliJ je top (programuje za mne kolikrát líp než já ala "simplify this code"). Jazyk se dá rychle naučit. Strmější křivku učení vidím v knihovnách/frameworcích bez kterých se v praxi člověk neobejde.

Ve velké většině případů v souvislosti s javou uslyšíš o Spring/Hibernate. Tyhle dva frameworky se dlouhá léta pro vývoj používají a je to dospělé, robustní a funknčí řešení. Je to také velice pohodlné na použití. Jako takové SUV audi, sedneš, nastartuješ (možná přečteš pár základních pouček) a jedeš. Všechno se zdá snadné, všude samí asistenti, řídí se to samo. Ale jako se vším tady je druhá strana mince. Zejména ten Hibernate/JPA považuju za hodně komplexní věc, která na jednu stranu extrémně urychluje vývoj, na druhou stranu je to procházka polem plným vidlí. Každou chvíli na nějakou člověk může šlápnout a praštit se do hlavy. A ve finále ten nadšený začátečník zjistí, že chtěl výši platu pana Pepy, ale stahuje kvůli tomu z databáze všechny účetní knihy, data všech zaměstnanců, sklad výrobků a dokonce kompletní jízdní řád českých drah (evergreen). Nebo že dostane místo toho čísla divnou chybu (něco o "líném začátku" nebo tak). Napálí se na to každý. Opravdu každý kdo si s Hibernate něco začne Rozhodně používat (používá to každý), ale je potřeba k tomu přistupovat s respektem, studovat specifikaci, vědět jak to funguje a číst také články o best practices s používáním tohoto frameworku. Skutečným machrem na JPA (ale relační databáze obecně) je Vlad Mihalcea, doporučuju jeho články.

Jinak proč ten hibernate používá (skoro) každý - nikomu se nechce pořád dokola psát SQL příkazy na vytažení dat/updaty z/do dtabáze. Tak je za sebe nechává psát framewrok. Je to složitější, ale princip je tenhle.

Spring zase během chvilku umožní nasetovat aplikcai (přístup do databáze, spuštění webového kontextu atd.) řeší takový ten "boiler plate" kód (který nijak nepomáhá tomu, co dělá aplikace, ale je to nutné zlo, aby to celé fungovlao dohromady). Spring je dle mého méně zákeřný a více se dá používat jako "černá krychle" která pod pokličkou nějak funguje a dělá co má. Ale do jisté míry platí totéž co pro ten Hibernate.

Frontend nevím, není to úplně moje parketa.  Jednodušší web se dá udělat v javě (tedy všechno na server straně). Modernějí a lépe na mě než JSP působí Thymeleaf. Spring má perfektní podporu. Ale v praxi jsem to nepoužil.

125

Studium a uplatnění / Re:Jak efektivně studovat programování?

« kdy: 27. 10. 2020, 10:43:45 »

Reseni GO je jenom znpouzectnost a vynucovani pouziti Err je rovnak na ohybak.
V Jave taky muzes vracet errory primo z metody (tedy ne primo dve hodnoty ale bean s dvema atributy valu,err)
A mas to samy co v GO. Nikdo to nepouziva protoze je to k nicemu.

Vyjimky oddeluji business kod od error handlingu, kdyz potrebuju resit chybu inplace, vyresim ji inplace.
Nechat probublavat exception neni zadna lenost ale obri vyhoda.
..

imho je to úhel pohledu/názoru a toho, na co se člověk naučí. Sám jsem dlouholetý javista, v GO jenom "poučený laik" a mechanismus výjimek je mi blízký (a GO přístup pro mne nezvyk).

try..catch..finally je elegantnější a líp použitelná konstrukce, to bych souhlasil. Znovu ale jenom jsem psal, že runtime exceptions -- ač mají tyhle výhody v jednoduchosti použití atp. -- vedou k tomu, že chybu řešit nemusím, a to ani inplace, ani v catch bloku ani v signatuře metody a to je pro mne s otazníkem. Že možná očekávaná (!) chyba není součástí kontraktu. Že ji volající klient může ignorovat a nechat řešit "automagií" (tedy probublat z metody ven, což je jen jedna z možností jak tu chybu ošetřit a ta se za mě vybere automaticky). Že vlastně ani nemusí na první dobrou vidět, že taková očekávaná chyba nastává. Možná je to úleva lenosti na úkor bezpečnosti kódu Ignorovat a  neošetřovat chyby ("SE" to vyřeší) je nízko visící ovoce. Pak nastávají ty situace (nejlépe až na produkci) co jsem popisoval.  Mluvím z praxe.

Jinak tenhl ekonkrétní případ by se v GO dal určitě napsat líp. GO umí funkce vyššího řádu a můžu si připravit šablonu (funkci), a volání té funkce dát do ní. Já vím... můžeme to prohlásit za narovnávák na..  Ale takhle ošklivě by to pak nevypadalo.

126

Studium a uplatnění / Re:Jak efektivně studovat programování?

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

Ono to ošetřování chyb v GO má svoji logiku (i když, přiznávám, jako Javista jsem tomu nepřišel na chuť .

Funkce typicky vrací dvojici hodnot - výsledek a chybu (result, err). Takto jsou napsané interní funkce a většinou se tak píšou i všechny ostatní. Obojí člověk musí do nějaké proměnné přiřadit  (result, err := func() ). A když už  něco do proměnné přiřadí, musí ji v kódu použít (jinak chyba, hlídá to kompilátor). Existuje ale placeholder "_" kdy můžu explicitně říct, že chybu ignoruju (result, _  := func() ). Takto explicitně kompilátoru řeknu, že chybový výstup funkce mě nezajímá a nechci ho ošetřit vůbec. Další možnost je  chybu ošetřít v kódu v místě vzniku nebo "poslat dál" v návratovém kódu funkce. Vždyť je to v jádru podobný mechanismus jako checked exceptions v javě (akorát s primitivnější konstrukcí).

Filozofie GO je, že chyba je jedna z možností, jak volání funkce může dopadnout. Je to plnohodnotná (a očekávaná!) alternativa k tomu, že funkce vrátí výsledek. Nikoliv něco jako corner case. Něco co "SE nějak" pořeší (frameworkem atp.). Rovnocenná varianta, která si zaslouží stejnou pozornost jako to, že funkce vrátila nějaký výsledek.

Ono v GO se typicky píšou ty mikroslužby, nástroje na automatizaci, síťoví klienti... Různé chyby spojení atd. tu nejsou výjimka ale regulérní věc, která prostě nastává. (tečka.)

A teď proč jsem si jako Javista nezvykl. Samozřejmě runtime exception. Ty jsou hodně oblíbené. Ty totiž nepřikazují, že se musí chyba řešit (buď ošetřit, poslat dál nebo prostě ignorovat (sic)) v místě vzniku.Tahle vlastnost checked exceptions je pro spoustu lidí tak silné omezení že je odchytávají a obalují do runtime a "posílají dál". Na nejpoužívanějších frameworcích v javě je to vidět. Checked exceptions jsou tak nějak demodé, nechtěný člen jazyka, na který se hledá jak to obejít. 

 No jo, je to návykové. Mít možnost chybu nechat bublat stackem, "chytit" ji o mnoho kroků dál a neřešit při každém volání něčeho "co když.."

Ano, pohodlně se s tím žije. Ale někdy je těžké (narozdíl od toho explicitního ošetřování) říct, co se stane, když... třeba server, který volám neopdoví. Data nejde načíst. Vstup je špatný...  Ono "SE" to vyřeší. Někdo tu výjimku ošetří, co na tom, že klient dostane divný návratový kód (nejlépe i se stack trace , v databázi (a jiných distribuovaných úložištích) zůstane nekonzistentní binec..  I tohle jsme mockrát viděli. Takže jako všechno se to musí používat s rozmyslem. Což se často neděje a proto vzniká výše uvedené. Bohužel jazyk a konstrukce neošetřených výjimek k tomu vybízí. Nejsem žádný evangelista check exceptions nebo stylu ale GO/C, jen jsem chtěl zkusit přiblížit co je pod tím za záměr.

Ono vynucovaná "štábní kultura" v GO je něco, co hodně lidí pobuřuje/omezuje. Prosté přiřazení proměnné bez dalšího použití v kódu je chyba. Chyba kompilaci (ne varování IDE). Ano, chybový výstup funkce můžu "dát do podtžítka" (ignorovat) ale okamžitě je vidět jaké jsem prase (a kde může být zdroj chyby). Dobře, buďme objektivnější - okamžitě je vidět, kde jsem se explicitně a po zralé úvaze rozhodl, že chybu ošetřím zrovna takhle.

Ještě jedna věc k tomu, že v GO je za trest psát větší projekt. Kubernetes je top repozitář na githubu. Nejoblíbenější open source produkt a veliký projekt v GO současně (trocha bulvárního jazyka neuškodí). Kdyby to bylo za trest, asi by to nebylo tak oblíbené.

127

Software / Re:V jakém svobodném SW sázet bakalářku na ČVUT?

« kdy: 21. 10. 2020, 10:45:52 »

Nevím jestli to bude ještě relevantní protože je to už 13 let

Psal jsem diplomku v LyXu. Dost matematických vzorců, dost vnořených grafů z gnuplotu. Pamatuji si, jak v tom práce slušně odsýpala a až na závěrečnou fázi upravování layoutu (okraje, přesné umístění obrázků atd.) kdy jsem se trochu natrápil - ale vinou mé neznalosti než těch toolů, to bylo fajn.

Dílčí věci (laboratorní protokoly,...) jsem dříve psal i v OO writeru (dřív to byl snad dokonce "star office"??). Pamatuji si, že matematika se tam dala také zapisovat pomocí nějakého jazyka (který byl ale nekompatibilní s TeXem), ne jenom "naklikávat", tak to také šlo...

128

Software / Nástroj pro práci s json/yaml

« kdy: 21. 10. 2020, 09:53:20 »

Ahoj,

hledám toolu (radši offline tj. aplikaci, CLI toolu, plugin do IDE apod., protože můžou být sensitivní data), ve které bych mohl

- procházet json stromově s rozbalováním/sbalováním s tím, že sbalené nody budou nějak inteligentně vizualizované
- hledat přes json path (xpath)
- semanticky (nikoliv textově) porovnávat jsony - i.e. nejenom ignorovat odlišné formátování, whitespaces etc. ale respektovat že na pořadí atributů v mapě nesejde, při porovnávání listů mít možnost říct, že na pořadí nezáleží a dva vnořené objekty ekvivalentní když mají stejnou hodnotu "id" (a ideálně aby tohle šlo nějak nastavit) přičemž tahle komparace aby fungovala rekurzivně do dalších vnořených listů atd.

Ideálně aby to zchrouplo i yaml (což je vlastně totéž jako json. v jiné prezentac). No a ideálně aby to šlo i pod windows...

Hlavně to porovnávání mě pálí. Typicky - porovnávám 2 výstupy operace, kde atributy jsonu přijdou různě pomíchané, itemy v listu taktéž (přičemž někdy na pořadí záleží a jindy ne a child itemy se dají spárovat přes nějaký atribut).

Měli byste tip? Díky

129

Vývoj / Re:Nový projekt vs. cizí kód

« kdy: 14. 09. 2020, 16:24:28 »

Dovolte mi menší offtopic, ze zvědavosti:

Architektura stála na dvou vrstvách. JSP stránky a PL/SQL procedury v oracle databázi.

...

Databáze (PL/SQL) ... přes SOAP někam posílala data (!!) a posílala i třeba e-mailové notifikace.

V čem vidíš zrovna v tomto problém?

Za me teda:
1. (subjektivne) Nemam rad ani JSP ani PL/SQL ... nechtel bych s tim pracovat takze bych to tak ani nenavrhoval... ;-)
2. (Snad objektivne) Vendor lock-in. Business logika by mela byt implementovana v prenositelne forme jinak to prodrazi prechod na jinou DB.

Ok, asi se pouštím  na tenký led (protože jsem ovlivněný tím, že dělám "vícevrstvé" aplikace, kde business logiku mám v aplikační vrstvě a db je prostě úložiště a tím, že PL/SQL tolik neznám), ale nepřišla mi databáze zrovna na tohle ideální nástroj.

Už jen ta SOAP/HTTP komunikace byla hodně low-level, přes nějaký utility balík se ručně skládal request (hlavičky, xml skládání ze stringů atd. (xml injection? ;-))), co by asi šlo abstrahovat a zapouzdřit do nějaké šablony, ale to se nestalo a tak se boiler-plate kód táhnul těmi procedurami... možná že existují nějaké pokročilejší tooly a jde to řešit elegantně, ale nevím. Také se mi nelíbilo, z pohledu architektury, že stejná db instance, která řeší úložiště dat, řeší i složitou business logiku zahrnující cally na web servisy.. (blokující a dlouho trvající). Také ta aplikace měla problémy s performance, ale jestli to bylo zrovna kvůli tomuhle, nevím.

Takže škálování a udržovatelnost. Když otočím otázku, proč to mít v databázi?

130

Vývoj / Re:Nový projekt vs. cizí kód

« kdy: 14. 09. 2020, 14:01:32 »

Ten software "tam" uz vznikal? Nebo "tam" byl predan na udrzbu _{(a rozvoj)}?

100% to nevím - byl to starý projekt, ale z toho co jsem slyšel se domnívám, že řízení projektu a snad i nějaká analýza byly "tady" a implementace předána "tam".

131

Vývoj / Re:Nový projekt vs. cizí kód

« kdy: 14. 09. 2020, 11:06:03 »

Vrtal jsem se v kódu od jedné nejmenované konzultační společnosti (abych nezakládal hate, nebudu jmenovat firmu ani národnost, ale byla to velká firma z velké země, která je proslulá low cost vývojem). Architektura stála na dvou vrstvách. JSP stránky a PL/SQL procedury v oracle databázi.

Kde začít? .jsp byly opravdu velké. Copy-paste by šlo, ale tohle bylo rafinovanější. Tady se konzistentně uplatňovalo x krát rewrite téhož, s různými implementacemi (a chybami). V JSP se samozřejmě řešily takové ty typicky front endové věci,  například nějaké query nebo reporty nad strukturami, které se před tím celé stáhly z databáze do paměti.

Databáze (PL/SQL) zase často skládala HTML výstup (!), přes SOAP někam posílala data (!!) a posílala i třeba e-mailové notifikace. PL/SQL procedury byly také obrovské ("mít jich víc by bylo škoda, stačí nám jedna"), a v podstatě šlo o propletenec milionu IFů. Když se to člověk snažil formátovat a rozparsovat, tak zjistil, že některé podmínky si i v zájemně odporují (tj v IFu byl zanořený IF s "mrtvým kódem" se stovkami řádků, které se neprovedly,).  Někdy to bylo vidět až okatě (IF fieldX = 3 a uvnitř zanořený IF fieldX = 5).  Prostě bylo vidět, že už v základu zkoněná implementace byla mockrát dolepena quick fixy stylu ("když je na vstupu jednička, má to vrátit dvojku -- ok, přidám tam IF a jdu na další ticket").

Nejlepší na celé věci (a to podle mne hází vidle do sena i těm největším masochistům, co by se chtěli vrhnout na "ozdravování" tohoto výtvoru) bylo, že nikdo vlastně (už) nevěděl, jak to má přesně fungovat. K čemu slouží funkcionalita A, proč na výstup B mám dostat C atd, . Nevěděl to business, nevěděl to analytik. Dokumentace a business analýza měla podobnou strukturu a kvalitu jako kód. Původní implementátoři (spolu s analytiky apod.) už z firmy, co to implementovala, samo sebou odešli (protože tahle firma drží jen low cost lidi a kdo je schopnější, přesunuje se jinam, často do jiného světadílu). Pokud už někoho chytíte, bude problém se domluvit na komunikačním protokolu, protože evidentně používá jinou angličtinu, než je ta vaše.

Protože v té Bance rotují lidé v manažerských postech podobně rychle, jako low cost pracovníci v těchto consultancy companies, a celé se to řídí principem "čím víc teď ušetřím, tím víc bonusů a po mě potopa", evidentně to nemůže a nebude vypadat jinak. Může to znít jako offtopic, jen jsem chtěl říct, že jen o refaktoringu kódu (což je samo sebou v tomto případě ultra challenge) to není, jsou tam ještě daleko vyšší výzvy.

Stále chápu, že ozdravit tuhle mizérii pro někoho to může být opravdu výzva. Lidé dělají různé věci, třeba běhají ultramaratony do kopce, chodí po horkém uhlí nebo v největší zimě plavou ve Vltavě, tak co já vím...

132

Hardware / Re:Zkušenosti s notebookem UMAX

« kdy: 20. 08. 2020, 11:58:00 »

Ruzne testy v "odbornych casopisech" (vc. jednoho jehoz nakladatelstvi primo propaguje takovy levny bazmek a z textu primo sala "nadseni" redaktora ze o takovem produktu muze psat) zminuji u tech levnych umaxu prekvapive dobry displej (IPS) a hrozny zbytek. 4 GB ram je dneska nepouzitelne. emmc uloziste je dneska nepouzitelne. Rychlostne i kapacitne. Vic zalozek v browsru (nebo jedna s narocnejsi strankou) uz je problem. Jakakoliv aktualizace windows to totalne sestreli. Jediny use case ktery bych si predstavil (vzhledem k tomu displeji) je levny prehravac filmu/netflixu do postele.

133

Studium a uplatnění / Re:Jak jste přežili svůj stav vyhoření

« kdy: 20. 08. 2020, 10:23:36 »

Pohybuji se v kontextu korporátu (banka) ale tam je potřeba uplatňovat určité vzory chování. Ano, podobně jako kód má svoji Gang of Four bibli s návrhovými vzory (s poetickými českými názvy jako "Baťovy cvičky" v interpretaci od p. Pecinovského) tak i pro přežití v korporátu (aby nedocházelo k chybám) je potřeba uplatňovat návrhové vzory. Příklady:

1) Štít (aka "plechování p*dele). Nejdůležitější a nejvíc podceňovaný pattern. Use case: obrana před "who to blame" attack, až dojde k problému (pozor, nikoliv abychom se vyhli problému, to je špatné pochopení kontextu). Příklad reálné implementace:  "Pošli jim e-mailem, že jsme to implementovali přesně podle nich a nejde jim to, dej mě na cc, schovám si to. Až budou říkat že..."

2) Fan out messaging (aneb "do kopie všechny"). Synonymum: brute force. Use case: zainteresováním co nejvíce osob se zvyšuje síla útoku a rozprostírá responsibilita. Příklad reálné implementace: "Dej do kopie tyhle 2 manažery a víš co, rovnou i VP. Nezapomeň napsat, že za nás to funguje."

3) Proxy (aneb "kecálista"). Use case: abych vypadal že generuji výstup, ale stálo mě to minimum prostředků. Příklad reálné implementace: "Přijímám práci, přeposílám na ostatní (bez přidané hodnoty), slíznu úspěch, průs*r je těch ostatních."

4) Dekorátor. Univerzálně aplikovatelné. Příklady implementací "e-mail s vykřičníkem", "ASAP obálka".

Nedodržováním vzorů vzniká něco označované jako "špagetové chování". Udržitelnost je špatná. Čitelnost pro korporate uživatele, kteří aplikují patterny je špatná, takže dochází ke konfliktům a chybám.

Berte toto trochu jako nadsázku ;-)

134

Studium a uplatnění / Re:Přechod na IČO

« kdy: 04. 08. 2020, 15:37:56 »

Ahoj

soukromé zkušenosti, OSVČ od 2012.

ad 1) agentury - velká agentura je (dle mého názoru) větší jistota stabilních plateb a vytíženosti

ad 2) ad ručení majetkem - toho se nebojím (měl bych?). Nejsem právník, ale..V softwaru jsou chyby (to je axiom).  Kód viděli (nebo měli možnost) vidět i jiní lidé (review a tak). Kdyby býval závisející modul nevrátil tenhle neočekávaný (chybný, mimo specifikaci?) výsledek, nebyl by býval na té mojí řádce spadnul null pointer, kvůli kterému zákazník přišel o milion. Vůbec je specifikace úplná, je správná? Produkt prošel testováním  Prošel user acceptance. Na předávacím protokolu zákazník stvrzuje OK. Podle smlouvy o dílo tedy případné nalezené chyby musím do měsíce opravit (do měsíce od předání). Pak už teoreticky ne Možná to zlehčuju, říkám, nejsem právník, dost by mě to samotného zajímalo.. Samozřejmě se chybám snažíme vyvarovat (a jsou na to nějaké politiky, mechanismy..) ale prostě stejně jsou tam.

ad 3) vykazování práce - fakturuju MD. Práce za mnou samozřejmě musí být vidět.
ad 3,5) rozklad práce - vzhledem k povaze projektu, k tomu, že jsme malý tým a děláme velký objem práce -- představa o nižším pohodovějším úvazku je dost růžová, ale nereálná

ad 4) velká agentura - nikdy problém. Malá firma - osobní zkušenost: s.r.o. skončilo. Já naštěstí peníze dostal, kamarádovi dluží 80 000 a už je zřejmě obrečel. Jako plátce DPH navíc z neproplacené faktury zplatíš státu DPH Jiná zkušenost - kolegové dělali přes divnou agenturu (tzv "one man show" firma). Faktury se zpožďovaly, jednu nedostali vůbec. Co byl tvrdý oříšek bylo vyvázat se z "pasáka", který svým ovečkám ani neplatí (jenom slibuje). Nakonec se jim povedlo utéct (a zůstat i u stejného zákazníka).Jestli jim zůstal týpek něco dlužen to nevím. Teď dělám pro subdodavatele svého zákazníka (na smlouvu o dílo). Kdyby nezaplatili, smlouva se ruší a odcházím (o peníze se pak budu hádat). Zatím platí

ad 5) MD je malý Zkušenost z jednoho korporátu/banky. Firma fakturovala fixní člověkučástku (řekněme, tehdy,  12 000 / MD).  Rozdělení junior/senior netrápilo zákazníka, ten platil stejně. Junior znamenal, že firmě zůstalo víc peněz na provizi. Nestyděl bych si říct víc. Jako chápu, že chceš dělat "na pohodu" s menší pracovní dobou. To nevím, já (z jistých hledisek i bohužel) co jsem přešel na OSVČ tak dělám mnohem víc.

ad 6) kamarád z Teplic ca před 2 lety sháněl práci, do které by nemusel dojíždět (max tak 1x týdně když bude potřeba). Nabídky se redukovaly tak
na desetinu, ale vybral si... U mě aktuálně homeoffice dle potřeby, i 9 dnů z 10 prac. dnů v jednom "sprintu".