Forwarded from alkov про it 🔋 (Alexander Kovalev)
Возможно кто-то заметил, что мне нравится активное участие в мероприятиях. Но часто это ограничено только вопросами к спикерам. Хорошо, если больше одного дадут задать. Ну или если сам в роли спикера. 🙃
В этом плане «Ресурсный баттл» обещал полное погружение в процесс. Так и оказалось!😎
Собрались в офисе Т1, организовались в четыре команды и в течение четырех импровизированных «спринтов» бились с другими командами за ресурсы (специалистов) и закрывали ими задачи - четыре основных и дополнительные.
Постепенно разобрались в правилах и понеслось! Мы выбрали стратегию, оказавшуюся выигрышной - закрывали основные задачи и понемногу готовили несколько дополнительных. И копили «сюрпризы» для соперников😈
Время пролетело незаметно. Получилось очень интересно и уже не терпится посмотреть на обновленную версию «баттлов» - с учетом опыта этого тестового запуска🤓
В этом плане «Ресурсный баттл» обещал полное погружение в процесс. Так и оказалось!
Собрались в офисе Т1, организовались в четыре команды и в течение четырех импровизированных «спринтов» бились с другими командами за ресурсы (специалистов) и закрывали ими задачи - четыре основных и дополнительные.
Постепенно разобрались в правилах и понеслось! Мы выбрали стратегию, оказавшуюся выигрышной - закрывали основные задачи и понемногу готовили несколько дополнительных. И копили «сюрпризы» для соперников
Время пролетело незаметно. Получилось очень интересно и уже не терпится посмотреть на обновленную версию «баттлов» - с учетом опыта этого тестового запуска
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7👌3🤝1
Forwarded from слеза дельфина
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
Это я вчера ходила на Митап и познакомилась с классными людьми ☺️
Как минимум это:
🔵 Оля Пономарева, основатель школы Системный анализ
🔵 Николай Колесник, 🏦 в миру Айтишник обыкновенный
🔵 Владимир Бурмистров,💙 которого мне пришлось реанимировать из чс
🔵 Фулстек аналитик из Робо Финанс, Оксана
🔵 Галина Кореневская, 📱 мы знакомы, но пообщались еще
Были хорошие инсайты, некоторые моменты мне явно откликнулись, но был и такой, с которого у меня чутка подгорело 🔥 и да, это было про Альфу и что у нас любят BPMN
В целом мне понравился непринужденный вайб 👌
После того, как все спикеры наговорились, мы пошли в бародно название, там никто почти не пил
Посидели там час, но я уже была уставшая, поэтому вскоре мы поехали с Галей домой, мы соседи по району, и Галя любезно довезла меня до дома🩷
Итог: теперь хочется еще больше нетворкинга 😅
Как минимум это:
Были хорошие инсайты, некоторые моменты мне явно откликнулись, но был и такой, с которого у меня чутка подгорело 🔥
В целом мне понравился непринужденный вайб 👌
После того, как все спикеры наговорились, мы пошли в бар
Посидели там час, но я уже была уставшая, поэтому вскоре мы поехали с Галей домой, мы соседи по району, и Галя любезно довезла меня до дома🩷
Итог: теперь хочется еще больше нетворкинга 😅
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🥰5🔥2👍1
Forwarded from Диагноз: Аналитик (Катя)
Сколько на ваших? ⏱
Фан-факт: 22% британцев в возрасте от 18 до 24 лет с трудом определяют время по часам со стрелками.
Нефан-факт: когда требуется сформировать и выгрузить отчёт по действиям пользователя в системе (аутентификация, подключение к конференции, покупка любимой шоколадки), аналитики задаются вопросом: в каком формате лучше отразить время действия пользователя в системе?
Там может быть по-разному:
1️⃣ UTC и точка. Всё в одном формате, без заморочек. Хоть в Токио, хоть в Нью-Йорке — время одинаковое.
2️⃣ По часовому поясу того, кто смотрит отчёт. Удобно? Да. Но что, если участники из разных часовых поясов?
3️⃣ По часовому поясу пользователя, совершившего действие в системе. Максимально персонализировано, но представьте отчёт, где у каждого своё время.
❓ Поэтому открываем врата холивара: какой вариант всё-таки лучше?
#холивар@DiagnosisAnalyst
Фан-факт: 22% британцев в возрасте от 18 до 24 лет с трудом определяют время по часам со стрелками.
Нефан-факт: когда требуется сформировать и выгрузить отчёт по действиям пользователя в системе (аутентификация, подключение к конференции, покупка любимой шоколадки), аналитики задаются вопросом: в каком формате лучше отразить время действия пользователя в системе?
Там может быть по-разному:
#холивар@DiagnosisAnalyst
Please open Telegram to view this post
VIEW IN TELEGRAM
У меня в телеге есть папка с каналами около рабочими и я их рандомно почитываю. Сегодня читал Проджект в кармане, там довольно много полезного и интересного по управлению проектами, а так как все мы в жизни проджекты, а на работе очень смежная роль извлекаю не мало пользы.
Таких каналов не мало и почему я вдруг выделил один конкретный?
Последние два поста, про токсика и наоборот про поддержку тех кто вот вот упадает попали мне в самое сердечко.
Я иногда думаю, что я токсик, но однажды на проекте появился мистер Х. Любой созвон превратился в душнение и вынос мозга. Аналитики, которых ставили к мистер Х. в пару по задаче рыдали, выгорали и хотели уволиться. Проблема была очевидна)
Как боролись?)
- запретили писать комментарии в конфлюенс в спеках, все вопросы на специальной отдельной странице
- перестали ставить ему в пару молодых, джунов, мидллов, людей со слабой психикой
- каждый раз когда мне удавалось его передушить я делился со всеми аналитиками и они были счастливы
- уволили
Ну а второй пост от продукта, как раз про то, как мы сплотились и не дали проекту посыпаться повторяя друг другу плечо.
Поддерживайте коллег! Будьте людьми, спасибо проджекту в кармане, аж слеза навернулась от воспоминаний
Таких каналов не мало и почему я вдруг выделил один конкретный?
Последние два поста, про токсика и наоборот про поддержку тех кто вот вот упадает попали мне в самое сердечко.
Я иногда думаю, что я токсик, но однажды на проекте появился мистер Х. Любой созвон превратился в душнение и вынос мозга. Аналитики, которых ставили к мистер Х. в пару по задаче рыдали, выгорали и хотели уволиться. Проблема была очевидна)
Как боролись?)
- запретили писать комментарии в конфлюенс в спеках, все вопросы на специальной отдельной странице
- перестали ставить ему в пару молодых, джунов, мидллов, людей со слабой психикой
- каждый раз когда мне удавалось его передушить я делился со всеми аналитиками и они были счастливы
- уволили
Ну а второй пост от продукта, как раз про то, как мы сплотились и не дали проекту посыпаться повторяя друг другу плечо.
Поддерживайте коллег! Будьте людьми, спасибо проджекту в кармане, аж слеза навернулась от воспоминаний
Telegram
Project Manager в кармане
Повесть, о развитии начинающего руководителя проектов. Сурово, непонятно, с умными словами и умными статьями.
By @panchkills
By @panchkills
Пагинация девять на двенадцать… 5 способов реализации, о которых должен знать системный аналитик
🧐Пагинация - самый частозабываемый элемент на практической части собеседования. Неправильная пагинация может привести к медленной загрузке данных, дублированию или потере записей. Разберём, какие подходы существуют и когда их применять.
Пагинация – важный механизм для работы с большими объемами данных в API. Она позволяет разбить выдачу на страницы, чтобы не перегружать систему и упростить работу с информацией. Существует несколько подходов к реализации пагинации, каждый из которых имеет свои преимущества и недостатки. Давайте рассмотрим основные:
🧮Offset pagination (Смещение)
Описание: Самый простой и понятный метод. Использует параметры offset (смещение от начала) и limit (количество элементов на странице).
Пример: GET /users?offset=20&limit=10 (вернет пользователей с 21-го по 30-го).
Плюсы: Простота реализации.
Минусы: Неэффективен при больших смещениях, может приводить к дублированию или пропуску данных при изменении набора.
📄Page-based pagination (Постраничная)
Описание: Данные разбиваются на страницы фиксированного размера. Используются параметры page (номер страницы) и size (размер страницы).
Пример: GET /products?page=3&size=25 (вернет 25 продуктов с третьей страницы).
Плюсы: Интуитивно понятна пользователю.
Минусы: Проблемы с производительностью при больших номерах страниц и изменениях в наборе данных.
🔑Keyset pagination (На основе ключей)
Описание: Использует уникальное поле (или комбинацию полей) в качестве ключа для определения начала следующей страницы.
Пример: GET /articles?after=article_id_123&limit=10 (вернет 10 статей после статьи с ID article_id_123).
Плюсы: Более эффективна, чем offset и page-based пагинация, особенно при часто изменяющихся данных. Избегает проблем с дублированием и пропуском.
Минусы: Более сложная реализация, требует наличия подходящего поля для ключа.
🖱️Cursor-based pagination (На основе курсора)
Описание: Использует "курсор" – непрозрачный токен, который указывает на конкретную точку в наборе данных. Может поддерживать как прямую, так и обратную навигацию.
Пример: GET /events?cursor=YXJ0aWNsZXMlM0Ez (вернет события, начиная с позиции, закодированной в курсоре).
Плюсы: Гибкая, позволяет эффективно перемещаться в обоих направлениях.
Минусы: Курсор может быть непрозрачным для клиента, усложняет отладку.
➕Combined pagination (Комбинированная)
Описание: Объединяет разные подходы для оптимизации извлечения данных в API. Например, для первой страницы использовать offset, а для последующих – keyset.
Плюсы: Позволяет достичь наилучшей производительности в конкретном сценарии.
Минусы: Сложность реализации и поддержки.
Пример структуры ответа API с пагинацией:
❓ Когда какой метод выбирать?
➖Offset – если данные статичны и нужна простота.
➖Keyset/Cursor – если данные часто обновляются.
➖Combined – если API должно работать оптимально в разных сценариях.
🔴 Какие ошибки чаще всего допускают?
1️⃣ Не учитывают сортировку → дублирование данных.
2️⃣ Не ограничивают limit → кто-то запросит миллион записей разом.
3️⃣ Забывают про total_count → клиент не может построить нормальный UI.
🔗Полезные ссылки:
- Пагинация в Yandex Cloud
- Pagination with Relative Cursors (Shopify Engineering)
Вы спросите «Можно ли вообще обойтись без пагинации?» (да, если использовать WebSockets или реактивные подходы )
🧐Пагинация - самый частозабываемый элемент на практической части собеседования. Неправильная пагинация может привести к медленной загрузке данных, дублированию или потере записей. Разберём, какие подходы существуют и когда их применять.
Пагинация – важный механизм для работы с большими объемами данных в API. Она позволяет разбить выдачу на страницы, чтобы не перегружать систему и упростить работу с информацией. Существует несколько подходов к реализации пагинации, каждый из которых имеет свои преимущества и недостатки. Давайте рассмотрим основные:
🧮Offset pagination (Смещение)
Описание: Самый простой и понятный метод. Использует параметры offset (смещение от начала) и limit (количество элементов на странице).
Пример: GET /users?offset=20&limit=10 (вернет пользователей с 21-го по 30-го).
Плюсы: Простота реализации.
Минусы: Неэффективен при больших смещениях, может приводить к дублированию или пропуску данных при изменении набора.
📄Page-based pagination (Постраничная)
Описание: Данные разбиваются на страницы фиксированного размера. Используются параметры page (номер страницы) и size (размер страницы).
Пример: GET /products?page=3&size=25 (вернет 25 продуктов с третьей страницы).
Плюсы: Интуитивно понятна пользователю.
Минусы: Проблемы с производительностью при больших номерах страниц и изменениях в наборе данных.
🔑Keyset pagination (На основе ключей)
Описание: Использует уникальное поле (или комбинацию полей) в качестве ключа для определения начала следующей страницы.
Пример: GET /articles?after=article_id_123&limit=10 (вернет 10 статей после статьи с ID article_id_123).
Плюсы: Более эффективна, чем offset и page-based пагинация, особенно при часто изменяющихся данных. Избегает проблем с дублированием и пропуском.
Минусы: Более сложная реализация, требует наличия подходящего поля для ключа.
🖱️Cursor-based pagination (На основе курсора)
Описание: Использует "курсор" – непрозрачный токен, который указывает на конкретную точку в наборе данных. Может поддерживать как прямую, так и обратную навигацию.
Пример: GET /events?cursor=YXJ0aWNsZXMlM0Ez (вернет события, начиная с позиции, закодированной в курсоре).
Плюсы: Гибкая, позволяет эффективно перемещаться в обоих направлениях.
Минусы: Курсор может быть непрозрачным для клиента, усложняет отладку.
➕Combined pagination (Комбинированная)
Описание: Объединяет разные подходы для оптимизации извлечения данных в API. Например, для первой страницы использовать offset, а для последующих – keyset.
Плюсы: Позволяет достичь наилучшей производительности в конкретном сценарии.
Минусы: Сложность реализации и поддержки.
Пример структуры ответа API с пагинацией:
"data": [], // массив элементов
"pagination": {
"total_pages": 5, // всего страниц
"current_page": 2, // текущая страница
"next_cursor": "abc123" // курсор для следующей страницы (если keyset/cursor)
}
}
➖Offset – если данные статичны и нужна простота.
➖Keyset/Cursor – если данные часто обновляются.
➖Combined – если API должно работать оптимально в разных сценариях.
🔗Полезные ссылки:
- Пагинация в Yandex Cloud
- Pagination with Relative Cursors (Shopify Engineering)
Вы спросите «Можно ли вообще обойтись без пагинации?» (
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥6👍2👏2