Все потоки

Ассоциация “Проектный Альянс” выпустила книгу “Управление проектами для заинтересованных сторон (стейкхолдеров)" (В.Воропаев, Я.Гельруд, О.Клименко), посвященную стейкхолдерам проекта и тому, как собирать управление сложными проектами вокруг интересов всех ключевых игроков, а не только команды PM.

Я прочитал новинку, и вот тезисно про книгу, ее плюсы и особенности.

Плюсы:

• Нацеленность на сложные крупнобюджетные проекты, вне зависимости от сферы (не столько привычные ИТ-проекты, но и “стройки века” и производственно-добывающие проекты). Сейчас комплексных материалов в этой сфере сильно не хватает, имхо, если знаете - напишите в комментах.

• Здоровая хардкорность. Да, тут не заскучаешь над авторскими эмоциями и отступлениями. Книга на 70% состоит из математического аппарата, формул, которых "гуманитариям не понять" (с), но которые прекрасно впишутся в excel и ИСУП и помогут проекту. Авторы именно считают, а не оценивают эффективность проектного управления.

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

• Несколько точек зрения, соответствующих разным стейкхолдерам: инвестора, заказчика, поставщика, регулирующих органов, коммерческой службы и, конечно, команды проекта. Каждому — свои цели, функции, компетенции и метрики. И еще отдельная карта связей.
  

  

• Из этого складывается основа (скорее ТЗ) для интегрированной информационной системы управления проектами, которая должна собрать вместе всё: архитектуру, логику взаимодействия сторон, планы финансов/поставок/налогов, функции по всем стадиям жизненного цикла.

• Есть практическая оптика для разных ролей: таблицы с ожиданиями, целями, ограничениями и инструментами по каждой стороне призваны помочь быстро собрать «карту интересов» под конкретный портфель/программу. Причем тут без формул...

И есть особенности.

• Монографический стиль. Среди авторов - доктор технических наук, и книга ни разу не лайтовый гайд, к которым многие из нас привыкли, а солидная академическая работа с формальными постановками и алгоритмами. Листается в целом быстро, но ожидает от читателя готовности к моделям и матанализу.

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

• Логика “сверху вниз”, от универсальной модели проектного управления к конкретным календарям, ресурсам и т.д. Если привыкли «от Jira к стратегии», то придётся развернуть взгляд.

Резюме.
Рекомендую книгу, в первую очередь, PMO, руководителям портфелей/программ, менеджерам крупнобюджетных проектов, интеграторам и консультантам, кто “варится” в многосубъектных проектах с конфликтующими интересами.

Если в профиле Max вписать «Телеграм» вместо имени, то такой аккаунт моментально отлетит в бан.

Хочу рассказать про Diffusion модели и одну проблему, которую решили в статье "Fast and Fluent Diffusion Language Models via Convolutional Decoding and Rejective Fine-tuning"

Представьте: вы пишете письмо в саппорт. Большое, с болью, как положено. А потом система берёт и начинает стирать из него слова. Сначала одно-два, потом половину. В итоге доходит до состояния «*** не работает *** вчера *** клиенты». Это называется forward-процесс. То есть сначала текст намеренно превращают в кашу.

Дальше reverse-процесс. Модель берёт этот обрубок и пытается догадаться, что же там было. Сначала простые слова (имена, даты). Потом технические термины. Потом связки. И вот у вас снова появляется более-менее внятное письмо. Это обучение через боль: чтобы в будущем модель могла достраивать даже то, чего не слышала.

Теперь внимание. В обычных генеративках текст растёт пословно, как будто вы диктуете. В диффузии всё наоборот: модель сразу пуляет целое «окно» текста, пытаясь угадать кучу слов одновременно. Звучит круто? Ага, только дальше начинается Long Decoding Window. Чем дальше от начала, тем больше мозг модели закипает. Итог: повторы, бессмысленные вставки, рандомный шум. Письмо начинается адекватно, а заканчивается как будто писал уставший стажёр.

