Java, C#...
nije za script jezike

ne razumem ovo sta je linaja komandi kao Excel


za AoP

Zasto? Ima odlicnih programa za knjigovodstvo napisanih skript jezicima.

pctel, na forum se odnosilo, ne na jezike..malo sam razbacao, desava se
ja sam predlozio C# ili Java-u obzirom da oce da radi na Windows-u

Ako bi postojali odlicni programi za knjigovodjstvo napisani u Assebly-u, da li bi to znacilo da je on dobar jezik za tu vrstu programa?

To sto oni postoje govori da je u skript jezicima moguce praviti ih, ne da su skript jezici obavezno i dobri za to.

za malu aplikaciju Access i VBA. za nešto ozbiljnije pretpostavljam .net ili Java uz neki DBMS.

Veb aplikacija za knjigovodstvo više uopšte nije loša ideja. A tu su skript jezici u najmanju ruku ravnopravni sa Javom i .NET-om.

web nije baš idealna platforma za knjigovodstvene aplikacije. razmisli
samo kako bi napravio funkcionalan interfejs u browseru i koliko bi
javascript-a trebalo za tako nešto.

Ne znam kako ti zamisljas "funkcionalan interfejs" za knjigovodstvo, ali tu nema nista izuzev polja za unos teksta, a to moze da se uradi maltene bez imalo skripta. Ovaj sajt elitesecurity ima otprilike slicnu strukturu i elemente kakve treba da ima knjigovodstvena aplikacija.

Danas u Srbiji nema vece kompjuterske firme koja u manjoj ili vecoj meri nema knjigovodstvenu aplikaciju uradjenu u nekom od skript jezika. To meni sada omogucuje da odem na sajt nekog od svojih dobavljaca, da vidim koliko kosta komponenta koja mi treba i koliko komada je raspolozivo, da narucim, da se automatski skinu sa stanja, da se meni proveri jesam li izmirio sva prethodna dugovanja, da mi se generise predracun i da mi se isti posalje na email. Takodje, obicno mogu da vidim sta mi je sa reklamacijama i koliko jos imam garancije na kupljene uredjaje. To bez skript jezika tesko da moze da se napravi. Upravo o tome pricam, to je buducnost koja ce iz kompjuterskih firmi stici i u sve ostale firme. Ako neko u to ne veruju i nece to da prihvati, to je u redu, svako ima puno pravo da sam bira svoju buducnost, ali, kad dodje pocetnik zainteresovan za knjigovodstveni softver, ja se osecam obaveznim da ga upoznam sa trendovima u toj oblasti i da ga upozorim da ne uzima zdravo za gotovo izjave tamo nekih da su script jezici bezveze i da mu to u zivotu nece trebati. Moj savet je upravo suprotan, oni koji imaju iskustva sa pisanjem aplikativnog softvera mogu da ostanu na tome, moci ce jos relativno dugo da se zivi od toga, a oni koji tek pocinju bi trebalo najozbiljnije da razmisle o usmeravanju ka skript jezicima - to je brze i lakse, a verovatno vec u ovom trenutku potrebnije, o buducnosti da i ne govorimo.

Evo razmišljam... I još malo razmišljam... I opet tvrdim da je sasvim ok.

Razvoj veb aplikacija je u poslednjih par godina strašno napredovao, JS biblioteke su standardizovane, ima dosta dobrih frejmvorka, broadband se raširio, itd itd.

Ilustracije radi, pogledajte tutorijal o korišćenju AJAX-a iz Railsa:

http://www.onlamp.com/pub/a/onlamp/2005/06/09/rails_ajax.html

Ni red javascripta. A tutorijal od pre 3 godine.

da li su skript jezici bezveze ili ne, nije ovde tema. uostalom, ja to
nisam ni rekao.

taj primer koji navodi pctel je webshop, ne računovodstveni program.
računovodstveni (i knjigovodstveni) programi ipak imaju drugačiji
model unosa podataka, jer se mnogo više stvari mora uneti tastaturom,
a ne preko hiperlinkova. često se podaci unose u tabelarne forme sa
master-detail vezama, interfejs je složeniji itd. sve je to moguće
napraviti i u JS-u. ali koliko vremena treba da se napravi, na primer,
forma za unos faktura i stavki u HTML/JS, a koliko u Javi ili čak
Access-u? dodaj na to toolbar-ove, popup menije, povezane forme, MDI
interfejs i zakopaćeš se u JavaScript-u. ako za primer web aplikacije
koja omogućava lak unos u tabelarne forme uzmemo Google Spreadsheets
(dajte i druge primere), nisam baš siguran da će neko ko razvija
računovodstveni program želeti da se bakće sa JavaScript-om potrebnim
da se takva aplikacija potera. da ne pričam o brzini izvršavanja koda
u browseru naspram stand alone (klijent) aplikacije koja ni na
modernim računarima nije zanemarljiva.

sve je to moguće napraviti u JS-u da radi, ali mislim da rezultat nije
vredan utrošenog vremena.

Ne bih se slozio. Bilo kako bilo, jasno ti je da bi napravio takav softverski proizvod MORAS poznavati baze podataka i skript jezike, a ako znas jos nesto onda to MOZES da primenis. Znaci, to sto ti kazes webshop je jedno a knjigovodstvena aplikacija drugo, to je sada sve sada jedna celina. Mislim, prodaju se jos uvek knjigovodstvene aplikacije u fortranu, maloj prodavnici u nekom selu moci ces bez problema da prodas aplikaciju u C++ za 20 godina, ali, za firmu koja hoce da ima poslovnu jedinicu u svakom gradu, koaj hoce da omoguci kupovinu putem web interfejsa a u perspektivi hoce potpunu funkciopnalnost za svakog radnika putem mobilnog telefona, resenje se namece samo. Sve to sto ja pricam sada deluje kao vrhunska tehnologija koju ce se mali broj firmi usuditi da trazi, ali, razmislite da li je tako i da li ce jos dugo biti tako.


Ne razumem primedbu o utrosenom vremenu. Recimo, ti si programer, utrosis mnogo vremena za nesto i onda, sta, postajes astronaut i nista od rezultata prethodnog rada ne mozes da primenis u svom novom zanimanju? Za bilo koju tehnologiju covek da se opredeli u pocetku ce trositi mnogo vremena a kako vreme bude prolazilo sve manje i manje. Izuzev, naravno, ako mu je posao programera privremeni a krajnji cilj mu je da postane astronaut.

Eto, svako je naveo prednosti jedne i druge tehnologije, koje evidentno postoje. Jasno je - sto manja firma, to je za nju pogodnija standalone aplikacija, sto veca, to su pogodnija skript resenja. Sada svako moze da sedne i razmisli kakve ce te firme biti ovde za 10 godina. Sto se mene tice, ovih manjih je iz godine u godinu manje. Nema vise malih prodavnica, tu su hipermarketi a ako je poneka i ostala, opet je deo velikog sistema. Nema vise malih kompjuterskih firmi, nekadasnje su ili postale deo velikih lanaca, ili pokazuju tendencije ka gasenju. One male kioske, agencije i slicno ne racunamo, oni nemaju obavezu vodjenja knjiga.

Nekada su standalone aplikacije bile nesto sto se podrazumeva, danas su skript resenja i standalone aplikacije otprilike podjednako zastupljene, a kako ce biti u buducnosti, svako neka sam pretpostavi.

Jos da cujem da se script jezici zameniti i ERP resenja, pa da idem u penziju :-). Salim se, mozda bi mogao preko scripta da se napravi program za neku malu STR, ali za ozbiljnu kompaniju to ne dolazi u obzir.

već sam napisao: razmisli malo koliko sati treba utrošiti za razvoj
pomenutog intefejsa u JavaScriptu, a koliko u Javi, .Net ili čak
Access-u. mislim da ta razlika vremena može i pametnije da se
iskoristi nego na budženje JS-a. takođe, nisu script jezici jedina
alternativa stand alone aplikacijama. klijent/server može da se pravi
i u pomenutim jezicima (između ostalih).

uostalom, daj mi primere knjigovodstvenih/računovodstvenih aplikacija
čiji je interfejs pisan u HTML/JS, pa da vidimo na šta to liči.

Po mom misljenju, za takve aplikacije je bitniji RAD nego izbor samog jezika.

.Net ili pak stari dobri VCL ...

Ma ono oko cega se vi sporite su web i destop applikacije. Sasvim je svejedno u cemu su pisane. Vremenom ce na kraju vecina data centric aplikacija da postane web orijentisana, upravo ovo sto pctel prica, dal' ce to biti skript jezici ili nesto drugo manje je bitno, bitno je za programere a za korisnike ne. Trziste ce na kraju zahtevati da iole ozbiljniji (danasnji desktop) program postane "web aware". To se vec polako radi i u buducnosti ce biti sve veca tendencija, pa cak i ERP, samo sto ce trebati vremena

mile75, sta podrazumevas pod linijom komandi kao u Excelu?


dosta framework-ova/biblioteka/API-ja/sta-god ima AJAX i web fazone koji dosta olaksavaju izradu web resenja + moguce je praviti viseslojna resenja :D
vec sada ERP-ovi imaju web mogucnosti (npr, na sap.com se spominje nesto za CRM http://www.sap.com/smallbusiness/solutions/overview/features.epx ) ili npr http://en.wikipedia.org/wiki/SAP_Web_Application_Server)


_{[Ovu poruku je menjao momsab dana 23.04.2008. u 23:50 GMT+1]}

I MVC je RAD.

a sta to, sem obima, razlikuje STR od ozbiljne kompanije? koji to deo ERP-a jedne velike kompanije ne bi mogao da se realizuje istom tehnologijom kojom bi se to uradilo za STR?

kao sto je ves receno, pored svih sad vec zrelih biblioteka i okruzenja, ja ne vidim problem.

sta bi rekao pre par godina kad bi ti neko pomenuo spreadsheet na web-u? a eto njega tu...

Pricamo o tehnologiji a ne o interfejsu. Kao sto rekoh, ERP-ovi rade preko WEB interfejsa, ali nisu uradjeni u script jezicima. Pretpostavljam da su ljudi koji su radili na razvoju tih sistema, razmisljali o problemima komunikacije, sinhronizacije i jos mnogo cemu pa su se odlucili da ipak ne koriste script jezike. Kao sto je neko pomenuo, ako ces imati pristup sistemu iz 15 razlicitih gradova, neka promena u poslovnim procesima ne bi mogla brzo i efikasno da se odradi preko script jezika. Moglo bi ukoliko neko misli da je dovoljno imati jedan web server i samo promeniti taj deo, ali u praksi to nije tako.

Hoćeš da kažeš da je pravljenje izmene lakše kad, pored deploymenta, imaš i dodatni korak bildovanja?

I tvrdiš da skript rešenja ne mogu da se distribuiraju na više veb servera?

:D

Upravo suprotno - kad se koriste skript jezici sve promene su trenutne i to je jedna od bitnih prednosti.


Nije sporno, ali ja bih ipak bacio pogled par godina unapred. Danas je neka prosecna internet veza u Srbiji 128kbps, a za 3 godine ocekujem da to bude reda velicine 50x brze. Upravo je to trenutak kada ce se sa nekih softverskih resenja masovno preci na neka druga. To su moje pretpostavke zasnovane na iskustvu i podacima. Neko ce iskopati ovu temu tamo 2011 godine pa nek napise jesam li bio u pravu. Nema potrebe da se sad ubedjujemo da li ce biti tako ili nece, dovoljno je da oni koji prave prve programerske korake budu svesni te mogucnosti.

Pa napolju vec postoji broadband tog opsega pa ljudi ne trce masovno na web aplikacije, mada ima izuzetaka. Mislim, zakacili ste se oko potpuno pogresne rasprave i mnogo ste iskljucivi, svi odreda. Programerske tehnike i tehnologije su toliko uznapredovale da apsolutno nema potrebe za tom iskljucivoscu, i resenje treba da se odabere shodno primeni u odgovarajucem scenariju. U krajnjoj liniji nigde ne postoji prepreka da se napravi vise opcija i standalone i web kanal koji idu na zajednicki business/data layer i primenjuju se na razlicite segmente kompanije.

Ako se ne varam ovo je treca iteracija "push"-a ka web based biznis aplikacijama od kad je web nastao, i ovaj put nema apsolutno nikakve veze sa tehnologijom koliko ima sa "poslovnom politikom". Ceo IT governance je sad u rukama tehnicki polupismenih ljudi koji sebe nazivaju "Risk managment" grupa i danas dobiti od te grupe odobrenje da instaliras standalone aplikaciju na citiram "managed desktop" u firmi zahteva monumentalno epohalni proces. Primera radi u banci u kojoj smo radili razvoj neke benigne aplikacije koja i nema veze sa njihovim core poslovanjem (aplikacija prati stock opcije i splitove radnika za HR), CIO i njegova banda su nam dali da popunimo "Risk registar", maleni papirni dokument od 150 Letter stranica. A posto za web aplikaciju i opet citiram "deployment URL-a na managed desktop" bio potreban Risk registar od samo 50 stranica mi smo aplikaciju uradili kao intranet web aplikaciju da se be bi smarali sa birokratama. Znaci jezik i platforma nisu imali nikakve veze sa tom odlukom. I to ce sad tako ici i funkcionisati dok otpor RMu ne postane mainstream i onda ce nova zamena na desktop aplikacije, pa ce onda malo kasnije opet na web, i tako u krug. Ako niste primetili to se desava vec godinama .

Pa može da upotrebi Adobe AIR ili Flex
U firmi za kojoj radim, razvija se komplikovan CRM i to baš u Flex

I ti ga pretera. Čovek pita za računovodstvene aplikacije, verovatno poput milion postojećih za mala i srednja preduzeća na domaćem tržištu. To (srećom) nije ni čulo za risk menadžment.

A drugo, rasprava i nije veb vs. desktop rešenje, već da li je veb (skripting) rešenje uopšte izvodljivo za tu namenu, a mi neki tvrdimo da jeste.

Naravno da jeste, samo je pctel naveo skroz pogresan razlog za to.

Ako nije web vs desktop, onda script jezici nemaju sta da traze u ovoj prici. Voleo bi da vidim koja su to resenja u script jezicima koja mogu da pariraju ostalim resenjima. Script jezici se uglavnom koriste za web resenja, bar koliko je meni poznato, za desktop tu su kompajleri i gomile biblioteka i tu script jezici skoro da nemaju sta da traze.

Hm, zar su biblioteke ograničene samo za kompajlirane programske jezike? :)

Nisu, ali su kvalitetnije za kompajlere, iz prostog razloga sto su biblioteke za kompajlere "blize" samom sistemu na kome se izvrsavaju, sto znaci da ces imati brzi odziv i bolju kontrolu.

Pa to što pričaš se ne odnosi samo na biblioteke već generalno na kod, a sa današnjim performansama hardvera taj odziv je i po malo diskutabilna stvar :) bilo nekad, sad se pripoveda :) ovo za bolju kontrolu mi s druge strane baš nije jasno :)

Nisi me razumeo. Hteo sam da kažem da ja ne zagovaram jedno naspram drugog, već zagovaram tezu da obe platforme ravnopravno mogu da se koriste za izradu rač. aplikacija, svaka ima svoje prednosti, ali se prevlast lagano seli na veb.

BTW, biblioteke za kompajlere su kvalitetnije zato što su bliže hardveru? Šta sve neću čuti...

Pre nego sto nastavimo diskusiju trebalo bi konkretno da se napise koji su to script jezici na koje se odnosi. Ja sam prvenstveno mislio na javascript. Ti u javasricptu ne mozes da pustis neki proces na novi thread (bar ja ne znam) i tako dobijes bolji odziv aplikacije, na ovu vrstu kontrole sam mislio, isto tako i memorija, u .NET imas GC koji je zaduzen za ciscenje, ali imas i kontrolu koji objekat treba da "zivi" a koji ne, tako sto ces se pridrzavati dispose patterna i cistiti objekte za sobom a za C++ da ne pricam. Uglavnom, kontrola resursa je sto se ide ka nekim "visljim jezicima" manja, dok u ovim "nizim" veca.

ja mislim da niko zdrav ne bi ni pomislio da radi tako nesto u JS.

pricamo o server-side skript jezicima - php, ruby, perl... a JS bi tu mogao da bude element koji bi doprinosio vecoj funkcionalnosti interfejsa.

Ovo za BTW - OK, trebao sam staviti navodnike. Mislio sam kvalitetnije u smislu jer imas vecu kontrolu, ne da li su bolje pisane i sta li vec...

Sto se tice teme, jasno mi je sta hoces da kazes, ali moja poenta je upravo ta da u svetu desktop aplikacija script jezici nemaju sta da traze jer isto to sa kompajliranim jezcima ce se lakse namestiti ako ne lakse, onda bar kavalitetnije iz razloga koje sam vec naveo.

Pa, opet netačno...

Što se kaže, "odma, da ne gledam" mogu da ti navedem desktop aplikaciju urađenu u skript jeziku (python) koju koristim bukvalno svakodnevno - mp3 plejer Exaile. A siguran sam da koristim još par njih bez da sam provalio da nisu kompajlirane aplikacije.

Ajde da ne zamajavamo narod, proguglaj malo šta se od biblioteka nudi za skript jezike tipa Perla, Pythona i Ruby-ja.

wxWindows (preko SPE ili Boa Constructor RAD alata) + SQLAlchemy + PostgreSQL + Python je sveta četvorka :)
Tu bi jedan skript jezik odvalio sve ostale po svim stavkama.

@jablan

OK, u pravu si, ja sam ciljao na ove script jezike koji se koriste u web resenjima, (vbscript, javascript, PHP) to mi je bila prva asocijacija i verujem da je vecina na to mislila. Sto se tice ovih script jezika koje si naveo (inace mislim da je "skript jezici" nesrecan naziv, bolje bi bilo static i dynamic u zavisnosti sta je) moguce je u njima raditi sasvim kvalitetno, ali tu dolazimo do one price dynamic i static jezici, koja je vec bila vodjena negde na .NET forumu. Ja cu uvek biti zagovornik static ideje, jer mislim da su razlike izmedju dinamickih i statickih jezika u tome da dinamicki jezici nisu dovoljno "razvijeni", u smislu da one mogucnosti koje pruzaju su u sadasnjem vremenu tesko implementirajuce na statickom nivou, dok neke osobine nece nikad moci biti implementirane, a to je onaj "nedeterminizam", gde ti mozes upisati bilo sta nad jednim objektom i ako to nesto postoji onda se to izvrsi, a ako ne onda da dobijes runtime gresku.



Ne znam, taj pojam script mi je nejasan, sta se sve pod tim podrazumeva i to bi trebalo prodiskutovati. Da li su script jezici podpadaju pod General Purpose Languages ili Domain Specific Languages, ili dynamic ili static type system, kako ih prepoznati?

Pretpostavljam da vecina ovde pod skript jezikom podrazumeva onaj koji se interpretrira.

Upravo ono sto treba uraditi je izbeci formiranje ovako uskih gledista kod novih korisnika. Prvo, jasno je da se obe tehnologije uspesno koriste, pa meni ustvari nije jasno zasto se ta cinjenica tako uporno pokusava sakriti. Drugo je pitanje kakve su nase vizije razvoja situacije. Trece, jasno je da nema ostalih resenja koja mogu da pariraju skript jezicima u nekim oblastima primene. Cetvrto, knjigovodstvo je prestalo da bude desktop aplikacija i to je ono oko cega se izgleda razilazimo. Knjigovodstvo podrazumeva uglavnom razmenu podataka izmedju banaka, kupaca, dobavljaca, poreskih institucija i razlicitih sektora preduzeca. To se nekada radilo tako sto jedan ukuca podatke u racunar, pa odstampa, pa spakuje u kovertu, pa posalje drugom, pa drugi ukuca u racunar, pa snimi. Vecim delom se to jos uvek radi tako, ali ne verujem da ce jos decenijama moci tako. Razliciti informacioni sistemi ce sve vise morati da komuniciraju, a ja stvarno ne vidim mogucnost da se to brze i bolje uradi nego primenom skript resenja.

Jedna od vecih domacih kompjuterskih firmi ima informacioni sistem potpuno uradjen u PHP-u. Taj informacioni sistem funkcionise vec nekoliko godina i evoluira iz dana u dan a da korisnici nikada nisu imali pauzu u radu zbog instalacije necega. Sve sto im treba je bilo kakav kompjuter sa bilo kakvim operativnim sistemom koji ima web browser. Za mene ce prva sledeca velika stvar u softverskoj industriji biti kada imam neki problem sa kompjuterom, ja samo donesem novi, ukljucim i nastavim gde sam stao, a kad odem sa radnog mesta i setim se da nesto nisam uradio, uzmem mobilni telefon pa to zavrsim. Sada takvih resenja nema, ali to je pitanje vremena. A, kada ih bude, sta mislite koliko ce biti korisnika koji ce reci "sta ce to meni, ja volim da sednem, instaliram aplikaciju, pola sata podesavam parametre pa tek onda pocnem sa radom"? Po mom misljenju, jako malo. Mislim, nebitno, mozda ce ih biti i mnogo, ali, nek svako ko pocinje sa programiranjem bude svestan svih eventualnih razvoja situacije, razmisli o tome pa nek donese sopstveni zakljucak.

