Assessment - реальная оценка твоих навыков или обучение навыку собеседований за счёт работодателя?
Мне кажется, все уже обсуждали, что ассессмент нужен для того, чтобы зажимать зарплату.
Здесь можно долго дискутировать, но давайте посмотрим с другой стороны.
Недавно мне прислали из нескольких крупных компаний новые критерии к аналитикам и рассказали, как у них внедряли ассессмент. И в этот раз я словила себя на мысли, что, похоже, теперь это стало отличным поводом для сотрудника потренироваться за счёт компании и свалить из неё.
Потому что по факту это очередное собеседование из классики: "не важно, чем тебе нужно заниматься, мы спросим тебя обо всём".
Я не утрирую, в одном месте руководство так и заявило: "Не важно, что вам это не нужно в работе, мы хотим, чтобы наши аналитики были конкурентны на рынке труда." Компания при этом забыла, что платит не по верху этого самого рынка :)
А что думаете вы?
Мне кажется, все уже обсуждали, что ассессмент нужен для того, чтобы зажимать зарплату.
Здесь можно долго дискутировать, но давайте посмотрим с другой стороны.
Недавно мне прислали из нескольких крупных компаний новые критерии к аналитикам и рассказали, как у них внедряли ассессмент. И в этот раз я словила себя на мысли, что, похоже, теперь это стало отличным поводом для сотрудника потренироваться за счёт компании и свалить из неё.
Потому что по факту это очередное собеседование из классики: "не важно, чем тебе нужно заниматься, мы спросим тебя обо всём".
Я не утрирую, в одном месте руководство так и заявило: "Не важно, что вам это не нужно в работе, мы хотим, чтобы наши аналитики были конкурентны на рынке труда." Компания при этом забыла, что платит не по верху этого самого рынка :)
А что думаете вы?
👍1😁1🤔1
Три потока, один я. Что выбрать на NextConf?
Уже в эту субботу пройдёт онлайн-конференция от NextWay (ссылка на сайт?)!
Ранее я писала о своих впечатлениях о NextConf как участник и как спикер. В этот раз удалось собрать три потока, и, честно, не знаю, как выбрать, куда пойти. Но вот эти доклады интересны лично мне:
🔹 Владислав Луговых "Использование С4 и принципов DDD на примере проектирования кредитного конвейера". Сама продолжаю осмыслять тему, как С4 и DDD использовать аналитику, поэтому интересно послушать о чужом опыте и размышлениях.
🔹 Анна Вичугова "Kafka теперь Rabbit и наоборот?". Анна как показатель качества и технически хорошо разобранной темы. И снова про моего любимого кролика 🐇 (да, здесь могла быть шутка 18+)
🔹 Между докладами Елизаветы Акмановой "Как мы адаптировали микрофронты под другой домен" и Иннокентия Бодрова "Технический продакт-менеджер" действительно можно разорваться.
В первом случае знаю, что спикер классный, но тема, судя по описанию, обещает быть подробно технически и процессно разобранной.
Во втором спикер тоже топ, а тема прямо очень близка к тому, что вокруг меня летает.
🔹 А после технических докладов, видимо, нужно отдать предпочтение воркшопу Ирины Шишкиной "Карта смыслов".
Эту тему я сейчас осмысляю в рамках технического доклада, с которым надеюсь выступить осенью, а здесь целый воркшоп! Очень интересна и механика "Как вообще на такую тему сделать воркшоп?", и к чему он может привести лично меня.
🔹 Ну надеюсь остануться силы на доклад Светланы Дергачёвой "AI + Аналитик = Архитектор".
Дискуссии на эту тему уже встречались мне последние несколько недель. Здесь интересно: можно подглядеть в этапы работы над архитектурой в конкретной компании и где там может быть место ИИ.
И кстати, из плюсов в стоимость уже входят воркшопы! А такое бывает не всегда :)
Уже в эту субботу пройдёт онлайн-конференция от NextWay (ссылка на сайт?)!
Ранее я писала о своих впечатлениях о NextConf как участник и как спикер. В этот раз удалось собрать три потока, и, честно, не знаю, как выбрать, куда пойти. Но вот эти доклады интересны лично мне:
🔹 Владислав Луговых "Использование С4 и принципов DDD на примере проектирования кредитного конвейера". Сама продолжаю осмыслять тему, как С4 и DDD использовать аналитику, поэтому интересно послушать о чужом опыте и размышлениях.
🔹 Анна Вичугова "Kafka теперь Rabbit и наоборот?". Анна как показатель качества и технически хорошо разобранной темы. И снова про моего любимого кролика 🐇 (да, здесь могла быть шутка 18+)
🔹 Между докладами Елизаветы Акмановой "Как мы адаптировали микрофронты под другой домен" и Иннокентия Бодрова "Технический продакт-менеджер" действительно можно разорваться.
В первом случае знаю, что спикер классный, но тема, судя по описанию, обещает быть подробно технически и процессно разобранной.
Во втором спикер тоже топ, а тема прямо очень близка к тому, что вокруг меня летает.
🔹 А после технических докладов, видимо, нужно отдать предпочтение воркшопу Ирины Шишкиной "Карта смыслов".
Эту тему я сейчас осмысляю в рамках технического доклада, с которым надеюсь выступить осенью, а здесь целый воркшоп! Очень интересна и механика "Как вообще на такую тему сделать воркшоп?", и к чему он может привести лично меня.
🔹 Ну надеюсь остануться силы на доклад Светланы Дергачёвой "AI + Аналитик = Архитектор".
Дискуссии на эту тему уже встречались мне последние несколько недель. Здесь интересно: можно подглядеть в этапы работы над архитектурой в конкретной компании и где там может быть место ИИ.
И кстати, из плюсов в стоимость уже входят воркшопы! А такое бывает не всегда :)
nextconf.pro
Профессия аналитик - настоящее и будущее. Архитектура и технологии, карьера и развитие, AI-инструменты для работы и жизни.
👍7
Июль у меня выдался... ух.
Запускали новую фичу, отменяли запуск старых фич, а ещё и болезнями накрыло.
Не удивительно, что под конец месяца я достаточно спонтанно(по своим меркам) взяла отпуск и уехала в горы и к морю к своей женской мафии ❤️.
Поэтому июль в блоге вышел несколько скомканным, но интересные посты всё же были:
📌 Больше всего сохранений было у достаточно старенькой статьи про работу Google.
Классика, которая не устаревает
📌 Не прошёл и мимо многих мой очередной факап, где я накосячила со спекой OpenAPI.
📌 Самый "мрачный пост" был про могильные камни и где в ИТ вы с ними встретитесь
📌 Ну и больше всего реакций и кулуарных обсуждений получилось вокруг Флирта безопасности (да, это именно та фича, которую мы запускали!)
А теперь, отдохнувшая и заряженная, я готова принять участие в конкурсе от System Education и поделиться парочкой новых интересных историй. Не пропустите :)
Запускали новую фичу, отменяли запуск старых фич, а ещё и болезнями накрыло.
Не удивительно, что под конец месяца я достаточно спонтанно
Поэтому июль в блоге вышел несколько скомканным, но интересные посты всё же были:
📌 Больше всего сохранений было у достаточно старенькой статьи про работу Google.
Классика, которая не устаревает
📌 Не прошёл и мимо многих мой очередной факап, где я накосячила со спекой OpenAPI.
📌 Самый "мрачный пост" был про могильные камни и где в ИТ вы с ними встретитесь
📌 Ну и больше всего реакций и кулуарных обсуждений получилось вокруг Флирта безопасности (да, это именно та фича, которую мы запускали!)
А теперь, отдохнувшая и заряженная, я готова принять участие в конкурсе от System Education и поделиться парочкой новых интересных историй. Не пропустите :)
Telegram
Анализ, коты, цветы и Катя
Какой путь проходят данные в ИТ-системах?
Вызвалась помочь молодому коллеге ответить на вопрос: «Как понять, на чьей стороне ошибка?» Тема интересная но, конечно, она не новая, поэтому легко ищется хорошая литература.
Лично мне для старта нравиться эта…
Вызвалась помочь молодому коллеге ответить на вопрос: «Как понять, на чьей стороне ошибка?» Тема интересная но, конечно, она не новая, поэтому легко ищется хорошая литература.
Лично мне для старта нравиться эта…
🔥8❤5
"Не знаешь, не отвечай"
Все уже сталкивались с тем, что ИИ лжёт и придумывает информацию.
Для борьбы с этим ULCamp услышала крутой совет: всегда добавлять такое пояснение к важным запросам.
Проверила. Ответы сокращаются и точнее. Необходимость в проверке это не отменяет, но проверять всякий шлак точно нужно реже.
А как вы спасаетесь от того, что ИИ лжёт и выдумывает?
#ИИ #вайбаналитика
Все уже сталкивались с тем, что ИИ лжёт и придумывает информацию.
Для борьбы с этим ULCamp услышала крутой совет: всегда добавлять такое пояснение к важным запросам.
Проверила. Ответы сокращаются и точнее. Необходимость в проверке это не отменяет, но проверять всякий шлак точно нужно реже.
А как вы спасаетесь от того, что ИИ лжёт и выдумывает?
#ИИ #вайбаналитика
😁9👍2🔥2
Зачем аналитику знать про харденинг?
Недавно в моём профессиональном лексиконе появилось новое слово — харденинг. Сейчас оно как никогда актуально. Между тем, когда я начала искать что это такое, то столкнулась с таким ужасным определением:
Харденинг (hardening) — процесс повышения безопасности компьютерных систем и сетей путём уменьшения поверхности атаки и усиления защиты от потенциальных угроз.
Вам что-то понятно? Лично мне — нет. Потому что такое определение можно дать про большинство DevSecOps-практик, криптографию и многое другое из сферы ИБ.
Так что же это?
Харденинг — не про безопасность кода. Это про безопасность окружения и систем, на которых запускается ваш код. То есть касается безопасности ОС, облаков и серверов.
Дело в том, что «из коробки» большинство операционных систем, облаков и сетей имеют:
множество утилит и демонов для специфических задач,
открытые порты,
пользователей и группы с чрезмерными правами,
и массу других потенциальных точек доступа — на уровне железа, прошивок, сетевых настроек, платформ и сервисов.
Всё это может дать злоумышленникам дополнительные возможности для атак.
Для системных администраторов, саппорта и девопсов это огромный пласт работы — выявлять такие места и сужать поверхность атаки.
Но и системные аналитики могут приложить к этому руку.
Что можем сделать мы?
🤌🏻 Правильно собрать нефункциональные требования🤌🏻
Корректная информация о портах, ключах, типах шифрования помогает правильно настроить окружения облаков и ОС.
🤌🏻 Сформировать понимание ролей и доступов🤌🏻
Кому, что и в каком объёме доступно. Нужны ли локальные учётки, под какими правами, что будет храниться или писаться в памяти.
🤌🏻 Описать границы систем🤌🏻
Что во внутренней сети, а что торчит наружу. Учитывать обмен данными в разных контурах.
🤌🏻 Подготовить метрики приёмки и набор стандартов для окружения важнейшей системы.
На что опираться при проработке?
Неофициально в России, но лучшие практики собраны в CIS Benchmarks.
Российские дополнения:
ФСТЭК № 17
Методический документ. Меры защиты информации в государственных информационных системах
Для работы с персональными данными и финсектором есть отдельные предписания.
И хотя харденинг - это вроде как «работа админов», во многих системах аналитик может помочь заложить чёткие, измеримые и реалистичные требования к окружению. А это позволит админам и девопсам выполнить работы по харденингу качественнее и быстрее.
Делитесь как у вас в команде: этим занимается только админы или аналитики тоже в теме?
Участвую в конкурсе #продолжи_мысль_SE от @systems_education
Недавно в моём профессиональном лексиконе появилось новое слово — харденинг. Сейчас оно как никогда актуально. Между тем, когда я начала искать что это такое, то столкнулась с таким ужасным определением:
Харденинг (hardening) — процесс повышения безопасности компьютерных систем и сетей путём уменьшения поверхности атаки и усиления защиты от потенциальных угроз.
Вам что-то понятно? Лично мне — нет. Потому что такое определение можно дать про большинство DevSecOps-практик, криптографию и многое другое из сферы ИБ.
Так что же это?
Харденинг — не про безопасность кода. Это про безопасность окружения и систем, на которых запускается ваш код. То есть касается безопасности ОС, облаков и серверов.
Дело в том, что «из коробки» большинство операционных систем, облаков и сетей имеют:
множество утилит и демонов для специфических задач,
открытые порты,
пользователей и группы с чрезмерными правами,
и массу других потенциальных точек доступа — на уровне железа, прошивок, сетевых настроек, платформ и сервисов.
Всё это может дать злоумышленникам дополнительные возможности для атак.
Для системных администраторов, саппорта и девопсов это огромный пласт работы — выявлять такие места и сужать поверхность атаки.
Но и системные аналитики могут приложить к этому руку.
Что можем сделать мы?
🤌🏻 Правильно собрать нефункциональные требования🤌🏻
Корректная информация о портах, ключах, типах шифрования помогает правильно настроить окружения облаков и ОС.
🤌🏻 Сформировать понимание ролей и доступов🤌🏻
Кому, что и в каком объёме доступно. Нужны ли локальные учётки, под какими правами, что будет храниться или писаться в памяти.
🤌🏻 Описать границы систем🤌🏻
Что во внутренней сети, а что торчит наружу. Учитывать обмен данными в разных контурах.
🤌🏻 Подготовить метрики приёмки и набор стандартов для окружения важнейшей системы.
На что опираться при проработке?
Неофициально в России, но лучшие практики собраны в CIS Benchmarks.
Российские дополнения:
ФСТЭК № 17
Методический документ. Меры защиты информации в государственных информационных системах
Для работы с персональными данными и финсектором есть отдельные предписания.
И хотя харденинг - это вроде как «работа админов», во многих системах аналитик может помочь заложить чёткие, измеримые и реалистичные требования к окружению. А это позволит админам и девопсам выполнить работы по харденингу качественнее и быстрее.
Делитесь как у вас в команде: этим занимается только админы или аналитики тоже в теме?
Участвую в конкурсе #продолжи_мысль_SE от @systems_education
CIS
CIS Benchmarks®
CIS Benchmarks help you safeguard systems, software, and networks against today's evolving cyber threats.
🔥7👍4❤1
Если вам кажется, что вы понимаете, что такое транзакции - вам кажется.
Несколько лет назад в знаменитом «кабанчике» Клеппмана я прочитала:
Хм, интересно, подумала я, но тогда не придала этому значения. Позже я начала работать с 389 Directory Server - иерархической БД на протоколе LDAP.
😮И... сюрприз, сюрприз: 😮 в базовой комплектации в ней нет транзакционности в привычном для SQL-разработчика смысле.
Что это значит:
- Как только произошла операция над объектом (в LDAP это ADD, MODIFY, DELETE) и она подтверждена сервером — она фиксируется.
- Нет отката изменений для группы объектов.
- Можно накрутить костылей вокруг changelog, чтобы имитировать транзакцию, но это будет уже backend-код, а не гарантия от самой БД.
При более детальном разборе оказалось, что в каком-то виде транзакционность (а точнее часть A из ACID) всё же есть, если речь о нескольких изменениях в рамках одной команды, обращённой к одному объекту.
В Пример 1, это обрабатывается как единая операция: либо применяется всё, либо ничего.
С этого момента жить стало проще… до тех пор, пока ко мне не принесли пачку запросов с неконсистентными данными, которые такими быть не долждны были (в нашем понимании).
Причина в том, что к одному объекту можно атомарно обратиться по-разному:
Как в примере 1, или же сделать те же действия, но двумя отдельными командами (пример 2, каждое объявление группы начинает новую операцию):
При работе на одном сервере: в первом случае атомарность гарантируется на уровне операции, во втором за счет транзакции уровня backend-хранилища (DBTxn). В целом зная об этом, у нас частенько встречались оба варианта операций.
⚠️ Вот только⚠️ , при репликации каждая команда получает свой CSN (номер изменения) и всегда выполняется отдельно. В результате в Примере 2 первая операция может примениться, а вторая - нет. Хотя на одном сервере, они всегда выполняются вместе.
Когда, казалось бы, я уже понимаю этим важные моменты, мне пришлось столкнуться с RFC 5805 (LDAP Transactions), который открывает перед LDAP возможности транзакционности при использовании специальных патчей. Но это уже совсем другая история.
Так что, если вы уверены, что уже хорошо разбираетесь в транзакциях, но работали только с реляционными СУБД, вас ждёт немало сюрпризов.
💬 Ну а те кто уже хлебнул разных систем, поделитесь с какой «недо»-транзакционностью сталкивались? К чему это приводило? Что было самым необычным?
Участвую в конкурсе #продолжи_мысль_SE от @systems_education
#LDAP #транзакции #СУБД
Несколько лет назад в знаменитом «кабанчике» Клеппмана я прочитала:
"Транзакции оказались главной жертвой" NoSQL БД: "многие базы нового поколения полностью отказались или поменяли значение термина — теперь он стал означать намного более слабый набор функциональных гарантий."
Хм, интересно, подумала я, но тогда не придала этому значения. Позже я начала работать с 389 Directory Server - иерархической БД на протоколе LDAP.
😮И... сюрприз, сюрприз: 😮 в базовой комплектации в ней нет транзакционности в привычном для SQL-разработчика смысле.
Что это значит:
- Как только произошла операция над объектом (в LDAP это ADD, MODIFY, DELETE) и она подтверждена сервером — она фиксируется.
- Нет отката изменений для группы объектов.
- Можно накрутить костылей вокруг changelog, чтобы имитировать транзакцию, но это будет уже backend-код, а не гарантия от самой БД.
При более детальном разборе оказалось, что в каком-то виде транзакционность (а точнее часть A из ACID) всё же есть, если речь о нескольких изменениях в рамках одной команды, обращённой к одному объекту.
В Пример 1, это обрабатывается как единая операция: либо применяется всё, либо ничего.
в группе Editors
ADD UserA, UserB
DELETE UserX, UserY
С этого момента жить стало проще… до тех пор, пока ко мне не принесли пачку запросов с неконсистентными данными, которые такими быть не долждны были (в нашем понимании).
Причина в том, что к одному объекту можно атомарно обратиться по-разному:
Как в примере 1, или же сделать те же действия, но двумя отдельными командами (пример 2, каждое объявление группы начинает новую операцию):
в группе Editors
ADD UserA, UserB
в группе Editors
DELETE UserX, UserY
При работе на одном сервере: в первом случае атомарность гарантируется на уровне операции, во втором за счет транзакции уровня backend-хранилища (DBTxn). В целом зная об этом, у нас частенько встречались оба варианта операций.
Когда, казалось бы, я уже понимаю этим важные моменты, мне пришлось столкнуться с RFC 5805 (LDAP Transactions), который открывает перед LDAP возможности транзакционности при использовании специальных патчей. Но это уже совсем другая история.
Так что, если вы уверены, что уже хорошо разбираетесь в транзакциях, но работали только с реляционными СУБД, вас ждёт немало сюрпризов.
💬 Ну а те кто уже хлебнул разных систем, поделитесь с какой «недо»-транзакционностью сталкивались? К чему это приводило? Что было самым необычным?
Участвую в конкурсе #продолжи_мысль_SE от @systems_education
#LDAP #транзакции #СУБД
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍1🤔1
Одни из самых крутых команд в мире системного анализа (Flow, NextWay, DevCrowd и автор канала "Системный сдвиг") объединились и создали опрос: "Исследование рынка системных и бизнес-аналитиков, 2025"
Цель: понять, что аналитики реально делают и используют на практике, а не очередной список из 100+ вопросов с Хабра и копипаст вакансий.
Не знаю, как у вас, но когда я читаю вакансии часто впадаю в уныние. Всё сложное и интересное, чем я занимаюсь, будто "не нужно" на рынке. И думаю, я не одна такая.
Поэтому я прошла опрос, и теперь очень жду результаты.
Присоединяйтесь. Давайте узнаем чем же занимаются аналитики в 25 году!
Цель: понять, что аналитики реально делают и используют на практике, а не очередной список из 100+ вопросов с Хабра и копипаст вакансий.
Не знаю, как у вас, но когда я читаю вакансии часто впадаю в уныние. Всё сложное и интересное, чем я занимаюсь, будто "не нужно" на рынке. И думаю, я не одна такая.
Поэтому я прошла опрос, и теперь очень жду результаты.
Присоединяйтесь. Давайте узнаем чем же занимаются аналитики в 25 году!
survey.alchemer.eu
Исследование рынка системных и бизнес-аналитиков, 2025
Исследование рынка системных и бизнес-аналитиков, 2025.
❤3🔥3
Владельцы котов, будьте осторожны, есть подозрение, что они саботируют разработку. Вот несколько признаков!
Во время созвона коллеги жаловались, что меня слышно прерывисто. Долго не могла понять, в чём дело… оказалось, кошка спала на пробеле!
Был важный звонок с камерами, другая кошка лезла в камеру хвостом, заставляя серьёзных людей улыбаться.
Ушла на обед, забыла заблочить экран, возвращаюсь и вместо ADR набор символов "ттттттттттттттттттттттт".
Ваши мысли:
🤔 - не понятно нужно тестить
💯 - известные диверсанты, все признаки заговора есть
👀 - глупая, они спасают от пустых созвонов и ненужных документов
В комментариях можете поделиться своими диверсантами)
Во время созвона коллеги жаловались, что меня слышно прерывисто. Долго не могла понять, в чём дело… оказалось, кошка спала на пробеле!
Был важный звонок с камерами, другая кошка лезла в камеру хвостом, заставляя серьёзных людей улыбаться.
Ушла на обед, забыла заблочить экран, возвращаюсь и вместо ADR набор символов "ттттттттттттттттттттттт".
Ваши мысли:
🤔 - не понятно нужно тестить
💯 - известные диверсанты, все признаки заговора есть
👀 - глупая, они спасают от пустых созвонов и ненужных документов
В комментариях можете поделиться своими диверсантами)
💯15👀13😁7🗿1
По традиции тест по новой теме. Пост будет в 12.
Swagger = OpenAPI?
Swagger = OpenAPI?
Anonymous Quiz
14%
Да, и JSON с YAML — это одно и то же
82%
Нет
4%
Да, потому что так говорит мой тимлид и спорить опасно
В каких форматах может быть спецификация OpenAPI?
Final Results
10%
Только JSON
0%
В формате «Скинь в Word, я поправлю»
64%
JSON и YAML
17%
JSON, YAML. XSD
8%
JSON, YAML. XSD, WORD
Что произойдёт, если не обновить спецификацию OpenAPI после изменения API?
Anonymous Quiz
4%
Мир рухнет, и придёт ИТ-апокалипсис
92%
Документация перестанет соответствовать реальности
4%
Ничего, ведь «и так всё понятно»
Можно ли использовать OpenAPI для чего-то кроме REST?
Anonymous Quiz
84%
Да, для описания любых HTTP API
7%
Нет
6%
Если архитектор разрешит
3%
Нет, только REST и точка
Простой ликбез почему Swagger ≠ OpenAPI
У нас в команде всё, что касается документации REST API, по привычке называют «сваггер»(догадайтесь, кто виноват? 🙈) .
А между тем Swagger один из инструментов, а не сама документация. Поэтому сейчас переучиваемся.
И так как виновата я, то взяла ответственность на себя и подготовила памятку для коллег с разъяснениями. Делюсь и с вами.
📌 Спецификация OpenAPI (OAS) 📌
конкретный YAML/JSON-файл или набор таких файлов, описывающий ваш API. Это источник правды для документации и автогенерации кода.
Я люблю править спеку в VS Code с набором плагинов (если нужен список дайте знать). Но можно в любом YAML-редакторе. А если JSON/YAML пока пугает попробуйте Stoplight Studio.
📌 OpenAPI-документация 📌
красивое, человекочитаемое отображение спеки, которое может быть в Swagger, но не обязательно. Мне нравится ещё Redoc.
📌 Swagger UI 📌
инструмент для отображения в браузере или в Visual Studio. Легко читать, можно даже делать запросы, но менять к нем спеку нельзя.
Путь работы: Придумываем новые эндпоинты → Описываем их в спецификации OpenAPI → Пушим изменения в репозиторий → Ревью →
CI/CD подхватывает обновления, валидирует спеку → Собирает и разворачивает документацию в Swagger UI → С ней начинают работать бэки и фронты
Если вы всё ещё зовёте всё это “сваггером” — просто пересылайте этот пост коллегам
#Swagger #OpenAPI #СистемныйАнализ
У нас в команде всё, что касается документации REST API, по привычке называют «сваггер»
А между тем Swagger один из инструментов, а не сама документация. Поэтому сейчас переучиваемся.
И так как виновата я, то взяла ответственность на себя и подготовила памятку для коллег с разъяснениями. Делюсь и с вами.
📌 Спецификация OpenAPI (OAS) 📌
конкретный YAML/JSON-файл или набор таких файлов, описывающий ваш API. Это источник правды для документации и автогенерации кода.
Я люблю править спеку в VS Code с набором плагинов (если нужен список дайте знать). Но можно в любом YAML-редакторе. А если JSON/YAML пока пугает попробуйте Stoplight Studio.
📌 OpenAPI-документация 📌
красивое, человекочитаемое отображение спеки, которое может быть в Swagger, но не обязательно. Мне нравится ещё Redoc.
📌 Swagger UI 📌
инструмент для отображения в браузере или в Visual Studio. Легко читать, можно даже делать запросы, но менять к нем спеку нельзя.
Путь работы: Придумываем новые эндпоинты → Описываем их в спецификации OpenAPI → Пушим изменения в репозиторий → Ревью →
CI/CD подхватывает обновления, валидирует спеку → Собирает и разворачивает документацию в Swagger UI → С ней начинают работать бэки и фронты
Если вы всё ещё зовёте всё это “сваггером” — просто пересылайте этот пост коллегам
#Swagger #OpenAPI #СистемныйАнализ
👍5😁2🔥1
Анализ, коты, цветы и Катя
В каких форматах может быть спецификация OpenAPI?
Видимо я мастер путать людей, и мне удалось не только запутать своих коллег, но и некоторых из вас.
Ответ JSON, YAML, XSD был ошибочно поставлен, как правильный. Хотя таким не является.
Конечно же XSD никак не связан с OpenAPI
Ответ JSON, YAML, XSD был ошибочно поставлен, как правильный. Хотя таким не является.
Конечно же XSD никак не связан с OpenAPI
👍7💯3
Была на лекции по архитектуре… городской архитектуре.
Слушала и понимала: у них всё как у нас.
Задача: реставрировать старое легаси, сохранив его изюминку. Но переосмыслить ещё и его применение! А сохранить нужно, потому что это дорогое сердцу, уникальное наследие.Если вы сейчас пустили слезу я вас понимаю.
Всё было хорошо продумано, спроектировано и с какого то этапа даже был бюджет. Что шло не так?
Упс, но не ожидали, что за много лет развития территории вокруг здания и особенности почв под ним будут собираться подземные воды. А именно в подвале планировали всю развязку коммуникаций, в том числе электрики.
Не было работяг, которые умеют работать по старым технологиям. Пришлось нанимать отдельную женщину-надсмотрщицу, которая следила, чтобы учились и соблюдали. Про нее до сих пор сняться кошмары рабочим.
Архитекторы очень хотели сделать у сада реку.. и снова не вышло. Оказалось, подземных вод мало, а они рассчитывать такое не умели.
Прибежали и ландшафтные дизайнеры, и оказалось, что архитекторы запланировали высадить на территории инвазивные виды. Потому что красиво. И символично. Что то это напоминает?
Да и потребности у современных помещений другие: по энергоэффективности, освещению и прочему. И вместе со старым фундаментом легаси оно плохо уживается.
Чтобы сделать реставрацию, на самом деле пришлось здание практически очистить от всего, что было. Остался в прямом смысле скелет, который укрепили разными способами, которые пришлось изобретать на колене растягивая бюджет и срок.
Зато сегодня в Самаре есть потрясающий филиал Третьяковки на месте старого советского здания в стиле Модернизм. И это точно того стоило.
Стоит ли сегодня то же самое делать с программами? Наверное, нет. Но кто знает, может лет через 50 тоже будут музеи "сохранения культурного наследия", объектами которого будут ИТ программы.
#легаси #архитектура #модернизм #выходнойконтент
Слушала и понимала: у них всё как у нас.
Задача: реставрировать старое легаси, сохранив его изюминку. Но переосмыслить ещё и его применение! А сохранить нужно, потому что это дорогое сердцу, уникальное наследие.
Всё было хорошо продумано, спроектировано и с какого то этапа даже был бюджет. Что шло не так?
Упс, но не ожидали, что за много лет развития территории вокруг здания и особенности почв под ним будут собираться подземные воды. А именно в подвале планировали всю развязку коммуникаций, в том числе электрики.
Не было работяг, которые умеют работать по старым технологиям. Пришлось нанимать отдельную женщину-надсмотрщицу, которая следила, чтобы учились и соблюдали. Про нее до сих пор сняться кошмары рабочим.
Архитекторы очень хотели сделать у сада реку.. и снова не вышло. Оказалось, подземных вод мало, а они рассчитывать такое не умели.
Прибежали и ландшафтные дизайнеры, и оказалось, что архитекторы запланировали высадить на территории инвазивные виды. Потому что красиво. И символично. Что то это напоминает?
Да и потребности у современных помещений другие: по энергоэффективности, освещению и прочему. И вместе со старым фундаментом легаси оно плохо уживается.
Чтобы сделать реставрацию, на самом деле пришлось здание практически очистить от всего, что было. Остался в прямом смысле скелет, который укрепили разными способами, которые пришлось изобретать на колене растягивая бюджет и срок.
Зато сегодня в Самаре есть потрясающий филиал Третьяковки на месте старого советского здания в стиле Модернизм. И это точно того стоило.
Стоит ли сегодня то же самое делать с программами? Наверное, нет. Но кто знает, может лет через 50 тоже будут музеи "сохранения культурного наследия", объектами которого будут ИТ программы.
#легаси #архитектура #модернизм #выходнойконтент
🔥10❤2👍1
Для следующего поста давайте снова поговорим про ИИ.
Пользуетесь ли вы ИИ в работе или жизни?
Пользуетесь ли вы ИИ в работе или жизни?
Anonymous Poll
46%
Да, всегда
50%
Иногда
4%
Нет, не нужно
0%
Нет, были неудачные опыты
Сталкивались ли вы со сложностями получения нужного ответа от ИИ?
Anonymous Poll
12%
Да, вечно отдает ерунду
78%
Да, но чаще всего умею это исправлять
10%
Нет
Используете ли вы готовые промты
Anonymous Poll
12%
Да, есть база из своих удачных
6%
Да, собрал крутую базу\подглядываю в интернете
16%
Иногда, когда не получается самому
45%
Нет, нет необходимости
20%
Все сам, все сам
Учились ли вы специально работать с промтами?
Anonymous Poll
12%
Да, на курсах, книгах
6%
Да, сам методом проб и ошибок
46%
Нет, получалось интуитивно
36%
Нет, каждый раз делаю по свойму
Как вы относитесь к промт-инжинирингу в целом?
Anonymous Poll
22%
Это важный навык
33%
Полезно, но не отдельная профессия
29%
Переоценено, обычное умение объяснять задачу
16%
Хайп без причины