JavaScript *

В связи с достаточно широким выбором неплохих отладчиков, JavaScript-программисты могут получить достаточно много пользы, изучая то как их можно использовать. Их пользовательские интерфейсы становятся все более совершенными, более стандартизированными между собой и более легкими в использовании, что делает их полезными как для экспертов так и новичков в отладке JS. В этой статье мы обсудим передовые методы отладки для диагностики и анализа ошибок, используя типичное веб-приложение.

В настоящее время средства отладки доступны для всех основных браузеров.

• Firefox имеет хорошо известное расширение Firebug
• IE8 выпускается со встроенными Developer Tools
• Опера 9.5+ поддердивает отладчик Dragonfly
• У Safari есть JS-отладчик Drosera и DOM-вьювер WebInspector. В более свежих версиях отладчик интегрирован в WebInspector.

На данный момент Firebug и Dragonfly наиболее стабильны. Утилиты IE8 иногда игнорируют контрольные точки, а во время написания этой статьи WebInspector имеет некоторые проблемы совмстимости с последними билдами Webkit.

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

Захотелось мне тут для JavaScript perspective в любимом Eclipse заиметь автодополнение функций для jQuery с наличием полной документации. Порыскав в сети, нашёл только jQueryWTP, который даже ставить не хотелось из-за негативных отзывов, и устаревшей версии.
Потому пришлось сделать самостоятельно, и вот результат:

Требования: Eclipse, Web Tools Platform / Zend Studio for Eclipse / Любой редактор с поддержкой JSDoc

P.S. Конечно, есть и другие методы подключения jQuery, например использование NetBeans или плагина Aptana. Так уж получилось, что был выбран именно этот метод :)

Как правильно должен быть написан учебник? Ответ стандартный:
— сначала предмет изучаемой науки;
— затем принципы и методология;
— потом основные разделы;
— потом подразделы каждого раздела;
— и в конце практические детали.

Этот порядок считается классическим, а учебник, написанный таким образом — образцовым.

В своей статье я намерен доказать, что хороший учебник пишется строго задом на перед. А хорошие учебники в области IT тем более. Не зря ведь существует «Hello, World!»

IE='\v'=='v'

Это решение является победителем в соревновании на выявление самого короткого способа определения IE.

Некий Shaun Friedle написал любопытный javascript который автоматизирует распознавание captcha на megaupload.

Пара любопытных особенностей скрипта:

1. используется HTML 5 функция javascript getImageData для работы с пикселями;
2. используется искусственная нейронная сеть для распознавания и работает довольно точно.

Пример работы: herecomethelizards.co.uk/mu_captcha
Исходник: userscripts.org/scripts/review/38736

После заметки Стыкуем асинхронные скрипты и предложенного решения от Steve Souders я подумал о модульной загрузке какого-то сложного JavaScript-приложения. И понял, что предложенный подход в таком случае будет довольно громоздким: нам нужно будет в конец каждого модуля вставлять загрузчик следующих модулей. А если нам на разных страницах требуются различные наборы модулей и разная логика их загрузки? Тупик?

Ан нет. Не зря Steve упоминает в самом начала своей заметки о событии onload / onreadystatechange для скриптов. Используя их, мы можем однозначно привязать некоторый код к окончанию загрузки конкретного модуля. Дело за малым: нам нужно определить этот самый код каким-либо образом.

Решение первое: дерево загрузки

В качестве наиболее простого способа определить порядок загрузки модулей на конкретной странице можно предложить глобальный массив, содержащий в себе дерево зависимостей. Например, такой:

Недавно на хабре была статья «Когда программисту нечего делать…», вот и у меня такая ситуация но я не просто хочу дать ссылку на Цветные линии, а рассказать как можно самому сделать её. Всем кого интересует добро пожаловать под кат

Периодически натыкаясь на статьи, посвященные оптимизации кода на JS (вот одна из популярных) я ловил себя на мысли, что информации в них катастрофически мало. Перечислены 2-3 конструкции, 1-2 браузера и все на этом.

Как говорится, если хочешь сделать что-то хорошо, сделай это сам.
Я решил протестировать, в первую очередь для себя, скорость работы различных языковых конструкций (начиная с самых базовых) в основных современных браузерах и на основе этого сделать выводы о том, что и как использовать в скриптах, требовательных к производительности.

Ну и раз уж результаты получены, почему бы не выложить их для всеобщего пользования?

Upd: добавил графики результатов, предоставленные хабраюзером deerua (для тех, кто воспринимает визуальную подачу информации лучше чем табличную)

В этой статье я хочу по возможности полно и последовательно рассказать о том, что такое объект в JavaScript, каковы его возможности, какие взаимоотношения могут строиться между объектами и какие способы «родного» наследования из этого вытекают, как это все влияет на производительность и что вообще со всем этим делать :)

В статье НЕ будет ни слова про: эмуляцию традиционной класс-объектной парадигмы, синтаксический сахар, обертки и фреймворки.

Сложность материала будет нарастать от начала к концу статьи, так что для профи первые части могут показаться скучными и банальными, но дальше будет намного интереснее :)

… он возьмет и сделает бесполезную ерунду вечерком, просто так, для себя. Недоработано, сыро и не поддерживает оперу, извиняюсь, конечно, но мне хотелось спать =)

UPD: Перенес в JavaScript, надеюсь, я все правильно сделал

Привет, хочу представить одну интересную разработку студии, в которой я работаю. И как ведущий разработчик буду её освещать :)

