TGViewer
Channel Public Channel
Yet Another Burakov

Yet Another Burakov

@another_sa

Анализ, архитектура, менеджмент в IT

Сообщество аналитиков: https://tech-analyst.ai

Вопросы сюда: @and_burakov
Subscribers
6.55K
Photos
52
Videos
0
Links
363

Showing posts older than #219 · Back to latest

Older Posts 20 shown
Post #218 4.24K
#API
Год назад вышло RFC с предложением стандартизировать описание ошибок в HTTP, чтобы дополнить status codes.

Интересна мотивация:

HTTP status codes cannot always convey enough information about errors to be helpful. While humans using web browsers can often understand an HTML response content, non-human consumers of HTTP APIs have difficulty doing so.

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

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

Вот так это должно выглядеть:

HTTP/1.1 403 Forbidden
Content-Type: application/problem+json
Content-Language: en

{
"type": "https://example.com/probs/out-of-credit",
"title": "You do not have enough credit.",
"detail": "Your current balance is 30, but that costs 50.",
"instance": "/account/12345/msgs/abc",
"balance": 30,
"accounts": ["/account/12345",
"/account/67890"]
}


HTTP/1.1 422 Unprocessable Content
Content-Type: application/problem+json
Content-Language: en

{
"type": "https://example.net/validation-error",
"title": "Your request is not valid.",
"errors": [
{
"detail": "must be a positive integer",
"pointer": "#/age"
},
{
"detail": "must be 'green', 'red' or 'blue'",
"pointer": "#/profile/color"
}
]
}
  • 👍 15
  • 🤡 1
Post #217 3.08K

Forwarded from Максим Дорофеев: Прокрастинация и джедайские техники

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


Аргументация к этой мысли в этой статье.
  • 👍 19
  • 😁 4
  • 🔥 1
Post #216 3.25K

Forwarded from ЮMoney Tech

Код или кот? 😐

Приглашаем на митап ЮMoney «Код аналитика»


На митапе для системных аналитиков и архитекторов IT-решений выступят спикеры из ЮMoney и NextWay. Эксперты поделятся опытом создания и проектирования решений для своих продуктов и ответят на вопросы слушателей.

Темы докладов ⤵️

🟣Docs As Code: настраиваем инструменты под себя.
🟣Моделирование архитектуры на графе.
🟣Как системному аналитику (не) выбрать технологию интеграции.

Ждём вас 19 июня в 19:00 (мск) — приходите в наш офис в Петербурге или подключайтесь онлайн. Для этого нужно зарегистрироваться.

Все подробности — на сайте митапа ❤️
  • 👍 3
  • 🔥 2
Post #215 2.93K
В среду буду снова набрасывать на тему Аналитик vs Интеграция на митапе в Петербурге.

Приходите похоливарить и чаек попить.
  • 👍 8
Post #214 3.62K
#манагерское
Еще одна классная метафора на тему KPI

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

Что общего в этих трагедиях? Страх наказания

Адекватная цель “посадить самолёт безопасно” подменяется ложной “избежать наказания за заход на второй круг”


Бесконечно люблю KPI:
• с точки зрения премирования
• с точки зрения системы
• а вот тут через теорию ограничений любят

Хорошо, что не самолеты строим.
Telegram Anna Sea IT Штормовыми вечерами на яхте делать нечего, поэтому мы смотрели разборы авиакатастроф на внутренних рейсах Катастрофа #1 - при посадке экипаж проигнорировал указания диспетчера и не выполнил заход на второй круг. Потому, что за второй круг при посадке в хорошую…
  • 👍 15
  • 🤡 1
Post #213 3.84K
В этом году активно вещаю, почему аналитики не могут просто взять и выбрать способ интеграции. Один из ключевых пойнтов - нет знаний и опыта в вопросах инфры и архитектуры.

На выхах 15-16го проводим последний перед летними каникулами тренинг System Design. Основы проектирования архитектуры систем. Будем познавать балансировку, кеширование, CDN и прочие способы масштабирования.

А еще поговорим о способах интеграции, выборе хранилища и влиянии бизнес-метрик на архитектуру. Все через практику, как обычно.

Тренинг ведет Даша Колесова - участница моего рейтинга топ-1 по наглядности подачи технических материалов.
  • 👍 11
  • 🤡 5
  • 🔥 2
Post #212 4.37K
Котики и работа с web-трафиком

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

Вот тут не самая свежая, но все еще актуальная статья про работу с HTTP-трафиком на примере простенькой соцсети

