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 - Filip Jirsák

Stran: 1 ... 238 239 [240] 241 242 ... 266
3586
Vývoj / Re:MySQL databáze nad 500 MB
« kdy: 13. 06. 2014, 09:43:27 »
500 MB je miniaturní databáze, v tom problém určitě nebude. Problém může být ve špatné struktuře dat (např. chybějící indexy), nebo ve špatných dotazech (nevyužívají se indexy, z databáze se tahá víc dat, než je potřeba…).

SQL databáze sice nejsou určené pro ukládání souborů, ale použít se k tomu dají. U takhle miniaturní databáze s tím nejspíš nebude žádný problém. Výhoda uložení v databázi je, že máte zaručenou referenční integritu (pokud tak databázi navrhnete, samozřejmě). Např. při obnově ze zálohy nemusíte nic řešit, prostě obnovíte data do nové databáze a můžete pokračovat. Nevýhodou je také zálohování – nejspíš budete dělat dump celé databáze, takže i neměnící se data budete mít v každé záloze znova. Při použití souborů byste nejspíš zálohoval jen rozdíly. Použití databáze může mít ještě jednu nevýhodu u zatíženého webu – data se budou v paměti několikrát kopírovat, při použití souborů je možné data odeslat rovnou z diskové mezipaměti bez kopírování.

Každopádně je neefektivní binární data do databáze ukládat v base64, zbytečně se tím zvětší objem dat o třetinu. Navíc při použití to zase musíte dekódovat, takže ta data budete mít nejspíš v jednu chvíli v paměti dvakrát. Pro ukládání velkých binárních dat do SQL databází slouží datový typ BLOB – Binary Large OBject.

3587
Nabízím zakázku / Re:Rychla praca xml -> csv
« kdy: 10. 06. 2014, 22:09:33 »
Nejjednodušší je to udělat v XSLT. Akorát si musíte říct, co a jak v tom CSV má být.

3588
Server / Re:Apache Proxy forwarding
« kdy: 29. 05. 2014, 13:03:10 »
Záleží na tom, jaké odkazy ta aplikace generuje. Pokud jsou absolutní, bude prohlížeč požadovat /graf, tím pádem se ty příkazy pro proxy vůbec neuplatní. Navíc ty přidané řádky

Kód: [Vybrat]
ProxyPass /test/graf http://192.168.0.10/graf
ProxyPassReverse /test/graf   http://192.168.0.10/graf

Jsou podle mne zbytečné, to pokryje už ta první varianta s /test.

Hláška o přesměrování od Firefoxu ale ukazuje ještě na jiný problém, možná cyklické přesměrování. Podívejte se přes Firebug, jakou přesně dostanete odpověď od serveru.

3589
Vývoj / Re:Assembler - problém s češtinou?
« kdy: 28. 05. 2014, 15:07:42 »
Pracuje správně, dokud nejsou na vstupu znaky české abecedy
Na vstupu zcela jistě nejsou znaky, ale bajty. Pro převádění mezi znaky a bajty slouží různé znakové sady a kódování. Znaková sada přiděluje jednotlivým znakům čísla, kódování pak určuje, jak se tato čísla zapisují do sekvence bajtů.

Vy tedy potřebujete vědět, v jaké znakové sadě máte vstup, následně rozpoznat jednotlivé znaky (třeba v kódování UTF-8 může být jeden znak vyjádřen jako jeden až šest bajtů), rozpoznat slova a prohodit jejich pořadí. Když to děláte podle bajtů, klidně za mezeru můžete považovat bajt, který je součástí nějakého znaku – a to bajtové vyjádření znaku roztrhnete na dvě části a uděláte z toho třeba dva úplně jiné znaky.

Při hledání mezery pracuji tedy s porovnáváním, jestli je znak menší než 32 v ASCI tabulce.
Ta tabulka se jmenuje ASCII a je to jedna ze znakových sad. Původní znaková sada ASCII je jen sedmibitová a české znaky s diakritiky neobsahuje.

Mezera má v ASCII (a v mnoha dalších znakových sadách) hodnotu 32 (dekadicky), měl byste tedy porovnávat na přesnou shodu. Znaky 0–31 jsou různé kontrolní znaky, rozhodně ne mezery. Třeba ve znakové sadě Unicode existují i další znaky, než jenom obyčejná mezera – neoddělitelná mezera, zúžená mezera apod. Jako oddělovač slov dokonce nemusí fungovat jen mezera, ale třeba také tabulátor nebo konec řádku.

3590
Hardware / Re:OS na flash disku?
« kdy: 25. 05. 2014, 19:52:37 »
Přes USB můžete připojit i normální disk - buď rovnou v externím provedení pro připojení k USB, a nebo SATA disk přes USB/SATA adaptér.

