Vytváření aplikačních systémů Unix-like metodou

[anonym]

Dam priklad typickeho J, Spring. Doporucil bych kazdemu Javistovi, aby si ho porovnal s Python Django, aby videl, jak ma vypadat webovy framework.

Takže bys chtěl mít Spring jednoúčelový a jednoduchý? To asi pro ty adminy s Pythonem stačí, ale u J potřebuješ daleko složitější věci. Django je dobré pro začátečníky, protože s ním dokážou pracovat. Když Djangu i porozumí, tak můžou přejít na plnohodnotný FW jako Spring.

Youda to napsal hezky. Jedno z možných luxusních využití J. A takových věcí je tam asi milion dalších.

Ja bych na to reagoval Javamane, bohuzel by to nemelo smysl, protoze jsi dement. Tak aspon pro ostatni:

Spring Framework ma zaprve pomaly deploy jako svina a dost pochybuju, ze v nejake ceske firme poridi JRebel (realtime deploy), ktery stojii 500$ rocne na vyvojare, kdyz kolikrat nejsou schopni koupit svym developerum ani IntelliJ IDE.

Dale, jeste v dobe XML byly Spring aplikace ponekud neprehledne kvuli rozsahlym konfigurakum a pokud se neco pokazilo ve verzich, nebyl ani schopny vypsat radnou hlasku proc se to stalo. Nicmene od te doby, co vznikl Spring Boot, tzn. framework nad frameworkem, je nejen neprehledny, ale jeste navic do Springu pribyl totalni magic, o kterem nikdo presne nevi, jak to vlastne funguje. V kombinaci s naprosto bidnou dokumentaci, pokud se neco rozesere, tak good luck.

Problem Javistu je, ze drtiva vetsina z nich nikdy nepoznala .NET. Nevi co to je, otevrit si Visual Studio, ktere v mziku najede (to i ta IntelliJ nacita, nacita, nacita), a zmeny v kodu se bleskurychle projevi v deplounute aplikaci. A uz vubec nevi, jak maji vypadat poradne udelane knihovny. Kdyby si totiz Javisti takhle uvedomili, ze jsme uz v 21. stoleti, tak by jejich pocet klesl na ctvrtinu.

Javisti proste zijou v predstave o sve husto krute Enterprise Jave. Viz Youda, tady se bavime o Unixove filozofii vyvoje SW a on prijde s javovksym OSGi.

[Reklama]

[anonym]

Kdo neveri, tak deploy takove typicke casti korporatni Springove aplikace muze trval klidne 3 minuty, pricemz kdyz se to veme kolem a kolem, dela v podstate hovno, protoze tam ma v par modulech akorat REST, nejakou if-krizovatku volani jinych restu, no a potom udelani cehosi nad databazi. To ji ale nebrani, aby byla slozita a neprehledna jako sfina.

Staci se podivat, cim agumentuje JRebel, kdyz za tu svou vec chce 450$ rocne:

https://zeroturnaround.com/software/jrebel/pricing/

[Jan Forman]

No dělám skoro všechno takto... a to mnoho let zpět a přišlo mi to vždycky naprosto normální. Spíš mě vrtalo hlavou, že někoho baví neustále hledat problém v monolitickém software. Když může v klidu škálovat jednotlivé komponenty horizontálně co se týče výkonu, tak řešit jejich funkcionalitu.

Navíc odtrhávat jednotlivé části za běhu a měnit je třeba za novější s tím, že pokud se to zblázní pořád existuje někde zasunutá ta původní verze, která jde triviálně připojit zpět. Verzování a kooperace mnoha systémů to snad ani nejde jinak ne?

Už v návrhu to rozflákám na komponenty a k nim přiřadím odpovídající data a podle toho, jestli se sdílejí i jejich způsob uložení. Byl jsem na tom, že dneska je to standard už jen kvůli WebSphere, WSO2 bych to bral jako normální.

Jinak to samozřejmě má obvykle odezvy cca 10-300ms obvykle ale těch 50ms třeba na komponentu. To je jistá nevýhoda. Ovšem pokud se podíváte na Google, Yahoo v podstatě jakoukoliv větší firmu nikdo to jinak nedělá.

[anonym]

Tady proste mnozi nepochopili, jak jsem to myslel. Rikam Unix-like. Vite snad, jak v konzoli muzete spojovnim konzolovych aplikaci dosahnout libovolne funkcionality, ne? Ano, ty jednotlive aplikace jsou komponenty vysledneho systemu, muzete o tom rict, ze je to komponentova architektura - to by se potom ale mohli vyrojit Younda s Javamanem a jejich OSGi - nicmene presnejsi je to oznacit jakozto cast Unixove filozofie. Proste mate aplikaci, historicky rekneme psanou v C. Ta aplikace ma standardni vstup a vystup. Kazda ma funkci main(argumenty), protoze se s nejakym nastavenim spusti z konzole. Ano, ta aplikace muze byt web service, ale v prve rade je to konzolova aplikace, jako treba nc. Podle Unixu, takova aplikace ma splnovat nekolik veci - viz kniha Art of Linux programming - nejdulezitejsi z nich je, ze ma delat jednu vec a ma ji delat dobre. Druha vec je, ze ma generovat lidmi citelny vystup.

