devel.cz

Komentáře

• vladislav.ladicky : Je to aj otázka čo je moderné. Jednu a tú istú aplikáciu môžem postaviť klasicky, ako serverom generovanú MVC apku, alebo siahnem po modernejšej architektúre a postavím ju ako SPA plus backend ako REST API a zistím, že mi to zabralo polovičný čas, lebo naprosto separovaný frontend kód od backendového kódu sa ďaleko prehľadnejšie píše či udržuje. A presne to sa aj v praxi stalo. Java plus Vaadin vs. Vue SPA plus Java na REST API. — 26.4.2019
• harrison314 : @vladislav.ladicky : to ze to zabralo o polovicu kratsi cas je subjektivne — 26.4.2019
• Taco : @vladislav.ladicky: Jak víš, že ti to zabralo polovičný čas? — 26.4.2019
• Mlocik97 : @harrison314 subjektívne áno, ale viac lidí by "hlasovalo" že vladislav má pravdu než že nemá... takže neco na tom i bude. — 26.4.2019
• Taco : @Mlocik97: Teď zrovna pracujem v týmu, kde kolegové sice ví, co je to AJAX, ale co je to MVC ne. A tak tam ty elementy frkaj jak jim to upadne od pazoury. Já teda hlasuju proti. Buď je to dobrý nápad, nebo to není dobrý nápad. Modernost v tom nehraje žádnou roli. — 26.4.2019
• vladislav.ladicky : Z praxe. Ten polovičný čas je vyjadrenie daného developera na základe odhadu na základe x ročnej praxe na obdobných projektoch. Čiže je to vyjadrenie človeka ktorý vie, čo hovorí. A pozor, nie jedného. Rovnako iný Java developer, z big projektov z Telekomu, už pri všetkých nových projektoch automaticky siaha po Vue a Java už len ako API, lebo mu to tiež prináša výraznú úsporu času. — 26.4.2019
• siq : @Taco: Ok, tak ty by si hlasoval proti, pretoze tvoji programatori su technologicky zaostali. Ako by si ale hlasoval, keby tvoji programatori oba koncepty zvladali priblizne na tej istej urovni? — 26.4.2019
• vladislav.ladicky : Hlasuješ proti kvôli neschopným programátorom? Ok, tiež možnosť. — 26.4.2019
• harrison314 : Zalezi aj od Backend technologie, pre mna znamena SPA apka dve vstvy navyse. A to ze niekto automaticky siaha po Vue ci comkolvek inom je blbost uz principu, na takych ludi by som sa neodvolaval. — 26.4.2019
• vladislav.ladicky : Ja odvolával, lebo nejde o Vue. Ide o architektúru. Loose coupled architektúra, frontend naprosto nezávisle vyvíjaný od backendu, je proste prehľadnejšia. Navyše aj škálovateľnejšia. Škálovať tight coupled MVC apku je naprostá tragédia, oproti škálovaniu restového api. Navyše mám automaticky viackanálový prístup. K MVC apke nedorobíš mobilnú. K mobilnej musíš následne naprogramovať API. Takto si na to rovno pripravený. Hovorím z praxe, že ľudia čo raz siahli po loose coupled architektúre, sa už tight coupled riešeniu s nejakým mvc frameworkom vyhýbajú. Je to prácnejší a v konečnom dôsledku drahší vývoj. — 26.4.2019
• harrison314 : @vladislav.ladicky: Skalovat MVC nie je ziaden problem, je to uplne rovnake ako sklaovanie API a to hovorim z praxe. loose coupled nie je strieborna gulka. — 26.4.2019
• vladislav.ladicky : Nie je, ale vyriešiť škálovateľnosť restového api postaveného nad mikroservismi nejde jednoduchosťou porovnávať so škálovaním akejkoľvek tight coupled mvc apky. — 26.4.2019
• harrison314 : @vladislav.ladicky: Microservisi su kapitola sama o sebe. Len skoda, ze mi nik predtym nepovedal, ze sa skalovatelne MVC apky robit nedaju, robim ich uz 4 roky, porpi inych veiach. — 26.4.2019
• vladislav.ladicky : Upresním to... Pri tight coupled architektúre musíš škálovať celú aplikáciu naraz. Kde je úzke hrdlo? Len v tomto, že vďaka AdWords kampani ľudia často otvárajú úvodnú stránku? Ako to naškáluješ? No tak, že naškáluješ celú aplikáciu naraz. Nech už bude úzkym hrdlom ktorákoľvek stránka či ktorýkoľvek mountpoint, musíš to škálovať ako celok. Pri loose coupled architektúre ideš ďaleko cielenejšie, ďaleko efektívnejšie. Otvára sa často úvodná stránka? Asi to ani len nebude problém, lebo bude zavesená na nejakej CDN. Ale ak aj, ok. V ktorom regióne? Posilníme ho. A backend? Ktorý konkrétne mountpoint je príliš vyťažený? Posilníme ho ďalšou inštanciou s daným mikroservisom. Alebo ... načo tieto problémy? Zrušme vlastný server preklopme API na serverless infraštruktúru nech sa to škáluje samo... Takto jednoducho či slobodne proste nemôžeš uvažovať pri pevne oreviazanej architektúre... — 26.4.2019
• vladislav.ladicky : Ale iste, že dajú. Ja som ani nepovedal, že nie. To len zle čítaš. Ja hovorím, že výsledný kód je ďaleko prehľadnejší, jednoduchšie udržiavateľný a potažmo menej nákladný na tvorbu a udržiavanie. — 26.4.2019
• Taco : @siq: Nehlasoval bych. Šel bych s nima na pivo, a tahal z nich know-how. — 27.4.2019
• harrison314 : @vladislav.ladicky: Zalezi od poziadaviek, tymto do toho vnasas len dlasiu komplexitu a vysledne nasadnie uz zavisi na viac provoderoch. Z monilitu, pokial nie je sprasneny tiez nie je problem vynat a balnsovat, tiez vyrane pomaha cache. A to co spominas sa hodi, ked mas projekt polovicnej velkost Facebooku, no takych vela nie je. Dalej su aj ine sposoby ako dosiahnutvelku skalovatelnost a perfomace, napriklad JAM stack, Kestrel ti obsluzi stotisice requestov na server rendering za sekundu v jednej instacii na podprimerenom serveri... — 27.4.2019
• harrison314 : @vladislav.ladicky: Ty necitas, ja netvrdim, ze SPA je zle, ja tvrdimze pouzivat automaticky SPA na vsteko je prinicipalna blbost, ignorujes tym poziadavky na aplikaciu, udrzbu, vnasas do projektu tisice kniznic tretich stran, ktore casto idu len v Chrome. Aj SPA maju svoje nevyhody, ktore ignorujes. — 27.4.2019
• vladislav.ladicky : Ako tým ignorujem požiadavky na údržbu? A aé tisíce knižníc tretích strán? Kde na tie argumenty chodíš? — 27.4.2019
• harrison314 : sem https://npm.anvaka.com/#/ — 27.4.2019
• harrison314 : Plus o tom uz diskusia prebehla aj tu https://www.facebook.com/groups/vyvojari/permalink/2509513839123568/ — 27.4.2019
• vladislav.ladicky : Bez toho aby som sa pozrel do predošlých diskusií ... dáva ti logiku, že sa spa apka horšie udržuje ako serverom generovaná? — 27.4.2019
• Mlocik97 : @harrison moje SPA/PWA programujem tak že u desiatkach projektov som vždy využil maximálne zo 5 "technologií" - 2-3 knižnice, 1 framework (Buď Angular alebo Vue) s 2-3 modulmi na frontende, na backende mám len nejaký express alebo Meteor, často backend mám aj bez závislostí, tzv. využívam len holý node. js s built-in modulmi. Pripadne používam Golang s Revel. — 27.4.2019
• Taco : Zopakujem: SPA nemůžeš porovnávat s MVC serverově renderovanou aplikací. Jednak SPA je samozřejmě taky MVC. A druhak ten rozdíl je v tom, ze vytváříš defakto aplikaci architekturou podobnou klasické desktopové appce. Což není nutně špatně. Ale v mnoha případech to není to co chceš. Což je ten problém. Nemůžeš SPA zvolit jen z důvodů, že se ti v tom dobře píše. Tyto dvě architektury nejsou zaměnitelné. — 27.4.2019
• vladislav.ladicky : Ona SPA ani nie je MVC, je to MVP (MVVM) architektúra. A áno, zvyčajne sa môžem rozhodnúť, či použijem tight, či loose coupled architektúru. Funkčnosť je rovnaká, iná je len organizácia kódu a použité nástroje. Akurát, že tá organizácia kódu sa ukazuje ako prehľadnejšia. Čo je jeden z najdôležitejších faktorov, ktorý výrazne vplýva na celkovú cenu tej aplikácie. Čo nie je môj názor, ale poznatok z praxe. — 27.4.2019
• Mlocik97 : @vladislav.ladicky SPA môže byť MVC, MVP, MVVM, MVW, HMVC, MMV, MVA alebo kľudne aj čokoľvek iné. MV* je iba spôsob jak je kód rozčlenený do častí. SPA je princíp akým sa načitávajú dáta do stránky, zatiaľ čo v prípade SPA je stránka stiahnutá celá naraz, a následne sa vymieňajú len údaje formou napr. AJAX, a nenačitáva sa zvyšok stránky, ale len zmeny v dátach, tak v prípade MPA je to zas tak že akákoľvek zmena dát vyžaduje znovunačítanie celej stránky. To s rozčlenením kódu nemá takmer nič spoločné. — 27.4.2019
• rmaslo : Samozřejmě mohu SPA udělat jako MVC (po kliku odešlu data z formu ajaxem, zpět mi přijde nová šablona stránky a data do ní a já celé HTML pomocí JS přemaluji), ale většinou se to podle mne takto nedělá. Spíš se přemalovávají části stránky a pokud by Controler měl přímo přemalovávat části stránky (bez přenosu přes stavovou informaci a spouštění View) tak to už není controler z hlediska MVC a je potřeba jej nazvat jinak. — 27.4.2019
• vladislav.ladicky : Ok, to je pravda, lenže ja som mal na mysli SPA s React, či Vue. Hoci tam môžem teoreticky použiť akýkoľvek pattern, reálne sa používa akurát tak MVVM. Resp., aby som sa vyjadroval presne, typicky sa používa MVVM. — 27.4.2019
• Taco : @rmaslo: To je omyl. SPA je sama o sobě MVC. To, že to komunikuje s nějakým serverem je implementační detail modelu. Stejně jako neřešíš, že u klasické aplikace model komunikuje s DB. — 27.4.2019
• Mlocik97 : "SPA je sama o sobě MVC." ne není — 27.4.2019
• Taco : @Mocik97: je. Samozřejmě jsem tím myslel, že SPA implementuje nějaký architektonický vzor. Třeba klasické MVC, nebo jinou variantu. Ale furt je to rozdělený na nějaké části. Je nesmysl to dávat do protikladu. — 27.4.2019
• Mlocik97 : SPA áno oddeluje aplikaci a dáta (a prípadne nejaké ďalšie medzičasti), aplikace se načíta ako celok jednou a následne sa už len so serverom vymieňajú dáta, pričom tieto dáta sa v stránke menia spôsobom že sa menia len a len tieto dáta, a zvyšok aplikácie sa znova zo serveru nenačitáva, to je pravda, avšak toto ale nemusí být dosiahnuté jen spôsobom MVC. To už som napsal v podstate hore o 15:02. Teda SPA nemusí být práve MVC. — 27.4.2019
• Taco : @Mlocik97: reagoval jsem na @rmaslo, v daném kontextu to chápej. SPA je kompletní aplikace běžící na platformě Webovej Prohlížeč. Kde bere data je druhořadé. Když píšu webovou aplikaci postaru, tak taky oddeluju Aplikaci (s architekturou MVC) a data. To je celé, co jsem chtěl zdůraznit. — 27.4.2019
• vladislav.ladicky : Oddeľuješ, na serveri, vo forme MVC. Potiaľ pravda. Zvyšok omyl. Prečo? Lebo s MVC ti jeden a ten istý server generuje stránky, a zároveň pre ne generuje aj dáta na zobrazenie. Preto sa to volá tight coupled - pevne previazaná architektúra. Avšak keď aplikáciu rozdelíš na naprosto nezávislý frontend, napríklad vo forme SPA, ktorý komunikuje s naprosto nezávislým backendom, napríklad vo forme REST API, to už je nieco iné. To je loose coupled, voľne previazaná architektúra. Web server ktorý poskytuje koncovým užívateľom frontend, nemusí mať nič spoločné s web serverom, ktorý poskytuje pre ten frontend dáta, najčastejšie vo forme REST API, a môže byť pokojne na opačnej strane sveta ako server s frontendom. Takto riešená aplikácia následne vôbec nepoužíva session premenné. Ani na frontende, ani na backende. Nato sa na uchovávanie stavu aplikácie, na frontende využíva, počas jednej session, iný pattern. A frontendové frameworky, využívané na tvorbu tých SPA apiek, používajú nový spôsob, MVVM pattern, ktorým robia ten "zázrak" menom reaktivita. ERGO, máš bordel v názvosloví. SPA apka síce môže byť tiež riešená formou MVC, ale tento pattern sa tam proste nepoužíva, ale MVVM. Typically, nie nevyhnutne, ale predsa... — 28.4.2019
• harrison314 : @vladislav.ladicky: To su zavdazjuce tvrdeia, serverovo rendrovana apka vobec nemusi pouzivat session premenne, dnes je trend sa im vyhybat, co nie je problem. A naopak SPA moze pouzivat session na backende, a na frondende v JS (local storage, javascripte,...). Ked uz ohanas pojmami, MVVM je starsie ako (modrenejsie) MVC. Dalej SPA apka nemusi pouzivat MVVM, je plno inych paternov. Stale sa ohanas " loose coupled" ale je to potrebne? IMHO server rendring neznamena, ze sa na tom istom serveri generuje HTML aj sa pristupuje k datam. — 28.4.2019
• Taco : @vladislav.ladicky: chtěl jsem uvést pár detailů, které mi přišli zajímavé zdůraznit. Ohledně toho zda mám bordel v názvosloví jsi mne nepřesvědčil, ale vyvracet ti to nebudu :) — 28.4.2019
• vladislav.ladicky : Ja som s vašimi názormi v pohode Taco. Riaď sa tým, čo povie harrison a pokojne ďalej obaja generujte celé apky čisto na serverovej strane, ideálne v PHP, s tým vašim moderným MVC patternom predstavenom v roku 1970. Ja a ostatní, ktorí už skúsili SPA / PWA s REST / GraphQL API, sa budeme ďalej vyhýbať MVC a generovaniu frontendu s PHP, a naďalej budeme používať React / Angular / Vue, vrátane s tým "starším" MVVM patternom z roku 2005. — 29.4.2019
• Žížala : Bože, tahle diskuse krásně naplňuje podstatu posledního odstavce mého příspěvku... No jsem rád, že už mě není 2x ani 3x a blížím se k 5x letům a tahle diskuse je mě vcelku jedno, protože už jsem se rozhodl a nové poznatky implementuji pomalu a jenom tehdy, když jsou ověřené praxí, alespoň 3 roky a nehoním se za každým hipe. A všechny ty zkratky a termity jsou mě ukradené, protože je potřeba odevzdat funkční apku. A klidně poruším návrhové vzory, když se dostanu k cíli efektivněji a vymáčknu ze serveru vyšší výkon. — 29.4.2019
• siq : @Žížala: to co popisuje Vladislav je tu uz dlhsie nez 3 roky. Dnes uz na to prechadzaju aj banky, ktore su notiricky extremne konzervativne. Server-side MVC/MVP je uz prekonane, ale chapem ze priemerny Cesko-Slovensky programator, ktory v zivote nemusel riesit riadne skalovanie moze byt spokojny s server-side MVC. Pri najhorsom tam hodi nejaku cache vrstvu, a ono to nejako pobezi. Este dodam, ze pri SPA + Microservices sa ovela lahsie(lepsie) tvoria automatizovane testy, ale na to sa v tomto kraji zial stale moc nehra. — 29.4.2019
• Žížala : @siq: líbí se mě tvoje osočování, typický přístup lam. Už jsi někdy pracoval na 7 vrstvé architektuře? Říkají ti něco pojmy jako cAPI, dAPI,AS/400,RPG ILE, MQ, DB2 UDB, ICBS? Na tom jsem dělal 5 let a to na všech vývojářských úrovní, programoval v JAVA,JSP,Javascriptu,HTML,CSS, RPG ILE,RPG III jak primární cyklus tak sekvence, SQL, podílel jsem se na testování, jak load testy, tak komparační (jestli vůbec tušíš co to je). Používal Mercury Load Runner až s 250 klienty pro simulaci zátěže až 1000 requestů/s s požadavkem na odpověď do 300ms. Zjisti si co jsou zač AS/400 a RPG a pak si vyměň plínku. — 29.4.2019
• harrison314 : Ok, sekol som sa MVC je starsie ako MVVM - 1980. @vladislav.ladicky: Ja radsej zvolim architekturu podla poziadaviek, nie podla nabozenskeho presvedcenia. — 29.4.2019
• vladislav.ladicky : Popravde, ty konkrétne si nevolíš to, čo je vhodnejšie. Ty konkrétne si volíš jediné čo vieš. Keby si vedel, zo znalosti, z praxe, o čom hovorím, nereagoval by si presne tak, z čoho obviňuješ mňa: že až s nábožným zápalom obhajuješ MVC... — 29.4.2019
• vladislav.ladicky : Žížala: ja ťa rozhodne za lamu nemám. Avšak chváliš sa v konečnom dôsledku nezmyslom... Ja vezmem iba HTML / CSS / JS a s nejakou SPA a s AWS na backende urobím aplikáciu, ktorá zvládne rovnakú záťaž. A to za zlomkový čas ktorý budeš s tým tvojim setupom potrebovať ty... Tie nové architektúry a frameworky sú totiž práve v tomto dobré. V tom, ako je s nimi v konečnom dôsledku organizovaný výsledný kód. Tak prehľadne, že tomu zatiaľ nič nedokáže konkurovať... A tá prehľadnosť má priamy vplyv na rýchlosť, a rýchlosť zasa na cenu... Preto mne príde normálnejšie chváliť sa tým, ako jednoducho a rýchlo som nie vyriešil, nie ako komplikovane, ako mi to dokáže udržiavať jeden developer z tisíca, nie tým, aké ťažké prachy som do toho musel naliať... PS: použitím iného jazyka na backende vývoj nespomalím. Stále budú ľahko škálovateľné mikroservisy. Či s JS, či Javou, či s Go... — 29.4.2019
• Žížala : vladislav.ladicky : Na základě čeho si dovoluješ tvrdit, to co tvrdíš? Víš něco o provozu jádra bankovního systému a aplikacích nad ním, o tom totiž ICBS a naše programování bylo. Vývoj dělal primárně náš zaměstnavatel + lidé z banky + lidé z dalších stran, kteří měli na krku další části celého ekosystému. Banka si dělala např. internetové bankovnictví a správu podpisových vzorů, my dělali jádro bankovního systému + třeba bankovní pokladny a printy. Další firma dělala jenom komunikační vrstvu nad naším bankovním API. Cca přes 1000 vývojářů/adminů/testerů. Takže žádný jeden developer. A senioři byli lidé s 10 a více let praxí. A rozsah kódu v desítkách milionů řádků v různých programovacích jazycích a na různých platformách. A nějaké AWS/HTML/JS/CSS by prostě nestačilo výkonu pro miliony transakcí za sekundu s přesností na až 31 desetinných míst. Běžné operace se počítali na 15 desetinných míst. Nebo by AWS bylo sakra, ale sakra drahé. — 29.4.2019
• harrison314 : @vladislav.ladicky: Pokial viem, zivotopis som ti neposielal, tak mi laskavo nevrav v com som robil a v com nie. — 29.4.2019
• vladislav.ladicky : Prečo ma tu všetci chytajú za slovíčka... Nemyslel som tým, že teraz jeden developer nahradí celý tým. Ale tebe samotnému nedáva logiku, že zrovna na taký mega rozsiahly projekt by sa hodili najnovšie patterny či architektúry ktoré by ho sprehľadnili, zjednodušili, zlacnili? A cena AWS... ZROVNA pri takom obrovskom projekte by AWS náklady ušetrilo. Prečo asi (zďaleka nielen) Netflix odpískal vlastné datacentrá a všetko premigroval na AWS? A výkon? Kľudne AWS, kľudne s Javou. Kľudne s takou presnosťou, kľudne s takým výkonom. A cena? Kľudne nižšia. Neidealizuj si platformu. Zvlášť nie preto, že nebola zvolená so zreteľom na cenu, ale hlavne so zreteľom na mantinely v bankovom sektore. A že je aj v ňom priestor na vyššiu efektivitu, o tom som presvedčený. Zrovna v bankovom sektore sa uvažuje dosť skostnatelo. Práve toho sa chytajú rôzne online banky. Práve preto vznikajú. Že pochopili, že to ide aj inak, efektívnejšie... — 29.4.2019
• vladislav.ladicky : Nepotrebujem vidieť tvoj životopis, keď vidím to dôležitejšie. Čo vieš a ako na základe toho zmýšľaš. To mi dáva dokonca ďaleko lepší feedback ako akýkoľvek životopis. — 29.4.2019
• Žížala : vladislav.ladicky: hare LAMA hare krišna. Doopravdy, ale doopravdy nevíš o čem je řeč. Nemá cenu se s tebou bavit. A o kvalitě online bank mám své mínění, konkrétně mBank, která už nám opakovaně zmrvila nastavení platební brány, jen tak sama od sebe, asi abychom se tu nenudili... A stačí si projít možnosti rozhraní od ČS/ČSOB/RB/mBank ... ten mTransfer a NPM notifikace mě fakt neberou. Ona teda ani RB. Zlatý Global Payment.... — 29.4.2019
• harrison314 : @vladislav.ladicky: Co keby si si precital moje prispevky este raz. Opakovane mi vkladas do ust nieco co som nevravel a utocis aj na ostatnich. — 29.4.2019
• vladislav.ladicky : A čo keby si urobil to, čo radíš mne? Prečítal si moje príspevky? Prišiel by si potom napríklad na to, že na NIKOHO NEÚTOČÍM, ale len vyjadrujem svoje názory. A to, že sa nezhodujú s názormi niekoho iného, nie je útočenie. Naopak, práve na výmenu názorov diskusia slúži... A že vyjadrujem svoj názor na tvoje znalosti tiež nie je útočenie, ale proste názor. Možno mylný, ale môj, mám na neho právo, aj dôvody, a útočenie to nie je. Avšak diskusiu s tebou ukončujem. Práve na základe toho názoru, ktorý som si z tvojich príspevkov o tebe urobil. Lebo len mudruješ nad komentármi iných, ale autorovi otázky nijak nepomáhaš. A mňa konkrétne obviňuješ z písania nepresností, pritom ty si uviedol nepresnosti. Obviňuješ ma z útočenia, pritom neútočím. Obviňuješ ma z vecí, ktoré sám robíš. Radíš mi veci, ktoré sám nerobíš. Atď. Už je to otravné a tvoje príspevky nemajú ani len základnú logiku, nieto ešte nejaký prínos do diskusie, kde sa autor vyslovene pýta na školenie tvorby webov aktuálne modernými metódami, prechodu od MVC na niečo iné. A všetko čo si mu k tomu poradil, bolo ubezpečenie, že jQuery nie je až také zlé a či chcú fakt opustiť MVC, pravdepodobný doterajší spôsob, súdiac z toho, že používali Symfony, a prejsť na SPA a veci s tým súvisiace. To je všetko z tvojej strany: autor nerob to a vy ostatní sa mýlite, MVC je lepšie. Dokonca novšie... A to ešte aj z dôvodov typu: ale JS framework môže kedykoľvek skončiť a musíš prerábať celú apku. A ako dôkaz si žiadny neuviedol. Iba proprietárnu MS technológiu a Javový framework zpred desiatich rokov... Z princípu to vadný argument, lebo skončiť môže akýkoľvek framework v akomkoľvek jazyku... Plus by som dodal, že už len použitie Vue ako knižnice v PHP projekte, ako priama náhrada za jQuery, vie kód sprehľadniť, čo je aj dôvod, prečo ho Laravel by default podporuje a odporúča miesto jQuery... Zbohom. — 29.4.2019
• siq : @Žížala: Hahaha, 1000 rq/s do 300 ms, tym sa akoze chvalis? Pracujem na projekte kde mame bezne 90k konkurencnych uzivatelov, KPIs su 98% requestov sa musi spracovat do 120 ms od prijatia s SLA 99.99%. Najlepsie je, ze na tom backende za posledne 3 roky nepracovalo ani 6 programatorov do kopy. Chcel by som vidiet ako to niekto skaluje na MVP v PHPcku, alebo v ktorej sracke si zostal zaseknuty. Ja som v tomto biznise uz vyse 25 rokov, a z nejakeho AS/400 sa rozhodne uz na zadok neposadim, skus ma ohurit niecim inym, a nezabudni mi napisat ze som lama :) — 29.4.2019
• harrison314 : @vladislav.ladicky: zas mi vkladas do ust nieco co som ja nepovedal, a keby sa pozries o par riadkov nizsie - https://devel.cz/otazka/javascript-pro-backendaky-skoleni#answer-32698 tak to uvidis. — 29.4.2019
• siq : Hej, to s tou podporou som pisal ja. Aj ked si myslim, ze SPA + Microservices je to najlepsie co dnes mame, stale si je treba byt vedomy nevyhod a uskali na ktore po ceste natrafime. — 29.4.2019
• vladislav.ladicky : Treba. Iste. Keby nie, doteraz by sme všetko písali ako MVC. Ale napísal si vlastne to, čo sa celý čas snažím povedať a niektorí to stále nechápu: spa na frontende a backend ako microservices je to najprehľadnejšie, čo tu aktuálne je. A zjavne si niektorí nedokážu dostatočne predstaviť aký veľký dopad má tá prehľadnosť na čas strávený nad kódom počas životného cyklu aplikácie. Tam ide o desiatky percent, čo je zasa vyjadriteľné v desiatkach percent ušetrených na nákladoch. Podceňujú tú konkurenčnú výhodu ktorú im tá úspora dáva. Ale tak ... mne je to vlastne fuk. Ja som tu vlastne chcel napísať len to, čo som už napísal. Zhodou okolností to školím a že to viem vlastne odškoliť aj na diaľku. Takže ja už fakt nemám čo viac dodať do tohoto vlákna. — 29.4.2019
• siq : Jasne, pre mna za mna, nech si programuju weby aj v Perle cez CGI. Ked niekto chce byt zaseknuty v minulosti, je to jeho problem. Cele mi to pripomina tie diskusie ked vyslo PHP4/5 a moje programatorske okolie sa hrdilo tym, ze oni hype OOP pouzivat nebudu a inline PHP + HTML je good enough. Tiez som vtedy nemal slov :) — 29.4.2019
• Žížala : @siq: si nevychovaná lama. Bankovní systémy se doopravdy nepíší v PHP. A 300ms je na systému, kde kromě nás běží další miliony requestů/s sakra dobrý výkon. Skutečně čti co píši. A nikdy doopravdy nikdy bych si nedovolil srovnávat výkon PHP s RPG, jelikož RPG je v zásadě assembler na AS/400. Takže ty zamindrákovaná neprofesionální dogmatická lamo, dej si pohov když nevíš o čem mluvíš. A já sem v IT přes 25 roků a tvých 25 ti nevěřím, protože bys musel být v mém věku a tomu tvé vyjadřování skutečně, ale skutečně neodpovídá. — 30.4.2019
• Mlocik97 : Vy už tu nevíte co psát... — 30.4.2019
• siq : Cloveku sa rozum zastavi po tom co si precita takuto sracku a na konci komentar o vyjadrovani. Nevidis si do huby ty mamlas :) — 30.4.2019
• siq : "Bankovní systémy se doopravdy nepíší v PHP" - tvoja odpoved je o PHP a Foundation frameworku. Byt tebou, tak sa so svojimi 300ms a neschopnostou zvladat kritiku zahrabem pod zem. Jediny zamindrakovany clovek si tu ty. — 30.4.2019
• siq : A co je to za kravinu ze RPG je assembler? Moze ho trochu syntaxou pripominat, ale je to vysokourovnovy jazyk, ktory priamo podporuje SQL. Vies vobec co je assembler? Odporucam sa na chvilu vratit do skoly, aby si sa tu potom online nemusel strapnovat ako nejaky zhrdeny pubertak. — 30.4.2019