ugrás a tartalomhoz

Frontend fejlesztő interjú kérdések

Bártházi András · 2012. Feb. 20. (H), 08.26

Interjúztatni nem könnyű, hiszen az interjúalanynak nem csak a szakmai tudását kell figyelembe venni. Az Arkon tavalyi kérdőíve például olyan volt, hogy csak nagyon kevesen tudták hibátlanul kitölteni, így az is kijött, hogy a kudarcot hogyan éli meg valaki, stresszhelyzetben hogyan viselkedik. Darcy Clarke is egy ilyen kérdéssort rakott össze – a legtöbb választ illik ismerni, amit nem ismertünk eddig, annak meg érdemes utánaolvasni.

A frontend fejlesztőknek összeállított kérdések között csupa gyöngyszemeket találni, melyek jól jönnek akkor is, ha interjúkérdéseket állít össze valaki, hát még akkor, hogyha állásinterjúra készül.

Néhányat kiemelnék:

  • Van Twitter accountod? – lehet hülyén hangzik a kérdés, de mi is azt figyeltük meg, hogy az aktív Twitter felhasználók kommunikatívabbak, az újdonságok és trendek iránt sokkal fogékonyabbak, mint akik nem használják a szolgáltatást, ez pedig egy nagyon fontos szempont.
  • HTML 5 esetében mire jók a "data-" kezdetű attribútumok? – érdemes tisztában lenni azzal is, hogy a jQuery pontosan hogyan kezeli ezeket a tulajdonságokat.
  • Mi az a closure és hogyan/mire célszerű használni? – hát még ha valaki azt is tudja, hogy a háttérben hogyan működik! :)
  • Mikor használunk document.write()-ot? - soha.
  • Kalóz vagy nindzsa?a kő-papír-olló már nem menő!

Ti milyen interjú kérdéseket tennétek fel, tudtok hasonló listákat egyéb területekhez (backend fejlesztés, üzemeltetés, tesztelés stb.)?

 
1

Pont most használtam a

inf3rno · 2012. Feb. 20. (H), 08.38
Pont most használtam a document.write-ot. Tesztelni akartam valamit, aztán nem akartam alert-et használni... :-D (Persze élesben tényleg gáz...)

Ez a kalóz vagy ninja teljesen beteg :D
2

Nem élesben is gáz

Bártházi András · 2012. Feb. 20. (H), 08.39
Használj console.log()-ot.
3

Igazából nem sűrűn használok

inf3rno · 2012. Feb. 20. (H), 08.42
Igazából nem sűrűn használok ilyen kiírási módokat. Ha js-t csinálok, akkor az vagy olyan rövid, hogy nem hibázom benne, de ha mégis akkor kivételt dob, vagy pl. qunit-ot használok a tesztekhez. Sosem használtam a console.log-ot, az alert-et meg szökőévente egyszer, amikor valami nagyon nem stimmel, és nem tudok rájönni, hogy mi a gond vele.
8

Én a firebug és a FirePHP

nova76 · 2012. Feb. 20. (H), 09.08
Én a firebug és a FirePHP nélkül abbahagynám a szakmát. Akkor inkább a mekiben felszolgálnék, ha felvennének. Az alert nem ugyanaz mint a console.log, hiszen az utóbbi egy html elemet, vagy objektumot is visszaadhat, amit utána objektumként, html elemként tudsz vizsgálni.
9

Használok firebug-ot, ha erre

inf3rno · 2012. Feb. 20. (H), 09.12
Használok firebug-ot, ha erre vagy kíváncsi. :-) firePHP-ről fogalmam sincs, hogy micsoda ;-))))

szerk:
Utánanéztem, érdekelne, hogy mi az az extra funkció, ami miatt nélkülözhetetlen. :D
13

Mondjuk például használsz egy

nova76 · 2012. Feb. 20. (H), 10.00
Mondjuk például használsz egy keretrendszert, ahol a lekérdező osztályodba beleteszed, hogy tegye ki magát az sql parancsokat egy táblázatba. Vagy egy teljes tömböt szeretnél kitenni anélkül hogy a designt elcsesznéd var_dumppal. Ozstályt is ki lehet de csak ha nem túl nagy (mondjuk var_dump esetén is gond, ha nagy). És ügye ez ajax lekéréseknél is működik. Meg lehet lenni nélküle, de körülményes és én már nagyon megszoktam.
120

Ezek szerint, ha a kezedbe

Pethical · 2012. Feb. 28. (K), 02.15
Ezek szerint, ha a kezedbe nyomok egy macet egy safarival, és azt mondom, azon szétesik az oldal, és mondjuk pont egy js által futtatott animáció okozza a dolgot, és nem is pakolhatsz fel a szgépemre mindenféle kiegészítőt, mert ne már, meg safarira nem is nagyon van, akkor azt mondod, hogy bocsi ügyfél, feladom, elmentem a mekibe dolgozni, vagy beírod oda szépen, hogy alert, vagy, hogy document.write? :-) Persze lehet ezt úgy is, hogy beraksz egy plusz elemet és abba logolsz, getElementById() és innerHTML-el, vagy $().html()-el, de ezzel meg lehet gyorsabb lesz.
--------
Sose értettem minek debugger meg FirePHP a php-hoz. Gyönyörűen megmondja mi a baja, vagy az ember képébe, vagy a logba. Persze olykor szívat, olyankor is ki lehet ám íratni sok dolgot. Pl. erre van a logolás, a html comment, a headerbe is szinte azt küldesz amit akarsz.
121

Ajaxos alkalmazás

Hidvégi Gábor · 2012. Feb. 28. (K), 07.53
Ajaxos alkalmazás fejlesztésénél, főleg ha nem HTML-ben történik az adattovábbítás, nagyon jó a FirePHP, mert a konzolon azonnal látod, mi a hiba, és nem kell egy csomó időt a logok tanulmányozásával eltölteni.
122

A "csomó idő" kb 5 sec

inf3rno · 2012. Feb. 28. (K), 10.05
A "csomó idő" kb 5 sec szokott lenni, amíg frissítem a logot és megnézem a hibaüzenetet. Nekem xdebug és firephp sem szokott kelleni debuggolásra, teszteket írok helyettük, meg megnézem az error.log-ot, ha olyanom van. Ha rendesen dobálod a kivételeket a kódodban, akkor nem fog váratlan meglepetés érni...
123

A FirePHP segítségével

Hidvégi Gábor · 2012. Feb. 28. (K), 11.46
A FirePHP segítségével többdimenziós asszociatív tömbök tartalmát is meg lehet nézni formázottan.
124

Pár nappal ezelőtt

zzrek · 2012. Feb. 28. (K), 14.53
Pár nappal ezelőtt próbáltam ki a firePHP-t, mert ugyan hallottam már róla ezelőtt is, de itt valaki javasolta. Megtetszett, tényleg kényelmes a használata. Nem csak hibakeresésre, de "mi lenne ha" kipróbálásokra is kényelmes.
126

Nekem fejlesztés közben a

deejayy · 2012. Feb. 29. (Sze), 10.04
Nekem fejlesztés közben a második monitoron ott figyel a
$ tail -f system.log
:)
125

Ehhez pont elég a net

Pethical · 2012. Feb. 28. (K), 21.24
Ehhez pont elég a net fülecske a firebugban. A json_encode csodákra képes..., már, ha json-al dolgozol. Ha nem, akkor meg megint ott a <!-- -->. Ha exceptiont dob, vagy error van, akkor is látod, hogy azt kaptad a phptól.
Egyébként bizonyára sok emberkének hasznos, és használja is, akinek az. Azonban nem vennék fel olyan programozót, aki egy bizonyos eszköz meglététől függően tud programozni.
127

Más meg nem jelentkezik...

Gixx · 2012. Feb. 29. (Sze), 13.22
...olyan helyre, ahol követelmény a fakír szék, az ablaktalan füstös iroda, az 50Hz-en vibráló Hercules monitorok és a vi használata :D

Mindent lehet sarkosítani. Sose egy eszköztől függően tud valaki/nem tud programozni, hanem ezek a hatékonyságnövelés célozzák. Bár én a google előtti időkben tanultam a programozást, mégse sírom vissza az online referencia, a stackoverflow és az PHP IDE előtti időket, ahol már a syntax highlightra is mindenki habosra verte, mert micsoda nagy dolog volt. Sőt nem is mennék már olyan helyre, ahol nincs lehetőség a megszokott eszközökkel/módszerekkel dolgozni.

Nem attól leszel fasza gyerek, hogy valós időben dekódolod fejben a mátrix folyamot. Ha te úgy vagy hatékony, akkor úgy vagy. Ha valaki a FirePHP-val az, akkor meg azzal. Ezektől függetlenül lehetsz őstehetség és Gáz Géza is.
128

+1

Poetro · 2012. Feb. 29. (Sze), 13.38
+1
129

...olyan helyre, ahol

Pethical · 2012. Feb. 29. (Sze), 22.59
...olyan helyre, ahol követelmény a fakír szék, az ablaktalan füstös iroda, az 50Hz-en vibráló Hercules monitorok és a vi használata :D

Egyiket sem mondtam, és ezek közül egyik sem igaz. Kifejezetten jó körülmények vannak, mindent megkap a fejlesztő amit igényel a kényelmes és hatékony munkavégzéshez. Legyen az szoftver, vagy hardver.

Akkor most magamat idézem:
Egyébként bizonyára sok emberkének hasznos, és használja is, akinek az.

Látom nehezen megy a szövegértés, így fordítom: Ha tetszik, és hasznosnak találod, használd.
És újra magam idézem:
Azonban nem vennék fel olyan programozót, aki egy bizonyos eszköz meglététől függően tud programozni.

Azaz nem kell kőbaltával barlangfalra vésni a programot, de, ne jelentsen már problémát, ha valamit olyan helyzetben, környezetben kell megcsinálni, ahol nem áll minden megszokott dolog rendelkezésre.
És most idézem amire az előző mondatot írtam:
Én a firebug és a FirePHP nélkül abbahagynám a szakmát


És most te jössz. Ülj le szépen, és olvasd el újra az összes általános iskolás kötelező olvasmányt, majd írj róla olvasónaplót, hogy megtanuld értelmezni a szöveget.

Nem attól leszel fasza gyerek, hogy valós időben dekódolod fejben a mátrix folyamot. Ha te úgy vagy hatékony, akkor úgy vagy. Ha valaki a FirePHP-val az, akkor meg azzal. Ezektől függetlenül lehetsz őstehetség és Gáz Géza is.

