Среда, мои программисты. Раздаём всем фруктов сегодня:

https://v.thecode.media/7pfwi

#пб_Код

roadmap.sh

Этот сайт предоставляет дорожные карты, рекомендации и другой образовательный контент, чтобы помочь разработчикам выбрать путь и направить свое обучение. Особенно полезно для новичков.

Немного расширим кругозор в построении архитектур приложений или проще говоря в системном дизайне. Ниже полезная статья про частный пример Event-Driven архитектуры для реального приложения. Статья расскажет как организовать EDA с медиатором с использованием Kubernetes и AWS:

➡️ https://www.infoq.com/articles/eda-mediator/

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

#architecture #systemdesign

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

➡️ https://devcenter.heroku.com/articles/increasing-application-performance-with-http-cache-headers

От себя:
В статье выше покрыты основные моменты с кешем которых хватит для 99% задач. Для оставшегося 1% можно посмотреть описание всех свойств Cache-Control хедера (тыц) или уже гуглить свой конкретный кейс.

P.S. Если у вас на проекте NestJS, то можно поиграться с CacheInterceptor, как тут

Prettier выпустил мажорную версию 3.0.0! Изменений много, все перечислены тут:

➡️ https://prettier.io/blog/2023/07/05/3.0.0.html

От себя:
Очень большой релиз. Команда внесла много breakage изменений, поэтому обновляться нужно осторожно и точно отдельной полноценной задачей.

Из существенного можно отметить:

#1 Теперь trailingComma:”all” по-дефолту. Вернуть дефолтное поведение 2й версии можно выставив trailingComma:”es5”. Если говорить в целом, то я выставляю trailingComma:”none”, т.к. не вижу никаких преимуществ в запутывающей запятой. Кто-то скажет, что это помогает быстрее писать код (якобы не нужно постоянно думать поставил запятую в конце объекта/массива/функции/типа и т.д - она будет добавляться автоматом, если правильно настроены автофиксеры), но мне этого не понять, т.к. мы вроде как не машинистки, а программисты. Наше основное затраченное время - это мыслительные процессы, а не печатание 🙂

#2 Выпилили поддержку Flow специальных комментариев для Flow. Слишком мало кто использует Flow и их директивы, а код поддерживать нужно - решили в мусорку, чем затраты времени. Как ранее писал (тыц1, тыц2), переезжайте на TypeScript и будет вам счастье

#3 Неплохо улучшили поддержку TS. Добавили много приятных изменений/фиксов для форматирования типов, ключевых слов и т.д. Бывало такое, что после пробежки Prettier-ом типы становились менее читаемыми, чем хотелось бы. Новая версия должна помочь

