Příspěvky

421

Vývoj / Re:Jaké používáte git workflow a proč?

« kdy: 02. 03. 2019, 15:55:39 »

@prihlaseny_uzivatel: pokud mas podporovat i stary verze, tak ten tvuj model proste pouzit z principu nejde a musi se mergovat, ten tvuj postup funguje jenom na ten tvuj specifickej release model

Ano, to nefunguje. Ale neni to b zadnem pripade specificky release model, je to asi snad ten nejpouzivanejsi model na backendu pri continuous integration.

422

Nabízím zakázku / Re: Nabízím zajímavý projekt

« kdy: 02. 03. 2019, 13:19:05 »

To je uplne neodolatelna nabidka na... na co vlastne? Ale psat ti nebudu, urcite uz ti napsalo minimalne 100 expertu.

423

/dev/null / Re:Sestupná kvalita lidí v IT

« kdy: 02. 03. 2019, 01:05:20 »

No, vseobecne ja vim, jak je muj obor SW Inzenyrstvi tezky, v podstate to prekracuje schopnosti a znalosti kohokoliv, kazdy, i ti nejlepsi, to jsou schopni pojmout jen do urcite miry. Zameruju se na slozite backend systemy, tam se technicke schopnosti, znalosti a osobnostni schopnosti kazdeho vyvojare projevi. Je to bezbreha studnice, kde nikdy nic nebude udelane na 100%, to nikdo nezvladne.

A proc to rikam. Nemam obavy z toho, ze chodi do IT lidi, kteri na to nemaji, a ze je firmy berou. Do te doby, do ktere ja za svou praci dostane poradne penize, tak je mi to sumak. A pokud firma bere kazdeho neznalce a me povazuje jen za jednoho ze 100, a to vc. mzdy, tak proste jdu jinam, za lepsim financnim ohodnocenim, a v te firme at si klidne shnijou. To je trh, silnejsi a schopnejsi firma porazi ty slabsi. A ja vim moc dobre, jak dopadne, kdyz se na projekt daji neschopni lidi. To proste nikdo nemuze osulit, dat na SW vyvoj neprogramatory s vidinou usetrenych penez, promeni se to v zumpu, ktera nakonec myslim si stoji hromadu penez a vystup je hrozny. Proste jako Indie.

Mam dojem, ze nejlevneji vychazi senior sw inzenyr. Zaplatis mu 90k a vyda jednoznacne za vic, nez 2 manualni testeri, kteri budou nekde v Praze stat minimalne 40k kazdy. A kdyz jsou to senior testeri, tak 60k. Takze do te doby do kdy si to firma uvedomuje, tak at mi nasazi do tymu koho chce. Ja jim budu otevrene reportovat, jak to je, a na svoji hlavu nic spadnout nenecham. A do doby, do kdy se ke me budou chovat slusne a s respektem, tak udelam, co dokazu.

To se mi prave libi na tech slozitych backendech, ze jak kvalitni lidi na to firma hodi, tak kvalitni a levny vysledek z toho ziska. Rekneme, ze nejake neprogramator co sel do it kvuli penezum je schopny komponentu udelat dobre na 75% a ja na 90%. Rekneme, ze ja jsem 2x drazsi nez on. Vypada to, ze se nevyplatim. Jenze kdyz das dohromady komponenty 4, tak:

0.75^4 = 0.32
0.90^4 = 0.66

A to je presne ono. Kazde procento navic ve vypilovanych schopnostech ti da u vetsiho celku mnohem lepsi vysledek. U nejake male kraviny typu webovky kde se to nejak musi slepit dohromady a je jedno jestli to je na prase nebo to je poradne, na tom asi nesejde. ale na poradnych velkych vecech uz na tom setsakramentsky sejde.

Barak si taky postavi ledaskdo, na to nemusis mit VS. Ale most pres reku pro nakladni automobily uz tak jentak nekdo nepostavi. A na to jsem tu ja, SW inzenyr, abych takove slozite veci delal, a tak je delam.

