Чем отличается HTTP/2 от HTTP/1.1

Спецификация HTTP/2 была опубликована в мае 2015, и это стало одним из важнейших шагов по улучшению производительности всего интернета за последние 10 лет. Какие же существенные отличия в сравнении с HTTP/1.1 нужно иметь ввиду:

1️⃣ Бинарный протокол. HTTP/2 использует бинарный протокол для передачи данных, в то время как HTTP/1.1 использует текстовый формат. Бинарные данные меньше по объему - скорость передачи и обработки увеличивается.

2️⃣ Мультиплексирование. В HTTP/1.1 для экономии времени на установление нового TCP-соединения (а так же SSL/TLS в случае https) использовалась техника keep-alive, чтобы слать запросы через одно соединения, но в блокирующем режиме: сначала должен прийти ответ на первый запрос, чтобы можно было отправить второй. В HTTP/2 через одно TCP-соединение можно отправлять множество запросов параллельно.

3️⃣ Приоритизация. HTTP/2 вводит приоритизацию для потоков данных. Это дает возможность клиентам (например, браузеру) более рационально использовать единое TCP-соединения. Теперь запросить все данные у сервера можно одновременно, но поступать на клиенты они будут в заранее выбранном порядке.

4️⃣ Сжатие заголовков. Кроме перехода на бинарный формат HTTP/2 может сжимать заголовки запросов и ответов с помощью специального алгоритма HPACK. Объем передаваемых данных еще меньше, скорость выше.

5️⃣ Server Push. В HTTP/2 серверу предоставляется возможность самостоятельно направить данные клиенту, как бы предугадывая его будущие потребности. Это может существенно уменьшить задержки, например, при переходе между разными страницами одного сайта.

Так же стоит отметить, что современные браузеры поддерживают HTTP/2 только поверх защищенного SSL/TLS соединения. Интернет становится еще безопаснее 🔐

Если в голых цифрах, то почти 95% пользователей интернета используют браузеры с поддержкой HTTP/2. Nginx получил поддержку в версии 1.9.5 (2015 год!). Так что если вы еще не включили для своих клиентов HTTP/2, то сделайте это прямо сейчас - нет причин откладывать!

До связи 🤘

Принципы разработки: KISS

В мире разработки программного обеспечения существует целый ряд принципов, рекомендаций и практик, которые помогают создавать эффективные и поддерживаемые решения. Принцип KISS - “Keep It Simple, Stupid” - был сформирован еще в середине XX века и применим почти в любой сфере интеллектуальной человеческой деятельности.

Почему KISS так важен в программировании?

Простота и читаемость кода 🤓 Принцип KISS настаивает на том, что код должен быть максимально понятным для разработчиков. Простой и ясный код легче поддерживать, тестировать и масштабировать.

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

Легкость в обучении и внедрении 📚 Простой код и ясная архитектура упрощают процесс передачи знаний и обучения для новых членов команды.

Соблюдение сроков 🗓️ Как правило, простой код требует меньше времени на разработку и тестирование. Простота помогает соблюсти сроки проекта.

Как говорится, простое лучше сложного! 😁

До связи 🤘

Что такое ORM?

ORM, или Object-Relational Mapping, представляет собой программный подход, который связывает объекты в приложении напрямую с записями в реляционной базе данных. Вместо того чтобы писать SQL-запросы вручную, разработчики могут использовать объекты и методы для выполнения типовых операций, типа SELECT, INSERT и так далее.

Давайте рассмотрим, какие преимущества и недостатки сопутствуют использованию ORM.

✅ Ускорение разработки. Использование ORM не только уменьшает количество написанного кода, если сравнивать с голым SQL, но и заметно упрощает написание однотипных выражений, типа фильтраций на больше/меньше/равно. Кроме этого все операции маппинга из БД в объекты вашего языка программирования происходят внутри ORM и для этого не нужно писать дополнительный код.

