Óranyilvántartó program projekt

Qtopiaval keverheted, Symbian support csak >>4.6-tol van!

A Qt már ezer éve forrogat. Kétlem hogy ennél sokkal jobb lesz. És a mobil verziója is van már vagy 5 éves.

A Nokia szamara a Symbian legalabb annyira fontos, mint a MeeGo, QT-ben meg Symbianra is fejleszthetsz ujabban. Ha majd kiforrott lesz, ugyanazzal az APIval fejleszthetsz majd desktopra es Nokia mobilra!

Én simán bevezetnék egy MS Projectet vagy egy CA Clarity-t. Oktatással együtt is kb olyan árra jön ki, mint egy saját fejlesztés (hacsak nem Pistikét választják, akinek az alkalmazásával éppannyira elégedetlenek lesznek, mint a ostanival) de tudásban sokkal több is lehet.

Ha ez nem jó, akkor SQL Server + ASP.NET a kliensre (és akkor kutyát nem érdekli, hogy komolyabb mobil vagy notebook). Manageri modul vagy ASP.NET vagy Winform - attól függ mennyire kell bonyolultra. Reportokra meg SSRS.

Azért az életben a dolgok ritkán ennyire egyszerűek.

Az eredeti kiírás arról szól, hogy a dolgozok olyan helyeken dolgoznak, ahol legfeljebb 3G van. És hogy minden dolgozó (tehát nem a brigádvezető) kellene berögzítse magát. Én ebből önállóan, a Te segítséged nélkül is, kikombináltam, hogy esetleg mobilon fogják ezt megtenni. A brigádvezetőnek esetleg van egy HTC-je, a dolgozóknak meg...

Azt meg írtam, hogy comboboxnál lehetnek problémák a főnöki modulban. Mindenesetre egy autocompleter manapság annyi, hogy a form osztály setupjában kiadsz egy ilyet:
Neked ez hatalmas szívás?

Ritkán változó nagy táblák meg nincsenek a dolgozók esetében. A dolgozó bejelentkezéskor azonosítva van. A projektek száma amihez hozzáírhatja az óráit kb. egyszerre 3db. A többi projekt egyrészt le van zárva, másrészt nincs hozzárendelve a dolgozó. Egy dátumválasztó meg ne legyen már nagy terhelés, de mivel napi szinten kell berögzítenie magát, nem is kell dátumot választani. Szóval eddig van egy select, amiben van 3 project és egy text mező, ahová a számot (jelen esetben az óráit) beírja. Ez ne terhelje már le a hálózatot...
Ez lenne úgy a dolgozói modul.

Akkor van a brigádvezető modul.
Ott már ki kell tudnia választani a brigádba belehelyezett dolgozókat. Ez olyan 40 főnél nem több szerintem. A projektet itt is csak kiválasztani lehet. De az aktuális projektek száma itt akár még elérheti a 6 rekordot is! ezeket össze vissza lehet kapcsolgatni. És meg lehet nézni hogy Kis Jakab hol dolgozik és felvette-e már a munkát. És esetleg van egy üzenet Kis Jakab részére, hogy hol és pontosan mit csináljon.
Szóval még sehol a láthatáron egy hatalmas tábla és adathalmaz.

Akkor jöjjön a főnöki modul.
Itt le kell tudni zárni a projekteket.
És bizony megjelenik az első nagy tábla, ahol esetleg egy autocompleterrel kell dolgoznunk. Mert itt már keresni is kell tudni a lezárt projektekben és azokat akár újból meg is kell tudni nyitni. De alapesetben itt is csak az épp futó projektek, kb 20-30, vannak. Viszont a dolgozok is lehetnek akár már 300-an is. Mondjuk még ez sem tétel, de itt is bejátszhat egy autocompleter.

Statisztikák készítésére hasonlóan egyszerűen kerül sor. Nálam annyi hogy van egy XML ahová beírom a queryt és az input mezőket. Aztán hajrá. A kérdezés mehet Excelbe, HTML táblázatba, vagy pdf-be, vagy csv-be, vagy sima szövegként. A generálás húszezer rekordnál sem több néhány másodpercnél. A letöltés már tarthat akár még néhány másodpercig is egy normális átlagos ADSL mellett.

