Comments 121
Ненавячивое (unobtrusive) программирование
Про статью. Не хочу я ничего использовать. Я подожду более standard-compliant решения.
Про статью. Не хочу я ничего использовать. Я подожду более standard-compliant решения.
можно подробнее, с какими проблемами вы столкнулись в попытке поработать с jquery? о соответствии каким стандартам идет речь?
Лет так через ...цать будет. Стандартизируеться всё настолько долго, что успевает устареть)
Пока на свете есть Microsoft, и он выпускает свой браузер, никакого standard-compliant решения не будет. Так что ждите, мы тоже будем молиться, и может когда-нибудь этот светлый день придёт.
Но пока prototype и jQuery очень помогают. И автору поста респект!
Но пока prototype и jQuery очень помогают. И автору поста респект!
Уважаемый автор, было бы очень приятно получить список ссылок по теме, для тех, кто не так сильно разбирается в JS, но для кого библиотека могла бы принести пользу: разработчики мелочей на ее основе.
На официальном сайте jQuery есть все необходимое: tutorials, docs and API (да, все только на английском).
Все материалы очень качественные, простые и понятные. Единственное, что меня не совсем устраивает — это API. Поэтому испльзую jQuery API Browser от Bassistance. Но там только версия 1.1.2.
Все материалы очень качественные, простые и понятные. Единственное, что меня не совсем устраивает — это API. Поэтому испльзую jQuery API Browser от Bassistance. Но там только версия 1.1.2.
А! Совсем забыл. Есть еще прекрасная книга Learning jQuery: Better Interaction Design and Web Development with Simple JavaScript Techniques by Karl Swedberg and Jonathan Chaffer.
Кому жалко $39.99, может скачать из p2p сетей. eMule ссылка.
Кому жалко $39.99, может скачать из p2p сетей. eMule ссылка.
Похожая реализация АПИ для 1.1.2 - Visual Jquery
Хорошая библиотека, давно использую ненарадуюсь.
В свое время отказался от многих, в том числе от Prototype, как от монстра гигантского.
В свое время отказался от многих, в том числе от Prototype, как от монстра гигантского.
А можно от вас узнать, хотя бы несколько доводов, чем jQuery лучше Prototype?
Просто я уже некоторое время использую Prototype и в принципе доволен, но вот упоминание jQuery в последнее время встречаю всё больше и больше. Реально, в чем плюсы и минусы?
Мне кстати показалось, что под jQuery написано больше различных приблуд чем под prototype, так ли это?
Просто я уже некоторое время использую Prototype и в принципе доволен, но вот упоминание jQuery в последнее время встречаю всё больше и больше. Реально, в чем плюсы и минусы?
Мне кстати показалось, что под jQuery написано больше различных приблуд чем под prototype, так ли это?
Размером (20Кб всего в сжатом виде), "мусором" в глобальном адресном пространстве - всего одна функция. Собственно размер был основным фактором ухода от Prototype.
Плагинов разных также много.
Плагинов разных также много.
jQuery сейчас похожа на церковь, в которую с помощью дурацких примитивных примеров и не менее дурацких увещеваний "про простоту и уникальность" ласково и нежно завлекают прежде всего бедных и несчастных js-ньюбов. А заодно и тех, у кого при острой нехватке времени (или ещё чего) на js-программирование есть время на изучение неоднозначного псевдо-кода-от-дяди-джона, что очевидно проще. Остаётся только сожалеть, что вся эта страсть и энергия, доки и вижуал-апи, туториалы и семинары, и даже книжки не направлены в сторону изучения и пропаганды старого доброго J(ava)Script.
Не знаю кто и кого там завлекает, но если кто-то говорит вам, что jQuery можно пользоваться не зная JavaScript'а - то он откровенно лжет. Либо не оканчивает фразу. Ибо полностью она должна звучать так: jQuery можно пользоваться мало что зная про JavaScript - но только тогда, когда у вас есть знакомый, который вас спасёт когда эта очередная абстракция "протечёт"...
Вообще же от любого хорошего программиста требуется некоторое понимание всех уровней в компьютере - начина от транзисторов и вверх. Не доскональное знание (этим не обладает никто), но ответить, скажем, на вопрос: почему современные видеокарты не могут использовать RayTracing (и никогда не смогут использовать его в качестве основоного инструмента) он должен уметь...
Вообще же от любого хорошего программиста требуется некоторое понимание всех уровней в компьютере - начина от транзисторов и вверх. Не доскональное знание (этим не обладает никто), но ответить, скажем, на вопрос: почему современные видеокарты не могут использовать RayTracing (и никогда не смогут использовать его в качестве основоного инструмента) он должен уметь...
UFO just landed and posted this here
LOL. Ваши ответы типичны для программиста - уж можете мне поверить. На этом этапе разницы между плохим и хорошим программистом нет. Разница появляется если объяснить человеку как устроен RayTracing и предложить вспомнить хоть чего-нибудь про транзисторы :-) Понимать простые алгоритмы хороший программист должен уметь (уж извините), а некоторые базовые факты про них он на самом деле тоже знает - чего бы там он ни заявлял по первости. К примеру:
- транзисторы - это такие маленькие элементики, которые могут быть в двух состояниях
- количество бит на транзистор в разных видах памяти - попадает в интервал (1, 4] (хотя ответ (1, 10] - тоже годится; за знание того что в некоторых "необычных" видах памяти типа флеша может быть и больше одного бита на транзистор - дополнительный маленький плюсик)
- транзисторов в современнем процессоре - сотни миллионов, но не миллиарды (ответ "десятки миллионов" - тоже годится, хотя он и не вполне верен)
- при переходе из состояния в состояние транзисторы выделяют тепло (за замечание про то что без переходов они тоже выделяют тепло, но значительно меньше - дополнительный маленький плюсик)
- транзисторы могут переключаться очень быстро - самые быстрые делают это за несколько пикосекунд
Если же человек досконально знает про то как устроен транзистор, чем полярный отличается от неполярного и зачем нужен плавающий затвор - ну что же, лишние знания никому не вредят, но и пользы особой от них нет: эти детали вряд ли "протекут" в более высокие уровни абстракции
А оценивать кандидатов мне приходится частенько (не знаю как где, но во всех местах где я работал последние несколько лет программист при приёме на работу должен переговорить не только с HR'ами, но и с программистами которые будут его коллегами). Оценивать же программиста "по работам" - очень сложно в современном мире ибо мало кто разрабатывает что-то "от" и "до" и я видел много случаев когда люди участвовали в интересных проектах, но занимались там рутиной и просто не обладают знаниями позволяющими поручить им самостоятельный проект - по возможности таких не следует принимать на работу... А людей у которых были интересные идеи, но которые по независящим от них причинам не довели их до ума - наоборот нужно брать...
- транзисторы - это такие маленькие элементики, которые могут быть в двух состояниях
- количество бит на транзистор в разных видах памяти - попадает в интервал (1, 4] (хотя ответ (1, 10] - тоже годится; за знание того что в некоторых "необычных" видах памяти типа флеша может быть и больше одного бита на транзистор - дополнительный маленький плюсик)
- транзисторов в современнем процессоре - сотни миллионов, но не миллиарды (ответ "десятки миллионов" - тоже годится, хотя он и не вполне верен)
- при переходе из состояния в состояние транзисторы выделяют тепло (за замечание про то что без переходов они тоже выделяют тепло, но значительно меньше - дополнительный маленький плюсик)
- транзисторы могут переключаться очень быстро - самые быстрые делают это за несколько пикосекунд
Если же человек досконально знает про то как устроен транзистор, чем полярный отличается от неполярного и зачем нужен плавающий затвор - ну что же, лишние знания никому не вредят, но и пользы особой от них нет: эти детали вряд ли "протекут" в более высокие уровни абстракции
А оценивать кандидатов мне приходится частенько (не знаю как где, но во всех местах где я работал последние несколько лет программист при приёме на работу должен переговорить не только с HR'ами, но и с программистами которые будут его коллегами). Оценивать же программиста "по работам" - очень сложно в современном мире ибо мало кто разрабатывает что-то "от" и "до" и я видел много случаев когда люди участвовали в интересных проектах, но занимались там рутиной и просто не обладают знаниями позволяющими поручить им самостоятельный проект - по возможности таких не следует принимать на работу... А людей у которых были интересные идеи, но которые по независящим от них причинам не довели их до ума - наоборот нужно брать...
UFO just landed and posted this here
А по-моему программисту постоянно приходиться изучать "не свои" области. В первую очередь хотя бы потому, что он пишет программы для людей, а потребности у этих людей — разные.
А то, что вы не хотите углубляться в основы, вешаете ярлыки на людей, да ещё и не можете воспользоваться хотя бы виртуальной клавиатурой, чтобы людям удобнее было читать ваши мысли, говорит о вас не самым лучшим образом.
А то, что вы не хотите углубляться в основы, вешаете ярлыки на людей, да ещё и не можете воспользоваться хотя бы виртуальной клавиатурой, чтобы людям удобнее было читать ваши мысли, говорит о вас не самым лучшим образом.
Вы где-то меня поймали: я никогда не занимался "webdev"'ом в стиле "давай-давай быстрей, лишь бы хоть как-то работало" - "бог миловал" пока. А серьезные разработки (когда QPS меряется десятками тысяч и борьба идёт за миллисекунды) оказались поразительно близки к тому чем я занимался раньше (драйвера, железки всякие). И вот как раз с этой точки зрения jQuery весьма и весьма неоднозначен. Для прототипов мы его иногда используем, но в реальных проектах - очень редко.
Возможно для программистов которые не знают основ и существует где-то ниша (даже скорее всего существует - хороших программистов мало, а миллионы визжащих и прыгающих сайтов кто-то ведь должен делать), но это не повод "навешивать ярлыки" ходу...
Что же касается умения "разбираться в риторике" - тут согласен, есть такое дело: я переливать из пустого в порожнее не умею. Вы тут уже много раз высказывали ничем не подкреплённую мысль что "всё, кроме оценки по работам - это субъективизм", но я не увидел ни строчки обоснований. Оценка по работам - ещё больший субъективизм, чем любая другая. Оценить "по работе" человека можно только тогда, когда он эту работу сделал сам "от и до", а если он что-то сделал "от и до" - то это значит что эта работа была небольшой - это уже тоже внисит субъективизм: сделать неплохую маленькую фитюльку и систему, которая будет 10'000 транзакций в секунду "тянуть" - это разные вещи. Конечно если кто-то руководил стоящей разработкой - то это чуть объективнее, но и тут всё не на 100% прозрачно: зачастую бывает что реально всё проектирование осушествляется вовсе даже не формальной главой проекта...
Тоже касается и фреймворков: с помощью некоторых откровенно отстойных сделаны интересные проекты - но это самр по себе фреймворки не красит (конечно когда таких проектов много - это повод посмотреть на фреймворк и понять - он реально хорош или просто "в струю попал")...
Возможно для программистов которые не знают основ и существует где-то ниша (даже скорее всего существует - хороших программистов мало, а миллионы визжащих и прыгающих сайтов кто-то ведь должен делать), но это не повод "навешивать ярлыки" ходу...
Что же касается умения "разбираться в риторике" - тут согласен, есть такое дело: я переливать из пустого в порожнее не умею. Вы тут уже много раз высказывали ничем не подкреплённую мысль что "всё, кроме оценки по работам - это субъективизм", но я не увидел ни строчки обоснований. Оценка по работам - ещё больший субъективизм, чем любая другая. Оценить "по работе" человека можно только тогда, когда он эту работу сделал сам "от и до", а если он что-то сделал "от и до" - то это значит что эта работа была небольшой - это уже тоже внисит субъективизм: сделать неплохую маленькую фитюльку и систему, которая будет 10'000 транзакций в секунду "тянуть" - это разные вещи. Конечно если кто-то руководил стоящей разработкой - то это чуть объективнее, но и тут всё не на 100% прозрачно: зачастую бывает что реально всё проектирование осушествляется вовсе даже не формальной главой проекта...
Тоже касается и фреймворков: с помощью некоторых откровенно отстойных сделаны интересные проекты - но это самр по себе фреймворки не красит (конечно когда таких проектов много - это повод посмотреть на фреймворк и понять - он реально хорош или просто "в струю попал")...
UFO just landed and posted this here
Zeroglif написал грамотный комментарий. jQuery (как и большая часть других фреймворков) пытается обойти тот печальный факт, что JavaScript в большинстве browser'ов не поддерживает XPath. И, соответсвенно, использование jQuery провоцирует написание кода, который будет безумно тормозить. И вам всё равно придётся спускаться на уровень JavaScript'а (хорошо если не ниже).
Вроде бы самые вопиющие проблемы со скоростью в 1.1.4 поправили - но эта версия ещё слишком молода, чтобы её можно было рекомендовать всем и вся, а 1.1.2 - просто слишком медленная в большинстве случаев. Но даже и 1.1.4 нельзя и сравнить с прямым использованием JavaScript'а. По моему ниша jQuery досточно узка: его стоит использовать тогда когда в проект нужно что-то добавить "сбочку" без больших переделок движка. Ну и для прототипов/внутренних проектов, когда скорость разработки важнее качества результата. Но для внутренних разработок можно просто использовать имеющийся в Mozilla (и движках на основе Mozilla) XPath - и не мучиться ни с какими фреймворками!
P.S. Оценка способностей человека к выполнению работы по выполненной работе - это ни в каком смысле не замер "прямых показателей" (если это не ACM contest или TopCoder). Ибо стартовые условия в реальной жизни у всех - разные и они вносят подавляющий вклад в результат. Гораздо больший чем способности самого человека. Умение грамотно решать задачки - гораздо более прямой показатель, так как они гораздо меньше зависят от предистории: тябе обычно мало волнует кем был человек - куда важнее кем он стал, а людям свойственно меняться и, увы, не всегда в лучшую сторону... "Идеал объективности", конечно, недостижим, но стремиться к нему стоит...
Вроде бы самые вопиющие проблемы со скоростью в 1.1.4 поправили - но эта версия ещё слишком молода, чтобы её можно было рекомендовать всем и вся, а 1.1.2 - просто слишком медленная в большинстве случаев. Но даже и 1.1.4 нельзя и сравнить с прямым использованием JavaScript'а. По моему ниша jQuery досточно узка: его стоит использовать тогда когда в проект нужно что-то добавить "сбочку" без больших переделок движка. Ну и для прототипов/внутренних проектов, когда скорость разработки важнее качества результата. Но для внутренних разработок можно просто использовать имеющийся в Mozilla (и движках на основе Mozilla) XPath - и не мучиться ни с какими фреймворками!
P.S. Оценка способностей человека к выполнению работы по выполненной работе - это ни в каком смысле не замер "прямых показателей" (если это не ACM contest или TopCoder). Ибо стартовые условия в реальной жизни у всех - разные и они вносят подавляющий вклад в результат. Гораздо больший чем способности самого человека. Умение грамотно решать задачки - гораздо более прямой показатель, так как они гораздо меньше зависят от предистории: тябе обычно мало волнует кем был человек - куда важнее кем он стал, а людям свойственно меняться и, увы, не всегда в лучшую сторону... "Идеал объективности", конечно, недостижим, но стремиться к нему стоит...
"Элементики, которые могут быть в двух состояниях" это триггеры. Так, к слову. Транзистор я (да и не только я) себе несколько иначе представляю (+ С другой стороны, конечно, в процессоре в качестве триггеров используются транзисторы.
Вообще говоря, я с вами полностью согласен. Без понимания основ, самих принципов работы компьютера говорить о программировании даже на высоком уровне не приходится.
Вообще говоря, я с вами полностью согласен. Без понимания основ, самих принципов работы компьютера говорить о программировании даже на высоком уровне не приходится.
Транзисторы могут находиться в двух состояниях, триггеры могут хранить два состояния.
На самом деле и то и другое - не совсем правда (бывают транзосторы, которые могут находиться более, чем в двух состояниях, хранить состояние может не только триггер, etc) - но это уже тонкости, которые редко бывают полезны...
На самом деле и то и другое - не совсем правда (бывают транзосторы, которые могут находиться более, чем в двух состояниях, хранить состояние может не только триггер, etc) - но это уже тонкости, которые редко бывают полезны...
а почему они никогда не смогут использовать RayTracing
Вы убрали из фразы важную часть: "в качестве основного инструмента". Просто потому что скорость света 300'000 километров в секунду - и она "протечёт" через любые абстракции. Достаточно очень простого описания алгоритма RayTracing'а и очень приблизительного знания об устройстве видеокарты, чтобы понять что они не стыкуются: заставить современную видеокарту считать RayTracing можно (через шейдеры), только вот 90% времени (хорошо если не 99%) она будет простаивать... Если человек знает про то какие абстракции есть в видеокарте - с ним можно поговорить про то, где конкретно в них в этом случае образуются "утечки" (высокоуровневые интерфейсы в GPU вроде как ничем для RayTracing'а не страшны - проблемы "протекают" через "дыры в абстракциях" с самого низу: из физики).
Офигеть, такие детали должен знать каждый хороший программист? Я думаю нет. От программиста, пишушего 3д движки и подобные вещи? это можно требовать, но от программиста, например, специализирующегося на базах данных, сетях, паралелльном программировании, экспертных системах и т.п., требовать такое, ну уж извините, перебор. Такой программист сам кого хочет завалит на глубинных вопросах своей области. В том числе и вас.
Вы читать умеете ? Где я написал что он должен всё это знать ? Он должен "ответить на вопрос". А для этого знать нужно очень мало. Причём вещи которые очень тяжело не знать: то есть можно себе представить программиста, который никогда в жизни не видел рекламного объявления где реклимровалась бы видеокарта с "512-битным доступом в память" (384bit, 256bit - неважно, важно что много - много больше 32-64bit) или "с 48-конвеерами" (32 или даже 16 - опять-таки важно что много) - но это само по себе плохой показатель: это значит что человек не просто этим не интересуется (что нормально), но сознательно избегает даже тех знаний которые ему пытаются "втюхать"... А это значит - что он либо просто ничего не умеет делать, либо он - суперузкий специалист (а это в IT - равносильно смертному приговору если только вы не спец по Коболу).
Собственно основной постулат прост: хороший программист имеет рудиментарные познания про всё что лежит "под ним", но главное - он умеет думать. Хороший ворос - не вопрос, требущий глубинных знаний (для ответов на такие вопросы есть Yandex и Google), а вопрос, на который можно ответить зная лишь основопологающие принципы и имею голову на пречах. Знать основопологающие принципы в смежных областях - всегда полезно, а голова на плечах - она просто необходима...
Как раз для людей "пишущих 3д движкии и подобные вещи" часто подобные проблемы оказываются сложнее, чем для "простых смертных". Они слишком много знают - и потому начинают мыслить с уровня шейдеров, ограничений в Cg и прочих высокоуровневых вещей - а там не так всё ужасно и вроде бы RayTracing должен бы быть возможен, но нет: "протекают" сюда (через все слои абстракций) весьма глубинные вещи, тесно связанные с законами физики, а не подробности GPU, с которыми обычно имеет дело "программист, пишущий 3д движки"...
Как раз для людей "пишущих 3д движкии и подобные вещи" часто подобные проблемы оказываются сложнее, чем для "простых смертных". Они слишком много знают - и потому начинают мыслить с уровня шейдеров, ограничений в Cg и прочих высокоуровневых вещей - а там не так всё ужасно и вроде бы RayTracing должен бы быть возможен, но нет: "протекают" сюда (через все слои абстракций) весьма глубинные вещи, тесно связанные с законами физики, а не подробности GPU, с которыми обычно имеет дело "программист, пишущий 3д движки"...
> Где я написал что он должен всё это знать ? Он должен "ответить на вопрос". А для этого знать нужно очень мало.
Я совершенно не принимаю такие словесные игры. Вы уж простите ... и прекращайте.
Дальше все спорно, но версия имеет право на жизнь. Поехали. Сеть:
- Почему не используют OSPF или EGMP для межпровайдерной маршрутизации?
- Почему не может существовать сети с маской 255.255.255.224 и адресом сети 192.168.0.16 ?
- Объясните как работает серверное приложение на базе конечного автомата и основные плюсы и минусы такого решения по сравнению с другими (какими?).
Первый вопрос, думаю, того же уровня что и ваш. А вот второй и третий полегче будут ...
Я совершенно не принимаю такие словесные игры. Вы уж простите ... и прекращайте.
Дальше все спорно, но версия имеет право на жизнь. Поехали. Сеть:
- Почему не используют OSPF или EGMP для межпровайдерной маршрутизации?
- Почему не может существовать сети с маской 255.255.255.224 и адресом сети 192.168.0.16 ?
- Объясните как работает серверное приложение на базе конечного автомата и основные плюсы и минусы такого решения по сравнению с другими (какими?).
Первый вопрос, думаю, того же уровня что и ваш. А вот второй и третий полегче будут ...
- OSPF использует Дейкстру для того чтобы уравлять роутингом, так что возникают проблемы с ресурсами, но есть у него и другие проблемы. Хотя на самом деле главная проблема в том что просто когда вопрос встал то было проще перейти от IGP к BGP чем придумать реализацию OSPF, которая бы скалировалась на весь Internet. К тому же BGP легко позволяет врать (не передавать соседям полную информацию о своей связности) и он остается при этом работоспособен, а с OSPF это сложнее.
- EGMP ? Если вы от "Ethernet Group Membership Protocol" (никакого другого EGMP, увы, не знаю) - то у него вообще ограничений масса (прямо из названия понятно)...
- 192.168.0.18&~255.255.255.224=0.0.0.16, а должно быть 0 (хотя это хороший вопрос для админа, а не для программиста: чистый вопрос на знание)
- последнего вопроса не понял, но наверное имеется ввиду CISCO/NGINX/TUX vs Apache/MySQL ? в первом случае одна нить обрабатывает десятки заданий - для этого нужно представить обработку каждого запроса как конечный автомат и аккуратно следить за состояниями оного, во втором - одна нить обслуживает одного клиента. Первый вариант требует меньше ресурсов, но гораздо сложнее в написании и отладке (в случае сложных сервисов большой проблемой становится влияние разных запросов друг на друга).
Не вижу в чём проблема с вашими вопросами: 1й и 3й хорошие вопросы чтобы поговорить о них с пристрстием (там есть о чём поговорить), 2й - простой тест на знание TCP/IP (в принципе какое-то понятие о нём у программиста должно быть, хотя не знаю - насколько оно реально нужно: ЭТА деталь из TCP/IP "наверх" почти никогда "наверх" не протекает)...
- EGMP ? Если вы от "Ethernet Group Membership Protocol" (никакого другого EGMP, увы, не знаю) - то у него вообще ограничений масса (прямо из названия понятно)...
- 192.168.0.18&~255.255.255.224=0.0.0.16, а должно быть 0 (хотя это хороший вопрос для админа, а не для программиста: чистый вопрос на знание)
- последнего вопроса не понял, но наверное имеется ввиду CISCO/NGINX/TUX vs Apache/MySQL ? в первом случае одна нить обрабатывает десятки заданий - для этого нужно представить обработку каждого запроса как конечный автомат и аккуратно следить за состояниями оного, во втором - одна нить обслуживает одного клиента. Первый вариант требует меньше ресурсов, но гораздо сложнее в написании и отладке (в случае сложных сервисов большой проблемой становится влияние разных запросов друг на друга).
Не вижу в чём проблема с вашими вопросами: 1й и 3й хорошие вопросы чтобы поговорить о них с пристрстием (там есть о чём поговорить), 2й - простой тест на знание TCP/IP (в принципе какое-то понятие о нём у программиста должно быть, хотя не знаю - насколько оно реально нужно: ЭТА деталь из TCP/IP "наверх" почти никогда "наверх" не протекает)...
2-й вопрос действительно из разряда теории построения сетей на основе стека протоколов TCP/IP, он для админа годиться.
А вот последний вопрос действительно интересный касаемый сетевого программирования и опять же взят из книжки Стивенса того же. Где рассматриваются реализации приложений многопоточных и однопроцессорных(fork)
А вот последний вопрос действительно интересный касаемый сетевого программирования и опять же взят из книжки Стивенса того же. Где рассматриваются реализации приложений многопоточных и однопроцессорных(fork)
Аббревиатуру EGMP я перепутал с [E]IGRP, сорри.
Ответы нормальные, придираться не буду.
Ответы нормальные, придираться не буду.
А не могли бы вы объяснить ПОЧЕМУ Intel в своем Larabee будет использовать трасировку лучей (это же она? ) в качестве основного инструмента?
Хоть по-моему понял — вы имели ввиду именно текущие видеокарты, но тем не менее это уж точно не то что надо знать программисту работающему где-нибудь в гугле и разрабатывающему поисковый движок или BigTable.
Хоть по-моему понял — вы имели ввиду именно текущие видеокарты, но тем не менее это уж точно не то что надо знать программисту работающему где-нибудь в гугле и разрабатывающему поисковый движок или BigTable.
А не могли бы вы объяснить ПОЧЕМУ Intel в своем Larabee будет использовать трасировку лучей (это же она? ) в качестве основного инструмента?Могу. Легко. Потому что маркетологи не обладают знаниями необходимыми для того, чтобы понять что этого не может быть. Потому фраза «Larrabee настолько крут что может даже обрабатывать простые сцены методом трассировки лучей в режиме реального времени» переродилась в их сознании в «Larrabee будет в основном заточен под использование трассировки лучей». И этот бред растиражировали в сотнях изданий, так что даже увещевания разработчиков которые прямым текстом говорят, что без сомнения Larrabee — самая крутая железяка для трассировки лучей, которая у нас есть… но эта функция абсолютно не является фокусом разработки Larrabee — и никогда не была фокусом — даже на мгновенье… это всеми фанатами игнорируется. Потому что люди хотят верить в чудо. А чуда не случится пока не будет изменена работа с памятью — и притом серъёзно изменена. Этого Larrabee не обещает. И не может обещать — потому что разрабатывают его (насколько мне известно) неплохие разработчики — и они знают чего в природе бывает, а чего нет.
точно не то что надо знать программисту работающему где-нибудь в гугле и разрабатывающему поисковый движок или BigTableЕсли программист, работающий в Гугле и разрабатывающий движок или BigTable не может за 15 прикинуть на листке бумаги — где будет «узкое место» в алгоритме рейтрейсинга реализованного в Larrabee и чем всё это ограничится, то зря его взяли в эту команду. Ибо и там и там самая главная задача одна — понять сколько информации и как именно нам надо прокачать через систему и понять — пролезет эта информация туда или нет.
Отвечу почему мне не нравится вариант с трассировкой лучей — для нахождения узкого места данной технологии требуется знать как минимум знание физики. И уж точно оно для большинства не является требуемым.
Да, кому-то нужно знание технологии вплоть до железа, НО не всем. и очень далеко не всем.
Я не спорю, что хороший программист должен уметь прикинуть чтолибо, оценить итд. Но нестолько насколько это пишете вы. Так мне кажется.
Да, кому-то нужно знание технологии вплоть до железа, НО не всем. и очень далеко не всем.
Я не спорю, что хороший программист должен уметь прикинуть чтолибо, оценить итд. Но нестолько насколько это пишете вы. Так мне кажется.
Зачем, например, web-программисту нужно знать, как устроена видеокарта? Чем это знание полезней, чем география Австралии, например?
Просто любое рациональное обоснование.
Просто любое рациональное обоснование.
Да низачем, в общем-то. Но дело в том что для ответа на этот вопрос нужно знать два с половиной факта:
1. Видеокарты используют очень широкую шину
2. Видеокарты используют много параллельных конвееров для рассчёта 3D
3. Видеопамять оптимизирована под большую пропускную способность и [относительно] большие задержки (во-первых это уже не так важно, а во-вторых можно догадаться про это из пункта 1)
Положа руку на сердце: вы действительно этих фактов не знаете ? Это как с задачами про мячики для гольфа, блендеры, мосты и прочее: формально про свойства этих объектов вы знать ничего не должны, но если вы совсем ничего про них не знаете - это вызывает недоумение. То же и с видеокартой: чтобы ответить на вопрос про неё знать нужно очень мало - примерно столько сколько знает нормальный человпек, который ежедневно общается с компьютером или даже чуть меньше (более подробные знания устройства видеокарты, конечно, помогут, но они не нужны!!!)...
1. Видеокарты используют очень широкую шину
2. Видеокарты используют много параллельных конвееров для рассчёта 3D
3. Видеопамять оптимизирована под большую пропускную способность и [относительно] большие задержки (во-первых это уже не так важно, а во-вторых можно догадаться про это из пункта 1)
Положа руку на сердце: вы действительно этих фактов не знаете ? Это как с задачами про мячики для гольфа, блендеры, мосты и прочее: формально про свойства этих объектов вы знать ничего не должны, но если вы совсем ничего про них не знаете - это вызывает недоумение. То же и с видеокартой: чтобы ответить на вопрос про неё знать нужно очень мало - примерно столько сколько знает нормальный человпек, который ежедневно общается с компьютером или даже чуть меньше (более подробные знания устройства видеокарты, конечно, помогут, но они не нужны!!!)...
На самом деле первого предложения достаточно. Незачем - так незачем. (К вопросу о рейтресинге - а чем вышеприведенные факторы делают его невозможным? Я ежедневно общаюсь с компом, более того, когда-то интересовался рейтресингом как таковым.)
На самом деле ваша идея правильна, но пример категорически не подходит. Нужно знать основной стек технологии, с которой работаешь, а также основы. Архитектура видеокарты - явно побочная ветвь.
На самом деле ваша идея правильна, но пример категорически не подходит. Нужно знать основной стек технологии, с которой работаешь, а также основы. Архитектура видеокарты - явно побочная ветвь.
Рейтрейсинг на мало-мальски сложных объектах приводит к достаточно случайным обращениям к разным частям модели. Против этого восстаёт вся "потоковая" организация видеокарты (да и современных CPU, если уж на то пошло: никогда не задумывались почему RayTracing считают на кластерах и никогда - на суперкомпьютерах?)... Да, некоторые приёмы могут снизить эту проблему - но в едва достаточной степени чтобы его можно было эффективно на CPU исполнять (и даже там латентность памяти частенько доминирует), а его архитектура куда менее "заточена" под потоковые исполнения...
я думаю нет смысла доказывать вебмастерам, что такое многопоточное, параллелизм и т.д. Если они желают предел в своей з.п в 1000$ то им это не надо
Не много грубовато с вашей стороны. Так уж получилось, что по образованию я железячник(хотя и работаю вебпрограммером) и потому большую часть из примеров знаю. Но меня этому учили.
Я знаю людей которые в своей области то что называется Гуру. Именно за счет умения воспринимать новую информацию и умению правильно распределять свое время. Те знания которые вы считаете фундаментальными, у них если и есть то появлялись в основном из случайных источников.
ЗЫ: И зарплаты у них на много выше килобакса при проживание совсем не в столицы нашей родины.
ЗЫ2: Отсутствие каких то знаний с лихвой компенсируются умением быстро найти и применить. Инет рулит
Я знаю людей которые в своей области то что называется Гуру. Именно за счет умения воспринимать новую информацию и умению правильно распределять свое время. Те знания которые вы считаете фундаментальными, у них если и есть то появлялись в основном из случайных источников.
ЗЫ: И зарплаты у них на много выше килобакса при проживание совсем не в столицы нашей родины.
ЗЫ2: Отсутствие каких то знаний с лихвой компенсируются умением быстро найти и применить. Инет рулит
Не понимаю почему вы думаете что фреймворк может избавить от необходимости знания языка, он просто избавляет от необходимости изобретать велосипед в каждом проекте и уменьшает количество кода (чем меньше кода тем проще написать и протестировать), к тому же позволяет использовать код протестированный армией программеров вместо своих велосипедов с кривыми колесами (выравнивание колес иногда требует больше усилий чем сам проект).
Конкретно в JavaScript фреймворки избавляют от проблем кроссбраузерности, с одними событиями проблем куча и, к несчастью, не с ними одними.
Конкретно в JavaScript фреймворки избавляют от проблем кроссбраузерности, с одними событиями проблем куча и, к несчастью, не с ними одними.
Вот она "власть большинства". Человека, открывшего глаза многим программистам на истинное поведение ECMA и прочих script, минусует за совершенно обоснованный комментарий, сообщество js-непрофессионалов.
Наверное все таки стоило привести пару примеров из кода jQuery
Наверное все таки стоило привести пару примеров из кода jQuery
Ваше право не любить надстройки над "старым добрым J(ava)Script", но я, как серверный программер, ненавижу JScript, потому, что написанный код не работает одинаково во всех браузерах.
Данную библиотеку склонен рассматривать, как базу знаний о различиях разных браузеров и буду использовать хотя бы для того, чтобы исключить разночтения(разноинтерпретации) моей программы.
А по поводу псевдокода приведу контрпример: Был машинный код, появился ASM...
После ASMа появился..., короче, дошло дело до JScript и на этом не остановится...
Данную библиотеку склонен рассматривать, как базу знаний о различиях разных браузеров и буду использовать хотя бы для того, чтобы исключить разночтения(разноинтерпретации) моей программы.
А по поводу псевдокода приведу контрпример: Был машинный код, появился ASM...
После ASMа появился..., короче, дошло дело до JScript и на этом не остановится...
Не стоит мифологизировать или идеализировать кроссбраузерность фреймворков. Несмотря на то, что действительно фреймворки считают эту тему важнейшей и на неё упирают рогом в расчёте на свою универсальность, нельзя однозначно сказать, что фреймворки в этом вопросе ушли дальше не-фреймворков. Они приблизительно там же, где и все, кто пишет кроссбраузерно. Там нет марсианского кода, он не зашифрован энигмой, просто посмотрите на него, если вы программируете плотно на js, то все эти решения, только вид сбоку, вы уже должны были видеть раньше не-о-дно-кра-тно.
Ничего не должно вам помешать воплотить кроссбраузерность самостоятельно в лучшем качестве, с оглядкой на свои задачи, без копирования местами слабого кода фреймворка. Это не изобретение велосипеда, если кто-то говорит про велосипед - это значит, что он знает про него всё, а если он знает всё, то должен видеть в любом фреймворке недостающие детали - педали, цепь, а иногда и колёса. В этом смысле лучше изобрести велосипед самому (не заново, а в первый раз) и обращаться при этом лучше к той же "базе знаний", откуда черпают свои решения и создатели фреймворков - к google.com ;) . Хотя, объективности ради нужно сказать, что изучение любой либы может быть полезным...
Что касается псевдокода, то ваш контрпример я учёл, но он меня не разубедил, с jQuery это как-то не вяжется...
Ничего не должно вам помешать воплотить кроссбраузерность самостоятельно в лучшем качестве, с оглядкой на свои задачи, без копирования местами слабого кода фреймворка. Это не изобретение велосипеда, если кто-то говорит про велосипед - это значит, что он знает про него всё, а если он знает всё, то должен видеть в любом фреймворке недостающие детали - педали, цепь, а иногда и колёса. В этом смысле лучше изобрести велосипед самому (не заново, а в первый раз) и обращаться при этом лучше к той же "базе знаний", откуда черпают свои решения и создатели фреймворков - к google.com ;) . Хотя, объективности ради нужно сказать, что изучение любой либы может быть полезным...
Что касается псевдокода, то ваш контрпример я учёл, но он меня не разубедил, с jQuery это как-то не вяжется...
Эх в рельсах прототайп :(, так что жикуери придется пока обойдти стороной.
Очень интересная статья. Опечатка: "сокращение, н оесли".
тоже использую jquery на нашем сайте. в данный момент жду багфикса и нового релиза. есть определенно проблема с событием document.ready в IE, когда страница долго грузится из-за баннеров. альтернативного решения я пока не нашел =(
В MS IE через document.readyState можно отловить момент когда страница уже загружена, хотя картинки, может быть, и нет. В Firefox нужно ловить событие "DOMContentLoaded" (правда в ним не всё гладко: в некоторых случаях событие может посылаться до загрузки всей страницы если страница очень большая и очень долго грузится, так что нужно ввести дополнительную проверку - скажем завести переменную document.FullyLoaded перед тегом и отлавливать её инициализацию)...
у меня почему-то все наоборот. в ИЕ jQuery ждет когда все загрузится и не хочет работать до этого. У нас есть некоторые баннеры, которые почему-то в последнее время долго загружаются. Самое что интересно, не везде долго грузятся. Мы тестировали на разных машинах, каналах. Результат везде разный. в ФФ все нормально у всех.
John Resig писал в гугл-группе что такой баг замечен, вроде пофиксили, но релиз ещё не вышел
John Resig писал в гугл-группе что такой баг замечен, вроде пофиксили, но релиз ещё не вышел
ссылка "Вставить jQuery" в разделе "Чего-нибудь с ними делаем" битая.
Господа, а простейшую проверку для формы как самому нагородить с помощью этой библиотеки, все решения, которые находил - уж очень тяжёлые, ещё 2-3 лишних скрипта подключать, покажите пример, как, например, проверить email на валидность.
попробуйте гугль
если не знаете что такое "регулярные выражения" будет повод узнать :)
для поиска готового решения добавьте в поисковый запрос JS или JavaScript
если не знаете что такое "регулярные выражения" будет повод узнать :)
для поиска готового решения добавьте в поисковый запрос JS или JavaScript
Да нувас :) Про регулярные выражения я слышал, конечно, но самому что-то на них сделать - это не знаю, как надо постараться, "я в этом деле не копенгаген" (с), просто хотел бы видеть пример.
Посмотрите в plugins для форм. Там несколько готовых решений.
ай, глупости говорите. стараться не надо, надо не бояться :)
с ними очень удобно работать, особенно если под рукой имеется regexBuddy и Expresso.
а готовые решения в выдаче гугля тоже присутствуют, в том числе и на JS:
http://javascript.internet.com/forms/ema…
http://javascript.internet.com/forms/che…
http://www.4guysfromrolla.com/webtech/05…
ну и дальше по списку
с ними очень удобно работать, особенно если под рукой имеется regexBuddy и Expresso.
а готовые решения в выдаче гугля тоже присутствуют, в том числе и на JS:
http://javascript.internet.com/forms/ema…
http://javascript.internet.com/forms/che…
http://www.4guysfromrolla.com/webtech/05…
ну и дальше по списку
Разъясните, пожалуйста, как приведённые вами примеры используют JQuery?
Никак ибо даже при наличии очень хорошей электрифицированной отвертки гвозди приходится вколачивать молотком...
jQuery можно использовать для того чтобы вызвать в нужный момент валидатор - а собственно проверка она чисто на JS пишелся. Но все эти решения, которые создают framework для проверки форм вам кажутся слишком тяжёлыми...
jQuery можно использовать для того чтобы вызвать в нужный момент валидатор - а собственно проверка она чисто на JS пишелся. Но все эти решения, которые создают framework для проверки форм вам кажутся слишком тяжёлыми...
>Господа, а простейшую проверку для формы как самому нагородить с помощью этой библиотеки,
"ЭТОЙ" заметил только после Вашего вопроса. изначально прочитал с точностью до наоборот, т.е. просто - "простейшую проверку для формы"
:"(
"ЭТОЙ" заметил только после Вашего вопроса. изначально прочитал с точностью до наоборот, т.е. просто - "простейшую проверку для формы"
:"(
Засорение глобального адресного пространства? Видимо, при использовании нескольких разнородных библиотек в качестве базы (что есть извращенство).
Вообще, кто-нибудь сталкивался с такой проблемой?
Вообще, кто-нибудь сталкивался с такой проблемой?
Знаете, совсем не обязательно извращенство.
Библиотек много хороших и разных. Начиная с известных, вроде той, которая описана в статье, и заканчивая своими личными. На своём опыте убедился, что в больших проектах после подключения библиотек, начинаешь больше времени думать над тем, как назвать очередную функцию.
Использование нэймспейсов самый очевидный выход. И код, кстати, приобретает человекоупотребимый вид. Инкапсуляция — наше всё )
Библиотек много хороших и разных. Начиная с известных, вроде той, которая описана в статье, и заканчивая своими личными. На своём опыте убедился, что в больших проектах после подключения библиотек, начинаешь больше времени думать над тем, как назвать очередную функцию.
Использование нэймспейсов самый очевидный выход. И код, кстати, приобретает человекоупотребимый вид. Инкапсуляция — наше всё )
Я говорил о базовой функциональности расширении ядрёных объектов, системных фичах. Ипользовать здесь несколько разнородных библиотек, какими бы хорошими они ни были, мне кажется странным и без напильника не выполнимым.
Расширение остальной функциональности пожалуйста. Хорошо разложенная по классам она вызывать проблем, вроде, не должна.
Расширение остальной функциональности пожалуйста. Хорошо разложенная по классам она вызывать проблем, вроде, не должна.
Это известная проблема. По-моему, об этом пишут даже в JavaScript Essentials book.
На прагматичном уровне для меня засорение глобального пространства имён резко сказывается на производительности и на отладке.
На прагматичном уровне для меня засорение глобального пространства имён резко сказывается на производительности и на отладке.
отличная вводная статья
http://www.rsdn.ru/article/inet/jQuery.xml
она есть и на jquery.com
http://www.rsdn.ru/article/inet/jQuery.xml
она есть и на jquery.com
sunnybear, большое спасибо за отличную статью.
С jQuery ещё не сталкивался, пользовался Mootools и немного Prototype (но отказался из-за большого размера и не слишком изящных решений), но сейчас очень хочу попробовать именно jQuery. Ряд решений выглядят действительно удобными и иновационными.
С jQuery ещё не сталкивался, пользовался Mootools и немного Prototype (но отказался из-за большого размера и не слишком изящных решений), но сейчас очень хочу попробовать именно jQuery. Ряд решений выглядят действительно удобными и иновационными.
Использую jQuery вместе с prototype. prototype для работы с AJAX. А для jQuery написано множество готовых плагинов. По поводу размера - prototype можно ужать любой из js-ужималок до тех же 25-30kb. По скорости prototype по многим критериям превосходит и jQuery, и mootools. (Тест). Перешел бы полностью на jQuery, но как-то уж сильно привык к prototype.
Отличный тест! Скопировал себе локально (и добавил еще новый JQuery 1.2). Запускал в IE6, FF2 и Opera 9.
jquery 1.2 очень немного не дотягивает по скорости к jquery 1.1.3.
А вот что очент интересно, prototype и mootools лидируют в FF2 и O9 (отрываются на ~500 мс по сравнению с jquery 1.1.3)
Зато jquery 1.1.3 лидирует в IE6 (и отрывается здесь на ~2,500 мс по сравнению с prototype и mootools!!!)
Так что выходит что в среднем (взвешенном) по браузерам jquery лидер. А особенно учитывая долю IE на рынкею
jquery 1.2 очень немного не дотягивает по скорости к jquery 1.1.3.
А вот что очент интересно, prototype и mootools лидируют в FF2 и O9 (отрываются на ~500 мс по сравнению с jquery 1.1.3)
Зато jquery 1.1.3 лидирует в IE6 (и отрывается здесь на ~2,500 мс по сравнению с prototype и mootools!!!)
Так что выходит что в среднем (взвешенном) по браузерам jquery лидер. А особенно учитывая долю IE на рынкею
Prorotype никак не превосходит jQuery. У нас в компании раньше использовали Prototype+Srcipt.aculo.us, и ничего, весь код спокойно переписывается на jQuery + plugins. Никаких невозможных для перевода частей не обнаружено, всё, наоборот, становится читаемей и компактнее - что просто удивительно. Причём переход происходит постепенно и быстро.
В этом отношении большой респект jQuery.noConflict().
В этом отношении большой респект jQuery.noConflict().
Не знаю, к чему вся эта демагогия была разведена. Моя веб-студия использует и джей квери, и мутулс, и прототайп. Все работает, клиенты довольны, мы тоже довольны. Конечно, можно было бы и без всего этого обойтись. Но без АЯКСА НИКУДА!!!
Что касается именно jQuery - очень отлично-прекрасная штука, однозначно.
Что касается именно jQuery - очень отлично-прекрасная штука, однозначно.
Одна вкусность, о которой умалчивается в статье: функцию jQuery(document).ready можно вызывать по нескольку раз на странице, при этом ничего не теряя.
Очень удобно, если сборка страницы идет из нескольких шаблонов: для общих событий вставляем jQuery(document).ready в самом элементе HEAD в каком-нибудь header.tpl, а ниже вызываем её-же для событий конкретной страницы, index.tpl например.
Помню до jquery по этому поводу приходилось извращаться вроде:
Очень удобно, если сборка страницы идет из нескольких шаблонов: для общих событий вставляем jQuery(document).ready в самом элементе HEAD в каком-нибудь header.tpl, а ниже вызываем её-же для событий конкретной страницы, index.tpl например.
Помню до jquery по этому поводу приходилось извращаться вроде:
document.onload = function(){
document.onload();
//еще действия
}
Поясните, пожалуйста, смысл бесконечного рекурсивного вызова.
Также, вы знакомы с DOM-моделью событий?
Также, вы знакомы с DOM-моделью событий?
Тут ключевое слово не вызов, а переопределение. Поясняю:
Например есть у нас необходимость на всех страницах сайта провести некоторые манипуляции, и, среди прочих, окрасить ссылки в синий цвет:
И, как всегда нежданно-негаданно, выясняется, что на новоиспеченной странице фотогалереи надо к ссылкам еще и атрибут rel добавить, а возможность залезть в изначальную onload уже нет. Поэтому переопределяем её, да так, чтоб не потерять исходный код (см. выше) Это примитивный пример. После 2-3 таких случаев, начинаем использовать addLoadEvent
Так вот отсутствие этой необходимости в jquery очень порадовало меня лично. Насколько я помню в прототайпе годичной давности такого не было. Как (почему-то) не было и простейшей trim() и еще всяких мелочей. Как сейчас там обстоят дела, честно сказать, не знаю, уже более полугода кроме jquery ничем не пользуюсь.
Например есть у нас необходимость на всех страницах сайта провести некоторые манипуляции, и, среди прочих, окрасить ссылки в синий цвет:
document.onload = function(){
//do stuff
paintLinksBlue();
//do more stuff
}
И, как всегда нежданно-негаданно, выясняется, что на новоиспеченной странице фотогалереи надо к ссылкам еще и атрибут rel добавить, а возможность залезть в изначальную onload уже нет. Поэтому переопределяем её, да так, чтоб не потерять исходный код (см. выше) Это примитивный пример. После 2-3 таких случаев, начинаем использовать addLoadEvent
Так вот отсутствие этой необходимости в jquery очень порадовало меня лично. Насколько я помню в прототайпе годичной давности такого не было. Как (почему-то) не было и простейшей trim() и еще всяких мелочей. Как сейчас там обстоят дела, честно сказать, не знаю, уже более полугода кроме jquery ничем не пользуюсь.
в общем-то я использую Prototype, jQuery как работает себе представлял, но ни разу не использовал.
сейчас вот прочел статью, спасибо sunnybear, и окончательно решил, что это не для меня.
с jQuery JS это уже не JS. это даже не программирование, это составление приложения. Ну, что-то вроде Visual Basic... когда всё настолько заморочено, становится уже неинтересно.. сам процесс _поиска решения и его воплощения_ теряет смысл.. остается только прописать jQuery('bla').bla('bla') и т.д.. это скучно и однообразно.
считаю, что главное отличие Prototype от jQuery в том, что первый не меняет _концепцию программирования_. Он не меняет меня самого, он просто избавляет меня от рутинной работы. Но когда я пишу и использую prototype, я чувствую, что пишу _я_, а мне помогают. А когда видишь, что делается с помощью jQuery, чувтствуешь, что ты не _пишешь_, ты _составляешь код_. я бы это назвал так. в общем для меня в программировании главное программирование, а поэтому пока не вижу для себя повода для использования этого фреймворка.
Главное в Prototype - это набор полезных методов, по какой-то причине отстутствующих в JavaScript, которые раньше были точно такими же, но приходилось писать их замены самому, а теперь они все в лучшем виде собраны в отдельном .js-файле.
А jQuery - это нечто большее, изменяющее сам JavaScript.. и я не уверен, нужно это или нет.
сейчас вот прочел статью, спасибо sunnybear, и окончательно решил, что это не для меня.
с jQuery JS это уже не JS. это даже не программирование, это составление приложения. Ну, что-то вроде Visual Basic... когда всё настолько заморочено, становится уже неинтересно.. сам процесс _поиска решения и его воплощения_ теряет смысл.. остается только прописать jQuery('bla').bla('bla') и т.д.. это скучно и однообразно.
считаю, что главное отличие Prototype от jQuery в том, что первый не меняет _концепцию программирования_. Он не меняет меня самого, он просто избавляет меня от рутинной работы. Но когда я пишу и использую prototype, я чувствую, что пишу _я_, а мне помогают. А когда видишь, что делается с помощью jQuery, чувтствуешь, что ты не _пишешь_, ты _составляешь код_. я бы это назвал так. в общем для меня в программировании главное программирование, а поэтому пока не вижу для себя повода для использования этого фреймворка.
Главное в Prototype - это набор полезных методов, по какой-то причине отстутствующих в JavaScript, которые раньше были точно такими же, но приходилось писать их замены самому, а теперь они все в лучшем виде собраны в отдельном .js-файле.
А jQuery - это нечто большее, изменяющее сам JavaScript.. и я не уверен, нужно это или нет.
большое спасибо за статью!
интересует, а есть ли в jQuery обработчик события для input поля типа onblur или onchange?
Есть оба.
http://docs.jquery.com/Events
http://docs.jquery.com/Events
Возникла проблема.
Есть xhtml
<table class="t_des dtable" cellspacing="5">
<tr>
<th>Строка/Столбец</th>
<th>Столбец 1</th>
<th>Столбец 2</th>
<th>Столбец 3</th>
</tr>
<tr>
<td>Строка1</td>
<td>1</td>
<td>2</td>
<td>3</td>
</tr>
</table>
Нужно проитись по всем ht.
Включаем js файл :
$(document).ready(init);
var init= new function (){
create_d_table('dtable');
}
function create_d_table(class){
$('table.'+class).css("background-color", "#000");;
}
В итог ошибка firebug
f has no properties
ready()jquery.js (line 27)
ready()jquery.js (line 27)
nodeName([function()], function(), undefined)jquery.js (line 20)
ready()jquery.js (line 27)
[Break on this error] jQuery.readyList.push(function(){return f.apply(this,[jQuery]);});return this;}}...
Есть xhtml
<table class="t_des dtable" cellspacing="5">
<tr>
<th>Строка/Столбец</th>
<th>Столбец 1</th>
<th>Столбец 2</th>
<th>Столбец 3</th>
</tr>
<tr>
<td>Строка1</td>
<td>1</td>
<td>2</td>
<td>3</td>
</tr>
</table>
Нужно проитись по всем ht.
Включаем js файл :
$(document).ready(init);
var init= new function (){
create_d_table('dtable');
}
function create_d_table(class){
$('table.'+class).css("background-color", "#000");;
}
В итог ошибка firebug
f has no properties
ready()jquery.js (line 27)
ready()jquery.js (line 27)
nodeName([function()], function(), undefined)jquery.js (line 20)
ready()jquery.js (line 27)
[Break on this error] jQuery.readyList.push(function(){return f.apply(this,[jQuery]);});return this;}}...
подозреваю, что основная проблема в вызове сторонних функций, ибо вот такой подход
срабатывает
$(document).ready(function(){$('table.dtable').css("background-color", "#000")});срабатывает
Очень просто.
var init = function() {
create_d_table('dtable');
}
function create_d_table(class) {
$('table.'+class).css("background-color", "#000");
}
$(document).ready(init);
Я с презрением отношусь ко всяческим либам, но почитав статью, думаю рискну и попробую jQuery. Спасибо!
Все, конечно, хорошо, библиотека удобная.
НО! стоит помнить следующее:
jQuery работает в IE начиная с версии 6 и выше.
В 5 она не работает совсем.
В 5.5 работает в неполной реализации. Например, там не работает ajax
НО! стоит помнить следующее:
jQuery работает в IE начиная с версии 6 и выше.
В 5 она не работает совсем.
В 5.5 работает в неполной реализации. Например, там не работает ajax
Те кто пользуетс IE5.5 сами в этом виноваты :)
Это неправильная позиция.
Продуманная библиотека должна поддерживать работу с распространенными браузерами, точнее говоря с версиями яваскрипт не только 1.5, но и 1.2
Это не так уж и сложно.
Прототайп, кстати говоря с IE 5.5 работает.
Продуманная библиотека должна поддерживать работу с распространенными браузерами, точнее говоря с версиями яваскрипт не только 1.5, но и 1.2
Это не так уж и сложно.
Прототайп, кстати говоря с IE 5.5 работает.
Если честно, то с прототайпом не работал. А от оЙгукн не хочу отказываться по причинами:
1. Скорость написания скриптов по взаимодействию объектов сократилась в разы
2. Хорошая документация, хотя ижаль, что нет свежей offline версии
3. Большое быстропомогающее community, хоть и на английском языке, но все равно полезно
А по поводу IE5.5 - это меньше половины процента от всех посетителей сайта
http://clip2net.com/clip/m2737/1199349055-3a56c-12kb.png
Так что, не вижу смысла подстраиваться под столь малое меньшинство. Хотя, конечно, если речь зайдет о написании какого-то скрипта для аудитории, которая сидит на этом диназавре, то напишем в меру технических возможностей.
1. Скорость написания скриптов по взаимодействию объектов сократилась в разы
2. Хорошая документация, хотя ижаль, что нет свежей offline версии
3. Большое быстропомогающее community, хоть и на английском языке, но все равно полезно
А по поводу IE5.5 - это меньше половины процента от всех посетителей сайта
http://clip2net.com/clip/m2737/1199349055-3a56c-12kb.png
Так что, не вижу смысла подстраиваться под столь малое меньшинство. Хотя, конечно, если речь зайдет о написании какого-то скрипта для аудитории, которая сидит на этом диназавре, то напишем в меру технических возможностей.
Пользователей E 5.x даже microsoft давно не принимает в расчёт (их сайты под ним не пашут корректно).
Их доля меньше 2%.
Их доля меньше 2%.
Сталкнулся с такой проблемой рпи использовании jQuery:
По одному событию происходит несколько эффектов с разными обьектами, хотелось бы выполнять их последовательно, однако jQuery их параллелит, каким образом выполнить их поочереди?
Подскажите, плиз, кто знает.
Пример кода:
$(".princip").click(function(){
$("div.krug").find("img").animate({left: "0"}, 500) // 1-е
var largePath = $(this).attr("href");
$("#plbg").attr({src: largePath}) // 2-е
$("#earth1").animate({left: "170"}, 1300) // 3-е
return false;
});
По одному событию происходит несколько эффектов с разными обьектами, хотелось бы выполнять их последовательно, однако jQuery их параллелит, каким образом выполнить их поочереди?
Подскажите, плиз, кто знает.
Пример кода:
$(".princip").click(function(){
$("div.krug").find("img").animate({left: "0"}, 500) // 1-е
var largePath = $(this).attr("href");
$("#plbg").attr({src: largePath}) // 2-е
$("#earth1").animate({left: "170"}, 1300) // 3-е
return false;
});
Спасибо огромное. Разрабатывая все более громоздкие системы приходит идея о переходе на какой-то фреймворк. Данная статья помогла мне определить на какой фрейм ворк все-таки перейти;) благодарю)добавил в избранное.
Вопрос по селекторам. Допустим, такой XML приходит от сервера в callback ф-ию ajax-овского get запроса:
Как выбрать элементы account, являющиеся непосредственными детьми ноды account? Т.е. id 1 и 3.
Такой xpath не работает:
Такой
<?xml version="1.0" encoding="UTF-8"?>
<accounts>
<account id="1">
<account id="2"/>
</account>
<account id="3"/>
</accounts>
Как выбрать элементы account, являющиеся непосредственными детьми ноды account? Т.е. id 1 и 3.
Такой xpath не работает:
function(xml) {
elements = $("/accounts/account");
}
Хотя, должен бы. Как ни бился, не смог получить детей ни через xpath, ни через xss селекторы.Такой
elements = $("account"); возвращает все элементы account, т.е. id 1, 2 и 3.И ещё вопрос: callback ф-ии, переданные в ф-ию animate вызываются не после анимации, как всюду в документации написано, а перед ней. Это у всех так или я что-то не так делаю? Даже такой код:
Сначала добавляет « Wow!», только потом скрывает div, и потом снова его показывает.
<div id="d1">Hi there!</div>
<script>
$("#d1").hide("slow").append(" Wow!").show("slow");
</script>
Сначала добавляет « Wow!», только потом скрывает div, и потом снова его показывает.
Респект автору давно искал такую статью!
Sign up to leave a comment.
jQuery для JavaScript-программистов