Honlapot? Bármivel! No de milyen áron? :)

Van egy ügyfél, aki kitalálta, hogy nem fizet honlapért, hanem majd ő megtanulja, hogy kell. Ő az ügyfél, biztos igaza van :D
Letöltött valami programot, amivel template-ekkel manipulálva le tudja generálni a honlapot (validátor szerint 12 Errors, 2 warning(s) ). Büszkén jelentette, hogy ő megtanult weblapot készíteni, mindösszesen 2 nap alatt (de jó neki, nem? De szerettem volna két nap alatt megtanulni)!
Mosolyogtam egy jót, mert hát mit is tudnék mást tenni (szörnyülködni semmi értelme, úgy sem értené meg, hogy ez azért messze van a weblapkészítéstől, s továbbra is az volna a véleménye, hogy ezért a "nulla" munkáért miért kérünk pénzt általában).

A poén kedvéért eljátszogattam. Illúzióim eddig sem voltak, ezután sem lesznek.
Elővettem hát egy office-t, 5 sort írtam benne és egy képet is beszúrtam.
Ugyanezt szépen valid xhtml-ben is megcsináltam, azonos kinézet, azonos betűcsalád, méret, stb.
Firebug és társai elő, méregettem:

Office verzió:
5 fájl (képpel együtt), 213k
(index fájl 25k, képet tovább tömörítette)

XHTML verzió:
2 fájl (képpel együtt), 185k
(index fájl 771bájt)

Maga a kép 184k.

Letöltések időtartama (onload, minden alkalommal újra töltve, azaz nem volt cache-elés):
Office: 132ms
XHTML: 74ms

Elég erős különbségek.
"Kedves ügyfelek! Ez csak 5 sor és egy kép. Semmi cicoma. El tudják képzelni, mekkora különbség adódik, ha még tartalmat és designt is teszünk bele?"

Álljon itt példának, lehet mutatni ügyfeleknek, ha kételkednek abban, hogy miért is érdemes megfizetni a kódert. Bár félő, hogy az "én majd megoldom" típusúnak ez sem lesz visszatartó erő...

Hozzászólások

Egyszer egy háziasszonynak elromlott a rádiója. Mivel mindennapos szórakozása volt, és szinte elképzelhetetlen volt a munka nélküle, ezért kihívott egy szerelőt. A szerelő rendben meg is érkezett, hümmögött, méricskélt egy keveset majd kihúzta magát és elkérte a háziasszony fakanalát. Az meglepetten odaadta várva mi fog történni. A szerelő egy határozott mozdulattal ráütött a készülék egyik "bigyójára" az legott megszólalt és működött.
- Nakérem! 500 Ft lesz a javítás! - mondta a mester.
- űűűű! De hát mi kerül ebben ilyen sokba? - sopánkodott a háziasszony. Akkoriban bizony ez nagyon nagy pénz volt.
- 1 Ft az ütés és 499 Ft az, hogy tudtam hová kell ütni. - felelte fölényesen a mester.
Na azóta is szorgalmasan "püfölik" a berendezéseket a háziasszonyok, sok-sok 499 Ft-ot megspórolva...

"megtanult weblapot készíteni, mindösszesen 2 nap alatt"

Nem mehet jól az üzlet az ügyfélnek, ha két napi produktivitása forintosítva kevesebbet ér, mint a weblap szakértővel való elkészíttetése. Vagy te kértél magas árat...

Egyik sem. Nem dolgozok drágán, de bagóért sem, ügyfél pedig nem keres rosszul (szerintem többet keres, mint én). Ez össz-vissz arról szólt, hogy ő meg akarta csinálni. Vagy egyszerűen csak az, hogy talált egy ilyen progit, s azt gondolta, biztos ilyennel csinálja mindenki, s ezért már sokallta az összeget.

A "12 errors..." baromi jó, Egy nem túlspílázott Drupal-os oldal 137-et, egy Joomla!-s viszont csak hatot produkált, Google website-ok közül is megnéztem néhányat, ott 80-100 hibát dob a validátor... Miközben valamennyi oldal működik, megnézhető, használható.

