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 ... 166 167 [168] 169 170 ... 375
2506
Vývoj / Re:Ideálny programovací jazyk
« kdy: 13. 05. 2019, 17:28:54 »
Tak, jaks to napsal, to vypadá, že async/await je pro tebe jen syntaktický cukr. Ono jde ale hlavně o runtime, třeba v tom JS je obzvlášť důležité, že “blokující” volání kooperativně přenechá jediné vlákno jiné části kódu.
Jenže v tom JS to přenechání vlákna neplyne z async/await, ale z promise a z interní implementace toho blokujícího volání. V JS je async/await prakticky opravdu jen syntaktický cukr. Když se vykašlete na ošetření chyb, můžete v JS async/await přepsat na Promise.then() a nebude v tom žádný rozdíl.

Důležité jsou ty chyby, protože v případě několika do sebe vnořených callbacků nejde udělat návrat z funkce (return by byl jen z lambdy), kdežto v případě linearizace se chyba vrací úplně normálně (jako třeba v Go) nebo normální výjimkou.
V JavaScriptu (předpokládám, že je řeč stále o něm) má Promise dva kanály – then pro validní výsledek a catch pro chybu. Takže prosté probublání chyby až na konec je tam také jednoduché. Složitější může být, pokud se někde v tom zřetězení callbacků chcete z chyby zotavit, případně je snazší tam výjimku úplně zazdít.

2507
Vývoj / Re:Ideálny programovací jazyk
« kdy: 13. 05. 2019, 15:52:13 »
Java NEUMI Coroutiny a rovnocenna nahrada za ne neexistuje. Tecka.
Chápu. Takže vy píšete spoustu nesmyslů, a když konečně napíšete něco správně, napíšete to tučně, abyste to od těch nesmyslů odlišil. Takže si ty nesmysly řešte s někým jiným, já si počkám, až za dvě stránky zase dospějete k něčemu pravdivému a napíšete to tučně.

2508
Vývoj / Re:Ideálny programovací jazyk
« kdy: 13. 05. 2019, 15:49:28 »
Await/async neni v C# v zadne pripade "jen" syntakticky cukr. Kdyby byl, tak jak to udelas v Jave? Nijak. Pod Await/Async je totiz v C# stavovy stroj, Java to neumi.
Pro stavový stroj nepotřebuju žádnou speciální podporu kompilátoru. Await/async jste na implementaci v C# zúžil právě teď, předtím jste psal o obecném await/async.

Zvláštní je, že když to v Javě nijak naprogramovat nejde, Jetty to má naprogramované jako Continuations. Ale to už jsme vám přece psal…


Za dalsi, neznam nic jako "jen syntakticky cukr"
Tak se s tím pojmem seznamte. Třeba v JavaScriptu je async/await v podstatě jen syntaktický cukr pro Promise.then(), liší se jen ve zpracování chybových stavů.

V C#, Await by se dal povazovat za syntakticky cukr pro neco jako "CompletableFuture.get()" ale Async cukr uz neni. O keyword Async uz nemuzete rict, ze je to cukr pro ktery kompilator provede neco jako "CompletableFuture.supplyAsync(()->.)" Na zklade klicoveho slova Async se musi nejak vygenerovat stavovy stroj, predstavu jak funguje mam jen pribliznou.
No jo, jenže vy nepíšete o async/await, ale o korutinách.

2509
2. Metoda ...definovat jednotlivě <td> který klíč se v něm má vykreslit a ten 11tý vynechat a tato metoda mi právě nešla
Vy jste původně psal o tom, že chcete tu hodnotu použít při nastavení posluchače události.

Pokud chcete ten klíč vynechat, prostě do výpisu těch sloupců přidejte podmínku. Nebo jinak – ve skutečnosti je ten kód špatně, protože iteruje přes klíče v mapě, což nemá definované pořadí. Ve skutečnosti by se vám tedy hodnoty do tabulky vypsali jinak, než jak máte uvedené názvy sloupců, a teoreticky by mohly být hodnoty uspořádané jinak i v každém řádku tabulky. Takže správně je potřeba vyjmenovat ve správném pořadí klíče, které se mají do tabulky vložit. A v tom výčtu akorát vynecháte ten údaj, který tam  mít nechcete. Takže:

Kód: [Vybrat]
function createTable1(json) {
    var table = $("<table>", { id: 'kw-list' }); //tabulka má id, takže je zbytečné cpát jí inline styly, lepší je ostylovat to id v externím stylu
    var thead = table.append($("<thead>"));
    var tr = thead.append($("<tr>"));
    tr.append($("<th>", { id: 'listOfKW', colspan: 10, text: 'List of the KW' }));
    tr = thead.append($("<tr>")); //opět lepší nastylovat přes externí CSS
    tr.append($("<th>", { class: 'listOfKW', text: 'Letter' }))
        .append($("<th>", { class: 'listOfKW', text: 'Commission' }))
        .append($("<th>", { class: 'listOfKW', text: 'Status' }))
        .append($("<th>", { class: 'listOfKW', text: 'KW' }))
        .append($("<th>", { class: 'listOfKW', text: 'P' })) //měl jste tam id, ale to musí být v rámci dokumentu unikátní
        .append($("<th>", { class: 'listOfKW', text: 'CAD' })) //měl jste tam id, ale to musí být v rámci dokumentu unikátní
        .append($("<th>", { class: 'listOfKW', text: 'NEST' }))
        .append($("<th>", { class: 'listOfKW', text: 'SAP' }))
        .append($("<th>", { class: 'listOfKW', text: 'SENT' }));
    var tbody = table.append($("<tbody>"));
    $.each(json, function (index, row) {
        tr = tbody.append('<tr>');
        tr.mouseover(function () {
            nhpup.popup(row.Items);
        });
        $.each(['letter', 'commission' /* další sloupce */], function (index, key) {
            $('<td>', { class: key + ' ' + row[key], text: row[key] }) //opět styl v externím CSS
                .appendTo(tr);
        });
//Chybný původní kód, pořadí sloupců není zaručené.
//        $.each(row, function (key, value) {
//kdybyste ale tedy chtěl jeden klíč vynechat, prostě jen přidáte podmínku if (key == 'sloupecKVynechani') {return;}
//            $('<td>', { class: key + ' ' + value, text: value }) //opět styl v externím CSS
//                .appendTo(tr);
//        });
    });
    $('#eachTable').append(table);
}


já vím jak tyto věci fungují
Nemyslím to nijak zle, ale nesouhlasím s vámi. Viděl jsem tu už spoustu vašich dotazů, a je z nich zřejmé, že nějak skládáte kód víceméně metodou pokusu a omylu, ale neznáte ty principy, které jsou za tím, nevíte, jak to dohromady funguje. Já vás nechci kritizovat, nikdo učený z nebe nespadl a každý se to musel nějak naučit – mně ale připadá, že tím vaším způsobem se to nikdy nenaučíte. Upřímně řečeno, četl jsem dost vašich dotazů, kde bych uměl odpovědět a odpověď by byla jednoduchá, ale záměrně jsem na ně neodpovídal – protože tohle podle mne není způsob, jak byste se to mohl naučit. A odpovídat na ty dotazy znamená jenom to, že se prodlužuje doba, než přijdete na to, že tudy cesta nevede – a o to pracnější pak pro vás bude doopravdy se to naučit.

Opravdu to vůči vám nemyslím nijak zle, líbí se mi, že se do toho snažíte proniknout a neodrazuje vás hned, když vám něco nejde – ale o to víc mne mrzí, že jste zvolil cestu, která podle mne k cíli nevede.

2510
Vývoj / Re:Ideálny programovací jazyk
« kdy: 13. 05. 2019, 10:56:55 »
To by me zajimalo jak chcete s thready napsat aynchronni kod.
No, ehm, úplně normálně? Asynchronní kód s vlákny dělá třeba to vaše @Async ze Springu, ostatně i primitivní new Thread().start() je asynchronní kód s vlákny.