Nebo jeste lepsi priklad je Indicke auto. Tam bude kazda jeho cast udelana z 90% tak dobre, jako v nasi Evropske tovarne, a stat bude jen 1/3 penez. Jenze, HAHA, kdyz das tech casti dohromady 100 aby se spojily v celek, tak dostanes Indicky, ustavicne se kazici techniku. A to je ten duvod, proc jsem z prilivu teto netechnicke konkurence vcelku klidny

424

Vývoj / Re:Jaké používáte git workflow a proč?

« kdy: 01. 03. 2019, 23:50:52 »

Dekuju za prispevek.

Většinou se provádí commit rovnou do master branche a dělá se review až tam, aby bylo vše integrované co nejdříve, ale občas děláme review před merge do master branche. Kromě UpSource pužíváme ještě OpenGrok.

Takze kazdy v tymu dela push do origin/master? A v origin nejsou feature branches?

Merge vs rebase. Ja osobne se snazim co nejvice pouzivat rebase, commity dělám docela často, zpravidla pokud jsem schopny tu změnu, co jsem udělal pojmenovat, ale nemáme to nijak omezené. Někdo používá merge, ale pak není vidět jednotlivé commit message.

Tomu nerozumim. Pri merge nejsou videt jednotlive commit messages? A pri rebase jo?

Ne nepouzivame feature branches. Teda neni to pro kazdou ficuru, sem tam se rozhodneme, ze neco zustane nejaky cas bokem, ale to je vyjimecne.

Pri merge musite udelat squash vsech lokalnich commitu do jednoho, pokud chcete mit aspon trochu "linearni" historii. Merge jako takovy jsem nedelal uz hodne dlouho. Pouze kdyz delame release a delame merge do production branch.

Rebase nejdrive odstrani vsechny lokalni commit zaznamy a prida nove commit zaznamy z origin a pak znova "prehraje" moje lokalni commit zaznamy. Toto nejde pouzit, kdyz na jedne branch pracuje vice lidi.

Mame vlastne jen jednu feature branch a to je master. Do ni vsichni integruji zmeny co nejdrive.

Proste nejak zacnete. Bude to bolet obzvlast, pokud prechazite z CVS, ale stoji to za to.

No my ted pouzivame squash and rebase...
Kazda story = jeden squashed commit
rebase na origin/master a push

A pred par lety jsme pouzivaly takove to atlassian workflow jak popsal prihlaseny_uzivatel.

A jeste drive jsme pouzivali v bit bucketu forky a kazdy si vyvijel co chtel a jeden vyvoleny spravoval repo ze ktereho se buildovalo a mergoval pull requesty kdyz se mu chtelo...

Kazde melo svoje pro a proti...

forky => snadna sprava vice release branches/ hrozny opruz s merge konflikty protoze vyvoleny napred zamergoval neco jinyho a musel se upravovat PR
atlassian => Snadny nastaveni CI - na kazdy PR probehly integracni testy a pritom se to nemuselo nastavovat kazdymu vyvojari na jeho repository
squash and rebase => Nevim presne proc, ale zda se mi, ze mnozstvi merge konfliktu se blizi nule (mozna za to nemuze git workflow, ale architektura projektu + male stories)/ kdyz chci proste nasypat lokalni zmeny na remote, aby se neztratily protoze mi vybouchne disk nestaci proste commit a push, ale musim commit - squash - rebase - push

No a me nejvic zajimaji ty merge konflikty...
Je mozny, ze proste to workflow vede k mensimu mnozstvi konfliktu? Pozorujete to taky?

Co se tyce historie tak je mi celkem jedno jestli vypada jako nadrazi nebo ne. Zas tak casto se do ni nedivam a kdyz jo tak nezacinam od grafu, ale spis od konkretniho commitu. Najdu posledni zmenu radku ktery me zajima a divam se na ostatni soubory ve stejnem commitu a jdu od nich do budoucnosti celkem linearne.

To co popisujes delame na projektu prave ted:

1. Mame jen Master branch
2. Kazdy commit predstavuje malou zpetne kompatibilni inkrementalni zmenu
3. Kazda commit ma svou Jiru a jmenuje se presne podle ni.
4. Nedelaji se Merge, ale Rebase.
5. Kazdy commit je releasovatelny.

Vyhoda je, ze:

1. Historie je mene ukecana.
2. Je to velice pohodlna a systematicka metodika nejen pro Git, ale i pro cely proces vyvoje.
3. Celkove mi to prijde cistsi nez metodika Margu v Attlasianu.

Zezcatku jsem lamentoval, ze se tim pro me jako pro vyvojare ztrati developerska historie, takove ty male dilci commity v branchi ktere vysvetluji zmeny, ktere jsem udelal. Ale fakt je ten, ze to nevadi, protoze to motivuje k tomu, aby Jiry byly male a implementace celeho Supertasku byla dobre dekomponovane na casti.

Ale nedelam s tim jeste dost dlouho, abych posoudil nevyhody. Kazdopadne je to velice dobra metodologie a jestli nekdy narazim zase za Mergovani, tak si budu tezko zvykat.

425

Vývoj / Re:Jaké používáte git workflow a proč?

« kdy: 01. 03. 2019, 19:19:53 »

Delali jsme v podstate standard flow ktere vznikne, kdyz od Atllasianu zintegrujes Jiru a Bitbucket:

1. Kazda nova branch nese nazev konkretniho Jira tiketu (hodi se tam automaticky)
2. Po Review se zasadne delal Merge a to do Development branche. Nebylo to vubec zalozene na Rebase.
3. Meli jsme vzdycky 2 Development branche, pro 2 releasy. Nejake zmeny sly totiz do drivejsiho releasu a nejaka az do toho dalsiho.
4. V Master branchi jsme meli Release.
5. Kazdy merge do Development branche musi byt kompletni a plne funkcni zmena.

Zadna veda. Podle me neni uplne dulezite samotne flow, je dulezite to, aby v tom nebyl mrdnik - musi byt jasne dana pravidla a ty kazdy vyvojar dodrzuje.

426

/dev/null / Re:Sestupná kvalita lidí v IT

« kdy: 01. 03. 2019, 13:03:42 »

Ja kdyz byl v jednom korporatu, tak jsem mel kolem sebe samy des a bes, k zakaznikovi nabirali vsechno co melo ruce a nohy. A i seniori nestali za moc.

Pak jsem navstivil jiny korporat a jineho zakaznika, a razem se muj dojem celkove obratil, lidi si vybiraji poctive, neberou uplne kazdeho. To co si dovolil k zakaznikovi predesly korporat tak to si tento nedovolil, aby bodyshopovali ledaskoho.

Takze zalezi na zakaznikovi, koho kupuje a jak se k tomu stavi. Korporat je jen dodavatel.

427

Hardware / Re:Konzoli nebo počítač na hry?

« kdy: 25. 02. 2019, 17:47:10 »

No a kdyz hrajes treba Battlefield pro konzoli jako multiplayer, tak protihraci maji vylucne taky jen konzole nebo hrajes i proti PC hracum kteri maji mys a klevesnici?

428

Hardware / Konzoli nebo počítač na hry?

« kdy: 25. 02. 2019, 16:50:26 »

Hraju hry jako je League of Legends, WoT, Battlefield 4, Dota, a vždycky multiplayer. Nikdy jsem neměl konzoli, ale na tyto hry si myslím, že je potřeba mít myš.

Ideálně bych chtěl konzoli, protože je to skladné a je to jen pro tento hrací purpose, dá se říct že je to i levné, navíc si na tom zahrajou i 2 lidi naráz, což se může hodit. Jenže kvůli té myší si nejsem jistý, jestli je to na Multiplayer dobrý nápad.

Kdyby mi ale vyšlo, že potřebuju PC abych si zahrál, tak bych rovněž nechtěl mít doma velkou krabici ověnčenou kabely. Raději bych něco mobilního. Ale notebook už je mimo můj rozpočet, je to moc drahé a na hry stejně moc kompromisní.

