heureka

[ghost]

už umím načítat kódy jako mobilní apka od heuréky, není to úplně košér, nejsem si jistý jestli tento parser zveřejnit, ale jistě by se ve finální aplikaci mohl používat

[ondrej-smola]

Tak osobne bych uprednostnoval se s nima zkusit nejdriv dohodnout :). Jsme se o tom s @Lweek bavili - ze by se poptal - tak uvidime.

[ghost]

no tak mame o argument navic

[Lweek]

@Charon351 @ondrej-smola Jsem domluvený s Markem Beniakem na příští středě. Ukážu mu apku a zkusím se s ním domluvit co by se dalo.

[ghost]

Ok, no minimalne jsem ziskal dalsi skilly.

Dale mam vyhlidle ziskani dat z zdravapotravina.cz ve slozeni mivaji napsano pokud obsahuje palmovy olej

[ghost]

tak jak ?

[Lweek]

@Charon351 Ahoj, promiň za lag. S Markem jsme se sešli, souhlasil že by to zahostovali. Co se týče jejich EAN databáze, říkal že je nekonzistentní. Že jim kody posílají eshopy a stává se že jeden výrobek má víc EAN apod. Ale asi jinak by to taky nemusel být problém. Říkal že se na náš kod podívají jejich prgátoři a bude se to řešit dál. Problém je, že zrovna dokončují závěrku a není na to moc čas. Zkusím se ASAP znovu sejít s Markem a posunout to dál. Díky za trpělivost.

[Lweek]

Zdravím ve spolek! Žijete? Vím že to trvalo dlouho, ale věci se dali do pohybu až teď. Mám pro vás dobré zprávy. Napište mi prosím kdo z vás tu ještě je, a má zájem to dotáhnout do cíle? :)

Drobná změna. Data nebudeme dolovat z netu, ale od lidí. Takže bude ještě potřeba přidělat jeden endpoint na API.

Byl by zájem se někde sejít a probrat to?

[Ttxman]

Tak jako existuju, ale s časem je to trochu horší :)

[RadarCZ]

U mě by se našel i čas, ale nebude ho moc

[ondrej-smola]

Ahoj, s casem jsem minimalne do konce roku v ...

2015-11-24 10:04 GMT+01:00 Lukáš Kubíček notifications@github.com:

U mě by se našel i čas, ale nebude ho moc

— Reply to this email directly or view it on GitHub https://github.com/ZooHackaton2015/PalmOilChecker/issues/1#issuecomment-159201444 .

[ghost]

Existuju a nějaká chvilka se vždy najít dá.

Víc jak 6 hodin spánku netřeba :D

[Ttxman]

:) když jsem psal trochu horší, tak to neznamená žádnej čas. Jenom to už není neomezeně :)

[Lweek]

Super, mě by se hlavně hodil někdo z vás, kdo umí scalu a dodělal by ten zapisovací endpoint. Takhle, juknu na to, jestli bych to nezvládl sám. Předpokládám, že to nebude žádný velký brutus. :) Ale samozřejmě pokud by se na to vrhnul někdo kdo má alespoň nějakou zkušenost se Scalou, tak to bude fajn.

Jak budeme sbírat data je ještě potřeba domyslet. Teď už s jistotou víme, že od lidí. Sdružení Listari má hromadu fanoušků. Takže buď budeme distribuovat dvě verze aplikace. Jednu pro koncáky a druhou pro členy sdružení, kteří budou zároveň budovat obsah, a nebo by se vymyslel nějaký alg. který by validoval data na základě množství sesbíraných dat.

Dneska jdu na oběd s Heurekou. Ta už přislíbila hosting, a možná pro nás bude i distribuovat apku. Uvidíme na čem se dohodneme.

Jinak z Listari dobré zprávy. Zájem o problematiku raketově roste. Listari se přihlásila hromada lidí a firem kteří chtějí pomoct. Zároveň získali granty z EU a navázali spolupráci s jednou z největších PR agentur v ČR. Bude to jízda!!!

[ondrej-smola]

Tak endpoint se stejne musi predelat - prakticky se da pouzit misto Scaly cokoliv jinyho (neni to nic slozityho) ... Redis bych urcite vymenil za napr. Cassandru nebo Riak ... kvuli in memory omezenim. Scala by byla zajimava az s ohledme na nasazeni napr. strojoveho uceni, analytiky apod. Na klasickej CRUD staci napr. node.js. Kdyz se dohondem na API v apiary tak nakodit jto je otazka max par hodin ... to bych i zvladl :).

Dne 24. listopadu 2015 11:00 Vladimír Bělohradský notifications@github.com napsal(a):

Super, mě by se hlavně hodil někdo z vás, kdo umí scalu a dodělal by ten zapisovací endpoint. Takhle, juknu na to, jestli bych to nezvládl sám. Předpokládám, že to nebude žádný velký brutus. :) Ale samozřejmě pokud by se na to vrhnul někdo kdo má alespoň nějakou zkušenost se Scalou, tak to bude fajn.