Protoze k tomu abyste z toho opravdu dokazal tezit, tak potrebujete mit drtivou vetsinu metod await async
Asi bychom si nejprve měli ujasnit, co je await/async – je to syntaktický cukr, aby kód, který se provádí asynchronně, byl zapsaný jako klasický synchronní kód. Normálně u asynchronního volání určíte, co se má dít po do dokončení příslušného kódu. Await/async znamená, že to asynchronní volání nějak označíte (pokud má podporu přímo jazyk, obvykle klíčovým slovem await), a kód, který se má provést po dokončení asynchronního volání pak píšete pod to asynchronní volání. Ohledně možností toho, co můžete napsat, se nic nemění.

Jenom tak se vam bude spoustet kaskada operaci zatimco normalne pisete relativne standardni kod a nesnazite se komplikovat si design paralelnim zpracovanim.
Nemůžu si pomoci, ale podle mne je await špatný koncept. Ten nápad „asynchronní kód je pro programátora složitější, uděláme to, aby to vypadalo, že o žádný asynchronní kód nejde“ staví na tom, že ta komplikovanost vzniká jenom strukturováním kódu. Jenže podle mne by si programátor měl být vědom toho, že pracuje s asynchronním kódem, protože jednak to stejně může mít vedlejší efekty, jednak kód psaný neasynchronně nebude při provádění tak efektivní, jako když programátor záměrně píše asynchronní kód.

Springovske Async neni neco jineho, kdyz se to spravne pouzije (kdyz se budou vyrabet Fibery z Quasaru), tak je to prave TO  Await Async, podobne jako je v C#.
Springovské @Async předá provedení kódu standardnímu javovskému Executoru. V kódu, který volá @Async metodu, dostanete jako návratovou hodnotu Future a kód normálně pokračuje v provádění, nečeká na dokončení té asynchronní metody. Pokud chcete udělat await, musíte na tom Future vzápětí zavolat get(). To už ale nijak nesouvisí se Springovským @Async, to je normální chování Future.

2511
Vývoj / Re:Ideálny programovací jazyk
« kdy: 13. 05. 2019, 09:17:28 »
Pokud pisete  komponentu, kde vam chodi paralelne requesty, tak mate zparalelizovane uz ty requesty. Nepotrebujete paralelizovat i ukoly v ramci jednotlivych requestu, to je nesmysl.
Není to nesmysl, běžně se dělá to, že pro zpracování síťové komunikace (přijetí požadavku) se používá jeden pool vláken, a pro vlastní zpracování požadavku (výpočet, dotaz do databáze, odeslání jiného požadavku) jiný pool vláken.

Dalsi vec i kdybyste mel nejakou singleuser komponentu, tak pokud pokud jsou hlavnim problemem blokujici operace, tak na to zase nechcete pouzivat vlakna, akorat si budete komplikovat zivot. Takze v Jave nahrada za await async neni. Resp. je, ve Springu "@Async" a nakonfigurovat to at se berou vlakna z Quasar, ale to je zase tak pres koleno...
To je těžké, když jediné, co znáte, je Spring. Ve standardní knihovně máte concurrent framework, máte RxJava nebo Reactor, Netty (a tím pádem Micronaut) používá zmíněný pool IO vláken a pool workerů, Jetty má Continuations a tím byly inspirovány Asynchronous servlets. Přičemž Continuations jsou právě koncept await/async. Springovské @Async je něco jiného, je to klasické asynchronní zpracování, není tam to await.

2512
Vývoj / Re:Ideálny programovací jazyk
« kdy: 13. 05. 2019, 07:48:20 »
Vidím, že se specializujete na komentování věcí, o kterých nic nevíte.

ze to zmeni design Javovskych frameworku k lepsimu.
Je pozoruhodné, jak často na Javu nadávají lidé, kteří předpokládají, že Java == Spring.

