Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: alex6bbc 24. 01. 2025, 11:23:42
-
mam zkusenost, ze backendak se spis nauci js pro frontend, ale frontendaci js nechcou opoustet a cpou to i na backend jako nodejs, deno atd. mate taky tuto zkusenost s frontendakama?
-
> Proč se cpe JavaScript na backend?
pretoze mas jeden jazyk ktorym riesis BE aj FE. FEckari su lacnesji nez BEckari.
Navyse s NodeJS bol vykon dostatocny na weby.
-
Nebo třeba proto, že je výhodné aby frontend developer alespoň trochu rozuměl i backendu a naopak? Takže je pak úplně zbytečná režie navíc používat víc jazyků? Když si napíši backendy v C#, Javě nebo v Ruby (doplňte svůj oblíbený jazyk), bude to sice možná hezké ale co tím získám navíc? Mnohdy skoro nic, za to pak budu muset držet vývojáře jak třeba javové tak javascriptové a polovina frontendistů se mi navíc na nějakou Javu nebo C# vykašle a když ne, nechají si to zaplatit. Takže pak budu v případě něčího neočekávaného výpadku leda zírat do stěny.
Přitom stačí mít v JS všechno, Node.js žádná věda taky není a všechny tyhle problémy to řeší bez dalšího samo.
-
Nebo třeba proto, že je výhodné aby frontend developer alespoň trochu rozuměl i backendu a naopak? Takže je pak úplně zbytečná režie navíc používat víc jazyků? Když si napíši backendy v C#, Javě nebo v Ruby (doplňte svůj oblíbený jazyk), bude to sice možná hezké ale co tím získám navíc? Mnohdy skoro nic, za to pak budu muset držet vývojáře jak třeba javové tak javascriptové a polovina frontendistů se mi navíc na nějakou Javu nebo C# vykašle a když ne, nechají si to zaplatit. Takže pak budu v případě něčího neočekávaného výpadku leda zírat do stěny.
Přitom stačí mít v JS všechno, Node.js žádná věda taky není a všechny tyhle problémy to řeší bez dalšího samo.
Udržuješ nějaký projekt (nebo dokonce produkt) který má napsaný backend v js? Jak je projekt složitý? Kolik let?
Opravdu mě to zajímá.
Vidím výhody, ale i nevýhody. Backend máme v Javě. Dělám hlavně na backendu a troubleshooting. Takove ty věci, proč je co na serveru v produkci pomalé, proč to žere hodně paměťi. Monitoring CVEs závislostí.
Zatím mám pocit, že js knihovny vznikají jak houby po dešti a taky tak rychle zanikají. Nástroje (Cpu profiling, memory profiling, analýza gc logů) nejsou, nebo nejsou tak dobré jako v jvm nebo .net platformě, ale jsem mimo tento ekosystém. JS-TS používám na clientu(ale málo) a psaní playwright testů.
-
Ja sa prave naopak zacinam zaujimat skor o to mat na FE to co na BE cez WASM. JS mi lezie na nervy vzdy ked s nim robim a dostat na FE typovany jazyk, i ked za cenu vykonovej penalizacie(neviem preco, ale WASM tam ma nejaku barieru), za to podla mna stoji.
-
Ekosystém okolo JS pro webové aplikace je bohatý. Například je pěkné, že lze použít Typescript místo Javascriptu :-)
Nicméně otázka spíš zní: proč existují full-stack vývojáři? Nejspíš má většina projektů i vývojářů počáteční fázi, kdy je lepší udělat nehezké "něco" než dumat nad optimální architekturou a učit se nejvhodnější nástroje/jazyky. Spousta lidí se pak zdokonaluje v JS a spousta projektů nikdy nedoroste do fáze, kdy by byl potřeba backend přepsat do "lepšího" jazyka. A pak jsou na trhu dostupní full-stack JS vývojáři a spirála se roztáčí.
-
Nebo třeba proto, že je výhodné aby frontend developer alespoň trochu rozuměl i backendu a naopak? Takže je pak úplně zbytečná režie navíc používat víc jazyků? Když si napíši backendy v C#, Javě nebo v Ruby (doplňte svůj oblíbený jazyk), bude to sice možná hezké ale co tím získám navíc? Mnohdy skoro nic, za to pak budu muset držet vývojáře jak třeba javové tak javascriptové a polovina frontendistů se mi navíc na nějakou Javu nebo C# vykašle a když ne, nechají si to zaplatit. Takže pak budu v případě něčího neočekávaného výpadku leda zírat do stěny.
Přitom stačí mít v JS všechno, Node.js žádná věda taky není a všechny tyhle problémy to řeší bez dalšího samo.
Udržuješ nějaký projekt (nebo dokonce produkt) který má napsaný backend v js? Jak je projekt složitý? Kolik let?
Teď aktuálně zrovna asi čtyři roky? Tak nějak. Složitost nevím jak kvalifikovat. Odhlédnuto od frontendu jsem primárně rubista, jenomže víme, jaký je o Ruby bez Rails zájem a Node.js na backendu stejně nebyla moje volba, přišel jsem už k dávno rozhodnutému a projekt je zajímavý. Sám bych si ho rozhodně nevybral ale bránit se mu také nepotřebuji.
Vidím výhody, ale i nevýhody.
Tak je to se vším.
Zatím mám pocit, že js knihovny vznikají jak houby po dešti a taky tak rychle zanikají. Nástroje (Cpu profiling, memory profiling, analýza gc logů) nejsou, nebo nejsou tak dobré jako v jvm nebo .net platformě, ale jsem mimo tento ekosystém. JS-TS používám na clientu(ale málo) a psaní playwright testů.
A to je možná další důvod. Knihoven jsou doslova miliony na kdeco a bez problémů dostupné a často navíc přímo přenositelné mezi Node.js a frontendem.
-
A to je možná další důvod. Knihoven jsou doslova miliony na kdeco a bez problémů dostupné a často navíc přímo přenositelné mezi Node.js a frontendem.
Ty miliony knihoven (i desítky různých na totožnou věc) nemusí být výhoda.
Nikdy ses s JS/Node nedostal do neřešitelného kolečka závislostí u aktualizace staršího projektu? Kdy nezbývá, než na to raději vůbec nesahat, nebo po výměně zastaralých a nepodporovaných knihoven nezanedbatelnou část kódu přepsat?
-
No to uz je zname z evangelia (Lukas 23.)
Ježíš řekl: „Otče, odpusť jim, neboť oni nevědí, co činí.“
-
> Proč se cpe JavaScript na backend?
pretoze mas jeden jazyk ktorym riesis BE aj FE. FEckari su lacnesji nez BEckari.
Navyse s NodeJS bol vykon dostatocny na weby.
To se jeste dneska deje?? Jako to byla moda tak pred 8-10 lety, ne? Prislo mi, ze od toho se uz upousti. Uz dostatecne mnozstvi lidi zjistilo, ze JS je fakt velky, spatny. Navic jeste na BE. Staticke typovani vyresi fakt spoustu potencialnich pruseru. A to zdaleka neni jediny bordel s JS.
Naopak mi prijde, ze se spis dostava do mody delat webassembly s nejakym silneji typovanym jazykem, jako treba Rust.
Taky mi prijde, ze mantra "fullstack" vyvojari uz taky zacina pomalu vyhasinat konecne. Zas dost lidi zjistilo, ze vysledek toho je spousta brouku pytliku, kteri vsechno videli, ale realne vysledky jsou kupa hnoje...
-
A to je možná další důvod. Knihoven jsou doslova miliony na kdeco a bez problémů dostupné a často navíc přímo přenositelné mezi Node.js a frontendem.
Ty miliony knihoven (i desítky různých na totožnou věc) nemusí být výhoda.
Nikdy ses s JS/Node nedostal do neřešitelného kolečka závislostí u aktualizace staršího projektu? Kdy nezbývá, než na to raději vůbec nesahat, nebo po výměně zastaralých a nepodporovaných knihoven nezanedbatelnou část kódu přepsat?
Jak bych to řekl. Na JS mě baví jedna věc... přesvědčovat tu věc, že opravdu má udělat to, co chcete i když potřebnou architekturu či API navrhoval v ECMA někdo po hodně dlouhém kokainovém mejdanu. Tohle je podobné. Ale problém obvykle nejsou kolečka závislostí. Spíš mi přijde, že se tu a tam stane, že nějaké XYZ funguje s jednou jedinou kombinací verzí knihoven ze čtyřiceti možných a nesmí se s nimi hnout.
A "zastaralé a nepodporované" knihovny obvykle nikdo moc neřeší pokud nepotřebuje nějakou další funkcionalitu. Samozřejmě, že v některých korporátech se po tom z lepších či horších důvodů občas někdo vozí ale pro takové prostředí zase Node.js prostě není dobrá volba. Že je potřeba při aktualizaci knihovny z verze 4 na verzi 6 část kódu více či méně upravit mi přijde celkem přirozené. Vývoj je vývoj.
-
To se jeste dneska deje?? Jako to byla moda tak pred 8-10 lety, ne?
Proč by se to nemělo dít? Na některé zvlášť startupovější projekty je to víc než dostatečné. Ano, děje, není to nic neobvyklého. Maximálně tak opadl hype, ale to je přirozené.
Prislo mi, ze od toho se uz upousti. Uz dostatecne mnozstvi lidi zjistilo, ze JS je fakt velky, spatny. Navic jeste na BE. Staticke typovani vyresi fakt spoustu potencialnich pruseru. A to zdaleka neni jediny bordel s JS.
Proto taky dnes velká část lidí sice vyvíjí v JavaScriptu ale přes TypeScript. Skoro bych řekl, že vysoká většina.
Naopak mi prijde, ze se spis dostava do mody delat webassembly s nejakym silneji typovanym jazykem, jako treba Rust.
Do módy možná. Ale to je zatím zhruba vše.
Taky mi prijde, ze mantra "fullstack" vyvojari uz taky zacina pomalu vyhasinat konecne. Zas dost lidi zjistilo, ze vysledek toho je spousta brouku pytliku, kteri vsechno videli, ale realne vysledky jsou kupa hnoje...
To je naprostý nesmysl. Nebyla to ani nikdy žádná mantra. Prostě někdo dělá jenom frontend, někdo jenom backend, někdo umí obojí. Já jsem třeba původně backend vývojář ale frontend mě vždycky bavil a ať jsem přišel kam jsem přišel, vždycky tam frontend nikdo nechtěl dělat tak to spadlo na mě čemuž jsem se nebránil. Když to děláte patnáct let, prostě se to naučíte. A fakt nejste žádný brouk Pytlík. Naopak, je spousta frontendových vývojářů, kteří fakt rozumí maximálně tomu frontendu a jinak nevidí neslyší. A totéž na backendu. Co s takovými lidmi, když odmítají dělat cokoliv jiného...
-
Nicméně otázka spíš zní: proč existují full-stack vývojáři?
fullstack není jen o tom, že to "nějak splácáš", ale taky bys měl chápat co děláš s proč sis vybral ten konkrétní jazyk k tomu konkrétnímu účelu. Lidi, kteří nikdy nezkusili nic jiného, než js/ts sem podle mě nepatří. Dost ts programátorů naskočilo rovnou na react/express, apod a vlatně toho o javascriptu ani moc nevědí a bez frameworků by nevěděli kde začít. Neříkám, že všichni, ale fakt, že javascript lze spustit v node na backendu neznamená, že je každý fe vývojář fullstack.
-
Proč se cpe JavaScript na backend?
Protože když má člověk v ruce kladivo, tak mu všechno připadá jako hřebík? Frontendista udělá hezčí frontend, než backendista, takže u malých projektů, kde na architektuře a výkonu moc nezáleží, je jednodušší nechat to na FE/FS, a ten použije, co zná.
-
Pokud udelate na backendu microservisovou architekturu, tak neni problem treba nejakou tu servicu naimplementovat v javascriptu.
Uz jsem taky zazil, ze technologie byla urcena tim, co ma firma za programatory.
-
> Proč se cpe JavaScript na backend?
Pretože je to dobrá technológia :)
Za 20 rokov som si prešiel asi všetkými mainstreamovými jazykmi a TypeScript je môj obľúbenec [*1] Nepoznám žiadny iný jazyk, ktorý by mal takú vyjadrovaciu schopnosť čo do typov [*2] A od typovej bezpečnosti sa potom odvíja veľa ďalších vecí.
Čo sa týka Node.js:
- Je to dosť rýchle s nízkymi nárokmi na hardvér.
- Event loop model je podstatne jednoduchší a menej náchilný na chyby ako multithreading. Žiadne mutexy, reentrant locky a podobné mozgové cvičenia...
- Vyvýja sa v tom rýchlo. Bez zdĺhavého reštartovania servera a čakania 3 minúty kým Spring povytvára všetky beany a podobne :)
Pre účely backendu pre webovú aplikáciu uprednostním JavaScript (TypeScript) pred všetkým ostatným, možno s výnimkou Rust-u, ale aj to nie vždy.
[*1] Ok, nie je to priamo JavaScript, ale pod JS si dnes už väčšina ľudí predstaví rovno TS.
[*2] Možno Haskell, ale ten má iné nepraktické momenty.
-
Bez zdĺhavého reštartovania servera a čakania 3 minúty kým Spring povytvára všetky beany a podobne :)
To zní spíš jako hodně letitá zkušenost s IBM WebSphere nebo něčím podobným. Dnešní Jakarta (dříve Java EE) nebo Spring startují v řádu několika vteřin, kromě toho tu máš věci Quarkus, Micronaut, GraalVM a kompilace do nativního kódu…
A pokud jde o webové aplikace, tak bych doporučil podívat se na Vaadin. Píše se to buď v čisté Javě nebo se tam používají Reactí komponenty. Odpadá tam to trápení se s aplikací rozdělenou na „frontend“ a „backend“ – je to prostě jedna aplikace a to, že část běží na serveru a část v prohlížeči, za tebe řeší framework.
-
Dnešní Jakarta (dříve Java EE) nebo Spring startují v řádu několika vteřin
Ten byl dobrej, před víkendem pobavilo. ;D
-
To zní spíš jako hodně letitá zkušenost s IBM WebSphere nebo něčím podobným.
Áno, v tomto máte pravdu. Sú to už roky, čom som naposledy robil Javu a Spring. Veci sa možno zlepšili. Tak či tak, TypeScript + Node.js nie je zlá voľba a v mnohých prípadoch je to pravdepodobne výborná voľba.
-
Dnešní Jakarta (dříve Java EE) nebo Spring startují v řádu několika vteřin
Ten byl dobrej, před víkendem pobavilo. ;D
Já nevím, čistý spring boot startuje na mém kancelářském notebooku 0,6 sec. Většinu času v reálných aplikacích zabere inicializace konexí na subsystémy a to trvá přibližně stejně bez ohledu vývojový jazyk a stack.
-
A pokud jde o webové aplikace, tak bych doporučil podívat se na Vaadin. Píše se to buď v čisté Javě nebo se tam používají Reactí komponenty. Odpadá tam to trápení se s aplikací rozdělenou na „frontend“ a „backend“ – je to prostě jedna aplikace a to, že část běží na serveru a část v prohlížeči, za tebe řeší framework.
Tohle se zkouší pořád dokola (dřív to byl třeba GWT). Ono to totiž zní moc hezky. Jenže ta abstrakce, která umožňuje nerozlišovat (a nedovoluje rozlišovat) mezi "frontend" a "backend", se nakonec vždycky při složitějším použití začne sypat...
-
Javascript a švábi (https://suno.com/song/28d0d33d-6ea0-4d72-b997-d383c4a96762) (album (https://suno.com/playlist/bd5f9198-3357-4a32-82a5-b228abcaa4a7))
-
Za 20 rokov som si prešiel asi všetkými mainstreamovými jazykmi a TypeScript je môj obľúbenec [*1] Nepoznám žiadny iný jazyk, ktorý by mal takú vyjadrovaciu schopnosť čo do typov [*2] A od typovej bezpečnosti sa potom odvíja veľa ďalších vecí.
Statický typing v TS je fajn, sám ho obľubujem, avšak funguje len v compile-time, naopak runtime typescriptovým typom nerozumie nedá sa s typescriptovými typmi pracovať za behu napr pomocou reflexie, takže pri programovaní cítim , že ten strong typing je len umelo dolepený na inak veľmi weak typed jazyk. Ešte som sa nestretol v inom jazyku s takou veľkou schyzofréniou ako pri TS. A toto je obrovský nedostatok. Aj keď uznávam že iná možnosť ako dolepiť typy na JS ani nebola. Dnes už naštastie existujú technológie ako Blazor a Bolero postavené nad WASM a tam už je prítomný plnohodnotný staticko-dynamický typing.
Čo sa týka vyjadrovacej schopnosti také C++ 23 je ešte dalej (aj keď uznávam že tu trošku porovnávam hrušky s jablkami). C++ má ďaleko pokročilejší typový systém. TS generics sú oproti C++ templatom (halvne v oblasti metaprogramovania) len vtip, ale pre širokú komunitu vývojárov sú na druhej strane generics ľahšie na pochopenie a naučenie. Takže všetko má svoje pre a proti.
-
Proč se cpe JavaScript na backend?
pretože isomorfné aplikácie umožňujú zdielať jeden kód medzi frontendom a backendom. takže môžem rovnaké triedy, funkcie a libky používať na frontende aj backende.
-
Javascript a švábi (https://suno.com/song/28d0d33d-6ea0-4d72-b997-d383c4a96762) (album (https://suno.com/playlist/bd5f9198-3357-4a32-82a5-b228abcaa4a7))
kryl - dekuji, za cecko dekuji, jenz nauci me pili.
-
Asi mi něco uniká, já jsem nikdy ten boom JS na backendu nepochopil. Nedokážu si představit, jak by na něm fungovaly moje projekty. Dělám e-shopy a mám tam plno blokujících operací, např.:
- Čtení a generování velkých XML/Excel dat (stovky tisíc produktů)
- Následné zpracování (dost často plnohodnotným ORM)
- Různé prasárny, kde se porovnávají obrovská pole atd. I těch rychlejších CPU operací je stejně hodně a podle mě se to nasčítá.
Jestliže celou administraci bude obsluhovat jedno vlákno, bude se to vzájemně blokovat a nebo budu každou blbost explicitně pouštět ve vlastním workeru a v tom případě mi to celé přestává dávat smysl, ne? A vůbec jsem nezmínil, že bych teoreticky mohl kvůli procesům na backendu blokovat dokončení objednávky zákazníkem - shop bych asi provozoval na samostatné instanci.
Pak jsem vůbec nepochopil, že ten boom začal v době, kdy se ještě moc nepoužíval TS. Bez typů je to krok zpět.
-
Statický typing v TS je fajn, sám ho obľubujem, avšak funguje len v compile-time, naopak runtime typescriptovým typom nerozumie nedá sa s typescriptovými typmi pracovať za behu napr pomocou reflexie
V TypeScript-e som takéto reflexie nikdy nepotreboval. Veci tam do seba pekne zapadajú už v compile time vďaka vlastnostiam ako discriminated unions alebo type predicates. Môj názor je presne opačný - ak potrebujem reflexie, aby som v runtime zistil typ objektu, tak je to nedostatok daného jazyka (prípadne nevhodný návrh kódu). TypeScript je pre mňa dôkaz, že sa to dá urobiť bez reflexií, jednoducho, čitateľne a v compile time.
C++ má ďaleko pokročilejší typový systém.
V C++ nie som až taký zbehlý, ale toto tvrdenie sa mi nepozdáva :) Áno, moderné C++ už má veci ako std::variant a std::optional, ale aj tak potrebujem často používať napr. static_cast a aj tak nakoniec nevyjadrím všetko to, čo by som vyjadril v TypeScript-e. Navyše, kým takýto kód v TypeScript-e je jednoduchý a čitateľný aj pre juniora, porovnateľný kód v C++ vyzerá ako dizertačná práca z matematiky a vyžaduje roky praxe. A to ani nehovorím o kryptických build erroroch, ktoré template-y produkujú.
Jestliže celou administraci bude obsluhovat jedno vlákno, bude se to vzájemně blokovat a nebo budu každou blbost explicitně pouštět ve vlastním workeru a v tom případě mi to celé přestává dávat smysl, ne?
Práve v tom je krása event loop-u, že sa to blokovať nebude. Z pohľadu programátora (aplikačného kódu) dokáže jedno vlákno obsluhovať množstvo "paralelných" requestov. Je to vďaka async/await syntaxi. Jasné, že na pozadí sa blokujúce operácie (čítanie/zápis na disk...) udejú v samostatných vlákach, aby sa využil potenciál viacerých jadier. Aplikácia to však nevidí a programátor môže existenciu vlákien úplne abstrahovať. Jedinou výnikou je, ak máte dlhú časť kódu bez await a skutočne začnete blokovať vlákno. Vtedy tam stačí niekde dať await a je to vyriešené. Za mňa výborný trade-off.
-
Pokud udelate na backendu microservisovou architekturu, tak neni problem treba nejakou tu servicu naimplementovat v javascriptu.
Neříkám, že to neni možný. Ale mít to v jednom jazyce má své výhody. Pokud se podíváme na monolit s modulama, upravíme v nějakym modulu něco, co ovlivní jinej, automaticky nám zařve statická analýza. Uplně stejně na tom je multirepo, alespoň v jazycích, co umí podprojekty, jako jazyky nad jvm a .net. Když se teď přesunem k mikroservisám, který jsou vyloženě v samostatnejch projektech, už to nebude tak jednoduchý, ale furt můžeme mít v samostatnym projektu kontrakty mikroservisy X a to si přidat jako závislost do mikroservisy Y. Ale už nám tu roste komplexita, musíme všude updatnout závislosti, testy integrací mezi jednotlivými mikroservisami jsou také podstatně složitější, než když máme monolit nebo mikroservisy v multi project repu. A pokud ještě použijem u mikroservisy X jinej jazyk než u ostatních mikroservis, bude to ještě pracnější.
Nechci říct, že mít mikroservisu ve vlastnim repositáři je vdžycky špatně, nebo mít že je vždycky špatně mít mikroservisy psaný v jinejch technologiích. Ale chci poukázat na to, že přicházíme o jednoduchost. Takže by člověk měl dobře vědět, co dělá, když tu jednoduchost zahazuje. Myslim si, že by měl bejt podstatnej důvod, proč to udělat.
-
Aby si Javascript pisici koderi mysleli ze programuji ;-)
-
Práve v tom je krása event loop-u, že sa to blokovať nebude. Z pohľadu programátora (aplikačného kódu) dokáže jedno vlákno obsluhovať množstvo "paralelných" requestov. Je to vďaka async/await syntaxi. Jasné, že na pozadí sa blokujúce operácie (čítanie/zápis na disk...) udejú v samostatných vlákach, aby sa využil potenciál viacerých jadier. Aplikácia to však nevidí a programátor môže existenciu vlákien úplne abstrahovať. Jedinou výnikou je, ak máte dlhú časť kódu bez await a skutočne začnete blokovať vlákno. Vtedy tam stačí niekde dať await a je to vyriešené. Za mňa výborný trade-off.
Nojo, jenže ten, na koho reaguješ, právě popisoval situaci, kdy "hodně počítá", tj. to vlákno se nefláká a nečeká na I/O, ale opravdu něco počítá - a takových vláken dokonce má víc než jedno. A v tu chvíli najednou nestačí "niekde dať await a je to vyriešené".
-
Nojo, jenže ten, na koho reaguješ, právě popisoval situaci, kdy "hodně počítá", tj. to vlákno se nefláká a nečeká na I/O, ale opravdu něco počítá - a takových vláken dokonce má víc než jedno. A v tu chvíli najednou nestačí "niekde dať await a je to vyriešené".
Pak nesmí takové výpočty provádět v hlavním vlákně, ale musí je volat z hlavního vlákna asynchronně s callback funkcí a ono se to zparalelizuje samo.
-
Pak nesmí takové výpočty provádět v hlavním vlákně, ale musí je volat z hlavního vlákna asynchronně s callback funkcí a ono se to zparalelizuje samo.
Přiznám se, že v JS nevyvíjím, mimo nějaké sebeobrany a provozu pár hotových aplikací. Ale přišlo mi, že ten princip je vcelku jasný - ten event loop běží pořád jako jedno vlákno - záměrně. Node.js pak používá ještě libuv, který vlákna samozřejmě používá a přes který řeší non-blocking IO operace, DNS resolving, streamy, systémové příkazy atp.
Ale jakmile jde přímo o nějaký kód přímo v JS, tak z toho event loopu přeci nijak nevyskočím, žádný mechanismus, který by to automaticky spouštěl v dalším vlákně tam není, a už je jedno jak ten kód obalím (aspoň já nevím jak).
Mimo worker threadů, které právě na tohle byly do Node.js přidané (i když samozřejmě to není konvenční threading jako v jiných prostředích typu Java nebo C#, protože to startuje celou novou izolovanou instanci V8, takže to spuštění je relativně pomalé a nesdílí to s hlavním vláknem stejná data - má to blíž např. k multiprocessing modulu v Pythonu, co si fakticky také spustí další interpretr).
A ano jsou na WT dál nějaké helpery, aby se to jednodušeji používalo (znám jen threads.js), ale ten základní princip zůstává.
Nebo jak jste to myslel?
Jinak ještě, já neříkám, že tenhle aspekt, musí každý nutně pocítit jako problém. Je vždycky x způsobů jak něco udělat. A asi tip bych si, že u většiny projektů, co na tom běží, se většina déle trvajících operací přesně vejde mezi ty non-blocking (síť, databáze), co si řeší node.js transparentně přes libuv. A když už tam někde má heavy věc, tak si ji šoupne do WT. Nebo třeba nějaké extrakce, komparace s hodně daty může udělat rovnou v db vrstvě, případně pokud je to něco pořád se opakujcího tak se třeba vyplatí rozjet nějakou mikroslužbu bokem.. Ale samozřejmě to rozhodnutí, jestli je některé vlastnost showstopper, je indiviudální.
-
ad michal smucr:
frontendak potrebuje neco na serveru tak tam vrazi nodejs s tema problemama co jste popsal.
jako backendar jsem se musel ten js nejak, jakkoliv doucit. frontendaci nemaji silu se naucit golang, python atd.
je to nahoda nebo symptom?!!
-
Nezazněly tu hlavní rozdíly mezi ekosystémy. Pokud je na backendu PHP, tak má každý návštěvník vlastní proces, který je po vygenerování výstupu zlikvidován. Tím je zabráněno možnému zaseknutí serveru, při pádu jednoho procesu stačí reload stránky.
Naproti tomu servery s Javou či Javascriptem řeší odpovědi jedním procesem větveným na vlákna. Návštěvníci tedy mohou spolu interagovat bez použití databáze, mohou pracovat se společnými daty. Nevýhodou může být, že při pádu aplikace spadne celý server.
Typový systém nepovažuji za nezbytný. Dá se spolehlivě pracovat i bez něho a vývoj je o to rychlejší. Jen je třeba klást větší důraz na testy, bez kterých se dnes stejně programovat nedá.
-
Pak nesmí takové výpočty provádět v hlavním vlákně, ale musí je volat z hlavního vlákna asynchronně s callback funkcí a ono se to zparalelizuje samo.
Nic se "samo" nezparalelizuje. Node.js event loop je single-threaded a pokud člověk potřebuje počítat ve víc vláknech najednou, tak musí začít řešit opičárny typu Worker threads (ale to už rozhodně není "samo").
Typový systém nepovažuji za nezbytný. Dá se spolehlivě pracovat i bez něho a vývoj je o to rychlejší.
Ze začátku, dokud je kódu málo a člověk to celý udrží v hlavě, možná i jo. Jak projekt začne růst, tak to drhne čím dál víc. (Ono celkem logicky pokud by vývoj bez typů byl vždycky rychlejší, tak by se moc nepoužívaly)
-
Pokud udelate na backendu microservisovou architekturu, tak neni problem treba nejakou tu servicu naimplementovat v javascriptu.
Uz jsem taky zazil, ze technologie byla urcena tim, co ma firma za programatory.
To je co za primitivny argument? To ze nieco mozes urobit neznamena zeby si mal. To ze si chlap mas vsetko potrebne nato aby si trtkal do riti ineho chlapa ale to neznamena ze to je dobry napad....
-
Asi mi něco uniká, já jsem nikdy ten boom JS na backendu nepochopil. Nedokážu si představit, jak by na něm fungovaly moje projekty. Dělám e-shopy a mám tam plno blokujících operací, např.:
- Čtení a generování velkých XML/Excel dat (stovky tisíc produktů)
- Následné zpracování (dost často plnohodnotným ORM)
- Různé prasárny, kde se porovnávají obrovská pole atd. I těch rychlejších CPU operací je stejně hodně a podle mě se to nasčítá.
O tom to cele je. Ja zase nevidim duvod proc by vetsina webu mela byt psana v (dosad si sam) kdyz je na to PHP nebo JS mnohem efektivnejsi. A to slovo efektivnejsi ma spoustu duvodu, ale vsechny v zasade konci na ceně.
-
jako backendar jsem se musel ten js nejak, jakkoliv doucit. frontendaci nemaji silu se naucit golang, python atd.
je to nahoda nebo symptom?!!
Kazdy holt nema dano byt raketovy inzenyr ci jaderny vedec. Ale vas nerd ninjy by zase nebavilo lepit ty webiky za par kacek. Stejne jako potrebujes neurochirurgy tak potrebujes i obvodaky, ale dokonce potrebujes i prodavacky v lidlu. Proc se vetsina testeru nema silu naucit goland? Je to nahoda nebo symptom? tak asi takhle hloupy je tvuj dotaz.
-
Nezazněly tu hlavní rozdíly mezi ekosystémy. Pokud je na backendu PHP, tak má každý návštěvník vlastní proces, který je po vygenerování výstupu zlikvidován. Tím je zabráněno možnému zaseknutí serveru, při pádu jednoho procesu stačí reload stránky.
Naproti tomu servery s Javou či Javascriptem řeší odpovědi jedním procesem větveným na vlákna. Návštěvníci tedy mohou spolu interagovat bez použití databáze, mohou pracovat se společnými daty. Nevýhodou může být, že při pádu aplikace spadne celý server.
Typový systém nepovažuji za nezbytný. Dá se spolehlivě pracovat i bez něho a vývoj je o to rychlejší. Jen je třeba klást větší důraz na testy, bez kterých se dnes stejně programovat nedá.
Uz je tady zas, Karliku, opakuji uz je tady zas!
Neni schopen pracovat s typama, omlouva si to a navic nechape horizontalni skalovani.
-
Když pominu tasky, co jsou na první pohled CPU intenzivní a pouštěl bych je ve Workeru, tak se mi nechce věřit, že obyčejný kód nebude blokovat requesty ostatních uživatelů. Prostě když pracuji s ORM, mapuju hromadu entit + další věci pro několik requestů v jednu chvíli, tak se to musí nasčítat a budou se blokovat navzájem. Chápu, u malý aplikace typu blog to asi nebude problém, ale nějak si to nedokážu představit na svých projektech.
-
... kdyz je na to PHP nebo JS mnohem efektivnejsi....
Mluvit v pripade js o efektivite to chce hodne fantazie ... je to zkratka jedina vec kterou browsery umej. A to php se v poslednich letech taky kvuli vsemoznym frikulinum pekne zvrhlo. Za par let bude jednodussi a pristupnejsi napsat to v asm.
-
Do pojmu efektivita pada taky: jak sehnat vyvojare, jak zaplatit vyvojare, jak vyuzit vyvojare ktere mas, pokud jsi vyvojar tak vyuziti znalosti i to, ze znas ekosystem a proste to dokazes udelat efektivne.
Efektivne neznamena inzenyrsky nejlepe s nejvyssim moznym vykonem.
Zejmena v media publishingu je stale efektivnejsi vyuzit tyhle "lopaty" nez hledat inzenyry co ti to udelaji v rustu nebo go...
-
Mluvit v pripade js o efektivite to chce hodne fantazie ... je to zkratka jedina vec kterou browsery umej. A to php se v poslednich letech taky kvuli vsemoznym frikulinum pekne zvrhlo. Za par let bude jednodussi a pristupnejsi napsat to v asm.
Ale ono to efektivní je - ve smyslu, že to běží dostatečně rychle a stálo to poměrně málo peněz na vývoj, protože jsi mohl použít levnýho JS/PHP bastliče. Není to efektivní ve smyslu využití CPU/RAM/atd., ale to u 90 % blogísků/eshopů fakt nikomu žíly trhat nebude...
-
frontendak potrebuje neco na serveru tak tam vrazi nodejs s tema problemama co jste popsal.
jako backendar jsem se musel ten js nejak, jakkoliv doucit. frontendaci nemaji silu se naucit golang, python atd.
je to nahoda nebo symptom?!!
Z tohoto mám dojem, že svoju úvodnú otázku ste nekládli preto, aby ste sa dozvedeli názori ľudí, ktorí uprednostňujú JavaScript ekosystém. Vyznieva to skôr tak, že na Vašom projekte sa používa JavaScript/TypeScript/Node.js a Vás to z nejakého dôvodu rozčuľuje. Preto tu hľadáte utvrdenie v tom, že "my backend-áci" sme nadradení a "oni frontend-áci" sú podradní.
Ak je to tak (a môžem sa samozrejme mýliť), tak zabudnite na "my" a "oni" a berte to ako príležitosť naučiť sa novú technológiu. Každý mainstreamový jazyk/ekosystém Vám dá niečo nové a žiadny nie je podradný. Obzvlášt JavaScript mi svojho času dal veľmi veľa.
-
frontendak potrebuje neco na serveru tak tam vrazi nodejs s tema problemama co jste popsal.
jako backendar jsem se musel ten js nejak, jakkoliv doucit. frontendaci nemaji silu se naucit golang, python atd.
je to nahoda nebo symptom?!!
Z tohoto mám dojem, že svoju úvodnú otázku ste nekládli preto, aby ste sa dozvedeli názori ľudí, ktorí uprednostňujú JavaScript ekosystém. Vyznieva to skôr tak, že na Vašom projekte sa používa JavaScript/TypeScript/Node.js a Vás to z nejakého dôvodu rozčuľuje. Preto tu hľadáte utvrdenie v tom, že "my backend-áci" sme nadradení a "oni frontend-áci" sú podradní.
Ak je to tak (a môžem sa samozrejme mýliť), tak zabudnite na "my" a "oni" a berte to ako príležitosť naučiť sa novú technológiu. Každý mainstreamový jazyk/ekosystém Vám dá niečo nové a žiadny nie je podradný. Obzvlášt JavaScript mi svojho času dal veľmi veľa.
velmi vela...
JS neznam, tohle je stale aktualni?
https://dorey.github.io/JavaScript-Equality-Table/
-
frontendak potrebuje neco na serveru tak tam vrazi nodejs s tema problemama co jste popsal.
jako backendar jsem se musel ten js nejak, jakkoliv doucit. frontendaci nemaji silu se naucit golang, python atd.
je to nahoda nebo symptom?!!
Z tohoto mám dojem, že svoju úvodnú otázku ste nekládli preto, aby ste sa dozvedeli názori ľudí, ktorí uprednostňujú JavaScript ekosystém. Vyznieva to skôr tak, že na Vašom projekte sa používa JavaScript/TypeScript/Node.js a Vás to z nejakého dôvodu rozčuľuje. Preto tu hľadáte utvrdenie v tom, že "my backend-áci" sme nadradení a "oni frontend-áci" sú podradní.
Ak je to tak (a môžem sa samozrejme mýliť), tak zabudnite na "my" a "oni" a berte to ako príležitosť naučiť sa novú technológiu. Každý mainstreamový jazyk/ekosystém Vám dá niečo nové a žiadny nie je podradný. Obzvlášt JavaScript mi svojho času dal veľmi veľa.
Vyplatilo by se spis zkusit Brainfuck.
-
Dnešní Jakarta (dříve Java EE) nebo Spring startují v řádu několika vteřin
Ten byl dobrej, před víkendem pobavilo. ;D
A copa te tak pobavilo?
Ted delam na backendu pro jeden portal, SSO auth keycloak, hibernate postgres, MVC a REST, takze moduly WebMVC, Security a JPA, start 4 sekundy na mem notebooku Lenovo P15 z roku 2022.
Je to ale krapet nezajimavy parametr, mam samozrejme zapnute Spring DevTools a ty meni classy za behu bez restartu, stara se o to VSCode plugin. Obcas to ten plugin otoci za cca 3 sekundy, to kdyz se hrabne do Beans dependency tree, jinak vetsinou ten class hotdeploy.
-
velmi vela...
JS neznam, tohle je stale aktualni?
https://dorey.github.io/JavaScript-Equality-Table/
Jasně. JS je stále stejný blázinec jako byl vždycky. V realitě na to ale člověk narazí dost vzácně.
-
velmi vela...
JS neznam, tohle je stale aktualni?
https://dorey.github.io/JavaScript-Equality-Table/
Nie, nie je to aktuálne. Typovo bezpečný tripple equals operátor prišiel s nástupom CoffeScript-u asi tak pred 10 rokmi. Potom si to našlo cestu aj do samotného JavaScriptu, PHP a možno iných jazykov. V súčasnosti sa používa klasický double equals v TypeScripte, v prípade čistého JavaScript-u tripple equals. Obe možnosti sú typovo bezpečné.
Vždy ma zaráža, ako niekto odsúdi jazyk za nejakú jeho návrhovú chybu spred 30 rokov (v tomto prípade 32), ktorá je už dávno vyriešená. Mimochodom, veci ako implicitné castovanie robí aj klasické C, C++, PHP a iné jazyky. A tiež sa s tým už nejako vyrovnali (explicit contructors a podobne).
JavaScript priniesol naozaj veľa a ovplyvnil množstvo ďalších jazykov. Pomohol spopularizovať funkcionálne programovanie, lambda výrazy, myšlienku že všetko (vrátane funkcie či definície triedy) môže byť reprezentované ako objekt, bindovanie parametrov funkcí a podobne. To, že Java alebo C++ majú dnes niektoré tieto črty (napr. labmda výrazy) je podľa mňa do veľkej miery zásluhou práve JavaScript-u, Node.js a ľudí, ktorí ich priniesli aj na backend.
-
velmi vela...
JS neznam, tohle je stale aktualni?
https://dorey.github.io/JavaScript-Equality-Table/
Nie, nie je to aktuálne. Typovo bezpečný tripple equals operátor prišiel s nástupom CoffeScript-u asi tak pred 10 rokmi. Potom si to našlo cestu aj do samotného JavaScriptu, PHP a možno iných jazykov. V súčasnosti sa používa klasický double equals v TypeScripte, v prípade čistého JavaScript-u tripple equals. Obe možnosti sú typovo bezpečné.
Vždy ma zaráža, ako niekto odsúdi jazyk za nejakú jeho návrhovú chybu spred 30 rokov (v tomto prípade 32), ktorá je už dávno vyriešená. Mimochodom, veci ako implicitné castovanie robí aj klasické C, C++, PHP a iné jazyky. A tiež sa s tým už nejako vyrovnali (explicit contructors a podobne).
JavaScript priniesol naozaj veľa a ovplyvnil množstvo ďalších jazykov. Pomohol spopularizovať funkcionálne programovanie, lambda výrazy, myšlienku že všetko (vrátane funkcie či definície triedy) môže byť reprezentované ako objekt, bindovanie parametrov funkcí a podobne. To, že Java alebo C++ majú dnes niektoré tieto črty (napr. labmda výrazy) je podľa mňa do veľkej miery zásluhou práve JavaScript-u, Node.js a ľudí, ktorí ich priniesli aj na backend.
Každý jazyk má svoje specifika, když tady někdo už poukazuje na nějaké specifičnosti javascriptu při porovnávání hodnot, chtěl bych ukázat, že jinde to je úplně stejný a prostě musíš ten jazyk znát.
Třeba java, ve vlákně mnohokrát doporučovaný na backend, ale má třeba takovéhle špeky,
Integer i = 100;
Integer j = 100;
System.out.println(i == j); // true
Integer i = 200;
Integer j = 200;
System.out.println(i == j); // false
Prakticky by mělo být úplně jedno v čem se to píše, řešit by se měly pouze ty vnější dopady volby jazyka, oni se pak některá prostředí vyloučí a jiná příjdou vhodnější. Odsuzovat někoho, že používá Javascript je strašně povrchní.
-
Třeba java, ve vlákně mnohokrát doporučovaný na backend, ale má třeba takovéhle špeky,
Integer i = 100;
Integer j = 100;
System.out.println(i == j); // true
Integer i = 200;
Integer j = 200;
System.out.println(i == j); // false
Tohle je zrovna taková školácká chyba. Už v úvodu do Javy se člověk dozví, že == porovnává u objektových typů přesnou shodu (tatáž instance). Tzn. že to pro 100 zrovna vrátí true je jen náhoda resp. optimalizace, ale používat to nemáš. To ti řekne i IDE (třeba NetBeans).
Na rozdíl od třeba C++ tu není přetěžování operátorů, takže == se chová všude stejně. Jestli je to dobře nebo špatně, to je otázka - asi jak pro koho - ale vzhledem k tomu, že to je jazyk pro široké masy, tak je to asi spíš dobře.
-
Tohle je zrovna taková školácká chyba. Už v úvodu do Javy se člověk dozví, že == porovnává u objektových typů přesnou shodu (tatáž instance). Tzn. že to pro 100 zrovna vrátí true je jen náhoda resp. optimalizace, ale používat to nemáš. To ti řekne i IDE (třeba NetBeans).
Na rozdíl od třeba C++ tu není přetěžování operátorů, takže == se chová všude stejně. Jestli je to dobře nebo špatně, to je otázka - asi jak pro koho - ale vzhledem k tomu, že to je jazyk pro široké masy, tak je to asi spíš dobře.
nikoliv náhoda, ale jak správně píšeš, optimalizace, dokumentovaná ve specifikaci, probíhá unboxing malých 8-bitových čísel (-127 až 128). Ano, je to školácká věc, avšak dokáže potrápit kdejakého zajetého vývojáře, když nemá IDE.
Ano, stejně tak mi IDE řekne ty chyby s porovnáním v JS. O to právě vůbec nejde. Horší je, když se ten jazyk chová nedetermisticky v čase. Tohle se naučíš a nepříjde ti to.
PHP je na webu velmi rozšířené, přitom to je jazyk, které není schopný ani sjednotit argumenty a názvy funkcí, ještě se nesbavil memory leaků a jediný lék je pravidelný restarat interpreta, ve výsledku to ale provoz nijak moc nevadí a lze s tím žít.
Tohle jsou argumenty, které můžeme my řešit u piva, ale pro aplikace to je jedno, je jedno jestli je jazyk více vláknový se zámky nebo to fejkuje přes event loop a asynchronní IO zase vlastně na té aplikaci a vývoji nemusí jít vůbec poznat (z pohledu času vývoje, náročnosti na zdroje, chybovosti atd. atd.)
Po těch letech vývoje mi je asi šumák v čem je BE/FE aplikace napsaná, důležité je, že jí bude možné dalších X let provozova a vývoj dokončit.
-
Tohle je zrovna taková školácká chyba. Už v úvodu do Javy se člověk dozví, že == porovnává u objektových typů přesnou shodu (tatáž instance). Tzn. že to pro 100 zrovna vrátí true je jen náhoda resp. optimalizace, ale používat to nemáš. To ti řekne i IDE (třeba NetBeans).
Ano, stejně tak je školácká chyba v JS používat ==. Javu mám docela rád, ale tohle je jedna z věcí, kde to na začátku trochu nedomysleli (spolu s kovariancí polí, Cloneable, synchronized a pár dalšíma).
-
Tohle je zrovna taková školácká chyba. Už v úvodu do Javy se člověk dozví, že == porovnává u objektových typů přesnou shodu (tatáž instance). Tzn. že to pro 100 zrovna vrátí true je jen náhoda resp. optimalizace, ale používat to nemáš. To ti řekne i IDE (třeba NetBeans).
Na rozdíl od třeba C++ tu není přetěžování operátorů, takže == se chová všude stejně. Jestli je to dobře nebo špatně, to je otázka - asi jak pro koho - ale vzhledem k tomu, že to je jazyk pro široké masy, tak je to asi spíš dobře.
nikoliv náhoda, ale jak správně píšeš, optimalizace, dokumentovaná ve specifikaci, probíhá unboxing malých 8-bitových čísel (-127 až 128). Ano, je to školácká věc, avšak dokáže potrápit kdejakého zajetého vývojáře, když nemá IDE.
Ano, stejně tak mi IDE řekne ty chyby s porovnáním v JS. O to právě vůbec nejde. Horší je, když se ten jazyk chová nedetermisticky v čase. Tohle se naučíš a nepříjde ti to.
PHP je na webu velmi rozšířené, přitom to je jazyk, které není schopný ani sjednotit argumenty a názvy funkcí, ještě se nesbavil memory leaků a jediný lék je pravidelný restarat interpreta, ve výsledku to ale provoz nijak moc nevadí a lze s tím žít.
Tohle jsou argumenty, které můžeme my řešit u piva, ale pro aplikace to je jedno, je jedno jestli je jazyk více vláknový se zámky nebo to fejkuje přes event loop a asynchronní IO zase vlastně na té aplikaci a vývoji nemusí jít vůbec poznat (z pohledu času vývoje, náročnosti na zdroje, chybovosti atd. atd.)
Po těch letech vývoje mi je asi šumák v čem je BE/FE aplikace napsaná, důležité je, že jí bude možné dalších X let provozova a vývoj dokončit.
Dnes se bez IDE programovat neda a popravde netusim jediny duvod, proc IDE nepouzivat.
Argument o nepouziti IDE je toho ranku, jakoze kdyz nepouziju klic od zahradni branky, polezu pres plot.
Nemyslim si, ze je sumak, co bezi na backendu, prave z toho duvodu dlouhodobe podpory.
Kdyz vezmu 20 let stare WAR tak ho na novem Tomcatu rozjedu bez potizi, max veci typu rename javax-jakarta, ktere jsou peclive popsane a jsou na to konverzni tooly.
Na javascript se podivam za dva mesice, npm upodate plne hlasek o deprecated modulech, CVEcka az na mesic, nektere modyly skoncily po roce vyvoj a mam nahradit alternativou, typicky se stejne jepicim zivotem.
Do JS/TS projektu se musi NEUSTALE hrabat a kdo chvili stal uz stoji opodal.
Pararelizace dtto, Java spolu se Spring podporou velice slusne ale tezkotonazni, NodeJS Async/Await je hnus vedoici k chaosu v kodu, nejlepsi mechanismus asi goroutines/channels. A java obdoba korutin "Project Loom - Virtual Threads" ma podporu v Java 21 a Spring Boot 3.2.
O PHP nema cenu se bavit, to zoufale bylo, je a bude.
Takze mas castecne pravdu, pro male veci je celkem jedno, co je vespod a typicky se to naplaca v necem, co dostupny Lojza programator ovlada. Pokud potrebuju dlouhodobou stabilitu a udrzovatelnost, pak Java/Spring/MavenCentral/ApacheFundation. A pro masivni vykon kontejnery a mikroservisy, ty jednodussi treba v GO.
-
O PHP nema cenu se bavit, to zoufale bylo, je a bude.
A hlavne uz pristi rok umre, uz dvacet let :-)
-
O PHP nema cenu se bavit, to zoufale bylo, je a bude.
A hlavne uz pristi rok umre, uz dvacet let :-)
To si nemyslim.
PHP tu bude s nami i nadale, stejne jako krysy, tyfus a nestovice.
-
O PHP nema cenu se bavit, to zoufale bylo, je a bude.
A hlavne uz pristi rok umre, uz dvacet let :-)
To si nemyslim.
PHP tu bude s nami i nadale, stejne jako krysy, tyfus a nestovice.
Variola eradikovaná byla, tak snad nějaká naděje je ;-)
-
Dnes se bez IDE programovat neda a popravde netusim jediny duvod, proc IDE nepouzivat.
Argument o nepouziti IDE je toho ranku, jakoze kdyz nepouziju klic od zahradni branky, polezu pres plot.
Nemyslim si, ze je sumak, co bezi na backendu, prave z toho duvodu dlouhodobe podpory.
Kdyz vezmu 20 let stare WAR tak ho na novem Tomcatu rozjedu bez potizi, max veci typu rename javax-jakarta, ktere jsou peclive popsane a jsou na to konverzni tooly.
Na javascript se podivam za dva mesice, npm upodate plne hlasek o deprecated modulech, CVEcka az na mesic, nektere modyly skoncily po roce vyvoj a mam nahradit alternativou, typicky se stejne jepicim zivotem.
Do JS/TS projektu se musi NEUSTALE hrabat a kdo chvili stal uz stoji opodal.
Pararelizace dtto, Java spolu se Spring podporou velice slusne ale tezkotonazni, NodeJS Async/Await je hnus vedoici k chaosu v kodu, nejlepsi mechanismus asi goroutines/channels. A java obdoba korutin "Project Loom - Virtual Threads" ma podporu v Java 21 a Spring Boot 3.2.
O PHP nema cenu se bavit, to zoufale bylo, je a bude.
Takze mas castecne pravdu, pro male veci je celkem jedno, co je vespod a typicky se to naplaca v necem, co dostupny Lojza programator ovlada. Pokud potrebuju dlouhodobou stabilitu a udrzovatelnost, pak Java/Spring/MavenCentral/ApacheFundation. A pro masivni vykon kontejnery a mikroservisy, ty jednodussi treba v GO.
To je pouze tvůj pohled, že potřebuješ IDE. Je na každém v čem dělá, mně prostě stačí vim, IDE mě akorát vyrušuje od práce, příliš moc ikonek, funkcí, příliš pomalá odezva, nepotřebuji, ale je to pouze můj způsob práce, stejně jako je tvůj práce v IDE.
Šumák to je z pohledu "který jazyk je lepší", krátkou podporu můžeš mít i u javy, když zvolíš nějakou nevhodnou verzi. Stejně tak o dlouhodou podporu můžeš přijít použitím nedokumentovaných funkcí, hacků a jiných libůstek, opět to není o jazyku.
WAR je zkompilovaná aplikace, porovnávej to také s sestavenou aplikací, tj. javascript i s node_modules složkou. Vem si k 20 let starému warku zdrojáky a zkus to znovu sestavit, pravděpodobně skončíš úplně stejně jako s tím npm. Říkáš to, jak kdyby java neměla cve, vždyť skoro každý měsíc musíme dělat security buildy.
I v javě uděláš hnus, to není o jazyku, ale o tom jak programuješ, jak máš nastavenou architekturu, jak se snažíš erudovat a kontrolovat tým. Opět to není žádný argument pro ten nebo ten jazyk.
Hodnotíš to příliš z technického hlediska, které ale ve výsledku není tak moc podstatné. Argument, že java je pro dlouhodobé projekty je naprosto "validní", díky tomuhle argumentu ještě řadu aplikací udržujeme v java 8 a ještě nedávno jsme horkotěžko přepisovali věci z java 6, já si dlouhodobou podporu představuji jinak než trávit spoustu času na legacy ekosystémem, kdy postupně umírají i závislosti a musí se přepisovat a udržovat doma. Pak najednou lehkost Javascriptu dostává naprosto jiný rozměr, že.
-
Dnes se bez IDE programovat neda a popravde netusim jediny duvod, proc IDE nepouzivat.
Aha, takže už víme, že vy bez IDE programovat neumíte. To ovšem svědčí spíš o vás, uvědomujete si to?
A důvodů proč nepoužívát IDE je celá řada. Stejně, jako proč ho používat. Rozepisovat se mi je nechce.
-
Dnes se bez IDE programovat neda a popravde netusim jediny duvod, proc IDE nepouzivat.
Aha, takže už víme, že vy bez IDE programovat neumíte. To ovšem svědčí spíš o vás, uvědomujete si to?
A důvodů proč nepoužívát IDE je celá řada. Stejně, jako proč ho používat. Rozepisovat se mi je nechce.
Existuje celá řada důvodů, proč se střelit do nohy, rozepisovat se mi je nechce.
-
V TypeScript-e som takéto reflexie nikdy nepotreboval. Veci tam do seba pekne zapadajú už v compile time vďaka vlastnostiam ako discriminated unions alebo type predicates.
Uf brzdi to nekritické nadšenie, všetko má svoje plusy aj mínusy, nechápem ľudí ktorí sa tie mínusy snažia nevidieť. To, že si niečo nepotreboval neznamená, že to nepotrebujú ostatní. Tu ide o to aby som ten typ dal zistiť a checkovať rovnako v compile time ako aj v runtime (tak ako to umožňujú skoro všetky hi level kompilované jazyky). Lebo dajme tomu mame funkciu:
type LedColour = 'red' | 'green' | 'blue';
function lightUpTheLed(color: LedColour) {
...
}
lightUpTheLed("yellow"); // tu mi kompilator vyhodi chybu
const ledColour = await (await fetch('/api/get-color')).json<LedColour>(); // vrati "yellow"
lightUpTheLed(ledColour);
v poslednom riadku mi hodnota "yellow" prejde a celé sa mi to zosype až v tele funkcie, nevyskočí mi žiadna exception o nesprávnom type argumentu, runtime nevie kde nastala chyba - IDE mi neoznačí argument funkcie ako chybový. Načo je potom taký deravý typing? Ako pomáha to, ale často tá schýza vedie skôr k pocitu falošného bezpečnia.
Potom keď chcem napísať ORM framework, service kontainer, alebo validovať restové apiny, tak sú mi typescriptové typy na dve veci. A potom vznikajú projekty ako https://github.com/gcanti/io-ts Kde si type checker píšem v novom DSL, nestačí mi na to jeden jazyk (typescript) potrebujem extra DSL s novou syntaxou zápisu typov, ktorý pokrýva len malú podmnožinu typingu TS, aby javascript runtime konečne rozumelo tomu istému čo som už raz vyjadril v TS.
Môj názor je presne opačný - ak potrebujem reflexie, aby som v runtime zistil typ objektu, tak je to nedostatok daného jazyka (prípadne nevhodný návrh kódu). TypeScript je pre mňa dôkaz, že sa to dá urobiť bez reflexií, jednoducho, čitateľne a v compile time.
píšeš to ako keby reflexia bolo niečo desivé:
var text = "ABC";
text.GetType().Name // vrati nazov typu premennej "text" ako "string";
Je na tomto niečo desivé? Nehovoriac o tom, že tú reflexiu / introspekciu najčastejšie používa priamo runtime keď ťa upozorní na chybu. Málokedy narazíš na situácie keď sa musíš na typy dopytovať sám (aj keď občas sa to hodí).
-
Dnes se bez IDE programovat neda a popravde netusim jediny duvod, proc IDE nepouzivat.
Aha, takže už víme, že vy bez IDE programovat neumíte. To ovšem svědčí spíš o vás, uvědomujete si to?
A důvodů proč nepoužívát IDE je celá řada. Stejně, jako proč ho používat. Rozepisovat se mi je nechce.
Existuje celá řada důvodů, proč se střelit do nohy, rozepisovat se mi je nechce.
Co jsem viděl lidi, co tvrdí, že "nepotřebujou IDE, stačí jim vim", tak jsou vždycky zoufale neefektivní - buď musí dělat ručně věci, co normálně dělá IDE samo, nebo tam mají 50 pluginů (včetně language serveru, ale vůbec to neni do-it-yourself IDE) a tráví půlku pracovní doby tím, že je udržujou ve funkčním stavu...
-
Co jsem viděl lidi, co tvrdí, že "nepotřebujou IDE, stačí jim vim", tak jsou vždycky zoufale neefektivní - buď musí dělat ručně věci, co normálně dělá IDE samo, nebo tam mají 50 pluginů (včetně language serveru, ale vůbec to neni do-it-yourself IDE) a tráví půlku pracovní doby tím, že je udržujou ve funkčním stavu...
A co jsem viděl já, byli to lidé, co normálně fungovali. Ostatně zajímalo by mě, co "IDE dělá samo". Nemluvě o tom, že jste určitě měřil kolik tráví pracovní doby tím, že něco "udržují ve funkčním stavu". Reálně jsou to jen vaše předsudky a dojmologie kombinované se značným nedostatkem představivosti společně případně rovnou s neschopností dělat věci bez IDE.
Pár let jsem takhle používal k vývoji třeba Gedit bez pluginů. To, že něco nemáte v IDE ještě fakt neznamená, že na to nemáte jiný nástroj jinde. Občas ale přijde nějaký věrozvěst a začne vždy vyprávět, jak to nejde... To už je skoro klasika.
-
Dnes se bez IDE programovat neda a popravde netusim jediny duvod, proc IDE nepouzivat.
Aha, takže už víme, že vy bez IDE programovat neumíte. To ovšem svědčí spíš o vás, uvědomujete si to?
A důvodů proč nepoužívát IDE je celá řada. Stejně, jako proč ho používat. Rozepisovat se mi je nechce.
Existuje celá řada důvodů, proč se střelit do nohy, rozepisovat se mi je nechce.
Co jsem viděl lidi, co tvrdí, že "nepotřebujou IDE, stačí jim vim", tak jsou vždycky zoufale neefektivní - buď musí dělat ručně věci, co normálně dělá IDE samo, nebo tam mají 50 pluginů (včetně language serveru, ale vůbec to neni do-it-yourself IDE) a tráví půlku pracovní doby tím, že je udržujou ve funkčním stavu...
Možná si jen nedokážeš představit jak vypadá práce, když ten kód máš v hlavě, a nepotřebuješ pomoc IDE, neustálé šahání na myš tě zdržuje, klávesnice je pro tebe hlavní nástroj. 50 pluginů a language server? Tmux, taby, čistý vim a barevná syntaxe je vše co k životu potřebuji.
Za mě je jedno v čem co píšeš, občas také otevřu Kate, Sublime, Eclipse nebo VSCode, spoustu kódu napíšu i přímo v editoru na github/gitlabu. Dává mi to volnost, ale ať si to každý dělá sám, klidně si to piš ve wordu, když ti to tak vyhovuje a jsi schopný tak pracovat, ale nenálepkuj ostatní, když mají raději wordpad.
-
...v poslednom riadku mi hodnota "yellow" prejde a celé sa mi to zosype až v tele funkcie
Prirodzene, že sa to zosype, veď ste to pretypoval "nasilu" na LedColor. Všetko, čo príde z zvonku, treba prehnať cez validátor. Preženiete to napr. cez Ajv a dostanete buď validný LedColour alebo validation error. Žiadne reflexie tam nepotrebujete. Samozrejme, že ak nekontrolujete vstupy, tak sa dostanete do problémov úplne v každom existujúcom jazyku.
Potom keď chcem napísať ORM framework, service kontainer, alebo validovať restové apiny, tak sú mi typescriptové typy na dve veci.
TypeORM pre mňa funguje dobre, je plne type safe. Validácie robím cez spomínaný Ajv, tiež type safe.
Ak myslíte skôr písanie vlastného ORM alebo kontainera, tak to som neimplementoval, takže sa žiaľ neviem vyjadriť a nejdem tu polemizovať. Každopádne ide o špecifické veci, ktoré si bežný web developer neimplementuje sám.
Je na tomto niečo desivé?
Nepíšem, že je reflexia desivá. Rád podsúvate "slamených panákov", aj vyššie v príspevku :)
Nehovoriac o tom, že tú reflexiu / introspekciu najčastejšie používa priamo runtime keď ťa upozorní na chybu.
To je v poriadku, interpreter predsa nevyhnutne potrebuje vedieť čo interpretuje.
Málokedy narazíš na situácie keď sa musíš na typy dopytovať sám (aj keď občas sa to hodí).
Úplne súhlasím. Občas sa to hodí. Čím lepší jazyk, tým menej je to potrebné. Ako som už písal, v TypeScript-e som to osobne ešte nepotreboval.
-
Co jsem viděl lidi, co tvrdí, že "nepotřebujou IDE, stačí jim vim", tak jsou vždycky zoufale neefektivní - buď musí dělat ručně věci, co normálně dělá IDE samo, nebo tam mají 50 pluginů (včetně language serveru, ale vůbec to neni do-it-yourself IDE) a tráví půlku pracovní doby tím, že je udržujou ve funkčním stavu...
A platí to i naopak: Ti lidé, kteří užívají IDE jsou velice efektivní, protože pošlou polorozbořený kód, u kterého vůbec netuší, co to dělá, a já to po nich musím učesávat...
Ve skutečnosti IDE/neIDE dobré programátory nedělá.
-
ide je fajn a s msvc debugerem je to lepsi.
ale je dobre vedet aspon neco o gdb v command lajne.
totez editace a prace s editorem nebo ide, bud jsi drsny nebo drsnejsi.
-
...v poslednom riadku mi hodnota "yellow" prejde a celé sa mi to zosype až v tele funkcie
Prirodzene, že sa to zosype, veď ste to pretypoval "nasilu" na LedColor. Všetko, čo príde z zvonku, treba prehnať cez validátor. Preženiete to napr. cez Ajv a dostanete buď validný LedColour alebo validation error. Žiadne reflexie tam nepotrebujete. Samozrejme, že ak nekontrolujete vstupy, tak sa dostanete do problémov úplne v každom existujúcom jazyku.
No v každém existujícím jazyku asi ne. Elm ani Rust by to nedovolil.
Technicky máte pravdu.
Ale když se podívám na ten kód:
const ledColour = await (await fetch('/api/get-color')).json<LedColour>(); // vrati "yellow"
Mě tam nic nevaruje, že tam používám nějakou reflexi, přetypování na sílu, etc. Ten kód má vrátit hodnotu typu LedColour, což zřejmě nedělá. Teď je tedy otázka, kdo za tu díru může: Jazyk, nebo knihovna, která je nedokonalá?
Jaká je signatura návratové hodnoty té funkce .json<LedColour>()?
Pokud je to něco jako
: T | string
tak je to sice prasečinka, ale vina je jednoznačně na straně #fortran1986
Pokud je signatura
: T
Tak je to chyba TypeScriptu (a zklamal mě).
-
Protože spousta začínajících programátorů není schopna napsat zdroják tak, aby běžel třeba v PHP na serveru a zároveň v JS na klientovi. A tak mylně došli k závěru, že je to potřeba napsat v jednom konkrétní jazyce a buď použijí JS i na serveru (jako node,js nebo třeba v8js), anebo naopak použijí PHP na klientovi (přes WASM), anebo to napíší v něčem jako Haxe a transpilují.
-
Dnes se bez IDE programovat neda a popravde netusim jediny duvod, proc IDE nepouzivat.
Argument o nepouziti IDE je toho ranku, jakoze kdyz nepouziju klic od zahradni branky, polezu pres plot.
To je pouze tvůj pohled, že potřebuješ IDE. Je na každém v čem dělá, mně prostě stačí vim, IDE mě akorát vyrušuje od práce, příliš moc ikonek, funkcí, příliš pomalá odezva, nepotřebuji, ale je to pouze můj způsob práce, stejně jako je tvůj práce v IDE.
Navíc IDE často podporuje psaní prasáckého kódu s hromadou zbytečných přístupových metod a s nevhodným rozhraním.
-
ide je fajn a s msvc debugerem je to lepsi.
ale je dobre vedet aspon neco o gdb v command lajne.
totez editace a prace s editorem nebo ide, bud jsi drsny nebo drsnejsi.
K čemu je dobrý debugger? Testy jsou mnohem praktičtější. Když jsou spouštěny přímo z editoru, tak je to velmi produktivní.
-
Protože spousta začínajících programátorů není schopna napsat zdroják tak, aby běžel třeba v PHP na serveru a zároveň v JS na klientovi. A tak mylně došli k závěru, že je to potřeba napsat v jednom konkrétní jazyce a buď použijí JS i na serveru (jako node,js nebo třeba v8js), anebo naopak použijí PHP na klientovi (přes WASM), anebo to napíší v něčem jako Haxe a transpilují.
Sorry, ale to je naprostý nesmysl. Realita je prostě taková, že když máte pár programátorů a umí JS, je podstatně snažší v nějakém startupu napsat v JS i backend místo toho, abyste se pracně učil nebo sháněl lidí na něco dalšího jen proto, abyste byl free, cool a in a mohl si říkat, jak jste úžasný. Když to bude potřeba, lze to udělat i později. Toho se totiž fakt nenajíte a faktury z toho nezaplatíte.
-
ide je fajn a s msvc debugerem je to lepsi.
ale je dobre vedet aspon neco o gdb v command lajne.
totez editace a prace s editorem nebo ide, bud jsi drsny nebo drsnejsi.
K čemu je dobrý debugger? Testy jsou mnohem praktičtější. Když jsou spouštěny přímo z editoru, tak je to velmi produktivní.
K tomu, že píšete-li testy, je to sice děsně cool i užitečné, ale ve většině případů vám těch padesát procent času co tím navíc strávíte jednoduše nikdo nezaplatí. A můžete třeba chodit po uších. Nemluvě o tom, že je sice hezké, že vám selže test, ale vy často potřebujete zjistit proč selhal. A to v komplexnějších aplikacích může být zatraceně zamotané. Vzájemně se to tedy ani fakt nenahrazuje.
-
ide je fajn a s msvc debugerem je to lepsi.
ale je dobre vedet aspon neco o gdb v command lajne.
totez editace a prace s editorem nebo ide, bud jsi drsny nebo drsnejsi.
K čemu je dobrý debugger? Testy jsou mnohem praktičtější. Když jsou spouštěny přímo z editoru, tak je to velmi produktivní.
K tomu, že píšete-li testy, je to sice děsně cool i užitečné, ale ve většině případů vám těch padesát procent času co tím navíc strávíte jednoduše nikdo nezaplatí. A můžete třeba chodit po uších. Nemluvě o tom, že je sice hezké, že vám selže test, ale vy často potřebujete zjistit proč selhal. A to v komplexnějších aplikacích může být zatraceně zamotané. Vzájemně se to tedy ani fakt nenahrazuje.
Když selže test, tak vždy přesně vidím, proč selhal. Třídy mívám do 80 řádek a nevidím v tom nic tak komplexního, aby mi testy neukázaly chybu.
-
K čemu je dobrý debugger? Testy jsou mnohem praktičtější. Když jsou spouštěny přímo z editoru, tak je to velmi produktivní.
Debugger používám málokdy, ale když už je potřeba, tak se hodí. Většinou při zkoumání, proč se nějaká knihovna chová jinak, než by měla/bych čekal. Pak je celkem užitečné moct si prohlížet všechny lokální proměnné z celého call stacku a proklikávat se strukturou složitějších objektů.
Testy jsou na něco trochu jinýho.
K tomu, že píšete-li testy, je to sice děsně cool i užitečné, ale ve většině případů vám těch padesát procent času co tím navíc strávíte jednoduše nikdo nezaplatí. A můžete třeba chodit po uších.
Zaplatí, protože nemá na výběr. To není něco, do čeho by měl zákazník kecat. Nehledě na to, že u dlouhodobějších projektů to čas nakonec ušetří (ale to i podle vašich ostatních příspěvků asi není ten typ, co byste dělal - spíš rychle splácat kód bez IDE a bez testů, hodit po zákazníkovi a hurá na další)
-
K tomu, že píšete-li testy, je to sice děsně cool i užitečné, ale ve většině případů vám těch padesát procent času co tím navíc strávíte jednoduše nikdo nezaplatí. A můžete třeba chodit po uších. Nemluvě o tom, že je sice hezké, že vám selže test, ale vy často potřebujete zjistit proč selhal. A to v komplexnějších aplikacích může být zatraceně zamotané. Vzájemně se to tedy ani fakt nenahrazuje.
Nevím zda jsem to správně pochopil, ale vážně jste zastáncem vývoje bez testů? Ano, je to čas strávený navíc, nicméně podle čeho vyhodnocujete dopad postupného vývoje na stávající kód? Já testy vnímám jako velmi hodnotné v rámci regresí a jednoduchého simulování různých stavů v každé fázi vývoje.
-
K tomu, že píšete-li testy, je to sice děsně cool i užitečné, ale ve většině případů vám těch padesát procent času co tím navíc strávíte jednoduše nikdo nezaplatí. A můžete třeba chodit po uších. Nemluvě o tom, že je sice hezké, že vám selže test, ale vy často potřebujete zjistit proč selhal. A to v komplexnějších aplikacích může být zatraceně zamotané. Vzájemně se to tedy ani fakt nenahrazuje.
Nevím zda jsem to správně pochopil, ale vážně jste zastáncem vývoje bez testů? Ano, je to čas strávený navíc, nicméně podle čeho vyhodnocujete dopad postupného vývoje na stávající kód? Já testy vnímám jako velmi hodnotné v rámci regresí a jednoduchého simulování různých stavů v každé fázi vývoje.
Ne, nepochopil. Jsem pouze zastánce dělat to, za co mě zaplatí. Pokud mě za testy nezaplatí což obvykle nezaplatí vzhledem k tomu, že najednou by to stálo dvakrát tolik, pak sice můžete o testech básnit jak Baudelaire ale rozhoduje zadavatel. Tyhle teoretické řeči jsou vždycky s běloskvoucí vůní čerstvě vypraného prádla, ta ale končí zhruba tam, kde začíná praktická realita. A čím menší firma, tím větší tlak na cash-flow a tím začíná dřív.
-
Já teda nevím, platí mě za dodávku řešení - součástí jsou tedy i testy. Ty slouží jak k regresi a okamžité zpětné vazbě na produkovaný kód ale mimo jiné jako funkční ukázka použití tohoto kódu, tedy v podstatě je dokumentací. To bychom mohli polemizovat nad tím, zda vám platí čas strávený debuggingem jako součást vývoje.
-
Ne, nepochopil. Jsem pouze zastánce dělat to, za co mě zaplatí. Pokud mě za testy nezaplatí což obvykle nezaplatí vzhledem k tomu, že najednou by to stálo dvakrát tolik, pak sice můžete o testech básnit jak Baudelaire ale rozhoduje zadavatel. Tyhle teoretické řeči jsou vždycky s běloskvoucí vůní čerstvě vypraného prádla, ta ale končí zhruba tam, kde začíná praktická realita. A čím menší firma, tím větší tlak na cash-flow a tím začíná dřív.
Takže zadavatel zaplatí i ladění aplikace? A není to náhodou větší částka, než vývoj podložený testy?
-
Já teda nevím, platí mě za dodávku řešení - součástí jsou tedy i testy. Ty slouží jak k regresi a okamžité zpětné vazbě na produkovaný kód ale mimo jiné jako funkční ukázka použití tohoto kódu, tedy v podstatě je dokumentací. To bychom mohli polemizovat nad tím, zda vám platí čas strávený debuggingem jako součást vývoje.
Zda mi platí čas strávený debuggingem? Platí. A není to můj problém, upřímně. Nechtějí testy, nemají testy. Kdyby chtěli testy, budou mít testy. Za co platí vám není relevantní. Když přijdu za majitelem firmy a řeknu mu, že to bude trvat jeden týden nebo dva týdny s testy, typicky mi řekne ať se na testy vykašlu, že na to nemá ani peníze ani čas. Jestli se mu to vyplatí je na něm, říkám pokaždé že by se testy hodily, ale nedodávám řešení v podobě ucelených celků; jsem jen námezdní síla a jsem tak spokojen. Nepotřebuji něco někomu nutit.
-
Takže zadavatel zaplatí i ladění aplikace? A není to náhodou větší částka, než vývoj podložený testy?
To je problém zadavatele, ne můj. Nedělám zakázkový vývoj celých celků. A věřte, že sice na to většinou kašlou hlavně v malých firmách kvůli penězům, ale korporáty na to dlabou většinou úplně stejně. Tam, kde pracuju teď jsme něco s testy napsali ale trvalo to dlouho, už jsme to neopakovali protože na to prostě nejsou peníze ani čas. V nejmenovaném korporátu předtím na to taky nebyl čas. Vedení to prostě nezajímalo. Mohu na to upozornit. To obvykle dělám. A dál mohu prudit nebo prostě pokrčit rameny a udělat to, co kdo chce. Co myslíte, že je jednodušší? Mně osobně je to finančně úplně jedno, práce je dost.
Když přijdete vy a budete chtít testy, napíšu vám je. Když ne, tak ne. Tohle fakt není na mně a ani nechci aby bylo. Já vám to navrhnu a řeknu proč by to bylo fajn ale to je vše. Víc dělat nepotřebuji a nechci.
-
Zda mi platí čas strávený debuggingem? Platí. A není to můj problém, upřímně. Nechtějí testy, nemají testy. Kdyby chtěli testy, budou mít testy. Za co platí vám není relevantní.
Díky za objasnění, moje otázka zdaleka nebyla míněna jako zpochybnění vašeho přístupu k práci, spíše mě zajímal názor jak by to mělo být v ideálním světě. Dokonce si myslím, že já sám mám z pohledu testování frňáček nahoru a tvrdím že nepíšu špatný kód, nicméně opakovaně jsem dospěl ke zjištění, že testy výrazně podporují kvalitu dodávky.
Původnímu zadavateli se omlouvám za odklon od původního tématu, a abych přispěl svou trochou:
Mám názor takový, že volbu backendové technologie nemá smysl řešit/zpochybňovat. Prostě to tak je - já budu samozřejmě hájit využití silně typovaných jazyků, zejména na JVM platformě - ať už se bavíme o Javě, Scale, Kotlinu, ale vůbec mě neuráží a nepřijde divné, že se někdo rozhodl pro JS. Až začne upadat zájem o JVM, holt přejdu na jiný jazyk - pro mě je to jen lopata. Nyní dělám BE v Javě + SpringBoot a rozhodně si nemyslím, že by to byl stack mých snů - a tak se snažím dodávat to nejlepší řešení v rámci možností.
-
Díky za objasnění, moje otázka zdaleka nebyla míněna jako zpochybnění vašeho přístupu k práci, spíše mě zajímal názor jak by to mělo být v ideálním světě. Dokonce si myslím, že já sám mám z pohledu testování frňáček nahoru a tvrdím že nepíšu špatný kód, nicméně opakovaně jsem dospěl ke zjištění, že testy výrazně podporují kvalitu dodávky.
No, v ideálním světě by to bylo skvělé. Už proto, že by pak člověku permanentně nenaskakovaly pupínky z regresí. Ale stejně když teď po půldenním pátrání proč zase XYZ přestalo po releasu fungovat přijdu s tím ať napíšeme alespoň end-to-end testy, že je fakt potřebujeme, první otázkou bude jak dlouho to bude trvat a po odpovědi, že asi tak měsíc se s pochopením zase rozejdeme pokračovat v tom na čem kdo pracoval. A o unit testech to platí jakbysmet -- tam zase ve chvíli, kdy project manager začne řešit kolik bude vývoj té či které věci stát.
"Jsou na té planetě lovci?" "Nejsou." "Ach, to je zajímavé! A slepice?" "Také ne." "Nic není dokonalé," povzdychla si liška.
-
Já teda nevím, platí mě za dodávku řešení - součástí jsou tedy i testy. Ty slouží jak k regresi a okamžité zpětné vazbě na produkovaný kód ale mimo jiné jako funkční ukázka použití tohoto kódu, tedy v podstatě je dokumentací. To bychom mohli polemizovat nad tím, zda vám platí čas strávený debuggingem jako součást vývoje.
Zda mi platí čas strávený debuggingem? Platí. A není to můj problém, upřímně. Nechtějí testy, nemají testy. Kdyby chtěli testy, budou mít testy. Za co platí vám není relevantní. Když přijdu za majitelem firmy a řeknu mu, že to bude trvat jeden týden nebo dva týdny s testy, typicky mi řekne ať se na testy vykašlu, že na to nemá ani peníze ani čas.
Pokud bys mu řekl, že to bude trvat jeden týden bez testů nebo jeden týden s testy, co by si vybral?
-
Pokud bys mu řekl, že to bude trvat jeden týden bez testů nebo jeden týden s testy, co by si vybral?
Neřekl bych mu to protože by to nebyla pravda.
-
Pokud bys mu řekl, že to bude trvat jeden týden bez testů nebo jeden týden s testy, co by si vybral?
Neřekl bych mu to protože by to nebyla pravda.
Aha, takže neumíš efektivně psát testy.
-
Pokud bys mu řekl, že to bude trvat jeden týden bez testů nebo jeden týden s testy, co by si vybral?
Neřekl bych mu to protože by to nebyla pravda.
Aha, takže neumíš efektivně psát testy.
Nechcem sa tu voči nikomu nijako stavať, ale ono to môže byť ešte horšie. Keď rozmýšľam o svojich skúsenostiach, tak testy sa zvyčajne píšu ťažko, keď je nedostatočný návrh aplikácie. Inak sa testy píšu rýchlo a sú jednoduché až do tej miery, že sú vlastne nudné. A navyše v JavaScripte sa testy píšu ľahko.
Nemôže to byť tak, že tým, že nepíšte testy síce ušetríte čas pred odovzdaním etapy, ale v ďalšej etape sa vám kvôli tomu nedostatočnému návrhu horšie pridávajú nové funkcionality? Takže si možno myslíte, že ste ušetrili čas, ale v skutočnosti ste ho neušetrili a ešte navyše máte vyššiu mieru stresu, lebo vývoj ide ťažšie?
A na to by už možno zadávateľ reagoval a vy by ste mali väčší pocit bezpečia.
-
Já teda nevím, platí mě za dodávku řešení - součástí jsou tedy i testy. Ty slouží jak k regresi a okamžité zpětné vazbě na produkovaný kód ale mimo jiné jako funkční ukázka použití tohoto kódu, tedy v podstatě je dokumentací. To bychom mohli polemizovat nad tím, zda vám platí čas strávený debuggingem jako součást vývoje.
Zda mi platí čas strávený debuggingem? Platí. A není to můj problém, upřímně. Nechtějí testy, nemají testy. Kdyby chtěli testy, budou mít testy. Za co platí vám není relevantní. Když přijdu za majitelem firmy a řeknu mu, že to bude trvat jeden týden nebo dva týdny s testy, typicky mi řekne ať se na testy vykašlu, že na to nemá ani peníze ani čas. Jestli se mu to vyplatí je na něm, říkám pokaždé že by se testy hodily, ale nedodávám řešení v podobě ucelených celků; jsem jen námezdní síla a jsem tak spokojen. Nepotřebuji něco někomu nutit.
Tak u neceho, co se vyviji 1 tyden si to i nejak dovedu predstavit, ze to clovek udela plus minus bez chyb. Ale ja treba pracuju na softwaru, ktery se vyviji roky a ma > 10 milionu radku a tam by to proste bez testu neslo.
-
Nechcem sa tu voči nikomu nijako stavať, ale ono to môže byť ešte horšie. Keď rozmýšľam o svojich skúsenostiach, tak testy sa zvyčajne píšu ťažko, keď je nedostatočný návrh aplikácie. Inak sa testy píšu rýchlo a sú jednoduché až do tej miery, že sú vlastne nudné. A navyše v JavaScripte sa testy píšu ľahko.
Nemôže to byť tak, že tým, že nepíšte testy síce ušetríte čas pred odovzdaním etapy, ale v ďalšej etape sa vám kvôli tomu nedostatočnému návrhu horšie pridávajú nové funkcionality? Takže si možno myslíte, že ste ušetrili čas, ale v skutočnosti ste ho neušetrili a ešte navyše máte vyššiu mieru stresu, lebo vývoj ide ťažšie?
Většinou to bývá tak, že se autor pokouší psát testy až po napsání aplikace. To je nesmysl. Testy se začínají psát ještě před napsáním prvního řádku produkčního kódu. Kód aplikace se pak píše mnohem snáze.
-
Nechcem sa tu voči nikomu nijako stavať, ale ono to môže byť ešte horšie. Keď rozmýšľam o svojich skúsenostiach, tak testy sa zvyčajne píšu ťažko, keď je nedostatočný návrh aplikácie. Inak sa testy píšu rýchlo a sú jednoduché až do tej miery, že sú vlastne nudné. A navyše v JavaScripte sa testy píšu ľahko.
Nemôže to byť tak, že tým, že nepíšte testy síce ušetríte čas pred odovzdaním etapy, ale v ďalšej etape sa vám kvôli tomu nedostatočnému návrhu horšie pridávajú nové funkcionality? Takže si možno myslíte, že ste ušetrili čas, ale v skutočnosti ste ho neušetrili a ešte navyše máte vyššiu mieru stresu, lebo vývoj ide ťažšie?
Většinou to bývá tak, že se autor pokouší psát testy až po napsání aplikace. To je nesmysl. Testy se začínají psát ještě před napsáním prvního řádku produkčního kódu. Kód aplikace se pak píše mnohem snáze.
Mne základné princípy TDD a to, čo prináša vo vývoji naozaj vysvetľovať nemusíte :)
-
Tohle fakt není na mně a ani nechci aby bylo.
To teda je...
Nikdo jinej tomu nerozumi... to je jako kdyby se mel manazer v bance rozhodovat jestli budou delat podvojne ucetnictvi...
Nebo aby se majitel servisu rozhodoval jestli se po prezuti kol bude kontrolovat utazeni sroubu.
Nebo abych se ja jako zakaznik rozhodoval jestli bude instalater delat kontrolu tesnosti....
Blbost... Testy jsou kod a kod je tvoje zodpovednost. A jestli vis ze jsou potreba a presto nechas zamestnavatele krvacet protoze si o ne nerekl tak to nemuzes moralne nijak obhajit.
(Mluvim o unit testech... ostatni jsou k diskuzi podle situace... )
-
Musím se přiklonit na stranu Martina s tím, že realita je taková že když se tlačí na čas a cenu tak testování je první co se ořezává. Já to třeba vysvětluji tak, že pokud nebudou unit testy tak si musí zákazník dodaný software otestovat uživateslky sám a chyby mu opravím bezplatně pokud se bude jednat o minutovky nebo se domluvíme na vícepracích.
Ve výsledku to většinou dopadne dobře a zákazník ušetří tím že nemá testy ode mě. Spíš mi vzniknou výcepráce protože si to projde podle jeho zadání ale zjistí že něco si nedomyslel, nebo že by to šlo ještě vylepšit a spíš dělám úpravy, které nikdo neuvažoval, za což si zaplatí.
S tím se pojí další komplikace udržovat unit testy aktuální. Dost často něco ladím, zrychluji, refactoriji a pod. Nepíšu nic zas tak super složitého že bych tomu nerozumněl a nemohl to přeskládat jako lego. Pak je to pain udržovat testy ...
Podle mě hrozně záleží na konkrétním případu vývoje podle technologií / použití / životnosti / rozšířitelnosti / počtu vývojářů / integraci CD/CI
Je hezký pushnout z visual studia - udělat pull request a po schválení to letí rovou na release a unit testy to zastaví pokud selžou. Nicméně někdy je potřeba jen zkopírovat exáč z binu na vzdálenou plochu ...
Myslím si že je dobrý být versatilní s tím vysvětlovat rizika i výhody zákazníkům.
Jen pro kontext
Žiju v prostředí - visual studio, c#, desktop aplikace, automatizace, asp.net, git, devops, azure
Projekty od 0 v rozsahu 1-3 týdny do nasazení.
-
za což si zaplatí.
Takze si podojis zakaznika... super. Kdybys mel napsany unit testy tak treba dokazes prijit za zakaznikem driv nez to dodas a reknes mu, ze to nedava moc smysl a jestli nahodou by to nebylo jinak lepsi...
Cim driv odhalis problem tim levnejsi je ho odstranit.
S tím se pojí další komplikace udržovat unit testy aktuální. Dost často něco ladím, zrychluji, refactoriji a pod. Nepíšu nic zas tak super složitého že bych tomu nerozumněl a nemohl to přeskládat jako lego. Pak je to pain udržovat testy ...
Ladeni, zrychlovani a refactoring by typicky nemeli vezt ke zmenam v unit testech.
Podle mě hrozně záleží na konkrétním případu vývoje podle technologií / použití / životnosti / rozšířitelnosti / počtu vývojářů / integraci CD/CI
Je hezký pushnout z visual studia - udělat pull request a po schválení to letí rovou na release a unit testy to zastaví pokud selžou. Nicméně někdy je potřeba jen zkopírovat exáč z binu na vzdálenou plochu ...
Myslím si že je dobrý být versatilní s tím vysvětlovat rizika i výhody zákazníkům.
Ano je dulezite byt flexibilni...
Ale taky je potreba si uvedomit, ze kdyz nechas nekoho kdo tomu nerozumi rikat ti jak mas delat praci a kde usetrit tak jsi amater. A ohanet se tim ze "oni plati => oni rozhoduji" je nemoralni.
-
> S tím se pojí další komplikace udržovat unit testy aktuální. Dost často něco ladím, zrychluji, refactoriji a pod. Nepíšu nic zas tak super složitého že bych tomu nerozumněl a nemohl to přeskládat jako lego. Pak je to pain udržovat testy ...
Naopak, když děláte refactoring, tak testy za mě jsou to nejlepší co může být. Od unitů přes funkcionální. Funkcionální by měli být zelené i po refactoringu, na unity by se mělo šahat jen v těch co testují refaktorovaný kód. Všechny ostatní by měli projít (tj. nezměnil jsem náhodou interface na který spoléhá zbytek programu etc. -- a pokud jsem interface změnil, víte kam se přesně podívat, jaké další části na to spoléhaly).
> Podle mě hrozně záleží na konkrétním případu vývoje podle technologií / použití / životnosti / rozšířitelnosti / počtu vývojářů / integraci CD/CI -- Je hezký pushnout z visual studia - udělat pull request a po schválení to letí rovou na release a unit testy to zastaví pokud selžou. Nicméně někdy je potřeba jen zkopírovat exáč z binu na vzdálenou plochu ...
Osobně si i na svých soukromých projektech dělám CI, CD a testy. Říká mě to jednoduchou věc: rozbil si to. Rád dělám programátora, ne testera klikače -- abych po večerech zjišťoval manuálně kde mi co funguje (nebo nefunguje). Navíc až Vás bude někdo zastupovat, může se velice lehce stát že ten exáč v binu prostě nedokáže zbuildit (protože env, verze kompilátoru chybějící přístup někam, whatever)
> Myslím si že je dobrý být versatilní s tím vysvětlovat rizika i výhody zákazníkům.
Osobně bych zákazníka co nechce testy poslal někam. Tj. takový vývoj po pár letech končí tragicky -- lidé se bojí někam šáhnout aby nerozbili nějakou jinou funkčnost -- protože jim to neřeknou právě testy. Možná že u drobných projektů se to dá, ale jakmile na projektu pracuje víc programátorů a je to něco long-term, nedá se to udržet.
-
Takze si podojis zakaznika... super.
Tohle není úmyslný a unit testy s tím nemají nic společnýho. Například se díky mojí automatizaci příjde při testování na to, že by bylo vhodné změnit konstrukční metodiku. Někdy i sám při vývoji dělám návrhy na změny a úpravy, které nejsou původně plánované. Nebo přijdou nové požadavky protože když to viděl management tak mu to otevřelo oči.
Jsou firmy co žijou v pravěku a excelu a když jim ukážete že 50% činností s informacemi lze pohodlně a rychle automatizovat tak jim to změní realitu, navíc když si můžou žít dál v tom co znají.
Naopak si myslím že můj přístup k zákazníkům je velmi skromny. ... Jeden projekt byla jednoduchá konverze dat z formátu do formátu ... jednalo se o několik tisíc souborů. Za týden se na to napsala malá aplikace co to pochroupala za pár dní. Tu práci si ten zákazník odhadoval na 2000 hodin (ruční klikání soubor po souboru (save as)). Zaplatili nám týden vývoje a konec :) ...
Nevidím tu žádné dojení zákazníků, spíš dělám charitu.
-
S tím se pojí další komplikace udržovat unit testy aktuální. Dost často něco ladím, zrychluji, refactoriji a pod. Nepíšu nic zas tak super složitého že bych tomu nerozumněl a nemohl to přeskládat jako lego. Pak je to pain udržovat testy ...
Testy jsou aktuální vždy. Pokud mám opravit chybu, tak nejprve upravím test tak, aby při nahlášeném vstupu selhal. Pak teprve hledám, kde je ta chyba. Výsledkem je aktuální test i jednotka.
-
Tohle fakt není na mně a ani nechci aby bylo.
To teda je...
Nikdo jinej tomu nerozumi... to je jako kdyby se mel manazer v bance rozhodovat jestli budou delat podvojne ucetnictvi...
(Mluvim o unit testech... ostatni jsou k diskuzi podle situace... )
Ne, není. Dělám to, za co mě zaplatí. Pokud výslovně nezaplatí, nedělám to. Takhle jednoduché to je. Nedělám ucelenou zakázku, nedodávám komplexní řešení. Tohle prostě není můj problém a pracuju pro ty, kteří to neočekávají. A vyhovuje mi to tak. Nemám důvod se snažit o víc, něco prodávat, někoho přesvědčovat. Proč bych to dělal? Co by mi to přineslo? Víc práce s něčím, co dotyčný ani neočekává ani nechce a když ho přesvědčím o tom, že chce, bude to jen zátěž pro mě a on bude jen o to víc vrčet nad každou fakturou, ve které si to zaplatí s pocitem, že je to prý potřeba ale on stejně neví k čemu a jen za to platí?
Teoretiky jako vy miluju.
-
za což si zaplatí.
Takze si podojis zakaznika... super. Kdybys mel napsany unit testy tak treba dokazes prijit za zakaznikem driv nez to dodas a reknes mu, ze to nedava moc smysl a jestli nahodou by to nebylo jinak lepsi...
Reálně mi spíš zákazník zaplatí tolik, kolik chce. To je na něm. A já mu podle toho odvedu práci.
Ale taky je potreba si uvedomit, ze kdyz nechas nekoho kdo tomu nerozumi rikat ti jak mas delat praci a kde usetrit tak jsi amater. A ohanet se tim ze "oni plati => oni rozhoduji" je nemoralni.
Nemorální to není. A nazývat si to můžete jak chcete. Je mi to dost srdečně jedno. Stejně, jako těm, pro koho dělám to, co potřebují. Až budou chtít vás, najmou si vás, upřímně ;)
-
N/A
-
Pokud bys mu řekl, že to bude trvat jeden týden bez testů nebo jeden týden s testy, co by si vybral?
Neřekl bych mu to protože by to nebyla pravda.
Aha, takže neumíš efektivně psát testy.
Vy nedojedete za hodinu z Prahy do Brna? Ha, takže neumíte efektivně řídit! Plácáte úplné kraviny, upřímně. Tyhle prázdné výkřiky do tmy, kterými se prostě snažíte dokázat vlastní ideovou nadřazenost si nechte někam na Novinky.cz, tam zapadnou.
-
> Podle mě hrozně záleží na konkrétním případu vývoje podle technologií / použití / životnosti / rozšířitelnosti / počtu vývojářů / integraci CD/CI -- Je hezký pushnout z visual studia - udělat pull request a po schválení to letí rovou na release a unit testy to zastaví pokud selžou. Nicméně někdy je potřeba jen zkopírovat exáč z binu na vzdálenou plochu ...
Osobně si i na svých soukromých projektech dělám CI, CD a testy. Říká mě to jednoduchou věc: rozbil si to. Rád dělám programátora, ne testera klikače -- abych po večerech zjišťoval manuálně kde mi co funguje (nebo nefunguje).
A já rád dostávám za svou práci zaplaceno. A to za to, co chce zákazník udělat. Pokud nechce testy, nebude mít testy. Chce-li testy, dostane testy. To je celé. Soukromé projekty jsou něco úplně jiného.
> Myslím si že je dobrý být versatilní s tím vysvětlovat rizika i výhody zákazníkům.
Osobně bych zákazníka co nechce testy poslal někam. Tj. takový vývoj po pár letech končí tragicky -- lidé se bojí někam šáhnout aby nerozbili nějakou jinou funkčnost -- protože jim to neřeknou právě testy. Možná že u drobných projektů se to dá, ale jakmile na projektu pracuje víc programátorů a je to něco long-term, nedá se to udržet.
To sice máte pravdu, ale rozhodnutí je na tom, kdo mě platí co bude a nebude chtít. Já mu mohu sdělit svůj vlastní názor ale zbytek řešit nechci. Nemám zapotřebí ho přesvědčovat. Nejsem firma. Jsem námezdní síla, se kterou to může zkonzultovat a která mu udělá to, za co si zaplatí. Ani méně, ani více. Samozřejmě by člověk mohl pracovat tam, kde bude mít větší odpovědnost ale atokonto taky o dost víc starostí, za (snad) lepší peníze, prostě reálně podnikat. Ale potřebuji to? Co mě nutí? Co by to přineslo mně?
A pokud mi zákazník zaplatit plánuje, nemám důvod ho kamkoliv posílat pokud je jeho projekt něco, co mě z jakéhokoliv důvodu zajímá nebo baví. Celé je to prostě o úrovni a způsobu angažovanosti. Kdybych byl firma a dělal vyloženě větší zakázky s následnou údržbou další roky, budu tlačit na udržitelnost. Jsem-li prostý námezdní programátor na volné noze pracující tu pro toho, tu pro onoho, je moje angažovanost ve správě projektu nastavená zase úplně jinak a správa a fungování projektu a to, co v tomto ohledu chce je na zadavateli.