Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - L..

Stran: 1 ... 8 9 [10] 11 12 ... 15
136
Vývoj / Re:Jak posunout vývojáře k CI/CD
« kdy: 27. 01. 2021, 20:22:36 »
Už to tu párkrát v různých obměnách zaznělo, ale klidně to zopakuji: Podstatný je business důvod, proč by k té změně mělo dojít. Například:

- Zavedením CI/CD se zkrátí doba vývoje o 20% a čas potřebný na deploy o 80%
- Nebudou se stávat situace, kdy někdo vymaže kód aby následně zjistil, že ho vlastně potřeboval a musí ho složitě lovit po zálohách nebo psát znovu.
- Nebudou se stávat situace, kdy člověk, co dělal projekt onemocní a nikdo to po něm nemůže převzít, protože rozumně aktuální verze zdrojáků je jen na jeho počítači.
- Nebudou se stávat situace, kdy nasazení projektu trvá tři dny, protože u programátora to funguje, ale na serveru ne.

A tak podobně.

Naopak důvody "prostě se to tak dělá" nebo "chci si hrát s CI/CD" nejsou pro business relevantní. Pokud si to budeš dělat sám ve volném čase, tak asi cajk, ale investovat do toho prostředky dalších lidí bez přínosu pro firmu je bláhový požadavek.

Pokud pro to business důvody jsou, tak je vysvětlit managementu, pak nadřízenému těch vývojářů, sestavit s ním plán zavedení a vysvětlovat programátorům. Pro mě jako pro programátora je verzování přínos i když dělám sólo, právě kvůli snadnému chození tam / zpět, vidím, do kterých souborů jsem aktuálně sahal atp. Ale pokud ti lidé nemají s VCS zkušenosti, tak tyhle výhody nevidí, to je jasné, musí se jim vysvětlit.


137
Software / Re:Sdílený adresář
« kdy: 21. 01. 2021, 19:28:08 »
A co tam udělat nějaký malý partition s FAT32?  :D ;D

138
Vývoj / Re:Přihlašování pomocí URL
« kdy: 21. 01. 2021, 08:21:35 »
A není řešení použít tam nějakého externího poskytovatele identity? MojeID / Google / Facebook / ...?

Já před lety řešil podobný problém. Psal jsem systém, kde si uživatel vybírá fotografie z focení k následné úpravě. A chtěl jsem obdobný scénář: Uživateli prostě jen pošlu odkaz, kde fotky vybírat, uživatelé si jej mohou přeposílat a přitom vím, kdo vybírá - jestli fotku hodnotil člověk, co na ní je, nebo někdo jiný ze skupiny. Na druhou stranu nechci, aby se bylo možné dostat se na jiné album (uhodnout jeho adresu).

Důležitým požadavkem byla minimální složitost, jak pro uživatele (nepotřebuje se registrovat), tak pro mne (žádné ruční přidělování práv, kdo může co vidět, prostě pošlu odkaz a je to).

Navrhl jsem to následovně:

- Album má jako identifikátor 32-znakový náhodný řetězec, který je v URL. Stejně tak fotky mají svoje náhodná id. Tedy dají se posílat odkazy na album, fotku, ale musím to id znát (dostat), není reálné ho uhodnout.

- Identifikace je pomocí identity z Facebooku. Poprvé musí uživatel potvrdit předání informací, při dalších návštěvách tam jde hned.

- Pro uživatele mám vytvořený lokálně záznam, kde jsou jeho data nacachována, abych mohl ukazovat ostatním uživatelům, kdo jak hodnotil.

- Mohu nastavit uživateli příznak, že může do administrace - tak z něho udělám administrátora (jsem zatím jediný, takže jsem to nastavoval prostě v SQL).

Za těch pár let s tím mám dobré zkušenosti. FB má skoro každý (jen v jednom případě dotyčný FB neměl) a když by to byl problém, mohl bych jednoduše přidat dalšího providera. Pro mě i pro uživatele je používání velmi jednoduché. Není to úplně super bezpečné, protože věřím externí autoritě, ale pro daný účel stačí.