Jak budeme sbírat data je ještě potřeba domyslet. Teď už s jistotou víme, že od lidí. Sdružení Listari má hromadu fanoušků. Takže buď budeme distribuovat dvě verze aplikace. Jednu pro koncáky a druhou pro členy sdružení, kteří budou zároveň budovat obsah, a nebo by se vymyslel nějaký alg. který by validoval data na základě množství sesbíraných dat.

Dneska jdu na oběd s Heurekou. Ta už přislíbila hosting, a možná pro nás bude i distribuovat apku. Uvidíme na čem se dohodneme.

Jinak z Listari dobré zprávy. Zájem o problematiku raketově roste. Listari se přihlásila hromada lidí a firem kteří chtějí pomoct. Zároveň získali granty z EU a navázali spolupráci s jednou z největších PR agentur v ČR. Bude to jízda!!!

— Reply to this email directly or view it on GitHub https://github.com/ZooHackaton2015/PalmOilChecker/issues/1#issuecomment-159214092 .

[ghost]

Tak se scalou toho moc neudělám, ale zas se to dá relativně rychle překlopit do nodejs, php, go.

Také je otázkou od lidí co přesně to znamená, zda přes apku nebo třeba web page, zda budou nějak registrovaní ...

[Lweek]

To je fakt. Ve finále to je možná na pár minut. Protože když se veme Node.js nebo PyFlask a použije se Alchemy, tak na tom v zásadě není skoro žádná práce. Cachovat se to nemusí, to by dokonce nedávalo žádný smysl, pač poměr cache ku data je 1:1 a data hledají podle čísla, kdežto cache podle hashe URL ... myslím že všichni cítíme v kostech co je rychlejší. :D

[Lweek]

PHP bych nepoužil. Je to realtime služba a PHP by mělo podle mne zbytečnou režii.

[ondrej-smola]

Pokud nechces rezii tak pouzij Scalu nebo Go ... pripadne muzes jit rovnou do C++ :).

Dne 24. listopadu 2015 11:17 Vladimír Bělohradský notifications@github.com napsal(a):

PHP bych nepoužil. Je to realtime služba a PHP by mělo podle mne zbytečnou režii.

— Reply to this email directly or view it on GitHub https://github.com/ZooHackaton2015/PalmOilChecker/issues/1#issuecomment-159218868 .

[ghost]

php tak ano i ne, cachovat se dá přimo i na web serveru treba nginx protože na ten samy request dostaneš vždy stejnou odpověď pokud se nastaví rozumný timeout třeba hodinka tak no stress, nebo se případně dá moužít nginx s invalidací cache pomocí třeba memcached

[Lweek]

Já navrhuji Nginx + Node.js + Mongo. Mongo kvůli verzování. Vlastně čtecí dotazy by mohli jít z nginx přímo do monga a zapisovací by šli přes Node.JS. Jinak jo, Nginx je potřeba kvůli frontě. Node.JS ani Mongo by nedovedlo obsloužit velký počet dotazů v jeden moment. Agregace výsledků na straně Nginx je příjemný bonus. :)

[Ttxman]

Vzhledem k tomu, ze pri cteni neni potreba udrzovat zadnej stav, tak bych pro verejnou cast bych proste nastavil nginx proxy (nebo mozna nodejs, ale nemam ho rad) pro autentifikace a telo pozadavku proste primo forwardoval na mongo/elastic/couch vsichni maji nejakou formu REST pristupu. (minimalne pro cteni v pripade monga).

Nema cenu tomu do cesty stavet dalsi vrstvy, kdyz skalovat muzou DB samotny :)

[Lweek]

Ad cachování. Tady se podle mne nehodí. Budeme pracovat s miliony řádků dat a dotazy budou četné a velmi různorodé. Obávám se, že cachování by v tomto případě byl spíš problém než užitek. Jinak bych možná ani nevracel JSON, ale prostě jen status kod (200/404) a 1/0 jako výsledek čtení z DB. JSON by byl v tomto případě zbytečný datový odpad.

[Lweek]

@Ttxman Záleží na tom, jestli bude nějaká vyšší logika při zápisu (vyhodnocování). Ale je pravda, že by se to dalo asi zapsat jako DB fce.

[Lweek]

Dalo by se to realizovat tak, že budou dvě tabulky (db dle terminologie), jedna bude obsahovat hotové záznamy. Z těch bude čerpat čtecí endpoint. Bude to číslo produktu a bool přítomnost oleje. A druhá tabulka bude obsahovat číslo produktu a bool oleje a UID zařízení. Až se jich sejde třeba deset tak se vyhodnotí, data se přesunou do té čtecí tabulky jako jeden řádek a ze zapisovací tabulky se záznamy smažou. Ale ještě uvidíme jestli to bude potřeba. Jsou dva scénáře. V jednom budou data zadávat všichni. V druhém budou data zadávat jen stoupenci organizace. Tohle ještě zjistím. Ale je fajn, že nám to tu tak pěkně jiskří nápadama. :+1:

