Возможно, вам доводилось видеть игру Box Car 2D — автогонки машинок, сгенерированных с помощью генетического алгоритма. Игра работает на платформе Flash и использует физический движок box2d. За тем, как из бесформенных уродцев через несколько десятков поколений развиваются вполне приличные гоночные автомобили, можно наблюдать часами. Игра существует уже несколько лет, а её фанаты соревнуются в выведении новых «пород» машинок на разных типах трасс. Недавно в сети появился клон этой игры под названием Genetic Cars, написанный на HTML5 и JavaScript. Хотя в нем ещё многого не хватает (например, редактора машинок), некоторые вещи сделаны гораздо лучше, чем в оригинале. Например, есть возможность наблюдать заезд всех машинок одновременно. И самое главное — можно ковыряться в исходниках!

Первоначально технология HTML (hypertex markup language) была предназначена для описания смысловой структуры веб-документа, то есть для определения частей текста, в которых находятся различные по типу и содержанию части страницы как например заголовки, абзацы, сноски, иллюстрации, гиперссылки и так далее. Говоря академическим языком, HTML создан для семантической разметки документа.

Напомню, что семантика — это раздел языкознания изучающий отношения и способы выделения смысловых структур в речи. К примеру определение членов предолжения (подлежащее, сказуемое, дополнение, определение), изучение отношений и заложенного в них смысла (что является субъектом/объектом действия, а что уточняет их описание и т.д.).

До HTML задача семантической разметки документов решалась с помощью:

• TeX (технологии 1978го года) для макетирования академических публикаций
• SGML (технологии 1968го года) для более широкого спектра задач. SGML очень похож на своего потомка XML за исключением ряда правил, которые в некоторых случаях заметно усложняют чтение разметки, как например разрешение не ставить угловые скобки в тэгах.

Другими словами, если TeX был адаптирован строго под нужды макетирования университетских докладов, научных работ и тому подобного, SGML позволял создавать структуры информации подобные Реляционным Базам Данных, то есть реализоваывать ER-модели (entity-relationship).

(пример ER-модели)

(пример ER-отношений)

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

Тим Бернерс Лии создавая Web в конце 80ых, взяв за основу SGML, упростил синтаксис, создал перечень предопределенных тэгов для макетирования веб-страницы, правила использования которых задал с помощью DTD (технология из семейства SGML которая регламентирует порядок использования тэгов — то есть перечень разрешенных атрибутов, вложенных тэгов, разрешение на текстовый контент и так далее) и мы получили HTML 1.0

Таким образом HTML основанный на SGML первоначально был призван для описания структуры документа в контексте ER-отношений ее частей, то есть определения структуры и содержания документа в терминах сходных к базам данных.

Теперь представьте ситуацию, когда в прикладной программе для того чтоб подвинуть GUI-кнопку на несколько пикселей в какую-либо сторону Вам приходится редактировать структуру базы данных. Парадоксально, но в соверменном вебе это в порядке вещей — очень часто для того чтоб визуально подвинуть какой-либо элемент (GUI-кнопку) приходится изменять HTML-структуру (базу данных)!

Всем привет. Меня зовут Макс Дегтерев (у меня тут нет аккаунта, так что вот мой twitter: @suprMax и сайт maxdegterev.name ). Мы недавно запустили новую классную версию мобильного сайта. Про него-то я вам сейчас и расскажу.

JavaScript принято считать прототип-ориентированным языком программирования. Но, как ни странно, этим подходом практически никто не пользуется: большинство популярных JS-фреймворков явно или неявно оперируют классами.
В этой статье я хочу рассказать об альтернативном способе программирования на JavaScript, без использования классов и конструкторов — чистым прототипным ООП и особенностях его реализации на ECMA Script 5.

В заметке Владимира Токмакова, утверждается:

HTML-элемент в документе может быть скрыт с помощью JavaScript или CSS-свойства display. Логику, заложенную в CSS, воспроизводить в JavaScript сложно и не нужно. Проще запросить offsetHeight объекта (если 0 = элемент скрыт).

Проще-то оно, конечно, проще, вот только какой ценой?

Backbone.js это каркас для создания RIA JavaScript приложений, его автором является Jeremy Ashkenas, создатель CoffeeScript, Backbone является частью компании Document Cloud ей же «принадлежит» Underscrore.js. Backbone — очень легкая библиотека, помогающая вам создавать интерфейсы. Она может работать с любыми библиотеками, к которым вы привыкли.

Backbone это набор классов, размером менее 4Кб, которые формируют структуру вашего кода и помогают создавать качественные MVC веб-приложения.

Backbone формирует структуру тяжелых JavaScript приложений, внесением моделей с key-value подобным хранилищем и своими событиями, коллекций с богатыми API, видов (ориг. views) с декларативной обработкой событий и соединяет все это в в одно приложение, поддерживающее RESTful JSON интерфейс.

Backbone не может работать без Underscore.js. Для поддержки REST API и работы с DOM элементами в Backbone.View настоятельно рекомендуется подключить json2.js и jQuery-подобную библиотеку: jQuery или Zepto

