Всем привет! 

Меня зовут Святослав. Я лидирую разработку сервисов оформления ипотеки в компании Домклик. Не так давно наша компания взяла курс на внедрение философии Progressive Web Application в наших клиентских сервисах.

Одним из важных аспектов PWA является использование технологии Service Worker API. Однако технология не так проста, как кажется на первый взгляд. Для эффективного использования нужно пройти тернистый путь из квестов, связанных с особенностями жизненного цикла воркеров, неполной поддержкой браузерами, проблемами с политикой кэширования и попутно встречающимися сайд-эффектами (кэширование устаревшего контента, сломанные ссылки и другое).

Workbox - это набор инструментов, предоставляющих высокоуровневый API для конфигурации и работы с такими браузерными технологиями как Service Worker API и Cache Storage API. Инструментарий состоит из набора изолированных модулей, которые помогут сделать ваше приложение "offline-ready". 

Недавно мы на Хабр Карьере устроили конкурс ко дню эйчара и попросили эйчаров и ИТ-рекрутеров рассказать нам о самых смешных собеседованиях, которые стали легендами в их компаниях. И в ответ получили столько историй, что хватило бы на небольшую книгу! Оказывается, работая эйчаром, можно познакомиться с семьёй и домашними любимцами кандидата, узнать о его кулинарных предпочтениях, стать объектом романтического внимания или свидетелем ДТП. 

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

Недавно опциональный доступ к аттрибутам (Optional Chaining) и значение по умолчанию для атрибутов (Nullish Coalescing) перешли на последний, четвёртый этап процесса TC39.

На практике это означает, что эти и другие нововведения станут частью стандарта JavaScript уже в этом, 2020 году. Их мы и рассмотрим в этой статье.

Отслеживать поддержку браузерами можно здесь («2020 features») — прим. перев.

Как создать Простой веб-сервер, используя только стандартные инструкции nodejs

Часто для разработки MPA/SPA/PWA приложений требуется простой веб-сервер. Однажды, на одном большом митинге в ответ на вопрос: «Что ты делал?», я сказал, что поднимал веб-сервер для хостинга PWA приложения. Мы все долго смеялись и да, кстати, PWA это не клей. Как SPA — это не косметический салон. Все это виды веб-приложений. А SSR это не страна :-). Если запустить такое приложение просто открыв стартовую страницу index.html через браузер, оно не будет работать как должно, в лучшем случае мы получим оффлайн версию. Я люблю язык JavaScript и буду решать проблему, используя только доступные мне средства, так сказать из "коробки".

Продолжаю делать расшифровку своего доклада Docker для фронтендера с конференции FrontendConf 2019.

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

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

Вот вы сделали что-то новое и крутое, приходит мысль — выложить в опенсорс и опубликовать в npm.

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

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

На самом деле всё это может занять у вас меньше часа. Без знаний DevOps и совершенно бесплатно.

Необходимое вступление

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

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

Столь малые гарантии поднимают вопросы о причинах, по которым статья пишется. Я считаю, что этим вещам должны учить везде, где учат программированию, вплоть до уроков информатики в школах с углублённым её изучением. Тем не менее, для меня стала пугающе нормальной ситуация, когда я узнаю, что собеседник мой коллега, причём работающий уже не первый год, но про инкапсуляцию «что-то там слышал». Необходимость собрать всё это в одном месте и давать ссылку при возникновении вопросов зрела давно. А тут ещё и мой «pet-project» дал мне изрядно пищи для размышлений.

Тут мне могут возразить, что учить эти вещи в школе рановато, и вообще на ООП свет клином не сошёлся. Во-первых, это смотря как учить. Во-вторых, 70% материала этой статьи применимо не только к ООП. Что я буду отмечать отдельно.

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

Этой осенью Яндекс.Маркету исполняется 18 лет. Все это время развивается партнерский интерфейс Маркета. Если кратко, то это админка, с помощью которой магазины могут загружать каталоги, работать с ассортиментом, следить за статистикой, отвечать на отзывы и т.д. Специфика проекта такова, что приходится очень много взаимодействовать с различными бэкендами. При этом данные не всегда можно получить в одном месте, из одного конкретного бэкенда.