Valóban nem attól, de függjünk már ennyire az eszközöktől! Ha valaki nem tudja ugyanazt leprogramozni FirePHP és IDE nélkül (persze lassabban), amit azzal, akkor nem neki való a szakma. Akkor tanuljon valami mást. Én is használok sok dolgot, kiegészítőt, de nem esek kétségbe, ha valamit úgy kell megcsinálni, hogy nincs esetleg. Nem programozok vi-ben, de előfordul, hogy bizony szükség van rá, hogy valamit úgy csináljak meg, mert mondjuk olyan jogosultsági beállítások vannak, amik megnehezítenék az sftp-t, de ssh-val és sudoval meg simán szerkesztek. Egy 50-100 soros kódért meg nem fogok 6x jogosultságot állítani, meg másolgatni.
130

Bocsánat

Gixx · 2012. Már. 1. (Cs), 08.06
Jaj én nem megsérteni akartalak, vagy ilyesmi. Bocsánatot kérek, ha így történt. Komolyan :)

Ugyanakkor ha a szövegértésemmel baj van, akkor visszahivatkoznék az idézeteidre, és telefonos segítséget kérnék a helyes értelmezésben.

Én a firebug és a FirePHP nélkül abbahagynám a szakmát


kontra

És most idézem amire az előző mondatot írtam:
"Azonban nem vennék fel olyan programozót, aki egy bizonyos eszköz meglététől függően tud programozni."


Meglátásom szerint a két dolognak semmi köze egymáshoz. Az első az akarásról szól, a másik a tudásról. Tény, hogy ha az akarás tudással is párosul, abból csak jó dolgok születnek. Na jó, az atombomba kivétel :D De itt most nem erről van szó.

A tévedés és a szövegértési probléma jogát mindenesetre fenntartom, nem vagyok mindentudó, komoly esély van rá, hogy én értelmeztem félre a szövegeket. Ez esetben kész vagyok egy kijelölt célpont mellett találkozni a 42 szűzzel. :D

De mindenféle korteskedés nélkül, pusztán átérezve Nova76 mondanivalójának kvintesszenciáját, úgy vélem, hogy ő csupán abbéli érzését próbálta kifejezésre juttatni, hogy eddig ő a ekével túrta a földet, de aztán kapott egy szép traktort, és ezért bátorkodott megjegyezni, hogy ő biza' traktor nélkül inkább elmegy almát szedni, de újra ekével nem fog többet földet túrni. Csuhajja :)

Szerintem. De tényleg, ha belegázoltam és/vagy hatáskörtúlléptem, akkor bocsánat.
131

Ez esetben kész vagyok egy

inf3rno · 2012. Már. 1. (Cs), 15.58
Ez esetben kész vagyok egy kijelölt célpont mellett találkozni a 42 szűzzel. :D

:D :D :D
132

???

Pepita · 2012. Már. 1. (Cs), 17.20
Há' én ezt má' követni se bírom, megyek inkább szántani. Traktorral és ekével, gyk.

Egyébként - szerintem - az igazság inkább a te oldalad felé van, de ti tudjátok (és szerintem nem voltál sértő sem).
133

Fogjuk be a teheneket, aztán

inf3rno · 2012. Már. 1. (Cs), 23.06
Fogjuk be a teheneket, aztán hejj Sári, Riska, Böske ne! (ahogy öreganyám mondaná) :D Bírom ezt a szántásos hasonlatot XD

Egyébként én is vele értek egyet, az alapelvek sokkal fontosabbak, mint az, hogy éppen milyen szoftvert használsz.
134

Ebben az esetben elnézést

Pethical · 2012. Már. 2. (P), 00.13
Ebben az esetben elnézést kérek a szövegértés miatt, félreértettelek! Elég fáradt voltam mostanában és ingerült emiatt, ha ez mentség lehet esetleg.

Szívjuk majd el a békeszüzeket valamikor almakaszálás után a szántóföldön! :D
135

Részemről nincs harag

Gixx · 2012. Már. 2. (P), 09.39
:)
136

+1

Pepita · 2012. Már. 2. (P), 19.57
Szerintem többször is, mindkettőtöknek.
23

Bölcsebb...

Bártházi András · 2012. Feb. 20. (H), 14.24
Ha inkább backend fejlesztőnek gondolod magad, akkor ne reklámozd, hogy tapasztalatlan vagy frontend fejlesztésben. :) Ha frontend fejlesztőként úgy gondolod, hogy document.write(), akkor pedig _tényleg_ olvass inkább utána. "document.write evil" a keresőkifejezés.
25

Backend-et jobban szeretem,

inf3rno · 2012. Feb. 20. (H), 15.42
Backend-et jobban szeretem, mert azt nem kell 3 féle böngészőre megírni... Nem hinném, hogy frontend terén tapasztalatlan lennék, 1997-ben kezdtem el javascripttel foglalkozni, azért 15 év csak elég tapasztalat...
26

There's actually nothing

Hidvégi Gábor · 2012. Feb. 20. (H), 15.56
There's actually nothing wrong with document.write, per se. The problem is that it's really easy to misuse it. Grossly, even.
Innen. Arra, hogy kiírjon egy stringet, jó, bár persze vannak ennél valóban jobb hibakereső eszközök.
27

Nem jó

Bártházi András · 2012. Feb. 20. (H), 17.02
Az első választ is olvasd el onnan:

document.write does really horrible things to the html parsers, and is only "extremely compatible" in simple cases.


Nem, szöveg kiírására sem túl praktikus, eléggé bad practice. Ha a HTML dokumentum már betöltődött, akkor pl. törli az oldalt. Ragozhatjuk még, de ahogyan nem használunk <table>-t layoutra, úgy nem használunk document.write-ot sem.
28

Hát igen, ez már tényleg

inf3rno · 2012. Feb. 20. (H), 18.11
Hát igen, ez már tényleg kifutott technológia ugyanúgy, mint a table, de ettől még nem hibás, csak egyszerűen már nem ajánlott, mert már vannak nála sokkal jobb megoldások.
29

Így van

Hidvégi Gábor · 2012. Feb. 20. (H), 18.29
Mindig a legcélszerűbb eszközt kell használni.
4

:-)

zzrek · 2012. Feb. 20. (H), 08.58
Én nem Twitterezek, elég nekem az itteni csirip szolgáltatás.
(Nem hinném hogy ne lennék fogékony az újdonságokra, és kommunikatív is vagyok, látod, ide is posztoltam :-)
6

;-)

inf3rno · 2012. Feb. 20. (H), 09.06
;-)
5

Sarokpont

janoszen · 2012. Feb. 20. (H), 09.03
Ami nekem egy nagyon komoly sarokpont a frontendesnel, hogy hajlando / kepes legyen egy olyan kodot eloallitani, ami szabvanyos, ne otletszeruen kodoljon. Nezzetek meg peldaul a dotroll.com-on a publikus feluleten levo formokat. Mind kodbol van generalva es a sitebuilder kivaloan alkalmazkodott ehhez, aminek eredmenye keppen a backend oldalon barmikor elo lehet allitani meg egy formot anelkul, hogy a sitebuildernek nagyon varazsolnia kelljen. Nem tudom, ezt hogy lehetne jol megfogalmazni interjuban.
7

Azt hiszem kód

inf3rno · 2012. Feb. 20. (H), 09.07
Azt hiszem kód újrahasznosításnak hívják, esetleg jól karbantartható legyen a kódja? :-)
14

Inkább CRUD generátornak

nova76 · 2012. Feb. 20. (H), 10.03
Inkább CRUD generátornak (symfonyban például admin generátornak) hívják. A lényege hogy legenerálok egy modult, aminek lesz egy szerkesztés, egy új felvitel, egy törlés és egy táblázatos megjelenést végző része. Ha egy sitebuilder lenne olyan jó fej, hogy legalább ne hetente változtasson a stílusán, akkor ezt a generátort nem kell hetente elővenni, vagy átalakítani akár egy-egy projekten belül is többször. Vagy amit Symfonynál szoktunk, hogy a generált kódot kiemeljük a cache mappából és átírjuk. Onnantól kezdve viszont nehezebben tartható karban a kód. Bármilyen változtatás újabb fájlok kiemelését, vagy a meglévőek módosítását jelenti. Ráadásul a vége sokszor az, hogy inkább a backend fejlesztő átírja a css-t, ami szerintem amellett hogy nem gazdaságos, nem is lesz olyan tökéletes (hiszen elvileg kevésbé ért hozzá) és a legrosszabb, ha a sitebuilder nem kapja vissza és tovább fejleszti a saját verzióját.
15

Ha egy sitebuilder lenne

Hidvégi Gábor · 2012. Feb. 20. (H), 10.07
Ha egy sitebuilder lenne olyan jó fej, hogy legalább ne hetente változtasson a stílusán, akkor ezt a generátort nem kell hetente elővenni, vagy átalakítani akár egy-egy projekten belül is többször.
Lehet inkább külön kéne választani az adatokat a megjelenésüktől. És akkor a sitebuilder azt csinál a html-ben, amit akar, de a te munkádat egyáltalán nem fogja érinteni.
37

Szerinted a sitebuilder

nova76 · 2012. Feb. 20. (H), 22.45
Szerinted a sitebuilder tevékenysége hová ér el? Az is az Ő feladata hogy az adatokat az adatbázisból lekérje? Nem tudom Te hogy csinálod, szívesen tanulnék tőled, ha ezzel időt spórolok. Kicsit talán ironikusan vagy nagyzolósan hangzik ez most tőlem, de én tényleg teljes alázattal állítom ezt.

Eddigi tapasztalataim szerint a sitebuilder feladata odáig terjed ki, hogy fogja felvágja HTML-be az designer terveit. Vagyis többnyire lorem ipsumokkal telepakolt HTML fájlokat kapok. Ezek között lesz táblázat,form és lista, és szét tudom kapni annyira, hogy akármennyi oldalt le tudok belőle gyártani. Általában van egy header, vannak jobb, esetleg bal oldalon dobozok és van a tartalom doboz és van lábléc. Általában ezekből áll egy oldal. Ami rám tartozik backend fejlesztőként, az többnyire a tartalom rész.

Lépjünk tovább, legyen egy egyszerű feladat, a regisztráció. Regisztráció általában egy form. De lehet több regisztrációm, például cégeknek, partnereknek és végfelhasználóknak. Mindegyiknek más más mezőket kínálok fel. Sőt nemcsak mezőket hanem kapcsolt táblák mezőit is. Ezt nálam egy form osztály végzi, ahol a formnak nyilván van formatter osztálya is. Ezt a részt átvállalhatja a sitebuilder is, de ez már bizony PHP és nem HTML. Természetesen az is egy állapot, hogy Ő elkészíti a formokat htmlben, csakhogy nekem van egy generátorom, ami a táblakapcsolatok alapján elkészíti a baseform osztályt, ahol az összes mező fel van fűzve egymás mögé. Egy konfigurációs fájlban pedig be tudom állítani hogy melyik form osztály jelenítse meg az aktuális formot. Így néhány származtatás és azokban a származtatott osztályokban egy useField paranccsal felsorolom a kívánt mezőket, vagy épp beágyazott formokat.

