Голосовые помощники — не далёкое будущее, а реальная действительность. Alexa, Siri, Google Now, Алиса встроены в «умные» колонки, часы и телефоны. Они постепенно меняют наш способ взаимодействия с приложениями и устройствами. Через ассистента можно узнать прогноз погоды, купить билеты на самолет, заказать такси, послушать музыку и включить чайник на кухне, лежа на диване в другой комнате.



Siri или Alexa говорят с пользователями в основном по-английски, поэтому в России они не так популярны, как Алиса от Яндекса. Для разработчиков Алиса тоже удобнее: её создатели ведут блог, выкладывают удобные инструменты на GitHub и помогают встраивать ассистента в новые устройства.

Никита Дубко (@dark_mefody в Твиттере) — разработчик интерфейсов в Яндекс, организатор митапов MinskCSS и MinskJS и редактор новостей в Web-стандартах. Никита не работает в Яндекс.Диалогах и никак не связан с Яндекс.Алисой. Но ему было интересно разобраться, как Алиса работает, поэтому он попробовал применить её навыки для Web и подготовил об этом доклад на FrontendConf РИТ++. В расшифровке доклада Никиты рассмотрим, что полезного могут принести голосовые помощники и построим навык прямо в процессе чтения этого материала.

Программный комитет FrontendConf отвечает за отбор заявок, готовит программу, расписание, отвечает за стенды и концепцию. При этом участники ПК еще и курируют доклады спикеров. Задача куратора — помочь со структурой, контентом и довести доклад до идеала. Таких докладов у члена ПК бывает от одного до пары десятков, а еще надо готовить программу и свой доклад, если член ПК еще и спикер на конференции.



Накануне FrontendConf мы взяли у интервью у Сергея Попова (@sergeytovarov) и расспросили обо всем подробнее. Сергей — участник ПК, руководитель Лига А., выступающий спикер. Мы узнали о том, как идет подготовка к конференции, какие доклады он берет на курирование и чего от них ждать зрителям, для чего он выступает, о чем его новый доклад и зачем ходить на конференции.

Что объединяет Trello, Gmail, Aviasales и Google Keep? В каждом из них есть Drag-&-Drop-компоненты, которые можно перетаскивать мышкой. Использование этих компонентов делает сайты по-настоящему удобными, потому что в реальной жизни мы часто используем этот паттерн. Передвигать вещи для нас естественно, поэтому и в вебе мы хотим перемещать элементы по экрану с одного места на другое, как стикеры на доске или магнитики на холодильнике. Сортировка todo-списков, организация дашбордов, загрузка файлов — мы просто не можем себе представить все эти события без перетаскивания элементов на странице.



Но есть нюанс. Когда мы разрабатываем такие компоненты, то думаем, что наши пользователи физически видят экран и элементы, могут зацепиться за них мышкой и перетащить.Часто так и есть, но мы забываем о сегменте пользователей с проблемами зрения. Мы создаем компоненты, которыми невозможно пользоваться большой группе людей, которая просто их не видит. Как сделать так, чтобы им тоже были доступны Drag-&-Drop-компоненты?

Сергей Кригер — фронтенд-разработчик в компании SinnerSchrader. Кроме фронтенд-разработки, активно интересуется темой веб-доступности и расскажет о некоторых способах ее повышения. Под катом — рассказ о создании Drag-&-Drop-компонентов для тех, кто не видит экран и пользуется другими устройствами для взаимодействия с браузером.

Однажды фронтендеру позвонил дизайнер и попросил сделать «паутинку» за запотевшим стеклом. Но потом оказалось, что это не «паутинка», а гексагональная сетка, и не за стеклом, а она уходит вдаль, и с WebGL фронтендер не знаком, а всей анимации пришлось учиться в процессе рисования. Тем фронтендером был Юрий Артюх (akella).



Юрий давно занимается версткой, а по воскресеньям записывает стримы с разбором реальных проектов. Он не профи в WebGL, не делает на нем карты, не пишет на Web-ассемблере, но ему нравится учиться чему-то новому. На FrontendConf РИТ++ Юрий рассказал, как провести одну анимацию от макета до сдачи клиенту так, чтобы все были довольны, и по дороге изучить WebGL. История идет от первого лица и включает в себя: Three.js, GLSL, Canvas 2D, графы и немного математики.

Никита Дубко — разработчик интерфейсов в компании Яндекс. Помимо работы в Яндексе, Никита участвует в организации англоязычной конференции CSS-Minsk-JS и митапов MinskCSS и MinskJS. На FrontendConf на РИТ++ 2019 Никита выступал с докладом «Алиса, пойдем во фронтенд». В нём описан эксперимент по созданию голосового навыка от Алисы от разработчика, который раньше с ней не работал. Доклад интересен тем, что за время, пока выступает спикер, легко создать такой же навык. Рассказ об Алисе зрители выбрали лучшим на всей конференции.