Ano, v Jave se bezne dela architektura komponentove a modularne.

Komponenta - samostatne spustitelna cast systemu, poskladana z modulu
Modul - ne nutne samostatne spustilna cast systemu, zprostredkovava nejakou funckionalitu a muze byt pouzit ve vicero komponentach

Jenze ja tady to jenze, ze Java je sracka a ja se ji chci vyhybat. Viz Youda a Javaman. A pokud si chce nekdo bez Javy zachovat univerzalnost, tak se muze porad jeste uchylit k unixove architekture vyvoje softwaru.

Tzn. v C++/Qt dektopove a mobilni aplikace, v Pythonu pak webove aplikace a skriptovani.

Master Foo once said to a visiting programmer: “There is more Unix-nature in one line of shell script than there is in ten thousand lines of C.”

The programmer, who was very proud of his mastery of C, said: “How can this be? C is the language in which the very kernel of Unix is implemented!”

Master Foo replied: “That is so. Nevertheless, there is more Unix-nature in one line of shell script than there is in ten thousand lines of C.”

The programmer grew distressed. “But through the C language we experience the enlightenment of the Patriarch Ritchie! We become as one with the operating system and the machine, reaping matchless performance!”

Master Foo replied: “All that you say is true. But there is still more Unix-nature in one line of shell script than there is in ten thousand lines of C.”

The programmer scoffed at Master Foo and rose to depart. But Master Foo nodded to his student Nubi, who wrote a line of shell script on a nearby whiteboard, and said: “Master programmer, consider this pipeline. Implemented in pure C, would it not span ten thousand lines?”

The programmer muttered through his beard, contemplating what Nubi had written. Finally he agreed that it was so.

“And how many hours would you require to implement and debug that C program?” asked Nubi.

“Many,” admitted the visiting programmer. “But only a fool would spend the time to do that when so many more worthy tasks await him.”

“And who better understands the Unix-nature?” Master Foo asked. “Is it he who writes the ten thousand lines, or he who, perceiving the emptiness of the task, gains merit by not coding?”

Upon hearing this, the programmer was enlightened.

zdroj: http://catb.org/esr/writings/unix-koans/ten-thousand.html

[Mirek Prýmek]

Neber si to osobně, ale silně mi to přijde jako vymýšlení kola. Hranatýho.

Spíš se podívej na pojem "microservices". Je to teď aktuální buzzword s coolfaktorem MAX_INT. Jak už to tak bývá, když se toho chytne hipster, kterej to implementuje jenom kvůli tomu cool factoru, může to špatným, neuváženým návrhem totálně zprasit, ale základní myšlenka je v principu správná (microservices se s velkým humbukem v podstatě snaží udělat to, co se v Erlangu používá jako základní princip přes dvacet let). Při návrhu je potřeba rozumně a střízlivě uvažovat nad tím, která komponenta je stavová, která nestavová, kterou můžu libovolně škálovat, jak se budou komponenty v systému vzájemně hledat, kde budou fyzicky běžet, kdo je bude supervidovat apod. Klíčová slova: CoreOS, Project atomic, Kubernetes, Docker Swarm, etcd...

Spustitelné komponenty imho nejsou dobrý nápad - buď je spouštíš s každým requestem, což je neefektivní, nebo někde naslouchají, což zase znamená, že nemají "console API", jak píšeš. Jak budeš se spustitelnou komponentou komunikovat ze vzdáleného stroje?!

Nejpalčivější problém téhle úplně decouplované architektury je v tom, jak zajistit, aby ti nevznikl špagetový systém vzájemného volání API nikdo neví odkud kam a kdy - zašmodrchaný uzel, který nejsi schopnej rozdělit na logické celky. Nedokážeš říct, co přestane fungovat, když vyřadíš nebo upgraduješ nějakou komponentu...

[Reklama]

[Mirek Prýmek]

Druha vec je, ze ma generovat lidmi citelny vystup.

Což je často největší limitace. Zašmodrcháš se do problémů typu "a jak mám vlastně oddělovat jednotlivé názvy souborů, aby ten znak zaručeně nemohl název souboru obsahovat?" viz "find . -print0 | xargs -0".

...o předávání složitějších struktur než pouhá posloupnost stringů ani nemluvě... Kdybys do té tvé architektury fakt šel, skončíš u předávání nějakých serializací (nedejmatkopřírodo JSONem) a nejednou to moc jako dobrý nápad vypadat nebude...

