Another Tech Product – Telegram
Another Tech Product
6.37K subscribers
35 photos
1 file
289 links
Анализ, архитектура, менеджмент в IT

Вопросы сюда: @and_burakov
Download Telegram
Что-то давно у нас стримов не было. Завтра с Глебом Шипиловым, тимлидом команды процессинга данных в Exness, погрузимся в дивный мир потоковых данных.

Говорить будем про Kafka и Flink, а если точнее:

• Чем отличются Event-Driven и Request-Response взаимодействия, и как их реализовать

• Как устроена архитектура Apache Kafka

• Как загружать данные в Kafka и выгружать из нее — без программирования

• Как работать с потоковыми данными при помощи SQL

Все случится 2 июля в 18:30 мск

🔗 Встречаемся в прямом эфире — приходите пообщаться и вопросов накидать.
👍30🔥52
#архитектура
На митапе ЮMoney был огонь-доклад про моделирование архитектуры всего на графе.

Кратко идея:

Собрали доступную документацию (спеки, оргструктуру, процессы), распарсили ее в сущности и связи между ними: сервисы, продукты, команды - и положили все это в графовую базу.

Теперь при анализе зависимостей можно вбить запрос и на выходе получить граф связей между командами и сервисами. Например, какие команды могут затронуть доработки, если я решил запилить фичу МегаРеклама в продукте МногоДенег.

Выглядит как black fucking magic. Шли к этому 10 лет, но слона можно резать на части.
🔥352👍2
Други, помогите с небольшим опросом, плз

Как часто используете публичные LLM (ChatGPT, YandexGPT, GigaChat и т.п.) в работе?
Anonymous Poll
20%
Никогда
27%
Пару раз поигрались
12%
Раз в месяц
11%
Раз в неделю
17%
Несколько раз в неделю
13%
Ежедневно
#манагерское

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

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

Особенно опасно заливать людьми проблемы в новых командах. Ну и закон Брукса никто не отменял.
👍26💯5👏41
NextWayConf

Когда-нибудь я научусь сначала пиарить, а потом делать что-то, но не в этот раз.

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

Будет два стрима: доклады и воршкопы. Что из технического:

◽️Научимся расчитывать сайзинг data-платформы на примере Flink на воркшопе Дарьи Колесовой

◽️Познакомимся с техникой EventModeling для проектирования систем вместе с Анной Сретинской. Не путать с EventStorming

◽️Пощупаем ручками RabbitMQ и построим взаимодействия с его помощью под руководством Анны Вичуговой

◽️Роман Цирульников расскажет о базовых понятиях архитектуры сисем и предприятий, и чем это полезно для аналитика

◽️Виктор Семак поделиться опытом обеспечения Observability систем и полезными практическими рекомендациями

Программа максимально прикладная, никакой записи и доплаты за воркшопы нет - запрыгивайте, всех ждем.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥113
OWASP для LLM приложений. Список уязвимостей с интересными примерами атак.

Для меня некоторые оказались совсем неочевидными. Здравствуй, дивный новый мир.
👍7
Осторожно, реклама

Через неделю проводим практический тренинг System Design. Основы проектирования архитектуры систем. Тут должна быть красивая нативная подводка, но мне как-то лень. Поэтому несколько фактов.

Кому будет полезно:

◽️Вы готовитесь к секции System Design на собеседовании. Все чаще их используют не только для разрабов, но и для аналитиков.

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

◽️Вам просто интересна архитектура.

Самое ценное по версии участников:

◽️Инструменты масштабирования: балансировка, шардирование, кеширование

◽️Работа с хранилищами: выбор под задачу, RDBMS, NoSQL, DWH, индексы

◽️Спикер и подача материала: понятно, последовательно, незанудно, с юмором

◽️Общение со спикером в режиме открытого микрофона: можно обсудить интересующую тему, получить подробные ответы, разобрать кейсы из практики

