Příspěvky

751

Studium a uplatnění / Re:Holoarchie pri projektovem rizeni

« kdy: 03. 11. 2018, 16:26:55 »

Mám s tím určité malé zkušenosti. Problémy jsou krom už zmíněné těžkopádnosti ještě dva:

1) Malá konzistence rozhodnutí. Jeden člověk má typicky nějakou ideu, podle které se řídí. Kolegium většinou ne.

2) Neexistující osobní zodpovědnost za rozhodnutí. Typicky někdo dá nějaký návrh. Já říkám "To je blbost, protože X" . Na moje varování se nedá a X nastane. Pokud to rozhodl člověk, tak mu ten problém hodím na hrb, ať si to vyřeší, když na mě nedal. U kolektivního rozhodnutí to ale není komu hodit na hrb.

To považujete za problémy kterého druhu rozhodování? U společného rozhodování je naopak dokonalá konzistence rozhodnutí (zejména u varianty jednomyslné shody - jedná se tak dlouho, dokud se  všichni za rozhodnutí nemohou postavit) a vysoká osobní zodpovědnost (kdo dokáže být zodpovědný sám za sebe, je stejnou měrou zodpovědný i za společné rozhodnutí, není zde dvojí metr, kde by se mohl někdo na někoho vymlouvat nebo kdy by mohl vystupovat různě např. na základě toho, s kým mluví). Tedy společná idea je nakonec skutečně sdílená všemi lidmi a není jen v hlavě jednoho člověka. Z toho vyplývá ještě jeden benefit - a tím je obtížná manipulovatelnost. Pro přijetí rozhodnutí musí být shoda všech, takže nelze někoho např. podplatit.

Nevýhodou je skutečně hlavně náročnost (všichni lidé musí tímto způsobem chtít a umět pracovat, což klade vyšší nároky na výběr kolegů a dále náročnost na čas - rozhodování zabere to dost času). A samozřejmě, může dojít i k nějaké nepovedené karikatuře společného rozhodování, kdy lidé odkývnou něco, s čím ve skutečnosti nesouhlasí, nebo kdy se nějakou formou manipulace omezuje svoboda jednotlivých členů. To pak ale není společné rozhodování, ale nepovedený pokus o něj.

Takže má tato metoda unikátní vlastnosti a do určitého počtu lidí může dobře fungovat. Mluvím o společném rozhodování. Nejsem si ale jist, zda se holoarchií míní právě toto. Každopádně u i společného rozhodování si lidé (společně) stanovují kompetence a jejich míru (takže rozhodně nedělají všichni všechno). Ale těm kompetencím předchází právě to společné rozhodnutí a v případě potřeby se kompetence upravují tak, aby ze sebe mohl každý dát to nejlepší (což se často kryje s tím, že to lidi baví a cítí se lidsky docenění, což zvyšuje prestiž, osobní interesi a frustrační odolnost).

752

Studium a uplatnění / Re:Holoarchie pri projektovem rizeni

« kdy: 03. 11. 2018, 01:37:07 »

Zažil jsem situace, kde to dávalo smysl. Nebylo to v technickém oboru. Zasedalo se v kruhu a rozhodnutí se přijímalo buď po dosažení úplné shody (jednohlasně) anebo procentuálně (většinová podpora daného rozhodnutí). Pak se podle rozhodnutí pracovalo, každý dle svých kompetencí. Neexistoval žádný nadřazený vedoucí, lidé vládli sami sobě. Počet kolem 20ti lidí. Za rozhodnutím si pak všichni museli logicky stát, takže tam byl velký apel na osobní zodpovědnost. Nevýhodou především časová náročnost rozhodování a vysoké požadavky na charakter zúčastněných. Přijímali se jen lidé, kteří tímto způsobem chtěli pracovat.

Pokud se rozhodovalo o odborné otázce, kterou vědomostně obsáhl jen určitý pracovník, bylo jeho úkolem téma dostatečně srozumitelně představit ostatním, aby se byli schopni vyjádřit.

Existuje více různě propracovaných systémů tohoto typu, dalším je třeba sociokracie a další.

753

Software / Re:Keepass, kde je záruka, že má hesla nebudou zneužita?

« kdy: 02. 11. 2018, 16:25:50 »

Otázku jsi položil: "Jaký mi autor software může dát záruky" ... "co vás přesvědčí..."
Pokud to nechceš rok studovat, pak buď věř, nebo jednoduše nepoužívej. Přijde mi to jako další trollící dotaz.

