MOTECH - připomínka termínů medikace pacientů #156

Closed
opened 2017-11-29 02:47:56 +01:00 by Podhorecky · 20 comments
Podhorecky commented 2017-11-29 02:47:56 +01:00 (Migrated from git.spotter.cz)

projekt https://motechproject.org/

code https://github.com/motech

dokumentace http://docs.motechproject.org/en/latest/

vývoj https://applab.atlassian.net/projects/MOTECH/summary

Java, Tomcat MySQL

software umožňující provozovat "mobilní sestřčku" = rozesílání SMS pacientům s připomínkou braní léků
integrace s OpenMRS a jinými SW

teoreticky pro využití v hospicích, nebo v rozvojových projektech

projekt https://motechproject.org/ code https://github.com/motech dokumentace http://docs.motechproject.org/en/latest/ vývoj https://applab.atlassian.net/projects/MOTECH/summary Java, Tomcat MySQL software umožňující provozovat "mobilní sestřčku" = rozesílání SMS pacientům s připomínkou braní léků integrace s OpenMRS a jinými SW teoreticky pro využití v hospicích, nebo v rozvojových projektech
Disassembler commented 2017-11-29 22:24:58 +01:00 (Migrated from git.spotter.cz)

added ~28 label

added ~28 label
Podhorecky commented 2017-12-03 23:39:35 +01:00 (Migrated from git.spotter.cz)

prosím nainstalovat.
Momentálně od toho nečekám nic velkého, pro začátek stačí abych se seznámil s tím, co chtějí tvůrci nabídnout. kdyby to nutně potřebovalo integraci s OpenMRS, tak mi řekněte.

logo http://docs.motechproject.org/en/latest/_images/header.jpg stačí ikona

prosím nainstalovat. Momentálně od toho nečekám nic velkého, pro začátek stačí abych se seznámil s tím, co chtějí tvůrci nabídnout. kdyby to nutně potřebovalo integraci s OpenMRS, tak mi řekněte. logo http://docs.motechproject.org/en/latest/_images/header.jpg stačí ikona
Podhorecky commented 2017-12-03 23:39:41 +01:00 (Migrated from git.spotter.cz)

assigned to @Disassembler

assigned to @Disassembler
Podhorecky commented 2017-12-04 00:12:20 +01:00 (Migrated from git.spotter.cz)

changed title from MOTECH - p{-růzkum-} to MOTECH - p{+řipomínka termínů medikace pacientů+}

changed title from **MOTECH - p{-růzkum-}** to **MOTECH - p{+řipomínka termínů medikace pacientů+}**
Podhorecky commented 2017-12-04 00:12:20 +01:00 (Migrated from git.spotter.cz)

changed the description

changed the description
Disassembler commented 2017-12-05 19:30:20 +01:00 (Migrated from git.spotter.cz)

Dneska do toho buším celý den, ale Motech zatím vyhrává. Podporuje MySQL i Postgres, ale...

  • S PostgreSQL vyhazuje při instalaci mrak errorů. Zjistil jsem, že problém je ve verzi JDBC ovladače. Motech distribuuje ovladač pro verzi 9.1, který je kompatibilní až do verze 9.4. My máme verzi 9.6. Po manuální výměně ovladače mi pak už zbyl error jen jeden, kdy se skript pro populaci databáze dotazuje na sloupec, který v databázi neexistuje a přes který se zatím nejsem schopen dostat.

  • S MySQL vyhazuje při instalaci mrak errorů. :) Ty mají ale spojitost s délkou indexů, která má zase spojitost s kódováním. V MySQL je pevný limit maximálně 767 bajtů na index. Moderní verze MySQL a MariaDB používají kódování utf8mb4, které používá čtyři bajty na znak kvůli podpoře Unicode. Obyčejné utf8 používá jen tři bajty, ale zase podporuje jen Basic Multilingual Plane. Vytvoří-li se index typu CHAR(255) v databázi s utf8 (což samo o sobě je celkem prasečina, indexy mají být z principu co nejkratší), zabere 766 bajtů (3 x 255 + 1 pro null terminátor). Tentýž index v utf8mb4 ale zabere 1021 bajtů a to MySQL už nerozdýchá. Pro naše potřeby by ale obyčejné utf8 mělo stačit, takže po vytvoření databáze s tímto kódování vypadá, že instalace proběhne úspěšně, nicméně aplikace stejně nejede.

