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
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?

2
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).

3
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.

4
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.

5
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.

6
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.

7
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ý.

8
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.

9
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.

10
Vývoj / Re:Doporučte programovací jazyk pro Windows
« kdy: 22. 03. 2020, 15:41:52 »
Wtf, vzdyt to s da v mavenu udelat tak, ze se udela <version>RELEASE</version>. To je uplne typicke, presne co jsem rial s programovanim v gradlu - vy uz byste tam bastlil na to skript.
Ne, tohle dělá něco jiného. To použije vždy poslední ostrou verzi, o které Maven ví. To není dobrá cesta, protože tak se vám může aplikace klidně rozbít sama od sebe – nic nezměníte, jenom si Maven na pozadí stáhne novou verzi, se kterou vám aplikace nebude fungovat. Právě proto jsem psal o té variantě, že se to povýšení dělá skriptem, ale řízeně – v okamžiku, kdy já chci. Třeba to můžu dělat na CI každou noc – povýším knihovnu na nejnovější verzi, spustím testy, a když všechny testy proběhnou, nová verze se commitne.

Ano, samozřejmě, že bych na to napsal skript, protože se to má chovat tak, jak chci já, ne podle nějakého šíleného defaultu.

Uz jenom to, jak zminujete CI a Maven - konfigurace CI nema co delat v Mavenu, ale v tom CI toolu, ktery pouzivate, si mate vyrobit uniformni build pipeline, a ne neco davat do mavenu.
Ale já žádnou konfiguraci CI nechci mít. Já od CI chci jenom to, ať automaticky spouští úplně to samé, co si spouští vývojář u sebe. Taková ta zábava, kdy u vývojáře něco funguje a v CI to padá, nebo opačně, je dobrý způsob mrhání času, ale vývojáři myslím mohou dělat užitečnější věci.

11
Vývoj / Re:Doporučte programovací jazyk pro Windows
« kdy: 22. 03. 2020, 15:12:59 »
4. Klikni si na "Files   jar (315 KB)" a stahni si to Jarko.
Ne, to rozhodně ne. O závislosti se stará buildovací nástroj, takže se jen v konfiguraci projektu uvede, že projekt závisí na nějaké knihovně, a buildovací nástroj už se sám postará o stažení té knihovny a závislostí.

A balíčky pro Javu se nehledají Googlem, ale v repository – např. přes javalibs.com. Tam se vám i pěkně ukáže, jak závislost vložit do Mavenu nebo Gradlu (nebo jiného buildovacího nástroje).

Mimochodem, v tom Gradlu si můžete snadno naprogramovat, aby se vám závislost na tom AWS SDK povýšila skriptem (ať už na ruční postrk, nebo automaticky).

12
Vývoj / Re:Doporučte programovací jazyk pro Windows
« kdy: 22. 03. 2020, 15:06:39 »
1. Pro zakladni rozvrzeni projektu vc submodulu je Gradle 1:1 to same co Maven
2. S tim rozdilem ze Gradle neumi definovat Parenta
3. S tim rozdilem ze Gradle je mene zaboilerplatovany, jenze jaksi za cenu toho, ze clovek nema naseptavani.
4. S tim rozdilem, ze v Gradlovi se da dobre programovat - to je snad ta nejhorsi vlastnost, protoze by to nekoho mohlo napadnout delat. Co potrebujete pri buildu programovat?
Ad 1) Jenom dokud máte prázdný projekt. A vlastně už ani to není pravda, Gradle zavedl rozdělení závislostí na api a implementation, takže konečně tranzitivní závislosti dávají smysl.
Ad 2) Gradle samozřejmě parenta nadefinovat umí. A umí, cokoli chcete – je to jen kód. Takže si můžete parenta udělat, jak chcete – můžete z něj dědit, co chcete, můžete si to parametrizovat, můžete si parenty třeba přepínat, když budete chtít.
Ad 3) IntelliJ Idea v Gradle skriptech našeptávat umí.
Ad 4) To, že můžete v buildskriptu programovat, je obrovská výhoda. Potřebujete to vždy, jakmile nejde jen o nějaký školní projekt. Stačí se podívat, kolik pluginů pro Maven vzniklo. Build chcete upravovat v závislosti na prostředí, kde poběží, chcete tam integrovat informace z VCS, chcete publikovat balíčky a dokumentaci, mimifikovat a komprimovat soubory, podepisovat, a milion dalších věcí, u každého projektu jiné. Když můžete v buildskriptu programovat, nepotřebujete různé šílené CI nástroje, které „naprogramujete“ (ideálně klikáním ve webovém prohlížeči), protože jediné, co od CI potřebujete, je spustit příslušný Gradle task. A co potřebujete si naprogramujete v něm.

1. Zkousel jste si uz zbuildit ten Micronauti Lambda example na Githubu s GraalVM? Vzdyt to je hrozne, kompilace tim Graalem trva snad 3 minuty.
2. Kdyz jsem videl nejaky benchmark, tak to stejne melo pomalejsi cold start nez Node.js lambda.
3. Na takovou monolitickou lambdu rovnou muzete pouzit Spring Cloud Function - nevim jen jestli tu v budoucnu bude podporovat Graal. 
4. Ikdyz to vsechno udelate, tak budete tvorit relativne velke monoliticke lambdy a ja se ptam - proc to do haje radeji rovnou nerozjet jako service v docker kontejneru? Co tim ziskate ze to bude lambda funkce?
Ad 1) Vašemu CD nástroji to nějak vadí, stěžuje si, že mu to trvá 3 minuty?
Ad 2) No jo, jenže Node.js už má za sebou roky optimalizací rychlého startu, GraalVM je ve stavu, že už to jde nastartovat a běží to. Optimalizace teprve přijdou.
Ad 3) a 4) Pokud vytváříte „monolitickou lambdu“, je chyba ve vás, ne v nástrojích.