139
Vývoj / Re:Mají smysl daily standupy?
« kdy: 06. 01. 2021, 19:47:31 »
Ale odpověděl bratře. Tony Stark, těší mě. Snad ti je to dost světoborný na to, abys teď začal reagovat k tématu.

Takže fiktivní charakter. Jo, to sedí ;D

140
Vývoj / Re:Mají smysl daily standupy?
« kdy: 06. 01. 2021, 07:09:07 »
Lidi, co dělají neorganizovaně na něčem, co není ve sprintu, jsou peklo ... člověk pak něco releasuje a nestačí se divit, co tam nějaký hyperaktivní trouba zas naprgal ...

Nejlepší jsou kutilové, co "nad rámec" sprintu zrefaktorujou půlku projektu, a člověk pak žasne, proč se v testech chovají věci, na které nikdo neměl sahat, najednou úplně jinak.

A jak mu to prošlo přes code review?

141
Odkladiště / Re:Reklamace chybné transakce v PayPal
« kdy: 30. 12. 2020, 08:35:19 »
Já teda žiju ve světě, kde je tohle default, nemusí se pro to dělat žádné speciální extra podpora...

Ano, matematici zkoumají i různé bizardní světy, ale nevím v tom, že by v takovém někdo žil :) Celou věc diktuje logika. Viz dále.

Pokud je problém s použitou technologií...


On je problém nejen s použitou technologií. Ale hlavně s logikou. Viz dále.

Obecně je podle mne zrovna u IB řešení vícenásobného přístupu poměrně snadné, ...

Ani smykem. Respektive, udělat to tak, aby to "nějak" spatlaně fungovalo opravdu jednoduché je. Ale v bankovnictví je třeba preciznosti a jasnosti. A udělat to pořádně je obtížné až nemožné. Viz dále.

Pokud je problém jenom v tom, že server drží stav klientského GUI, je zbytečné bránit uživateli používat dvě různé session – z pohledu serveru by to byly dvě různé instance s odlišným stavem (pokud by stav byl skutečně svázán se session a ne přímo s uživatelským účtem).

To typický naivní, začátečnická představa. A fatálně chybná. Začnu nejprve "klasickým" případem, kdy přistupujete v jedné session. Trik je v tom, uvědomit si, že tady není jeden stav, ale dva(*) stavy. Jeden stav databáze serveru a druhý stav UI (= to co má uživatel zobrazeno, v případě webu HTML elementy). Tyto stavy je třeba synchronizovat a je to práce UI aplikace - když pošle mutaci na backend, musí si zajistit občerstvení stavu tak, aby její stav reflektoval změny na serveru.

V případě, kdy pracujete ve dvou session paralelně, tak nastává problém. V session 1 něco změním, ale aplikace v session 2 to neví, tedy neaktualizuje svůj stav ze serveru a stavy se rozejdou. Do určité míry by to šlo řešit nějakým systémem push aktualizací, třeba GraphQL na tohle má subscriptions, nicméně to není automatické, je potřeba ty závislosti naprogramovat a tak se to používá spíš jen ve specializovaných případech. Pak se dá používat nějaký polling, ale ten zase bere prostředky navíc a stejně není stoprocentní, když uživatel "stihne kliknout" než se data zaktualizují.

Tedy v okamžiku, kdy se rozjedou stavy na klientovi a na serveru, máme problém. Někdo tu zmiňoval nákupní košík, ukáži to tedy na něm. Mějme košík, kde mám u položky akce "odstranit kus", "přidat kus", "nastavit počet kusů" a "odstranit položku". Dále je možno zaplatit.

Vezměme si teď následující scénáře:

A) Uživatel má v košíku 5ks, v jedné session položku odstraní, ve druhé klikne na "přidat kus". Tady je několik možností, kde každá dává smysl:

1) vyhodit chybu, že položka už neexistuje (detekce neplatné operace)
2) přidat položku a mít tam jeden kus (operaci definujeme jako "přidej 1 ks tohoto výrobku do košíku ať se děje co se děje")
3) přidat položku a mít tam celkem 6 kusů (podle toho, co uživatel viděl, než klikl)

Problém je v tom, že každý uživatel bude mít jiný, silný, názor na to, která cesta je správná a když se bude aplikace chovat jinak, bude nadávat. Úplně klasický případ tu předvedl Jenda:

(OMG! si v Tescu otevřete do tabů 10 výrobků a seznamů, že si je prohlídnete a naházíte do košíku, a ono si to obsah košíku navzájem přepíše!)

Třeba zmiňované Tesco se chová podle logiky v bodě 3 (košík viděl uživatel prázdný a přidal jednu položku => má tam tu jednu položku).  Nicméně Jenda by chtěl, aby se to chovalo podle logiky v bodě 2. Jenže to by pak zase jiný uživatel přišel s tím, jak to, že se mu v košíku objevují položky, které tam neviděl... Žádné řešení není správné.

S ostatními operacemi budou vznikat další kolize, ale ty vám nechám k analýze za domácí úkol :) Proberu ještě jednu věc související s placením:

B) Řekněme, že mám možnost placení uloženou kartou. Tedy uživatel dojde na stránku shrnutí objednávky, potvrdí ji a ta se zaplatí. Ale co když mezi zobrazením stránky a jejím odkliknutím přidá do košíku ještě další položku? Pak odklikne nějakou objednávku (a cenu) a zaplatí jinou! A tady už jde do tuhého, tady jde o peníze, takže uživatelé si na vás hezky smlsnou. (Podobná věc se stala právě zakladateli tohoto vlákna - potvrdil něco jiného, než co měl na obrazovce.)

Tenhle případ by se samozřejmě dal řešit - například tak, že při odkliknutí potvrzení pošle klient na server i objednávku
a pokud nesouhlasí s tam uloženým stavem, vyhodí se chyba, kterou klient nějak ošetří, například aktualizuje stav a napíše informaci, že se změnil a je třeba potvrdit znovu. A pak tedy ještě musí řešit, že třeba uživatel něco odebral, tím se dostal pod minimum zvoleného druhu dopravy a je třeba zvolit nový druh dopravy, tedy jít ve flow o stránku / dvě zpět - samé složitosti.
 
Už je to hrozné dlouhé, takže abych to shrnul: Je možné udělat aplikace, které umožňují paralelní práci, aby "nějak" fungovaly. Pokud se v nich převážně čte a na konzistenci obsahu až tak nezáleží, tak to docela funguje bez většího množství práce (třeba zrovna Root). Jenže pak jsou aplikace, kde narážíte na docela nepříjemné problémy, které musíte ošetřovat. Jen se podívejte, na co jsme narazili u pitomého nákupního košíku.

Pokud to chcete ošetřit pořádně, tak musíte:

1) Identifikovat jednotlivé scénáře (Kolik jste jich identifikovali jen u toho jednoduchého košíku? A jste si jistí, že jste identifikovali opravdu všechny? Můžete to nějak verifikovat?)
2) Definovat, jak se mají řešit (ale vždycky bude někdo nadávat, že to máte blbě)
3) Naprogramovat
4) Otestovat
5) V nových verzích aplikace myslet, jestli tím nemůžete způsobit nějakou další kolizi, ošetřovat je plus na tu kopu už existujících scénářů dělat regresní testy

Tedy u složitější aplikace pěkná kopa práce navíc, často pro podporu minoritních use-cases a uživatelé vám budou stejně nadávat. Proto složitější aplikace jako třeba IB práci ve víc paralelních session typicky nepodporují.