[Kit]

Jenze ja tady to jenze, ze Java je sracka a ja se ji chci vyhybat. Viz Youda a Javaman. A pokud si chce nekdo bez Javy zachovat univerzalnost, tak se muze porad jeste uchylit k unixove architekture vyvoje softwaru.

Tohle ale není problémem Javy, ale vývojářů, kteří nepochopili její filosofii. Vše, co jsi popsal, je možné realizovat v Javě. Navíc bez nutnosti serializace mezi komponentami. Java samotná to umí, jen to většina vývojářů nezvládá.

[anonym]

Ok, tady se to moc rozjelo do teoretizovani, takze pojdme to trochu uzemnit konkretnim usecasem.

Oc se jedna: programator P se chce uzivit a nechce pouzivat Javu a .NET. P se zamysli a uvedomi si: desktopove a mobilni aplikace muzu pokryt vyvojem v C++/Qt. Skriptovani muzu pokryt Pythonem. P ale vi, ze v dnesni dobe to nejde bez webovych aplikaci a ty se v C++ nedelaji. Na ty by proto pouzil Python Django. Jenze P je chytry a vi, ze ikdyz je Python Django peknejsi nez Java frameworky, nedaji se v nem delat vypocetne narocne operace, protoze je mnohokrat pomalejsi nez Java. P tedy premysli, jak z teto situace ven. V tom si P uvedomi:

Kód: [Vybrat]

p2 = subprocess.Popen(["grep", "-c", "test"], stdin=p1.stdout, stdout=subprocess.PIPE)

P zjisti, ze z Pythonu muze mit pristup k mnoha jiz existujicim vytvorenym utilitkam, ktere mu muzou pomoct rychle zpracovat nektere vypocetne narocnejsi tasky. P taky premita, ze podle potreby si nejake utility muze rovnez vytvorit. P je stastny, ze nasel alternativní, univerzalni platformu pro vyvoj.

[Kit]

Kód: [Vybrat]

p2 = subprocess.Popen(["grep", "-c", "test"], stdin=p1.stdout, stdout=subprocess.PIPE)

P zjisti, ze z Pythonu muze mit pristup k mnoha jiz existujicim vytvorenym utilitkam, ktere mu muzou pomoct rychle zpracovat nektere vypocetne narocnejsi tasky. P taky premita, ze podle potreby si nejake utility muze rovnez vytvorit. P je stastny, ze nasel alternativní, univerzalni platformu pro vyvoj.

Tohle vypadá docela dobře, jen k podobným účelům obvykle používám místo Pythonu Bash, ve kterém to vypadá ještě lépe. Je to na volbě.

[Kiwi]

Není ani pravda, že by se to dalo prostě označit jako komponentová architektura, protože to by byl moc obecný pojem. Komponenta totiž nutně neznamená, že se jedná o samostatně spustitelnou aplikaci.

"Samostatně spustitelná aplikace" je už dost konkrétní představa - prostředí, kde jsou nějaké aplikace, které lze nějak spouštět. V tom případě je asi opravdu nejvhodnější obrat unixová koncepce. Např. v tom Forthu to nemělo moc smysl, protože tam se žádné aplikace nespouštěly, ani Forth nebyl aplikací, ale spíše byl sám tím systémem a současně jeho shellem, takže těmi "aplikacemi" byly přímo ty procedury.

[Meh]

Tady proste mnozi nepochopili, jak jsem to myslel. Rikam Unix-like. Vite snad, jak v konzoli muzete spojovnim konzolovych aplikaci dosahnout libovolne funkcionality, ne?

Clovece, tady jsi na rootu, nemuzes na lidi, co bastli Javu nebo .NET pro korporat, vyrukovat hned s pipou. To je jak kdybys na zdrojaku.cz zacal vetou "vite, jak v HTML muzete udelat stranku bez JavaScriptu, ne?".

[anonym]

Kód: [Vybrat]

p2 = subprocess.Popen(["grep", "-c", "test"], stdin=p1.stdout, stdout=subprocess.PIPE)


Tohle vypadá docela dobře, jen k podobným účelům obvykle používám místo Pythonu Bash, ve kterém to vypadá ještě lépe. Je to na volbě.

Ja nejsem moc master of Bash, ale nektere veci zase v Bashi moc dobre nevypadaji, naposledy jsem se stretl treba s regexy a jeste by me trochu mrzelo, ze tim ztratim moznost to spoustet na windowsech, protoze precijen hodne puvodne unixovych utilitek je portovanych i pro ne.

[zboj]

Ok, tady se to moc rozjelo do teoretizovani, takze pojdme to trochu uzemnit konkretnim usecasem.