3591
Server / Re:Zvláštní chování domény
« kdy: 25. 05. 2014, 11:45:59 »
Nepochopil jsem z vašeho dotazu, zda máte problém s DNS, síťovou dostupností (ping) nebo dostupností webového serveru. každopádně u mne vše funguje a nějaká webová stránka se zobrazí.

Ale jestli jste to nezaznamenal, Wedos měl od pátku problémy, možná to s vaším problémem souvisí.

3592
Server / Re:sftp skopirovanie adresara v ramci serveru
« kdy: 25. 05. 2014, 08:09:14 »
Ešte musím vyriešiť problém, že !cp na akýkoľvek súbor hovorí "No such file or directory".
Zkusil bych ještě plnou cestu /bin/cp.

Ještě mne napadá, /web a /zaloha jsou skutečné cesty, které jste použil? Pokud takhle v sftp fungují (třeba pro download), nejspíš jste v chrootu a pak tam asi žádné /bin/cp nebude. Zkuste si příkazem pwd v sftp vypsat aktuální cestu, zda v těch příkazech nemáte použít i nějaké nadřazené adresáře.

3593
Server / Re:sftp skopirovanie adresara v ramci serveru
« kdy: 24. 05. 2014, 18:11:28 »
Skúsil som cp cez sftp. Dostal som odpoveď Invalid command. Mohli by ste mi pomôcť s cp cez scp?
Skúsil som scp -r uzivatel@server:/web uzivatel@server:/zaloha . Trvá to iba toľko, čo trvá prihlásenie a nič to nespraví. Ani chybovú hlášku nedostanem.
Přes to sftp byste musel příkaz cp spouštět přes vykřičník !cp .... U scp by bylo lepší použít ještě parametr -3, aby kopírování nešlo přes váš počítač. Určitě to vyzkoušejte také s parametrem -v, aby se vypsaly podrobnější informace.

Pokud máte možnost někde vyzkoušet WinSCP, zkuste to přes něj. Myslím, že už tam jsou různé triky vymyšlené a přístupné na jediné kliknutí.

3594
Server / Re:sftp skopirovanie adresara v ramci serveru
« kdy: 24. 05. 2014, 16:39:43 »
Pokud máte na serveru povolené sftp, možná tam máte i scp - a scp protokol příkaz cp umí. Případně vyzkoušejte, zda v sftp nemáte povolené spouštění příkazu cp přes shell.

3595
Sítě / Re:firemní firewall
« kdy: 20. 05. 2014, 14:16:01 »
V Linuxu je firewall přímo součástí jádra a jmenuje se netfilter. K jeho ovládání slouží sada nástrojů iptables, což jsou konzolové nástroje. To je vše, co je k provozování firewallu na linuxu nutné. Pak existují různé nadstavby, často s grafickým „klikátkem“, pomocí kterých můžete pravidla firewallu spravovat – tyto nadstavby pak interně zase volají iptables. Abyste mohl firewall nakonfigurovat, potřebujete vědět, jak funguje – jaká pravidla se kdy na procházející paket aplikují. Když si tohle nastudujete, můžete se pak sám rozhodnout, zda budete používat přímo iptables, nebo co byste vyžadoval od nějakého nástroje nad tím.

3596
Server / Re:Databazy - programovanie/spravovanie
« kdy: 17. 05. 2014, 17:59:50 »
Když systém to duplicitní rodné číslo neumožní zadat, tak holt tu pohledávku obsluha zapíše k tomu druhému člověku se stejným RČ, a třeba si to bude nějakou dobu pamatovat.
Tazko niekoho donutite kontrolovat nieco, co sa vyskytuje u niecoho ako 1 z 10k pripadov alebo menej. To z principu nejde - aj ked na uradnicku budete najskor davat pozor, casom si vsimne, ze je to "vzdy spravne" a jednoducho to bude v hlave ignorovat.
Jste si jist, že váš komentář nějak souvisí s tím, na co reagujete?

To u vas normalne funguje tak, ze ked uradnicke nieco nejde, tak si nieco vymysli, aby to nejak preslo?
Ne. Když něco nejde (třeba zadat žádost o důchod z důvodu duplicity rodného čísla), úřednice oznámí možnou chybu v systému, problém se analyzuje, zjistí se, že jde skutečně chyba v zadání, vypíše se výběrové řízení na úpravu software (nezapomeňte, že jde o změnu zadání, ne opravu chyby), no, a až tohle celé proběhne, může si dotyčný přijít požádat o důchod znovu.

Ale myslím, že ke zjištění, že se ptáte na pěkný nesmysl, se stačilo trochu zamyslet.

3597
Server / Re:Databazy - programovanie/spravovanie
« kdy: 17. 05. 2014, 17:35:44 »
V takových případech ale zase není nutné tam ten údaj vůbec mít.
To pak nevím, jak budete v zaměstnání, ve škole nebo na úřadě osoby identifikovat. Rodná čísla, jména a příjmení a adresy trvalého bydliště odstraníte, a jak pak poznáte, komu máte třeba vydat diplom nebo vyplatit důchod?