Protoze ta kompilaci na native ma nejake problemy s reflexi
Ve skutečnosti se akorát musí pro reflexi při kompilaci přibalit další informace. Nedivil bych se, kdyby to v budoucnosti nebylo potřeba. Ostatně kdyby se spojila AOT a JIT kompilace (aplikace by nastartovala z nativního kódu, ale dál by se v při běhu uměla optimalizovat pomocí JIT), byl by to další krok vpřed.

ja si myslim, ze Spring pouziva reflexi az presprilis
Podle mne Spring vůbec nesmyslně vše řeší až za běhu, přitom většina věcí, co dělá Spring, se dá řešit v době kompilace. Podle mne málokdo používá modularitu až v době běhu. Ale vzhledem k době vzniku je to pochopitelné.

Takze treba ten Micronaut je v tomhle vice odlehceny a mozna je to castecne zasluha toho GraalVM.
Nemyslím si, že je to zásluha GraalVM. Podpora pro GraalVM byla do Micronautu dodána až později. Udělat něco jako Spring, ale anotace použít tak, jak byly původně především zamýšlené – tj. využít je při překladu – vyselo ve vzduchu, byla jen otázka času, kdy se do toho někdo pustí.

Akorat nevim jak se tam treba resi anotace typu @Transactional, asi nijak. Snad se jednou dockam jazyka, kde se @Transactonal a podobne veci poresi uz v prubehu kompilace, protoze se mi nelibi, kdyz se porad vsechno musi volat pres proxy beany.
Micronaut anotaci @Transactional umí používat a řeší ji přesně tak, jako řeší vše ostatní – už v průběhu kompilace.

To by se u normalniho stavoveho stroje s await async nemelo stat, protoze tam bezi jenom jeden thread.
Jistě, použít jediné vlákno je na dnešních mnohojádrových procesorech výborný nápad.

Protoze na tom, jak se neco pouziva a jak slozite je to nakonfigurovat, setsakramentsky zalezi. To ma problem pochopit Jirsak.
Naopak, já tohle chápu velice dobře. Mimochodem, v tom je právě jedna z předností Javy, že je prostředí kolem už tak bohaté, že se spousta i poměrně složitých věcí používá velmi jednoduše. GraalVM je mladá technologie, takže to samozřejmě bude chvíli trvat, než bude také tak snadno použitelná, ale to je problém všech nových technologií, včetně třeba toho Go. Navíc Oracle se dost snaží GraalVM nedělat jako revoluci ale jako evoluci současných nástrojů, takže některé vlastnosti můžete používat tak, že OpenJDK spustíte s určitým parametrem a do projektu si přidáte závislost na normálním jarku dostupném v Maven repository. Vás to dokonce zmátlo tak, že jste si myslel, že to ani nepřináší podstatné nové možnosti.

2513
Vývoj / Re:Ideálny programovací jazyk
« kdy: 12. 05. 2019, 15:57:44 »
Ja som sa konkretne vas na ziadne enterprise nasadenie nepytal.
Máte pravdu, nebyla to otázka. Bylo to tvrzení, které bylo fakticky špatně. Proto jsem ho opravoval. Konkrétně jste napsal: „GraalVM nebude na enterprise nasadenie ready nikdy.“

Napisal som, ze GraalVM sluzi ako testbed, aby sa technologie dostali co najskor medzi developerov.
Ano, to jste napsal, a už jsem vám to vyvracel, že jste to napsal špatně. Vývojáři používají jednotlivé technologie (SubstrateVM, native-image, Truffle), GraalVM je naopak marketingový název Oraclu, aby to mohl propagovat jako balík a nabídnout k tomu placený support.

Vy ste co? Predavac s teplou vodou od Oracle?
Nikoli, pouze vyvraceč nesprávných tvrzení.