Учёные посмотрели на этот и сказали: ладно, давайте хотя бы починим. Придумали Convolutional Decoding — это как если бы у стажёра попросили сначала сосредоточиться на ближних словах, а дальние воспринимать с осторожностью. Добавили Rejective Fine-Tuning — модель теперь штрафуют за «the the the» и «: : :». И добили EOS-fill: как только модель ставит точку, всё дальше просто забивается точками, и никто не позорится.

Рабочее решение:
— Convolutional Decoding — как если бы стажёру сказали: «сначала смотри на ближние слова, а дальние фильтруй».
— Rejective Fine-Tuning — за повторы и мусор прилетает штраф, и модель учится так не делать.
— EOS-fill — как только модель ставит точку, дальше всё затирается точками, и никто не позорится.

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

Привет, коллеги! 👋

Снова с вами рубрика "вечерний вайбкодер", и сегодня я принёс вам MyRepETL (Ссылка на github)— инструмент для ETL через MySQL репликацию.

Зачем это нужно?

Задача: у вас куча MySQL баз в микросервисах, нужно всё это затащить в Metabase для красивых отчетов.

Проблема в том, что:

• В каждой базе своя схема и структура

• Данные нужно объединить и нормализовать

• Metabase любит когда всё в одном месте

• Ручной экспорт/импорт — это боль

MyRepETL решает это: берёт данные из всех ваших баз, трансформирует их на лету и складывает в единую аналитическую базу для Metabase.

Что умеет MyRepETL

🚀 Основные фишки

Многопоточность из коробки

• Каждый источник работает в своём потоке

• Не блокирует друг друга

• Автоматически восстанавливается при сбоях

Гибкие трансформации

• Переименование таблиц и колонок

• Вычисляемые поля

• Фильтрация данных

• Кастомные Python-функции

JSON-конфигурация

• Всё настраивается через конфиг

Как использовать

Простая синхронизация

Самый базовый случай — просто скопировать данные из одной базы в другую:

{
  "sources": {
    "prod_db": {
      "host": "prod-mysql",
      "user": "repl_user", 
      "password": "repl_pass",
      "database": "production"
    }
  },
  "targets": {
    "backup_db": {
      "host": "backup-mysql",
      "user": "backup_user",
      "password": "backup_pass", 
      "database": "backup"
    }
  },
  "mapping": {
    "prod_db.users": {
      "source": "prod_db",
      "target": "backup_db",
      "source_table": "users",
      "target_table": "users"
    }
  }
}

С трансформациями

А теперь добавим магию — переименуем таблицу, добавим вычисляемые поля:

{
  "mapping": {
    "prod_db.customers": {
      "source": "prod_db",
      "target": "analytics_db",
      "source_table": "customers",
      "target_table": "users",
      "column_mapping": {
        "id": {"column": "user_id"},
        "name": {"column": "full_name"},
        "email": {"column": "email"},
        "birth_date": {"column": "age", "transform": "transform.calculate_age"},
        "phone": {"column": "formatted_phone", "transform": "transform.format_phone"},
        "created_at": {"column": "registration_date"},
        "source": {"column": "source_system", "value": "production"}
      }
    }
  }
}

Создайте файл transform.py с вашими функциями:

# transform.py
def calculate_age(birth_date, row_data, table):
    from datetime import datetime
    if not birth_date:
        return None
    birth = datetime.strptime(birth_date, '%Y-%m-%d')
    return (datetime.now() - birth).days // 365

def format_phone(phone, row_data, table):
    if not phone:
        return None
    # 79991234567 -> +7 (999) 123-45-67
    return f"+7 ({phone[1:4]}) {phone[4:7]}-{phone[7:9]}-{phone[9:11]}"

Запуск

# Установка с GitHub
pip install git+https://github.com/tumurzakov/myrepetl.git

# Или клонировать и установить локально
git clone https://github.com/tumurzakov/myrepetl.git
cd myrepetl
pip install -e .

# Запуск с конфигом
myrepetl run config.json

# Или через Docker
docker run -v ./config.json:/app/config.json myrepetl:latest

На этом всё, удачного кодинга! 👨‍💻

