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

[Kit]

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.

Bash funguje i ve Windows, jen s těmi pípami je to horší - bez ohledu na to, zda použiješ Bash, Python, PHP či něco jiného.

[Reklama]

[JS]

Mam k puvodni otazce dve poznamky. Prvni je, ze ten "Unixovy pristup" (ktery je asi stale zatim nejvetsi ukazkou znovupouzitelnosti v praxi) dovedlo k dokonalosti funkcionalni programovani. Jak?

Ta hlavni vyhoda Unixoveho pristupu je v tom, ze ta "API" jednotlivych "modulu" jsou vlastne jen (typicky textova a nestrukturovana) data predavana mezi temi aplikacemi. V OOP je typicke API nejaka mnozina akci, a data jsou skryta. Zatimco ve funkcionalnim programovani jsou API vzdy strukturovana data (datove typy) predavana mezi funkcemi. Tedy v FP jde o otoceni situace - misto toho, aby se vykonavaly prikazy, jako v OOP, tak se posilaji jako data. Ten rozdil je v tom, ze v OOP datum rozumi jen cilovy objekt, jenze pokud mas data jako verejne API, tak jim nemusi rozumet jen dany cilovy objekt, jsou pak proste samopopisna. (Ono to v podstate souvisi s tim, ze si pak ty jednotlive aplikace nemohou drzet vlastni kontext/stav, vsechno se musi rict temi vstupnimi daty. Tim, ze se zakaze nebo omezi drzeni kontextu, ktery zna jen dany objekt/funkce, dojde k vetsi znovupouzitelnosti.) Uplne idealni je pak predavat samotne prikazy jako data (viz treba http://degoes.net/articles/modern-fp nebo napady jako CQRS).

V modernim "OOP" se obcas snazi o neco podobneho, ale vetsinou pres ruku delaji neco, co lze snaz udelat v FP.

Druha poznamka je, ze Unixova filozofie je dost stara a mozna uz dnes neaktualni. Vznikla v dobe, kdy byly pocitace drahe a lidska prace levna, dnes je to naopak. Takze tehdy davalo smysl dodavat software jako stavebnici, kterou si zakaznik sam zkonfiguruje, ale dneska po tom IMHO takova poptavka neni. To je ale spis obchodni otazka - vyplati se ti budovat stavebnici, nebo je lepsi udelat jednoucelovou aplikaci?

[Franta <xkucf03/>]

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/

Tak je to prostě blbě napsané. Aplikace v Javě EE nebo Springu může být v pohodě přenasazená v rámci vteřin. Aplikační server ti zachová „session“, takže pokud jsi nezměnil datové struktury v ní uložené, tak si během okamžiku nasadíš novou verzi aplikace a ani se nemusíš znovu přihlašovat.

A pak tu jsou takové věci jako Karaf a Camel a v nich máš aplikaci rozsekanou na menší moduly, můžeš je nasazovat jednotlivě, tam už máš časy pod vteřinu nebo v řádu ms. zprávy/volání se ti doručují do nových instancí modulů – dokonce je to umí pozdržet, dokud nová verze modulu nenaběhne, takže můžeš i upgradovat bez výpadku (požadavek klienta chvilku čeká ve frontě, než nasazení doběhne, ale není odmítnut).

[Franta <xkucf03/>]

Ten tvuj dlouze popsany pokus o znovuvynalezeni kola popisuje podmnozinu funkci OSGi containeru. Doporucuju nastudovat a stahnout si Apache Karaf.
Karaf ma navic podporu maven/blueprint (velice dulezite) a komercni firmy (napr Talend) ti to prodaj predzvykane a dokonce s podporou cluster deploymentu a load balancingu. Tj pokud tvoje aplikace potrebuje nejakou komponentu, system ji poskytne pres adresarovou sluzbu a pokud je servica vzdalena, transparentne ji vola pres ws, aniz by to musela volajici strana resit.

V kostce jde udelat reseni, ze mas na nekolika nodech spustene Karafy napojene na centralni Nexus server, ktery poskutuje JARka od services. Na kazdem Karafu se jenom prdne konfigurace, co na nem ma bezet, karaf si to sam sosne z nexusu a spusti. Vlastni aplikace je pak shluk na ruznych nodech bezicich komponent, ltere si predavaji data. A pokud je v nejake komponente bottleneck, spusti se 5x a Karafu se rekne at loadbalancuje.

Vsechno je to ciste v jave, pokud potrebujes zakomponovat nejake legacy patlaniny, pak se musi napsat pro ne wrapper.

Vetsi modularni systemy se timto zpusobem delaji bezne a napr Eclipse IDE take bezi na OSGi containeru "Eclipse Equinox" - a wtf zadrhely eclipsu opravdu nejsou zpusobeny OSGi containerem.

1) Tohle zní přímo idilicky :-) Zrovna na jednom projektu s Karafem a Camelem dělám. Můj závěr z toho je, že je to použitelná technologie, ale není to všespásné ani se nejedná o „stříbrnou kulku“ – je to technologie jako každá jiná, v něčem je to lepší než Java EE (nebo Spring) a v něčem horší.