Ha olcsó az időd, akkor lehetséges. Ha viszont van 10E Ft egy komplett smink elkészítésére, amiben 2-3 konzultáció is bele kell, hogy férjen, nos akkor nagyon nem mindegy, hogy egy-egy módosítást milyen gyorsan tudsz megcsinálni, az ügyfélnek megmutatni. Nagyon meggyőző tud lenni, ha az üf. szeme láttára alakul a kinézet...

Visszakérdezek :)
Egy html faragásnál mennyivel több idő a szabványnak megfelelően beírni a kódot (gondolok itt az olyan szarvashibákra, mint amikor img-ből kifelejtik az alt-ot. Ok, nem okoz működésbeli hibát, no de akkor is.)? Főleg a mai IDE-kben, ahol jobbnál jobb kódkiegészítő funkciók vannak. S így is tud az ügyfél szeme láttára alakulni a kinézet.

Az, hogy az "alt=" szarvashiba, az szerintem ordenáré baromság, pláne a grafikus böngészők korában :-P Félretéve a tréfát, normális ember nem html-t, nem css-t farag elsősorban, hanem webes szolgáltatást épít, szétválasztva a küllemet (skin, smint, dizájn) a tartalomtól (cms), és már bocsánat, de orcán legyinti azt, aki a cms-be html-forrást óhajt tartalomként belapátolni.
Ha a tervezőeszköz és/vagy a cms nem követeli meg, hogy pl. a "kép beszúrása" párbeszédablak "alternatív elnevezés:" mezője ki legyen töltve, az az adott szoftver hibája, nem pedig azé a felhasználóé, aki megvette, megelégedéssel használja, és ezt a "szarvashibát", illetve a következményeit sohasem fogja sem ő, sem az oldal látogatója tapasztalni.

Valóban, de abból a szempontból azonos a kettő, hogy az oldalt valamilyen általános célú, html-oldalak generálására szolgáló szoftver hozza létre. Az egyik esetben statikus oldal(aka)t szolgál ki a webszerver, a másik esetben meg "röptében" készül az oldal. Mindkettő - a kényelem és az általános használhatóság miatt- tartalmazni fog "szemetet", sallangokat, és feltehetően sok olyan "hibát", ami a működést, az oldal kitalálójának az elképzelése szerinti megjelenést nem, vagy csak minimális mértékben befolyásolja.

Viszont sebesség tekintetében nagyon nem mindegy. Én azt gondolom, hogy egy nagyon egyszerű, bemutatkozó oldalnál, ahol a tartalom nem változik 1 éven keresztül, ágyúval verébre harc egy cms. Ugyanilyen megfontolásból a generátor is az. Végül is csak a céget ítélik meg a weblap alapján. Én meg szeretem, ha ügyfeleim a legjobbat kapják a felvázolt kívánalmaknak megfelelően (s most vonatkoztassunk el a fent jelzett ügyféltől, ő csak példa volt egy rossz szoftver használatára). De lehet, hogy én gondolkodok rosszul.

Egy-két, de még féltucat, ritkán változó oldal esetén valóban ágyúval verébre lehet egy cms - pláne, ha 2-3 éven belül nem akarnak továbblépni. Viszont ebben az esetben együtt kell élnie azzal, hogy saját maga nem nagyon fogja tudni a cége weboldalának a tartalmi részét módosítani - ami azért elvárás szokott lenni.
Az ügyfél nem a w3c valid plecsnit akarja a legtöbb esetben (azt sem tudja, mi az), hanem azt, hogy az oldal úgy nézzen ki, ahogy azt a dizájnerrel közösen (sok esetben hagymázas) álmaikban megjelent. Pont. Ha igényesebb, akkor a keresőoptimalizálást is kéri, meg némi izgőmozgó cuccot, formokat... És máris beficcen egy kis flash, esetleg Java, meg persze a péhápé (vagy Ruby, vagy a jó ég tudja, hogy mi...)

