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

anonym

Vytváření aplikačních systémů Unix-like metodou
« kdy: 25. 02. 2017, 22:48:19 »
Už delší dobou si pohrávám s myšlenkou vývoje aplikací Unixovou metodou, kdy jeden funkcni celek se sestavi pospojovanim mensich aplikaci. Tyto aplikace slouzi vlastne zaroven jako moduly. Velice se mi to libi a reknu proc:

  • Nejsem zavisly na jednom jazyku, protoze vysledkem neni knihovna, ale spustitelna aplikace. V konecnem systemu muze byt nejaky modul napsany v C, jiny v Go, jiny treba v Pythonu.
  • Tim, ze nejsem zavisly na jednom jazyku, tedy i jeho ekosystemu, muzu Unix-like vyvojem dosahnout ohromne univerzalnosti, o jake se nezda zadne existujici vyvojove platforme.
  • Jedna se o system, kde moduly doopravdy splnuji princip zapouzdreni. Dokud aplikace funguje tak jak ma, zajima me jen jeji API a k nemu dokumentace. Co me vadi na OOP je, ze mam nejakou knihovnu (ktera vlastne bude plnit funkci modulu) a malokdy se mi stane, ze do ni nemusim lezt a divat se, jak to tam funguje, protoze samozrejme nema jasne definovany API a tim padem ani jasnou dokumentaci, pokud nejakou vubec ma.
  • Nebude dochazet ke zneuzivani Unit testu jako v v praxi v OOP, bude bohate stacit otestovat aplikaci smerem od jejiho API.
  • Za velice dulezite povazuju ono konzole-like API. Tim se totiz automaticky definuje, jak ma to API vypadat, jak se ma ta aplikace pouzivat (nastaveni a dale pak input a  output streamy) a jak ma k nemu vypadat dokumentace. Davat to do protikladu k OOP modulum. Ty proste maji sadu trid a balicku a to ma jakoze byt to API, jenze casto to neni zdokumentovane a je to proste bida.
  • Unixova filozofie spojovani aplikaci je brutus a cool

No a v jakem kontextu me to vlastne napada. Napada me to v kontextu prave toho OOP. Prijde mi proste lepsi, ze pokud chci nejakou funkcionalitu, neporidim si knihovnu, ktera to bude umet, ale poridim si konzolovou aplikaci. Prave kvuli tomu jasne definovanemu API, ktere je potom i snadnejsi zdokumentovat. Nemusim se potom te aplikaci hrabat ve vnitrnostech, jako to casto byva u OOP knihovny.

A napada me to jeste v jednom kontextu. Strasne me sere jedna platforma, kterou zde konkretne nebudu zminovat. Budu ji rikat platforma J. Nejsem spokojen s tim, jak v J probiha vyvoj, predevsim webovych aplikaci, a jak vypadaji webove frameworky. A s par dalsima vecma. Jenze mimo jistou J je tady .NET a to je Microsoftu vec. Takze krome J a Microsoftu, pokud chce byt clovek univerzalni, znamena to, ze potrebuje neco, v cem muze rovnez na urovni delat webove aplikace. A nic takoveho tady nezbyva. Krome jedne veci a tou je Unix-like typ vyvoje.

Napada me proto, ze se preorientuju na nasleduji weapons of choice: Python + Go + C. Co rikate, da se s tim dobre uzivit?
« Poslední změna: 26. 02. 2017, 20:53:18 od Petr Krčmář »


čumil

Hezka vize, ale používá se už někde jinde a z jiných důvodů než jak jsi popsal.

Co se tyče serverove služby, tadle filozofie bude spíš obtíž.

Ale neboj, mission critical systemy jsou takhle psaný.

A dokumentací to nebude ...

anonym

Nemyslím si že bude obtíž. Servrovou službu uděláš klidně celou v Pythonu. Můžeš výpočetně náročné části napsat v něčem jiném. Jde o specializaci programátora: Python + Go + C, abych nebyl jen bušič kódu v Pythonu.

Kit

Nápad to rozhodně není špatný, je to vlastně správně uchopené OOP. O nesmyslnosti mnohých "objektových" knihoven a frameworků jsem toho ostatně již napsal dost. Touto formou své aplikace běžně píši a nemohu si ji vynachválit. Výsledné aplikace jsou jednoduché, rychlé a spolehlivé.