2) Přestože jsem skalní Javista, tak i já se dívám podobným směrem jako tazatel – někdy to prostě chce nízkoúrovňovější lehčí řešení a navíc je fajn být nezávislý na konkrétním programovacím jazyku a mít možnost skládat systém z komponent psaných v různých jazycích.

[javaman ()]

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/

Tak je to prostě blbě napsané. Aplikace v Javě EE nebo Springu může být v pohodě přenasazená v rámci vteřin. Aplikační server ti zachová „session“, takže pokud jsi nezměnil datové struktury v ní uložené, tak si během okamžiku nasadíš novou verzi aplikace a ani se nemusíš znovu přihlašovat.

A pak tu jsou takové věci jako Karaf a Camel a v nich máš aplikaci rozsekanou na menší moduly, můžeš je nasazovat jednotlivě, tam už máš časy pod vteřinu nebo v řádu ms. zprávy/volání se ti doručují do nových instancí modulů – dokonce je to umí pozdržet, dokud nová verze modulu nenaběhne, takže můžeš i upgradovat bez výpadku (požadavek klienta chvilku čeká ve frontě, než nasazení doběhne, ale není odmítnut).

+1

[Reklama]

[Kit]

Tim, ze se zakaze nebo omezi drzeni kontextu, ktery zna jen dany objekt/funkce, dojde k vetsi znovupouzitelnosti.) Uplne idealni je pak predavat samotne prikazy jako data (viz treba http://degoes.net/articles/modern-fp nebo napady jako CQRS).

V modernim "OOP" se obcas snazi o neco podobneho, ale vetsinou pres ruku delaji neco, co lze snaz udelat v FP.

Tohle provozuji v OOP zcela běžně a funguje to skvěle. Objekty se tak stávají virtuálními procesory, které se konfigurují v konstruktoru či jiném builderu a kterými data protékají v podobě strukturovaných či objektových zpráv.

Druha poznamka je, ze Unixova filozofie je dost stara a mozna uz dnes neaktualni. Vznikla v dobe, kdy byly pocitace drahe a lidska prace levna, dnes je to naopak. Takze tehdy davalo smysl dodavat software jako stavebnici, kterou si zakaznik sam zkonfiguruje, ale dneska po tom IMHO takova poptavka neni. To je ale spis obchodni otazka - vyplati se ti budovat stavebnici, nebo je lepsi udelat jednoucelovou aplikaci?

Unixová filosofie je v dnešní době naopak výhodná, neboť každý dílčí proces může běžet v samostatném jádře. Lépe se tedy využije HW vícejádrových procesorů nebo i více serverů.

[gll]

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.

dělat tohle ve webové aplikaci je blbost. Zjisti si, proč se přestalo používat CGI.

když už to chceš dělat ve scriptech, existují vhodnější knihovny než subprocess.

https://plumbum.readthedocs.io/en/latest/
https://amoffat.github.io/sh/

neobjevil jsi nic nového. Tento přístup se běžně používá, ale ne ve webových aplikacích, které mají běžet rychle.

[Franta <xkucf03/>]

Jinak to samozřejmě má obvykle odezvy cca 10-300ms obvykle ale těch 50ms třeba na komponentu. To je jistá nevýhoda.

Ne, čekat tolik ms. na zavolání jedné funkce/podprocesu je za hranicí použitelnosti. Tedy pokud se nejedná o dlouhodobější úlohy běžící desitky vteřin nebo déle (tam si klidně 50 ms. můžeš „navazovat spojení“ a už tě to nevytrhne) nebo věci které voláš jednou a za dlouho. Ještě bych si to dovedl představit na desktopu, kde u výkonného počítače sedí jeden uživatel a občas nějakou takovou akci vyvolá – tam je výkonu nadbytek a i těch 300 ms. bude uživatel vnímat jako okamžik. Jakmile bys to ale chtěl dát na server, ke kterému přistupuje víc uživatelů, nebo ty akce provádíš často, tak to půjde do háje a tyhle časy jsou smrtelné.

Řešením jsou trvale běžící moduly/procesy, které během své životnosti vyřídí mnoho požadavků – démoni. A nemusí běžet pořád – může tam být nějaká orchestrace, nějaký framework, který je spouští v případě potřeby – ať už systemd se „socket activation“ nebo něco na způsob PHP-FPM nebo podobný nástroj. Modul/proces se vytvoří, když je potřeba, nebo si vytvoříš pár instancí do zásoby předem, pak vyřídí řadu požadavků a když není delší dobu potřeba, tak ho framework uspí nebo ukončí. A hlavně tohle chování je konfigurovatelné a řídí ho ten framework – nikoli volající nebo volaná komponenta – podobně jako třeba u „poolu“ databázových spojení v aplikačním serveru.

[Franta <xkucf03/>]

Druha poznamka je, ze Unixova filozofie je dost stara a mozna uz dnes neaktualni. Vznikla v dobe, kdy byly pocitace drahe a lidska prace levna, dnes je to naopak. Takze tehdy davalo smysl dodavat software jako stavebnici, kterou si zakaznik sam zkonfiguruje, ale dneska po tom IMHO takova poptavka neni. To je ale spis obchodni otazka - vyplati se ti budovat stavebnici, nebo je lepsi udelat jednoucelovou aplikaci?

Ono to bude firmu od firmy různé, ale často se právě ta flexibilita bude hodit – místo abys objednával změnové požadavky, vyjednával o jejich ceně, čekal na vydání nové verze a nasazení monolitu, tak je lepší, když máš stavebnici, ve které si můžeš aspoň některé věci udělat sám – dodavatel ti dodává ty stavební kostky, ale když je chceš použít trochu jinak, než bylo původně plánováno, tak to uděláš – teď hned, otestuješ si to sám a nasadíš – a tím ušetříš tu drahou lidskou práci.

[javaman ()]

Ono to bude firmu od firmy různé, ale často se právě ta flexibilita bude hodit – místo abys objednával změnové požadavky, vyjednával o jejich ceně, čekal na vydání nové verze a nasazení monolitu, tak je lepší, když máš stavebnici, ve které si můžeš aspoň některé věci udělat sám – dodavatel ti dodává ty stavební kostky, ale když je chceš použít trochu jinak, než bylo původně plánováno, tak to uděláš – teď hned, otestuješ si to sám a nasadíš – a tím ušetříš tu drahou lidskou práci.

Aha, takže to testování a stavění je zadarmo? Proto chce každý hotové řešení. Nikdo si tam nic ladit nebude a pokud jo, tak jen proto, že je to moc specifické pro jeho byznys a nejde to předpřipravit více.

[Franta <xkucf03/>]

Aha, takže to testování a stavění je zadarmo?

Není zadarmo. Ale spolupráce mezi více lidmi taky ne – má velkou režii – a spolupráce mezi lidmi v různých firmách má režii ještě větší. Proto je řešení vlastními silami a skládačka/parametrizace často lepší volba než monolitické řešení na klíč dodané komplet externí firmou.

[čumil]

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.

1) v pythonu se nedělají webové aplikace, webová aplikace běží v prohlížeči a jsou psané v JS nebo v něčem co se do něj kompiluje, python můžeš maximálně použít jako webovou servisu (nedejbože se statickým renderováním na straně serveru...dneska už zastaralym).
2) dělat do webového vývoje bez JS je dneska už minulost, před 10 lety to šlo, dneska už ne.
3) dělat desktopové aplikace v C++ je overkill, C++ už se dneska používá buď v legacy systemech a nebo v embedded vývoji. I tu AI bys dneska dělal v python, přečemž jako backend bys měl tensorflow nebo cntk. Mimo svoje niche se C++ opouští na ukor Javy a C#. Zvláště Java teď zažívá v době big data hotovou renesanci. Kdybych do toho dělal, a nebo chtěl dělat, Java je must have.