A látogatók döntő többségénél érdektelen, mint ahogy az "error"-ok igen jelentős hányada. Részben azért, mert nem veszi észre, részben azért, mert a böngészők javítják ezeket. Gondold végig, ha olyan browserek lennének, amik a hibák esetén azokat nem javítanák, hanem hibaüzenettel, széttördelt weblappal, meg nem jelenített képpel díjazák ezeket... A tartalom tulajdonosát és a felhasználók jelentős részét marhára nem érdekli, hogy mi a szabványos - az a lényeg, hogy a fontosabb böngészőkben úgy nézzen ki, ahogy a megrendelő kérte. A jelenlegi cms-ek, dizájner eszközök mellett a kutya sem fizeti meg azt, hogy te a meglévő eszközt (pl. Drupal) átvakarod úgy, hogy nulla hibát és figyelmeztetést adjon a w3c validáló cucca, és ezen felül természetesen a sminket is úgy alakítod ki, hogy az se tegyen keresztbe a w3c valid plecsninek.

Manapság, hogy a HTML-t nem mindössze webes dokumentumok, de kliensoldali webes alkalmazások (megfelelő API-kkal) létrehozására használjuk ez már kevésbé megfelelő hozzáállás annak ellenére, hogy a HTML5 továbbra is kellően flexibilis.

Ami a gyakorlatot illeti, a HTML5 még nincs véglegesítve (és számos részének tekintett webes technológia nem része), továbbá a W3C validátora nem kezeli megfelelően a beágyazott scripteket és számtalan széleskörben használt HTML taget obsoletenek tekint.

a keresoket erdeklik ezek a hibak, es innentol fogva a site tulajdonosat is. Ha valamit meg lehet csinalni szepen is (w3c compliant) (ugyanannyi munkaval), akkor aligha indok a trehanysagra, hogy "a megrendelot ugysem erdekli..."

Ja, hat legfeljebb "a jozsi" csak ennyit tud (2 nap utan), aztan sir, hogy a google-ben nem jut elorebb a 3. oldalnal....

Viktor az eletrol es a halalrol

Mennyi időbe tellene mondjuk a Drupal által generált oldalakat teljesen szabványossá tenni? És egy closed source cms esetén ugyanez? De nézhetjük a sminktervező/generáló programok produktumait is, azoknál is plusz munka a forrást átgyúrni, hogy az utolsó szabványügyi hülyeséget is kielégítsd. Ezek azok a plusz órák,a miket nem nagyon lehet eladni az ügyfélnek. Ráadásul utána ha bármi módosul (cms frissül, sminken kell alakítani) lehet nekiállni a javításokat portolni az új verzióra.

WordPress-hez szoktam a HTML Purifiert pluginként alkalmazni, mert a beépített input filterrel nem szabványos XHTML5 dokumentumok jöhetnek létre.

De én a perfekcionizmusom miatt alapvetően XHTML-t szoktam alkalmazni minden esetben.

Az input filtering persze mindenekelőtt a biztonságról szól, a webszabványokkal történő konformitás az interoperabilitás és SEO miatt lehet az üzemeltetőnek előnyös.

A hibák egy része valóban releváns a keresőknek (pl. képnél a hiányzó alt tag), de elhiheted, hogy a többsége nem. Pl. egy kereső magasról tojik rá, ha egy inline elembe blokk-elemet ágyazol, stb.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

amikor generatort irsz, akkor mennyivel kerul tobb idobe/penzbe beletenni pl. egy alt tagot az img tag-be? Felre ne erts, tolem a drupal, meg az osszes tobbi, amit hasznalsz/csinalsz maradhat olyan amilyen, csak egy keresem van: irjatok ki a drupal faq-ba, hogy ez bizony nem w3c compliant...

Viktor az eletrol es a halalrol

Ha te egy generatort irsz, akkor egyszeruen nem tudhatod, hogy kitolti-e a "tartalmi felelos" a vilag masik vegen vagy sem. De meg ha nem is tolti ki, akkor is ugy szep, ha ott van az alt="" tag.

De ha mindenaron analogia kell, akkor az az ertelme, mint amiert pl. smtp-nel a null sender eseten is szepen kiirjak, hogy mail from: <>, es nem hagyjak el ezt a parancsot...

