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 - Filip Jirsák

Stran: 1 ... 173 174 [175] 176 177 ... 375
2611
Odkladiště / Minimální interval mezi změnami hesla
« kdy: 27. 03. 2019, 12:13:03 »
Článek Nekomplikujte lidem přihlášení, jinak začnou být kreativní, říká Jim Fenton mi připomněl jednu otázku týkající se politiky hesel. Někde je součástí politiky hesel pravidlo, které stanovuje minimální interval mezi změnami hesla – např. pokud si heslo změníte, další změnu můžete udělat až za 30 minut (těch 30 minut je v naší vyhlášce o kybernetické bezpečnosti).
Chápete někdo, jaký to má bezpečnostní účel? Jaký je vektor útoku, kterému to má bránit? Chápal bych to ještě jako obranu, aby si uživatel nemohl heslo změnit „na oko“ a vzápětí vrátit na původní, ale to řeší historie hesel (např. ta vyhláška NÚKIBu vyžaduje pamatovat si historii 12 hesel). Jaký je vektor útoku založený na tom, že si uživatel změní heslo a vzápětí si ho změní ještě na jiné, nebo že to samé udělá útočník?

2612
Vývoj / Re:Několik nejasností začátečníka s Gitem
« kdy: 27. 03. 2019, 10:59:14 »
Dejme tomu bude potřeba udělat zásah do strého projektu, doma stáhnu, udělám opravy, push na GitHub. Ovšem v práci pak zjistím, že před X měsíci jsem tohle už taky řešil a jen nenahrál na server. Jde to sloučit, nebo jak na to Git upozorní - předpokládám, že zařve a je to rozumně řešitelné.
Záleží na tom, jestli tu změnu máte commitnutou nebo ne, v jakém branchi a jestli tam máte i jiné změny. Pokud vyvíjíte sám, asi nebudete moc používat branche, budete úpravy průběžně commitovat a průběžně synchronizovat s „centrálním“ repository – pak takovýhle případ nemůže nastat. Může nastat případ, že budete mít na obou místech různý poslední commit (nebo několik posledních commitů). Pak na jedné straně dáte push commitů do centrálního repository, na druhé straně dáte pull a řeknete, co se má udělat se změnami – buď rebase, který dá ty vaše commity bokem, stáhne branch ze vzdáleného repository a pak ty vaše commity, co dal bokem, přeskládá, jako by vznikly až na konci toho vzdáleného branche. A nebo zvolíte řešení změn pomocí merge, který ponechá ty dvě větve tak jak jsou, a na konci je jedním commitem spojí do jedné větve.

Nebylo by lepší na vývoj z domu mít druhý účet a skládat to jako od dvou vývojářů? Má to nějaké výhody, nebo je to úplný nesmysl?
Z hlediska workflow a práce s commity git nijak neřeší, zda je to od jednoho vývojáře nebo od více. Z pohledu gitu je to tak, že prostě máte dva různé commity, které chcete dostat do jednoho repository. Protože upravují ten stejný soubor, je potřeba vyřešit případné konflikty – jednoznačné věci git zvládne vyřešit sám, a pokud by tam byl skutečný konflikt, tj. různé varianty kódu, budete konflikt muset vyřešit ručně.

A nakonec, u webových projektů, se mi prostě nelíbí představa mamutí složky .git na webserveru. Jistě, můžu zakázat přístup do složky, ale... Navíc jak správně řešit když samostatně vyvíjím např. knihovnu pro DB, prezentační vrstvu (hromada SASSy šablon + kompilované styly), hodilo by se spíš řešit Git pro jednotlivé komponenty a pak jenom poskládat hotový projekt z aktuálních verzí. Jak k tomu přistupovat? Nebo prostě .git pro každý web a případné knihovny prostě kopírovat...
Na webovém serveru byste neměl vyvíjet, takže mít tam složku .git je zbytečné. Ani byste neměl řešit aktualizaci zdrojáků na serveru přes git – aktualizace v gitu není atomická, tj. v průběhu aktualizace byste měl některé soubory nové a některé staré, takže by aplikace nejspíš nefungovala správně.