Любой веб-разработчик рано или поздно сталкивается с CSS. Но речь ниже пойдет не про новые свойства или новомодные CSS-приемы (для этого есть прекрасный https://css-tricks.com/), а про организацию стилей в вашем приложении. Возможно, термин «организация стилей» может прозвучать громче, чем будет на самом деле 😁

С незапамятных времен разработчики пытались превратить необъятную массу селекторов и CSS-файлов в лаконичную структуру. Многие из вас слышали про методологии организации CSS. Проговаривать и пояснять за каждую здесь не буду, а приведу ссылки для общего ознакомления (тыц1, тыц2). Как видно из статей, основные методологии - это BEM, OOCSS, SMACSS, Atomic CSS. Но хоть они и существуют сколько существует CSS, по инфографике от https://stateofcss.com/ о них знает оптимистично не более 2/3 опрошенных разработчиков (тыц1, тыц2). Забавный момент, что CSS-методологии исключили из опроса начиная с 2021 года (или еще не успели добавить результаты?). Но по тренду 2019->2020 видно, что он снисходящий. Тема становиться менее неактуальной для разработчиков на сегодня, поэтому нет большого смысла углубляться и разбираться в нюансах каждой их методологий 👹

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

1. Использовать готовые фреймворки (тыц на наиболее популярные за 2022 год)

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

2. Автосборочные решения

В настоящий момент наиболее ходовой подход к автосборке и генерации CSS - это пре-/пост-процессоры (тыц на наиболее популярные за 2022 год) и CSS-in-JS (тыц на наиболее популярные за 2022 год).

Обе опции - это CSS на максималках со всеми вытекающими, поэтому минус (но минус ли?) такого подхода - необходимость описания стилей и организация их хранения. Пришли с чего начинали пост 🙃 Но не все так плохо, ведь всё большее предпочтение уходит к CSS-in-JS, а его основное преимущество в изолированности пространства имен селекторов (решается проблема перекрытия стилей) и возможность использовать стили, как обычный код (решается проблема дублирования с добавлением переиспользования стилей).

На счет организации стилей в приложении: самая простая и мощная структура - держать стили максимально близко к месту их использования. Идеально - в рамках одной папки или в файле с компонентом. Примеры таких организаций стилей: тыц1, тыц2, тыц3. Но проекты у всех разные, поэтому гуглите конкретно под свою ситуацию и/или читайте рекомендации по стилям к вашим фреймворкам (пример для next.js)

#css

Бонус: Stylelint

Говоря про стили, нельзя не упомянуть Stylelint. Как и основной код, описанные стили требуют проверки на корректность и упорядоченность. Если с вопросом проверки проблем не возникает, т.к вполне достаточно использовать stylelint-config-standard с уже готовым выстраданным набором правил, то с порядком свойств не всё так однозначно ведь он тревожит умы не первый десяток лет (тыц на пост за 2012 год). Но под самым популярным Grouped by type каждый понимает своё.

На сегодня существует несколько вариантов порядка стилей с готовой конфигурацией для Stylelint. Для удобства ссылки на модули приведу в инфографике на npmtrends. Расписывать про каждую не буду, но лично мне больше всего импанируют stylelint-config-property-sort-order-smacss, stylelint-config-recess-order и stylelint-config-concentric-order. Они отличаются незначительными деталями, но их объединяет общая идея - модель упорядочивания свойства. Первоочередно идут те свойства, которые влияют на то, как элемент вписан в страницу к свойствах изменяющим внешний вид элемента

#css #stylelint

Зачастую есть необходимость быстро и непрерывно получать/обмениваться данными с сервером. Зачастую, для такого типа задач используют вебсокеты. Но если ваша задача ограничена только получением данных с сервера без обратной связи, то есть хорошая, незаслуженно забытая, альтернатива - Server-Sent Events. Про разницу, плюсы/минусы можно почитать тут:

➡️ https://blog.bitsrc.io/websockets-vs-server-sent-events-968659ab0870

От себя:
Вообще, задался вопросом про удобство SSE после прочтения лонгрида (тыц) о разработке дизайна системы для «живых комментариев» (aka комментарии к Live-трансляциям). Дизайн применим к любому высоконагруженному сервису с живым комментированием такие как YouTube, Twitch, Facebook, и т.д. В статье довольно подробно описано почему выбран именно SSE, а не другие альтернативы (про них тоже рассказано). Пересказать всё сложно, лучше прочитать самому. Но в голове нужно держать мысль, что не только вебсокетами едины и есть альтернативы.

Из личного опыта проблем с вебсокетами могу отметить две:

1. Скейлинг вебсокет-серверов. А точнее его отсутствие из коробки
Если не хочется тянуть сторонние библиотеки, то решить проблему получится только написав свою 🙃 Со сторонними библиотеками скейлинг настроить можно (например, у socket.io за это отвечает адаптер), но это требует лишних усилий как разработчика, так и девопса.
К слову, в свое время socket.io mongodb adapter работал некорректно и в итоге пришлось написать свой.

2. Несовместимость с proxy-серверами
Зачастую прокси-сервера просто не поддерживают вебсокеты из-за их технической природы (вебсокеты идут поверх TCP, что усложняет поддержку для прокси-серверов). Поэтому, опять приходится прибегать к сторонним решениям с поддержкой long-polling, как у вышеупомянутого socket.io (тыц)

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

Задача сборки фронтенда стара как мир. С давних времен стандартом для этого служит webpack. Он используется практически повсеместно, во много известном софте. Но его основная проблема - медлительность. На сегодня есть достойные конкуренты в лице Vite, Parcel.js, Rollup.js и т.д, но проблема общая - проблема переезда существующего приложения с webpack на альтернативу. Такая задача может отнять неподъемное количество времени и быть скорее в тягость, нежели в удовольствие. Но, что если появится быстрый сборщик совместимый с webpack-конфигурацией?

И такой нашелся! Встречайте rspack:

➡️ https://blog.stackademic.com/rust-port-of-webpack-rspack-the-new-kid-on-the-block-c3a3de569bfb

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

Как вызвать черную дыру на практике:

Эксперимент с созданием NPM-пакета, зависимого от всех пакетов в репозитории https://opennet.ru/60392/

Немного чтива на выходные:

➡️ https://tontinton.com/posts/database-fundementals/

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

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

➡️ https://rxdb.info/articles/websockets-sse-polling-webrtc-webtransport.html

Иногда в декораторе nestjs нужно заинжетить какой-то из сервисов. Рецепта из коробки нет, увы, но добрые люди придумали способ как это сделать:

➡️ https://liftoffllc.medium.com/nestjs-clean-code-with-decorators-85b124eb13b1

Решение немного сумбурное, но рабочее (успешно применил в своем проекте). Поэтому пользуйтесь в случае необходимости

Хорошая, достаточно подробная статья по работе с изображениями в HTML. Пояснено и прояснено много нюансов:

➡️ https://kurtextrem.de/posts/modern-way-of-img

JetBrains проводит ежегодное большое исследование состояния айтишки:

➡️ https://surveys.jetbrains.com/s3/developer-ecosystem-survey-2024-sh?pcode=24918498197270551

Если есть желание, то можете пройти и попробовать выиграть один из призов (призы неплохие). Сам один раз смог выиграть Amazon Gift card на их исследовании - вдруг повезет и вам 😄

Немного философии о сложности разрабатываемого ПО и систем:

➡️ https://olano.dev/blog/a-note-on-essential-complexity/

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

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

Поэтому, всегда помнить, что будущее может не наступить - и это происходит чаще, чем его наступление. Не бегите впереди паровоза 😅

#systemthinking #software