Může ale existovat nějaká potenciálně důvěryhodná autorita, která provede audit a ten pak může sloužit uživatelům, kteří nechtějí nebo neumí číst zdrojáky. Je to stále kompromis, ale lepší než nic. Pak není dotaz trollení ale hledání, podle jaké autority se orientovat.

754

Sítě / Re:Divné chování Synology NAS

« kdy: 29. 10. 2018, 20:44:36 »

IMHO vrátit zařízení je docela nesmyslná reakce. Zařízení je kvalitní a linux se tradičně snaží využít veškerou paměť - pokud ji nevyužívají programy, používá ji pro cache, buffery apod. Takže nejdříve je potřeba porozumět tomu výpisu free a pak teprve soudit. Nevím, zda zařízení uživatele špehuje nebo ne, ale podle výpisu paměti to nepoznáte 

755

Hardware / Re:Cpubenchmark.net - jak se orientovat?

« kdy: 26. 10. 2018, 21:45:42 »

Já nejvíc používám tuhle podstránku a tam si dám vyhledat daný cpu https://www.cpubenchmark.net/CPU_mega_page.html

Podle mě ta známka už zahrnuje zahřívání, tj. ta známka odpovídá reálně dosažitelnému výkonu. Tak nějak to koresponduje i s mým pozorováním.

756

Hardware / Re:HW a CPU pro webserver

« kdy: 25. 10. 2018, 22:33:46 »

Načítání stránek je ok, i ty cronjoby, že jdou delší dobu nevadí, ale jde o to, že chci ten elastic search, chci užívat na serveru program na lepší práci s kompresi fotek, to mi hosting nedá samozřejmě. VPS co jsem zkoušel, tam jsem vždy narazil na to, že výkon není stále stejný. Ano, dedikač by se většinu dne kopal do zadku, ale pokud by lepší výkon, lepší hledani... Kdyby každý den toto přineslo zisk 1 000 Kč navíc, pak je nějaký rozumný stroj i housing brzy zaplacen. Když by se udělalo rozumné zálohování, tak v případě havárie serveru by se nechalo i celkem rychle (za pár hodin) případně sehnat jiný, podobný stroj a jet na něm. Sice jsem moc mrtvých hw na servery neviděl, ale stát se může vše.

Vyzkoušej https://cloudimage.io/ a máš po problémech se zpracováním fotek. Utáhne ti to pak i obyčejný webhosting.

Ale na fotkách to podle všeho nestojí. Nemůžou to blokovat právě ty cronjoby (izolace transakcí, zámky...)? Já bych nasimuloval zátěž (jmeter nebo něco podobného) a zaměřil se na analýzu úzkého hrdla. Zkoumal bych, kolik server unese s cronjobama a bez nich. Samozřejmě někde v testovacím prostředí, ne v produkci.

Dedikovaný server si můžete pronajmout i na zkoušku, a taky není VPS jako VPS.

757

Hardware / Re:GSM brána přes USB (Linux) pro SMS

« kdy: 10. 10. 2018, 21:35:52 »