Nechcem vam kazit den, ale ziadna generacna zmena sa v GraalVM nekona. Je to klasicky 8ckovy HotSpot rozsireny o JVMCI. JVMCI je sucastou OpenJDK od 9ny. O Jave 9, 10, 11 aj 12 preco potom nepisete, ze je to "vm novej generacie"? Tie si to nezasluzia?
Jedna z komponent GraalVM je SubstrateVM, což je JVM s AOT kompilací (na rozdíl od HotSpotu, který má JIT kompilaci). Součástí GraalVM je je úplně nový kompilátor z bajtkódu do nativního kódu, je napsaný v Javě a umí ho používat jak HotSpot tak SubstrateVM. Pod GraalVM také patří Truffle, který umožňuje přidávat do VM podporu dalších jazyků (vedle Java bytecode). GraalVM pak umožňuje i současný běh různých jazyků pod jednou VM, takže můžete aplikaci napsanou v Javě nakonfigurovat v JavaScriptu a pak spustit nějaký výpočet v R. Pro Truffle existuje i implementace pro LLVM bajtkód, takže pod GraalVM můžete spouštět i programy napsané v některém z jazyků, které podporuje LLVM.

To všechno jsou věci, o kterých se původnímu HotSpotu ani nesnilo. Že je to vše udělané tak, aby se to dalo používat z původního HotSpotu, je plus, pomáhá to překonat problémy se zpětnou kompatibilitou.

2514
Vývoj / Re:Ideálny programovací jazyk
« kdy: 12. 05. 2019, 14:26:12 »
Fakt?
Ano.

ja hovorim o Community Edition. A vy?
Já píšu o GraalVM EE. Ptal jste se na enterprise nasazení.

Nikde som nevidel, ze by sa nu od Oraclu dal ziskat plateny support. vy snad ano?
Tak proč diskutujete o něčem, o čem nic nevíte? Ve středu byla oznámena GraalVM 19.0, první produkční verze GraalVM. Vydána byla ve dvou edicích, jak bylo celou dobu plánováno, v edice Community Edition a v edici Enterprise Edition. Na Enterprise Editionposkytuje Oracle komerční podporu.

Nehovoriac o tom, ze cielom projektov ako MLE je, ze ziaden GraalVM treba neni.
Nenašel jsem, co je projekt MLE. GraalVM je virtuální stroj nové generace, podporuje běh více jazyků, AOT kompilaci do nativního kódu – mně osobně to připadá dost užitečné, nejen pro Javu.

2515
Vývoj / Re:Ideálny programovací jazyk
« kdy: 12. 05. 2019, 12:00:12 »
GraalVM nebude na enterprise nasadenie ready nikdy. Je to iba testbed project, ktory sluzi na to, aby sa ludia zacali hrat s buducimi technologiami a poskytli potrebny feedback.

Ak chcete vediet, kedy sa technologie, ktore sa na GraalVM prototypuju, stanu enterprise ready, tak to zavisi od kazdeho downstream projektu zvlast.

Je to přesně opačně. GraalVM je marketingové označení od Oraclu, který vzal několik souvisejících projektů a spojil je pod tímhle názvem, aby to mohl prodávat do enterprise sféry.

Ano, většina těch projektů je velmi mladých, ale mají našlápnuto velice dobře, správným směrem, a ukazuje to, že to Oracle s Javou myslí vážně. A že si s ní ví rady, na rozdíl od Sunu.

Pane Jirsak, me uz asi nepresvedcite.
Ano, to už jsem pochopil. Mně je to jedno, já vás přesvědčit nechci. Akorát bych byl velmi nerad, abych takhle jednou dopadl sám – že pro mne můj názor bude tak důležitý, že nebudu ochoten přijmout jakékoli argumenty proti.

2516
Vývoj / Re:Ideálny programovací jazyk
« kdy: 12. 05. 2019, 11:23:20 »
1. Oracle - kolik bude GraalVM stat, jake bude srani s licencemi?
2. Kompilace - jak dlouho se to kompiluje v porovnani s Go?
3. GraalVM a Spring - nedari se mi vyrobit image - uz se s tim zase seru, hodina a pul zabita.
4. Konfigurace - neni to lusknutim prstu, s Go dam 1x download a mam vse.
5. Kdy bude GraalVM pripraven pro produkcni nasazeni v enterprise?