Nista od ovoga ne bih napisao da neko na pocetku nije rekao "script jezici nemaju tu sta da traze". Trebalo bi svima da bude jasno da imaju, to je sve.

Kojim oblastima primene?

pctel to sto pises ja sam se cak i u prvoj poruci na ovoj temi slozio, ali onog momenta kada je Jablan spomenuo da ovo nije poenta izmedju web i desktop resenja ja se nisam slozio. Jer to sto ti ocekujes je onda "web" resenje i meni je to jasno i cak sta vise sam ubedjen da je to buducnosti i skript jezici su tu nasli primenu i danas se zovu "script jezici" a za nekoliko godina tu funkcionalnost (da upravo tu gde spominjes zamenu starog za novim kompjuterom i sve isto) ce mozda obavljati bas staticki kompajlirani jezici, ili interpreteri (tek ovo sto je diskutabilno). To sam zeleo da istaknem da to sto ti trazis nema veze u cemu je implementirano, jer to je odredjena vrsta funkcionalnosti, a to da li je skript ili nesto trece je stvar implementacije u kojoj se pravi ta funkcionalnost.

@Shadowed
.NET bi mogao da nazoves interpreter, jer se ne izvrsava na masinskom jeziku nego preko IL-a se kompajlira u assembler pa iz assemblera na masinski jezik, mada to vec znas, tako da je i interpretacija sirok pojam.

Oblastima primene koje zahtevaju razmenu informacija sa velikim brojem korisnika i/ili velikim brojem razlicitih informacionih sistema.


Pa to. Nadam se da mozemo da se slozimo - mozda ce biti ovako, mozda onako, treba ukazati na sve aspekte i mogucnosti a ne da se jedna tehnologija tek tako otpise kako je ucinjeno na pocetku teme.

negyxo, a htedoh reci "interpretira iz izvornog koda", al' skratih :)

pctel, a da batalis stvari u koje se ne razumes? Ili bar pitaj umesto da tvrdis. To sto ti pricas je web vs. desktop ne script vs. kompajliran program. Kapiras? Web != script jezik.

Ovo meni bode oci, mada jasno mi je sta hoces da kazes i tvoj stav kao korisnika je sasvim opravdan. Ja prvo polazim od sebe, recimo, ne treba mi banka koja ne moze da mi obezbedi online uvid mojih primanja, neke transakcije itd. Mene kao korisnika treba da zanima to, znaci funkcionalnost, a ne tehnologija kako je to implementirano, ako je funkcionalnost bitna, a jeste, onda se bira sve sto ce moci da zadovolji tu funkcionalnost, znaci nije bitna tehnologija. Ako u onom slucaju gde je Jablan rekao da ovo nema veze sa web i desktop aplikacijama, onda to znaci da ostaju desktop aplikacije, jer nije bitna ta funkcionalonst da li ti mozes online nesto da obavis ili ne, nego da je bitna tehnologija, gde se ja ne mogu sloziti, i to samo ako su script jezici dynamic jezici u kombinaciji sa (DSL)Domain Specific jezicima jer za velike projekte bi bas voleo da vidim kako se to radi u dynamic jezicima, gde jedna pogresna rec moze da izazove glavobolju od tri neispavane noci ili ako u slucaju da DSL onda ne mozes da uradis odredjenu funkcinalnost jer je to ipak domenski jezik, tj. skript. Ali o ovome tek kad raspravimo sta je to skript jezik. Inace kos dodatni razlog zasto ne verujem zasto mogu sadasnji skript jezici da zamene tek tako kompajliranje jezike jer ne verujem da je pola industrije neobavesteno, jer koliko vidim ipak ih je vise koji rade sa statickim kompajliranim jezicima za iole malo veci program.

Access, vb, Delphi, .Net, Java, FoxPro, Clipper, (Cobol???)

Ništa mi niste jasni sa tim "skript jezicima za desktop", može li par primera i koja gotova rešenja postoje.
Nešto sumnjam da su "pogodna", barem ne sledećih 5-10 godina.

Evo ERP-ova u Python-u (koji JESTE skipt jezik): http://www.tinyerp.org/ i http://www.stoq.com.br/index.php?lang=en

Python: pyRacerz
:D

pctel, sto se tice tog povezivanja razlicitih ISova i tako to, za tako nesto se koriste web servisi (mnogo dobra stvar)
ja vise volim web resenja ko su dobro podrzana u vecini aktuelnih browsera
inace prednost dajem web resenju, ma konzolnoj, sao da ne mora da se posebno instalira

Eh sad.. Ako se radi o ozbiljnijem softveru, valjda postoje testovi koji ce svakako otkriti ovakvu gresku, tako da.. A ako nemamo testove, onda smo sjebani svakako, pa ti neće mnogo pomoći ovaj ili onaj jezik.

I da, čini mi se da će C# u sledećoj verziji (4.0) još dalje da ode sa preuzimanjem fazona iz dinamičkih jezika pa će biti moguće napisati i kod kao ovaj gore, ako se dobro sećam šta sam nedavno čitao..

Degojs, ima to public, sta ce biti (bi trebalo biti) u sledecem C#/VB.NET-u?

Nešto možeš da vidiš ovde http://blogs.msdn.com/charlie/...e/2008/01/25/future-focus.aspx

Da ne bude zabune, obrati pažnju da kažu da "the team is currently considering adding the keyword dynamic to the language.."

Vidim ja opet cemo doci do price static i dynamic.

@degojs
Za C# mi je dosta jasan "future direction", bar mislim, i ono sto je odlika C# je da je i dalje static type a da ima dinamicne osobine, o ovome, kao sto sam vec rekao, je bilo reci na .NET forumu, tako da ne bi mnogo da ponavljam. To "dynamic" se misli na osobine koje poseduju dynamic jezici ali i dalje je static type sistem upitanju. Uostalom, onda bi mogli da kazemo da je C# 3.0 skript jezik, ima dinamicke osobine (recimo lambda, type infirence, anonymous types.. sve to cini da je jezik "dinamicniji") a i prevodi se u IL, koji se interpretira, doduse preko JIT samo jednom tokom izvrsavanja i to u blokovima.

I da, to za testove je jako interesantno, ako ti budes pisao toliko testova, onda si napisao i sam program samo kroz testove i plus sam program sto je jos vise informacija, to je fakin informaciona entropija, protiv koje se ne moze. Probacu da nadjem article na Joel on Software, on je to veoma lepo napisao.

Evo ga http://www.joelonsoftware.com/items/2007/12/03.html

Kako tece diskusija nisam siguran da je covek dobio odgovor na svoje pitanje.

Za pocetak pogledaj Access, imas knjiga i literature koliko hoces. Sledece ti je Delfi, mozda i bolje, ali ne tako rasireno.

Zasto Access?. U knjigovodstvu imas mnogo podataka pa je osnova za to neka baza. Tamo imas sve elemente, kreiranje i odzavanje tabela, forme za unos, report za izvestaje, lako se kreira meni. A naucices SQL koji je danas standard za baze.

IL se ne interpretira, tacka. Da ne zalazimo mnogo u to, interpretacija se zasniva na direktnom izvrsavanju meta DOMa (koji je nastao parsiranjem skript jezika) kroz blokove koda samog interpretera. Iako je teorijski moguce interpretirati IL, .NET to ne radi i IL se prevodi u native code platforme na kojoj se izvrsava. Jedina razlika izmedju recimo C++ i C# u tom pogledu je da se c# aplikacija bukvalno kompajlira dva puta pre izvrsavanja.

Dynamic u C# nije nista novo i sasvim je ocekivano i zapravo nije nista drugo do late binding-a, kao sto negyxo rece, rezultovani IL je i dalje strong typed samo sto pozivi idu kroz reflection kompajlerskom magijom (slicno kao sto se LINQ svodi na pozivanje prefabrikovanih ekstenzija nad IEnumerable<T>). Nema tu nista scriptable, jedina slicnost je sto ces sad i u C# moci da ne platis na mostu nego kasnije na cupriji kroz runtime type errors.


U principu nemam nista protiv script jezika, niti interpretacije, ako je ista tacno to je da performanse zaista vise ne igraju kriticnu ulogu u izradi ERP resenja sa svim ovim novim shiny hardverom koji danas moze da se kupi. Dakle, ja se slazem da je moguce i izvodljivo raditi ERP u skript jezicima, samo sto to nikad ne bih radio u praksi iz prostog razloga nedostatka strong typinga. Trebalo je dosta vremena da prodje da strong typing evoluira do te mere da mozes da ga koristis u praksi bez da budes C++ guru i ja sam sasvim zadovoljan onim sto imam kroz .NET i iskreno mi se ne vraca nazad na vreme skrivenih runtime gresaka koji nemaju veze sa poslovnom logikom. Naravno, nivo tolerancije je razlicit kod razlicitih ljudi i neki ljudi vole da debaguju skript jezike trazeci te greske (neki cak u tome vide job security), ali kad dodjes u poziciju da shefujes ekipici programera od kojih nisu svi seniori onda uzimas svaku pomoc koja ti je na raspolaganju, izmedju ostalog mogucnost strong typed kompajlera da spreci te greske tokom samog razvoja. Testiranje je naravno i dalje potrebno, ali je sad fokusirano na testiranje poslovne logike a ne testiranje toga da li je programer A promenio svoju klasu C bez da programer B to zna.

Ajde da se i ja ukljucim. Ja sam takav program odradio u VB5, koji je naravno prvazidjen odavno, em sto su kontrole ruzne, em sto je jako nestabilan: moras da stvoris naviku da snimas program svakih pet minuta, inace stalno pises iz pocetka sto je bas frustrirajuce. Inace, mislim da ne mozes mnogo da pogresis koji god jezik da izaberes, ali moras raditi. Ja sam definitivno odlucio da predjem na python

Ma da, mogu sad i ja da kazem da ako ti za svaku promenjivu pises kog je tipa i slicno, to je takodje konfuzija i slicno. Mislim - za svaku promenjivu moras da "pratis" kog je tipa, itd?? :D

Osim toga, TDD (test driven dev) je, po meni, sasvim OK, sigurno imamo razlicita iskustva.

Pricas o nekoj sigurnosti koju strongly typed jezici pruzaju i kako je to bolje za ozbiljan softver, a onda kao - kome trebaju testovi? Eh.



Pa necemo bas ni da pisemo test za to. Ali ce test to indirekto da proveri, itd.

_{[Ovu poruku je menjao degojs dana 25.04.2008. u 15:09 GMT+1]}

@mmix
Sve se slazem sem ovog prvog. Nije da sam cepidlaka, ali sam hteo reci da ni .NET kompajleri ne prozvode masinski kode, stoga kao sto ti rece, kompajlira se dva puta, ja sam tu podvukao paralelu sa onim sto recimo javascript radi, znam da nije isto ali na kraju da bi pokrenuo i jedan i drugi kod treba ti neki "kompajler" koji ce to da prebaci. Moracu da pogledam definicuju intrpretera.

Nisam ni rekao drugacije (da nije static type u pitanju). Ali ocigledno da ima sve vise osobina dynamic jezika, pa sad.. neka zakljuci ko sta hoce.

Pa s obzirom da sad imas type inference ne moras da vodis racuna, na prvi pogled bice to odlicno, dok jednom posle 200 klasa ne skontas da je tip koji si dobio u jednoj kljucnoj promenljivi float a tebi trebao decimal.

Isto, TDD je OK, ali da ne ulazimo u tu pricu. Mislim da nisi shvatio ponetu onoga sto je Joel napisao.

Kako rekoh, testiranje resava te probleme, a ljudi koriste jezike kao Python i slične bez problema tako da jednostavno ne vidim tu ni najmanji problem iz prostog razloga što testovi hvataju takve greške indirektno. Osim toga, to bi bio problem sa C#, a ne verujem da bi Python imao problem tog tipa (evo float, a ja očekujem decimal, šta ćemo sad?).

(Da se razumemo, ja nisam nešto velika pristalica tog što rade sa C#.)



Nisam ni čitao to što si linkovao. Isto tako mislim da ti nisi shvatio moju poentu vezano za testiranje, pa da ti ponovim: testovi hvataju sve takve greške, a ti ako ne pišeš testove onda se svakako zajebavaš, bez obzira koristiš li Python ili Javu.

E samo ovo da odgovorim



Shame on you

Inace ja jesam pristalica toga sto rade sa C#, jer ce mnoge stvari moci mocnije da se urade ako znas kako sa njima da baratas. Recimo, cak sam uveren da ovo sto se radi sa LINQ-om ima da zameni SQL negde u buducnosti, jedino ako MS u medjuvremenu ne pukne

I da jos ovo, ako krenes od samog pocetka da vodis racuna o tipovima onda si izbacio potrebu za pisanjem takvih testova, zato, procitaj onaj link

Ajd i ja za kraj:



Čekaj malo, pa što onda kažeš malopre da:

Prvo kudiš nešto, a onda si pristalica?


Dalje,



Jbga, a ti pročitaj ono što ja pišem na ovoj temi već 5-ti put: testovi tog tipa nisu ni potrebni. Normalni testovi će indirektno, naravno da hoće, da uhvate i takve greške.

Privremeno se iskljucujem iz diskusije, pa u utorak mozemo nastaviti.

Degojs, u tome i jeste zackoljica, sto ti izgleda brkas type system i dinamicke osobine (feature) dinamickih jezika. Te feature se ubacuju strongly typed jezike, sto znaci da je sve isto samo sto su neke jezicke konstrukcije sad mocnije. Evo ti LINQ za primer, recimo zelis nad nekim objektima da dobijes rezultat ali ne u onom obliku u kojem se vec nalazi definicija objekta, nego sasvim neki novi output

Recimo




Bez ovih "dinamickih" osobina ti bi morao da napises negde tvoj novi tip podatka koji bi se sadrzao c.Name, p.Name i p.ID i ovaj where uslov bi morao da napises verovatno preko neke f-je kako bi filtrirarao podatke. Ovde mozes sve add hoc da uradis, ali ce kompajler uraditi potrebnu "logiku" kako ti ne bi to rucno kucao.

Reci mi da se salis. To sto linq ima SQL-like sintaksu ne znaci da ce zameniti SQL. Stavise LINQ uopste nije CLR core .NET tehnologija, to je samo kompajlerska konstrukcija. Probaj da dekompajliras bilo koji metod koji koristi LINQ i videces da LINQ-a tu vise nema i sve se svodi na pozive extension metoda nad IEnumerable interfejsom i isntanciranje anonymous tipova. Jednom recju LINQ je fatamorgana




Ja nesto ocigledno propustam ovde, kako ce izgledati ti tvoji testovi ako u script jeziku ne testiras direktno type validation vec samo poslovnu logiku? Pretpostavljas da ce pozivar da zna koji tip da prosledi i da nikad od toga nece odstupiti? Nece npr ubaciti string sa float brojem u netipizirani prametar metode u kome ocekujes int? To je bas VELIKA pretpostavka. Ti tako mozes samo da istestiras metod pod "pretpostavkom" da ce biti pozvan sa tipom koji ti ocekujes, a znas sta se kaze za "pretpostavke" (doduse na engleskom ), "assumption is the mother of all screwups"

Sa druge strane ako ces da testiras type safety metoda, onda moras da pozoves metod iz testa sa svim mogucim kombinacijama tipova sto je prakticno nemoguce u potpunosti pokriti.

Da se odmah razumemo, ja sam koristio TDD i iako ima nekih zanimljivih aspekata, nisam "kupljen" idejom testiranja kao drajvera razvoja. Kao prvo, TDD zahteva da programeri pisu adekvatne testove i ne prave "krivine" u istim, sto je realan problem u timovima koji imaju tight deadline, kada se prave gomile nedokumentovanih "pretpostavki" o tome sta se "sigurno nikad nece desiti" i eto belaja, prave se nekompletan i nesiguran kod koji prolazi test ali ne radi kad te nepisane pretpostavke nisu zadovoljene i developera za to boli uvo jer je njegov kod prosao njegov sopstveni test. TDD takodje "pretpostavlja" da si ti vec resio type safety problem, sto sa scripted jezicima nije situacija. Samim tim ti testovi ladno prelaze u green fazu iako je testirani kod felerican sa aspekta tipova.

Ne brkam ja ništa. Lepo se vrati na onaj prvi primer koda koji si dao. Hajde da razgovaramo o jednoj stvari, pa kad se dogovorimo da je ovako ili onako onda prelazimo na sledeću. Ovakvo skakanje svaki čas na nešto deseto me baš i ne interesuje, jer više ostavlja utisak da ti izvlačiš nešto drugo svaki put samo ne bi li bio u pravu, a ja više pojma nemam kakve to sad veze ima sa onim na početku, itd.



Pa evo zašto mislim da nije problem, a ti me ispravi ako grešim:

Zašto bi bio problem ako mi proslediš string koji sadrži float umesto int? Pretpostavka je da jezik sam ume da uradi konverziju (string -> broj) ako je potrebno te će pasti na testu jer će rezultat biti pogrešan, a ako ne ume da vrši konverziju (ili je uradi u pogrešnom smeru npr. int -> string pa uradi lepljenje teksta umesto sabiranja), test će da padne još pre ili opet na kraju.

Niti takvo razmišljanje ima smisla.. jednostavno ne mogu ja da napišem sve moguće testove za sve moguće tipove podataka - pa ti možeš uvek da napraviš neki svoj tip i proslediš to kao ulazni parametar. Ali ti ćeš onda da imaš i takav test za svoj kod, koji će onda da padne (jer je moja funkcija pala), itd.

Što se TDDa i testova generealno tiče, sve se slažem, ne kažem da su garant da će sve biti OK, ali šta -- type safe jezici garantuju da će sve biti OK, i to bez ikakvih testova, kako je kolega nešto 'teo da kaže? Ma sigurno. Ne znam samo otkud onoliko test alati i za npr. Javu i C#.. I to još pominje nekakve stotine klasa. Pa lepo bez testova, samo napred, pa da vidimo šta će biti kad se malo ljudstvo na projektu menja i slično. Osim toga, testovi se valjda pišu i iz razloga da bi kasnije neko deseti mogao da uradi izmene negde, potera testove i uveri se da nije polomio nešto drugo usput.


_{[Ovu poruku je menjao degojs dana 25.04.2008. u 22:57 GMT+1]}

Ovo je pitanje koje sam i ja sebi postavljao. Probao novotarije i ostao na kliperu. Brz, jednostavan ne treba mi šestium i radi na 100% sigurnom OS-u. Volim ja ovaj game boy od vindoza, ali to je za igre, net i elektronsko plaćanje... Šalu na stranu, mislim da je web budućnost. Takodje mislim i da je linux i gpl budućnost (možda daleka). http://www.ledgersmb.org/ ili http://www.sql-ledger.com/ Ako pogledamo sa stanovišta kompletne instalacije, gpl knjigovodstveni softver+linux+postgres+perl+apach+net košta mnogo manje od .net+windows+server+++. A radi u svakom browseru, win, lin, mac, dos... Možda treba malo da se pomučiš da ga prilagodiš, ali to je cena besplatnog softvera. Mislim da bi to mogao da bude veliki plus za linux na ovim prostorima u poslovnoj upotrebi. Ja pokušavam.
p.s. Ima li koga voljnog da pripomogne?

Ok, osnovni primer (banalan ali dobar kao primer)



Metod je "validan", test je green, i svi su happy, a Multi(3.5, 3.6) je neispravno. Recimo da je a kolicina prodatog artikla, b cena po artiklu. U bazu ode 3.5 komada sa neizvesnim upisom (mozda ce DB da ga flooruje na 3 ili zaokruzi na 4, sto ne mozes da znas bez da znas kako baza funkcionise i sta DB.Insert radi sa svojim parametrima), u svakom slucaju zapisani iznos a*b nece biti ispravan niti u skladu sa logikom metoda. Naravno, sto kompleksniji metod to kompleksnija i logika i to vise potencijalnih rupa po osnovu type unsafe.



Type safe jezici naravno ne garantuju ispravnost logike kode, ali garantuju ispravnost komunikacije izmedju pozivnog i pozvanog koda, tj preventivno deluju protiv gomile potencijalnih bagova izazvanih nepaznjom i hvataju ih tokom samog kompajliranja. Jedini nacin da u skript jezicima to uradis je da radis validaciju parametara na pocetku metoda, a ako to vec radis, sto jednostavno ne bi koristio type-safe jezik

Inace, mislim da si pomesao moje postove sa negyxovim, ja sam veliki poklonik testiranja i definitivno nisam negirao njegovu korist, samo ne kupujem pricu o TDD, tj o drugom slovu ovog akronima (D - Driven). Testiranje je odlican instrument za ranu detekciju logickih bagova i backward kompatibilnost koda da neko deseti ne bi pokrljao kod, ali testiranje definitivno po meni nije centralni aspekt koji treba da upravlja razvojem i definitivno mi skripi taj "minimalisticki" pristup testovima gde se kod steluje samo da bi prosao test bez obzira na sve ostalo. Pored toga, testiranje odredjenog dela koda treba da radi drugi tim ljudi koji kako bi se izbegao konflik interesa i slabljenje test koda.

Niko ovde ne pomenu Visual FoxPro. Vecina se uhvatila za .NET kao da je resenje za sve. Bice, ali za jedno 2 iteracije kada stigne zadnju verziju Fox-a.
Zasto Fox? Pa on je jedini "Data Centric" programski jezik koji ima svoj lokalni "Cursor" engine, ima svoju bazu podataka, lako se povezuje sa bilo kojom bazom putem vise tehnologija (remote views, cusros adapters, SQL passthrou), RAD je, ima svoj ReportEngine, ima makro substituciju, oop (nasledivanje kao u c-u), vizuelni je alat ...
Covek hoce da pravi knjigovodstveni program a zato mu treba : baza podataka, programski jezik koji ce to najlakse da odradi i omoguci mu najlaksu manipulaciju sa podacima. Nemam nameru da kudim neki drugi jezik ali za to od Fox-a nema boljeg i brzeg. Evo primer, koliko treba linija koda u C# da se povezes sa MSSQL serverom, iscitas tabelu i prikazes je korisniku? Necete verovati a u Fox-u je to 3 linije koda. Dalje vidim da se ovde spominje LINQ kao neko cudo a Fox ga ima skoro od svog pocetka.
NET je super stvar i verovatno je u njemu buducnost ali trenutno, kada su u pitanju baze podataka, ne moze niko da me ubedi da moze da parira Fox-u.

Pozdrav.

@mmix

Hehehe, to sa tipovima podataka u bazi jeste problem - čak sam to i sam napomenuo na jednoj sličnoj raspravi na DPT-u da postoji taj problem sa skript jezicima i bazama :) U takvom slučaju mora da se obrati pažnja, ne sporim.

Evo našao sam:


Mada.. ako znamo da ne znamo :) šta će baza ili DB.Insert tačno da urade, onda ćemo da svoj kod prilagodimo toj situaciji tipa:

DB.Insert( floor(a), b );
return floor(a)*b;

A nisam siguran da to nisu više kao teoretske situacije, pošto se podaci ionako češće proveravaju prilikom unosa, isčitavanja i slično, nego ne.



Inače, takođe da se razumemo, ja preferiram strongly typed jezike, ali ako se koristi testiranje, ne vidim veći problem sa upotrebom ovih drugih.



_{[Ovu poruku je menjao degojs dana 26.04.2008. u 01:46 GMT+1]}

Tebi treba dobar code generator pre nego jezik. U davna vremena clarion je bio najnapredniji
DOS alat za generisanje poslovnih aplikacija ne znam kako je sada. Quick search mi je kazao da
ovaj alat nudi vise opcija za razvoj, (.net win32 exe web/desktop valjda generise i php itd)
a secam se da je aplikacija tog tipa mogla da se napravi bukvalno bez programiranja.
Link sa gugleta : http://www.softvelocity.com/

Pozzz!

Ovo meni zvuci kao "pretpostavka", ona koja preklapa dve kategorije: "ovo ce neko drugi da obezbedi" i "ovo se nikad nece desiti"

Realno, ti si upravo ispravio bug u kodu Multi() metode, ali to je bug koji ti nisi otkrio testiranjem, testovi su prosli ok. Ti si ovaj bug ispravio nakon sto je aplikacija usla u QA fazu ili jos grdje nakon deploymenta kad je metod bio pozvan sa non-int parametrom u simuliranim ili jos grdje proizvodnim uslovima. U tome je problem sa TDDom i skript jezicima, sama type unsafe priroda script jezika ubija TDD.

FoxPro je odličan ali mrtav jezik, zadnja verzija je 9 SP2 i - NEMA DALJE.



Probao sam one ERP-ove od Python-a ali to meni liči kao da se neko dete igralo sa kockicama, bez uvrede.

Ne znam, možda grešim ali koliko je Python skript jezik toliko su i Access i FoxPro (dBase itd.) skript jezici. Mada ih ja nikada nisam tako zvao.

Ako to nisu skript jezici onda: može DEO programa (vezan za Web recimo) da bude urađen u skript jezicima ali za iole ozbiljan program potreban je efikasniji programski jezik, još uvek.

Imam nekoliko godina iskustva u odrzavanju i razvoju knjigovodstvenih aplikacija (Clipper, VB + Access, PHP + MySQL, C# + MSSQL), pa evo nekih mojih iskustava:

1. Knjigovodstvenu aplikaciju tesko mozes napraviti bez baze podataka. Znaci, nauci sto vise mozes o bazama podataka.

2. Svaka aplikacija bi se u grubo mogla razdvojiti na tri sloja - korisnicki interfejs, engine (obrada podataka) i baza podataka; trebao bi da tezis tome da najpre razvijes engine, i da ga sto vise moguce odvojis od interfejsa i baze podataka, odnosno da budu sto nezavisniji, jer ce ti to olaksati sve buduce izmene u aplikaciji, u protivnom na primer jedna sitna izmena u dizajnu interfejsa moze da znaci sate ceprkanja po kodu. Objektno orjentiasni jezici su idealno za to, pitanje je samo koliko je tebi lako da ih naucis i primenis prakticno.

3. Knjigovodje uglavnom koriste numericku tastaturu za unos podataka - ako mozes izbegni upotrebu misa, i smesti sto vise kontrola mozes na numericku tastaturu i u njenu blizinu; ako operater moze jednom rukom bez puno setanja da manipulise celom aplikacijom, a drugom rukom drzi telefonsku slusalicu/soljicu sa kafom/puter kiflicu/novine/itd., moze tvoja aplikacija imati najskrnaviji graficki dizajn i manjak nekih opcija, pa ce opet korisnici teze odabrati neki novi ultra/mega/giga/turbo sljasteci knjigovodstveni sistem, tako da ces godinama lako zadrzati postojece klijente uz sebe. Najbolja preporuka je da izdvojis neko vreme i sedis uz operatere dok rade na unosu podataka, i posmatras ih kako to rade. Tako ces biti siguran da si napravio nesto sto je njima po meri (sto ih manje teras da se prilagodjavaju interfejsu, a sto vise prilagodjavas interfejs njima, to ce oni biti zadovoljniji - naravno, treba uvek imati neku granicu).

4. Prosecan operater unese oko 400 stavki dnevno, sto na godisnjem nivou (uz sve godisnje odmore, drzavne praznike i sl.) iznosi oko 100.000. Ako pravis taj program za nekoga ko na godisnjem nivou ima mnogo manje stavki, mozes ga praviti prakticno u bilo kom programskom jeziku jer je dovoljno da radi na samo jednom racunaru. Naravno, treba da imas na umu i buduce potrebe, odnosno uvecanje obima posla, pa da predvidis na vreme da li ce toj firmi biti potrebno mozda dva ili vise racunara za unos podataka (naravno, na svakih 100.000 stavki racunas po jednog vise operatera odnosno po jedan vise racunar). U tom slucaju treba da se preorjentises na programske jezike koji olaksavaju razvoj mreznih aplikacija (baza "trci" na jednom racunaru, a po jedna kopija tvog programa se instalira na svaki racunar za unos i preko mreze pristupa bazi).

5. Matricni stampaci su jos uvek zakon u knjigovodstvu, a veliki broj novijih laserskih i ink-jet stampaca dolaze iskljucivo sa USB konektorima. Matricni stampaci su prilicno brzi ako im saljes "suv" tekst ("raw data" format), ali ocajno stampaju grafiku, a prednost im je beskonacni papir i virmani na beskonacnom papiru. Neki stariji programski jezici mogu da rade samo sa printerima koji su direktno prikaceni na taj racunar, pa onda moras koristiti razne trikove da bi prevario tvoj softver i naterao ga da koristi mrezni printer. Ako je klijentima bitno da imaju logo firme i slicne kerefeke, onda je tu bolje upotrebiti laserski printer, ali neki stariji programski jezici imaju prilicno losu (ili nikakvu) podrsku za USB, a kod mnogih jeftinih USB printera se tesko softverski kontrolise stampa u "raw data" formatu (ne mogu im se direktno slati komande za promenu velicine fonta, prelom reda i sl.) tako da i o ovome moras voditi racuna prilikom odabira odgovarajuce tehnologije za programiranje.

Ovo su samo neke od stvari na koje treba da obratis paznju, ima naravno jos mnogo toga o cemu ces da saznas kad se konacno bacis na izradu te aplikacije. U ovoj zemlji ima na hiljade programera koji se bave razvojem knjigovodstvenih aplikacija, sto samo po sebi znaci da nije nikakav problem napisati nesto sto moze da odradi taj posao.

Kako to mislis mrtav? Ima zvanicnu podrsku do 2014 god. Nego nece biti verzije 10 sto ne znaci da je mrtav! Drugo a sta je to sto bi verzija 10 mogla da donese u Fox a da on nema ili da ne moze vec da se uradi. Dalje Fox je ono sto se kaze "mature product" znaci kada su u pitanju podaci nema sta ne moze da se uradi u nekoliko linija koda dok u svim ostalim M$ jezicima treba daleko daleko vise.
Stvar je malo drugacija nego sto izgleda. M$ ima svoj "flagship product" kada su u pitanju baze a to je MSSQL server, dalje M$ je firma koja zaraduje novac; iz cega sledi zasto bi M$ gurao Fox kada se na njemu zaraduje mnogo manje para nego na MSSQL serveru (Fox platis 650 dolara i mozes da distriburas bazu koliko god hoces na koliko racunara god hoces, MSSQL se prodaje po licencama). M$ interesuje samo profit. Nigde u M$ neces naci da ce se C# razvijati u narednih 20 godina (recimo), jednostavno ako donosi profit ima perspektivu ako ne donosi ode u penziju.

Ovo je apsolutno tacno i ne samo u knjigovodstvu nego i u proizvodnji. Uzmimo primer Ikarbus-a gde je njima sastavnica : 1 Autobus, a on ima preko 5000 pozicija. Kada se taj nalog lansira i treba da stampa svaki laser bi se zapalio, dok matricni to kulturno odstampa bez problema. Ali kada je u pitanju ostala stampa samo laser (u fox-u imas odlican reportengine, mogucnost dodavanja samog koda u svaki segment stampe ...)

Pa pazi, i Cobol je mature product pa ga ne bih koristio
A i poredjenje sa MSSQLom ti nije dobro rezonski. Za potrebu koja matchuje i prevazilazi FoxPro, MSSQL Express moze da se koristi i ne kosta nista. Nije MSSQL taj koji je konkurencija Foxu, Access je konkurencija Fox-u i zbog Access-a MS ubija Fox.


Al kad vec pomenuste raw printing na matricne stampace, gde je tu sad scriptable web resenje bas me interesuje kako bi izbacili raw paket podataka na loklani LPT port korisnika iz javascript-a u html strani bez instalacije pomocnog COM objekta.

Mali offtopic, Laseri vise nisu tako "smotani" ko pre, postoje sasvim OK continous form printeri.
Google: "Continuous Form Laser Printers"

Samo da dodam, matricni stampaci se i dalje primarno koriste kod nas najvise zbog "drugog primerka" posto matricni primenjuje |silu" nad karbonizovanim papirom sto laser nikad nece moci da postigne.

Upravo. Matrični štampači su nezamenljivi ne samo zbog "drugog" nego i "šestog" primerka. Postoje izvanredno brzi matrični štampači koji i nemaju neki drugi mod sem DRAFTa i jedini cilj im je brzina štampe i otiskivanje u više primeraka odjednom.

Jednom sam probao da odštampam jednu EXCEL stranicu tim štampačem, što je uzelo celih 11 minuta (jedanaest minuta) uz užasne zvuke i cepanje trake (ribona).

Pazi da ne dobijes "mig na levo oko"

Sto se tice Cobol-a bas si preterao jer danas odraditi nesto u Cobolu ...... necu da komentarisem da se neko nebi nasao uvreden.
Gde moze Access da bude konkurencija Fox-u? Ti ocigledno nisi nesto radio sa Fox-om kada tako nesto mozes da tvrdis. Access je samo mala bazica ciji page-ovi rasu eksponencijalno. Ako hoces nesto da odradis moras da koristis VBA sto se ne moze smatrati nimalo ozbiljno zar ne? Dalje MSSQL Express (ali i Oracle Express) je nastao kao posledica ekspanzije opensource SQL servera tipa : PostgreSQL, MySQL ... a sta reci za MSDE 2000 koji je nuden kao free varijanta MSSQL-a?
Mnogo tehnologija za MSSQL je prvo razvijeno u Fox-u pa prebaceno u MSSQL. Dalje TSQL i nije neki mocan DB jezik (o postovanju standarda da ne pricam) naspram PL/SQL ili PgPL/SQL ... U Fox-u (v9) imas preko 400 ugradenih funkcija i preko 160 naredbi za rad sa podacima, mozes da pravis COM objekta, app module ... (sad vidis da tvoja usporedba nije rezonska)

Pa poredjenje sa Cobolom u ovom kontekstu je ispravno, oba su umiruca i samim tim diskutabilna kao preporuka novim programerima da utrose vreme i trud da ih nauce.

Nisam ja bas toliko mlad i koristio sam FoxPro i pre njega Clipper i dBaseIV (doduse nisam novije verzije FoxProa) i secam se dobro toga, ali to je i dalje u ovom kontekstu nevazno, kao i mogucnost da pises COM objekte u FOXu (koliko si ih ti napisao za ekternu uportebu?). Za "ubijanje" Fox-a nije presudno to sto u Accessu moras da koristis VBA i sto moras da uradis vise manuelnih koraka, presudno je to sto je glavno trziste FoxPro-a "RAD desktop database", sto je ujedno i trziste Access-a koji vec ima duboku integraciju sa ostatkom njihovog flagship proizvoda zvanog Office, dakle FoxPro gubi. Neke dobre stvari koje Fox ima su preuzete i ubacene u .NET platformu (LINQ koncept je jedna od njih), ali generalno Fox umire i to zapravo 2010 (2014 vazi samo za one koji pljunu lovu za dodatni support).

Inace, nemoj da se zanosimo da je sve to sto si naveo pocelo od Fox-a , to je vec previse. Fox je veci deo svoje funkcionalosti "pokrao" od dBASE-a. Na kraju krajeva, svi danasnji derivati SQLa ukljucujuci i TSQL i PL(gp)SQL su pokrali koncepte od IBM-ovog DB2. Poredjenje TSQL-a i PL/SQL-a je deplasirano jer oba sluze svojoj svrsi u okviru relacionih baza u kojima se koriste i niko ne place mnogo zbog nedostatka standardizacije, kad ni same ralcione baze nisu standardizovane, niti je i sam PL/SQL standardizovan u poredjenju sa "orignilanim" DB2 SQLom. Sam MSSQL je core svoje funkcionalnosti pokrao iz Sybase-a (i TSQL je zapravo Sybase-ova izmisljotina) i Fox nema nikakve veze sa njim, a ti mi daj konkretan primer, sta je to sto je Fox doneo novo u RDBS sto je MSSQL uzeo od njih?


PS: MSDE2000 i SQL2005 Express ne mogu da se porede jer je MSDE2000 osakacen funkcionalno za workgroup okruzenje, SQL2005 Express nije. Zasluga za to zaista i lezi u konkurenciji opensource resenja, ali to ne menja cinjenicu da je express potpuno funkcionalan i besplatan i veoma upotrebljiv za gomilu LAN resenja, ukljucjuci i multiuser finansijku bazu. Pitanje je samo sta koristiti za biznis/GUI layer.

Ti ERP-ovi su samo primer. Nešto sam gledao free ERP standalone pa sam zapamtio ta dva u Pythonu.

Ali i dalje tvrdim da sve što se radi za neki donji i srednji sloj tržišta (mala i srednja preduzeća) može da se uradi u Pythonu, čak i efikasnije nego u C# ili Javi. Python je dovoljno razvijen, dovoljno poznat (po Tiobe indeksu ispred C#), dovoljno brz (a uvek se može ubrzati sa Psyco), izuzetno lagan, sa gomilom biblioteka. Gui može da bude u blilo kojoj biblioteci (uključujući Swing, i ono što win koristi ako se koriste jython ili ironpython). Za ORM se može koristiti SQLAlchemy koji je u nekim stvarima napredniji od JPA sa TopLink implementacijom. I IBM pravi SQLAlchemy adaptere za DB2 i Informix. Kao bazu ništa jače i bolje od PostgreSQL-a tim preduzećima ne treba. Postoji i ReportLab biblioteka za pravljenje izveštaja.

Da, ali je i realna, ukoliko se ne radi o velikom projektu.



Ni slučajno. I ja i ti smo videli problem pri radu sa bazom pre nego što smo napisali jednu liniju koda. Ne vidim onda kako bi takava stvar obavezno promakla i prilikom kodiranja i testiranja, kad je problem poznat za takve situacije.



Ne bih se složio, tj. ne vidim neki veći problem.

_{[Ovu poruku je menjao degojs dana 26.04.2008. u 17:50 GMT+1]}

Microsoft je odustao od Fox-a, samim tim veliki broj programera traži alternative, novi programeri se ne odlučuju za rad sa njim.
Nije bukvalno mrtav, nisam tako ni mislio, ali svakako nema perspektivu. Sedna kao projekat prilagođavanja Fox-a .NET tehnologiji jeste interesantan ali samo odlaže neminovno (odnosno i nastao je da prebaci Fox programere na .NET).
I sam sam ga neko vreme koristio i mislim da su u njega ugrađene odlične ideje ali se pokazalo da ga je Microsoft kupio samo zbog rushmore tehnologije - i zaboravio. Čudo je i što je toliko opstao.


Python jeste vrlo interesantan ali...
Bavi li se neko na našim prostorima razvojem programa za knjigovodstvo u Python-u?
Baš bih voleo da vidim neki konkretan ali uporediv primer.

E da, u pitanju nije bilo navedeno za koju vrsta knjigovodstva se pise ta aplikacija - robno, materijalno, finansijsko, obracun zarada, osnovna sredstva, PDV, normativi, vodjenje KEPU i slicnih knjiga, izrada bilansa stanja i zavrsnih racuna, obracun zateznih kamata, kursnih razlika, carinskih stopa, itd. Pa su tu i varijante direktnog povezivanja na POS terminal i stampa na fiskalnom stampacu, pa izvoz podataka u elektronskoj formi za potrebe boniteta, poreske uprave, socijalnog & zdravstvenog osiguranja, pa specijalizovane statistike za odeljenje plana i analize i finansijskog direktora, razni izvestaji i nalozi za komercijalu i proizvodni sektor itd. Moze tu jos puno toga da se nabraja, sve zavisi od toga sta hoces da taj tvoj program radi.

Znaci, da li zelis da pises aplikaciju za neko najprostije knjigovodstvo sa najelementarnijim izvestajima, ili bi hteo da napravis objedinjeni alat za sve moguce primene u knjigovodstvu? U sustini, za neku najosnovniju varijantu, ako zelis da lici na Excel, "radi" matematicke operacije i sortira, mozes napraviti par makroa u Excelu i cuvati sve podatke u sheetovima. I to ce savrseno raditi posao za nekoga ko ima tri fakture mesecno i jednog zaposlenog. Ako zelis da pravis nesto kompleksnije, onda je potrebno da znas malo vise sta hoces od programa, osim da lici na Excel, racuna i sortira, pa samim tim mozes dobiti i konkretnije odgovore. Ja jos nisam cuo za programski jezik koji abnormalno radi matematicke operacije i u kojem nije moguce odraditi sortiranje, tako da nemoj da se cudis ako na ovom forumu ne dobijes odgovor koji si ocekivao.

Diskusija oko nacina implementacije korisnickog interfejsa nema smisla.

Prvo napravi srednji sloj/ aplikacionu logiku koja ce cucati na serveru, a onda napravi razlicite korisnicke interfejse - desktop, pda, web itd
Sve to moze da se zapakuje i u jedinstvenu desktop aplikaciju ako je takav korisnicki zahtev.

Rasprostranjena je varijanta - Java na serveru, sa JSP web interfejsom (Tomcat) ili .Net (C#) desktop klijentima.


_{[Ovu poruku je menjao cikaIvan dana 27.04.2008. u 17:24 GMT+1]}

Ako neko vec ima .NET programere koji rade desktop aplikaciju, zasto ne bi i serverska strana bila u .net-u? Ili obrnuto, ako ima Java programere, zasto ne napraviti i Java desktop stranu.

Zaista, sto da ne?
To je vec stvar licnih preferencijala.
Ako koristis Linux server, Java je verovatno logicniji izbor.
.Net klijent za desktop je verovatno lakse napisati u C# nego u Swingu i on ce se izvrsavati nesto brze na korisnikovoj Windows masini.

Mislim na liniju komandi File, Edit,View... sa padajucim listama ispod
naslovne linije u Excelu samo su to u ovom programu delovi programa,
izvestaji,.... Mislim na program koji ce obavljati sve knigovodstveno,
racunovodstveno, finansijske poslove na vise umrezenih kompjutera(robno,
materijalno, finansijsko, obracun zarada, osnovna sredstva, PDV, normativi,
vodjenje KEPU i slicnih knjiga, izrada bilansa stanja i zavrsnih racuna,
obracun zateznih kamata, kursnih razlika, carinskih stopa, itd. )
Pri unosenju podataka naprimer kontiranju u glavnoj knjizi konta se unose na
pocetku u koloni do kolone i sve se odvija u jednom redu (kao u Dnevniku -
ko se razume u knjigovodstvo) a kolone gde se unose podaci su kao u
Excelovom listu.

@mmix


Ne salim se. Zaista to mislim. Samo ce vreme pokazati da li ce tako biti. Uostalom, i sam si odgovorio zasto LINQ imas sanse, ta "SQL like" sintaksa jedino i moze da natera developere da ga probaju, da imaju bar jedan dobar deo sto imaju i sa SQL-om i jos plus nesto novo, a to novo ce biti static type checking i model podataka (naravno ovo ce ici preko nekog ORM alata), no da ne sirim pricu o ovome, posle ce neko reci da se samo izvlacim, uglavnom ovo je moje vidjanje, a da li ce biti tacno to ce vreme prosuditi.

@degojs


Izvni degojs ali brkas. Dao sam ti primer iz kojeg se vidi da brkas. Type sistem je jedno a osobine jezika drugo, i to sto je tebi kontradiktorno ne znaci i da jeste. Ako hoces i tvojim jezikom, onda bi to bilo ovako, "kudim" non static type sistem ali "hvalim" osobine "dinamickih" jezika, jer konstrukcije koje se sa njima mogu postici su zaista "mocne", i ja jesam pobornik spajanja ta dva sveta, u stvari to ti govore i ljudi poput Stroustrupa, Hejlsberg, cuces nesto poput "multiparadigm".

Ima tu jos elemenata...

Na primer, da li se aplikacija pravi od nule, ili se preradjuje par meseci ili par godina stara postojeca aplikacija? U prvom slucaju, lakse je odabrati najrazumniju opciju (da li je to .NET, Fox ili nesto deseto), dok u drugom slucaju treba ipak manje vremena da se aplikacija renovira unutar iste tehnologije (recimo sa Visual Fox Pro 7 na 8). problem sa dosta aplikacija sa kojima sam se sretao a koje su pisane u Fox-u (dos ili Windows), je taj sto su prve verzije tih aplikacija napisane u nekim slucajevima i pre vise od 10 godina, a od tada pa do danas su povremeno (ili konstantno) unapredjivane, ali na jednoj te istoj ili vrlo slicnoj platformi. U pocetku bese dBase, pa onda Clipper, pa zatim Fox, pa Visual Fox. Recimo u hotelu za koji radim vrti se aplikacija za hotelsko poslovanje, koja je napisana i Visual Fox Pro, sa klasicnim DBF fajlovima za bazu podataka. Ceo sistem bi bio mnogo efikasniji da je baza podataka na nekoj od SQL Server varijanti, ali ljudi koji su aplikaciju radili poceli su razvoj pre dosta godina, u medjuvremenu prodali izmedju 150 i 250 instalacija, i njima se ne isplati portovati sve na neku .NET + SQL platformu...

Ja sam upravo sada na pola puta da kompletiram portiovanje svih mojih aplikacija na VB.NET 2008 a koje su ranije bile pisane u VB6, dok je baza od samog pocetka uvek bila MS SQL. Dobit je visestruka (ocistio sam aplikaciju maksimalno od stvari sto planiram odavno a sto ne bih NIKAD uradio da sam ostao na VB6, povadio dosta bagova, optimizovao neke procedure tako da sada rade i preko 10x brze), jedino sto je potreban za nijansu jaci hardver. Da promena tehnologije nije bila tako velika (stari VB6 i .NET), dosta toga se ne bi desilo u skorije vreme, jer bih vrsio samo zaista neophodne izmene).

(p.s. Ja sam poceo sa clipper 5.0x, pa VB 3, 4, 5, 6, 2005, 2008)

Pa svako bi trebalo da ume da uporedi vreme i živce koje bi potrošio ako i ako ne uradi rewrite na boljoj platformi. Ako se radi kako treba, upgrade postojeće aplikacije, ma u čemu da je pisana, mogla bi da se svodi na "nekst, nekst".

Pogodnih ima mnogo.
Za desktop varijantu npr:

Borland C++ Builder (ili delphi) + access ili SQL server
ili
VB ( VB.NET ili C# ) + access ili SQL Server

Za web:

Oracle Forms + Oracle reports + Oracle

Čisto mi je čudno da se nije javio ni jedan programer u Clarionu. Oni jako vole svoj jezik i brane ga ognjem i mačem ako treba. Foxpro je htio to netko priznati ili ne mrtav no još upotrebljiv. Koliko će to dugo biti vidjet će njegovi developeri. Mrtav je i Clipper pa se još uvijek ponegdje prodaje. U prilog tome, mi smo u firmi prije 6 mjeseci bacili masu licenci, instalacija, raznih 3-party libraryja, Clipper 5.2, Foxpro za DOs i windoze, VisualFoxPro, Ultimade, dBsee... zadržali smo Delphi 7.

Koliko god recimo ja obožavao Delphi, i iako on ima podršku za sve moguće tehnologije (win32, .net, podrška za SOAP, CORBA, MIDAS, COM, WERBSNAP, INTRAWEB) vidim da lagano ugiba. Čak i unatoč stalnoj podršci, novim verzijama, novim mogućnostima. A njime se može raditi sve što poželiš, i bilo kojim pristupom. Od web-based alikacija, n-tiered programa, servisa... što god ti na pamet padne.

Meni je smislen i budućnosti okrenuta najviše Java. To je odavno i dokazano i pokazano. Tko nije shvatio - ni neće. Na žalost tu je pitanje isplativosti jave. J2EE je divna stvar, po meni je to "prava stvar" u svim pogledima, osim kad staviš na papir koliko ti treba resursa za razvoj. Kad zbrojiš koliko ti treba vremena, koliko ti treba ljudi, koliko ti treba za održavanje, i što je vrlo bitno - koliko to uopće možeš prodati i po kojoj cijeni. tu pomalo pada u vodu i onda mi se opet nameće Delphi koji može puno toga, a znatno brže i preciznije nego u drugim jezicima.

Što se tiče knj. programa osnova je brza i pouzdana baza + interface, ili ako je ikako moguće baza + aplikacijski sloj + client. i tu se sve svodi na Javu, na .net, na Delphi u nekom od njegovih oblika.

Vidio sam stvari bazirane na ajaxu, tj. spregi ssi+csi jezika i zaključih da ne nude ništa bolje riješenje nego što se to može napraviti Javom ili Delphijem.

Ako se koristi Internet bez VPN-a. tj. nekih extranet riješenja, ne treba zaboraviti ni na ranjivost sadržaja i količini prometa koja je kod SOAP-a, a da ne govorim SSI+CSI itekako izražena.

Pa da rezimiram: tko ima resursa tu je platformski neovisna, jaka, pouzdana i vječna: Java. Kome se žuri i hoće naplatiti sve što stvori tu je Delphi i njemu slični jezici.

A, ovaj, na osnovu čega tvrdiš da je Delfi efikasniji od Jave (sem na osnovu toga što si ti radio u istom)?

A zasto ne flex ili AIR + webOrb i neka baza ?

Na osnovi toga što radim u Delphiju godinama, a imam i dobro iskustvo u C-u. Recimo da sam učio programirati i uživao u poslasticama tipa TSR programa i upravljanja periferijom i kontorlerima iz Turbo C-a. 2 još u doba DOS-a. Javu sam načeo prije par mjeseci i malo testirao što i kako.

Spomenut ću banalnu situaciju, za nešto vrlo jednostavno i efikasno mada izbjegavam takav pristup: Odabereš samo jednu od nekoliko metoda pristupa nekoj od baza, postaviš komponentu za connection, za transakcije, provider, datasetprovider, clientdataset, neki query, povežeš ga na datagrid i gotovo. Eventi okidaju, većina toga se odvija automatski i stvar je uglavnom riješena. A to napraviti u Javi? Ne znaš hoće li ti trebati više vremena da napraviš nešto upotrebljivo u Swingu što će ispravno hvatati kojekakve evente tj. signale ili ćeš krotiti JvTable. Ili ćeš se pak baciti na neki framework tipa Springa, Hibernatea i sl. A ako hoćeš punu snagu i moć Jave, baciš se na izradu zrna za aplikacijski server tipa Glasfisha ili Tomcata, pa onda još razvijaš i nekakvo web ili GUI sučelje i to sve ide sporije u odnosu na Delphi. Pogrešno si me razumio, ja kažem da je Java fantastična stvar i definitivno jedan od igrača budućnosti, no nije za one-man-band programiranje i nešto gdje treba brzo pokazati rezultate. Ja u Delphiju u par popodneva mogu stvoriti itekako efikasan program, za što će ti u Javi trebati znatno više. A moje je skromno mišljenje da će se i native kod uvijek brže izvršavati od raznih među-kodova kao što su Java ili .net . I kao što sam već spomenuo, objeručke bi prigrlio javu kad bi njom idući tjedan mogao uspješno zaraditi svojem djetetu za hranu jednako vješto kao i Delphijem. Smatram da je najbolji jezik onaj koji najbolje poznaješ. Tako sam ja u Delphiju koristio BDE i IBX. Sad se evo selim na nešto ozbiljnije i perspektivnije pa ćeš i naći na nekom od ovih podforuma moje bedasto početničko pitanje o radu s DBX jer sam u toj tehnologiji zbilja početnik. Slično tome je i Java. Ne tvrdim da je sporija, meni je sporija jer nemam za nju razvijene sisteme, rutine, štoseve i trikove koje mogu brzo iskorisiti.

@negyxo: apsolutno si u pravu!

@lukeguy: ne znam koji je tvoj razlog za odbijanje apsolutno nepobitne cinjenice a to je da su desktop aplikacije vec uveliko pocele da evoluiraju u web aplikacije i da ce u veoma skoroj buducnosti desktop aplikacije biti dinosaorusi u svetu kompjutera. Ne samo Zoho i Google Docs vec sam negde procitao i da je Photoshop vec izasao kao beta web aplikacija samo ne mogu da se setim gde je taj clanak. A uskoro ce i dial-up biti nesto sto sluzi za nedajboze jer ce brzi internet biti u svakom domacinstvu kao sto je sad telefon.

Ako sam ja sam uspeo da napravim da Preferans (http://www.preff.net) u AJAX-u, i to bez ikakvog iskustva sa JavaScriptom, zasto neko ne bi mogao jedan knjigovodstveni program u kome je em interaktivnost drasticno manja em nema potrebe za nekakvim kolaborativnim azuriranjem, a i to bi moglo bez problema.

U svakom slucaju, sada vec postoje JS editori ili JS plugin za Eclipse i slicno i vreme potrebno da se nesto uradi je sasvim uporedivo sa drugim programskim jezicima.

I GOTOVO??? Pa meni u Java treba 5 minuta da sve to odradim i to sa Hibernate??? A ovo sto si ti napisao ja bih skocio kroz prozor da moram da uradim, svega mi!



Idi??? A u Java eventi spavaju ili su na odmoru pa moras da ih tuzis da bi odradili svoj posao???



Pa sve ionako ide na web tako da ne vidim sta hoces da kazes??? I ne znam zasto rec "nekakvo"??? Nego posalji ti jedan mail Google-u i eBay-u da ne znaju sta rade i da batale Java zbog radi Delphi-ja... Stvarno ti je ceo ovaj deo vise nego bezveze, uvredljiv za sve Java programere i po meni za programere uopste. Neosnovano napadas nesto sto si i sam u pocetku napisao da ne poznajes!



APSOLUTNO NETACNO jer ja mogu u Java da napravim isti program za manje od par popodneva. http://www.kvizolino.com sam ceo napravio za dva tri popodneva, koliko bi ti trebalo za to u Delphiju???



Da, pa? Program pisan u Assembly-ju radi brze od drugih, u Masincu jos brze, pa? Da batalimo sve jezike i vratimo se na kartice? Postoji razlika izmedju "brze" ili cak "mnogo brze" i "zanemarivo brze". To sto kompjuterski moze da se izmeri da nesto radi 1000 puta brze nije uopste bitno ako je ljudima i ta sporija varijanta prebrza. Drugim recima, ako je nesto prebrzo ili "dovoljno brzo" sve sto je brze je "zanemarivo brze".



E, napokon se apsolutno slazemo! Ali ako tako smatras onda sve ovo gore napisano nema osnova. Jer mozda je tebi licno tesko nesto napraviti u Java ali si se raspisao i iznapadao Java kao da je to univerzalna istina a ne tvoje licno iskustvo ili problem. Ja recimo imam identican problem sa Delphijem, i najverovatnije ga necu nikada ni uciti kako treba, ali sigurno necu nikada reci da je apsolutno lakse, brze ili bolje programirati u Java ili da Delphi ne valja po bilo kojoj osnovi!!!

_{[Ovu poruku je menjao preff.net dana 01.05.2008. u 11:36 GMT+1]}

Za malo da zaboravim, kad vec spominjes Hibernate: sa Hibernate-om ne moras da poznajes SQL ili DB2 ili PostgreSQL ili bilo koji drugu DB sintaksu!!! Sve se radi sa klasama i metodama kao i ostatak Java programa! Drugim recima ne treba ti provider, datasetprovider, clientdataset, neki query i datagrid... U jednoj klasi podesis parametre za konekciju i "Vozi Misko"...

.net (VB.net , C#)
prednosti - brza izrade projekta
mana - rad samo na windowsima

Java
prednost - rad na više Os-ova sa manjim modifikacijama
mana - duža izrada projekta


Python

prednsot - jednostavnost, radi na više Os-ova
mana - nepostojanje kvalitetnog GUI-a kao što je VS, ako bi se pisalo ručno, duža izrada projekta

može se integrirati u VS, ali opet radi onda samo na win.


ako misliš koristiti aplikaciju samo na windowsima, onda preporučam C# + mysql.

_{[Ovu poruku je menjao MarkoBalkan dana 01.05.2008. u 12:36 GMT+1]}

Hm, ne postoji prebrza aplikacija.

Na primer, stara aplikacija (VB6+MS SQL 2000) za obradu plata koju prodajem vec nekih 4-5 godina radila je na prosecnom P4/256Mb/40Gb racunaru izmedju 5 i 10 zaposlenih u sekundi. Nova aplikacija na VB.NET 2008 + SQL 2005 radi na istom racunaru izmedju 20 i 90 zaposlenih u sekundi. Da li je to zbog nove i bolje tehnologije, ili zbog toga sto sam radi rewrite cele aplikacije od nule, ne znam. Za radnu okolinu sa 50 ili 100 zaposlenih i jedna i druga aplikacija su savrseno upotrebljive. Medjutim, sada pregovaram sa jednom drzavnom ustanovom koja ima izmedju 30 i 35,000 zaposlenih, i ti je ubrzanje izmedju 300% i 1000% i te kako znacajno.

sada pregovaram sa jednom drzavnom ustanovom koja ima izmedju 30 i 35,000 zaposlenih, jel to neka Omladinska Zadruga :)



30 ili 35.000

hahahha

Pazi, LINQ je mocna stvar, LINQ for SQL jos mocnija (ukljucuje i taj famozni ORM u 1:1 obliku da bi preneo relevantnu DB shemu u aplikacioni domen), ali LINQ nikad nece istisnuti SQL jer jednostavno nije niti ce ikad biti toliko "mocan" kao (T)SQL. I koji god ORM da izaberes (EntityModel, LLBLGen, XPO, etc) svi oni tvoje operacije na kraju svode na SQL instrukcije, cak i sam LINQ for SQL u stvari prepevava tvoj LINQ query u SQL query. Nista to ne donosi fundamentalno novo, samo dopunjuje SQL u toj meri da (kao sto si rekao) daje strong type checking slican onom koji dobijas kroz typed dataset i omogucava lakse ucitavanje i/ili offline pretrazivanje objektnog modela (sto je samo po sebi ql i meni dovoljan razlog da ga koristim). Ako pod zamenom podrazumevas to da developeri nece morati da pisu SQL kod, onda si to vec imao kroz DataSet-ove (prevuces tabelu u dataset i visual studio ti izgenerise sve CRUD skripte), znaci opet nista novo samo malo "ispeglanije".

Iako LINQ for SQL ima svojih problema (npr sa subquery-em, server side funkcijama, forsiranjem query lock hintova, itd), i ja mislim da ce evoluirati dalje (sledeci korak bi bio podrska za sql2005 CLR i mogucnost koriscenja domenskih metoda u linq query-ima), ali stvarno ne vidim smrt SQL-a kroz LINQ. Maksimum sto ce se desiti je da pored SQL na serveru zazivi neka vrste remotinga koji ce marshalovati semu baze i primati IQueryable i vracati server site entity objekte tako sto ce IQueryable objekat odmah upucati u query execution engine cime ce se zaobici SQL kao jezik. Medjutim, toliko postoji trenutnih primena za SQL da ce se u najboljem slucaju server side LINQ i SQL naci rame uz rame. A od toga smo jos podosta godina.

@preff.net , pogrešno shvaćaš moje posteve i krivo tumačiš njihovu bit. Ne napadam Javu, čitaš li pažljivije vidjet ćeš da vrlo cijenim Javu, sve njene mogućnost i osobito njenu budućnost. Istovremeno govorim zašto je MENI npr. Delphi bolji od Jave za stvari koje ja trebam (bilo poznavanje jezika, bilo naplativosti, orpavdanosti...). Hibernate dovoljno poznajem da o njemu mogu donjeti svoju prosudbu no ni ne želim je napisati jer će opet biti da Javu dočekujem na nož; u svakom slučaju više cijenim native pristup bazama.

Rekao bi da ovo nema veze sa VB6 i VB.NET, vec sa SQL upitima.
Znaci ili si optimizovao SQL upite ili je MSSQL2005 deset puta brzi od SQL2000.

PHP uopste vise nije toliko labav da se iskoristi za taj tip web aplikacije ;)

Mozes da koristis kao bazu mysql bez da se brines.

A kao alat koji je jako dobar za taj tip aplikacije koristi ATK www.achievo.org/atk

Poseduje sve sto je bitno za rad sa bazom, pritom ti pruza veliku mogucnost da manipulises tabelama plus je vrlo lako napraviti CRUD u njemu za celu bazu.
Sa svega par linija koda imas totalno funkcionalan sistem.
Uostalom pogledaj njihov demo i sve ce ti se samo kasti ;)

Em je free, em ti netreba nista osim apache servera i php-a ;)
Plus sve java scripte su vec odradjene kao i java podrska.

Moj savet ako hoces tako nesto da pravis je da obavezno pogledas ATK.

Ne bih da ulazim u diskusiju koji je programski jezik bolji jer mislim da svaki ima svoje prednosti u određenoj oblasti primene, pa bih ti recimo preporučio Clarion (koji je koliko sam primetio tek jednom malo pomenut).
Isključivi razlog je što ga pominjem je što ga u praktičnoj upotrebi poznajem mnogo bolje od nekih drugih koje koristim i naravno, što na osnovu toga mislim da je za primenu u knjigovodstveno-računovodstvene namene odličan izbor.
On nije sada ni najmoderniji ni najefikasniji u mnogim aspektima ali omogućava prilično korisnih stvari:
- vrlo brzu izradu aplikacije (predstavlja pravi RAD alat u svakom pogledu)
- potpuno je objektno orijentisan odavno a naročito od ver 6.x
- sa veliko većinom RDBMS sistema se povezuje kroz native drajvere, a sa ostalima preko ODBC
- radi samo pod Windowsom ali na svim verzijama bez značajnih problema
i naravno što u isto vreme može da se napravi i desktop i web aplikacija iz istog IDE okruženja
Matematičke, statističke i neke druge mogućnosti u vezi sa optimizacijama i kompajliranjem koda ne bih posebno navodio obzirom da na današnjem hardveru skoro sve radi dovoljno brzo za knjigovodstvo bez posebnih zahteva jer je u većini slučajeva za ovakve aplikacije glavno ograničenje brzina rada operatera što nikakve veze nema ni sa programima i računarima.
Neko je ovde naveo i neke brojke koliko stavki operater u fakture i slično može da unese u program i to je verovatno tačno (nisam nikad merio). Ja bih samo pitao da li u jednom dobro projektovanom sisitemu za automatizaciju poslovanja neke firme neki operater uopšte treba da unosi takve podatke (osim možda ako je to firma koja se bavi pružanjem knjigovodstvenih usluga).

Taman kad ga naučiš shvatićeš da si usput naučio ključne elemente iz većine danas aktuelinih programskih jezika od widows sistemskih fukcija, asemblera C++ pa do .Net varijacija i jave.

