Citat:
galenit: Nisu zahtevi za racunovodstvene programe samo fiskalni stampac da bi mu se toliko ovde poklanjalo paznje.
Naravno da podrska fiskalnom stampacu nije jeidni zahtev, ima ih jos gomila koji stavljaju na muke i mnogo ozbiljnije igrace, a krpez-resenja kakva se ovde nude ozbiljan projektant i ne uzima u obzir, osim u sali.
Citat:
A ova platforma ispunjava zahteve sa terena koje daju knjigovodje i te zahteve slusam od perioda dBase II i nista se znacajno nije promenilo osim sto se malo slabije placa.
Ozbiljno me interesuje kako neko ko se bavi razvojem knjigovodstvenih programa jos iz vremena dBaseII moze da uopste razmislja o krpezu kao zameni za dBase. Pa i dan danas dBase ce da resi svaki zahtev u knjigovodstvenoj apliakciji bolje od LAMP, jedino to ce ruznije da izgleda.
Citat:
Ako ovi programi ne zadovolje neku trafiku gde je po cenu zivota bitno da se izda fiskalni to ce vervatno neko resiti u narednom uredjaju gde ce imati kucica da sedi ispektor i pazi ko je u trafici izdao fiskalni odsecak
Zaista cudan nacin razmisljanja. :)
Citat:
Ali i dalje ovde nisam dobio odgovor za koji se programski jezik opredeliti za racunovodstvene programe a da nisu DOS programi samo ofarbani i maske generisane vec da donosi nesto novo u celoj koncepciji koja se za zadnjih 20 godina nije promenila
Odgovor necesni dobiti jer ima vise platformi koje rade posao kako treba, pa je to sve stvar afiniteta. Stavise, sa razvojem komunikacione infrastrukture sve su cesci zahtevi koje je zaista lakse resiti nekom LAMP platformom, tako da je pravi odgovor u stvari u vise platformi - za jedan deo posla treba razvijati klasicne dekstop aplakacije koje su cvrste, brze i efikasne, a druge delove raditi u nekoj web platformi. To niej stvar izbora vec je postalo uslov: kao sto nikada neces napraviti web apliakciju za unos ogromen kolicine podataka (fakture i slicno), tako nikada neces napraviti ni prakticnu dektop aplikaciju koja treba da radi online, recimo pregled izvestaja i pracenje stanja u knjigovodstvu sa udaljene lokacije, cesto mobilno.
U sustini zahtevi pred knjigovodstvenom apliakcijom se lokacijski mogu svrstati u cetiri grupe:
- rad na jednom racunaru
- radi u LAN-u
- rad na udaljenim mestima gde je neophodna ista funkcionalnost kao i u lokalu ali je komunikacija ogranicena na link ogranicene brzine (iznajmljena linija, VPN preko Interneta i slicno), kao sto su razne poslovnice, ispostave, prodavnice, skladista)
- rad u mobilu, bez zahteva za poptunu funkcionalnost kao u lokalu, vec su uglavnom potrebni izvestaji i povremeni unos manje kolicine podataka, po pravilu na nekom mobilnom uredjaju: laptopu, PDA, ili cak mobinom telefonu.
Svaka od ovih grupa zahteva drugaciji pristup.
Radi pojednostavljenja, obicno se prva, druga i treca objedine pod zajednickim imeniteljem: radom mrezi, gde se aplikacija razvija za prilike ogranicene brzine komunikacije a kada se radi u lokalu, to se samo oseti u brzini protoka podataka. To se najcesce pokaze kao los potez.
Udaljeni rad sam po sebi zahteva kompromise u korisnickom interfejsu, koji nisu potrebni kada se radi u lokalu, a aplikacija koja se razvija za udaljeni rad, obicno u lokalu deluje osakaceno. Ukratko: samim tim sto je ogranicena brzin pristupa podacima, interfejs mora to da ima u vidu i da do podatak dolazi na nacin koji je prihvatljiv i sa stanovista brzine i stanovista upotrebljivosti interfejsa. S druge strane, za rad na jednom racunaru tesko da nekome mozes da prodas potrebu za Oracle serverom na primer...
Na izbor platforme utice i ciljna grupa korisnika programa. Sasvim je jasno da program koji treba da radi u trafici, ne moze da radi posao i firmi koja ima 10.000 zaposlenih, i 100 udaljenih lokacija u kojima knjigovodstvo treba da bude funkcionalno isto kao i u centrali, ali i da je program koji radi posao nekoj velikoj firmi jednostavno preglomazan za trafiku. a opet, cesto, velika firma ima neki zahtev koji se svodi na trafiku.
Bitno je voditi racuna i o medjusobnoj kompatibilnosti platformi koje se koriste. Pre svega je bitna kompatibilnost na nivou podataka ali je dobro ostvariti i aplikativnu kompatibilnost u smislu da ako se radi neka obrada podataka a ta obrada je porebna na obe platforme, valjalo bi da isti kod uvek radi taj posao. Mnogo je nezgodno odrzavati program u kome na dva mesta, dve razlicite procedure rade isti posao.
Kao idealnu platformu za razvoj zamisljam nesto sto se sastoji iz tri platforme:
- jedna, koja veoma lici na mesavinu FoxPro-a i Delphi-ja, sluzila bi za razvoj desktop verzije. Njene karakteristike su: odlicne mogucnosti razvoja korisnickog interfejsa, brz i efikasan pristup bazama, podrska za SQL servere, mogucnost rada sa tabelama u lokalnom sistemu datoteka, ravijen programski jezik, lak za ucenje, kao i otvorenost za prosirenje kako razvojem biblioteka u okviru tog jezika, tako i koriscenjem eksternih biblioteka. Apliakcija bi trebalo da bude viseslojna i modularna.
- druga, SQL server dobrih karakteristika, sa naprednom podrskom za serverske procedure, jednostavan za odrzavanje
- treca, web platforma, nista bolja nego sto je recimo PHP u kombinaciji sa Apache-om
Ne bih uslovljavao da sve tri platforme moraju da rade na istom OS, ali ni da jedna platforma moze da se korsiti na vise OS. To, da jedna alikacija radi na vise OS uvek predstavlja debelo ogranicenje koje za racunvodstvenu apliakciju nije prihvatljivo. Prioritet aplikacije je da se posao obavlja brzo, kvalitetno i sigurno i tome mora biti sve podredjeno.