1246
Vývoj / Re:Replikace MySQL/MariaDb
« kdy: 20. 10. 2015, 18:14:15 »
S Couchdb jsem neměl tu čest. Znáte to z praxe? Jak se s tím pracuje? Koukám na http://docs.couchdb.org/en/latest/replication/conflicts.html
Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
1247
Vývoj / Re:Vizualizace kryptografického otisku (Hashe)
« kdy: 20. 10. 2015, 14:05:58 »
To je dobrý nápad, navíc audio výstup není problém - čtení textu počítačem funguje i offline spolehlivě, zvlášť pokud mohu omezit množinu vstupních textů.
1248
Vývoj / Re:Replikace MySQL/MariaDb
« kdy: 20. 10. 2015, 13:43:26 »
Asi někdy před půl rokem se zde řešila mobilní aplikace pro sběr dat, na kterou byly kladeny podobné požadavky. Zkuste to ve fóru najít.
Je třeba řešit řadu situací a je to dost komplikované. Hodně záleží na aplikační logice. Nedokážu si představit, že by existovalo nějaké automatické řešení. Co když dva klienti upraví stejný záznam? Anebo jeden klient záznam smaže a druhý ho ofline upravuje? Atd atd.
Nejlépe si to osobně dokážu představit jako práci s decentralizovaným verzovacím systémem. Tam se musí řešit kolize případně se dělají branche. Současně je vyřešeno, jak aplikovat inkrementálně změny na jeden a ten stejný záznam (patch). A potřebujete navíc testy, abyste se dozvěděl, zda výsledek funguje (zda jde program zkompilovat a zda se chová konzistentně vůči nějaké aplikační logice).
Přeji příjemnou zábavu :-)
Je třeba řešit řadu situací a je to dost komplikované. Hodně záleží na aplikační logice. Nedokážu si představit, že by existovalo nějaké automatické řešení. Co když dva klienti upraví stejný záznam? Anebo jeden klient záznam smaže a druhý ho ofline upravuje? Atd atd.
Nejlépe si to osobně dokážu představit jako práci s decentralizovaným verzovacím systémem. Tam se musí řešit kolize případně se dělají branche. Současně je vyřešeno, jak aplikovat inkrementálně změny na jeden a ten stejný záznam (patch). A potřebujete navíc testy, abyste se dozvěděl, zda výsledek funguje (zda jde program zkompilovat a zda se chová konzistentně vůči nějaké aplikační logice).
Přeji příjemnou zábavu :-)
1249
Vývoj / Re:Vizualizace kryptografického otisku (Hashe)
« kdy: 19. 10. 2015, 22:53:51 »
To zadání je přibližně tak, že jeden hash je na papíře a druhý na displeji a uživatel to má porovnat.
1250
Vývoj / Re:Vizualizace kryptografického otisku (Hashe)
« kdy: 19. 10. 2015, 18:00:57 »
Ale šel by použít kratší hash (navrhoval jsem SHA-3, kde si mohu sám volit délku) - za cenu pravděpodobnější kolize. Jelikož ta metoda stejně nemůže být 100% spolehlivá, nemuselo by to zas tak vadit.
Logika věci je totiž asi následující: Většina uživatelů žádné hashe nekontroluje, protože to je moc pracné. Pokud kontrolu usnadníme a uděláme zábavnější, bude ji kontrolovat více lidí a celkově to bude pro bezpečnost přínosné a to dokonce i pokud kontrola v jednotlivých případech selže (původní tazatel sice chtěl řešit nějakou aplikaci a kontrolu čárových kódů, ale princip zůstává, stačí nahradit "bezpečnost" za "naskenování správného kódu").
Ještě by šlo nahradit hash nějakou monotónní vzestupnou řadou, kde by člověk jen ověřil číslo (id toho záznamu). Musel by ale někde být centrální index všech hashů (resp. těch záznamů). Pak by to bylo podobné jako zkontrolovat číslo účtu na které posílám přes internetové bankovnictví peníze.
Logika věci je totiž asi následující: Většina uživatelů žádné hashe nekontroluje, protože to je moc pracné. Pokud kontrolu usnadníme a uděláme zábavnější, bude ji kontrolovat více lidí a celkově to bude pro bezpečnost přínosné a to dokonce i pokud kontrola v jednotlivých případech selže (původní tazatel sice chtěl řešit nějakou aplikaci a kontrolu čárových kódů, ale princip zůstává, stačí nahradit "bezpečnost" za "naskenování správného kódu").
Ještě by šlo nahradit hash nějakou monotónní vzestupnou řadou, kde by člověk jen ověřil číslo (id toho záznamu). Musel by ale někde být centrální index všech hashů (resp. těch záznamů). Pak by to bylo podobné jako zkontrolovat číslo účtu na které posílám přes internetové bankovnictví peníze.
1251
Vývoj / Re:Vizualizace kryptografického otisku (Hashe)
« kdy: 19. 10. 2015, 12:40:04 »
Ano, samozřejmě, ten můj nápad stojí nebo padá na tom, jak velké množiny se na sebe mapují. To samé ale platí i pro tu vizualizaci.
Určit velikost těch množin asi nebude triviální, protože velikost použitelných množin závisí na rozpoznatelnosti prvků množiny člověkem. To je ta komplikace v porovnání s použitím běžného člověkem obtížně čitelného textového hashe (a motivace původního tazatele je právě „zlepšit čitelnost hashe“).
Pokud potřebný objem literatury byl moc objemný, šlo by ji skutečně generovat - akorát by se zhoršila srozumitelnost („čitelnost“).
Hezké téma na menší výzkum :-)
Určit velikost těch množin asi nebude triviální, protože velikost použitelných množin závisí na rozpoznatelnosti prvků množiny člověkem. To je ta komplikace v porovnání s použitím běžného člověkem obtížně čitelného textového hashe (a motivace původního tazatele je právě „zlepšit čitelnost hashe“).
Pokud potřebný objem literatury byl moc objemný, šlo by ji skutečně generovat - akorát by se zhoršila srozumitelnost („čitelnost“).
Hezké téma na menší výzkum :-)
1252
Vývoj / Re:Vizualizace kryptografického otisku (Hashe)
« kdy: 18. 10. 2015, 22:32:48 »Abych ho mohl porovnávat, musím ho prvně přečíst. Pak ho musím udržet v paměti a pak ho musím porovnat znak za znakem s tím, který jsem tam viděl dříve. Pak musím rozhodnout, jestli je stejný.
V případě obrazu nemusím dělat tolik kroků. Možná jsem výjimka, ale dokážu prostě porovnávat dva obrazy a jejich podobnost v hlavě přímo, doslova je vidím. Stejně tak si jednodušeji zapamatuji barvy a tvar, než náhodnou alfanumerickou sekvenci znaků.
No jenže string právě znak po znaku porovnávat nemusíte. Snadno poznáte, zda jsou dva verše stejné:
Ach Romeo, Romeo! Proč jsi Romeo?
Své jméno zapři, odřekni se otce.
versus
Co je to, Montek? Ruka ne, ni noha,
ni paže, ani tvář, ni jiná část.
Takže by šlo využít právě výňatky z literatury. Není to geniální?
Jinak skutečně existují anomálie, které některým lidem umožňují vizuální operace provádět přímo v představě - bez nutnosti si cokoli vizualizovat na papíře. Ale jsou velmi vzácné, není to nic, na čem byste mohl založit aplikaci pro neznámé uživatele.
O.
1253
Vývoj / Re:Vizualizace kryptografického otisku (Hashe)
« kdy: 17. 10. 2015, 14:46:31 »
Abych nebyl špatně pochopen - jde mi o to, že písmo samo o sobě už jsou snadno rozpoznatelné obrázky, navíc je jich dost a jsou na ně lidé adaptovaní. Takže mi přijde přímočará cesta použít.
Ale ještě mě napadlo, že by bylo dobré, pokud by se hash nějak přeložil na slova, která mají význam. Těch slov je v běžném jazyce snad dost a rozhodně snáze poznám rozdíl mezi dvěma souslovíma než mezi dvěma podobnými obrázky. Jedině, že by byly ty obrázky navrstvené přes sebe...
Takže co třeba vypisovat citáty ze Shakespeara? :-)
Ale ještě mě napadlo, že by bylo dobré, pokud by se hash nějak přeložil na slova, která mají význam. Těch slov je v běžném jazyce snad dost a rozhodně snáze poznám rozdíl mezi dvěma souslovíma než mezi dvěma podobnými obrázky. Jedině, že by byly ty obrázky navrstvené přes sebe...
Takže co třeba vypisovat citáty ze Shakespeara? :-)
1254
Vývoj / Re:Vizualizace kryptografického otisku (Hashe)
« kdy: 17. 10. 2015, 13:01:50 »
V obrázkovém řešení vidím jediný smysl - WOW efekt. Jinak mi přijde lepší vypsat prostě ten hash, což jsou přeci právě obrázky poskládané vedle sebe, nic jiného. Záměnou za obrázek se nic neřeší, jen vynálézá kolo (alespoň mi to tak přijde). Pokud trváte na obrázku, stačí použít obrázkový font.
Pokud si pamatuju dobře, tak https://en.wikipedia.org/wiki/SHA-3 umí variabilní délku hashe, takže si můžete vybrat kompromis mezi rizikem kolize a délkou textu, který musí uživatel číst. A řešení je hotové. Nebo se pletu?
Pokud si pamatuju dobře, tak https://en.wikipedia.org/wiki/SHA-3 umí variabilní délku hashe, takže si můžete vybrat kompromis mezi rizikem kolize a délkou textu, který musí uživatel číst. A řešení je hotové. Nebo se pletu?
1255
Vývoj / Re:Přístup k www aplikaci, API
« kdy: 08. 10. 2015, 19:30:16 »
Dělal jsem v php API pro komunikaci s mobilní aplikaci (Android+iOS). Používal jsem ORM Propel http://www.propelorm.org, který považuju v rámci php zvyklostí za kvalitní, pro některé operace jsem psal vlastní sql (Propel to umožňuje). Requesty i response se posílaly v xml, běžné chybové stavy, na které mobilní aplikace uměla reagovat, se posílaly uvnitř xml odpovědi s http kódem 200, kód byl odlišný od 200 jen v případě fatálních chyb - těch, které vylučovaly smysluplné pokračování v akci. Pro čtení a vytváření xml jsem používal Simplexml. Xml se validovalo proti ručně psanému dtd. Databáze byla Postgres, bylo tam poměrně dost uložených procedur. Fungovalo to, ale s vrstvícími se požadavky a rozšířeními se množily různé neobratnosti, které vyplývaly hlavně z nedokonalostí simplexml a php. Modulárnost a znovupoužitelnost nic moc.
Když to hodnotím s odstupem, nevymýšlel bych dnes vlastní formát xml, použil bych hotové řešení. Knihovny pro php nejsou žádný zázrak. Osobně bych to psal v javě a pro samotnou komunikaci použil nějakou knihovnu pro messaging nebo RPC - takovou, které funguje na Androidu i na serveru. Pokud by uměla víc jazuků, vzal bych to, protože nikdy nevíš, kde všude se bude služba dál používat. Pokud bych na serveru potřeboval ORM, použil bych http://javalite.io/activejdbc a pokud bych potřeboval i web připojil bych http://javalite.io/activeweb Nezahrnuje to ale administrační rozhraní. Pokud bych ho potřeboval, použil bych http://www.brightspot.com/ tam se podle datového modelu automaticky generuje administrační rozhraní, pro persistenci je použita sql databáze - ale jen jako storage, nepracuje se tam běžným sql stylem. S Brightspot bych nicméně udělal nejdřív nějakou pilotní verzi, kód toho frameworku otevřeli teprve nedávno a podpora a komunikace autorů je asi tak nějak „jak zbyde čas“. Na druhou stranu to ušetří spoustu času právě s tím administračním rozhraním a framework je evidentně používaný už delší dobu a to i na větších projektech.
Nicméně, jestli to API má mít jen dvě metody iniciované z klienta a jestli nebudou přibývat další metody, tak stačí poslat dva http požadavky a není třeba vstřebávat nějaké frameworky nebo budovat nějaké velké API. Takže záleží hlavně na požadavcích a komplexnosti - kolik metod, push nebo pull? data budou binární nebo textová? bude to synchroní nebo asynchroní? kolik klientů to má zvládnout, bude nějaký load balancing? atd...
Tož nevím jetli jsem pomohl :-)
Když to hodnotím s odstupem, nevymýšlel bych dnes vlastní formát xml, použil bych hotové řešení. Knihovny pro php nejsou žádný zázrak. Osobně bych to psal v javě a pro samotnou komunikaci použil nějakou knihovnu pro messaging nebo RPC - takovou, které funguje na Androidu i na serveru. Pokud by uměla víc jazuků, vzal bych to, protože nikdy nevíš, kde všude se bude služba dál používat. Pokud bych na serveru potřeboval ORM, použil bych http://javalite.io/activejdbc a pokud bych potřeboval i web připojil bych http://javalite.io/activeweb Nezahrnuje to ale administrační rozhraní. Pokud bych ho potřeboval, použil bych http://www.brightspot.com/ tam se podle datového modelu automaticky generuje administrační rozhraní, pro persistenci je použita sql databáze - ale jen jako storage, nepracuje se tam běžným sql stylem. S Brightspot bych nicméně udělal nejdřív nějakou pilotní verzi, kód toho frameworku otevřeli teprve nedávno a podpora a komunikace autorů je asi tak nějak „jak zbyde čas“. Na druhou stranu to ušetří spoustu času právě s tím administračním rozhraním a framework je evidentně používaný už delší dobu a to i na větších projektech.
Nicméně, jestli to API má mít jen dvě metody iniciované z klienta a jestli nebudou přibývat další metody, tak stačí poslat dva http požadavky a není třeba vstřebávat nějaké frameworky nebo budovat nějaké velké API. Takže záleží hlavně na požadavcích a komplexnosti - kolik metod, push nebo pull? data budou binární nebo textová? bude to synchroní nebo asynchroní? kolik klientů to má zvládnout, bude nějaký load balancing? atd...
Tož nevím jetli jsem pomohl :-)
1256
Vývoj / Re:Java Applet a zjištění MAC
« kdy: 07. 10. 2015, 00:40:26 »
Přehlédl jsem se a četl: muzu applet spustit na prikazove radce?
No nic, stane se :-)
No nic, stane se :-)
1257
Vývoj / Re:Java Applet
« kdy: 05. 10. 2015, 21:10:54 »
Applet viewer už nejde použít? To by bylo přesně to, co tazatel požaduje, ne?
1258
Server / Re:Myslíte, že Apache2 se přestane nasazovat a nahradí ho plně nginX?
« kdy: 03. 10. 2015, 18:56:49 »pokud někdo ovládá Apache, proč by nemohl ovládat NGINX?Já spíš nechápu, co na tom chcete "ovládat". Jo, když někdo napíše, že "ovládá PostgreSQL" a nic jinýho se mu nechce učit, tak to chápu - je tam spousta nejrůznějšího know how, postřehy z praxe, tuning ... blabla, ale co by měl člověk "ovládat" na webserveru? Vždyť tam žádná raketová věda není. Nebo aspoň jsem o ní zatím ještě nezavadil, v kterémžto případě by mě to docela zajímalo, co "pokročilého" může člověk umět - aby to nebyl jeden až pět řádků v konfiguráku nginxe.
No já bych ten objem znalostí zas tak nepodceňoval. Je toho docela dost, co by měl administrátor znát a nezjistí to za pár dní, ale právě až zkušeností. Namátkou:
- přehled o modulech
- znalost zabezpečení, povědomi o bezpečnostních slabinách
- speciality při běhu ve virtualizovaném prostředí
- zkušenosti s laděním výkonu, schopnost interpretovat statistiky, monitorování
- rozdíly mezi verzemi, balíčkování, kompilace
- povědomí o tom, kde hledat informace a kam se obrátit - což zahrnuje třeba i zkušenost s tím, jak reagují vývojáři toho software a jak a kde se hlásí chyby
1259
Desktop / Re:rozponani typu souboru - přípony, MIME
« kdy: 18. 09. 2015, 14:14:15 »
PS: KDE nepoužívám, mám MATE desktop.
1260
Desktop / Re:rozponani typu souboru - přípony, MIME
« kdy: 18. 09. 2015, 14:13:15 »
Záleží, jak definujete ""rozpoznání souboru"? To, v čem se otevře po dvojkliku? Mime typ, které je vidět v informacích o souboru v manažeru souhorů? Jinak?
Je potřeba rozlišit rozpoznání mime-typu a přidělení aplikaci k mime typu, což jsou dva různé procesy. Rozpoznání mime typu se děje podle souborů mime.types a magic souborů, přičemž jich může být v systému víc (a každý program může používat jiný, což působí zmatek). Přidělení aplikace k mime řeší obvykle desktopové prostředí, nejčastěji správce souborů daného desktopového prostředí. Standardizovat se to na desktopu snaží freedesktop standards (alespoň myslím). Výsledek ale není podle mých zkušeností ideální. Mám tušení, že se nastavení ukládá do .desktop souborů, což je kapitola sama pro sebe.
Tolik globálně pro představu - snad bude někdo fundovanější a poradí konkrétněji.
Je potřeba rozlišit rozpoznání mime-typu a přidělení aplikaci k mime typu, což jsou dva různé procesy. Rozpoznání mime typu se děje podle souborů mime.types a magic souborů, přičemž jich může být v systému víc (a každý program může používat jiný, což působí zmatek). Přidělení aplikace k mime řeší obvykle desktopové prostředí, nejčastěji správce souborů daného desktopového prostředí. Standardizovat se to na desktopu snaží freedesktop standards (alespoň myslím). Výsledek ale není podle mých zkušeností ideální. Mám tušení, že se nastavení ukládá do .desktop souborů, což je kapitola sama pro sebe.
Tolik globálně pro představu - snad bude někdo fundovanější a poradí konkrétněji.