Hajde sad reci da si se salio... :)

@mmix
Da, SQL nece jos dugo umreti kao takav ali ocekujem da ce se promeniti njegova direktna upotreba, tj. "front end" ce biti LINQ za developere a posle ko zna.


Ja mislim da ce upravo tako nesto slicno da urade, lepo dobave "expression tree" od developera koji napise LINQ "against" EF modela (gde ce lepota biti sto nece biti kao LINQ to SQL 1:1 nego apstrakcioni model) i to se posalje execution engine-u koji ce znati kako izgleda EF model posto ce sam EF model biti ono sto su sada tabele na SQL Server-u (i vise) tj. ugradjen na SQL serveru, naravno ovo je sve po nekoj vizij MS-a, a do ovoga ce trebati dosta vremena.

Ovo ce sve znaciti da imamo model, model koji se na jednom mestu menja, static type checking prilikom query-ovanja tog modela i samim tim sve dosadasnje stvari koje izgledaju samo jedan korak vise ce nestati, tipa, kada izmenim schemu baze ne zelim da isto to prepravljam i nad DataSetovima, kada izmenim schemu baze ne zelim da ponovo trcim kroz sve qyueriju da vidim da li su validni, kada pisem neku f-ju koja mi treba u programu i identicna funkcionalnost mi treba i u SQL-u ja treba da je napisem u T-SQL ili da je importujem preko CLR integracije itd. ubudjen sam da ce jos hiljade drugih razloga proizici zato ce ovo biti dobro, _{kao i zato ce biti lose :)}

Mislim da je najbolje za tebe da taj program pises u COBOLu.
Zasto ?
Zato sto ga ja super znam.

Zajebi MVC, visenivojske arhitekture, reusability, sva ta inzenjerska sranja. To ti nista ne treba.
Ja nemam bas mnogo skole, ali imam mnogo godina iskustva s COBOLom. Poslusaj zato moj savet.
COBOL!

@MarkoBalkan:
Java
prednost - rad na više Os-ova sa manjim modifikacijama
mana - duža izrada projekta

Šta ste se navrli na Javu toliko??? Kao prvo ne znam na kakve modifikacijame mislis? Nisam do sada morao da bilo sta modifikujem da bi radilo na Linux-u ili Mac-u? Programiram u Javi i startujem na bilo kom OS-u.

I opet šta znači "duža izrada projekta"? Ne postoji jezik u kome ću brže da izprogramiram malte ne bilo ta nego u Javi! Pa opet ne tvrdim da je u Javi najkraća izrada samo zato što to jeste slučaj kod mene. Svako ima svoje viđenje i svoje mišljenje ali reći da je GENERALNO duža izrada u Javi je glupost i dovodi samo do zbunjivanja onog ko je pitanje postavio. Dakle nije tačno da je u Javi uopšte duža izrada nekog projekta, već je naprotiv kraća!



Pa to je sve OK, imaš svoje mišljenje o Hibernate i imaš svoje mišljenje o Javi, ali ona dva posta na koja sam ja komentarisao su, isto kao i MarkoBalkan iznad, zvučali generlano i apsolutno. To što ti, ili bilo ko drugi, više voliš ili ti je lakše da koristiš neki drugi programski jezik to je super i ja to cenim! Ali ja neću nikad reći da PHP ne valja ili nešto drugo loše zbog toga što ga ja ne koristim i što više volim JSP... Nije ni bitno, reagovao sam jer su postovi, barem meni, delovali kao da izjavljuju isto što i MarkoBalkan, neku generalnu izjavu koja je u suštini samo njegovo lično iskustvo...

kolko redova ti treba za čitanje iz jedne tablice iz baze i prikazivanje u datagridu?

kod jave moraš posebno učitati kolone i redove, dok recimo kod .net-a ne moraš.

kod jave moraš staviti u nekim situacijama try-catch blok dok kod .net-a programer određuje.

itd....
istina svatko je onoliko brz koliko zna!

ja sam program za knjigovodstvo radio u PHP-u, ne razumem zasto ne moze script jezici da se koriste

Oracle definitivno najbolji.Po mom misljenju ima najrazvijeniji interfejs.

kad se kaze Oracle misli se na bazu podataka
inace, sam Oracle (preduzece, ne baza) gura Javu

znaci, ti predlazes Java kao jezik i Oracle kao bazu?

Ne od uvek, JDeveloper je u sklopu Oracle Developer Suit-a tek od skoro, skoro sve legacy Oracle aplikacije su radjene u pretecama ODSa koji su se zvali SQL*Forms i SQL*Reports, sto se uglavnom u skorije vreme dopeglalo u Oracle Forms i Oracle Reports, svejedno Jave tu nigde nije bilo. Funkcionalno najblize ovom konceptu je recimo Fox.

Malo sam off sto se oracla tiche, ali JDeveloper postoji vec sigurno 7-8 godina, a koliko znam Forms i Reports su na Javi od verzije 9 (baze)... ali moguce da nesto nisam shvatio dobro.

Priznajem da je "tek od skoro" malo nesrecan izbor reci, ali sa obzirom na to da Oracle Forms i Reports vuku svoje korene sa kraja 80'ih, pojavljivanje JDeveloper-a pocetkom XXI veka je "skoro" A, bar po Wiki-ju, Java se pojavila u Oracle-u cak u verziji 8, pre JDevelopera.
Problem sa Forms i Reports je sto ne zna svaki Oracle DBA Javu, ali svaki iole ozbiljan Oracle DBA zna PL/SQL sto je sve sto ti treba za izradu Forms i Reports aplikacija, kako na starim tako i na novim verzijama. Ja sam isto bio tvojih ubedjenja (nisam ni ja mnogo manje off za Oracle ) da je na Oraclu sve u Javi sad, i u neku ruku jeste ako to zelis, ali sam onda svojim ocima video Oracle 10 instalaciju na kojoj se vrtela specijalizovana accounting aplikacija bez linije Java koda. A znam da nema linije Java koda jer sam radio konverziju nekih formi i izvestaja u .NET kao deo veceg projekta, sve "suvi" PL/SQL.

Ne znam da li je aleksv mislio na taj aspekt razvoja ili na JDeveloper, niti sam ikad radio u JDeveloperu, ali moj generalni komentar je bio da accounting aplikacija verovatno moze da se uradi na Oraclu bez Jave, iako to ne bih nikad predlozio ni radio, sve mi to deluje mnogo arhaicno i clipper-like.

@negyxo / mmix
Svidja mi se vas pogled na stvari.

Iskreno cenim da je LINQ "bezanje od stvarnosti" i da kao takav ima buducnost, ali vise kao "pomocna alatka" nego kao "osnovno sredstvo za rad". Moram da kazem, da nisam upoznat sa LINQ-om u prakticnom radu, vec samo sa njenim konceptom (koji mi opet mirise na neka java resenja koja sam citao pre vise godina).

Moje iskreno ubedjenje je da (kvalitetniju) buducnost pre ima evolucija SQL-a nego uvedjenje tehnologija poput LINQ-a.
Posrednici su oduvek bili skupi.

No, ovo je off-topic, ali koliko vidim slabo ko se na ovih 6 strana uopste drzao osnovnog pitanja :)))

Pa u neku ruku i nije offtopic jer je LINQ kao data layer vezan i za izradu racunovodstvenih aplikacija.

Problem sa LINQom i ovom primenom nije u malim atomizovanim operacijama, za njih je LINQ to SQL vise nego idealan (napravi jedan unos, izemeni jedan unos, itd, itd) jer je sam po sebi idealno i ako se pravilno upotrebi veoma optimizovano resenje koje ne zahteva izradu specificnih adaptera za svaku mogucu primenu.
Problemi sa LINQom u racunovodstvenim aplikacijama pocinju, kao i u drugim narocito vecim sistemima, sa batch operacijama. Npr trenutno je prakticno nemoguce iz fabrickog LINQ to SQL generisati sledeci SQL query:



Jedini out-of-the-box nacin da obrises te promene je da ucitas sve te promene u memoriju, da ih obrises iz kolekcije i da uradis Submit(). Problem je sto ako imas tabelu promena sa 1.000.000 unosa od kojih je 900.000 iz prosle godine, ucitaces svih 900.000 u memoriju i onda ce LINQ to SQL pri brisanju da ih brise jedan po jedan generisuci ukupno 900.001 querija, od kojih svaki DELETE query matchuje record po svim poljima u redu (mada ovo moze da se zaobidje). Pretpostavljam da ce ovakvi scenariji biti eventualno pokriveni kako se korisnici budu zalili ali za sada ih nema, ima samo par entuzijasta koji su rucno petljali po expressions drvcetu i generisali neke budzevine kroz inner join na samog sebe

A teko ovo



Atomicnost ne moze da se izvede danas a da se sve operacije ne posalju serveru, to ce biti neka vrsta slanja micro assembly-a, sem naravno da se ne drzi lock na klijentu a to bi bas bila ludost.



Pa to sto radi LINQ je evolucija jezika, i to se samo tako zove, ali na kraju ce se sve to lepo mergovati i mozda ce se zvati new SQL (EntetySQL ), to je nebitno kako se zove, bitno je sta obavlja. Po meni, ovo je samo prebacivanje SQL u novo okruzenje - okruzenje kompajlera
Inace, danas je to posredovanje, a u buducnosti ce biti, vrlo moguce, direktno komuniciranje sa engine-om (hint: .NET: IEnumerable, Deferred Execution i eager/lazy evaluation, e to je kontrola )

Nisam kompletno procitao Topic, ali sta god bilo najbolje je resenje imati Front-End na racunaru (Jednostavan EXE napisan u bilo kom jeziku) koji bi pristupao Serveru i bazi na Net-u. Ja sam licno Radio Kombinaciju Delphi7+PHP+MySQL+SSL(internet konekciju) i sve je radi savrseno (Bio mi je posao da napravim Front-End za jednu stranu firmu). Prednost ovoga je bilo to sto nisam morao da ima pred znanje PHP- i MySQL-a mada sam osnove ipak naucio (samo sintaksu u pocetku) cisto toliko da bih razumeo kako da posaljem upit i kako da objasnim Adminu gde i kako da mi dozvoli pristup i kako da interpretiram stvari koje mi oni vrate u front-end.

Naime koliko god da imas memorije, skriptovi i Dinamicki generisane strane opterecuju Procesor i Memoriju, tako da posle dugog koriscenja mora doci do gusenja.

Sto je najbolje na stranici http://www.sqlmaestro.com/ mogu se naci nekoliko besplatnih resenja koje itekako pomazu/pojednostavljuju izradu front-enda narocito kada su upiti u pitanju.

E-banking radi na slicnom principu ovo nije nista novo, baza je baza a front-end moze da bude sta god mi hocemo. I last.fm koristi slican princip (Znam nema veze sa temom ali princip, nacin i resenje je u stvari bitno)

Ako blebecem gluposti, zanemarite moju poruku.

Upravo to prvo sto si naveo :
evolucija jezika ili kako to jos zovu "extremely human readable o.o.p. vs sql code"
al otvara polako vrata za potpuno automatizovanje entity procesa preko razlicitih izvora podataka ili ti pravljenje polimorfnih upita ..
Da ne prevodim bas sve evo linkova o LINQ-u na msdn-u :

http://msdn2.microsoft.com/en-us/library/bb425822.aspx
http://msdn2.microsoft.com/en-us/library/bb308959.aspx




Samo bi da dodam i IQueryable<T> :)

Pozdrav !!!

Iskreno rečeno, tko će brže napraviti aplikaciju za računovodstvo: VB programer ili C++ programer ili Java programer?!

Zašto komplicirati kad može jednostavnije i brže.

Predlažem Visual Basic (ver 6. ili .net), u kombinaciji sa T-sql bazom.

Brzina i jednostavnost je danas vrlina dobrog programera.

U protekle tri godine radim sa knjigovodstvenim programima u web okruzenju ( Linux -Apache -PHP -JavaScript - MySQL ) nisam imao nekih vecih problema to sve radi korektno kao i fiskalni stampac, finansijsko ,robno ,obracun zarada,pomocne evidencije .To sve radi na internet konekciji ADSL cak je radilo solidno i na dial-up .Ako se instalira Linux server to radi u lokalnoj mrezi a moze se pristupati i sa udaljenog mesta preko internet konekcije .Ako bi se dodale AJAX metode programi bi dobili na kvalitetu .
Mislim da je ovakav nacin u buducnosti najpogodniji i daje mnogo novih mogucnosti a vrlo lako se prelazi na ovaj nacin rada sa starih DOS programa .

Krenulo je od pitanja "Koji je programski jezik pogodan za pisanje programa za racunovodstvo?" isključi sve što ima veze sa microsoftom, oraclom i ostalim skupim alatima i bazama. Koštaće tebe i tvoje klijente jako mnogo. MySQL, PostgreSQL, ili nešto slično za bazu. Perl, PHP, Java za alat. Ukoliko razvijaš aplikaciju za MSP (sa naglaskom na M) i želiš sutra da je lako održavaš (moraćeš), obezbedićeš sebi i svom softveru lepu budućnost. Brzina razvoja i brzina rada nisu najvažnije. Svi "test piloti" koji brzinu u ovoj vrsti programa smatraju presudnom verovatno NIKADA nisu napisali knjigovodstveni softver koji se koristi.

Kako si resio problem stampe za fiskalni racun iz browsera?



Ova tema se opasno pretvara u advocacy :)

samo da odbranim stav " isključi sve što ima veze sa microsoftom, oraclom i ostalim skupim alatima i bazama.". Ako je u pitanju softver namenjen MALIM preduzećima koja svrha je angažovati tešku artiljeriju za teške pare? Takav program NEMA kupca! "Spram sveca i tropar."

Da bi radio fiskalni stampac FP 550 koristim gotov program Metalink a iz PHP generisem tekstualni fajl u folder koji zahteva Metalink .To moze da se resi i na drugi nacin ali tema zakona ,fiskalnog stampaca ,atestiranog softvera i dalje nije do kraja definisana .

@galenit: je'l moguce vidjeti negdje demo te aplikacije ili makar screenshot-ove da okacis?

Mikail, da si citao temu video bi da se to sve moze sa MS proizvodima uraditi besplatno, osim samog windows-a.

Znaci realno ti nemas konkretnu informaciju da je fikalni racun zaista odstampan ili jos vaznije poslat poreskoj, a vec si "proknjizio" transakciju, a to znaci da je realna situacija da kes u kasi bude veci od onog koji FP550 posalje poreskoj sluzbi kroz "etar". Finansijska obozava takve situacije. Brinete se da klijenta ne osteite za licencu XPa al vam izgleda potencijalne kazne nisu skupe

Ja i dalje ne vidim konkretno resenje ovog problema sa svim tim predlozenim sistemima baziranim na html-u i client side skriptama, jednostavno vam je sandboxing browsera velika prepreka. Osim mozda instalacije trusted koda na krajnjim masinama, u kom slucaju se gubi cela ta prica sa mekanim deploymentom.

Nisam bas razumeo ovu recenicu citat Brinete se da klijenta ne osteite za licencu XPa al vam izgleda potencijalne kazne nisu skupe
Kada sam napomenuo atest za softver to se odnosi na knjigovodstvene programe a ne za operativni sistem .Jedna od prednosti pisanja programa u ovom okruzenju je nezavisnost od operativnog sistema ali postoji mnogo vise razloga da se opredeli za ovu vrstu knjigovodstvenih programa i prema tome pripada im buducnost .Konkretan nedostatak u delu programa nije vezan za pogodnost pisanja programa u ovom okruzenju vec se to resava individualno a posto vidite problem lako je naci resenje .

Citat je vrlo jednostavan, od pocetka ove teme slusam price kako je LAMP majka mara svih mogucih aplikacija i sistema i besplatno resenje svih zivotnih problema od spremanja zdravog dorucka do implementacije ERP-a za konglomerate i kako smo svi mi koji se drzimo Windoza ustvari zamracene svesti jer ne vidimo svetlo koje je LAMP. Cinjenice su medjutim daleko od toga, a kontrola fiskalnog printera je samo jedan od tih problema.

Sve web aplikacije (ukljucujuci tu i LAMP a i ASP.NET) imaju dva velika problema, izvrsavaju se u sandox rezimu browsera i na serveru rade u per-request rezimu. Ta dva problema predstavljaju ozbiljnu smetnju za kontrolu externih hardverskih resursa, ukljucujuci fiskalni printer. Ti fiskalni printeri imaju za sebe zakacen GPRS emiter koji salje sve fiskalne transakcije poreskoj, i kad ti predas raw file u Metalink ti mozes samo da pretpostavis da ce taj racun biti odstampan/poslat i da se nadas najboljem i da transakciju "proknjizis" u svom sistemu. A znas sta se kaze za pretpostavke . Ako se racun kojim slucajem ne odstampa iz bilo kog razloga imaces situaciju da se transakciono stanje u tvom programu ne slaze sa stanjem koje ima poresko i ne treba ti inspektor sa PhD iz ekonomije da to iskopa i kazni tvoju musteriju. Mozda ja jesam perfekcionista, ali za mene je to veliki showstopper.

Pogledaj malo i temu Koji je programski jezik pogodan za pisanje programa za racunovodstvo - ekonomski aspekt, za detalje oko "skupoce" i videces da tvog klijenta (preko cene tvog programa) u osnovnoj SoHo varijanti windows based solucija kosta jednokratno oko $100 po masini, sto je definitivno u plateznoj moci i najmanjih preduzeca, i sasvim sigurno kosta manje od kazne poreske inspekcije za neispravne fiskalne transakcije.

Ne znam da li Metalink vraca neku povratnu informaciju, u vidu output.txt sa porukom/statusom da li je proknjizio transakciju. Ako vraca informaciju, onda nije nikakav problem procitati je - sa servera.

Nije problem ni stampati na matricnom stampacu, ako je stampac u mrezi deljen,



Web interfejs nije zgodan za POS terminale gde se unosi veliki broj transakcija/vrem.jed - super/mega marketi, salteri, za sve ostalo funkcionise sasvim ok.

Nisam baš upućen u problematiku i ne znam šta je metalink, ali zašto je problem da se na svakoj mašini na kojoj postoji fiskalni štampač instalira i mali server za komunikaciju sa istim, sinhrono, pošalješ zahtev i on ti odmah vrati info šta je bilo sa tim računom? Mislim, znam da se time delimično potire suština veb platforme kao izbora, ali opet fiskalni štampač (a sa njim i taj server koji bi mogao da se nazove i drajverom) nije nešto što zahteva stalne apdejtove. Plus što i on može biti crossplatform.

Nemoj da se nerviras. Meni je bas zabavno da gledam kako ljudi koji ocigledno i ne znaju kakvi su zahtevi pred knjigovodstvenom aplikacijom, imaju "idealna" resenja i predlazu platforme kje nemaju veze sa vezom. Ostalo je jos samo da neko predlozi kao idelno resenje aplikaciju pisanu u BAT ili sh skriptama i celina je zaokruzena :)

Nisu zahtevi za racunovodstvene programe samo fiskalni stampac da bi mu se toliko ovde poklanjalo paznje .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 .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 .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

Problem je u sinhronosti operacije, ovo bi mozda i funkcionisalo u statefull sistemu, ali web to nije. Operacija je u potpunosti asinhrona i ne garantuje procesiranje zahteva za stampom i dobijanje feedback-a u vremenskom periodu alociranom za per-request PHP (ili asp.net) strane, niti postoji pouzdani mehanizam da se operacija stornira. To nije novina, ti timing problemi sa swivel-chair integracijom komponenti sistema postoje jos odavno, real-time distribuirani sistemi i distribuirane transakcije su i osmisljene da bi se prevazisao taj problem. A LAMP to nema.

Metalnik mu dodje neka vrsta interfejsa, bar koliko sam ja to prokapirao, generalno asinhroni system koji prebacuje informacije iz jednog izvora u drugi koristeci metalink xml format da definise izvor, destinaciju i operaciju. Moda negde i gresim, ali generalno mislim da je to to.
A sto se tice tvoje primedbe, generalno da, ali kako? Sad vec pricamo o binarnim programima i nocnoj mori sa komaptibilnoscu distro-a i integraciji sa browserima i pluginima na tim razlicitim platformama. To nije nista manje kompleksno niti jeftinije od recimo pokusaja da se ActiveX podigne na linux-u kroz Wine ili crossover . A ako se fokusiras na samo jedan distro i jedan browser, onda dalje gubis tu sustinu web platforme.

Ma ne nerviram se uopste, samo sam malo cinican Malo me samo generalno iritira sto svi zaboravljaju kakvi su sve problemi bili prosli put dok je trajala groznica intranet-a i kad su svi obecavali da je web buducnost i da cemo cak jednog dana svi imati jeftine thin masine i da cemo sve raditi na webu da bi posle tone problema taj koncept odumro i rich statefull koncept prevagnuo a mi svi sad imamo thick masine sa zverskim procesorima i brdom memorije zbog drasticnog pada cene hardvera. Sad x godina kasnije ponovo se cuju iste price, a ne cuju se resenja tih starih problema, kao da ih nikad nije ni bilo i kao da je prvi pokusaj propao zato sto zvezde na nebu nisu bile postavljene kako treba. A sa druge strane proizvodjaci browsera najavljuju jos grdji sandboxing browsera iz siguronosnih razloga. Nekako mi ta matematika uopste ne stima.