*) Kdybych měl být precizní, tak těch kopií stavů je ještě víc, v různých cache, frontend mívá svůj uložený datový model, který pak reflektuje v UI, ale synchronizace těchto stavů problém není, ty základní a z našeho pohledu zásadní jsou dva.

142
Odkladiště / Re:Reklamace chybné transakce v PayPal
« kdy: 28. 12. 2020, 22:11:16 »
Nepredpokladam ze to udelali takto umyslne (aka featura), spis to nemaj vychytany nebo je to technologicke omezeni frameworku (a s tim jako integratori nic nenadelaj).

S tímhle máte AFAIK pravdu. Pokud vím, má Fio web ve Wicketu. Ten si drží stránku v paměti serveru a když přijde AJAXový calback pro komponentu, tak na ní zavolá příslušný callback. Aby se nestalo, že komponenta už tam není / je v jiném stavu, tak pracuje s verzemi stránky, takže volání obsahuje i informaci, pro jakou verzi je určeno.

Problém s tím je, že server si musí držet ty verze zpětně a to žere hodně paměti, takže na zatíženějších serverech se to omezuje a pak je právě problém, když by vám přišel callback pro verzi, kterou už v paměti nemáte. Například když si otevřete stránku v jiném okně, něco na ní děláte a pak se vrátíte do původního s o dost starší verzí stránky. Proto se tomu v takovýchto setupech zamezuje a to je technologický důvod, proč to Fio neumí. Nicméně i kdyby to technologie uměla, tak to není moc žádoucí (viz dále).

Ale on tam zadny evidentni stav neni (...)

Ale je. Že vy byste zrovna dělal něco, co by bylo OK je hezké, ale těžko to obecně zaručit.

... musim to delat po jednom - opakovat+k podepsani, opakovat+k podepsani...

Poznámka mimo k workflow: AFAIK Fio umožňuje transakci vytvořit a podepsat později. Tedy si je můžete vytvořit a podepsat později v dalším kole.

Vážně? Jaký problém by to mohlo způsobit?

Že na něco kliknete a dostanete divnou interní chybu (protože se to ověřuje na serveru, jak správně píšete), protože je to v divném stavu, už neexistuje atp. Ono by se to dalo ošetřit, aby se to chovalo nějak rozumně, ale bylo by dost pracné vychytat (a vůbec identifikovat!) všechny scénáře. Práce ve víc oknech je sice občas užitečná, ale náklady jsou velké, takže se to nevyplatí podporovat a než to mít blbě, tak je lepší to odstřihnout.

Stejného stavu můžete dosáhnout třeba tím, že budete mít otevřené okno v prohlížeči a mezi tím uděláte změnu z jiného prohlížeče nebo z internetového bankovnictví.

Pokud se přihlásím z jiného prohlížeče, původní session se odloguje (může odlogovat), v tom problém není. Asi jste chtěl napsat "mobilního bankovnictví" - to je teoreticky možné, ale ne až tak pravděpodobné.

143
Odkladiště / Re:Reklamace chybné transakce v PayPal
« kdy: 28. 12. 2020, 20:46:26 »
Podobny problem ale je treba i u banky - tusim FIO rovnou zahlasi vadu a odhlasi vas - protoze nesedi sekvencni poradi cookies verzi.

To není bug, ale feature. Pokud byste pracoval na stejném účtu ve dvou oknech paralelně, tak budete klikat do stavu, který už není platný a to může způsobit různé podivuhodné věci (které třeba nechcete). A co se týče peněz, tak "better safe than sorry".

144
Odkladiště / Re:Advent of Code 2020
« kdy: 28. 12. 2020, 20:43:24 »
Já to píšu v Typescriptu, taky super, i když na takhle malých úlohách se jeho přednosti moc neprojeví. Akorát od 19. prosince nemám čas, tak mě zatím posledních sedm dní chybí. Byly tam ke konci ještě nějaké špeky?

