Привет! Меня зовут Александр Завьялов. В Яндексе я занимаюсь разработкой интерфейсов. Недавно я выступил перед коллегами с докладом об аппаратном ускорении в жизни верстальщика, где также коснулся смежных тем. Рассказал о производительности веб-страниц, о том, как она измеряется и к чему она может стремиться.

^{Ссылка, если видео не отображается}

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

Не так давно озадачился поиском работы, в связи с чем посетил n-нное количество собеседований и услышал много интересных вопросов. По сети гуляет много статей с вопросами по JS, поэтому постараюсь выбрать вопросы, которые ещё не видел. Здесь нет вопросов типа Что такое замыкание?, Наследование в JavaScript или Сделайте ajax запрос на VanillaJS. Кстати советую поискать ответы на эти вопросы, прежде чем читать статью :) Под катом вопросы типа «с подвохом». Вряд ли какой-то из них попадётся вам, но, надеюсь, статья настроит вас на «подвоховое» мышление, и напомнит некоторые скользкие места и подводные камушки javascript.

В девелоперских сборках браузеров Chrome, Firefox и Opera появилась поддержка нового элемета picture, призванного решить ряд проблем возникающих при разработке адаптивных дизайнов. Давайте рассмотрим его подробнее.

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

Для прогрессивной визуальной разработки нельзя просто внедрить пару тройку фишек. Нужно радикально изменить сознание и фундаментально поменять подход. Я не буду разбивать процесс на избитые заезженные этапы. Опишу более свежо. Две основных составляющих агрессивно нового подхода: «Дизайн в Браузере» и «Автоматизация фронт-энда».

Начнем с первого — «дизайна». Тут проблема в отношении к дизайну как к статической .psd. По ощущению это должно было потерять свою актуальность в тот момент, когда появился адаптив, добавилась динамика и доработка на живую макета стала привычным делом. Теоретически смерть статичных .psd-шек наступила вместе с отходом табличной верстки. Зачем пытаться оживить то, что отслужило?! Тогда это было актуально, так как фактически в таблицу запахивалась картинка макета, только в нарезанном виде. Сейчас же макет выполняет роль ориентира. В большинстве случаев мы не вырезаем ни пикселя. А просто держим макет открытым в соседнем окошке. Для того, чтобы написать всю эту «красоту» кодом.

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

С первых дней в Airbnb происходило то, что случалось со многими стартапами: мы писали много сомнительного кода и мало времени уделяли тестированию. И чем больше мы росли, тем большей это становилось проблемой. На сегодняшний день мы ежедневно обрабатываем данные миллионов пользователей. Только представьте себе, с какими объёмами данных приходится иметь дело, учитывая одни только платежи, когда сделки ежеминутно происходят в десятках разных валют. Небольшая незначительная ошибка может иметь огромные последствия для наших пользователей. Теперь благодаря нашим тестам, мы можем быть уверены, что финальный продукт выйдет действительно качественным.

Мы расскажем вам, как нам удалось изменить культуру тестирования и какие инструменты мы использовали для написания и выполнения тестов, чтобы упростить жизнь нашей команде.

Добрый день, уважаемые хаброжители!

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

Поиск выдал мне всего одну статью на Хабре по схожей тематике — «Талмуд по формулам в Google SpreadSheet». В ней дано хорошее описание базовых вещей для работы в excel (хотя он и не 100% про сам excel).

Таким образом, накопив определенный пул запросов/задач, появилась идея их типизировать и предложить возможные решения (пусть не все возможные, но быстро дающие результат).

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

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

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

Сразу, зачем это нужно:

• трансдьюсеры могут улучшить производительность, т.к. позволят не создавать временные коллекции в цепочках операций map.filter.takeWhile.etc
• могут помочь переиспользовать код
• могут помочь интегрировать библиотеки между собой, например underscore/LoDash могут уметь создавать трансдьюсеры, а FRP библиотеки (RxJS/Bacon.js/Kefir.js) могут уметь их принимать
• могут упростить FRP библиотеки, т.к. можно будет выбросить кучу методов, добавив один метод для поддержки трансдьюсеров

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

[Прим. перев.]: предлагаю вашему вниманию перевод статьи Бена Черри, в прошлом разработчика Twitter. В этой статье он приводит несколько советов по написанию javascript кода, пригодного для тестирования.

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

Избегайте синглтонов

Один из моих наиболее популярных постов был о том, как использовать javascript шаблон «Модуль» для создания синглтонов в вашем приложении. Этот подход может быть простым и полезным, но он создает проблемы для тестирования по одной простой причине: синглтон загрязняет состояние объекта между тестами. Вместо синглтона в виде модуля, следует создавать его как конструируемый объект и присваивать его экземпляру глобального уровня во время инициализации вашего приложения.

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