Dobrý den, nemáte tip na GSM bránu pro Linux (Debian pro zasílání SMS ze serveru (z příkazové řádky) přes rozhraní USB? Důležitá je podpora Debianu 8, potažmo 9. Děkuji za jakékoliv tipy, Pavko.

https://en.wikipedia.org/wiki/Huawei_E220

Ale chtělo by info o tom, jak je to stabilní při dlouhodobém připojení. Pokud to je k serveru a bude to hlásit výpadky, mělo by to být super spolehlivé.

758

Software / Re:Monitoring sítě

« kdy: 09. 10. 2018, 13:48:34 »

Ano, úvaha správná, ale budete se muset naučit, jak fungují sítě atd. Pak teprve budete vědět, co se po Vás vlastně chce (= budete vědět, co nabízíte a čeho lze docílit). Tím pc routerem budete monitorovat - v závislosti na adresaci sítě a nastavení jen část provozu, tj. pravděpodobně jen provoz do a z internetu. Provoz uvnitř sítě nemusíte ani zachytit. Což může vadit, protože pokud je někde zahlcená linka, nemusí to vůbec tím, že něco „tahá z internetu“. Jak už bylo řečeno, správně se síť rozdělí na několik segmentů (klientské počítače zvlášť, síť pro hosty zvlášť, výrobní zařízení zvlášť atd.) a ty segmenty se pak sledují jako celek, lze je pokusně odstavit atd.

Pokud Vám to nebude fungovat, nebudou Vás mít rádi. Takže jestli se to opravdu chcete naučit, udělejte si někde bokem testovací provoz a tam vše důkladně otestujte a nechte i zkontrolovat někým zkušenějším. Počítejte s tím, že ten sebevzdělávací čas Vám asi neproplatí, resp. můžete porovnat s komerční nabídkou u konkurence. Pokud na síti záleží provoz v té výrobě, byl bych velmi opatrný, abych to nerozes***. Chyby dělají i profesionálové (jsou smluvně ošetřené, pojištěné...), začátečník jich naseká zákonitě ještě víc.

Dokážu si ještě představit, že pokud je problém jen v tom, že je „pomalý internet“, že tam dáte před router switch a v promiskuitním módu budete provádět na malém servříku monitoring, jak píše AoK výše. Je to totiž neinvazivní metoda - pokud server vypnete, vše poběží dál. Ale může se stát, že na nic nepřijdete, protože je problém v tom, že je síť zahlcená nějakým zblázněným zařízením běžícím na UDP protokolu a jelikož je třeba vše bridgované tak vám ty UDP pakty lítají kdoví kde a třeba k servříku ani nedorazí anebo se vám třeba ruší wifiny a je problém v tom.

PS: Začal bych tak jako tak zdokumentováním celé sítě. To je něco co udělat můžete a co má tak jako tak hodnotu. Zařízení, adresace, co tam běží, k čemu to je.

759

Vývoj / Re:Co vám vadí na JavaScriptu v roce 2018?

« kdy: 25. 09. 2018, 16:33:12 »

Uplne nejvic nejzakladnejsi priklad, co mne napada, je treba ze proti hadani hesel se dela (mimo jine) ze po zadani credentialu se 1s pocka. Obvykly sleep ma ten problem, ze na tu sekundu zablokuje thread/proces. V JS se tohle dela snadno.

Anebo, pisu neco jako WWW proxy a sluzba vraci neco, co si pred tim vyzada realtime nekde jinde. Kdyz je "to nekde jinde" pomale, zase to blokne cely thread/proces.

Ne ze by se neco takoveho nedalo naspat v pythonu, ale JS je z podstaty async a i vsechny knihovny jsou taky async. Takze, kdyz treba pisete neco, co ceka na AWS SQS, je to v JS SDK rovnou async. Kdyz to budete delat v pythonu/ruby/java, tak to mate blby a musite delat thready/procesy.  V JS si efektivne klidne stacite s 1 procesem/threadem.

Vznika nove paradigma, misto toho, aby funkce vracela navratovou hodnotu, vola callback. Ne kazdy se s tim dokaze poprat a ano, nekdy je to opravdu nesikovne...

To ale není žádná výsada Javascriptu a naopak to mají jiné jazyky často vyřešeno lépe. Javascript je jen místo, kde na to začínající (nebo sváteční) programátoři nejdřív narazí.

760

Vývoj / Re:websocket vs. rest

« kdy: 24. 09. 2018, 20:51:23 »

V rámci vzdělávání bych doporučil udělat tu chatovací mini aplikaci v obou variantách - RESTem i Websocketem. Pro pochopení je nejlepší si to ze začátku víc nakódovat sám a teprve pak používat frameworky. Jinak hrozí, že nebudete vůbec tušit, jak framework funguje, což se časem nezřídka vymstí. Začal bych něčím hodně přímočarým, na server něco jako sparkjava a na klienta jquery. Pak bych šel o level výš a použil už nějaké zastřešující řešení. React,

Pokud budete mít vytvořený websocket, můžete přes něj tlačit vše, udělat si nějaký message bus a ten pak na serveru i klientovi obsluhovat. Ale pozor na to, že websocket spojení může zaniknout a že pak budete muset řešit přeposlání nebo stornování zpráv při výpadku.

761

Vývoj / Re:Mají tabulkové databáze v dnešní době smysl?

« kdy: 20. 09. 2018, 22:31:02 »

OOP je na to vhodné, ale data je lepší nemít v objektech, ale v kolekcích. Tím se vyhneme zastaralému AD a místo něj s elegancí přejdeme na modrerní DM.

Active record je pouze prostředkem uvnitř ORM, samotné ORM jej nevyžaduje. Mimoto objektový model nijak neovlivňuje.

Co s tím má společného ORM?

Co má s OOP společného mít data v kolekcích a ne v objektech (sic!) a ActiveRecord či DataMapper? Zřejmě jen jel volnou asociaci, stejně jako ty.

Když je to DataMapper, tak přece nemapuji objekty, ale data.

ActiveRecord vs. Data Mapper se liší v tom, kde je zapouzdřená kompetence za persistenci - zda spolu s daty (v objektu reprezentujícím data z business domény) anebo bokem (v data mapperu). Některá ORM umožňují použít oba přístupy (vybrat si, kterému dám přednost). Viz.:

Data mapper Podle tohoto vzoru neobsahuje doménový objekt žádné CRUD nebo vyhledávací operace a o vytváření, úpravu a mazání doménových objektů z databáze se stará oddělený (mapovací) objekt. Doménový objekt je tedy zcela nezávislý na databázi. Zatímco mapovací objekt má přístup jak k doménovému objektu, tak k databázovému systému. Výhodou tohoto vzoru je právě nezávislost doménového objektu na datovém modelu, kdy je veškerá zodpovědnost za persistenci přesunuta na mapovací objekt.

https://cs.wikipedia.org/wiki/Data_Mapper

Ve výsledku mi Tvůj příspěvek nedává moc smysl (netuším, jak jsi to myslel).

762

Vývoj / Re:Mají tabulkové databáze v dnešní době smysl?

« kdy: 19. 09. 2018, 23:11:39 »

Já se obávám, že zde mnoho přítomných stále nepochopilo, že mít objektový model a relační DB bez ORM jaksi z podstaty nejde - někak se ty relace musejí měnit na objekty a naopak, a to bez ohledu na realizaci. Ano, nemusíte používat knihovní ORM, pak si překlady musíte udělat sami, ale to je právě to ORM. A nebo se na ORM vyserete a povedete model v aplikaci v n-ticích či samostatných hodnotách, to ale nemá s OOP nic společného.

Jestli to nebude tim, ze proste na modelovani globalne konzistentnich dat (= splnujicich globalne nejakou podminku) neni OOP prilis vhodne.

OOP je na to vhodné, ale data je lepší nemít v objektech, ale v kolekcích. Tím se vyhneme zastaralému AD a místo něj s elegancí přejdeme na modrerní DM.

Tuším nějakou Kitovinu :-) Ale můžeš to trochu rozvést? A nevím co je DM, AD.