В статье будет рассмотрена структура Backbone.js, будет поэтапно создано простое Todo приложение.

Совсем недавно мы выпустили в свет первую бета-версию нашей онлайн-читалки, с которой можно ознакомиться, почитав книгу Михаила Лермонтова «Герой нашего времени». Эта читалка — результат почти семимесячной работы, пять из которых ушло только на разработку движка. Казалось бы, в интернете уже есть бесплатные и открытые JavaScript-движки для чтения электронных книг и такой долгий срок может вызвать сомнения в профпригодности разработчика (то есть меня). Но есть одно большое и жирное «НО». Мы поставили перед собой слишком амбициозную и трудновыполнимую задачу: мы хотели использовать один и тот же движок на разных устройствах, в том числе маломощных, таких как айфон или электронная читалка.

В чём же заключается трудновыполнимость задачи? В первую очередь — в очень низкой скорости работы веб-приложений на айфоне. Например, мобильный Сафари по моим прикидкам работает раз в 100 медленнее своего десктопного собрата. Если на декстопе одна и та же операция выполняется 10 мс и совершенно незаметна для пользователя, то на айфоне она может выполняться больше секунды. Для сравнения: первая версия движка разбивала небольшую главу на страницы примерно за 15 секунд. Сейчас, спустя полгода, он делает то же самое менее, чем за секунду и вполне сносно работает в нашем приложении booq.

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

В своем прошлом топике, я описал базовые принципы работы с фреймворком backbone.js, теперь предлагаю перейти к практике и сделать что-нибудь полезное.

Задача

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


В соответствии с заветами ООП, попробуем разработать класс для попапа, от которого мы сможем наследоваться и создавать попапы на свой вкус с общим для всех поведением.

Скачиваем backbone.js, jquery, jquery ui, underscore.js и

Данная статья является вольным переводом. Оригинал тут.

Введение

Думаю, ни для кого не секрет, что клиентские приложения в современных веб-сервисах становится все сложнее и количество JS кода в них растет. До недавнего времени архитектура клиентской части, как правило, разрабатывалась с нуля и была специфична для каждого проекта. Не удивительно что приходилось снова и снова сталкиваться с типичными задачами.
К MVC-фреймворкам на серверной стороне все уже привыкли, но JS код на клиенте часто бывает плохо структурирован.

Предлагаю ознакомиться с решением на базе backbone.js, underscore.js и jQuery, которое поможет решить эту проблему.

Постановка задачи

Каким бы мы хотели видеть наше приложение? Вот основные моменты, которые мне кажутся важными:

1. Должен быть удобный способ описать модели нашей предметной области.
2. Любые изменения в модели должны немедленно отражаться в пользовательском интерфейсе, если модель в нем представлена каким-либо образом.
3. Понятная и легко-поддерживаемая структуризация кода в стиле MVC.

Попробуем решить эти задачи на примере простого приложения «Каталог фильмов».

Я совсем не долго изучаю и использую git практически везде, где только можно. Однако, за это время я успел многому научиться и хочу поделиться своим опытом с сообществом.

Я постараюсь донести основные идеи, показать как эта VCS помогает разрабатывать проект. Надеюсь, что после прочтения вы сможете ответить на вопросы:

• можно ли git «подстроить» под тот процесс разработки, который мне нужен?
• будет ли менеджер и заказчик удовлетворён этим процессом?
• будет ли легко работать разработчикам?
• смогут ли новички быстро включиться в процесс?
• можно ли процесс относительно легко и быстро изменить?

Конечно, я попытаюсь рассказать обо всём по-порядку, начиная с основ. Поэтому, эта статья будет крайне полезна тем, кто только начинает или хочет разобраться с git. Более опытные читатели, возможно, найдут для себя что-то новое, укажут на ошибки или поделятся советом.

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

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

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

В данном топике будут рассматриваться:

1. Замыкания
2. Прототипирование
3. Контекст выполнения

tFormer.js — empower your HTML forms

Предисловие:

Вам приходилось верстать формы? Приходилось писать скрипт для валидации этих форм на клиенте? Доводилось ли использовать уже существующие плагины/надстройки для валидации форм?
Мне приходилось, но я не был на 100% удовлетворен ни от подхода решения задачи в лоб (собственный скрипт валидации для каждого проекта под его формы), ни от того, как работают существующие сторонние плагины.

Проблема:

Основными проблемами собственных скриптов и плагинов всегда были — гибкость, удобство и простота.
Большое количество data-attributes, необходимых для конфигурации скриптов (как это в Parsley.js) делают и код менее читабельным, и никогда не помнишь, как все они пишутся. Не просто…
Не все плагины хорошо подходили под желаемые HTML-формы, а постоянно писать свои скрипты под разные формы не всегда удобно и разумно.

Задача:

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

Решение:

Решение вылилось в небольшой опенсорсный плагин, который получил название tFormer.js.

Мы уже писали о методах (Mobile First и Response Web Design), которые используем при разработке нашего сервиса. В этой статье я хочу поделиться с вами нашим опытом. То, что в теории кажется простым, на практике порой оборачивается кошмаром. Речь пойдет о том, как нам удается создавать универсальный веб-сервис, способный работать на большом количестве устройств.

