Вкратце: есть Strict стандарт, и есть Transitional, созданный "для корректной конвертации документов, созданных в старых версиях".
И все бы ничего, но:
По умолчанию офисы сохраняют НОВЫЕ документы в Transitional формате. Strict нужно явно включать.
Не во всех версиях офиса есть возможность использовать strict формат.
Transitional поддерживает "совместимость фичей". Совместимость в спецификации указывается "выравнять так, как это делал word 95" или "сделать как в office 97". Как это делали указанные версии софта 30-летней давности, в "стандарте" не указывается. Также там содержатся отсылки на закрытые виндовые апи (реверсить нельзя).
OOXML считает 1900 год високосным, чтобы поддерживать совместимость с багом софта 90-х годов.
"Открытый стандарт" де факто не реализуем в стороннем софте.
А я ведь правильно понимаю, что эта штука сломается, как только я, например, порядок элементов поменяю? Тупо, например, подложу li с какой-нибудь стильной стрелочкой перед номером страницы?
Ну или решу отображать список страниц по 10 штук (1-10, 11-20) - и на 11-й странице у меня кнопки "назад" не будет?
Analyze — анализирует требования и превращает их в спецификацию.
Design — проектирует систему на основе утвержденной спецификации.
Develop — реализует систему согласно спецификации и архитектуре.
Review — проводит ревью кода и проверяет качество реализации.
Security — проверяет систему на уязвимости и риски.
Test Generation — создает тестовые сценарии.
Flow Orchestrator — управляет полным жизненным циклом разработки.
DocsExplorer — следит за актуальностью документации.
Вот здесь глобальный косяк в порядке пунктов.
Почему генерация тестов после разработки и ревью? Тесты тут, получается, просто для галочки? Генерим тесты из готового кода - ну отлично. Единственное, что они будут проверять - что в коде написано ровно то, что написано.
Ну, говна и в письменном виде - полно. Графоманией различной степени упоротости полки книжных магазинов под потолок завалены.
Вопрос в потреблении качественного контента. Представьте "бубнящую голову", с экрана читающую хорошую плотную доку, без воды и копирайтерского высера.
Что там она, эта голова прочитать за полчаса успеет? Пару-тройку страниц?
Что вы на слух их этого поймете/запомните?
Сколько вы успеете прочитать сами за полчаса, и насколько лучше усвоите написанное?
При всем обилии "мультимедийных" форматов, плотность подачи и качество усвоения выше письменности так и не достигли. КПД текста - очешуительное, и уметь читать текст нужно.
Однако фокус смещается в другие форматы подачи. Картинки надо яркие, голову говорящую, эмоции через край и вот это вот все. На выходе - человек, изучающий программирование, ищет ролик, в котором какой-то хлыщ читает ему вслух избранные места из книжки "Алгоритмы и структуры данных" вместо того, чтобы взять книжку и прочитать (ситуация реальная).
Не, я охотно верю, что в мире, возможно, существуют 15-секундные видеоролики, несущие какое-то важное знание. Но я таких не видел, чесслово.
Что за 15 секунд сказать/показать можно? Пара предложений + яркая картинка? Получится ли дать какое-то ценное знание в 2 предложениях с картинкой в видеоролике? (Только не надо говорить, что "есть же схемы/карты с подписями, они много информации несут". Ролик - 15 секунд, что вы там на этой схеме рассмотреть успеете?)
На выходе, максимум, на что способен 15-секундный ролик - вызвать эмоцию. И вот тут совсем беда.
Можно разобрать сложный алгоритм и порадоваться своей удаче (получить эндорфин). Можно слепить горшок из глины, покрасить стены, написать поэму или выучить новый танец и порадоваться (получить эндорфин). А можно посмотреть 15-секундный ролик, вызывающий на эмоцию и получить эндорфин.
Беда в том, что эндорфин - один и тот же. Разбирая алгоритм, ты получаешь ценный скилл + эндорфин, а от ролика - только эндорфин. Но эндорфин роляет...
Само название ORM достаточно хорошо отражает его задачу: объектно-ориентированное сопоставление/отображение
Нет в аббревиатуре ORM ничего про ООП. Object Relational Mapping - это типа относительное сопоставление объектов. Откуда постоянно "ориентированность" лезет?
предоставляет сервис для конечного ПО в том виде, как это принято в данной конкретной ОС
вот тут ошибочка закралась, имхо. Драйвер для конечного ПО никакого сервиса не предоставляет. Конечное ПО не в курсе, какой драйвер получает команды - оно с ОС общается.
Если предположить, что это первая статья из цикла - то вполне ок. Ровно из этого кода можно собрать рабочий модуль ядра, который будет что-то полезное делать.
А по поводу того что "пользовательское ПО" - тут по реализации вообще разницы нет, пользовательское оно или в ядре живет. Например, если нам понадобится драйвер USB-мыши написать, мы просто напишем буквально софтину, которая будет по некоторому таймеру опрашивать мышь по USB на тему "куда тебя там шевелили" и писать результат в /dev/mouse. Оно в линуксе прям настолько просто, драйвер - вполне обычная софтина.
Не отвечает на вопрос, почему LLM гораздо лучше и честнее отвечают, если с них снять избыточное давление из-за их инструкций
В концепцию ЯМ = сжатие, как раз, очень хорошо ложится. Вы же на нейронку ограничения накладывает, т.е. буквально из "архива" часть данных исключаете.
Примерно как jpeg'у сказать "исключи из картинки все пиксели с преобладанием красного спектра, а потом попытайся аппроксимировать мне исходную картинку". Это, как раз, логично, что артефактов будет больше - вы коэффициент сжатия увеличили, при этом путем подвигается бегунка lossy в сторону возрастания.
Вот тут пояснение позиции есть: https://blog.documentfoundation.org/blog/2026/06/02/a-standard-in-name-only/
Вкратце: есть Strict стандарт, и есть Transitional, созданный "для корректной конвертации документов, созданных в старых версиях".
И все бы ничего, но:
По умолчанию офисы сохраняют НОВЫЕ документы в Transitional формате. Strict нужно явно включать.
Не во всех версиях офиса есть возможность использовать strict формат.
Transitional поддерживает "совместимость фичей". Совместимость в спецификации указывается "выравнять так, как это делал word 95" или "сделать как в office 97". Как это делали указанные версии софта 30-летней давности, в "стандарте" не указывается. Также там содержатся отсылки на закрытые виндовые апи (реверсить нельзя).
OOXML считает 1900 год високосным, чтобы поддерживать совместимость с багом софта 90-х годов.
"Открытый стандарт" де факто не реализуем в стороннем софте.
А я ведь правильно понимаю, что эта штука сломается, как только я, например, порядок элементов поменяю? Тупо, например, подложу li с какой-нибудь стильной стрелочкой перед номером страницы?
Ну или решу отображать список страниц по 10 штук (1-10, 11-20) - и на 11-й странице у меня кнопки "назад" не будет?
Вот здесь глобальный косяк в порядке пунктов.
Почему генерация тестов после разработки и ревью? Тесты тут, получается, просто для галочки? Генерим тесты из готового кода - ну отлично. Единственное, что они будут проверять - что в коде написано ровно то, что написано.
Это важнейший на данный момент навык. И он в среднем сильно падает.
Вот именно, система образования еще не приспособилась, а студенты читать уже разучились. В этом и беда...
Ну, говна и в письменном виде - полно. Графоманией различной степени упоротости полки книжных магазинов под потолок завалены.
Вопрос в потреблении качественного контента. Представьте "бубнящую голову", с экрана читающую хорошую плотную доку, без воды и копирайтерского высера.
Что там она, эта голова прочитать за полчаса успеет? Пару-тройку страниц?
Что вы на слух их этого поймете/запомните?
Сколько вы успеете прочитать сами за полчаса, и насколько лучше усвоите написанное?
При всем обилии "мультимедийных" форматов, плотность подачи и качество усвоения выше письменности так и не достигли. КПД текста - очешуительное, и уметь читать текст нужно.
Однако фокус смещается в другие форматы подачи. Картинки надо яркие, голову говорящую, эмоции через край и вот это вот все. На выходе - человек, изучающий программирование, ищет ролик, в котором какой-то хлыщ читает ему вслух избранные места из книжки "Алгоритмы и структуры данных" вместо того, чтобы взять книжку и прочитать (ситуация реальная).
Вот тут беда-беда, про то и изначальная статья(
Нулевая информационная ценность?
Не, я охотно верю, что в мире, возможно, существуют 15-секундные видеоролики, несущие какое-то важное знание. Но я таких не видел, чесслово.
Что за 15 секунд сказать/показать можно? Пара предложений + яркая картинка? Получится ли дать какое-то ценное знание в 2 предложениях с картинкой в видеоролике? (Только не надо говорить, что "есть же схемы/карты с подписями, они много информации несут". Ролик - 15 секунд, что вы там на этой схеме рассмотреть успеете?)
На выходе, максимум, на что способен 15-секундный ролик - вызвать эмоцию. И вот тут совсем беда.
Можно разобрать сложный алгоритм и порадоваться своей удаче (получить эндорфин). Можно слепить горшок из глины, покрасить стены, написать поэму или выучить новый танец и порадоваться (получить эндорфин). А можно посмотреть 15-секундный ролик, вызывающий на эмоцию и получить эндорфин.
Беда в том, что эндорфин - один и тот же. Разбирая алгоритм, ты получаешь ценный скилл + эндорфин, а от ролика - только эндорфин. Но эндорфин роляет...
А тут... Ну, точно так же заэвейтить можно. Несколько другими абстракциями, конечно, но пакет sync таки существует
Не, не сработает. Просто вместо вертикальных минутных видео будут смотреть на 15-секундные ролики в кружочках.
Вот и весь протест
Нет в аббревиатуре ORM ничего про ООП. Object Relational Mapping - это типа относительное сопоставление объектов. Откуда постоянно "ориентированность" лезет?
Даже, наверное, "реляционные отображение объекта"
Это где такой запрет описан? Вы, может быть, с DDD путаете?
Очень удобно: можно пробовать логины на существование.
Я не великий специалист, конечно, но
вот тут ошибочка закралась, имхо. Драйвер для конечного ПО никакого сервиса не предоставляет. Конечное ПО не в курсе, какой драйвер получает команды - оно с ОС общается.
Если предположить, что это первая статья из цикла - то вполне ок. Ровно из этого кода можно собрать рабочий модуль ядра, который будет что-то полезное делать.
А по поводу того что "пользовательское ПО" - тут по реализации вообще разницы нет, пользовательское оно или в ядре живет. Например, если нам понадобится драйвер USB-мыши написать, мы просто напишем буквально софтину, которая будет по некоторому таймеру опрашивать мышь по USB на тему "куда тебя там шевелили" и писать результат в /dev/mouse. Оно в линуксе прям настолько просто, драйвер - вполне обычная софтина.
Выглядит как определение драйвера, имхо
У меня один только один вопрос: в какой момент осел в мышей превратился?
В концепцию ЯМ = сжатие, как раз, очень хорошо ложится. Вы же на нейронку ограничения накладывает, т.е. буквально из "архива" часть данных исключаете.
Примерно как jpeg'у сказать "исключи из картинки все пиксели с преобладанием красного спектра, а потом попытайся аппроксимировать мне исходную картинку". Это, как раз, логично, что артефактов будет больше - вы коэффициент сжатия увеличили, при этом путем подвигается бегунка lossy в сторону возрастания.
Вы же не встраиваете.
Вот это композиция. А у вас аггрегация, вам совершенно верно сказали
Или не будет работать... Ну, в смысле, у вас нет инструмента, чтобы отследить, что изменения в базовом классе сломало что-то в наследниках...
Вот тут что-то странное написано... Родительский класс, вроде, никакого доступа к наследнику не имеет. Он буквально не знает о его существовании же?
Ну и даже если исправить - наследник, например, к приватным полям родителя доступа не имеет.
Не все так однозначно, в общем. Да sealed/final не на ровном месте придумали - видимо, какую-то проблему решали? Может, есть она, все же?
Ну вот нет у слова "дырявый" такого смысла. "Дырявый" - это синоним "ненадежный" и "уязвимый". Подберите другой термин, пожалуйста.
А wireguard с openvpn в какой момент дырявыми стали? Есть прецеденты взлома и получения доступа к информации, передаваемой через зашифрованный канал?