Lepší je mít v rámci vývoje nějakou fázi „sestavení aplikace“, která posbírá potřebné soubory, případně je upraví (mimifikuje, zkomprimuje, validuje apod.) a sestaví z toho distribuční balíček, který nahrajete na webový server. Balíček tam rozbalíte do nového adresáře a pak přesměrujete symbolický link ze staré verze na novou. Tím přesměrujete aplikaci atomicky ze staré verze na novou – v jednom okamžiku se ještě používá stará, v dalším nová. Samozřejmě to neřeší případ, kdy si webový prohlížeč stahuje různé soubory (může stáhnou jeden skript ze staré verze a další z nové), ale to se zase řeší jiným způsobem (obvykle verzováním skriptů a stylů). Díky tomu symlinku také máte možnost vrátit se hned zpět k předchozí verzi, pokud by se ukázalo, že v té nové je chyba.

2613
Vývoj / Re:Ako komplikovane programujete?
« kdy: 27. 03. 2019, 07:17:54 »
For-loop vs foreach s lambdou, to je imho presne ta vec, co by mel delat kompilator, ne programator.
Ještě lepší je, když to nedělá kompilátor, ale běhové prostředí, protože to má informace o aktuálním běhu programu, takže může dělat i optimalizace, které kompilátor dělat nemůže.

Když to ale vrátím k původnímu tématu diskuse, optimalizace rychlosti aplikace inlineováním kódu ve smyčkách je na světelné roky daleko od situace, kdy někdo používá v aplikaci nějaký framework a vůbec neví proč.

2614
Vývoj / Re:Ako komplikovane programujete?
« kdy: 26. 03. 2019, 21:30:54 »
Je to podmiene implementaciou a pouzitim invokedynamic.
K čemu se v implementaci Java Stream API používá invokedynamic? A kde je to implementováno? Podle mne je celé Stream API implementováno v Javě a nevyžaduje žádnou magii na straně kompilátoru.

2615
Vývoj / Re:Ako komplikovane programujete?
« kdy: 26. 03. 2019, 21:19:43 »
Ty nevis, jak to v enterprsise enviromentech chodi? Chodi to tak, ze budes pouzivat vsechny 3. Protoze jeden frajer pouzije Maven, druhy na sousedni komponente si mysli, ze Maven je moc oldschool tak pouzije Gradle, a treti si mysli ze Maven a Gradle na to jdou moc slozite a pouzije Ant nebo Ivy.
To bych chtěl vidět, jak ty tři/čtyři nástroje použijete najednou k sestavení jedné komponenty. Spíš bych si tipnul, že si vymýšlíte. Pokud se ty nástroje používají pro „sousední“ komponenty, je vám úplně jedno, jaký nástroj se pro sestavení používá – vy dostanete hotové JARko, případně obohacené o model závislostí (např. pom.xml), ke kterému se chováte jako k jakékoli jiné knihovně.

Vsechny ty 3(4) pripady maji jednoho spolecneho predchudce - bordel v Jave, kde existuje hromada nic moc externich knihoven delajicich plus minus jedno a to same, protoze v zakladnim JDK na to serou a neudelali tam hromadu veci poradne.
To samé máte třeba v opensource, firmy na trhu nebo živí tvorové – také hromada nic moc různých variant téhož, místo aby se napsal jeden program, existovala jedna firma a jeden živý tvor, které by ale byli udělané pořádne.

Uz jsem tu s tebou diskuzi v tomto stylu vedl v minulosti a neminim to delat znova, protoze to nema smysl, protoze ty mas proste problem pochopit takoveto nuance.
Nemám problém to pochopit. Akorát si myslím, že jste si kód, kde se používá pro sestavení Maven, Gradle i Ant, prostě vymyslel.

protoze ty jsi skolitel Java technologii
Tak určitě. A pak se divíte, že vaše komentáře beru s velkou rezervou, když vidím,jak si vymýšlíte.

Ad Micronaut - diky za tip, asi se na to nekdy podivam, nicmene prijde mi, ze uz se tu pres sebe v Jave placa pate pres devate, ani na GraalVM uz jsem se nedival
Hlavně že máte ty praktické zkušenosti.

