Új hozzászólás Aktív témák
-
julius666
addikt
Izé, most a html/css funkciókról van szó, vagy az ECMAScript-ről?
ECMAScript-ről.
ha viszont a nyelvek különböznek, az keményebb dió, emiatt nem érdemes gyors sikerre számítani
Annyira nem különböznek. Bizonyos featureök implementálhatóak a régebbi nyelven is (kvázi syntactic sugar-ök), max 1-2 ritka use caseben nem megfelelő a működésük/teljesítménybeli problémák. Bizonyos featureök visszafelé "kompatibilisek" (pl. strict mód). Bizonyos featureök esetleg nem megoldhatóak, ezek nyilván ugrottak. A nyelv maga maradt.
Ez legfeljebb azok a programozókra igaz, akiket te ismersz.
Nyilván van kivétel is bőven, de szerintem körbe lehet nézni a piacon. A webprogramozás klasszikusan nem az az igényes terület.
Ha van egy nyelv, ami mondjuk a Javascript-nél jobb (valamilyen metrikák szerint) és lehet belőle javascript-et fordítani, akkor mi a probléma?
Esetleges teljesítménybeli problémák, fejlesztési problémák (amit ntomka is említett illetve jó debuggolást).
És miért nem adnak a böngészők hasonló API-t?
Nálam hiába vered az asztalt, ez inkább a W3C meg a böngészőgyártók területe (verik is náluk elegen). A jQueryre szerintem nyugodtan mondhatjuk hogy kvázi-szabvánnyá vált, gyakorlatilag ezt használja mindenki.
-
Integra
titán
kiigazitanálak.
azért nézd meg mit kér az ibm a mainframe licenszekért.. meg fogsz lepődni..
nem azért használnak globális nagyvállalatok, bankok, olajcégek etc mainframe-t mert az régi és ha már az van, akkor használjuk tovább, mert nem éri meg, hanem mert geci drága és sokan inkább próbálják kiváltani olcsóbb rendszerrel, amiről tudják, hogy hulladék és nem hozza azt amit az mf tud, de legalább a managerek prezentálhatják a költségcsökkentés számát (a support meg cumizhat..), hanem azért mert ez az egyetlen rendszer ami képes mai napig azt az adatmennyiséget stabilan és nagyon gyorsan feldolgozni, miközben nem lehet feltörni sem.
újrairni? újra lehet, optimalizálva, okosabban, modulárisan megirni a kódot, lehet, persze. csak még jobb lesz. ez igy működik, igy lett kitalálva, igy stabil. az kéne még, hogy belepiszkitsanak sallangokkal, onnantól lenne igazán csodás ekkora rendszereket karbantartani és megfelelő sebességgel üzemeltetni
szóval hagyjuk ezt a jellegzetes bullshit dumát inkább.. inkább te általánositasz, én meg konkrétan látom a különbséget, hogy az adott hardver és szoftver hogy működik együtt és mit tud egy másik adott hardver és szoftver pároshoz képest. ég és föld. de mindegy, nem magyarázom, felesleges, hiszen ez csak bullshit
ha tehetné, minden nagy cég mf-et állitana csatasorba, csak nem tudják megfizetni.. ilyenkor jönnek az olyan alternativ (és borzalmas) megoldások mint a sap.. ami amúgy sok esetben szintén mf db2 táblákból dolgozik, nem véletlenül
de mondhatnám azt is, hogy szerintem meg a te irásod jellegzetes bullshit-szöveg, fiatal világ kódere duma, aki a nagy öregeknél is jobban tudja mi fán terem a világ, de még a tojás héjj is ott a seggén..
szóval hagjyuk inkább..[ Szerkesztve ]
...egy fecske nem csinál nyarat, viszont egy hülye százat csinál...
-
ddekany
veterán
"Végül is a PHP csont nélkül teljesíti a hozzászólásodban leírt fő feltételt - gyorsan és pöcsölés nélkül lehet benne megoldani a dolgokat."
Mennyiben kell több "pöcsölés" akkor, ha az ember egy nem inkompetens emberek által összegányolt de hasonlóan "script" nyelven ír meg valamit? Tényleg csak példának, mondjuk Python vagy akár Ruby nyelven. Nyilván költői a kérdés, mert ezekben rövidebb és esetleg megbízhatóbb is lesz a cucc...
Mellékesen az is félig legenda, hogy statikus nyelvekben hosszabbak a programok. Valamennyivel nyilván, a mindenféle deklarációk miatt. Azon felül ez inkább kultúra kérdése... A dinamikus nyelvekben a tervezők általában igyekeznek tömören kifejezni dolgokat, meg elég hamar felkapják az új paradigmákat, míg a populáris statikus nyelvek általában szarnak ezekre. Most csak példának, Java-ban a mai napig nincs semmi, amivel JavaBean property-ket lehetne gyorsan definiálni egy osztályban, és erre nincs is kilátás. Nem normálisak. Project lombok mondjuk egy próbálkozás erre, de hát amíg nem része a nyelvnek...
[ Szerkesztve ]
-
Integra
titán
nem fogytam ki, csak reagáltam a bullshitezésedre, nem tetszik? ne bullshitezzél, mert az amit irsz.
az az ő bajuk, szivnak is a rendszerekkel. járjál utána az mf-nek egy picit, mert úgy látom, sok rálátásod nincsen. a mainframe él és élni fog, akkor is, mikor ezek az alnternativ megoldások már rég halottak és valami újat próbálnak eladni helyettük. hányszor temették már az mf-et, aztán mégis itt van él és virul és keményen megy a fejlesztés rá. csak kevesen engedhetik meg maguknak, ennyi. nem kell leköpni azt ami öreg, hiába divat a fika
nem nekem kell hinni, hanem a történelemnek, az pedig tökéletesen bizonyitja, hogy ezeknek a rendszereknek igenis van létjogosultságuk és még sokáig lesz is, nem is kicsi. max nem kicsiny magyarhoni piacban kell gondolkodni..[ Szerkesztve ]
...egy fecske nem csinál nyarat, viszont egy hülye százat csinál...
-
Integra
titán
cloud és mf technológia teljesen más és teljesen más céllal működik, nem is ugyanaz a két cégcsoport. akinek az adatai életbevágóan fontosak, azok nem fogják kiadni az adatparkjaikat, megépitik inkább a sajátjukat. teljesen jól megfér a kettő egymás mellett. az adatvédelem miatt az igazán komoly cégek nem fognak cloudozni. van pénzük rá, hogy megtehessék, hogy ne tegyék, sokkal többet érnek azok az adatok, mint az a szaros szerverpark valaha érni fog. cloudot alapvetően a kisebbek használják, akiknek nem éri meg a saját. és van ebben valami, nem feltétlen rossz ez, csak megint azt mondom, nem ugyanaz a célcsoport, nem ugyanazok a célok és okok, indokok.
ha pedig az mf kifutó lenne, akkor az ibm sem fejlesztené mai napig és a vállalatok sem használnák mai napig illetve fejlesztés sem menne rá. pedig van, max nem látod mert nagyon más téren mozogsz, semmi baj nincsen ezzel. miért fejleszti? mert van rá igény és lesz is rá még nagyon sokáig. szerintem az ibm nem hülye.. ahogy a nagyvállalatok is amelyek ezt a technikát használják. nem lehet, hogy megvan az okuk rá, amiről te nem tudsz, vagy nem akarod megérteni?
nyilvánvalóan egy apple és egy google más cégprofil mint bankok és hatalmas állami és magán vállalatok, amik nem tech cégek, de a működésükhoz elengedhetetlen a support részleg is. azért mert mit csinál a google ez absz semmit sem jelent arra nézve, hogy teljesen más profilú vállalatok mit csinálnak és forditva
ez a cloud tisztára olyan mint az outsorcing, boldog boldogtalan kiszervezte a supportot indiába, mer az jó, mer az olcsó.. az igazán okosak meg sosem tették, megbecsülik a saját belső munkaerőt. be is jött nekik.
azt meg már csak csöndben jegyzem meg hogy megy a gameframe fejlesztés is, asszem a neve mindent elmond[ Szerkesztve ]
...egy fecske nem csinál nyarat, viszont egy hülye százat csinál...
-
ArchElf
addikt
Kettős a dolog kis rendszereknél (még nagy cégeknél is) tényleg erősen nyomul a virtualizáció.
Viszont az üzleti core rendszereket egyszerűen nem éri meg kidobni. Soha nem termli ki a cég az a több 100 milliós (vagy milliárdos) nagyságrendű költséget, amibe csak a csere alapból kerül (és akkor még a régi rendszerhez illesztett szatelitekről nem is beszéltünk).Integra: Indiai support - na erről tudnék mesélni
AE
[ Szerkesztve ]
Csinálok egy adag popcornt, és leülök fórumozni --- Ízlések és pofonok - kinek miből jutott --- Az igazi beköpőlégy [http://is.gd/cJvlC2]
-
ddekany
veterán
Ja, hát ez lényegében a fókusz hiánya az adott területre (weboldal készítés)... Nagy kár, hogy anno senki hozzáértő nem fedezte fel ezt a rést, pontosabban, hogy milyen szögből kell támadni (könnyű kezdés, kulcsrakészség). Ha lenne afféle romantikus szakmai böcsület és büszkeség, én mint szoftveres szégyellném magamat, hogy ez így történt ahogy. Amúgy ezért is tartom rombolónak az egész jelenséget, aminek simán a szimbóluma lehetne a PHP... Mert az egy dolog, hogy gyakorlatilag egy-két ember fiatalos ostobasága miatt kell szükségtelenül többet vacakolni millióknak. De még ott van az is, hogy mennyire demoralizáló ez azoknak, aki esetleg amolyan gyermeteg módon valóban szeretik és értik is szakmájukat. Oh well...
-
bambano
titán
az egyik ok, hogy azt a megbízhatóságot, amire egy banknak szüksége van, a mai pc-k még mindig nem tudják. a pc az még mindig a bohócliga, más kérdés, hogy sok helyre elég.
a másik ok pedig az, hogy pénzt akkor lehet kizsarolni az ügyfélből, ha változtatást tukmálsz rá. azért soha nem fog fizetni, hogy van egy főkerete, te meg, mint sales manager special főfőaccount kezelő, beállítasz a főnökhöz, hogy milyen jó is a főkeret. Pénzt akkor tudsz kivasalni belőle, ha főkerete van és rábeszéled a cloudra, hogy az milyen jó. beruház, megveszi, majd hagyod pár évig főni a levében, és utána elkezded neki magyarázni, hogy nem cloud, hanem főkeret.
ezt csinálják évtizedek óta.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
nekem pl. egy eserver x3650 nem dzsunkapc, még talán azt is mondhatnám, hogy nekem egy ilyen gép (a maga *méret*kategóriájában) a pc-k csúcsa.
de egy ilyen gép ipari hulladék ahhoz képest, ami egy 6510-es vax (ami még mindig nem főkeret, max. midrange), vagy egy 4361-hez képest, ami igazi főkeret volt a maga idejében. pl. hol vannak a pc-k virtualizáció tekintetében egy igazi főkerethez képest? kb. ott, ahol a 60-as években a főkeretek tartottak. van még ötven év hátrányuk.
a cloudról alkotott véleményem ismert, viszont azt gondolom, hogy minél nagyobb pénzeket fognak bevasalni a cloudra átállást elkapkodók egy leállás után, annál inkább főkeretre fognak költözni azok a cloudok, amelyek gazdái valamit is komolyan gondoltak.
Majd vesznek pár főkeretet, mindegyiken el fog futni 10-20 ezer darab pc-nek megfelelő mennyiségű cloud kliens és kész. vagy marad a kevéskilences rendelkezésre állás.a szélszes nem vásárol eszközt, hanem elad. jelen esetben tukmál.
php: ha egy nyelv nem akar szigorú szabályokkal rendre és rendszerességre kényszeríteni, akkor először kiderül, hogy azon a nyelven lehet ócska programokat írni, másodszor kiderül, hogy csak ócska programokat írnak.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
"Ez biztos nagy truváj volt a 70-es években, de most már nem az.": mennyire is virtualizáltak a mostani pc-s processzorok? képes hardveres virtualizációt használó rendszer bebootoltatni a virtualizációs réteget egy guesten? ez még a kódmorfingosoknál sem mindig megy, ha jól emlékszem. Kérdés tehát, ha ma már nem akkora truváj a virtualizáció, miért nem tudnak ma olyan szintű virtualizációt az x86-os procik, mint anno az s/370-esek?
"ami elosztott rendszereknél alapvetően nem is nagyon létezik?": így is nézheted, meg úgy is, hogy azért lettek elosztott rendszerek, mert a pc egy hulladék. ha nem lenne a pc megbízhatósága olyan, amilyen (semmilyen), akkor nem kellene cloud, meg nem kellene azon agyalni, hogyan migrálsz egy futó guestet másik hostra, meg ilyenek.
persze érdekelne, hogy a cloudban futó alkalmazásod hogyan éli túl, ha az azt hostoló node pukkan ki. nekem valami azt súgja, hogy sehogy.
"A 6510-es VAX egy 22 éves gép, 62 MHz-es processzorral" szerintem meg 75 MHz-es. De teljesen mindegy, mert hiába 22 éves, ha akkor is többet tudott, mint a mostani pc-k. Hiba lenne feltételezni, hogy a főkeretek azóta nem léptek előre. A főkeretek sem 75MHz-en mennek 128 mega rammal.
Szóval lehet, hogy nosztalgia zóna 22 éves példákat hozni, de ez csak akkor lenne helytelen, ha feltételeznénk, hogy az a szerver-kategória azóta nem fejlődött semmit. De fejlődött, ergo a mostani főkeretek jobbak, mint a 22 évvel ezelőttiek. Ennyi.
"Szerintem te nem vagy programozó"? és itt nagyon erősen a szerinteden van a hangsúly.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
Cathfaern
nagyúr
"Szerintem te nem vagy programozó (nem bántásból, csak a gondolatmeneted erről árulkodik)"
Sajnos nagyon igaza van pedig akár az, akár nem. Tele van az ország (meg a világ) olyanoknak, akik webprogramozóknak hiszik magukat, de valójában webprogramozót alig találni. Ellenben van nagyon sok ember aki tud weblapokat készíteni... és a kettő nagyon nem ugyanaz. Mi cirka fél éve próbálunk embereket keresni, de egyszerűen siralmas a kínálat (igaz részben ez köszönhetően annak is, hogy nem budapesti cég, de a lényegen nem változtat). És ez alapvetően a php-nak és a js-nek köszönhető.[ Szerkesztve ]
-
bambano
titán
"melyik az a nyelv, amiben kevés munkával, gyorsan lehet egyszerű weboldalakat és webes szolgáltatásokat gyártani?": nyelv? programozik még valaki csupasz nyelven, pl. php-ban webes alkalmazást?
én inkább azt kérdezném, hogy melyik az az ecosystem, amiben...
nekem a woodstock. még akkor is, ha régi.egyébként "boldog-boldogtalan szeretett volna magának egy egyszerű honlapot": hát ja, ez meg is látszik a deface helyezési listával foglalkozó weblapon
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
bambano
titán
woodstockot (ismereteim szerint, de lehet, hogy tévedek) az 5.5-ös meg a 6-os netbeansben visualweb nével lehetett találni, volt hozzá huzogatós klikkelős felülettervező. ezért szeretem. a későbbi netbeansekből dobták, mert túl sok erőforrást igényelt a fejlesztése.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
ddekany
veterán
Ha csak teljesen földhözragadt gyakorlati jelentőségét nézzük a dolgoknak, jó lenne, ha nem kövülne bele örökre a civilizációnkba ez a szar (is), hanem egyszer kiváltaná valami jobb. És de igen, számítana. Ez nem fog megtörténni valószínűleg soha, de ha meg fog, ahhoz kellett, hogy ne legyenek annyira sötétek a programozók, hogy nem látják a "tetvezők" (
) által elkövetett hibákat, ami igenis az ő idejükbe kerülnek a végén.Az egész pont így kapcsolódott a témához (JavaScript/ECMAScript VS új valami nyelvvel próbálkozás) amúgy... Ha nem akarunk úgy járni, mint PHP-vel, sőt a C/C++-al, jobb vigyázni.
[ Szerkesztve ]
-
FTeR
addikt
az érved ott megdől, h php már rég nem arra van hazsnálva, amire kitalálták.
a php egy perl klón script nyelvnek indult és mindenféle koncepció nélkül kapaszkodott fel webserver OOP-ig.
a probléma a koncepció hiányával és verziókezeléssel van. ez legjobban a függvénynevekben követhető, mint a pl mysql_real_escape_string, mert az eslő verzió nem sikerült elég real-re. a string függvények jó példák még, ugyanarra a feladatra van 6 függvény, amik 6 féleképpen kell meghívni és egyik sem igazán jó.összehasonlításképpen, a C# is egy bloatware, ami nincs leragadva egy metodikánál, mégsem akkora káosz mint php.
-
bambano
titán
nem azt kérem számon, hogy miért nem menti a php az állapotteret, hanem azt, hogyha megkérdezed, hogy miért gagyi a php és választ kapsz a kérdésre, akkor a válaszolás tényén minek kell kiakadni.
miért is mentse a php az állapotterét? mert az alkalmazásoknak szokott olyanjuk lenni, azért. ez az alap php-ban értelmes eszközökkel kezelhetetlen probléma, míg jáva ee-ben alapból ott van és kezeli a teljes ecosystem load balancer frontendtől kezdve appszerverrel bezárólag. Hát ezért gagyi a php, minimum a jávához képest.
Annak a php-nak, amit az arckönyv használ, van bármi köze az eredeti php-hoz? mert itt olyan hírek szállingóztak, hogy nagyon átdolgozták az egészet... ráadásul az arckönyvben alapvetően rövid, egyszerű tranzakció zajlik, de abból sok. Ezt simán lehet úgy skálázni, hogy hordod be a vasat a szobába, valamelyik majd csak kiszolgálja azt a kérést. Egy bonyolultabb alkalmazásnál ez nem működik rendes nyelvi eszközrendszer nélkül.
Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
FTeR
addikt
mi köze a http-nek ahhoz, hogy a session-t hol tárolja?
asp.net-ben pl 3 van:
- inprocess
- state server
- sql serverconfig kérdése. ha sql server-be rakod, akkor az sql server képességeinek megfelelően tudod skálázni. előnye még, h egy server restartot is túlél a session.
#166
ezt az érvrendszert gondold újra. komolyan azzal akarsz érvelni, h php az a környezet ahova nem kell 3rd party? 3rd party nélkül a php konkrétan használhatatlan.[ Szerkesztve ]
-
ddekany
veterán
"Weboldalak fejlesztésénél az állapottér mentése valamilyen session azonosítón keresztül történik - ez a http protokoll következménye, tehát független a programozási nyelvtől."
Ez nem így működik. A session-t, mivel a látogató tevékenységéhez kötődőik és nem reprodukálható, persze illik menteni HDD-re. De csomó dolog van, ami újra felépíthető ha újraindítod az alkalmazást, csak épp az időbe telne. Lehet itt gondolni tipikus cache-ekre, pool-okra, de akár egy rakás összetett akármire, aminek rakás konfigurációs fájlt meg osztályt be kell olvasnia, hogy elinduljon, stb, szóval nem két pillanat, amíg feláll a semmiből. Pont mert a PHP erre nem képes alapból/kényelmesen, nagyobb rendszereknél kezd kínos lenni, hogy minden egyes beérkező kérelemnél újra és újra felépít mindent a kályhától indulva.
"Az alap php-t nem tudod lefordítani, mint ahogy semmilyen scriptnyelvet nem tudsz alapból, mivel ezeknek pont az a lényegük."
A valamire való script nyelvek valamilyen köztes kódra fordulnak futás előtt, amit viszont el tudsz menteni ha nagyon akarod (pl. Python így is csinálta: py -> pyc). Általában nem akarod. De még cache-elheted is memóriában a köztes kódot, és akkor nem kell hozzá fájlokat gyártani.
[ Szerkesztve ]
) által elkövetett hibákat, ami igenis az ő idejükbe kerülnek a végén.
Új hozzászólás Aktív témák
it A technikai előzetes egyelőre Mac OS X-re és Linuxra tölthető le.
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- Vírusirtó, Antivirus VPN kulcsok
- Adobe Előfizetések - Adobe Creative Cloud All Apps, Photography Plan - 12 Hónap - NYÁRI AKCIÓ!
- Adobe Creative Cloud - 2024. 04. 05 - 2025. 04. 05-ig
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.