Aké som mal nápady a fičurky v SkladePro.

Tí ktorí ste prečítali môj predchádzajúci blog sme ma poprosili aby som popísal aké som mal nápady a fičurky v svojom SkladePro. Prečo môj program fungoval a iné mali problém minimálne s rýchlosťou výpočtu na sieti. Rád to popíšem.

V prvom rade by som rád poznamenal, že na vysokej škole som skoro stále pracoval v prostredí s obmedzenými zdrojmi. Bežne sme používali vyradené súčiastky, ktoré nedosahovali predpísané parametre. Používali sme pomalé procesory, pamäte ktorým ale spoľahlivo pracovala len časť kapacity, diskety ktoré boli vadné, nakoľko aj polovica bola mechanicky poškodená (napr. škrabnutá). Ak sme mali HDD a fungoval mu len jeden magnetický disk, aj s tým sme si vedeli poradiť. Všetko sme využili. Naviac VŠDS ma naučila v čom je rozdiel medzi bezpečnosťou a spoľahlivosťou. Naučila ma postupy ako postaviť bezpečný komponent aj z nespoľahlivých súčiastok. Túto logiku učili len železnice.

Pri programovaní aj nás učili, že zdrojový kód je ako kniha a musí vyzerať krásne. Keď sa ti niekto pozrie na tvoj zdrojový kód, tak to musí byť román, len písaný v predpísanom počítačovom jazyku. Častokrát som počul, že román by nemal dobrú čitateľnosť ak by sa v ňom opakovali rovnaké slová. Preto sa všetko píše, len raz! Ak máte volať nejakú inštrukciu 100x nenapíšeš ju 100x pod seba, ale urobíš cyklus, funkciu, procedúru, objekt. To do nás hustili na počítačovej katedre a pri fortráne či pascale to aj platilo. Problém nastal, keď som prešiel do jazyka symbolických adries. Procesor žiadny cyklus nepozná, on chce len plynulý tok inštrukcií ktoré by vedel čo najjednoduhšie a najrýchlejšie vykonávať. Napr. v pascale ak sme použili príkaz GOTO tak náš učiteľ programovania vyskočil po strop, ale v jazyku symbolických adries to bolo často krát najlepšie a najrýchlejšie riešenie. Ja som vo svojich riešeniach veľmi často naháňal čas. Ono je to zásadný rozdiel či Vám húfnica vystrelí za minútu, alebo za 10 sekúnd od zistenia súradníc cieľa. Konkrétne v tomto prípade to bola často otázka života a smrti (vojakov ktorých sme paľbou bránili). Rovnako to bolo pri riadení statických meničov. Je dobré merať a vypočítavať čo najrýchlejšie. Ináč neregulujete dynamické deje ale ich len odhadujete a Vaše riadenie stojí za figu. Dnes keď idem vo svojom autíčku VW Golf 2,0 Diesel, tak je mi úplne jedno či je napísaný zdroják v riadení motora ako román. Mňa zaujíma len či mi môj palubný počítač dokáže odmerať a vypočítať hodnoty chodu motora dostatočne rýchlo, aby mal môj agregát „pravidelný chod“ aj pri rýchlej akcelerácii. V týchto podmienkach som študoval. Rýchlosť výpočtu aj pri pomalých súčiastkach bola rozhodujúca. Moje zdrojáky vyzerali hrozne, ale boli na danom hardware najrýchlejšie.

Podobnú logiku som naprogramoval v SkladePro. Najprv som si zmeral spoľahlivosť jednotlivých príkazov vo FoxPro. Áno, urobil som krátke procedúry s jedným rozhodujúcim príkazom nad tabuľkami dát a meral som či je daný príkaz spoľahlivý. Niektorý príkaz urobil spoľahlivo to čo má 100x a potom spadol. Niektorý to urobil 1000x a potom spadol a niektorý urobil spoľahlivo to čo má, len keď sa pomýlil. Napr. príkaz SQL SELECT bol vo FoxPro príkaz ktorý sa nedal používať vôbec. Je to smutné, nakoľko SELECT je základný príkaz nad databázou, ale bol absolútne nepoužiteľný (urobiť SELECT v SELECTE vo FoxPro by bolo na samovraždu, v Oracle úplne bežný postup). Takýchto príkazov bolo v jazyku FoxPro dosť. Našťastie dosť bolo aj príkazov ktoré fungovali celkom spoľahlivo, alebo spoľahlivo s určitým obmedzením. FoxPro tiež doporučovala skompilovať celý program do jedného pseudo .exe (spustiteľného) súboru. Bolo to až smiešne, ale takého výrobcom doporučené riešenie, bolo najmenej spoľahlivé. Ja som mal .exe ako samostatný súbor na každý podprogram hlavného menu a po skončení výpočtu som vymazal všetky pracovné súbory, uvoľnil pamäť a regulérne skočil naspäť do hlavného menu. Mne v DOS-e stačilo cca 75% základnej pamäte DOS a rozšírenú pamäť sme vedeli bez problémov použiť celú na podporu protokolu siete, RAM DISK, podporu tlače po sieti… a mnoho iného.