Eddig semmi olyan nem került elő, ami ne egy tipikus webalkalmazás lehetőségét vetné fel. Ennél sokkal, de sokkal összetettebb mondjuk a felvi.hu, de még akár egy önkormányzati időpont foglalás is. Pedig azok is elfutnak a weben. Az előbbi ráadásul az általad utált PHP-n.

Szóval, szerintem teljesen mindegy miben csinálod. Ennél a projektnél nagyságrendekkel több idő fog elmenni az egyeztetéssel, kívánságok értelmezésével, mint magával a megvalósítással.

Kedves LC. Én már 2 éve Ajax-ozok, úgy, hogy kvázi még egy sor javascriptet sem írtam.
Igaz, elsősorban belső fejlesztés, és üzleti alkalmazás, nem csilivili portál amit csinálok, így az a 50-100 tool, ami alapból benne van néhány ajax framework-ben, nekem általában elég szokott lenni.

Szerintem túl sokáig nem. A Nokia is megy linux irányba, a többi nagy gyártó pedig mostanság inkább androidozik, és ezen max. az új winmo fog változtatni.

Nem. Az eredeti kiírás pár munkaállomásról és 1-2 laptopról szól. A mobil cuccokat már én hoztam fel mint alternatívát.

A webes user interfész azért erőltetett, mert Pl. egy comboboxnál az összes elemet le kell húznod. Vagy ajax, de az már kb. 50x akkora szívás mint ugyanezt megcsinálni vastag klienssel, és még mindig nem tudod Pl. letenni lokálisan a ritkán változó illetve nagyobb táblákat, azaz szép nagy forgalmat generálsz a hálón, ami különösen wi-fi kapcsolat esetén nem öröm.

Hidd el, nem véletlenül vannak a vastag kliens pótlékok a webes UI-hoz (ajax, flex, silverlight), a hagyományos vékony kliens elég nagy szívás az end-júzernek nagyobb adatmennyiség esetén, és ezt kellett valahogy kiváltani. Ebből a flex és a SL az ami többé-kevésbé alkalmas is erre.

Annak ellenere, hogy messze a vezeto mobil OS, es az is marad egy jo ideig...

Azért a .NET hasonlóan a javához elég stabil dolog. Alapvetően a Delphi is stabil volt, csak a .NET igazából kifogta a vitorlájából a szelet, linuxon pedig nem tudott megkapaszkodni. De ha a Borland kicsit bátrabban és okosabban gazdálkodik a Delphi platformmal akkor az is vígan túlélhetne és lehetne harmadik erő a .NET és a Java mellett.

Szerintem ha üzleti mobil cucc azt mindig is windows mobile-nak fogják hívni. A symbian halott, az android pedig nem igazán elég stabil üzleti platformnak. Webes alapon pedig ilyesmit csinálni szerintem bűn a felhasználó ellen.

Mennyi is jelenleg a Win Mobile piaci reszesedese..? Es mennyi lesz 2012-ben a >>Gartner szerint..?

Tudjuk hogy parázol a linuxszal szemben és hogy egy PHP-s, de akár egy bármilyen webes megoldást nem tartasz elég elegánsnak még egy sima form elkészítéséhez sem.

De itt mi lesz a feladat?

Lesz 88 féle platform. Mert nem lesz minden munkásnak netbookja, nem lesz mindegyiknek új windows 7 mobileja. Helyette talán lesz egy céges teló, ami esetleg valami HTC, vagy annál egy kicsit gyengébb, javas cucc.
Erre pedig a legalkalmasabb egy webes felület. Olyan ahol nincs semmilyen ajax. Belépés után azonosít, szigorúan csak az azonosított ember lezáratlan feladatai, projektjei jönnek elő (2-3 record), egy dátum és egy időválasztó, esetleg még 2-3 mező. Szóval semmi olyan ami egy webalkalmazásnál iszonytató bonyolult lenne. Mint egy regisztrációs űrlap. Körülbelül egyszerre 1 ügyfél akar a szervertől lekérni 1-2 queryt és utána egy 1 updatet, vagy 1 insertet kioszt. Ennek a layoutját összedobni kb 10 perc, de csak mert 8 perc cigiszünetet is közbeiktattam.

