reklama

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] 2 3 ... 245
1
Software / Re:Kde najít přesnou formu spuštěného programu?
« kdy: 04. 04. 2020, 14:42:16 »
Přesměrování do souboru bar by možná šlo dohledat jinde, v cmdline to nebude.
V otevřených file descriptorech bude odkaz na obsah toho souboru. Ale jaká byla původní cesta k tomu souboru nezjistíte – on už ten soubor nemusí mít v souborovém systému jméno (může ho držet už jenom ten proces), nebo dokonce pod tím jménem může být v souborovém systému jiný soubor.

2
/dev/null / Re:Proč mapy.cz chtějí polohu?
« kdy: 03. 04. 2020, 16:52:41 »
Fakt na sebe nekdo praskne soukrome firme, ze je nemocny? Goebbels by zasnul.
Nežasnul by. Ale z vás by byl nadšený. Pokud někdo nerozlišuje mezi dobrovolným činem a přinucením násilím, je ideálním adeptem pro totalitní režim.

3
/dev/null / Re:Proč mapy.cz chtějí polohu?
« kdy: 02. 04. 2020, 18:54:33 »
Proč je potřeba sdílet svoji polohu?
Aby se mohlo vyhodnotit, kteří lidé se potkali.

Funguje to bez toho, abych se "tam dostal" a nebo i když kliknu do náhodně vybraného místa, třeba do rybníka u Bruntálu?
Ne. To upozornění funguje zpět. Nedává smysl vyhodnocovat: „Pokud bych býval byl minulý týden v hospodě v Bruntále, mohl bych se býval byl nakazit?“

4
Vývoj / Re:Dalsi, UZ POSLEDNI KIKS V PYTHONU
« kdy: 01. 04. 2020, 10:17:07 »
Dictionary v Pythonu nezachovava order klicu!!!
Zatímco Map v Javě – nezachovává pořadí klíčů. Jak překvapivé. Ona to je totiž režie navíc, přitom u většiny způsobů použití mapy/slovníku zachovávat pořadí klíčů nepotřebujete.

My v Jave mame i svoje vlastni objektove databaze, ktere ale moc nepouzivame, protoze jsou Java-specific. Pouzivame univerzalnejsi SQL databaze, ktere sice vyzaduji ORM vrstvu a dalsi opruzy, ale zato jsou standardni. Jiank bychom si v Jave taky mohli ukladat objekty a pracovat s nima bez nejakeho ORM.
Pokud to nebyl pluralis majestatis, pište sám za sebe. Spousta věcí, co píšete, nemá nic společného s tím, co je programátory v Javě obecně přijímané.

5
Sítě / Re:Pomalé připojení k internetu při uploadu
« kdy: 30. 03. 2020, 16:47:44 »
Tohle je bohužel vlastnost takhle silně asymetrického uploadu. Když něco stahujete, musí váš počítač průběžně potvrzovat, která data už dostal. Když odesílatel takové potvrzení nedostane v rozumném čase, vyloží si to tak, že se data ztratila a pošle je znova. No když je upload ucpaný, nedostanou se tam ani ty vaše potvrzovací pakety. Takže toho jednak jde do downloadu víc (protože některá data dostáváte dvakrát i víckrát), jednak se odesílatel přizpůsobí tomu, že má ve frontě hodně dat pro vás, která nejsou potvrzená, usoudí z toho, že máte pomalý download a zpomalí odesílání.

Řešením může být řízení kapacity linky (nebo-li kvality služby – QoS), kdy nedovolíte jednomu odesílateli plně vytížit upload, takže pro ostatní vždy zbyde alespoň úzký kanál pro ty potvrzovací pakety. Stručně jak na to už vám poradili jiní, nicméně já bych ke QoSu v těchhle spotřebních routerech byl dost skeptický, za mne je otázka, co tam ten QoS vůbec dělá – myslím, že to bude zaměřené spíš na download.

6
Vývoj / Re:NoSql document databaze
« kdy: 29. 03. 2020, 21:52:22 »
Neměla by být ale databázová vrstva spíš od aplikace oddělená tak, aby naopak nezáleželo na tom, jakou databázi použiju?
Pokud „databází“ myslíte to, že má být jedno, jestli to bude SQL relační databáze, dokumenová databáze, grafová databáze, XML databáze nebo souborový systém, pak to rozhodně jedno není. Pokud vám tohle je jedno, pak nejspíš žádnou databázi nepotřebujete…