Jinou stránkou je však obchodní model. Pokud zadavatel chce, abys celou aplikaci napsal v J, tak nějaká kombinace jiných jazyků ho nijak neoslní. Proto předstírám, že píši v jazyce P, ale uvnitř volám binární moduly pro interpretaci jazyků S a X, které tu svěřenou práci zvládají mnohem lépe než jazyk P. V jazyce J tohle není možné.

Kiwi

V podstatě jsi tu načrtl komponentově orientovaný návrh. Svého času byl docela populární v souvislosti s jazykem Forth.


Lemming

No, podle toho co jsi napsal není problém v OOP, ale v chybějící dokumentaci. Další věc je, že dokumentace k jednoduché utilitce se píše a udržuje ještě dobře, ale v okamžiku, kdy se věci zesložití, tak už je to horší.

V principu nevidím problém na tom, podívat se kvůli nějakým detailům chování do zdrojáku. Mám heslo "dobře napsaný a okomentovaný zdroják je nejlepší dokumentace". Mimo jiné proto, že nikdy není zastaralý, což u dokumentace bývá často problém.

Pokud bys to chtěl dělat opravdu UNIX-like, tak narazíš také na to, že předávat komplikovanější strukturovaná data mezi utilitami je docela problém.

Mimochodem, existuje spousta systémů sestavených z komponent a podobných tomu, co píšeš. Říká se tomu WebServices a píšou se velmi často v J a za pomoci OOP ;) Takže v jazyku/OOP to fakt nebude. :)

gll

Nic ti nebrání psát CGI skripty v bashi. Tohle můžeš praktikovat tam kde nejde o výkon. Spouštění utilit má ohromnou režii. Další nevýhoda je, že předávaná data musíš převádět na text a zpět. Ztrácíš typovou kontrolu.

Asi ti nejde tolik o dokumentaci jako o možnost is ty utility (funkce) interaktivně vyzkoušet. Zkus použít jazyk s REPLem.

Pro údržbu a reportování vlastní command line utility používám. Nic mě nenutí psát lepší dokumentaci než k běžným funkcím.

anonym

No, podle toho co jsi napsal není problém v OOP, ale v chybějící dokumentaci.

Ono není problém v tom komunismu, soudruzi. Ale v té zlovůli imperialistů a nedostatečné politické uvědomělosti lidu naši rozvalité socialistické vlasti.

gll

No, podle toho co jsi napsal není problém v OOP, ale v chybějící dokumentaci.

Ono není problém v tom komunismu, soudruzi. Ale v té zlovůli imperialistů a nedostatečné politické uvědomělosti lidu naši rozvalité socialistické vlasti.

On má pravdu. Ty si stěžuješ na dokumentaci, která s jazykem nesouvisí.

Youda

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.

anonym

No, podle toho co jsi napsal není problém v OOP, ale v chybějící dokumentaci.

Ono není problém v tom komunismu, soudruzi. Ale v té zlovůli imperialistů a nedostatečné politické uvědomělosti lidu naši rozvalité socialistické vlasti.

On má pravdu. Ty si stěžuješ na dokumentaci, která s jazykem nesouvisí.

Ja bych rekl ze s jazykem teda souvisi dost a malokdo si to uvedomuje, protoze dokumentace vyzaduje usili a to je v J dost spotrebovavano jinymi vecmi.

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


Youda: zaprve ja nevynalezam kolo, to bych asi nemluvil o Unix-like metode vyvoje sw, cimz implicitne rikam, ze se to tak dela v Unixu. Zadruhe, to co ja mam na mysli je ponekud odlisne od OSGi kontejneru.

anonym

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.

anonym

Ad volani jine aplikace je strasne drahe. Neni nutne drahe. Kdyz se nejaka aplikace A rozjede, tak se predpoklada, ze se s ni potom komunikuje pres standardni vstup/vystup a to jde samozrejem pres pamet. Ta aplikace zustane bezet po celou dobu, ikdyz nema co zpracovat. Je to proste jako se v Unixu spojuji aplikace v bashi prostrednictvi píp.
Dale nemyslim si, ze je v dnesni dobe nejaky problem co se vykonosti tyce, komunikovat pomoci citelneho textového streamu.

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.

čumil

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.
No pane jo, ta Java fakt ma dobrý nastroje.
Ma něco podobnýho i c#?