Ezzel szemben egy sitebuildernek ugyanez mitől lenne könnyebb? Ügye egy csapatban vagyunk, attól hogy a munka nála csapódik le, a csapat nincs előrébb.

Neki egyszerű dolga van, amikor egy másik projekten másik ötlettel áll elő és ami eddig dív volt, az mostantól p elem lesz. Ha ezt teszi, akkor nekem minimum egy form formatter osztályt kell feleslegesen kreálnom. De milyen megvilágosodásból adódik az, hogy amire eddig egy div megfelelt, az mostantól már csak p elemmel jeleníthető meg?
38

Rosszúl csinálod

zsoc · 2012. Feb. 21. (K), 00.12
Azért álljon meg egy picit a menet. :)

Ahhoz, hogy egy dizájnból valaki HTML + CSS párost gyártson, már egy Photoshop is elég. Persze a minőség az közel sem lesz ugyanaz, mintha valaki értő kézzel megcsinálja, de van akinek megteszi...

Ha Te azt mondod, hogy dolgozzak azokkal a "Lorem ipsum dolor" szövegekkel tarkított elemekkel, amiket a dizájner beleszórt (amikor már az is eleve probléma, hogy a dizájner nem kapott alap adatokat a dizájnhoz) a feldarabolandó dizájnba, akkor te nyilván számolsz azzal is, hogy a dizájn közel sem fogja azt a képet tükrözni, amit az alkotója, és a megrendelője elképzelt.

És nyilván azzal is, hogy _neked_, aki backend fejlesztőnek vallja magát, még sokkal több munkaóra lesz kiegészíteni, vagy módosítani a CSS paramétereket.

Szerény véleményem szerint, ha valaki tisztességes, és jól összerakott sitebuildet akar, akkor az nem áll meg ott, hogy X, vagy Y elvégezte a rászabott feladatot, hanem a project végéig együtt kell működnie a "csapatnak".

Az meg egy elég szép kis vágyálom, hogy "egyszer megcsinálom, aztán soha többé kell hozzányúlni..." Ilyen egész egyszerűen nincs. :)
49

Az a bajom hogy mindketten

nova76 · 2012. Feb. 21. (K), 10.30
Az a bajom hogy mindketten (Poetroval) elzárkóztatok a példámtól :-) Többféle regisztrációnál maradjunk.
Mitől lesz hatékonyabb a cég, ha a sitebuilder feladata lesz a megjelenés a projekt végéig? Tehát az én általam használt (Symfony által kreált) formok nem használhatóak. Tehát a templatek generálásáról nem is beszélhetünk. Hogy megy ez nálatok? Pedig általában egy form nem szokott túl bonyolult lenni, csak egy alkalmazásban van vagy 50-100 vagy több.

Az előre gyártott komponensek meg már tényleg betesznek egy zabolátlan sitebuildernek. Azokhoz általában van egy csomó elkészült template is. Most azokat is átírogatja?

Az meg egy elég szép kis vágyálom, hogy "egyszer megcsinálom, aztán soha többé kell hozzányúlni..." Ilyen egész egyszerűen nincs. :)

Ilyet nem is állított senki. De épp ezért nehéz ezt a sitebuildernek megoldani. De ügye nem azt nehéz megoldani, hogy van egy div, amiben van a label és az input mező és ezt szépen egymás alá leírjuk egy konfigurációs állomány szerint? Szépen jelölve (class, id) hogy mi van benne a divben. Az a form elem szépen formázható. Ezen egyszer és mindenkorra túl lehet tenni magunkat. Mint ahogy azon is, ha ezt egy accordion vagy egy tabos megjelenítéssel csoportosítjuk. Ezt nem kellene minden egyes projektnél külön legyártani. Most teljesen mindegy, hogy a sitebuilder gyárt külön másikat, vagy én készítek külön másik template generálót. Az azért elvárható hogy egy projekten belül a formok legalább hasonlítsanak egymásra a felhasználó szemével.

A javascript sem hiszem hogy mindig rá tartozna. Most vegyünk egy autocompletert. De ne egy egyszerűt, hanem mondjuk töltse ki a teljes formot. Például egy szállodai szoftver, aminél a név kiválasztásakor a törzsvendég/elutazott vendég adatbázisból felkínáljuk a vendég összes adatát. Most nekem egyszerűbb kitennem magát a törzsvendég objektumot a templatebe, ahelyett hogy létrehozok valami tömböt. De nyilván a törzsvendég objektum nem fogja tartalmazni a teljes adatmennyiséget, esetleg lesznek kapcsolt adatok, tehát nekem úgymond a szájába kell rágnom hogy mi micsoda. Egy form sem feltételemül abból áll, hogy elemeket jelenítek meg, hanem lehet hogy az aljában egy log rész van, ahol leírom hogy eddig kik azok, akik módosították a record adatait. Na most oda megint kinyomni a sitebuildernek az adatokat egy tömbben, hiszen a log többnyire tartalmaz kapcsolt adatokat is. Semmivel nem vagyunk előrébb, ha én gyártom le a tömböt, és Ő templatet, ahelyett hogy tömbgyártások helyett mindjárt a templattel foglalkoznék. Ráadásul valami másik nyelven és templatekezelővel (smarty?)?

Tehát a példánál maradva, mit vár a suitebuilder a regisztrációs formnál a backend fejlesztőtől? Szerintem, amire nekem szükségem van, az egyrészt név szerint a tartalom, másrészt amire neki, azok a kapcsolt entitások. Tehát egy tömb valahogy így:
név => Kis Pista
Cim => Budapest
kedvenc szine => 12
És ügye kellene egy másik tömb, a színek:
11 => Sárga
12 => Piros
És mondjuk a cím közé legyen beszúrva a log, az még egy tömb (az első tömbben?):
Név => Admin János
módosítva => 2011-12-31

Mivel a megjelenítésért Ő felel, gondolom hogy sorrendbe is majd Ő rakja a színeket név szerint vagy bármi szerint. Meg nyilván a tömb is általa kerül megfelelő sorrendbe. Én arra vagyok kíváncsi hogy hol nyeri a csapat azt a sok időt, ha mégis Ő csinálja? Én azzal hogy kiteszem ezeket a tömböket már mínuszban vagyok az idővel. de nyilván erre is írhatok egy generátort és akkor ugyanott vagyok. De Ő hol van előrébb? Pláne hogy abból indulunk ki hogy nincs kész templateje, hiszen össze vissza cserélgeti a html elemeket.

Persze tudom hogy hol nyerünk időt. Ott, hogy önmagát nem szívatja meg az állandó változtatásokkal. :-)
50

Azon gondolkozz el, hogy

Hidvégi Gábor · 2012. Feb. 21. (K), 10.37
Azon gondolkozz el, hogy mivel vagytok előrébb, ha az adatok megjelenítésével járó feladatokat Te kezeled? Nincs elég dolgod az adatok mentésével/lekérdezésével stb.?
67

Szerintem

zsoc · 2012. Feb. 21. (K), 13.20
Alapvetően egy ilyen munkafolyamatnak úgy kell történnie, hogy:
1. megvan a "barebone" site, ami csupán az adatokat köpi ki.
2. megvan a dizájn.
3. jön a sitebuilder, és ebből a kettőből összegyúrja a végleges oldalt.

Lehetséges visszacsatolások:
a) a dizájn egyes elemei nem megvalósíthatók
b) a dizájn egyes elemei nem értelmezhetők.
c) a dizájn és a kapott adatmennyiség sehogy sem összeegyeztethető.

Mint az látható, ha a dizájner sem kapja már meg a szükséges infókat, akkor csak szivatja az őt követő kollégát, és viszont...

Egy jó frontendes -ugyancsak szerintem- jól bánik a kliens oldali javascripttel is, szóval azt sem lenne szabad levenni a válláról.

Persze simán lehet, hogy valaki lerövidíti a dolgokat egy saját, vagy mások által készített css rendszert használva, és nem kell mindent újraírni, az idő nekem eddig azt igazolta, hogy ahány oldal, annyi eltérő igény, és lehetőség.
39

Sitebuilder / frontend fejlesztő

Poetro · 2012. Feb. 21. (K), 00.26
Szerintem a sitebuilder / frontend fejlesztő feladata, hogy
  • A dizájnertől kapott képet HTML formára hozza.
  • Kivágja a képeket, amik kellenek.
  • Elkészíti a használandó CSS fájlokat, és elmondja a programozóknak, melyik template-hez, melyik CSS fájlok fognak kelleni.
  • Elkészíti a használandó JavaScript fájlokat, és elmondja a programozóknak, melyik template-hez, melyik JS fájlok fognak kelleni.
  • Elkészíti a template fájlokat, amiket a program majd meg fog hívni a megfelelő adatokkal.
  • Az adatokon esetleg kisebb átalakításokat végez, bizonyos feltételek alapján megjelenít benne dolgokat, bizonyosakban pedig elrejt (ezt minden template rendszer tudja).
  • Amennyiben a backend fejlesztő még nem készítette elő az adatokat amiket a template vár, akkor megmondja, neki milyen formában kellenek.
  • Amennyiben a backend fejlesztő már előkészítette az adatokat, és azok valamiért nem felelnek meg a template követelményeinek, akkor változtatást kér.
41

Az előttem szólók leírták a

Hidvégi Gábor · 2012. Feb. 21. (K), 08.26
Az előttem szólók leírták a lényeget. Tehát most egy jó sablonozó rendszert kéne keresned, amivel ezt meg lehet valósítani.

A magam részéről az XML + XSLT párost tudom ajánlani, mert többek között backend és frontend oldalon is fel lehet használni, azaz nem kell kétszer dolgoznod, ha szeretnéd a rendszeredet ajaxosítani.
42

Divat

Bártházi András · 2012. Feb. 21. (K), 09.20
Hát, az XML + XSLT ma már nem nagyon divat, van, hogy az XSLT elég körülményes tud lenni. Ha PHP, akkor szóba jöhet a Twig:Vagy szinte bármilyen nyelvhez a Mustache:Bár volt már egy projektem, ahol szükség volt rá, de praktikusan elég ritkán kell olyan template engine, ami mind a két oldalon működik.

Divatos alatt a népszerű, az alap problémákon felül a friss trendekre, problémákra is választ adó megoldásokat értem.
56

Divat

Hidvégi Gábor · 2012. Feb. 21. (K), 11.47
Ha valami divatos, az feltétlenül azt jelenti, hogy jó is?
Ha valami nem divatos, akkor azt inkább ne használjuk, mert szükségszerűen rossz?

Ki mondja meg, hogy mi a divat?
Követni kell-e a divatot?
Mi van akkor, ha az aktuális divat hülyeség?
Ha nem követed a divatot, akkor hátrány ér?
Lehetnek-e önálló gondolataid?
Mi van akkor, ha az ügyfeleidnek nem a divat szerint, hanem az igényeikre kínálsz megoldásokat?
57

Én tényleg nem értem mi

nova76 · 2012. Feb. 21. (K), 11.57
Én tényleg nem értem mi szükség erre:

{% for user in users %}
    * {{ user.name }}
{% else %}
    No user have been found.
{% endfor %}
Először is használhatatlan ebben a formában, hiszen nincs benne I18n. Ez most kukacoskodásnak tűnik, de a példa mindig az, hogy { user.name }, ahelyett hogy valami tényleg nagyon extrém lenne, amit ki kell írni. Smartynál is mindig ez volt a vesszőparipa, miközben egy javascript függvény beleírása meg egy féloldalas kódot eredményezett 2 sor helyett.

Ezzel még nagyon messze vagyunk attól hogy egy form adatait megjelenítsük. Aztán a users honnan kerül oda? Tőlem, a backend fejlesztőtől, az tiszta sor. De honnan tudja hogy én úgy fogom hívni? El kell mondjam neki? Ráadásul az előző példámnál maradva a user.color.name fogja visszaadni a kedvenc színét? Na azt találd ki! :-) És ha több van neki? Azért ez egy nagyon szoros munkakapcsolatot kíván. Vagy valami template kezelő IDE is kell, olyan ami felkínálja ezeket a változókat. Anélkül szinte használhatatlan.
59

miközben egy javascript

Hidvégi Gábor · 2012. Feb. 21. (K), 12.06
miközben egy javascript függvény beleírása meg egy féloldalas kódot eredményezett 2 sor helyett
Át kellett volna nézni a dokumentációt, át lehet definiálni a smarty kezdő- és végtag-eket.
De honnan tudja hogy én úgy fogom hívni?
Megegyeztek az elején.
Vagy valami template kezelő IDE is kell, olyan ami felkínálja ezeket a változókat. Anélkül szinte használhatatlan.
Anélkül is lehet.

A CSS és a Javascript is azért kerül külön fájlba, hogy ne keveredjenek a különböző funkciók. A html-lel az a baj, hogy még egyben vannak az adatok és a megjelenítéshez szükséges információk (gondolj itt a rengeteg plusz divre, ami a grafika miatt kell), a sablonrendszerek arra valók, hogy ezt különválasszuk.
60

Csapatban

Poetro · 2012. Feb. 21. (K), 12.12
Ajánlom kezdj el csapatban dolgozni, vagy megtanulni, hogyan kell együttműködni egy csapattal. Természetesen az sem árt, ha mélyebben elsajátítod az MVC alapjait.
Először is használhatatlan ebben a formában, hiszen nincs benne I18n.

Miért ne lehetne benne i18n? Csak meg kell hívni egy függvényt a szöveggel, és ezt szinte minden sablonozórendszer tudja. A mustache alatt ezek a lambda függvények. És természetesen smarty alatt is van ilyen. Nem kell azt gondolni, hogy a frontendes / sitebuilder az nem lenne képes alapvető parancsokat meghívni.
De honnan tudja hogy én úgy fogom hívni? El kell mondjam neki?

Mivel legelőször is dokumentálnod kell a projektet, mielőtt elkezded, nem kell elmondani neki, elég ha elolvassa a dokumentációt, hogy mit hogyan fog megkapni.
Vagy valami template kezelő IDE is kell

Sablonkezelő rendszerekkel Dunát lehet rekeszteni, egyeseknek van IDE támogatásuk, másokhoz csak kódszínezés létezik.
ami felkínálja ezeket a változókat. Anélkül szinte használhatatlan.

Nem gondolnám, hogy használhatatlan, legfeljebb kicsit többet kell gépelni, de a dokumentáció mindig sokat tud segíteni, hogy mit is várjon az aktuális sablonban.
68

Csak meg kell hívni egy

nova76 · 2012. Feb. 21. (K), 14.25
Csak meg kell hívni egy függvényt a szöveggel, és ezt szinte minden sablonozórendszer tudja

Nem értettél meg, nem az a gondom, hogy nem lehet benne, hanem hogy amikor majd belekerül, akkor már semmivel sem egyszerűbb, sem nem kevesebb, mint PHP-val. Csak beleteszel a kódba még egy rendszert, amit vajon ki fog kihasználni? A sitebuilder? Most egy smartys sitebuilder mennyivel több mint egy PHP sitebuilder?

Nem gondolnám, hogy használhatatlan, legfeljebb kicsit többet kell gépelni, de a dokumentáció mindig sokat tud segíteni, hogy mit is várjon az aktuális sablonban.
A kicsit többet kell gépelni vagy kicsit utána kell olvasni a doksiban és utána kicsit többet kell gépelni között nagy különbség van. :-) Főleg ha olyat keresel, aminek nem tudod a nevét, és a doksi mondjuk 200 oldal.

Az a baj hogy így sem vitatkozni nem tudunk, sem tanulni nem fogok ebből a topikból. Én próbáltam példával előjönni, Ti is tehetnétek ezt. Mondjatok példát hogy mit spórolok meg egy template kezelővel. Legyek én a templatező (4 órában) és legyek én a backend fejlesztő (4 órában). 2 x 4 órában érjem el azt, amit most 8 órában :-)
69

PHP template

Poetro · 2012. Feb. 21. (K), 14.38
Nem kell sablonkezelő, lehet a sablon pusztán PHP is. Azt spórolod meg, hogy több ember tud dolgozni egy feladaton. A dokumentációt meg így is, úgy is el kell készíteni, és a dokumentációban az a jó, hogy kereshető. Tegyük fel, hogy van egy 10 fős csapat, ebből mondjuk 3 ért frontendhez, 7 pedig backendhez. Ekkor a 3 frontendes elkezdi készíteni a HTML-t, amíg a backendesek előkészítik az adatokat a megjelenítéshez. Mivel párhuzamosan tudnak dolgozni, így időt spórolnak. Amikor valami kérdés van valamelyik oldalról, mert nem volt egyértelmű a dokumentáció vagy a specifikáció, akkor tudnak beszélgetni, mert mindketten ugyanazzal foglalkoznak. Valamint nem akadályozzák egymás munkáját, mindenki foglalkozhat azzal, amihez ért. Az egyik gyúrja a HTML-t, CSS-t, JS, a másik meg a Ruby-t vagy Python-t. A másik bónusz szolgáltatás, hogy a kód egyszerűbben tesztelhetővé válik.
70

Csapatmunka...

H.Z. v2 · 2012. Feb. 21. (K), 14.45
Működik a mail címed? Csapatmunka témában szeretnélek megkeresni egy kérdés erejéig...
71

Természetesen

Poetro · 2012. Feb. 21. (K), 15.04
Természetesen működik, sőt a többi elérhetőségem is, ami megtalálható itt, vagy a saját oldalamon is.
72

a dokumentációban az a jó,

nova76 · 2012. Feb. 21. (K), 15.07
a dokumentációban az a jó, hogy kereshető

Ha tudod hogy hívod amit keresel. De épp azt nem tudod, mert azt keresed, hogy hívják :-)
Tegyük fel, hogy van egy 10 fős csapat, ebből mondjuk 3 ért frontendhez, 7 pedig backendhez.

De ez ügye nem jelenti azt hogy elég 8 ember munkáját elvégezni? Akkor talán máshogy kellene felosztani a feladatokat. Például az egyik készíti a regisztrációt a másik webshopot, harmadik a webshop adminját, stb. Ráadásul 3 ember azon dolgozik, hogy a css fájlban definiált div helyett p elemet hozhasson létre a templatekben. Mert ügye a dives template már készen van, egy mozdulattal legenerálom. Csak arra a css nem húzható rá.
81

Ez a sablonozás gyakorlatilag

inf3rno · 2012. Feb. 21. (K), 22.10
Ez a sablonozás gyakorlatilag egy saját nyelv gyártása, amit aztán persze ugyanúgy php-ra fordítunk. Szerintem ennek semmi értelme nincsen, ha valaki sablonnyelvet akar, akkor ott az XSLT, az elég szabványos, nem kell kitalálni semmit hozzá, ha meg valami rugalmasabb kell, akkor ott a PHP. Ahhoz még ráadásul vannak fantasztikus IDE-k kód kiegészítéssel és színezéssel, lehet debuggolni, és a backend-esek is ismerik a lehetőségeit, tehát tudnak segíteni, ha elakad valamelyik frontend-es kolléga... Miért éri meg szerintetek mégis ezeket a sablonrendszereket használni?
84

Akkor lehet értelme

Hidvégi Gábor · 2012. Feb. 21. (K), 22.22
Akkor lehet értelme sablonnyelvet használni, ha valamennyi dinamizmusra van szükséged, de nem szeretnéd a php teljes eszköztárát a sitebuilderre bízni, mert esetleg véletlenül valamit elront.

Szerintem XSLT-vel meg lehet a legtöbb problémát oldani, továbbá olyan előnnyel jár, hogy az XML-ben lévő adatokat könnyebb más formátumba transzformálni.
99

"Akkor lehet értelme

inf3rno · 2012. Feb. 22. (Sze), 11.11
"Akkor lehet értelme sablonnyelvet használni, ha valamennyi dinamizmusra van szükséged, de nem szeretnéd a php teljes eszköztárát a sitebuilderre bízni, mert esetleg véletlenül valamit elront."

Ha elrontja, akkor az úgyis kiderül, és vissza lehet állni az előző verzióra.
Egyébként szerintem meg lehet beszélni vele, hogy milyen függvényeket vagy osztályokat használhat, esetleg lehet egy listát készíteni erről, és a build-be betenni egy ellenőrzést, hogy tényleg csak ezeket használta e...

Volt már bárkinek problémája ezzel (nekem olyan mondvacsinált dolognak tűnik)?
101

Szerintem ne ragadjunk le a

BlaZe · 2012. Feb. 22. (Sze), 14.29
Szerintem ne ragadjunk le a Smartynál, vannak más elven működő template rendszerek is. Sőt, ne ragadjunk le a php-nál se. A template (egyik) nagy előnye, hogy a frontendes kollégának semmit nem kell tudjon a rendszerről, elég ha egy nagyon egyszerű template rendszert ismer (vagy még azt sem kell ismerje). Ő ért a html+css+js kombóhoz és ennyi. Ha én egyik nap egy php alkalmazást tolok az orra alá, másik nap meg j2ee alkalmazást, ugyanúgy tud dolgozni anélkül, hogy ismerné a php-t, jsp-t, jsf-et, vagy bármit. Persze a legtöbb template frameworknek van egy nagyon egyszerű és hasonló nyelve, ezt sok esetben meg kell tanulják. De ez töredéke az említett technológiák megbízható elsajátításának. Amire ráadásul nincs is szüksége.