Проблема: Кадровый голод по специалистам, и при этом рекордные количества откликов на вакансии.

Причина: Плохая воронка наема специалиста (по аналогии с воронкой продаж, хорошие воронки способствуют продажам, а плохие нет), читай как - существующий процесс наема не помогает нанять специалиста, притом что специалистов на рынке более чем достаточно.

Общее решение: Изменить процесс наема так чтобы он помогал нанять специалиста для решения задач бизнеса.

Конкретные варианты решения:

1. Использовать зарекомендовавшие себя решения в других воронках\процессах получения чего-либо. Например сарафанное радио и нетворкинг, кумовщину и рефералки, при этом отказаться от существующих фильтров в пользу доверия на старте.

2. Устранить причину мешающую текущему процессу наема. Например сократить цепочку ЛПР-ов на пути соискателя до оптимума.

   (Сейчас это авто-скрипт, эйчар(или ряд эйчаров), собеседующий специалист(или ряд специалистов), представитель команды(или ряд представителей), опционально тут еще какие-то посредники, и вот тут уже можно выйти на работу и работать 😁. Причем на каждом этапе у лже-ЛПР-ов есть цель отсеять человека на основании формального фильтра. Тогда как лучшие работники обычно "неформалы" ибо они про работу работать как Стив Возняк, а не про продукт(себя) продавать как Стив Джобс. Очевидно что не каждая птица долетит даже до середины.. 😢)

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

   ЛПР - это тот кто принимает решение что считает лучшим на этот момент, а не тот который работает по прописанному скрипту (иначе это не ЛПР, а человек которого настоящий ЛПР назначил отрабатывать строго по скрипту 😜).

3. Устранить еще одну причину мешающую процессу наема. Например монолитность условий для прохождения собеседования. Можно искать пол жизни рыцаря на белом коне, до момента когда ни конь ни рыцарь уже будут не нужны, а можно взять то что само приползло и докрутить его под свои хотелки уже здесь и сейчас (то что само приползло должно быть согласно на докрутку, чтобы ни одно живое существо не пострадало в процессе наема 😁).

P.S. Все 3 варианта решения на самом деле про одно и то же, только заход с разных сторон: убрать не то что мешает обрабатывать заявки на чиле, в пол уха, левой пяткой, а убрать то что действительно мешает нанять сотрудника для решения конкретных задач. (Да стало много спама, ну и что? Разве то что много спама говорит о том что среди спама нет специалистов способных делать работу? Нет. Как раз таки в этом и заключается задача\работа нанимателя - нанять сотрудника в этих конкретных условиях. Ну да, придется поработать. Соискатель, наниматель и работодатель в одной лодке как ни крути, если кто-то не хочет грести, то далеко ли уплывет такая лодка?🛶)

Хорошего дня, наема и трудоустройства!

Обнял 🤗

Андрей Бурков — канадский специалист по машинному обучению из Квебека. Он руководил командами машинного обучения в Gartner и TalentNeuron, много лет возится с обработкой естественного языка, а прославился «The Hundred-Page Machine Learning Book», компактным учебником, который разошёлся по университетским курсам. В 2024—2025 годах он выпустил продолжение — «The Hundred-Page Language Models Book», где объясняет путь от простых счётных моделей и свёрточным нейросетям к трансформерам и БЯМ.

Впрочем, Бурков не просто повис где-то в сухой академии и написании учебников — он активно ведёт микроблог в X. Тон его микроблога и интервью легко узнать: он любит сбивать хайп и говорить про реальные ограничения моделей. Давайте хотя бы посмотрим, как озаглавлены его недавние беседы: «БЯМ — полезные лжецы» и «Вокруг БЯМ и агентов слишком много хайпа». По его мнению, большие языковые модели полезны, но склонны обещать больше, чем могут, а агенты без аккуратной инженерии разваливаются на форматировании, таксономиях и хрупких пайплайнах.

Аналогично скептичен и недавний твит Буркова. Андрей язвительно приводит следующее остроумное наблюдение: «БЯМ дообучили врать почти во всех ответах по написанию кода». Исследователь обратил внимание, что когда генерируется ответ, сначала модель торжественно выдаёт в тексте «я реализовал такую-то фичу», а сам код рождается позже — токен за токеном. По сути, БЯМ врёт, она ещё не написала никакого кода.

Однако в комментарии пришёл не менее маститый исследователь искусственного интеллекта Андрей Карпатый со своей фирменной иронией. Карпатый — один из одиннадцати основателей OpenAI, он возглавлял компьютерное зрение в Tesla и просто преподавал культовый курс CS231n.

Карпатый с юмором пишет: «Код был написан на слоях 22–30 и хранится в value-активациях, ты просто не можешь его прочитать. Мне кажется, тебе нужно извиниться перед БЯМ».

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

Я исследовал тему связности и связанности в построении кода и вот к чему пришел:

Не существует плохих\хороших\идеальных связности и связанности кода.

Мне кажется проблема и решение глубже - сколько людей столько и вариантов осмысления и построения "модели", столько вариантов же coupling & cohesion. У каждого что-то свое.

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

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

Ведь суть всего этого моделирования чтобы "на понятном" объяснить железу что и когда нужно сделать.

Т.е. решение кроется в здравом смысле - описываешь приложение плюс-минус понятными человеку структурами и нужная связность и связанность образуются сами собой как следствие.

Ну и когда я говорю ООП, это не значит что я буду писать абстракцию на каждый чих, влоть до Int, Long и т.п., нет, это значит что я начну с самых больших MyApp { UserClient, ServerClient, DeviceClient } и законтачу их между собой логикой приложения, а там дальше буду создавать абстракции по необходимости, если будет удобно и полезно что-то добавить и переиспользовать то я добавлю и переиспользую (вот кстати хороший критерий - моделировать сущность когда надо что-то передавать между главными абсракциями(надсистемами)).

ООП рулит :)

P.S. И не надо стремиться к идеалу, иначе тут можно скатиться в подмену задач, и начать делать не данное конкретное приложение, а предложенный кем-то идеал архитектуры.

Упрашивал ChatGPT нарисовать мне картинку с человеком. Ни в какую! Отказывается!

Сегодня с помощью ChatGPT генерировал картинку к Норм ЦРМ.

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

Попросил нарисовать фрилансера-одиночку за уютным домашним рабочим местом. И тут — хопа — отказ. Мол, это не соответствует нашим политикам.

Тогда попросил нарисовать человека, лица которого мы не видим. Просто фигуру. Снова отказ.

Затем попросил нарисовать антропоморфного кота. И тоже нельзя.

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

Если что, использую пятую версию с подпиской Plus.

——
Апдейт:

В комментариях пишут, что никаких ограничений нет.

Я попробовал сгенерировать в новом диалоге — и тоже ограничений не оказалось.

А вот внутри папки с проектом — не разрешает по какой-то причине.

Буду разбираться дальше.

Хеш-таблица с транзакциями на Go

Привет, продолжим удивительное. Смех смехом, но на Go стали доступны:

1. Хеш-таблица с транзакциями.

2. Структуры данных второго порядка.

И в отличие от C++, они еще не создают проблемы для Garbage Collector. Вы угадайте почему, а я немного процитирую:

------------------8<------------------

Все выглядит примерно так:

func NewMemDb() MemDb { /* ... */ }

type MemDb interface {
    Close() error
    StartTrn() Transaction
}

type Transaction interface {
    Close() error

    Get(key Ptrsz) (Ptrsz, bool)
    All(getKeys bool, getVals bool) (keys []Ptrsz, vals []Ptrsz)

    Set(key Ptrsz, val Ptrsz)
    Del(key Ptrsz)

    DependVal(key Ptrsz, val Ptrsz)
    DependDel(key Ptrsz)

    Commit() error
    Rollback() error
}

А именно:

• Объект MemDb создается с помощью функции NewMemDb().

• У MemDb есть функция Close() -- мы ОБЯЗАНЫ ее вызвать!!!

• Объект Transaction создается с помощью функции StartTrn().

• У Transaction тоже есть функция Close(). Да, мы ОБЯЗАНЫ!

• Transaction работает с данными через lib.Ptrsz. Точно также, как и mdb.BlobMap.

• Чтение данных выполняется посредством функций Get() и All(). Возвращаемые ими Ptrsz указывают на внутренние структуры MemDb. Они остаются валидными пока не завершена транзакция и не было вызовов Set() и Del(), инвалидирующих указатели.

• Изменение данных выполняется посредством функций Set() и Del(). MemDb копирует себе байты, на которые указывают key и val.

• Функции DependVal() и DependDel() устанавливают зависимости. Их проверяет Commit().

• Функции Commit() и Rollback() завершают транзакцию. Завершают, но не закрывают! Мы ОБЯЗАНЫ вызвать Close()!!

• Просто Close() означает Rollback().

------------------8<------------------

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

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

Кроме удовольствия от переноса многочисленных мыслей в текст, это безобразие меня еще и мотивирует этим заниматься и структурирует тот бардак, который живет у меня в голове. Потому что хочется спасать человечество, искать средство от смерти или думать о вечном, а вот решать проблему, почему очередной раз не выполняется элементарный apt-get update на машинке совсем не хочется. Сразу появляются мыслишки, что я трачу свое время на что-то бессмысленное и глупое и сажусь играть в "собери три предмета в ряд", потому что там в отличие от элементарных проблем с линуксом я не чувствую себя тупой, а при окончании ходов тебе всегда услужливо предлагают посмотреть рекламу за несколько дополнительных, чтобы ты снова чувствовала себя победителем.

По сложившейся традиции моих немногочисленных постов

Мое маленькое ДАНО ХОЧУ:

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

И да, я знаю, что вполне можно нарыть это в тырнетике или спросить у чата жипити, но я опрометчиво решила, что установить ее и посмотреть ручками будет проще, а когда это не получилось командой apt-get install postgres мое самолюбие было уже не остановить и срочно надо было доказать дурацкой базе данных, что я умнее (ну как иначе, то?). Вообще не то, чтобы я никогда не работала с постгрей, в моей голове достаточно смутные воспоминания, что скорее всего она пишет лог в /var/log/, а настройки у нее вообще живут только в двух файлах. Но точных имен я не помню, поэтому имеем, что имеем.

А вот теперь ДАНО:

У меня есть в запасе чистый диски на VirtualBox'e винды и дебиана, вот клон последней и было решено использовать для изысканий.

Шаг 1

Пробуем запустить apt-get install postgres, потому что что может быть проще... учитывая, что в ТЗ даже версия мне безразлична... просто вспомнить название файликов...

