Nyilvántartó Rendszer2
2009-12-05T10:21:30+01:00
2009-12-09T08:34:25+01:00
2022-07-19T05:22:13+02:00
  • De valahogy PHP-ban ezekbe a problémákba pont nem futottam bele

    Külön jó, amikor egy "tipusos eszközt" (adatbázis) és egy nem tipusos "php"-t használsz együtt. És ezután egy-egy jó parancssorral lazán hazavághatod az adatbázis tartalmát, mert a program ki tud számolni valamit, de az adatbázisba beirogatás közben meg hiba generálódik.

    A 3.234 milyen számként tárolódik? Milyen pontossággal (vagy pontatlansággal fog számolni egy 10%-al szorzás, ahol 2-es számrendszerben ugye 0,00011001100110011

    Sebességi szempontokról meg ne beszéljünk. Két Integer vagy 2 valamivel gyorsabb a műveletvégzés?


    De pontosan annyi energiát kell belefektetned abba, hogy a PHP-t "típusosan" használd, mint amennyit mondjuk a c#-ban. Mert ahogy ott használod a konvertáló függvényeket, itt írhatsz saját összeadó, összefűző függvényeket, és akkor nem lehet gondod.


    És akkor melyik az egyszerűbb? Használni a készet, vagy megírni egyet és utána azt használod.

    ---
    [off]
    Én imádom a nem tipusos használatot, de egyetértek LC-el, "néha" sokkal jobb a tipusos.
    Mutasd a teljes hozzászólást!
  • A 32767 akkor probléma ha 16 bites integert használsz - azt pedig nemigen szokott használni senki. Viszont az még mindig jobb amikor a rendszer egy típus túlcsordulás miatt egy exceptionnal elszáll (vagy beír a logba mert azért ezeket általában illik elkapni) mint ha teszem azt a pénzügyi rendszered nem tudja tárolni a korrekt összeget és emiatt összejön néhány millió forint eltérés, esetleg pár tízezer hibásan felvitt bizonylat. Ez pistike webáruházánál nagyjából mindegy, de nem véletlenül javáznak a bankok...

    Én egyébként éveken át dolgoztam kb. a PHP-hez hasonló rendszerrel (Clipper) és elég sokat különféle erősen típusos nyelvekkel (Delphi, C++, C#). A különbség nagyjából ég & föld ami a kód megbízhatóságát illeti.

    Ezért nem nagyon örülök annak hogy .NET alatt lehet vizuálbézikezni és PHP-zni, illetve a DLR-nek: a típusmentes kód mindenképp rizikófaktor. És hiába megbízható a te programod ha a szutyok amit meghívsz esetleg típus nélküli kód és belül hülyeséget csinál. Illetve ez hosszú távon magára a platformra is rányomhatja a bélyegét: ha a júzer lát egy-két tákolt programot az adott platformon akkor a többi a platformot használó programról is meg lesz a véleménye.
    Mutasd a teljes hozzászólást!
  • Mert így a fejlesztés során adódó hibák kb. 70%-át már fordításkor elfogja a fordító, sőt a mai IDE-k már amikor hülyeséget írsz kiszínezik a hibát, míg PHP esetén max. futás közben jönnek elő - de akkor sem mindig, pont a típuskezelés hiánya miatt.

    A méretek meg akkor fontosak ha nem mindegy hogy mekkora helyen ábrázolsz valamit, illetve ha olyan rendszerekkel kell kommunikálnod ahol ez nem mindegy. A legegyszerűbb eset az adatbázis: egy byte kereken negyedannyi helyet foglal mint egy int. Egy int negyedannyit mint egy decimal.

    Szóval, alapvetően az a PHP legnagyobb baja hogy nem csak profi C++ tudás után lehet elsajátítani. Lehet ugyan profi programot is írni benne (bár erre azért vannak jobb rendszerek, lásd típuskezelés + normális osztálykönyvtárak mint amilyen a javának vagy a .NET-nek van) de alapjában véve az egyszerűsége és a típuskezelése, a primitív osztálykönyvtárai vonzzák a gányolóművészeket.
    Mutasd a teljes hozzászólást!
  • De valahogy PHP-ban ezekbe a problémákba pont nem futottam bele. Nagyon ritkán kell használnom valami típuskényszerítést. Mert azért van olyan benne, annak ellenére hogy nem típusos.
    És inkább a típusos nyelveknél futhatsz bele ezekbe. Megválasztasz egy integert egy számlálónak, tesztelsz 200 recorddal, aztán élesben jön a 32xxx record és dob egy hibát, vagy átvált -32xxx-be
    Talán 1x fordult elő velem, hogy valamit elszámolt a PHP. Ez is csak a magyar sajátosság miatt: nálunk "," van "." helyet tizedesként.
    De pontosan annyi energiát kell belefektetned abba, hogy a PHP-t "típusosan" használd, mint amennyit mondjuk a c#-ban. Mert ahogy ott használod a konvertáló függvényeket, itt írhatsz saját összeadó, összefűző függvényeket, és akkor nem lehet gondod.
    Mutasd a teljes hozzászólást!
  • Ezt a tipusosságot sosem értettem....

    Aztán majd jön a kérdés, hogy a
    123
    134
    15
    27
    375
    39
    Miért rendezés, ha nem ezt akartad.

    Meg esetleg az egyik-másik nyelvben a 2009.12.08 első 4 karaktere miért 4015. Vagy a "2.2"+"3" miért 2.23 (Az "-eket segítségként adtam)
    Vagy (prog.hu-s kérdés) a -szam miért nem vált előjelet.
    Vagy miért száll el esetleg a 20000*2
    Mert a nem tipusos nyelvekben ezek mind előfordulhatnak, ha nem vigyázol. (Bár persze van amelyik tipusosba is előfordulhat, de ott kénytelen vagy jobban átgondolni a változók használatát.)

    --

    Persze vannak előnyei és hátrányai (kényelmetlenségei) is a tipusos/nem tipusos nyelveknek.
    Mutasd a teljes hozzászólást!
  • Ezt a tipusosságot sosem értettem.
    Miért jó ha (128)byte -hoz hozzáadok 1-et , akkor -127-et kapok? Miért jó, hogy egy számnak meg kell adnom az értelmezési tartományát, mint egy függvénynek? Miért jó, hogy állandóan valami függvényt kell hívnom, mert össze akarom adni a 2-öt meg a 3.12-öt. Én azelött Pascalban és Delphiben programoztam, nem sírom vissza a tipusosságát. Egyébként évek óta programozók php-ban és még sose okozott gondot, hogy valamiből betű lett volna miközben szám, vagy épp fordítva. Az meg különösen nem probléma, hogy 2.2+3 összeadás működik.
    Mutasd a teljes hozzászólást!
  • a valasz egyszeru..

    Vitatkoznék, szerintem pont az nem egyszerű.
    Egy volt kollégámat idézve:
    "Nem a munka a nehéz, hanem a döntés"

    Ez pedig 100%-ban igaz.
    Addig van lehetőséged variálni, amíg nem döntesz.
    Ha már döntöttél, akkor már csak kódolni kell.
    Ha jót akarsz magadnak, akkor rászánsz sok-sok órát és feltérképezed teljesen az elvégzendő feladatot, mert ha meló közben derül ki valami, amire az általad választott környezet nem ad választ, akkor nagy slamasztikában leszel.

    Személyes véleményem, hogy én robusztus rendszert nem építenék php-ra, mert nekem egy összetett rendszerben nagyon számít a típusosság mankója, de mindenki maga tudja.
    Mutasd a teljes hozzászólást!
  • a valasz egyszeru.. hagyd a fenebe az accesset... csinald a nyilvantarto rendszert, myqsl, php, hmtl, es javascript alapra.. az alkalmazottak es a fonok webbongeszon keresztul modosithatjak... nincs jogdij etc...

    es akkor a webshoppal konnyeden tud kommunikalni...
    itt egy kis segedlet:
    http://mochaui.com/demo/
    Mutasd a teljes hozzászólást!
  • Először is köszönöm mindenkinek a jó indulatú hozzáállást, javaslatokat és segítséget. Teljesen egyetértek veletek mindenben. Igazatok van.

    -Az igényeket alaposan fel kell mérni
    -Megfelelő architektúrát kell tervezni ami támogatja a később keletkező akár óriási mennyiségű adatok kezelését is.
    -Legyen a rendszerben kialakított szoftver és hardver struktúra megfelelően rugalmas ahhoz hogy viszonylag könnyen lehessen bővíteni.
    -Egy kezdő számára be kell vonni tapasztalt szakembereket ha megfelelő eredményt akar elérni
    -Ja és a hazai oktatási rendszer egy rakás ...
    (Ha kikerülsz a gyakorlati életbe elkezdheted képezni magad mert amit az egyetemen tanítottak azt vagy soha nem fogod használni vagy olyan kevés hogy abból még nem tudsz túl sok dolgot összehozni)
    Mutasd a teljes hozzászólást!
  • Tökéletesen jól látod a helyzetet. Ismerem a cégvezetést, nagyon jó kapcsolat van közöttünk. Számomra ez egy nagyon jó fejlődési lehetőség.
    Mutasd a teljes hozzászólást!
  • "Ezért is nem szeretem egyébként a hazai oktatási rendszert."


    Engem is zavar, hogy századjára megiratják ugyanazt a támát a századik szakdolgozatban.

    Ezzel szemben az amcsi egyetemeken már 40 éve unixokat (és sok más nagyszabású dolgot) raktak össze úgy, hogy egy-egy téglát egy-egy szakdolgozat adott.
    Így persze kénytelenek a diákok csoportmunkában is résztvenni és a tanerőknek muszáj tervezni és szervezni.

    Más világ.
    Mutasd a teljes hozzászólást!
  • És nem egyből a legösszetettebb architektúrát akarom összehozni.

    Az baj.

    Egy "megoldást" úgy kell megtervezni, hogy az a maximális terhelésnek és igényeknek is megfeleljen. Késöbb sokkal nehezebb egy rosszul megtervezett rendszert hozzáigazítani az igényekhez, mint egy jó tervezést (ahogy chikk is említette).

    A fizikai felépítésben ettől nem nagyon szabad eltérni. A webszervert mindenképpen DMZ-be vagy külső hosting céghez kell kitenned. Oda tényleg csak olyan adatokat szabad publikálni, ami ha illetéktelenek kezébe kerül, akkor nem tud akkora kárt okozni, mintha az összes adatot megkaparintaná.

    Nem azt mondom, hogy rohanni kell két csúcs szerverért és két duplaprocesszor licenszes SL Enterprise licenszért. Megoldhatod MySQL-ben vagy akármi másban. Csak ekkor bukod pl. a replikáció és a reporting szerver előnyeit. Ezeket magadnakj kell megírnod (vagy ha szerencséd van, akkor találasz hozzá valamiféle template megoldásokat). Így ez több időbe kerül, az több pénz és a végén lehet, hogy jobban jártál volna ha mégis megveszed .
    Persze ha nem ismered ezeket az eszközöket, akkor mindegy, mert pl. a replikáció beüzemelése az adatszerkezet tervezésénél kezdődik.

    Sok apró buktató van egy project kivitelezésénél. Kezdőként nem biztos, hogy érdemes egyből egyedül dolgozni. Egy-két rutinos öreg rókától rengeteget lehet tanulni. Egy fejlesztőcégnél csak a munkamódszer elsajátítása akkora lehetőség, hogy nem szabad kihagyni (én kihagytam, mert soha nem készültem fejlesztőnek - sokáig ittama levét). Ezért is nem szeretem egyébként a hazai oktatási rendszert. Hiába írtál kiváló szakdogát - semmit nem tudsz a szakma valódi menetéről, módszertanáról. És ez nem a te hibád.
    Mutasd a teljes hozzászólást!
  • Szerintem ez tipikusan a tanulópénz projekt. A cégnek nincs sok tapasztalata az informatikával, a srác most végzett az egyetemmel, és meló mellett mondjuk szeretne tovább fejlődni. Ha esetleg személyesen ismeri a céget - cégvezetést + nagyon kedvező árat mond a kivitelezésre, akkor neki jó fejlődési lehetőség, referencia munka + még így is plusz lóvé.
    A cégnek pedig lehetőség, hogy olcsón kapjanak egy viszonylag használható rendszert.
    A nagyon necces dolog ebben a szűk határidő. 2 hónap teljesen felejtős szerintem.
    chikk írására pedig: Amikor átláthatatlanná válik, felsóhajt, felkiált, hogy tanulópénz, újraírja és legközelebb már figyel erre.

    Ott van persze a másik lehetőség, hogy nem elég tehetséges, kitartó és bukik a mutatvány.
    Mutasd a teljes hozzászólást!
  • És nem egyből a legösszetettebb architektúrát akarom összehozni. És amúgy a cégnek sem kell egyből minden, lépésről lépésre haladnánk. Először a raktár nyilvántartást aztán a termelési adatok bevitelét kell hozzátenni.


    Ez minden esetben ott szokott bebukni, hogy a folyamatosan pumpolod egy olyan kódba az új modulokat és a főnök agymenéseit, aminek az eredeti specifikációja és architektúrája nincs erre felkészítve = gyűlik a gány, egyre csak gyűlik. Ez a gány jó vastag, lévén ezen a projekten tanulod meg az egész felépítésének módját is.

    Ez az egész fenntartható egy bizonyos pontig, ami után aztán olyan mértékben átlathatatlan és tetűlassú lesz az egész, hogy nem marad mád: újraírni. A főnök meg nem fog ezért + egy projekt árát kifizetni, ehhez nyugodtan támaszthatsz biciklit.

    Én _mindenképpen_ az javaslom, hogy valam CAB alapján állj neki a fejlesztésnek, mert az legalább már a kezdetektől belekényszerít egy rugalmas, moduláris architektúra felépítésébe, így később nem lesz gond a bővítés és bizonyos modulok újraírása.
    Mutasd a teljes hozzászólást!
  • Amúgy nem is baj talán a fejlesztők szempontjából, hogy elindulnak ilyen cégen belüli miniprojektek, mert legalább kiderülnek az igények.

    Nyilván nem ez az igazi hanem

    Felmérik az igényeket, készítenek egy köv. speckót, és adnak rá egy határidőt, és árajánlatot.

    de ez is egy lehetőség az igények felmérésére
    Mutasd a teljes hozzászólást!
  • Ok, bocs, félreértettem :)
    Mutasd a teljes hozzászólást!
  • -ami amúgy elég komplex- full .net, C# és PHP-t is használtam benne pár helyen.

    Csak az a gáz hogy még munka mellet csinálom ezt. És nem egyből a legösszetettebb architektúrát akarom összehozni. És amúgy a cégnek sem kell egyből minden, lépésről lépésre haladnánk. Először a raktár nyilvántartást aztán a termelési adatok bevitelét kell hozzátenni.

    (Ő amúgy azt mondta nekem elég a legegyszerűbb dolog amibe beleírják a dolgaikat és kész)


    Na hát itt kezdődnek a bajok :D
    Na én nem okoskodom tovább, majd fél év múlva szóljatok, és jó pénzért újraírjuk. ;)
    Amúgy nem is baj talán a fejlesztők szempontjából, hogy elindulnak ilyen cégen belüli miniprojektek, mert legalább kiderülnek az igények.
    Mutasd a teljes hozzászólást!
  • Kicsit előreszaladtam: ezt Norb88-nak szántam, hogy fontolja meg ezt az egyedül csinálom dolgot és keressen egy profi céget ehez, ezért reagáltam a Te hsz-edre...
    Mutasd a teljes hozzászólást!
  • Nem értelek. :)

    Ha egy értelmes szervezőről van szó, akkor ő nem fogja azt mondani, hogy 2 hét alatt kulcsrakész a dolog. Jobb cégeknél megvan a normális menete az egyedi alkalmazások fejlesztésének.
    Felmérik az igényeket, készítenek egy köv. speckót, és adnak rá egy határidőt, és árajánlatot.
    Ha elfogadja az ügyfél, jön a fejlesztési időszak, menetközben a szállítói tesztelés, végül egy tesztelési lista alapján az ügyfél leteszteli az alkalmazást, amit mindketten aláírnak.
    A végén kap egy teljesítésigazolást a fejlesztőcsapat és mindenki boldog.
    Természetesen lehet vállalni supportot az alkalmazásra, de ez már megint egy más dolog.

    Csupán arra akartam rávilágítani, hogy ez egyedül nem fog menni, ilyen csapjunk a lecsóba, gyorsan megtanulom, holnapra kész van főnök módszerrel...
    Mutasd a teljes hozzászólást!
  • Nos tapasztalatom még valóban nincs, de azért hülye nem vagyok. A kiváló minősítésű szakdogám -ami amúgy elég komplex- full .net, C# és PHP-t is használtam benne pár helyen.

    De nyilvántartó rendszert még nem készítettem.

    Én úgy érzem hogy képes vagyok új dolgokat viszonylag rövid idő alatt megtanulni. Nyilván nem két hét összehozni a rendszert de szerintem 2 hónap minimum benne van. Csak az a gáz hogy még munka mellet csinálom ezt.
    És nem egyből a legösszetettebb architektúrát akarom összehozni. És amúgy a cégnek sem kell egyből minden, lépésről lépésre haladnánk. Először a raktár nyilvántartást aztán a termelési adatok bevitelét kell hozzátenni. Ekkor már lesz a főnöknek a cégről egy adatbázisa lekérdezésekkel, jelentésekkel, ami már nagy fejlődés neki a jelenlegi semmilyen informatikai rendszer után. Ezért jelenleg azt sem tudja pontosan mibe ruház be. (Ő amúgy azt mondta nekem elég a legegyszerűbb dolog amibe beleírják a dolgaikat és kész) De tudjuk milyen az ember ha meglátja valamiben a fantáziát...

    Aztán jöhet a website és majd ott jöhet a képbe a rendszerek összehangolása. (egyáltalán igénylik-e ezt a fajta intelligenciát a rendszertől vagy az is tökéletesen elég nekik ha e a két dolog független és a website-nak elég egy CMS rendszer amiben mindig feltüntetik a legújabb termékeiket vagy akcióikat. Ez még nem derült ki)

    Viszont a lehetőségekkel nekem kellene tisztában lennem hogy javaslatokat adhassak nekik hogy mit lehet megvalósítani, az milyen előnyökkel jár és mennyibe kerül és ez alapján egy jó döntés szülessen meg.
    Mutasd a teljes hozzászólást!
  • Akkor meg vagyok győzve. A főnöknél biztosan ott a prof., már csak a diák (.pps) miatt is
    De mondjuk ha valaki azt mondaná hogy accessben csináljam meg a legutolsó php-s munkám, azért rendesen összef..snám magam. De nyilván c#-ban se lenne leányálom számomra Szóval, a kérdés, hogy norbi88 mihez is ért. Ha semmihez, akkor interpet2 véleményét osztom én is.
    Nem lesz ez a project olyan drága. Végső mentsvárként itt van roliika.
    Mutasd a teljes hozzászólást!
  • Főleg ilyen pályázatoknál! Igen könnyen be lehet bukni határidő be nem tartása, vagy specifikációtól eltérés miatt.
    Aztán jön a tulaj kártérítésért. Meg kéne ezt fontolni..
    Mutasd a teljes hozzászólást!
  • Öööö, csak én értek félre valamit?

    Most arról beszélgettek, hogy Norb88 gyorsan megtanul programozni c#-al/php-val, és minden nulla tapasztalat nélkül felépít egy bonyolult architektúrát, és megvalósít egy rakat komplex üzleti funkcionalitást 2 hét alatt? :)

    Most nem azért de jópár kezdővel dolgozom most is, és előtte is volt velük dolgom, és nem két hét alatt jutnak olyan szintre (már aki képes eljutni odáig), hogy ne kelljen fogni a kezüket. Ha csinálnak is valamit, akkor is ostorozni kell őket, hogy mit gányolnak már megint...

    Én a helyedben azzal kezdeném, hogy az igények felmérése után megkeresnék egy céget, akik ezzel foglalkoznak, és a szervezőjükkel megalkotnék egy követelményspecifikációt, és lefejlesztetném.

    Az hogy így mennyibe kerül az egy más tészta, de reálisabb az esély, hogy belátható időn belül lesz is valami belőle...
    Mutasd a teljes hozzászólást!
  • Hát, azért nem. Az Access gépenként 70e körül van ha jól tudom

    Ezt nem értem....

    A cégnél nem vesznek Office-t? Akkor nem Basic-et (53490) kell venni, hanem Profit (Microsoft Office 2007 Professional OEM 99500 (Bruttó))
    Akkor csak Br. 44000 a különbség.

    Ezt 1 gépre (fejlesztő) a többire meg futtatókörnyezettel lehet használni.
    Mutasd a teljes hozzászólást!
  • Így van!

    Nincs még tapasztalatom, és jól látod, a legnagyobb probléma a határidő lesz, ugyanis a pályázatok határidőkhöz vannak kötve (ráadásul ez most elég rövid lesz)

    Amúgy lehet használni Access Runtime-ot is a gépeken és akkor nem kell gépenként megvenni?
    Mutasd a teljes hozzászólást!
  • Kösz a javaslatot!

    Szerintem amit leírtál az a TOP. Nagyon szuper, logikus felépítést javasoltál. Valószínű ilyen keret nincsen de ez függ a megrendelő által nyert pályázattól is. Szóval még nem tudom mi lesz, de fel szeretnék készülni minél több esetre.

    Személyeskedés->Egyáltalán nem sértődök meg, mert ha olyan profi lennék hogy ezeket amiket leírtok mind tudnám már, akkor be se írtam volna.

    Valóban nincs tapasztalatom ezen a területen, DE pont azért kérdezek ezeknek utána hogy el merjem kezdeni és hogy több legyen a tapasztalatom.

    Valahol el kell kezdeni.

    Eddig is voltak olyan megbízásaim hogy a legelején azt sem tudtam hogyan kezdjek neki, de szerencsére a kitartó munka és a külső segítséggel sikerült összehozni a dolgot úgy hogy évek múlva sem kellett hozzányúlni.
    Mutasd a teljes hozzászólást!
  • A PHP-ben is lehet jó dolgokat csinálni, de maga a nyelv nagyon csábít a gányolásra. Iszonyúan jó, tapasztalt és fegyelmezett programozó kell ahhoz hogy valaki PHP-ben ne olyan dolgot csináljon amiben ha fél év múlva bele kell nyúlni akkor régen rossz.

    Ami a bonyolultságot illeti, nekem ez épp elég bonyolultnak tűnik, legalábbis megvan benne a lehetőség hogy az legyen. Persze nagyon keveset lehet innen látni a dologból, de amiket én eddig láttam ilyen rendszereket azok minden voltak csak egyszerűek nem.

    Ez innen nézve inkább a fejlesszük ki az SAP-t olcsóért dolognak tűnik. De ne legyen igazam.
    Mutasd a teljes hozzászólást!
  • Hát, azért nem. Az Access gépenként 70e körül van ha jól tudom. Viszont böngésző már mindegyik gépen van. Egyébként körülbelül annyira jó mint az ASP. Csak PHP-nél még a szerver is megspórolható. De úgyse lesz megspórolva, mert senki nem ért majd hozzá a cégnél. Persze a Windowshoz se ért senki, csak hát mégis az van otthon és az ismerős Így felrakják majd egy Windowsra a wampot.
    Lehet persze c#-ban gondolkodni. Annyira nem látok bele a feladat bonyolultságába, lehet meg is térül mind időben, mind anyagilag. De szerintem ez nem lesz olyan bonyolult rendszer, mint a Tiéd. Amúgy sincs akkora tapasztalata, se annyi ideje Ha viszont csak úgy összedobálja a komponensekből (editbox, lista, stb), majd összeköti a táblákkal a komponenseket, akkor semmivel sem lesz előrébb, mintha php-val csinálta volna az egészet. És még időben sem lesz kész hamarabb.
    Mutasd a teljes hozzászólást!
  • A PHP pont annyira jó erre mint az access. És pont ugyanazért.
    Mutasd a teljes hozzászólást!
  • Nem tűnik a program olyan túl komplikáltnak.
    Én php-ban csinálnám az egészet. Ha már generátorokban gondolkodsz, mindegyik keretrendszer tud olyat, vagy majdnem olyat. Nézd meg a symfony-t, ahhoz rengeteg kész plugin is van (pl:cms) és a generátora is nagyon jó. Bár, php ismerkedéssel egyszerre, nem könnyű anyag...
    Mutasd a teljes hozzászólást!
abcd