Pokračovat ve čtení »]]> Jedná se o MVC aplikaci napsanou v PHP 5.3

Použil jsem Zend Framework 1 a to zejména z důvodu dobré dostupnosti dokumentace a literatury. Další aplikace ale už budu raději vyvíjet v nette nebo jiném frameworku, neboť u Zend-u jsem narazil na dost nečekané a otravné limity zejména v oblasti spolupráce s Ajax, jquery, přizpůsobení vzhledu, atd.

Dále také používám MYSQL 5.5, Apache 2 a APC resp. memcached daemona.

Vstupem jsou textové (csv) tabulky jednotlivých uskutečněných volání (volající, volaný čas zahájení, čas ukončení). Výstupem jsou faktury v pdf a xml pro jednotlivé koncové zákazníky, dále seznamy jednotlivých uskutečněných volání konkrétního uživatele, jež lze v html prohlížet, filtrovat, sumarizovat a řadit podle různých sloupců.

Tento projekt je stále ještě ve stádiu vývoje, nebyl zatím předán zadavateli, takže ještě nemohu zveřejňovat veškeré podrobnosti, na které bych chtěl upozornit. Jakmile to bude možné, tento text rozšířím o konkrétní ukázky a zajímavosti, na které jsem v průběhu vývoje této aplikace narazil.

• Podle volajícího ID (číslo A)  se načtou data uživatele a patřičný ceník uživateli přiřazený.
• v ceníku se vyhledá tarif odpovídající předčíslí s největším stupněm shody s volaným ID (číslo B)
• každý ceník má cca 6000 řádků, tedy z důvodu urychlení využíváme cachování pomocí jedné z více možných metod memcached, APC, RAM, RAMDISK
• podle Timestampu volání se určí, zda se jedná o silný či slabý provoz (svátky, Vánoce, Velikonoce, víkendy atd)
• na základě údajů z ceníku se určí také tarifikace, která je rozdílná pro různé kategorie uživatelů a také pro různé destinace volání (60+60, 60+1, 30+1, 15+15, 1+1)
• spočítá se výsledná cena
• musí se ošetřit přechody mezi vysokým a nízkým tarifem v rámci jednoho hovoru
• musí se ošetřit různé chytáky ve speciálních tarifech (linky 810, 900,906, 976, 1188, 1301 apod)
• kontroluje se minimální marže (koncová cena pro zákazníka vs. spojovací poplatky operátorům a poskytovatelům)
• v případě chyby (nenalezen uživatel nenalezen tarif atd) nejsou faktury vygenerovány a vše se vrátí ze zálohy do původního stavu

další je myslím nejlépe patrné ze screenshotů:

Uživatel + JS

◄ Back

Next ►

Picture 1 of 19

Editace uživatele. Verifikace polí formuláře pomocí javascriptu.

Pokračovat ve čtení »]]> SYSTÉM NA SPRÁVU DWG DOKUMENTŮ

byl plánován jako odlehčená náhrada za Ms. Sharepoint a podobné systémy, bez administrativní části, bez správy a hierarchie uživatelů, pouze jako takové lepší uložiště, které bude umět vyhledávat, řadit, upravovat zejména soubory DWG, neboť s těmi si klasický Sharepoint, neřku-li windows search indexer bez drahých komerčních doplňků prostě neporadí.

Jedná se o aplikaci složenou z několika komponent vytvořených v několika různých jazycích.

frontend je PHP, jedná se o jednoduchou aplikaci s jedním kontrolerem a dvěma pohledy. Její hlavní funkcí je zobrazovat obsah, řadit řádky a případně vyhledat data podle zadání klíčového slova ve formuláři.

S uživateli komunikuje pouze jednosměrně, data se nevkládají přes tuto frontendovou aplikaci, ale přes

backend , jež tvoří BASH / AWK skript, spouštěný pravidelně po 10ti minutách (cronem) a jehož úkolem je sebrat metadata o nových či upravených souborech v uložišti a aktualizovat databázi těchto metadat (mysql)

o generování metadat a jejich “dolování” se stará “plugin” vytvořený z důvodu kompatibility ve speciální odrůdě LISPu, tzv. AutoLispu. Ten se spouští přímo v CAD aplikaci (Intellicad, Autocad či jiném 2D kompatibilním CADu s podporou AutoLISPu). Pro originál AutoCAD od Autodesku by bylo možné tento plugin napsat také jako makro VBA.  Ovšem podpora VBA není, pokud je mi známo, implementována u žádné verze IntelliCadu (ProgeCAD, BricsCAD, ZWCAD atd) , tedy je nutné při nasazení  těchto programů zvolit LISP.

Metadata by bylo možné generovat i mimo vlastní CAD aplikaci, ale nastává pak problém se čtením naprosto uzavřeného DWG formátu, jež je bitovým formátem s tokem dat několikrát rekurzivně komprimovaným, s CRC ochranou a redundancí. A navíc každý druhý rok vychází nová DWG specifikace, takže by se musela vytvořit i nová verze tohoto DWG extraktoru.

—————————————————

 několik screenshotů, ze kterých bude vše myslím jasné:

1

◄ Back

Next ►

Picture 1 of 6

tento systém jsem vyvinul pro mého zaměstavatele v rámci mojí pracovní činnosti

Pokračovat ve čtení »]]> Po nejake dobe nastaly v nasi kancelari ukrutne hadky o to, kdo bude mit pripojene bednicky a kdo bude mit sluchatka. Uz jsem se na to nemohl koukat, a tak jsem hledal reseni. Nalezl jsem php frontend k prehravaci mpg123 jmenemToasterMP3. Bohuzel mel vsak tu chybu, ze byl vytvoren v roce 2001 a urcen pro php3. Nastesti nebylo prilis slozite prizpusobit jej pro pouziti v dnesni dobe.
K behu je potreba nainstalovat mpg123, apache, php5, perl, amixer, a eventuelne jeste ogg123. Vsechny zminene utility a demoni jsou beznou socasti oblibenych distribuci (v mem pripade Mandriva)

Co se tyce nastaveni systemu, je potreba vypnout v php.ini safemode = off, a nastavit pristupova prava k zvukove karte . Vseobecne se to doporucuje zajistit prirazenim uzivatelu do skupiny “sound” a nebo lze nastavit opravneni pro pristup k /dev/dsp (alsa) [pripadne /dev/audio (oss)] a ovladani mixeru  na 666.

Vlastni toaster tak, jak jsem jej upravil, najdete zde: http://bouska.biz/linux/toastermp3/toastermp3.zip
staci vse rozbalit a nastavit spravnou cestu v konfiguracnich souborech a v souboru player.pl
ma funkce razeni souboru do fronty, primy poslech konkretniho souboru, shuffle playlistu, rizeni hlasitosti, start / stop a zobrazeni aktualne prehravane mp3ky.

navod k nastaveni atd najdete zde:  http://bouska.biz/linux/toastermp3/readme.txt

pozn. :  je to už pár let, jedná se ještě o procedurální, neobjektový kód převzatý z původní php3 verze. Dnes už překonaná záležitost