Viktor az eletrol es a halalrol

Ismerősömnek kellene egy wp+design+domain+hosting. Van itt aki ezt a lehetőséget egy szegény kezdő vállalkozónak szánt árajánlattal megkínálná?

Szerintem neki (több okból is) wp lenne az ideális. Szerintem csak kellene neki egy link ahol vannak templatek és ott választ, majd a "kivitelező' a vállalkozásához igazítja.

Én azt mondtam neki, hogy hosting+domain 10e/év és szerintem 30e hufért találni a wp+design-ra embert.

Foleg, mert a skin az egy "bör" ami miatt a tigrisbol oroszlan lesz, mig a smink az... amitol az asszony talan kicsit elviselhetobb.
Szoval, a sminkkel nem az a baj, hogy magyar, hanem az hogy nem megfelelo kifejezes.
"Ezert tart itt ez a orszag..."
(azert, mert nem a megfelelo, es azert, mert "nem erdekel")

"a hivatalos magyar fordítás szerint a Drupal sminket használ"

Na ez szomorú. Kb. olyan, mint az excel magyarított függvényei.

Az a baj a smink szóval, hogy bár a jelentése hasonló, mégsem ugyanaz, mint az eredeti skin. Az angol skin jelentése pedig sokkal bővebb a magyar bőr szónál. A lényeg az, hogy a skin az valami olyasmit fejez ki, amire a magyarban nincs szó. Ekkor pedig úgy illik, hogy ahelyett, hogy ráerőltetjük az egyik magyar szót, inkább használjuk az eredetit. Még az is jobb, ha az eredeti szót magyarítjuk, ahogy erre számtalan példa van (pl. kliens, szerver, generátor, fájl, stb.), mert ekkor legalább az új szó valóban azzal a jelentéssel fog bírni, mint amivel az angol eredetije.

Már valahol írtam egyszer a scite fordításáról, ahol a "regular expression" kifejezést a fordító "szabályos kifejezés"-re fordította. Ezzel az a baj, hogy annyira eltér a fordított változat az eredetitől, hogy az eredeti teljes jelentéstartalmát elvesztette. Azaz amikor én először láttam ezt a fordítást, azt se tudtam, mit akar jelenteni. Az már csak extra, hogy a "regular expression" kifejezésnek van egy magyarított változata, a "reguláris kifejezés", ami pont azért született, hogy az angol kifejezést le lehessen úgy fordítani, hogy jelentéstartalma ne változzon meg.

--
Don't be an Ubuntard!

Főiskolai tanulmányaimban a formális nyelvek/fordítóprogramok órákról csakis "reguláris kifejezés" megnevezésre emlékszem, oktató nyomtatott jegyzetei szintén ezt a kifejezést használták.
--
"Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live." John F. Woods

Attól, hogy a többség a kg mértékegységet súly mértékegységnek tartja, az attól még tömeg mértékegység. A piacon elmegy, ha összekeveri valaki a két fogalmat, de egy előadáson, vagy egy publikációban már nem. Ugyanígy egy számítógépes szoftver esetében is elvárható, hogy a hivatalos megnevezést használjuk, és ne a köznyelvit.

Szerk: a go!-t se hívjuk magyarul menj!-nek.

--
Don't be an Ubuntard!

Aham, tehát a reguláris kifejezés szakkifejezés, a szabályos kifejezés meg nem szakkifejezés. Érdekes módon, olyan embertől, aki ne foglalkozna szakmailag informatikával,még nem hallottam a regexre azt, hogy szabályos kifejezés. Nem ismerik, fogalmuk sincs róla, mi az. A köznyelv ezt a dolgot nem ismeri. Ugyanúgy, mint ahogy nem ismeri a köznyelv azt a fogalmat sem, hogy "lefejtő fogazási eljárás." Ez pedig a gépészek szakkifejezése. Köznyelvi megfelelője nincs, mert aki találkozik ezzel a kifejezéssel, az a szakmában teszi. Te hány nyugdíjas szobafestőt láttál már arról beszélgetni, hogy melyik szabályos kifejezés-megvalósítás a jobb (pedig közben nem tudják, hogy hibásan beszélnek, és reguláris kifejezésről van szó)? Bevallom, én egyet sem.

