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.


Příspěvky - Ondrej Nemecek

Stran: 1 ... 23 24 [25] 26 27 ... 90
361
Software / Re:Software pro vyplnění PDF formuláře z XML
« kdy: 30. 09. 2020, 16:04:42 »
Akorát že je řeč je o vyplňování pdf formuláře údaji z xml.

Ruční vyplnění pdf formuláře vytvořeného ve Scribus mi funguje třeba v Xreader (z Xapps).

Ale je potřeba vždy vyzkoušet ten konkrétní formulář...

362
Server / Re:Zabezpečení databáze
« kdy: 29. 09. 2020, 00:40:31 »
Asi se shodneme , že záleží co je to ten tajemný "lékařský software". To může být totiž prakticky cokoliv, od malého prográmku který běží iozovaně na pc v ordinaci až po raketetoplán běžící na centrále, který má už objednávání přes web vyřešeno.

363
Server / Re:Zabezpečení databáze
« kdy: 27. 09. 2020, 14:51:11 »
Do databáze bude přistupovat jen aplikační server, který vystaví API – a to API bude používat jak lékařský software, tak web.

Jenže tady musíte vysvětlit, co je aplikační server, kde běží a jak vznikne ta bezpečnost.

Nejspíš myslíte, že lékařský software bude sám skrz API nahrávat údaje na aplikační server (takže aplikační server nebude znát žádné přístupové údaje do lékařského software, naopak se bude muset samotný lékařský software autorizovat při přístupu do toho API). Bezpečnost vznikne tím, že když někdo získá plný přístup k aplikačnímu serveru, nezíská tím data lékařského software.

Zde opravdu není dobrý nápad přistupovat do živé databáze, kterou současně používá lékařský software. Jsou tam obvykle různé cache, takže se snadno dostanete do stavu, že by externí systém viděl neaktuální nebo nekonzistentní data a kdyby náhodou ten externí systém začal do té živé databáze zapisovat, mohl by lékařský software spadnout a data by se mohla rozbít. Aby šla takto databáze použít, muselo by to na to být navržené.

Nejrozumnější je kontaktovat výrobce lékařského software s dotazem, jaké nabízejí možnosti pro integraci s externími systémy. Pokud to mají dobře navržené, tak Vás odpověď i navede na správné řešení. Teprve pokud na tuto variantu nebudou připraveni, lze řešit integraci vlastní cestou. Třeba dávkovým přenosem v read-only režimu načíst údaje z lékařského software (v době kdy neběží) a tímto exportem aktualizovat data na webu. Na to byste musel vyvinou nějaký nástroj. Ať ale neběží na serveru, ale spouští se na počítači v ordinaci. Tím docílíte cca toho stavu, co psal pan Jirsák výše. Je otázka, co se s tím objednáním pacienta pak stane. Pokud se to má přenášet zpět do lékařského software, tak se nejspíš nevyhnete tomu aplikačnímu serveru a v lékařském software pro to musí být nějaká podpora. Do databáze to přímo nezapisujte, pokud to dodavatel lékařského software přímo nepodporuje - koledoval byste si o malér.

Z hlediska osobních údajů by bylo nejlepší do databáze na serveru zapisovat opravdu jen např. (osolené) hashe mailu. Když by se k údajům ze server někdo dostal, dozví se pouze kolik je kdy objednaných pacientů ale nedokáže je ztotožnit s osobami. Teoreticky - pokud se např. někdo dostane i k logům serveru a v nich budou ty maily uvedeny (může se stát), tak ke ztotožnit může dojít celkem snadno.

364
Server / Re:Zabezpečení databáze
« kdy: 26. 09. 2020, 22:52:01 »
"K databázi se bude přistupovat jak z klientských aplikací"

Vyloučeno
Databáze nemá být vůbec vidět z venku. Vůbec nevíte, jaké exploity databáze obsahuje a při problému ani nedohledáte, co se stalo.

Já jen že pokud je ten mezikus napsaný blbě nebo blbě nasazaný, pak tu bezpečnost může klidně snížit. Pokud v něm máte chybu a spoléháte na něj, máte de fakto o průnik postaráno. Je to jen můj názor...

