Fórum Root.cz

Hlavní témata => Vývoj => Téma založeno: anonym 25. 02. 2017, 22:48:19

Název: Vytváření aplikačních systémů Unix-like metodou
Přispěvatel: anonym 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:


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?
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: čumil 25. 02. 2017, 23:02:45
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 ...
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: anonym 25. 02. 2017, 23:10:19
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Kit 25. 02. 2017, 23:12:36
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é.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Kiwi 25. 02. 2017, 23:27:30
V podstatě jsi tu načrtl komponentově orientovaný návrh. Svého času byl docela populární v souvislosti s jazykem Forth.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Lemming 26. 02. 2017, 00:10:36
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. :)
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: gll 26. 02. 2017, 00:16:29
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: anonym 26. 02. 2017, 00:50:11
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: gll 26. 02. 2017, 00:59:37
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í.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Youda 26. 02. 2017, 09:12:04
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: anonym 26. 02. 2017, 10:18:09
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: anonym 26. 02. 2017, 10:42:30
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: anonym 26. 02. 2017, 10:48:36
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: javaman () 26. 02. 2017, 10:54:35
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: čumil 26. 02. 2017, 11:09:21
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#?
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: anonym 26. 02. 2017, 11:25:48
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: anonym 26. 02. 2017, 11:34:22
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/
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Jan Forman 26. 02. 2017, 11:37:18
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á.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: anonym 26. 02. 2017, 12:03:57
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.

Citace
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
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Mirek Prýmek 26. 02. 2017, 12:06:15
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...
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Mirek Prýmek 26. 02. 2017, 12:11:49
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...
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Kit 26. 02. 2017, 12:38:24
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á.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: anonym 26. 02. 2017, 12:53:16
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Kit 26. 02. 2017, 13:03:18
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ě.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Kiwi 26. 02. 2017, 13:03:52
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Meh 26. 02. 2017, 13:16:32
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?".
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: anonym 26. 02. 2017, 13:36:46
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: zboj 26. 02. 2017, 13:40:03
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Franta <xkucf03/> 26. 02. 2017, 13:50:09
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: javaman () 26. 02. 2017, 13:52:27
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 8)
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Kit 26. 02. 2017, 14:03:24
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: JS 26. 02. 2017, 14:10:27
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 (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?
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Franta <xkucf03/> 26. 02. 2017, 14:16:12
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).
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Franta <xkucf03/> 26. 02. 2017, 14:22:17
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: javaman () 26. 02. 2017, 14:25:11
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
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Kit 26. 02. 2017, 14:34:32
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 (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ů.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: gll 26. 02. 2017, 14:47:06
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Franta <xkucf03/> 26. 02. 2017, 14:51:26
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Franta <xkucf03/> 26. 02. 2017, 14:58:16
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: javaman () 26. 02. 2017, 15:01:04
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Franta <xkucf03/> 26. 02. 2017, 15:08:41
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: čumil 26. 02. 2017, 15:15:12
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Kit 26. 02. 2017, 15:28:09
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: javaman () 26. 02. 2017, 15:40:10
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.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Mirek Prýmek 26. 02. 2017, 15:46:41
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...
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Kit 26. 02. 2017, 16:00:23
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.

Javovský program se rychleji spustit nedá. Obvykle nabíhá několik sekund až minut.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Franta <xkucf03/> 26. 02. 2017, 16:13:36
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.

Javovský program se rychleji spustit nedá. Obvykle nabíhá několik sekund až minut.

Spustit se dá za cca 100 ms – zde např. ukázka mého programu, když vypisuje verzi:

$ time sql-dk --version
SQL-DK
Mercurial: eb1ca1395ab3+ tip
Compiled:  2016-11-09 00:15:39+01:00

Copyright © 2013 Ing. František Kučera a.k.a. <xkucf03/>
https://sql-dk.globalcode.info/ https://frantovo.cz/
SQL-DK is free softare. You may redistribute copies of SQL-DK
under the terms of the GNU General Public License v3+.
For more information about these matters, run with option: --license

real    0m0.111s
user    0m0.108s
sys     0m0.028s


$ java -version
openjdk version "1.8.0_121"
OpenJDK Runtime Environment (build 1.8.0_121-8u121-b13-0ubuntu1.16.04.2-b13)
OpenJDK 64-Bit Server VM (build 25.121-b13, mixed mode)

$ cat /proc/cpuinfo |  grep "model name" | head -n1
model name      : AMD FX(tm)-8350 Eight-Core Processor


Jasně, oproti C je to pomalé a taky to takhle nebude chodit třeba na nějakém slabém ARMu, ale i tak jsou dnes ty rychlosti úplně někde jinde, než si myslí lidi, co na Javu obvykle nadávají a zasekli se někde v 90. letech.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: javaman () 26. 02. 2017, 16:14:22
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.

Javovský program se rychleji spustit nedá. Obvykle nabíhá několik sekund až minut.

Ono totiž spouštění nikoho nezajímá. To je jako chtít mít nádrž u auta plnou během jedné vteřiny. Není prostě jak.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: javaman () 26. 02. 2017, 16:17:09
Pořád nechápu, proč by někoho mělo spouštění zajímat. Java si natahuje hromady věcí, které potřebuješ a často ani nepotřebuješ za chodu. U velkých aplikací je ten poměr lepší a chceš mít hodně funkcionality.

Hlavně tenhle "problém" řeší i Java 9, takže pak už nevím, co hateři zase vymyslí :D
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: JS 26. 02. 2017, 16:18:08
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.

Ano, jak rikam, programujes funkcionalne v OOP jazyce, delas si to zbytecne slozitejsi. :-) (V FP se tem "virtualnim procesorum" rika funkce, "builderum" se rika currying a tem "strukturovanym zpravam" se rika argumenty.)

