Недавно в офисе Хабра я хотел прочитать своим коллегам небольшой доклад об объектной ориентации и наследовании классов в JavaScript.

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

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

Пользуясь тем, что семинар все время откладывается «до следующей пятницы», я решил опубликовать тексты семинара в сети, дабы мои восторги оказались полезными еще кому-нибудь.

Весь текст подеён на 5 разделов:

1. ООП в Java Script (1/5): Объекты
2. ООП в Java Script (2/5): Классы
3. ООП в Java Script (3/5): Свойства и методы класса
4. ООП в Java Script (4/5): Наследование классов
5. ООП в Java Script (5/5): Полезные ссылки

Ситуация. Есть папка с фотографиями, которые нужно показать на сайте кликабельными thumb'ами.
Делаем раз: for f in *.jpg ; do convert -quality 90 -resize 80 "$f" "${f%.jpg}-thumb.jpg" ; done
Делаем два: for f in *-thumb.jpg ; do echo "<a href=\"./photos/${f%-thumb.jpg}.jpg\"><img src=\"./photos/$f\" alt=\"фото\" width=\"80\" height=\"53\"></a>" ; done
Вот, собственно, и всё. Остаётся только скопировать получившиеся строки и вставить на нужную страницу. Набрать эти две команды — пара минут с учётом того, что я не очень хорошо помню синтаксис bash'а (там substitution нужно знать) и convert'а.

Мне страшно подумать, сколько бы это заняло времени, если делать руками. Фотографий 32; На каждую ушла бы, наверное, минута. То есть это полчаса непрерывной работы.

Довольно часто на сайтах встречаются нелепые словесные конструкции, которыми программист обезличено хотел показать какой либо количественный параметр, например:

на сайте 22 человек ( а должно быть 22 человека )
1 комментариев ( понятно, что расчёт шёл на 10+ комментариев, но это не выход )

Прочитав в этом блоге о балансировке на стороне клиента, решил опубликовать свою статью, в которой описаны основные принципы масштабирования для web-проектов. Надеюсь, хабралюдям будет интересно почитать.

Основы масштабирования

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

Обычно о масштабировании начинают думать тогда, когда один
сервер не справляется с возложенной на него работой. С чем именно он не
справляется? Работа любого web-сервера по большому счету сводится к основному
занятию компьютеров — обработке данных. Ответ на HTTP (или любой другой) запрос
подразумевает проведение некоторых операций над некими данными. Соответственно,
у нас есть две основные сущности — это данные (характеризуемые своим объемом) и
вычисления (характеризуемые сложностью). Сервер может не справляться со своей
работой по причине большого объема данных (они могут физически не помещаться на
сервере), либо по причине большой вычислительной нагрузки. Речь здесь идет,
конечно, о суммарной нагрузке — сложность обработки одного запроса может быть
невелика, но большое их количество может «завалить» сервер.

Всем знакома ситуация, когда запущенный ролик YouTube (или другого хостера видео) хочется отменить, если он был запущен по ошибке или дальнейший просмотр не интересен. На текущий момент отменить загрузку через плеер возможности нет. Даже если Вы остановите ролик — загружаться он будет продолжать до конца.

Пока Youtube не прикрутили к embeded-плееру кнопку «отменить загрузку» — сайтовладельцы могут воспользоваться небольшой хитростью и реализовать такую кнопку самостоятельно.

Примечание: ниже расположен перевод статьи «jQuery for JavaScript programmers», в которой автор высказывает свое мнение об этой библиотеке, ориентируясь, в первую очередь, на продвинутых программистов, и приводит несколько десятков примеров ее использования.

Когда jQuery увидела свет в январе 2006, я подумал: «очередная красивая игрушка». Выбор CSS-селекторов в качестве базиса было, конечно, изящной идеей (подробнее о ней в моей заметке getElementsBySelector), но использование цепочек преобразований выглядело немного замысловато, и сама библиотека, по-видимому, не покрывала всех возможных случаев. Я расценивал тогда jQuery только как временное и проходящее решение.

Только несколько месяцев спустя понял я, насколько же ошибался по отношению к ней. jQuery является просто произведением инженерного искусства. Она умело покрывает достаточно широкой диапазон повседневных функций и предоставляет при этом удобный API для расширений, с помощью которых можно добавить любую другую функциональность. Абстрактность в ней заложена на уровне ядра — речь идет о выборе DOM-элементов — и она извлекает из него максимум пользы. И что важнее всего, использование этой библиотеки подразумевает следование хорошему стилю в программировании и хорошо сочетается с другими частями JavaScript-кода.

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

Примечание: ниже перевод статьи «Presentation Layer Performance Tuning», в которой затрагиваются основные аспекты оптимизации загрузки веб-приложений и предлагаются некоторые практические советы.

Обычный разговор про увеличение скорости работы веб-приложений сводится к обсуждению задержек при передачи информации между сервером и клиентом, оптимизации базы данных и времени, потраченного сервером для обработки и отправки HTML клиенту.

Эти процессы, однако, только частично затрагивают то время, которое клиент тратит на ожидание загрузки страницы в окне своего браузера. Большая часть времени тратится на загрузку, кеширование и отображение JavaScript, CSS и картинок (прим.: не-HTML файлов). Оптимизация производительности уровня представления (presentation layer) веб-приложений, на самом деле, сводится к двум простых условиям:

• Меньше данных
• Меньше запросов

читать дальше на webo.in →

Примечание: ниже представлен перевод двух последовательных статей «The window.onload Problem — Solved!» и «window.onload (again)», посвященных оптимизации исполнению скриптов при загрузке страницы, эта проблема была предварительно затронута в статье: «Как JavaScript тормозит Веб (и что с этим делать)?»

Для начала определимся с самой проблемой. Событие window.onload используется программистами для старта их веб-приложения. Это может быть что-то довольно простое, например, выпадающее меню, а может быть и совсем сложное, как пример, запуск почтового приложения. Суть проблемы заключается в том, что событие onload срабатывает только после того, как загрузится вся страница (включая все картинки и другое бинарное содержимое). Если на странице много картинок, то можно заметить некоторую задержку между загрузкой страницы и тем моментом, когда она начнет фактически работать. На самом деле, нам нужно только узнать способ определить, когда DOM полностью загрузится, а не ждать еще и загрузку картинок.

читать дальше на webo.in →

24 августа вышел новый релиз популярной JavaScript-библиотеки jQuery: jQuery-1.1.4. Вероятно, это последний релиз из ветки 1.1.x и в сентябре выйдет релиз 1.2.

• значительное (в несколько раз) увеличение быстродействия по сравнение с предыдущим релизом
• вместо операторов '$' и 'jQuery' для обращения к функциям JQ можно использовать любое имя
• возможность использовать несколько версий JQ на одной странице, назвав их по-разному
• возможность внедрять JQ в другие JS-библиотеки