Naravno da ispunjava, racunovodstveni programi nisu rocket science, ali ako cemo tom logikom i dBASEII (ajd da budemo noviji pa da kazemo dBASEIV) jos uvek ispunjava sve te zahteve sa terena, pa sto si onda presao na LAMP? Sasvim sam zapravo siguran da taj dBASE jos uvek predstavlja bolje resenje tog problema nego LAMP.
A to da imas prodate funkcionalne verzije u LAMPu ti naravno verujem, i siguran sam da su svi tvoji klijenti presli na LAMP, ali to nema nikakve veze sa tehnoloskim prednostima i manama istog o kojima ovde pricamo, vec sa cinjenicom da ti kontrolises format baze koja je kod njih instalirana i da tretiras taj format kao proprietary i da time njima uskracujes mogucnost da predju kod drugog proizvodjaca zbog teskoca u konvertovanju baze. Efektivno ti koristis FUD taktiku da "prisilis" svoje klijente da predju na onu platformu koja TEBI odgovora umesto na onu koja bi njima mozda bolje odradjivala posao.

Šta znam, ja sam imao drugačiju ideju - da se tom drajveru pristupa ne iz brauzera, nego iz serverske aplikacije (mislim, koliko to ima fiskalnih štampača u organizaciji? Nema valjda svaka klijentska mašina nakačen fiskalni štampač?!) A sa druge strane, ako to rešenje iz nekog razloga ne pije vodu, u drajver se ugradi HTTP serverčić i request/response se obavlja jednostavnim AJAX zahtevom iz brauzera, bez potrebe za Activexom ili čime već. Mislim, sad stvarno ima dosta različitih načina da se obavi ta famozna fiskalna štampa.

A za portabilnost ima takođe više načina, jedan od njih je svakako Java, a što da ne i neki skript jezici tipa perl, python...

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.



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.



Zaista cudan nacin razmisljanja. :)



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.

Ili još banalnije, kada se neki posebno formatizovan sadržaj pojavi u prethodno dogovorenom folderu, on izvrši operaciju nad sadržajem, recimo - pošalje na štampu :)

onlile: "Ne znam da li Metalink vraca neku povratnu informaciju"
http://metadata.co.yu/se/fiskal/metalink.htm
"Kao rezultat, program vraca fajl sa odgovorom na postavljeni zahtev."

@jablan: sve to stoji i to sto si predlozio je ocigledno izvodljivo (mada sumnjam da bi pravio svoj HTTP server zbog ovoga ), ali pazi koje sve budzenje moras da radis a na kraju i nemas potpunu transakcionu kontrolu (mada je u ovom primeru to nevazno posto ne mozes da rollbackujes podatke koje fiskalni printer posalje poreskom). Zar nije jednostavnije imate statefull aplikaciju koja ima direktnu kontrolu nad print spoolerom i onda mozes da konfigurises stampu kako ti volja, dal preko centralnog printer, dal preko lokalnog, sve je transparentno za kod a mozes da radis RAW izlaz, da pratis status dokumenta, da vidis status stampaca, itd, itd. Jednostavno mi nekako bode oci kad moram da radim neki workaround koji je u drugom resenju lepse odradjen samo da bi zadovoljio neku potrebu za dokazivanjem da i LAMP to moze da uradi.

Kad smo vec kod AJAX-a, bas me interesuje dal neko od ovde prisutnih boraca za knjigovodstveni LAMP ima tako nesto implementirano u svom resenju, ili se radi o klasicnom web programiranju.

Pa nit' je veb server (posebno neki tako uske primene) težak za napraviti, nit' je to nešto što se radi svaki dan.

Pa sve je stvar kompromisa - neke stvari žrtvuješ da bi dobio neke druge.

Ja lično ne verujem, ali razlog tome nije to što ti impliciraš. Kontrapitanje bi bilo koliko je knjigovodstvenih paketa urađeno u .NETu? Tehnološka inercija u ovoj oblasti je ogromna, većina knj. paketa je nastala još u Clipper eri i svaki rewrite je bio em mukotrpan za autore (zbog prinuđenosti da uče nešto novo), em za korisnike (jer autori po pravilu nisu najbolji učenici i to na kraju ne liči ni na šta).

Pa ima ih dosta, cak stranih adaptiranih za nase trziste kao sto je MS Dynamics. Svojevremeno je spinaker imao svoje resenje (bar su radili na njemu dok su mi bili komsije), ali mislim da su batalili to i know-how iskoristili za adaptaciju NaVision-a za nase trziste. .NET tu nije glavni iz istih razloga koje si naveo o interciji, jednostavno se pojavio suvise kasno da bi usao na to prezasiceno trziste. Suvise se mala lova sad vrti u tome da bi nekog privukla, a deo trzista gde ima love (velika preduzeca) obicno gravitira ka brendovima bez obzira na to koliko je proizvod katastrofalan tehnoloski (samo kad se setim Great Plains-a, tj Great Pains-a od miloste ).

Mada sve je to manje vazno, nisam generalno pokusavao da ubacim .NET u jednacinu, vise zastupam stav da je statefull rezim rada bolji od stateless browser rezima, sto podrazumeva i proizvode za druge platforme sem .NET-a (npr adaptirani AccPac koji je ako se ne varam radjen u Delphi-u) i da je deployment mnogo manji problem od realnih i potencijalnh operativnih problema koje stateless donosi.

PS> Zaboravih na Informatiku, njihov knjigovodstveni program je u .NET-u, ali nisam imao prilike da ga vidim.

Slazem se da je bolji jer je pouzdaniji ali mozda i web ima i neke prednosti
Razvojem web aplikacija donelo je da na trzistu klijenti dosta puta traze "user friendly"
interfejs koji imaju na IE,Firefox-u Mozzili Operi itd. koji su itekako poznati ljudima koji koriste program da bi olaksali ucenje i koriscenje istog,
dok je developerima muka i oko deploymenta i oko postavljanja celog sistema na noge (transakciiona kontrola,print spooler itd..) u web okruzenju ...

Tako da ostaje na onom sto je jablan rekao :


Tako da zrtvujes pouzdanost naspam kraceg ucenja i objasnjavanja rada programa krajnjim korisnicima .
Pa ko voli nek izvoli !!!


_{[Ovu poruku je menjao deerbeer dana 23.05.2008. u 21:00 GMT+1]}

Ne mozes porediti JavaScript i .NET. To su dve potpuno odvojene stvari. .NET je sasvim ok platforma za razvoj aplikacija. To sto on nije zastupljen je samo zato sto se retko kome isplati da vec razradjenu apliakciju koja ima klijentelu odbaci samo zato da bi presao na novu tehnologiju.

Sasvim je sigurno da neko ko sada razmislja dapocne dapravi aplikaciju od nule, ozbiljno razmatra i .NET kao opciju, jer svejedno pocinje od nule i normlanoje da ce da trazi podlogu koja ce mu obezbediti kvalitetniji rezultat. Medjutim izbor .NET-a je isti kao i izbor programskog jezika, to pre svega zavisi od afiniteta, ranijeg iskustva i poznavanja tehnologije. Signo niko ozbiljan nece odluciti da korsiti .NEt ili bilo sta drugo samo zato sto je to sada u trendu.




Sta je vise user friendly je veliko pitanje. Ne znam zasto bi neko smatrao da je okruzenje web citaca pogodnije za rad nego recimo windows okruzenje. Web icataci uvek imaju jednu veliku manu: njihov korsinicki interfejs je veoma ogranicen, skoro do neupotrebljivosti za bilo kakvu aplikaciju koja nije jednostavan web sajt. Da ostavimo neophodne elemente interfejsa za unos podataka koji nedostaju, pogledajmo samo stampu. Knjigovodstvenoj aplikciji je cesto potreban tako sofisticiran nivo kontrole stampe da cak ni ceo windows API ne moze da zadovolji a zamisli da moras da stampas iz web itaca koji ti ne daje nikakvu kntrolu osim da li ce da se stampa pozadina i koja ce biti margina (a pri tom i taj deo u stvari ne mozes da kontrolises nego korisnik moze da promeni kako mu se cefne).

Da ne pominjemo da korisnik moze bilo koju trenutnu stranu da "zapamti" u boookmark i da j epokrene kad god pozeli, a za knjigovodstvene aplikacije je veoma bitno da mogu da kontrolisu svaki aspekt aplikacija, a narocito taj kada, ili kojim redosledom korisnik moze da pristupa opcijama. Da ne pominjemo da je vrlo cesto potrebno da program ima pristup resursima na niskom sistemskom nivou a da su web citaci ograniceni na samo banalan nivo pristupa lokalnim resursima.


Ako neko misli da je weboliki interfejs bolji to uvek moze da napravi u desktop alikaciji (sam Microsoft je izbacio dosta programa koje na prvi pogled izgledaju kao web sajtovi ali su itekako cvrste desktop aplikacije), dok obrnuto nije moguce osim da napravis nei ActiveX ili sta slicno sto u stvari predstavlja dektop aplikaciju koja se ucitava u web citac.

Pa neka stampa iz web okruzenja ako ima strozije zahteve ide se u generisanje PDF formata pa tako stampamo u istom trenutku virman sa upisanim podacima .
Da bi se mogao kompleksnije sagledati problem knjigovodstvenih programa treba se vratiti malo dublje u istoriju knjigovodstva i kartonske kartice sa indigom i kopiranjem na dnevnik . Posle obicnih kartonskih kartica pojavljuju se kartice sa magnetnom trakom po rubovima i sve to realno odslikava knjigovodstvo i tada dolaze programi koji okrecu celu pricu naglavacke .Knjize se podaci u neku datoteku a iz nje se generisu kartice po potrebi sto je suprotno od zahteva knjigovodstva gde se trazi da se podaci knjize direktno na karticu a izvestaji se dobijaju sakupljanjem podataka sa pojedinacnih kartica -za ovim postoje realni zahtevi .
Da bi se ovakvi zahtevi ispunili stupa na scenu AJAX metoda sa svojim mogucnostima da knjizimo direktno na odredjenu karticu i dok to knjizimo vidimo ispred sebe realnu sliku kartice sa proknjizenim redovima do tada .Ovakav nacin upisa podataka preko kartica daje bolju preglednost u radu i ispravnu logiku za knjigovodje koje ne interesuje programski jezik vec svoj posao .
Ne poznajem dovoljno AJAX metode pa ako bi neko mogao da napravi lep primer za ovakav nacin knjizenja mislim da bi se otvorilo novo poglavlje u knjigovodstvenim programima a knjigovodje bi konacno dobile poruceno resenje od pre 30 godina .

Sto se "user friendly" okruzenja tice, ne zaboravite da knjigovodje extremno mnogo koriste numericku tastaturu - ja jos nisam video web resenje koje se moze lako koristiti iskljucivo sa tastature, a pogotovo ne samo upotrebom numericke i eventualno kurzorskog dela tastature.

Znaci, ako knjigovodja moze jednom rukom bez puno setanja da ukucava stavke, a recimo prstom druge ruke markira stavku na fakturi koju ukucava, unece desetak stavki dok kazes "user friendly interface za knjigovodstvenu aplikaciju". Ali ako on mora da vija Tab taster, koji se najcesce koristi za prelazak sa jednog na drugi element u web okruzenju, i koji je na suprotnom kraju tastature, ili da podize desnu ruku i spusta je na misa i zatim vija dugmad i menije po ekranu, za isto to vreme ce uneti svega stavku-dve. Koliko puta sam samo ja bio u situaciji da vidim kako knjigovodje posle nekoliko meseci upotrebe odbace napredniju aplikaciju i vrate se na Clipper resenje jer im "lezi pod prstima", pa imaju mnogo vise vremena za ispijanje kafe, listanje novina, tracarenje sa koleginicama i zavrsavanje privatnih poslova u radno vreme.

BTW, neko rece da .NET nije mnogo zastupljen - Privredni Savetnik je svoje knjigovodstvene aplikacije razvijao u C# & .NET & MSSQL varijanti, a koliko se secam dok sam bio u njihovoj tehnickoj podrsci imali su prilicno brojnu klijentelu.

Ja sam namerno unapred pomenuo bas primer stampe da bih predupredio da iko pomene PDF, ali eto.. ljudi su skloni krpezu...



Nece to oni nikada razumeti. Krpez logika se zasniva samo na jednom principu: vazno je da ikako moze da se dobije neka osnovna funkcionalnost i onda se to proglasava kao idealno resenje.


To ti je kao da neko sklepa trombelaj (vozilo koe se sastoji od drvene ploce i cetiri lagera umesto tockova) i prodaje ga da je prevozno sredstvo dobro kao i najsavremeniji automobil, uz napomenu da eto mora da se povede racuna da se vozi samo po idaelno ravnoj povrsini, a da se ne vozi brzo jer ce da trucka, a moze i da se raspadne... Nema veze sto to sa kolima ima veze samo utoliko sto ima cetiri tocka i upravljac.

Pa dobro uvek su neki mislili da nesto sto se ranije pojavilo je savrseno ,mnogi su brze sabirali rucno sa mastiljavom olovkom od racunske masine sa trakom ,bile su bolje rucne kartice od cobol programa ,pa su bili bolji cobol programi od clipper programa i normalno ta ista grupa se upustila da objasni kako su vece mogucnosti ofarbanih dos programa u odnosu na savremene web tehnologije .Zeleli mi to ili ne knjigovodstveni programi ce biti u web okruzenju sigurno uz mnogo problema ali to je buducnost .A ja razumem ako neko ima 500 instalacija u foxbase da tvrdi kako je dostignut maksimum i nema dalje jer u praksi zameniti toliko instalacija ,obuciti korisnike skoro je nemoguce a nema potrebe jer i ovako donosi zaradu .I zbog toga valjda postoje entuzijasti a postoje i konzervativci uglavnom je konacna pobeda prve grupe jer nebi trebalo da bude posle nas potop .

Ovde se uopste ne radi o konzervativizmu vec o tome da ne mozes trombelaj prodavati umesto automobila. Napredak bi trebalo da predstavlja nesto pozitivno, neko unapredjenje, a nuditi web interefejs za knjigovodstvenu aplikaciju to nije.

Vrlo dobro znam o cemu pricam jer sam radio i jedno i drugo. Kao to sam vec objasnio, web ima smisla za neke poslove a za neke ne, isto kao sto i desktop alikacija ima smisla za neke poslove a za neke ne.

Delimo mišljenje po celom ovom pitanju, ali za ovo moram da te ispravim, ovo se lako reguliše u Web aplikaciji i trebalo bi da bude osnova programiranja Web aplikacija: state management u stateless sistemu kakav je Web, tj. HTTP protokol. Koliko lako zavisi od alata, ali ko iole želi da se bavi razvojem Web aplikacija ovo je jedna od prvih stvari koje mora da savlada bez obzira na alat.

Hajde da pogledamo malo prednosti jednog i drugog.
Desktop:
- kontrola unosa (daleko je lakse i bolje kontrolisati korisnika u win app nego u web browseru, gdje se recimo Back i Forward ne mogu iskljuciti)
- kontrola uredjaja spojenih na racunar (razni stampaci, citaci kartica, key-evi i slicno)
- stampa (objasnjeno gore)
- statefull konekcija sa bilo cime (bazom, serverom, whatever)

Web:
- lakoca upgrade-a tj novih verzija
- centralizacija podataka (mada nisam siguran gdje ide ovaj argument, klijenti vole 'kod sebe' cuvati podatke, ovo je samo olaksica programerima)


Ispada da web rjesenje vishe odgovara programerima nego klijentima. Klijenta bas briga kako ce raditi upgrade nove verzije (a nije nemoguce da se uradi i upgrade desktop verzije preko interneta, tona programa to radi).

Da, slazem se, ali ti u web okruzenju vishe posla gubis da predvidvis sve akcije korisnika, zabranis, iskljucis da ne bi kakvo s**** napravio nego sto to radis recimo pri razvoju desktop app.

U praksi bi to znacilo ovako, podesimo max_execution_time = 30 i posaljemo zahtev preko browsera zahtev web serveru da odstampa fiskalni racun, medjutim u tom trenutku je opterecene web servera 100% i dok cekamo odgovor, tih 30 sekundi istekne, a fiskalna kasa je vec odstampala racun, sto i jeste veliki problem. Postoje jos i drugi moguci problemi, kao na primer napuni se hard disk i nemoguce je upisati fajl sa povratnom informacijom ili dodje do prekida mreznog kabla do servera, tj. svaki posrednik do kase uvecava verovatnocu outsynca sa kasom.

Za potpuno sigurnu transakciju je u svakom slucaju potrebna povratna potvrda od klijenta ka kasi da je racun ispravno upisan u bazu podataka i tek tada kasa treba da overi fiskalni racun, nesto kao two-phase commit. Inace ako se iz bilo kog razloga racun ne memorise u bazu podataka fiskalna kasa bi morala da uradi rollback prethodnog racuna :).

Zbog smanjenja mogucnosti greske, vise naginjem fat clijentu kada je u pitanju POS terminal, koji moze biti u obliku swing-a, .NET, gtk, tk, tekstualni ili bilo koji drugi.

Sto se tice backend baze, sadasanji RDBMS-ovi uglavnom zadovoljavaju ACID specifikaciju i zbog toga njima dajem prednost u odnosu na dbase/fajl/cobol baze.

Stampa je najmanji problem koji sam sreo kod web aplikacija. Dobro podesenim css-om uglavnom svi pregledi (sve sto se vidi na ekranu) mogu da se odstampaju direktno iz browsera, da se povecaju slova, smanje i da budu potpuno upotrebljivi kao izvestaj, dokument. Cesto sam vidjao da su nekada ljudi pokusali neki pregled da odstampaju print screenom. Vide ga, imaju unesenog, ali ne mogu nista vise da urade sa svojim podacima ako im to nije omoguceno programom.

Takodje web strane mogu i da se snime u html, a zatim otvore u excellu, gde uz malo ciscenja/formatiranja postaju korisni. Korisniku su za jedan korak blize njegovi podaci, sto je vrlo korisno. I sve sto vidi na ekranu moze da markira i pomocu copy prenese u tekst procesor ili drugu aplikaciju.

Do sada nisam imao problem ni sa forward/back dugmicima, cak su se pokazali i kao prednost.

Najveca prednost kod fat clijenta je bolja kontrola unosa, tj. unosa koriscenjem samo numericke tastarure.
Problem kod unosa web browserom se jos javlja na vise mesta:
- browser pamti history, pa tako po defaultu otvara combobox sa ponudjenim prethodnim unosima, sto moze da smeta gde je unesen veliki broj numerickih vrednosti. Za neke druge aplikacije je koristan, ali za cisto racunovodstvo ga treba iskljuciti.
- imao sam problem kada je ukljucen spell checking u firefoxu, pa su vrednosti u tekst boxovima podvucene crvenom linijom, sto smeta i prilikom stampe.
- potrebni su workaroundi za formatiranja unosa numerickih vrednosti
- problem kontrola submita da ne reaguje na pritisak enter-a

S druge strane korisnik moze da otvori vise pregleda odjednom ctrl-t, bez ikakvih ogranicenja i da brzo seta ctrl-pgup/down, ili otvori vise prozora odjedno, smanji/uveca slova uporedjuje podatke i slicno, u bookmarku sacuva sta mu je interesantno, ili koristi bookmark toolbar kao brze precice (sto vidim kao vrlo laku i za korisnika poznatu metodologiju customizacije menija), sto je vec sve dato po defaultu bez dodatnog programiranja.

Pa rekao sam da je user-friendly ne za programere nego za krajnje korisnike ..
Ako si radio nekad sa krajnjim korisnicima shvatices da im je browser jedini program koji stvarno koriste i mozda neki mail client
i navikavanje i obuka na slozen User interface im uglavnom tesko pada tj. moze da bude skup proces sto mozda vecina klijenata ne zeli


Pa dosta je napredovalo u ovoj oblasti ... pogotovu ako si radio sa ASP.NET-om (ne znam za ostale alate )
Sve vise se web-browser-i primicu desktop funkcionalnosti sto se tice User interface ( i AJAX ulazi u tu pricu)
Ali stoji da neke stvari se sigurno ne mogu uraditi preko Web-a


Da li si cuo mozda za Report Services ???
Ovaj service stampa i prikazuje sve moguce dokumente (Excel,PDF, HTML) i stampa bez problema
i radi podjednako dobro i u Web i u Desktop okruzenju

Po meni najbolje je u ovakvom slucaju projektovati hibridno okruzenje (mesavina Desktop programa i Web aplikacije)
ako se radi o kompleksnim i slozenim kjnigovodstvenim programamima
Neki korisnici ce imati pristup preko web browser-a a neki preko desktop ..sve zavisi od slucaja i namene ..



