Itt a Chromeless, a Mozilla asztali alkalmazásplatformja
2011-05-02T10:51:43+02:00
2011-05-29T11:42:52+02:00
2022-07-24T15:01:20+02:00
  • Ez igaz hogy 5000 sor van benne de ez meg csak egy sima grid!!! azert tegyel bele barmilyen widgetet es mar picit nehezebb lesz ... :) bar itt a kliens gepetol fugg :) de az teny hogy a nagy adatmennyiseg ellenere is nagyon gyors meg mindig ... :) bar ne felejtsuk el hogy folyamatossan huzza be az adatokat... es hat egy lassab net elott vagy lassabb servernel... akar valami miatt megakad az adat kuldes akkor viszont sajnos :{.... bar oks otta peldaban proxy type memory de azert altalaban ez nem igy van... jajajajaj majdnem elfelejtettem :) nezd meg mondjuk egy complex-ebb extjs-es peldat ami mondjuk jopar widgetet rendellel a kepernyore es nezd meg ugyanezt chromeban ... eg es fold :) sot amit en nem ertek hogy oke hogy az adatfeladolgozas sebessege mas de az en konkret tapasztalatom hogy volt egy gridem 400 sor es mindegyik sorban van egy gomb ami feldob egy szinpalettat ... na most ffben feldolgozas utan is nagyon lassan tudtam csak a gridben lepkedni a chromeban semmi baj nem volt na ez a nem mind1 :)
    Mutasd a teljes hozzászólást!
  • A JIT szvsz a típuskezelés hiányosságait nem igazán tudja kiküszöbölni. Ha te meghívsz egy függvényt amiben van egy Pistike nevű paraméter, akkor JIT ide vagy oda neki futás közben kell figyelnie hogy Pistike szám-e vagy szöveg, vagy dátum, mivel te hívhatod a függvényedet 20 helyről, különböző paraméterekkel. Azaz ha a függvényed mondjuk annyit csinál hogy visszatér Pistike+1-gyel, akkor szigorú típusosság esetén a JIT lefordít neked ebből egy inc utasítást. Ezzel szemben dinamikus típuskezelésnél futásidőben kell megnézni hogy mi van a változóban, és ha int akkor inc utasítás, ha string akkor hozzáfűzés, stb. Persze lehet(ne) olyat csinálni hogy a függvény minden hívását megnézzük, és annak megfelelően int-es vagy stringes verziót hívunk meg a függvényből hogy milyen az átadott paraméter - de kétlem hogy ezt egy komplex program esetén véges sok erőforrással meg lehet oldani. Ehhez képest sokkal egyszerűbb megoldás ha megmondjuk hogy a változó típusa integer.
    Mutasd a teljes hozzászólást!
  • Hogy érted, hogy generálódni fog a felület?
    Valamilyen dizájner által generált kódra gondolsz?


    Az üzleti objektumok tartalmazzák eleve a UI vázat is egy egységes leírónyelven egy valamire való enterprise rendszerben. Alapból meg van határozva milyen mezőnek milyen a controlja és az hogyan jelenjen meg a felületen. Ebből aztán a megfelelő template segítségével lehet generálni xaml-t, html-t, lua-t, vagy, amit akarsz. Teljesen huszadrangú kérdés innen már a felület, ami a kliensen megjelenik. Persze egy AutoForm nem lesz hiper design csoda, de a célnak megfelel. Később esetleg lehet rajta változtatni, ha szüksléges designerrel, ahogy te is írtad, vagy egyszerűen megadni bizonyos szabályokat még az üzleti objektum UI leírójában.

    Mehet tovább a flame mindenféle szemponok alapján, de értelmetlen, mert egy komolyabb rendszer alapból platformfüggetlen kimenetet fog adni, amiből aztán hottentotta nyelvű UI-t is lehet generálni, ha épp az kell.
    Mutasd a teljes hozzászólást!
  • Igen a html5 elmegy a desktop iranyban meg a specben is lesz desktop kommunikacio .. regebben meg a googli slides -ban is volt pelda csak most kivettek... szerintem jo otlet bar en arra leszek kivancsi hogy mikor lehet eldobni a bongeszo keretet :)) egy kis GWT es mar keszen is van :)
    Mutasd a teljes hozzászólást!
  • jó a flame :P

    zzel együtt szvsz a javascript mindig is lassabb lesz a statikusan típusos, előfordított, JIT-es nyelvekhez képest.


    modern böngészőkben a javascript is JIT-es. Szerintem felhasználói felületek programozásához bőven elégséges a sebessége, ezzel nincs gond. Az más kérdés, hogy a nyelv nagyon dinamikus, típustalan, ezért aztán egyrészt könnyű benne hibát véteni, másrészt nehéz (lehetetlen) hozzá olyan fejlesztői környezetet írni, ami megközelítené a Java/C# nyelvekhez megszokottakat.

    a többibe most nem mennék bele
    Mutasd a teljes hozzászólást!
  • 1. A Chromeless szvsz inkább a Mozilla fejlesztőinek poénja lehetett - míg a gugli általában igyekszik a felhasználót odaszögezni a on-line szolgáltatóhoz és minél inkább próbálja megszüntetni a hagyományos oprendszert, addig ez pont az ellenkező irányba tett lépés.

    2. Ezzel együtt szvsz a javascript mindig is lassabb lesz a statikusan típusos, előfordított, JIT-es nyelvekhez képest. De az ExtJS-es grid valóban biztatónak tűnik, az új HTML5 API-kal együtt ezzel már akár ütőképes webes megoldást is lehet tervezni.

    4. Ugyanez igaz a PHP-re is. Nem mondom hogy PHP-ben nem lehet jó programot csinálni. A dinamikus típuskezelés nem zárja ezt ki - ahogy sok-sok Clipper program van, ami még a mai napig is elfut. Anno én is írtam sok-sok ilyet. Ezzel együtt a statikus típuskezelés sok-sok hibát megfog, ami jócskán lecsökkenti a hibázás esélyét. Szvsz ritka az a projekt aminek minden sora le van fedve unit tesztekkel, a statikus típuskezelés viszont mindent lefed. Persze ez utóbbi sem csodaszer, ott is lehet hülyeségeket csinálni, csak én azt tartom hogy minden olyan hiba ami nem a felhasználónál jön elő, ajándék. És ha csak a hibák 1%-át fogja meg a statikus hibakezelés már azért megéri.

    5. Valószínűleg igazad van, kérdés az hogy mi okoz nagyobb kiesést, a lockolás vagy a keveredés.
    Mutasd a teljes hozzászólást!
  • Üdv minden régi ismerős névnek újra :) (Sting, Ivn, LC - hali)

    Ebből a topikból mekkora flame lett, amám :D öröm volt olvasni :)

    Pár dolgot szeretnék csak tisztázni a fele OFF lesz, bár ez flame-nél azt hiszem úgysem számít :D

    1. A Chromeless-nek ZÉRÓ köze van a Google Chrome-hoz, utóbbi egy böngésző, előbbi pedig a Firefox felhasználói felületének neve (...volt már azelőtt is, hogy a Google kitalálta volna a sajátját). A GC Webkit alapú, a Firefox meg nem. Tekintsünk most el a böngészőmotorok kronológiai ősrobbanásától nagyvonalúan és akkor mondhatom, hogy a kettő ég és föld :) (ma már úgysem tudni, miket lopkodtak össze egymástól az egyes motorok a kezdeti időkben)

    2. Az ExtJS szívügyem, a 2.0-ás verzió óta használom, a 3.x-ekhez még komponenseket és bugfixeket is toltam. A 4.0 előtti gridjük trágyadomb volt, kétségtelen. A 4.0 új gridje viszont repeszt mint a disznó és elvi szinten (elvileg gyakorlati szinten is :D) mindegy neki, hogy 10, 100, 1000, 10000, 1000000000 sor van benne. Bersze, az adatbetöltést a több sor lassítja (JSON over HTTP, az mire eljut a feldolgozásik, hagyjuk hogy min megy keresztül...), de az igazi szűk keresztmetszetet a DOM manipulálásának sebessége adta (és adja minden böngészőben a mai napig). A jelenlegi (4-es ExtJS) gridje viszont nem generálja le a teljes gridet, hanem csak a viewportot. Ha változik a viewport, az a megjelenített 10-20 rekord kerül renderelésre csak, ami a viewport-ban látszik. A HTML 5 offline API-jaival egyébként az adatcsere is "gyorsítható", persze erre a tervezéskor kell megoldást találni (ha egyáltalán lehet).

    3. A Chromless lényege: jelenleg is léteznek webalkalmazások. Ezek erőssége, hogy központi szerveren futnak, nem igényelnek telepítést, központilag teljesen felügyelhetőek, biztonságosan backup-olhatóak, stb. Azonban a jelenlegi webalkalmazások legnagyobb defektje, hogy nem igazán tudnak kilépni a böngésző adta keretekből, elérve például a háttértárolót, a desktop-ot, a host OS egyéb specifikus részeit. A Chromeless - többek közt - ezt hivatott áthidalni amellett, hogy már a HTML 5 is komoly előrelépéseket tett ezirányban (File API, DB API, stb buzzword-ök, "Google a te barátod" ha részletesen érdekel).

    4. Az egy városi legenda, hogy PHP-ben nem lehet komoly alkalmazásokat összerakni. Ha a most legelterjedtebb 5.2-es verziót veszem elő (amiben sajnos a late static binding még mindig nem ismert, az már ugye 5.3), ott is számos OO lehetőség adott. Én nem állítom, hogy a PHP egy komoly nyelv, sőt, sokszor kimondottan trágya, de azt hiszem a szakmában töltött cirka 16 év alatt sikerült megtanulnom, hogy komolytalan programozási nyelv nincs, csak komolytalan programozó. Korrekt, átlátható, szervezett kódokat lehet PHP-ben is összerakni. Ehhez lehet használni bevált és ismert design pattern-eket, keretrendszereket, library-ket, PHP kiterjesztéseket, unit testinget, debuggert vagy 5 félét, adatbázis vagy egy tucat fajtát (a PDO, de még inkább a megfelelő ORM használatával közel teljesen egységesen), stb. A tervező végezzen jó munkát, a végeredmény nem lesz gány.

    5. SVN nagyobb fejlesztéseknél, ahol ugyanazt a fájlt azonos helyen módosítják többen, bezony sajnos összeakadhat, és bezony sajnos volt rá precedens, hogy a legnagyobb elővigyázatosság ellenére a "szűz" kolléga pont oda piszkált, ahova nem kellett volna neki, és bezony elment jó 1 óra és 1000 agysejt a kezi összefésüléssel. Tény: ritka, mint a fehérholló, különösen ha a kód jól szervezett, de sajnos ilyen is előfordul. A lock használata SVN alatt is ajánlott, ha van rá bármekkora sansz, hogy azonos fájlon azonos időben egynél több ember dolgozhat.

    És még egyszer: köszönöm a nosztalgikus pillanatokat, egy élmény volt :) remélem érdemben sikerült hozzászólnom a vitához.
    Mutasd a teljes hozzászólást!
  • Visszatérve a topikhoz, a prog.hu-n éppen ezeket a híreket olvasom a legszívesebben, amelyek új fejlesztőrendszerekkel foglalkoznak. Néha még le is szoktam tölteni őket, ha van időm és kipróbálom.
    Nem baj, ha nem áll mögötte olyan nagy csapat, mint a M$. Attól még lehet jó.
    Mutasd a teljes hozzászólást!
  • Kipróbáltam poénból azt a dolgot, amit LC hozott fel (partnerek grid), és az én ultragány megoldásom (amit most dobtam össze) is elbír ezer sort. A lentebb említett buffered grid-del szerintem megoldható a feladat.
    Mutasd a teljes hozzászólást!


  • Körülbelül 3 éve használom az SVN-t a saját projektemhez, és egy másikhoz is amin anno ketten dolgoztunk. Soha fel sem merült a lock használata, mivel egyszerűen nem volt szükség rá. A merge simán megbirkózott a feladattal, akkor is ha nagyritkán ketten piszkáltuk ugyanazt a fájlt, vagy ha én elfelejtettem commitolni. Persze lehetett volna olyan eset ahol jó eséllyel nem - de szvsz átlagos felhasználás mellett ez elvétve jöhet szembe, és az hogy esetleg egy hibás merge miatt minden 1000. esetben esetleg kézzel kell bűvölni egy függvényt nem áll arányban azzal hogy lockolgatni kell. Legalábbis szvsz.
    Mutasd a teljes hozzászólást!
  • SVN-el nem igazán divat lockolni szerintem sem. Legalábbis ahol én dolgoztam eddig, ott nem lockoltak sehol. Eleinte szokatlan volt, mert picit már hozzászoktam régebbi verziókövetőkhöz, ahol a lockolás volt a szokás, de aztán hozzászoktam a nem lockolós munkamódszerhez, sőt talán meg is szerettem a merge-on-pull filozófiát. Persze valamiféle józan projectmanagement kell a dologhoz és/vagy gyakori kommitálás, hogy ne szálljanak el a verziók egymástól, viszont előnye, hogy elég gördülékeny a csapatmunka így.
    Mutasd a teljes hozzászólást!
  • Igen, mi is próbáltuk. Aztán sokszor előfordult, hogy 2-en is egyszerre ugyanahhoz nyúltak, és a merge nem birkózott meg vele, és lehetett kézzel javítani. Ennek elkerülése érdekében 1 forrással 1 ember dolgozik.
    Mutasd a teljes hozzászólást!
  • OFF

    Elvileg SVN-ben csak azokat a fájlokat kell lockolni, amik nem diffelhetők/merge-ölhetők (pl. képek, diagramok). A többi fájlt is lehet, de én is úgy tudtam, hogy nem szokás. (Így is használtuk 5-6 emberes projektben; nem lockoltunk, hanem commit előtt merge-öltük a legfrissebb változtatásokat a saját kódunkba.)

    Gondolom az, hogy ki hogyan használja, függ a szokásoktól illetve a vállalati policy-től.
    Mutasd a teljes hozzászólást!
  • Az igazság az, hogy én egyszemélyes projektnél használom, már évek óta.


    Akkor miről beszélünk? Megint olyanhoz szóltál hozzá, amihez nem értesz?

    Ha nem tudjuk biztosan, ne mondjuk! A hibás, de hitelesnek hangzó válasz rosszabb a semminél. Ne küldjük az embereket az erdőbe, csak hogy szakértőnek látsszunk! Legyünk szerények és őszinték; járjunk elöl jó példával a kérdező és a többiek előtt!


    Mutasd a teljes hozzászólást!
  • Lockolni mikor szoktál?


    Hát, mielőtt nekiállnék mokolni benne?
    Mutasd a teljes hozzászólást!
  • Lockolni mikor szoktál?
    Én a source safes korszak utántól egyszer sem lockoltam :)
    (mindig csapatban dolgozom)
    Mutasd a teljes hozzászólást!
  • A 30000 sor berántása úgy megy, hogy lokálisan, tömörítve, esetleg titkosítva lerakod az adatokat, és indításkor, illetve frissítéskor csak a változásokat húzod át. Ez csak akkor gond, ha olyanok a táblák amibe folyamatosan sok változás megy át, ez esetben tényleg probléma lehet a dolog, ugyanakkor ha olyan táblákról van szó ahol csak néhány száz sor mozdul naponta, ugyanakkor egész nap ezt a progit nyüstöli a user, akkor jelentős hálózati forgalmat takaríthatsz meg vele.
    Mutasd a teljes hozzászólást!
  • Én eddig észre sem vettem hogy van lock is, de tényleg van. Az igazság az, hogy én egyszemélyes projektnél használom, már évek óta. És jó néhányszor volt már olyan hogy egy forrást módosítottam de elfelejtettem commitot nyomni rá, közben egy másik helyen is módosítottam ugyanazt a forrásfájlt, de a rendszernek semmi gondot nem okozott, simán végigvitte mindkét módosítást. Persze, ha ugyanazt a függvényt módosítottam volna akkor valószínűleg nem lett volna ennyire szép a helyzet.
    Mutasd a teljes hozzászólást!
  • "felesleges 30.000 rekordot belerakni egy rácsba"


    Annál is inkább, mert olyan technologiát kell használni, ami 100 sorral ugyanolyan hatékony, mint 1.000.000-val.
    Én legalábbis ilyesmi 'nagy igazságokat' szoktam mondani a tanítványaimnak.

    A 30.000 sor berántása már csak azért is gond, mert egyszercsak szembejön egy meló, ahol lassú bérelt vonalon kell egy távoli adatbázisból dolgozni...
    Mutasd a teljes hozzászólást!
  • Ha nem ismered, miért nyilatkozol róla?
    Mutasd a teljes hozzászólást!
    Csatolt állomány
  • csv-ben még lockoltál, svn-ben már nem.
    Mutasd a teljes hozzászólást!
  • Még nem láttál oldstyle usereket? :D
    Sokuknak még az is katasztrófa, hogy ha nem történik ugyanarra a 3 gomblenyomásra ugyanaz, mint szokott, és hívja az it-t.
    Szerencsére egyre kevesebb van ilyen, de azért előfordul.
    Mutasd a teljes hozzászólást!
  • Meg akarják nézni, hogy egy termék/vevő szerepel-e többször kicsit más elnevezéssel.

    30.000 sorban, rásegítő szűrés nélkül? Max Kínában :)
    Mutasd a teljes hozzászólást!
  • A verziókezelést általában csv vagy svn vagy más verziókezelő szoftverrel végezzük. Annak meg nagyjából mindegy mekkora a forrásfájl.


    Nem az a lényeg, hogy mekkora a forrásfájl, hanem hogyha egyben van minden, és én azt lelockolom szerkesztésre, akkor a többi fejlesztő várhat rám. Vagy esetleg steal-elhet. Aztán lehet bízni a merge-ben, vagy nem.

    Ezzel szemben én kb. 20 éve fejlesztek ilyen szoftvereket, és elég sok userrel találkoztam már.


    Nekünk most is sok userünk van, de egyik részéről sem volt olyan igény, hogy most azonnal de izibe rakjunk ki minden adatot neki a képernyőre. Sőt! Minden userünk azt preferálja, hogy előszűrés legyen mindenképpen. Ahol meg nincs előszűrés, ott meg használhatják az adhoc lekérdezést, ahol ő állítja össze, hogy mi kell neki, és milyen szűrések legyenek.

    És ez gyorsan megvalósítható az általad szutyoknak kikiáltott JS/HTML párossal is. Onnan tudom, hogy van egypár webes rendszerünk is, és a userek meg vannak elégedve vele.
    Mutasd a teljes hozzászólást!
  • A verziókezelést általában csv vagy svn vagy más verziókezelő szoftverrel végezzük. Annak meg nagyjából mindegy mekkora a forrásfájl. [...]

    Köszönjük, hogy megint megállapítottál egy csomó nyilvánvaló dolgot. Ugyanakkor kár, hogy mindeközben nem vagy tisztában számos, csapatmunkában ill. komolyabb projekteken is dolgozók számára hasonlóan kézenfekvő más dologgal, megfontolással.

    Mint pl. azzal, hogy nagyon nem mindegy, hogy egy forrásfájlon hányan dolgoznak egyszerre, mert ha sikerül többeknek is úgy módosítaniuk azt, hogy a verziókövető ne tudja azokat automatikusan összefűzni (pl. mert eleve bináris a formátum, vagy mert elég átfogóak a változtatások ahhoz, hogy ne tudjon megbízhatóan azonos szövegblokkokat találni benne a verziókezelő), akkor jó nagy szívás veszi kezdetét, és állhat neki kézzel összefésülni a változtatásokat az ember. Például ezért is szokás az értelmesen lehető legkisebb egységekre széttdobni a forrásfájlokat is (ti. mert ezzel csökkented annak az esélyét, hogy két ember ugyanazon a fájlon fog módosításokat végrehajtani).

    No meg azért is, mert így sokkal jobban követhető biztonsági és audit szempontból is, hiszen már pusztán a módosított fájlok listája alapján is nyilvánvaló, hogy ki mihez nyúlt hozzá ill. mi változott két verzió között. Ami regresszív hibák keresése során megint nem mindegy. (A komplett diff ilyen esetekben legtöbbször használhatatlan és szuboptimális, mert nem helyi összefüggéseiben mutatja meg a változtatásokat, és mert egybeömlesztve mutat mindent, amivel pont ellene dolgozik annak az elvnek, aminek mentén szét lettek dobva minél kisebb egységekbe a fájlok.)

    De ugye ennek semmi köze a topik alaptémájához - csak megint bele akartál kapaszkodni és okoskodni valami teljesen mellékes megjegyzésbe, miután a főszálat már teljesen elbuktad, mert mindenki közölte veled, hogy nemes egyszerűséggel hülyeség többtízezer vagy még több rekordot egy gridben a felhasználó orra elé tolni. A szép ugye, hogy még a mellékszálba okoskodás sem jött össze, és csak azt sikerült bebizonyítani, hogy lövésed sincs róla, miért igazán fontos minél kisebb egységekre bontani a forráskódot ha nem magányos programozó vagy és nem Hello World szintű alkalmazásokat hegesztesz.

    Ezzel szemben én kb. 20 éve fejlesztek ilyen szoftvereket, és elég sok userrel találkoztam már.

    Nem az lett elvitatva, hogy találkoztál -e már júzerekkel, hanem az, hogy praktikus lenne többtízezer rekord egy gridben a képükbe hányása, és ne léteznének -e jobb, modernebb, effektívebb módjai az információk prezentálásának és kereshetővé tételének.

    Egyébként meg ezt a "ki hány éve fejleszt" dolgot, mint érvet hagyagoljuk, nem csak azért, mert nem érv semmilyen objektív szakmai megfontolás mellett vagy ellen, de azért is, mert nyilvánvalóan még kettőnk közül sem te vagy a nagyobb és átfogóbb szakmai múlttal rendelkező.

    Miért, 20 éve még nem ismerték az input boxot ? Mi olyan dolog változott meg az elmúlt 20 évben hogy ma már lehet teszem azt a megnevezés első 3 karakterére szűrni, míg anno Clipperben nem lehetett ?

    Például az változott meg, hogy ma már van grafikus felület és van egér, amik az információk egy sokkal sokrétűbb prezentálását, és a vezérlés egy sokkal finomabb módját teszik lehetővé, amelyek mellett értelmetlenné, ineffektívvé válik sok olyan beviteli és megjelenítési paradigma, ami karakteres képernyőn és csak billentyűzetes terminálon még valóban optimális és célszerű volt.

    Meg az is megváltozott, hogy ma már nem helyileg tároljuk az adatbázisainkat egy-egy gépen, hanem minden hálózaton van, amit sokszor nem csak a telephelyen belül, de akár kontinensek között is megosztunk. És amelyeket így nem csak, hogy értelmetlen nyersen, célzatlanul böngészni, de sávszélesség és egyéb okoknál fogva nem is lehetséges gazdaságosan.

    Az is megváltozott, hogy ma már automatizálunk mindent amit lehet, vonalkódokkal, a rendszereink összekötésével, integrálásával, így a legritkább esetben van pl. arra szükség, hogy egy cikket vagy partnert kézzel keressünk ki a húszezres cikkbázisból (hanem lehúzzuk a vonalkódját, törzskártyáját, és a rendszer automatikusan feldobja, vagy nagyobb partnere eleve valami importfájlon, urambocsá' SOAP-on küldi be a megrendelését - esetleg elmegy a webshopunkba és ott ő maga adja fel "kézzel" -, és mi legfeljebb csak jóváhagyjuk, továbbítjuk, stb. annak részleteit, de sosem kutakodunk sem a partner-adatbázisban, sem a cikktörzsben közvetlenül, böngészgetve a millió rekord között).

    Stb. stb. stb.

    Biztos hogy bennem van a hiba, de nagyjából ugyanazokat a szűrési lehetőségeket amiket ma meg tudsz tenni egy webes felületen, én 20 évvel ezelőtt Clipperben szintén meg tudtam csinálni.

    Nem, nem tudtad megcsinálni, mert pusztán az, hogy weben keresztül érsz el valamit olyan távlatokat és lehetőséget nyit meg pluszban, amiket Clipperrel sosem tudtál volna megcsinálni. Pl. azt, hogy veled párhuzamosan a világ másik feléről is megnyithatja valaki ugyanazt a (web)alkalmazást és veled együtt és/vagy veled párhuzamosan dolgozhat ugyanazon az adatbázison. Vagy hogy a világ másik felén lévő üzemeltetőnek nem kell elküldenie neked a frissítéseket, hanem csak felrakja a szerverére az új verziót, és a következő kattintáskor - minden telepítés nélkül - te már annak újdonságait is eléred. Vagy hogy ugyanazt a (web)alkalmazást az asztali gépedről, a mobiltelefonodról és a tabletedről is el tudod érni és ugyanúgy tudod használni, akkor is ha ezen eszközök tök más gyártóktól származnak és tök más rendszereket futtatnak, és egyikük sem hallottam sosem azokról a technológiákról, amiket te a (web)alkalmazásod építése során felhasználtál szerveroldalon.

    Csak ezeket a megfontolásokat, előnyöket és szükségszerűségeket illetve ma már elvárásokat te gálánsan ignorálod amikor összehasonlítod a két dolgot, és azt mondod, hogy de hát "input doboz már a Clipperben is volt". Igen, input doboz már abban is volt - csak éppen millió másik, manapság minden (web)alkalmazás által használt és kihasznált technológiai újítás meg nem volt benne, sőt, bele se lehetett hekkelni.

    Amit csinálsz a Clipper és egy modern webes platform összevetése kapcsán az kb. csak annyira komolytalan, mint ha egy biciklit és egy űrrepülőt összehasonlítva kijelentenéd, hogy utóbbi mekkora technológiai visszalépés, mert milliószor annyiba kerül és milliószor annyi energiát fogyaszt, mint egy bicikli. Amiből persze utóbbi igaz - csak éppen cserébe csillió olyan dolgot is meg lehet csinálni vele, amire nem csak egy biciklivel, de még millióval együtt sem lennél képes.
    Mutasd a teljes hozzászólást!
  • Ugyanis ekkora - ti. több tízezer vagy millió soros - forrásfájlokkal sem dolgozunk, sőt, minél nagyobb egy projekt és ezzel összefüggésben minél többen dolgoznak rajta, annál fontosabb az, hogy lehetőleg minél kisebb részekre daraboljuk szét a forráskód szintjén is, már csak verziókezelési szempontok miatt is.

    A verziókezelést általában csv vagy svn vagy más verziókezelő szoftverrel végezzük. Annak meg nagyjából mindegy mekkora a forrásfájl. Az áttekinthetőség miatt jó ha egy objektum egy forrásban van (kivéve amikor valamelyik részét kódgenerátor állítja elő, erre jó C# alatt a partial class). Az meg hogy egy objektum mérete korlátozott igazából a tervezés miatt van és nem a forráskód mérete miatt. Ha csak nem PHP programozó vagy, aki sok kis php kódocskát ír minden form kezeléséhez az oop meg hasonló marhaságok teljes mellőzésével, akkor a forráskód méretét igazából a tervezés befolyásolja.

    A baj, hogy idáig pl. a topikban egy júzertől sem hallottuk, hogy ő kolbászolni akarna millió rekord között.

    Ennek azért az is oka lehet, hogy ide viszonylag kevés user jár.
    Ezzel szemben én kb. 20 éve fejlesztek ilyen szoftvereket, és elég sok userrel találkoztam már.

    akkor kényszerből megszületett, de azóta régen elavult

    Miért, 20 éve még nem ismerték az input boxot ? Mi olyan dolog változott meg az elmúlt 20 évben hogy ma már lehet teszem azt a megnevezés első 3 karakterére szűrni, míg anno Clipperben nem lehetett ? Biztos hogy bennem van a hiba, de nagyjából ugyanazokat a szűrési lehetőségeket amiket ma meg tudsz tenni egy webes felületen, én 20 évvel ezelőtt Clipperben szintén meg tudtam csinálni. Amúgy azért más is, mert az efféle szűrő input boxok illetve dialógus ablakok már az első Clipperes/Turbo Pascal-os progikban is ugyanúgy ott voltak.
    Mutasd a teljes hozzászólást!
  • Megoldható ez is szűréssel, csak körülményes:
    Meg akarják nézni, hogy egy termék/vevő szerepel-e többször kicsit más elnevezéssel.
    Mutasd a teljes hozzászólást!
  • Ha az user kolbászolni akar egy ekkora táblában, akkor ott valami nagyon el lett rontva a felülettervezéskor. Mert ez azt jelenti, hogy nincsen neki valamelyik feladathoz megfelelő eszköz biztosítva.

    Sokat gondolkodtam, hogy milyen munkafolyamat lehet az, amikor tényleg szükség van arra, hogy többtízezer rekordot egyben mutassunk. Ugye konkrét keresés kizárva (erre vannak a keresőmezők). Egyfajta áttekintést tudok elképzelni, hogy pl egy számlalistában pirossal ki vannak emelve a kifizetetlen számlák, és átgörgetve talán látszik, hogy arányaiban mennyi a piros. Persze az más kérdés, hogy ekkora tételben már ez igencsak pontatlan adat lenne. Erre sokkal alkalmasabb lenne pl egy diagram.

    A tévedés jogát fenntartom, tehát ha valaki tud egy olyan munkafolyamatot, ahol egyben kell látni nagy adatmennyiséget, szűrés nélkül, amit nem lehet hatékony eszközökkel kiváltani (a "kolbászolás" nem munkafolyamat), arra (irónia nélkül) kíváncsi vagyok.
    Mutasd a teljes hozzászólást!
  • Az email megjelenése meg ötezer évvel visszavetette a levélírásban elért fejlődést.


    Ebben van valami!
    Mutasd a teljes hozzászólást!
  • Ugyanezt el lehet mondani a forráskód szerkesztőkről is. Ki tud egyszerre átlátni 500 sort ami egy átlag C# forrásfájlban van ? És mégsem csinálja egyik fejlesztőkörnyezet sem a Visual Basic kivételével hogy egyszerre csak egy függvényt szerkeszthetsz.

    Köszönjük a tökéletes példát arra, hogy miért nincs értelme többtízezer vagy millió rekordot böngészhetővé tenni (amit te annyira királynak tartasz és amit mellesleg egy Chromeless alkalmazásban is simán és kiváló sebességgel lehet biztosítani). Ugyanis ekkora - ti. több tízezer vagy millió soros - forrásfájlokkal sem dolgozunk, sőt, minél nagyobb egy projekt és ezzel összefüggésben minél többen dolgoznak rajta, annál fontosabb az, hogy lehetőleg minél kisebb részekre daraboljuk szét a forráskód szintjén is, már csak verziókezelési szempontok miatt is.

    Ha a user kolbászolni akar, nekünk az a dolgunk hogy ezt lehetővé tegyük.

    A baj, hogy idáig pl. a topikban egy júzertől sem hallottuk, hogy ő kolbászolni akarna millió rekord között. Csakis tőled, mint a harminc évvel ezelőtti - akkor kényszerből megszületett, de azóta régen elavult - paradigmákhoz ragaszkodni, azokon túllépni képtelen fejlesztőtől olvassuk folyamatosan, hogy így kellene működnie minden alkalmazásnak - miközben 99.99%-uk ma már nem így működik, akkor sem, ha valaha korábbi változatai esetleg igen. Aminek nyilván oka van, és ez nem az, hogy mindenki elhülyült a világon, és csak te maradtál okos.

    Az hogy a web 15 évvel visszavetette a fejlődést a desktop programozásban talán nem az userrel kell megfizettetni.

    A web 15 évvel visszavetette a fejlődést a desktop programozásban. Persze. A robogók megjelenése pedig kétszáz évvel visszavetette az autók terén elért fejlődést. Az email megjelenése meg ötezer évvel visszavetette a levélírásban elért fejlődést.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd