Веб-разработка *

В середине 2018 года в Sports.ru задумались о переезде на новый WYSIWYG-редактор текста для пользовательских постов. С июня 2019 года редактор работает в режиме бета-версии. За это время мы решили множество проблем, связанных как с проектированием архитектуры всего сервиса, так и с реализацией самого редактора в браузере на основе библиотеки ProseMirror, и решили поделиться своим опытом.

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



Автор статьи, перевод которой мы сегодня публикуем, хочет рассказать о нескольких мощных, но малоизвестных клиентских фреймворках и библиотеках, основанных на JavaScript. Конечно, «большая тройка», в лице Angular, React и Vue, никуда не делась, но в мире веб-разработки есть и другие инструменты, достойные внимания. Такие, например, как Svelte, Preact и Riot. Вопрос выбора подходящего средства зависит от многих факторов. Среди них — знания разработчика, особенности проекта, ситуация на рынке. Поэтому давайте рассмотрим малоизвестные фреймворки, расширив тем самым свободу выбора тех, кто ищет подходящий инструмент для своего очередного проекта.

Если вы пытаетесь разобраться, какой из этих двух замечательных фреймворков выбрать, читайте мнение сторонника Vue по этому вопросу, которое я перевел и дополнил.

Переведено при поддержке облачной платформы Mail.ru Cloud Solutions.

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

Кроме огромных репозиториев с источниками для подготовки к интервью, здесь много чего интересного

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

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

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

Веб-браузеры медленно но верно реализуют большинство функций операционной системы, и остается все меньше причин разрабатывать нативное приложение, если можно написать веб-версию (PWA). Кроссплатформенность, богатое API, высокая скорость разработки на TS/JS, и даже производительность движка V8 — все идет в плюс. Браузеры уже давно умеют работать с видеопотоком и запускать нейронные сети, то есть мы имеем все компоненты для создания системы видеонаблюдения с распознаванием объектов. Вдохновленный этой статьей, я решил довести демо-пример до уровня практического применения, чем и хочу поделиться.

Приложение записывает видео с камеры, периодически отправляя кадры на распознавание в COCO-SSD, и если обнаружен человек — фрагменты видеозаписи порциями по 7 секунд начинают отправляться на указанный емейл через Gmail-API. Как и во взрослых системах — ведется предзапись, то есть мы сохраняем один фрагмент до момента детекции, все фрагменты с детекцией, и один после. Если интернет недоступен, или возникает ошибка при отправке — видеозаписи сохраняются в локальной папке Downloads. Использование емейла позволяет обойтись без серверной части, мгновенно оповестить хозяина, а если злоумышленник завладел устройством и взломал все пароли — он не сможет удалить почту у получателя. Из минусов — перерасход трафика за счет Base64 (хотя для одной камеры вполне хватает), и необходимость собирать итоговый видеофайл из множества емейлов.

Работающее демо здесь.

Проблемы возникли следующие:

Автор статьи, перевод которой мы публикуем сегодня, хочет рассказать о том, как упаковывать в контейнеры Docker веб-приложения, основанные на React, Express и MongoDB. Здесь будут рассмотрены особенности формирования структуры файлов и папок таких проектов, создание файлов Dockerfile и использование технологии Docker Compose.

В прошлом году к Яндексу присоединился сервис TheQuestion. На тот момент уже был схожий сервис вопросов и ответов — Яндекс.Знатоки. У Знатоков была большая аудитория и много интересных вопросов, но не хватало экспертов, которые могли давать качественные ответы на эти вопросы. TheQuestion же, наоборот, имел сильное сообщество экспертов, но ему не хватало интересных вопросов. Логичным шагом было объединить два сервиса, чтобы взять лучшее у каждого из них. Но как это сделать, если у каждого сервиса своя технологическая база, контент и пользователи?

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

Когда в Sports.ru понадобился свой WYSIWYG-редактор, мы решили сделать его на основе библиотеки ProseMirror. Одной из ключевых особенностей этого инструмента является модульность и широкие возможности кастомизации, поэтому с его помощью можно очень тонко подогнать редактор под любой проект. В частности, ProseMirror уже используют в The New York Times и The Guardian. В этой статье мы расскажем о том, как с помощью ProseMirror написать свой WYSIWYG-редактор.

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