A sztaki egyik munkatársának volt a webpage, homepage szavak magyarítására javaslata az ottlap. Nem ez lett az elterjedt, de ettől még természetesen nem mondom, hogy ez az ember számomra kevésbé értékes. Ugyanez igaz a te példádra is, csak fordítsuk meg: attól, hogy egy elismert ember, még nem biztos, hogy helyes, ahogyan a regexp kifejezést magyarítja.

"szerk.: Egyesek úgy irtóznak itt a szakkifejezések magyarításától, mint ördög a szenteltvíztől, pedig nem mindig rosszak azok."

Nem mindig, de ebben az esetben nagyon. Nem baj, ha a window-ot ablaknak nevezzük, a display-t kijelzőnek, a keyboard-ot billentyűzetnek, hiszen ezen esetekben a magyarítás megőrizte a szó eredeti jelentését (függetlenül attól, hogy az eredeti jelentés mennyire fedi azt a fogalmat, amire vonatkozik).

--
Don't be an Ubuntard!

"még nem biztos, hogy helyes, ahogyan a regexp kifejezést magyarítja."

Szerintem meg magyarítás esetén nincs olyan, hogy "helyes". Vannak különféle próbálkozások, aztán az idő eldönti, hogy elterjed vagy sem. Mindenesetre én is több helyen olvastam már a "szabályos kifejezés" formát, és meglepő módon még értettem is :) (Ugyanez igaz a "smink" esetén is.)

Ne kanyarodjunk el mindig! Innen indultunk:
"Mivel tudományosan az a helyes, egyszerű ez. A szabályos/szabványos kifejezés elnevezést azok használják, akik csak programozásilag ismerik azt a fogalmat, hogy regex, formális nyelvekről nem hallottak még soha."

Erre hoztam én 1 db ellenpéldát. Egyébként pedig, a szakkifejezések magyarítása esetén szerintem nincs "tudományosan az a helyes".
A nyelv változik. És ebbe az is beletartozik, hogy időnként a szakkifejezések is.

Igen, es pont a valtozaskor van az, hogy az emberek egyik fele (mint en is) a regi, masik fele (mint te is) az uj mellett foglal allast. Ilyen a vilag. En elmondtam a velemenyemet, leirtam, hogy miert regularis kifejezes a regularis kifejezes (a regularitas, regularis egy nagyon elfogadott szakkifejezes a matematikaban, ami kb. 100 eve nem valtozott). Ti megprobaltatok meggyozni egy olyan nem szakmai ervvel, hogy "a nyelv valtozik.". Ez innentol kezdve zsakutca, szakma vs. kozelet kozotti izlesvita.

Az eü.ben most is hemzsegnek, akkor amikor két szakember beszélget egymással. Azért, mert így egyértelmű nekik, hogy mire gondol a másik, amikor azt mondja, appendicitis.
A szabályos kifejezés nem egyértelmű: szabályos kifejezés az is, amit egy CFG ír le, hiszen szabályszerűen írja le az adott szó felépítését, az pedig jóval bővebb nyelvosztály, mint a reguláris kifejezések nyelvosztálya.

Eredetileg ugye az volt a kérdés, hogy a "regex" ékes magyarsággal "szabályos kifejezés" vagy inkább "reguláris kifejezés" lenne. Aztán kicsit elkanyarodtunk a reguláris kifejezés matematikai vonala felé. Nos ahogy Larry Wall írja, éppen azért használja a "regex" formát, mert a kettő nem ugyanaz. Most ezek után a "regex" helyett melyik a szerencsésebb, a "reguláris kifejezés" vagy inkább a "szabályos kifejezés"? Szerintem az utóbbi.