Závěrem, vybral sis kompletně nevhodné technologie na to co chceš dělat a pokud si nezaložíš vlastní živnost, neseženeš v tom práci.
Respektive seženeš, ale budeš mít málo na výběr a budeš dělat na zastaralejch věcech.

4) už jen to že soudíš javu podle toho jak je psaná dokumentace o tobě něco říká
je to jako říkat že common lisp je sračka jen protože dokumetace je ještě v horším stavu.

[Kit]

Jinak to samozřejmě má obvykle odezvy cca 10-300ms obvykle ale těch 50ms třeba na komponentu. To je jistá nevýhoda.

Ne, čekat tolik ms. na zavolání jedné funkce/podprocesu je za hranicí použitelnosti. Tedy pokud se nejedná o dlouhodobější úlohy běžící desitky vteřin nebo déle (tam si klidně 50 ms. můžeš „navazovat spojení“ a už tě to nevytrhne) nebo věci které voláš jednou a za dlouho. Ještě bych si to dovedl představit na desktopu, kde u výkonného počítače sedí jeden uživatel a občas nějakou takovou akci vyvolá – tam je výkonu nadbytek a i těch 300 ms. bude uživatel vnímat jako okamžik. Jakmile bys to ale chtěl dát na server, ke kterému přistupuje víc uživatelů, nebo ty akce provádíš často, tak to půjde do háje a tyhle časy jsou smrtelné.