3598
Server / Re:Databazy - programovanie/spravovanie
« kdy: 17. 05. 2014, 17:14:39 »
To, že něco, co bylo původně navrženo jako unikátní nakonec tak moc unikátní není a ještě k tomu to nikdo nechce řešit
Tady se nebavíme o tom, jak něco bylo navrženo, ale jaký je o tom předpoklad. Někdo předpokládá, že rodná čísla jsou unikátní (v zákoně je napsáno, že totéž rodné číslo nesmí být přiděleno více osobám), ale pak se zjistí, že dříve nějaká duplicitní rodná čísla přidělena byla. A že to nikdo nechce řešit? Má škola nebo zaměstnavatel prohlásit: "Vážený pane, máte duplicitní rodné číslo, náš informační systém ho nedovolí zadat, tak si laskavě nechtě přidělit nové rodné číslo, a pak vás možná vezmeme?" To, že jsou duplicity  někde, kde by být neměly, je problém té primární evidence, která ty identifikátory přiděluje. Nikdo jiný to vyřešit nemůže, ostatní se mohou jen přizpůsobit a počítat s tím, že to s tou unikátností není až tak slavné.

je podle mě tak velká změna zadání, že to vyžaduje v podstatě nový návrh. Protože ona změna unikátnosti má podstatný vliv na další logiku aplikace.
Na další logiku aplikace to nemusí mít vůbec žádný vliv. Třeba pokud pro evidenci osob používám umělý primární klíč a rodné číslo používám jenom jako jeden z evidenčních údajů, nemá změna unikátnosti rodného čísla na logiku aplikace žádný vliv. Dříve uživatel vyhledal osobu podle příjmení nebo rodného čísla a podle dalších údajů ověřil, že jde skutečně o tu správnou osobu (případně podle nich vybral tu správnou), nově bude postupovat úplně stejně.

3599
Server / Re:Databazy - programovanie/spravovanie
« kdy: 17. 05. 2014, 16:30:52 »
Rodné číslo také má být unikátní. Jak už jsem psal, to, že nějaký identifikátor není primárním klíčem, ještě neznamená, že se unikátnost nemůže kontrolovat (s varováním) nebo vynucovat. Systém může uživatele varovat, že zadává duplicitní VIN, může vyžadovat schválení duplicitního VINu od dalšího uživatele nebo od vedoucího. Dokonce může mít i kontrolu na unikátnost VIN v databázi, ale když se použije umělý primární klíč, pořád je možnost aplikaci jednoduše upravit, až se přijde na to, že v praxi VIN unikátní není. Je mnohem jednoduší zrušit unikátní index a doplnit varování do aplikace, než ve všech odkazujících tabulkách měnit klíč.

3600
Server / Re:Databazy - programovanie/spravovanie
« kdy: 17. 05. 2014, 15:34:39 »
Ano, praktická zkušenost to bohužel je. A na základě této praktické zkušenosti potom vznikají situace, jako že je třeba vymáhána pohledávka pro zcela jiném člověku podobného jména nebo bohužel neunikátního rč a nikdo se nenamáhá to řešit. Do systému to naťukat lze, počítač řekl, že dlužíte, tak plaťte.

Pokud má někdo za úkol napsat systém pro evidenci vodizel, tak VIN je pro měj dostatečně unikátní už z definice na to, aby z něj mohl být i PK. Protože v běžném režimu se nemůže stát, že dvě různá vozidla mají stejný VIN. Pokud se tak stane, nelze nad tím mávnout rukou, naopak se to musí řešit mimořádně. Systém, který umožní zapsat dvě vozidla se stejným VIN jaksi nikoho nenutí to řešit a v praxi to dopadne nejjednodušší možnou cestou, že to tam dotyčný operátor prostě nechá.
To, že nějaký údaj není v PK, vůbec neznamená, že se nemůže kontrolovat unikátnost takového údaje. Naopak ten váš přístup znamená, že se pohledávka bude vymáhat po někom úplně jiném, nebo že se na tu duplicitu VIN nepřijde. Když systém to duplicitní rodné číslo neumožní zadat, tak holt tu pohledávku obsluha zapíše k tomu druhému člověku se stejným RČ, a třeba si to bude nějakou dobu pamatovat. A pro to auto si vymyslí jiný VIN, a ten do databáze zadá. Protože je to pořád menší otrava, než to auto neevidovat vůbec.

Všimněte si, že to vyžadování unikátnosti tam, kde v reálném světě identifikátor unikátní není a obsluha programu ten identifikátor nemůže nijak ovlivnit, tu chybu nikdy neopraví, naopak to připraví půdu pro vznik dalších chyb.

Stran: 1 ... 238 239 [240] 241 242 ... 266