Citace
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ů.

O tom moje namitka vubec neni. Paralelismus se da realizovat mnoha zpusoby, vertikalne i horizontalne.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Kit 26. 02. 2017, 16:22:53
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.

Javovský program se rychleji spustit nedá. Obvykle nabíhá několik sekund až minut.

Ono totiž spouštění nikoho nezajímá. To je jako chtít mít nádrž u auta plnou během jedné vteřiny. Není prostě jak.

Nejprve jsi napsal, že 300 ms je pomalá sračka a teď píšeš, že čas spouštění nikoho nezajímá. Tak si to laskavě nejdřív srovnej a pak piš.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: gll 26. 02. 2017, 16:24:39
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...

Roury mohou být užitečné. Zejména při práci s velkými soubory. Ale určitě ne tak univerzální jak píše anonym.

V c api se dá pracovat s iterátory, ale je to dost komplikované. Jednodušší je použít oddělenou utilitu.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: javaman () 26. 02. 2017, 16:25:28
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.

Javovský program se rychleji spustit nedá. Obvykle nabíhá několik sekund až minut.

Ono totiž spouštění nikoho nezajímá. To je jako chtít mít nádrž u auta plnou během jedné vteřiny. Není prostě jak.

Nejprve jsi napsal, že 300 ms je pomalá sračka a teď píšeš, že čas spouštění nikoho nezajímá. Tak si to laskavě nejdřív srovnej a pak piš.

Někdo psal, že 300 ms čeká na odpověď. Odpověď by měla být v řádu milisekund a méně. Samozřejmě záleží na složitosti, ale stovky milisekund je hodně mimo reálné použití.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: gll 26. 02. 2017, 16:29:36
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.

Ano, jak rikam, programujes funkcionalne v OOP jazyce, delas si to zbytecne slozitejsi. :-) (V FP se tem "virtualnim procesorum" rika funkce, "builderum" se rika currying a tem "strukturovanym zpravam" se rika argumenty.)

Novější PHP má pro tohle generátory a coroutiny.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Kit 26. 02. 2017, 16:34:59
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.

Javovský program se rychleji spustit nedá. Obvykle nabíhá několik sekund až minut.

Ono totiž spouštění nikoho nezajímá. To je jako chtít mít nádrž u auta plnou během jedné vteřiny. Není prostě jak.

Nejprve jsi napsal, že 300 ms je pomalá sračka a teď píšeš, že čas spouštění nikoho nezajímá. Tak si to laskavě nejdřív srovnej a pak piš.

Někdo psal, že 300 ms čeká na odpověď. Odpověď by měla být v řádu milisekund a méně. Samozřejmě záleží na složitosti, ale stovky milisekund je hodně mimo reálné použití.

Z Vimu spustím program napsaný v Javě a na jeho výsledek, který se vrací zpět do Vimu, jsem nejprve čekal 300 ms od povelu ke spuštění. Proto jsem to překompiloval v gcj, aby se to spouštění urychlilo. Teď je to o něco rychlejší, to čekání už není tak hrozné.

