Új hozzászólás Aktív témák
-
joghurt
addikt
Jaja. Az Apeh szempontjából annyi a lényeges, hogy azonosított módon megkapjon szabványos formátumú adatokat. Miért nem lehet kirakni mondjuk az szja XML leírását? Aztán tök mindegy, hogy ki milyen programmal tölti ki. Írhat rá akár programot is, vagy akár Notepadben is kitöltheti a saját XML-jét.
A tej élet, erő, egészség.
-
joghurt
addikt
Amíg a magyaroszag.hu-n egy gagyi jelszó ismeretében hozzáférek bárki összes ügyéhez, addig talán még ez az informatikai fejlesztés a legkevesebb. Én legalábbis szívesen kifizetnék 1500 Ft-ot, amibe egy USB-s titkosító kulcs kerül. Cserében biztonságban tudhatnám az adataim.
A tej élet, erő, egészség.
-
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. -
ddoboz
csendes tag
Jó, nem ugyanazok csinálják, akkor miért kérik számon a nyomtatványkitöltőn, hogy szar benne az ellenőrzés?
Március és december között az a sok ember gondolom az új adótörvényeket vitatja meg
Hűha, a windowsos verzióból meg biztos azért kell évente (sőr gyakrabban) újat kiadni, mert olyan fajinul független a program a függvénydefinícióktól, meg az egyéb változó dolgoktól,
Az időket azért írtam, mert - ellentétben a 2 hetes határidőt emlegető valakitől - szoktam gondolkodni. Az persze benne van, hogy hibás következtetésre jutok néha.
Az os-hoz meg annyi köze van, hogy sztem túl sokat vár el ez a közösség az apehtól. Kérje a beküldendő formátumot és kész. De 1 csomó ember gondolom fáradságos munkáját (ellenőrző fv-ek) sztem túlzás, bár lehet, hogy tévedek.
+ ha os. lenne a kitöltő, akkor még az a pici hivatkozási alap is ugrana, amit eddig jelentett, hogy az abev szerint hibátlan volt. (jó tudom, hogy ez nem volt garancia, de mégis számított sztem) -
ddoboz
csendes tag
Ez a legkevesebb?
Egy adóbevallást segítő programban az a legkevesebb, hogy jó-e az ellenőrzés vagy nem? Vagy csak azt nehezebb fikázni?
Mert szerinted mi? Az hogy simán települjön linux alá?
Egyébként valahol írta valaki, hogy akkor meg a "nem linux használó" közösség háborog majd, hogy az ő adóforintjukat pocsékolják pár ember hobbijára. Ha majd megjelenik vhol 1 ilyen fórum, akkor meg az apeh csak hátradől és röhög.
03-12: sztem ezeknek az embereknek semmi közük ahhoz, hogy mikor és milyen adótörvényt fogadnak el. Gondolom 1etértünk abban, hogy mindenkinek jobb lenne évekre előre tervezhető adótörvény, ahol csak az összegek, %-ok változnak.
Az elvárást pedig nem a működőképes programra értettem, az természetesen teljesen jogos (csak az 1. pontban írtak alapján azt nem tudom Te mit értesz működőképes program alatt)
hanem arra, hogy sztem túl sok információt akar. Bár ez más, szerencsésebb fejlődésű országokban asszem teljesen magától értetődő lenne.kicsit más: ezt az "én adómból..." dolgot tudod hányszor hallottam már - és legfőképpen olyan emberek szájjából akik életükben 1 fillér adót sem fizettek.
Ne vedd magadra, csak 1 megjegyzés volt. -
ddoboz
csendes tag
Igen ez lenne a feladata egy kereskedelmi szoftvernek. De az apeh által kiadottnak szerintem az a feladata, hogy az apehos nyomtatványokat pontosan megjelenítse, ellenőrizze, és az adózónak ne legyen belőle semmi hátránya ha megbízik benne.
Ezer mezőből 1 prompt meg egy input véletlenül 1másra lóg. Skandallum, kirúgni az összes pancsert!
A vágólap tényleg gáz, de azért nem hiszem, hogy emiatt szar az egész.
De folytatom: "internetbögésző" volt az 1ik cimke, a szervíz sztem rövid i. De nem hiszem, hogy ezek olyan lényegesekA megjegyzés nem csak úgy jött, Te hoztad föl. Most már megnyugodtam, hogy Te is befizető pozícióban van
Itt legalább elkészült valami, ha nem is tökéletes (<-> pl. Korm. 1/4)
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.
- Xiaomi Redmi 9 64GB, Kártyafüggetlen, 1 Év Garanciával
- Dell Latitude E7450 Full i7-5600U, 16GB DDR3, 512GB SSD, FHD IPS, Nvidia, HUN Vil.Bill. Új
- Dell Latitude 7310 i7-10610U, 16GB DDR4, 512GB NVMe, FHD IPS Privacy, HUN Vil.Bill, NBD, Új Állapot
- Dell Latitude 7310 2in1 Alu i7-10810U, 16GB DDR4, 512GB NVMe, FHD IPS Touch, HUN Vil.Bill.
- Dell Latitude 7420 Aluminium i5-1145G7, 16GB DDR4, 512GB NVMe, FHD IPS Touch, HUN Vil.Bill, NBD