Ve chvíli, kdy relační databáze umožní uložit libovolný dokument (json) do jednoho sloupce, tak v tom okamžiku se na ni můžu dívat jako implementaci dokumentové databáze, a v tomto ohledu jsou ekvivalentní v tom smyslu, že nemůžu říct, která je vhodnější, nebo není. Prostě jsou na tom stejně. Pochopitelně jedna implementace bude rychlejší v tom, jedna pomalejší v onom, ale jako koncept umí totéž. Ale proč bych kvůli změně měl přepisovat aplikaci?
Auto, letadlo i loď jako koncepty také umí totéž – dopravovat náklad z místa na místo. Jenže když začnete vyvíjet s autem, skončíte nakonec s tím, že budete i tu loď a letadlo tahat po zemi.

Myslím, že se na to totiž díváte z opačné strany. Pro aplikaci není důležité, co databáze umožňuje, ale co neumožňuje.Tomu, co neumožňuje, se budete v aplikaci snažit vyhnout. A tím se vaše aplikace přizpůsobí konkrétní databázové technologii – protože bude obcházet to, v čem je slabá, a využívat toho, v čem je silná. Takže klidně můžete ukládat dokumenty do PostgreSQL, ale nezískáte tím žádnou výhodu relační databáze, ale přijdete o výhody dokumentové databáze.

7
Vývoj / Re:NoSql document databaze
« kdy: 28. 03. 2020, 23:55:52 »
PostgreSQL budete třeba těžko provozovat v režimu „repliky po celém světě, a dokud vidím n/2+1 repliky, v pohodě funguju“. Nad PostgreSQL musíte ručně stavět indexy. Partitioning a dotazování přes víc serverů také v PostgreSQL nejdou dělat úplně snadno.

Pokud potřebuju v databázi ukládat dokumenty, proč bych se mořil s nějakým SQL nebo dokonce ORM?

8
Server / Re:Docker: více aplikací a subdomény
« kdy: 28. 03. 2020, 20:03:40 »
vsak ta aplikace muze mit oba porty, ale jen uvnitr docker site.
Ta backendová? Pokud je to na lokálním počítači, připadá mi zbytečné to šifrovat. Navíc byste se tam musel starat o certifikáty (minimálně vydat nějaký selfsigned na 10 let a za 10 let se divit).

9
Server / Re:Docker: více aplikací a subdomény
« kdy: 28. 03. 2020, 19:01:23 »
mam adresar kde mam jen docker-proxy, vytvoril jsem mu sit. pak kazdy web ma svuj nginx ktery ma pristup do te docker-proxy site. nastavuju vsechny 4 VIRTUAL_* promenne (host, port, proto, network).
Však to mi funguje. Mám problém s https, které mi dává chybu 500
Nepokoušíte se tím proxy nginxem přistupovat na backend server špatným protokolem? Že byste se třeba protokolem HTTP připojoval na port 443 backend nginxu nebo naopak protokolem HTTPS na port 80? Pokud oba ty nginxy běží na stejném počítači (u vás asi ano), je zbytečné používat mezi proxy a backendem HTTPS, nechte tam normálně HTTP na portu 80.

10
Server / Re:Docker: více aplikací a subdomény
« kdy: 28. 03. 2020, 08:53:10 »
Děkuji, však o této možnosti vím a rád bych to udělal nejlépe bez instalace nginx do systému.
Můžete ten nginx nainstalovat také do Dockeru a pak mezi sebou kontejnery síťově propojit tak, aby ten reverzní proxy viděl na ty dva backend servery.

Také mi tam docela chybí ten lets encrypt. Zkoušel jsem několik návodů na internetu, však ty nefungovaly.
Postup je takový, že si vyberete nějakého klienta, který vám vyhovuje, a toho podle návodu nainstalujete a nakonfigurujete. Nejspíš na Docker Hubu už najdete nějaký obraz nginxu, který má v sobě podporu pro Let's Encrypt zabudovanou (ten obraz, ne neginx). Pokud vám něco nebude fungovat, napište konkrétně co – s „nefungovalo mi to“ vám nikdo nepomůže.