I těch 300 ms může být opruzujících. Mám plugin do Vimu, který jsem si napsal v Javě. Těch 300 ms mi skutečně vadilo. Problém vyřešil až gcj, který ten čas významně zkrátil.

Samozřejmě jsem uvažoval i o démonovi, který bych použil, pokud by to nestačilo. V záloze byla i další řešení, která jsem však použít nemusel.

[javaman ()]

300 ms je pomalá sračka, to je tak dobré u prototypu. Kdyby se takhle opravdu dělalo v Javě, tak to není nejpopulárnější jazyk.

[Mirek Prýmek]

P zjisti, ze z Pythonu muze mit pristup k mnoha jiz existujicim vytvorenym utilitkam, ktere mu muzou pomoct rychle zpracovat nektere vypocetne narocnejsi tasky.

To se už dávno používá, protože Python sám o sobě je hodně pomalý, jeden z nejpomalejších jazyků vůbec. Všechny ty "vědecké výpočty v Pythonu" spočívají v tom, že se pomocí Pythonu lepí dohromady céčkové knihovny, které dělají ten vlastní výkonově náročný výpočet. Je to docela dobrý přístup - v Pythonu se píše rychle a pohodlně a céčková implementace tomu dodá patřičný švih. Akorát ten GIL to trochu hatí

...ale přes roury s lidsky čitelnou serializací se to fakt nedělá, to by ses daleko nedostal...