Jak na to?

429

Distribuce / Re:Najspolahlivejsi a najmenej zabugovany ubuntu desktop?

« kdy: 23. 02. 2019, 19:31:16 »

Nejmene zabugovany Ubuntu desktop pocitam ze bude Debian Stable. Nenech se zviklat, ze se muzes prepnout do Testing a nic se nestane, protoze jinak mas zpatky svuj stary zabugovany Ubuntu desktop

430

Hardware / Re:Spotreba energie notebook

« kdy: 23. 02. 2019, 09:59:46 »

Jinak trochu jina odpoved na tvou otazku. At uz s Linuxem, nebo s Widlema, odpoved je, ze ti ten PC kram zere moc A JESTE navic tomu musis venovat pozornost nejakymi hloupymi opatrenimi.

Na Macbook ti vsehno zere znacne min a jeste nemusis a ani nemas jak tomu nejak venovat pozornost.

431

Hardware / Re:Spotreba energie notebook

« kdy: 23. 02. 2019, 09:57:18 »

Ahoj, zajímal. Můj 40W, pěkně rozpálený zdroj, ten jsem položil na keramickou desku. Jinak si pořiď watmetr do zásuvky, nestojí svět. Potom změříš celkovou spotřebu celé sestavy - zdroj má také něaké ztráty.

Zmeris prd, budes akorat merit jakym vykonem se ti nabiji baterka.

432

Hardware / Re:Spotreba energie notebook

« kdy: 23. 02. 2019, 09:48:18 »

Thinkpad x520, Windows 7, nic spustene, display na minimum, vsechny wireles veci vypnute - 7W.

433

Vývoj / Re:Deadlock v databázi, který vznikl na úrovni requestu v komponentě

« kdy: 22. 02. 2019, 17:24:01 »

Jasne, ono ten deadlock jde vlastne snadno vyresit na urovni frameworku, ze pokud DB vratila nejaky deadlock error, tak se muze znova automaticky zopakovat request. Jenze co treba Spring Framework, automaticky pochybuju ze to dela.

434

Vývoj / Deadlock v databázi, který vznikl na úrovni requestu v komponentě

« kdy: 22. 02. 2019, 08:16:29 »

Kdyz budu mit komponentu se svou vlastni databazi, a databazi budu mit nastavenou v rezimu SERIALIZABLE, tak se muze stat, ze 2 Requesty se na urovni databaze navzajem zablokuji. Databaze sice umi detekovat deadlock 2 transakci a dokaze na jedne z nich udelat Rollback, nicmene co se nasledne stane s tim Requestem - to jako 1 z nich bude vzdycky neuspesny, ja obdrzim bug, a budu muset tento deadlock case to case "agilne" zafixovat?

A mimochodem, neznamena vlastne moznost takoveho deadlocku vlastne to, ze mam spatne strukturovana data a logiku manipulace s nimi a ze bych praveze mel izolaci SERIALIZABLE pouzit, protoze me bude na toto deadlocky upozornovat?

435

Vývoj / Re:Viděli už jste někde distribuované transakce?

« kdy: 21. 02. 2019, 07:49:22 »

S implementaci je docela problem, je to docela pomale, ale casto je te konzistence proste potreba.

Me prijde ze te konzistence je potreba snad vzdy u nejakeho korporatniho backendu. To ze se na to kasle a misto toho se povola armada opravaru dat v databazi je vec druha. Ja jsem takovy projekt jednou mel. Ustavicne pokazena data v DB, spolu se srasenym kodem to bylo naprosto otresne, objevovaly se chyby, kde nikdo nevedel co je pricin,a jestli je to bug v kodu, nebo je to zpusobeno nedokonalym "db machine" strojem. Ustavicne se vyrabely skripty na opravu dat v DB.

To je proste jako hodinky a vsechno do sebe musi zapadat.

Proto me fascinuje, ze se nekoupi poradny HW pro DB a nedelaji se distribuovane transakce, aby byly databazova schemata konzistentni nejen sama, ale i navzajem vuci sobe.