Burmistrov - It и около

Подтверждайте навыки — их увидят работодатели

Сертификат симпатичный, каждый год обновлять, наверное смысл есть.

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

поможет ли в поиске работы? наверное нет, хотя если говорим про старт карьеры, там другие правила и любой плюс важен)

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

Искать не там, где предлагают

Популярность предложения создает обманчивое впечатление о его ценности.

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

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

Ориентироваться на популярное — это путь к покупке на рыночных условиях. Рынок сглаживает экстремумы и не оставляет пространства для чуда.

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

Модель заказывали?)

Я в Минске, скоро поеду на площадку прогнать выступление.
Если вы в Минске рассказывайте и показывайте классные места на вечер!

📢 Всем привет!
К сожалению (в силу обстоятельств) и жалобы одного "недружественного" человека, более нет русскоязычной версии сайта #PlantUML https://plantuml.com/ru/, поэтому оставляю Вам доку на русском.

Митап Т1 ЛАМПА: 1С в Екатеринбурге 👀

🔹 20 июня в 19:00 (по Екб)
🔘 Екатеринбург, Вайнера, 16 (площадка Домна)

— в этот день и по этому адресу собираемся обсудить разработку, архитектуру и применение ИИ в 1С. Если конкретнее — вот какая программа вас ждёт:

➡️ Документирование интеграций по OpenAPI (Swagger для 1С), Олег Каратаев, технический архитектор в Т1

Как удобно описывать API в 1С с помощью OpenAPI: что это такое, какие есть библиотеки (включая swagger-1c) и как применять на практике.

➡️ Опыт перехода на EDT+Git, Радик Гирфанов, разработчик 1С в Т1

Как перевели команду из 50+ разработчиков с хранилища 1С на EDT и Git: зачем это нужно, как проходил переход, с какими трудностями столкнулись и что в итоге получилось.

➡️ Использование LLM-сервисов в 1С, Сергей Харламов, руководитель группы разработки в Т1

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

Регистрируйтесь на митап на платформе pro.t1 и готовьте побольше вопросов нашим спикерам 😉

Профессионализм системного аналитика
Ключевой признак профессионализма системного аналитика – способность видеть и анализировать проблему в широком контексте.

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

💡Как выйти на новый уровень? Расширяйте границы анализа. Многие работают только с явными требованиями, но настоящая ценность системного анализа – в выявлении скрытых взаимосвязей и долгосрочных последствий.

❗️Памятка: Хороший системный аналитик всегда учитывает полный контекст задачи и ясно демонстрирует, как предлагаемое решение улучшает работу системы для всех заинтересованных сторон.

Obsidian stats 2025-06-02
На текущий момент моя личная база знаний выглядит так:
- 875 заметки (+21)
- 119 вложений (+2)
- 994 файл (+23)
- 1654 ссылки (+45)
- 102960 слов (+3181)
- 196.49 МБ (+3.16)
- 1264 Тэгов (+580)
- 1.89 Качество базы знаний (+0,006)
#Obsidian #БазаЗнаний

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

Когда я спрашиваю о том, почему люди не заводят детей, они отвечают, что это дорого и им нужно встать на ноги.

Вопрос этот беспокоит не только меня, ещё его задаёт государство и, получив такой же ответ, решает склонять к деторождению путём пособий, льгот и семейной ипотеки. Государство подходит к вопросу рационально, считая, что этот вопрос — исключительно экономический.

Однако вот, что нужно иметь в виду. Население само по себе обычно иррационально и почти всё его поведение экономически невыгодно.

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

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

Проблема в том, что машины, квартиры и туризм продают корпорации, а повышение демографии — государство.

У корпораций в руках «кортизольный кнут» и каждый, кто хоть в чем-то не соответствует некоему идеалу, будь то наличие машины либо своего жилья, испытывает смесь боли, стыда, отчаянья и зависти. А у государства в руках лишь бумага и ручка.

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

«Ты ‎лузер, ‎если‏ у тебя ‎нет‏ ‎детей!», — так должен думать каждый.

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

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

С праздником!)

Пагинация девять на двенадцать… 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 с пагинацией:

  "data": [],  // массив элементов
  "pagination": {
    "total_pages": 5,  // всего страниц
    "current_page": 2, // текущая страница
    "next_cursor": "abc123" // курсор для следующей страницы (если keyset/cursor)
  }
}

❓Когда какой метод выбирать?
➖Offset – если данные статичны и нужна простота.
➖Keyset/Cursor – если данные часто обновляются.
➖Combined – если API должно работать оптимально в разных сценариях.

🔴Какие ошибки чаще всего допускают?
1️⃣Не учитывают сортировку → дублирование данных.
2️⃣Не ограничивают limit → кто-то запросит миллион записей разом.
3️⃣Забывают про total_count → клиент не может построить нормальный UI.

🔗Полезные ссылки:
- Пагинация в Yandex Cloud
- Pagination with Relative Cursors (Shopify Engineering)

Вы спросите «Можно ли вообще обойтись без пагинации?» (да, если использовать WebSockets или реактивные подходы)

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

Таких каналов не мало и почему я вдруг выделил один конкретный?

Последние два поста, про токсика и наоборот про поддержку тех кто вот вот упадает попали мне в самое сердечко.

Я иногда думаю, что я токсик, но однажды на проекте появился мистер Х. Любой созвон превратился в душнение и вынос мозга. Аналитики, которых ставили к мистер Х. в пару по задаче рыдали, выгорали и хотели уволиться. Проблема была очевидна)

Как боролись?)
- запретили писать комментарии в конфлюенс в спеках, все вопросы на специальной отдельной странице
- перестали ставить ему в пару молодых, джунов, мидллов, людей со слабой психикой
- каждый раз когда мне удавалось его передушить я делился со всеми аналитиками и они были счастливы
- уволили

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

Поддерживайте коллег! Будьте людьми, спасибо проджекту в кармане, аж слеза навернулась от воспоминаний

Вот вы смеетесь про Яндекс и 72 собеседования на клингонском и езде на велосипеде без рук, а все не так! Передаю из первых уст.

Всем приемлемых требований!

Сколько на ваших? ⏱

Фан-факт: 22% британцев в возрасте от 18 до 24 лет с трудом определяют время по часам со стрелками.

Нефан-факт: когда требуется сформировать и выгрузить отчёт по действиям пользователя в системе (аутентификация, подключение к конференции, покупка любимой шоколадки), аналитики задаются вопросом: в каком формате лучше отразить время действия пользователя в системе?

Там может быть по-разному:
1️⃣ UTC и точка. Всё в одном формате, без заморочек. Хоть в Токио, хоть в Нью-Йорке — время одинаковое.

2️⃣ По часовому поясу того, кто смотрит отчёт. Удобно? Да. Но что, если участники из разных часовых поясов?

3️⃣ По часовому поясу пользователя, совершившего действие в системе. Максимально персонализировано, но представьте отчёт, где у каждого своё время.

❓ Поэтому открываем врата холивара: какой вариант всё-таки лучше?

#холивар@DiagnosisAnalyst