Ügyviteli rendszer fejlesztéshez
2016-10-20T12:08:17+02:00
2016-10-25T06:13:14+02:00
2022-06-29T11:36:56+02:00
  • Amúgy tényleg jól megy a dolog.
    A jelenlegi csapat teljesen le van foglalva, nincs szabad erőforrás, ezért is van szükség
    újakra.
    10-ből 1 "client from hell" előfordul, igen. Látom Te is láttál már ilyet...... :) :) :)
    Mutasd a teljes hozzászólást!
  • Mivel mindenki csak feltételezett valamit, az ötletek is teoretikusak voltak. "Ha, ... szerintem akkor..."   Tanulni viszont ebből is lehet, hiszen az eredeti felhívástól függetlenül előkerülnek technológiai tanácsok, vélemények.

    Az eredeti felhívásról is összeált a kép (gondolom én). Mármint az üzleti logikáról és a hírdetésben a technológiapontosítás hiányáról. A cégetek megszerzi a feladatot (megrendelést) és saját+külső erőforrást próbál allokálni hozzá. Ha X technológiához értő guru jön, akkor megvizsgáljátok, azzal működhet-e a megoldás, Y tech-es szaki jelentkezése esetén pedig azt.

    A cégadatokból úgy látom, működik ez a modell. Gond csak akkor van, ha nincs szaki a projektre és pl. időkényszerben, teljesítési kényszerben vagytok, vagy belefuttok egy "Clients from Hell" tipusú megrendelőbe...

    De ne tanítsak már baglyot huhogni, ezt Ti biztosan jobban tudjátok.
    Mutasd a teljes hozzászólást!
  • Csak érdeklődésképpen, nem kötekedésből, egy észrevétel:
    Ha ennyi vállalatirányítási rendszert fejlesztetek párhuzamosan, szerintem az lenne az optimális, ha minél közelebb állnának egymáshoz technológiai szempontból. 
    Gondolom supportálni is kell majd őket, mivel vállalatirányítási rendszerekről van szó, így könnyebb lenne átrakni egy hasonló fejlesztői stack-el rendelkező fejlesztőt az egyik rendszerről a másikra, ha kiesik valaki.
    Mutasd a teljes hozzászólást!
  • Köszönöm, Csak segíteni, lefordítani próbáltam és egyben a programozók számára is közelebb vinni a téma megértését.
    Mutasd a teljes hozzászólást!
  • Egyébként nem szabad túldimenzionálni a feladatot.
    Vállalatirányítási rendszerekből jelenleg is 18 fejlesztésünk fut párhuzamosan.
    Ez egy újabb szép példány lesz, már nagy tapasztalatunk van e téren.

    (szándékosan egyediek mind, s nem dobozos, mint másoknál - nem egyszerű,
    de ez a cég pont ettől más)
    Mutasd a teljes hozzászólást!
  • Köszi szépen a pozitív hozzáállást.
    Érdekes, milyen sok hozzászólás jött és az is, hogy mennyire elkanyarodott
    a téma mindenfelé :)
    Mutasd a teljes hozzászólást!
  • Szia Qrump Lee,

     Tudod, azért nem definiáltak a részletek, mert ez csupán egy figyelemfelhívás.
     Bevallom mindig így szoktunk új és értelmes embereket keresni a csapatba
     és eddig szépen bevált.

     Illetve, ha megszabnánk a részleteket, akkor az ügyes fejlesztők egy szegmensétől
     elesnénk úgymond.
     Inkább jöjjön mindenki, akit érdekel és a megfelelő emberekkel majd együtt eldöntjük a technológiát, ami a meghatározott cél (ügyviteli rendszer és azok funkciói) alatt idézőjelben, de másodlagos és picit még ráér.

    Ez persze csak az én véleményem, kösz, ha elolvastad, s a meglátásod is érdekel.
    Mutasd a teljes hozzászólást!
  • Amiket kommenteltem ebben a társalgói témában, számomra is csak feltételezések.
    Számomra korrekt cégnek tűnnek. 
    Amit lehetett itt elmondták.
    Biztos vagyok benne, hogy sokan a megadott Email elérhetőségükön érdeklődnek. Bátorság!!
    Próbálkozz - próbálkozzatok ott többet megtudni a projektről.
    bovit
    Mutasd a teljes hozzászólást!
  • Én nem is arra céloztam, hogy ki kellene adni bármiféle szakmai részletet. Közel s távol elő nem került még olyan kérdés (páran lentebb feszegették, de az nem én voltam). Amire én gondoltam rávilágítani, hogy még csak a korlátok elnagyolt felmérése zajlik, de már első körben is amik előkerültek (és csak a hirdető postjaira értem), minimum külön cég fog ahhoz kelleni.
    Mutasd a teljes hozzászólást!
  • Csak a véleményemet mondtam el.
    Mert ez egy állásajánlat "vélhetően" nem publikálható tartalommal. A cég helyébe én magam már az alkalmazott programozóknak is részfeladatokat adnék, rész ismertetőkkel. Az ismert kód felhasználás teljesen közismert a programozók körében. Majdnem már csak ezekkel dolgoznak. Azért javasoltam annak mellőzésének javaslatát, hogy a jelentkező programozóról legyen olyan kép, amivel ismert kódfelhasználás nélkül is tud kreatívan programozni. A varázsszó a kreatív. Javaslom, erről próbáljátok meggyőzni a munkaadót.

    Ezek csak javaslatok. Hogy gondolkozom magam erről.
    Mutasd a teljes hozzászólást!
  • Szerintem meg nem tiszteletlenség rávilágítani arra a képtelenségre, hogy "nem definiált" fejlesztési technológiához és "nem definiált" adatbáziskezelőhöz értő szakembert keresnek.
    Lehet, hogy a személyesen érdeklődőknek már többet tudnak négyszemközt mondani, de lesz KOMOLY SZAKEMBER érdeklődő egy ilyen megfogalmazású felhívásra? Szerintem nem.

    Témajavaslatodad elolvastam. Elvetem. Ha valami nem okés a hozzászólásokkal, a moderátor majd szól.

    Az, hogy nem szereted a kód-, vagy program- újrafelhasználást, az meg érthetelen számomra, de biztos félreértek valamit. Design pattern-ek az örödögtől valók?
    Mutasd a teljes hozzászólást!
  • Kérem a téma hozóval nagyobb tiszteletet tartsatok.
    Javasolnám azon már megvalósított témákra megnézését is.
    Vélhetően egy nagyformátumú online ügyviteli rendszer kiépítéséről lehet szó.
    Még az is lehetséges, hogy állami-kormányzati megrendelés.
    Éppen emiatt feltételezem, hogy még ismeretlen online ügyvitel kivitelezése a cél. Ezért ez egy eléggé komplex ügy lehet.
    Ezeket, vagy hozzá hasonlókat nem írhatnak le!!

    Javasolnám nektek, hogy olyan témákkal igyekezzetek magatokra felhívni a figyelmet, ami bármely életszerű programozási feladat megoldásának megfelelőségét célozzák. Tehát eltávolodnák a programozóknál szokássá vált már ismert megoldások adaptálásával igyekezzenek megfelelést igazolni a feladat megoldására. Ezzel persze bizonyítva, hogy a feladat megoldásához ebben is „képben” vannak. Magam részéről sem szeretem, ha egy programozó az általam megbízott feladatban meglévő programokat használ fel. Ennek számos oka van.

    Természetesen adatbázis építő és adatbázis kezelő program társítására szükség lehet. Mert ami megvan az nem kell megcsinálni.
    Mutasd a teljes hozzászólást!
  • Ha csak vázlatosan leírnák itt az eredeti problémát (ügyfélkérést), lehet hogy már kódolná valaki nekik.
    Mutasd a teljes hozzászólást!
  • Az izgalmas lehet, amikor egy "rendszerház"-nak érintőlegesen sincs elképzelése az ügyféligény megvalósíthatóságának mikéntjéről...
    Mutasd a teljes hozzászólást!
  • A jelek szerint még odáig sem jutott a történet érdemben, hogy szakmai kérdések előkerülhetnének.

    Nekem van egy olyan gyanúm, hogy valaki felvetett egy ötletet, amiről előbb azt kellene eldönteniük, képes-e a valóságban létezni, és kiadták a hr-esnek, hogy keressen embereket, mert senki sincs a csapatukban, akiben meg is bíznának, meg értene is hozzá. Szerinted mi lesz annak a vége csapatmunka szintjén?
    Mutasd a teljes hozzászólást!
  • Mi van a MariaDB-vel? Az egy MySQL fork amit akkor csináltak mikor az Oracle megvette a Sunt. Elvileg már gyorsabb is mint a MySQL nem mellesleg már a nagy linux disztribútorok is áttértek már rá. Pl. a RedHat.
    Mutasd a teljes hozzászólást!
  • Bár én se vagyok ennek a szakértője de a noSQL-t nem azért használjuk mert menő hanem mert sokszor egy adott feladatra nem hatékony.
    Például árfolyam adatokat akarsz tárolni majd visszaolvasni (időben egy egy tartományt) vagy egy IoT berendezés például egy hőmérő percenkénti adatait elmenteni. Ebben az esetben mindig a végére szúrod be az elemet, nem akarsz indexelni a dátumon kívül semmit, a lekérdezéseid nem tartalmaznak bonyolult joinokat sok tábla között csak get from to datetime jellegűt. Na ilyenkor lép a képbe mondjuk egy TimeSeries adatbázis (ez egyfajta noSQL) ami erre van optimalizálva.
    Amikor rendes tábláid vannak azok közötti relációkkal akkor relációs adatbázis érdemes használni :)
    Mutasd a teljes hozzászólást!
  • Nem vagyok adatbázisos, ezért kérdezem a szakértőket !
    Miért nem jó a nagyon fejlődő noSQL rendszerek?
    pl. Redist?
    Mutasd a teljes hozzászólást!
  • MS SQL Express teljesen kihullott? Miért?

     - Üzleti alkalmazáshoz is ingyenes.
     - pl. 2014-es kiadásban 10Gbyte lehet az adabázis mérete, amiben sokmillió soros táblák vígan elvannak. (1 socket, max 4 mag, max 1Gbyte RAM használat mellett)

    Klasszikus Cliens/Server alkalmazásokhoz átlagos cégméret ügyviteléhez szerintem tökéletesen elegendő. ( a "szerintem" itt saját tapasztalatból ered)
    No persze az  "esszápét" nem erre kell uszítani.
    Mutasd a teljes hozzászólást!
  • A MySQL kicsit szerényebb, de a feladatok zömében elegendő tudású és nem mellesleg ingyenes - ami ugyi' a vevő számára nem lényegtelen szempont.

    Pontosítsunk: a MySQL Community Edition-t bizonyos feltételek esetén használhatod ingyenesen, és csak ha betartod a licenszfeltételeit (GPL). Ha ez nem megfelelő, akkor vásárolhatsz kereskedelmi licenszt.

    A GPL pedig elég korlátozó, így egy MySQL egy telepített ügyviteli rendszer mellé ingyenesen csomagolva nem biztos, hogy a legmegfelelőbb választás.
    Mutasd a teljes hozzászólást!
  • Kedves jelentkező kollégák!
    Végigolvasván a hozzászólásokat, csak vitát látok - ami nem is baj, mert a vita előre visz, de...
    Nem tudjuk pontosan, hogy :
    - ebbe a team-be hány főre számítanak; Ha 2 programozó kell, akkor fölösleges tolakodni.
    - azt sem tudjuk, mik a feltételek;
    - mi alapján válogatják össze a társaságot;
    (az egyikünk Delphi5-ben, míg a másik RAD XE10-ben fog fejleszteni?)
    Ha egységes platformban nem állapodunk meg, akkor könnyen szétcsúszik az egész.
    Az Oracle szuper, nagyvállalati szinten és méreg drága!
    A MySQL kicsit szerényebb, de a feladatok zömében elegendő tudású és nem mellesleg ingyenes - ami ugyi' a vevő számára nem lényegtelen szempont.
    - Ha egységesítünk, a megrendelő ellát minket majd a munkához szükséges egységes és jogtiszta szoftverekkel?
    Azt vettem észre, hogy a felhasználó az egyszerű logikát és az egyszerű felületet szereti.
    Néha velünk - programozókkal - el száll a cocó! (Lásd az előbbi hozzászólásokat).

    Csak a vicc kedvéért mesélem: Pár éve jelentkeztem egy pesti céghez informatikusnak. Volt egy kérdőívük vagy 80 kérdéssel: a DDL sql-től a web fejlesztésig. Vagy 50-et ismertem, 20-ról hallottam, 10-ről soha. Persze nem kellettem, de a végén azért nem álltam meg:
    - Megvan! Maguk szuper man-t keresik, nem?

    Talán ha ismertetnék a programmal kapcsolatos elvárásokat, eldönthetnénk, hogy otthon vagyunk-e a témában vagy sem.
    Mutasd a teljes hozzászólást!
  • Szia Hurka,

      Nos ezt mindig akkor döntjük el, amikor már alaposan átbeszéltük közösen a csapatban,
     hogy melyik adatbázis kezelő rendszer az indokolt.
     Kiválasztjuk, amelyik pont oda illik.
     Ez esetben vagy MsSQL, vagy Oracle lesz.

     köszi a jogos kérdést!
    Mutasd a teljes hozzászólást!
  • Kedves Stella,

     Hidd el nekem, amiket kérdezel a (fontos) részletek.
     Most még csak ott tartunk, hogy keressük a megfelelő kollégát
     és gyakorlatilag ő is keres minket. :)

     Utána jöhet mindez!

      köszi azért!
    Mutasd a teljes hozzászólást!
  • szia,

     nagyon köszi, teljesen igazad van.
    Mind a Telerik, mind a Devexpress-t használjuk és tényleg hasznosak/szépek!

      Hali: Pedor
    Mutasd a teljes hozzászólást!
  • Ismerős helyzet. Anno volt két párhuzamos projektem, ahol az egyikben programozó matematikus volt a kóder, a másikban egy ipari mérnök kódolt autodidakta módon fejlesztve magát.
    Amikor azt mondtam mindkettőjüknek, hogy másnapra működnie kell a programjuknak, mert átadás van, akkor a mérnök azt mondta: Kész, működik, de nem optimálisan. A progmatos azt mondta, egész éjjel optimalizálta az ős "fill" függvényt és már háromszázszor gyorsabb mint a gyári rutin, de a programból még hiányoznak funkciók, mert nem maradt rájuk ideje....

    Levontam a tanulságot. Hiába kiváló elméleti szakember valaki, ha a "közgazdasági korlátokat" (pl. határidő) nem képes megfelelő súlyán kezelni. Ennek megfelelően másképp kezeltük és más jellegű feladatokra osztottuk őket. MIndketten ki tudták hozni továbbra is a maximumot magukből.
    Mutasd a teljes hozzászólást!
  • Nézőpont kérdése. Van ahol annyira nincs pénz, hogy Unit teszteket sem írnak, mert fölöslegesnek tartják. Van ahol teszterek sincsenek. Én nem ilyen helyen dolgozok és nem olyan ügyfeleknek akik elfogadnák ezek hiányát...
    Mutasd a teljes hozzászólást!
  • Mert te a legoptimálisabb dolgot akarod megcsinálni (ugye ilyen szó nem is létezik, bocs :) ) én pedig az optimális megoldást nézem minden szempontból beleértve a pénzügyi és megtérülési dolgokat is. Egy ideális utópisztikus világban ahol senkit nem érdekel a pénz és a fejlesztés szépsége meg az élvezete a lényeg ott lehet a te megoldásod lenne a nyerő de a világ nem ilyen. Egy ügyviteli rendszer meg főleg nem.
    Mutasd a teljes hozzászólást!

  • Ha pedig már a UI tesztek szóba kerültek gondolom tudod, hogy ezekhez a komponensekhez vannak ám ilyen végigkattintós tesztelő programok is

    Olvasd el újra, amit írtam a tesztelésről.

    Nézzük másképp. Nincs szükség 1500 féle control-ra egy alkalmazáshoz sem. Ha igen, akkor ott valami nagy tervezési hiba van és a felhasználók nem fogják érteni hol és mit csinál a szoftver.
    ....
    Mint írtam nem szerszámokat akarok méricskélni, csak nem értek veled egyet. Tapasztalataink is elég különbözőek lehetnek... Én inkább szeretek fejleszteni, mint hegeszteni...
    Mutasd a teljes hozzászólást!
  • Nem célom, hogy egymás szerszámát méricskéljük, de hidd el, hogy egy olyan cég mint pl a Deutche Telekom rendelkezik elegendő erőforrással ahhoz, hogy ne third party cuccokat használjon, hanem saját fejlesztőket tartson akik megcsinálják amit kell... Nem, nem nekik dolgozok, de dolgoztam az ő rendszerükön is.

    Érdekes, mert én amikor egy projektet vezettem egy cégben a Magyar Telekom számára akkor az első lépés az volt, hogy akkor milyen komponens gyártó cuccát is használjuk. De mondjuk a mostani munkahelyemen (nagy amerikai befektetési bank) is Infragistics kontrollokat használunk (mondjuk ezek sokkal bénábbak mint a Devexpress).
    Szóval lehet, hogy el tudod adni a projekted, hogy oda egyedi kontroll kell de nem ez a jellemző és üzletileg egyáltalán nem éri meg újra feltalálni a kereket. Mint mondtam nem fogsz egy pivot gridet elkezdeni faragni. Mellesleg erre nem válaszoltál, hogy ha mondjuk egy grafikont kell kiraknod a felhasználónak akkor elkezded nulláról megírni?
    Itt pedig egy ügyviteli rendszerről van szó. Tehát kell hozzá legalább egy grid, egy grafikon rajzoló, egy scheduler control, egy pdf kezelő (igen ez is van bennük), egy riport készítő.
    Nem árt ha a felület valamilyen szinten dokkolható. Ha ezeket magad írod meg több év lenne az ügyviteli rendszered megírása míg ha legó szerűen összelapátolod az egész pár hónap alatt kész is van az egész és fizettél értük 900 dollárt.

    Ha pedig már a UI tesztek szóba kerültek gondolom tudod, hogy ezekhez a komponensekhez vannak ám ilyen végigkattintós tesztelő programok is. A tesztelő szoftvert gyártó cégek megcsinálják az összes nagy komponens gyártóra. A HP-nak van valami ilyen cucca, nálunk a QA azt használja.
    Mutasd a teljes hozzászólást!
  • ... 

    Erre nem igazán tudok mit írni. Nem célom, hogy egymás szerszámát méricskéljük, de hidd el, hogy egy olyan cég mint pl a Deutche Telekom rendelkezik elegendő erőforrással ahhoz, hogy ne third party cuccokat használjon, hanem saját fejlesztőket tartson akik megcsinálják amit kell... Nem, nem nekik dolgozok, de dolgoztam az ő rendszerükön is. 

    Nem csiszolgatni kell, hanem adott feladatra megalkotni...

    Én úgy gondolom, hogy mindenre érdemes automata tesztet készíteni, nem csak az üzleti logikára.
    Amin pl most dolgozunk ahhoz van 3 tesztelőnk, vannak Unit tesztjeink és van automata UI teszt is. Tehát egy program ami végigkattintgatja a programot minden nap többször is...  

    Ha bonyolultabb control-t készítesz ott azért van némi egyéni logika is mögötte, de nem úgy kell megnézni, hogy működik-e, hogy minden módosításnál végigkattintgatod a control-t...
    Mutasd a teljes hozzászólást!
abcd