За плечами Никиты десятки выступлений, на каждое из которых уходят недели. Во время подготовки он изучает много нового материала, тренирует выступления на камеру, среди коллег и друзей, оттачивает сценарий и слайды. Поэтому его доклады интересны, увлекательны и заслуженно получают высшие оценки слушателей. О подготовке к докладам, изменениях в жизни, синдроме самозванца, а также о том как выступать на конференциях, чтобы получить работу в Яндекс, в интервью Никиты Дубко. Это не совсем обычное интервью, а текстовая расшифровка подкаста Frontend Weekend, который ведёт Андрей Смирнов. Что из этого получилось, читайте под катом.

Зачем нужен микроконтроллер? Например, чтобы устроить дома пивоварню. Если своего пивного заводика мало, то можно и что-то масштабнее: построить квест-комнату, оформить презентацию, интерактивный фонтан, который рисует картину каплями, или выставочный стенд для большой компании. С микроконтроллером можно сделать что угодно — все зависит от фантазии.

Есть заблуждение, что для создания своих железок требуется знать ассемблер, C/C++, уметь управлять памятью и глубоко понимать электричество. Когда-то так и было, но технологии развиваются и сейчас для полноценной реализации своего проекта достаточно только JS!



Ок, JavaScript мы знаем, а как соединить его с железом? Какое вообще бывает железо и что умеет? Как настроить всю систему? В расшифровке доклада Виктор Накорякова на FrontendConf узнаем: как, с помощью одного лишь JS, управлять сервоприводами, как физически объединить систему с PC, и о вариантах коммуникации приложения на JS. Обсудим пакеты serialport и Firmata, serialport с самописной прошивкой на C++, Espruino и программирование контроллера прямо на JS, Raspberry Pi, HTTP в локальной сети и HTTP и MQTT через облако.

В ежегодном опросе «The state of JavaScript» разработчики рассказывают о том, что они используют здесь и сейчас. Вопросы там знакомы и привычны фронтенд-сообществу. В 2019 году появился опрос «The state of CSS», который ввёл разработчиков в ступор. Оказывается, многие технологии разработчикам не знакомы, хотя большинство из них уже активно используются. Возможно, разработчики используют привычные инструменты и технологии, и не стремятся применять что-то новое? Возможно, просто нет задач под новые технологии? Зачем использовать CSS Grid, CSS Multi columns, там, где проще построить все на Flexbox? Возможно, это все касается старичков, а джуны уже и не знают про Flexbox и Float и в опросах не участвуют?



Сергей Попов (popovsergey), руководитель Лиги А, спикер и организатор конференций задался этими вопросами, провел свой мини-опрос и даже получил результаты от организаторов «The state of CSS». Всю информацию Сергей обработал, структурировал и получил срез фронтенд-сообщества: кто что знает и использует, где учатся верстальщики и сколько зарабатывают, какие технологии актуальны, а какие пора сдавать в переработку, и что изучать, чтобы применять всю мощь CSS. Расшифровка доклада — один из вариантов отчета по актуальному состоянию CSS, вместе с оригинальным отчетом «The state of CSS» подскажет, куда двигаться и какие технологии применять.

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

Почему мы используем фреймворки? Angular, React и Vue помогают нам строить сложные веб-приложения: структурировать код, управлять состоянием и разрабатывать сложные интерфейсы. За последнее десятилетие фреймворки стали стандартом. Дорогим стандартом. С тех пор как фреймворки вошли в обиход, JS сильно раздуло. Страниц весом несколько мегабайт становится больше, и существенная часть этого объема — фреймворк сам по себе. Кажется, это немного, но для пользователя критично — на телефоне или слабом интернете страница может даже не загрузиться. Это проблема.



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

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

Я руковожу Программным комитетом конференции FrontendConf и хочу рассказать как все работает изнутри, объяснить, что мы вложили в программу, почему выбрали те или иные доклады. Почему, при всем обилии информации в интернете, конференции — не просто тематическая тусовка, а реально полезное мероприятие. Рассказать, зачем, в конце концов, мы этим занимаемся, и кто это мы, потому что конференция — это, в первую очередь, люди.



Спикеры — «лицо» конференции: по заявленным и принятым докладам участники судят о полезности события и решают пойти или нет. Но за «кулисами» присутствуют и другие незримые участники мероприятия, которые и определяют, каким будет это лицо. Это Программный комитет. У нас на FrontendConf подобрался коллектив очень классных, активных ребят. Всех, конечно, упомянуть не получится, но постараюсь рассказать и о тех, и о других.

В инвестировании есть понятие «Плохо сейчас — хорошо потом». Инвестор регулярно отщипывает 10, 20% или даже 30% своего заработка на будущее. Эти деньги он инвестирует в облигации, акции, ОФЗ, ETF — кто во что горазд. Сейчас, в моменте, инвестор отбирает у себя свой заработок, лишает себя каких-то благ, чтобы в будущем, на горизонте в 10-20 лет, получить пользу от инвестиций. Прибыль в будущем покроет сегодняшние лишения. Примерно такую же стратегию исповедует Алексей Охрименко (obenjiro), но применительно к разработке — лучше день потерять, а потом за 5 минут полететь.


Источник

