VM Frontend design - draft k zadání #1
Labels
No Label
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/vmmgr#1
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?
shrnutí potřeb a návrhů pro realizaci frontendu (CptO. incl.). Přednostně tedy pro frontend designera, ale určitě je možné probrat, upravit. návrhy nemusí být zcela dokonalé, rád přijmu vhodnější.
Cíl:
Návrhy k řešení (řazeno bez priorit)
koexistence s aplikacemi
postup vzniku
pokud by mělo později vzniknout samostatné GUI distribučního serveru nebo jiné GUI, bude řešeno jinde.
(prosím nesmát se, mam za sebou extrémně špatnou zkušenost k podobnému zadání, kde se všichni tvářili jak je profíkům vše jasné a u termínu "responzivní design" na jehož shodné pochopení jsem se výslovně ptal, se řešitel tvářil, že se zbytečně ptám co je to "kolo", ale jeho výsledek byl odstrašující karikatura responzivního designu.)
na testy mám momentálně výkřik techniky:
Body
se ve většině případů vylučují, alespoň dle mé definice přiměřeně nízkých nároků. Moderní webové frontendy se dělají tak, že se vezmou dvě supersportovní auta a z jednoho se použije levé přední kolo a z druhého klika u dveří. K tomu, aby to celé fungovalo ale musí být všechny součásti pořád pohromadě a spotřeba i nároky na údržbu jsou stejné, jako by byly při jejich zamýšleném užití. Dělá se to tak proto, že pak může programovat každý, kdo se trefí do klávesnice a workload se přenese na stranu uživatele, protože z cizího krev neteče.
Například minifikovaná verze Bootstrapu (který považuju za jeden z těch příčetnějších) má 138 kB CSS a 50 kB JS. Takže máte 188 kB kódu, který už musí prohlížeč zpracovat, a ještě nemáte jedinou řádku toho, jak má webová aplikace vypadat nebo co má dělat. Aplikace našeho manažeru VM má 103 kB kódu. Neminifikovaného. Včetně serverové části v pythonu. No a k tomu, aby aplikace vůbec mohla něco dělat moderní frontenďák použije další frameworky. Já skončil u jQuery a dál to nesleduju, ale myslím, že pořád ještě letí React a Angular. Tam se velikosti nebo náročnosti nedají vyčíslit, protože závisí na tom, co a jak se napíše, ale vím, že se není problém dostat třeba na 4 MB JavaScriptu, takže uživatel na pomalém připojení s pomalým počítačem pak pět minut civí do prázdna a čeká až se stránka zjeví. Tenhle systém používá třeba Mifos X, který na Vašem internetu přes poštovní holuby občas nebyl schopen načíst řetězce prostě proto, že to už nestihl.
Tím chci říct, že bych za každou cenu nelpěl na použití frameworku, pokud se bude jednat o rozhraní o pěti stránkách, kdy se stejně nejvíc práce bude odehrávat na straně serveru. I responzivní weby se dají dělat bez frameworků, když se chce. Viz třeba můj https://www.dasm.cz . Když se nechce, tak pak je to samozřejmě jednodušší a přenositelnější i s frameworkem, ale tím víc bude trpět uživatel a jeho browser.
Dále
Co bude obsahovat rozhraní pro klienty? V současnosti máme "anonymizované" rozhraní bez ikonek a názvů, ale to předpokládám nebude setrvalý stav, protože název aplikace si každý může přečíst hned po prvním kliknutí. Pokud bude obsahovat totéž co strana portálu, která je viditelná adminovi, akorát bez jmen a hesel, pak se z hlediska aplikace jedná o tutéž stránku s pár podmínkami v kódu.
Se zbytkem bodů v zásadě problém nemám. Připadá mi, že hledíte hodně do budoucna, takže bych preferoval, abychom se tam dostali iterativním způsobem a přidávali a upravovali funkce dle skutečné potřeby a ne dle nějakých projektovaných cílů (YAGNI princip). Jak už jsem zmiňoval, nejsem frontenďák a drbání se s HTML a CSS nenávidím, protože jsem přesně na tomhle začínal a vím, že je to strašně nevděčná práce. Všechny ty zlepšováky a zjednodušováky přišly až když jsem se profesně posunul dál, takže teď už jen koukám ze strany správce serveru a chytám se za hlavu, když vidím, co mi to tam ti mladí instalujou za žrouty systémových prostředků. Takže budu určitě rád, když se nějaký nebožák bude trápit místo mě a na to co vyplodí jen hodím dva řádky svého pythonu a budu mít vystaráno.
Ok, s tim frameworkem jsem to možná nasadil příliš vysoko. Já tedy nemám znalost výroby současného frontendu, takže moje info končí u toho, že na vývoj designu je kdejaký nerd-tool nebo fw a 95% jsou strašné bizáry, které si někdo oblíbil a pak to zákazník musí trpět. Nikdo už design ručně nepíše.
Omlouvám se, ale moje zkušenost zadavatele je tak strašlivá, že to je asi znát. To si představte, jak máte v býv. zaměstnání za úkol zadat a dohlížet výrobu jednoduchého webshopu na 25 SW/HW produktů. Po pár iteracích zcela zbytečných výběrových řízení dojdete až k partičce nerdů, kteří šéfovi naslibují že jsou nejlepší, nejlevnější a prostě maj cool webik. Šéf je totiž drobný škudlil.
Když po celoročních projektových a vývojových nesmyslech začnou předvádět výsledky, tak se mi chce taky rozkousat klávesnice a nebo se teatrálně zabít. U téměř finální prezentace šéfovi ten webshop neumí kliknutím na tlačítko "koupit" udělat nákup! Nerd to před zraky ladí a zbytek svádí na laravel a jiné čerty. O designu nemluvě. Jako charakterově klidná povaha jsem duševně trpěl, protože hlasitě křičet na cizí lidi neumim. Jiný případ s podobnou katastrofou mě stál asi 40 tisíc jen za pokus o microsite. A pak jsem to odmítl abych nemusel kodera zabít, peníze zpět nedostal.
Ok ... zadání by asi mělo být bez přesných keywordů a jiných frameworků, ale strašně se mi svírá zadek.
Zadání dál můžu upravit
něco, co se mi na první pohled líbí jako frontend je třeba https://www.anaconda.com/distribution/
Anaconda Navigator. Ještě jsem nezkoumal co všechno to v rámci projektu Anaconda umí, ale obecně to je cesta někudy tudy.
Github mají https://github.com/ContinuumIO
Po chvíli zkoumání musim říct, že tohleto Anaconda je cosi velmi vymakaného pro to, co tím chtějí dosáhnout. Rozběhla se mi fantazie o naší VM, ale zase vím, že nejsem Ročild.
Až budete mít chvíli, můžete se prosím na to podívat odbornějším a střízlivějším okem, posoudit a říct jestli se z tohohle konceptu dá něco odkoukat, něco naučit a něco podobně realizovat? Samozřejmě že v našem případě jde o celé aplikace, nejen o jednotlivé knihovny.
assigned to @Disassembler
Tak určitě. Dá se z toho třeba naučit, že bude lepší se na to vykašlat a začít místo toho třeba sázet stromky nebo včelařit. Technologicky to zaštiťuje 17 lidí, vyvíjí to minimálně 6 let, cílí to na dvě konkrétní platfomy (Python a R) místo našich pěti a mají krásných 10392 issues pro rozhraní jako celek a dalších 5932 pro balíčkovací systém samotný, z čehož je drtivá většina otevřená kvůli nekompatibilitě komponent. Jestli mi tohle nemá způsobit depresi, tak pak už nevím co.
Co se týče pouze frontendu, tak ten je vcelku příjemný. U nás IMHO nedává moc smysl mít volitelné jednotlivé komponenty, protože aplikace je buď vyžaduje a pak nainstalovány prostě být musí anebo je nevyžaduje a pak nejsou pro uživatele ničím užitečné, nicméně mohlo by být vidět, že tam třeba jsou, už jen proto, že bude jasnější, co se kde instaluje a aktualizuje. Dále bych viděl zásadní rozdíl v tom, že Anaconda launcher a všechno co řídí a dělá, jsou desktopové aplikace, kdežto my řešíme server. Anacondu tak nezajímá jestli nějaká aplikace běží nebo neběží - prostě tady tím čudlíkem se spustí, otevře se nové okno a to si uživatel pak sám zase zavře. V lepším případě to skutečně zavře celou aplikaci, v horším pak zůstane běžet nějaká serverová část bez možnosti ji zastavit.
Ty karty aplikací ale mají něco do sebe. Nejsem asi úplně nadšen z toho, že se mi míchají nainstalované a nenainstlované aplikace, ale to u nás zatím máme taky a to se dá vyřešit nějakým filtrovacím zašktrávátkem nebo dropdownem. Anacondí karta pak má jedno velké tlusté tlačítko s očekávanou akcí (u nás by to byl install / start / stop) a vše ostatní je schováno pod ozubeným kolečkem. U nás bych si dovedl představit vedle kolečka ještě nějaký otazníček, kde by bylo vidět číslo verze, licence a třeba jaké datové formáty to žere nebo tak něco, jako jsme probírali u metadat v Spotter-Cluster/Spotter-Cluster#305.
Naopak jako nedostatek, který narozdíl od Anacondy máme vyřešený, vidím to, že nevidím co se děje, kolik se toho ještě bude dít a jak daleko v dění to je. Dole se mi sice píše, že se něco instaluje, ale nevím, jestli budu moci aplikaci použít za deset vteřin anebo až pozítří. Pak jsem šel do kolen, když mi v dokumentaci bylo oznámeno, že jako absolutní minimum pro instalaci pouze samotného balíčkovacího systému potřebuji pouhých 400 MB. Tolik to přece nemůže mít ani kdyby to neurálními sítěmi predikovalo, co budete chtít spustit nebo nainstalovat.
tl;dr: Balíčkovací systém samotný pro naše účely nepoužitelný, ale funkcemi a vzhledem frontendu se dá inspirovat.
Děkuji... jojo, vidím že mají velký tým. Nelze srovnávat.
S tím interface souhlasím.
Jedno ale nevím a možná odpověď přijde později. Pokud bych chtěl usnadnit vznik našeho frontendu a zároveň trochu myslet i na budoucnost, která cesta je vhodnější? Použít a adaptovat něco hotového jako toto, nebo raději od nuly vyrobit vlastní frontend?
Mam sice "luxus" rozhodnutí, ale nakonec jsou mým limitujícím faktorem čas a lidi... takže zatím nevím.
Tak ještě jednou a pomalu. Je to desktopová aplikace. Takže buďto musíme zahodit všechen náš kód a začít od nuly s nějakým linuxem použitelným na desktopu (asi Ubuntu) a pak můžeme použít jejich frontend... anebo budeme chtít zůstat u toho, že je to minimalistický server a pak musíme pracovat s tím, co již máme nebo s úplně jiným řešením které má webové rozhraní. Adaptace toho jejich nepřichází v úvahu z velmi prostého důvodu - Licence: Proprietární, Zdrojové kódy: neexistující. Ona je totiž pod BSD licencí vydávána jen ta distribuce Anaconda, která má v EULA kouzelnou větičku
Historicky tam býval i jiný frontend - Anaconda Launcher, ale k tomu se mi také nepodařilo najít kódy. To je také důvod proč se issue reportují v repu anaconda-issues, které neobsahuje žádný kód. Open source my ass.
Jinak se Vám samozřejmě nesnažím bránit ve výběru technologií, ale počítejte s tím, že má mentální kapacita je omezená, takže čím víc pro mne neznámých věcí vyberete, tím méně Vám s nimi budu schopen pomoci. Chápu, že 6 milionů
židůuživatelů je úctyhodné číslo, takže platforma to bude nejspíše prověřená, ale k úplně jiným účelům a za úplně jiných podmínek.aha, pardon... Samozřejmě, že teď už rozdíl vidím i napsaný. Pro mne je zpočátku vždycky špatně rozeznatelné co prezentují. A tak dotaz byl i obecnější. Nechci měnit zadání.
Když se snažím něco najít, tak nehledám podle "největší známosti těch aplikací" ale hledám z druhého konce, tj. podle hotových případových studií, častokrát na nějakých univerzitních projektech, kde jsou zmíněny zdroje. A tak jsem se dočetl z úplně u jiné stránky, že "projekt byl kompletně postaven na nejlepším vědeckém FOSS evr Anaconda blablabla... Hm. Tyhlety cool názvy jako Python, Anaconda ...hledat fulltextově bez kontextu, to bych taky mohl strávit mládí v zoo pavilonu plazů. Inu, angličtina.
Pak jsem vlez na web https://opensource.com/article/18/4/getting-started-anaconda-python
kde mě zas přesvědčovali o tom, že
(no jasně... trestuhodné zjednodušení)
a tak po zkoumání webu Anaconda jsem pojal podezření, že mají nějako formu modelu free sw + vlastní sw a služby za peníze, což je někdy strašně složité rozeznat, protože pochopitelně tvůrci vždy nejvíc promují tu placenou variantu. A to že je skutečně něco s otevřenými zdroji pak jen tak prohodí mikropísmem v poslední kapitole dokumentace. Zde zjevně ne.
Také jsem ještě hledal free alternativy k balíčkovacím vehementům, hlavně kvůli GUI. Abych viděl, jestli je nějaký už časem / vlastnostmi prověřený. Abych znovu nevynalézal vynalezené... ale tam jsem brzy skončil s nabídkou, google samože vrací vždy ty provařené komerční sw které si zaplatili pozici ve vyhledávači. Stránky jako Quora nebo jiné žebříčky pak nažvaní kdeco, ale to by u toho člověk zestárl, protože většina z nich směřuje k jiným cílům než hledám.
Takže se ptám na ufo věci, ale já předem nevím, že to jsou ufo věci. Když se na to nezeptám, nikdy se nedozvím, že jsem se zeptal blbě. Vy často nabídnete jiný sw, o kterém jsem v životě nezaslechl, protože nemám zkušenost a proto jsem s ním taky v koncích. A to nepopírám, já ho jen neznám o nic víc, než moje ufo. :(
Proto máte nakonec důležité slovo ve výběru a já jen nadhazuju pitomé dotazy. Omlouvám se.
Asi by v téhle diskusi stálo ještě za to vypíchnout, že balíčkovací manažer a jeho frontend spolu nemusí mít vůbec nic společného a zpravidla ani nemají. V případě Anacody je použit manažer conda, ten má nějaké API a na něj se dá vyrobit jakékoliv GUI (jakým je třeba Anaconda Navigator), které pak volá funkce manažeru a tahá z něj data.
Abychom se míň nadřeli, můžeme použít jakýkoliv balíčkovací manažer, který zrovna poběží okolo. Na Alpine máme systémový APK. Problém ale je, že ne všechny manažery podporují featury, které bychom potřebovali. Důvody, proč nepoužíváme třeba zrovna APK jsou:
Samozřejmě použití existujícího balíkovacího systému má i svá pozitiva - nemusíme ručně implementovat spoustu věcí jako třeba řešení závislostí, stahování a jejich následné ověřování atd. Způsoby jak využít existující balíčkovací manažery se najít dají, ale pochybuji o tom, že se dá najít nějaký, který naším potřebám vyhoví rovnou. Naše balíčky navíc nejsou úplně typické jako ty, které řeší APK nebo conda, takže některé featury jsou pro nás naopak na škodu. My prostě potřebujeme dostat hromadu souborů do VM a pak akorát nějakým způsobem vědět, jestli tam jsou nebo ne a jen pro nedostatek výrazů tomu říkáme balíčkovací manažer.
Tohle issue je o frontendu. Co se frontendu týče, dovedu si představit, že jeden frontend bude použitelný na více různých backendů jen s minimálními modifikacemi. Jde jen o to, navázat na data, která manažer poskytuje. Pokud tedy náš baličkovací manažer a jeho API důkladně zdokumentuji, frontendař bude moci vyrobit jakékoliv GUI, aniž by musel detailně vědět, jak manažer vlastně funguje. Prostě tenhle čudlik bude volat funkci install se jménem balíku jako parametrem a jestli to bude instalovat APK, rpm, conda, dkpg nebo někdo úplně jiný už není jeho starost. Takový hotový projekt ale nenajdete, protože i přesto, že webových xichtů pro balíčkovací manažery existuje hromada v různých NASech, routerech, IoT a jiných zařízench, každé je implementováno tak, aby vyhovělo danému ekosystému. Takže nám nezbývá než udělat to samé, protože hotové řešení bychom museli upravit do takové míry, že by to vyšlo na stejno.
Ok... co se týče vlastností, nemůžu rozporovat. Co se týče diskuse k frontendu, vyhovuje tedy, že tvorba rozhraní bude opravdu od začátku. A bude to tedy pokud možno dobře popsaná evoluce.
Náhodný objev nějakého cozího řešení nanejvýš pomůže v diskusi, která ještě nemusí být změnou zadání.
Ježišmarjááá. To si tak hraju s proxy serverem, že bych zkusil nějak tu podporu pro autentizaci u APK repozitářů odrbat. A nějak mi to funguje divně, tak koukám do zdrojových kódů... a vona tam podpora pro autentizaci i pro HTTPS normálně je. Akorát se to nikde nikdo neobtěžoval zdokumentovat nebo zmínit. Pláču.
Tím pádem tedy zkusím odrbat ještě i ty zbývající nedostatky. Mám k tomu nějaké nápady. Nebude to sice tak flexibilní jako vlastní řešení, které máme teď, ale rozhodně Vám dávám za pravdu v tom, že čím více ověřeného kódu a komponent pod správou někoho jiného máme, tím spíš se nám z toho podaří poskládat něco smysluplného bez znovuvynalézání kola.
pro zajímavost hodím ještě odkaz na projekt senaite https://www.senaite.com který se také rozhodl jít cestou samostatné VM. v PDF dokumentaci mají ukázaný nějaký http://supervisord.org a další administrační tooly, nevím přesně, jestli neobsahuje nějakou zajímavou vlastnost pro náš případ.
Tento příspěvek není novým zadáním k čemukoliv. Jen sdílím pro případ, že by vás to zajímalo.
v souvislosti s tím jsem se chtěl zeptat, jak moc bude pod kontrolou logování z běhu jednotlivých aplikací, nebo dalších komponent VM. Rád bych, aby nedošlo k tomu, že mi pak někdo upozorní, že na jejich VM se množí gigabajty logů a jiných temp souborů, které se tam nějak cyklicky vytvořily a jenom jsme prostě nepočítali s tím, že se tak může stát.
Otázka tedy: Bylo by vhodné mít pro admina nějaký snadnější přístup k logům, případně jejich mazání?
Týká se i pro nějaké těžko předvídatelné situace, když by něco zacyklilo nějaký proces a logy by to pořád dokola zapisovaly...
Logování stejně jako hromadu dalších věcí, které budou důležité až v daleké budoucnosti při ostrém běhu jsem zatím příliš neřešil, nicméně jsem je trochu nakousl, abychom je nemuseli horkou jehlo došívat na poslední chvíli. V současnosti jsou
Otázka je spíš jak hluboce chceme administrátora pouštět k systémovým záležitostem. Přístup k logům virtualhostů nginxu a kontejnerů je jednoduše řešitelný, protože jednotlivé aplikace mají logy oddělené (skryl bych třeba pod ozubené kolečko ve frontendu). U ostatních logů záleží na očekávaných problémech. Syslog jsem snad použil jen jednou k nahlédnutí na chyby při odesílání mailů, takže bych se nebál jej před světem zamlčet.
Takových projektů existuje hromada. Nejznámějším je pravděpodobně Webmin, ale jsou v drtivé většině určeny pro úplnou správu OS a služeb, což je přesně to, co my nechceme. My potřebujeme zajistit, aby na úrovni OS existovala co nejmenší nutnost zásahu (to se nám daří jednoduše tím, že náš OS vlastně vůbec nic neumí, takže tam není co by se rozbilo :) ) a chceme odstínit administrátora od zaklínadel nutných pro správu linuxu. Převedu-li to do řeči cloudu, naše VM by měla poskytovat Software as a Service s tím, že zveřejněné zdrojové kódy mohou umožňovat i sestavení pro Platform as a Service. Nástroje jako WebMin nebo Senaite jsou ale všechny určeny pro tu nejnižší úroveň Infrastructure as a Service, kdy si klikáte záležitosti přímo na úrovni OS, storage a sítě. Samozřejmě se ale některými funkcemi můžeme inspirovat.
ok, odpověď zatím takto vyhovuje, díky. Řešme to hlavně tak, aby to bylo pro nás dostatečně blbovzdorné, tj. pokud možno bezúdržbové. V budoucnosti se to případně dá vylepšit pro cílové uživatele, ale jak říkáte... čím jednodušší to bude, tím lepší. (na webmin jsem nedávno koukal, zde chápu že to nepotřebujeme)
mentioned in issue Spotter-Cluster#311
Další "příbuzné" řešení pro management softwaru je BIBBOX http://bibbox.bbmri-eric.eu/ v této úpravě
soustřeďuje se na bioinformatics software.
na screenu vlevo jsou vidět tagy, které popisují typy softwaru. Může být zajímavé při větším počtu SW. Dokumentace: https://bibbox.readthedocs.io/en/latest/
do rodiny epidemiologických SW patří např. i skupina SW OBiBa https://www.obiba.org/
Mám při procházení té jejich dokumentace silný pocit Déjà vu. Některé designové prvky jsou naprosto identické s našimi (přísahám, že jsem o existenci BIBBOXu dosud netušil), například na této stránce
appinfo.json. Naše metadata jsou v JSONu s názvemmetaa prakticky totožnou strukturou, s drobně odlišnými názvy klíčů.app-. Všechny naše balíčky začínají řetězcemvm-, protožeapp-jsem si původně vyhradil pro nativní aplikace instalované přímo na hostiteli.Jediný zásadní rozdíl vidím v tom, že BIBBOX je z uživatelského hlediska méně blbuzvdorný, ale u toho samozřejmě záleží na zkušenostech deployera. A taky rozhodně ani v nejmenším není minimalistický. Staví na plném (a zastaralém) Ubuntu 14.04 a celá ta paráda běží nad Javou (Liferay portal), skládá si statické assety pomocí Node.js a vůbec je to moloch. Pokud byste o BIBBOXu věděl dříve a narazil na nějakého normálního sysadmina místo toho minimalismem posedlého idiota, co máte teď, velmi pravděpodobně by Vaše VM na BIBBOXu jela. I tak ale tuším, že se nám stane silnou inspirací.
ano, jsem taky rád, že naše řešení je lepší :) Díky! Jdeme dobrou cestou.
zkusil jsem si frontend na živém demu a je to téměř přesně, kam se chci dobrat. Drobnosti velkoryse přehlížím.
mají tam jednoduchou správu uživatelů, pro mne příjemné. Všechno mobile friendly + vyhledávání. přístupnost v GUI intuitivní, apps tříděné do skupin jako jsem to začal třídit ve wiki.
u těch app-balíčků vidím, že je jsou nasyslené na githubu (i jinde) a to by ve finále asi taky mohlo tak být. Kvuli místu, nebo dostupnosti...
Teď jen jak zařídit nejlepší cestu k cíli... Máme teď zajímavý vzor, který by mohl usnadnit práci. Jen nevím jak moc.
mentioned in issue Spotter-Cluster#337
Jen pro info: Senaite už jsem zmiňoval v komentáři výše, ...teď jsem k tomu našel nějaké praktické implementace na https://www.bikalims.org/ kde jsou i další varianty https://www.bikalims.org/demos a popis jak to funguje.
Je to postavené na CMS Plone a Baobab LIMS https://baobablims.org a dalších open-source SW.
Pro mne zde není co využít, ale naučil jsem se alespoň, že se tomu říká LIMS (laboratory information management system).
ještě žebříček konkurence https://medevel.com/top-10-foss-lims/
další terminus-technikus je Froid. Free Open Instrument Middleware
DuckDuckovat něco, co konečně vím jak se jmenuje - k nezaplacení!
Jen pro info:
projekt https://www.freedombox.org/ má HW a SW vybavení pro autonomní provoz.
Po zalogování do demoverze https://www.freedombox.org/demo/ jsem viděl různé systemové služby co to umí. (uživatelských aplikací si nevšímám)
Netuším, zda by z toho mohlo být něco budoucí inspirací, nebo usnadněním. Vše se snaží být uživatelsky co nejjednodušší.
Určitě to není nijaké zadání k nové aktivitě. žádná změna projektu, žádná výzva k činnosti,... Jen cedím internety a odkládám na kdykoliv pozdější zájem.
pro info... projekt BBMRI-ERIC® Biobanks directory, který měl na svém webu Bibbox, tak už ho tam nemá. Dokumentaci https://bibbox.readthedocs.io/en/latest/ zatím ještě mají.
Já si sem s dovolením pro úplnost ještě prásknu screenshot z DIALu (Spotter-Cluster#109), protože ten vypadá úplně nejblíž celé té mé představě o tom, jak by ten frontend mohl vypadat a fungovat.
jojo.. mají tam i takové opičárny jako https://registry.dial.community/productmap které jsem sice ani nechtěl, možná jen v nějakých divokých snech uvažoval. To jen tak na okraj.
ostatně mají to GUI tady https://gitlab.com/dial/osc/eng/t4d-online-catalog/product-registry a dá se to i počeštit.
mentioned in issue Spotter-VM#498
uvažuji nahlas tuto "variantu": Při zadání výroby VMMgr zadat frontendistovi forknout projekt DIAL a přizpůsobit ho pro náš účel rozhraní. Co si od toho slibovat?
nevymýšlet zbytečně již vymyšlenou úpravu a funkčnost
doplnit funkčnost která je u nás navíc
doplnit vícejazyčné rozhraní. Oni ta mají podporu více jazyků, ale ještě nevim jak to je udělané, protože to viditelné není. Možná na tom zatím pracují. Tak ať to klidně dopracují.
ve vlastnostech toho rozhraní je nějaký proces "návrhu aplikace zalogovaným uživatelem a schvalování někým kdo je admin" Tohle ještě nevim jestli by bylo k něčemu dobré, ale možná že jo?
do DIAL site se mohou registrovat lidé, kteří patří pod již zaznamenanou aplikaci, kterou tam navrhl někdo jiný. Po nějakém schválení adminem pak může ten člověk popis aplikace upravit Tohle taky nevim jestli se mi to k něčemu hodí, ale chápu že na DIAL web se to hodí
admin zřejmě schvaluje uživatelům nějaké role, nebo vyšší kompetence. Asi k zapisování poznámek, nebo k úpravám v boxíku. Nevim, to jako uživatel nepoznám.
Další věc je nějaká "spekulace" že by podobnost rozhraní mohla přiblížit projekt DIAL a Spotter VM a z našich boxíků by šlo odkazovat na jejich site něbo takněco. Ten projekt jim možná pár let vydrží, přinejmenším do 2030. Jako mít něco společného s větším projektem nemusí být na škodu...?
Třeba bych s tímto cirkusem zaujal Gatese, ten by nabídl tučný balík bankovek a do konce žvota už bych nepracoval (asi jako teď) HAHAHA, no nic...
Má nápad nějaké skryté problémy? Pro frontendistu asi vyšívání z cizího kódu...
To nedává moc smysl. To rozhraní tvoří asi tak 2 % z celého toho repa, je psané v úplně jiném jazyce a komunikuje s backendem úplně jiným způsobem. Jediné, co se z toho dá ukrást je ten vlastní vygenerovaný HTML kód, na což frontendista potřebuje akorát funkční klávesy Ctrl, C a V.
Šlo mi hlavně o ten UI/UX návrh, protože tohle je přesně to, co nosím v hlavě - mřížka karet, každá karta s logem aplikace a pár nejdůležitějšími metadaty (popis aplikace, pro admina i verze a stav instalace třeba) a při najetí myší se zobrazí nějaké konextové ikony, kde se dají vyčíst dodatečné informace o aplikaci, licence, odkaz na manuál a pro admina i ikony, přes které se dá ta aplikace spouštět a zastavovat nebo otevřít její nastavení.
Drtivá většina věcí se u nás odehrává v backendu, protože my tu máme aplikační kontejnery, které fakt dělají i nějakou práci a ne jen databázovou tabulku plnou odkazů na nějaké cizí appky. Ten frontend u nás bude fakt jen jednoduchá fasáda, která z nějakých JSON dat vytažených přes API backendu udělá umělecké dílo a každé kliknutí zase pošle přes to samé API zpátky, aby se na pozadí mohla rozjet soukolí automatizované systémové administrace.
A jak by se to mělo dít? DIAL je katalog. Uživatel zadá do formuláře informace o aplikaci, ta se uloží v databázi, admin je schválí, informace se zobrazí. Jak by měl vypadat workflow v našem případě, kdy nepracujeme s formulářem a informacemi o aplikaci, ale s celými aplikačními kontejnery? Nebo Vám jde jen o ta metadata k aplikacím?
ok, ... zapomeňte na to. Podíval jsem se na ten web ještě trochu víc a myslim že tam je méně použitelných nápadů, než se to původně jevilo. Takže beru zpět ty spekulace, které se vydaly zbytečně daleko. Projekt DIAL je poměrně neobjevný a nedopracovaný.