Je jasné, že kdyby ten javovský program byl už v paměti jako démon, bylo by to rychlejší.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: javaman () 26. 02. 2017, 16:38:18
Z Vimu spustím program napsaný v Javě a na jeho výsledek, který se vrací zpět do Vimu, jsem nejprve čekal 300 ms od povelu ke spuštění. Proto jsem to překompiloval v gcj, aby se to spouštění urychlilo. Teď je to o něco rychlejší, to čekání už není tak hrozné.

Je jasné, že kdyby ten javovský program byl už v paměti jako démon, bylo by to rychlejší.

Tyhle píčoviny nikoho nezajímaj. Řešilo se úplně něco jiného, pokud se nepletu. A pokud se pletu, tak je to jedno, protože jen retard bude pouštět program pořád dokola, který má několik mega závislostí pro spuštění.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Kit 26. 02. 2017, 16:46:49
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.

Ano, jak rikam, programujes funkcionalne v OOP jazyce, delas si to zbytecne slozitejsi. :-) (V FP se tem "virtualnim procesorum" rika funkce, "builderum" se rika currying a tem "strukturovanym zpravam" se rika argumenty.)

Ve FP se těm "virtuálním procesorům" spíš říká closures nebo currying, ne? Nezapomeň, že se ten virtuální procesor musí nejprve nakonfigurovat (nejlépe konstruktorem) a pak teprve je možné ho používat.

V OOP se těm "strukturovaným zprávám" také říká argumenty. Napsal jsem to takhle, aby sis nemyslel, že objektům jako argumenty posílám nějaké primitivní datové typy (jak je dnes bohužel běžné u *etterů). Jsou to prostě zprávy, na kterých je OOP založeno.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Kit 26. 02. 2017, 16:55:27
Z Vimu spustím program napsaný v Javě a na jeho výsledek, který se vrací zpět do Vimu, jsem nejprve čekal 300 ms od povelu ke spuštění. Proto jsem to překompiloval v gcj, aby se to spouštění urychlilo. Teď je to o něco rychlejší, to čekání už není tak hrozné.

Je jasné, že kdyby ten javovský program byl už v paměti jako démon, bylo by to rychlejší.

Tyhle píčoviny nikoho nezajímaj. Řešilo se úplně něco jiného, pokud se nepletu. A pokud se pletu, tak je to jedno, protože jen retard bude pouštět program pořád dokola, který má několik mega závislostí pro spuštění.

Aha, zřejmě jsi ještě nepoužil Javu jako CLI. Prostě se spustí JRE s nějakým JARem, předají se mu pípou nějaká vstupní data a ve výstupní pípě dostaneš výsledek. Tohle mi za normálních okolností zabere těch 300 ms a program končí. S gcj se to zkrátilo na přijatelný čas.

O jakém mega závislostí to píšeš?
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Kit 26. 02. 2017, 17:02:07
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.

Ano, jak rikam, programujes funkcionalne v OOP jazyce, delas si to zbytecne slozitejsi. :-) (V FP se tem "virtualnim procesorum" rika funkce, "builderum" se rika currying a tem "strukturovanym zpravam" se rika argumenty.)

Novější PHP má pro tohle generátory a coroutiny.

To sice ano, ale pro vlastní virtuální procesor se specifickými vlastnostmi si ten generátor musíš napsat sám. Říká se tomu třída :)
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Mirek Prýmek 26. 02. 2017, 17:04:56
Roury mohou být užitečné.
Roury jsou užitečné - ale na to, na co se používají, ne v té znásilněné podobě, kterou navrhuje anonym.

Pokud chci, aby něco bylo rychlé, nesmím data často převádět z jedné reprezentace na jinou. Častá serializace a následná deserializace je spolehlivý zabiják výkonu (to je i slabé místo těch microservices, zvlášť pokud se použije http a json, což je teď móda). A úplně ideální je s datama ani nehejbat - radši pamět sdílím než kopíruju.

Čili anonym to možná myslí dobře, ale vymýšlí prostě hranaté kolo. Lepší by bylo si nastudovat existující používané architektury a případně přemýšlet nad tím, jak je vylepšit, než si myslet, že všichni na světě jsou pitomci, všechno dělají blbě a já teď vyřeším všechny problémy světa zcela geniálním způsobem, kterej ještě nikdy nikoho nenapadl :)
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: gll 26. 02. 2017, 18:49:23
To sice ano, ale pro vlastní virtuální procesor se specifickými vlastnostmi si ten generátor musíš napsat sám. Říká se tomu třída :)