Oc se jedna: programator P se chce uzivit a nechce pouzivat Javu a .NET. P se zamysli a uvedomi si: desktopove a mobilni aplikace muzu pokryt vyvojem v C++/Qt. Skriptovani muzu pokryt Pythonem. P ale vi, ze v dnesni dobe to nejde bez webovych aplikaci a ty se v C++ nedelaji. Na ty by proto pouzil Python Django. Jenze P je chytry a vi, ze ikdyz je Python Django peknejsi nez Java frameworky, nedaji se v nem delat vypocetne narocne operace, protoze je mnohokrat pomalejsi nez Java. P tedy premysli, jak z teto situace ven. V tom si P uvedomi:

Kód: [Vybrat]

p2 = subprocess.Popen(["grep", "-c", "test"], stdin=p1.stdout, stdout=subprocess.PIPE)

P zjisti, ze z Pythonu muze mit pristup k mnoha jiz existujicim vytvorenym utilitkam, ktere mu muzou pomoct rychle zpracovat nektere vypocetne narocnejsi tasky. P taky premita, ze podle potreby si nejake utility muze rovnez vytvorit. P je stastny, ze nasel alternativní, univerzalni platformu pro vyvoj.

Cele to zní rozumně a užitečně, jen ta komunikace přes roury není moc vhodná, většinou se používá jiná forma meziprocesové komunikace.

[Franta <xkucf03/>]

Už delší dobou si pohrávám s myšlenkou vývoje aplikací Unixovou metodou, kdy jeden funkcni celek se sestavi pospojovanim mensich aplikaci.

Ano, tohle je správná cesta, kterou taky jdu (byť to samozřejmě není univerzální, jsou případy, kdy je lepší monolit nebo jeden jazyk a OOP).

Ale nepředstavuj si to tak, že postavíš velký systém na tom, že pomocí rour pospojuješ jednotlivé příkazy, mezi nimi textové proudy a slepíš to BASHem.

Něco z toho pojede přes unixové sokety, něco přes TCP, pak tu máš technologie jako D-Bus… Zapomeň na to, že si vystačíš s parametry příkazů, protože to je jen pole textových řetězců – na předávání složitějších datových struktur/stromů je to nedostatečné.

Potřebuješ společný jazyk, ve kterém si budeš předávat datové struktury/zprávy – to může být XML, ASN.1, nějaký binární formát… důležité je, aby to mělo schéma a umožnilo ti to verzovat toto API a umělo to generovat struktury a mapování v různých jazycích (ve kterých budeš psát ty moduly), jinak se z toho zblázníš a nebudeš dělat nic jiného než psát serializace/deserializace a mapování a divit se, proč na sebe API nepasují.

A pak potřebuješ nějaký framework, který to bude řídit – umožní nastartovat moduly ve správném pořadí, pospojovat je, umožní vstupovat do jejich komunikace, usnadní ti ladění a vývoj. Nebo takové věci jako upgrade za chodu – chceš aby rozpracované transakce dojely se starou verzí modulů a nové zprávy se už směřovaly do nových verzí příslušných modulů.

V podstatě potřebuješ něco jako ESB, BPEL a WSDL, ale v odlehčenější/nízkoúrovňovější variantě.

V krátkodobém horizontu je to pracnější způsob vývoje – v dlouhodobém se projeví přínosy, větší flexibilita, modularita, efektivnější vývoj, spolehlivější komponenty, tlak na kvalitu, testování… líbí se mi na tom možnost používat různé jazyky, možnost rozložit program na více počítačů na síti, dobře specifikované API.

[javaman ()]

Dam priklad typickeho J, Spring. Doporucil bych kazdemu Javistovi, aby si ho porovnal s Python Django, aby videl, jak ma vypadat webovy framework.

Takže bys chtěl mít Spring jednoúčelový a jednoduchý? To asi pro ty adminy s Pythonem stačí, ale u J potřebuješ daleko složitější věci. Django je dobré pro začátečníky, protože s ním dokážou pracovat. Když Djangu i porozumí, tak můžou přejít na plnohodnotný FW jako Spring.

Youda to napsal hezky. Jedno z možných luxusních využití J. A takových věcí je tam asi milion dalších.

Ja bych na to reagoval Javamane, bohuzel by to nemelo smysl, protoze jsi dement. Tak aspon pro ostatni:

Akorát si ukázal, že o Javě nevíš nic a nemáš žádné zkušenosti. Kdybys totiž nějaké měl třeba s Pythonem a Javou, tak bys podobné nesmysly nevymýšlel. Přijde mi to asi jako když se středoškolák ptá na nápady, které ho napadly. Jsou cool, ale reálně se používají už dávno daleko sofistikovanější postupy. Takže ten tvůj shit není úplně použitelný. Chce to praxi, kámo