Tvl ta Java to je takova hydra, a ted ji akorat zase narostla dalsi hlava  :D
GraalVM Community Edition je pod GPL. Argumenty vás ale zjevně nezajímají, vy máte jasno, a když jsem vaše argumenty vyvrátil, vymyslel jste si jiné – co na tom, že jsou úplně nesmyslné. Nebo vás vážně trápí, kolik sekund trvá vytvoření nativního obrazu někde na build serveru? GraalVM vyšla zrovna před pár dny v oficiální produkční verzi. Pro nasazení v enterprise bude vhodná tak během roku dvou. Na rozdíl od Go, které by pro nasazení v enterprise potřebovalo ještě aspoň tak pět (pokud by se na tom opravdu pořádně makalo) nebo deset let vývoje celého ekosystému. Jenže ve skutečnosti nebude Go pro nasazení do enterprise vhodné nejspíš nikdy, protože k tomu není určené. Java tak sice původně také nebyla zaměřená, ale nemyslím si, že by Go zopakovalo cestu Javy. Největší smůla Go je ta, že se teď na něj lepí takoví ti rozumbradové, kteří jenom opakují memy zaslechnuté někde na internetu, ale ve skutečnosti o tom nic neví.

2517
Server / Re:PHP SQL problem s SELECT a OR
« kdy: 12. 05. 2019, 11:06:34 »
Kód: [Vybrat]
$lastnameParam = '%' . $lastname . '%';

$sth = $dbh->prepare("SELECT * FROM users WHERE firstname OR lastname LIKE :lastname");
$sth->bindParam(':lastname', $lastnameParam, PDO::PARAM_STR);
$sth->execute();

Až na to, že je tam zase ta chyba s OR jako v původním příspěvku…

2518
Vývoj / Re:Ideálny programovací jazyk
« kdy: 11. 05. 2019, 23:22:39 »
Proc to vubec resime toto. Kazdy proste vime, ze Java je pomala a nenazrana, pomalu startuje, v provnani treba s Go, nebo Swift, nebo Objective-C.
Ne, to „víte“ jenom vy. A řešíme to proto, abyste se dozvěděl, jak je to doopravdy. Když provedení aplikace v Go trvá průměrně 260 ms a doba běhu aplikace (s tím samým algoritmem) v Javě trvá průměrně 166 ms, nevypadá to, že by Java byla v porovnání s Go pomalejší. Spíš to vypadá opačně.

2519
Vývoj / Re:Ideálny programovací jazyk
« kdy: 11. 05. 2019, 23:08:14 »
Dam dalsi priklad - jak dlouho startuje Spring, treba pri JUnit springovych testech? To vsechno tak nejak s tou zravosti Javy souvisi.
Jak dlouho startují JUnit testy bez Springu? Jak dlouho startuje Micronaut? To je nějaká jiná Java?

2520
Ano, pokud ten token bude uložen v JS aplikaci na frontendu, z pohledu CSRF je to bezpečné – útočník se k tokenu nemůže dostat a prohlížeč ho neposílá automaticky, tj. požadavek s validním tokenem nemůže odejít jinak, než přímo z vaší aplikace.

Pokud se OAuth2 implementuje podle aktuálních doporučení, žádný známý útok mne nenapadá. Jedině to, že u Single Page Aplikací (SPA) se dříve doporučovalo u autentizace přes OAuth2 implicit flow, dnes už se doporučuje provést i v tomhle případě standardní získání tokenu. Celý proces přihlášení přes OAuth2 je odbře popsán teřba v OAuth 2 Simplified a jsou tam i odkazy na aktuální doporučení.

Stran: 1 ... 166 167 [168] 169 170 ... 375