Rubrika: Nezařazené

Čtečky čárového kódu na webu

Při psání informačního systému jsme narazili na nutnost využít čtečky čárového kódu.

Tato zařízení jsou dnes poměrně levná a spolehlivá. V první chvíli jsme se obávali jejich použití v prostředí webové aplikace. Naštěstí vše bylo jednodušší než jsme čekali.

Většina čteček se chová jako další klávesnice. My jsme využili USB variantu, která přímo implementuje HID protokol pro klávesnici. Pokud přečtete čárový kód, čtečka pošle odpovídající znaky do počítače jako stisky kláves.

Abychom zabránili vepsání čárového kódu do libovolné položky formuláře na stránce, naprogramovali jsme čtečky tak, aby před odesláním znaků poslaly i stisk klávesy Shift+F12 a po dokončení klávesu Enter. Poznáme tedy, že uživatel použil čtečku a nikoliv klávesnici, zobrazíme skryté zadávací pole (pomocí JavaScriptu) a po dokončení, díky klávese Enter, se formulář sám odešle.

Pro generování a tisk čárových kódů používáme program UJAC a do čárového kódu ukládáme nejen čísla, ale i znaky (v podstatě jde použít jen A-Z a a-z).

Zajímavý je také způsob programování čteček. Je s nimi dodáván obslužný program. V něm vytvoříte nastavení, které pak jako soubor čárových kódu vytisknete. Čtečku pak k vytištěným kódům postupně přikládáte a tím jí nastavíte. Zajímalo by mne zda je možné tímto způsobem přeprogramovat čtečky v supermarketech 🙂


Klíčová slova: čtečka, čárový kód, webová aplikace, web, barcode reader

PostgreSQL 8.1 – znatelné zrychlení

V současné době vytváříme informační systém, který jako svojí databázi využívá PostgreSQL. V produkčním prostředí jsme používali verzi 7.4.

V poslední době jsme pro vývoj začali používat verzi 8.1.

Protože velmi často používáme složité dotazy s velkým množstvím "joinů" a podmínek, museli jsme vytvářet složené indexy pro různé kombinace podmínek a i přesto je často databáze nedokázala využít. Tato verze však přináší novou vlastnost "Bitmap Scan", a dokáže tak kombinovat více jednoduších indexů. Protože nemusíte vytvářet složené indexy, ušetříte paměť/IO operace/místo na disku a zvýšíte rychlost vkládání záznamů. Dokáže také častěji najít kombinaci indexů pro dotaz.

Další zajímavou vlastností PostgreSQL je od verze 8.0 možnost provozu více verzí databáze současně (toto zpětně zprovoznili i pro verzi 7.4) a také skvělá podpora platformy Windows.

Z PostgreSQL se stává velmi dobrá databáze.

Využití OpenSSL certifikátu k podepsání JAR souboru

Využít existující certifikát OpenSSL (vygenerovaný např. vlastní certifikační autoritou) k podepsání JAR souboru (např. pro JavaWebStart) není zrovna jednoduchý úkol. Chtěl bych vám popsat návod jak jsme to vyřešili my. K vygenerování OpenSSL certifikátu můžete použít např.

Předpokládejme, že máme certifikát i klíč uloženy v jednom souboru ve formátu PEM.
Nejdříve musíme vše vyexportovat z formátu PEM do PKCS12. Důležité je pojmenovat certifikát v uložišti, protože se na něj budeme později odkazovat při podepisování JAR souboru.

openssl pkcs12 -export -in SoftEU-JavaWebStart.pem -out SoftEU-JavaWebStart.p12 -name softeu

Akce (export do PKCS12) se provádí jen jednou. Tím jsme získali úložiště, se kterým už jarsigner dokáže pracovat. JAR podepíšeme:

jarsigner  -keystore SoftEU-JavaWebStart.p12 -storetype pkcs12 target/softeu-scan-1.jar softeu

A výsledek zkontrolujeme:

jarsigner -verify target/softeu-scan-1.jar


Klíčová slova: jar sign openssl convert keytool java keystore

PostgreSQL a priorita dotazů

Naše databázová aplikace obsahuje dva druhy akcí – "interaktivní" a "na pozadí". Interaktivní jsou takové akce, které vyvolal uživatel a čeká na jejich výsledek (např. výpis záznamů). Akce na pozadí jsou spouštěny automaticky a provádějí různé dlouhotrvající práce (např. přepočet aktuálních úroků pro nový den). Téměř všechny akce na pozadí spouštíme v noci a žádný uživatel nečeká na výsledek.