◽️Простейшая оценка производительности
◽️Что происходит между клиентом и сервером на сетевом уровне
◽️Как можно балансировать трафик
◽️Влияние географии

#интеграция
  • ❤ 26
  • 🤝 4
  • 👍 2
Post #211 4.4K
Я смотрю, среди около-аналитических конференций продолжает появляться новое и интересное.

Наташа Семенова организует первый Smart Speaker Conf - живая конфа для лидов и экспертов из айтишечки, где будут говорить не об архитектуре и требованиях, а о мышлении, мета-навыках, и есть ли жизнь после работы.

Вот такие темы будут:
▪️Лидерство в IT
▪️Кросс-ролевые софт-скиллы
▪️Профессиональная самореализация
▪️Работа и карьера в разрезе полноты жизни
▪️Выход на новый уровень мышления
▪️Использование проф. инструментов в жизни

Сам не попаду из-за пересечения с кодфестом, но если будете в Петербурге, заходите:

🔗 Регаться тут
📆 26 мая, начало в 09:00
📍 Санкт-Петербург, Невский проспект, д.54
  • ❤ 8
  • 🤔 2
  • 👍 1
Post #209 3.96K
#подслушано

Хорошо по процессу работать - не надо париться за сроки и результаты, просто сидишь и задачи клепаешь.
  • 🤔 13
  • 💯 9
  • 🤡 7
  • 👍 4
  • 🌚 3
  • 😢 2
  • 🥱 1
Post #208 6.22K
А сегодня реально важный контент от автора предыдущей статьи - разбор работы TLS, где он последовательно выдает всю необходимую базу:

• Способы атак, что и зачем защищаем

• Синхронное и асинхронное шифрование, ключи, подписи

• Обмен ключами, протокол Диффи-Хелмана

• Сертификаты и центры сертификации CA

Наглядно и со схемами. Кто метит в архитекторы или техлиды - читать обязательно.

Есть хардкорное продолжение, где рассматривает процесс на уровне сообщений со схемами и примерами кода.

#интеграция
  • 👍 11
  • ❤ 5
  • ⚡ 1
Post #207 3.13K
Вспомнил, что яжепродакт, и завел канал для всякого продуктового. Будут собирать интересные ссылочки, рассуждать про финтех, около-образование, экспериментировать с иишечкой. Все как здесь 4 года назад.

Веллкам, если интересно: https://t.me/fake_product
  • 👍 7
  • 👎 5
  • 🔥 2
Post #206 3.75K
Хардкорный разбор работы протокола HTTP/2 на уровне обмена сообщениями фреймами.
Написано классно и интересно. Но зачем вам это, я не знаю
  • ❤ 16
Post #205 3.05K

Forwarded from CodeFest'16 | 30–31 мая 2026

🧪 Секция System analysis

🔹 Олеся Пахомова расскажет об архитекторе решений: что это, чем отличается от других видов архитектур и причём здесь бизнес-анализ.

🔹 Андрей Шапиро поделится авторским методом схематизации процесса и пользовательского опыта.

🔹 Кирилл Кашин и Сергей Хованов продемонстрируют, как можно перепроектировать системы с помощью ТРИЗ и извлекать максимум из ограниченных ресурсов.

🔹 С Андреем Бураковым обсудим, как требования и ограничения влияют на выбор технологии интеграции.

🔹 С Анной Вичуговой поговорим про инженерию данных и важность для системных аналитиков.

🔹 Роман Селезнёв разложит по полочкам тему выбора средств визуализации информации и почему это важно при разработке информационных систем.

🔹 С Викторией Лузиной обсудим проблему некорректной документации, роли технического писателя и как выглядит документация, за которую не стыдно.

Вся программа 👉 https://14.codefest.ru/program

#спикеры_CodeFest14
  • ❤ 7
  • 👍 4
Post #204 2.91K
Через неделю еду в Сибирь релизить и молиться.

И вы заходите - там секция по анализу вернулась.
Post #203 4.12K
Designing High-Performance APIs - с одной стороны поверхностная и капитанская статья, с другой - полезные вопросы на подумать при проектировании API. Можно пробежаться и покопать незнакомые темы.

#API
DZone Designing High-Performance APIs Learn API design principles for optimal performance and scalability. Create high-performance APIs for great user experiences and workload management.
  • 👍 7
Post #202 3.62K
Реквием по интеграции

У меня в около-образовании тоже своя история. В 2020 году мы запустили в ComPractice курс по самым основам интеграции систем, тогда он назывался “Проектирование Web-сервисов”. На сколько помню, это был первый открытый курс по интеграции для аналитиков. А для меня это был первый опыт разработки и проведения коммерческого обучения, до это только внутри компании делал что-то.

Тут большое спасибо Ирине за то, что втянула в эту тему. Не знаю, связался бы я с обучением без того предложения.
И отдельное спасибо Ане за то, что терпит меня все эти годы))

За четыре года курс пережил 6 сезонов, обновился примерно на 50%, впитал в себя немного архитектуры и продвинутых тем. Теперь это полноценное погружение в тему на middle+ уровне.

Одна беда - сил и времени проводить его больше нет. Поэтому в начале лета провожу последний поток курса, больше в таком формате проводить не буду. Старт 30 мая, описание тут.

Главные особенности:

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

◽️“Иммерсивное обучение” (участник придумал название) - мы встречаемся с проблемой, и вместе ищем решение. “Повторяйте за мной” будет минимально.

◽️Правильных решений не существует, мы учимся думать и создавать подходящие.

Что дальше будем делать не знаю, но точно не хочу переходить в формат видосики-задания.

P.S. Если у тебя, дорогой читатель, есть желание попробовать себя в роли автора и ведущего курса в теме интеграции или проектирования - дай знать в комментах, нам будет о чем поговорить ;)
  • 👍 10
  • ❤ 5
  • 👌 1
Post #201 3.58K
Околообразование для аналитиков

Интересно наблюдать за развитием инфобиза в аналитической тусе. Как это было для меня.

2012-2019. Тишь да Вигерс
Из открытого обучения есть базовый курс ШСА и 2-3 коротких тренинга, плюс несколько центров корп обучения при крупных интеграторах. В основном все фокусируются на базовых техниках работы с требованиями: ФТ, НФТ, Use Cases и вот это все.

2020-2021. Интеграция расправляет плечи
Стартуют первые курсы по интеграции систем для аналитиков у ШСА и Com-Practice. Фокус смещается на “технику”, в основном на HTTP-based сервисы и SOAP, народ задорно обсуждает что такое REST, и как его правильно готовить.

2021. Вторжение титанов
На волне роста онлайн-образования в тему SA/BA заходят гиганты эдтеха в духе БрикФактори и им подобных. Многие закидывают их камнями и помидорами, ибо качество вызывает вопросы.

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

Хозяйке на заметку: сегодня пост в канале на ~10к подписчиков стоит 10-15к рублей. По моим наблюдениям канал может приносить 50-200к в месяц в зависимости от сезона. И не нужно заморачиваться с курсом.
А с открытыми LLM это реально автоматизировать.

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

За это время качество локального бутикового (Денис, спасибо за термин, каждый раз ржу) образования сблизилось с большими игроками: брикфактори подтянули качество, а в андергрунде появились курсы по архитектуре от аналитиков с 3-5 летним стажем.

2023-2024. Пост-пост, мета-мета
Курсы плодятся, запускать легко, но нужно продавать - много конкурентов.

Появляются курсы вида “как пройти собеседование на SA”, “как найти работу аналитиком”, “как построить карьеру в IT” и т.п.
Подход мегаразумный - продать техническое обучение куда сложнее, чем продать буст карьеры. Участники тратят меньше времени на обучение, а результат намного понятнее и проще измерять. Тем более брикфактори и другие стабильно поставляют клиентов - специалистов с завышенными ожиданиями.

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

Среди каналов случился первый эксперимент с платной подпиской. Контент классный, но не особо летит. Возможно, народ привык к халявному контенту.

2024 - …
Вангую тренд на мета-скиллы и обучение-без-курсов будет развиваться, а начинающим авторам будет проще запрыгнуть в них, чем в стандартные технические курсы.


P.S. Хронология или причинно-следственные связи в вашей версии реальности могут отличаться, поделитесь же ими.
  • 😁 28
  • 👍 11
  • 🔥 6
Post #200 3.11K

Forwarded from Системный сдвиг

UML умер, но никто этого не заметил?

Один знакомый сейчас идет работу в Европе. Он продакт, CPO. Вы, возможно, слышали, а может и сами сталкивались с поисками работы вне России — внезапно сейчас в ИТ довольно сложно. Очень много соискателей, очень много интервью проходит впустую.

Вот и он так же: ходит на множество собеседований. И вот на одном интервью заходит речь про UML. Соискатель напрягается, и аккуратно выясняет — а не российские ли корни у компании? Оказывается, да, основатели из России, программисты, учились в российских институтах. Потому что никто, кроме российских программистов, UML при разработке продуктов давно уже не использует 😂
(Ну, по крайней мере, на верхнем уровне проработки. Такой опыт у моего знакомого.)

