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

«Хочу программировать под iPhone — говори, что почитать...»
Любимая девушка

Когда решаешься заняться разработкой под iOS, то трудно выбрать литературу и ресурсы, которые действительно были бы полезны. Хорошо еще, что Apple предоставляет множество учебных материалов и программ с открытым исходным кодом в своем центре для разработчиков. В остальных книжках можно если и не утонуть, то порядочно захлебнуться. Сейчас я жалею, что потратил время на пару «мануалов». Не буду делать им антирекламу, а лучше порекомендую хорошие материалы по программированию под iOS.

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

Прокси — это новые объекты JavaScript для которых программист должен определить своё поведение. Стандартное поведение всех объектов определено в движке JavaScript, который чаще всего написан на C++. Прокси позволяют программисту определить практически любое поведение объекта JavaScript, они полезны для написания базовых объектов или оберток функций или для создания абстракций виртуальных объектов и предоставляют API для мета-программирования. Сейчас Прокси не входит в стандарт, но его стандартизация запланирована в ECMAScript Harmony. Чтобы избежать путаницы уточню, что эти Прокси не имеют ничего общего с прокси серверами.

Где их можно использовать

1. Общие промежуточные абстракции
2. Создание виртуальных объектов: обертки существующих объектов, удаленные(от слова далекий) объекты, ленивое создание объектов (Пример ORM — Ruby ActiveRecord, Groovy GORM)
3. Прозрачное ведение логов, трассировки, профилирования
4. Внедрение предметно-ориентированных языков
5. Динамический перехват несуществующих методов, создание отсутствующих методов (__noSuchMethod__)
6. База для специфичных итераторов

Раньше я проанализировал функциональность обьектов и свойств ECMAScript 5. Это огромный новый аспект языка и он заслуживает особого рассмотрения.

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

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

(function (foo, bar) {
	console.log(typeof arguments); // ?
	
	arguments[0] = 42;
	console.log(foo); // ?
})(10, 20);

А также покажу интересную идею-библиотеку

function test (foo, bar) {
    Args(arguments).defaults(100, 100);

    return [foo, bar];
};

test(      ); // 100, 100
test(15    ); //  15, 100
test(21, 42); //  21,  42

Одни питонисты любят код читаемый, другие предпочитают лаконичный. К сожалению, баланс между первым и вторым — решения по-настоящему изящные — редко случается встретить на практике. Чаще стречаются строки вроде

my_function(sum(filter(lambda x: x % 3 == 1, [x for x in range(100)])))

Или четверостишья а ля

xs = [x for x in range(100)]
xs_filtered = filter(lambda x: x % 3 == 1, xs)
xs_sum = sum(xs_filtered)
result = my_function(xs_sum)

Идеалистам же хотелось бы писать как-то так

result = [x for x in range(100)] \
    | where(lambda x: x % 3 == 1)) \
    | sum \
    | my_function

Не в Питоне?

Вы PM. Как узнать – готова ли вёрстка к реальному использованию?
Вы заказчик. Как убедиться, что работа выполнена качественно?
Как оценить качество вёрстки?

Когда я стал тим-лидом, а позже PM, передо мной стала задача проверять вёрстку наших проектов. Нужно было выработать формальные, легкопроверяемые критерии, соответствие кода которым, должно было давать некую гарантию, что не будет факапов и ни клиент, ни программеры не сказажут потом “WTF?”.

Клиенту неважно насколько красив ваш код, но ему важен результат. Качественный код нужен фирме, т.к. он надёжней и в будущем его будет легче поддерживать.

Требования должны были быть такие, что соблюсти их легче, создавая качественную вёрстку, а не говнокод. Я составлял такой чек-лист в течении полутора лет. За последние полгода в него не добавилось ничего. Значит самое главное учтено.

Итак что же это за список?

Краткая версия теперь доступна на html5checklist.com (github), где можно вносить pull-request'ы.

История обновлений:

• 2015/08/11: Актуализировал рекомендации по оптимизации скорости загрузки. Добавил требование поддержки Retina. Дополнил «19. Мелочи» требованием что изображения должны масштабироваться в зависимости от размера окна.
• 2015/08/10: актуализирован список исключений для CSSLint
• 2015/07/29: актуализирован пункт №13 «плохо»/«хорошо»
• 2015/04/08: добавлено требование использования препроцессоров и рекомендация использования систем сборки
• 2013/04/25: добавлены анализаторами качества кода: CSSLint и JSHint, указан сайт подбора css font stack (спасибо @fliptheweb), мелкие уточнения (работу интерактивных элементов страницы, что не пропадает фон на высоких разрешениях, не должно быть пустых презентационных блоков, при проверках контента — пробовать удалять заголовки, менять местами блоки)
• 2013/04/24: добавил пункт об минимизации каскада (БЭМ-техники, MCSS, SMACSS), необходимости вписывания в экран моб. устройства, заменил ссылку на проверочный текст отображения стандартного html на код с normalize.css, поправил пример где в рекомендации встречался длинный каскад, упомянул про Opera на Presto и новый уровень семантики — в именах классов BEM.
• 2012/04/12: отсортировал пункты проверки в порядке важности, выделил главные, дополнил статью подробностями
• 2011/12/07: дополнил согласно доклада на WSD Минск'2011.
• 2011/07/19: добавлено про повышение надёжности вёрстки благодаря html5-тэгам, про необходимость favicon/apple-touch-icon, отсутствие багов при ресайзе textarea
• 2011/06/15: добавил пояснения какие ошибки валидации допустимы, рассказал про отсутствие официальной кнопки «HTML5 Valid» и про официальное лого HTML5 на сайте.

