Příspěvky

31

Vývoj / Re:Maven vs. Gradle

« kdy: 29. 11. 2020, 12:40:15 »

Kritérium je, myslím, poměrně zřejmé: budete skutečně vyvíjet nějaký buildscript? Budete skutečně potřebovat něco, na co není standardní (a dobře fungující) maven plugin?

Pokud ano, tak je volba jasná - gradle. Psát si vlastní maven plugin je většinou overkill a pokusy o psaní scriptů v pom.xml jsou jasným znakem začátečníků a šílenců.

Pokud ne, tak přichází do hry další aspekty - co kdo zná (a na co je zvyklý), jaké další nástroje se používají - především IDE a CI. Pokud někteří z těch lidí používají "alternativní" IDE (tj. ne Idea) a pokud buildserver nemá dobrý plugin pro gradle (ale má pro maven), tak budete X let řešit brblání, žbrblání a nadávání na "frikulíny" a jejich "kurvítka" (další termíny naleznete na dfens-cz.com).

Jo a rozhodně varuji před argumentem "xml je fuj", to je nejlepší způsob jak se zdiskreditovat.

32

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 06. 10. 2019, 15:31:14 »

INNER JOIN bejvá výkonnější, ale dneska si to databáze stejně zoptimalizujou.

Udělal jsem na to schválně test (na PostgreSQL). Podle očekávání ve všech třech případech si to SQL zoptimalizovalo na tutéž náročnost:

Sorry že se do toho pletu, ale

• Dotaz explicitně specifikoval MySQL, kde to může dopadnout jinak (a nejspíš dopadne, viz bod dva).
• Uvedené výsledky nevypovídají naprosto nic o tom jak se "dotaz zoptimalizuje", protože explain byl proveden na pididatabázi s tak malým počtem řádků, že z toho postgres prostě udělá 2x full scan + nljoin. Což je charakteristická vlastnost postgresu.

33

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 05. 10. 2019, 19:04:00 »

ale da sa aj subselect:

Ale fuj, to bude mnohem pomalejší. Na tento příklad je jediným správným řešením LEFT JOIN + WHERE.

Pro každý solidní optimizér je to jedno, výsledný query plan je stejný. Samozřejmě, ne každá databáze má solidní optimizér, takže LEFT JOIN je rozhodně jistější.

34

Studium a uplatnění / Re:Práce v zahraničí - vyplatí se?

« kdy: 14. 08. 2019, 07:58:43 »

Jo, teď na to koukám, s těmi platy je asi blbost koukat se na GlassDoor, teď jsem si projel nabídky, a reálně se to pohybuje 80.000-90.000 eur.

Tzn. cca. 5.000 eur čistého.

Jak jsi k tomu číslu došel? Najdi si nějakou kalkulačku online.
Pokud jsi svobodný, tak 80000 ročně hrubého je asi tři a půl měsíčně čistého. S 90000 --> 4000!
Ono to reálně bude trochu víc (odečitatelné položky, různé spolkové země), zvlášť když si dáš něco do nákladů (to v Německu může i zaměstnanec), ale rozhodně nepočítej že se dostaneš na 5k.

Možná ženatý s N dětma, ale pak je asi hlavní otázka kde a za kolik bude pracovat manželka a jak drahé máš děti :-)

- 1.500 eur byt
- 25x30 obědy = 750 eur
- zbylé jídlo = 15*30 = 450 eur

Pro kolik je to lidí? 1500 EUR pro jednoho je moc i na Mnichov, pro čtyřčlennou rodinu je to tak tak :-(
25 za oběd totéž - pro jednoho člověka naprostá rozmařilost (hochnóbl restaurace v turistické zóně), pro 4 málo.

35

Vývoj / Re:Jak mam programovat v Node.js?

« kdy: 24. 05. 2019, 23:36:03 »

Přidám se k ostatním:

• začni s TypeScriptem, tam si můžeš datové typy definovat co hrdlo ráčí a samotný kód je přitom v podstatě přímo samotný Javascript (na rozdíl od některých víc "fancy" transpilovaných jazyků)
• vyhýbej se třídám a používej interface - a to především u datových struktur, protože na rozdíl od Javy má v TypeScriptu interface fieldy a dá se vytvořit přímo, bez implementující třídy

Myslím že to do začátku stačí, za chvíli přestaneš chtít psát Javovský kód

36

Server / Re:PHP SQL problem s SELECT a OR

« kdy: 09. 05. 2019, 07:58:47 »

Dakujem spravna odpoved. Inak ten select je az za osetrenim SQL Injection.

Doporučuju rovnou se to naučit dělat správně pomocí bindování parametrů. „Ošetření SQL injection“ je jenom hack, který nemusí vždy fungovat správně, snadno se na něj zapomene a jenom zbytečně komplikuje kód. Ostatně je to vidět i na tomhle dotazu – vypadá to, že tam SQL injection je, vy ostatní ubezpečujete, že někde před tím kódem snad je nějaké ošetření. Což je přesně to, co udělá další programátor, až ten kód uvidí (nebo vy, až se k němu vrátíte po nějaké době) – budete doufat, že někde před tím je „ošetření“. A pak vám jednoho dne útočník ukáže, že tam nebylo.

S tím vším se dá jen souhlasit, má to ale jeden praktický háček: v tomto konkrétním případě se nepoužívá hodnota přímo, ale odvozený řetězec (jsou tam přidaná procenta na začátek a konec).

Takže jedině něco jako:

Kód: [Vybrat]

SELECT * FROM users WHERE firstname  LIKE '%'||?||'%' OR lastname LIKE '%'||?||'%'

V každém případě: tento dotaz vždy a v každé databázi dělá FULL TABLE SCAN! Takže pokud tam někdy bude netriviální množství uživatelů, tak se databáze utaví. Na druhou stranu, pravděpodobnost je asi malá :-)