✅ Защищает от ошибок и опечаток. Если при написании SQL можно допустить ошибку в синтаксисе или вообще обратиться к несуществующей таблице, то как правило при использовании ORM это сделать значительно сложнее. В этом помогают и автоматические подсказки в IDE при вызове методов ORM, и проверки на этапе компиляции и/или статического анализа. Всё это позволяет больше сосредоточиться на бизнес-логике во время непосредственного программирования.

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

⛔️ Непрозрачность. При использовании ORM сложно быть до конца уверенным, как именно будет обработана конкретная конструкция под капотом и в какой SQL-запрос она будет преобразована. Это может усложнить отладку и понимание того, что происходит в базе данных.

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

⛔️ Невозможность написать сложный SQL-запрос. Возможности ORM по генерации SQL почти всегда ограничены и не весь доступный функционал вашей СУБД может быть отражен в синтаксисе ORM. Очень часто сложные запросы приходится писать на голом SQL, что лишает вас преимуществ работы с ORM.

Так же большинство ORM пытается обобщить работу с разными СУБД через единый интерфейс. Это с одной стороны может быть удобным, позволяет работать с разными СУБД через одну и туже известную вам ORM. С другой стороны не дает воспользоваться максимум преимуществ каждой отдельно взятой базы данных.

ORM - это мощный инструмент, который действительно упрощает и ускоряет разработку нового функционала, но не бесплатно: необходимо идти на компромисс как минимум с производительностью. В таком контексте основной задачей проектирования становится выбор частей проекта, где ORM принесет максимальную пользу.

До связи 🤘

Null-ссылки и Null Safety

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

🤓 Появление null-ссылок в программировании обычно приписывают языкам из семейства ALGOL в 1960ых годах. В последствии Тони Хоар - лауреат премии Тьюринга, один из автором ALGOL и создатель “быстрой сортировки” - называл Null своей “ошибкой на миллиард долларов”. Почему же так?

🤔 Несмотря на всю простоту и вроде бы логичность концепции, Null порождает бесконечное количество ошибок при обращении к переменным, которые могут содержать в себе null в качестве значения. И действительно, какой-то полноценной защиты от таких ошибок до последнего времени не было - только вездесущие проверки if (arg != null) и различные виды тестирования для выявления ошибок на ранних стадиях.

А проблема остается актуальной для широко используемых в наше время языков, таких как Java, Python, Go, C#, JavaScript.

🔒 Но не так давно на сцену вышел принцип Null Safety или Void Safety. Данный принцип строится на поддержке в языке программирования продвинутой системы типов с возможностью Union и Intersection типов. Благодаря этому типы с null и без null можно отделить друг от друга, и становится возможным провести все необходимые проверки на этапе статического анализа или компиляции и не допускать обращения к null в рантайме. Наиболее популярными языками, которые поддерживаю данную возможность, являются Rust, Kotlin, TypeScript, Swift, Dart.

Будьте внимательны при работе с null или переходите на Null Safety!

До связи 🤘

Что такое Webhook?

Webhook — это мощный и универсальный инструмент в области веб-разработки и API. Этот механизм позволяет одному веб-приложению уведомлять другое приложение о возникновении определенного события. Уведомление обычно имеет форму HTTP-запроса, отправляемого на конкретный URL-адрес, предоставленный принимающим приложением.

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

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

🔐 URL адрес принимающей стороны должен быть доступен в интернете, поэтому необходимо дополнительно позаботиться о безопасности. Для этого можно использовать разные подходы или их комбинации: принимать запросы только с разрешенных ip-адресов, использовать длинные рандомные токены, зашитые в URL или переданные в специальном заголовке, а так же подпись запросов с помощью, например, HMAC

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

А вот несколько примеров it-решений на базе webhook:
- Платежные шлюзы уведомляют сайты магазинов об успешной оплате или, наоборот, отклонении платежа
- Telegram использует вебхуки для отправки обновлений ботам
- Платформы CI/CD используют webhook для отправки информации о сломанных билдах или наоборот об успешно завершенных пайплайнах

Если вы разрабатываете публичное API, то ваши пользователи будут действительно рады появлению вебхуков 😍

До связи 🤘

Принципы разработки: DRY

