Круглый стол закончился, это было восхитительно. Посмотрите запись, там много интересных штук 🤣

https://youtu.be/ll3aCbLMLqI

Напишите потом ощущения 🙏

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

Найти такую аналитику оказалось не просто, но в итоге я остановился на https://plausible.io/

Во-первых, они удовлетворяют всем моим требованиям.

Во-вторых, у них есть ряд приятных бонусов, о которых я даже не думал: возможность не ставить GDPR-баннер для Европы, классные имейл-дайджесты и сорцы на Elixir.

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

Если вам понадобится простая и классная аналитика — возьмите эту.

#рекомендации

Субботний мини-анонс! Мы с Лешей Войцеховским (@crazymidnight) запустили твиттер-аккаунт с новостями фронтенда. Есть один нюанс — все твиты написаны нейросетью 🌚

Подписывайтесь, ставьте лайки, кекайте с удовольствием — https://twitter.com/neurofront

Из-за декабрьского факапа с подкастом у меня совсем пропало желание его дальше делать.

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

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

​​Сто лет не делал дайджест, а вот сейчас решил сделать 🌴

+ Как Netflix ведет разработку продукта. Обзор на книжку, обзор хороший, книжку не читал.

+ System Design для самых маленьких. Хорошая вводная статья, там в блоге есть еще небольшие заметки по более узким темам, тоже классные.

+ Introducing Zero-Bundle-Size React Server Components. Некоторые говорят, что это будушее фронтенд-разработки, почитайте пост в блоге.

+ Очарованные циферками. Интересные мысли про дата-дривен-что-угодно.

Наслаждайтесь!

#дайджест

Больше года назад мы в Самокате сделали прекрасную систему передачи параметров во фронтенд приложение во время деплоя. Я тогда написал черновик статьи про это, а потом целый год не мог его довести до нормальной статьи.

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

https://habr.com/ru/post/541314/

#фронтенд #удобство_разработки

JetBrains Academy ищет автора статей про Unix Shell (Bash)

Ребята ищут человека, который возьмёт на себя раздел Bash. Это классная парт-тайм ремоут работка, с большой творческой свободой и классной командой.

👉 Подробности

Масштабируемость

Готовность приложения к решению проблем возникающих при росте нагрузки.

Чтобы говорить о масштабируемости системы, нужно выделить ключевые параметры нагрузки (например, число запросов в секунду, отношение операций записи к операциям чтения, etc.)

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

Для веб-сервисов самые важные метрики производительности — время ожидания и время отклика. Часто смотрят на медиану, 95-й перцентиль, 99-перцентиль и 99.9-й перцентиль.

> Измерять время отклика внутри приложения не стоит, это даёт недостоверные результаты. Лучше замерять на клиенте.

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

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

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

#dia

Удобство сопровождения

Это в первую очередь возможность эффективной работы всех специалистов (разработчиков, админов, вот эвер) с системой.

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

+ удобство эксплуатации (мониторинг, автоматизация, документация, разумные дефолты, возможность самовосстановления, принцип наименьшего удивления, независимость от среды исполнения);

+ простота понимания (хорошие абстракции, явные зависимости, низкое сцепление модулей);

+ возможность развития на уровне всей системы.

#dia

Сегодня в 18 МСК буду в Клабхаусе, залейтайте.

https://www.joinclubhouse.com/event/P9g8oRjA

Мы в эфире, заходите 🤗

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

Мы в программном комитете 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