Pokračování zítra.

Dneska do toho buším celý den, ale Motech zatím vyhrává. Podporuje MySQL i Postgres, ale... - S PostgreSQL vyhazuje při instalaci mrak errorů. Zjistil jsem, že problém je ve verzi JDBC ovladače. Motech distribuuje ovladač pro verzi 9.1, který je kompatibilní až do verze 9.4. My máme verzi 9.6. Po manuální výměně ovladače mi pak už zbyl error jen jeden, kdy se skript pro populaci databáze dotazuje na sloupec, který v databázi neexistuje a přes který se zatím nejsem schopen dostat. - S MySQL vyhazuje při instalaci mrak errorů. :) Ty mají ale spojitost s délkou indexů, která má zase spojitost s kódováním. V MySQL je pevný limit maximálně 767 bajtů na index. Moderní verze MySQL a MariaDB používají kódování `utf8mb4`, které používá čtyři bajty na znak kvůli podpoře Unicode. Obyčejné `utf8` používá jen tři bajty, ale zase podporuje jen *Basic Multilingual Plane*. Vytvoří-li se index typu `CHAR(255)` v databázi s `utf8` (což samo o sobě je celkem prasečina, indexy mají být z principu co nejkratší), zabere 766 bajtů (3 x 255 + 1 pro null terminátor). Tentýž index v `utf8mb4` ale zabere 1021 bajtů a to MySQL už nerozdýchá. Pro naše potřeby by ale obyčejné `utf8` mělo stačit, takže po vytvoření databáze s tímto kódování vypadá, že instalace proběhne úspěšně, nicméně aplikace stejně nejede. Pokračování zítra.
Disassembler commented 2017-12-05 19:31:26 +01:00 (Migrated from git.spotter.cz)

Btw. minimálně na tu záležitost s Posgresem určitě vytvořím issue v upstreamu, ale napřed se chci dobrat stavu, kdy se mi tu aplikace podaří jakýmkoliv způsobem zprovoznit.

Btw. minimálně na tu záležitost s Posgresem určitě vytvořím issue v upstreamu, ale napřed se chci dobrat stavu, kdy se mi tu aplikace podaří jakýmkoliv způsobem zprovoznit.
Disassembler commented 2017-12-07 15:00:28 +01:00 (Migrated from git.spotter.cz)

closed via commit 03e21dfbfe

closed via commit 03e21dfbfecd24902895770068281d60524907dc
Disassembler commented 2017-12-07 18:20:18 +01:00 (Migrated from git.spotter.cz)

Nainstalováno. Jak jsem se se Sigmahu rozplýval nad Java aplikacemi, tak bych zdůraznil, že mluvím o aplikacích, které ty standardy skutečně dodržují. Kdyby Dalí programoval aplikace, na Motech by byl hrdý.

  • Aplikace deklaruje, že vyžaduje Javu 8, nicméně neběží na Tomcatech novějších než 8.0 (My máme 8.5, aktuální verze je 9.0).
  • Aplikace deklaruje standardy kompatibilní s Javou 4 (léta páně 2003), které ale fakticky ignoruje a používá novější (z r. 2005).
  • Aplikace ignoruje fakt, že domovský adresář instance Tomcatu nemusí být (a ve skutečnosti by ani neměl být) zapisovatelný pro aplikace v něm běžící a snaží se do nich zapsat konfiguraci k aplikaci.
  • Výše uvedená konfigurace ve skutečnosti jen odkazuje na skutečný adresář s konfigurací.
  • V tomto adresáři má každý prd separátní konfigurační soubor. Jeden pro nastavení mailů, dva různé pro nastavení databáze se schematy, dva pro databázi s daty, jeden pro nastavení jazyka atd.
  • Aplikace vyžaduje práva databázového superuživatele, aby si mohla databáze vytvářet sama. Ty jsem jí odmítl udělit a databáze vytvořil ručně.
  • Instalace vyžadovala vytvoření čtyř databází. Aplikace ale fakticky používá jen tři. Ta čtvrtá je nejspíše nějaké historický artefakt, nicméně instalace bez ní selže.
  • Jedna z databází obsahuje popis schemat, jiná pak vlastní data náležící těmto schematům. Laicky řečeno - popis dat v databázi je v jiné databázi. To sice umožňuje vytvořit prakticky jakoukoliv datovou strukturu a vymýšlet nová pole a tabulky, které fakticky nebudou tabulkami, ale také to znamená, že jsou na sobě tyto dvě databáze závislé a je s nimi možno pracovat jen z aplikační perspektivy. Při přímém pohledu do databáze je ztracen kontext dat.
  • Databáze mají pevně daná nezměnitelná jména, protože aplikace výslovně nepodporuje běh v prostředí sdíleném s jinými databázemi a aplikacemi. V dokumentaci sice mají napsáno, jak se to dá obejít, nicméně tento způsob se zdá byt docela nešťastným.
  • Aplikace nepodporuje bezobslužnou instalaci nebo provisioning. Instaluje se přes GUI, prvotní konfigurace se provádí přes GUI, tvorba admina se provádí přes GUI.
  • Aplikace používá message queues (ActiveMQ), ale využívá k nim JMS (Java Messaging System), čímž jedním vrzem zahazuje všchny benefity použití MQ.
  • Použití JMS místo MQ by v krajním případě dávalo smysl, pokud by spolu komunikovalo více různých aplikací nebo procesů používajících stejné messaging schema. To se u Motechu neděje, takže by stačilo použít pouze JMS, které je podporováno přímo Javou, tj. bez externího MQ daemona.

