Сейчас Habr заставляет при этом бесконечно разгадывать капчу, я "сломался" после четвертой успешно разгаданной подряд. А для комментариев капчи нет) Привет, Habr!
Всё правильно, при импортозамещении авто покупателя лучше сразу начать приучать самостоятельно починять своё новое отечественное ведро. Поскольку вендор и интегратор свои бабки уже получили, и негоже им свои руки марать, время тратить</irony>
Я лично не вижу попыток развивать вокруг своих продуктов профессиональное комьюнити и публично делиться опытом решения проблем / знаниями. YDB и ClickHouse не в счёт, они молодцы. Остальные просто стригут купоны
аргументация на уровне луддитов, сопротивлявшихся механизации труда
каждый использует инструмент по своему разумению, кто-то во благо, а кто-то нет... но тут уж и преподавателю, монотонно начитывающему предмет, не чем помочь
Почему вы решили, что именно "... действия ЦБ приводят к ухудшения положения в экономике?" С чего вы взяли, что ВДЛ страны делится / согласует свои планы с ЦБ? Много вопросов - если сможете ответить на них, станет понятно почему такие прогнозы
Россия и так на протяжении многих лет в топе стран по золотовалютным резервам центральных банков, только не видно чтобы это как то помогало экономике.
Исходя из своего опыта, полагаться только на «на контекст, сформированный по топу полученных векторов» — очень наивный подход, теряется уйма важных деталей. Стоит сразу смотреть в сторону решений вроде GraphRAG, и аннотации чанков дополнительными метаданными, теми же NER к примеру.
Кто-то встречал удобный в использовании инструмент ведения кабельного журнала в электронном виде? Последнее с чем сталкивался сам - RackTables (стойки, юниты, порты), но не сказать, что прям сильно удобно
Взгляните на статью о SCIN и соответствующий дата-сет от Google на GitHub. Интересен как общий подход к формированию датасета, так и с точки расширения функциональности вашего мобильного приложения
До последнего был уверен, что статья — стёб в духе «Вредных советов» Григория Остера, сплошь перлы – нарочно не придумаешь))…
«Когда админы работают, как на конвейере», а количество «инженерных систем в районе тысячи» как раз спихнуть на них ещё одну — проще всего.
«Не смешно» — это глубина проработки проблемы… «Корневая причина: Неработоспособность БД. Накопление очередей SQL запросов»… Серьёзно?! Разработка / вендор — ни чем помочь не могут, DBA возможностей не видит.
«Потушили» проблему, «залив» её новым железом.. — идеальная модель решения проблем)
Попробую перефразировать данный опус. Менеджер проекта обо#%@лся, крайним остался отдел эксплуатации среды виртуализации. Из-за задействования резервных ресурсов, бедолаги теперь вынуждены решать не только проблемы горе-менеджера, но и «снежный ком» проблем от систем, уже находившихся в эксплуатации, ведь не зря же существовал резерв ресурсов!?
Но горе-менеджер не унывает, ведь есть Service Desk! Главное верно изложить контекст проблемы: { “корневая причина”: “неработоспособность БД”, “организационный фактор”: “кто угодно, кроме Я”, “зона ответственности”: “отдел эксплуатации виртуальной среды” }
Остаётся только «дёргать за нужные веревочки» для повышения приоритета выполнения «операции перезагрузки Postgre», чтобы снизить MTTR от простоя новодела.
Главное — грамотное разграничение ответственности между сотрудниками. Менеджер проектов не парится за реализацию обходных решений и развёртывание, мнение админа «за организационную составляющую» никого не интересует (снижаются затраты на футбол).
Такая модель управления хорошо подходит в ситуациях, когда некогда думать, сроки горят, и ничего нет.
P.S. последнюю фразу полностью позаимствовал из статьи, надеюсь автор не обидится.
В наиболее примитивных случаях построение "цифрового ядра" основывается на понимании бизнес-целей и декомпозиции KPI. И только спустя годы выясняется, что компания профукала по настоящему золотую жилу, когда решила не тратить ресурсы на сбор и накопление на первый взгляд "бессмысленной информации".
Статья - пустышка, про практику Data driven в ней ни слова
Как будто бы уже пора переходить с ZooKeeper на Raft, нет?
Сейчас Habr заставляет при этом бесконечно разгадывать капчу, я "сломался" после четвертой успешно разгаданной подряд. А для комментариев капчи нет) Привет, Habr!
Всё правильно, при импортозамещении авто покупателя лучше сразу начать приучать самостоятельно починять своё новое отечественное ведро. Поскольку вендор и интегратор свои бабки уже получили, и негоже им свои руки марать, время тратить</irony>
Я лично не вижу попыток развивать вокруг своих продуктов профессиональное комьюнити и публично делиться опытом решения проблем / знаниями. YDB и ClickHouse не в счёт, они молодцы. Остальные просто стригут купоны
Коротко, лаконично, всё по делу. Здесь сложно добавить что-то ещё
В 2025? Ту, на которой можно `vibe no-кодить` с помощью популярных GPT-ассистентов))
А в 2026 — поддерживающую MCP и AI-агентов...
аргументация на уровне луддитов, сопротивлявшихся механизации труда
каждый использует инструмент по своему разумению, кто-то во благо, а кто-то нет... но тут уж и преподавателю, монотонно начитывающему предмет, не чем помочь
Почему вы решили, что именно "... действия ЦБ приводят к ухудшения положения в экономике?" С чего вы взяли, что ВДЛ страны делится / согласует свои планы с ЦБ? Много вопросов - если сможете ответить на них, станет понятно почему такие прогнозы
Россия и так на протяжении многих лет в топе стран по золотовалютным резервам центральных банков, только не видно чтобы это как то помогало экономике.
Исходя из своего опыта, полагаться только на «на контекст, сформированный по топу полученных векторов» — очень наивный подход, теряется уйма важных деталей. Стоит сразу смотреть в сторону решений вроде GraphRAG, и аннотации чанков дополнительными метаданными, теми же NER к примеру.
Кто-то встречал удобный в использовании инструмент ведения кабельного журнала в электронном виде? Последнее с чем сталкивался сам - RackTables (стойки, юниты, порты), но не сказать, что прям сильно удобно
Снёс от греха подальше. А есть такое же, но про Firefox / Chrome?
Странно, что не упомянута Natasha
Взгляните на статью о SCIN и соответствующий дата-сет от Google на GitHub. Интересен как общий подход к формированию датасета, так и с точки расширения функциональности вашего мобильного приложения
Вместо
fuzzywuzzyуже пора использовать RapidFuzz наверно)Спасибо, интересное решение, надо попробовать
GEOMETRY например)
РедОС сертифицированная, или обычная? Полагаю с сертифицированной версией нюансов на порядок больше, любопытно почитать о подобном опыте
ORM справляется с чтением / записью в колонки с json-native и прочих СУБД-специфичных типов данных, или из коробки только текст, числа и булево?
До последнего был уверен, что статья — стёб в духе «Вредных советов» Григория Остера, сплошь перлы – нарочно не придумаешь))…
«Когда админы работают, как на конвейере», а количество «инженерных систем в районе тысячи» как раз спихнуть на них ещё одну — проще всего.
«Не смешно» — это глубина проработки проблемы… «Корневая причина: Неработоспособность БД. Накопление очередей SQL запросов»… Серьёзно?! Разработка / вендор — ни чем помочь не могут, DBA возможностей не видит.
«Потушили» проблему, «залив» её новым железом.. — идеальная модель решения проблем)
Попробую перефразировать данный опус. Менеджер проекта обо#%@лся, крайним остался отдел эксплуатации среды виртуализации. Из-за задействования резервных ресурсов, бедолаги теперь вынуждены решать не только проблемы горе-менеджера, но и «снежный ком» проблем от систем, уже находившихся в эксплуатации, ведь не зря же существовал резерв ресурсов!?
Но горе-менеджер не унывает, ведь есть Service Desk! Главное верно изложить контекст проблемы: { “корневая причина”: “неработоспособность БД”, “организационный фактор”: “кто угодно, кроме Я”, “зона ответственности”: “отдел эксплуатации виртуальной среды” }
Остаётся только «дёргать за нужные веревочки» для повышения приоритета выполнения «операции перезагрузки Postgre», чтобы снизить MTTR от простоя новодела.
Главное — грамотное разграничение ответственности между сотрудниками. Менеджер проектов не парится за реализацию обходных решений и развёртывание, мнение админа «за организационную составляющую» никого не интересует (снижаются затраты на футбол).
Такая модель управления хорошо подходит в ситуациях, когда некогда думать, сроки горят, и ничего нет.
P.S. последнюю фразу полностью позаимствовал из статьи, надеюсь автор не обидится.
В наиболее примитивных случаях построение "цифрового ядра" основывается на понимании бизнес-целей и декомпозиции KPI. И только спустя годы выясняется, что компания профукала по настоящему золотую жилу, когда решила не тратить ресурсы на сбор и накопление на первый взгляд "бессмысленной информации".
Статья - пустышка, про практику Data driven в ней ни слова