11
Server / Re:Docker: více aplikací a subdomény
« kdy: 27. 03. 2020, 23:18:07 »
Dáte před ty kontejnery nginx v roli reverzní proxy. Požadavky z internetu budou směřovat na něj a nginx je předá do konkrétního kontejneru.

12
Vývoj / Re:Doporučte programovací jazyk pro Windows
« kdy: 23. 03. 2020, 08:38:25 »
Jsem rád, že jsem se dozvěděl jak to funguje ve světě Javy, někdy se může hodit, ale třeba u menších projektů hostovaných na AWS Lambda mně nedává smysl dát přednost Javě namísto Pythonu. V naší diskuzi jsem pro takové projekty žádnou přednost Javy nenašel, právě naopak. U větších projektů je to otázka, kde by hrálo roli více faktorů, ale kdyby bylo dostatek vývojářů GoLangu a já se rozhodoval z pozice zákazníka, tak by padla volba na něj - šíření ve strojovém kódu a nemuset šířit své zdrojáky považuji za obrovské plus.
Souhlasím, já v současné době také nevidím důvod, proč používat Javu na AWS Lambda. Snad s jedinou výjimkou – už bych měl kód napsaný a jenom bych ho potřeboval spouštět pod Lambdou. Ale už i to dneska jde a před rokem by to bylo nemyslitelné.

Věřím tomu, že i tady se pozice Javy ještě zlepší. Ideální by bylo, kdyby Amazon začal v Lambdě Javu podporovat nativně – tj. měl by už nastartované JVM, ve kterých by se jen spouštěly příslušné lambdy.

Jinak pokud máte jeden menší projekt a programátory, kteří znají Python nebo Go, nedává smysl psát to v Javě. Výhoda Javy je tom velkém ekosystému – ať si vymyslíte cokoli, pro Javu na to najdete minimálně jednu, ale spíš víc knihoven. Python je na tom v tomhle směru také docela dobře, ale Go je prostě příliš mladé a těch knihoven je malinko. Další výhoda toho ekosystému je to, že má široký záběr, můžete psát od velkých monolitů (když nějaký máte, ve kterém je hromada kódu, který musíte dál podporovat) až po mikroslužby nebo teď už i Lambdy (i když to zatím není ideální). Opět – pokud budete psát jeden malý projekt, neoceníte to.

13
Vývoj / Re:Doporučte programovací jazyk pro Windows
« kdy: 22. 03. 2020, 22:10:16 »
To už mi došlo. Nejdřív mi mazali med kolem huby jak je Java jednodušší než Python a nakonec jsem zjistil, že dokud to všechno nezbuilduju, nenainstuluji Maveny a nenaprogramuji aktualizaci aws-sdk-java, tak mi našeptávání nepojede ani náhodou.  :)
Buildovat knihovny opravdu nemusíte. Ve světě Javy si sám buildujete knihovnu jedině v případě, že na ní potřebujete aplikovat nějaký hotfix.

IntelliJ Idea má v sobě i JDK i Maven, takže kromě IntelliJ Idea už nic dalšího instalovat nemusíte :-)

Stejně tak nemusíte programovat aktualizaci AWS SDK – předpokládám, že tam nedělají zpětně nekompatibilní změny, že jenom rozšiřují API. Takže prostě použijete aktuální verzi, a povýšit na novou verzi můžete v okamžiku, až budete potřebovat nějaké novější API, které ve vaší verzi není, nebo prostě jednou za čas, třeba až budete připravovat nový vývojový cyklus vaší aplikace. To naprogramování automatické aktualizace jsem uváděl jako příklad, co se také dá řešit. Ale AWS SDK je těmi každodenními releasy výjimečné, takže je logické, že zrovna na tohle není ekosystém Javy optimalizovaný.