Utána a főnök már a laptopjáról szeretne kimutatásokat készíteni. Például hány órát dolgozott Kiss Jakab a Miskolci Pláza projekten. Vagy kik és mennyit dolgoztak a Miskolci Pláza projekten. Na itt már elgondolkodhatunk hogy legyen delphi/VS, vagy erre is megfelel-e a web. A web miért nem tökéletes? Mert 2-3 év után a 3000 projektből gyors választéklistát készíteni (pl: select) nem egyszerű (értsd: lassú). Lehet persze autocompletert használni. Vagy lehet előzetes szűrés, hogy ne hozza le a már archivált projekteket, eltávozott munkásokat. Ha ezt a kompromisszumot elfogadjuk, akkor cserébe a főnök laptopjára nem kell telepíteni semmit se. És akár egy netkávézóból a világ másik oldalán is belenézhet az adatokba / munkafolyamtokba.

Nyomtatás:
Már nem tudom mi volt az a 2 borzalmas gyári kiegészítő delphiben (d6-d7), amivel a nyomtatási képeket lehetett kreálni, de annál még egy notepaddal is hamarabb összerakok egy táblázatos layoutot HTML-ben.

És miből gondolod, hogy 10 év múlva lesz még silverlight programozó, szerintem már addigra a kx2z lesz a menő és aki nem abban programozik az már egy őskövület, aki nem képes tartani a lépést a technológiával:D. 10 év rengeteg idő főleg az informatikában.

Ép most jött ki a windows phone 7, amin éppenséggel kizárólag silverlight programokat lehet fejleszteni.
Arról nem is szólva, hogy ehhez 10 év múlva is hozzá lehet nyúlni, míg egy Delphi programhoz már nem biztos, mert addigra kihalnak a Delphisek.

Én nem látok sehol mobilplatform igényt.
mobil stick != mobil platform

A kérdező asztali PC és notebook kliensekben gondolkodik a leírása alapján.

A vastagkliens előnyeivel egyetértek, viszont a rövidke specifikáció alapján én max a "főnöki modulhoz" alkalmaznám, ott is csak, ha kacifántos reportok kellenek.

Az adatrögzítő részhez szerintem minél egyszerűbb megoldás és felület kell, mert:
1. előny a kis forgalom a stick-ek esetén
2. nem akarom lebecsülni az építőmunkásokat, brigádvezetőket, de nem hiszem, hogy elvarázsolja őket az informatika világa, szerintem jobban örülnek 2-3 mezőnek 1 ok gombbal
3. a "spec" alapján nem látom az igényt arra, hogy a felrögzítésen kívül egyéb műveleteket kelljen tudni egy alap kliensnek

A Siverligh-tal az baj, hogy odahegeszt az M$ platformhoz, ami nem is lenne baj, ha nem jött volna szóba a mobil platform. Ott pedig azért van több alternatíva, ami nem rajong az M$ dolgok;rt (symbian, android)

A linuxot általában azért szokták kizárni mert desktop céljaira nem igazán alkalmas. Lásd Pl. stabil API hiánya és bináris kompatibilitás című téma a PC fórumon.

A képernyő fizikai korlátai weben is ugyanúgy adottak mint delphiben. Ha olyan UI-t tervezel ami mind 320x200 px-en mind 1280x1024 px-en jó, az mindkét felületen gagyi lesz akár webes akár ablakos a felületed. Amúgy Delphiben (és általában desktopon) 1000x jobb layout kezelés van mint html-ben aminek az egyik leggyengébb pontja éppen ez. Arról nem is szólva, hogy vastag kliensen eleve lényegesen több lehetőséged van - nem véletlenül jöttek létre a különféle vastag klienshez hasonló dolgot létrehozni próbáló dolgok weben mint az ajax, flash, silverlight. Persze ez utóbbi már kb. el is éri a vastag kliens színvonalát, illeve ha nem is, de legalább valamennyire közelíti azt (a WPF-nek csak egy subsetje van benne, de ez is fényévekkel több mint amit html-lel + ajax-szal vagy bármi mással valaha csinálni fogsz).

