Пока ничего содержательного не пишется, поделюсь своими любимыми околорабочими мемами. И вы делитесь в комментариях!
😁40🔥9🤣4❤1
Какого размера должны быть микросервисы?
Несколько лет назад я уже писала о своем опыте работы с MSA. Там про знакомство и взаимодействие аналитика с микросервисами. Сейчас опыта стало побольше и хочется поговорить про то, как размер сервисов влияет на разработку.
Название архитектурного паттерна как бы намекает, что сервисы в MSA должны быть небольшими. Но что значит небольшим? И в масштабах какой системы?
По канонам, сервис может считаться микросервисом, если он соответствует основным принципам MSA:
- Он имеет чёткие границы и сферу ответственности,
- он независимо развертывается,
- у него своя база данных,
- он взаимодействует с другими сервисами через API.
То есть про размер ничего нет. Ни в большую, ни в меньшую сторону.
В рекомендациях часто косвенно связывают размер микросервиса с размером команды. То есть команда, разрабатывающая 1 (и в идеале только 1) микросервис, должна быть 6-12 человек (правило 2х пицц). И, кажется, что это правило - результат сложного опыта и ошибок.
Иногда разработчики делают микросервисы настолько маленькими, что между ними возникает большая и разветвленная сеть APIs. Происходит много сетевых вызовов, сервисы ломают друг друга, команды много и неэффективно общаются между собой. То есть сервисы зависят друг от друга и мы получаем распределенный монолит. Хотя формально эти сервисы соответствуют принципам MSA, но фактически такая архитектура противоречит смыслу разработки микросервисов - она не избавляет систему от зависимостей, но увеличивает ее сложность за счет интеграций и инфраструктуры.
Бывают и обратные ситуации. В примерах микросервисов часто можно увидеть такие агрегаты, как Оплата, Заказ, Доставка, Склад и др.
При определенном масштабе системы такие бизнес-функции могут включать в себя много сложной логики.
Например, платежный микросервис будет содержать данные об оплатах, проверки транзакий, интеграции с платежными шлюзами, бухгалтерией, антифродом и пр. То есть на выходе получается не то чтобы “микро-” сервис.
И если с этим справляется одна двухпиццевая команда, то все отлично - сервис автономен, не сильно зависит от других сервисов и представляет сам по себе ценность для бизнеса.
Но системы имеют свойство развиваться. И в какой-то момент 12 человек уже может не хватать, чтобы поддерживать всю логику и контракты. Команда вырастет, незаметно для всех разобьется на подкоманды, каждая со своей зоной ответственности. Эти подкоманды начнут друг другу мешаться, долго разрабатывать и еще дольше деплоить. В результате получится мини-монолит в микросервисной шкуре.
Можно, конечно, попросить системных аналитиков держать всю эту махину под контролем. Но иногда и их ресурсов не хватает, чтобы осознать, запомнить и задокументировать весь контекст “микро-”сервиса. В таких случаях рекомендуют распиливать получившийся мини-монолит - скорее всего, образуя из подкоманд отдельные команды.
В общем, микросервисы это и так сложно, а тут еще приставка “микро-” сильно сбивает с толку.
Например, на одном моем проекте распределенную систему из “среднего” размера сервисов причисляли к SOA-паттерну. Хотя там не было ни ESB-шины, ни общих баз данных, ни централизованной оркестрации. По факту это была распределенная система из микросервисов и мини-монолитов, которые все вместе вполне отвечали принципам MSA.
По моему опыту все-таки лучше иметь дело с мини-монолитами, чем собирать слово “Вечность” из слишком мелких и сильно связанных микросервисов.
Многие эксперты тоже советуют “не мельчить”, например здесь и здесь.
А с какими микросервисами вы сталкивались в своей практике? И как вам такой опыт?
Несколько лет назад я уже писала о своем опыте работы с MSA. Там про знакомство и взаимодействие аналитика с микросервисами. Сейчас опыта стало побольше и хочется поговорить про то, как размер сервисов влияет на разработку.
Название архитектурного паттерна как бы намекает, что сервисы в MSA должны быть небольшими. Но что значит небольшим? И в масштабах какой системы?
По канонам, сервис может считаться микросервисом, если он соответствует основным принципам MSA:
- Он имеет чёткие границы и сферу ответственности,
- он независимо развертывается,
- у него своя база данных,
- он взаимодействует с другими сервисами через API.
То есть про размер ничего нет. Ни в большую, ни в меньшую сторону.
В рекомендациях часто косвенно связывают размер микросервиса с размером команды. То есть команда, разрабатывающая 1 (и в идеале только 1) микросервис, должна быть 6-12 человек (правило 2х пицц). И, кажется, что это правило - результат сложного опыта и ошибок.
Иногда разработчики делают микросервисы настолько маленькими, что между ними возникает большая и разветвленная сеть APIs. Происходит много сетевых вызовов, сервисы ломают друг друга, команды много и неэффективно общаются между собой. То есть сервисы зависят друг от друга и мы получаем распределенный монолит. Хотя формально эти сервисы соответствуют принципам MSA, но фактически такая архитектура противоречит смыслу разработки микросервисов - она не избавляет систему от зависимостей, но увеличивает ее сложность за счет интеграций и инфраструктуры.
Бывают и обратные ситуации. В примерах микросервисов часто можно увидеть такие агрегаты, как Оплата, Заказ, Доставка, Склад и др.
При определенном масштабе системы такие бизнес-функции могут включать в себя много сложной логики.
Например, платежный микросервис будет содержать данные об оплатах, проверки транзакий, интеграции с платежными шлюзами, бухгалтерией, антифродом и пр. То есть на выходе получается не то чтобы “микро-” сервис.
И если с этим справляется одна двухпиццевая команда, то все отлично - сервис автономен, не сильно зависит от других сервисов и представляет сам по себе ценность для бизнеса.
Но системы имеют свойство развиваться. И в какой-то момент 12 человек уже может не хватать, чтобы поддерживать всю логику и контракты. Команда вырастет, незаметно для всех разобьется на подкоманды, каждая со своей зоной ответственности. Эти подкоманды начнут друг другу мешаться, долго разрабатывать и еще дольше деплоить. В результате получится мини-монолит в микросервисной шкуре.
Можно, конечно, попросить системных аналитиков держать всю эту махину под контролем. Но иногда и их ресурсов не хватает, чтобы осознать, запомнить и задокументировать весь контекст “микро-”сервиса. В таких случаях рекомендуют распиливать получившийся мини-монолит - скорее всего, образуя из подкоманд отдельные команды.
В общем, микросервисы это и так сложно, а тут еще приставка “микро-” сильно сбивает с толку.
Например, на одном моем проекте распределенную систему из “среднего” размера сервисов причисляли к SOA-паттерну. Хотя там не было ни ESB-шины, ни общих баз данных, ни централизованной оркестрации. По факту это была распределенная система из микросервисов и мини-монолитов, которые все вместе вполне отвечали принципам MSA.
По моему опыту все-таки лучше иметь дело с мини-монолитами, чем собирать слово “Вечность” из слишком мелких и сильно связанных микросервисов.
Многие эксперты тоже советуют “не мельчить”, например здесь и здесь.
А с какими микросервисами вы сталкивались в своей практике? И как вам такой опыт?
Хабр
Микросервисы глазами аналитика
Расскажу про системы с микросервисной архитектурой (MSA). Как они устроены, как я их анализировала, какие увидела проблемы и преимущества. Статья не раскрывает лучшие практики использования...
👍25❤11🔥3
Курсы по основам программирования
Решила освежить базу и пройти легендарный гарвардский курс CS50: Introduction to Computer Science.
Пока прослушала половину лекций и мне все очень нравится.
Курс бесплатный и очень качественный. Особенно ценно, что он обновляется каждый год и дает актуальную информацию и современные примеры.
Из возможных сложностей отмечу, что материала много и он на английском. Но английский очень понятный, B1 должно спокойно хватать. Есть перевод на русский от JavaRush, но там версия 2015го года.
В CS50 не дают лишних подробностей и не перегружают терминами, а стараются объяснить так, чтобы появилось общее понимание базовых концепций и принципов.
Мне кажется очень грамотным, что основы программирования начинают объяснять на примере C, а не Python, как это делается в большинстве современных стартовых курсов. Потому что на C все расписывается подробно и долго — а это очень помогает усвоению информации.
Также полезно понимать, как работают функции, встроенные в высокоуровневые языки. А С — это отличный способ разобраться в фундаменте работы программиста. Ведь многие интерпретаторы и компиляторы написаны на C (в том числе Python). И С все еще остаётся базовым языком операционных систем и низкоуровневых библиотек.
Помимо C, в курсе рассказывают про Python, память, алгоритмы, структуры данных, SQL, HTML, CSS и JavaScript. То есть информации много и даже если посмотреть только лекции — вполне можно получить общее представление об ИТ.
Отдельного восхищения достойны лектор Дэвид Мэлэн и организаторы — прекрасная подача материала и техническая подготовка. Как будто ты смотришь стендап-концерт, а не лекции по основам информационных технологий.
В общем, рекомендую.
А если CS50 кажется сложноватым — можно посмотреть на эти курсы:
🐤 ITProger: все коротко, без подробностей и иногда не очень связно, но бесплатно.
🐤 Wexler: программа хорошая, бесплатные пробные уроки понравились, но дороговато.
🐤 Udemy: программа неплохая, ее можно взять за основу самостоятельного обучения. Сами мини-лекции мне показались поверхностными и нудными.
Решила освежить базу и пройти легендарный гарвардский курс CS50: Introduction to Computer Science.
Пока прослушала половину лекций и мне все очень нравится.
Курс бесплатный и очень качественный. Особенно ценно, что он обновляется каждый год и дает актуальную информацию и современные примеры.
Из возможных сложностей отмечу, что материала много и он на английском. Но английский очень понятный, B1 должно спокойно хватать. Есть перевод на русский от JavaRush, но там версия 2015го года.
В CS50 не дают лишних подробностей и не перегружают терминами, а стараются объяснить так, чтобы появилось общее понимание базовых концепций и принципов.
Мне кажется очень грамотным, что основы программирования начинают объяснять на примере C, а не Python, как это делается в большинстве современных стартовых курсов. Потому что на C все расписывается подробно и долго — а это очень помогает усвоению информации.
Также полезно понимать, как работают функции, встроенные в высокоуровневые языки. А С — это отличный способ разобраться в фундаменте работы программиста. Ведь многие интерпретаторы и компиляторы написаны на C (в том числе Python). И С все еще остаётся базовым языком операционных систем и низкоуровневых библиотек.
Помимо C, в курсе рассказывают про Python, память, алгоритмы, структуры данных, SQL, HTML, CSS и JavaScript. То есть информации много и даже если посмотреть только лекции — вполне можно получить общее представление об ИТ.
Отдельного восхищения достойны лектор Дэвид Мэлэн и организаторы — прекрасная подача материала и техническая подготовка. Как будто ты смотришь стендап-концерт, а не лекции по основам информационных технологий.
В общем, рекомендую.
А если CS50 кажется сложноватым — можно посмотреть на эти курсы:
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
1. CS50 на русском: Лекция #1 [Гарвард, Основы программирования, осень 2015 год]
Доп. материалы и задачи к лекции - https://javarush.com/s/level_0
Весь курс CS50 — https://javarush.com/s/course_cs50
Это Хогвартс? Нет, друзья, это Гарвард и первая лекция (Week 0) легендарного курса по основам программирования CS50 с русским переводом.…
Весь курс CS50 — https://javarush.com/s/course_cs50
Это Хогвартс? Нет, друзья, это Гарвард и первая лекция (Week 0) легендарного курса по основам программирования CS50 с русским переводом.…
❤22🔥13👍8🙏1
НАВИГАЦИЯ ПО КАНАЛУ
Наконец дошли руки систематизировать мой сервант и сделать оглавление всех постов:
О канале и авторе
🔧 HARD SKILLS
Интеграции и API
• Пректирование GraphQL API - цикл статей:
- Введение в GraphQL (07.2025)
- Схема GraphQL (07.2025)
• Как познакомиться с GraphQL (10.2024)
• Чем опасен PATCH? (09.2024)
• 6 принципов проектирования API (08.2024)
• Инфографика: API technologies (07.2024)
• Проблема зависимых сообщений (07.2024)
• 12 способов сделать API безопаснее (12.2023)
• Event Driven Architecture - что почитать (07.2023)
• Доступ к данным в API (02.2023)
• Воркшоп по проектированию интеграций (11.2022)
• Идентификаторы в системах (08.2022)
• Что почитать про REST-like API (08.2022)
• Пагинация (04.2022)
• Основы интеграции систем - вебинар (03.2022)
• Обратная совместимость (01.2022)
Анализ и разработка
• Курсы по основам программирования (05.2025)
• Какого размера должны быть микросервисы? (04.2025)
• Дискуссия о книге Вигерса в 2024 году (08.2024)
• Важность реальных данных при разработке (12.2023)
• Памятка для погружения в новый проект (04.2022)
• Интервью о работе системного аналитика (11.2021)
• Бесплатные курсы по базам данных и SQL (10.2021)
• Статья про микросервисы на Хабре (10.2021)
• Документация в порядке - статья на Хабре (03.2021)
• Требования к ПО на пальцах - статья на Хабре (05.2020)
• А. Купер "Интерфейс" (09.2019)
🧠 SOFT SKILLS
Карьера и развитие
• Прожарка LinkedIn профиля (12.2024)
• Резюме для международного рынка (11.2024)
• Ресурсы для поиска работы (11.2021)
• Летний Аналитический Фестиваль (07.2021)
Написание текстов и коммуникация
• Позитивная коммуникация (11.2019)
• TED про когнитивные искажения (10.2019)
• 5 этапов написания текста (08.2019)
• Тексты, которые пишут люди - книги по писательству (08.2019)
Тайм-менеджмент и продуктивность
• Notion для личной базы знаний (08.2021)
• Книга про уверенность К. Форен (03.2021)
• Agile-методологии - космическая одиссея (10.2019)
• Энергия и откуда ее брать (09.2019)
• Секретный секрет тайм-менеджмента (09.2019)
Наконец дошли руки систематизировать мой сервант и сделать оглавление всех постов:
О канале и авторе
🔧 HARD SKILLS
Интеграции и API
• Пректирование GraphQL API - цикл статей:
- Введение в GraphQL (07.2025)
- Схема GraphQL (07.2025)
• Как познакомиться с GraphQL (10.2024)
• Чем опасен PATCH? (09.2024)
• 6 принципов проектирования API (08.2024)
• Инфографика: API technologies (07.2024)
• Проблема зависимых сообщений (07.2024)
• 12 способов сделать API безопаснее (12.2023)
• Event Driven Architecture - что почитать (07.2023)
• Доступ к данным в API (02.2023)
• Воркшоп по проектированию интеграций (11.2022)
• Идентификаторы в системах (08.2022)
• Что почитать про REST-like API (08.2022)
• Пагинация (04.2022)
• Основы интеграции систем - вебинар (03.2022)
• Обратная совместимость (01.2022)
Анализ и разработка
• Курсы по основам программирования (05.2025)
• Какого размера должны быть микросервисы? (04.2025)
• Дискуссия о книге Вигерса в 2024 году (08.2024)
• Важность реальных данных при разработке (12.2023)
• Памятка для погружения в новый проект (04.2022)
• Интервью о работе системного аналитика (11.2021)
• Бесплатные курсы по базам данных и SQL (10.2021)
• Статья про микросервисы на Хабре (10.2021)
• Документация в порядке - статья на Хабре (03.2021)
• Требования к ПО на пальцах - статья на Хабре (05.2020)
• А. Купер "Интерфейс" (09.2019)
🧠 SOFT SKILLS
Карьера и развитие
• Прожарка LinkedIn профиля (12.2024)
• Резюме для международного рынка (11.2024)
• Ресурсы для поиска работы (11.2021)
• Летний Аналитический Фестиваль (07.2021)
Написание текстов и коммуникация
• Позитивная коммуникация (11.2019)
• TED про когнитивные искажения (10.2019)
• 5 этапов написания текста (08.2019)
• Тексты, которые пишут люди - книги по писательству (08.2019)
Тайм-менеджмент и продуктивность
• Notion для личной базы знаний (08.2021)
• Книга про уверенность К. Форен (03.2021)
• Agile-методологии - космическая одиссея (10.2019)
• Энергия и откуда ее брать (09.2019)
• Секретный секрет тайм-менеджмента (09.2019)
Telegram
Системный сервант
О КАНАЛЕ И АВТОРЕ
Привет!
Меня зовут Таня, я системный и бизнес-аналитик, занимаюсь разработкой IT-систем с 2015 года. Работала в ритейле, строительстве и финтехе.
Это мой авторский блог, который я веду с 2019 года в формате хобби. Я не покупаю и не продаю…
Привет!
Меня зовут Таня, я системный и бизнес-аналитик, занимаюсь разработкой IT-систем с 2015 года. Работала в ритейле, строительстве и финтехе.
Это мой авторский блог, который я веду с 2019 года в формате хобби. Я не покупаю и не продаю…
👍26🔥18❤9
Системный сервант pinned «НАВИГАЦИЯ ПО КАНАЛУ Наконец дошли руки систематизировать мой сервант и сделать оглавление всех постов: О канале и авторе 🔧 HARD SKILLS Интеграции и API • Пректирование GraphQL API - цикл статей: - Введение в GraphQL (07.2025) - Схема GraphQL…»
Статья «Введение в GraphQL»
Впервые я встретилась с GraphQL в 2021 году на проекте с мобильным приложением. К тому времени я уже несколько лет работала с REST-like APIs, что помогло, но не слишком. Чем больше я читала документацию и статьи по этой теме, тем меньше я понимала, а что вообще происходит. Ответ на любой базовый вопрос вроде “Что такое типы в GraphQL?” порождал несколько дополнительных вопросов, ответы на которые сложно было нагуглить и еще сложнее осознать.
После я спроектировала несколько GraphQL API с нуля и в течение 3 лет с ними работала. В итоге, кажется, что-то все-таки стала в этом понимать. Хотя на протяжение 3 лет мы всей командой обнаруживали что-то новое и неизведанное в мире GraphQL. Что-то, что если и было описано, то где-то в закромах у Apollo или в блогах компаний на Medium.
GraphQL — новый и сложный инструмент. При этом он сейчас на этапе развития и постоянно появляются новые паттерны и подходы для применения этой штуки в реальных системах.
Спецификация еще дорабатывается, а официальная документация не то чтобы дает исчерпывающие ответы на все вопросы. И это я не говорю про материалы на русском языке.
Поэтому у меня возникла идея написать статью, где бы я собрала и структурировала свои знания и опыт об этой технологии. В процессе написания меня немного занесло и материала получилось на целый цикл из 5 статей “Проектирование GraphQL API”. Не все они на данный момент дописаны.
Но сегодня вышла первая статья из цикла: “Введение в GraphQL”. 🥳 Очень этому рада, потому что от идеи до публикации прошел год. Надеюсь, для кого-то эти статьи окажутся полезными и помогут быстрее и лучше разобраться в хитросплетениях селективных запросов.
Очень благодарна Systems.Education за поддержку, публикацию и корректировки.
Первая статья вводная и очень общая, чтобы познакомиться с технологией и понять основную суть работы. А в ближайшее время выйдет вторая часть цикла — подробный лонгрид про схему GraphQL.
Впервые я встретилась с GraphQL в 2021 году на проекте с мобильным приложением. К тому времени я уже несколько лет работала с REST-like APIs, что помогло, но не слишком. Чем больше я читала документацию и статьи по этой теме, тем меньше я понимала, а что вообще происходит. Ответ на любой базовый вопрос вроде “Что такое типы в GraphQL?” порождал несколько дополнительных вопросов, ответы на которые сложно было нагуглить и еще сложнее осознать.
После я спроектировала несколько GraphQL API с нуля и в течение 3 лет с ними работала. В итоге, кажется, что-то все-таки стала в этом понимать. Хотя на протяжение 3 лет мы всей командой обнаруживали что-то новое и неизведанное в мире GraphQL. Что-то, что если и было описано, то где-то в закромах у Apollo или в блогах компаний на Medium.
GraphQL — новый и сложный инструмент. При этом он сейчас на этапе развития и постоянно появляются новые паттерны и подходы для применения этой штуки в реальных системах.
Спецификация еще дорабатывается, а официальная документация не то чтобы дает исчерпывающие ответы на все вопросы. И это я не говорю про материалы на русском языке.
Поэтому у меня возникла идея написать статью, где бы я собрала и структурировала свои знания и опыт об этой технологии. В процессе написания меня немного занесло и материала получилось на целый цикл из 5 статей “Проектирование GraphQL API”. Не все они на данный момент дописаны.
Но сегодня вышла первая статья из цикла: “Введение в GraphQL”. 🥳 Очень этому рада, потому что от идеи до публикации прошел год. Надеюсь, для кого-то эти статьи окажутся полезными и помогут быстрее и лучше разобраться в хитросплетениях селективных запросов.
Очень благодарна Systems.Education за поддержку, публикацию и корректировки.
Первая статья вводная и очень общая, чтобы познакомиться с технологией и понять основную суть работы. А в ближайшее время выйдет вторая часть цикла — подробный лонгрид про схему GraphQL.
systems.education
■ Статья. Введение в GraphQL
🔥39👍5❤1
Вот и статья про схему в GraphQL. Так как я в основном работала со схемой — получилось много практической информации. А так как схема — центральный элемент GraphQL — там есть о чем поговорить🙂.
systems.education
■ Статья. Схема GraphQL
Автор: Татьяна Сальникова
❤12👍8✍2🔥1
Коллеги из NextWay устраивают 2 августа онлайн-конференцию для аналитиков. Мне показался интересным разброс тем в программе: от стриминговых платформ и ИИ-агентов до антикризисной карьеры и “Как выжить в 2025 и не выгореть”.
Ощущается, как аналитический пост-апокалипсис: собираем бластер за кучей легаси, чтобы успеть отбиться от роботов🤖 . Да, сейчас “сложный рынок”, но у меня не было ощущения, что профессия сама по себе в кризисе. Сообщество развивается, IT-компании внедряют процессы проектирования, открываются позиции для аналитиков. Всё реже встречаю людей, которые никогда не работали с БА/СА и вообще не в курсе, чем мы занимаемся. Да, развивается ИИ, но ему все равно нужны будут вводные: требования, цели, ограничения. Вроде за этим и нужен аналитик. Или уже нет?🤔
То есть кажется, что кризис на рынке и быстрое развитие ИИ разогнали всем воображение и уже сложно понять: кто мы, что мы делаем и зачем? Как будто мы бежим вокруг дерева со скоростью света и вот-вот себя нагоним.
Поэтому интересно послушать спикеров на конференции: с какими вызовами встречаются коллеги и как их решают? На сколько сильно изменились требования от аналитиков и их задачи? Можно ли определить какой-то вектор развития профессии, или пока это броуновское движение?
А вы как считаете: ИИ просто вскружил нам головы или грядут великие перемены?
Ощущается, как аналитический пост-апокалипсис: собираем бластер за кучей легаси, чтобы успеть отбиться от роботов
То есть кажется, что кризис на рынке и быстрое развитие ИИ разогнали всем воображение и уже сложно понять: кто мы, что мы делаем и зачем? Как будто мы бежим вокруг дерева со скоростью света и вот-вот себя нагоним.
Поэтому интересно послушать спикеров на конференции: с какими вызовами встречаются коллеги и как их решают? На сколько сильно изменились требования от аналитиков и их задачи? Можно ли определить какой-то вектор развития профессии, или пока это броуновское движение?
А вы как считаете: ИИ просто вскружил нам головы или грядут великие перемены?
Please open Telegram to view this post
VIEW IN TELEGRAM
nextconf.pro
Профессия аналитик - настоящее и будущее. Архитектура и технологии, карьера и развитие, AI-инструменты для работы и жизни.
👍9❤🔥4🔥4❤1
А еще в августе буду жюрить в конкурсе авторских постов🤗
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥6👏2❤1
Forwarded from Systems.Education: Системный Анализ и Проектирование информационных систем: архитектура, интеграции, базы данных
🏆 Конкурс авторских публикаций «Продолжи мысль» от Systems.Education
За последние годы сообщество авторов экспертных постов в Telegram серьёзно выросло. Мы предлагаем возможность ведущим профессиональных каналов заявить о себе. На конкурсе мы будем оценивать ваше умение не только писать чётко, понятно и по делу, но и рецензировать публикации коллег.
▫️ Участниками конкурса могут стать авторы, ведущие Telegram-каналы на темы, связанные с системным, бизнес-анализом, проектированием ИТ-систем и смежными дисциплинами.
Формат конкурса — Дистанционный. Участники будут размещать свои авторские публикации в собственных Telegram-каналах.
▫️ Зачем это вам:
— Заявите на большую аудиторию о своих знаниях, опыте и наработках
— Получите бесплатную нативную рекламу ваших блогов, если пройдёте в первый и второй туры
— Победители конкурса получат профессиональное развитие за счёт SE на свой выбор: оплата подписок на профессиональные ресурсы, продюсирование и методическая поддержка авторов, менторство и карьерные консультации от экспертов
▫️ Зачем это нам:
Мы стремимся развивать профессиональное сообщество системных и бизнес-аналитиков. Поэтому мы готовы поддерживать авторов качественного контента и распространять знания в области анализа и проектирования ИТ-систем.
⬆️ На карточках мы подробно рассказали о процессе подачи заявки, номинациях и этапах конкурса.
На лендинге вы найдете ссылку на регламент с методикой оценивания конкурсных работ и список жюри.
Подавайте заявку — и пусть мысль не просто продолжится, а станет вирусной
Контакт координатора для ответов на вопросы и подачи заявки на конкурс — @kosvetlanov
#продолжи_мысль_SE
За последние годы сообщество авторов экспертных постов в Telegram серьёзно выросло. Мы предлагаем возможность ведущим профессиональных каналов заявить о себе. На конкурсе мы будем оценивать ваше умение не только писать чётко, понятно и по делу, но и рецензировать публикации коллег.
▫️ Участниками конкурса могут стать авторы, ведущие Telegram-каналы на темы, связанные с системным, бизнес-анализом, проектированием ИТ-систем и смежными дисциплинами.
Формат конкурса — Дистанционный. Участники будут размещать свои авторские публикации в собственных Telegram-каналах.
▫️ Зачем это вам:
— Заявите на большую аудиторию о своих знаниях, опыте и наработках
— Получите бесплатную нативную рекламу ваших блогов, если пройдёте в первый и второй туры
— Победители конкурса получат профессиональное развитие за счёт SE на свой выбор: оплата подписок на профессиональные ресурсы, продюсирование и методическая поддержка авторов, менторство и карьерные консультации от экспертов
▫️ Зачем это нам:
Мы стремимся развивать профессиональное сообщество системных и бизнес-аналитиков. Поэтому мы готовы поддерживать авторов качественного контента и распространять знания в области анализа и проектирования ИТ-систем.
⬆️ На карточках мы подробно рассказали о процессе подачи заявки, номинациях и этапах конкурса.
На лендинге вы найдете ссылку на регламент с методикой оценивания конкурсных работ и список жюри.
Подавайте заявку — и пусть мысль не просто продолжится, а станет вирусной
⏰Прием заявок до 11.08 включительно
Контакт координатора для ответов на вопросы и подачи заявки на конкурс — @kosvetlanov
#продолжи_мысль_SE
❤5⚡3👍2
Опубликовала третью статью из цикла про GraphQL, посвященную архитектуре. На мой взгляд, это самая головоломная часть истории.
Есть множество вариантов, как примостить GraphQL API в рамках ИТ-ландшафта компании. Однако понять, какой из этих вариантов не превратит жизнь команды в боль и страдания — задачка не из легких🤯.
Конечно, бремя выбора ложится на плечи архитекторов и руководителей разработки. Но и нам, простым смертным, хорошо бы понимать — а что вообще происходит? Постаралась разобраться и объяснить существующие картины мира с GraphQL в рамках статьи.
Есть множество вариантов, как примостить GraphQL API в рамках ИТ-ландшафта компании. Однако понять, какой из этих вариантов не превратит жизнь команды в боль и страдания — задачка не из легких🤯.
Конечно, бремя выбора ложится на плечи архитекторов и руководителей разработки. Но и нам, простым смертным, хорошо бы понимать — а что вообще происходит? Постаралась разобраться и объяснить существующие картины мира с GraphQL в рамках статьи.
Хабр
Архитектура и GraphQL
Это третья статья из цикла « Проектирование GraphQL API ». Введение В предыдущих статьях мы рассмотрели основы GraphQL и принципы проектирования схемы . Теперь перейдём к архитектуре — фундаменту,...
🔥8👍6❤5🎉1😐1