[Ttxman]

Já předpokládám, že budeme chtít i něco jiného než olej ano/ne. ULR fotky výrobku (nebo přímo obrázek)? Datum kdy řepkoolejková lobby dotlačila výrobce aby přestal používat palmový olej? nějaký OK kupuji / nekupuju díky informaci z této aplikace + zobrazení počtu lidí v aplikaci? Fakt není problém v response vracet json. HTTP hlavička je sama o sobě tak gigantická, že se něco jako {status: OK} v případě nalezení hodnoty ztratí. (představte si headery pro povolení cross site XHR, autentifikaci a nastavení cachování)

Ad přidávání a vyhodnocování - to bych udělal úplně bokem. Většina trafficu pojede v read only módu a nemá cenu tam stavět do cesty cokoliv. (jako cache stačí spoléhat na cache-control headery, jsme jak google není potřeba 100% realtime schoda výsledků s DB)

Zápis nových výrobků a aktualizace (neberu countery nákupů nebo tak něco to není problém přez rest) může jít úplně bokem přez libovolnej interface klidně i na jinym serveru/hostingu i desítky přístupů za minutu jsou scifi.

A v případě výpočtů nějakých statistik a podobně v mongu jsou tailable cursory (třeba i na oplogu) co můžou taky běžet bokem...

[ondrej-smola]

Osobne bych se spis klonil k reseni pomoci simple aplikace + nejaka skaolvatelna KV/document store (Riak, Cassandra, ElasticSearch). Tj napr. golang + elasticsearch. Z principu tam bude potreba naka jednoducha aplikacni logika. Nginx neni treba. Vracet json potrebujem pac jakmile zjistime, ze potrebujem vic nez ano ne tak to bude z hlediska api na novou verzi :).

Dne 24. listopadu 2015 11:56 Ladislav Šeps notifications@github.com napsal(a):

Já předpokládám, že budeme chtít i něco jiného než olej ano/ne. ULR fotky výrobku (nebo přímo obrázek)? Datum kdy řepkoolejková lobby dotlačila výrobce aby přestal používat palmový olej? nějaký OK kupuji / nekupuju díky informaci z této aplikace + zobrazení počtu lidí v aplikaci? Fakt není problém v response vracet json. HTTP hlavička je sama o sobě tak gigantická, že se něco jako {status: OK} v případě nalezení hodnoty ztratí. (představte si headery pro povolení cross site XHR, autentifikaci a nastavení cachování)

Ad přidávání a vyhodnocování - to bych udělal úplně bokem. Většina trafficu pojede v read only módu a nemá cenu tam stavět do cesty cokoliv. (jako cache stačí spoléhat na cache-control headery, jsme jak google není potřeba 100% realtime schoda výsledků s DB) Zápis nových výrobků a aktualizace (neberu countery nákupů nebo tak něco to není problém přez rest) může jít úplně bokem přez libovolnej interface klidně i na jinym serveru/hostingu i desítky přístupů za minutu jsou scifi.

A v případě výpočtů nějakých statistik a podobně v mongu jsou tailable cursory (třeba i na oplogu) co můžou taky běžet bokem...

— Reply to this email directly or view it on GitHub https://github.com/ZooHackaton2015/PalmOilChecker/issues/1#issuecomment-159229190 .

[ghost]

tak tak, statistiky a připadné vyhodnocování se dá dělat bokem, také souhlasím, že to jestli daný ean je či není na palmový olej pozitivní nemusí jet úplně realtime, proto jsem navrhl tu cache na nginxu, samozřejmě jen pro search

škálování, nejsem si jistý zda je to třeba i obyčejný hosting obslouží stovky dotazů za sekundu a tolik jich nikdy nebude, vím to memfun.cz jsem provozoval na jednom serveru a byla tam návštěvnost 100k unik / den a to byla data v mysql, aplikace v nette (php) postupně co šlo se rvalo do apc cachi ale cela page se rendrovala per user. Nejvíc prostředků ale stejně žrala databáze.

navíc nějakou cache by měla mít i samotná aplikace

[ondrej-smola]

Tam pak jde spis treba o budouci rozsiritelnost, odolnost vuci vypadkum a fulltext search ... jinak mysql to zvladne taky o to se nebojim :) .

Dne 24. listopadu 2015 12:56 Karel Blavka notifications@github.com napsal(a):

tak tak, statistiky a připadné vyhodnocování se dá dělat bokem, také souhlasím, že to jestli daný ean je či není na palmový olej pozitivní nemusí jet úplně realtime, proto jsem navrhl tu cache na nginxu, samozřejmě jen pro search