Arról nem is beszélve, hogy mennyivel kulturáltabban néz ki egy normális template, mint egy "telehányt" php+html, vagy akár sok esetben jsp dzsindzsa (bár itt már azért jobb a helyzet, mint eleinte).
109

Bár volt már egy projektem,

Hidvégi Gábor · 2012. Feb. 23. (Cs), 10.41
Bár volt már egy projektem, ahol szükség volt rá, de praktikusan elég ritkán kell olyan template engine, ami mind a két oldalon működik.
Az ingatlan.com ajaxos, de semmi sem indokolja, hogy javascript nélkül ne működjön, szóval itt pont jól jönne ez a funkció.
111

AJAX?

Bártházi András · 2012. Feb. 23. (Cs), 13.22
Nem tudom miből következtettél arra, hogy az ingatlan.com AJAX-os lenne. Nem az. A kereső URL-t JavaScript állítja össze, mert felhasználóbarát URL-eket akartunk létrehozni, és ez tűnt a legjobb megoldásnak. Ennek viszont semmi köze a template-ezéshez.
112

Nem ajax

Hidvégi Gábor · 2012. Feb. 23. (Cs), 13.44
Megzavart a loader, ez tényleg nem ajaxos.
10

Mikor használunk

Hidvégi Gábor · 2012. Feb. 20. (H), 09.13
Mikor használunk document.write()-ot? - soha.
Körülbelül egy éve a google maps is használta, emiatt akkor a Flash megjelenítőjüket választottam. Most megnéztem megint, újraírták a kódot, már nincs benne.
11

Rock Paper Scissors Spock Lizard

Varsányi Martina · 2012. Feb. 20. (H), 09.14
A, ennel menobb nincs is :)

http://www.samkass.com/theories/RPSSL.html
12

Dehogynem.

inf3rno · 2012. Feb. 20. (H), 09.22
16

:-D

H.Z. v2 · 2012. Feb. 20. (H), 10.18
Ez fájt! :-D
19

/o\

deejayy · 2012. Feb. 20. (H), 11.05
/o\
17

Jó stressztűrő képesség

Gixx · 2012. Feb. 20. (H), 10.49
Nekem az a kedvencem, amikor azt írják a hirdetésbe, hogy előny/feltétel a jó stressztűrő képesség. Ergo megint két ember munkáját kell elvégezni :)

Ahogy mondani szoktam (elnézést a nyelvezetért):

Nyugalomban szárnyalok, stressz alatt meg szar-nyalok.
18

Stressz teszt...

H.Z. v2 · 2012. Feb. 20. (H), 10.58
Amit eszembe juttat a stressztűrő képesség:
Emlékeim szerint, életemben egyetlen alkalommal jelentkeztem olyan hirdetésre, ahol ez követelmény volt.
Az interjú valahogy úgy nézett ki, hogy télen, repkedő mínuszok közepette, megjelentem a megbeszélt időpontban. (öt perccel korábban, ahogy illik)
Egy nagyméretű családi ház kb. 1.5x3m-es, fűtetlen előszobájában várakoztattak kb. húsz percen át, még leülni sem volt hova.
Végül megjelent egy általam 18-20 év körülire saccolt srác, bementünk a tárgyalóba, beszéltünk pár percet, miközben egyre hangsúlyozta, hogy a főnök egy kissé idegbeteg alak, akinek minden azonnal kell...
Hogy mindezzel a stressztűrést tesztelték vagy valóban ilyen tahó cég volt, azóta sem tudom. Viszont arra már évekkel ezelőtt is úgymond felkészítették a friss munkanélkülieket, hogy esetenként úgy tesztelik őket, hogy bunkó módon viselkednek velük az interjú előtt és alatt...
20

Az én tapasztalatom szerint

zzrek · 2012. Feb. 20. (H), 13.19
Az én tapasztalatom szerint a másik helyzet a gyakoribb: ha bunkó módon viselkednek, az nem teszt, hanem tényleg olyanok. :-o
21

masik cikk

adobi · 2012. Feb. 20. (H), 13.20
22

ugyanaz

Bártházi András · 2012. Feb. 20. (H), 14.18
Én is pont ezt linkeltem be, ennek kapcsán írtam a bejegyzést. ;)
24

Twitter

Gixx · 2012. Feb. 20. (H), 14.26
Are you on Twitter?
If so, who do you follow on Twitter?


Kovit, ki mást? :D
30

Néhány kérdés

T.G · 2012. Feb. 20. (H), 18.38
Általános JavaScript:
  • Mi az eredménye a 10 + 010 + 0x10 + '010' kifejezésnek? (és itt jófejek vagyunk, nem baj, ha kevered a 8-as és 16-os számrendszert:)
  • Mi az eredménye? [5, 1, 10].sort()
  • Hol használjuk a finally kulcsszót? Mi a szerepe?

ExtJS kérdések:
  • Mi a különbség az Ext.get és az Ext.fly között?
  • Sorolj fel minél több eseményt, amely egy Ext.Window létrehozásától az első megjelenítéséig történik?
  • Mi a createDelegate? Mire való, hol használjuk?
31

Ezeknek a számrendszeres

inf3rno · 2012. Feb. 20. (H), 18.45
Ezeknek a számrendszeres kérdéseknek mi értelme van? A gyakorlatban soha nem kerül elő a 8-as vagy 16-os számrendszer. Láttam már PHP-nál is, hogy előfordult ez a kérdés, talán ott egy fokkal több értelme van, de ott is nagyon ritka, amikor használom.

Amihez kellhet a 16-os, az a színátmenetek számolása, de ott meg ugyanúgy lehet 10-es számrendszert használni, és a végén konvertálni toString(16)-al. Szóval szerintem több értelme lenne egy olyan kérdésnek, hogy [255, 0, 255]-ből hogyan csinálsz "#ff00ff"-t? Persze ez csak egyéni vélemény, ti tudjátok, hogy nektek mi a fontos.
32

Számrendszerek

T.G · 2012. Feb. 20. (H), 19.06
Mi értelme van, hogy a nyelvnél bevezették a használatát? Ha profi JavaScript programozót keressünk, akkor az nem mondhatja, hogy szerinte a nyelv egyes részei feleslegesek és emiatt nem is ismeri. Nem baj, ha nem használod, de ismerete szükséges. Legalább annyi, hogy a fenti összeget kiszámold! És még az sem baj, ha a kettőt kevered!

Konkrétan a te példádnál maradva én nem látom, hogy miért lenne itt a PHP-ben ennek nagyobb létjogosultsága. Szerintem a színek, színátmenetek kezelése inkább kliens oldal. :)
35

Szerintem sem fölöslegesek

MadBence · 2012. Feb. 20. (H), 20.02
Szerintem sem fölöslegesek ezek a nyelvi elemek, nemrég node-ban kellett fájl jogokat állítanom valami miatt, ott jól jött az oktális számrendszer, bitmaszkokat meg 16-os számrendszerben könnyű csinálni (persze kérdés, JS-ben mennyi szükség van ilyenre. nyilván elenyésző, de jó tudni, hogy van)
44

Mi most kliens oldalról

inf3rno · 2012. Feb. 21. (K), 09.46
Mi most kliens oldalról beszéltünk, ott jóval kevesebbszer kell ilyesmi, mint szerver oldalon vagy asztali alkalmazásnál... Azért kliens oldali js nem a bonyolult algoritmusokról híres...
43

A színváltoztatásnál js-re

inf3rno · 2012. Feb. 21. (K), 09.45
A színváltoztatásnál js-re gondoltam, nem PHP-re... Persze, hogy nem felesleges, mert előfordulhat nagy ritkán olyan probléma, amikor szükség van rá, viszont az egyik legkevésbé fontos kérdés szerintem. Vagy ez valami sokadik kör, amikor már extrákat kérdeztek, nem a fontosabb dolgokat?
107

Elég sok mindent bevezettek

tgr · 2012. Feb. 22. (Sze), 22.21
Elég sok mindent bevezettek Javascriptbe, aminek nincs értelme (lásd Crockford klasszikus művét). Ezeket annyira kell ismerni, hogy messziről el tudd kerülni őket, de a pontos működésüket számonkérni teljesen felesleges. Pl. mit számít, hogy valaki tudja-e, mi a különbség a function declaration és a function statement között, ha a gyakorlatban úgyis csak annyit kell tudni, hogy ne definiálj feltételesen függvényeket?
33

összeadás vs. konkatenálás

T.G · 2012. Feb. 20. (H), 19.11
Mellesleg az átlag felhasználó a konkatenáláson csúszik el. :) Az eredmény nem ugyanaz JS-ben, mint PHP-ben, így szerintem a példának van létjogosultsága. Az, hogy a számrendszerek elterelik a figyelmet, meg másik kérdés...
34

A sort meglepett, valamiért

MadBence · 2012. Feb. 20. (H), 19.59
A sort meglepett, valamiért sose rendeztem számokat JS-ben :-). A számoshoz annyit, hogy kicsit erőltetett, mármint ott igen nagy bajok vannak, ahol háromféle számrendszer szerint áll elő egy eredmény, a stringes móka meg ilyenkor túl egyértelmű (aki valaha is használta a parseInt függvényt, az nem dől be neki. illetve bedől neki, mert azt hiszi becsapós :-) )
36

szerintem sincs

zzrek · 2012. Feb. 20. (H), 22.28
Szerintem sincs sok értelme olyan kérdéseket feltenni, amik ritkán fordulnak elő. Ez csak kekeckedésnek jó, amiből ha sok van, az a kérdéssor összeállítóját minősíti (nem jól jön ki, ha vagy direkt, vagy hozzánemértés miatt a kérdéssor azt sugallja, hogy az összeállítójának fogalma sincs róla, hogy mi fontos és mi nem)
40

Mi fontos? :)

T.G · 2012. Feb. 21. (K), 07.19
Tehát, akkor megint, a konkrét kérdésnél nem a számrendszer, hanem a + operátor a lényeg, ám egy 10 + '10' túl direkt, emiatt kell az „elterelés”. Ami tetszik, nem tetszik, bejön. Ez egy buktató kérdés.

Ám sok esetben nem a válaszok eredményessége a fontos, hanem a megoldás megmutatása utáni reakció. Amit nem is a programozó, hanem a boss néz. Emiatt kellenek a „kekeckedő” kérdések!
45

És mit lehet leszűrni ebből a

inf3rno · 2012. Feb. 21. (K), 09.50
És mit lehet leszűrni ebből a reakcióból? (Most már tényleg érdekel, hogy mi értelme van ennek...)
46