Под катом — видео и расшифровка доклада Артема Ерошенко из Qameta Software с конференции Heisenbug. Он представил несколько разработанных простых и элегантных решений, которые помогают команде Яндекс.Вертикалей оценивать покрытие тестов, написанных автоматизаторами тестирования. Артем расскажет, как можно быстро узнавать, что покрыто, как покрыто, какие тесты прошли, и мгновенно смотреть наглядные отчеты.

Вносить однотипные изменения в три-четыре разных места в JS-коде — искусство, требующее концентрации внимания. Если элементов больше, поддержка кода превращается в муку. Поэтому для долгосрочных или крупных проектов следует писать код так, чтобы его можно было вынести в отдельные компоненты.

Я занимаюсь фронтенд-разработкой уже 10 лет и расскажу о применении компонентов для создания элементов фронтенда — это значительно упрощает жизнь фронтенд-разработчика.

Написано при поддержке Mail.ru Cloud Solutions.

Доброго времени суток, друзья!

Вероятно, многие из вас слышали о таком новшестве в экосистеме JavaScript, как сервис-воркеры (Service Workers), которые являются ключевым элементом современной веб-разработки. Сервис-воркеры становятся все более востребованными, в первую очередь, благодаря популярности прогрессивных веб-приложений (Progressive Web Applications — PWA).

Когда я впервые услышал о них, я задался вопросом: «Когда мы должны использовать сервис-воркеры? В каким сценариях или контексте мы можем их использовать?»

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

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

Привет! Меня зовут Алексей Пьянков, я разработчик в компании Спортмастер. В этом посте я рассказал, как начиналась работа над сайтом Спортмастер в 2012 году, какие инициативы удалось «протолкнуть» и наоборот, какие грабли мы собрали.

Сегодня я хочу поделиться мыслями, которые следуют за другим сюжетом – выбор системы кеширования для java-бэкенда в админке сайта. Этот сюжет имеет особое значение для меня – хотя история разворачивалась всего 2 месяца, но эти 60 дней мы работали по 12-16 часов и без единого выходного. Никогда раньше не думал и не представлял, что можно так много работать.

Поэтому текст разбиваю на 2 части, чтоб не загрузить по полной. Наоборот, первая часть будет очень легкой — подготовкой, введением, некоторыми соображениями, что такое кеширование. Если вы уже опытный разработчик или работали с кешами — с технической стороны ничего нового в этой статье, скорее всего, не будет. А вот для джуниора небольшой такой обзор может подсказать, в какую сторону смотреть, окажись он на таком распутье.

Автор статьи, перевод которой мы сегодня публикуем, предлагает, пользуясь чистым CSS, создать механизм изменения цвета текста ссылки при наведении на неё мыши. Но это должна быть не обычная смена цвета. Новый цвет должен заполнять ссылку слева направо, заменяя старый.

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

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

Однако если вы достаточно долго работаете с разного рода задачами, вероятней всего вы столкнетесь с чем-то, что требует некоторых знаний в области бэкенда.

Ниже представлен краткий список того, о чем должен знать разработчик интерфейсов.

Синий кит — отличный пример того, как проектирование сложного проекта пошло не по плану. Кит внешне похож на рыбу, но он млекопитающее: кормит детенышей молоком, у него есть шерсть, а в плавниках до сих пор сохранились кости предплечья и кистей с пальцами, как у сухопутных. Он живет в океанах, но не может дышать под водой, поэтому регулярно поднимается на поверхность глотнуть воздуха, даже когда спит. Кит самое большое животное в мире, длиной с девятиэтажный дом, а массой как 75 автомобилей Volkswagen Touareg, но при этом не хищник, а питается планктоном.

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



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

Что такое DDD и какие инструменты в нем есть, мы расскажем в статье на основе доклада Артема Малышева. Подход DDD в Python, инструменты, подводные камни, контрактное программирование и проектирование продукта вокруг решаемой проблемы, а не используемого фреймворка — все это под катом.

Свежая подборка со ссылками на новости и материалы. В выпуске: релизы Laravel 7 и CodeIgniter 4, атрибуты v2 и другие RFC-предложения из PHP Internals, порция полезных инструментов, видео, подкасты и многое другое.

Приятного чтения!

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