В моем твиттере прошла ссылка на десять JS-фреймворков, которые интересны в плане изучения и расширения возможностей, для того, чтобы разработчики не ограничивались только верхушкой мейнстрима (имеется ввиду jQuery/Prototype/Mootools/YUI). Вполне вероятно, что что-то из этого списка завтра будет не менее популярно, да и просто для повышения своей квалификации или подсматривания интересных решений. Оригинал на английском языке здесь, а я попробую рассмотреть самое интересное со своей колокольни.

Вчера, после прочтения поста Джон Резига, решил записать по горячим следам первый в своей жизни (это я к тому, что сильно ругать не стоит, а конструктивная критика приветствуется :) скринкаст.

Fireunit — это инструмент для тестирования javascript кода, созданный в виде дополнения к firebug'y Джоном Резигом в рамках его сотрудничества с командой firebug. На данный момент, он работает только под ff3+, firebug 1.2+.

Зачем же нужен такой инструмент тестирования, если он работает только в firefox?

1. Fireunit позволяет тестировать очень интересные dom-события — события загрузки и готовности контента, завершнения отрисовки, вроде contentReady
2. Вполне вероятно, что fireunit будет включен в состав (или, по крайней мере, его можно будет установить с) firebug light.
3. Сама идея фреймворка тестирования, встроенного в браузер, является очень привлекательной. Вполне возможно, что производители других браузеров включат аналогичный инмструмент в свои продукты (как уже было с web inspector'ом для webkit, dragonfly для opera, developer toolbar для ie8)

Итак, напишу о том, как пофиксить дрожание в IE при эмуляции position:absolute; (без фоновой картинки), устроить склонение слов, решить проблемы с вопросиками в Mysql и про остальные неважные, но иногда полезные хитрости.
Если Вы матёрый веб-технолог, можете не читать: ничего нового не найдёте.

Захотелось вот что-нибудь для людей сделать.


Оно умеет:

• Ползать
• Дрыгаться
• Разваливаться на листы
• и Менять размер
• а ещё оно разных цветов

Эта статья о мирном атомеXSS. Заставим зло работать на добро!

А зачем?

Простейший пример всё объяснит:
Вы разрабатываете веб-сервис, который поставляет данные другим сайтам (погода, данные по торгам в реальном времени, чат и т.п). Вам нужно организовать кроссайтовую передачу данных(данные погоды, торгов, текст чата) на стороне клиента.

Методы организации XSS

1. Через тэг iframe
2. Через тэг script
3. Через flash<->javascript
4. Через window.name + iframe + form
5. Через CSS хак
6. Через canvas + img
7. Через прокси

Спасибо всем.

Честно, не ожидал настолько позитивного отклика (некоторые даже кинулись внедрять библиотеку в свои проекты и всячески пропагандировать :). Для большей ясности поясню основные идеи:

1. Это мини-ядро. Чтобы выбирать элементы DOM-дерева. На его основе (или дополнительно к нему) можно разрабатывать остальные модули. Но конкретно этот функционал дальше CSS-селекторов расширяться вряд ли будет. Идея ни разу не новая.
2. Это самое быстрое мини-ядро. Каждая строчка тестируется и будет тестироваться на экстремальную производительность в большинстве случаев. Чтобы это можно было положить в основу большого проекта. Иначе все остальное не имеет смысла.
3. Код открытый (MIT + GPL). Можно использовать где угодно (вроде даже без ссылок на авторство). Комментарии по улучшению приветствуются.

После заметки о Peppy я почти обрадовался — вот оно, счастье. Наконец появился движок CSS-селекторов, который делает тоже самое, что и jQuery, только быстрее. Сильно быстрее.

Радоваться было недолго, как только я посмотрел в код, то немного ужаснулся: он не соответствовал моим представлениям об исключительной производительности. Совсем не соответствовал. Точнее, немного удовлетворял, но не до конца. Поэтому сразу встал вопрос: а если быстрее?

Почему нельзя сделать быстрое мини-ядро для CSS-селекторов, которое обеспечит базовую функциональность для работы с DOM (ну, совсем базовую — просто выборку элементов, например)? И, самое главное, чтобы это работало не медленнее (в идеале, даже быстрее), чем нативные вызовы.

Привет.

Наверное, многие из вас пользовались стандартными javascript-виджетами, написанными как безвестными разработчиками, так и крепкими профессионалами, так и гуру. Есть великолепные коллекции виджетов, поставляемых в качестве плагинов к известным фреймворкам (вроде jQuery, Prototype JS, YUI), так и целые фреймворки, акцентирующие свое внимание на создании виджетов, вроде Ext JS или qooXdoo.

Но что, если вы не хотите использовать достаточно объемный фреймворк для создания простого диалогового окна, или хотите разобраться в том, как создаются такие виджеты, или даже разрабатываете собственный фреймворк?

Об этом и пойдет речь в сегодняшнем посте — как сделать простейшее диалоговое окно и alert средствами чистого javascript, без применения каких-либо фреймворков.

Когда то давно, не помню где я читал о том, что обычный скрол можно сделать более функциональным и предлагалось ряд решений.
Мне эти идеи понравились и вот спустя много лет :)…
Предлагаю свою реализацию на javascripte. Идея в том чтобы на фоне скрола показывать эскиз всего текста, а с помощью движка скрола видимую часть текста. При таком подходе сразу видно где находится картинка, заголовок, а где параграф.