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 - Kamil Podlešák

Stran: 1 2 [3] 4 5 ... 13
31
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).

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

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

34
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í.

35
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í"

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

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

38
Software / Re:Nahradenie hex stringu
« kdy: 10. 03. 2019, 12:17:01 »
Tu mas Go verziu(2mb), ale moc som to netestoval takze za nic nerucim.
Při zběžném pohledu se mi zdá, že to bude fungovat korektně jen pokud je v hledaném řetězci každý byte unikátní.

39
Software / Re:Nahradenie hex stringu
« kdy: 10. 03. 2019, 12:11:16 »
mmap verze, python 3

Kód: [Vybrat]
#!/usr/bin/env python3
# vim:ts=4 sw=4:

import sys
import os
import mmap

if len(sys.argv) < 4:
    print("Usage: "+sys.argv[0]+" file searchHex replaceHex")
    sys.exit(-1)

(repl_from, repl_to) = [bytearray.fromhex(h) for h in sys.argv[2:4]]
repl_len = len(repl_from)
if repl_len != len(repl_to):
    print("Error: search and replacement strings have different lengths")
    sys.exit(-2)
filename=sys.argv[1]

with open(filename, "r+b") as f:
    map = mmap.mmap(f.fileno(), 0)
    idx = 0
    while True:
        idx=map.find(repl_from, idx)
        if idx<0:
            break;
        map.seek(idx)
        map.write(repl_to)
        idx += repl_len
    map.close()

40
Vývoj / Re:Viděli už jste někde distribuované transakce?
« kdy: 20. 02. 2019, 18:59:45 »
Databazim to muze byt uplne fuk, ty jsou jak jsou.
tvl, tak uz chapem preco niektore statne systemy u nas funguju ako funguju. Znizit DB na uroven sady tabuliek....
Ne, DB to samozřejmě nemůže být fuk - musí se použít API pro dvoufázový commit (a DB engine musí takové API mít, samozřejmě).

Typické použití je, že se transakce provádí na dvou (třech, i více) databázích současně - přičemž se jedná o různé db ale třeba i různé db engine a i nějaký ne-db systém (typicky MQ). Takže třeba DB2+postgresql+IBM MQ.

Ano, viděl jsem to (tedy konkrétně kombinace DB2+IBMMQ+WebSphere a DB2+Postgresql+ActiveMQ+JBoss/WildFly). Je to pěkná věcička pro programátory, ale naprostá noční můra pro administrátory.

41
Vývoj / Re:Co si myslíte o OOP?
« kdy: 13. 01. 2019, 09:46:09 »
Akorát pohlaví (u lidí) jsou dvě. Tzv. "gender" je něco jiného. To jen taková technická :)
Ještě přesněji, pojem "pohlaví" postupně ztrácí svůj někdejší čistě vnějškový biologický význam (má pindíka/nemá pindíka).
...
Nebo možná to poučení z té anekdoty s IP ve stringu je v tom, že bysme do labelu takové položky neměli psát "pohlaví", ale "co máte v občance v položce >pohlaví<?", nevím.
Vy chcete překonat stávající rekord počtu příspěvků?

Nicméně k tématu: "gender" se lépe než "pohlaví" přeloží jako "rod". I když ani to není úplně ono... ale už to naznačuje na co se zaměřit u datového modelování.

K čemu vlastně potřebuji "pohlaví" nebo "rod" ve formuláři? Opravdu danou aplikaci zajímá jaký má dotyčný primární pohlavní orgán? Nebo jaké má chromozómy? Někdy ano. Ale troufám si říci že ve většině případů je zajímavý mluvnický rod pro skloňování (zvlášť v češtině, kde existuje vokativ). V takovém případě je lepší místo "pohlaví" mít kolonku "oslovení" s výběrem (pan, paní, slečna, doktor, etc) který mluvnický rod i správně implikuje. Dokážu si ale představit i aplikaci kde se používají "přezdívky" a pak je zcela na místě mít všechny tři rody které v českém jazyce existují.