На Frontend Conf 2018 Алексей рассказал, как потеряв кучу времени сейчас, в конечном счете его сэкономить потом. Этот доклад не о чувстве скуки и не о том, как бороться с монотонными и рутинными задачами, а о том как потратить время по максимуму — сколько есть, все потратить, и посмотреть, что из этого получится. В расшифровке доклада опыт написания инструментов для отладки, тестирования, оптимизации, скафолдинга и валидации под разные проекты. Бонусом Алексей расскажет о ряде уже существующих инструментов и о пользе, которую они приносят. Давайте выяснять, надо ли вообще на это тратить время.

О докладчике: Алексей Охрименко — разработчик в Avito Frontend Architecture, где немного улучшает жизнь миллионов людей. Ведет подкаст «5 min Angular», а в свободное ото сна и подкаста время организует Angular Meetup вместе с ребятами из Тинькофф, и выступает с огромным количеством разных и спорных докладов.

Качество кода — тема, которая родилась вместе с программированием. Для оценки и контроля качества менеджмента предприятий применяется ISO 9000, для продуктов — ГОСТ и тот же ISO, а вот для оценки качества кода ГОСТа нет. Точного определения и стандарта для качества кода тоже нет.



Каждый разработчик понимает качество по-своему, исходя из опыта. Представления джунов и лидов различаются, и это приводит к разногласиям. Каждая команда для отдельных проектов оценивает код по-своему. Команда обновляется, разработчики уходят, тимлиды сменяются — определение качества меняется. Эту проблему попробует помочь решить Иван Ботанов (StressoID) из Tinkoff.ru — Frontend-developer, преподаватель онлайн-курса по Angular, спикер на митапах и конференциях, ведущий уроков на YouTube и, иногда, тренер команд в компаниях.

В расшифровке доклада Ивана на Frontend Conf поговорим о читаемости, нейминге, декларативности, Code style, и косвенно коснемся отношений джунов и лидов: ошибки, грабли и «сгорание» тимлидов.

Disclaimer: Подготовьтесь морально, в тексте будет много плохого кода, взятого с «особенного» сайта.

JS-приложения, сайты и другие ресурсы становятся сложнее и инструменты сборки — это реальность веб-разработки. Бандлеры помогают упаковывать, компилировать и организовывать библиотеки. Один из мощных и гибких инструментов с открытым исходным кодом, который можно идеально настроить для сборки клиентского приложения — Webpack.

Максим Соснов (crazymax11) — Frontend Lead в N1.RU внедрил Webpack в несколько больших проектов, на которых до этого была своя кастомная сборка, и контрибьютил с ним несколько проектов. Максим знает, как с Webpack собрать бандл мечты, сделать это быстро и конфигурировать так, чтобы конфиг оставался чистым, поддерживаемым и модульным.


Расшифровка отличается от доклада — это сильно усовершенствованная пруфлинками версия. По всей расшифровке рассыпаны пасхалочки на статьи, плагины, минификаторы, опции, транспайлеры и пруфы слов докладчика, ссылки на которые просто не поставить в выступление. Если собрать все, то откроется бонусный уровень в Webpack :-)

В последнее время веб-разработка разделилась. Теперь мы все не full-stack программисты — мы фронтендеры и бэкендеры. А самое сложное в этом, как и везде, это проблема взаимодействия и интеграции.

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

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

В темные века верстальщики строили сайты на таблицах. Потом они освоили float и flexbox, и тьма отступила. В 2017-м наступила эпоха Просвещения с приходом CSS Grid Layout.

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



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

Об этом расшифровка доклада Сергея Попова на Frontend Conf: про спецификацию, про то, почему верстальщики боятся Grid и как решиться применять сетку в своих проектах, чтобы «Make your website great again!».

Браузеру для исполнения JavaScript нужно немножко памяти, нужно же где-то хранить объекты, примитивы, функции, которые создаются на все действия пользователя. Поэтому браузер сначала выделяет нужный объем RAM, а когда объекты не используются — чистит её самостоятельно.

В теории звучит хорошо. На практике пользователь открывает 20 вкладок с YouTube, соцсетями, что-то читает, работает, браузер ест память, как Hummer H2 — бензин. Сборщик мусора, как этот монстр с шваброй, бегает по всей памяти и добавляет неразберихи, все тормозит и падает.



Чтобы таких ситуаций не происходило и производительность наших сайтов и приложений не страдала, фронтенд-разработчику стоит знать, как мусор влияет на приложения, как браузер его собирает и оптимизирует работу с памятью и как это все отличается от суровой реальности. Как раз об этом доклад Андрея Роенко (flapenguin) на Frontend Conf 2018.

Мы пользуемся сборщиком мусора (не дома — во фронтенд-разработке) каждый день, но особо не задумываемся, что он вообще есть, чего это нам стоит и какие у него есть возможности и ограничения.

Если бы в JavaScript действительно работала сборка мусора, большинство npm-модулей удаляли бы сами себя сразу после установки.

Но пока это не так, и мы поговорим про то, что есть — про сборку ненужных объектов.