škálování, nejsem si jistý zda je to třeba i obyčejný hosting obslouží stovky dotazů za sekundu a tolik jich nikdy nebude, vím to memfun.cz jsem provozoval na jednom serveru a byla tam návštěvnost 100k unik / den a to byla data v mysql, aplikace v nette (php) postupně co šlo se rvalo do apc cachi ale cela page se rendrovala per user. Nejvíc prostředků ale stejně žrala databáze.

navíc nějakou cache by měla mít i samotná aplikace

— Reply to this email directly or view it on GitHub https://github.com/ZooHackaton2015/PalmOilChecker/issues/1#issuecomment-159245292 .

[ghost]

ten memfun nemel byt priklad, jen a uz vubec ukazka jak to postavit, dnes je jina doba jine moznosti, dneska bych to take udelal jinak, ale co se rozsiritelnosti tyka tak nejaka KV databaze je pto toto idealni, proto treba to mongo, klicem udelat ean a bude to litat. Jen z hlediska bezpecnosti to chce mit vzdy nejakou vrstvu pred elasticsearch, mongem

jinak kdyz uz jsme u napadu, tak by se to klidne dalo postavit i jako static web, kde jen ta administracni cast proste vytvarela soubory obsahujici json, synchronizace pak treba pres rsync :D

[Lweek]

Tak oběd za mnou. Domluvil jsem s Heurekou, že nám poskytne virtuál. Můžeme si na něm rozjet co budeme chtít. Budeme mít SSH přístup, takže server zcela pod naší kontrolou. Jinak Marek Beniak z Heureky nás odrazuje od Monga. Prý s tím měl velké trápení. Jinak nám možná budou schopni poskytnout API pro párování EAN s názvem produktu. Je ještě na zvážení jestli to potřebujeme a chceme. Proberu to s Jakubem z Listari.

Nginx podle mne potřebujeme. Je to nástroj jak snadno škálovat a řešit problémy. Pokud bychom použili něco na API logiku, jsem pro technologii, kterou zvládne kdekdo ... Node.js nebo Python. Go lang je super, ale je tu stejný problém jako se Scalou. Umí to hrozně málo lidí. A nejde jenom o jazyk, ale jde i o to to umět provozovat a na to nestačí jen znát syntaxe jazyka.

[Ttxman]

Tohle je idealni use case pro nosql a asynchronni pristup do DB. Mysql je kvuli pripadnymu skalovani mimo (jestli na to dava eu granty tak by se to mohlo strasne rozrust), o klasickej komercnich databazich nema cenu mluvit. Takze v podstate pokud chceme SQL zbyva Postgre a nejak si nedokazu predstavit, ze by s nim bylo min problemu nez s mongem.

[Lweek]

Asi nemá moc smysl se zaseknout na tom cobykdyby. Můžeme zvolit jednu technologii a až narazíme na limit, tak to překlopit do jiné. Dneska při obědě třeba padl CouchDB.

[ondrej-smola]

Ja bych zacal tim API na apiary - az bude to tak se muzem bavit o DB.

Dne 24. listopadu 2015 13:58 Ladislav Šeps notifications@github.com napsal(a):

Tohle je idealni use case pro nosql a asynchronni pristup do DB. Mysql je kvuli pripadnymu skalovani mimo (jestli na to dava eu granty tak by se to mohlo strasne rozrust), o klasickej komercnich databazich nema cenu mluvit. Takze v podstate pokud chceme SQL zbyva Postgre a nejak si nedokazu predstavit, ze by s nim bylo min problemu nez s mongem.

— Reply to this email directly or view it on GitHub https://github.com/ZooHackaton2015/PalmOilChecker/issues/1#issuecomment-159260146 .

[ghost]

jestli si hraly s mongem na virtualu tak chapu ty problemy, my co ho provozovali na dediku tak parada

k postgre skalovat se da mam pocit, zvlaste ted uz by mel mit i master master replikaci, ale kazde databazi se ve virtualu neliby, pokud to neni virtual s fyzickym diskem, jinak je problem s io.

proto sem navrhl i to cachovani na nginxu, tam lze treba cachovat do ram disku, coz je na virtualu asi to nej, protoze ramky mivaji vetsinou dostatek. Nebo in memory databaze ktera se na disk jen sychronizuje

nadruhou stranu predelat se to da vzdy :D

projel sem si chouchDB + nginx by mohlo byt zajimave reseni

[Ttxman]

Ted ma vyjit mongo 3.2 s inmemory storagem, to by melo pomoct na virtualu.

[Lweek]

Kdo to tu nesledujete, checkněte druhé issue: https://github.com/ZooHackaton2015/PalmOilChecker/issues/2

[Lweek]

Obsolete