145
Studium a uplatnění / Re:Jak děláte (Java) pohovory?
« kdy: 22. 12. 2020, 17:55:53 »
Pokud ve volnem case ABSOLUTNE nekoduje (...), dela to jako praci.
Pokud o volnem case testuje knihovny, dela benchmarky databazi, uci se dalsi jazyk a ja nevim co (...) pak je u takoveho cloveka potencial jako blazen.

Možná krátkodobě. Dlouhodobě takový člověk vyhoří / odvaří se zdravotně. Mě třeba programování baví, ale mimo práci programuji jen výjimečně, protože prostě osm hodin pětkrát týdně mi stačí a potřebuju dělat zase něco (typově) jiného.

Pokud jde o samotný test u pohovoru, tam jsou různé přístupy. Někdo zadává větší úkol, který uchazeč vypracovává na svém počítači. Tím se dá poznat hodně, nicméně musíte být dost atraktivní zaměstnavatel, aby vám uchazeč byl ochotný věnovat třeba 1 MD.

Pak jsou různé služby, kde můžete uchazeči dát test a on programuje sám v prohlížeči v jazyku dle výběru. To se dá stihnout třeba za dvě hodiny a dá se tím rozumně prověřit algoritmizace.

Zažil jsem úkol třeba na hodinu "na papír", to mi přišlo dost naprd.

My jsme na pohovorech praktikovali "párové programování" na papír / do texťáku / do online editoru. To mi přišlo z hlediska pohovorujícího jako dobré, protože jsem měl k dispozici nejen výsledek, ale také reakce a postup toho člověka a bylo ho tak možné odhadnout poměrně rychle a přesně. Z hlediska kandidáta je samozřejmě "papírové programování" trochu nepohodlné a museli jsme jasně vysvětlovat, že nám nejde o detaily syntaxe, ale o postup. Plus spousta lidí měla problém s tím, že nemohla programovat "Google => Stack Overflow => Copy => Paste" :-D


146
Odkladiště / Re:Advent of Code 2020
« kdy: 13. 12. 2020, 22:58:23 »
A vida :) S pojmem "modulární aritmetika" jsem zatím nikdy nepřišel do styku, takže jsem netušil, co googlit, respektive jsem se k ničemu rozumnému nedogooglil. No, nakonec jsem to zvládl i tak :)

147
Odkladiště / Re:Advent of Code 2020
« kdy: 13. 12. 2020, 15:13:25 »
Tak dneska je druhá část úkolu dost drsná. Zatím ji zvládla méně než polovina účastníků, i mě zabrala dost přemýšlení.

Není náročná ani tak programátorsky, jako matematicky. Nedá se řešit jen hrubou silou, ale podle mě čistě analytické řešení taky neexistuje (?), takže je potřeba to vhodně nakombinovat.

148
Odkladiště / Re:Advent of Code 2020
« kdy: 12. 12. 2020, 17:04:58 »
koukám že u desátýho dne celkem dost lidí vodpadlo hele :o :o

Protože to byl první den, kdy bylo potřeba trochu přemýšlet a nedalo se to řešit hrubou silou :-)

Dnešek zatím nemám, jinak všechno.

149
Odkladiště / Re:Advent of Code 2020
« kdy: 07. 12. 2020, 09:26:35 »
Dneska zase, opruz naparsovat lidské věty (!) do nějaké rozumné datové struktury. Pak easy peasy.

150
Odkladiště / Re:Advent of Code 2020
« kdy: 06. 12. 2020, 08:03:09 »
joa mam takovej dojem že v druhý půlce pátýho dne maj bug ale taky je jako možný že sem něco popletla já sama a prostě to teďko nevidim :o :-\ už sou taky dvě pryč koukejte nato :o :o dobrou noc!!!!!!!!!!!!!

Nemají, jen to vysvětlují dost zmateně. Jde o to, najít takové id, které se v seznamu nevyskytuje, ale okolní id (o 1 vyšší a nižší) ano.

Stran: 1 ... 8 9 [10] 11 12 ... 15