A nejak pochybuju, ze to zachrani Kotlin.
Ne, Kotlin to určitě nezachrání. Jednak teda není co zachraňovat, jednak Kotlin je jen zajímavý experiment, ze kterého se vezme pár věcí, které se osvědčí, a nebude to tak bolet, když s ním zaniknou ty věci, které se neosvědčily.

Uz se tesim, az tato nova generace jazyku zacne vytlacovat Javu pryc. (jeste to dlouho potrva)
Nemyslím si, že Kotlin nebo Go budou ty jazyky, které se dlouhodobě prosadí. Hodně experimentují, a jazyk, který se dlouhodobě prosadí, musí být dost konzervativní. Kotlin i Go jsou taková líheň nápadů, ale ještě nejsou ty pravé, to přijde až někdy po nich.

Jeste jsem chtel rict, ze hodne lidi vidi budoucnost v tom, ze se do jazyku pridavaji nove featury (treba streamy) a ze to je ten svaty gral, jak se to pohne dopredu a bude lip. Ja s tim zasadne nesouhlasim, myslim si, ze budoucnost je praveze jinde, je v osekavani zbytecnych veci, tak jak to dela Go. Myslim si, ze tento pristup do budoucna vyhraje.
Osekávání vlastností, přílišná jednoduchost, je to, co se většinou vytýká Javě. A vy byste chtěl osekávat ještě víc. Což je přesně ten důvod, proč nikdy nevyhrají ani extrémně složité jazyky (teda s výjimkou C++), ani ty extrémně jednoduché. Protože by je nikdo z toho druhého tábora nechtěl ani neuměl používat. Zatímco na jazyk, který je někde uprostřed, sice oba tábory svorně nadávají, ale nakonec ho používají, protože se díky němu mohou potkat.

2616
Vývoj / Re:Ako komplikovane programujete?
« kdy: 26. 03. 2019, 17:11:16 »

2617
Vývoj / Re:Ako komplikovane programujete?
« kdy: 26. 03. 2019, 11:13:49 »
A ty externi knihovny zpusobi, ze musite pouzivat Maven. A ze se musi pouzivat Maven zpusobi, ze se musi pouzivat i Gradle. A ze se musi pouzivat Gradle zpusobi, ze se bude pouzivat i Ant. Vsechno se na sebe vrstvi a pak toho je hromada.
Co je to za nesmysl? Používáte buď Gradle, nebo Maven, nebo Ant, nebo třeba Ivy. Všechno jsou to systémy pro sestavení aplikace a budete je používat i kdybyste měl závislost jenom na JDK.

Ja se ptam, kdyz nekomu prijde Spring moc velky overhead pro jeho aplikaci, tak v cem jinem to ma potom fidlat?
V čem? Spíš pomocí jakých nástrojů, ne? A tak nějak mi připadá normální použít nástroje, které jsou pro daný účel vhodné. Pokud budu psát aplikaci pro příkazovou řádku, která dostane na vstupu XML, transformuje ho a zapíše do databáze, tak použiju Saxon, dom4j, JDBC driver, možná nějakou nadstavbovou knihovnu nad JDBC a možná něco na parsování argumentů příkazové řádky. K čemu by mi tam byl Spring?

O cehokoliv jineho nez Springu si uz budu klast otazku, jestli si ten backend nemam rovnou udelat v Node.js
Proč „rovnou“? Svět Javy a Node.js jsou dost odlišné, v Node.js se teď řeší věci, které má Java vyřešené třeba deset patnáct let, znovu se objevuje to samé.

A u veci slozitejsich uz se zase dobre hodi ten Spring, protoze ten overhead se ztrati.
Existují i jiné frameworky, než Spring. Spring je takové nové J2EE… Má nepopiratelné místo v historii, usnadnil spoustu věcí, ale už má příliš velkou zátěž z minulosti a snaží se řešit úplně všechno. Ale už vedle něho vyrůstají nástupci, kteří (nebo jejich následníci) Spring nahradí. Berou si ze Springu to dobré, opravují věci, které má Spring špatně ale kvůli zpětné kompatibilitě je nemůže opravit, umí se na Spring napojit tam, kde se to hodí. Třeba Micronaout.

