Штош, было забавно. Клабхаус я так и не распробовал, странная штука.

Мы в программном комитете Frontend Crew придумали пять тем для предстоящей конференции ☺️

Помогите выбрать лучшие. Среди проголосовавших разыграем пару билетов 💙

https://forms.gle/BbVx4PhssjdWrJ5aA

Ищем в Авиасейлс специалиста по информационной безопасности!

https://www.aviasales.ru/about/vacancies/2606969

Лучшая в мире компания, крутейший продукт, ремоут (или релокация).

Страховка, спорт, обучение, психотерапия и куча всего ещё — просто лучшие условия.

​​Новый выпуск подкаста!

Дима @ZeroBias сделал супер-крутой Effector — современный менеджер состояния для фронтенд приложений. Поговорили про фуллтайм опенсорс, спонсорство от компаний, проблемы современных UI-библиотек и недооцененных фронтендеров.

+ Патреон Димы — https://www.patreon.com/zero_bias
+ Новости экосистемы Effector — @effector_tips_ru
+ Процесс размышлений о реализации визуализации — @lines_of_code
+ Личный канал Димы — @leadingedge

Вот тут можно написать фидбек и мне будет радостно👇

Вжух, снова ищу пару неопытных фронтенд-инженеров. Пишите, расскажу подробнее.

Набраны ☺️

​​В эти выходные участвовал в хакатоне EBASH48. На мой взгляд, одна из главных ценностей хакатонов — попробовать новые подходы и технологии в реальном проекте. Одна из опробованных технологий поразила меня так сильно, что, возможно, мы затащим ее в большой продакшн.

Linaria — это CSS-in-JS библиотека с нулевым рантаймом и шикарным API, почти полностью повторяющий styled-components. Я сравнивал ее с SASS (потому что мы используем его в боевых проектах) и вот почему Linaria выигрывает:
+ Обычный CSS, без миксинов, сасс-переменных и прочего дерьма;
+ Шикарные динамические стили через CSS-переменные;
+ Удобный скоупинг всего — от класснеймов до кастомных переменных и кейфремов.

Linaria — лучшее решение для написания CSS в React-приложениях, что я встречал, просто кайф 😍

Реляционная модель vs документноориентированная модель

Большая часть приложений работает с объектами, которые не очень хорошо ложатся на реляционную модель — это называют рассогласованием (impedance mismatch). Часто это проблема решает через ORM, но фигово.

С другой стороны, если структура данных представляет собой независимый документ, то ее удобно сохранить в документноориентированную БД (MongoDB, RethinkDB, CouchDB, Espresso) в виде JSON.

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

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

В документноориентированных БД используется schema-on-read — схема данных неявная и их интерпретация происходит при чтении. В реляционных — schema-on-write, то есть схема данных проверяется при записи и все данные в базе гарантированно ей соответсвуют.

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

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

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

#dia

Закончу историю про цели нашего фронтенд-департамента 🤓

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

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

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

Может показаться, что мы придумали микрофронтенды, но это не совсем так. Дело в том, что сейчас вся эта система имеет две особенности:
+ все отношения определяются статически, еще при сборке бандлов известно какие виджеты присутствуют на странице и как они связаны между собой;
+ все виджеты и отношения деплоятся одновременно и приезжают на клиент в одном бандле.

Вероятно, в будущем мы будем развивать эту систему и придём к более трушным микрофронтендам 🤷‍♂️

#кейс

Сегодня ровно год, как я уехал из России и живу на Пхукете.

Написал в твиттере здоровенный тред про это — https://twitter.com/kamyshev_code/status/1370977190649552896?s=20

Посмотрел сегодня отличный доклад — Энтерпрайз, который выжил

Очень мотивирующий!

#softskills

​​Build your own React

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

Я уверен, что если ты 90% времени на работе делаешь приложения на React, то обязан знать как он устроен. Пусть поверхностно, но важно знать почему происходит та или иная дичь.

Чтобы не читать исходники React, можно пройти маленький бесплатный онлайн-курс Build your own React. Автор за ручку проводит через основные концепции и термины, а в конце получается полностью функциональная личинка фреймворка.

#фронтенд

SvelteJS under the hood

Я уверен, что Svelte, или какой-нибудь его более удачный последователь, станет фронтенд-фреймворком номер 1 совсем скоро.

Вчера посмотрел крутейший доклад SvelteJS under the hood, в нём Павел доступно рассказывает о внутренностях фреймворка — рантайме и компиляторе. Еще раз убедился, насколько это восхитительная технология!

#фронтенд

Моя хорошая комрадка нуждается в новых программистах 🤗

Parseq Lab ищут фронтендеров (Vue.js, TypeScript) и бэкендеров (Java/Kotlin).
Ребята делают комплексные решения для генетических исследований в области диагностики наследственных заболеваний, HLA-генотипирования и онкогенетики.
Нужно будет разрабатывать продукты для специалистов в области анализа и интерпретации геномных данных.

Предлагают:
— Белую зарплату
— Обеды в офисе
— Крутую бизнес-область
— Сильную команда разработчиков, биоинформатиков и генетиков

Требуют:
— Готовность погрузиться в предметную область: молекулярную биологию и генетику
— Стремление делать качественный продукт

Я сейчас изучаю проектирование распределённых асинхронных систем. В рамках этого проекта посмотрел доклад «Алгоритмы консенсуса. При чем тут Node.is?» В нём Андрей Печкуров рассказывает про проблематику распределённых систем, CAP-теорему, алгоритмы консенсуса и подробно разбирает один из них.

Посмотрите доклад — распределенные системы сейчас повсюду, полезно понимать, какие сложности возникают при их создании и эксплуатации.

#проектирование

До работы в Авиасейлс я два года рулил небольшими командами — в Breadhead и в Самокате. Я невероятно рад, что последний год работаю просто инженером. На самом деле, мне нравилось быть полу-менеджером, просто у меня получалось не очень хорошо.

Особенно в Breadhead. Когда я пришёл туда работать, оказалось что вся команда разработки уволилась и кроме меня осталась только пара джуниоров и стажёр. Так я случайно стал лидом. Сначала у меня получалось совсем плохо, потом по-лучше, но закончилось все выгоранием и сменой работы. Простите меня, ребята.

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

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

#рост

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

Чтобы прокачаться во всем этом, я записался на курс Феди Борщёва и Марьяны Оныско — Стать тимлидом. Курс состоит из 5 недель-тем:
+ Как договариваться с бизнесом, командой и собой
+ Найм команды, налаживание коммуникаций для работы в кайф
+ Процессы и ритуалы в команде
+ Создание продукта и понимание бизнеса
+ Работа с техдолгом и качеством кода

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

А ещё, мне выдали промокод на скидку 10% — kamkam — чтобы я пошарил его вам.

#рост #партнерский_материал

Последнее время большую часть времени я работаю над платформой для развития фронтендов внутри Авиасейлс.

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

Посмотрел про это доклад «Как мы в Tinkoff принимаем архитектурные решения». Он довольно высокоуровневый, но как вводная лекция — просто отлично.

#архитектура