VM - flowchart architektury za účelem vývoje a dokumentace #316
Labels
No Label
app-basic
app-ckan
app-crisiscleanup
app-cts
app-decidim
app-dhis2
app-frontlinesms
app-gnuhealth
app-kanboard
app-mifosx
app-motech
app-odoo
app-opendatakit
app-pandora
app-sahana
app-seeddms
app-sigmah
app-taarifa
app-ushahidi
critical
CZ
documentation
Doing
enhancement
GMaps
info
Mapbox
needinfo
new-app
OSM
performance
QGIS
regression
suggestion
To Do
upstream
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Spotter-Cluster/Spotter-VM#316
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Rád bych připravil vizuální rozkres toho, co už existuje + navrhnout další plány s rozvojem VM + DS, případně dalších souvisejících SW. Tj. nějaké boxíky, vztahy mezi sebou, závislosti, popisky.
týká se to především softwarového návrhu, zatím bez pohybu pracovních dat. Později možná na nákresy pracovních workflow
Chci použít kreslící sw na tyto flowcharty, jsem v pohodě téměř se vším, ale rád bych aby se to dalo snadno editovat společně, případně později dalším člověkem, který se bude podílet na projektu. Tj. sdílet a editovat na jednom místě. Ideál open-source, něco, co nenasere při finalizaci.
Máte něco oblíbeného? vygooglil jsem nějaké https://www.draw.io/ nebo cosik podobného. Možná existuje nějaké vizualizační rozšíření do GitLabu. Nejde mi o řízení činnosti lidí a vývoje sw, jde o návrh a vizualizaci sw architektury.
Představuji si, že navrhnu drafty, vy se k tomu vyjádříte, nebo upravíte.
výsledek bude hlavně pro interní potřebu, aby se mi lépe diskutovalo s programátory, zjednodušená část může být později i ve veřejné dokumentaci.
changed the description
Když se mi přihodí, že jsem nucen vyrábět flowcharty nebo diagramy, používám Microsoft Visio. To má k opensource bohužel hodně daleko. Z OSS desktopových nástrojů diagramy umí Dia a OpenOffice Draw, oboje se IMHO ovládá zoufale. Online žádné nástroje neznám. Někdu jsem něco takového asi taky hledal, ale pak to vzdal, takže teď kreslím jednoduché diagramy v ASCII a složitější ve Visiu.
Nicméně mě v současné fázi nenapadá, kde bychom potřebovali něco rozkreslovat. Možná tak strom závislosti balíků.
ASCII:
Visio:
jasné. Díky za ukázku. Visio bylo pro mne vždycky tak trochu slon v ledničce, na Macu jsem ujížděl na OMNI graffle, ale pak mi MBP zemřel, od té doby se trápím s W7 kde se štítím každého podivného shareware... a trajektorií směřuju k linuxovým SW. objevil jsem nějaký Pencil https://github.com/evolus/pencil , což vypadá jako OK. Sdílení to ale nemá. Později něco načrtnu.
Použít služby Google Drive mne nedávno odradilo, díky jejich překomplikovanému řešení jsem málem přišel nervy i data. Tak teď testuju ten Pencil.
Lehké OT - Na twitteru dnes kdosi zmiňoval, že draw.io se dá nainstalovat jako aplikace do NextCloudu. Tak jsem to zkusil na své testovací instanci a nekecají. Na to, že je to pitomá JavaScriptová aplikace se všemi omezeními, které z toho vyplývají, se to ovládá docela obstojně. Až se jednoho krásného dne k nějakým těm diagramům dostaneme, můžeme to zkusit použít. Kdyby bylo potřeba diagramy zpracovávat i někde jinde, data z toho lezou v otevřeném formátu JGraph / mxGraph.
pokoušel jsem se to tam adminem nainstalovat, ale nějak se mi draw.io neukázalo v horní liště. Jinak bych to považoval asi za dostačující.
Z nějakého důvodu zůstala mezi vypnutými, tak jsem ji zapnul. V horní liště se neukazuje, integruje se rovnou jako typ souboru (New Diagram), které se schovávají pod menu pro přidání položky.
super. Pomalu se začínám s NextCloudem kamarádit. Na transifexu jsem objevil něco k překládání do něj, tak chvílemi to zkouším.
closed
Za překlad NextCloudu Vám budu vděčen i mimo soutěž. Když jsem s ním před lety začínal, tak jsem si ho na Transifexu krásně dopřekládal do 100 %, ale NextCloud je zrovna taková aplikace, která jde kupředu, zpátky ni krok, takže hromada těch řetězců už bude vypadat jinak a druhá hromada jich přibyla.
Celkem chytře to tam mají členěné do těch modulů, takže když nemáte třeba mobilní appku, nemělo by se Vám stát, že narazíte na nějaký řetězec, který je bez ní nepochopitelný, pokud se tedy nerozhodnete překládat zrovna modul pro mobilní appku.
teď je tam jako hotovo vše, ale jestli řikáte že se to mění, tak by snad změn+né řetězce měly být znovu k překladu. Jinak na Crowdinu jsou k překladu nějaké GPxEdit https://crowdin.com/project/gpxedit a GPXPod https://crowdin.com/project/gpxpod což jsou mapky. Ještě to neni.
Jsem schopen překládat pouze existující projekty jako participant. Nemůžu si dovolit zakládat nový překládací projekt, to je většinou placená služba. Tak se pouze vsírám do rozdělaných věcí.
první draft schematu jsem začal, k němu pak upravíte chlívečky https://server.spotter.cz/s/frZSPW2M9MGKpRe
Vlastně nevim jestli tímto sdílením můžete editovat, asi ne. Leda bych vám udělal uživatele na mém cloudu?
reopened
Asi bych potřeboval upřesnit, co od těch flowchartů vlastně očekáváte. Ten původní popis "...aby se mi lépe diskutovalo s programátory..." mi tu moc nepomáhá. Když se koukám na to, co jste začal, tak sice chápu jednotlivé chlívky, ale nechápu celek. Má to být rozkres z pohledu uživatele? Z pohledu aplikace? Z pohledu platformy? Má to být skutečně flowchart, tedy popis změn stavu v nějakém rozhodovacím stromu nebo spíše mapa toho, co kde je a s čím souvisí v jediném okamžiku? Pokaždé, když začnu vymýšlet, co by kam dalo přidat, vznikne mi z toho po chvíli teserakt plný schemat ve schématech a jiných matrjošek, ve kterém je všechno od velkého třesku až po restart matrixu a je to úplně nečitelné a nepoužitelné.
Takže přemýšlím, že těch schemat budeme potřebovat několik a zajímá mě, co na nich má hlavně být. Hádám, že to hlavní bude mapa platformy, tedy VM a kontejnery, ale do toho mi třeba vůbec nepasuje "data layer" a "application layer" z původního schematu, protože těm kontejnerům je z pohledu platformy putna, co v nich běží a mezi binárkami, konfiguracemi a uživatelskými daty nerozlišují, natožpak, aby rozlišovaly co jsou mapová data a jestli jsou offline nebo online. Každá aplikace navíc pracuje s něčím úplně jiným, jedná zobrazuje mapy, druhá ne, jedna potřebuje databázový server, jiná zas message broker atd., takž paušálně říct "tadyhle jsou data" taky nemůžu.
Pro životní cyklus aplikace by se pak hodil nějaký flowchart v pravém slova smyslu, kde by bylo vidět, co se vlastně děje, když uživatel instaluje aplikaci. Že se napřed zkontroluje, jaké komponenty jsou dostupné lokálně, stáhnou se chybějící, nainstalují se, nastaví se atd. Prostě pavouk k tomu, co je slovně popsáno v dokumentaci.
Stejně tak mi do celého obrázku nezapadá třeba wiki a dokumentace atd, protože to je zase něco, co žije na serveru úplně odděleně a nesouvisle s VM nebo jejími aplikacemi. Takže to by zase bylo úplně jiné samostatné schéma.
Takže co z toho mám vlastně vyrobit, aby to pro Vás (a případně někoho dalšího) bylo užitečné?
zde je na ukázku dokument, kde na straně 92 je jednoduchý rozkres architektury pro BiBBOX. https://link.springer.com/content/pdf/10.1007%2Fs12553-016-0175-x.pdf
Ti se stim taky moc nepárali.
Takový "nepřesný" rozkres slouží buď pro prezentační účely, nebo pro nějakou teoretickou studii. Může sloužit i jako rychlé intro k dokumentaci. Takže nemusí být podrobné ani složité. Naopak by měly být záměrně zjednodušené, ale formálně pravdivé. Toto se týká zejména architektury VM. tj. co tvoří základ VM aby existovala.
Váš návrh na více schemat: ANO. A ty další schemata - budu rád, když mi nakreslíte, ale v tuto chvíli na ně není neodkladné zadání. Může vám to trvat déle, nebo nad tím můžu ještě diskutovat, rozmýšlet.
Pravděpodobně mohou schemata procházet vývojem, takže bude fajn, když budou v editovatelném formátu. (např. jako příloha v dokumentaci) Tj. nestačí pouze obrázek, nebo exportované PDF.
Flowchart s nějakými detailními stavy nevyrábějte, to by bylo strašně složité a pro tuto chvíli zbytečné.
Navrhuji:
architektura platformy z pohledu obeznámeného uživatele (to je proto, že lidé se orientují spíše z pohledu vlastního, než nějakého abstraktního)
životní cyklus aplikace ve VM tj. jak píšete. (zde už si můžete troufnout být detailnější a týká se aplikace).
Ano, to je pravda. Můj návrh je naházené seno, zatim jsem tam dal vše co mě napadlo, včetně toho co neexistuje, však mne znáte. Je možné vydělit do jiného schematu.
Tím jsem původně myslel nějaký rozkres, kde budou zmíněny podpůrné služby, (např. FTP) tak aby bylo jasné, že VM neni nějaký "holý" blackbox který přilétl z deep-internetu, ale že pro vývoj a činnost tu jsou další data, nebo hosting. - to je asi info do zálohy, kdyby se na to někdo ptal.
a to by tedy bylo "volitelné třetí schema"
Takže váš úkol v kreslení je přednostně takový, který nezvládnu já. Tj. popsat model co jste sám navrhl a naprogramoval. Mělo by to pomoct dalšímu člověku v orientaci, když se začne prokousávat psanou dokumentací. Ale nemá zcela vizuelně nahrazovat dokumentaci, to je jasné:)
Jste-li zvyklý na nějaký konkrétní stylopis, barevnost, nebo vytváření legendy ke schematu, nechám na vás.
Pokud tam budou popisky, tak anglicky. Licence ke grafice CC 4.0 BY-NC-ND (?)
(tento dotaz je přesně to, co předejde práci, kterou byste třeba nepochopil a pak dělal zbytečně, takže děkuji za něj :)
mentioned in issue Podhorecky/Hosting#40
Mno, koukal jsem na dokument, kde na straně 92 je nějaký obrázek, který o architektuře neříká vlastně vůbec nic. Vezmu-li dva libovolné boxíky v obrázku, dá se vyčíst, zda je mezi nimi spojitost nebo ne, ale to je tak všechno. Jako celek ten obrázek nedává žádný smysl. Čte se zleva doprava nebo zespoda nahoru? Znamená to, že "User Management" je součástí "Server Tool Management", "BiBBOX Portal" nebo je samostatnou komponentou? Co představuje ta závislost "Server Tool Management" - "Docker" - "Docker" - "Docker". Ovládá se tím Docker runtime, userspace nástroje nebo přímo ta aplikace v kontejneru? A ty jednotlivé instance Dockerů jsou skutečně provázané nebo to jsou jen překryté závislosti 1:1 mezi "Server Tool Management" a individuálními instancemi Dockeru? Prostě - obrázek je hezky barevný, ale vůbec nevím, co si z něj mám vzít.
Co se týče naší architektury, moc tam toho nemáme, takže schema zobrazující hierarchii komponent bez zjevných závislostí by bylo prostě:
To je celkem na prd. Nicméně u nás všechno souvisí se vším, takže je vcelku obtížné ty závislosti znázornit pravdivě a úplně. Pokud vynechám takové ty zjevnosti, jako že operační systém poskytuje prostředí pro běh služeb nebo že i aplikace se může někam připojit, pak se dopracuji k tomuto:
No a co se týče těch životních cyklů imagí, kontejnerů a aplikací, tak mám z pohledu buildera:
A z pohledu uživatele:
Všechna schemata jsem vytvářel v draw.io u Vás v NextCloudu. Ten program je až podezřele příjemně použitelný, v LibreOffice jsem při kreslení flowchartů vždycky brečel. Pokud diagramy shledáváte přijatelnými, překopíruju je na účet k Vám, zasdílím zpátky k sobě pro případné editace a obrázky nahážu do technické dokumentace. Mám vytvářet ještě nějaká schemata?
První schema: Ano, takto zcela vyhovuje... pro přehled není potřeba víc.
Další schemata: Všechny tři jsou fajn zpracované a teď nemám žádné výhrady. Úroveň složitosti taky OK.
Možná by bylo vhodné do všech obrázků udělat nadpis Aby byl přímo součástí schematu. Čistě z praktických důvodů, nevíme kde by se později obrázky objevily, Tak budou mít alespoň záhlaví. Nadpis nemusí nutně obsahovat slovo Spotter.
Tohle bych samože mohl udělat i já, kdyby se vám do toho nechtělo, nicméně pak to stejně budete vkládat do dokumentace. Umístění do dokumentace nechám na vás, ten první bude asi někde v úvodu.
Kopírování / sdílení... Ok, udělejte jak vyhovuje.
Další dokumentující grafy tohoto typu v nejbližší době neplánuji. Případné dotazy cizích lidí budu odpovídat slovně.
Takže zadání jste naplnil skvěle. Díky moc.
closed via commit
d5aca4ad52Schemata ještě trochu poupravena a přidána do dokumentace. Zdrojové XML soubory máte v NextCloudu v kořenovém adresáři účtu jp@spotter.cz