Как, в его опыте, обычно устроено управление продуктовыми требованиями:
🔸 Job Stories для формулировки продуктовой проблемы (кажется, фактически этот формат победил User Stories во многих проектах).
🔸 сценарии работы пользователя (не в виде юскейсов, а менее формально)
🔸 критерии приемки в виде BDD-сценариев.

Возможно, UML появляется где-то внутри в команде разработки — в основном в виде диаграмм классов, последовательности/активности и иногда состояний. Он этого не знает, это внутренний язык общения разработчиков друг с другом.

Слухи о смерти UML циркулируют ещё с 2010-х годов. Из последнего — много обсуждений вызвала статья Эрнесто Гарбарино 'Has UML Died Without Anyone Noticing?'.
Впрочем, встречаются и мнения, что "UML не мог умереть, потому что он никогда не был живым".

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

1. UML — это формальный графический язык. Элементы в нём зафиксированы в стандарте. Но бизнес-заказчикам такой язык не нужен! Им нужны диаграммы, которые показывают то, что им нужно увидеть здесь и сейчас. И если на диаграмму нужно добавить описание персон — нужно его добавить. Возражение "в UML это не предусмотрено" не принимается.

2. А проиcходит так потому, что на организационном уровне разработка программных систем больше не является инженерной практикой. Где-то в глубине — да, разработчики всё ещё являются инженерами (а ещё более ими являются инженеры по надежности, которые даже иногда используют тервер и математическое моделирование!), но на уровне бизнеса — больше нет.

Принцип fail fast, fail often (and fail cheap) убил практику инженерии требований, бизнес-анализа и проектирования. UML просто умер вместе с ними. Программирование фокусируется на том, чтобы быстро накодить что-то, а потом быстро переделать. Инженерам нужен язык для общения друг с другом, для проектирования и анализа моделей, а кодерам — нет, им нужны фреймворки, библиотеки, low-code и copilot.

В прекрасном новом мире нет бизнес-анализа и детализированных моделей бизнес-процессов. Всё очень легковесно: DDD и Event Storming вместо сложных моделей, JTBD для интерфейсов, C4 для архитектуры.

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

А вы применяете UML? Насколько часто, и что именно из него?
  • 🔥 26
  • 🤔 15
  • 👎 12
  • ❤ 4
  • 😁 3
  • 👍 1
Post #199 4.69K
Чек-лист - отличная штука. Если сделал его сам

Когда обсуждают выбор типа хранилищ, брокеров, способа интеграции регулярно слышу вопрос: “А что лучше использовать для XXX?”

Рассказываешь об особенностях технологии, сильных и слабых сторонах, известных кейсах применения… а в ответ: “Нет, ты пальцем покажи: здесь нужно использовать FOO, а здесь BAR”. После короткого диалога собеседник просит какой-нибудь чек-лист, таблицу с критериями принятия решений или что-то подобное.

🤦‍♂️ Если вы узнали себя, то у меня плохие новости.

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

◽️Во-вторых, большая часть подобных материалов поверхностна, создана не на основе опыта автора, а является выжимкой из аналогичных источников.

◽️В-третьих, глубокие материалы с серьезным анализом могут оказаться как бесполезны, так и вредны для вас.

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

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

Тогда что делать?

1️⃣Погружаться в контекст вашей задачи. В большинстве случаев он шире зоны ответственности аналитика или разработчика. Например, я писал о проблемах выбора способа интеграции

2️⃣Изучать технологии по первоисточникам, а не обзорным статьям. Благо, сейчас проблем с оригинальной документацией нет

3️⃣Самостоятельно выявлять значимые критерии принятия решений и валидировать их с командой

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

Мораль проста: занимайтесь творческими задачами, которые пока недоступны моделькам. Всю рутину неизбежно сметут LLM, причем это уже не вопрос возможностей, а внедрения и безопасности.

❗️Работающий чек-лист - это тот, который вы сделали сами. На все остальное есть GPT.
  • ❤ 22
  • 👍 10
  • 🤡 1
Post #198 4.7K

Forwarded from Chief Philosophy Officer

Этапы взросления менеджера:
- Не догадывается, что существует чат без него, но где есть все его подчиненные.
- Расстраивается, что существует чат без него, но где есть все его подчиненные.
- Радуется, что наконец создали чат без него, но где есть все его подчиненные.
- Делаем вид, что не заметил, когда добавили в очередной новый чат.
  • 😁 67
  • 🐳 4
  • 👎 3
  • 🤮 3
  • ❤ 1
  • 💩 1
Older posts →
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →