Jak mám programovat v Node.js?

[Idris]

V JS bohuzel nic jako Hibernate nemam.

sebevědomé tvrzení od někoho, kdo JS nezná. ORM knihoven je spousta.

  no prave

https://stackoverflow.com/questions/6007353/which-orm-should-i-use-for-node-js-and-mysql

No longer maintained...
No longer maintained...
No longer maintained...
No longer maintained...

Node.js není moc dobrá volba, sám autor tohoto frameworku přešel na Go

[Reklama]

[Filip Jirsák]

co vám vadí na js ekosystému v roce 2019? Podle mě se ten ekosystém už dávno stabilizoval. Je stejně stabilní, ale mnohem modernější než java ekosystém. npm už také funguje bez problémů.

Chtěl jsem vám to věřit, ale pak se mi v timelině objevilo toto: https://twitter.com/lukejacksonn/status/1131506699356037121

Jinak ale pokud někdo chce programovat jako v Javě, ať programuje v Javě – programovat jako v Javě v něčem jiném nedává smysl, to nemůže dopadnout jinak, než že bude dotyčný nespokojený. Výhoda existence více programovacích jazyků je právě v tom, že jsou různé, každý se hodí na něco jiného, jiný způsob práce a pro jiné programátory. Nedávalo by smysl mít dva jazyky, které budou stejné.

[Zabanovaný Anonymní Troll]

Jeste bych ten Javascript mohl uchopit trochu jinak - programovat to ze strany UI a backend zadratovat. Tak po to podle me delaji javascriptari.

[Kit]

Jeste bych ten Javascript mohl uchopit trochu jinak - programovat to ze strany UI a backend zadratovat. Tak po to podle me delaji javascriptari.

Feritové paměti už vyšly z módy.

[Zabanovaný Anonymní Troll]

Teda vazeni, ja uz dlouhe mesice Waldemarovy prispevky zcela ignoruju, ani nevim co mi tady psal.

Nicmene je zajimave, ze doted se tu nikdo nerozepsal jak v tom dynamickem jazyce teda programovat. Zkousel jsem proklikavat ruzne knihovny, jaky design pouzivaji ony, a jako je to vcelku hnus, komentare zadne, dokumentace vetsinou bida, na nejake intuitivni rozeznani jak kterou knihovnu pouzivat se da zapomenout. Takze asi musim programovat taky tak.

Asi zkusim jeste pro inspiraci jak je udelany Python.

[Reklama]

[Kit]

Nicmene je zajimave, ze doted se tu nikdo nerozepsal jak v tom dynamickem jazyce teda programovat. Zkousel jsem proklikavat ruzne knihovny, jaky design pouzivaji ony, a jako je to vcelku hnus, komentare zadne, dokumentace vetsinou bida, na nejake intuitivni rozeznani jak kterou knihovnu pouzivat se da zapomenout. Takze asi musim programovat taky tak.

Asi zkusim jeste pro inspiraci jak je udelany Python.

Komentáře nejsou potřebné, kód musí být srozumitelný i bez nich. Pokud není, tak je to zpravidla chybou autora a nějaké komentáře to nespraví. U takových programů často ani nebývají testy, ze kterých se obvykle dají vyčíst příklady použití. Ovšem těmi knihovnami bych se moc neřídil, raději bych sáhl po nějakém tutoriálu.

Python je na tom podle mne mnohem lépe, určitě ho vyzkoušej.

[Mlocik97]

Doteraz nikde som nevidel navrhovať Node aplikáciu spôsobom "a ako prvé si zadefinujeme doménový model". Ani definovaním data access objects. O čom točíte?

tak se programovalo před rokem 2000, v dobách nedokonalých verzovacích systémů dávalo smysl x vrstev abstrakce. Někteří tak programují dosud.

Jak to souvisi s verzovacim systemem? Ja mam za to, ze domenovy model je zaklad dobreho OOP designu.

Nevim jak mam udelat spravny OOP desigm kdyz si jako jednu z prvnich veci neujasnim domenovy model. Me to tak vyhovuje.

Dobry OOP? picovina... https://sw-samuraj.cz/2019/02/remcani-proti-jave/

[Kit]

Nevim jak mam udelat spravny OOP desigm kdyz si jako jednu z prvnich veci neujasnim domenovy model. Me to tak vyhovuje.

Dobry OOP? picovina... https://sw-samuraj.cz/2019/02/remcani-proti-jave/

V tom blogu nepopisuje nic jiného, než blbě pochopené OOP. Java je v tom nevinně.

[Zabanovaný Anonymní Troll]

Doteraz nikde som nevidel navrhovať Node aplikáciu spôsobom "a ako prvé si zadefinujeme doménový model". Ani definovaním data access objects. O čom točíte?

tak se programovalo před rokem 2000, v dobách nedokonalých verzovacích systémů dávalo smysl x vrstev abstrakce. Někteří tak programují dosud.

Jak to souvisi s verzovacim systemem? Ja mam za to, ze domenovy model je zaklad dobreho OOP designu.

Nevim jak mam udelat spravny OOP desigm kdyz si jako jednu z prvnich veci neujasnim domenovy model. Me to tak vyhovuje.

Dobry OOP? picovina... https://sw-samuraj.cz/2019/02/remcani-proti-jave/

Ten clanek je zajimavy, uz jsem ho cetl nekdy driv, ale v podstate mu chybi neco, co jeho hodnoto hodne devalvuje. A to je, v jakem enviromentu ten otycny clovek pracuje. Je totiz velky rozdil v designu komponent zvolenem v Enterprise a designu zvolenem nekde na mensich projektech. A nemysli si, Java se da taky skalovat - nemusis mit automaticky na vsechno byrokraticky napsanych nekolik vrstev abstrakci. Ackoliv nekteri lidi to maji tendenci delat - respektive mame to tendenci delat vsichni, ale projevuje se to ruzne intenzivne. Odpovida to gaussove krivce, programovani je ohromna zatez a zkouska na kognitivni schopnosti jedince.

O spravnosti OOP a toho, jak to dela Java, uz nepochybuju. Muzu srovnat uz 2 enviromenty, v jednom se bastlilo proceduralne (master Javista byl byvaly PHPkar), v druhem se dela OOP - OOP enviroment svou prehlednosti jednoznacne vede.

