JavaScript *

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

Сделан скрипт, показывающий результаты голосования одним числом не только разностью «за» и «против», но и с показом соотношения противоборствующих сил. Силы показываются в виде круговой (кольцевой) диаграммы, верхняя часть которой с зелёным цветом показывает долю голосов «за» (или отсутствует), а нижняя — долю «против», красного цвета. Таким образом, наглядно показано соотношение сил и насколько спорным было общее решение. От общего количества голосов зависит толщина кольца и насыщенность, что показывает статистическую устойчивость результата.

Проще посмотреть и оценить на примерах. Справа — примеры в списке топиков, взяты из разных анонсов, на одну оценку наведена мышь, открывающая арифметику суммарной оценки. Примеры из комментариев — далее.

Прочитав очередную умную книжку про javascript, стал разбираться в методах реализации в нём наследования. Ну, то есть всем конечно понятно, что в реальном, большом, проекте лучше всего для этого использовать функцию из какой-нибудь библиотеки( благо их много ), но ведь хочется понять, как это вообще работает.

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

Долгое время использовал в своих проектах, различные готовые JavaScript-календари для ввода дат, в частности Dynarch jsCalendar, и они полностью устраивали. Но в ходе разработки одного проекта, связанного с автострахованием, возникла необходимость довольно частого ввода дат из прошлого (дни рождения, дата выдачи паспорта и водительских прав, пенсионного и т.п.). Оказалось, что использовать календари в таких случаях не так уж и удобно, так как приходится отматывать несколько десятков лет назад и для этого приходится делать много действий мышкой.

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

Так например разработчики из команды Mozilla смеха ради сделали H.264 декодер на JavaScript. Любопытно, что скрипт при этом не был написан вручную.

Благодаря библиотеке jQuery примерно с 2006 года (то есть лет пять как) никому не надо объяснять, что такое method chaining: это та самая техника программирования, в которой методы объекта могут быть вызваны друг за другом по цепочке, как в jQuery.

Главнейшим достоинством этой техники является заметная экономия усилий программиста. С нею программисту не приходится заново, неоднократно записывать имя объекта вот в такой манере:

obj.шмяк();
obj.тыдыжжь();
obj.ынц();

Вместо этого программист может вызвать все методы цепóчкою — в одну строку:

obj.шмяк().тыдыжжь().ынц();

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

obj
   .шмяк(параметр1, параметр2, …)
   .тыдыжжь(параметр1, параметр2, …)
   .ынц(параметр1, параметр2, …);

На практике возможность такой техники обеспечивается тем, что ни один метод объекта не возвращает значение undefined. Вместо этого, если метод является командою, а не запросом (то есть выполняет некоторое действие, а не возвращает некоторое значение), то в конце его автор библиотеки пишет «return this» — этим-то и обеспечивается возможность записи вызова нескольких команд подряд в форме цепочки.

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

Удобство цепного вызова вызывает привыкание. Ну правда же: достаточно пару-тройку-другую недель попрограммировать на jQuery — и обыкновенные API начинают раздражать, даже бесить, своею допотопною невозможностью цепного вызова. Также недостаёт возможности задания их свойств в виде объекта, передаваемого методу, подобному .css({color: 'red', 'line-height': 1}) в jQuery.

Вообразите себе, например, как необыкновенно было бы удобно, кабы по холсту (<canvas>) можно было рисовать цепными вызовами в такой манере:

ctx.beginPath()
   .prop({
      lineWidth: 2,
      strokeStyle: '#333'
   }).moveTo(0,0)
   .bezierCurveTo(50,50, 80,80, 100,100)
   .stroke().closePath();

И средство для именно таких цепных вызовов появилось — благодаря Lea Verou. Вот оно:

Много воды утекло с тех пор когда я сел за написания своего файлового менеджера. В то время поддержка ИЕ6 считалась обычным делом, а про фичи HTML5 можно было только мечтать. В общем вот ссылка на версию 0.1.0 альфа. В конце первого топика, я написал, что планирую сделать в будущем, можно сказать я сдержал свое обещание и хочу представить Вам версию 1.0b. Из того, что планировалось, была отброшена идея внедрения авторизации в менеджер, потому что, как говорили здесь, это пятое колесо. Рассмотрим, что изменилось и что улучшилось, но для начала скрин

Компания Codecademy выполнила операцию Codecademy.add(investors) на сумму 2,5 миллиона долларов США. Кстати, одно из новых свойств объекта — Юрий Мильнер.

Напомним, что уникальный в своём роде стартап Codecademy обучает новичков JavaScript с помощью бесплатных интерактивных упражнений. Он открылся два месяца назад: за первые 72 часа работы сайт посетили 200 тыс. начинающих программистов, которые выполнили 2,1 млн уроков.

После получения такой значительной суммы инвестиций Codecademy может ещё долго работать бесплатно (в будущем они всё-таки планируют придумать какую-то бизнес-модель), а также может нанять контент-органайзеров и увеличить количество уроков на сайте. Новый контент будут добавлять силами коммьюнити по модели UGC. Например, недавно был запущен первый такой курс «Функции в JavaScript», написанный Альбертом Венгером.

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

Хотя про паттерн «Обозреватель (Наблюдатель, Observer)» сказано достаточно, в том числе и на Хабре, вкратце повторюсь. Суть паттерна в наблюдении за состоянием неких субъектов системы и соответствующей реакции наблюдателей на изменения этих состояний. За одним субъектом может следить несколько наблюдателей, причём сам он об этом не знает (слабое связывание), но исправно оповещает всех об изменении состояния.

Удобно использовать Обозревателя на сайтах и в веб-приложениях, поэтому логично реализовать его с использованием самого популярного языка для веб-среды — Javascript.

Простой мини-скрипт List.js размером 7 КБ добавляет интерактивности маркированным спискам в HTML. С помощью скрипта можно сделать удобный поиск, сортировку, редактирование списка с добавлением или удалением новых элементов (например, адресная книга на странице) и т.д. Чем-то напоминает Chosen, только там модифицировались выпадающие списки.

List.js — обычный JavaScript, который не требует jQuery, работает без проблем во всех браузерах. Пару примеров см. здесь и здесь.

List.js опубликован под открытой лицензией MIT.

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

Оформим начатое в habrahabr.ru/blogs/javascript/130495 в удобный для использования метод .inherit4 конструктора Constr, чтобы, фактически построить модель классов и наследования (она будет более мощной, чем классическая, но это побочный эффект). Если у Вас нет желания подключать Mootools с аналогичной моделью, будет достаточно этого метода на 2 КБ несжатого кода, чтобы нормально работать с прототипным наследованием и иметь пару дополнительных методов: доступ к методам предков .ancestor('имя_метода', номер_поколения_предка) и расширение хешей. Применение всех 3 методов позволяет исключить из лексикона слова prototype и constructor, продолжая работать с тем и другим, и делает код легко читаемым.

Одной из самых обсуждаемых тем на Хабре стало объявление Гугла о создании нового языка Dart, претендующего на то, чтобы полностью заменить Javascript.
Для Гугла это не первый проект подобного рода. С 2006 года существует Google Web Toolkit, позволяющий создавать веб-приложения полностью на Java. На нём, например, работают Adwords и Google Wave.
Но, не смотря на красивые обещания и очень серьезные, особенно по меркам 2006 года, возможности, GWT так и «не взлетел». Да, проект поддерживается и развивается, но сообщество разработчиков так и не сложилось. Сторонних компонентов мало, они не поддерживаются, знакомых с системой программистов найти сложно.
Практически все «плюшки» языка Dart, которые сейчас рекламирует Google, уже были реализованы в Webtoolkit-е. В этой статье я хочу проанализировать достоинства и недостатки GWT в попытке рассмотреть мутные очертания будущего Dart.

Признаться, сообщение о разработке в Google языка Dart я встретил с недоумением. Если coffeescript и прочие надстройки я считал просто чьим-то развлечением на досуге, то к Dart-у при всём желании не получается относиться как просто ещё к одной гиковской игрушке.

Сегодняшний пост про грядущее господство Дарта подтолкнул меня к тому, чтобы ясно сформулировать, наконец, почему я считаю Дарт всё равно просто гиковской игрушкой и в чем неправа корпорация Google. Начну, пожалуй, с цитаты:

«Нужна полная замена JS — язык широкого профиля: от простых скриптов, для сложных приложений»

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

 

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

Возьмём за основу метод прототипного наследования, который максимально эффективен тем, что производит минимум действий при описании цепочек наследуемых классов и при этом максимально поддерживает базовые операции и свойства наследования: instanceof, constructor. Для доступа к предку он создаёт свойство .superclass.

Добрый день, коллеги!

Хотел поделиться своими наработками в области автоматизации процесса сборки javascript проекта использующего Google Closure Compiler и Google Closure Library при помощи Apache Maven. Страничка проекта https://github.com/urmuzov/closure-maven, там же лежит документация по каждому из компонентов проекта.

О проекте

Главный компонент проекта — это архетип. Архетип объединяет в себя все остальные компоненты проекта, которые при желании могут использоваться отдельно от него.

Архетип предоставляет средства для решения самых часто встречающихся задач при разработке, а именно:

• Запаковывает javascript код в maven артефакты для распространения (такие артефакты содержат помеченные пакеты специальной структуры, названные closure-packages);
• Распаковывает closure-packages из подключенных в <dependencies> артефактов для компиляции;
• Помогает в объединении и оптимизации js и css файлов при помощи Web Resource Optimizer for Java (wro4j);
• Предоставляет 5 профилей компиляции для разных целей:
  
  • compiled — для «боевой» сборки проекта. Уровень компиляции ADVANCED_OPTIMIZATIONS;
  • merged — для склеивания всех исходных js файлов в один, фактически без компиляции. Уровень компиляции WHITESPACE_ONLY, форматирование PRETTY_PRINT;
  • sources — для дебага javascript файлов в бразуере. Компиляция происходит как и в профиле compiled, но в html будут подключены файлы с исходными кодами;
  • sources-no-compile — для дебага html/css файлов. Компиляции не происходит, просто в html подключаются файлы с исходными кодами;
  • jar — для сборки jar-архива для распространения;
  
  
• Генерирует jsdoc и jslint отчеты при выполнении mvn site.

Доброго времени суток, уважаемые хабражители.

Сегодня мы поговорим подробней об упоминавшейся вскольз технологии написания кроссбраузерных юзерскриптов, а именно об упаковывании юзерскрипта в простейшее расширение для Google Chrome.

Ниже я постараюсь овтетить на вопросы «зачем ?» и «как ?».

Эпоха тёплого лампового WEB 1.0 давно прошла, и в последнее время мы имеем дело со страницами, которые кишат так называемой динамичностью. Динамичность может быть обеспечена при помощи JavaScript, VbScript и плагинами вроде Java, Flash, Silverlight. В этой статье я хочу затронуть одну из возможных оптимизаций web-сайта — объединение всех javascript файлов в один.

Зачем?

Основных причин две:

1. Повышение скорости загрузки страницы.
2. Снижение нагрузки на сервер.

Начнём с «повышения скорости загрузки». Зачастую web-сайт просто пестрит скриптами и их общее число может перевалить за 50. Впрочем, это уже будет «клинический случай». Но хотя бы 15-30 встречается регулярно. На каждый чихскрипт браузер посылает запрос и, в зависимости от ответа, либо грузит его полностью, либо забирает из кеша. 15 запросов это много. На это нужно время. Да, все современные браузеры загружают файлы параллельно, но это не повод их так эксплуатировать. В моём случае скорость загрузки страницы возросла в несколько раз.

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