Nevím čemu říkáš virtuální procesor. Diskutovalo se tu o utilitách typu grep.

Kód: [Vybrat]
function grep ($in, $pattern) {
    foreach ($in as $line) {
        if(preg_match($pattern, $line)){
            yield $line;
        }
    }
}

k čemu by byla třída?
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Franta <xkucf03/> 26. 02. 2017, 18:57:49
k čemu by byla třída?

Třeba tomu, abys ji mohl jednou naparametrizovat a opakovaně použít nebo si v ní držet zkompilovaný regulární výraz.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: gll 26. 02. 2017, 19:06:24
k čemu by byla třída?

Třeba tomu, abys ji mohl jednou naparametrizovat a opakovaně použít nebo si v ní držet zkompilovaný regulární výraz.

v php se regulární výrazy AFAIK cachují. Stejný výraz se nezkompiluje dvakrát. Pro parametrizování se dá použít i uzávěr.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Kit 26. 02. 2017, 19:24:42
k čemu by byla třída?

Třeba tomu, abys ji mohl jednou naparametrizovat a opakovaně použít nebo si v ní držet zkompilovaný regulární výraz.

v php se regulární výrazy AFAIK cachují. Stejný výraz se nezkompiluje dvakrát. Pro parametrizování se dá použít i uzávěr.

xkucf03 to vystihl. Pro jednoduché úkoly se dá využít i uzávěr, ale na ty složitější (s více metodami) je mnohem výhodnější si napsat třídu. Také je dobré udržovat nějakou kulturu projektu. Používat uzávěry na stejném levelu jako objekty se mi jeví jako hůře přehledné.

Proč bych měl používat uzávěr, když mohu použít plnohodnotný objekt, se kterým se lépe pracuje a mnohem snáze se rozšiřuje o další metody? V případě uzávěrů bývá problém i s pojmenováním - jedno slovo zpravidla nestačí. U objektů je to mnohem jednodušší: objekt.akce().
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: gll 26. 02. 2017, 19:46:30
k čemu by byla třída?

Třeba tomu, abys ji mohl jednou naparametrizovat a opakovaně použít nebo si v ní držet zkompilovaný regulární výraz.

v php se regulární výrazy AFAIK cachují. Stejný výraz se nezkompiluje dvakrát. Pro parametrizování se dá použít i uzávěr.

xkucf03 to vystihl. Pro jednoduché úkoly se dá využít i uzávěr, ale na ty složitější (s více metodami) je mnohem výhodnější si napsat třídu. Také je dobré udržovat nějakou kulturu projektu. Používat uzávěry na stejném levelu jako objekty se mi jeví jako hůře přehledné.

Proč bych měl používat uzávěr, když mohu použít plnohodnotný objekt, se kterým se lépe pracuje a mnohem snáze se rozšiřuje o další metody? V případě uzávěrů bývá problém i s pojmenováním - jedno slovo zpravidla nestačí. U objektů je to mnohem jednodušší: objekt.akce().

Diskutovalo se tu o obdobě shellových utilit. To je typicky jedna metoda (funkce).
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Kit 26. 02. 2017, 20:10:41
Diskutovalo se tu o obdobě shellových utilit. To je typicky jedna metoda (funkce).

Typická shellová utilita mívá minimálně jeden parametr, který říká, co se s těmi vstupními daty má udělat. Tedy pokud to nemá být vyloženě jednoúčelové, jako např. gzip.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: gll 26. 02. 2017, 20:19:20
Diskutovalo se tu o obdobě shellových utilit. To je typicky jedna metoda (funkce).

Typická shellová utilita mívá minimálně jeden parametr, který říká, co se s těmi vstupními daty má udělat. Tedy pokud to nemá být vyloženě jednoúčelové, jako např. gzip.

Ano. Je to jedna funkce s nějakými parametry.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Franta <xkucf03/> 26. 02. 2017, 21:08:40
Diskutovalo se tu o obdobě shellových utilit. To je typicky jedna metoda (funkce).

Typická shellová utilita mívá minimálně jeden parametr, který říká, co se s těmi vstupními daty má udělat. Tedy pokud to nemá být vyloženě jednoúčelové, jako např. gzip.