37

Vývoj / Re:Je Swagger utter crap?

« kdy: 07. 04. 2019, 19:46:57 »

...

Takže, abych to shrnul - vy vlastně ani WS/SOAP nepoužíváte. Vy jenom používáte podmnožinu konkrétní implementace v Javě pro "homemade" RPC.

No, v podstatě proč ne. Když vám to funguje, tak na tom není nic špatného. Výhody jsou jasné - do životopisu a powerpoint slajdů pro management si dáte spoustu pěkných zkratek a přitom se nemusíte skutečně zabývat radostmi standardu vyprodukovaného komisí složenou z těch nejbyrokratičtějších korporací v oboru.

JSON se da validovat oproti XSD

Jo, a v Sovětském Svazu rozdojili kozla...

38

Vývoj / Re:Je Swagger utter crap?

« kdy: 07. 04. 2019, 09:52:21 »

Zaprve, kdyz se to WSDL vygeneruje automaticky na zaklade XSD schematu, tak by si s tim snad melo poradit PHP pri generovani clienta.

Mělo. Podmiňovací způsob je na místě.

Co mě ale zaráží víc, je (opakované) tvrzení že WSDL se generuje automaticky na základě XSD schématu. Což je naprostý nesmysl - WSDL obsahuje XSD pro definici typů, ale obsahuje i spoustu dalších informací které v XSD nejsou. Viděl jsi WSDL vůbec někdy?

A to ani nemluvím o WSDL 1.1, které se pokud vím stále ještě leckde vyskytuje.

Zadruhe kdyz si s tim neporadi, tak je to uplne jedno, protoze jako predloha stejne slouzi to XSD schema - to je v podstate primarni human readble API te aplikace - a s tim uz si snad musi poradit PHP nebo programator, aby si na zaklade schematu udelal request. Zatreti, kdyz si ani s timto neporadi, tak at de dozadeke, radeji nekde na salas past ovce.

Ano, tak to také dopadne. A pak si někdo vzpomene, že se použije pro WS-Security pro zabezpečení...

Omg co to zas je za kec, jake tuny sracek, posilas jen XMLko s daty, oproti XSD schematu se to jen validuje. Muzes to poslat i jako JSON.

SOAP přes JSON? Tak to jsem ještě neslyšel. Což se může stát, novinky nesleduji, možná komise vytvořila nové monstrum, nebylo by to poprvé. Na druhou stranu, uvážím-li kvalitu ostatních informací, může to být jen blábol.

Takže: Můžeš sem dát odkaz na specifikaci?

39

Vývoj / Re:GIT server - nasazení kódu do produkce

« kdy: 04. 04. 2019, 19:28:49 »

@to_je_jedno: no priznam se bez muceni ze tomu co jsi napsal nerozumim, tusim ale nerozumim. nicmene zeptam se jeste jinak: docker v ostrem produkcnim prostredi? byl jsem na tom ze docker je spis urceny pro vyvoj a mozne rychle testovani, ale ne na produkcni intranet server ve vyrobe ktera jede 24/7 a je na intranetu zavisla. doporucis i v tomto pripade docker?

Docker se samozřejmě normálně produkčně používá - používat ho jen na vývoj a testování je absurdní představa, základní smysl dockeru spočívá v tom že v produkci běží přesně totéž co se testovalo.

Na druhou stranu ale platí to co tu padlo - pokud jste o dockeru slyšeli jen z doslechu, tak si při hurá-nasazení do produkce nabijete hubu. Ale to snad není nic specifického pro docker, že.