Kornai András cikke (amit te linkeltél) meg ponthogy az elméletről beszélt, és nem gyakorlatról, de ő azt hívta szabályos kifejezésnek. Most akkor szerinted melyikre kéne megtartani a szabályos kifejezés szót? Az elméletre vagy a gyakorlatra?
Magyarán hoztál két ellentmondó példát a saját véleményed alátámasztására.

Akkor szerintem itt az ideje egy reformnak: a matematikai fogalom legyen szabályos kifejezés, mert nem egyértelmű, összefoglaló fogalomként viszont megállja a helyét. A reguláris kifejezés meg vonatkozzon a regexp-re, mert az egy egészen konkrét fogalom (pontosabban tulajdonnév). Így a regexp továbbra is része a szabályos kifejezéseknek, de nem minden szabályos kifejezés reguláris kifejezés.

--
Don't be an Ubuntard!

Kornai csak egy _ellenpéda_ volt egy sarkos (csak olyanok használják...) állításodra. Nem azért hoztam fel, hogy érveljek a matematikában használatos reguláris halmaz/nyelvtan/kifejezés megváltoztatása irányában. De ezt már írtam egyszer. Mint matematikus, én is így tanultam, és eszem ágában sincs tovább "magyarítani". A legutóbbi link meg a "regex" magyarítása "szabályos kifejezés"-re témában lehet szakmai érv.

A saját véleményemet már leírtam párszor. Szerintem mint "regex" (amit a programozók használnak) magyarítás ez egyáltalán nem rossz, de úgyis az idő dönti el, hogy elterjed vagy sem.

Már leírtam egyszer, miért reguláris kifejezés a reguláris kifejezés. Azért, mert formális nyelvi leírása a matematika reguláris halmaz fogalmát használja fel. A szabályoknak és szabványoknak ehhez semmi köze, a formális nyelvek elmélete alkalmazott matematika/automataelmélet. Szabályos kifejezés bármilyen környezetfüggetlen nyelvtan szava is, hiszen jóldefiniált szabályok alkotják a nyelvet (mint minden formális nyelvét), de mégsem reguláris kifejezések, annál bővebb nyelvosztályt írnak le.
http://www.cs.uky.edu/~lewis/texts/theory/automata/reg-sets.pdf

A regexp az ékes magyar nyelven bizony reguláris kifejezés.

Szerintem pedig a szkin végképp nem jelent semmit és nem értelmezhető annak, aki nem tud angolul vagy nem ismeri az általad vázolt mögöttes tartalmat. Nem tartom jónak csak ezért egy újabb idegen, amúgy hangzásában is eltérő szót meghonosítani. Pláne, hogy a smink lefedi azt az értelmet, amit elvárunk tőle. Ez nem egy emberes döntés volt, elég sokat agyaltak rajta, mindenesetre véleményem szerint teljesen megfelelő, és sokkal jobb, mint a "bőr" vagy a "téma".

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)

"Szerintem pedig a szkin végképp nem jelent semmit és nem értelmezhető annak, aki nem tud angolul vagy nem ismeri az általad vázolt mögöttes tartalmat."

A skin (sic!) egy szakmai kifejezés ebben a szövegkörnyezetben, és nem csak egy egyszerű szó. Aki ezzel a szóval ebben a szakmában kapcsolatba kerül, és nem ismeri a jelentését, az nézzen utána. De csak az, hogy nem mindenki tud angolul, még nem lehet indok arra, hogy egy szakmai kifejezést bármi áron magyarosítsunk.

Az orvosok sem azért kommunikálnak latinul, mert így két idegen nyelvű orvos is tud kommunikálni (nem is tudnak egyébként szerintem), hanem mert nem minden latin kifejezésnek létezik világi nyelvű megfelelője. De egyik orvos sem várja el, hogy az ilyen kifejezéseket átültessék az ő nyelvükre, hiszen épp azért orvosok, hogy ezeket a kifejezéseket ismerjék. Ha pedig egy beteg kerül kapcsolatba ezekkel a latin kifejezésekkel, megvan a lehetősége arra, hogy utánanézzen, melyik mit jelent (vagy megkérdezheti az orvost, aki elmagyarázza neki).

"Pláne, hogy a smink lefedi azt az értelmet, amit elvárunk tőle."