Výhoda je ta, že mám vše na jedné platformě. Takže můžu mít aplikaci, která se skládá z jednoho nebo více monolitů, kolem se mohou motat mikroslužby a nějaké nárazové prkotiny můžu řešit lambdou. A pořád mám jednu platformu a jeden zdrojový kód, takže můžu sdílet implementaci a přelívat ji tam, kam zrovna potřebuju. Chci vytrhnout z monolitu část a nadělat z ní mikroservisy? Jasně, není problém, nemusím nic programovat znova, jenom implementaci upravím pro jiný způsob běhu. Přestane lambda stačit? Nevadí, udělám z ní mikroservisu.

Jave tim ujel vlak a muj nazor po X hodinach googleni je, ze to jeste nedohnala.
Nemyslím si, že povědomí o současných technologiích lze získat googlením.

A pokud GraalVM nepohne pri rychlosti buildu zadeki, tak ani nedozene.
Jenže rychlost buildu do nativního kódu nikoho nezajímá. Vybral jste tu jedinou operaci, která nebrzdí nikoho důležitého – ani programátory, ani uživatele. Pro programátory je důležitá klasická kompilace do bajtkódu a start aplikace, kompilace do nativního kódu je nezajímá. A pro uživatele je důležitý běh aplikace.

Nicmene reseni b mohlo byt jine, a sice jinaci JVM. V Lambde vam je burt nejaka performance vyjma cold startu. Pomale to muze byt klidne jako python. Hlavne at se ta mrcha lina rychle nastartuje.
Ta jiná VM se jmenuje SubstrateVM a je právě součástí GraalVM. Už teď je start dost rychlý, a věřím, že se bude dál zrychlovat – protože optimalizovat ho dává smysl, na rozdíl od optimalizace rychlosti release buildu.

13
Vývoj / Re:Doporučte programovací jazyk pro Windows
« kdy: 22. 03. 2020, 13:58:51 »
Fuj, tak to radeji prejdu na Python, nez na Gradle.
Proč? Autoři Gradle pochopili, že každý trošku větší projekt si nevystačí s deklarativním popisem projektu. Maven sice neumožnil vyloženě imperativní programování v XML jako Ant, ale v Mavenu se to řeší miliony properties a profilů, takže výhoda deklarativního popisu je ta tam. A sice už se snad Maven zbavil Avalonu (alespoň pro pluginy), ale pořád je utrpení rozšířit build o nějaký kód.

Akorat musim rict, ze Jave docela dost hori koudel pokud jde o Cloud, microservices a serverless architketuru.
Co se vám nelíbí na Micronautu nebo Helidonu? Když to navíc spojíte s GraalVM… Můžete psát mikroservisy nebo lambda funkce, výkon bude už teď nejspíš lepší než u NodeJS a spol. a k dispozici máte celý ekosystém Javy. Javě v tom myslím trochu ujel vlak, ale už je zpět ve hře a má našlápnuto velice slušně.

14
Vývoj / Re:Doporučte programovací jazyk pro Windows
« kdy: 22. 03. 2020, 13:48:00 »
A je to jednodušší a rychlejší než použít botostubs?
Záleží na tom, jak je to API definováno. Pokud můžu použít nějaký nástroj, který mi definici API překlopí do modelu v daném jazyce, je to záležitost jednoho příkazu.

Nicméně jednoduchost a rychlost nejsou jediná kritéria pro vývoj. Existují i projekty, které mají delší životnost než tři měsíce, tam pak získává na vrchu kritérium udržovatelnosti.

15
Vývoj / Re:Doporučte programovací jazyk pro Windows
« kdy: 22. 03. 2020, 12:05:10 »
Tak s tim co jste napsal uplne nesouhlasim, AWS ma api definovane JSONem podobne, jako jina API jsou definovana treba XSDeckem. V Jave je to tradicni uloha na vygenerovani modelovych trid v dobe kompilace, v samostatnem maven modulu.
Nezáleží na tom, jak je to API definované, jestli WSDL, OpenAPI nebo nějak jinak. Pokud je statické, můžete si ho namodelovat v jakémkoli staticky typovaném jazyce (v dynamicky typovaných jazycích samozřejmě také). Pokud je to API dynamické, není to podle mne API – protože implicitní vlastností rozhraní je to, že se nemění. proto proti němu můžu programovat a spolehnout se, že ten můj kód bude ještě zítra s tím API fungovat. Na druhou stranu, pokud je API dynamické jenom tím, že se tam přidávají nové služby,není problém mít ho namodelované ve staticky typovaném jazyce – a když budu chtít tu novou službu využít, vytvořím si příslušný model.

Jenze pochybuju, ze v Pythonu na tento ukon maji dostatecne robustni nastroj jako je Maven a generatory.
Když se tak bijete za to, jak je ekosystém Javy moderní, doporučuju něco tak zastaralého jako Maven přestat nazývat „robustním nástrojem“ a podívat se na nástroje, které patří do roku 2020 – třeba Gradle.

Stran: [1] 2 3 ... 245

reklama