Ano. Je to jedna funkce s nějakými parametry.

Jenže to je dané tím, že to v shellu jinak nejde a nemáš si jak držet stav mezi jednotlivými voláními.
Např. když přes find a xargs budeš zmenšovat obrázky, tak musíš tu velikost předávat pořád dokola jako parametry.
Kdežto v objektovém programovacím jazyce by sis inicializoval objekt, který bude zodpovědný za to zmenšování, s těmi parametry a pak ho opakovaně používal.
V shellu se to řeší uložením konfigurace do souboru, když je těch parametrů moc nebo jsou složitěji strukturované. Pak voláš program s jedním parametrem, kterým je název toho konfiguráku. Pak se vlastně dá ten program (binárka) přirovnat ke třídě a ten konfigurák k její instanci (resp. konfigurák drží stav a společně s programem vytvoří proces a to je ta instance).
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: gll 26. 02. 2017, 22:08:58
Jenže to je dané tím, že to v shellu jinak nejde a nemáš si jak držet stav mezi jednotlivými voláními.
Např. když přes find a xargs budeš zmenšovat obrázky, tak musíš tu velikost předávat pořád dokola jako parametry.
Kdežto v objektovém programovacím jazyce by sis inicializoval objekt, který bude zodpovědný za to zmenšování, s těmi parametry a pak ho opakovaně používal.
V shellu se to řeší uložením konfigurace do souboru, když je těch parametrů moc nebo jsou složitěji strukturované. Pak voláš program s jedním parametrem, kterým je název toho konfiguráku. Pak se vlastně dá ten program (binárka) přirovnat ke třídě a ten konfigurák k její instanci (resp. konfigurák drží stav a společně s programem vytvoří proces a to je ta instance).

v shellu se dá použít alias.

v pythonu bych určitě použil functools.partial. V php asi uzávěr. Ušetří mi to psaní kvanta zbytečného kódu a zlepší to čitelnost.

Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: Kit 26. 02. 2017, 22:30:07
v shellu se dá použít alias.

v pythonu bych určitě použil functools.partial. V php asi uzávěr. Ušetří mi to psaní kvanta zbytečného kódu a zlepší to čitelnost.

Pokud jsi přesvědčen, že ti v PHP uzávěry ušetří psaní kvanta zbytečného kódu, tak si je dělej. Pro mne jsou výhodnější objekty, protože toho umí víc a kód je hezčí.
Název: Re:Vytvareni aplikacnich systemu Unix-like metodou malych, single purpose aplikaci
Přispěvatel: BoneFlute 27. 02. 2017, 01:46:54
Diskutovalo se tu o obdobě shellových utilit. To je typicky jedna metoda (funkce).

Typická shellová utilita mívá minimálně jeden parametr, který říká, co se s těmi vstupními daty má udělat. Tedy pokud to nemá být vyloženě jednoúčelové, jako např. gzip.

Ano. Je to jedna funkce s nějakými parametry.

Jenže to je dané tím, že to v shellu jinak nejde a nemáš si jak držet stav mezi jednotlivými voláními.
Např. když přes find a xargs budeš zmenšovat obrázky, tak musíš tu velikost předávat pořád dokola jako parametry.
Kdežto v objektovém programovacím jazyce by sis inicializoval objekt, který bude zodpovědný za to zmenšování, s těmi parametry a pak ho opakovaně používal.
V shellu se to řeší uložením konfigurace do souboru, když je těch parametrů moc nebo jsou složitěji strukturované. Pak voláš program s jedním parametrem, kterým je název toho konfiguráku. Pak se vlastně dá ten program (binárka) přirovnat ke třídě a ten konfigurák k její instanci (resp. konfigurák drží stav a společně s programem vytvoří proces a to je ta instance).
Už to tu zaznělo: curring.
Kód: [Vybrat]
function grep ($in, $pattern) {
    foreach ($in as $line) {
        if(preg_match($pattern, $line)){
            yield $line;
        }
    }
}
function curr_grep($pattern) {
    return function($in) use ($pattern) {
        return grep($in, $pattern);
    }
}
$curr_grep_a = spec_grep('a*');
$curr_grep_b = spec_grep('b*');

$spec_grep_a($obsah);