Vyřešil jsem to tedy tak, že společně s Motechem instaluji separátní instanci starého Tomcatu 8.0, nahrazuji JDBC ovladače pro PostgreSQL, kurvím upravuji konfiguraci ActiveMQ, povoluji aplikaci oprávnění k řízení vlastního aplikačního serveru (hóóódně špatný nápad), násilím tlačím několik property souborů, které by mi správně mělo zapsat až GUI a nakonec volám curl, abych simuloval odeslání formuláře pro konfiguraci v GUI. Hnus, velebnosti.

Každopádně pokud tuhle aplikaci budete chtít zachovat, trvám na tom, že musí běžet v kontejneru. Teď už se jen třepu strachy, až mi napíšete, jaká do ní mám instalovat rozšíření, protože jsem nabyl dojmu, že ve výchozím stavu vlastně nic neumí a poskytuje jen jakýsi framework pro integraci ostatních služeb.

Nainstalováno. Jak jsem se se Sigmahu rozplýval nad Java aplikacemi, tak bych zdůraznil, že mluvím o aplikacích, které ty standardy skutečně dodržují. Kdyby Dalí programoval aplikace, na Motech by byl hrdý. - Aplikace deklaruje, že vyžaduje Javu 8, nicméně neběží na Tomcatech novějších než 8.0 (My máme 8.5, aktuální verze je 9.0). - Aplikace deklaruje standardy kompatibilní s Javou 4 (léta páně 2003), které ale fakticky ignoruje a používá novější (z r. 2005). - Aplikace ignoruje fakt, že domovský adresář instance Tomcatu nemusí být (a ve skutečnosti by ani neměl být) zapisovatelný pro aplikace v něm běžící a snaží se do nich zapsat konfiguraci k aplikaci. - Výše uvedená konfigurace ve skutečnosti jen odkazuje na *skutečný* adresář s konfigurací. - V tomto adresáři má každý prd separátní konfigurační soubor. Jeden pro nastavení mailů, dva různé pro nastavení databáze se schematy, dva pro databázi s daty, jeden pro nastavení jazyka atd. - Aplikace vyžaduje práva databázového superuživatele, aby si mohla databáze vytvářet sama. Ty jsem jí odmítl udělit a databáze vytvořil ručně. - Instalace vyžadovala vytvoření čtyř databází. Aplikace ale fakticky používá jen tři. Ta čtvrtá je nejspíše nějaké historický artefakt, nicméně instalace bez ní selže. - Jedna z databází obsahuje popis schemat, jiná pak vlastní data náležící těmto schematům. Laicky řečeno - popis dat v databázi je v jiné databázi. To sice umožňuje vytvořit prakticky jakoukoliv datovou strukturu a vymýšlet nová pole a tabulky, které fakticky nebudou tabulkami, ale také to znamená, že jsou na sobě tyto dvě databáze závislé a je s nimi možno pracovat jen z aplikační perspektivy. Při přímém pohledu do databáze je ztracen kontext dat. - Databáze mají pevně daná nezměnitelná jména, protože aplikace výslovně nepodporuje běh v prostředí sdíleném s jinými databázemi a aplikacemi. V [dokumentaci](http://docs.motechproject.org/en/latest/demos/different_DB_names.html) sice mají napsáno, jak se to dá obejít, nicméně tento způsob se zdá byt docela nešťastným. - Aplikace nepodporuje bezobslužnou instalaci nebo *provisioning*. Instaluje se přes GUI, prvotní konfigurace se provádí přes GUI, tvorba admina se provádí přes GUI. - Aplikace používá message queues (ActiveMQ), ale využívá k nim JMS (*Java Messaging System*), čímž jedním vrzem zahazuje všchny benefity použití MQ. - Použití JMS místo MQ by v krajním případě dávalo smysl, pokud by spolu komunikovalo více různých aplikací nebo procesů používajících stejné messaging schema. To se u Motechu neděje, takže by stačilo použít *pouze* JMS, které je podporováno přímo Javou, tj. bez externího MQ daemona. Vyřešil jsem to tedy tak, že společně s Motechem instaluji separátní instanci starého Tomcatu 8.0, nahrazuji JDBC ovladače pro PostgreSQL, ~~kurvím~~ upravuji konfiguraci ActiveMQ, povoluji aplikaci oprávnění k řízení vlastního aplikačního serveru (hóóódně špatný nápad), násilím tlačím několik *property* souborů, které by mi správně mělo zapsat až GUI a nakonec volám *curl*, abych simuloval odeslání formuláře pro konfiguraci v GUI. Hnus, velebnosti. Každopádně pokud tuhle aplikaci budete chtít zachovat, trvám na tom, že musí běžet v kontejneru. Teď už se jen třepu strachy, až mi napíšete, jaká do ní mám instalovat rozšíření, protože jsem nabyl dojmu, že ve výchozím stavu vlastně nic neumí a poskytuje jen jakýsi framework pro integraci ostatních služeb.
Podhorecky commented 2017-12-07 19:02:08 +01:00 (Migrated from git.spotter.cz)

uf, tak tohle se čte hezky jen s dávkou dětinského masochismu. Nicméně vážně: Držel jsem palce že to dáte, to jsem rád. Vidím, že i zde jde o lahůdku. Pokud z pohledu budoucí údržby řeknete, že to nemá smysl, nebudu dál tlačit na pilu a Motech zahibernujeme.

Teď mě nenapadá další rozšíření. Budu se muset víc seznámit, jestli to nutně vyžaduje napojení na zdravotnická data nebo SW. A jestli ke komunikaci se světem potřebuje další SW typu SMS gateway. (mailserver předpokládám to chce).

Samostatný kontejner by znamenal tedy zvlášť OS+SW = cca 2-3GB místa?

uf, tak tohle se čte hezky jen s dávkou dětinského masochismu. Nicméně vážně: Držel jsem palce že to dáte, to jsem rád. Vidím, že i zde jde o lahůdku. Pokud z pohledu budoucí údržby řeknete, že to nemá smysl, nebudu dál tlačit na pilu a Motech zahibernujeme. Teď mě nenapadá další rozšíření. Budu se muset víc seznámit, jestli to nutně vyžaduje napojení na zdravotnická data nebo SW. A jestli ke komunikaci se světem potřebuje další SW typu SMS gateway. (mailserver předpokládám to chce). Samostatný kontejner by znamenal tedy zvlášť OS+SW = cca 2-3GB místa?
Disassembler commented 2017-12-07 20:48:33 +01:00 (Migrated from git.spotter.cz)

Samostatný kontejner by znamenal tedy zvlášť OS+SW = cca 2-3GB místa?

Vidím to tak, že kontejnerování nás nakonec stejně nemine. I z hlediska údržby to bude jednodušší. Přímo na VM pojede akorát databáze a web server a bude tam persistentní adresář s daty. Pak se buildne kontejner, namountuje si datový adresář a spustí si aplikaci. Při update se prostě kontejner zahodí a buildne znovu v nové verzi a pak se akorát napojí na stávající databázi a data a v případě potřeby pustí nějaký upgradovací/migrační skript. Stejně tak to bude jednodušší se zálohováním, protože se budou zálohovat pouze ta persistentní data, která už budou dopředu umístěna ve stejném nadřazeném adresáři.

Také pak budeme moci dělat to, že si lokální admin ve webovém rozhraní bude moci jednotlivé kontejnery zapínat a vypínat, takže se pak vlezeme i do scénáře "Laptop za 8K z výprodeje z Datartu", na kterém se prostě zapne jeden nebo dva kontejnery a zbytek, na který nejsou systémové prostředky, se nechá vypnutý.

K otázce velikosti - pokud se nám podaří operovat s kontejnery postavenými na Alpine linuxu, vyšlo mi cca 300 MB navíc. Pokud bychom museli použít plnotučný Debian, pak 1 GB. Samozřejmě pak záleží kolik kontejnerů budeme mít a kolik jich bude dědit ze společných předků. Docker používá systém OverlayFS, kde na disku fakticky zabírá místo jen základní image a k tomu jen ta data, která se mezi kontejnery liší. Tohle téma pak můžeme otevřít a prozkoumat, pokud bude potřeba srážet velikost. Btrfs má ještě nějaké další deduplikační featury, takže výsledná velikost by i s plně kontejnerovanou VM mohla být docela rozumná. K tomu ale potřebuji, abychom nějak finalizovali užší výběr aplikací a nepřidávali do nekonečna další. Pak teprve budu moci zvolit vhodnou kontejnerovou a zeštíhlovací strategii.

> Samostatný kontejner by znamenal tedy zvlášť OS+SW = cca 2-3GB místa? Vidím to tak, že kontejnerování nás nakonec stejně nemine. I z hlediska údržby to bude jednodušší. Přímo na VM pojede akorát databáze a web server a bude tam persistentní adresář s daty. Pak se buildne kontejner, namountuje si datový adresář a spustí si aplikaci. Při update se prostě kontejner zahodí a buildne znovu v nové verzi a pak se akorát napojí na stávající databázi a data a v případě potřeby pustí nějaký upgradovací/migrační skript. Stejně tak to bude jednodušší se zálohováním, protože se budou zálohovat pouze ta persistentní data, která už budou dopředu umístěna ve stejném nadřazeném adresáři. Také pak budeme moci dělat to, že si lokální admin ve webovém rozhraní bude moci jednotlivé kontejnery zapínat a vypínat, takže se pak vlezeme i do scénáře "Laptop za 8K z výprodeje z Datartu", na kterém se prostě zapne jeden nebo dva kontejnery a zbytek, na který nejsou systémové prostředky, se nechá vypnutý. K otázce velikosti - pokud se nám podaří operovat s kontejnery postavenými na Alpine linuxu, vyšlo mi cca **300 MB** navíc. Pokud bychom museli použít plnotučný Debian, pak **1 GB**. Samozřejmě pak záleží kolik kontejnerů budeme mít a kolik jich bude dědit ze společných předků. Docker používá systém OverlayFS, kde na disku fakticky zabírá místo jen základní image a k tomu jen ta data, která se mezi kontejnery liší. Tohle téma pak můžeme otevřít a prozkoumat, pokud bude potřeba srážet velikost. Btrfs má ještě nějaké další deduplikační featury, takže výsledná velikost by i s plně kontejnerovanou VM mohla být docela rozumná. K tomu ale potřebuji, abychom nějak finalizovali užší výběr aplikací a nepřidávali do nekonečna další. Pak teprve budu moci zvolit vhodnou kontejnerovou a zeštíhlovací strategii.
Podhorecky commented 2017-12-07 22:08:32 +01:00 (Migrated from git.spotter.cz)

Rozumím. díky za vysvětlení. Návrh s oddělením do kontejnerů dává smysl a zatím mi připadá že to dostatečně řeší následné updaty sw, uvidíme v praxi. Kdyby náhodou v budoucnu se mi narodil nějaký nápad, nejdřív to probereme a z toho vypadne výsledek.

Pokud jde řádově o tuto velikost, tak jsem v pohodě... Začal bych se bát až když by VM přesahovala 30-40GB...

co se týče počtu aplikací a finalizace:
Ano, chápu a cítím, že to je potřeba rozetnout. Teď tedy návrh dopracování. pak bude stop-stav na moje objevování sw.

Návrh na poslední aplikace:
FrontlineSMS (mam naději že to nebude těžké, ale můžu se mýlit)
OpenMap Kit (taky naděje, že to je hladká instalace) to prostě potřebuji alespoň vidět,

co se týče kombinací SW, tak nechám na vás jak to třídit.

Odloženo na později:

  • všechny další nápady odvozené z řešení OpenData Kit (AKVO atd..) dokud se s tím nějak neseznámím. Ono to bude dost podobné jako ODK, pochopitelně se liší v detailech kdo si co doprogramuje a na jaký cloud instaluje.
    diaspora- tohle je low-priority, spíš pro VM Spotter-Media
    POSM- tohle by taky zatím odložil, evidentně se to stejně dá rozdělit na jednotlivé SW: jmenovitě:
    HOT tasking manager - to počká, stejnak už teď tuším poblémy
    mapserver pro OSM a offline mapy - odložit
    OpenDrone Map - na později, zrovna dneska jsem zkoumal jak lepí do sebe fotky z dronů a výsledek umí umístit podle souřadnic do mapy. To je docela sexy featura, ale počká. Něco podobného umí ještě https://www.youtube.com/watch?v=-kSTDvGZ-YQ (taky na Gitu)
    Mifos X - na tom hned netrvám, nechám si poradit zda to je zas nějaký peklo. Tematicky to patří do zájmů NNO, ale spíš těch rozvojových.

k diskusi - nejsem rozhodnutý ano/ne
existuje cosi jako http://geoshape.org což je vpodstatně rozšířený GeoNode tj. takový akosi CKAN určený hlavně na mapy. Tyhle datové sklady vypadají sice podobně, ale liší se. Já potřebuji první zpětnou vazbu od lidí, kteří jsou svou prací schopni tvořit nějaká geodata a pak je archivovat. Pokud zareagují že dobrý, pak bych do toho šel. Na světě je několik velkých portálů tohoto typu, přidanou hodnotu vidím v teprv až by došlo k budoucí "výměně dat".
Mimochodem, Geoshape používá v interface OpenLayers3 což je (na mojí zkušenost s připojením) závratně rychlé.

Tím se plynule dostávám k tomu, co vás potěší: Z posledních vyjádření na skupině Sahana jsem vyčetl, že přechod na OpenLayers3 a leaflet knihovnu mají v plánu, ale nebyly slíbeny detaily. Takže po vás ani po člověku který by se vrtal v SE to nebudu chtít, zbývá čekat. Nanejvýš se může doptat F+D jak to myslí, ale nepočítám, že bych je přemluvil na změnu roadmapy.

Moje další průzkumy SW, které dopisuji do wiki, klidně otevřeme jindy.

Pak tedy bude prostor na úpravu a vývoj architektury VM. Možná máte ještě připravené nápady na zálohování nebo zabezpečení.(?)
Ještě bych rád zkusil to synchro dat mezi dvěma instancemi SE. A alespoň pokus o spojení Sambro Mobile se SAMBRO.

Pak můžeme dojít k vylepšní intro, ale to pouze po funkční stránce. Nyní je připravena pro adminy, určitě ne pro (potenciální) usery. Možná že user dostane od admina jen URL do browseru, to by mu mohlo stačit, ale spoléhat na to nejde.

Napište, případně rozšiřte tento koncept jak se dostat k prvnímu cíli.
Pak bych potřeboval tu VM stáhnout a vyzkoušet první zkušenost s VM, splaším někde Android GSM modem a pokusím se povrtat v SMS službách.

Pak se dá na to navázat. Práce vidím ještě dost.

Rozumím. díky za vysvětlení. Návrh s oddělením do kontejnerů dává smysl a zatím mi připadá že to dostatečně řeší následné updaty sw, uvidíme v praxi. Kdyby náhodou v budoucnu se mi narodil nějaký nápad, nejdřív to probereme a z toho vypadne výsledek. Pokud jde řádově o tuto velikost, tak jsem v pohodě... Začal bych se bát až když by VM přesahovala 30-40GB... co se týče počtu aplikací a finalizace: Ano, chápu a cítím, že to je potřeba rozetnout. Teď tedy návrh dopracování. pak bude stop-stav na moje objevování sw. **Návrh na poslední aplikace:** **FrontlineSMS** (mam naději že to nebude těžké, ale můžu se mýlit) **OpenMap Kit** (taky naděje, že to je hladká instalace) to prostě potřebuji alespoň vidět, co se týče kombinací SW, tak nechám na vás jak to třídit. **Odloženo na později:** - všechny další nápady odvozené z řešení OpenData Kit (**AKVO** atd..) dokud se s tím nějak neseznámím. Ono to bude dost podobné jako ODK, pochopitelně se liší v detailech kdo si co doprogramuje a na jaký cloud instaluje. **diaspora**- tohle je low-priority, spíš pro VM Spotter-Media **POSM**- tohle by taky zatím odložil, evidentně se to stejně dá rozdělit na jednotlivé SW: jmenovitě: **HOT tasking manager** - to počká, stejnak už teď tuším poblémy **mapserver pro OSM** a offline mapy - odložit **OpenDrone Map** - na později, zrovna dneska jsem zkoumal jak lepí do sebe fotky z dronů a výsledek umí umístit podle souřadnic do mapy. To je docela sexy featura, ale počká. Něco podobného umí ještě https://www.youtube.com/watch?v=-kSTDvGZ-YQ (taky na Gitu) **Mifos X** - na tom hned netrvám, nechám si poradit zda to je zas nějaký peklo. Tematicky to patří do zájmů NNO, ale spíš těch rozvojových. **k diskusi - nejsem rozhodnutý ano/ne** existuje cosi jako http://geoshape.org což je vpodstatně rozšířený **GeoNode** tj. takový akosi CKAN určený hlavně na mapy. Tyhle datové sklady vypadají sice podobně, ale liší se. Já potřebuji první zpětnou vazbu od lidí, kteří jsou svou prací schopni tvořit nějaká geodata a pak je archivovat. Pokud zareagují že dobrý, pak bych do toho šel. Na světě je několik velkých portálů tohoto typu, přidanou hodnotu vidím v teprv až by došlo k budoucí "výměně dat". Mimochodem, **Geoshape** používá v interface OpenLayers3 což je (na mojí zkušenost s připojením) závratně rychlé. Tím se plynule dostávám k tomu, co vás potěší: Z posledních vyjádření na skupině Sahana jsem vyčetl, že přechod na OpenLayers3 a leaflet knihovnu mají v plánu, ale nebyly slíbeny detaily. Takže po vás ani po člověku který by se vrtal v SE to nebudu chtít, zbývá čekat. Nanejvýš se může doptat F+D jak to myslí, ale nepočítám, že bych je přemluvil na změnu roadmapy. Moje další průzkumy SW, které dopisuji do wiki, klidně otevřeme jindy. Pak tedy bude prostor na úpravu a vývoj architektury VM. Možná máte ještě připravené nápady na zálohování nebo zabezpečení.(?) Ještě bych rád zkusil to synchro dat mezi dvěma instancemi SE. A alespoň pokus o spojení Sambro Mobile se SAMBRO. Pak můžeme dojít k vylepšní intro, ale to pouze po funkční stránce. Nyní je připravena pro adminy, určitě ne pro (potenciální) usery. Možná že user dostane od admina jen URL do browseru, to by mu mohlo stačit, ale spoléhat na to nejde. Napište, případně rozšiřte tento koncept jak se dostat k prvnímu cíli. Pak bych potřeboval tu VM stáhnout a vyzkoušet první zkušenost s VM, splaším někde Android GSM modem a pokusím se povrtat v SMS službách. Pak se dá na to navázat. Práce vidím ještě dost.
Podhorecky commented 2017-12-07 22:39:47 +01:00 (Migrated from git.spotter.cz)

Jen pro představu:
Každý rok je v ČR několik veřejných akcí týkající se NNO, které bych si troufl navštívit. např, NGO Market https://www.forum2000.cz/projekty/ngo-market (jaro), nebo konference kolem Map a NGO a menší jednotlivosti. To ještě neznamená, že se tam budu předvádět, ale musím je monitorovat a v příznivé chvíli umět co říct. Až budu mít první VM, stále ještě budu ve fázi testů a vývoje a odvšivování. Nicméně v 2018 bych chtěl veřejně vystavit web https://spotter.ngo , kde budou jen řeči, ale nic konkrétně k vidění. Abych mohl o tématu vzbudit zájem a s někým hovořit. Bojím se vzbuzovat zájem a nemít co ukázat na svém NTB.

Pak chci jazykově učesat sdělení na webu, na to asi budu potřebovat copywritera, nebo nějakou komunikační agenturu, aby mi poradili. Moc se na to netěším, ale lepší nápad nemám.

Moje další domény a weby na forpsi jsou teď v lehkém bordelu. Poslední měsíc jsem se snažil přeinstalovat Wordpress a vyrobit multisite. Wordpress běží, šablony taky, nicméně s doménovým nastavením jsem se v tom zasekl, takže mi domény nefungují jak mám v plánu. Ve slabé chvilce bych si troufl vás poprosit, detaily vysvětlím.

S nynějšími aplikacemi na VM se mi skládá dohromady celá mozaika co chci, co se dá dělat a jak to má makat. A na to připravím pár webových stránek, kde to bude napsané a s tím pak budu před někým prezentovat. Když to udělám srozumitelně, tak by to mohlo i překvapit.

Kombinace SW kterými se zabýváme, má potenciál, který si nepoučený člověk ani nedovede představit. Lidi co SW viděli v zahraničí to ví, ale nemyslím, že by se dostali k nim blíž.

Jen pro představu: Každý rok je v ČR několik veřejných akcí týkající se NNO, které bych si troufl navštívit. např, NGO Market https://www.forum2000.cz/projekty/ngo-market (jaro), nebo konference kolem Map a NGO a menší jednotlivosti. To ještě neznamená, že se tam budu předvádět, ale musím je monitorovat a v příznivé chvíli umět co říct. Až budu mít první VM, stále ještě budu ve fázi testů a vývoje a odvšivování. Nicméně v 2018 bych chtěl veřejně vystavit web https://spotter.ngo , kde budou jen řeči, ale nic konkrétně k vidění. Abych mohl o tématu vzbudit zájem a s někým hovořit. Bojím se vzbuzovat zájem a nemít co ukázat na svém NTB. Pak chci jazykově učesat sdělení na webu, na to asi budu potřebovat copywritera, nebo nějakou komunikační agenturu, aby mi poradili. Moc se na to netěším, ale lepší nápad nemám. Moje další domény a weby na forpsi jsou teď v lehkém bordelu. Poslední měsíc jsem se snažil přeinstalovat Wordpress a vyrobit multisite. Wordpress běží, šablony taky, nicméně s doménovým nastavením jsem se v tom zasekl, takže mi domény nefungují jak mám v plánu. Ve slabé chvilce bych si troufl vás poprosit, detaily vysvětlím. S nynějšími aplikacemi na VM se mi skládá dohromady celá mozaika co chci, co se dá dělat a jak to má makat. A na to připravím pár webových stránek, kde to bude napsané a s tím pak budu před někým prezentovat. Když to udělám srozumitelně, tak by to mohlo i překvapit. Kombinace SW kterými se zabýváme, má potenciál, který si nepoučený člověk ani nedovede představit. Lidi co SW viděli v zahraničí to ví, ale nemyslím, že by se dostali k nim blíž.
Podhorecky commented 2017-12-08 00:43:52 +01:00 (Migrated from git.spotter.cz)

Moduly ještě pročtu a vyberu. Na Githubu píší, že se instalují přesunutím do adresáře. Tak nevim, snad to není léčka.

Moduly ještě pročtu a vyberu. Na Githubu píší, že se instalují přesunutím do adresáře. Tak nevim, snad to není léčka.
Podhorecky commented 2017-12-08 03:58:49 +01:00 (Migrated from git.spotter.cz)

tak jsem přidal moduly, zkuste si to v GUI (odebrat/přidat)

tak jsem přidal moduly, zkuste si to v GUI (odebrat/přidat)
Disassembler commented 2017-12-08 22:41:40 +01:00 (Migrated from git.spotter.cz)

mentioned in issue #166

mentioned in issue #166
Podhorecky commented 2018-03-14 22:41:18 +01:00 (Migrated from git.spotter.cz)

changed milestone to %2

changed milestone to %2
Disassembler commented 2018-03-30 16:41:55 +02:00 (Migrated from git.spotter.cz)

added ~31 label

added ~31 label
Disassembler commented 2018-03-30 16:49:22 +02:00 (Migrated from git.spotter.cz)

mentioned in issue #246

mentioned in issue #246
Podhorecky commented 2018-10-15 11:27:45 +02:00 (Migrated from git.spotter.cz)

changed milestone to %5

changed milestone to %5
Sign in to join this conversation.
No project
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Disassembler/Spotter-VM#156
No description provided.