У меня периодические возникают разные потребности решения мелких насущных задач в Mac OS X. Для этих целей я обычно делаю небольшие программы, которые «закрывают» потребность частным образом. Но иногда хочется, чтоб программа была универсальной, и ей могли воспользоваться другие люди при необходимости (например «Переlator»). Так получилось и в этот раз…

Я люблю, когда Dock отображается всегда на экране. Но при запуске Симулятора iOS постоянно приходилось включать автоматические скрытие, чтобы симулятор полностью умещался на экране. Появилась задача — автоматизировать этот процесс. За пару дней набросал универсальную программу, с помощью которой можно задать AppleScript на определённое действие любой программы: «Программа запущена», «Программа завершена», «Программа активирована», «Программа деактивирована» и пр.

CSSO (CSS Optimizer) является минимизатором CSS, выполняющим как минимизацию без изменения структуры, так и структурную минимизацию с целью получить как можно меньший текст.
CSSO написан на Javascript, выполняется как в браузере, так и в командной строке (с помощью NodeJS).
Распространяется под лицензией MIT.

В 2008 году будущая команда «Мосигры» начала воплощать свою давнюю мечту по изданию качественной отечественной настольной игры. С продажи первой партии «Шакала» началась история розничной сети. Сначала мы открыли интернет-магазин, потом магазин в реале, а затем за два года построили сеть, покрывающую крупнейшие города России, Украины, Беларуси и Казахстана.

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

Осенью 2008-го года у нас на руках уже была большая партия игры «Шакал» (в премиум-версии), стоящая немалых денег, масса энтузиазма, глобальные планы и некоторое количество денег на сайт и первый маленький магазин.

А теперь медленно и по порядку.

В статье пойдет речь о Must Have тулзе для удаленной отладки Node.js приложений либо кода на WebKit браузерах node-inspector.

Для отладки кода в браузере, впринципе удаленная отладка и не нужна, не считая мобильных устройств, где она фактически не возможна потому что крайне не удобна. Совсем другое дело с серверным JavaScript. Node.js имеет несколько отладчиков, восновном продвигают ndb Node Debugger — консольная утилита для дебага Node.js приложений. Подходит только для фанатов консоли либо для мазохистов. Работать не удобно, отлаживать долго, по сравнению с отладкой кода в том же FireBug.

Что же умеет node-inspector:
1. Удаленная отладка
2. Отладка в графическом интерфейсе WebKit-debugger (На клиент ничего не нужно ставить — у вас все уже есть)
3. Редактирование runtime-кода!
4. Использует WebSockets, и никакого polling'а!
5. Удаленное профилирование блоков кода c использованием v8-profiler

Архитектура и платформа проекта Одноклассники

В этом посте расскажем о накопленном за 5 лет опыте по поддержанию высоконагруженного проекта. Надеемся, что коллегам-разработчикам будет интересно узнать, что и как мы делаем, какие проблемы и трудности у нас возникают и как мы справляемся с ними.

Сегодня начал писать проект частью которого были неубиваемые таймеры с Воркерами, выдерживающие полный перебор clearTimeout/clearInterval. Одним из условий было, что воркер или прочие функции/объекты могут подменить перед запуском скрипта. Для этого я написал функции isNativeObject(), isNativeFunction(), каждая имеет с десяток условий и определяют подмену/не подмену функции/объекта и косвенных признаков указывающих на «мухлёж».

Но тут дело не в этих функциях и тем более не в моём проекте. Прогоняя всевозможные нативные объекты я наткнулся на вопиюще разное поведение браузеров при обработке объектов с typeof и toString.

Например, меня крайне поразил тот факт, что абсолютно все браузеры выдают разные значения на

Worker.prototype + "";
// FF 3.6 [xpconnect wrapped native prototype]
// Op 11 [object DedicatedWorkerPrototype]
// Sa 4 [object WorkerPrototype]
// Ch 10 [object Object]

Сафари во все нативные конструкторы и прототипы подсовывает Prototype, Constructor — [object WorkerConstructor], [object WorkerPrototype]

В статье описаны другие интересные случаи поведения браузеров с typeof и toString.

