Обновить
Комментарии 72
там уже ползаем. Хочется что-то бумажное, дабы можно было в транспорте читать, да и плюс мы сходимся в мнении что это удобно — читать бумажные книги
мне вод эта книжка понравилась
javascript.ru/book/ajax-action#head-toc-full
А я считаю что лучше литература, плюс делать сразу упор на объектный подход.
Я тоже думаю что литература может очень помочь. Вопрос в конкретике — какая именно? Ибо я ни одной толковой книжки не знаю.
Толковые книжки, которые мне очень понравились:
1. JavaScript: The Definitive Guide, 5th Edition By David Flanagan (есть в переводе, www.ozon.ru/context/detail/id/3881091/) — читать обязательно и первым делом, лучшая книга и справочник по JS.
2. Pro JavaScript Techniques by John Resig (да-да, это именно тот клёвый дядька, который сделал jQuery).
3. Простенькая интересная книжка — DOM Scripting Web Design with JavaScript and the Document Object Model by Jeremy Keith (как правильно управлять DOMом :) )

первое заказал, спасибо. Люблю эту серию :)

в третье — о чем там пишут? Описание дом-а? или фишки и трюки там попадаются? Что входит в понятие «правильного» управления?
Книжка Джереми для начинающих, я бы не стал на нее распылятся. Берите Джона.
Поддержу рекомендации первых двух книг. Книга Фланагана вообще по моему единственная доступная на русском книга которая рассказывает о JavaScript именно как о языке.
Мое мнение, сугубо imho:
1) прочесть книжку по основам JS
2) прочесть книжку по ООП ( языконезаисимую )
3) полазить по zvon / xpoint.ru / xhtml.ru / rsdn.ru почитать основные фишки и проблемы у людей
4) начать писать задание, ибо практика ставит вопросы и находит на них ответы
Слова хорошие.
«практика ставит вопросы и находит на низ ответы». Воистину так
задания ставятся… вопрос в том что хочется форсировать. у меня ощущение что я уже сейчас задания ставлю чуть сложнее чем он может сделать и соответственно в голове каша получается.

1, 2. А можно конкретный пример? Причем первое чтоб можно было посмотреть как можно с большим отрывом от штмля?
мимо откомментил :(
посмотрите коммент выше — я не туда написал ответ
Хм, очень хороший вопрос )
Если я скажу по себе, то в качестве п.1 Это был справочник по JS + JS core ref :)
Знаю, что сейчас множество таких книжек есть. У меня народ очень хорошо отзывался про какуюто издательства O'Relly если мне не изменяет память. попробую потом узнать что за книжка.
По п.2. Этого очень много. Есть такая книженция праямо так и называется «Основы О.О.П.».
Я это читал людям по ( не поверите :) ) Wikipedia :)
Раз уж поднялась такая тема. Может кто скажет стандартные скрипты, который должен первым реализовать начинающий яваскриптер. Hello, world — понятно, калькулятор — понятно. Что еще?
календарик :)

мне важно жаваскриптеру важно пониманать различия между свойствами дом-объектов. К примеру почему браузеры быстрее отрисовывают изменение цвета у элементов, нежели изменение их геометрического размера.
Настоящий JavaScript-ер должен разбираться не только в DOM и Ajax. Он должен, например, без запинки написать функцию add которая складывает a и b и вызывается так: add(a)(b)

У меня это любимый вопрос на интервью.
хм… забавный пример :) Но видимо я не настоящий жаваскриптер, ибо думал аж 15 секунд :(

А есть у него практическая сторона?

ЗЫ С моей точки зрения очень важно знать тонкость работы с объектами в ЖСе — я уверен что я их сам понимаю далеко не полностью. При этом многие не понимают их вообще и пытаются с ними работать совсем не так, как должно.
Не надо прибедняться. Многим и 15 минут не хватит. Уверен, вы бы прошли интервью. ;)
Возможно. Но моё слабое место — понимание ООП. Я пока не написал большой жаваскриптовый клиент не понял его плюсов. Сейчас вроде понял и пытаюсь осознать поглубже. Ибо у меня в голове только жаваскриптерская его версия, которая из-за окружения достаточно специфична получается даже в небольших скриптах.
Интересный пример, может есть еще какие?
да, было бы интересно :)
А что же я на интервью тогда буду спрашивать? :)
Начинаю я обычно с азов:
Write the result of these expressions:

6 / «3»

«2» * «3»

4 + 5 + «px»

«$» + 4 + 5

«4» — 2

«4px» — 2

7 / 0

typeof null

typeof {}[0]

typeof («4px» — 2)

parseInt(«09»)

5 && 2

2 && 5

5 || 0

0 || 5

Сразу видно человек действительно знает язык или просто нахватался верхов.
ааа :) я не знаю что будет в половине случаев :)

А браузером пользоваться можно при тесте?
хотя случай с parseInt(«09»)
 у меня был — я долго матерился почему этот жс такой глючный :)
Ну это же не глюк никакой, надо просто parseInt(a, 10) всегда писать.
я уже знаю :) Но тогда я матерился и в итоге сделал «09»+0
Нет, конечно. Тест без компьютера. Но я же тоже не робот: главное это увидеть насколько человек опытен.
Ну у меня не половина но некоторые примеры с typeof удивили. Да эти задания показывают на скоко человек знает тонкости языка.
Щас подумал… а какое соотношение между опытом и количеством правильных ответов можно выделить?
Я считаю, что если человек пишет много скрипта, то он рано или поздно столкнётся и с «$» + 4 + 5, и с parseInt(«09»). Ответить на эти вопросы занимает минут 5, зато потом я знаю примерный уровень человека.
P.S. За 8 месяцев интервью ответил на все вопросы всего один человек.
Я верно ответил на все. Куда слать резюме?
Опять машина времени барахлит…
Если бы я встретил как работодатель программиста, который такие функции пишет — этот программист пошёл бы искать другую работу. Почему понятно, надеюсь?
А читать надо нетскейповскую документацию — там всё прозрачно описано.

function a1(a){
return function(b){return a+b;}
}

alert(a1(2)(3));
Непонятно, если честно. Надеюсь вы различаете академические и практические задачи?
Вот, мне тоже интересно, что плохого в замыканиях?
Страдает ясность и читаемость программ. Очень сильно, причём. О замыканиях, по хорошему, знают только те кто прошёл школу Perl, а таких нынче нету. Когда я пишу callback на JS — всё время себя контролирую на предмет использования замыканий, ведь это, по сути, глобальные переменные. И утечки памяти, кстати. Я, например, не знаю, что будет с памятью:

function a1(a){
return function(b){return a+b;}
}

var s='1';
alert('Check memory 1!');
for(i=0; i<20; i++)s=s+s;
alert(s.length);

for(i=0; i<10; i++){
a1(s)(s);
}
alert('Check memory 2!');
s=''
alert(s.length);
alert('Check memory 3!');

Программа должна быть прозрачной кристально и не быть рассчитанной на очень хорошего специалиста — таких просто нет в достаточном количестве.
Ну и в каком месте в вашей программе будут проблемы с памятью? Вызов a1(s)(s) создает, выполняет и уничтожает функцию-замыкание вместе с ее скопом. В чем проблема?

> Программа должна быть прозрачной кристально и не быть рассчитанной на очень хорошего специалиста

Ну так… давайте будем избегать ООП — там тоже не совсем прозрачно и далеко не каждый понимает, что происходит на самом деле, когда в коде встречается foo.bar().

> О замыканиях, по хорошему, знают только те кто прошёл школу Perl, а таких нынче нету.

О замыканиях, по-хорошему, знают только те, кто прошел школу Lisp, а вот таких, действительно нынче нету. Но это не значит, что замыкания — плохой инструмент. Он просто слишком хорош для современных программистов.