A windowst azért ki lehetne zárni, mint ahogy a linuxot szokták...

Amúgy teljesen mindegy miben írják, ha egyszer a felhasználói felületet nem tervezik meg jól. Márpedig elég nehéz megtervezni úgy delphiben hogy mobilról is elérhető legyen, vagy épp PDA-ról. Máris 3 felületet kell megírni. Természetesen meg lehet oldani, de hogy hogyan fognak becsatlakozni 3G-vel és még szakmai/biztonsági szempontból se lehessen belekötni a központi adatbázishoz való hozzáférésbe? Például különböző webserviceokkal és a telefonokra/PDA-kra írt alkalmazásokkal. De mondjuk weben egy ilyen felület, ahol beírhatja az óráit megvan seperc alatt, addig mondjuk egy PDA-n valaki nagyon sokat dolgozik ezzel. Persze lehet hogy nem és valami teljesen egyszerű fejlesztőeszköz van delphiben is, amivel ezeket meg lehet valósítani. Nem tudom, nem csináltam még, csak gondolom. Cáfoljatok!

Ezt én is megértettem, pusztán finoman akartam célozni arra hogy a témaindítót is egy hasonló (igaz más területen) dilettáns indította.

Jó hogy már nem a Windows-t zárja ki emiatt vagy teszem azt a PC-t...

Itt nyilvánvalóan arról van szó, hogy valamilyen dilettánsok írtak Delphiben nekik egy programot, ami olyan, amilyen. Ebből ők messzemenő következtetéseket vontak le a fejlesztőeszközzel kapcsolatban...

Lehet Excel makróban, de Delphi kizárva?!

Most vagy Excelt nem láttál, vagy nem tudod hogy mi az a Delphi... Mi itt a helyzet?

Amúgy meg ha kapsz egy exe-t akkor honnan a fenéből tudod hogy miben fejlesztették?!

Már többen említették itt ezt, vagy ehhez hasonló dolgot.
Nekem tulajdonképp se pro se kontra, de annyit jegyeznék meg, hogy nálam a "privát szférában" a megrendelőnek van igaza.

Ha Ő fehér háttérre fehér betűt kér, ám legyen

Persze általában vannak javaslataim, de kérdőre vonni szerintem nem bölcs dolog.


Peace

Szerintem számít nekik, különben nem lennének kiváncsiak a várható árra sem:)

"A fentiek alapján várjuk a jelentkezőket várható ár és prognosztizált elkészülési idő megjelölésével."

És az nem számít Neketek hogy mennyiért vállalja el, vagy ingyért gondoltátok? :)

Csatlakozom, gondolom a kérést feltevő mérnökember így szemléletesen javaslom neki ne engedjen Hilti márkájú gépeket megvenni, mert tapasztalatom szerint nagyon alkalmatlan eszköz.
Nem tudtam vele jól kalapálni!

...
Erre csak annyi a reagálásom hogy a programozók nem tudtak programozni.
Amilyen problémákat ide leírtál arra tökéletesen alkalmas a Delphi Builder

Nekem az a tapasztalatom, hogy ami nincs benne egy ilyen sok multit partnerként tudó cég programjában, az nem is kell.
De mindenképp ki kellene próbálni, mielött legyártatnak egy ilyen progit. Már csak azért is hogy az esetleges felmerülő hiányosságok már a tervezés fázisában előkerüljenek.

Tapasztalatom szerint kis/közép vállalatoknál az efféle kész megoldásokkal az alábbi gondok szoktak lenni:

1. nincs magyar felület
2. nincs magyar dokumentáció, támogatás
3. mivel eddig "semmit" nem használtak, a kelleténél komplexebb kész megoldásoktól idegenkednek a dolgozók, és a hatékonyság sínyli meg
4. mindig van legalább egy, de inkább több olyan dolog, amit nem tud, vagy nem úgy tud, ahogy az ügyfélnek kellene