Уже второй год я участвую в JS1k, в прошлом году был пробный скрипт, сейчас я решил подойти основательно. Приложения я уже написал и отправил. В статье я хочу поделиться своим опытом: как стоит писать приложение для JS1k, чем сжимать, как сократить код в 4 раза и вообще как впихнуть что-то интересное в 1 Кб.

Тема текущего JS1k "Oregon Trail" — классическая игра для Apple II (что это можно нагуглить). Поэтому рекомендуется написать что-то в этом духе, но это не обязательно.

Начало

Вам необходимо придумать небольшое приложение или демку, которое по вашему мнению может влезть в 1кб (продумать детали и управление). Если вы сомневаетесь в своих прикидках, то можно посмотреть, что впихнули в прошлом году: Legend Of The Bouncing Beholder, Tiny chess. Прочитайте правила и используйте html шаблон — тогда ваше приложение будет 100% работать в демо среде.
Начните писать скрипт, без каких-либо оптимизаций, но следите за его размером. Если он стал больше 4-5Кб — вам стоит придумать другую тему или в будущем придется попотеть (у меня было 4393 байт).

Моя последняя тема про “минус ноль” вызвала много интереса. По этому сегодня я собираюсь описать ещё одну особенность JavaScript, на что меня так же вдохновил твит:

Без попытки повторить это в браузере, что вернет следующий код?

["1", "2", "3"].map(parseInt);

Итак, что же это значит, когда кто-либо говорит, что foo выглядит как pythonic? Что значит, когда кто-либо смотрит в наш код и говорит, что он unpythonic? Давайте попробуем разобраться.

В Python-сообществе существует неологизм pythonic, который можно трактовать по разному, но в общем случае он характеризует стиль кода. Поэтому утверждение, что какой-либо код является pythonic, равносильно утверждению, что он написан в соответствии с идиома Python’a. Аналогично, такое утверждение в отношении интерфейса, или какой-либо функциональности, означает, что он (она) согласуется с идиомами Python’a и хорошо вписывается в экосистему.

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

Понятие Pythonicity плотно связано с минималистической концепцией Python’a и уходом от принципа «существует много способов сделать это». Нечитабельный код, или непонятные идиомы – все это unpythonic.

При переходе от одного языка к другому, некоторые вещи должны быть «разучены». Что мы знаем из других языков программирования, что не будет к месту в Python’e?

Метод console.log() — отличный способ вывести отладочную информацию, не мешая пользователю. Но знаете ли Вы, что объект console имеет еще уйму других не менее полезных методов? Очень редко разработчики используют этот функционал, ограничиваясь неблокирующим alert'ом. Что-ж, давайте исправим это положение.

Вступление

Здравствуйте, Хабрачеловеки.

В этой статье я хочу рассказать сообществу о такой полезной штуке, как DOM Events. Все, кто хоть как то связан с Javascript, знают, что в этом языке события и их обработка являются одним из важнейших и часто используемых свойств, но не многие знают, как эти события генерировать программно. Собственно, этому и посвящена статья: в ней рассказано, что это, зачем нужно, и как это использовать. О listener'ах речи идти не будет, хоть эта тема весьма тесто связана с рассматриваемой.

Что такое CouchDB для вас? Вероятно любой, кто хоть немного интересуется популярной нынче темой NoSQL, прекрасно знает общие детали: это такая симпатичная игрушка с map/reduce-запросами, которые пишутся на JavaScript, с которой можно работать, гоняя JSON по HTTP-протоколу, а также не исключено, что слышали, что она fault-tolerant, тобишь не ломается вообще. Дальше этого обычно дело не идёт, в результате CouchDB отправляется в delicious в общую кучу со всякими MongoDB, Cassandra, Hadoop и т.п.

Примерно такого мнения придерживался и я вплоть до недавнего времени, пока не возникла острая необходимость переосмыслить архитектуру текущего проекта (упёршегося лбом в свою реляционную БД) и пересесть на документную базу данных, которая бы умела map/reduce. После того, как более пристально взгялнул на CouchDB, я понял, что он уникален в своём классе, его не следует ставить в один ряд с упомянутыми продуктами. Идеи, которые заложены в CouchDB настолько концептуальны, что способны в корне перевернуть представление о разработке веб-приложений.

О том, что же меня так впечатлило, постараюсь рассказать под катом.

Когда-то давно, когда я практиковался в написании хранимых процедур, триггеров, курсоров под MSSQL, мне не давала покоя мысль о приложении, где вся бизнес-логика крутится на уровне БД, а presentation tier просто дергает базу и отвечает за отрисовку полученных результатов. С тех пор прошло много моих девелоперских лет, но возможности для реализации данной идеи так и не встретилось… до тех пор, пока я не наткнулся на CouchDB.

Я думаю, что многие уже слышали о NoSQL базах данных и в том числе о Couch DB. Здесь я хочу рассказать о замечательной возможности встраивать JavaScript-приложения в CouchDB, название которым CouchApp.