Ne bih se slozio ... ono sto ne treba da klikne ili neka druga nepredvidiva akcija nece ni videti na HTML strani
to je rekao bih danas lako za izvesti ako je rec o ozbiljnom web developmentu alatu










<sub>[Ovu poruku je menjao deerbeer dana 24.05.2008. u 12:52 GMT+1]

[Ovu poruku je menjao deerbeer dana 24.05.2008. u 12:52 GMT+1]</sub>

Ne kazem ja da knjigovodstvene aplikacije ne mogu da se izradjuju u Web okruzenju - i ja sam pre par godina napravio jednu jednostavnu alatku za obracun zatezne kamate i kursnih razlika u PHP & MySQL varijanti, i doticna se uz vise izmena koristi u nekoliko firmi jos i danas.

A sad da probam sa nekoliko analogija - pet paleta sokova mogu od tacke A do tacke B da prevezem i kamionom, i traktorom, i F1 bolidom, i biciklom, ali i da ih prenesem peske po par litara u svakoj turi. Takodje, mogu da preorem njivu i kamionom, i traktorom, i F1 bolidom, i biciklom, a mogu i sam rucno da povucem plug ako zatreba. Mogu da se trkam po pisti svim ovim navedenim prevoznim sredstvima, a mogu i sam da potrcim pa da tako ucestvujem u trci.

Ako je rastojanje izmedju tacke A i tacke B metar-dva, onda mi je cesto brze & isplativije da na "o-ruk" preguram tih 5 paleta nego da ih utovaram u kamion pa ih ponovo istovaram. Ako tih 5 paleta treba da prebacim po jednu svakog dana, onda je mozda bolje da uzmem neki kombi. Naravno, ako treba sve da prevezem odjednom na veliku razdaljinu, izabracu kamion.

Ako je duzina trkalista jedan metar, ja kao pesak imam dobre sanse za pobedu. Ali ako treba preci par stotina kilometara za sto krace vreme, F1 je pravi izbor. Ako vise ljudi istovremeno treba da predje neku vecu razdaljinu, treba razmisliti o autobusu.

Mogu zivu ogradu seci makazicama za nokte, mogu kukuruz okopavati kasicicom za sladoled, kada zaveje mogu da vucem rasireni suncobran iza sebe i njime pokupim sneg sa trotoara, mogu konzervu tunjevine da otvaram sekirom, itd. Sve je moguce, samo je pitanje kakve su potrebe i mogucnosti krajnjeg korisnika. To sto jedan alat olaksava posao arhitekti ne znaci da ce olaksati i knjigovodji. A sto je jos gore, ono sto je jednom knjigovodji odlicno drugome moze da predstavlja veliku smetnju u radu. Onaj ko ocekuje da ce napraviti univerzalni knjigovodstveni program koji ce zadovoljiti zahteve svakog knjigovodje a uz to da je i lak za koriscenje, bolje neka odmah krene sa prekvalifikacijom u drugu struku - sto univerzalniji program, to je potrebno vise parametara za customizaciju koji ce biti dostupni korisniku kako bi mogli da ga prilagode svojim potrebama, a sto vise parametara to je aplikacija manje "user friendly". Najvise "obozavam" one koji razvijaju GUI a da nisu proveli ni pet minuta pored krajnjeg korisnika i posmatrali ga kako on koristi taj njihov "savrseni" GUI.

Da konacno ovo moje pisanije privedem kraju, nekome ko unosi par stavki dnevno, i racunaljka sklepana od programatora za ves masinu ce odraditi posao, ali onome ko unosi nekoliko stotina stavki svaki dan trebace nesto sto provereno brzo & lako odradjuje posao. Onome ko zeli da dobije logo u boji na odstampanoj otpremnici normalno je da ponudite neko PDF ili web resenje, i tu Clipper i slicne varijante prakticno nemaju sta da traze, mada sam ja recimo i iz Clippera kreirao sarene HTML stranice za prikaz raznih izvestaja na ekranu. Ali onome ko zeli da dobije brz ispis na matricnom stampacu, ne treba nuditi nista sto ne podrzava RAW format, pa sa te strane web bas i nije prihvatljiv. Takodje, nekom operateru koji mora sto pre da "ucekica" hiljade cifara u bazu, sve sto trazi misa ili bespotrebno trckaranje po tastaturi bice cisto smaranje, ali ce zato njegovom finansijskom direktoru biti daleko prihvatljivije da klikne par puta misem i dobije detaljan izvestaj iz te iste baze, nego da se smara cukajuci komande sa tastature. Mislim da ipak treba malo razgraniciti sta je "user friendly" za tacno odredjenog knjigovodju, od onoga sto jedan developer smatra da je "user friendly" za nekog prosecnog korisnika neke prosecne aplikacije. Ove price tipa "moj tata je jaci od tvog tate" su samo prazne price dok ne uporedimo tacno kako se koji "tata" snalazi u nekim konkretnim situacijama - ima li neko zelju & volju da organizuje turnir?

Pre ce biti "Povratak u buducnost II, osveta browsera". Kao i film, bice zabavno gledati, ali nije vise tako uzbudljivo k'o prvi put Prvi deo je bas bio zanimljiv sa sve intranet aplikacijama koje pokusavaju da kontrolisu industrijske robote, u poredjenju sa tim kolosalnim promasajima knjigovodstevna web aplikacija je tek marginalno intersantna. Ne ocekujem box-office hit.

Da mi je neko dao po dolar/evro svaki put kad sam cuo ovakve bajkovite tvrdnje sad bi mogo da se penzionisem sa sve otplacenom kucom. Industrija je toliko nepredvidiva i toliko se krece u nekim besmislenim krugovima da se ni ja posle toliko godina iskustva ne usudjujem da predvidim sta ce biti buducnost, niti sam siguran da uopste postoji ili ce postojati nesto sto ce biti tata nad svim tatama i preuzeti apsolutni primat u svim sferama industrije.

Sta to zapravo cini web neprikosnovenom buducnoscu? I to bas u sferi knjigovodstvenog softvera? Nadam se da nije zato sto si bas ti odlucio da napravis takav program?

Ove dve price prevoz paleta ,trka na sto metara ,deset metara i sledeca dolar /evro nisu mi bas jasne mozda bi bilo logicnije pomenuti Bulovu algebru na kojoj ovo zasad sve funkcionise ali ja nazalost pripadam generaciji koja zna za busene kartice i racunar IBM 1130 ali vidim kojim putem idu nove tehnologije .A kako se prodaju knjigovodstveni programi (sa manje ili vise provizije ) ,ko od knjigovodja stvarno moze da ponudi realan projektni zadatak je pitanje kojim se treba pozabaviti i bilo bi lepo da se i ta prica pojavi na ovom forumu .Jer nije u redu reci web nema sanse u odnosu na Foxpro i zatvoriti ovu temu vratiti se u stvarnost .
Vazan je ovaj detalj po recima iskusnih knjigovodja da analiza vremena izgleda priblizno ovako : 70 % vremena ide na pripremu knjigovodstvene dokumentacije a samo 30 % na unos tih podataka .Tu stupaju na scenu knjigovodstveni programi gde od tih 30 % mogu da donesu neku ustedu u vremenu na racun preglednosti podataka u odnosu na kartonsku karticu .Ovde se ne razmatra ko je napravio program ili ko ce praviti ,da li se moze prodati i da li ce lokalni knjigovodja dati dobru ocenu vec se trazi ideja za neko novo vreme .Sadasnje stanje je poznato u svakoj sredini ima programa i programa za knjigovodstvo a najbolji su oni koji uspeju da se prodaju na razne nacine nezavisno od u cemu su pisani .

Pozdrav!
Zelim da podjelim neka svoja iskustva:
Radio sam na razvoju i izradi jednog web-based sistema za apotekarsku djelatnost (koja je specificna jer se mnogo toga unosi rucno, kalkulacije, obrada recepata, osiguranici fonda i sl. - tj. jako puno podataka za "ukucavanje" svaki dan), i mogu reci da smo vrlo zadovoljni kako se sistem ponasa (gledajuci sa strane klijenata koji su ga odlicno prihvatili, kao i sa strane nas, razvojnog tima).

Ovdje je najveca prepreka bila kako olaksati "unos" sa tastature i prevazici ogranicenja web-browswra, te smo dosta vremena potrosili na Javascript i Ajax, ali na kraju je u "formama" za unos kalkulacija i sl. dobivena interaktivnost koja s moze ravnopravno mjeriti sa slicnim programima pisanim u Dephi-ju i sl.

No sav ulozeni trud i "izgubljeno" vrijeme na prilagodjavanje web interfejsa nam se isplatio u poslednja dva mjeseca, kada je dolazilo do promjena u sistemu zdravstvenog osiguranja, nove liste lijekova i sl. (podrucje Republike Srpske).
Ljepo kad na lak nacin za par sati mozes izvrsiti izmjenu u 10 objekata sa 40-tak klijenat masina, sjedeci kod kuce uz FTP i SSH.

Smatram da i Desktopi Web rjesenja imaju prednosti i mane, ali mislim da ce u buducnosti Web rjesenja uci u mnoge vode gdje ih do juce nismo mogli zamisliti.

Pozdrav!

Cek, nije mi jasno, napravili ste sjajan web interefejs ali ipak izmene radite preko FTP i SSH?!?!?!

Zanima me, da li korisnicima uslovljavate da apliakciju mogu da koriste samo iz jednog veb citaca i to neke konkretne verzije ili vam radi na svemu i svacemu? Da li uslovljavate i OS koji klijenti moraju da koriste?

Inace je lepo cuti da ste uspeli da interfejs dogurate na taj nivo, jeidni problem je ste u desktop varijatni oko toga uopste ne bi ste ni imali posla jer se taj nivo funkcionalnosti podrazumeva, a vreme i resursi se trosie na razvoj aplikacije koja radi konkretan posao.

A cime ti radis deployment aplikacije na server?

Neces verovati, ali preko web interfejsa i to desktop aplikaciju.

Hehe, imaš dignut apache i PHP na svakoj instanci gde ti se vrti desktop aplikacija? :)

Ne. Imam jedan web server na koji se stavi update a onda desktop aplikacije svih korisnika preuzmaju update odatle. Ko nema pristup internetu sa racunara gde mu je instalirana aplikacija, moze i sam da skine update veb citacem pa da rucno instalira...

Da ne pominjem da se ogroman deo aplikacije nalazi u stvari u bazi tako da i nema potrebe da se menja desktop apliakcija nego baza...

Dosta! Dosta! Imaj milosti, imaću noćne more... ;)

Svi moderni ERP sistemi veci deo aplikativnih podesavanja, stampi pa cak i koda (skriptovi) drze u bazi, nije to strasno vec normalno

Voleo bih da se u ovoj temi malo povede računa o korišćenju reči "normalno". :)

OK, sto je meni normalno tebi obicno nije.

Dacu ti jedan primer iz moje prakse gde se pokazalo da je drzanje dizajna stampi bolje u bazi, nego kompajlirano u aplikaciji ili dinamicko ucitavanje iz fajlova - naravno, pricam o klasicnoj windows klijent/server aplikacije:

Sve dizajne stampi koje se koriste u programu drzim u bazi, tako da uz dizajner koji je deo aplikacije postizem da svakoj firmi mogu da prilagodim stampe dokumenata (npr. racuni, predracuni i sl.) ne menjajuci aplikaciju - cime sam otklonio jednu veliku glavobolju koja muci mnoge koji se bave izradom knjigovodstvenih programa. Takodje i sva ostala podesavanja ekrana i standardnih ekrana takodje cuvam u bazi i korisnici sami sebi mogu da prilagodjavaju vecinu stvari tipa: prosiri mi ovu kolonu, hocu prvo ovo pa onda ovo, hocu da ovde to i to pise itd. Takodje u bazi cuvam i odredjene skriptove koje mogu dinamicki da ucitavam po potrebi i prilagodjavam svakom korisniku.

Normalno da je bolje

Ah pošto vidim da si se lično našao prozvan, sad mogu da razumem. :)

Inače, komentarisao sam držanje koda u bazi, ne rasporeda kolona (to radi i svaka veb aplikacija) i sl.

OK, onda je u pitanju nesporazum jer ono sto je @broker naveo: se odnosilo ne samo na kod kako si ti to shvatio, a ja te nisam razumeo (pretpostavljam, tj. pricam u Pedjino ime), a znas vec iz nasih prethodnih dopisivanja da se javljam samo kad me nesto licno pogodi

Poenta i jeste u tome da se aplikacija tako osmisli da je potpuno nebitno da li ce se deo korisnickog interfejsa realizovati kao desktop, kao web ili neka sasvim treca vrsta aplikacije. Za svaku vrstu posla u okviru aplikacije treba koristiti ono sto je najpogodnije, a ne ogranicavati se unapred na neku platformu.



Jablane pitaj boga sta si ti razumeo. :)

Kako recimo tretiras server stored procedures? To nije kod u bazi? Mozda cemo sad da pokrenemo jedan off topic o definiciji izraza baza? :)

Recimo, kao jednu od (pored trigera, oni ipak ubedljivo vode) najzloupotrebljavanijih tehnologija u upotrebi danas. I jedni i drugi se mnogo češće koriste kao 1) krpež za loše isprojektovanu bazu i/ili aplikaciju i 2) slabo baratanje SQL-om, nego za ono za šta su namenjeni.

Ali da ne idemo u OT. Ipak sam ja pogrešno razumeo da deo aplikativne logike čuvaš u tabelama. SP mogu da budu i opravdane. Ponekad.

Pa sad, iako off, moram da prokomentarisem.

Jablane, delimicno se slazem sa tobom ali samo u pogledu buducnosti, nadam se da ce SP izumreti kao i SQL ali namece se jedno pitanje, kako resiti transakcije a da nisu SP?

Ne razumem pitanje.

Zašto su ti stored procedure potrebne da bi imao transakciju? Transakciju možeš da imaš i iz aplikacije.

http://wiki.rubyonrails.org/rails/pages/HowToUseTransactions
http://www.codeproject.com/KB/database/transactions.aspx

Pa naravno da nisu problem, ali cela ta prica sa transakcijama na client strani jos nekako funkcionise dok se komunikacija izmedju servera i clienta odvija brzo, ali cim ti za svaki execute moras da cekas povratnu informaciju a recimo imas ISOLATION LEVEL podesen na SERIALIZABLE, imas da namestis jedan lep lock nad resursima, mislim da ovo cak nije ni problem u web okruzenju (jer client - executing code, i server cesto su na istoj masini) ali u intranet viskom konkurentom okruzenju ovo moze biti veliki impact, naravno, verujem da ce za vecinu stvari ovo biti sasvim dovoljno ali ja licno client side transakcije izbegavam, mozda ne toliko zbog performansi koliko zbog preglednosti. Uzmi za primer ovo na code project-u, ovde imas samo tri klauzule a u mnogo kompleksnijim situacijama ovo je bas tricky:



umesto

Za trigere si u pravu ( i ja ih se klonim ko djavo od krsta :) al za SP ne bih rekao da je to njihova zloupotreba ...
SP su odlicna stvar bas u knjigovodstvenim programima i slicnima gde klijenti s' vremena na vreme traze neke funkcionalne izmene
sto je neminovno jer u pocetku ni sami (klijenti ili knjigovodje) ne poznaju dobro svoju biznis logiku i procese dok ih brojke u aplikaciji ne uvere .
a to ne znaci naravno da je bazu neko lose isprojektovao ili slabo barata sa SQL-om ...

Promenis SP na bazi i nemas potrebu za novim deployment-om aplikacije na recimo 30 klijentskih masina ako je desktop varijana u pitanju
ili ako je u pitanju web-app deployment na server-u
Pa sta ti je lakse ti sam prosudi.
Menjati i build-ovati ceo kod i raditi deployment zbog neke sitne izmene ili izmeniti samo jednu SP na SQL-u

Samo me onda interesuje ako gresim za sta su ustvari SP namenjene ???

Ako drzis biznis logiku (mislim na SP i UDF ) na SQL-u sutra ti nece biti problem da napravis i web-app i mobile-app itd..
i lakse ces da migriras tvoj kod iz postojece aplikacije jer ce se raditi o samo drugom user-interfejsu
(thin-client fat-server arhitektura)

@negyxo: Pa ne vidim neku veliku razliku u kompleksnosti između dva parčeta koda koji si dao, C# sintaksa ima veliki overhead statičkog jezika. Čudo nisi citirao kod sa Rails linka:

:)

A za performanse si i sam rekao - u najvećem broju slučajeva nije problem, tako da u najvećem broju slučajeva nije problem izbeći korišćenje SP.


Pa i taj SP moraš da deploy-uješ nekako, ne? U kulturno automatizovanom sistemu (automatizujete build/deploy procese, jel' tako?), deploy se svodi na dvoklik na exe ili poziv deploy skripte.

Za operacije nad bazom koje se izvršavaju periodično i nezavisno od ostatka aplikacije, za operacije nad bazom koji se sastoje od više koraka, a koriste velike setove međupodataka, za operacije koje zahtevaju korišćenje temp tabela ili kursora... Sve u svemu jako su korisne, ne sporim.

Biznis logika svejedno treba da se odvoji od prezentacione, to nije stvar tehnologije već lepog vaspitanja. Ako hoćeš podršku za različite klijente, svejedno moraš tako pisati aplikaciju, baza tu ne može mnogo da ti pomogne.

Načelno, ima dosta tekstova po netu, pa da ne bih (loše) prepisivao:
http://www.codinghorror.com/blog/archives/000117.html
http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx
Guglajte dalje... Na kraju krajeva, korišćenje ORM-ova (a čak i najzagriženiji kliperaši među vama će pre ili kasnije početi da ih koriste) će ionako istrebiti većinu stored procedura, nema potrebe ja da vas ubeđujem... ;)

<sub>edit: dodao capistrano link
edit: dodao zaključak i linkove

[Ovu poruku je menjao jablan dana 29.05.2008. u 00:12 GMT+1]</sub>

Ali ako taj deploy exe treba da uradis na recimo 30 masina u desktop okruzenju... i moras da ih pokrenes na samoj masini ..
A sa SP se zakacis remote na server(baza radi na TCP-u zar ne ?) i samo kliknes na execute ....

Retke su firme koje imaju tako automatizovan build/deploy proces ...
Video sam jedan primer u Siemens-u gde se instaliranje nove verzije programa na sve korisnicke masine radi sa jednog mesta ...
a i to ume bogami da potraje pola dana ....
Nadam se da sam bio jasan .,..


Mozda nisam bio jasan ..al opet da pojasnim sta sam hteo da kazem ..

Sta ti je lakse da migriras ?
Jedan user interface sa desktop-a na web/mobile aplikaciju ili
da migriras i user-interface i biznis logiku u taj drugi program ..
Pogotovu ako se radi o razlicitim tehnologijama, skript jezicima i razvojnim okruzenjima ...
Baza ce ti pomoci jer se u njoj biznis logika nije promenila i ostaje ista samo se "klijenti" menjaju zato sam i rekao thin-client i fat-server ..

Vreme je za spavanje mora da se radi ... sutra nastavljamo sagu ...

Nije kompleksnost (mada ima i toga malo) nego preglednost i odrzavanje, ovo govorim zato sto sam ja u pocetku tako u .NET-u radio, a i pre u VB 6.0 i nimalo mi se nije svidjalo, tako da je na kraju za mene prelazak na SP bio blagoslov :) Recimo, mene je licno nerviralo razdvajanje SQL u novi red kao i zadrzavanje formata, sto zaista mislim da je bitno, jer lose formatiran SQL ne zelim ni citati, a kada u sve to ubacis jos i komande, apostrofe... zaista je error prone i SP su za mene daleko elegantnije/cistije resenje, ovo su za mene cisto prakticni razlozi. Onda plus, iako moze da se resi sve preko jednog SQL, ne znaci da je najcistije resenje, meni je daleko lepse suvise kompleksan query da razdovjim na vise manjih pa da ih spojim, nego sve da muljam u jedan, opet, ovo je meni lepse i prakticnije a ako neko ima drugi stav meni ne smeta, ja radim onako kako mislim da je lakse.



Ne radim u rails-u. A i moram da primetim da ovde nema SQL, slicno bi mogao da uradis i u C#, kreiras DAL sa objektima balance i acount, dodelis im metod save a taj save na kraju pozove SQL, naravno ruby to malo elegantnije radi pa ne moras da prosledjujes nikakvu transkciju objektima nego sve ide u okvirima do i end.


Ovo niko ne dovodi to u pitanje, bar ne ja (mada ORM je samo jedan deo price, sluzi ce za inteligentnije smestanje podataka, dok za manipulaciju sa tim podacima ipak treba nesto dodatno), mislim da je problem samo u tome sto ORM alati nisu bili bas upotrebljivi u proslosti.

Za Predraga:

Za administraciju i upload izmjena korisnicima koristi se SSH i FTP. Mozda je "zastarjelo", ali provjereno i sigurno radi :).
Kao "server" se podrazumjeva masina u apoteci (CentOS linux ili sl.), i obicno opsluzuje vise client racunara u LAN-u (pultovi za izdavanje, kancelarije, skladiste, pristup preko web-a).
U BiH bi jos uvijek bilo neizvodljivo napraviti neki cisto "centralizovan" web sistem za "obicnog smrtnika", zbog lose infrastrukture i cijene.

Program je trenutno optimizovan za Firefox i Konqueror, ali se uz minimalno truda moze ispeglati za IE i Operu. Radi i sa mobilnog telefona, uz neka ogranicenja zbog slabje podrske za javascript.
Client moze biti bilo koji OS na koji se moze instalirati Firefox, server kao sto rekoh - linux, (kojeg forsiramo i za klijente, zbog licenciranja), mada moze i windows.
Ponekad koristimo "kiosk" skripte za browser i blokadu desnog klika, da nemamo problema sa "back" i sl. dugmicima kod "neposlusnih" klijenata.

Server side programiranje - ColdFusion (dobro i skupo), najcesce free derivati CFML (BlueDragon, Railo), omogucajaju veoma brz razvoj "poslovne logike".
Baza - bilo koja sa JDBC konekcijom (sav pristup bazi je "cist" SQL), trenutno forsiramo MySQL (free, a zadovoljava potrebe).

Svjesni smo bili da je izrada programa u browseru bila komplikovanija , ali kao i svaki pristup ima svojih prednosti i mana.

Pozdrav!

Za galenit-a :

Pogledaj mail....

I šta, sad je to argument, što neko nije obezbedio deploy proces kako treba? Ako si se već uhvatio za desktop aplikacije, šta je problem da svaka instanca po pokretanju proveri da li se pojavila nova verzija na serveru i instalira je ako jeste? Mali milion programa radi na taj fazon.

Pored toga, budi iskren pa priznaj koji procenat izmena na programu možeš da izvedeš samo kroz SP izmene? Daj, argument ti je aj' zdravo.

Kao prvo, biznis logika ne može kompletna da se smesti u DB (mislim, koristiš li uopšte biznis objekte u svojoj aplikaciji, ono, klase Dokument, Otpremnica, StavkaOtpremnice itd?). Tako da ako migriraš sa platforme na platformu (što se dešava minimum jednom nedeljno, jel tako?) svejedno ćeš morati da se oteliš od posla. E da, šta ćemo sa migracijom baze sa jednog sistema na drugi (kad smo već počeli sa "aj' zdravo" argumentima)? Ja u Railsu samo promenim stavku u konfiguracionom fajlu sa adapter: postgresql na adapter: mysql i vidi - sve radi, ništa nema da se migrira...


Ček malo. Šta je problem da pišeš multiline upite u C#? Taj primer iz članka nije ni pisan da bude lep, nego ilustrativan. Kad hoćeš da uradiš kako treba, koristiš parametrizovane upite, baš kao i u SP. Na kraju krajeva, da li ti tvrdiš da je T-SQL bolji i lepši jezik od C#?! Hehe, ajde da ga porediš sa VB6 pa da kažemo da su tu negde, ogavne budževine i jedan i drugi...

Čoveče, opet ti o estetici! Pa nije pitanje estetike, postoje razlozi zašto se upiti pišu kako se pišu, execution plan, optimizacija upita, itd itd. Jedan upit i isti upit podeljen na više malih (ma šta to značilo) jednostavno nisu ekvivalentni, da bi mogao da se vodiš estetikom.

Apsolutno, i to je način kako većina ljudi radi, a sve više se ide i dalje u pravcu ORM. Dakle, bez SP. I sa što manje ručno pisanog SQL-a.

Ne, ORM služi za olakšavanje posla programeru jer ukida (naravno ne može uvek, svuda i do kraja) potrebu da programer piše SQL kod za rad sa bazom i kod za smeštanje tih podataka u biznis objekte. Za manipulaciju tim podacima koristi se naravno klijentski kod. Tipa:

itsl.

Nije nista, samo ovo



Meni se ovo desavalo nebrojeno puta, i jednostvno spajanje stringova izbegavam kada je SQL u pitanju. Ali ovo su sve mali primeri, sad zamisli kada je SQL "velik" 300 linija lepog formatiranog teksta, kako je to lepo onda odrzavati, naravno mozes ti koristiti neki editor, ili namestiti program koji ce ti to sve lepo uokviriti za C# ili neki drugi jezik, ali opet, to je onda igranje copy-paste.



Meni je T-SQL odvratan za pisanje bilo cega drugog osim SELECT/INSERT/UPDATE/DELETE, ali to ne znaci da sad treba osudjivati sve koji su u proslosti radili sve i svasta sa tim istim T-SQL-om, jer tada je to mozda bilo najmanje bolno resenje, cini mi se da ti sve posmatras iz ugla danasnjice, gde imas dosta moce ORM alate, gde imas bolje programske jezike (da, ovde zaista vidim funkcionalne jezike kao num. 1 u buducnosti) da ne kazem da posmatras iz prizme ruby-a.




Ovo boldovano mu dodje isto ;-)

Vidi u nekim situacijama, ja mogu da delim upit na vise manjih jer je tako elegantnije, bar meni

recimo, imam situaciju gde treba da izvuces zarade zaposlenih za tekucu i proslu isplatu



Evo ti situacija kada imas vise manjih pa posle dobijes jedan "cist" query, naravno ti ces moci da kazes kako se ovo moglo napisati kao jedan query ali po meni to ce samo biti nepregledniji SQL. A sto se tice optimizacije, i ovako ce query engine optimizovati code i u vecini slucajeva nece se ni osetiti neki impact na performanse zbog toga.




Ne znam zasto rece ne, kada je otprilike to sto sam i ja rekao samo sam pokusao reci sto krace. Inace zasto mislim da je to samo jedan deo price je upravo taj primer sto si nave. Odakle ti Track.find_by_title metod, generisao ga ORM verovatno, i znaci za svako polje ces morati imati po jedan metod, a tek kombinacije.... no ovde nisam upucen pa ocekujem da ces dati kvalitetan odgovor.

http://www.jameskovacs.com/blog/MultiLineStringsInC.aspx


Naravno... Koristio sam i ja SP (sad ne radim više u istoj firmi, ali sam siguran da bih ih i dalje koristio da sam još uvek tamo, mada mi se život smučio od kopipejstovanih procedura od hiljadu-dve linija TSQL-a) i stvarno umeju da budu jako korisne. Ceo offtopic je počeo mojom tvrdnjom da se prečesto zloupotrebljavaju. Ali tako je sa svim stvarima u programiranju - što više mogućnosti ponudiš, sve će više zloupotreba biti (dovoljno je setiti se kakav OO kod pišu programeri svikli na proceduralni kod itd).


Ono jes.


ActiveRecord (ORM koji se koristi u Railsu) koristi zgodne fazone kod rubija - ti metodi (u kojima figuriraju imena polja) se ne generišu, već se konstruišu on-the-fly: taj metod zapravo ne postoji, a pozive svih nepostojećih metoda (tamo gde bi se statički kompajler bunio) u rubiju obrađuje poseban metod pod nazivom method_missing, koji vidi šta si ti hteo (npr. po čemu si hteo da filtriraš) i od toga pravi SELECT. Užasi promiskuiteta...

BTW, ovaj ceo offtopic ja lično ne gledam kao prozivanje, već priliku da malo evanđelizujem modernije pristupe programiranju.

Pa bas zbog ovog zadnjeg sto si rekao to i jeste poenta
Zasto bih radio ceo build/deploy samo zbog neke sitne izmene koja se tice samo jedne forme ili izvestaja ....
Evo ti primer: Imas SP koje radi neke zatezne kamate ili poreze...
Sutra se donese novi zakon koji menja kamatne stope itd .. i ja zbog neke konstante koje tamo mnozim sa necim treba da buiild-uje
ceo kod i da saljem na server pa onda korisnici automatski da povuku novu verziju ...

I ne kazem da taj automatizam za deploy ne postoji i to nije argument kako ti kazes "Aj' zdravo vec samo koliko je to lakse ili teze od
pukog izvrsenja SP serveru koje se uradi za manje od pola sekunde ....
Ne bih dalje da komentarisem ovo ...
ko procita nek sam prosudi i nemam nameru da se natezem sa tobom i da budem u pravu .....



Naravno da koristim
Pa mozda ne moze cela biznis logika da se smesti u bazu i ne bi valjalo da se cela smesti u bazu
Mislio sam da je bolje da se neki upiti, kalkulacije, itd...
stavlja u SP nego da se takvi upiti i takve kalkulcaje kodiraju kroz stringove u aplikaciji
(SELECT, INSERT ,UPDATE ,DELETE )
jer takvi programi kao sto su knjigovodstveni zahtevaju stalno neko odrzavanje i izmene
Promenis prezentacioni sloj baza ostaje ista ...
i iz novog klijenta samo pozivas te SP sa jednom ili 2 linije koda ....



E slazem se odvratan je za pisanje i veoma je robustan u nekim slucajevima ...
al izgleda da je jablan navikao da minimalisticki pristup kodiranju (nemam nista protiv funkcionalnih jezika oni su buducnost )
pa mu pisanje T-SQL koji ima vise od 10 linija koda tesko pada
a kad dodje vreme da se optimizuje nesto u takvom kodu neces imati sta da optimizujes jer ti je sav kod stao u 10 linija

Meni je jasno da se T-SQL potiskuje sve vise (dovoljno govori pojava i upotreba MS-ovog LINQ-a )
i uopste mi nije zao niti se osecam pogodjenim da bi do kraja svog zivota koristio T-SQL
al videcemo u buducnosti koje su lose a koje su dobre strane toga ...

@jablan

OK, sad smo bar dosli do zakljucka da SP i nisu tako lose za stvar koju su obavljale u proslosti.

Inace, to sto ruby radi i nije lose, mislio sam da ORM generise, sto sam vidjao da rade u ovim statickim jezicima i meni je to ruzno, jer mozes dobiti overhead u code-u, prakticno se desi da od se generise gomila metoda od kojih se samo 20% koristi. Mada imam jedno pitanje, sta se desi ako napises :



Namerno sam izostavio e iz 'find_by_title'.

BTW za BTW, nije da sam se nasao prozvan, ali vecina ljudi ne voli da cuje kako imaju potpuno idiotsko resenje samo zato sto se pojavili "New Kids On The Block", tj. neki novi hype pa makar to i zaista bila superiornija tehnologija.

Zašto ne bi? Zato što si navikao da ti je deploy noćna mora. Bitno je da je jedostavan, a da li traje pola sekunde ili pet minuta nije uopšte bitno.


Ne menjaj teze, jesam li ja negde rekao da konstante treba da se hardkodiraju? Konstantu naravno držiš ili u polju u bazi (dakle, ne ni u SP!) ili u nekom konfiguracionom fajlu.


Rekoh već da nema potrebe da izmena aplikacije bude išta komplikovanija nego izmena SP.


Netačno. SQL mora da bude onoliki koliki mora. Ako ima par JOIN-ova, naravno da će biti dugačak.


Ja bogami nisam došao do tog zaključka. Zaključio sam da su SP dobre za neke stvari, bile i ostale. Ali ne za kompenzovanje lenjosti ili nestručnosti. :P


Ja ne vidim ništa loše u ovom, možda nešto propuštam? Tih 20% koje koristiš neće sporije raditi zbog onih 80% koje ne koristiš. A taj generisani kod ionako nećeš ručno da održavaš i menjaš.


Desi se runtime greška sa odgovarajućom porukom, to je jednostavno način kako funkcionišu svi dinamički jezici. Mana što kompajler ne može da nađe neke takve greške kompenzuje se mnogim prednostima na drugoj strani.

Ne menjam teze vec sam ti dao banalan primer i ne moraju da budu konstante
vec moze da bude i neka logika koja se menja (npr. pojave se jos 2 IF uslova umesto jednog)
Ne znam sto se hvatas bas za detalje


Nisam navikao da mi je nocna mora ..
vec sam proces novog deploy-a a kamoli build-a je besmislen za takve sitne stvari
da bi smarao korisnike svaki put sa novom instalacijom
Nova verzija (deploy) treba da se povuce sa servera samo kad su krupne izmene programa u pitanju
(na primer : sa verzije 1.0 na 1.5 )


Hahaha :) Pa ti ponovo radi build/deploy na server zbog pravopisne greske :)



Skreces sa teme ... pogledaj ponovo ceo moj citat a ne samo njegovo parce tj. recenicu ...


E lepo si to rekao... upravo sam se zbog toga i ukljucio u ovu raspravu ...


Eeeeeej ljudi predlazem jablana za novog mesiju ES foruma iako takve funkcije za sada nema ...

Toliko od mene ... ne bih da se ova tema pretvori u neki "Krstashki Rat" :)







_{[Ovu poruku je menjao deerbeer dana 29.05.2008. u 13:00 GMT+1]}

Bah, moderno. Osveta SmallTalk-aša ako mene neko pita. Najpre su nas ojadili design patternima, pa Javom, a sa Rubijem su skoro stigli nazad do SmallTalk-a. Odo ja da obnavljam asembler ;)

To se zove retro, dragi tata. Nađemo se kod fortrana. ;)

Da li si nekada radio softver koji ima recimo red velicine hiljadu korsinika a svaki od njih od 20 do 200 racunara, i jedno 20$ njih radi 24h dnevno i uz to su rasrkani kojekude i jos imaju razna pravila o korsicenju svojih internet linkova da ne daju ni muva da im sleti na ruter a kamoli da neko spolja pristupa njihovj mrezi?



Nemoj bukvalisati. Covek je mislio na neki izraz koji mora da se promeni jer je propis promenjen, a vrlo cesto nije takobanalna izmena. Uz to, sta ako imas apliakciju koja podrzava i web, i mobilne telefone na sve moguce nacine i ko zna sta jos sve? Je l' i za njih treba pisati aplikaciju i menjati svaki put kada se nesto promeni?



U knjigovodstvenim aplikacijama je komplikacija u definiciji.

Uvek je zanimljivo slusati razne ideje ljudi koji po svemu sudeci malo prakse imaju pa im sve ide kao po loju i bas onako kako su zamislili. A kad ih bacis u realan svet, vide da je teorija jedno, a u praksi se sve odvija drugacije. :)

Ehh.. da vidis kakva je restriktivna securtiy politika u Siemens-Bg -u za koji sam radio 2 programa ..
Nisam smeo da ubacim USB flash u masinu (i pored svog poverenja koje su imali u nas)
a da nisam dobio dozvolu glavnog Admin-a za tako nesto :)
a kamoli da radim deploy i ostala cuda ili cak da im predlazem bolji automatizovani sistem za instalacije
i pored toga sto oni imaju svoj sistem koji vazi za celu korporacijsku mrezu.

@jablan
Svaki klijent ima svoje zahteve i uslove i ti moras da se prilagodis takvom sistemu (teorija je jedno a praksa drugo )
inace od posla i para nema nista jer ce naci drugog koji ce im to ispuniti.
Jednostavno to su zakoni trzista a ne novih super-modernih tehnoligija ...

To je sad klasika za vece, narocito strane kompanije, nova stigma tih security experata je da je zaposleni najveci neprijatelj i shodno tome se firma zateze iznutra. Na stranu sto to delimicno jeste tacno, realnost je da je jedina zastita sistema od zaposlenih da se zaposlenima potpuno zabrani pristup kompjuterima (cudi me da to ne predlazu). Imali smo jednu takvu prezentaciju gde smo iskodirali trojanca kao watermark i pustili u sistem spolja preko emaila, unutra dekodirali preko super zasticene radne stanice i startovali, onda je trojanac skinuo bootimage preko HTTPa, modifikovao boot i digao surogat OS koji je iz sada nezasticene particije pokupio SAM fajlove i dosao do domain admin naloga koji su "experti" koristili pri ghostovanju masine i tu su nas zaustavili . Jednostavno nema bulletproof zastite, postoje samo ova zatezanja neukih admina koji su to procitali u ISACA ili slicnoj dokumentaciji i prosipaju mudrost zaplasenom visem menadzmentu. Realnost je da su sve te kompanije koje limitiraju svoje radnike i koje sam ja video zabelezile drastican pad produktivnosti u R&D i inhouse odeljenjima naspram kompanija koje fokus stavljaju na pojacanu kontrolu autorizacije korisnika u kriticnim i produkcionim podsistemima umesto na krajnjim boksovima. Medjutim to za ovu temu nije vazno, cisto sumnjam da male i srednje kompanije imaju zaposlenog CISM ili CISSP eksperta koji im odredjuje dal smeju da ubace flash u USB.

Nemaju. Oni jednostavno odvoje (necu reci kupe, psoto je to i mnogima problem) jedan racunar koji spoje na Internet, a ne umrezavaju ga :)

Jos jedan podatak u vezi ovoga sto je mmix ispricao :
Korporacijska mreza Siemens ima cak backend ekipu hackera (ili ti experata za security)
na nivou korporacijske mreze koji testiraju tj. vrse namerne ucestale napade na sistem i podnose izvestaj 1 ili 2 puta godisnje
o stabilnosti i sigurnosti celog sistema i mreze sto administratore drzi dovoljno budnim da se ne napravi neki propust.....

Naravno da mala i srednja preduzeca nemaju takav razvijeni sistem
ali sigurno imaju svoja pravila koja vaze unutar njihove mreze ....

Ma i to je smesno isto, ti ne mozes da znas koliko ti je frontend prema internetu siguran dok te grupica rusa ne uzme na zub i pokusa da te provali . To sto oni interno djoraju jedni ssa drugima ne mora ni izdaleka da znaci da je sigurnost dobra, postoji veoma malo kvalitetnih ethical hackers ekipa i oni kostaju ruku i nogu. A sve i pored toga niko od njih ne moze da proveri da li dobrila iz finansija ima malu crnu knjizicu u kojoj ima zapisano 11 lozinki koje vrti u krug jer joj je tesko da svakih 14 dana pamti novu kripticnu lozniku od 15 slova sa bar 3 non-alfanumerika i koja ne sme da se ponovi bar deset menjanja. U toj istoj firmi koju sam napomenuo gore smo posle radnog vremena fore radi obisli sve stanice na spratu i nasli nekoliko radnih stanica kojima je lozinka bila napisana na sticky papiricu zalepljenom ispod tastature .
Toliko o sigurnosti, al sad bas odosmo u offtopic. Sto se ove teme tice, to je stvarno nevazno i nepotrebno za razmatranje jer su vam male sanse da prodate knjigovodstveni softver konglomeratima kao sto je Siemens, to su visemilijonski dilovi sa jakim imenima pri cemu je knjigovodstveni deo samo malo parce cele ERP price koju ta firma kupuje. Tu igru igraju MS, Oracle i ostali, ne oni koje interesuje koji programski jezik je dobar za pravljenje knjigovodstvenih programa. I ovo ne mislim u derogativnom smislu vec u smislu troskova i resursa (da ne pominjem razvoj brenda) za izradu, prodaju i odrzavanje takvih sistema.

Ne postoji 100% bezbedan sistem i na to nema smisla trositi reci ....


Naravno da je tesko prodati kad siemens ima vec instaliran SAP (milonska suma),
ali nemaju bas sve module iz SAP-a tako da iz cisto ekonomskih razloga
pribegavaju kupovini programa po narudzbini tj. iz domace radinosti ...


Hehe :) u pravu si ..al to spada vec u social engineering ..
a tek koliko takvih knjizica i papirica imaju knjigovodje :)


Stvarno je offtopic ...da ne duzimo pricu o ovome ...

Što kaže naš narod, ponuđen ko počašćen.

Ma zaboravi sta sam hteo da kazem :) :)

Evo par linkova malo da se osvezi tema :
CodeProject: NHibernate Best Practices with ASP.NET, 1.2nd Ed ...
http://www.codeproject.com/KB/...e/NHibernateBestPractices.aspx

David Hayden (procitati pod conclusion )
http://davidhayden.com/blog/dave/archive/2005/09/30/2493.aspx

Generics & Unit Tests
http://geekswithblogs.net/Billy/archive/2006/03/11/72094.aspx

Mozda je ovo sto cu reci preambiciozno, ali mi se cini da bi za sistem za racunovodstvo dobro pasovala neka platforma bazirana na "rules" (kao u "business rules"). Radi se o domenu koji je kompleksan i gde se pravila cesto menjaju...

Veci deo vasih predloga i polemika bas i nisam previse razumeo, jer nisam u tim vodama. Pokusao sam sa Microssoft Accesom i neke jednostavnije programe bih mogao odraditi. Za neki kompletniji racunovodstveni program ne bih bas uspeo jer bih imao muke da uradim neku dobru orvu stranicu interfejs i povezem sve.
Skinuo sam sa neta i neke programske jezike ali to ako nekad bas budem imao viska vremena. Sada ipak radim nesto.
U svakom slucaju hvala na savetima.

Probaj delphi.

Quick Basic

Ozbiljno il se sprdas :) Vidjao sam svakakve al jos nisam video nijedan u quick basicu :)

Ma, zezam se.