Potom som začal merať čo robí s rýchlosťou výpočtu skutočnosť, ak pridávam obmedzujúce podmienky (príkaz FOR). Úplne najhoršia bola podmienka ktorá ohraničovala časové obdobie. Ak som do príkazu napr. TOTAL dal ešte aj ohraničenie dátumov, teda od dátumu do dátumu, tak som výpočet spomalil aj 100x. To bolo pre mňa tiež kľúčové zistenie. Oracle pracoval veľmi zaujímavo s vymazanými údajmi. On si označil riadky, že sú vymazané, a nemazal ich, pri najbližšej príležitosti ich ale dokázal použiť a zapísať tam nové data. Podobne mazala aj Fox-ka, aj ona si označila riadok za vymazaný (na prvom mieste znakom hviezdička), ale potom už s tým nevedela nič urobiť. Úplne najhorší príkaz bol príkaz na pridanie riadka do tabuľky. Tento príkaz nakoľko potreboval do hlavičky zapísať, že pridal riadok tak uzamkol celú tabuľku (čo bolo hrozné pre ostatných užívateľov ktorým na display nabehol LOCK a bolo potrebné čakať na odblokovanie celej tabuľky, nie len jedného riadku), príkaz fyzicky riadok skutočne pridal, ale zmenu hlavičky držal len v pamäti. Do hlavičky súboru na disku nič nezapísal. Ak v tomto momente spadol program a tabuľka sa regulérne neuzavrela, všetky dáta tabuľky boli pre FoxPro stratené. Tabuľku už nevedel program otvoriť. Ak ste používali nespoľahlivú LAN, tak ste tento problém riešili každý týždeň. Ak mal zákazník zálohu, tak paráda, ak nie, tak bol problém. Takto stratil všetky dáta z poškodenej tabuľky (teda najčastejšie položiek predaja). Táto chyba bola veľmi nepríjemná. APPEND bol jednoducho nielen nespoľahlivý, ale aj extrémne nebezpečný. Ako som z toho vykorčuľoval?

Oracle dáta zapisoval na vyhradený disk, alebo aj do súboru, ktorý si databáza urobila pri inštalácii. Tento súbor sa založil s dostatočnou kapacitou a jeho rozšírenie nebola užívateľská práca. Ak sa miesto v tablespace zaplňovalo, tak bol správca databázy vyzvaný, aby tento problém riešil. Mal na to dostatok administratívnym nástrojov, aby to dokázal. FoxPro mala jeden súbor na každú tabuľku. Veľkosť tohto súboru sa menila každým pridaním riadku tabuľky. Riadky pridávali samozrejme užívatelia. Zmenil som túto logiku. Príkaz APPEND som v užívateľskom móde takmer nepoužíval. V každej tabuľke som si pri jej založení vytvoril dostatok prázdnych riadkov, ktoré som potom označil ako vymazané. Oni tam samozrejme ostali, len dostali znak hviezdičky na začiatok riadka. Ak užívateľ potreboval pridať riadok, tak som spustil príkaz na nájdenie prvého vymazaného. Ak som ho našiel, tak som zrušil príznak vymazania a ponúkol som programu daný riadok na zapísanie nových údajov. Ak som ho nenašiel, tak som nageneroval správcovi databázy správu, že má sputiť správcovský program po skončení smeny a zavolal som nebezpečný APPEND BLANK a okamžite príkaz FLUSH, ktorý zapísal zmenu počtu riadkov v tabuľke do hlavičky súboru na disk, potom som tabuľku uzavrel (vtedy ostatným konečne zmizol LOCK a vedeli ďalej pracovať) a tabuľku znovu zdieľane otvoril, nakoniec som skočil na pridaný prázdny riadok. Bolo to celé veľmi pomalé, ale spoľahlivé a bezpečné. Prax ukázala, že obsluha si spomalenie hneď všimla a sama kontaktovala správcu, aby spustil po skončení smeny SORT DAT, ako sme procedúru na pridanie riadkov volali. Procedúra SORT DAT bol program ktorý bol naprogramovaný v jazyku C+ a vedel si poradiť pri súboroch .DBF aj s tým, že v hlavičke nesedel záznam počtu riadkov na reálnu dĺžku súboru. Hlavičku vždy opravil tak, aby daný súbor určite otvoril FoxPro aj keby počas zadávania nových riadkov vypadol prúd a došlo k nezapísaniu regulérnej hlavičky súboru. Po opravách hlavičiek a fyzického zoradenia záznamov na disku podľa hlavného indexu tabuľky som potom nanovo nageneroval všetky indexy a pridal prázdne riadky, ktoré som označil za vymazané. Takto som zachoval rýchlosť aj bezpečnosť aj v prostredí FoxPro.