Принцип DRY (Don't Repeat Yourself) - это один из основных принципов разработки программного обеспечения, который важен как для начинающих, так и для опытных разработчиков. Если переводить дословно, то это звучит как “Не повторяйтесь”, то есть призывает не дублировать код.

Давайте разберемся, что может дать следование принципу DRY:

✅ Переиспользование кода. Сознательное избавление от дублирования заставляет разработчика проводить более строгую декомпозицию кода на классы и/или функции для дальнейшего переиспользования.

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

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

✅ Увеличение производительности. Отсутствие дублирования обычно приводит к уменьшению кодовой базы. Меньший объем кода означает более быструю загрузку и скорость выполнения приложения.

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

До связи 🤘

Сетевые протоколы. DNS

Первые спецификации DNS (Domain Name System) появились в 1983 году, а в 1984 г. в Беркли была написана первая реализация DNS-сервера - BIND (остается одним из самых широко используемых DNS-серверов). На базе ДНС работает весь современный интернет, так как именно эта система служит для преобразования доменных имен в IP-адреса.

Для того, чтобы домен example.com ссылался на ваш IP-адрес необходимо создать A-запись. Так же часто используется CNAME - эта запись служит для создания переадресации или псевдонима. Например, очень часто www-домены указываются именно через CNAME на оригинальный домен (без www префикса).

При работе с DNS необходимо иметь ввиду следующие моменты:

✉️ DNS неразрывно связан с электронной почтой. Именно MX запись указывает, по какому адресу расположен почтовой сервер вашего домена.

TXT записи активно используются для хранения мета-информации, например, для подтверждения владения доменом или подписи для email.

DNS-сервера используют очень агрессивное кэширование. Время жизни записей начинается как правило от 5 минут и доходит до суток и более. Это приводит к тому, что изменения распространяются по сети очень долго 🐢.

🔐 Безопасность DNS - тема, важность который с годами только растет. Здесь стоит обратить внимание на DNS-over-HTTPS надстройку, которая не только обеспечивает подлинность, но и конфиденциальность.

Если говорить про сегодняшний день, то нельзя не упомянуть разработку под названием CoreDNS (написан на Go, более 11 тысяч звезд на Github). Отличительной особенностью этого DNS-сервера является расширяемость: даже базовая функциональность реализована с помощью плагинов и вы легко можете добавить свой.

Быстрого и бесперебойного разрешения имен 🚀

До связи 🤘

TCP-пакеты обычно гуляют по интернету, но и в реальную жизнь иной раз забегают 😆

Дорогие коллеги, хочется поздравить вас с наступающим Новым Годом.

Загадывать не будем, но пусть следующий год у каждого будет успешнее и интереснее, чем предыдущий 🚀
А в планах Alex Code делиться новостям, лучшими практиками и просто полезной информации чаще, больше и круче! Не будем ограничиваться текстом - запустим видео формат 🎞

До новых встреч в 2024 году 🐲

Пятничное 😅

Чем программист отличается от лампочки?
Лампочка перестает работать, когда перегорит.

Какие бывают ID?

А давайте сегодня познакомимся с различными видами числовых идентификаторов, их особенностями, интересными свойствами и ограничениями. Поехали!

Integer и Big Integer с автоинкрементом

Один из самых простых и распространенных способов. В качестве ID выступает простое число (обычно начиная с 1) и каждое следующее число больше предыдущего на единицу: 1, 2, 3, 4, 5...

В разных реляционных базах данных такие идентификаторы могут создаваться через немного разный синтаксис: AUTO_INCREMENT, SERIAL, SEQUENCE - но смысл общий.

✅ К плюсам относят малое место на диске (4 для int и 8 байт bigint), быструю скорость генерации.

⛔️ Но для для распределенных систем подходит плохо. Такие айди предназначались для случая с одним мастером в БД. Кроме этого такие айди могут нести проблемы безопасности, потому что добавляют системе излишней прозрачности для стороннего наблюдателя - по сгенеренному ID очевидны предыдущий, следующий и общее количество конкретных сущностей в системе.

UUID

Расшифровывается, как универсальный уникальный идентификатор (еще называют GUID - глобальный уникальный идентификатор). Представляет собой 128-битное число, которое обычно записывают с использованием цифр и латинских букв c505044c-85bd-496e-b711-bdcaae31a803 В rfc4122 описано целых 5 разных схем генерации с использованием timestamp, MAC-адреса, хешей md5 и sha1, а так же полностью рандомный способ - uuid v4.

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

❗️В качестве недостатка отмечаем больший размер по сравнению с Integer и Big Integer, а так же условно долго время генерации случайных или псевдослучайных числе.

ObjectId и Snowflake ID

✅ Пытаются объединить в себе лучшее, что могут предложить варианты выше: и сравнительно компактный размер (8 и 12 байт соответственно), и генерацию на базе timestamp, и высокую скорость, и возможность использовать в распределенных системах.

🦾 Данные идентификаторы состоят из 3 частей: timestamp (с точностью до секунд или миллисекунд), идентификатор ноды/инстанса/процесса, автоинкрементальная часть. Такая структура обеспечивает и уникальность на разных машинах, и высокую скорость генерации, а также предсказуемую сортировку (чем позже сгенерирован ID, тем он ниже при сортировке по возрастанию).

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

До связи 🤘

Новый Shell для JavaScript - Bun Shell

Всем (или почти всем) приходится иногда писать что-то на shell/bash, но взаимодействие с основным языком каждый раз вызывает смешанные чувства - скорее негативные 😒
Именно поэтому создатели Bun (нового быстрого runtime для JavaScript) пытаются решить это путем создания нового встроенного Shell.
Решение имеет сразу много плюсов: и быстро работает, и кроссплатформенное, и выразительный синтаксис, и удобное взаимодействие с остальным кодом.

Подроности опубликовал сегодня на habr - https://habr.com/ru/articles/795949/.

Docker - давай до свидания 🤪

Вчера российский сегмент интернета наполнился новостями о том, что компания Docker отключила доступ к своему публичному registry с российских ip-адресов.
Шок, паника, какие-такие законы, претензии, почему только сейчас - вот этот поток эмоций наполнял жаркие обсуждения. Честно говоря, у меня почти не случилось никакого эмоционального отклика😐 И вот почему.

"Уже проходили, ничего нового".
Для меня был яркий момент весной 2018 года, когда Роскомнадзор пытался блокировать телеграм и начал блокировать целые подсети апишников. В эти массовые блокировки стали попадать и облачные гиганты, такие как Google Cloud, где тогда жил наш проект с чатиками для отелей. Вот тогда был шок😱 такого на практике ещё не было.

Достаточно быстро мы поняли, что ждать у моря погоды бесполезно, пытаться в Гугле вытащить новый айпишник, который не попал в блокировки, тоже как-то слишком на удачу. И мы просто подняли свой прокси в Германии, переключили DNS, подвязали нужные сертификаты и вперёд. Все заработало и мы вернулись к своим делам.

Теперь про докер.
Проблема с docker pull наиболее легко решается через зеркала, поддержка которых заботливо встроена в сам докер. В файле конфига (в Linux обычно /etc/docker/daemon.json) нужно добавить ключик registry-mirrors со списком адресов. Я пользуюсь:
- https://mirror.gcr.io (это гугл)
- https://dockerhub.timeweb.cloud (это далеко не маленький российский хостер, который раньше всех подсуетился😄)

Если вы собираете свои контейнеры, то хранить их (и соответственно делать `docker push`) лучше на registry от Яндекс Облако, Selectel, VK Cloud и тд, или поднимайте свой регистр, или используйте встроенный в какой-нибудь Gitlab/Gitea/аналог.

Это далеко не полная инструкция, чуть подробнее нашел сегодня на хабре статью - https://habr.com/ru/articles/818565/.

Работаем дальше, до связи 🤘

Идеально для пятницы - huecker.io 😆

Начинаем использовать ИИ 🤖

Уже только ленивый не слышал о ChatGPT, нейронных сетях и том, как ИИ может помочь человечеству. А может и заменить собой то ли 50%, то ли 80% профессий, если не прямо сейчас, то в скором будущем.

Все истории и примеры использования генеративных нейронных сетей прекрасны и вдохновляют, но что же мы можем получить на сегодняшний день? Вроде как нужно попытаться максимально облегчить выполнение рутинных и скучных задач. Но, оказывается, использовать ChatGPT на постоянной основе - это тоже навык, ему тоже нужно научиться 🧠

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

Что легко начать делать с помощью нейронки в разработке:

🔍 Использовать как поисковик по нетривиальным темам. Если ваш запрос звучит “как использовать вместе A, B, C”, то это то самое. Вам должно повезти, чтобы кто-то сталкивался с проблемой раньше и гугл бы смог найти статью или обсуждение этой проблемы. Но скорее всего вам придется собирать пазл самостоятельно из отдельных порций информации. ChatGPT же сразу начинает описывать готовое решение в соответствии с запросом.

🛠️ Использовать новую библиотеку. Если сроки горят и погружаться с головой в документацию не вариант, то ИИ тут отлично помогает. Можно и валидацию написать, и SQL запрос через неизвестную ORM тоже сделать, и какие-нибудь нужные компоненты в клиентском роутинге заюзать.

🥱 Переписывать код, когда простого find-and-replace уже не хватает. Если нужно заменить одну библиотеку на другую или изменить что-то в подходе именования, то тут ИИ справляется на ура.

🖨️ Генерация шаблонного кода. Оставим за скобками тот факт, что избыток шаблонного кода на проекте - это грустно. Но тесты, например, писать никто не отменял. ChatGPT отлично сгенерирует структуру из describe / it и добавит дефолтное наполнение, которое остается только подкорректировать с учетом специфики проекта.

Отдельно бы хотелось сказать, что у ChatGPT бывают опечатки или фактически неверные ответы, поэтому всё это требует тщательной проверки! Не стоит ответы от ИИ сразу запускать на проде 😁

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

Всем нейронного повышения продуктивности!
До связи 🤘

Поиск “сломанного” коммита с git bisect

Обычно для исправления бага очень бы хотелось знать, в каком конкретно коммите он впервые появился… Но коммитов с последней работающей версии может быть запушено очень много! Как же найти коммит, который всё сломал??? 🤯

На первый взгляд кажется вполне логичным проверить все коммиты, начиная с конца - и нужный коммит мы не пропустим! Но и время можно убить за этой процедурой предостаточно⏳

В терминах алгоритмов, такой поиск называется линейным, и он действительно не отличается скоростью 🐢🐢🐢  А вот бинарный поиск справится намного быстрее! В общем случае он применяется для поиска по отсорированному массиву и обладает логарифмической сложностью. В нашем же случае можно считать, что коммиты отсортированы по признаку сломанности - сначала все несломанные коммиты, потом сломанные. С помощью такого подхода среди 100 коммитов можно найти первый поломанный за 7 шагов.

А в гит это сделать еще проще, потому что есть готовая команда git bisect . Давайте разберемся с ней по шагам.

1️⃣ Стартуем через git bisect start

2️⃣ Указываем границы поиска - хороший и плохой коммиты:

git bisect good <commit_hash>
git bisect bad <commit_hash>

3️⃣ Затем git bisect переключит репозиторий на коммит, который находится посередине. Вам остается проверить повторяется ли баг или нет и указать это через git bisect good или git bisect bad. Под капотом гит поменяет границы поиска и опять запустит шаг №3

4️⃣ В конце поиска мы увидем следующее сообщение:

<commit_hash> is the first bad commit

Если нужно выйти из процесса поиска заранее, то используем git bisect reset .

Приятно, когда такой повседневный рабочий инструмент, как git, способен удивить какой-то дополнительной полезной функцией!

Скорейшего поиска “сломанных” коммитов 🚀
До связи 🤘

Эволюция сделала полный круг или htmlX

Не так давно натолкнулся на проект, который пытается подойти к снаряду веб-разработки и HTML еще раз. Создатели обещает то ли сделать HTML "Great Again", то ли наконец-то подарить разработчикам "настоящий" hypertext или как минимум html eXtended.

Но давайте посмотрим на многострадальный язык разметки HTML с исторической перспективы. Крупными мазками я выделяю следующие этапы:

- сначала был просто HTML
- потом HTML генерировали с помощью PHP на сервере (html внутри php на сервере)
- затем случился web 2.0, single page applications и html собирался силами первых клиентских MVC-фреймворков, jQuery и шаблонизаторов (сервер стал отдавать на клиент JSON вместо HTML)
- потом многие стали писать почти-html с помощью React (html внутри js на клиенте)
- затем js начал добираться до серверов в виде Node.js и уже появился Server Side Rendering. HTML стал генерироваться на сервере опять, но уже с помощью большой клиентской тройки Angular, React & Vue (html внутри js на сервере)

И вот тут на сцену выходит проект https://htmx.org/ (более 34 тысяч звезд на Github). Создателям хочется, чтобы web-страницы оставались живыми и интерактивными, но с меньшим количеством js-кода и без всяких модных фреймворков. И это не пустые слова. HTMLX позволяет на уровне разметки пользоваться такими штуками, как AJAX, CSS Transitions и даже WebSocket. И что же получается?

<button
 hx-trigger="click"
 hx-get="/api/data"
 hx-target="#result"
>Загрузить данные</button>
<div id="result"></div>

Читаем: "По клику на button сделать GET-запрос на /api/data и ответ отрендерить в элемент c идентификатором result". Все логично.

Выглядит ли это, как предложение для ребят из 2000-ых сдуть пыль с клавиатуры, запустить сервачек на каком-нибудь не-js языке, смахнуть ностальгическую слезу по jQuery и пуститься во все тяжкие “настоящего” hypertext? Очень возможно! 😁

Прикольно ли это трогать, запускать на этом прототипы? Определенно 😊
А вот выгоднее ли это в долгосрочной перспективе, чем использовать тот же Next.js и все прелести клиентской разработки на React плюс серверный рендеринг? Уже далеко не так очевидно 🤔 

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

Не бойтесь пробовать что-то новое и до связи 🤘

Нейронки на расстоянии вытянутой руки 🦾

Продолжаю изучать, чем же современные ИИшки могут помогать в разработке на ежедневной основе. И как раз мне подкинули ссылочку на интересный проект - https://www.machinet.net/

Я попробовал их продукт под названием Mate. Как это все устроено? Устанавливается отдельная апка (не веб), затем ему можно выдать доступ на папку проекта (или несколько проектов), нейронка производит анализ содержимого, выводит отчёт о проекте, а дальше готова выполнять задания 😱

Уже анализ и отчет заслуживает внимания. Для Node.js проекта Mate не просто банально перечисляет зависимости пакетного менеджера, но и рассказывает с какими внешними сервисами происходит интеграция, какие у вашего сервиса http ендпоинты и для чего нужны, какие базы данных используются. Если попросить дополнительно, то эта штука вполне справляется с ER-диаграммами для таблиц из бд.

Был реально в шоке, когда Mate расписал основные флоу работы приложения, то есть запрос A приводит к созданию бекграунд джоб B, которые ходят во внешний сервис C и результаты пишутся в табличку D. Здесь закралась мысль, что если не писать код, так писать документацию эта штука точно может помочь ✍

На этом пока все. Об опыте написания кода с Mate напишу чуть позже.

До связи 🤟

Почему программисты так любят пятницу?

Потому что в пятницу пишешь код, а исправляешь баги уже в понедельник 🤣

Хандра 😑

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

В любом случае вышеописанная картинка не очень похожа на лучезарное и беззаботное лето, к которому мы привыкли со времен нашего детства ☀️

Зато такое овощное состояние помогает ненадолго выйти из айтишного круговорота и немного вдохнуть новых красок:

📖 Начал читать книжечку "Атомные привычки" (пока не вау, но занятно)
📺 4 сезон сериала The Boys (с нетерпением уже жду 5ый)
🍲 Доставка готовых рационов питания - удобно, вкусно (для неприхотливых, как я) и калории все учтены

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

Всем продуктивной рабочей недели!
До связи 🤟