Je fakt, že na něco takového jsou třídy hack. A je fakt, že co se týče FP php zrovna nespolupracuje. Ne, že by to nešlo, ale je to děsně ukecaný.
Název: Re:Vytváření aplikačních systémů Unix-like metodou
Přispěvatel: Youda 27. 02. 2017, 10:13:44
Heh, to je zase debata.

V kostce ten "UNIX pristup" znamena, ze aplikace je tvorena souhrnem komponent, ktera si predavaji data.
UNIX pipa je pro realne pouziti nepouzitelna, anzto predava jenom newline delimited nestrukturovany text, navic je schopna predavat jenom mezi dvema komponentami a jenom jednim smerem.

To znamena, ze je potreba mit:
-message bus
-definovane data interchange API
-aspon primitivni BPEL na routovani dat
-nejaky toplevel framework co komponenty pospousti ve spravnem poradi a umozni jejich spravu
-a protoze se pise rok 2017 tak i nejaky centralni Deployment/DevOps v verzovanim komponent
-a protoze rok 2017 a legislativa EU, musi to byt sifrovane a zabezpecene, treba neco ve stylu PEP (Policy Enforcement Point), ke kterymu se komponenty hlasej, to aby byly schopne RBAC autorizace.

Ano, je samozrejme mozne si neco takoveho napsat sam, za par clovekolet to bude hotovo. Zvlast kdyz Apache Karaf je tak strasne nenazrany, spusteny prazdny Karaf bez naloadovanych bundlu a services si sezere 30MB RAM (priblizne uroven holeho Tomcatu), to je neunosne a na ZX Spectru to rozhodne nepojede.


Potom este stravit par clovekostaleti a vytvorit si svoji obdobu MavenCentral s tou obri sadou predpripravenych komponent a je hotovo.

Preju hodne stesti.
A pokud to prestane bavit, doporucuju vyplout na zapad z pristavu Palos de la Frontera, pry se da cestou na zapad doplout do Indie!

Název: Re:Vytváření aplikačních systémů Unix-like metodou
Přispěvatel: Mirek Prýmek 28. 02. 2017, 00:12:09
UNIX pipa je pro realne pouziti nepouzitelna, anzto predava jenom newline delimited nestrukturovany text
Fakt?

Tohle teda asi není unix roura:
Kód: [Vybrat]
cat /dev/sda1 | cat >/dev/sda2
Název: Re:Vytváření aplikačních systémů Unix-like metodou
Přispěvatel: Youda 28. 02. 2017, 02:31:49
UNIX pipa je pro realne pouziti nepouzitelna, anzto predava jenom newline delimited nestrukturovany text
Fakt?

Tohle teda asi není unix roura:
Kód: [Vybrat]
cat /dev/sda1 | cat >/dev/sda2

Ehm, vzhledem k tomu, ze je tu rec o komponentovych aplikacich, ktere si predavaji zpravy ve stylu zretezenych cat, grep, awk xargs, prijde mi tato poznamka ponekud zvlastni.
Ale budiz, Allah miluje rozmanitost.

Echt rootovy linuxak si muze postavit system na binarnich streamech, binarni nula bude message delimiter a nula bude dvojita nula.
Timto je puvidni tazateluv problem vyresen a vlakno se muze uzavrit. Transportnim protokolem bude WBSI (Whatever binary shit inside), jenom bych se primlouval za malyho indiana, mohla by teoreticky nastat situace, kdy soucasti deploymentu bude i netcal z intelu na sparc.
Název: Re:Vytváření aplikačních systémů Unix-like metodou
Přispěvatel: Mirek Prýmek 28. 02. 2017, 08:42:04
Echt rootovy linuxak si muze postavit system na binarnich streamech, binarni nula bude message delimiter a nula bude dvojita nula.
Timto je puvidni tazateluv problem vyresen a vlakno se muze uzavrit. Transportnim protokolem bude WBSI (Whatever binary shit inside), jenom bych se primlouval za malyho indiana, mohla by teoreticky nastat situace, kdy soucasti deploymentu bude i netcal z intelu na sparc.
To uz udelal Microsoft s PowerShellem ;)
Název: Re:Vytváření aplikačních systémů Unix-like metodou
Přispěvatel: Kamil Podlešák 28. 02. 2017, 11:51:12
Echt rootovy linuxak si muze postavit system na binarnich streamech, binarni nula bude message delimiter a nula bude dvojita nula.
Jenom taková hnidoišská poznámka:
Kód: [Vybrat]
find ./ -print0 | xargs -0 echo