Ako sa ale vysporiadať s tým, že v príkazoch nesmiem používať podmienku dátumov od:do? Riešenie bolo len jedno. Keď program potreboval vypočítať niečo z hlavnej tabuľky za časové obdobie, tak som ako prvé vykopíroval dáta s podmienkou dátumov do novej dočasnej pracovnej tabuľky. Túto som potom otvoril výhradne pre seba a vykonal všetky výpočty ktoré som potreboval vykonať už bez časových podmienok, nakoľko iné dáta ako tie ktoré som chcel spracovať som v tabuľke nemal. Data som potom zoradil, spočítal, pripravil report… všetko čo som potreboval, na čo som si pomyslel. Napriek tomu, že to kopírovanie som tam mal naviac, v konečnom dôsledku som ušetril čas. Ak niečo počítač naozaj vie rýchlo, tak vie kopírovať súbory. Videl som mnoho programov ktoré názvy týchto pracovných súborov generovali náhodne, ja som tak nerobil. Program poznal číslo užívateľa od 01 do 99 a toto číslo potom bolo súčasťou názvu dočasnej tabuľky. Názvy súborov určite obsahovali aj číslo podprogramu ktorý uvedenú tabuľku vykopíroval. V tom som bol strojovo presný. Ak niečo nefungovalo názvy súborov ktoré ostali v temp adresári mi jasne povedali, ktorý užívateľ spadol a v ktorej bol dávke. Takto sa jednoducho hľadali chyby. Určite zdržanie vykopírovaním dát bolo minimálne ak to porovnáme k ušetrenému času pri výpočte. Celý výpočet prebiehal na lokálnom disku, alebo v RAM-ke staničky a nezaťažovalo to LAN sieť, čo bolo ďalšie veľké plus pre môj program. Ak by videl tento postup učiteľ programovania, asi by ho trafil šľak a žiadny strop by nebol dosť vysoko, ale mne to nevadilo. Na zdroják sa síce nedalo pozerať a čítať ho ako román, ale znovu som bol pri pomalom hardware (ktorý bol k bežne dispozícii) najrýchlejší a najbezpečnejší. Je pravdou, že teraz sme už po nikom aspoň nestrieľali. 🙂 [Teda ak by som sa pomýlil pri výpočte krivky alebo pri riadení pohonov na novú pozíciu, aspoň to nemohlo mať fatálne následky zbombardovania vlastných pozícií.]

Niektorí ktorí študovali môj zdroják sa ma potom pýtali prečo som to celé programoval vo FoxPro, keď v tomto prostredí viac príkazov nefungovalo ako fungovalo (teda aspoň na začiatku). Ja som to celé bral ako výzvu. Ako všetko v mojom živote. Ak dokážem v nespoľahlivom prostredí postaviť bezpečný sieťový program, tak som sa niečo naučil. Čas ukázal, že som to dokázal. Dokázal som z lacného hardware vyťažiť maximum a mnohým podnikateľom ktorí používali môj sklad som pomohol v ich začiatkoch podnikania. Dnes už majú dosť peňazí aj skúsenosti zakúpiť si SQL verzie skladov či účtovníctva a s láskou spomínať na naše začiatky a značku (c) hajasoft 89-XX. Nikdy som sa necítil byť programátorom databáz. Bol som programátorom, nakoľko nik iný by moje postupy nevedel naprogramovať. Nechápala ma ani moja manželka a to sme študovali rovnakú školu aj odbor. Nikdy ma to však nebavilo napriek tomu, že som programoval rýchlo a ľahko. Mojou životnou láskou je riadenie. Dôvod prečo som sa nikdy necítil byť programátorom databáz, o tom radšej napíšem nový blog.

Život je výzva. Niekedy vyhráš, niekedy prehráš. Najhlúpejšie čo by si však mohol urobiť je výzvu neprijať a potom celý život plakať, že ti ušli všetky príležitosti. Ja nemám prečo plakať. Mne nič neušlo a veľa som vyhral a verím, že vyhrávať neprestanem. 🙂

Neprešlo jazykovou úpravou!