763

Vývoj / Re:Mají tabulkové databáze v dnešní době smysl?

« kdy: 16. 09. 2018, 00:20:12 »

Dovedl bych si představit mixovanou DB, kde si budu moct zvolit, zda do "tabulky" budu ukládat klasické řádky nebo objekty definované nějak složitěji jako strom (interně ať si to uloží jak chce).
A dotaz by buď vracel klasický plochý result (tabulku), nebo seznam objektů (nebo spíš jejich properties) filtrovaný přes klasický SQL dotaz podle jejich properties.   

https://en.wikipedia.org/wiki/Multi-model_database
https://en.wikipedia.org/wiki/Comparison_of_multi-model_databases

764

Vývoj / Re:Mají tabulkové databáze v dnešní době smysl?

« kdy: 13. 09. 2018, 16:00:33 »

Akorát se tu trochu zapomíná na to, že reálná ORM umožňují psát SQL nebo mají API, které SQL věrně kopíruje. Pak si může člověk vybrat a pořád má výhodu mapování na objekty. Otázka je, kolik práce si tím ve výsledku ušetří a kolik přidělá, což se ale bude lišit projekt od projektu.

Já myslel, že se tady bavíme o ORM jako o programovací technice, ne o tom, že v reálu si ORM frameworky jen s ORM přístupem nevystačí a musí k tomu přilepit funkčnost, která už nemá s ORM prakticky nic společného a která zcela zásadně narušuje tu úroveň abstrakce, na které pracuje ORM.

OK, jako čistý koncept je ORM dost omezené. Ale v praxi to lze docela snadno řešit, takže to moc nevadí.

765

Vývoj / Re:Mají tabulkové databáze v dnešní době smysl?

« kdy: 13. 09. 2018, 11:31:42 »

Akorát se tu trochu zapomíná na to, že reálná ORM umožňují psát SQL nebo mají API, které SQL věrně kopíruje. Pak si může člověk vybrat a pořád má výhodu mapování na objekty. Otázka je, kolik práce si tím ve výsledku ušetří a kolik přidělá, což se ale bude lišit projekt od projektu.

Mě se docela líbí taková ta úplně lehká ORM jako třeba http://javalite.io/activejdbc#design-principles, akorát mě tam štve ten zápis sloupců jako string (dá se řešit tím, že si člověk napíše gettery a settery ručně).

Proč se víc nerozšířili objektové databáze, to netuším. Asi že chybí ta standardizace...?