Za me, Java se proste bohuzel nehodi na mensi veci, nez na ktere uz je vhodny Spring. Si myslim. Schvalne uvedte nejaky jiny priklad z praxe.
Podívejte se na Micronaout – DI inspirovaná Springem, ale udělaná správně (v compile-time místo run-time). Umí spolupracovat s GraalVM a vytvořit miniaturní binárky. Založený na neblokující síťové komunikaci, ale bez problémů můžete programovat synchronní kód a bude to fungovat správně. A protože máloco vzniká na zelené louce, potřebujete často nějaké vazby na Hibernate nebo Spring – a máte je tam. Klidně v tom můžete psát microservisy nebo cloudové lambdafunkce, a dává to smysl, protože pořád kolem sebe máte ten obrovský svět Javy, kdykoli můžete sáhnout po nějaké knihovně, a nemusíte se bát, že až vám těch microservis přibyde víc, bude to neudržovatelné.

2618
Vývoj / Re:Ako komplikovane programujete?
« kdy: 26. 03. 2019, 09:58:40 »
Tazatele stve overhead frameworku a importovani hromady externich knihoven, klade si spravnou otazku, proc se neda vystacit se zakladnimi vecmi, ktere poskytuje Java. Normalni jeste zdravy clovek si totiz kladu otazku, proc se neco dela slozite, kdyz to jde jednoduse.
Já jsem se ptal na otázku, která tomuhle ještě předchází – jak se stane, že to někdo začne dělat složitě, když to jde dělat i jednoduše. Vy řešíte případ, že někdo už začal špatně a pak se ptá, jestli to nejde lépe. Já se ptám, jak se stane, že někdo začne špatně.

Určitou teorii na to mám – že lidé neznají JDK a neznají různé knihovny, znají akorát Spring (v téhle souvislosti se vždy objevuje jen Spring, často dotyčný píše o Javě a najednou píše o Springu, jako by to bylo jedno a to samé). Tím pádem se snaží vše dělat ve Springu.

No v Jave to bohuzel moc dobre nejde a to kvuli tomu, ze zakladni knihovna nedisponuje dostatecne kvalitne udelanymi vecmi. Pokud nekdo nevi jak to myslim, tak at se podiva jak to maji vsechno pekne vyresene v .NETu. Tak by to melo vypadat, kdyz se majitel platformy o ni stara.
V základní knihovně Javy existují i dobře udělané věci, například kolekce – nejspíš těch věcí dokonce bude většina, když se Java tak rozšířila. A cílem samozřejmě není mít vše narvané v základní knihovně, naopak je dobře, že máte spoustu specializovaných knihoven a vyberete si tu, která vám vyhovuje nejlépe.

Ja treba pridam jeste naprosto vtipny Unzip v JDK, ktery nejenom ze je pomaly jako snek, ale jeste navic v podstate zcela znemozni odzipovavat vnorene zipy kompletne v pameti - mezirozbalovacky se musi vzdycky ukladat na hdd.
Otázkou je, proč by zrovna propracovaný unzip měl být v základní knihovně Javy. Jaký podíl Java aplikací asi potřebuje rozbalovat zip v zipu? Není lepší, když takové aplikace použijí externí knihovnu, která může mít rychlejší vývojový cyklus a poskytovat toho mnohem víc?

2619
Vývoj / Re:Ako komplikovane programujete?
« kdy: 26. 03. 2019, 07:47:07 »
Caute,

