Forwarded from Соер.Клуб | Сервисная архитектура
Перенасыщенный информационный поток — это верный способ посадить нервную систему. Современные люди потребляют конские дозы информации, которые не несут никакой полезной нагрузки, но требуют постоянных умственных затрат. Причём часто мы изнашиваем нервную систему дополнительным стрессом от прочтения всякой ерунды.
Избежать новой информации невозможно, поэтому для себя стараюсь максимально ограничивать потребление ненужной информации, а в остальном сосредоточиться только на чём-то полезном. Поэтому задаю два важных вопроса:
1. «Что я узнал нового?»
2. «Что из нового оказалось полезным?»
Во втором вопросе есть подвох: не всегда понятно, что считать пользой. Полезной я считаю информацию, которая либо напрямую делает мою жизнь лучше, либо расширяет профессиональную эрудицию.
Мне кажется, что между потреблением полезной и бесполезной информации выбор очевиден.
Теперь почему не получится «не потреблять информацию». Тут всё просто: технологии массмедиа сильно продвинулись вперёд и легко обходят наши защитные механизмы. Тут меч сильно опережает щит.
Кроме этого, в современном обществе есть явный культ знаний, и люди его периодически пытаются игнорировать. Но, как правило, это приводит к тому, что вместо спокойного ритмичного развития они развиваются рывками, в моменте нагружая свой организм огромными порциями информации. Это приводит к банальному выгоранию и потере здоровья.
В целом моя идея в том, что если информационного потока нельзя избежать, то нужно его контролировать и делать максимально спокойным и полезным.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥49👍17
В рекомендации выдалось хорошее видео по ACID, понравилось простое и понятное объяснение, без лишней воды. Просили делиться подобными видео, вот ловите -
https://youtu.be/s4_bROEL4vQ?si=aGzAf3JFxPJGZzXd
https://youtu.be/s4_bROEL4vQ?si=aGzAf3JFxPJGZzXd
❤24👍16
Forwarded from Соер.Клуб | Сервисная архитектура
Что нужно знать про контейнеризацию
Через пару недель на курсе по монолитным архитектурам будем разбирать, зачем нужна и как устроена контейнеризация. Ради интереса посмотрел ролики на YouTube по этой теме и хочу указать на очевидные пробелы, которые заметил.
Итак, нам часто говорят: «Сегодня знания не нужны, всё есть в бесплатном доступе». К сожалению, это не так. В открытом доступе — в основном видео, где пересказывают документацию Docker. А когда речь заходит про контейнеры, звучит что-то вроде:
А потом мы удивляемся, когда разработчики говорят:
Между тем, отладка и поиск корневых причин сбоев — важнейшая часть работы инженера (соера). Без глубокого понимания сути процесса это просто невозможно.
Чтобы разобраться, как Docker работает под капотом, обязательно нужно рассматривать:
✅ механизмы изоляции в ядре: namespace и cgroups,
✅ как именно устроена изоляция,
✅ как получать доступ к ключевым метрикам работы контейнеров (например, через Berkeley Packet Filter),
✅ виртуальные сети, которые требуют понимания iptables (Docker активно их использует).
Постоянно возвращаюсь к вопросу: могут ли люди, которые сами учились по бесплатным мануалам и никогда не применяли инструмент на практике, помочь в его изучении?
Глядя на ролики в YouTube, создаётся ощущение, что это больше про пиар, чем про знания. Конечно, не все видео — просто пересказ документации, но в массе своей ситуация печальная.
Через пару недель на курсе по монолитным архитектурам будем разбирать, зачем нужна и как устроена контейнеризация. Ради интереса посмотрел ролики на YouTube по этой теме и хочу указать на очевидные пробелы, которые заметил.
Итак, нам часто говорят: «Сегодня знания не нужны, всё есть в бесплатном доступе». К сожалению, это не так. В открытом доступе — в основном видео, где пересказывают документацию Docker. А когда речь заходит про контейнеры, звучит что-то вроде:
«Это такая магия, которая как-то работает и делает легковесные виртуалки».
А потом мы удивляемся, когда разработчики говорят:
«Не знаю, почему не работает, у меня локально всё ок».
Между тем, отладка и поиск корневых причин сбоев — важнейшая часть работы инженера (соера). Без глубокого понимания сути процесса это просто невозможно.
Чтобы разобраться, как Docker работает под капотом, обязательно нужно рассматривать:
Постоянно возвращаюсь к вопросу: могут ли люди, которые сами учились по бесплатным мануалам и никогда не применяли инструмент на практике, помочь в его изучении?
Глядя на ролики в YouTube, создаётся ощущение, что это больше про пиар, чем про знания. Конечно, не все видео — просто пересказ документации, но в массе своей ситуация печальная.
Please open Telegram to view this post
VIEW IN TELEGRAM
4👍24
Ветвление в git - это с одной стороны очень простая штука, а с другой мало кто пользуется ей на максималках. В общем, хочу поделиться классным тренажером, который поможет научиться делать и использовать ветки в git-е, если вы реальный соер - https://learngitbranching.js.org
learngitbranching.js.org
Learn Git Branching
An interactive Git visualization tool to educate and challenge!
2👍49🔥13
Недавно на созвоне в Соер.Клубе обсуждали вопросы создания Architecture Decision Record (ADR), у нас была задача описать условия при которых целесообразно создавать и вести ADR.
Обсудили огромное количество деталей, которые хочется обобщить и зафиксировать в виде коротких подсказок. Возможно вам тоже будет полезно.
#cards #adr
Обсудили огромное количество деталей, которые хочется обобщить и зафиксировать в виде коротких подсказок. Возможно вам тоже будет полезно.
#cards #adr
1👍44
Forwarded from Соер.Клуб | Сервисная архитектура
Первый шаг к понимаю архитектуры ПО - понимание контекста решаемого вопроса.
Я много консультирую, провожу воркшопы, делаю курсы по архитектуре и заметил одну важную деталь - часто люди упускают момент, который является основным ключом к пониманию архитектуры - контекст.
Сложность в том, что по архитектуре ПО нет общего стандарта, который можно было бы брать за основу и говорить всем "так и только так правильно", одни и те же термины используются разными авторами в разных контекстам по-разному (например, "зависимость" в UML и зависимость в DIP - имеют разные смыслы, или "пасивность view" в MVC и MVP тоже разные, более того есть свой вариант MVC для десктопов и веб).
Поэтому при проектировании я придерживаюсь следующего порядка:
1. Определить контекст
2. Определит архитектурную идею (об этом как-нибудь тоже расскажу)
3. Отразить схему или диаграмму для иллюстрации идеи.
Графическое представление идеи - очень важно, но без контекста может сильно запутать. Пока не появится привычки отделять "мух от котлет" ни о каком понимании речи идти не может.
Я много консультирую, провожу воркшопы, делаю курсы по архитектуре и заметил одну важную деталь - часто люди упускают момент, который является основным ключом к пониманию архитектуры - контекст.
Сложность в том, что по архитектуре ПО нет общего стандарта, который можно было бы брать за основу и говорить всем "так и только так правильно", одни и те же термины используются разными авторами в разных контекстам по-разному (например, "зависимость" в UML и зависимость в DIP - имеют разные смыслы, или "пасивность view" в MVC и MVP тоже разные, более того есть свой вариант MVC для десктопов и веб).
Поэтому при проектировании я придерживаюсь следующего порядка:
1. Определить контекст
2. Определит архитектурную идею (об этом как-нибудь тоже расскажу)
3. Отразить схему или диаграмму для иллюстрации идеи.
Графическое представление идеи - очень важно, но без контекста может сильно запутать. Пока не появится привычки отделять "мух от котлет" ни о каком понимании речи идти не может.
1👍15
Хочу поделиться с вами публичным гайдом Как правильно использовать и обрабатывать исключения в программе, который поможет улучшить обработку ошибок и исключений на бэкенде. Если хотите такой же гайд для обработки ошибок на фронтенде, то давайте соберем 100 отметок 💡 и я подготовлю материал для вас.
Please open Telegram to view this post
VIEW IN TELEGRAM
SOER.MEDIA
Как правильно использовать и обрабатывать исключения в программе (для бэкенда)
Постоянно сталкиваюсь с глубоким непониманием того как должны обрабатываться исключения в современных приложениях, реализующих клиент-серверный подход. Поэтому решил собрать краткий гайд об основных моментах, которые нужно учесть при обработке исключений
Сейчас на практике встречается четыре основных подход в архитектуре:
1️⃣ Монолит
2️⃣ Сервисный подход
3️⃣ Микросервисный
4️⃣ Событийный подход
Последний часто комбинируется вместе с микросервисами и по сути является способом организовать реактивное поведение в системе.
Это базовая четвёрка является основой абсолютного большинства решений на рынке. Я сделал небольшой обзор каждого из них. Думаю будет полезно ознакомиться каждому.
Последний часто комбинируется вместе с микросервисами и по сути является способом организовать реактивное поведение в системе.
Это базовая четвёрка является основой абсолютного большинства решений на рынке. Я сделал небольшой обзор каждого из них. Думаю будет полезно ознакомиться каждому.
Please open Telegram to view this post
VIEW IN TELEGRAM
SOER.MEDIA
Чем отличаются монолитная, сервисная, микросервисная и event-driven архитектуры
В современной разработке программного обеспечения существует несколько фундаментальных архитектурных стилей, определяющих структуру, принципы взаимодействия компонентов и эволюцию системы. Понимание их различий является критически важным для выбора оптима
3❤34👍24
В прошлом посте об обработке ошибок на бэкенде мы собрали больше 100 отметок 💡 , выполняю свое обещание и публикую новую заметку на тему исключений - Как правильно обрабатывать исключения (для фронтенда). На этот раз я больше задумался об архитектурных вопросах обработки ошибок, и в итоге получил более полный и глубокий разбор, надеюсь вам понравится.
SOER | PRO | Boosty
SOER | PRO | Boosty
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
S0ER
Хочу поделиться с вами публичным гайдом Как правильно использовать и обрабатывать исключения в программе, который поможет улучшить обработку ошибок и исключений на бэкенде. Если хотите такой же гайд для обработки ошибок на фронтенде, то давайте соберем 100…
1
Программирование в значительной степени эмпирическая штука, теория строится не на базе строго доказанных теорем, а на основе обобщения личного опыта. Поэтому трудно винить программистов в том, что они придумывают и придумывают новые правила.
Ради справедливости стоит сказать, что некоторые правила оказываются весьма удачными, потому что просты и понятны. Примеры хороших правил - "is-a" и "has-a".
IS-A
гласит, что наследование уместно использовать там, где можно вместо слова "наследование" подставить "is-a" (является). Если мы хотим понять, может ли стул наследоваться от стола, то фраза "стул является столом" подсказывает, что нет, не можем.
HAS-A
гласит, что композицию уместно использовать там, где слово "композиция" может быть заменена на "has-a" (имеет). Например, "Стол это композиция столешницы и ножек" может быть заменен на "Стол имеет столешницу и ножки", правило выполняется, а следовательно композиция в данном случае применима.
Ради справедливости стоит сказать, что некоторые правила оказываются весьма удачными, потому что просты и понятны. Примеры хороших правил - "is-a" и "has-a".
IS-A
гласит, что наследование уместно использовать там, где можно вместо слова "наследование" подставить "is-a" (является). Если мы хотим понять, может ли стул наследоваться от стола, то фраза "стул является столом" подсказывает, что нет, не можем.
HAS-A
гласит, что композицию уместно использовать там, где слово "композиция" может быть заменена на "has-a" (имеет). Например, "Стол это композиция столешницы и ножек" может быть заменен на "Стол имеет столешницу и ножки", правило выполняется, а следовательно композиция в данном случае применима.
2👍66
Forwarded from Соер.Клуб | Сервисная архитектура
#бриф
Соер.Клуб активно пополняется новыми материалами, мы наконец-то подошли к концу курса по монолитной архитектуре и активно готовимся к курсу по сервисной архитектуре. Далее короткий список материалов, с которыми можно ознакомиться:
Без подписки (публичные материалы):
- Как правильно использовать и обрабатывать исключения в программе (для бэкенда)
- Как правильно обрабатывать исключения (для фронтенда)
- Чем отличаются монолитная, сервисная, микросервисная и event-driven архитектуры
- Что такое URL, URN и URI. В чем их различие
- Алгоритм работы https handshake
Лекции по архитектуре
- Лекция. Сбор требований
- Лекция. Архитектурный ландшафт монолитного приложения
- Лекция. Проведение границ и разделение обязанностей, модульные монолиты
- Лекция. Проектирование (модель C4)
- Лекция. Введение в паттерны проектирования
- Лекция. Шаблонизация
- Лекция. Работа с контейнерной инфраструктурой для монолита
- Лекция. Облачные провайдеры и виртуализация
- Лекция. Проксирование и маршрутизация запросов в монолитных приложениях
- Лекция. Анализ вектора развития приложения
Воркшопы
- Воркшоп. Разбираем сбор требований на примере
- Воркшоп. Описание архитектурного ландшафта приложения
- Воркшоп. Анализ границ готового приложения
- Воркшоп. Пример описания проекта по модели C4
- Воркшоп. Развертывание приложения NestJS в монорепозитории
- Воркшоп. Примеры применения шаблонизации
- Воркшоп. Контейнеризация приложения
- Воркшоп. Разбор примера облачной инфраструктуры
- Воркшоп. Развертывание Nginx как прокси сервера
Созвоны
- Созвон. Анализ и подготовка требований
- Созвон.Архитектурный ландшафт монолитного приложения
- Созвон. Рефакторинг архитектуры и сбор требований
- Созвон. Компонентная диаграмма и зависимости
- Созвон. Обсуждение модели С4, обсуждения эффективных методов погружения в архитектуру
- Созвон. Использование мультиагентных систем ИИ и планировние контекст
- Созвон. Обсуждение С4 и эволюции архитектуры
- Созвон. Terraform vs Ansible, планы на развитие курсов
Гайды
- Установка и настройка nginx
- Автоматизированное развертывание Docker с помощью Ansible
Все перечисленные материалы можно получить по подписке, до конца месяца действует льготная цена на подписки STREAM, WORKSHOP
Please open Telegram to view this post
VIEW IN TELEGRAM
👍16🔥7❤1
Промпт для исправления ошибок в коде
Некоторое время использую QWEN3-Coder-480b-А35b-Instruct и QWEN Coder. Модель в чем-то хороша, в чем-то не очень. Хочу рассказать о своем опыте борьбы с неверным поведением модели.
Когда ИИ генерирует программный код, он может допускать ошибки, как и обычный разработчик. Синтаксические проблемы исправляются довольно просто, но встречаются и более сложные случаи, связанные с семантикой.
Хочу разобрать конкретный пример, который демонстрирует, насколько по-разному может работать ИИ в зависимости от формулировки промпта.
Сообщение от интерпретатора выглядит так:
На первый взгляд кажется, что это стандартная синтаксическая ошибка, но в действительности наша проблема связана с семантикой. Рассмотрим фрагмент кода, на который указывает интерпретатор:
Особенность в том, что "function" здесь представляет собой имя поля в таблице, а не ключевое слово Lua для объявления функций. Это требование продиктовано не локальными особенностями, а спецификацией OpenAI API. Следовательно, ИИ должен не только диагностировать суть недочёта, но и предложить корректное решение. Например, вместо замены имени поля следует использовать обращение через квадратные скобки:
Некоторое время использую QWEN3-Coder-480b-А35b-Instruct и QWEN Coder. Модель в чем-то хороша, в чем-то не очень. Хочу рассказать о своем опыте борьбы с неверным поведением модели.
Когда ИИ генерирует программный код, он может допускать ошибки, как и обычный разработчик. Синтаксические проблемы исправляются довольно просто, но встречаются и более сложные случаи, связанные с семантикой.
Хочу разобрать конкретный пример, который демонстрирует, насколько по-разному может работать ИИ в зависимости от формулировки промпта.
Сообщение от интерпретатора выглядит так:
Failed to run `config` for agentsoer.nvim
vim/loader.lua:0: ...soer/projects/agentsoer.nvim/lua/agentsoer/engine/ai.lua:43: '<name>' expected near 'function'
# stacktrace:
- vim/loader.lua:0
- lua/agentsoer/commands.lua:5
- lua/agentsoer/init.lua:4
- ~/.config/nvim/lua/plugins/init.lua:34 _in_ **config**
- ~/.config/nvim/init.lua:17
На первый взгляд кажется, что это стандартная синтаксическая ошибка, но в действительности наша проблема связана с семантикой. Рассмотрим фрагмент кода, на который указывает интерпретатор:
42 local function handle_tool_call(tool_call)
43 if tool_call.function.name == "list_directory" then
44 local success, params = pcall(vim.fn.json_decode, tool_call.function.arguments)
45 if success then
Особенность в том, что "function" здесь представляет собой имя поля в таблице, а не ключевое слово Lua для объявления функций. Это требование продиктовано не локальными особенностями, а спецификацией OpenAI API. Следовательно, ИИ должен не только диагностировать суть недочёта, но и предложить корректное решение. Например, вместо замены имени поля следует использовать обращение через квадратные скобки:
['function'].name.GitHub
GitHub - QwenLM/qwen-code: An open-source AI agent that lives in your terminal.
An open-source AI agent that lives in your terminal. - QwenLM/qwen-code
👍9❤7👎6
Здесь проявляется любопытная закономерность. Если просто попросить LLM исправить сообщение об ошибке, система воспримет информацию от интерпретатора буквально и сосредоточится на синтаксических аспектах, вместо того чтобы исследовать корневую причину.
Неудачный промпт:
Эффективный промпт:
Неудачный промпт:
Исправь ошибку
vim/loader.lua:0: ...soer/projects/agentsoer.nvim/lua/agentsoer/engine/ai.lua:43: '<name>' expected near 'function'
# stacktrace:
...
Эффективный промпт:
Проанализируй причину возникновения ошибки, рассмотри несколько подходов к решению и предложи способ устранения:
vim/loader.lua:0: ...soer/projects/agentsoer.nvim/lua/agentsoer/engine/ai.lua:43: '<name>' expected near 'function'
# stacktrace:
...
👎9👍6