На что умный дебиан нам напоминает про безопасность и права (женщины боролись за права с 18 века!!!! а мне до сих пор не хватает =( )

Поэтому заходим под рутом, выполняем apt-get update - радуемся, когда тот успешно выполняется и идем искать нужный нам пакет apt search postgres.

В получившейся портянке ищем саму постгрю, потому что apt-search выдает результаты со словом postgres не только в названии пакета, но и в его описании. Лично мой взор привлекает пакет postgresql-all, где в описании обещают, что это metapackage depending on all PostgreSQL server packages. Его и пробуем поставить.

На удивление пакет (а точнее пакеты) ставится без ошибок, и в цмдушечке появляется заветный psql, который правда говорит, что подключаться ни к чему он не хочет, сокета на 5432 у него нет, а роль root вообще не существует.

Но по крайней мере у меня есть ответ на мой первый вопрос. Основные файлы конфигурации живут в /etc/postgres/ее версия/main/ и зовутся pg_hba.conf и posgresql.conf, где первый отвечает за разрешения подключения к этой самой бдушечки, а второй как раз хранит в себе все переменные ее настройки - в том числе и куда хранить лог "log_directory" которая по умолчанию закомментирована.

Удивительно и невероятное, если запустить apt-get update из под пользователя, у которого нет прав, под рутом этот самый apt-get update выдает обшибку.

Удивительно и невероятновое 2: Почему-то мой быстрый путь тяп ляп и готово по добавлению извера в /etc/sudoers не помог дать ему необходимых прав, а дебиан под ним пакеты не захотел устанавливать.

Но об этом в лучших традициях Скарлетт О'Хара я подумаю завтра, потому что количество букв в посте сильно ограничены.

На имиджборде 4chan стартовала операция с красноречивым названием «Засорить туалет». Цель операции — лишить граждан Индии шанса быстро попасть в США. 20 сентября 2025 года Трамп увеличил цену за рабочую визу для иностранцев: теперь за возможность въехать и работать в США придётся отдать $100 000 вместо прежней тысячи. На этом фоне американские компании спешно попросили сотрудников вернуться обратно в США. У индийских специалистов остаётся ровно сутки, чтобы успеть подать заявку и заскочить в последний вагон без большого сбора. Чтобы испортить им планы, на площадке начали массово бронировать билеты из Индии в США. Итог не заставил себя ждать: стоимость перелётов уже выросла почти до $5000.

Игра с огнём, или нулевой байт

В одном проекте заказчик потребовалось различать (и делать поиск) по трем состояниям текстового поля в Lucene индексе:

1. непустое значение (работает из коробки)

2. пустая строка "" (не поддерживается люсин)

3. null (не поддерживается люсин)

Lucene не хранит null и пустые строки "" - значения просто не индексируется. Для бизнес-логики, где нужно различать все три состояния, стандартных механизмов Lucene недостаточно.

Создание "специальных" замен в виде комбинаций типа "_null_" текста и спецсимволов - ломается тестерами которые пропускали различный мусор через индекс.

Был выбран компромиссный подход:

• "\0" (строка из нулевого байта) используется как маркер null

• "\0\0" (строка из двух нулевых байтов) используется как маркер ""

Пробило в холодный пот? Правильно, и меня тоже. Тем не менее, это рабочий способ.

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

Плюсы:

• \0 — это валидный символ в Java-строке, который практически не встречается в реальных данных.

• Символ \0 невозможно ввести напрямую из внешних систем, редакторов или форм без явного кодирования. Это защищает от случайных коллизий, даже если тестировщики пробуют «мусорные» символы.

• Таким образом достигается стабильное различие между null, "" и содержимыми строками.

Риски:

• Утечки наружу. Маркеры \0 могут попасть в API-ответы, логи, сериализацию. В нашем случае lucene был в обертке и поиск напрямую не использовался внешними системами - обработчик вызовов был инкапсулирован в прокси сервис.

Использование \0 и \0\0 как маркеров — это баланс между «желанием клиента» и технической безопасностью. Работает, но требует дисциплины: любая утечка этих символов превращает решение в источник трудноуловимых багов снаружи индекса.

Сегодня в чате техписателей спросили про разницу между Docs-as-Code и DocOps.

Docs-as-Code — это один из подходов к организации документирования, который рекомендует определенное устройство процессов и диктует выбор инструментов. Звучит сложно? На самом деле строится всё на языке разметки, Гите и SSG.

DocOps — это вообще вся автоматизация вокруг документирования. И хотя в интернетах и в GPT вам будут говорить, что это философия, методология, культура, рамка (простигосподи) и другие аморфные слова. Не верьте.

По сути и на практике DocOps — это набор инструментов для автоматизации всех процессов документирования. Инструментов, которые вы используете у себя в компании для подготовки, проверки и публикации документации. Естественно, о Ворде речь не идёт. Естественно, инструментов без процессов не бывает. Но организация документирования это всё-таки задача руководителя, а не докопса.

Кстати. Человек, роль, должность это не DocOps, это DocOps-инженер. Если из контекста можно понять, что речь о человеке, то, конечно, обычно сокращают до «наша докопс сегодня учудила». Но всем должно быть понятно, что учудила не инженерная дисциплина, а коллега.

В Epic Games выпустили специальную игру для японских сотрудников на заводах компании, чтобы скрасить рутину. Каждому работнику выдали виртуальное поселение, в котором можно отправлять персонажей что‑то делать. В игре есть таймер обратного отсчёта и только во время него человечки двигаются и работают. Чтобы сбросить таймер, нужно выполнить определённую работу в реальной жизни на фабрике. Чем эффективнее работаешь, тем быстрее развиваются персонажи виртуальной игры.

Посде игрофикации производства продуктивность фабрик Epic Games выросла на 18%, а сотрудники начали хвалиться друг перед другом своими виртуальными поселениями. В будущем в Epic Games планируют добавить больше механик и геймифицировать любую рутинную работу.

Германский умлаут и славянская третья палатализация
Кто интересовался историей славянских языков (в частности праславянским), тот наверняка слышал, что современные буквы ъ и ь ранее обозначали звуки ŭ и ĭ, сравните, например древнерусское мьзда, стькло и готское mizdo, stikls или древнерусское кънѧзь и финское kuningas. При этом вследствие третьей палатализации «твёрдый знак» мог переходить в «мягкий», например (в дореформенной орфографии) другиня другъ, но княгиня князь. Причиной палатальной перегласовки в данном случае является наличие в слове князь буквы «я», которая как некоторые любознательные читатели, наверное, уже слышали, может переходить в «ин» размять разминать, распять распинать, ну а «и» может переходить в «ь» липнуть, но льнуть (сравните капать / кануть). Иными словами, тем самым фактором из-за которого отражавшийся ранее на конце слов «ъ» перешёл в слове князь в «ь» является засевший в корне ещё один ерь «ь» «сингармонически» уподобляющий идущие за ним гласные себе. Такое уподобление называется прогрессивным.

Теперь же плавно перейдём к умляуту в германских языках по-иному именуемому i-mutation. Сравним, например английское full полный и fill наполнять. Возвращаясь к означенному в самом начале статьи можно заметить некую аналогию и она действительно есть ...

Продолжение следует

Старые часы Casio можно преобразовать в фитнес-браслет. Команда Olee Watch выпустила модуль для часов, который считает шаги, измеряет пульс и даже запускает игры. Работает всё через мобильное приложении. Цена модуля $55 (~4500₽). Совместимые часы: Casio F-91W или A158W.

Дело не в том как ты проходишь собеседование

Дело в том хочет человек тебя нанять или нет

Т.е. проходишь ты дальше или нет основывается не на твоих желаниях и знаниях, а на желаниях и знаниях собеседующего

Так что не парься, будь счастлив 😁

Воспринимай собеседования не как путь именно к этой работе, а как путь к чему-то вообще :)

