Этим постом мы завершаем серию публикаций о конкурсах Яндекс.Блиц в 2018 году. Надеемся, что вам довелось поучаствовать или хотя бы посмотреть, какие приближенные к продакшену задачи мы предлагаем. Последний контест был посвящен применению алгоритмов во фронтенде. Сегодня мы публикуем подробные разборы 12 задач: первые 6 из них предлагались в квалификационном раунде, а задачи 7–12 — в финале. Мы постарались объяснить, как формировались условия, на какие навыки мы обращали внимание. Спасибо всем участникам за проявленный интерес!

Задача 1

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

Привет, Хабр!

Не так давно я понял, что работа с CSS во всех моих приложениях — это боль для разработчика и пользователя.

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

Тестов много не бывает — это все знают. Мемы про unit и интеграционное тестирование уже не очень-то веселят. А мы по-прежнему не знаем, можно ли полагаться на результаты прохождения тестов, и какой процент покрытия позволит не пустить баги в продакшен. Если фатальные изменения в коде проскакивают тесты, не оказывая влияния на их результат, то решение напрашивается само — надо тестировать тесты!



О подходе к автоматизации этой задачи и был доклад Марка Лангового на Frontend Conf. Видео и статья короткие, а идеи очень рабочие — надо брать на заметку.

Сегодня публикуем четвёртую часть перевода руководства по JavaScript, которая посвящена функциям.

→ Часть 1: первая программа, особенности языка, стандарты
→ Часть 2: стиль кода и структура программ
→ Часть 3: переменные, типы данных, выражения, объекты
→ Часть 4: функции
→ Часть 5: массивы и циклы
→ Часть 6: исключения, точка с запятой, шаблонные литералы
→ Часть 7: строгий режим, ключевое слово this, события, модули, математические вычисления
→ Часть 8: обзор возможностей стандарта ES6
→ Часть 9: обзор возможностей стандартов ES7, ES8 и ES9

Функции в JavaScript

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

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Введение

Angular предоставляет удобный декларативный способ подписки на события в шаблоне, с помощью синтаксиса (eventName)="onEventName($event)". Вместе с политикой проверки изменений ChangeDetectionStrategy.OnPush подобный подход автоматически запускает цикл проверки изменений только по интересующему нас пользовательскому вводу. Иными словами, если мы слушаем (input) событие на <input> элементе, то проверка изменений не будет запускаться, если пользователь просто кликает по полю ввода. Это значительно улучшает
производительность, по сравнению с политикой по умолчанию (ChangeDetectionStrategy.Default). В директивах мы также можем подписаться на события на хост-элементе через декоратор @HostListener('eventName').

В моей практике нередко встречаются случаи, когда обработка конкретного события требуется только при выполнении какого-либо условия. т.е. обработчик выглядит примерно так:

(Иллюстрация)

Senior web developer’ы Антон и Алексей продолжают рассказ о непростой борьбе с Nuxt. В предыдущем раунде битвы с этим фреймворком они показали, как запустить проект на Nuxt так, чтобы все были счастливы. В новой статье поговорим о реальном применении фреймворка.

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

После пары раундов обсуждения решили не полагаться на традиционный подход с только серверным рендерингом — но и не загонять себя в ловушку клиентского рендеринга. Как итог мы начали строить решение на базе Nuxt.js.

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

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

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



Это руководство, по замыслу автора, рассчитано на тех, кто уже немного знаком JavaScript и хочет привести свои знания в порядок а также узнать о языке что-то новое. Мы решили немного расширить аудиторию этого материала, включить в неё тех, кто совершенно ничего не знает о JS, и начать его с написания нескольких вариантов «Hello, world!».

→ Часть 1: первая программа, особенности языка, стандарты
→ Часть 2: стиль кода и структура программ
→ Часть 3: переменные, типы данных, выражения, объекты
→ Часть 4: функции
→ Часть 5: массивы и циклы
→ Часть 6: исключения, точка с запятой, шаблонные литералы
→ Часть 7: строгий режим, ключевое слово this, события, модули, математические вычисления
→ Часть 8: обзор возможностей стандарта ES6
→ Часть 9: обзор возможностей стандартов ES7, ES8 и ES9

Как написать девять книг по совершенно разным технологиям, включая Angular, Vue, React, React Native и другим? Что самое важное в обучении, что такое «hallway chat» и вообще, при чём тут Dart и Flutter?

Сегодня у нас в гостях автор множества книг и статей по программированию, включая ng-book — Ari Lerner. Какой будет дальнейшая книга, что автор думает о таком… противоречивом языке, как Dart, и почему на конференциях так важно общаться, спрашивают ребята из программного комитета конференции HolyJS (Дмитрий DmitryMakhnev Махнёв и Евгений bunopus Кот).

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

Полгода назад Google представила обновленную версию своего почтового сервиса. Несмотря на то что многие пользователи были недовольны редизайном, в том числе и на Хабре, это теперь основной интерфейс для пользователей.

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

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

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

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

Зачем парсить свой код? Например, для того, чтобы найти забытый console.log перед коммитом. А что делать, если вам надо изменить сигнатуру функции в сотнях вхождений в коде? Справятся ли тут регулярные выражения? В этой статье будет показано, какие возможности перед разработчиком открывают абстрактные синтаксические деревья.



Под катом — видео и текстовая расшифровка доклада Кирилла Черкашина (z6Dabrata) с конференции HolyJS 2018 Piter.

Недавно мы опубликовали серию материалов, представляющую собой перевод руководства по Node.js. В первой публикации мы интересовались мнением аудитории о целесообразности перевода этого руководства и говорили, что планируется подготовить его PDF-версию.



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

Скачать PDF-версию [ 1.8 Мб ]

Сегодня мы хотим представить вашему вниманию новое руководство того же автора, посвящённое JavaScript.


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

Недавно мы публиковали материал о функциях высшего порядка в JavaScript, направленный на тех, кто изучает JavaScript. Статья, перевод которой мы публикуем сегодня, предназначена для начинающих React-разработчиков. Она посвящена компонентам высшего порядка (Higher-Order Components, HOC).

Предлагаем вашему вниманию подборку с ссылками на новые материалы из области фронтенда и около него.

От переводчика:
Я не являюсь ни профессиональным программистом ни профессиональным переводчиком, но появление описанного в статье инструмента от создателя популярной библиотеки D3.js произвело на меня сильное впечатление.

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

Знакомьтесь, d3.express, интегрированная исследовательская среда.
(с 31 января 2018г d3.express зовется Observable и живет на beta.observablehq.com)

Если вам когда-либо приходилось тупить над своим кодом или разбираться в чужом, тогда вы не одиноки. Эта статья для вас.

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

Предназначение инструмента визуализации — построение визуализаций. Но в чем же цель визуализации? Слово Бену Шнейдерману(Per Ben Shneiderman):

«Результат визуализации — это

Вы стремитесь к тому, чтобы писать аккуратный код, но не знаете с чего начать… Вы вчитываетесь в руководства по стилю, вроде этого от Airbnb, стараетесь следовать практическим рекомендациям ведущих специалистов… Вам приходится удалять неиспользуемый код? Приходится искать ненужные переменные? Вы пытаетесь выявлять неудачные паттерны, применённые в ваших программах? Например — хотите понять, читая хитросплетения кода некоей функции, возвратит ли она что-нибудь или нет. Звучит знакомо? Проблема заключается в том, что программисту очень тяжело и многое успевать, и многому учиться.

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



Автор этого материала говорит, что он сталкивался со всем тем, чему посвящены только что заданные вопросы. То, с чем он столкнулся, утомляет и изматывает. Здесь он хочет рассказать об инструментах, правильное применение которых позволяет решить вышеописанные проблемы.

А именно, здесь пойдёт речь о таких средствах как Prettier, ESLint, Husky, Lint-Staged, EditorConfig, об автоматизации форматирования и линтинга кода. Этот материал ориентирован, в основном, на React-разработку, но рассмотренные здесь принципы можно применить в любом веб-проекте. Вот репозиторий, где, кроме прочего, собрано то, о чём тут пойдёт речь.

Команда скорости Яндекса вручную оптимизирует поисковую выдачу. Делать это вслепую трудно и зачастую просто бесполезно. Поэтому в компании построили инфраструктуру для сбора метрик, тестирования скорости и анализа полученных данных.

О том, какие метрики стоит использовать и как все оптимизировать, знает разработчик интерфейсов Яндекса Андрей Прокопюк (Andre_487).



В основе материала — выступление Андрея на конференции HolyJS. Под катом — и видеозапись, и текстовая версия доклада.