vela programujem v Jave a v poslednom case som sa prichytil pri tom, ze som zacal preferovat komponenty a libky ktore su v Jave samotnej. Dlho som napriklad pouzival Jackson a ekosystem okolo na JSON alebo Apache HTTP libky na HTTP klientov ale uz celkom dlho existuje JSON-B / JSON-P a Java ma v sebe HttpClient-a ... Najprv som sa bal ze to nebude vela vediet ale cuduj sa svete, ono to ani nie je treba. Co zacinam nove projekty tak zamerne programujem uplne jednoducho v cistej Jave takze som zavisly na minime externych veci a ono to na pocudovanie aj celkom funguje. Zahodil som cely Spring a zacal som pouzivat Guice a Javalin. Na JWT tokeny java-jwt z com.auth0 a tiez to uplne v pohode fici jak ma ... raketovo sa v tom programuje.

Já moc nechápu, o čem vlastně chcete diskutovat. V titulku máte „komplikovanost“, ale v samotné otázce k ní pak není ani čárka.

Co se týče knihoven, samozřejmě nemá smysl používat externí knihovnu, pokud vašim potřebám vyhovuje i vestavěná runtime knihovna.

Knihoven pro JSON vzniklo několik, Jackson je mezi nim i asi nejrozšířenější. Používá ho i spousta dalších knihoven, takže občas jste k jeho použití donucen jinou knihovnou. Na druhou stranu to, jak je ta knihovna navržená, není žádná sláva. JSON-P je dobře navržené API, bylo to standardizováno, doufám, že postupně převezme roli toho standardního API pro JSON v Javě, že ho bude implementovat i Jackson a další. JSON-B je jiný případ, sice také snaha o standardní API, ale to API je nešťastně navržené a špatně zdokumentované. Referenční implementaci jsem naposledy zkoušel krátce před verzí 1.0 a bylo to docela dobrodružné – v jednom případě se něco špatně přetypovávalo a vyhazovalo o výjimku, v druhém případě dokonce bylo evidentní, že to nikdo nikdy neotestoval na mapě s více než jedním klíčem, protože zbytek mapy se prostě zahodil.

Původní HTTP klient v Javě byla tragédie a nemohl ho použít nikdo, kdo alespoň z rychlíku zaslechl něco o tom, jak má vypadat programování síťové komunikace. Nešlo tam nastavit nic, ani tak základní věc, jako timeouty. Proto se používaly externí knihovny. Teď už má Java HTTP klienta, který vypadá podstatně lépe, ale abych pravdu řekl, je to snad jediná věc z nových vlastností Javy, na kterou jsem se ještě víc nedíval – protože ta původní implementace byla opravdu tragédie, a být „podstatně lepší“ než to pořád ještě nezaručuje, že to bude alespoň dobré. Ale pokud už má vlastnosti, které potřebujete, a nepotřebujete podporu starších verzí Javy, proč to nepoužít?

To samé se týká i Springu – pokud ho nepotřebujete, tak proč ho používat? Spring spoustu věcí také implementuje tak, že akorát zabalí nějakou externí knihovnu tak, aby se používala stejně, jako ostatní komponenty Springu. Tak pokud potřebuju jenom funkcionalitu dané knihovny, použiju tu knihovnu a ne celý Spring.

Pouzivate externe libky aj ked nemusite? Zacal som to brat z uplne ineho konca, co najmenej externalit a vyuzit platformu na 100% a zatial sa mi nestalo, ze by mi tam nieco chybalo. Podla mna sa da vela krat dosiahnut ten isty ciel aj jednoduchsie, vsetky tie frameworky su vela krat len uplne zbytocne nadstavby.
Ta zbytečnost není vlastností frameworku ale jeho použití. Mne by spíš zajímalo, jak se vám stalo, že používáte externí knihovnu, i když nemusíte, nebo používáte zbytečně nějaký framework. Já se s takovými případy nesetkávám a moc si nedovedu představit, jak to vznikne.

2620
Server / Re:PHP, jednoduchá transakční operace do MySQL
« kdy: 25. 03. 2019, 08:26:23 »
Z hlediska SQL už je to správně, ale takhle je v tom PHP kódu bezpečnostní díra – SQL injection. Kdyby vám útočník do id_akce vložil
Kód: [Vybrat]
* FROM dual; DROP DATABASE;
tak vám smaže celou databázi.

Je chyba vkládat data do SQL příkazů tak, že je tam vkládáte textově. Správně se to dělá tak, že v textu SQL příkazu jenom řeknete, že tam má být parametr (vloží se tam otazník):