Szerintem meg nem fedi le. A smink szó eleve egy nagyon behatárolt jelentéssel bír: az emberi (rendszerint női) arcra felvitt, az arc megjelenését befolyásoló vegyianyagok. Ebből kb. a "megjelenését befolyásoló" rész az, ami illeszkedik a skin szó jelentésére, azaz a smink szó jelentését túlzottan kibővítjük ahhoz, hogy fedje a skin szó jelentését. Szerintem egy jó magyarítás pont ennek fordítottja, azaz egy nagyon tág fogalmat alkalmazunk egy olyan fogalomra, ami az adott helyzetben egy szűkebb jelentéssel bír.

--
Don't be an Ubuntard!

Ezzel a skinnel az a baj, hogy már régóta beépült a nyelvünkbe.
Még csak halvány sejtéseim voltak, hogy mi az a számítógép, sőt még a számítógépes világ sem használta a skin szót (legalábbis arra, amire most használja), de már hallottam a skinheadekről. Pedig akkor még az angol tudásom kb. kimerült a help és save szavak ismeretében. Sőt már jó ideje szkinhedként is lehet találkozni vele.
A magyar villamosmérnökök körében már régóta ismert fogalom a skin-effektus. Nem sokan gondolhatják úgy, hogy előbb bőrt kell húzni a vezetékre, hogy ez a jelenség fellépjen.

Kedves Dacr: amíg nem érted meg ezt a vállalkozót, addig nem fogsz tudni neki eladni. Ha leszarod, akkor pedig ne keseredj és ne fordíts rá annyi energiát, hogy kiposztolod.

Valamit nem értesz. A téma alapvetően mérési eredményekről szól, a generátor szoftverek felesleges szemeteléséről, s azok hatásáról.
A vállalkozó honlapja a mi szerverünkön lakik, szóval tudtam neki eladni, nem kesergek.
De ha már mindenképpen ezen lovagolunk, s nem azon, hogy mennyivel jobb egy átgondolt kód, mint egy legenerált, teleszemetelt vacak, akkor legyen: ez a srác egy műszaki ember. Vállalkozása jól fut, simán megengedhetné magának egy nagyon komoly weblap háromszorosát is. Ennek az embernek nem is fogsz tudni eladni egy weblapot sem, még ha latba vetsz minden tapasztalatot, akkor sem. Ő meg akarta csinálni, s ennyi a lényeg benne. Nem is csináltam belőle problémát. Ha ő így akarja, így akarja.
S akkor most akár hozzászólhatsz a témához is, ha gondolod...

1. Gratulálj Neki a teljesítményéhez

2. Adj neki ingyen segítséget, hogy mire figyeljen oda. Mondd el neki, hogy te amikor kezdted mennyi hibát követtél el és ebből milyen károd származott.

3. Fejezd ki örömödet, hogy segíthettél neki és köszönd meg, hogy meghallgatott.

(Ezt mind megteheted írásban is. Szerintem a végeredmény nem várt meglepetést fog neked hozni vagy okozni, de minimum kurva jól fogod érezni tőle magad. )

A téma alapvetően mérési eredményekről szól, a generátor szoftverek felesleges szemeteléséről, s azok hatásáról.
És pont ez az a téma is, ami nem nagyon érdekelte. A generátor szoftverek pedig alapvetően szemetelnek, ez köztudott. Valamit valamiért.

Az átgondolt, "szemétmentes" kód előállítása időben mennyivel tart tovább? Mennyivel később tud a megrendelő használható produktumot átvenni? Mennyivel jobb, ha 10-15%-kal kevesebb a "fölösleges" szöveges tartalom annál, hogy pl. a jpg-képeket nem 100%-os, hanem mondjuk 78%-os minőségben, "convert -strip" használata után rakod ki?
Ez utóbbira érdekes példa: 400x300 körüli jpg, ebből 300x300 kivágva és 140x140-re kicsinyítve. Eredeti kép 43k, a 140x140-es 29. 78%-nál 23... Ha strip is megy rá, akkor mev valami négy és fél...

