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

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

В Авиасейлс у нас много маленьких продуктовых команд. То есть, в каждой команде есть свои фронтендеры, бекендеры, 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-генотипирования и онкогенетики.
Нужно будет разрабатывать продукты для специалистов в области анализа и интерпретации геномных данных.

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

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