Kód: [Vybrat]
INSERT INTO dochazka (akce, soupiska, ucast) SELECT ?, id, 0 from soupiska

Následně v kódu řeknete, jakou hodnotu parametr má:

Kód: [Vybrat]
mysqli_stmt_bind_param($stmt, "i", $id_akce)

Jsou to prepared statements.

2621
Server / Re:PHP, jednoduchá transakční operace do MySQL
« kdy: 25. 03. 2019, 07:14:27 »
Tohle se neřeší tak, že byste v cyklu generoval příkazy INSERT, ale použijete INSERT from SELECT – napíšete si SELECT, který vám vrátí tabulku, kterou potřebujete zapsat, a tu pak předáte jako hodnoty do INSERTu.

2622
Sítě / Re:Mitmproxy posílá požadavky zpět na klienta
« kdy: 22. 03. 2019, 17:34:57 »
Kód: [Vybrat]
Accept-Encoding: identity

Kód: [Vybrat]
Content-Encoding: gzip
wget Seznamu řekne, že nemá používat žádnou kompresi, ale Seznam to ignoruje a pošle soubor zazipovaný. Je to chyba na straně Seznamu, asi nepočítají s tím, že by někdo kompresi nepodporoval. Kdybyste ten přijatý soubor rozbalil gzipem, měl byste dostat správný obsah.

Nebo zkuste

Kód: [Vybrat]
curl --compressed https://www.seznam.cz

Překvapuje mne, že wget kompresi neumí vůbec a u curl se musí explicitně zapnout, jinak hlavičku serveru ignoruje (i když v tomto případě je chybná odpověď serveru). A taky mne překvapuje, že jde vůbec nginx nakonfigurovat tak, aby odpovídal takhle špatně.

2623
Sítě / Re:Mitmproxy posílá požadavky zpět na klienta
« kdy: 22. 03. 2019, 16:34:38 »
Zkuste ten wget spustit s parametrem -d, ať vidíte, jaké přesně požadavky odesílá a jaké dostává odpovědi.

Edit: Pardon, u wgetu je to -d. -vcurl.

2624
Sítě / Re:Mitmproxy posílá požadavky zpět na klienta
« kdy: 22. 03. 2019, 15:21:50 »
Proxy server listening at http://*:8080
Tohle je divné. Vy zkoušíte protokol HTTPS, tedy potřebujete, aby mitmproxy očekával od klienta protokol HTTPS – tohle ale vypadá, že očekává HTTP.

Proxy se10.0.10.60:55162: GET https://seznam.cz/
A tohle je také divné, za HTTP metodou je normálně jenom cesta, název serveru se přenáší v hlavičce Host, případně v SNI rozšíření TLS. A protokol v požadavku není uveden vůbec. Pokud to není jenom způsob, jakým to vypisuje mitmproxy, vypadá to, jako by to byl požadavek na HTTP proxy server – jako byste v tom prostředí, kde spouštíte wget, měl nastavené proměnné prostředí HTTP_PROXY a HTTPS_PROXY a na tom mitmproxy se neodchytávala komunikace s cílovým serverem, ale komunikace s proxy serverem.

2625
Software / Re:Dvoufázové přihlášení do PC
« kdy: 22. 03. 2019, 14:53:34 »
P.S.: Je lepší LastPass Authenticator. Pokud ztratíte mobil/přeinstalujete appku v telefonu, vše zůstane uložené. Ne jako u Googlu, tam musíte mít ten plus, ten to pak dovede taky.
Jenom upřesním, že zmiňovaný Authenticator Plus nemá s Googlem nic společného.

A ano, bezpečné zálohování klíčů je podle mne podstatná vlastnost pro OTP generátor na mobilu. Většinou sice máte možnost vygenerovat si nějaké záložní kódy nebo si nechat poslat OTP kód na mobil, ale to není něco, co bych chtěl řešit v případě ztráty nebo jen nedostupnosti mobilu.

Stran: 1 ... 173 174 [175] 176 177 ... 375