Ještě bych se ale vrátil k tomu telefonu, který zde byl zmíněn. Doufám že nikoho snad opravdu nenapadne telefon ukládat jako integer nebo float!! A i když je k dispozici datový typ s neomezenou přesností (v dekadické soustavě), tak typicky nepodporuje významné nuly na začátku! A počet číslic také není úplně jasný, u mezinárodních čísel... A to všechno má stejně smysl zase podle aplikace: někdy je telefon použitý pro vytáčení, pak se samozřejmě číslo musí validovat. Ale pokud jsou to jenom kontaktní údaje někde zobrazené pro lidi, pak je lepší nechat telefon jako volný řetězec. Umožní to lidem zapsat speciality jako "klapka", rozsah čísel, nebo třeba "jen 9-12h". Samozřejmě, je to kompromis hodně směrem k uživatelům a nevhodný pro stroje :-)


42
Vývoj / Re:Proč se v Javě XML nahrazuje YML?
« kdy: 15. 11. 2018, 08:06:17 »
Povodne urcenie XML nie su textove dokumenty!
Je to strojovo aj ludsky citatelny format. Bol urceny na to aby ho citali stroje aj ludia.
Tak nevím, nějak tomu nerozumím... Má to druhého tvrzení (tj. XML je čitelný strojově i lidsky) nějak plynout podpora pro to první (tj. XML není původně určený pro textové dokumenty)?

Protože já tam žádný rozpor nevidím - XML je formát pro značkování textů čitelný pro stroje i dokumenty.

Možná by chtělo specifikovat, co jsou "textové dokumenty". Někdo si pod tím pojmem představuje dokumenty z Wordu...
No, dobře, ale to snad... no tak raději se zeptám, než budu soudit :-)

Plus: dokumenty z Wordu skutečně jsou (už nějakou řádku let) ukládány v XML :-)

43
Vývoj / Re:Proč se v Javě XML nahrazuje YML?
« kdy: 14. 11. 2018, 20:37:15 »
Povodne urcenie XML nie su textove dokumenty!
Je to strojovo aj ludsky citatelny format. Bol urceny na to aby ho citali stroje aj ludia.
Tak nevím, nějak tomu nerozumím... Má to druhého tvrzení (tj. XML je čitelný strojově i lidsky) nějak plynout podpora pro to první (tj. XML není původně určený pro textové dokumenty)?

Protože já tam žádný rozpor nevidím - XML je formát pro značkování textů čitelný pro stroje i dokumenty.

44
Vývoj / Re:Proč se v Javě XML nahrazuje YML?
« kdy: 13. 11. 2018, 19:29:27 »
...XML je "značkovací" (markup) formát, primárně určený pro text...
Ehm nikoli, xml je format urceny primarne pro data, s textem to nema temer vubec nic spolecneho.
Ehm nikoli, každý Markup Language je (z definice) určen pro text. Přesněji řečeno textová data, takže ano, je primárně pro data :-)

Ale asi bych měl dodat: nemám nic proti konfiguraci v XML, naopak. Ale YAML je pořád mnohem lepší než JSON nebo INI. 


45
Vývoj / Re:Proč se v Javě XML nahrazuje YML?
« kdy: 13. 11. 2018, 08:10:57 »
YAML získává na oblíbenosti, protože je to kompromis. Obsahuje totiž věci, které v JSON zoufale chybí a činí ho velmi nepraktickým pro konfigurační soubory - komentáře a víceřádkové texty (na více řádkách, samozřejmě).
Má samozřejmě i další feature, ale ty se moc nepoužívají (např. tagy jsem v praxi nikde neviděl) - právě z toho důvodu, že se používá jako náhrada za JSON.

Porovnání s XML je trochu mimo - XML je "značkovací" (markup) formát, primárně určený pro text jehož části jsou nějak označeny (takže třeba XHTML). Použití pro konfigurační soubory je méně praktické jak pro lidi, tak pro zpracování v programu. Samozřejmě, zvykli jsme si (koneckonců, pořád lepší než ini soubor).

Stran: 1 2 [3] 4 5 ... 13