Какая разница в каком? Google пишет (http://code.google.com/apis/maps/documentation/#Memory_Leaks) что использует closures, и это приводит к утечкам памяти, и я вверю ему.

Требование прозрачности работы программы — обосновано практикой и к Вашему примеру отношения не имеет. Если программа написана просто и понятно, для её развития можно привлекать менее квалифицированных программистов.

По третьему пункту мы согласны — замыкания использовать нельзя?
Гугл пишет… Саймон говорит…

Если бы Вы немножко покопались в данном вопросе, то узнали бы, что к утечкам памяти приводят не замыкания сами по себе, а кривой сборщик мусора в trident aka IE, который не освобождает память, занимаемую DOM-элементами, если на DOM-элемент повесить обработчик события, который является замыканием, в скопе которого есть ссылка на этот DOM-элемент. Решается этот момент тривиально: путем явного удаления обработчиков сотыбий для DOM-элементов при unload текущей страницы.

Замыкания использовать можно и нужно, потому что они позволяют существенно сократить объем программы, а, как известно, при прочих равных условиях большую ценность имеет та программа, в которой меньше кода.

Более того, поняв суть замыканий, можно писать офигенно элегантные вещи на том языке, который поддерживает концепцию «замыканий» и, как следствие, «продолжений».

Если Вы в своей практике не желаете развивать «менее квалифицированных специалистов», то грош цена Вам и вашей компании как работодателю.

Одним словом, если Вы не любите замыкания, то Вы просто не умеете их готовить. ;-)

P.S. Nothing personal, меня просто взбесила Ваша фраза «Если бы я встретил как работодатель программиста, который такие функции пишет — этот программист пошёл бы искать другую работу. Почему понятно, надеюсь?»

Полезно почитать библиотеки типа jQuery, Prototype и тд. просто исходники.
В данном случае я боюсь кривой дорожки — уйдет юный девелопер в эти библиотеки и будет именно их использовать, вместо того чтобы самому _уметь_ писать. Вот чуть попозже — да, я согласен что их стоит почитать.
JAVASCRIPT. Полный справочник. Второе издание. Толстая книженция такая. Очень толково понятно и обширно все описано!
чисто справочник — это несколько не то. Для справки интернет лучше используется имхо
ну эта книга не совсем как справочник! Отличное пособие как для начинающих так и для профи, именно пособие!
ок, посмотрю — а то я в свое время… еще лет 5 тому назад купил себе толстый справочник :)
не все толстые справочники одинаково полезны! :)
зато как подставку можно использовать любой из них :)
Повезло вашему ученику :) Кто б меня взял Java обучить… Без отрыва от производства.
незнаю-незнаю. Один уже не выдержал нагрузки… Ищется ему замена…
а вот у нас как… взяли меня… посадили, сказали вот твое рабочее место и теперь дают всякие задания… и им совершенно не важно как я их сделаю Х_х
По большому счету у нас тоже есть задания которые могут быть сделаны абы как :)

Вопрос в том, на что изначально ориентировать человека. Можно на поддержку, а можно и на разработку. Во втором случае вместе с ЖС идет вбивание в головы концепций, паттернов и прочих страшный вещей. Ну и прикладное, типа систем контроля версий и тракеров — учета задач.
По-моему, если «вбивать» эти самые «страшные вещи» без отрыва от земли, закрепляя практикой, то ничего страшного не будет. Особенно, если это все применяется пусть учебном цельном проекте. А не отдельными упражнениями-скриптиками. Тогда у ученика разовьется как бы комплексное видение. Без больших соблазнов «ой, а там легче применить jQuery и не мучаться, все-равно проект сложный».
И да, это мое мнение.
Соглашусь. Комплексный подход в этом деле полезен. В идеале еще смотреть как это делается другими. Но торопится с включением в командную разработку на данном уровне тоже не стоит… вот такая вот диалектика.
Точно так. Как говорится, «лучше день потерять, но потом за час долететь».
Эмм… Задания абстрактные или идут в продакшн?
JavaScript. Справочник (Аллен Вайк), супер книжка, юзаю постоянно
НЛО прилетело и опубликовало эту надпись здесь
Ну почему никто просто документацию не хочет читать? Набла, признанная безграмотной после многостраничного обсуждения? А всего-то надо было почитать инструкцию. Апофеоз программирования…
Если английский не проблема, то могу порекомендовать книгу «Professional JavaScript for Web Developers» издательства Wrox. На мой взгляд очень качественно написана.
Здесь можно посмотреть содержание: www.wrox.com/WileyCDA/WroxTitle/Professional-JavaScript-for-Web-Developers.productCd-0764579088, descCd-tableOfContents.html
Я думаю надо просто заставить его начать писать что-нибудь для проекта.
Зачем кого-то заставлять? Надо из группы отобрать несколько человек и на них сосредоточить все усилия, а остальным поставить оценки и не тратить время. А вот с избранными работать на полную катушку.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.