История одного успеха
Участник предыдущего потока подался на архитектурный хакатон, вошел в тройку победителей, получил и принял оффер на архитектора в большой известный банк. Вину тренинга в описанных событиях не отрицает.
Конечно, заслуга человека, а не наша, но чем я хуже инфоцыган?

📆 Запрыгивайте, ждем 7-8 сентября в 10:00-14:00 (UTC +3)

🔗 Регаться тут
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15🤡5👍3
Использовать фреймворки нужно не для того, чтобы их использовать

Люблю рассказы в духе: “Возьмите фреймворк XXX для задачи NNN, и будет вам счастье”. Дальше обычно начинается холивар: “Мы попробовали, и получилась какая-то хрень”.

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

Берем RICE
Редко кому удается (вы существуете, кстати?) настроить функцию четырех переменных, дающую на выходе приоритеты, которые можно использовать для развития продукта. Все равно будем двигать с точки зрения “здравого смысла”.

Зато в процессе возникнут вопросы:

• Какие сегменты охватывает фича? Сколько там клиентов? Как они платят?

• Какой профит получим? Это оптимистично или пессимистично?

• Как оценивали? Есть данные, результаты исследований, или это чье-то мнение?

• Есть зависимости от других команд и отделов?

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

Или Use Cases
Как самостоятельный способ передачи требований - ужас ужасный.
Обычная реакция после прочтения: “Кулл стори, бро, но объясни нормально, что сделать нужно?”

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

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

#мышление
👍19🔥151😁1🤔1💯1
Еще про мышление

Обратил внимание, что наиболее эффективно работаю над сложными задачами, когда использую три механики:

Визуализация
Чтобы увидеть элементы системы и отношения между ними. Обычно нахожу неявные связи, о которых не подумал или не знал.

Текстовое описание
Важно описать продукт, систему или процесс так, чтобы читатель осилил текст и правильно понял его. Лаконично, содержательно и доступно для разных ролей. Позволяет проработать детали, выявить корнеры, покрутить разные point of view. Максимально больно в мозг.

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

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

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

#мышление
👍42💯103🔥2
Я тут продал душу вписался в историю с папками. Здесь собрали 20 каналов про системный анализ. Не знаю, зачем столько, но можете найти интересное.
😁21👍7👎42🔥2🤨1🤝1
Forwarded from Chief Philosophy Officer
Мало кто знает, но просить от сотрудника оценку задачи, которую ты ему поручил, нужно не чтобы оценить сроки, он все равно ошибется и все сроки просрет, тут поможет только статистика и sla. Дело не в этом. Просто наличие оценки - это отличная метрика того, что была произведена декомпозиция. А декомпозиция говорит о том, что над задачей уже размышляли, планировали, думали о результате. Поэтому просто узнать число недостаточно, придется самому вникнуть и понять, почему это число именно такое, а главное, самому стоит представлять результат задачи, а не фантазировать его на ходу, принимая работу.
👍306🤡2
Шикарный разбор реализации перевода средств между клиентами. Иллюстрация, чем мы занимаемся в этих наших финтехах.

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

#архитектура
🔥13
Кажется, что-то интересное намечается

https://mts-digital.ru/events/details?id=742631
🔥7😈6
Знакомый поделился прекрасным. Однажды он обнаружил сервис с методом:

GET /api/getClientInfo?clientId=123

Попробуйте угадать, что он делает:
1. Если клиент не существует
2. Если клиент существует

Дада, вы все правильно поняли:
1. Сервис создает клиента
2. Сервис открывает клиенту счет


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

А вы какие шедевры встречали в практике?
😁41🙈19😨8🌭3🤬1
Статья (нужен vpn) о ретраях и защите от дублирования транзакций из недр Airbnb. В том числе разбирают проблемы реализации идемпотентности, и почему это не просто ключик в запрос положить. В том числе, использование распределенных хранилищ.

Заодно вспомним историю Васи и его борьбе с идемпотентностью в Яндекс.Такси, тоже полезно
👍8🔥3