Eloszo:
Mindig is maximalista voltam, es a leheto legjobban akartam mindent csinalni. eppen ezert a web programozas sohasem vonzott, mert messze nem eroforrashatekony. En meg commodore-on kezdtem programozni, aztan PC-n folytattam assemblyben, most mikrokontrollereket programozok. Ezekben az a kozos, hogy szamit a meret! Nem mindegy hany biten abrazolsz egy szamot, vagy vegzel vele muveletet. Igazabol ez sohasem mindegy, de a modern fejlesztokornyezetek, es programnyelvek elfedik ezt. Persze aki igazan ert hozza az ott is tudja, hogy egy osszeadas, szorzas, tomb indexeles muvelet hogy fog vegrehajtodni a processzoron (es a memoriaban, processzor cacheben). Bar ez nem mindig egyszeru, hiszen ma a platformfuggetlenseg sokszor fontosabb, igy nem is tudjuk min fog futni. Sokszor nem is erdekli a fejlesztoket hogy gyors legyen a kod, majd vesznek erosebb gepet ala, ha kell, inkabb az a lenyeges, hogy gyorsan kesz legyen. Ma a gyors fejlodes (es gyors profit) vilagaban a fejlesztesi ido az elsodleges. Ami nem baj, hisz a fejlesztes penz, es ha nem igyekszenek akkor masok hamarabb kijonnek ugyanazzal a termekkel.

A Web fejlesztesnel is fontos a gyors fejlesztes, de az elsodleges szempont az elerhetoseg. Mindig, mindenhonnan! Mig mas programokat telepiteni kell addig szinte minden PC-n van web bongeszo. Igy minden ami a weben fent van az barhonnan elerheto. Az mas kerdes, hogy ha mobiltelefonon GPRS-en keresztul egy megabyte-nyi flasht es java scriptet kell letolteni az oldal betoltodesehez annek nem fog a felhasznaloja orulni. A bongeszopiacon eles verseny van a gyors javascript motorok teren is. Barmennyire jol is irnak meg egy webes alkalmazast, mivel az bongeszon belul futtatott, igy mindig lassabb eroforras igenyesebb lesz mint egy jol megirt helyi program. Persze a jol megirtat fontos hangsulyozni, mert vannak programok amik egymaguk ki tudjak donteni a gepet.
Talan ez az overload nem latszik meg egy mai gepen, ha csak egy-ket program/bongeszoablak fut. Viszont nalam allandoan tele van a kepernyo ablakokkal, felbehagyott feladatokkal (irodalomkutatas…) Csak az operaban 29 tab van most nyitva, a firefoxban legalabb negyven oldal kb 10 ablakban, es IE-ben is meg van nyitva vagy 10, meg google chromeban is kb 10. A firefox es az opera csak egy-egy processzt hasznal mindketto 250..500MB memoria+ ugyanennyi virtualis memoriahasznalattal. A firefox igen gyakran egy gigaig is felmagy (mem+VM), ed volt mar olyan is hogy 1GM mem, 1.3GM VM hasznalattal futott (.. jart.. setalt.. cammogott). Az IE is siman felment kozel 400MB VM hasznalatik tegnap.
Nem ritkasag hogy a taskbaron 50-nel tobb ablak van (3 sorban), de van kepernyomentesem ahol 69 ablak volt megnyitva. Az se ritka, hogy remote desktop es vagy virtual PC is az ablakok kozott van amin tovabbi proceszek futnak (de ez nem annyira lenyeges az eroforras hasznalat szempontjabol). A lenyeg, hogy hard core felhasznalo vagyok, es az oprendszert, bongeszoket nem ezekhez az igenyekhez tervezik.
A chrome peldaul buszken hangoztatja hogy minden ablakhoz/tabhoz sajat processt hasznal, igy az egyik kiakadas nam akasztja meg a tobbiben a betoltest… Aki elolvasta az elozo postomban szereplo “Pushing the Limits of Windows: Processes and Threads” cikket az tudja, hogy a sok processnek megvannak a hatulutoi. Tegnap pl a chromeban tobb masodpercet kellett varnom hogy barmit reagaljon, vagy betoltodjon a google maps oldal (pedig ugye azt irja, hogy hasznaljak chrome-ot mert azzal gyorsabb). Persze ez azert van mert a bongeszok es egyebek (visual studio…) annyi memoriat foglaltak, hogy a ket giga rendszermemoria nem eleg, es szinte a teljes memoriajat kiswappeli page fileba, majd onnan probalja visszatoltogetni…
Csak a kontraszt kedveert a uTorrent kozel ezer torrentel a listajan (kb 50 fut is) (tudjatok linux image-ek) kevesebb mint20+40MB-ot hasznal! (a memoria meretek task manager adatok, a VMMap szerint se hasznal 65MB VM, 16MB WS-et) Pedig forgalomban is ez bonyolitja a legtobbet (tobb szaz giga). A FAR Managerbol szokott futni 5..10..20 db es csak nehany mega memoriat hasznal (colorer+autocomplete.. pluginekkel)

Szoval nagyabol ennyi mar sok is a webes alkalmazasok, es weboldalak eroforras hatekonysagarol. Teny, hogy rendkivul kenyelmes, es a vilag is a mobilitas fele megy.
Ha viszont web oldalt tervezunk, akkor tervezzunk jot. Itt kapasbol ket reszre lehet osztani: a kliensben megjeleno oldal, es az azt generalo szerverre. aztan azokat tovabb: webszerver, adatbazis szerver, cgi/php/asp(x)/jsp… eloallito program/script. php eseten lehet gyorsitan cache megoldasokkal, hogy ne keljen minden hozzaferesnel ujraforditani/ertelmezni a scriptet pl. eAcceleratorral. Klieons oldalon htlm, java script, css, flash, java applet… megoldasok kozul lehet valasztani, kombinalni… Ill. szinten ide tartozik nem utolsosorban, hogy hogy fog az oldalkinezni, hogy lehet hasznalni. (ez ezert kezdtem el irni ma)

(web) Design. Meg koli alatt olvastam webdesign pszihologiat. Nehany inkek kint is van az oldalamon http://szikraistvan.no-ip.info/. A kedvencem a regi HTML Hell page. Ezek magaval az oldal megjelenesevel foglalkoznak.
Itt van meg par link:
Top Ten Mistakes in Web Design
113 Design Guidelines for Homepage Usability
Guidelines for Visualizing Links
Web 2.0 Can Be Dangerous
Feature Richness and User Engagement
The Need for Web Design Standards
The Power of Defaults
Site Map Usability
Training Wheels User Interface
Information Foraging: Why Google Makes People Leave Your Site Faster
Top Ten Guidelines for Homepage Usability
Deep Linking is Good Linking
The Canonical Intranet Homepage
The Difference Between Intranet and Internet Design
Growing a Business Website: Fix the Basics First
Fancy Formatting, Fancy Words = Looks Like a Promotion = Ignored
Eyetracking Research
Show Numbers as Numerals When Writing for Online Readers
How Little Do Users Read
How Users Read on the Web
Does the Internet Make Us Lonely?
Banner Blindness: Old and New Findings
The Ten Most Violated Homepage Design Guidelines
Writing for the Web
…

Szinten a design resze az ami mogotte van, vagyis maga a kod. Egy programot/oldalt rengeteg fele keppen meg lehet irni. En azt szeretem ha a forraskod majdnem olyan latvanyos mint maga a megjelenitett kezelofelulet 🙂
Persze egy webes oldalnal nem art utana egy minimalizalot raengedni (html, js, css), hogy minnel kevesebb adatot kelljen a halozaton atkuldeni. Ezen persze segit ha a szerver es a kliens tamogatja a gzippel tomoritett adatatvitelt.
A htmlben, css-ben, es java scriptben lehet hosszu ertelmes classokat, es id-ket hasznalni, vagy rovid ertelmetleneket is. Ha kesz vagyunk (vagy legalabbis azt hiszuk), akkor lehet hogy erdemes a deployment szakaszaban a kiszolgalora mar minimalizalt verziot felrakni. Nem utolso sorban az oldal visszafejteset is neheziti (ha ez cel), viszont ha szerkeztheto, adatbazisbol generalt css-eket hasznalunk, akkor erdemes megtartani az ertelmes classokat, id-kat.
Maga az oldal megjelenes strukturalasara is tobb megoldas van. Pl. a phpBB 2.x meg tablakat hasznalt a design elemek elhelyezesere, a phpBB 3.x, a wordpress mar div elemekkel alakitja ki a kinezetet.
Table Layouts vs. Div Layouts: From Hell to… Hell?
in-line vs. kulonallo javascript/css file…
Yahoo!’s Rules for High Performance Web Sites.

Technologiak, eszkozok:
en.wikipedia.org/wiki/Minification_(programming)
code.google.com/p/minify/