Új hozzászólás Aktív témák
-
Gregorius
őstag
A GPL-nek pont az a lényege, hogy használata esetén az új forrást is GPL alatt kell kiadni, továbbadni.
Ha a GPL-es cucc forrásához is hozzányúlsz. Viszont ha egyszerűen komponensként felhasználod, akkor csak mellékelni kell a vonatkozó komponensek licencét és a többi maradhat zárt fejlesztés.0-ról, először alaposan átgondolva, megtervezve kezdjenek neki
Mint azt a sírással küszködve szoktam mondogatni: van a jól átgondolt, alaposan megtervezett és validált rendszer, meg van az a rendszer, ami határidőre, olcsón készen van.
Tendertől és bundától függetlenül.Hiba volt Delphi-ben írni a windowsos változatot, rögtön Java-ban kellett volna, akkor lehetne ugyanazt a forrást használni.
Most egyrészt mondhatnám, hogy később könnyebb okosnak lenni, másrészt azért a Java is elég sokat fejlődött az utóbbi X évben, hogy desktop vonalon is komolyan lehessen venni.Hiszem, hogy hozzáértéssel kettő hét alatt meg lehet egy ilyet írni, ennek ellenére hónapok alatt nem sikerült normálisan
Nem lehet. Hidd el. Két hét alatt még odáig sem lehet eljutni, hogy a kedves fejlesztőcsapat lezsírozza a megrendelővel, hogy tulajdonképpen nagyvonalakban mi is a feladat, mik a követelmények.meg lehetett volna csinálni .NET-ben, vagy már eleve Javaban, platformfüggetlenül
2003-ban a .NET sem volt olyan állapotban, hogy egy ilyen jellegű fejlesztést csak úgy rá mertem volna bízni.Mi mást csinál a program, mint beviteli mezőkben értékeket vár, majd azokat ellenőrzi és kimenti az adatokat egy adott formátumú fileba?
Tudod ha ezt úgy kell csinálnia, hogy univerzálisan beletolsz egy nyomtatványleírást, ami a mezőkön túl tárolja az a+b=c jellegű kifejezésektől a tudjaistenmilyenbonyolultakig az összefüggéseket, validálási szabályokat is, és a program ezt egyből tudja használni, akkor a probléma hirtelen két nagyságrenddel bonyolódik.miért nem lehet a feltöltendő file és az űrlapok formátumát nyilvánosan elérhetővé tenni, és akkor lehetnének open source free programok a kitöltésre, feltölteni meg az ügyfélkapun keresztül lehetne,
Mert ha a 3rd party program nem tökéletesen végzi a dolgát (és erre a szoftveriparban 99%-nál nagyobb esély van attól függetlenül, hogy open source vagy nem), akkor kész a support nightmare.Miért kell egy nyomtatványkitöltő programot kizárólagosan házon belül fejleszteni?
Sokba kerül a nemlétező dokumentáció emészthetővé tétele illetve nyilvánosságra hozatala.Én legalábbis szívesen kifizetnék 1500 Ft-ot, amibe egy USB-s titkosító kulcs kerül.
Support nightmare. Az USB eszköz elveszik/megrongálódik/gyári selejt/ellopja a postás és a kedves júzer máris megvan lőve. Ez max akkor lesz majd alternatíva, amikor a személyink is chipkártya lesz. Persze többszintű hitelesítést ettől még használhatnának.[ Szerkesztve ]
-
Gregorius
őstag
képtelenek voltak megírni a leírást értelmező programot. Azért lássuk be, hogy ez manapság már nem szabadna, hogy ekkora gond legyen!
Ezt a problémát nem kellene lebecsülni. Lehet választani az általad javasolt böngészős megoldást, az viszont imperatív (most itt valamilyen szkriptben gondolkodom), ergó bonyolultabb (több hibalehetőséget tartalmaz) egy rendes eseményvezérelt nyomtatványt összehozni, ha egy hivatalos nyomtatványleírásban hiba van, az mindenkinek az életét megkeseríti, és nem éppen a biztonság csúcsa egy általános szkript értelmezőt beépíteni egy ilyen programba.
Ha deklaratívan állunk a problémához, akkor a nyomtatványok jóval egyszerűbbek, átláthatóbbak, könnyebben összefércelhetőek - gondoljunk bele hány nyomtatványt is kell kidolgozni és milyen rendszerességgel, és ehhez épp elég nagy feladat a vonatkozó jogszabályok értelmezése -, viszont maga a program vért izzad, amíg egy sima szövegből felértelmezi a kifejezést, összepárosítja az egyes tokeneket a cellákkal, eseményekkel, paraméterekkel, az egészet funkcionálisan összedrótozza, és esetleg rendes tempóban működik is a dolog. (De ha nekem kellene megcsinálni, még ennek ellenére is a második megoldást választanám.)Aha. Na ez gáz ha így van, hogy egy állami (értsd, az én pénzemből történő) fejlesztés nincsen rendesen dokumentálva.
Ez nem állami specifikus. Mint írtam feljebb, van a rendesen tervezett és dokumentált szoftver, meg az olcsó, határidőre elkészülős szoftver. A belső dokumentáció általában silányabb minőségű, de adott esetben ez is megteszi. Az adott fejlesztők viszont vastag implicit tapasztalattal rendelkeznek azon a területen, szóval dokumentáció ide vagy oda, költséges a személycsere a projektben. Amennyire meg tudom ítélni, ez tömeges jelenség az iparban. Ezért van még mindig annyi DOSos program a nyilvántartásban (de már olyanról is hallottam, hogy egy hapsi egyszer összerakott valamilyen frankó számoló xls-t, ami azóta a kérdéses cég első számú kincsévé lépett elő és nem mernek hozzányúlni). Egyszer valaki régen frankón megírta, aztán az a valaki elkallódott. És könnyebb megoldani, hogy a mostani környezetben a régi doszos csoda fusson, mint modernizálni az egészet.De ha már Java/Delphi/akármi, ennyi erővel mehetne az egész php alapon is, szerverről futtatva, kétségkívül eléggé erőforrásigényes lenne a doog
Így is agyon van terhelve az egész a határidő előtti éjszakán. Ha áttolod szerveroldalra az egészet, akkor teljesen lehalna. (Az esetleges támadásokról nem is beszélve.)De elég lenne egy böngésző és nem kellene rágódni, hogy milyen rendszeren működik/nem működik.
És akkor jönnének a cross-browser problémák, mert a fejlesztő IE-re írta meg...Az USB kulcs helyett írj bankkártyát. Máris nem olyan vészes, ugye?
Az is ugyanúgy elveszik/megrongálódik/gyári selejt/ellopja a postás. Egy ilyen kártyával értékesebb információkhoz lehetne hozzájutni, mint az átlagember átlagbankszámlájának átlagtartalma. Ráadásul rontja a helyzetet, hogy külön olvasó kell hozzá, vagyis nem biztosítottak a feltételek. Kicsit még terjednie kell a SmartCard mizériának, mire ebből alternatíva lesz. -
Gregorius
őstag
A dokumentációnál nem érdekel, hogy máshol is ez van. Az a cég pénzéből meg, ez meg az enyémből, ezért ha sehol máshol nem, az állami megrendelésű cuccoknál az alapos dokumentáció alapkövetelmény kell legyen. Mondom és követelem ezt mint egyszerű adófizető állampolgár.
Csak a többi egyszerű adófizető állampolgár, akinek szintén a pénzét költik szépen felhúzza a szemöldökét, hogy miért költenek extra papírmunkára duplaannyit az ő pénzéből.nem életszerű, hogy egyszercsak délután fél kettőkor fejemre csapok, hogy "basszus, az ügyfélakapu kulcs, mennyire kellene most!".
Az életszerű az, hogy a hivatalos határidő előtt pár órával kezd el kapkodni az ember, és akkor derül ki, hogy valami nem jó.Ja értem. Egy sokmillió embert és vállalkozást érintő, országos, sok-sokmillióba kerülő fejlesztésnél tényleg ez legyen a lényeg. Sianis szerintem nem arra gondolt, ahogyan te fejlesztesz (?) rendszereket.
A gyakorlati tapasztalatok ezt mutatják. Valamikor jópár évvel ezelőtt Állambácsi csináltatott egy tankönyvrendelő rendszert, amiről az éles üzembehelyezés után derült ki, hogy a nyomtatásokban elfelejti az utcaneveket megjelenítei, vagyis gyakorlatilag a célra teljesen használhatatlan volt.
Egyébként nem véletlenül vannak ilyenek: [link]Ahhoz már akkor is okosnak lehetett volna lenni, hogy a Delphit ne vegye komolyan valaki. Különösen, ha már akkor megfogalmazódik követelményként a többplatformos működés.
Mint azt egy volt tanárom megfogalmazta: atombiztos pécét nem építünk, kivéve ha a megrendelőnek pontosan ez az igénye. A megrendelőben pedig nem fogalmazódott meg időben követelményként a többplatformos működés.Persze azzal a fenntartással, hogy ez nettó két hét, tehát nem számít bele az, hogy felteszek egy kérdést, és az illetékes elmegy két hónapra síelni. Ha egy ilyen "bonyolult" szoftver esetében neked nem megy a megrendelővel való egyeztetés, az már a te problémád.
Te be tudnád adni a megrendelőnek, hogy habár fél évet csúszott a projekt, a nettó két hetes határidőt tartani tudtuk?
Az olyan esetekről nem is beszélve, hogy a megrendelő válaszol a kérdésedre és egy hét múlva meggondolja magát.Az űrlap azonnali validálásáról: Ott van erre a PDF űrlap platformfüggetlenül, installálás nélkül, biztosan hallottál már róla, ha más megoldást te nem ismernél.
És szerinted ezt mennyi idő volt összehozni az érintetteknek a rendes szoftvert hozzá (Adobe és tsai)? És az APEH melyik alkalmazottja fog tömegesen PDF-es űrlapokat profin összeszerelni?Feltöltéskor simán lehet validálni. XML-nél eleve csak olyannal kell foglalkozni, ami konform a megadott style sheethez képest. Nem valid az XML-ed? Haggyámá.
Azt hiszem hozzáértésedről kiválóan árulkodik, hogy kevered a stylesheet-et a schemával. A schema egyébként leginkább csak szintaktikus ellenőrzésre használható, tartalomvalidálásra kevésbé.Dokumentálás nélkül ki vette át a megrendelő részéről?
Kérdezd meg Állambácsit. A minőségi dokumentáció költségnövelő tényező, innentől kezdve a politikai döntés sem kizárt. Plussz sem az államnak sem az átlag adófizetőnek nem érdeke, hogy többféle szoftverrel lehessen töltögetni az űrlapokat.Luciferchez csatlakozva: És ha a fejlesztőt (mert egy ilyen hatalmas munkán valószínűleg nem egy többszáz fős fejlesztőlabor dolgozott) elcsapja a villamos?
Erre már fentebb válaszoltam.Amúgy meg egy normális rendszerben dönthetek, hogy mit akarok. Chipkártyát (és akkor kifizetem/telepítem hozzá az olvasót), vagy USB kulcsot.
És akkor a te adódból lehet fizetni a chipkártya problémákat támogató support teamet meg az usb kulcsot támogató support teamet is.Különben meg az általad állandóan emlegetett support nightmare nem létezik.
Igen, minden bizonnyal azért gyárt annyi nagy cég olyan sok különböző linux disztribre szoftvert, mert úgy imádják mindegyikkel letesztelni a rendszert...Aki nem ért hozzá, az majd használja a mainstream, windowsos desktop cuccot.
Szóval akkor mégis elég nekünk a paracssoros abev linuxra?Nem akarlak megzavarni, de egeszen pontosan igy van megcsinalva, mivel ilyen mennyisegu nyomtatvanynal ennel egyszerubb nincs.
Azért kezdtem úgy a vonatkozó bekezdésemet, hogy nem szabad lebecsülni a probléma méretét, meg ilyeneket mondani, hogy öt perc alatt összehozható nulláról a rendszer.
[ Szerkesztve ]
-
Gregorius
őstag
Olcsóbb most dokumentálni, mint 5 év múlva újra írni, mert a fejlesztőcsapat szétszéledt. Hm?
Erről a fővárosi kátyúzás jut eszembe, amiről már évek óta kórusban zengik, hogy kicsit többet kellene rááldozni, a kicsit drágább technológiát kellene használni, és akkor esetleg nem kellene havonta megismételni a műveletet.Ne keverd a szezon a fazonnal. Eddig arról írtál, hogy elveszti, stb, nem pedig arról, hogy nem megy a rendszer.
Most sem arról írok. Pár órával a határidő előtt derül ki, hogy nincs kéznél, elveszett vagy egyszerűen nem működik a kulcs. Amíg nem muszáj a bevallással foglalkozni, addig a többség nem is fogja megnézni, hogy minden megvan-e hozzá.Na ne idegesíts! Esetleg az, amelyiknek ez a munkája? Na? Miért, most ki heggeszti össze az űrlapokat?
És gondolod, hogy fizet az APEH saját PDF szakértőket, akik éjjel-nappal kalapájlák az űrlapokat, amikor a jelenlegi formátum keretei között jóval egyszerűbben, kevesebb szakértelemmel össze lehet állítani egy űrlapot?Ha az átlag adófizető odatekint a formálódó MS szerződésre (no MS flame please), akkor lehet, hogy érdeke lesz. Hm?
Nem értem az összefüggést. Az átlag adófizetőnek az MS szerződés költségvonzataival van problémája ebben a témában, nem a választékkal. A technológiailag jól informált adófizető sajnos még nem nevezhető átlagnak.Egyreszt, az atlag adofizeto nem huzza fel a szemoldoket, mert nem is tud rola (ha meg jol tajekozott, akkor meg azert nem (vagy nem ezen)).
Az átlagadófizető tud róla, mert a költségvonzatot (és csak a költségvonzatot) alaposan az orra alá dörgölik minden pártközi összetűzésben, amiből politikai tőkét lehet kovácsolni. Lehet, hogy azt sem tudja, hogy mi a Java, de azt tudja, hogy a kedvenc párt szerint a megoldás sokba került és ezért az ellenpárt a felelős.Masreszt meg igazabol nem az lenne a feladata az APEH-nek, hogy programot irjon, hanem az, hogy adjon vmi interface-t. A programot majd megirjak masok.
Egyszer meg kell írni a programot, különben nincs garantált "júzer-frendli" e-bevallás. Akkor meg ha úgy kell megírni, hogy használható publikus interfész is legyen, akkor az többe kerül.Harmadreszt meg a normalis dokumentacio azert is fontos, hogy ne legyen egy bandahoz kotve, hanem amikor akarja, akkor at tudja adni a fejlesztest vki masnak.
Ehhez kétség nem fér, csak amikor a fontossági szempontok közé bekerül a pénz is, akkor a felsővezetés hajlamos krónikus rövidlátástól szenvedni. (Ld. még fentebb a kátyúzásnál)A schema egyébként leginkább csak szintaktikus ellenőrzésre használható, tartalomvalidálásra kevésbé.
Szerintem nézd meg még egyszer, mit tud az XML Schema.
Szerintem nézd meg a szótárban a "használható" és a "képes" közötti különbségeket.
Az a sajnálatos helyzet, hogy gyakran fordul elő az a jelenség, hogy egy webservice XML sima text node-jába belehánynak egyébként strukturált adatot, amit a validálásból egyszerűen lustaságból (szorít a határidő, nem fizeti meg senki, stb...) kihagynak (pedig ez még csak szintaktikus ellenőrzés lenne).Egyébként megmondaná nekem valaki, hogy származtatott adatokat mi a büdös halálnak kell "kitölteni"?
Gondolom mert nem akarnak minden űrlapot mindig végigszámolni megnyitáskor. Fene tudja, hogy az űrlapfeldolgozó milyen tempóban dolgozik...[ Szerkesztve ]
-
Gregorius
őstag
Tehát egyetértünk, csak te úgy véled, ez egyszerűen így működik és kész. Én meg szeretném hinni, hogy ha lassan is, de a szakmai közösség nyomásával lehet ezen változtatni, el lehet érni, hogy ésszerűbben, hatékonyabban menjenek a dolgok, még ha az látszólag rövid távon költségesebb is.
Mondjuk inkább úgy, hogy pesszimista vagyok, és nem vagyok róla meggyőződve, hogy a szakmai közösségnek van akkora érdekérvényesítő képessége, hogy ebben a helyzetben lényeges előrelépéseket érjen el.Ha az átlag adófizetőnek elmondjuk, hogy akár már 5 éves távlatban is drágább egy dokumentáció (vagy mondjuk az említett interface) nélküli rendszer, mint egy kezdetben drágább, de jól dokumentált (interface-szel ellátott), akkor érdekelni fogja.
A probléma ott van, hogy 5 éves távlatban még a dokumentált rendszer is könnyen elavultnak számíthat azon egyszerű okból, hogy közben merőben más igények merültek fel, és lehet újragondolni az egész rendszert. A doksiba/interfészbe ölt pénz egyáltalán nem biztos, hogy megtérül.
Tendertől és bundától függetlenül.
Az olyan esetekről nem is beszélve, hogy a megrendelő válaszol a kérdésedre és egy hét múlva meggondolja magát.
Új hozzászólás Aktív témák
it Olvasónk szerint a Java-alapú program fejlesztésekor sok hibát követtek el. A rossz program olyan, mintha nem is lenne – írja.
- ASUS ROG STRIX Z690-A DDR4 White fehér garanciával
- Nem használt, hibátlan cuccok eladása brutálisan áron alul - kérlek olvasd el a teljes hirdetést.
- DELL OPTIPLEX 3020 SFF PC, i5-4570 CPU, 8 GB DDR3 RAM
- Szép! HP ZBOOK 15 G6 Tervező Vágó Laptop -60% 15,6" i9-9880H 32/512 QUADRO RTX 3000 6GB FHD
- EVGA GeForce FTW3 ULTRA GAMING RTX 3080 Ti 12GB GDDR6X 384bit videokártya
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen