A web "fejlődése"
2010-09-30T14:55:34+02:00
2010-10-04T17:23:30+02:00
2022-06-29T09:36:34+02:00
  • Ami a legofntosabb tévedésed: Az absolute nem az ablak széléhez van kötve!!! Hanem ahhoz a legközelebbi befoglaló őséhez, amelyik nem static!




    Csak azt tudnám, hogy ahol ezeket én néztem miért nem így volt ez leírva!

    Ez így már tényleg használható, ha kissé nyakatekert is. Köszönöm!
    Mutasd a teljes hozzászólást!
  • Amúgy aki mostanában kezd webes fejlesztéssel fogalkozni, érdemes először ezen a google tutorialon átrágnia magát. Ez elég jól összefoglalja a modern html/css/javascript alapjait:

    http://code.google.com/edu/submissions/html-css-javascript/

    (Mondjuk teljesen kezdőknek nagyon tömény, de akik már láttak html-t, vagy le akarják porolni a rég elfelejtett tudásukat, azoknak jó, mert nem hosszú, és azért az alapokat tartalmazza.)
    Mutasd a teljes hozzászólást!
  • Na most, van ugye a fixed és az absolute position, de ez az ablak széléhez van kötve, ami kizárja a fenti megoldást. Van aztán a relative ami a világ legnagyobb marhasága, mert az előtte lévő elemhez pozicionál - ami azt jelenti, hogy ha azt megváltoztatod, akkor szétesik az egész. És van a default static, ami a flow layout- ami a legtöbb esetben finoman szólva nem igazán használható.


    Na, ezért ezt tisztázzuk le egy kicsit, néhány dolgot félreértesz. Tényleg hihetetlenül elkbonyolították ezt, de ha egyszer megérti az ember, hogy hogy működik, túl teheti ezen magát, és nem ez lesz a szűk keresztmetszet.

    Na szóval a 'fixed'-el most ne törődjünk, az most nem érdekes, de egyébként néha nagyon hasznos.

    A relative ritkán használható, tehát rámondhatjuk, hogy marhaság, de nem az előzőhöz relatív, és néa tényleg nagyon jól használható. Van egy olyan fogalom a css pozícionálásban, hogy 'flow'. Egy elem vagy benne van a flow-ban, vagy nincs. Ha valami benne van a flow-ban, az befolyásolja a következő a flow-ban lévő elem helyzetét. A relative azt jelenti, hogy az elemet úgy rendereli, mintha normál módon lenne a flow-ban, a következő elem ehhez a hipotetikus pozícióhoz képest rajzolódik ki, de mégis a valóságban kissé arréb rajzoljuk ki. Ez gyakorlatilag arra jó, hogy valami 'kiugrik a helyéről.', és tényleg pl. javascriptben ki is ugraszhatod így a flowbeli helyéről, anélkül, hogy a többi elem helyzetét bántaná.

    Ami a legofntosabb tévedésed: Az absolute nem az ablak széléhez van kötve!!! Hanem ahhoz a legközelebbi befoglaló őséhez, amelyik nem static! Az tényleg marhaság, hogy miért van az, hogy az ősnek nem szabad staticnak lennie, én sem értem, hogy miért van ez. De nagyon egyszerűen workaroundolható: ha static-ba akarod foglalni, foglald olyan relative-be, amit nem ugrasztasz ki egy pixellel sem, és kész is vagy. Azt olvastam, hogy ez ismert technika webdesigner körökben.

    Szvsz. ez elsőre fusztrálóan bonyolultnak hangzik, de igazából ha az egy két hülyeséget megtanulja az ember, akkor nincs vele sok munka. A css nem pozícionálással kapcsolatos részei pedig kifejezetten fejlettek.

    Amúgy mondom, ha nem akasz sokat foglalkozni a pozícionálással, használj egy grid framewoörköt, ezek tényleg egyszerűek, és gyorsan lehet bennük dolgozni: pl. 960 Grid System

    Komolyabb webes alkalmazásnál az UI le van választva a designtól. Még PHP-ben is (template motorok). Azt amikor a progi közvetlenül írogatja a lapot print-ekkel gányolásnak hívjuk.

    Mindenképpen szerencsés a view-t leválasztani az action-októl és a service rétegtől. De hogy a view printekkel van-e megoldva, annak azért olyan húde nagy jelentősége nincsen. Ha nagyon durván dinamikus egy oldal, akkor már szerencsésebb is rendes programneylven írni a view-t, mert a template nyelvbe túl sok feltételt és ciklust tenni nem szép. Főleg azért nincs ma már akkora jelentősgée annak, hogy mindenáron template nyelven írjuk a view-t, mert a html ami generálódik az nagony egyszerű, az még nem a prezentáció, hanem egy bare-bone struktúra. Nem az a bonyulult már stilizált html ami a css megjelenése előtti időszakban volt. Ezt bare-bone html-t a css tupírozza fel stílussal. A css az teljesen le van választva még a html-ről is. A css a prezentáció, a html csak a struktúra.
    Mutasd a teljes hozzászólást!
  • Én az Expressiont ismerem, illetve a visual studio form editorát, illetve pár openszorszos cuccot. Persze, odáig rendben van a dolog, hogy szépen X,Y pozícióba tudod húzogatni a form textboxait és a többi elemet. De próbáld meg azt a szokásos felállást megcsinálni ami a legtöbb helyre kell, hogy van egy fix, mondjuk 1024 pixel széles középső oszlopod, és van két oldal ami olyan széles hogy a 1024 px széles rész pont középen legyen,

    Olyasmire gondolok mint Pl. az osnews.com. Középen van a cucc, két oldalt pedig a keret, amin belül ugyanúgy pixelre kellene elhelyezni a tartalmat mint egy visualbasic-es formon.

    Na most, van ugye a fixed és az absolute position, de ez az ablak széléhez van kötve, ami kizárja a fenti megoldást. Van aztán a relative ami a világ legnagyobb marhasága, mert az előtte lévő elemhez pozicionál - ami azt jelenti, hogy ha azt megváltoztatod, akkor szétesik az egész. És van a default static, ami a flow layout- ami a legtöbb esetben finoman szólva nem igazán használható.

    Egyetlen "apróbb" lehetőség maradt ki a dologból: egy olyan pozicionálási lehetőség, ami a befoglaló div-hez képest relatív.
    Ettől azonnal használható lenne a dolog. Amit amúgy minden általam ismert ablakozó rendszer tud a Visual Basic-tól a WPF-ig.

    Olyan is volt az eredmény mind kinézetben mind használhatóságban. Egy 'kicsit' fejlődtünk azóta ha a userek kényelméről és szépérzékének kielégítéséről van szó.

    Nagyon kevés az olyan weblap ami akár look akár feel szintjén megközelíti a jól megírt visual basic 3-mas programot. És ami van, azt vagy flash-ben, vagy silverlightban van elkövetve.
    Nem véletlenül próbál mindenki mindenféle vastagkliensesnek látszó megoldást ráhúzni a jó öreg html-re, az ajaxtól a silverlightig. Az most már más kérdés, hogy anno a visual basices programodon nem dolgozott 30 grafikus hogy mindenféle csicsás hátteret és egyebet csináljon neki.

    Komolyabb alkalmazásnál a tartalom (HTML) úgyis dinaikusan generálódik, úgyhogy fontosabb, hogy a letisztult html-t tudj írni, mint,hogy vizuálisan odaszerencsétlenkedj valamit.

    Komolyabb webes alkalmazásnál az UI le van választva a designtól. Még PHP-ben is (template motorok). Azt amikor a progi közvetlenül írogatja a lapot print-ekkel gányolásnak hívjuk.
    Mutasd a teljes hozzászólást!
  • Az főleg arra van, hogy azok a programok, amik nem XP-re készültek, de még futottak rajta (kb. win95-től felfelé) is elfussanak win7en.
    Mutasd a teljes hozzászólást!
  • Ja még annyit, hogy abban a múltkor már egyetértettünk, hogy a CSS pozícionálás 'kissé' el van baltázva. Viszont közben rájöttem, hogy a dinamikus layoutolással általában csak a szívás van amúgy is, és nehéz szépre csinálni. Szvsz. legtöbbször fix méretű layouttal érdemes dolgozni. Legfeljebb külön fix layouttal PC-hez meg külön fix layouttal mobiltelefonhoz. Ezt pedig manapság CSS grid framewörkkel csinálják, mert így iszonyúan egyszerű.

    Egy példa nagyon egyszerű CSS grid framework:
    960 Grid System

    Használd egészséggel.
    Mutasd a teljes hozzászólást!
  • Azaz az XP-re, és win2k-ra írt programok futnak a win7-en


    Ö... ugyan nincs win7-em, de akkor minek az ú.n. XP mód (ami egy XP virtuális gép, ha jól tudom) ?
    Mutasd a teljes hozzászólást!
  • Nem akarom védeni a HTML-t, de nem pontosan értem, hogy mit értesz a wyswyg editorok hiánya alatt. Hiszen tömegével vannak a wyswyg html editorok (a jó öreg FrontPage a legismertebb), keress rá a google-on erre:

    WYSIWYG html

    Ha kifejezetten enduserek site készítő tooljairól beszélünk, olyanok is vannak, pl nézd meg a demo videót itt:

    Weebly is the easiest way to create a website, store or blog

    Vagy miért nem írsz egy ilyen designert, ha ilyen fontosnak tartod?

    addig egy sima 2D-s dokumentumhoz / formhoz notepadban gányolják össze a designt


    Nem tudom mit értesz gányolás alatt, de az elterjedtebb web2.0-ának titulált websiteok inkább design mesterművek, mint gányolások.

    http://www.flickr.com/

    Welcome to Twitter - Login or Sign up

    de akár a minimalizmusával:
    Hacker News

    90-es években meg lehetett ezt csinálni grafikus felületen Visual Basic-ben

    Olyan is volt az eredmény mind kinézetben mind használhatóságban. Egy 'kicsit' fejlődtünk azóta ha a userek kényelméről és szépérzékének kielégítéséről van szó.

    Egy komolyabb alkalmazásnál már nem a vizuális editor létezése a lényeges kérdés. Komolyabb alkalmazásnál a tartalom (HTML) úgyis dinaikusan generálódik, úgyhogy fontosabb, hogy a letisztult html-t tudj írni, mint,hogy vizuálisan odaszerencsétlenkedj valamit.
    A fontos az, hogy a prezentációt a viselkedést és a tartalmat lehetőség szerint el tudd választani: erre való a HTML,CSS,Javascript szétválasztás. Mondjuk a CSS3 sytleshheteket összehasonlítani pl. azzal, hogy milyen lehetőségeid voltak a 90-es években a stilizálásra, vagyis a kinézet és a tartalom elválasztására mondjuk finoman szólva is nevetséges.
    A HTML5+CSS3+Javascript(JQuery) nagyságrendekkel fejlettebb és (grafikus) designer barátabb GUI fejlesztői eszköz mint a 90-es évekbeli VisualBasic. Próbálj leültetni egy profi webdesignert egy 90-es évekbeli Visual Basic elé. Hamarosan ki fogja tépni a saját haját, megígérem.
    Mutasd a teljes hozzászólást!
  • Aztán a .NET kialakulásakor a cég teljesen megváltozott, a visszafelé kompatibilitás vonal szerepe jócskán csökkent.

    Az újabb windowsok is kompatibilisek úgy 10 évre visszafelé. Azaz az XP-re, és win2k-ra írt programok futnak a win7-en is (hacsak nem csináltál valami csúnyaságot. És elég sokat csinált a win7 azért, hogy a kompatibilitás megmaradjon (és a rendszer megfeleljen a kor biztonsági kihívásainak).

    Az meg megint egy másik dolog, hogy azért fejlődni is kell. Vicc hogy 2010-ben még mindig azt a win32-t és COM-ot nyomják ami már a 80-as években is elavult technológia lett volna. Azaz a .NET-re átállás hosszú távon nem hülye ötlet: ma sem igazán ír már senki Pl. DOS-os vagy Commodore 64 basic-es programot.

    Épp ezért a HTML5 nem is olyan rossz.

    Alapvetően az egész html világot kellene kidobni a fenébe. Kezdve a javascripttel, folytatva az egész agyonbonyolított, designerrel tervezhetetlen trutymóval. Vicc hogy míg egy autót 3D-ben normálisan meg tudsz tervezni vizuális eszközzel, addig egy sima 2D-s dokumentumhoz / formhoz notepadban gányolják össze a designt. Amikor már a 90-es években meg lehetett ezt csinálni grafikus felületen Visual Basic-ben.
    Mutasd a teljes hozzászólást!
  • Amúgy ha valakit részletesen érdekel a HTML története, akkor ajánlom ezt az oldalt:

    How Did We Get Here? - Dive Into HTML5

    A tanulságok:

    - A HTML evolúciós módon fejlődött. (ezt mindenki tudja)
    - Eleinte a kutyát nem érdekelték a dumamatyik, aki működő kódot szállított, az formálta a legnagyobb eséllyel a HTML-t. (lásd img tag létrejötte.)
    - Aki nem vette figyelembe a visszafelé kompatibilitást, az könyörtelnül elsüllyedt a történelem süllyesztőjében. Tervezhetett az akármilyen szépet, elsüllyedt. (Egyébként kissé más téma, de beugrik, hogy anno még a huszadik században volt egy cég, aki akkoriban a világ egyik legnagyobb cégévé nőtte ki magát a visszafelé kompatibilitást szinte vallásos fanatizmussal követve. A céget úgy hívták, hogy Microsoft. Aztán a .NET kialakulásakor a cég teljesen megváltozott, a visszafelé kompatibilitás vonal szerepe jócskán csökkent.)
    - Vicces, hogy ebben a topicban egyszerre szidják a visszafelé kompatibilitást meg a w3c bölcsészségét, amikor ezek pont ellentettjei egymásnak. Pont a w3c 'bölcsész tagozata' volt az, amelyik letojva a visszafelé kompatibilitást, tök új, a régiekkel nem kopatibilis, sokkal szigorúbb specifikációkat akart létrehozni (XHTML2) de a világ letojta őket, és 2009-ben ipari érdeklődés híján kénytelenek voltak feloszlatni az XHTML2 working groupot. Tehát nem igaz az, hogy a w3c sikerrel erőltethet akármilyen szabványt a népre.
    - A HTML5-öt nem a bölcsész w3c találta ki. Browser készítők és web alkalmazásfejlesztők vízionálták meg egy konferencián, és a w3c elutasította az ötletet. Ezek azonban megalapították a WHAT groupot. A w3c csak akkor kapcsolódott be újra a munkába, amikor már aWHAT group munkájának sikere nyilvánvaló volt. Épp ezért a HTML5 nem is olyan rossz.
    - A 2000-es évek eleje a web sötét középkora volt. A Microsoft böngészőjének óriási piaci részesedése volt. Tudni lehet, hogy a Microsoft levette a fejlesztőket az IE-ről, és csak néhány ember lézengett az IE fejlesztői csapatban akkoriban, azok is csak lényegtelen maintenance-el, bugjavítással foglalkoztak főleg. A konkurrens böngészpk által gerjesztett utóbbi évek web reneaszánsáznak köszönhető, hogy a Microsoft is kénytelen lett foglalkozni a HTML/CSS/Javascripttel megint.
    - Az, hogy a HTML5 specifikáció nincs véglegesítve, de nagyrész implementálva van több böngásző által, az nem bug, hanem feature: állítólag a WHAT group filozófiája, hogy figyelnek a visszajelzésekre, és gyakorlatiasak (ellentében a w3c korábbi bölcsész tagozatával, lásd xhtml2)

    A fent írtak nem a szubjektív véleményem egy technológia jóságáról (nem érzem azt a luxust, hogy én olyasmivel törődhessek), hanem inkább történelmi tények.
    Mutasd a teljes hozzászólást!
  • A html megítélésében nincs is különbség, csak az ide vezető útban. Szerintem a fő ok az volt, hogy nem volt egy cég aki kézbentartsa az egészet, csak a W3C nevű bohóccsapat.

    Bármilyen alkalmazás lehet "terminálos szerveralkalmazás". De az nem jelenti azt, hogy ha X alól elindítasz egy OpenOffice-t az ugyanaz mint egy webes app. Különös tekintettel az erőforrásigényre.

    Az mondjuk egy dolog hogy Pl. egy üzleti logikában ma már a disconnected kapcsolódási modell a default (15 éve, a régi "szép" delphis időkben még nem volt feltétlenül így) és hogy az üzleti logika le van választva a user interfésztől, de az algoritmusok megválasztása is más.
    Mutasd a teljes hozzászólást!
  • Ne haragudj, de a technológiai oldalon nem látok semmi különbséget az állításaink között (HTML fejlődéstörténet, eszközkészlet).

    A "terminál" vs böngésző összehasonlítást sem érzem idegennek: egy korrekt terminálos szerver szerintem ugyanúgy aszinkron kell legyen, mint egy web/appsrv, a terminál is leszakadhat, stb.
    Az "otthagyja a weblapot, visszalép" csak a böngésző terminológiájában létezik, lévén az egy dokumentum megjelenítő, és nem egy remote gui renderer. Folytathatnánk a sort az iframe-ek konzisztenciájával, a historyval, a repost-tal, de minek?

    A Jucika-office hasonlatból szerintem kimaradtak a "szükségességre" vonatkozó kérdéseim. Jucika nem csak a TeX-et nem tanulja meg, de az Office "újdonságait" sem. Olvastam egy elemzést valamikor egy neves számtech oldalon (de sajnos most nem találtam meg). A cikkíró letett egymás mellé egy 15 éves és egy mai gépet a megfelelő programokkal, és mint normál user értékelte őket, a boot időtől a levélírás, dokumentumszerkesztés, excel, web, stb. (alapvetően tehát a munka-hasznosság és nem a csilivili területen) Hajszállal sikerült kihoznia a régi gépet győztesként - de nem ez az érdekes, hanem az, hogy ha ez az összehasonlítás egyáltalán elvégezhető egy állítólag rakétasebességgel fejlődő területen, akkor ott marha nagy átverés van. Az "user" szempontjából az a 15 év kidobott idő volt... Ugyanígy: tényleg "kellett" a pixel-design, az animáció, a ...? Vagy csak ezzel elvárást teremtve adtuk el a lényeg tekintetében változatlan "újdonságokat"?

    Nincsenek összeesküvés-elméleteim, az üzletemberek szerintem legsötétebb csoportja a Google-nél üldögél, akik elérik, hogy az "ingyen" szoftver és szolgáltatások árát ne a kasszánál, hanem mindenféle termékek marketingköltségébe csurgatva fizessük ki, és mivel "ingyen és szívjóságból" van, még asztal se legyen, amit verhetünk.
    Szóval nem az üzletembereket bántom én, csak azt jegyzem meg csendesen, hogy nincs értelme szidni az eszközeink bénaságát, mert ebből élünk.
    Mutasd a teljes hozzászólást!
  • Ez tényleg szépen foglalja össze a web lényegét...
    Mutasd a teljes hozzászólást!
  • Alapjában véve másról van szó. Az egész onnan indult, hogy van egy html nevű dokumentumformátum ami alapvetôen szöveget tartalmaz, némi formázási lehetőséggel, és ebbe hiperlinkeket lehet elhelyezni. A dolog igazából arról szólt hogy van egy doksi amit elhelyezel egy számítógépen, és ez hivatkozhat ezen a gépen belül, vagy egy másik gépen egy másik doksira. Ez az egész erre volt kitalálva. Szó sem volt üzleti logikáról. A tervezésénél az volt a szempont hogy a doksi olvasható legyen a Commodore 64-től az Apple Macintoshig mindenhol. Felbontásfüggetlenül, OS függetlenül. Szépen működött is a dolog.

    Aztán, hogy a web kilépett az egyetemek világából és megjelentek a céges weblapok, megváltoztak az igények. Kellett animáció, kellett pixelre megtervezett design, és többé nem az volt a fő szempont hogy Commodore 64-en is meg lehessen nézni, hanem az hogy a leggyakrabban használt felbontáson jól mutasson. És persze megjelentek az anno a html-be mellékesen belepakolt form elemek alapján "üzleti logika" rakása a dolog mellé.

    Az aztán megint egy másik dolog, hogy ehhez szerveroldalon milyen gányolmányok születtek a perles weboldalaktól a PHP-ig. De az egy másik történet.

    A lényeg, hogy ez az egész alapvetően más mint amikor te egy X11-gyel vagy egy RDP-vel elérsz egy távoli gépet és azon futtatsz valamit. És nem csak a felületben más, de a logikában is. Kezdve azzal, hogy teljesen asszinkron. Egy távolról futó desktop program tudhatja hogy a user a állapot után milyen másik állapotba hozhatja a programot. Web esetén a user bármit tehet: otthagyhatja a weblapot, visszaléphet az előző oldalra, stb.

    Az tény, hogy a web technológiai szempontból egy trágya. Főleg kliens oldalon az. Maga a javascript is egy hülye vicc, a html-t egyszerűen nem arra találták ki amire használják, és amire használják arra a létező legrosszabb megoldás. De ez nem holmi gonosz üzletemberek összeesküvésének eredménye, hanem a community design hatása. Nem véletlenül van a méheknél királynő és nem parlament. Ezért van méz...

    Ami az office-t illeti, szerinted mi jelent nagyobb időmegtakarítást: 1000 ember írja az office-t (aminek a word azért csak egy kis része) vagy az ha az a jó néhány millió ember aki wordöt használ nekiáll megtanulni a Tex-et olyan szintig hogy azonos produktivitásra legyenek képesek vele mint a worddel. Már persze, amennyiben ez lehetséges.

    Másképp nézve a dolgokat: Egy office úgy 50 ezer forint. Jucika bérköltsége aki dolgozik vele úgy 300 ezer forint havonta. És Jucikát nem fogod egy hónap alatt olyan szintre hozni a Tex-ben hogy ki tudja váltani a Word-öt. És Jucika Excelezik is...
    Mutasd a teljes hozzászólást!
  • Anno valami hasonlót írtam én is itt.
    De amúgy hülyeség az egész.
    Mutasd a teljes hozzászólást!
  • egy államadósságnyi pénzből fejlesztett szoftvernél is az az elképzelés, hogy "majd működik valahogy, megsupportáljuk még több pénzért, esküszöm"


    Egyszerűen itt tart a fejlődés. Nem tudsz jobbat mondani. Olyan módszerekkel lehet csak hibákat csökkenteni, amik nagyon időigényesek, mint pl. mindenre tesztet írni. Ez praktikusan 2-3 szorosára növeli a fejlesztési időt, de így sem lesz garantált a végeredmény.
    Mutasd a teljes hozzászólást!
  • De ma már a Microsoft szerepe sajnos a HTML CSS világban szinte a szándékos kerékkötés. A Microsoft a Silverlightot nyomja, és csak azért van benne a HTML CSS bizniszben, hogy kerékkötő tudjon maradni. Kénytelen kelletlen megcsinál pár dolgot, amit már rég tudnak a többi böngészők (lásd CSS3 feature-ök), kénytelen kelletlen felgyorsítja a javascript interpreterét, ha már tényleg annyira lassabb a többikenél, hogy a browserpiacról való kihalás fenyegeti őket, de tesznek róla, hogy ne fejlődjön a HTML+CSS elég gyorsan és legyen elég inkompatibilitás, ezáltal megteremtve a helyet a Silverlighnak. Senki nem gondolhatja komolyan, hogy egy cég magának akarna konkurrenciát csinálni. Az nem lehet, hogy a HTML+CSS-t és a Silverlightot is egyformán komolyan vegye az MS.


    Fyi: Az MS-en belül is kegyetlen harc folyik a két platform között. Az IE csapat a saját nünükéjének tekinti a felturbózott IE 9-et, az egész csapat hülyére lobby-zzal magát annak érdekében, hogy inkább a hardvergyorsított HTML5 vonal legyen az új webes frontend zászlóshajó. Egyes MS emberkék odáig mentek, hogy egyenesen temetik a WPF/SL vonalat a blogjaikban.

    Viszont van valami a tarsolyban, amiről még ők sem tudnak ... (erről nem beszélhetek még másfél hónapig az NDA miatt, de hamarosan ki fog derülni, miről is van szó).
    Mutasd a teljes hozzászólást!


  • Rég bólogattam ekkorát fórumolvasás közben! Megengeded, hogy a céges levlistára bekopipészteljem a műved a jövő héten minden érintett okulását és szórakoztatását elősegítendő?

    SZERK.: A kopirályt meg a prog.hu link nem marad le.
    Mutasd a teljes hozzászólást!
  • Az ellenőrzés kedvéért: az, hogy a csupán példaként kiragadott TeX és az X11 a vita tárgya, azt jelenti, hogy a jóval durvább megállapításaim nálatok is ülnek?

    X11 - nyilván korábban evidens volt a "vékonykliens", hiszen "A GÉP" csillagászati árú csodaizé volt. Azt sem véletlenül írtam, hogy az X11-et nem megoldásként hoztam fel, csak jelezve, hogy ez az irgalmatlan méretű "eszközhalom" véleményem szerint technológiai szempontból nem indokolt - üzletileg viszont természetes. Röviden: a technológiai "jó" majdnem fedi az üzleti "rossz" fogalmát.

    TeX - én sem TeX-et, hanem OO-t használok. Ismét a jelenség az érdekes: HA elhatározod, hogy meg akarod oldani a problémát, és nem akarsz félévenként új verziót kihozni valamiből, akkor az üzleti bukta - így nyilván nem lesz pénz (vagy, mint a neves free cuccok esetén: dac) arra, hogy felhasználóbarát legyen. Ugye egyikünk sem gondolja komolyan, hogy a TeX és a Word fejlesztésére fordított erőforrás összehasonlítható? Bár... ha nem részvényindexeket, hanem emberévet számolunk, vajon tényleg "megéri" a Word?

    Egyáltalán nem reklámozom az "ingyen" munkát (és én sem tartom "jónak" a Google-t, sőt). Viszont riaszt a feleslegesen elvégzett munka, a rá fordított erőforrás, a csak erre, és sok másra nem alkalmas "programozó" hegyek képzésére fordított energia.
    Vajon a megírt programok, az új és új verziók hány százalékára van valóban szükség? Vajon a Word tudáskészletének hány százalékára van szüksége "az usernek"? Vajon a leírt kód hány százaléka valóban eredeti, és nem ezredik ismétlése egyazon feladat megoldásának?

    Véleményem szerint ezek a kellemetlen kérdések "tűnnek el" a valós feladatmegoldásra guánóként rakódó "eszközök" halma alatt.
    De tudom, már be is fogtam... Jó hétvégét!
    Mutasd a teljes hozzászólást!
  • A vékonykliens valóban régi dolog. Persze, az X11 előtt is létezett ez, és persze a vékonykliens ára a felhasználói élmény - ami gyakran produktivitást is jelent. Minél butább a kliens, annál inkább. Nos, az X11 elég buta...

    Ami meg a Tex-et illeti, pár ezer fanatikuson kívül nem igazán használja a kutya sem. Ugyanis nem csak üzletileg gáz, de a használhatóság sem az erős oldala. A usereknek viszonylag kis százaléka hajlandó megtanulni egy könyvet csak azért hogy megspórolja egy Word árát.


    Egyébként meg a programozás arról szól, hogy az embereknek olyan programot csinálunk amire szükségük van - és amiért hajlandóak fizetni is. És nem gáz ha valaki ezért pénzt kér - amúgy érdekes, hogy ez az egész dolgozzunk ingyen dolog mindig a programozókat célozza, és nem Pl. a pizzasütőket, az áramszolgáltatókat, a hardvergyártókat, stb. Pedig pizzát sütni sem rossz dolog, ha az ember szereti.
    Mutasd a teljes hozzászólást!
  • X11-nél picit régebbi dolog a vékonykliens.
    Az első ilyen gép, amivel találkoztam, egy RC3600-as adatrögzítő rendszer volt. (asszem, lengyel berendezés volt, sok-sok monokróm karakteres terminállal)
    Mutasd a teljes hozzászólást!
  • Azért nem annyira off-topic...

    Mi is ez a nagy webes történet? Arról van szó, hogy eredetileg kitaláltak egy hivatkozásokat és alap formázásokat kezelni képes statikus szövegformátumot (HTML), illetve írtak olyan programokat, amik ezt megjeleníteni képesek (böngészők).

    Aztán megjelentek a (különböző) formázási szabványok, amiket a böngészők különböző módon értelmeztek. Kitalálták azt, hogy az eredetileg statikus tartalmat dinamikus módon állítsák elő a szerveren (sokféle szerver típus, nyelvek, ...), felhasználói interakciót hozzanak létre a kliensen (JavaScript, Flash, ...), ezekre mindenféle toolkiteket húzva szerveren, kliensen, böngészőn, ..., ..., ...
    Mindenből állandóan változó újabb verziók, értelmezési eltérések, kompatibilitási őrület (miért és meddig igen, miért nem), hulladék minőségű kiszolgálók, kliens engine-ek, nyelvek.

    Pedig mi a feladat valójában? Az üzleti logika egy a hálózaton elérhető másik gépen fut, nem a kliensen. Jaj, de nagy durranás, ezt pl létrehozásától kezdve tudja az X11... Bár tény, a kliensre delegált logikát nem oldja meg - de valljuk be, annak túlnyomó része parasztvakítás, elvégre a lényegi dolgokat a biztonság miatt úgyis a szerveren kell végezni az adatok felküldése után.

    Nem azt mondom, hogy az X11 kiválthatná azt, amit ma a böngészők csinálnak - de azt igen, hogy nem a megoldást keressük, hanem a pénzt. A történet szerintem szó szerint lefedi az első irományom tartalmát.

    Ami meg a minőséget illeti, lehet máshogyan is, lásd: Donald Knuth: TeX - ám így nem lehet pénzt keresni, sok programozót fizetni, tőzsdei céget működtetni. Üzletileg Knuth úr egy balfék - viszont, pont ezért, valódi programozó. Nem úgy, mint az Oracle.
    Mutasd a teljes hozzászólást!
  • Itt ami veszélyes lesz a következő pár évben az a gugli és a többi webes nagyszolgáltató dominanciája. A microsoft csak a windowst akarja eladni. A google a lelkedet.
    Mutasd a teljes hozzászólást!
  • Én nem lennék az ellen sem, ha a Silverlight terjedne el, csak olyasmi terjedjen el, ami fejlett, és ne kelljen inkompatibilis megoldásokhoz programozni. Mondjuk egy Microsoft dominanciának meg vannak a veszélyei, (de egy Google dominanciának is, csak más szempontból.) Ami szerintem még nagyon ígéretes lehet, az egy 3-adik technológia: a google NativeClient. Ha a NativeClient elterjed, onnantól kezdve újra lehetőség lesz tetszőleges rendszerek (csak security constraintek lesznek) böngészőben futtatására, így nem kell annyi szirt egymásra pakolni, és szabadabbak leszünk az alkalmazott programozási nyelvek tekintetében is. Amikor Unity3D programot demóztak külön Unity3D plugin letöltés nélkül NativeClientben, az már elgondolkodtató volt.
    Mutasd a teljes hozzászólást!
  • Szerintem alapítsunk egy V133C-t és találjuk ki hogy a 230V-os áram holnaptól 133V legyen. Aztán szóljuk le az áramszolgáltatókat, mert nem akarnak átállni a "szabványunkra".


    Tiszta mázli, hogy a gépekben általában szaggatóüzemű táp van, így legalább akkor is tudunk majd programozni, amikor az ELMŰ hirtelen elkezd a V133C szerint szolgáltatni :)
    Mutasd a teljes hozzászólást!
  • Ok, hogy fejlődnek, csak már most kevés a css3, html5 a felhasználói igényekhez, pedig még kész sincs...


    Igen, igen, ez az egyik leggyönyörűbb végeredménye az egésznek. Hogy a csodálatosan nyílt, szuper, remek HTMLCSSJS hiperűr-technológia mellett szóló legfőbb érv az, hogy hát Istenek vagyunk, 2010 felé már leírtuk azt, hogy hogy kellene támogatni azt, ami még úgy öt évvel ezelőtt lett volna esedékes.

    Ennek meg ugye az az eredménye hogy méginkább jquery, extjs és hasonló keretrendszerre építünk. Aztán pedig jön az extjs alapú x keretrndszer, aztán pedig az x alapú y keretrendszer és így tovább. Lapátoljuk a szrt a fejünk fölé.


    Igen, valami olyasmi jelenség ez, mint a sztereó rádiózás. Nem gondolkodtunk előre, hát akkor nyomjuk az összegjelet, 22KHz-el feljebb a különbségi jelet, és akkor néhány remek összeadás és kivonás után már valami egészen hasonlót tudunk majd kiadni a hangszórón, mint amit a rádióadóban akartak elérni.
    Mutasd a teljes hozzászólást!
  • De ma már a Microsoft szerepe sajnos a HTML CSS világban szinte a szándékos kerékkötés. A Microsoft a Silverlightot nyomja, és csak azért van benne a HTML CSS bizniszben, hogy kerékkötő tudjon maradni.


    Ezzel én szinte maradéktalanul egyet bírok érteni - de nem messze megfelelőbb és használhatóbb a web "céljaira" a Silverlight, mint a szedett-vedett HTML+CSS+JS kombó? Meglepő-e a Microsoft-tól, hogy nem igyekeznek túlzottan támogatni ezt a technológiát? Én mondjuk annyira nem rajongok az ilyen nagyon proprietary megoldásokért, de nem messze jobb alternatíva még ez is, mint valami olyasmit hackelni még tovább, ami egyáltalán nem is erre lett kitalálva?
    Mutasd a teljes hozzászólást!
  • Szerintem is hulladékon élünk - de ez a fentiek alapján nem véletlen, az alternatíva pedig az, hogy a ma "programozásból" élő emberek túlnyomó többségének mással kéne foglalkozni...


    Ez kétségkívül igaz - a formális definíciók a programjainkra perpill kb. használhatatlanok bármiféle minőségbiztosítási célra, gyakorlatilag szinte csak és kizárólag tapasztalati tényekre építhetünk remek gépeink működése kapcsán. Mondjuk ez már kicsit offtopic, mert a web borzalmairól akartam diszkutálni, de azért a nullabites felhasználó szemszögéből nézve nem rettenetesen felháborító, hogy konkrétan hülyére keressük magunkat, ellenben gyakorlatilag semmiféle felelősséget nem vagyunk hajlandóak vállalni azért, hogy amit összeraktunk, az képes lesz működni? Vagy hogy az elképesztő összegekért megvásárolt support az annyit fog érni - bocsánat, de nemrég történt velem ez az affér egy remek Oracle termékkel, ami a maradék illúzióimat is összetörte -, hogy majd két hónapon át nézhetjük a csodálatos webes ügyintéző felületen, hogy "X átpasszolta az ügyet Y-nak. Y biztosít, hogy foglalkoznak a problémánkkal. Ó igen, most jön egy internal discussion a fejlesztő kollégákkal. Ó, ezen sajnos nem derült ki semmi. De sebaj, ott van Csandragandragupta Sziámiáú, kérdezzük meg őt is, etc, etc"?

    Szerintem azért a döbbenetes pénzekért, amit egy "megoldás" kifejlesztéséért elkérünk, némivel több garancia is elvárható lenne, minthogy "köss velünk support szerződést minél több időre minél több pénzért, és akkor esetleg negyed év alatt megoldjuk a sürgős problémáidat"; én (be)látom, hogy egy program megfejlesztése bonyolult és nehéz dolog, de az, hogy egy államadósságnyi pénzből fejlesztett szoftvernél is az az elképzelés, hogy "majd működik valahogy, megsupportáljuk még több pénzért, esküszöm", az valahogy rohadtul felháborító.
    Mutasd a teljes hozzászólást!
  • Ok, hogy fejlődnek, csak már most kevés a css3, html5 a felhasználói igényekhez, pedig még kész sincs...

    Ennek meg ugye az az eredménye hogy méginkább jquery, extjs és hasonló keretrendszerre építünk. Aztán pedig jön az extjs alapú x keretrndszer, aztán pedig az x alapú y keretrendszer és így tovább. Lapátoljuk a szrt a fejünk fölé.
    Mutasd a teljes hozzászólást!
  • Egyébként egy fejlődő területen szerintem az egész szabvány lassító tényező.


    Na ebben egyetértek. 10 éve egyszerűen a világ alkalmazkodhatott volna a Microsoft böngészőjéhez. Ma 2010-ben pedig kb. a Google Chrome-hoz vagy a Firefoxhoz.
    Legalábbis ha a webfejlesztők, azok megrendelőik és a felhasználók érdekeit nézzük.
    Mutasd a teljes hozzászólást!
abcd