14
Vývoj / Re:Doporučte programovací jazyk pro Windows
« kdy: 22. 03. 2020, 19:01:45 »
V tom případě to lepší než pip nebude pokud bych měl dependencies rešit ručně. Dobře, takže za použítí Mavenu/Gradlu nebo nějakého Java IDE musím zkompilovat zdrojáky AWS-SDK-JAVA a vytvořit jarko a to naimportuju do mého projektu. To chápu.
Nikoli. Máte váš Javovský projekt založený na Gradle (nebo Mavenu,když se chcete trápit :-). Do otoh projektu si přidáte závislost na AWS SDK – jak na to máte popsané na té odkazované stránce https://docs.aws.amazon.com/sdk-for-java/v2/developer-guide/setup-install.html#include-sdk Zajímá vás jen ten krátký odstavec s výběrem mezi Maven a Gradle. Ta část „Compiling the SDK“ už se vás netýká, ta je pro případ, kdy byste SDK chtěl kompilovat ze zdrojáků.

Přidáním té závislosti do Gradle nebo Mavenu se stáhne příslušné JARko (přeložený Java kód)z Maven repository, stejně tak se stáhnou případné závislosti. IDE si to JARko proleze, zaindexuje a na základě toho pak napovídá. Nápověda může být zkompilovaná v samostatném JARku, pokud je k dispozici, IE si ho stáhne také a pak vám přímo v IDE může zobrazovat i tu nápovědu. To je ale nad rámec našeptávání – je to člověkem psaná dokumentace metod, parametrů apod.

Takže o našeptávání se bude starat přímo to zkompilované jarko, které si nějak poradí s těmi JSON soubory (které popisují operace, které daná AWS služba podporuje)?
V tom statickém JARku už jsou nadefinované třídy, které můžete použít – podle nich IDE napovídá. O převod z JSON souborů do těch tříd už se musel postarat autor toho JARka.

Takže mně bude našeptávání fungovat, až když pomocí mavenu vybuildím dokumentaci? Jsem zmaten :o
Našeptávání funguje rovnou na základě kódu (ať zdrojového nebo zkompilovaného v class souborech).

Uff, tam je potřeba programovat i ruční aktualizaci AWS SDK? Tam není nějaký jednoduchý příkaz jako v pip, např. "maven/gradl -upgrade aws-sdk-java"?
Takovýhle příkaz tam není. Rozdíl je totiž v tom, že v případě pipu si stáhnete ten balíček lokálně a dál pracujete s ním. A to pip -upgrade vám prostě přepíše ty soubory na souborovém systému. Maven i Gradle ale fungují tak, že jenom řeknete, jaký balíček se má používat – a zbytek už je starost buildovacího systému (případně IDE). On to nakonec také stáhne někam na disk, ale to se děje na pozadí. Hlavně ale ta deklarace závislosti nemusí být tak jednoduchá – může být podmíněná, nemusí tam být uvedená verze natvrdo ale nepřímo třeba pomocí proměnné. Takže příkaz pro aktualizaci závislosti by často nevěděl, co má kde upravit, aby se ve výsledku změnila ta verze závislosti.

On to ale většinou nebývá problém, vydávání nové verze každý den je specialita Amazonu…

Maven i Gradle jsou v tomhle flexibilnější, nemožnost udělat takhle jednoduše upgrade je daň za tu flexibilitu. Třeba můžete mít firemní bezpečnostní tým, který bude nové verze knihoven auditovat. Tím pádem nebude chtít brát nové verze z internetu, ale z toho auditu. Maven i Gradle vám to umožní. V Gradle napíšete skript na pár řádek, v Mavenu vytáhnete čísla verzí do nějakého externího souboru, který budete aktualizovat něčím jiným, než Mavenem (nebo do Mavenu napíšete plugin).

Je to example pro sqs, ale co kdybych chtěl používat jinou službu (sns, s3, ...). To musím pokaždé ručně upravovat <dependencies> v souboru pom.xml?
Ano. Ale IntelliJ Idea k tomu zase hezky napovídá, případně když chcete použít třídu z balíčku, který nemáte v závislostech, sama nabídne to přidání do závislostí. Je to stejné, jako kdybyste upravoval packages.json pro NPM. Osobně mi ta editace souboru připadá lepší, než přidávat závislosti přes příkazovou řádku – v tom souboru rovnou vidím, jaké další závislosti tam mám, takže třeba rovnou vidím, že už tam mám jinou knihovnu ze stejného projektu, tak se postarám o to, abych je měl ve stejných verzích.

15
Vývoj / Re:Doporučte programovací jazyk pro Windows
« kdy: 22. 03. 2020, 18:05:31 »
Dyt to muzete taky v Mavenu:

<version>[1.0,2.0)</version>
Vam bude automaticky dava posledni verzi pro 1.*
Problém je v tom automaticky.

Pokud vam pada build v CI toolu, tak sorry ale to neznamena, ze budete neco programovat v Mavenu. To mate blbe nakonfigurovany ten vas tool. CI uz jsem konfiguroval nekolik a pokazde je na vine spatna konfigurace CI, rozhodne za to nemuze Maven - v pomku nechci mit ani jednu jedinou malou zminku ohledne CI.
Já zmínku o CI nechci mít vůbec nikde. CI je pro mne nástroj, který automaticky spouští úlohy buildu. Pokud musím nějak konfigurovat CI, asi mám špatný buildovací nástroj.

ted uz i chapu, proc chcete do buildu davat neco z VCS - vy mate totiz zblastlene to vase CI. Rozumna CI pipeline umi ukazat, jaky commit se zrovna buildi. To je vas problem, ze to chcete programovat sam.
Já jsem nepsal nic o zobrazování v CI. Chci mít číslo verze a číslo commitu v sestavené aplikaci, aby to uměla zobrazit ta aplikace.

Vsak to rikam - to raci prejdu rovnou na Python nez Gradle.
Už chápu ten vaše hate na Python. Vy jste se prostě něco naučil používat, a teď nenávidíte cokoli jiného, bez ohledu na skutečné kvality toho nástroje. Takže se držíte svého Springu a Mavenu a vše ostatní je špatně. Co na tom, že Gradle převzal z Mavenu vše dobré a poučil se z jeho chyb, takže je ve výsledku mnohem lepší? Jenom takovou prkotinu, jako spouštěcí wrapper, nemohl Maven vymyslet za tu spoustu let, co existuje, a teprve když s tím přišlo Gradle, najendou se to brzy objevilo i v Mavenu.

Kdyz uz se da zprasit kde co a nema to byt kriterium, tak proc vlastne vubec delat neco v Jave?
Gradle vás nenutí prasit. Naopak vás k prasení nutí Maven, protože vám dává do rukou tak slabé nástroje, že vám nezbývá, než jeho nedostatky nejrůznějším způsobem obcházet. A jakmile něco musíte obcházet, nezbývá vám, než prasit. Kdyby Maven jenom popisoval strukturu projektu, což byla původní idea, asi by vyhovoval a jeho deklarativní povaha by byla výhodou. Ale když má fungovat i jako buildovací nástroj, je prostě slabý.

Jestli se budeme zbavovat veci, protoze jsou "zastarale", a nahrazovat je vecma, ktere nic lepsiho neprinasi, tak to muzu rovnou prejit na Javascript s Node.js.
Já se zbavuju věcí, které považuju za nefunkční, když se místo nich objeví náhrada, která funguje lépe. Což je i případ Mavenu a Gradle. Maven jsem za nefunkční považoval hodně dlouho – myšlenka deklarativního popisu projektu byla skvělá, ale sám Maven jí bohužel opustil velmi brzy, ani obyčejný javovský projekt s jednou třídou nejde pomocí deklarace v Mavenu popsat kompletně. Takže pak nastupují pluginy, které ve skutečnosti od deklarace (co má být výsledkem) ustupují zpět k příkazům (jak se toho má docílit), ovšem pořád se tváří, že je to deklarativní a zapisuje se to v XML. A to prostě nefunguje. Autoři Gradlu si správně uvědomili, že každý build je jiný a je pro to potřeba dát do ruky vývojářům plnohodnotný programovací jazyk, zároveň to ale díky Groovy DSL dokázali nádherně propojit s deklarativním zápisem. Takže když se vejdete do nějakých standardních šablon, používáte deklarativní popis projektu, ale jakmile potřebujete vybočit mimo (což dříve nebo později potřebuje každý), nic vám nebrání. Dokonce ani nemusíte nic měnit, jenom se na ten původní deklarativní zápis začnete dívat jako na příkazy. Už jenom tohle propojení deklarativního a imperativního přístupu je geniální. Že prostě do toho seznamu závislostí kdykoli můžu přidat if a do něj jakoukoli podmínku chci.

Stran: [1] 2 3 ... 245

reklama