Új hozzászólás Aktív témák

  • karnokd

    tag

    A panaszok egy része nagyon vicces. Akarunk más oprendszer alatt is adót bevallani, de azért elvárjuk, hogy a telepítés és használat olyan legyen, mint a windowsos változat. Ha jól tudom, akkor a GPL-es és más open source eszközökkel minden gond nélkül lehet készíteni és eladni closed source szoftvereket, csupán mellékelni kell azok licenszét. Windows alatt persze nincs sok értelme a Java-s változatot használni szerintem, aki meg linux alatt használja, az tán csak képes használni a parancssort.

    Cf550W + E6600 @ 2,4 + 4GB 800MHz Kingston 5-5-5-18 + Asus P5B Deluxe + 2 x 320GB + 1TB +SB Xtreme +Nec18x + GF250GTS 1 GB Twint Frozr

  • czappa

    aktív tag

    válasz karnokd #1 üzenetére

    "de azért elvárjuk, hogy a telepítés és használat olyan legyen, mint a windowsos változat"
    Nem, szerintem azt várják el, mint elég sok nem open source-os proginál, hogy a telepítő grafikus "next", "next" klikkelgetős legyen.
    De ha mindenképpen parancssoros, akkor legyen ".run" bináris, ezeket csak futtatni kell (./a_progi.run). Egy picit az az érzésem, mintha szerinted a linux az egyenlő lenne a parancssorral. Aki linuxozik elégedjen meg ezzel oszt jól van.
    Megjegyzem a linuxosok éppen úgy adóznak mint a windowosok és az ő pénzükből fejlesztett programtól elvárható h ugyan olyan seggkinyalós legyen mint a másik OS-re írt változat.
    "A panaszok egy része nagyon vicces."
    Nem tudom melyiken röhögtél. A vágólap hiányára? Vagy azon h Win-en készült doksik linuxon nem használhatók? Vagy esetleg egy "multi-user" rendszer "multi-user" tulajdonságának földbe tiprásán? Komolyan érdekel melyik a vicces szeretnék egy jót röhögni.
    Megj.: nem próbáltam a progit csak a cikk alapján írtam véleményt.

    szerk.: Visszatérve a segg kinyalós részre: Mióta Ubuntu jellegű disztrók is léteznek rég nem mondhatjuk h a linuxot csak kockák használják, akiknek -nyilván(?!)- jó a parancssor is.

    [ Szerkesztve ]

  • Sianis

    addikt

    válasz karnokd #1 üzenetére

    A GPL-nek pont az a lényege, hogy használata esetén az új forrást is GPL alatt kell kiadni, továbbadni. Valamint elérhetővé kell tenni a forrást. GPL-el nem készíthető zártforrású kód, hiszen akkor az alap célját szegné meg. Az már más kérdés, hogy a GPL-es program pénzért árusítható, de ettől még a forrásnak szabadon elérhetőnek kell lennie.

    Sianis

  • #25954560

    törölt tag

    válasz karnokd #1 üzenetére

    egy desktop ubuntu azert hozzaszoktatja az embereket a 'klikkel-es-muxik' felhasznalashoz. persze meg most is sok kivetel van (driverek heggesztgetese ritkabb hw-khez, stb), de ez a tendencia. a cikkben emlitett hibak nagy reszet en is hibanak latom. foleg azutan, hogy tenyleg nem volt beta verzio kiadva, pedig a kozosseg erre (is) van.

  • gLes

    őstag

    Ezt is sikerült nagyon jól a Microsoftra kenni, holott nyilvánvalóan nekik ehhez semmi köze.

    Ha a kedves panaszos vette volna a fáradságot és kipróbálta volna a Windowsos változatot (amit valószínűleg a Microsoft termékek iránt érzett mélységes utálatból nem tett meg), akkor láthatta volna, hogy az eredeti program is messze nem volt tökéletes.

    A helyzet valószínűleg az, hogy a pályázatnyertes cég (és a pályázatokat az IT-szektorban rendszeresen bundázzák ugyebár) teljesen inkompetens, leülnek valami egyszerű RAD környezet elé és összehuzigálják a megfelelő elemeket. Ezt első körben Windowsból könnyebb volt megtenni, olyan is lett amilyen (mintha az eredeti program Delphi-ben készült volna), aztán sírtak hogy legyen Linuxos változat és elővettek valami Java-s RAD eszközt (NetBeans vagy Eclipse), és megcsinálták még egyszer ugyanazt, csak még silányabbul.

    Hasonló a felsőoktatásban oly hírhedt Neptun esete, aminek a legújabb változata tavaly oly katasztrofálisan indult. Történetesen a félre sikerült start után a Microsoft szakemberei szálltak ki és mentették a menthetőt, hogy mégis használható legyen a rendszer, és természetesen az derült ki, hogy a fejlesztők nem egészen voltak tisztában az optimalizálás és a terhelésteszt fogalmával.

    Ennek az egésznek pedig semmi köze ahhoz, hogy a szoftver nyílt forrású vagy sem. Meg lehetne ezt csinálni ugyanolyan jól nyílt- és zárt forrású variációban is. Csak akarni kell.

    [ Szerkesztve ]

  • ngabor2

    nagyúr

    az alapvető hibát én abban látom, hogy egy szükségszerűen monopol helyzetben levő társaság (állam, kormányzat, adóhivatal) számára készít egy cég egy programot, mindenféle konkurencia és komolyabb ellenőrzés, valamint vállalt garanciák nélkül. ha egy kicsit is odaállnának hozzáértők mellé, első lépésben valszeg sikítófrászt kapnának, és az egészet törölnék, hogy 0-ról, először alaposan átgondolva, megtervezve kezdjenek neki. mert legutóbbi értesüléseim szerint ez nem így szokott kezdődni "odafenn".

    csakhát ahoz, hogy a hozzáértők odaférjenek, egyes odanőtt elemeknek arrébb kellene állni, vagy fel kellene állni a székből... ami nekik nem tetszik. de innentől már nagyon megközelíteném a politikát, úgyhogy nem folytatom.

    nekem is úgy tűnik, hogy itt nem a probléma megoldása a lényeg, hanem a "kennyük be sárral oszt jó lesz az tanyára" esete.

  • FTeR

    addikt

    vannak progik, amiknél kitétel, h ne legyen visszafejthető. sztem ez is egy ilyen, így a GPL-t nem is értem...

  • rollins

    őstag

    Az utolsó két leírt hiba azért az nem semmi. Ezért a pénzt is kaptak a "fejlesztők"?

  • azbest

    félisten

    A korábbi hír hozzászólásainál mintha arról is írtak volna hogy Win alatt is olyan könytárba akar írni amihez semmi köze... ott sem a felhasználói könyvtárba pakolt.

    Ha rosszul emlékszem akkor elnézést.

    szerk: a cikkben
    "A program telepítéséhez rendszergazdai (!?) jogosultságra van szükség, mivel a program elhelyez egy állományt (abevjavapath.cfg néven) Linux alatt a /etc, Windowsnál pedig a %windir% környezeti változó által mutatott könyvtárban."

    [ Szerkesztve ]

  • bambano

    titán

    LOGOUT blog

    tegnap teszteltem. (magamat hardcore parancssor buzik közé sorolom).
    ez a program egy HULLADÉK.

    Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

  • luciferc

    őstag

    válasz FTeR #7 üzenetére

    Egy űrlapkitöltő programnál miért kitétel, hogy ne legyen visszafejthető? Miben több az abev, mint egy űrlapkitöltő és ellenőrző program?

  • ngabor2

    nagyúr

    válasz FTeR #7 üzenetére

    oké, ne legyen gpl-es, mert valaki belenyúl, belemódosít, adót csalhat. de az hadd legyen már elvárás, hogy működjön. ne csak elinduljon, ne csak mojoljon, ne "jól is lehet csinálni, ha épp van hozzá kedve" módon működjön, hanem mint egy rendes program. hány éve is létezik elektronikus adóbevallás? legalább 3. és azóta nem bírták rendesre megcsinálni? mit csináltak addig? vagy váratlanul érte őket, hogy jééé, jövőre is kell adózni? a törvények elég korán kijönnek, hogy kényelmesen hibaszegényre megcsinálják (nem hibátlanra, azt úgyse lehet). de semmi komoly fejlődést nem vettem észre.

  • loszerafin

    senior tag

    Bizony, a windowsos verzió sem jó. Rendszergazdának kell lennem a telepítéshez, ha jól emlékszem power usernek az űrlapok letöltéséhez, frissítéséhez. Mindkettő kerülendő a 60 éves számítógéptől írtózó könyvelők gépein.

    A forráskód mindenképpen problémás, ha GPL-es dolgokra támaszkodik, de ezt ki tudná megmondani ha zárt a kód?

    Hiba volt Delphi-ben írni a windowsos változatot, rögtön Java-ban kellett volna, akkor lehetne ugyanazt a forrást használni. Ha két szoftvert fognak fejleszteni, sosem lesz a kettő ugyanolyan fejlett, a windowsos mindig "okosabb" lesz.

    Nem követelmény a zárt forráskód, ez egy nyomtatványkitöltő program.
    Semmilyen rizikót nem jelenthet, ha megtudjuk, hogy ír a program egy input mezőbe...
    Sokat segítene, ha egyszerűen össze lehetne kötni más programokkal (bér programok például).

  • loszerafin

    senior tag

    válasz ngabor2 #12 üzenetére

    adócsalás:
    Adót nem a nyomtatvány kitöltésekor csalunk, hanem amikor kitaláljuk, mit melyik input mezőbe írjunk.

  • KEndre

    HÁZIGAZDA

    válasz ngabor2 #12 üzenetére

    Azért ez nem egészen így van. Mi, családi könyvelőiroda lévén, folyamatosan használjuk az ABEV/EBEV/Ügyfélkapu szentháromságot, s azt kell mondanom, hiba nélkül tudunk dolgozni. Tehát az enyhe túlzás, hogy "nem bírták rendesre megcsinálni".

    Vannak persze problémák: sokszor van mostanában üzemszünet, nehézkes a javítás/önrevízió, a folyószámla lekérdezés is lassú... szóval ilyenek.

    Nem tudom (állítólag titkos adat, vagy nem lehet összeszámolni) mennyit költöttek eddig az elektronikus adózási rendszerre, tehát ár/érték nem látszik, de végülis műxik minden.

    El ne felejtsétek: iszonyú adatmennyiséget kell lekezelni ezen a rendszeren!!!!

    Az AbevJava megjelenése egy határidős feladat volt, a pénzügyminiszter a parlamentben megígérte, hogy 2008 elején kijön a java-s Abev, szerintem ezért kiforratlan. Jobb persze, hogy kirakták, mert különben lehet, hogy 2010-ig sem lett volna platformfüggetlen kliensprogram. Ennek örüljünk. A hibákat meg soroljuk, remélhetőleg lesz foganatja a kritikának.

    Légy óvatos, sokan pályáznak a nehezen megszerzett pénzedre! Tudd, hogy csak te vagy képes megvédeni magad!

  • KEndre

    HÁZIGAZDA

    válasz loszerafin #13 üzenetére

    Tudtommal nem fognak kettőt fejleszteni, a mostani AbevJava megy majd tovább 2009-től.

    Szerintem sincs probléma a nyílt forráskóddal, mert az adatok annyira összefüggnek logikailag, hogy nem lehet manipulálni...

    Légy óvatos, sokan pályáznak a nehezen megszerzett pénzedre! Tudd, hogy csak te vagy képes megvédeni magad!

  • Lortech

    addikt

    Ilyen gányolást. Nem volt egyetlen linuxos emberke, aki normálisan megtervezi a telepítőt és jogosultságokat?

    20 percembe tellett, mire normálisan belőttem, hogy menjen minden root nélkül a saját home-omban.

    Thank you to god for making me an atheist

  • joghurt

    addikt

    válasz Kalandor #15 üzenetére

    A %WINDIR% illetve az /etc használata is az. Jó, ne legyenek Linux-guruk. De Windowson sem szokás a rendszerkönyvtárba írni; jobb policyk meg sem engedik. És egy elvileg többfelhasználós gépen (már az XP is ilyen...) a saját, jogosultságokkal védett profil helyett az összes felhasználónak egy könyvtárba hányni, hogy jól hozzáférjenek egymás adataihoz...

    A Linux alatti /etc használat kb. egyenértékű a rendszer még felhasználói szintű ismeretének hiányával. Megintcsak ne legyen parancssoros guru. Leül az Ubuntuja elé, nem rootként kattintgat, és nem bír beledisznózni ebbe a könyvtárba.

    A tej élet, erő, egészség.

  • joghurt

    addikt

    válasz KEndre #16 üzenetére

    Iszonyatos adatmennyiség? 3 milliószor 1 kB, összesen 3 GB? Tömörítve talán még egy CD-re is felférne az egész. Bármelyik banknál vagy mobilszolgáltatónál több a napi tranzakciószám ennél.

    A tej élet, erő, egészség.

  • KEndre

    HÁZIGAZDA

    válasz joghurt #20 üzenetére

    Na ne, azért itt folyik már a munkaügyi adatok kezelése, a magánnyugdíjpénztárak, egészségbiztosítás, cégadatok, havi adóbevallások, etc.

    Nagyjából 5 millió ember és többszázezer cég dolgai... Melyik banknak van ennyi ügyfele? Az OTP egy monstrum, de ennyi ügyfele még neki sincs, mégis néha összecsinálja magát a netbankja.

    Légy óvatos, sokan pályáznak a nehezen megszerzett pénzedre! Tudd, hogy csak te vagy képes megvédeni magad!

  • klinsi

    csendes tag

    válasz FTeR #7 üzenetére

    vannak progik, amiknél kitétel, h ne legyen visszafejthető. sztem ez is egy ilyen, így a GPL-t nem is értem...

    Uristen!! Már miért kellene titkosnak lennie? Ebben csak olyan számítások és képletek vannak, melyet hozzáértők kiolvashatnak a jelenleg hatályos jogszabályokból!

    Nem hiszem, hogy a különböző % számításokra a fejlesztő feltalált új fajta % számítást, amit szabadalmaztatott és most védeni kellene...

    Ha valaki a forrás láttán próbál csalni és mahináltan beküldeni bármit, ahhoz meg szerintem nem kell a forrás sem, ha akarom megy az anélkül is (max megvágnak ha rájönnek, vagy nem tudom mi történne).

    Ez az egész megint tipikusan magyar. Köszönjük. :F

    [ Szerkesztve ]

  • LordX

    veterán

    válasz klinsi #22 üzenetére

    Hát igen. Ez a program csak azt csinálja, hogy a megfelelő mezőkbe beleírod amit kell, és a származtatott mezőket meg kiszámolja. Ugyanaz, mint amikor bemész a nyomtatványboltba, megbeszed az azonos számú nyomatványt (már amelyiket még lehet papíron), kitöltöd, kiszámolod a megfeelő mezőket.

    Most ebben mi olyan kód van, amit védeni kéne bármitől is?

  • klinsi

    csendes tag

    válasz KEndre #21 üzenetére

    Mi, családi könyvelőiroda lévén, folyamatosan használjuk az ABEV/EBEV/Ügyfélkapu szentháromságot, s azt kell mondanom, hiba nélkül tudunk dolgozni.

    Lehet bennem a hiba. PHP fejlesztőként és sitebuilderként dolgozom és az ügyfélkaput szakmai és felhasználói szemszögből is logikátlan, nem felhasználóbarát oldalnak tartom. A technikai megoldásaik egy része is több, mint érdekes.

    Mielőtt szubjektív és objektív okokon kezdünk vitatkozni, volt szerencsém látni több kutatást is az említett weblappal kapcsolatban (website usability témakörben) - ezek pedig alátámasztják, hogy messze van a jótól...

    Nagyjából 5 millió ember és többszázezer cég dolgai... Melyik banknak van ennyi ügyfele?

    2 apróság.
    Egyrészt az én ügyfeleimet nem érdekli, hogy hogyan oldom meg de 1 web szolgáltatás vagy szoftver legyen jó és gyors is. Nem indok az, hogy 5M rekordot, vagy 50M rekordot kell mozgatni.
    Szolgáltatást veszel / vesznek az adódból.
    Amikor autót vásárolsz akkor is a hibát kijavítják, nem mosolyognak kényszeredetten a 2ik héten, hogy "elromlott, van ilyen, bonyolult szerkezet :K ".
    Másrészt megdöbbennék, ha a teljes apeh és egyéb adattárakat onthefly egyben mozgatná a rendszer. Ha így lenne akkor nincs ehhez sem több hozzáfűznivalóm (ill. de, megnézném a szerverparkot :DDD ). Ha meg tisztességesen tervezték, akkor 100%, hogy nincs benne olyan rész, amikor adatbázis szinten az 5 millió ember adataival dolgoznak egyszerre és azokat mozgatják (kliens oldalról).

    Szóval összeségében az eddigi offtopic hozzászólásom lényege, hogy a windows oldalon is lenne ezeken a szoftvereken BŐVEN mit javítani.
    A felsorolt Linux hibák meg olyan horrorisztikus dolgokat mondanak, amikér sajnos megint nem fogja senki a bokáját megütni.

  • #64791808

    törölt tag

    Kérdem én: miről beszélünk? Min csodálkozunk?

    Az ABEV program egy rakás kaki. Nem régóta, csak mióta megvan.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. Rengeteg fejlesztési eszköz állt volna rendelkezésre, meg lehetett volna csinálni .NET-ben, vagy már eleve Javaban, platformfüggetlenül, sőt, web alapon, a lehetőségek tárháza végtelen, elvégre elég primitív feladatot kell megoldani.

    Jó sok pénz elment, de legalább szar lett az eredmény. Aki dolgozik egyéb "állami" programmal, az tudja, hogy kivétel nélkül mind vacak. Nyenyinél dos program van, és floppyn kell küldözgetni a cuccot... Botrány. És? Itt komolyan gondolja valaki, hogy az említett szempontok valakit is érdekeltek fejlesztés közben?

    Három kritérium volt:

    1., Legyen olyan nem-windows környezet, ahol adott esetben működik, ezzel prezentáljuk, hogy elvégeztük a feladatot.

    2., Ki csinálja meg ezt a létező legolcsóbban?

    3., Zsebbe mennyi píz jut?

    Ez ennyi, mindig is így ment, és mindig is így fog menni, kár rajta rágódni szerintem.

  • luciferc

    őstag

    válasz KEndre #16 üzenetére

    El ne felejtsétek: iszonyú adatmennyiséget kell lekezelni ezen a rendszeren!!!!

    El ne felejtsd, hogy nem az adatbázis szerverekkel, és úgy általában a rendszerrel van gond, hanem a hótprimitív nyomtatványkitöltő programmal, amit egy jobb képességű középiskolás olcsóbban és jobban megír 1 hónap alatt.. Kitöltés közben ugyanis nem kommunikál az adatbázissal, és nem kezel iszonyatos mennyiségű adatot, csak annyit, ami egy nyomtatványban van! A meg azért nem olyan sok. Hm?

    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?

    Mellesleg 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, vagy egy csak erre szolgáló célprogrammal (azt talán meg tudják írni; talán). Miért kell egy nyomtatványkitöltő programot kizárólagosan házon belül fejleszteni? Akinek van erre magyarázata az érdekelne, mert én nem értem.

    [ Szerkesztve ]

  • joghurt

    addikt

    válasz KEndre #21 üzenetére

    Szezon vs fazon. Ügyfelek száma senkit nem érdekel, mert nem az adja a terhelést. Hanem az adatok száma. Az szja-bevallás az jelent évente egyszer ötmillió embert, plusz az áfa-bevallás havonta egyszer x millió céget. Vagy te évente egyszer veszel ki pénzt a bankodból, és havonta csak egyetlen tranzakciót végez a céged? Saját adataimmal én kb. 500-1000 tranzakciót végzek évente, a cégem tranzakcióit meg össze sem tudom számolni.

    Szintén szezon vs fazon a nagy terhelésű központi rendszert és az ügyfeleknél futó kliensprogramot összemosni. Az AbevJavát érdekli, hogy hánymillió adózó van az országban? A sokmillió adózó miatt akar olyan helyekre írni, ahova csapokakezére?

    A tej élet, erő, egészség.

  • joghurt

    addikt

    válasz luciferc #26 üzenetére

    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.

  • luciferc

    őstag

    válasz joghurt #28 üzenetére

    Már csak azért is, mert tudjuk jól tavalyról, hogy ha az ABEV szarul számol valamit, azért is az adózó felel. Akkor meg miért ne használjak olyan (mondjuk open source) programot, amiben jobban megbízom, mint a pénzlopási hadműveletek között összefércelt abev-ben? Kinek fájna ez? Már persze a zsíros fejlesztési pénzeket felvevőkön kívül...

  • joghurt

    addikt

    válasz luciferc #29 üzenetére

    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.

  • luciferc

    őstag

    válasz joghurt #30 üzenetére

    a régi-új IT Café feltehetne pár ezekhez hasonló érdekes kérdést az állami informatika fejeseinek... :U

  • Gregorius

    őstag

    válasz Sianis #3 üzenetére

    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 ]

  • luciferc

    őstag

    válasz Gregorius #32 üzenetére

    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.

    Ok, de akkor végülis csak azt csinálja a program amit mondtam, csak úgy tűnik hiányzik az nyomtatványleírás rendes kidolgozása vagy 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! A böngészőm is képes tetszőleges nyomtatványt megjeleníteni, sőt még ellenőrzi is azt ha úgy akarta a fejlesztő. Hm? Mi a különbség? Lehet hogy van, de én nem látom.

    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? Feltöltéskor ellenőrzés. Ha megfelel a leírásnak, akkor mehet, az adatok hibájáért meg a feltöltő felel. Ha egy aprócska struktúrális, szintaktikai, stb hiba is van, vissza kell dobni.

    Sokba kerül a nemlétező dokumentáció emészthetővé tétele illetve nyilvánosságra hozatala.
    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. És ha a fejlesztőket kollektíve elüti a villamos. Akkor? ha nincs rendes részletes normális dokumentáció, akkor minden a megrendelésben, átvételben részes embert azonnal ki kell rúgni.

    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.
    Ó ó ó. Az USB kulcs helyett írj bankkártyát. Máris nem olyan vészes, ugye? Lehet hogy drága lenne az USB kulcsos rendszer, de akkor meg ott van az utolsó mondatod. Vajon van erre irányuló rövidtávú terv?

  • dabadab

    titán

    válasz KEndre #16 üzenetére

    Hany ceget visz nalatok az ABEV? Mert nalunk 130 tajan van, es az uj adatlap megnyitasakor meglehetosen hosszu es kinos szunet utan tortenik csak barmi is.

    "Az AbevJava megjelenése egy határidős feladat volt, a pénzügyminiszter a parlamentben megígérte, hogy 2008 elején kijön a java-s Abev, szerintem ezért kiforratlan."

    Persze, hiszen evek ota dolgoznak rajta, biztos nem volt ra idejuk.
    Az gondolom kurvara nehez lett volna, ha kiadjak a specifikaciokat mondjuk a windowsos ABEV urlapjaihoz, hogy tessek, ehhez kell programot irni, hajra Black Panther es tsaik! Nem, dehogy, az hasonlitott volna vmi piaci mechanizmusra, inkabb kiadtak allamilag, hogy gyartsanak valami tragyat.

    "El ne felejtsétek: iszonyú adatmennyiséget kell lekezelni ezen a rendszeren!!!!"

    Bocs, ez valami vicc akart lenni? A fent emlitett cegek ketevnyi minden adata felelmetes 64 MB. Tenyleg, iszonyatos adatmennyiseg.

    [ Szerkesztve ]

    DRM is theft

  • CharlieDrop

    veterán

    Hjah, az abev egy mumus szvsz
    Anno mikor beindult egy fejlesztő cégnél dolgoztam, és a megrendelőnk kért egy importáló modult a rendszerünkből az abev felé. Lekértük a megfelelő paramétereket és még azzal is vagy 2 hetet szívtünk, mert aszerint nem működött.
    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. De elég lenne egy böngésző és nem kellene rágódni, hogy milyen rendszeren működik/nem működik. Plusz a hibajavításokat sem kellene letölteni és ebből adódóan nem lennének kavarások, "balesetek"....

    Nem használok AD-blockert a PH! oldalain!

  • dabadab

    titán

    válasz CharlieDrop #35 üzenetére

    A bongeszos megoldasoktol azert en tartok, amennyire latom, a bevitelt egyszeruen nem lehet olyan felhasznalobaratra megcsinalni, mint egy normalis programnal (ill. AJAX-os varazslassal elkepzelheto, de az meg nem biztos, hogy olyan faszan fut a P2/P3 gepeken).

    DRM is theft

  • CharlieDrop

    veterán

    válasz dabadab #36 üzenetére

    Hm, végül is nem tudom mi igazán felhasználóbarátnak mondott dolog az ABEV-ben, én amennyit látom úgy tudom adatokat lehet bevinni, amit ellenőriz valamilyen szinten, még a betöltésért sem felelős. Ezt meg bármilyen egyszerű form is tudja, semmi extra sincs benne, vagy nem használom eleget?

    Nem használok AD-blockert a PH! oldalain!

  • dabadab

    titán

    válasz CharlieDrop #37 üzenetére

    Gyakorlatilag minden konyvelessel kapcsolatos program legsarkalatosabb pontja az adatbevitel: az, hogy az adott adatokat minel kevesebb leutessel, lehetoleg a kepernyore sem nezve lehessen bevinni. Teljesen mashogy nez ki a dolog egy webes fejleszto szempontjabol, aki egesz nap a kodot hegeszti, aztan idonkent bevisz par tesztadatot, meg mashogy a konyvelo szempontjabol, aki napi nyolc (tiz) oraban mast se csinal, csak viszi be az adatokat.

    Annyira nem vagyok otthon a dologban, hogy konkret ellenveteseket tudjak hozni, de mar lattam webes konyveloprogramot es az hatarozottan borzalmas, hasznalhatatlan vacak volt.

    DRM is theft

  • luciferc

    őstag

    válasz dabadab #38 üzenetére

    Így van. És nem vagyok meggyőződve arról, hogy akármelyik abev verzió teljesíti ezt a kritériumot. Mit mondanak erről azok, akik használják nálatok?

  • Gregorius

    őstag

    válasz luciferc #33 üzenetére

    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.

  • luciferc

    őstag

    válasz Gregorius #40 üzenetére

    Nem nem, én nem javasoltam a böngészős megoldást, csak jeleztem, hogy vannakn olyan általános célú eszközök, amik adott esetben sokkal általánosabban tudják azt, amit az abevnek kellene. Szerintem is jobb a külön program erre a célra (lásd korábban is) és nekem is a második megoldás szimpatikusabb.Az apeh nyomtatványok azért elég egységes és egyszerű szerkezetűek, sokkal sokkal kevésbé komplexek mint akár csak egy html dokumentum is, ezért nem értem, hogy miért gond ezt rendesen megcsinálni.

    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.

    Az USB kulcsot azért ritkábban hurcolja magával a mezei halandó, ugye? Mezei emberke évente egyszer bevall, néha ügyintéz, jól el van az otthon, nem életszerű, hogy egyszercsak délután fél kettőkor fejemre csapok, hogy "basszus, az ügyfélakapu kulcs, mennyire kellene most!". A cégeknél meg ugye eleve tilos csak úgy piszkálni az ilyen dolgokat, gondolom a trezor (értsd bizalmas dolgok) kulcsára is vigyáznak...

  • joghurt

    addikt

    válasz Gregorius #32 üzenetére

    Mint azt a sírással küszködve szoktam mondogatni ... 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. Itt az átgondolás, megtervezés még az Apeh részéről kellett volna, hogy megtörténjen. Legalábbis nem hiszem, hogy az ő részükről fogalmazódtak meg ezek az elcseszési követelények.

    Most egyrészt mondhatnám, hogy később könnyebb okosnak lenni ... 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.

    Hiszem, hogy hozzáértéssel kettő hét alatt meg lehet egy ilyet írni, ... Igazat adok Sianisnek. 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.

    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.

    A formátum és az adatok ellenőrzéséről: 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á.

    Sokba kerül a nemlétező dokumentáció emészthetővé tétele illetve nyilvánosságra hozatala. ... Dokumentálás nélkül ki vette át a megrendelő részéről? 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?

    Az USB-s kulcs elveszése, megrongálódása egyenértékű a személyid megrongálódásával. Én legalábbis arra vigyázni szoktam. De szerintem a lakáskulcsod sem szoktad olyan gyakran elhagyni, elrongálni. Gyári selejt? Postás ellopja? Okmányirodai átvételnél (ld. személyi)? Amúgy csak példaképp írtam. Az a hatalmas előnye megvan a chipkártyához képest, hogy semmilyen USB-hez képest drága olvasó nem kell külön hozzá. 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. Természetesen USB kulcs esetén a haverok cége elesik attól az extraprofittól, amit az államilag elfogadott kártyaolvasók értékesítése jelent.

    Különben meg az általad állandóan emlegetett support nightmare nem létezik. Aki nem ért hozzá, az majd használja a mainstream, windowsos desktop cuccot. Akinek ezt vallása tiltja, ámde ért hozzá, az majd ír kézzel XML-t, vagy egy webes űrlapot. Ez nem kötelező, hanem csupán egy lehetőség.

    A tej élet, erő, egészség.

  • CharlieDrop

    veterán

    válasz dabadab #38 üzenetére

    Hm, nem tudom, szerintem egy böngészős ürlapfelvételis dologgal meg lehet mindent oldani...
    Persze mindennel lehet csinálni egy rakás trágyát is...

    Nem használok AD-blockert a PH! oldalain!

  • lapa

    veterán

    szerintem nincs teljes egyetértés a "dokumentáció" definíciójában, vagy keveredik a (nem létező) "interface leírás" tartalmával.

    a két hét alatt megírás / teljesítés meg egyszerűen nevetséges irl, pláne, hogy a megbízó jellemzően nem valami haver it-s faszi, akivel együtt developázik az ember évek óta.

    ez most láma kérdés: nem lehet, hogy azért adták ki most, hogy határidőre összejöjjön egy működő / jól működő verzió? ismerek egy céget, aki pont ugyanígy csinálja.

  • KEndre

    HÁZIGAZDA

    válasz dabadab #34 üzenetére

    Nálunk 60-70 céget intézünk. A havi (0708) bevallások elég sok adatot termelnek, de tényleg, abban igazatok van, méretre nem olyan nagy mennyiség.

    A feladatunk, hogy 100-150 dolgozó bérszámfejtését és bevallását hárman megcsináljuk 2-3 nap alatt, szükségessé tette, hogy a bérszámfejtési (munkaügyi) rendszerünket illesszük az Abevhoz, így azért már elég gördülékeny a meló.

    Szeretném jelezni: fontos lenne, hogy a cégeknek, könyvelőirodáknak megoldják a biztonságos személyi azonosítást!!!!

    Lehet mellébeszélni kedves Szitner úr, hogy nincs erre fogadóképesség, meg minek ez, de itt tök nem mindegy, hogy ki adta be az adatokat. Az egyéni bevallóknál maradhat a user/password hitelesítés, de cégeknél/könyvelőirodáknál NEM!!!!!

    Légy óvatos, sokan pályáznak a nehezen megszerzett pénzedre! Tudd, hogy csak te vagy képes megvédeni magad!

  • dabadab

    titán

    válasz Gregorius #32 üzenetére

    "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."

    Nem akarlak megzavarni, de egeszen pontosan igy van megcsinalva, mivel ilyen mennyisegu nyomtatvanynal ennel egyszerubb nincs.

    Ideznek pl a 0753-as nyomtatvany .alg file-jabol:

    m18534 < > 11700735
    A visszaigénylõ pénzforgalmi jelzõszám nem lehet 11700735. (Hibakód=<174/>)
    m18534 > 0 => m18534 > 9999999
    A pénzforgalmi jelzõszám nem kezdõdhet 0 vagy üressel (Hibakód=<175/>)
    mv$842
    m847 > 0 <=> m842 > 0
    Ha 7A>0, akkor 7D>0, Fordítva is igaz! (Hibakód=<176/>)
    mv$843
    m864 > 0 <=> m843 > 0
    Ha 8A>0, akkor 8D>0, Fordítva is igaz! (Hibakód=<177/>)
    mv$861
    m861 <= m866
    [0753] 22A <=22D (Hibakód=<179/>)
    mv$865
    m865 <= m867
    [0753] 23A <=23D ! (Hibakód=<180/>)
    mv$677
    m866 + m677 > 0 => m866 > m677
    [0753] 22D>27B, ha a két mezõ közül bármelyik kitöltött (Hibakód=<181/>)

    Igy jobban megnezve, lehet, hogy siman lehetne ra interpretert irni. Hm.

    [ Szerkesztve ]

    DRM is theft

  • dabadab

    titán

    válasz dabadab #47 üzenetére

    Megneztem a linuxos kitoltot is, ott egy XML-ben van minden adat.
    Siman lehetne rajuk valami normalis keretprogramot is irni, csak adjak ki a speckot (igazabol anelkul is menne, csak akkor lenne vmi biztositek arra, hogy nem valtoztatjak meg ossze-vissza).

    DRM is theft

  • Gregorius

    őstag

    válasz luciferc #41 üzenetére

    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? :U 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... :U

    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? :U

    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 ]

  • WN31RD

    addikt

    Ehhez a szánalmas cirkuszhoz annyit szeretnék hozzátenni, hogy szakmabeliként meglátásom szerint az itt felmerült problémák nem csupán kapkodásra vagy apróbb hiányosságokra, kezdeti nehézségekre utalnak, hanem totális dilettantizmusra, amelyet egyszerűen nem lehet mentegetni. És ez azért elkeserítő, még ha meglepőnek nem is nevezném.

    Ezért normális esetben magas szinten fejeknek kellene hullani, mert akik ezt a projectet vezették, azok vagy teljesen idióták vagy pofátlanul korruptak vagy mindkettő.

    Az jut erről eszembe, hogy Japánban olykor lemond egy közlekedési miniszter, mert késett valami vonat... Példát vehetnénk róluk, és itt nem elsősorban a miniszter lemondását hiányolom, sokkal inkább a mögöttes tartalmat: A vezetőknek felelősséget kellene vállalniuk az általuk irányított dolgokért.

    (Ezt bármiféle pártpolitikai megfontolástól teljesen függetlenül írtam.)

    [ Szerkesztve ]

    ''... we as consumers want our content free (as in Freedom) and if we don't get it, we'll take our content free (as in beer).''

Új hozzászólás Aktív témák