Például azt, hogy hogyan

Hidvégi Gábor · 2012. Feb. 21. (K), 10.01
Például azt, hogy hogyan reagál az illető az újfajta problémákra.
48

De ne legyen sok ilyen

zzrek · 2012. Feb. 21. (K), 10.30
De ne legyen sok ilyen kekeckedős kérdés, mert akkor úgy fog látszani mintha vagy pökhendiek lennének a kérdéssor összeállítói (akik a szakmai tudásukat fitogtatják, vagy nagyon gurunak akarnak látszani) vagy inkompetensnek fognak tűnni (akik azt se tudják hogy a fejlesztésben mi a fontos). Egy igényes emberke egy inkompetens kérdéssor esetén meggondolja, hogy esetleg ne ahhoz a céghez jelentkezzen - vagyis a pályáztató a rossz kérdéssorral akár még veszíthet is. (Bár manapság már minden munkalehetőségre ugranak a pályázók)
51

Felvezetés

Bártházi András · 2012. Feb. 21. (K), 10.45
Mi előre szólni szoktunk, hogy lesznek direkt szívatós kérdéseink is, figyeljen oda a válaszokra, de egyáltalán nem gond, ha nem jó a válasz. Ebből még sohasem volt problémás interjú.
61

Mit lehet leszűrni?

T.G · 2012. Feb. 21. (K), 12.22
Maximum egy órád van, hogy megismerj egy vadidegen embert, akármiről beszélgettek utána dönteni kell. Minél több infód van, annál könnyebb. Ennyi. Ez egy max. 15 kérdésből álló, egy-két perc alatt kitölthető teszt. Csak akkor vesszük elő, ha van benne bármi érdekes. Ám, ha ott félhangosan megkérdezi, hogy ki találta ki ezt a f.sz kérdést, akkor valószínűleg az ügyféligényeknél is hallhatjuk a hasonló kommentárt. Ez a vezetésnek szóló üzenet. :)

De, hogy szakmailag mit láthatunk ezen a kérdésen? Egy másik példa, feladat ugyanaz, mi az eredmény?

var third = 1 / 3;
third.toFixed(2) + third.toFixed(2) + third.toFixed(2);
Sajnos nagyon sokan azon gondolkodnak, hogy vajon 1 vagy 0.99 a megoldás? Pedig ki van előtte emelve, hogy JavaScript kérdéskör. Ennek megfelelően a megoldás: "0.330.330.33"
Aki a fentiben is, illetve itt is hibázik az túl sokat PHP-zet és keveset JavaScript-ezet. Ami nem feltétlen baj, de ha kifejezetten JavaScript-es embert keresünk, akkor azért mégsem előny. :)

Az előző kérdésnél kétszer kellett összeadni, sokan figyelmetlenségből harmadszor is összeadnak. Mert azt hiszik, hogy a feladat „nehezén” már túl vannak. Ráadásul még PHP-ben igazuk is lenne.
47

Szerintem van

szaky · 2012. Feb. 21. (K), 10.21
Ezek az apró, ritkán előforduló dolgok ismerete különbözteti meg az átlagos fejlesztőt a kiváló (tapasztalt) fejlesztőtől. Mert mikor az a ritka eset jön, hogy előjön ez a probléma, akkor nem mindegy, hogy 10 másodperc, vagy 2 óra megy el a megoldásra.
73

Ne haragudj, de a 10 perc

inf3rno · 2012. Feb. 21. (K), 18.09
Ne haragudj, de a 10 perc vagy a 2 óra közti különbség nem ebből adódik, hanem hogy hogyan debuggol az illető. Nyilván látja, hogy nem stimmel, ha képes 5 perc alatt leszűkíteni egy kódrészletre a hibát, akkor hamar rájön, hogy mi nem stimmel...
74

5 perc debug?

T.G · 2012. Feb. 21. (K), 19.13
Ez nagyon optimista hozzáállás, ha minden hiba 5 perc alatt előjönne...

Ha nem ismered a nyelv korlátait, akkor nem tudsz felkészülni a szélsőséges esetekre. Ha a TDD tesztjeid a szélsőséges eseteket nem vizsgálják, akkor nem elegendő, hogy az összes teszted hiba nélkül lefut.

PHP esetén, stringet vársz valahol, használsz substr –et, felkészülsz, hogy false is lehet az érték? Vagy csak string típussal gondolkozol?

Ennek kapcsán jogos kérdés lehet egy ilyen tesztnél, hogy mi a substr('x', -2); kifejezés értéke? Illetve ha már frontend interjú kérdéseknél tartunk, akkor a mi a 'x'.substr(-2); értéke? Hál’Isten ez sem ugyanaz PHP és JS esetén. :)

Számomra ellentmondásos, hogy valaki azt mondja, hogy a szélsőséges esetekkel minek foglalkozni, majd, hogy a hiba 5 perc alatt megtalálható.
75

Ha IDE-vel szerkeszted, akkor

inf3rno · 2012. Feb. 21. (K), 21.24
Ha IDE-vel szerkeszted, akkor kiírja az összes paraméter nevét... Nem értem miért kéne fejből tudnom egy 2 vagy több paraméteres függvény paraméter listáját. Eleve OO szempontjából nem is lenne nagyon szabad ilyeneket megengedni, mert egynél több paraméternél a sorrend már nem egyértelmű. Nem szeretem a PHP-t különösebben pont az ilyen örökségei miatt. A javascript sokkal közelebb áll a szívemhez, a java meg még közelebb...

Javascript-nél netBeans-ben sajnos nem működik a legjobban az automatikus kiegészítés, kíváncsi vagyok, hogy vajon más IDE-kben felajánl e valamit az általad említett esetnél. Ami megint csak érdekes, hogy én string darabolásra javascriptben mindig a slice-ot használom, szóval lazán odaírnám, hogy hibaüzenetet kapok. A substring-et tudtam, hogy létezik, viszont a substr-t azt nem... Szóval ezek alapján engem fel se vennétek :D (Bár lehet, hogy amúgy sem felelek meg a követelményeiteknek...)
76

substr

Poetro · 2012. Feb. 21. (K), 21.32
Lehet, azért is nem emlékszel a substr-re, mert nem része az ECMAScript-nek, viszont a substring és a slice igen. Ráadásul a slice többet is tud, úgyhogy én mindig azt használom.
78

Jah, gondoltam, hogy valami

inf3rno · 2012. Feb. 21. (K), 21.47
Jah, gondoltam, hogy valami bővítmény, újabban hozzátákoltak pár metódust az alap osztályokhoz, mint pl a forEach, meg ezek szerint ezt a substr-t is. A forEach helyett én jobban örültem volna, ha Iterator-t csinálnak, nem tetszik, hogy állandóan be kell állítani a this értékét, minden ciklusnál. Könnyen lemarad, ha nem figyel oda az ember, mert ugye nem kötelező... (Ez megintcsak az 1-nél több paraméteres függvények/metódusok hibája...)
94

Jah, gondoltam, hogy valami

kuka · 2012. Feb. 22. (Sze), 10.07
Jah, gondoltam, hogy valami bővítmény, újabban hozzátákoltak pár metódust az alap osztályokhoz, mint pl a forEach, meg ezek szerint ezt a substr-t is.
substr() kuka emlékezet óta létezik. Mozilla dokumentáció szerint „Implemented in JavaScript 1.0”.
95

Most már megnéztem a

inf3rno · 2012. Feb. 22. (Sze), 10.37
Most már megnéztem a szabványt, és tényleg benne van.
Régen nyúltam js-hez, úgy látszik felejtettem...
96

Some implementations of

Poetro · 2012. Feb. 22. (Sze), 10.49
Some implementations of ECMAScript have included additional properties for some of the standard native objects. This non-normative annex suggests uniform semantics for such properties without making the properties or their semantics part of this standard.

Azaz az escape / unescape / String.prototype.substr / Date.prototype.getYear / Date.prototype.setYear / Date.prototype.toGMTString nem az ECMAScript része, hanem amolyan kiegészítések, amiket az implementálók megvalósítottak (szinte) kivétel nélkül megvalósítottak.
98

Ahm, szóval kevésbé veszélyes

inf3rno · 2012. Feb. 22. (Sze), 11.06
Ahm, szóval kevésbé veszélyes a használatuk...
77

"Számomra ellentmondásos,

inf3rno · 2012. Feb. 21. (K), 21.40
"Számomra ellentmondásos, hogy valaki azt mondja, hogy a szélsőséges esetekkel minek foglalkozni, majd, hogy a hiba 5 perc alatt megtalálható."

Elég érdekes, ahogy kiforgatod a szavaimat... Annyit írtam, hogy szerintem a szélsőséges esetek kevésbé fontosak, ezért nem hiszem, hogy az alapján kellene felmérni valakinek a tudását, hogy mennyi szélsőséges esetet ismer, és mennyit nem, hanem az alapján, hogy mi az, amit ténylegesen tud. Legalábbis az egyetemen így vizsgáztatott a tanárok 99%-a. Volt 1-2 renitens, akit utáltak, mert ettől eltért, és úgymond "szivatta" az embereket... Megintcsak egy érdekes kérdés, hogy nekem volt olyan vizsgám, ahol csak a speciális eseteket tudtam, mert az megragadt, és ezért kaptam 4-est, viszont ha komolyabban belementünk volna az alapelvekbe, akkor akár meg is ránthattak volna...

Szóval szerintem semmi értelme ezeknek. Én inkább olyan kérdéseket tennék fel, amik úgy kezdődnek, hogy "hogyan valósítanád meg ...", vagy "hogyan tesztelnéd ...", vagy "mit csinálnál, ha ...". Az ezekre kapott válaszokból, esetleg rövid példakódokból szerintem sokkal többet le lehetne szűrni a felvételiző tényleges tudásából.

Persze ha a személyiségi jegyeit akarjátok valakinek vizsgálni, meg hogy hogyan reagál a stresszhelyzetre, akkor elismerem tényleg jó módszer a "szivatás"... A kérdés csak az, hogy ennek vajon mennyi köze van ahhoz, hogy valaki ért e egy adott szakmához, vagy sem?
80

Hiába értesz a szakmához a

Hidvégi Gábor · 2012. Feb. 21. (K), 21.51
Hiába értesz a szakmához a legmagasabb szinten, ha stresszhelyzetben mondjuk lebénulsz agyilag, és képtelen bármit csinálni.
85

Re. lebénulsz agyilag

T.G · 2012. Feb. 21. (K), 22.24
Na, de ez hogy derülhet ki egy felvételi elbeszélgetésen? (amúgy tök jogos az észrevétel)
86

Nem tudom

Hidvégi Gábor · 2012. Feb. 21. (K), 22.25
Nem én vagyok a felvételiztető : )
87