Как было отмечено в предыдущем посте букмарклет можно разделить на 3 взаимодействующие части:

1. Первая часть, небольшой, до 2000 символов javascript-код, который сохраняется в закладках браузера и, в простейшем случае может выполнять всю работу, но обычно служит для инициации работы букмарклета.
2. Вторая, подгружаемая часть букмарклета: javascript-код подгружаемый в текущий документ в процессе инициации букмарклета и обеспечивающий основную функциональность.
3. Третья, резервная часть букмарклета которая срабатывает если подгрузить javascript в текущий документ не удалось.

Первая часть букмарклета была досконально разобрана в предыдущем посте на живом примере букмарклета веб-сервиса TheOnlyPage (сервис хранения закладок, заметок и html-фрагментов)

На этот раз остановимся на подгружаемой части букмарклета.

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

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

Напомним, вкратце логику работы «навороченного» букмарклета:

1. Кликом по сохраненной в закладках браузера ссылке, вызывается на выполнение небольшой (до 2000 символов) javscript-код, основная задача которого организовать загрузку javascript-кода выполняющего основную работу букмарклета
2. Основная часть букмарклета после загрузки выполнят всю работу.
3. Если основную часть букмарклета невозможно подгрузить – основную часть работы, выполняет резервная часть букмарклета, как правило, в урезанном виде.

Вы можете спросить себя: зачем мне это читать, если я и так пользуюсь сервисом Airbnb? Вы можете спросить себя: кто это такие и зачем мне читать о них? Мы не сможем ответить на второй вопрос — в этой статье нет ни слова о том, что такое Airbnb, зачем и кому он нужен. И здесь не будет FAQ по использованию сервиса. Но мы можем поделиться интересными советами с теми, кто уже пользовался нашими услугами или знает о них достаточно, чтобы быть готовыми ими воспользоваться. Советы у нас от очевидных до завуалированных, но все они в едином стиле направлены на то, чтобы сделать вашу работу эффективной интереснее ваше путешествие в любую из 190 представленных у нас стран.

Сегодня сооснователю Яндекса Илье Сегаловичу исполнилось бы 50 лет. Мы сняли небольшой фильм-воспоминание о нём и том, что значило работать рядом с ним. Это первая часть фильма.

Привет! В этой статье я хочу поделиться своим опытом разработки приложений для платформы LG Smart TV. Лично я свой путь Smart TV разработчика начинал именно с этой платформы и хотел бы порекомендовать ее всем заинтересованным в данном направлении приложений. В первую очередь это связано с тем, что по качеству документации и предоставляемых разработчику возможностям LG не уступает своим основным конкурентам из Samsung. В то же время, специалисты санкт-петербургской лаборатории LG R&D достаточно открыты и всегда готовы предоставить актуальную информацию, тогда как от их коллег из московского центра разработок Samsung я уже несколько месяцев пытаюсь получить контакт хоть кого-то, кто может внятно отвечать на технические вопросы. Про других участников рынка Smart TV я лучше не буду упоминать: то, как они подходят к вопросам взаимодействия с теми, кто, по идее, должен наполнять их магазины приложений, вызывает большие сомнения в том, что они вообще заинтересованы в том, чтобы для них что-то разрабатывалось.

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

Не так давно Apple представила iPhone 5S, и сайт с презентацией, где страница была поделена на секции, и каждая секция описывала одну из особенностей продукта. Я подумал, что это – замечательный способ представления продукта, исключающий возможность пропустить ключевую информацию.

Я отправился на поиски подходящего плагина, и к удивлению, не обнаружил такового. Так и родился плагин постраничной прокрутки.

Давным-давно

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

Самое крутое, классное и волшебное, что было в JS — это то, что никто в больших организациях не хотел с ним иметь дела, оставаясь в своём спокойном мире прекрасно организованных слоёв абстракций из фабрик и волшебных фреймворков инъекций XML.

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

Мало того, когда все эти проблемы с производительностью возникали, мы могли всех спасти, написав на JS фронтэнд, который делал вид, что никаких проблем не существует и всё это прекрасно работало, несмотря на тоскливое качество бэкэнда.

Мы достигли расцвета JS

С приходом jQuery наша жизнь стала ещё лучше, и мир вокруг стал собираться из маленьких переиспользуемых плагинов к jQuery. Наконец, мы достигли расцвета, когда пришёл NPM, и мы начали использовать более-менее работоспособную систему модулей для работы с автономными виджетами.

Я представлял себе будущее, где я мог работать с отличными командами над отличным кодом из маленьких модулей и автономных функций и виджетов. Я даже думал, что нам удастся отвоевать контроль над кодом у корпоративных маньяков с их библиотеками, ОРМами, паттернами и практиками, и основанными на них фабриками фабрик сервисов.

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

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

Скорее всего, вы уже знаете об одной из таких методологий, разработанной Яндексом, — БЭМ. БЭМ утверждает, что трёх сущностей (блоков, элементов и модификаторов) достаточно для написания HTML и CSS, задания структуры кода и компонентной структуры с последующим масштабированием проекта до самого высокого уровня.

Я проработал в Яндексе достаточно долго и видел, как эта методология работает на больших проектах. В Яндексе БЭМ используют для разработки CSS- и JavaScript-компонент, с помощью этой методологии также пишут шаблоны и задают зависимости между компонентами. Есть БЭМ-инструменты, поощряются различные эксперименты с кодом, исследования. В масштабах большой компании эти трудозатраты окупаются и дают Яндексу возможность быстро и качественно разрабатывать сотни сервисов одновременно.

Могут ли маленькие команды получить от БЭМ то же самое? Я совершенно не был в этом уверен. Всё же БЭМ — абстракция, которая поставляется вместе с инструментами и технологиями. Для маленькой компании польза от переключения на «полный стек» этих технологий — сомнительна, многие из инструментов изначально приспособлены под крупные и сложные задачи. Быть может, тогда полезной окажется сама идея, сама методология?

Изначально эта моя статья была опубликована в известном многим журнале Smashing Magazine. Но я решил, что и на Хабре она может быть интересна, ведь многие здесь занимаются собственными небольшими проектами.

В июне к команде LinguaLeo присоединился Артур Думчев, рекордсмен «Книги рекордов России» по запоминанию, признанный эксперт в области развития памяти, тренер и консультант. Артур помнит число «Пи» до 22 528 знаков после запятой и является автором книги «Помнить все. Практическое руководство по развитию памяти».

В настоящий момент Артур работает в LinguaLeo над внедрением дополнительных эффективных методов запоминания слов и фраз. Мы попросили его поделиться советами по быстрому и качественному изучению языков с читателями нашего блога, и Артур расказал про такие хаки, как «разумное применение мнемотехники» и «систематика в обучении». Итак, что же это такое, и поможет ли оно в развитии памяти и изучении языка? Давайте разберемся.

Разумное применение мнемотехники

Мнемотехника — это совокупность приемов, облегчающих запоминание. Пример использования мнемотехники: нам нужно занести в память слово Shrug — «пожимать плечами». Чтобы это сделать, достаточно представить какой-нибудь визуальный образ, который позволит вам вспомнить слово и его перевод. Например, Шрек пожимает плечами. Когда вы услышите Shrug, вам тут же вспомнится этот образ, а затем перевод слова.

1 августа в офисе Яндекса, открывшемся недавно в Берлине, состоялся финал нашего чемпионата по программированию. И его победителем снова стал известный всем, кто интересуется спортивным программированием, Геннадий Короткевич.

Задания для Алгоритма готовила международная команда. В нее вошли программисты из России, Беларуси, Польши и США. Это специалисты МГУ имени М.В. Ломоносова, Университета Карнеги-Меллон, сотрудники Яндекса и Google. В Яндексе задачи составляли разработчики минского и киевского офиса, а потом проверяли их на своих коллегах. Один из составителей в прошлом году сам был финалистом Алгоритма. Специально для Хабрахабра мы разобрали с авторами все задачи. Кстати, несмотря на то, что соревнование завершено, вы можете попробовать себя в вирутальном контесте.



На победу претендовали многие финалисты. Среди них были победители и призеры АСМ ICPC и TopCoder Open, разработчики Google и Facebook. В финальном раунде сражались призёры Алгоритма-2013 Евгений Капун и Ши Бисюнь, чемпион АСМ ICPC Михаил Кевер, а также один из самых титулованных спортивных программистов мира Пётр Митричев. В этом году побороться за приз решил также Макото Соэдзимо — составитель заданий для Алгоритма-2013 и администратор TopCoder Open.

Борьба за первое место разгорелась между Геннадием Короткевичем и Хосакой Кадзухиро из Токийского университета. Лучший результат — четыре задачи при 66 минутах штрафного времени — показал Короткевич, подтвердив титул чемпиона. Кадзухиро решил столько же задач, но набрал больше штрафного времени (90 минут) и занял второе место. Третье место завоевал Ван Циньши из университета Цинхуа: он решил четыре задачи при 125 минутах штрафа.

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