Je jasný, že je to složité a neznáme situaci tazatele, ani reálné požadavky na bezpečnost. Podle dotazu to bude něco spíchnuté na koleně, kde potřeba řešit nejspíš ty nejzákladnější základy jako třeba netriviální hesla, aby data nelítala v plaintextu. V téhle situaci je IMHO nesmysl řešit vícevrstvou aplikaci, to je sci-fi.

Ohledně přímého přístupu do databáze z aplikace zase záleží na situaci. To je jako říct že nemám spouštět http server protože obsahuje exploity.

365
Hodně hustej je https://www.texmacs.org/

366
Server / Re:Zabezpečení databáze
« kdy: 25. 09. 2020, 22:21:19 »
K věci: Od klienta k serveru musí být vše šifrované (např. https) a uživatel musí být ověřovaný dvoufaktorově. Nastavit rozumný timeout session. Nasadit nějaké penetrační testování proti běžným chybám jako sql injection apod. Dvoufaktor použít i pro přihlášení do databáze, pokud to databáze umí a připojuje se do ní přímo z pc uživatelů (tím tedy nemyslím webovou aplikaci). Důležité operace opět vázat na ověření. Tím se dostanete na úroveň zabezpečení internet bankingu a víc nebudete myslím potřebovat. Samozřejmě zabezpečit i server proti průniku zvenčí (to však není předmětem dotazu). Pokud na tom záleží, nechat si vše zkontrolovat nezávislou stranou (bezpečnostní audit) a zhodnotit, jaká škody by vznikly v různých scénářích. A na nějaké vlastní šifrování a dešifrování v aplikaci rovnou zapomeňte, to řeší šifrované kanály za vás.

Bokem: Další vrstva navíc v principu nic neřeší, potřebujete kontrolovat rizika a kvalitu, nikoli kvantitu.

PS: Jo a aby si data uživatelé nevykradli vzájemně, tak na to nasadit samozřejmě to row level security (nemám ale zkušenost).

367
Vývoj / Re:Kalkulace vývoje software
« kdy: 18. 09. 2020, 14:44:15 »
Drobením taky dostávám nejrealističtější čísla, často víc než jsem od boku odhadoval. Ale je to dost pracné...

368
Server / Re:Porovnanie SQL databaz
« kdy: 18. 09. 2020, 14:39:12 »
Chcete porovnat data nebo strukturu? Strukturu a základní data je nejlepší verzovat již v projektu pomocí db-migračního nástroje (Flyway, ...), pak vidíte rovnou v databází jakou verzi struktury databáze má a potřebné změny jsou aplikovány automaticky pomocí sady změnových souborů. Funguje to bezproblémově.

Někteří sql klienti mají i nástroje na porovnání,  např. Dbeaver má Schema compare a Data compare (jde tuším o  placené pluginy). SQuirell má dbdiff a dbcopy. Podobné funkce mohou mít i různé data-pump nástroje.  Osobně ale většinou dumpuji samotnou strukturu a použiju textový diff, to mi většinou stačí.

369
Server / Re:Vacuum databáze nevrací volné místo
« kdy: 18. 09. 2020, 14:27:15 »
Jojo, zkuste VACUUM FULL. Ještě mohou hrát roli indexy - pokud je jich hodně a jsou netriviální, mohou zabírat dost místa.

370
Vývoj / Re:Kalkulace vývoje software
« kdy: 17. 09. 2020, 23:58:07 »
pocitat cenu podle poctu radku kodu? to je echt novatorstvi.

Spíš by to mělo být opačně, z analýzy by mělo vypadnout, kolik toho kódu bude potřeba.

Ale poměr funkčnosti vs. počet řádků vychází různě podle jazyka a použitých nástrojů.

Některé jazyky jsou tak expresivní, až se blbě čtou (Scala...)  ;D