Értem, és ha emiatt rúgnak ki

inf3rno · 2012. Feb. 21. (K), 22.29
Értem, és ha emiatt rúgnak ki állásinterjúról, akkor az nem konzerválja még jobban ezt az állapotot?

Jó persze ez már egyéni szociális probléma témakör, ez meg nem egy pszichológiával vagy szociológiával foglalkozó fórum... :-) Azért én tanácsolnám az illetőnek, hogy keressen meg egy szakembert ezzel a problémájával, fizet x összeget, és talán megszabadul tőle egy életre...
90

És egy fejlesztőnél ennyire

H.Z. v2 · 2012. Feb. 22. (Sze), 08.01
És egy fejlesztőnél ennyire fontos, hogy stresszhelyzetben mit csinál?
Mert tapasztalataim szerint, a stresszes dolgok általában az üzemeltetőkön csapódnak le még akkor is, ha a programmal van gond.
92

Gondolj például a leadás

Hidvégi Gábor · 2012. Feb. 22. (Sze), 08.28
Gondolj például a leadás előtti hajrára, nem mindenki viseli ugyanúgy a nyomást.
100

Én azt gondolom, hogy az

BlaZe · 2012. Feb. 22. (Sze), 13.37
Én azt gondolom, hogy az említett példák inkább a lexikális (manuális :)) tudást tesztelik, mint az alkalmazási készséget, illetve stressztűrő képességet. És én azt gondolom, hogy előbbi egy kevésbé lényeges szempont, mert úgyis manualból dolgozunk, képtelenség fejben tartani mindent. Engem az ilyen jellegű tudás nem nagyon érdekelne, ha felvételiztetnék valakit. Ha van megfelelő tapasztalata - ami az interjún beszélgetés közben úgyis kiderül -, a legfontosabb problémákkal úgyis találkozott. Inkább érdekelne az, hogy tudja-e, hogy a használandó eszköz mit tud. De főleg a gondolkodása a lényeges, hogyan old meg egy problémát, hogyan ismerkedik meg egy új eszközzel, technológiával. Erre szerintem egy próbafeladat sokkal alkalmasabb, mint egy teszt. Majd a munkáját átnézve újabb jól irányzott kérdésekkel jó képet kaphatunk róla.

A stressztűrő képesség és egyéb személyiségjegyek mérésére pedig vannak speciális tesztek, vagy ahol arra van idő és keret, ott vannak az AC-k (assessment center). Akinél ez erős igényként előjön, annak ezt a szűrést megéri szerintem profibban csinálja. Neki is érdeke.
102

Én azt gondolom, hogy az

inf3rno · 2012. Feb. 22. (Sze), 16.43
Én azt gondolom, hogy az említett példák inkább a lexikális (manuális :)) tudást tesztelik, mint az alkalmazási készséget, illetve stressztűrő képességet.

Én is ugyanezt gondolom, bár a lexikális tudás is számít, de sokkal kevésbé, mint az, hogy az ember tisztában van az alapelvekkel, ami szerint az adott szakma felépül. Régebben a lexikális tudás sokkal többet ért, a mai világban viszont nagyon sok dolgot pillanatok alatt meg lehet találni a neten, felesleges mindent fejben tartani, elég, ha tudod, hogy hol keressed, vagy milyen kulcsszavakkal jutsz el hozzá ...
103

+1

zzrek · 2012. Feb. 22. (Sze), 18.06
+1
83

Konkrétan?

T.G · 2012. Feb. 21. (K), 22.21
Tudsz írni konkrét példát? Tehát ne a kivételekre kérdezzünk rá, hanem?
(a felsorolt néhány minta kérdésem alapján persze volt elméleti kérdés is, illetve az ilyen típusúak vannak többségben)

A keresd meg a tömbben egy bizonyos feltételnek megfelelő elemet, szerintem nem feladat. Ami meg feladat, az elvesz több időt. Mert azt azért továbbra is fent tartom, hogy egy óra alatt kell kihozni a legtöbbet. Ebbe nem fér bele, hogy triviális feladatot adjunk meg, hogy megnézzük, hogy az if-ben Yoda vagy nem Yoda feltételeket használ. Ráadásul teljesen lényegtelen számomra, hogy melyiket használja. :)

Illetve kérdés, hogy papíron, vagy gépnél kellene ezeket megoldani? Papíron 5-6 sornál hosszabb kódot íratni már szívatás. :)
88

Pár dolog, (frontend, backend

inf3rno · 2012. Feb. 21. (K), 23.14
Pár dolog, (frontend, backend vegyesen):
Mondjuk hogy van e globális rálátása arra, hogy miből áll egy webalkalmazás, és ő ennek melyik szeletét csinálja. Tudja e, hogy mi az, hogy verziókezelő, milyen verziókezelő rendszert használt eddig. Mik az előnyei annak, ha kliens oldalon validálsz, és mik annak, ha szerver oldalon validálsz. (Ez már kicsit beugratósabb, mert ugye szerver oldalon mindig kell.) Mi az, hogy MVC, mi az, hogy front controller, hogy zajlik egy kérés kiszolgálása. Milyen támadási módokat ismer. (CSRF, XSS, stb...) Js: mi az a closure, hogyan iterál egy gyűjteményt, milyen gyűjtemények vannak js-ben, mi az a css selector, írjon css selectort, ami kiválasztja ezeket az elemeket (html vagy xml példa). Hogyan dolgozná fel ezt az XML-t, hogy a következő kimenetet kapja. Hogyan oldaná meg, hogy egy ajax-os alkalmazásnál a vissza gomb lenyomásánál is megváltozzon az oldal, ezzel kapcsolatban milyen megoldásokat ismer, pl HTML5-ben került be egy teljesen új histroy API, előtte csak fragment-es megoldás volt. Ha már a fragment-nél tartunk, akkor mik a részei egy url-nek stb...

Igazából még ezer évig lehetne sorolni, már meguntam... Ezeknek a kérdéseknek egy jó részét meg lehet találni pl prog.hu-n, vagy stackoverflow-on, vagy akár az itteni fórumban is, szóval még csak nagy fantázia sem kell hozzá.

Ha meg nem tudja a választ az adott kérdésre, akkor mondjuk el lehet játszani vele egy olyat, hogy jó, akkor keressen rá google-ben (ehhez mondjuk olyan kérdések kellenek, amikben nincsenek benne a kulcsszavak, legalábbis nem túl sok), ezzel pl le lehet mérni, hogy mennyi idő alatt talál megoldást egy problémára.

A "hogyan oldaná meg" kezdetű kérdések szerintem azért jók, mert sok olyan kérdés van, amire rengeteg választ lehet adni. Pont ma volt egy olyan kérdés PHP-val kapcsolatban prog.hu-n, ami roppant egyszerű: van egy változód, amit egy szövegbe kell beillesztened, majd kiírnod a kiértékelt formáját a kimenetre. Na erre PHP-ban kb 10 megoldás van. Minél többet fel tud sorolni valaki, annál többet tud az adott nyelvről.

A stresszhelyzetre adott reakciót meg sokkal direktebben is lehet tesztelni. Akár ilyet is fel lehet tenni a vizsgázónak, hogy közeleg a határidő, de elmaradása van a projekttel, mit csinál, és ott van néhány válaszlehetőség. Miért gondolja, hogy az jobb megoldás, mint a többi felsorolt? stb... De akár ha a stressz oldási képességére vagy kíváncsi, akkor olyat is fel lehet tenni neki, hogy pl az egyik kollégája totál ideges, leblokkolt a stressztől, és nélküle nem tudják határidőre befejezni a munkát, mit tesz. Ha azt mondja, hogy próbálná megnyugtatni, akkor megkérded, hogy na és hogyan. stb... Az, hogy mit válaszol nagyban függ attól, hogy ő hogyan kezeli magában a stresszhelyzeteket. Nyilván olyat fog mondani, amivel önmagát is nyugtatná...
91

Nem lett konkrét a válaszod. :)

T.G · 2012. Feb. 22. (Sze), 08.03
Nem lett konkrét a válaszod. :) Kicsit olyan érzésem van, hogy még nem állásinterjúztattál, roppant nehéz egy óra alatt bárkiről is ítéletet mondani. Szükség van a kézzelfogható elemekre. Szerintem a guglizás nem az. Nem tudom reálisan eldönteni, hogy három perc netezgetés után még adjak egy percet és talán találunk valamit, vagy leállítsam, mert így is értékes három percet elszúrtunk.

Eljátszottam a történetet, a leendő kolléga sosem hallotta még a deep linking kifejezést, a history szó sem jut eszébe. A következő szavakkal mahinál: browser, back button, event. Talál is rögtön egy oldalt, amelyben az onbeforeunload használatáról írnak. Szóljak neki, hogy teljesen téves, vagy készítsem el vele akkor az oldalt, ahol van Ajax hívás, írassam meg vele az oldalelhagyás eseményt és nézzük meg, hogy mire is jutott?

Eltelt 10 perc, és tényleg mire jutottam? Emiatt nem írhatom le a kollégát!

Egy triviális feladatra hozott 5 megoldást, mondjam azt, hogy ez nem elég, legalább még kettő kellene? (majd a for helyett while-t ír:) Számomra ezek nem életszerűek. Inkább rákérdezek, hogy a mi glob függvény PHP-ben? Ha nem tudja, akkor a triviális példában az egyik megoldás kimaradt volna, ha tudja, akkor örülünk. Vagy kérem, hogy az exec-hez hasonló függvényeket soroljon fel. Ha nem tud még kettőt, akkor az probléma, ha felsorol tízet, akkor az már veszélyes. :)

Persze tegyünk különbséget a Junior és Senior állások között. Juniornál teljesen más szempontok számítanak, nem baj, ha nem ismeri az OOP-t, az MVC-t, a TDD-t és a további hárombetűs varázslatokat :), ha a kérdésfelvetés után azt válaszolja, hogy örülne neki, ha ezekre látna jól működő példákat és valaki megmutatná milyen mindez gyakorlatban. Az persze bukta, ha azt mondja, hogy szerinte ezek feleslegesek. Nálam ez annyi mínuszt ér, amit a többiek sem húzhatják fel. :)

Ám a senior-nál más a helyzet! Ott profi és profi között kell választani!
A Mensa-nál is van IQ teszt, meg a nevelési tanácsadónál is, előbbinél úgy alakították ki, hogy a felső rétegnél pontos, míg utóbbinál az alsó rétegre add pontosabb eredményt. Merthogy teljesen más a cél. A leendő kolléga idejét is tiszteletben kell tartani, meg a mi időnket is. Szerintem csak a felső réteget kell nézni.
97

Szerintem a guglizás nem az.

inf3rno · 2012. Feb. 22. (Sze), 11.04
Szerintem a guglizás nem az. Nem tudom reálisan eldönteni, hogy három perc netezgetés után még adjak egy percet és talán találunk valamit, vagy leállítsam, mert így is értékes három percet elszúrtunk.

Ha mondjuk adnál neki egy fix időt, hogy megkeresse. Így utólag belegondolva a google tényleg nem egy jó ötlet, mert én is néha órákat töltök vele, hogy megtaláljam a megfelelő kulcsszavakat egy témára.

Egy triviális feladatra hozott 5 megoldást, mondjam azt, hogy ez nem elég, legalább még kettő kellene? (majd a for helyett while-t ír:) Számomra ezek nem életszerűek. Inkább rákérdezek, hogy a mi glob függvény PHP-ben? Ha nem tudja, akkor a triviális példában az egyik megoldás kimaradt volna, ha tudja, akkor örülünk.

És ha arra kérdezel, hogy szerinte mi a legjobb megoldás arra, hogy .png kiterjesztésű fájlokat keressen egy mappában? (Szerintem tévedtem veled kapcsolatban, túl jóindulatú vagy, mert pl jelen esetben megmondod a függvény nevét, még csak gondolkodnia sem kell a vizsgázónak...)

Teljesen egyetértek veled abban, hogy különbséget kell tenni az állás "nehézsége" (junior/senior) között és nyilván a teszteket is ezekhez kell igazítani. Valóban nem vizsgáztattam még, viszont attól még véleményem lehet a témáról (a másik oldalon már álltam elég sokat...). Szerintem meg kell adni mindenkinek a lehetőséget, hogy kibontakozzon, és a túl konkrét vagy túl szivatós kérdések ezt hátráltatják. Persze egy nehézségi szint felett valóban szükség van ezekre is.
52

majd biztos kiszámolom...

Gixx · 2012. Feb. 21. (K), 10.50
Mi az eredménye a 10 + 010 + 0x10 + '010' kifejezésnek?


Válasz: A kliens majd kiszámolja. Egyébkét meg szívlapáttal kell fejbe verni azt, aki életvitelszerűen le mer írni ilyet egy működő kódba.
53

nem kell leírni ilyet

szaky · 2012. Feb. 21. (K), 11.22

 var adat_a_usertol = '010'; //typo
 var rendelt_draga_stuff_mennyisege=parseInt(adat_a_usertol);
54

De mivel az ECMA kitalálta

kuka · 2012. Feb. 21. (K), 11.37
De mivel az ECMA kitalálta hogyan rombolható a verzió kompatibilitás, ez már nem gond.
The ECMAScript 5 specification of the function parseInt no longer allows implementations to treat Strings beginning with a 0 character as octal values.
ECMAScript 5 Removes Octal Interpretation
55

Mégrosszabb

szaky · 2012. Feb. 21. (K), 11.43
Ezek szerint végképp adhoc a működés :)

PS: nálam, 10.0.2 ff alatt szépen 8-at ad vissza.
58

PS: nálam, 10.0.2 ff alatt

kuka · 2012. Feb. 21. (K), 12.01
PS: nálam, 10.0.2 ff alatt szépen 8-at ad vissza.
Chrome és Opera alatt is.

Valahol olvastam annak idején, hogy a Mozilla ezúttal nem szándékozik követni a szabványt, mert kifogásai vannak ellene. (De mivel a Mozilla dokumentáció egy wiki, ezt természetesen már nem találom.) Részemről én egyetértek ezzel a szándékukkal.
108

parseInt

MadBence · 2012. Feb. 22. (Sze), 23.58
Mi a probléma a parseInt-tel? Második paraméternek meg lehet adni a számrendszert.

Esetleg nem ez a probléma? Ebben a hosszú threadben kezdek elveszni :)
110

Mi a probléma a

kuka · 2012. Feb. 23. (Cs), 11.53
Mi a probléma a parseInt-tel?
Semmi. De mivel
JavaScript: The World's Most Misunderstood Programming Language – Douglas Crockford
ezért nem a második paraméterről nem halló pancsereket hagyják sülni a saját zsírjukban, inkább új működést írnak elő a függvénynek.
Ebben a hosszú threadben kezdek elveszni :)
A korábban reklámozott megoldás még érvényes. (Csak most, csak neked! Ha e téma olvasása közben töltöd le, akkor a hihetetlen árengedmény és az ingyenes szállítás mellett választhatsz még egy szkriptet a gyűjteményből teljesen ingyen és csomagolási költséget sem számolunk fel.)
113

Itt már az sem ér semmit, nem

inf3rno · 2012. Feb. 23. (Cs), 17.57
Itt már az sem ér semmit, nem tudom görgetni, és kilóg a lista a képből :D
114

Itt már az sem ér semmit, nem

kuka · 2012. Feb. 24. (P), 10.07
Itt már az sem ér semmit, nem tudom görgetni, és kilóg a lista a képből :D
Lehet frissítened kellene. A lista görgethetősége ügyében valamikor időközben tettem valamit.

Emellett a tegnap kiegészítettem a működését: a új hozzászólások száma mellé tettem előző/következő nyilat, így „kézi” görgetés nélkül végigugrálhatóak az új hozzászólások.

(Az első új hozzászólásra pedig úgy lehet legegyszerűbben eljutni, hogy a témát a Weblabor - Hozzászólás szám által beszúrt „(xx új)” hivatkozásra kattintva látogatod meg.)
115

FF-ben bent van, hogy

inf3rno · 2012. Feb. 24. (P), 11.51
FF-ben bent van, hogy autocheck for updates... Most akkor vagy az autocheck nem megy, vagy valami más ment félre...
116

Ehhez sajnos már nem tudok

kuka · 2012. Feb. 24. (P), 12.41
Ehhez sajnos már nem tudok hozzászólni. Én nem élek az automatikus frissítésekkel így nem is tudom mi a működésük feltétele.
117

Bár nem néztem át, de nem

inf3rno · 2012. Feb. 24. (P), 21.45
Bár nem néztem át, de nem tűnik valami bonyoultnak... Van még egy tonna találat, ha ez nem jönne be. Most akkor ezek szerint ha updatelni szeretném törölni kell, és újra felvenni?!
118

Az más, az önkiel… izé…

kuka · 2012. Feb. 25. (Szo), 16.03
Az más, az önkiel… izé… önkiszolgálás. (Bocs, nem rajongok az ilyen praktikákért.) Tehát független a felhasználónak a Greasemonkey beállításoknál kifejezett automatikus frissítéssel kapcsolatos óhajától.

Csak arra jó, hogy a gazda szkript ellenőrizze önmaga frissességét, értesítse a felhasználót és látogassa meg önmaga lelőhelyét. Tehát részéről a frissítés a .user.js állomány böngészőben való megnyitásából áll. Szerintem a kézi frissítés is ugyanennyi lehet.
119

Ahm, azt hittem valami

inf3rno · 2012. Feb. 26. (V), 01.31
Ahm, azt hittem valami komolyabb...
62

Ha már van Javascript...

Gixx · 2012. Feb. 21. (K), 12.51
...akkor eleve arra (is) kellene használni, hogy ne engedjen a felhasználónak hülyeséget beírni.

Ha meg nincs JS, vagy le van tiltva, akkor meg a backenden kell elkapnia a validátornak, hogy ilyen értéket nem áll módjában használnia, és visszatolni egy akkora Error üzenettel, hogy az Internet kávézó túlsó sarkában is lássák :)

Na jó ez a hibaüzenetes alázás csak vicc volt. De a hibajelzés nem. A backend sose bízhat meg a frontendről érkező semmilyen adatban még akkor sem, ha az egyébként "leakalappal-kategóriás" JavaScript kód elő-validálta már azokat.
63

8 nem megbízható?

szaky · 2012. Feb. 21. (K), 13.08
Igen, csak pont ez a lényeg: JS oldalon tudni kell, hogy nem elég egy ^[0-9]+\.?[0-9]* validáció, mert az a backendnek 8-at küld el, ami akárhogy validálok, helyes. A dolog javítható - ha az ember tudja, hogy javítani való van.
64

Akkor esetleg...

Gixx · 2012. Feb. 21. (K), 13.10
^[1-9]{1}\d*\.?\d*$
65

felesleges

Poetro · 2012. Feb. 21. (K), 13.14
A {1} teljesen felesleges, az az alapértelmezett.
^(?:[1-9]\d*|0)(?:\.\d+)?$
66

Ez hibát dobna erre: 0.5 De

szaky · 2012. Feb. 21. (K), 13.19
Ez hibát dobna erre: 0.5
De nem ez a lényeg. A feladat megoldható, ha tudjuk, hogy meg kell oldani.
79

Azt elmondanátok, hogy egy

inf3rno · 2012. Feb. 21. (K), 21.49
Azt elmondanátok, hogy egy számot miért kell regex-el validálni? (Nem tartom jó gyakorlatnak...)
82

parseInt illetve parseFloat

Poetro · 2012. Feb. 21. (K), 22.21
Természetesen lehet parseInt és parseFloat függvényeket is használni, csak ezzel nehéz azt validálni, hogy amilyen számot a felhasználó adott, az tényleg az-e a szám, amit adni akart. Ugye a parseFloat esetén ütközhetünk számábrázolási problémákba, valamint olyan számokat is elfogad, amik valószínűleg furán néznek ki például:
>>> parseFloat('9e9')
9000000000
>>> parseInt('0776')
510
>>> parseFloat('0.9999999999999999999').toString() === '0.9999999999999999999'
false
89

Jogos.

inf3rno · 2012. Feb. 21. (K), 23.19
Jogos.
104

Lehet maskepp is

Leonuh · 2012. Feb. 22. (Sze), 18.37
var test = '0755';
if(parseFloat(test) !== test) console.log('Invalid number');
else console.log('Valid number');
105

var test =

Poetro · 2012. Feb. 22. (Sze), 18.52
var test = '0.9999999999999999999';
if(parseFloat(test).toString() !== test) 
  console.log('Invalid number');  
else 
  console.log('Valid number');
Invalid number
106

Igaz, csak numerikusan

Leonuh · 2012. Feb. 22. (Sze), 19.46
Igaz, csak numerikusan teszteltem de belegondolva ugy nincs ertelme, bevitt stringkent pedig megkerulhetetlen a regexp sajnos.
93

tudtok hasonló listákat egyéb

Hidvégi Gábor · 2012. Feb. 22. (Sze), 08.37
tudtok hasonló listákat egyéb területekhez (backend fejlesztés, üzemeltetés, tesztelés stb.)?
Szerintem érdemes lenne ezeknek akár egy külön blogbejegyzést indítani, hogy azok a kollegák is könnyen rátalálhassanak mondjuk a keresőből, és a végén összekötni ezeket, mint egy cikksorozatot.