To nie jest takie proste – oczywiście poza tym przepisywaniem daty urodzenia z PSEL – gdzie nie przypuszczałem że może to stanowić istotny problem oraz wykaz urządzeń, który był stworzony na szybko do testowania i oczywiście może być poszerzony a wręcz musi .
Wspominałem już o pewnych założeniach do tego programu i do jego „ojca” – założyliśmy że to będzie tania , prosta i skuteczna forma gromadzenia istotnych danych na poziomie JOT z połączeniem z UG/UM gdzie będzie można wrzucić do jednego worka X OSP . Każdy „pisarz” ten programów również siadając do dzieła ma pewien pomysł z zakończeniem włącznie i nie wierzcie w wersję ver. 6.8.99 bo nawet pisząc z założeniem intensywnej rozbudowy oprogramowania po 10 wersji program nadaje się do przepisania by trzymał tzw. linię - fason. No chyba że przyjmiemy luźną formę byle gdzie powstawianych komponentów , byle by działało i do przodu ale to nie ten adres .
Pisząc program prosty jest tak naprawdę jeszcze trudniej utrzymać dużą uniwersalność . W programach rozbudowanych tworzymy to dynamicznie ,np. na bazie dziesiątków edytowanych skorowidzów . Tu próbowaliśmy wybrać jakiś kompromis , raz by uniknąć kosztów , dwa by uprościć formułę a co z tym związane musimy trzymać tą linie do końca .
- owszem ekwiwalent może mieć stałą wartość jednak nie w każdej OSP ma – w wersji rozbudowanej pewnie bym to powiązał z wieloma opcjami i relacjami – tu niestety musi pozostać tak by było uniwersalnie prosto i tanio .
- Kary drogowe i sprzętu to kolejny dylemat – zadeklarowałem że dopisze i to czynie właśnie, ale musze również zrobić to równie elastycznie i prosto ( mam dużo dylematów i kombinuje jak przysłowiowy koń pod górkę ) - co nie jest łatwe bo każdy ma inne zdanie w temacie – wiązać z wyjazdami , nie wiązać , kupować paliwo na samochody , a może do jednego worka i rozdzielać , a może automatycznie pobierać z magazynu . Doliczać poza autopompą , pracę na postoju , webasto ? ale 1, a może 2 ? a co z rozruchami ? itd. itd. Do tego dane te muszą dać się analizować bo o to między innymi w tym chodzi , a co z tym związane muszą spełniać pewne cechy matematyczno-statystyczne. W dynamicznym programie nie było by problemu – ale ja chcę zaproponować wam moduł kart drogowych i sprzętu np. za 100 zł a nie za 1000 zł. Wiec musimy opierać się z jednej strony na kompromisach , z drugiej na uniwersalności by program mógł się dostosować do użytkownika , a nie użytkownik do programu .
I tak to z mojej strony niestety wygląda .
Jednocześnie bardzo się cieszę z każdej uwagi – nie ukrywam z większości zdaje sobie świetnie sprawę ponieważ od lat jestem w OSP i znam potrzeby , tylko jak wspomniałem muszę z wielu powodów posługiwać się kompromisami .
Zachęcam do testowania i wyrażania opinii bo wyłapujemy błędy - również na moich komputerach które są skonfigurowane do pisania nie jestem w stanie wyłapać wszystkich wad . Dopisując częściami nie mam również pełnej kontroli, ponieważ nie wracam do pewnych rzeczy , a zdarza się że mogą mieć wpływ na działanie programu w innych miejscach .