371
Vývoj / Re:Kalkulace vývoje software
« kdy: 17. 09. 2020, 18:14:29 »
PS: Začal bych tím násobením odhadů a vyhotovením odhadu od jiných firem. Pak můžete vzít rozum do hrsti a navrhnout třeba nějakou metodiku ke změně firemních zvyklostí při kalkulaci a schvalování projektů.

372
Vývoj / Re:Kalkulace vývoje software
« kdy: 17. 09. 2020, 18:09:41 »
Nejlepší je zjistit, kolikanásobně jste původní odhad překročil v minulých případech a v vynásobit příslušnou konstantou v aktuálním odhadu.

Negativní dopady špatného odhadu či špatné analýzy se dají minimalizovat rozdrobením na malé podčásti - pokud něčemu věnujete tři dny místo původně odhadovaného dne jednoho, tak se tolik nestane. Pokud něčemu věnujete tři měsíce místo odhadovaného měsíce jednoho, je to problém. Rozdrobení funguje nejlépe pokud je možno rychle prototypovat. Na prototypu se dá názorně ukázat, co je jak pracné. Dá se včas zatáhnout ruční brzda, pokud projekt neúměrně bobtná.

Doporučuju také nechat si udělat odhad u jiné externí firmy. Pravděpodobně si napočítají veškeré potřebné rezervy což zlepší Vaši informovanost a vyjednávací pozici při obhajování projektu. Pokud externí firma nacení vývoj na půl milionu a vy jej nabízíte za 300 tisíc, může to být výhra/výhra pro Vás i pro vaši firmu. Vy máte výhodu, že znáte prostředí a interní procesy ve firmě, takže vývoj můžete nabídnout za menší náklady jelikož ušetříte na analýze. Firma vidí, že jste nejlevnější způsob, jak software vyvinout. Výhra-výhra.

Nakonec záleží, jaké máte vy nebo firma rezervy, kterými je možné vykrýt například potřebné sebevzdělání či vybavení nutné pro vývoj. Pokud nemáte dostatečné zkušenosti a vybavení, může vyjít poměr opačně - zkušený externista může software vyvinou za násobně menší čas než vy, pokud se musíte většinu věcí učit, nakoupit licence apod. To se firmě může vyplatit pouze tehdy, pokud se investice do Vašeho vzdělání vrátí tj. pokud v dané specialilzaci dokážete další projekt realizovat úsporněji. Zde hrají roli i osobní schopnosti a dále vztahy ve firmě. Znovupoužitelnost kapitálu (zkušení lidé) se v daném časovém úseku zvyšuje se specializací - pokud by byl každý projekt jiného charakteru, může být problém použít předchozí zkušenosti. Proto jsou vysoce cenění lidé s širokým záběrem, ovšem k tomu záběru potřebovali znační čas (investici), aby jej získali. Čili mluvíme o volbou mezi specializací a rozhledem přičemž každá varianta přináší jiné potřeby.

A nezapomeňte, že nemusíte dělat vše sám, můžete si nadiktovat, co budete potřebovat od kolegů. Tím se může i vhodně delegovat zodpovědnost a rozdělit rizika. Pokud vás v tom bude víc, nebudete z toho míst takové nervy. Příliš velký tým je ale náročný na synchronizaci, leckdy dobře funguje dvojice či trojice lidí, ale to záleží také na charakteru firmy... Mimochodem dobré vedení by Vám mělo dát veškerou podporu pro kvalitní odhady, takže místo toho, aby se vozilo po nedodržených termínech, by mělo zvládnou Vás managovat tak, aby k problémům nedocházelo - úměrně k vašim zkušenostem (u nezkušeného pracovníka musí vedení předjímat automaticky chyby a minimalizovat jejich rizika pro firmu i zaměstnance). Pokud byste ovšem byl seniorní pracovník, mělo by toto být právě Vaším úkolem.

374
psaní knih != sázení knih
Při psaní knih nepotřebujete vrstvy, které tazatel poptává.

Já bych za tazatele nemluvil. Vrstvy jsou obecný koncept.

375
psaní knih != sázení knih

Stran: 1 ... 23 24 [25] 26 27 ... 90