Итак ajax запросы, всё просто, все привыкли их уже писать, но всё же как можно сократить количество написанного кода.
jquery.async.js

Сразу пример:

<form action="/" jasync>
	<input type="submit" />
</form>

форма отправляется ассинхронно

<input type="file" href="/" multiple jasync />
<div type="file" href="/" multiple jasync>Выберите файл</div>
<div href="/" jasync dropfile>Перетащите файлы и они отправятся на сервер</div>

файлы загружаюся асинхронно

<a href="/" jasync data="year=2013&month=5" class="send">отправить данные</a>

данные отправляется ассинхронно

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

Несмотря на то, что HTML5 всё ещё находится в процессе разработки, он уже появляется в веб-интерфейсах. Одним из основных нововведений этой версии HTML стал элемент Canvas, который используется для отрисовки двухмерной графики. Например, всё, что вы видите и с чем взаимодействуете в игре MMORPG от компании Mozilla или старом-добром Command and Conquer, отрисовывается и обрабатывается с помощью Canvas. Самые изощрённые умы даже реализуют полноценные формы на Canvas. Или интерактивную модель солнечной системы.

Фреймворки для работы с этим элементом растут как грибы после дождя; про то, как начать программировать, используя Canvas, написано огромное количество статей. Но есть один пункт, о котором, по-видимому, из-за узкой специфики говорят редко и мало. Речь идёт о тестировании приложений на Canvas. В каком-то смысле оно становится проблемой для инженера по тестированию, который привык обращаться к элементам на странице по их css или xpath селекторам, а затем выполнять с объектом какие-то действия. С Canvas такой подход не работает, ведь DOM элемент один, а объектов в нём — много.



Под катом на примере автоматизации тестирования API Яндекс.Карт я расскажу вам о том, как мы решили эту проблему в Яндексе.

Давно на хабре не было постов про CSS и я решил восполнить этот пробел. Сегодня мы учимся готовить зубчатый фон используя только средства CSS и никаких изображений!

Важные требования к такому забору:

• Никаких изображений!
• Он должен спокойно тянуться по горизонтали
• Обязательно должен поддерживать неравномерный фон у подложки
• Фон не должен требовать никакой экстра-разметки. Лучше всего будет избегать псевдо-элементов (экономия — хорошо).

Поддерживаемые браузеры: Chrome, Firefox (> 3.6), Opera (>= 12), Safari (>= 5), IE10.

Для IE 7, 8 у нас будет фоллбэк в виде обычной заливки. А вот с IE9 проблема — он не поддерживает градиенты, но при этом понимает hsla и rgba цвета. Воистину «великолепный» браузер. Что ж, его пока придётся игнорировать. Если кто–то подскажет хороший фоллбэк для IE буду только благодарен.

Данный текст был написан моей женой для собственного блога. Мне он показался достаточно интересным и полезным для людей, интересующихся изучением иностранных языков, и я решил опубликовать его здесь, учитывая, что на Хабре таких людей очень много. Почему моя жена решила, что может давать какие-либо советы в этой области? Потому что она окончила иняз, свободно говорит на английском, продолжительное время вела курсы изучения английского языка с разными группами и благодарные ученики не раз положительно отзывались о ней, как о преподавателе, а сейчас она успешно изучает итальянский и уже использует его в своей работе.



Итак, кто заинтересовался — прошу под кат.

Фреймворк Angular.js видится весьма перспективным, но, к сожалению, материалов на русском по нему почти нет. Чтобы поспособствовать формированию русскоязычного сообщества, начал перевод руководства разработчика. Подключайтесь angular.ru

Добавка

Еще в 2009 году, Сергей Чикуёнок опубликовал статью, в которой представил новый способ написания HTML и CSS кода. Этот революционный плагин, назывался Zen Coding, он помогал многим разработчикам на протяжении многих лет и в настоящее время вышлел на новый уровень.

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

Для тех, кто предпочитает смотреть, а не читать, вот видео любимых трюков автора.

Привет, хабр!
С удивлением обнаружил отсутствие на хабре развернутой статьи о сабже, что немедленно сподвигло меня исправить эту вопиющую несправедливость.

В условиях когда клиентская часть веб-приложений становится все более толстой, бизнес-логика неумолимо переползает на клиент, а на суверенитет серверных технологий все более смело посягает node.js нельзя не задуматься о приемах проектирования архитектуры на javaScript. И в этом деле нам несомненно должны помочь паттерны проектирования — шаблонные приемы решения часто встречающихся задач. Паттерны помогают построить архитектуру, которая потребует от вас наименьших усилий при необходимости внести изменения. Но не стоит воспринимать их как панацею, т.е., грубо говоря, если качество кода «не фонтан», он кишит хардкодом и жесткой связью между логически независимыми модулями, то никакие паттерны его не спасут. Но если стоит задача спроектировать масштабируемую архитектуру, то паттерны могут стать хорошим подспорьем.
Но впрочем эта статья не о паттернах проектирования как таковых, а о их применении в javaScript. В первой части этой статьи я напишу о применении порождающих паттернах.