Pokud nechcete předem investovat do vyrábění balíčků (ať už docker nebo deb/rpm), tak klidně můžete mít v gitlab CI script který aplikaci nahraje na server třeba přes ssh/rsync (o ftp bych fakt ani neuvažoval). Pro začátek to bude naprosto stačit, a časem snad budete mít lepší představu co a jak. Gitlab CI je dobře vybaven a jde i zajistit, aby do produkce neměl právo nasazovat každý vývojář (i když je to trochu komplikovanější - bude potřeba nastavit práva na větve a dobře odladit .gitlab-ci.yml).

40

Vývoj / Re:Je Swagger utter crap?

« kdy: 04. 04. 2019, 19:15:13 »

Vse co popisuju jsem realne zazil a ty systemy stale "funguji".

SOAP je v realnem pouziti prekomplikovany shit a proto taky vsechny softy co znam vystavujou API na REST nebo XML-RPC.

Přidávám se, moje zkušenosti jsou velmi podobné.

Na druhou stranu předpokládám, že přesně takhle budou vypadat korporátní systémy budované pomocí Swaggeru (podle toho co píše OP, tak mají dobře našlápnuto).

41

Vývoj / Re:Je Swagger utter crap?

« kdy: 04. 04. 2019, 08:26:56 »

SOAP zprava prenasena v HTTP je vzdycky POST - vsechny dalsi http metody jsou redundantni. V body se prenasi objekt, jehoz jmeno reprezentuje jmeno metody. Pro rozliseni ma zpravidla postfix "Request". Jeho atributy predstavuji 1:1 parametry metody. A to je v principu co se tyce RPC vsechno - nic vic neni potreba. je zde kompletni, osekana, takrka 1:1 vazba mezi SOAP zpravou a volanou metodou. To co je v REST API delanem jako Resource jsou akorat reduntantni nesmysly:
Je to uplne k nicemu, redundatni nesmysly, ktery oceni tak leda programatory typu impresionisticky umelec, ktery se minul povolanim.

Sorry, ale zase mimo. Když pomineme to že jsou i jiné transportní možnosti než HTTP (moc se to nevidí), tak rozhodně nemůžeme vynechat dva různé styly - RPC a Document. V kombinaci s literal/ecoded to dává čtyři styly. No a pak samozřejmě haldy různých rozšíření. A to že přenos přes HTTP není úplně přesně standardizován, takže ne každé dvě implementace se domluví (ok, možná že v tomhle se situace za posledních 15 let změnila). Jo, hlavička SOAPAction, s tou byl vždy kopec srandy...

To co popisuješ je v podstatě XML-RPC, nebo gRPC, nebo některý z dalších protokolů - už jsem jich viděl víc. Ale rozhodně ne SOAP.

Neni zde zadny prostor pro impresionisticke umelce programatory, a to je vzycky dobre.

V SOAPu je hodně prostoru pro manýristické umělce programátory. To je hlavní důvod, proč se proti němu před deseti lety zvedla vlna odporu. Dnes se možná zvedná vlna odporu proti RESTu, uvidíme co bude dál.

Holt musím pověsit cibule na opasek a dát za pravdu RDa: Dneska ti mladí neznají historii...

42

Vývoj / Re:Je Swagger utter crap?

« kdy: 04. 04. 2019, 08:07:45 »

Tak asi to dělal poprvé. Možná měl dostat pro začátek menší zadání. Ale s technologií to moc nesouvisí, ne? Ani to automaticky neznamená, že by bylo UDP vhodnější.

To ho neomlouva.. zaklady sitariny a BSD socketu by mel mit.

Jistě. Všechno co udělal by udělal úplně stejně blbě s BSD sockety. Takže nanomsg je v to úplně nevinně.

Já vím že je se to dá brát jako šťourání, ale sorry - bavíme se zde o schopnosti lidí analyticky řešit problémy, a takové detaily jako správná identifikace zdroje problémů, jsou zásadní.

43

Vývoj / Re:Je Swagger utter crap?

« kdy: 03. 04. 2019, 22:02:36 »

Stejne tak, jako pro IPC komunikaci pouzije zcela nevhodne napr. nanomsg, namisto toho, aby se protokol udelal nad UDP, nebo TCP.

Ok, o nanomsg jsem dodnes neslyšel, ale podíval jsem se na https://nanomsg.org a musím se zeptat: proč je to zcela nevhodné a proč je lepší navrhnout vlastní protokol nad TCP?

Tedy kromě toho, že je to moc nové a že je "trendy" a že je to "lepení" - to já osobně nepovažuji za relevantní argumenty. Pravda, sedmdesátá léta nepamatuji, tak jsem možná jeden z těch "mladých lidí"

44

Vývoj / Re:Je Swagger utter crap?

« kdy: 03. 04. 2019, 21:53:08 »

V podstatě souhlasím s tím, že REST je vhodný jenom na některé aplikace a rozhodně je nevhodný tam, kde je potřeba RPC. OpenAPI neznám, ale swagger jsem viděl a dospěl jsem k názoru že je to k ničemu.

Nicméně by to celé to kazí ten naprosto zmatený odstavec:

Maly skok do historie. REST byl vyvinuty jako soucast HTTP v roce 1990 a je urcen pro modelovani webovych api typu Resource, tzn. webovka ma nejaky svuj backend, ze ktereho si potrebuje tahat data, zapisovat, updatovat atd. Je to neco designem dost spjateho s HTML, ktere se prenasi pres HTTP v RequestBody at uz pri GET, nebo kdyz se odesila nejaky formular, nebo co ja vim.

No, evidentně jsou u vás programátoři hodně zmateni a ti co si stěžují na rootu jsou akorát jednoocí mezi slepými :-) O správném zařazení primátů do čeledí raději nebudu spekulovat...

Dneska se za valecneho pokriku prumernych opic vyvojaru vytlacuje z backendu SOAP, nadavajic na to, jak je neflexibilni, pricemz se to nahrazuje necim tak naprosto nevhodnym, jako je Swagger api a rest. Samotny REST neni az zase tak problem, i SOAP se prenasi pres HTTP kde metoda je vzdy POST, problem je az teprve Swagger.

No já nevím, vytlačování SOAPu bylo moderní tak před deseti lety - to musí být nějaký extra konzervativní korporát, co? Podle toho co jsem viděl osobně a v Dilbertovi, tak problém je primárně tam :-)

Btw, hidopišská poznámka: SOAP rozhodně nemusí používat HTTP ani POST.

Backendove komponenty mezi sebou potrebuji delat RPC volani a ne si vzajemne sahat do Resource.

Ok, tohle si zaslouží komentář: rozhodně to neplatí všeobecně, existují aplikace kde je "šahání si do Resource" naprosto v pořádku a REST je dobře pasující architektura. Na druhou stranu, existují aplikace kde je to hovadina.

Swagger je navede na to, aby delali Resource API (vetsina ani nevi, co to je), jenze to jim v drtive vetsine pripadu nepasuje na to, co potrebuji delat, coz vsak vedome nevi, takze do toho michaji RPC az nakonec vznkne naprostgo zpackane gulas API.

Kdyz se k tomu prida zaklinadlo OpenAPI a prihodi se rvouci opico-ovce, tak z toho je dalsi jedna velka vyvojarska tragedie, ktera zase pro jednou vede k horsimu a zpackanejsimu backendu.

Clovek by rekl, ze by se mela metodologie vyvoje hybat dopredu, a ne dozadu a jeste dal.

Bohužel, naprosto normální. Pokud ti to vadí, doporučuji změnit obor. Minimálně pak změnit působiště, evidentně to stávající je zbytečně stresující.

Prohlasuju, ze kvuli Swaggeru se enteprise dostal z roku 2019 nekde do stavu vyvoje API pred rokem 2000, nez byl vymyslen SOAP. A to jsem jeste nemluvil o nahrazovani XMLek jinymi, "lepsimi" formaty.

Docela by me zajimal nazor mistnich.

SOAP nebyl první RPC (a to ani první RPC použitelné přes http) a není poslední. Existují jiné varianty, spousta z nich použitelnější, a některé dokonce použitelné v PHP (to je jeden z problémů SOAPu - pokud vím, neexistuje funkční implementace pro PHP).

45

Hardware / Re:Herní konzole - je to perfektní hardware za nízkou cenu?

« kdy: 12. 03. 2019, 21:17:52 »

Když už se tu diskutuje na téma "pirátství" PC vs konzole tak je tu ještě jeden fenomén: tzv. pvp "hacking" (správněji "cheating").

Jedná se v podstatě o klasické cracky+cheaty zajišťující výhody jako nesmrtelnost, neomezené náboje, extrémně silné zbraně a podobně (občas i nějaké kosmetické vylepšení, oblíbený je -nepřekvapivě- obří penis). No a jelikož vývojáři (zvlášť ti japonští) na nějaké serverové kontroly dlabou, tak se takoví "borci" pak pustí do souboje s poctivými hráči. Hlavně u her s asymetrickým pvp (Soulsbourne) to nepotěší.

Na konzolích tento problém není ze stejného důvodu proč není rozšířené pirátství - v podstatě neexistuje (reálně rozšířená) možnost používat neoficiální kód. Což samozřejmě je důvod, proč se vývojáři nemusí zabývat s vývojem (a provozováním) herních serverů zajišťujících herní pravidla (nebo dokonce nějaké anticheaty) - a cyklus je uzavřen.