Egy tetszőleges sminkgenerátor+tartalomkezelő kombinációval készült weboldal mindenképp fog sallangot, általad "szemétnek" nevezett dolgokat tartalmazni. DE... Ennek folyományaként a smink igen gyorsan és fájdalommentesen cserélhető/módosítható, ha az eredeti, natív dizájn megvan, akkor a cms is cserélhető(!) hiszen néhány kattintással lehet x vagy y vagy akár z cms-hez is sminket csinálni belőle.

Igen, megcsinálta. Egy weblapot. Nem cms-t, nem webshop-ot, nem webes csoportmunka-megoldást, estébé. Műszaki ember, érdekli a téma, foglalkozik vele, és megoldja a saját igényeinek megfelelően a problémáját. Ha bővíteni, továbbfejleszteni kell, akkor lehet, hogy szolgáltatást is fog venni - az, hogy termékcsapda-e, vagy sem az a megoldás, amit most választott, az majd akkor fog kiderülni.

Ugyan már szarrágók mindig is lesznek. Nem kell rajta csodálkozni.

Velem az is megtörtént, hogy egy szórakozóhelynek szerettek volna honlapot készíteni, tartalomkezelő rendszerrel és egyebekkel. Mondtam egy összeget/ismerős lévén egy jóval nyomottabb piaci árat/, amire elkezdett hezitálni. Aztán talált valami webkontár józsit, aki photoshoppal slice-olt honlapot csinált, amibe csinált volna egy tartalom részt, de a képek köré nem volt definiálva border = 0 , ezért nyomot egy alap bordert a böngésző amiben szétcsúszott az oldal.

Mindezen tréningeztek 2 hetet, miután felhívtak telefonon, és közölték velem, hogy adják "a józsit" és mondjam meg neki, hogy mit csináljon hogy jó legyen a honlap...

És akkor ne legyen az ember felháborodva?

az ofisz jo arra, hogy szoveget szerkessz, meg tablazatokkal varazsolj, de katasztrofa, ha az Internettel osszefuggesbe hozhato dolgokra hasznalnad, mint pl. outlook levelezesre (amilyen okadek css bloat/blob/haszontalan fos definiciot ez bevag a level elejere, az valami kriminalis), vagy word html eloallitasara.

Deutsch: Ki a fasz az a Thomas Melia?

META NAME="GENERATOR" CONTENT="OpenOffice.org 3.2  (Win32)"

Lazán 2 MB az index.html (ez csak a kód, a képek még +15 MB mellette), a validator pedig 1153 hibát talál benne.

Úgy néz ki, nem csak az MS sz.rik magasról (ez esetben az OOo kb az exoszféra magasságából) a szabványokra/ajánlásokra...

A legnagyobb baj az, hogy orvos létére sz@rik a színtévesztőkre (az állatorvos is orvos). Példa rá a „Veszettség elleni védőoltás”-ról szóló rész. De az oldal több része is piros alapon zöld betűkből áll. Vagy fordítva. Emellett a kék alapon kék, és a zöld alapon zöld betűk is a kedvencei közzé tartoznak.

Bár a „A HONLAPOM ELSŐ TELJES BETÖLTÉSE A …” rész mindent visz! Ezt még a felette lévő, lila, illetve narancs alapon zöld sem tudja felülmúlni, pedig már az sem semmi.

Itt nem a generátor szoftverben van a legnagyobb hiba.

Sajnos nem csak a webre jellemző a gányolás. Vannak olyan szoftverek, amiket hasonlóan gányolnak össze, mint a te vállalkozód a honlapját. Kedvenc példám a xilinx ise, amiben a mingw még elmegy (hiszen ez alapvetően egy ide), de van benne eclipse, van benne jre (külön 32 és 64 bites), stb. A program fájljai 10,3GB-ot foglalnak (166968 fájl, 13553 mappa), aminek nagy része valószínűleg így is adatfájl, de állítom, hogy ennek töredéke is elegendő lett volna, ha teljesen egyedi, a feladatra optimalizált szoftvert készítenek.

--
Don't be an Ubuntard!