O spravnosti designu Javy (a C#) uz nepochybuju taky - kdyz to srovnam s Javascriptem. Celkova kvalita knihoven v Javascriptu neni moc dobra.

Udelat necemu dobre design neni uplne jednoduche a v Jave je diky Springu zavedena uz 2 dekady metodologi toho, jak ma komponenta vypadat. Je to spravne a vhodne definovano tim frameworkem. Delat neco OOP uplne od nuly, tomu se snazim vyhybat, protoze to neni tak jednoduche - mam tendenci vsude uplatnovat to, jak vypada komponenta ve eSpringu, protoze je to prehledny a dobry design, tzn. rozdeleni na API, Service, DAO, domenovy model, vstupni mappery, vystupni mappery, background joby - na tom neni treba nic menit, nikdo nic lepsiho nez je tohle nevymysli.

Kdyz ctu tyhle clanky, kde nekdo rozporuje OOP, tak jedna z veci je, ze OOP neznamena Java. OOP je tady uz nekolik dekad. A kdovi, mozna bylo toto paradigma vymysleno jeste predtim, nez vznikly pocitace - jak uz to tak u nekterych veci byva, lidi se jimi zabyvaly driv, nez je vubec meli na cem implmentovat. A je vcelku vtipne, kdyz nejaky jednotlivec rozporuje desitky let vyvoje programovaich jazyku - cimz se zabyvali lide chytrejsi nez ja nebo autor clanku. A jak to dneska vypada v popularite jazyku je jasne videt, OOP jazyky vedou.

[Idris]

Doteraz nikde som nevidel navrhovať Node aplikáciu spôsobom "a ako prvé si zadefinujeme doménový model". Ani definovaním data access objects. O čom točíte?

tak se programovalo před rokem 2000, v dobách nedokonalých verzovacích systémů dávalo smysl x vrstev abstrakce. Někteří tak programují dosud.

Jak to souvisi s verzovacim systemem? Ja mam za to, ze domenovy model je zaklad dobreho OOP designu.

Nevim jak mam udelat spravny OOP desigm kdyz si jako jednu z prvnich veci neujasnim domenovy model. Me to tak vyhovuje.

Dobry OOP? picovina... https://sw-samuraj.cz/2019/02/remcani-proti-jave/

Ten clanek je zajimavy, uz jsem ho cetl nekdy driv, ale v podstate mu chybi neco, co jeho hodnoto hodne devalvuje. A to je, v jakem enviromentu ten otycny clovek pracuje. Je totiz velky rozdil v designu komponent zvolenem v Enterprise a designu zvolenem nekde na mensich projektech. A nemysli si, Java se da taky skalovat - nemusis mit automaticky na vsechno byrokraticky napsanych nekolik vrstev abstrakci. Ackoliv nekteri lidi to maji tendenci delat - respektive mame to tendenci delat vsichni, ale projevuje se to ruzne intenzivne. Odpovida to gaussove krivce, programovani je ohromna zatez a zkouska na kognitivni schopnosti jedince.

O spravnosti OOP a toho, jak to dela Java, uz nepochybuju. Muzu srovnat uz 2 enviromenty, v jednom se bastlilo proceduralne (master Javista byl byvaly PHPkar), v druhem se dela OOP - OOP enviroment svou prehlednosti jednoznacne vede.

O spravnosti designu Javy (a C#) uz nepochybuju taky - kdyz to srovnam s Javascriptem. Celkova kvalita knihoven v Javascriptu neni moc dobra.

Udelat necemu dobre design neni uplne jednoduche a v Jave je diky Springu zavedena uz 2 dekady metodologi toho, jak ma komponenta vypadat. Je to spravne a vhodne definovano tim frameworkem. Delat neco OOP uplne od nuly, tomu se snazim vyhybat, protoze to neni tak jednoduche - mam tendenci vsude uplatnovat to, jak vypada komponenta ve eSpringu, protoze je to prehledny a dobry design, tzn. rozdeleni na API, Service, DAO, domenovy model, vstupni mappery, vystupni mappery, background joby - na tom neni treba nic menit, nikdo nic lepsiho nez je tohle nevymysli.

Kdyz ctu tyhle clanky, kde nekdo rozporuje OOP, tak jedna z veci je, ze OOP neznamena Java. OOP je tady uz nekolik dekad. A kdovi, mozna bylo toto paradigma vymysleno jeste predtim, nez vznikly pocitace - jak uz to tak u nekterych veci byva, lidi se jimi zabyvaly driv, nez je vubec meli na cem implmentovat. A je vcelku vtipne, kdyz nejaky jednotlivec rozporuje desitky let vyvoje programovaich jazyku - cimz se zabyvali lide chytrejsi nez ja nebo autor clanku. A jak to dneska vypada v popularite jazyku je jasne videt, OOP jazyky vedou.

Kdybys to měřil inteligencí, tak vede Haskell. I ten je ovšem pro Agdaře primitivní, protože má (z jejich pohledu) omezený typový systém.

[Kit]

Udelat necemu dobre design neni uplne jednoduche a v Jave je diky Springu zavedena uz 2 dekady metodologi toho, jak ma komponenta vypadat. Je to spravne a vhodne definovano tim frameworkem. Delat neco OOP uplne od nuly, tomu se snazim vyhybat, protoze to neni tak jednoduche - mam tendenci vsude uplatnovat to, jak vypada komponenta ve eSpringu, protoze je to prehledny a dobry design, tzn. rozdeleni na API, Service, DAO, domenovy model, vstupni mappery, vystupni mappery, background joby - na tom neni treba nic menit, nikdo nic lepsiho nez je tohle nevymysli.

Pokud se někdo pokusí použít metodologii Springu v NodeJS nebo třeba v PHP, tak je z toho obvykle katastrofální design aplikace plný mapperů a nesmyslných servisních tříd. Do MVC nic takového nepatří.

[Zabanovaný Anonymní Troll]

Udelat necemu dobre design neni uplne jednoduche a v Jave je diky Springu zavedena uz 2 dekady metodologi toho, jak ma komponenta vypadat. Je to spravne a vhodne definovano tim frameworkem. Delat neco OOP uplne od nuly, tomu se snazim vyhybat, protoze to neni tak jednoduche - mam tendenci vsude uplatnovat to, jak vypada komponenta ve eSpringu, protoze je to prehledny a dobry design, tzn. rozdeleni na API, Service, DAO, domenovy model, vstupni mappery, vystupni mappery, background joby - na tom neni treba nic menit, nikdo nic lepsiho nez je tohle nevymysli.

Pokud se někdo pokusí použít metodologii Springu v NodeJS nebo třeba v PHP, tak je z toho obvykle katastrofální design aplikace plný mapperů a nesmyslných servisních tříd. Do MVC nic takového nepatří.

Co je spatneho na tom, mit design udelany tak, ze budu rozlisovat kategorie funkci na api, vstupni mappery, vystupni mapper, service, domenu, dao a background joby? Kazde kategorii bude i odpovidat jedna slozka. To mi vysvetli, co je na tom tak spatneho. - to ti prijde prebyrokratizovane?

[Mlocik97]

Nevim jak mam udelat spravny OOP desigm kdyz si jako jednu z prvnich veci neujasnim domenovy model. Me to tak vyhovuje.

Dobry OOP? picovina... https://sw-samuraj.cz/2019/02/remcani-proti-jave/

V tom blogu nepopisuje nic jiného, než blbě pochopené OOP. Java je v tom nevinně.

Ak niekto kto programuje v Jave 10 rokov nepochopí OOP, tak už to je náznakom že OOP je blbosť, keďže Java je nejvíc strikt OOP jazyk. Ostatne ten pojem OOP je samo o sobe nestriktne definovaný, a každý to chápe trocha inak, a každý tvrdí o druhom že nesprávne pochopil OOP. Pritom čo je to vlastne OOP? Hodne abstraktný pojem samo o sobe. Ale ok, dajme tomu že vy viete čo je OOP. Avšak ako môžete hovoriť že je OOP lepšie? Když neviete ako spraviť kvalitný program ne-OOP formou? Skúšali ste jazyky Golang alebo Ruby? Ja som programoval aj v Jave, aj v Golang, viem porovnať. Když viete len OOP jazyk, a nemusí to byť len Java, klidne trebárs C#, tak stejnak nemôžete tvrdiť čo tvrdíte, kým ste nerobili na komplexnom projekte ne-OOP cestou. Vy budete tvrdiť že OOP je skvelé, len preto že to vyzerá dobre, ale není tomu tak.


E: p.s. moja najbolúbenejšia kombinácia technológií je Node.js+Angular+Golang+Redis všetko cestou MVC ... ale mám rád i C/C++ a prekvapivo Scalu.

[Cikáda]

A je vcelku vtipne, kdyz nejaky jednotlivec rozporuje desitky let vyvoje programovaich jazyku - cimz se zabyvali lide chytrejsi nez ja nebo autor clanku.

Ty desítky let byly v nějakém kontextu, zkušenosti a znalosti se posouvají... takže ano, i jedinec může rozporovat desítky let vývoje programovacích jazyků, stejně jako u jiných věcí. Navíc podle čeho posuzuješ chytrost autora článku? (a to vůbec neříkám, že chytrost je něco, co s tím má co dělat)

A jak to dneska vypada v popularite jazyku je jasne videt, OOP jazyky vedou.

Popularita není úplně dobrým měřítkem kvality.

[Kit]

Udelat necemu dobre design neni uplne jednoduche a v Jave je diky Springu zavedena uz 2 dekady metodologi toho, jak ma komponenta vypadat. Je to spravne a vhodne definovano tim frameworkem. Delat neco OOP uplne od nuly, tomu se snazim vyhybat, protoze to neni tak jednoduche - mam tendenci vsude uplatnovat to, jak vypada komponenta ve eSpringu, protoze je to prehledny a dobry design, tzn. rozdeleni na API, Service, DAO, domenovy model, vstupni mappery, vystupni mappery, background joby - na tom neni treba nic menit, nikdo nic lepsiho nez je tohle nevymysli.

Pokud se někdo pokusí použít metodologii Springu v NodeJS nebo třeba v PHP, tak je z toho obvykle katastrofální design aplikace plný mapperů a nesmyslných servisních tříd. Do MVC nic takového nepatří.

Co je spatneho na tom, mit design udelany tak, ze budu rozlisovat kategorie funkci na api, vstupni mappery, vystupni mapper, service, domenu, dao a background joby? Kazde kategorii bude i odpovidat jedna slozka. To mi vysvetli, co je na tom tak spatneho. - to ti prijde prebyrokratizovane?

Funkcím se v OOP říká metody a mají v něm odlišnou roli. Statickým metodám můžeme říkat funkce, ale jejich výskyt by měl být v OOP minoritní - například u továrních metod.

Jaká jedna odpovídající složka? Copak ty složky pojmenováváš názvem kategorie? Správně mají být pojmenovány názvem domény, o kterou se starají. Zbytečně ti vzniká další vrstva adresářů. Struktura má být plochá, dvouvrstvá, maximálně třívrstvá. V žádném případě se z toho nesmí dělat taxonomie. Slova mapper, service, domain apod. do těch názvů nepatří - jinak z návrhu vznikne paskvil.