Někdy je třeba spustit akce na pozadí i v době, kdy je systém vytížen interaktivními akcemi. V takových případech se může stát, že se běh interaktivních akcí zpomalí.
Pokračování textu PostgreSQL a priorita dotazů

Proč se vydávájí produkty se známými chybami

Adam Hauner mně upozornil na zajímavý článek na témá, proč se vydávají produkty se známými chybami.

Cituji z článku:

  • vydáte verzi se známou chybou, protože se staráte o kvalitu kódu tak moc, že rozhodujete, které chyby jsou ještě akceptovatelné a které už ne
  • vydáte verzi se známou chybou, protože je lepší vydat produkt s úrovní kvality, která je známá než vydat produkt, který je plný překvapení
  • vydáte verzi s chybami, protože druhou možností je opravit je a riskovat možnost zanesení dalších chyb, které mohou být ještě horší než ty, které máte teď

Doporučuji k přečtení.

Celý článek My life as a Code Economist uveřejněný na blogu autora.

Omezení přístupu přes SSH klíče

V unixovém prostředí s více počítači je často potřeba vyvolat z jednoho počítače akci na jiném – např. synchronizace přes rsync z cronu. Oblíbeným způsobem je užití SSH spolu s klíčem, ale nejde o řešení bezpečné: aby přihlášení mohlo proběhnout v automatickém módu, vygenerované certifikáty nemají hesla. Riziko je zřejmé: při kompromitaci prvního serveru je automaticky kompromitován i druhý server.

Rád bych vám nabídl návod na bezpečné řešení, které vám umožní omezit dostupné akce na druhém serveru:

Vygenerujete certifikát jen pro danou akci – např. rsync a do souboru ~/.ssh/authorized_keys na cílovém počítači ke klíči přidáte i pár magických slov, která musí být na stejném řádku:

command="rsync --server --daemon .",from="zdrojovy-server",no-port-forwarding,no-X11-forwarding,no-pty ssh-rsa KOD-SSH-KLIČE root@localhost

Po uložení souboru je pravidlo okamžitě aplikováno a je tedy povolen jen konkrétní příkaz z konkrétního stroje, naopak je zakázáno forwardování portu, forwardování X11 a alokování PTY.

Pokud potřebujete pro jeden počítač povolit více příkazů, stačí napsat více řádků.

Upozornění: při testování funkčnosti si nezapomeňte vypnout SSH-Agenta, aby nepoužil váš vlastní klíč jako alternativu při selhání ověření.

Více nabízí články Automated Backups With rdiff-backup na serveru HowtoForge a SSH Bouncing – How to get through firewalls easily na Hacking Linux Exposed.

Tomcat a problémy s kódováním

Před časem jsme měli problémy s kódováním češtiny v tomcatu. Při postu a getu se čeština občas pokazila.

Chtěl bych se tedy podělit s fíglem jak to vyřešit.
Problém nebyl v aplikaci, ale v konfiguraci tomcatu.

Na všech verzích tomcatu (4.x a 5.x) je potřeba přidat 

-Dfile.encoding=utf-8

do CATALINA_OPTS (na debianu do /etc/default/tomcat5). Ve windows v Monitor Tomcat do Configure->Java->Java Options.

Pokud používáte tomcat 5.x (což je náš případ) musíte přidat i toto 

URIEncoding="UTF-8"

do konfigurace connectoru v server.xml <Connector port="8080" ... URIEncoding="UTF-8" ... /> (více viz. dokumentace u apachů).

Vlastní certifikační autorita

Také jste už někdy řešili generování certifikátů? Vygenerovat self-signed je ještě docela snadné (zvlášť když k tomu použijeme KMS :-).

Pokud jste ovšem chtěli vygenerovat vlastní CA a pomocí něj vygenerovat a podepsat certifikáty, už to tak snadné není. Pomocí OpenSSL to člověk, po hodině studování materiálů, zvládne.

Pokud to chcete jednodušeji, použijte TinyCA2. Jendá se o GUI aplikaci, ve které to lze naklikat za chvilku.

Ideální řešení pro CA v malé firmě.