В любом случае этот шаг делает тебя на шаг ближе к цели

Если ты не прошел собес, то выбор простой: сражайся с этим или наслаждайся этим, и даже если сражаешься, то насладись сражением 😁

P.S. И так во всём..

Хакер этимология

Слово hacker произошло от английского глагола to hack "разрубать".

1. Германское (готское, древнеанглийское, древнескандинавское, ...) "h" соответсвует русскому "к" по Закону Гримма

2. Германское "a" соответствует русскому "о" по Германскому сдвигу гласных

3. Германское "c" соответствует русскому "г" по Закону Гримма

4. Германское "k" соответствует ассимилированному "n" по Закону Клюге, присутствующему в значительном числе случаев в германских языках, но отсутствующему в русском, сравните древнескандинавское laun лов, vagn воз

5. В русском языке существует пара нога ноготь

Итого: hack ~ коготь.

Baidu представила ERNIE X1.1 — модель рассуждений уровня GPT-5 и Gemini 2.5 Pro

На конференции WAVE SUMMIT 2025 китайская компания Baidu анонсировала ERNIE X1.1 — обновленную модель рассуждений с существенными улучшениями в точности, следовании инструкциям и агентских возможностях. Модель превосходит DeepSeek R1-0528 и сопоставима с топовыми решениями от OpenAI и Google.

Технические улучшения

ERNIE X1.1 демонстрирует значительный прирост производительности относительно предыдущей версии. Фактическая точность выросла на 34.8%, следование инструкциям улучшилось на 12.5%, а агентские способности — на 9.6%.

Архитектурные особенности:

• Построена на базе мультимодальной модели ERNIE 4.5

• Использует итеративную гибридную систему обучения с подкреплением

• Объединяет смешанное reinforcement learning и итеративную самодистилляцию

• Поддерживает контекст 128K токенов

Производительность в бенчмарках

По результатам множественных тестов ERNIE X1.1 превосходит DeepSeek R1-0528 в общей производительности, показывая явные преимущества в ряде задач. Модель работает на одном уровне с такими топовыми решениями как GPT-5 и Gemini 2.5 Pro.

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

Доступность и интеграция

ERNIE X1.1 доступна через несколько каналов:

• ERNIE Bot — веб-интерфейс на ernie.baidu.com

• Wenxiaoyan — мобильное приложение Baidu

• Qianfan MaaS — платформа Models-as-a-Service для корпоративных клиентов и разработчиков

Параллельно с ERNIE X1.1 компания открыла исходный код модели ERNIE-4.5-21B-A3B-Thinking — легковесной MoE-модели с 21 миллиардом общих и 3 миллиардами активных параметров.

Экосистема PaddlePaddle

Развитие ERNIE X1.1 происходит в контексте расширения экосистемы PaddlePaddle. На данный момент экосистема PaddlePaddle-ERNIE обслуживает 23.33 миллиона разработчиков и 760,000 предприятий.

Новые инструменты включают:

• PaddlePaddle framework v3.2 с улучшениями обучения и совместимости

• ERNIEKit для разработки фундаментальных моделей

• FastDeploy v2.2 для эффективного развертывания

• Научные тулкиты PaddleCFD и PaddleMaterials

Baidu Comate 3.5S

Одновременно с ERNIE X1.1 представлена обновленная версия ИИ-помощника для программирования Baidu Comate 3.5S. Система поддерживает более 10 миллионов разработчиков, а внутри Baidu 45% нового кода теперь генерируется ИИ.

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

Конкурентная позиция

ERNIE X1.1 позиционируется как прямой конкурент западных моделей рассуждений. Baidu делает ставку на сочетание высокой производительности с локализацией под китайский рынок и требования регуляторов.

Преимущества модели:

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

• Интеграция в экосистему китайских облачных сервисов

• Поддержка специфичных для региона задач и языковых особенностей

• Соответствие местным требованиям по данным и безопасности

Релиз ERNIE X1.1 демонстрирует способность китайских технологических компаний создавать модели мирового уровня и конкурировать с ведущими американскими разработчиками ИИ.

Варез этимология

Слово warez произошло от сленговой формы множественного числа английского существительного ware.

Английское ware, в свою очередь, связывается с готским глаголом warjan (готский язык, в ряде случаев, сохранил наиболее архаичные прагерманские черты, поэтому и используется в определённых этимологических словарях в качестве отсылочного).

Глагол warjan, согласно словарю Фасмера, связан с глаголом отворить, где исконно приставкой являлась от- (а не о- как в современном русском).

1. Готско-русское (а изначально прагерманско-праславянское) соответствие a~о является хорошо изученным фактом, отражённым в специализированной литературе под названием "Германского сдвига гласных" (сравните: marei море, gasts гость, skatts скот).

2. Готское j относится к полугласным и может переходить в i

(сравните, например: landa земли land земля, но kunja рода́ kuni род).

3. Данное j (из первоначального i) является в готским суффиксом слабых глаголов

(именуемых в терминологии английского языка правильными, а в терминологии русского - каузативами) и родственно русскому суффиксу и.

Сравните:

гот. ligan lagjan

англ. lie lay

рус. лежать -ложить

4. Не вдаваясь в истоки происхождения готского -an стоит отметить его сообразное использование наряду с русским -ть (старославяским -ти, литовским -ti)

Сравните: гот. malan лит. malti молоть

Примечание: автор против означенного в заголовке программного обеспечения. Он выступает за использование исключительно распространяемых законным путём и без нарушения прав правообладателя программ.