Плагин можно использовать в приложении Codex Desktop и интерфейсе командной строки Codex CLI от OpenAI, в редакторе кода Cursor, а также в Claude CLI от Anthropic. Чтобы ИИ-агент издавал звуки при чтении, в новом диалоге нужно отдельно попросить использовать инструмент endless-toil. Автоматически плагин не запустится. Например, чтобы использовать его в Claude CLI, нужно ввести команду: /plugin install endless-toil@endless-toil. Затем нужно перезапустить Claude Code и запустить набор навыков командой: /endless-toil.

В итоге пользователь задействовал около 200 дронов, которые формируют в небе светящиеся подсказки и стрелки. Сообщения буквально ведут курьера к нужному адресу: «сюда», «продолжай ехать», а при ошибке появляется предупреждение о неверном повороте с просьбой сдать назад.

ИИ иронизирует.

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

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

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

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

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

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

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

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

Итак, наслаждайтесь...

Сессия нулевая, ответ первый, без уточнений и наводок.

Обзор от ИИ Запуск FlightGear 2024 в «условиях Кин-дза-дзы» (песчаная планета Плюк, дефицит ресурсов, отсутствие воды и гравицаппы) требует нестандартного подхода. Учитывая, что на Плюке «эцилопп не имеет права бить по ночам», можно попробовать установить симулятор. Вот как выглядит «план действий» для выживания в симуляторе:

1. Подготовка оборудования (Гравицаппа не нужна)

   Ноутбук/ПК: Подойдет любой, работающий на «луце» (бензин/электричество). Минимальные требования (для работы на Плюке): Процессор: Двухъядерный (чтобы обрабатывать песчаные бури). Память: минимум 1 ГБ. Видеокарта: С поддержкой OpenGL 2.0 (чтобы видеть чатлан и пацаков). Место: 2 ГБ для минимальной установки.

2. Установка (Настройка «Пепелаца»)

   Скачайте версию 2024 (работает на Windows/macOS). При установке вместо выбора стандартных ландшафтов, используйте симулятор для генерации текстур пустыни.

3. Запуск полета (В «условиях Кин-дза-дзы»)

   Место взлета: Установите локацию на пустынный аэродром. Самолет: Выбирайте что-то простое, например, Cessna C172P. Запуск двигателя: Выберите пункт «Autostart» в меню Cessna C172P, чтобы запустить двигатель, если песок попал в карбюратор.

4. Правила полета

   При встрече с другим самолетом — сделайте «КУ». Если у вас есть «Цак» (симулятор FlightGear), вы имеете право летать. Если вас остановил эцилопп, скажите: «Ку!».

Примечание: Если FlightGear не запускается, значит у вас нет «КЦ» (лицензии/мощности ПК), и вам нужно купить гравицаппу.

Когда пользователи ищут обменник, чаще всего смотрят на курс. Если цифра выглядит лучше - значит “выгодно”. Проблема в том, что безопасность почти никогда не видна на первом экране. И именно поэтому ошибки чаще происходят не после обмена, а в момент выбора.

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

1. Прозрачность условий

Если итоговая сумма становится понятна только в процессе или “после подтверждения”, это плохой сигнал. В нормальном сценарии пользователь заранее понимает, сколько спишется и сколько придёт.

2. Предсказуемость курса

Важно не только число на экране, а то, фиксируется ли курс и в какой момент. Если итог может “поплыть” без понятных правил, то это уже зона риска.

3. Комиссии и скрытые потери

Даже при хорошем курсе итог может ухудшаться за счет комиссии сети, внутренней комиссии сервиса или спреда. Сравнивать нужно не витрину, а результат.

4. Скорость и тип обработки

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

5. Поведение интерфейса

Странные редиректы, неожиданные шаги, изменение условий по ходу оформления - всё это чаще сигнал не про дизайн, а про риск.

6. Требования по ходу процесса

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

7. Лимиты и ограничения

Несовпадение суммы с правилами сервиса - частая причина ситуаций “деньги отправлены, но не зачислены”. Эти вещи лучше проверять до, а не после.

8. Отзывы и агрегаторы

Отзывы могут помочь, но сами по себе ничего не гарантируют. У любого популярного сервиса будут и положительные, и негативные оценки. Проблема в том, что пользователь чаще смотрит на среднюю оценку, а не на детали. При этом гораздо полезнее обращать внимание не на “5 из 5”, а на повторяющиеся сценарии в отзывах: задержки, изменение условий по ходу обмена, проблемы с зачислением или поддержкой. Если одни и те же жалобы встречаются регулярно, это уже не случайность, а паттерн.

9. История сервиса и цифровой след

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

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

10. Риск транзакции и предварительная проверка

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

11. Поддержка и реакция

Важно не наличие чата, а то, как быстро и по делу отвечают. Это становится критичным, если что-то пошло не по плану.

12. Тестовый прогон

Если сервис новый или сумма чувствительная, небольшая тестовая операция почти всегда дешевле, чем разбираться с последствиями. Если упростить, безопасный обмен - это не тот, где “лучший курс”, а тот, где весь процесс предсказуем: от ввода суммы до финального зачисления.

И наоборот: чем больше в сценарии сюрпризов, тем выше шанс, что проблема возникнет не в блокчейне, а ещё до него.

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

Рынок 2026 года переходит в фазу жесткого регулирования каждого товара! Теперь на каждую единицу товара у продавца должно быть сформировано четкое юридическое обоснование, которое зависит от статуса вещи.

Полагаю, что новые правила не коснуться тех, кто продаёт "пару" личных вещей в месяц. Отслеживать будут именно тех, кто системно что то продаёт.

1. Если товар продается как «Новый»: Здесь закон не оставляет пространства для маневра. Помимо договора поставки и накладных, обязательны:

• Маркировка «Честный ЗНАК»: согласно Распоряжению № 792-р, без специального цифрового кода товар юридически не существует в обороте.

• Сертификат или Декларация (ТР ТС): подтверждение безопасности. Если это изделия из Китая без торговой марки и документов, стоимость получения собственного сертификата (от 30-40 тыс. руб.) на маленькую партию делает закупку бессмысленной. Чем дешевле товар и чем его меньше, тем быстрее прибыль уходит в минус.

2. Если товар имеет статус «Бывший в употреблении» (БУ): Здесь правила мягче (хотя и есть ужесточения для возврата товаров ПП № 2463):

• Обязательная сертификация и маркировка (ЧЗ) всё ещё не требуются.

• Но необходим Акт разукомплектации (если закупалась партия смешанных товаров).

Важно: статус «бывший в употреблении» должен быть зафиксирован документально, а не просто «на словах» в описании.

Белая экономика 2.0

Я создал таблицу соответствующую новым правилам торговли, заполнил формулами, которые позволяют увидеть текущую прибыльность закупок и будущую, с учетом всех нововведений. Прогнал базу своих товаров через этот расчет. Вот что получается в моём случае (в среднем на товар):

• Работа с остатками, которые можно юридически обосновать как БУ новые, сопутствующие расходы съедают около 12% прибыли.

• Работа с новым товаром, требующим маркировки и дополнительных разрешений - расходы вырастают до 17%.

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

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

Долгое время думала, что использовать паттерны на фронте незачем и это больше тема для собесов

Но недавно все-таки удалось использовать паттерн фабрику для фронта и моему счастью не было предела, когда после 30-минутного рефакторинга разъехавшейся вёрстки через Claude, я попросила: "брат, слушай это ж паттерн фабрика, сделай BaseModal тонким, который просто решает, какой компонент отрисовать"

Технически, классический GoF Factory Method подразумевает наследование, а здесь у меня скорее Simple Factory — функция, выбирающая что создать. Но в обиходе все называют это "фабрикой", и я не буду усложнять.

Классический паттерн фабрика на Java:

// Интерфейс
interface Modal {
    void open();
    void close();
}

// Конкретные реализации
class Dialog implements Modal { ... }
class BottomSheet implements Modal { ... }
class FullscreenSheet implements Modal { ... }

// Фабрика — решает какой класс создать
class ModalFactory {
    static Modal create(String type, boolean isMobile) {
        if (!isMobile) return new Dialog();

        return switch (type) {
            case "bottom-sheet" -> new BottomSheet();
            case "fullscreen"   -> new FullscreenSheet();
            default             -> new Dialog();
        };
    }
}

// Использование
Modal modal = ModalFactory.create("bottom-sheet", isMobile);
modal.open();

Как это работает во Vue?

На фронте есть <component :is="..."/> - динамический компонент, который рендерит то, что ему передадут. Это и есть наш аналог ModalFactory.create(...).

<!-- BaseModal.vue — фабрика -->
<template>
    <component
        :is="modalComponent"
        v-bind="$props"
        @close="emit('close')"
    >
        <slot />
    </component>
</template>

<script setup>

// Фабричный метод — выбирает компонент
const modalComponent = computed(() => {
    // Desktop → всегда Dialog (центрированный)
    if (!isMobile.value) return BaseDialog

    // Mobile → зависит от mobileStyle
    switch (props.mobileStyle) {
        case 'fullscreen':
            return BaseFullscreenSheet
        case 'bottom-sheet':
            return BaseBottomSheet
        default:
            return BaseDialog
    }
})
</script>

Получился BaseModal, который сам почти ничего не делает.

Он не знает, как устроен dialog.
Не знает, как анимируется bottom sheet.
Не знает, как выглядит fullscreen-модалка.

Он просто маршрутизирует:

BaseModal.vue  
  ├─ BaseDialog.vue    
  ├─ BaseBottomSheet.vue    
  └─ BaseFullscreenSheet.vue  

А каждая конкретная реализация живёт отдельно и отвечает только за себя.

Почему это лучше, чем один большой компонент?

Потому что большой универсальный компонент очень быстро превращается в кашу:

<!-- Каша в template -->
<div
    class="modal"
    :class="{
        'modal--open': open,
        'modal--mobile': isMobile,
        'modal--desktop': !isMobile,
        'modal--fullscreen': isMobile && mobileStyle === 'fullscreen',
        'modal--bottom-sheet': isMobile && mobileStyle === 'bottom-sheet',
    }"
>

А потом туда добавляются:

• разные анимации

• разные отступы и размеры

• разное поведение закрытия

• разные transition

• разные layout-правила

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

С фабрикой проще:

• BaseDialog отвечает за centered dialog

• BaseBottomSheet отвечает за bottom sheet

• BaseFullscreenSheet отвечает за fullscreen

• BaseModal только выбирает, что показать

То есть вместо одного монолита появляется тонкий слой выбора и несколько изолированных компонентов.

И кстати, поделитесь: насколько паттерны актуальны сейчас? Или про них всё рассказали 20 лет назад и хватит говорить о них?

Неделю назад ко мне обратилась одна небольшая компания с довольно необычным запросом: им необходимо защититься от Big Data маркетинга - метода кражи клиентов через форму обратной связи. На мой удивленный вопрос “А что это, собственно, такое?” заказчик пояснил, что когда клиент оставляет запрос на ВАШЕМ сайте, то его сведения, включая персональные данные, направляются напрямую к конкурентам 😳. Я, естественно, возразил, что такое не возможно и тут явное нарушение законодательства, но клиент настаивал, и подтверждал это общим собранием конкурентов и обсуждением этой “вопиющей” нездоровой конкуренции. Кроме того, в подтверждение своих слов, мне на ознакомление была представлена статья, описывающая эту методику.

Так, в статье описывается текущий кризис рекламных каналов в России: рост стоимости привлечения клиентов (CAC), снижение эффективности классических инструментов вроде контекстной рекламы, таргета, SEO и маркетплейсов. На этом фоне авторы статьи предлагают альтернативу - так называемый «перехват клиентов» через Big Data. Суть подхода в том, чтобы “находить” пользователей, которые уже взаимодействовали с конкурентами (посещали сайты, звонили, получали СМС), и затем выходить на них с предложением через прозвон и дополнительный прогрев. После получения номеров телефонов запускается процесс квалификации: операторы звонят людям, уточняют их интерес и передают «прогретые» лиды клиенту. В статье делается акцент на том, что это законно (за счет согласий пользователей) и сравнивается с привычными маркетинговыми практиками вроде таргетинга по аудитории конкурентов или брендовой рекламы. Ну и в завершении, конечно, приводятся кейсы из разных ниш, где заявляется высокая эффективность метода и предлагается протестировать услугу через платный пилот.

Я бы к этой идее относился очень осторожно. Сама концепция «перехвата аудитории конкурентов» не новая и в легальной форме действительно существует (ретаргетинг, look-alike аудитории и т.д.). Но конкретные утверждения из статьи, особенно про доступ к номерам людей, которые «звонили конкурентам» или «получали СМС», выглядят как минимум сомнительно с точки зрения законодательства и реальных технических возможностей. В Российской юрисдикций такие практики без явного согласия пользователя незаконны. С высокой вероятностью это маркетинговое преувеличение и речь идет о серых/пограничных схемах работы с данными, например инсайдер или форма обратной связи, которая направляет запрос нескольким адресатам.

Хотя, не исключено, что я ошибаюсь и технологии Big-data действительно сильно шагнули вперед, однако на текущий момент нет публично известных легальных технологий, которые позволяли бы получать номера пользователей на основании их звонков или СМС конкурентам в описанном виде. Подскажите пожалуйста, имели ли Вы опыт разбора таких кейсов и существуют ли реально такие техники конкурентной борьбы?

🧠 Обязательно поделись с теми, кому это может быть полезно: 💬 Телеграм | 💬 Max | 📝 Хабр | 💙 ВКонтакте

В недавнем видосе я рассказывал, что сейчас читаю Талеба (в частности, его идеи вокруг “Антихрупкости”). И вот на днях на работе поймал идеальный личный пример одной из его любимых метафор Прокрустова ложа.

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

А теперь к практике. Как говорят таксисты: блог и инди-хакинг - это для души, а вообще у меня и настоящая работа есть. Я бэкенд-лид в команде, которая пилит платформу для масс-найма (курьеры, сборщики).

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

А дальше классика: 20% эйчаров закрывают 80% вакансий. И тут возникает моя самая наивная мысль: ну так давайте пилить фичи специально под этих топов!

Но тут кроется засада. Выясняется, что процессы самых эффективных ребят очень сложно загнать в рамки. У них свои паттерны, подходы, интуиция. И когда пытаемся натянуть на них стандартный флоу, мы строим для них то самое Прокрустово ложе. Пытаясь впихнуть нестандартного, сильного спеца в удобные для системы формочки, мы буквально “отрубаем ему ноги”. Мы заставляем его работать “как положено”, лишая тех самых фишек, которые и делали его звездой.

Получается забавный парадокс: классическая автоматизация мешает сильным, но отлично помогает “слабым”. Среднего сотрудника надо меньше учить, он быстрее вкатывается. А если он уйдет, найти замену гораздо проще, а порог входа сильно снижается за счет жесткого и автоматизированного рабочего процесса.

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

Дебаж 🐞с ноги 🦶

Analyze the handwriting in this image in a detailed and nuanced way. Describe observable features such as letter size, spacing, slant, pressure, consistency, and overall structure. Based on these features, infer possible personality traits, habits, and emotional tendencies, clearly distinguishing between objective observations and speculative interpretations.

Avoid making any medical or psychological diagnoses. Instead, frame insights as possibilities (e.g., ‘may suggest,’ ‘could indicate’). Comment on:

• Level of organization vs spontaneity

• Emotional expressiveness vs restraint

• Confidence vs hesitation

• Attention to detail vs big-picture thinking

• Energy levels or intensity suggested by stroke patterns

Also note any unique or unusual features that stand out and what they might symbolize in a general behavioral sense.

End with a brief, balanced summary that highlights both strengths and potential challenges suggested by the handwriting, while emphasizing that handwriting analysis is interpretive and not scientifically diagnostic.

На встрече вместе с экспертами из МТС Web Services и Orion soft поговорим про тренды в системном анализе, актуальные вызовы профессии и опыт внедрения ИИ.

В ходе дискуссии обсудим:

• Как развивается роль системных аналитиков и ждет ли нас трансформация профессии?

• Что нужно понимать системному аналитику при внедрении ИИ в архитектуру решений.

• Какую рутину уже можно отдать ИИ, а где результат все еще нужно внимательно проверять руками?

📅 Когда: 14 мая (четверг) в 18:00 по мск

📍 Где: офлайн в офисе МТС в Москве (м. Технопарк) + онлайн-трансляция.

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

Предупреждение плагиаторам Илона Маска ⚠️

Часто аналитика в мире технологий сводится к простому «давайте копировать успешные проекты и не будем повторять провальные». Но в мире важны не только технологии, есть ещё ложь, наглая ложь и финансовая отчётность. По данным The Information, компания SpaceX по итогам года получила 5 млрд убытка. Почему в этом виноват… искусственный интеллект?

Компания SpaceX с 2015 года запускает многоразовые ракеты Falcon 9. С 2020 года разрабатывает спутниковую систему связи Starlink. И вроде бы это позволяло хорошо зарабатывать, компания служила примером и вызывала зависть у остального мира. Что случилось в 2025 году? Сразу скажем, что все данные получены из косвенных источников, потому что SpaceX — компания непубличная.

Для начала отметим, что SpaceX получила многомиллиардные инвестиции и стала одной из самых дорогих компаний мира, а Илон Маск так и вовсе временами обгоняет «заклятого друга» Джефа Безоса в гонке богачей. Так что по крайней мере инвесторы верят в проекты Маска.

Но кроме взлетевших проектов есть ещё и «стартапы», которые проходят инвестиционную стадию, и, чтобы не искать инвесторов, Илон Маск добился слияния SpaceX и xAI (создание моделей ИИ) в одну компанию с общей оценкой 1,25 трлн долл. Но xAI пока не зарабатывает, а сколько денег надо на инфраструктуру для обучения нейросетей, мы постоянно рассказываем — в результате этот «стартап» съел в прошлом году 10 млрд долл. и привёл к убытку SpaceX в 5 млрд при выручке 18,5 млрд долл. Такой способ спрятать (уменьшить) убытки за счёт более успешной компании. Маск уже проделывал такой трюк, слив с Tesla своё убыточное начинание SolarCity.

Значит, у SpaceX всё хорошо и всем надо срочно делать Starship «как у Маска»? Не торопитесь, финансовые документы не только скрывают истину, но и показывают тайное. SpaceX собирается на IPO и должна была оценить свои риски. И юристы, не моргнув глазом, написали что-то в духе «планы по созданию орбитальных дата-центров для обучения ИИ, освоения Луны и Марса находятся на ранней стадии, имеют много непредсказуемых рисков и могут не принести прибыли».

Грустно, но честно — так что всегда стоит следить за современными технологиями, но пользу от их внедрения оценивать самостоятельно.

Директор «Инферит Техника» Олег Епишин побывал в гостях у Максима Горшенина, ведущего блогера, освещающего тонкости отечественного высокотехнологичного производства.

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

Видео уже доступно на всех крупных площадках: RuTube, VK, YouTube. Присоединяйтесь к просмотру!

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

Мы сняли фильм про Российский венчурный форум 2026! В нем мы собрали не только интервью интересных проектов с аллеи стартапов, но и отразили саму атмосферу форума.

Питчи, стенды, нетворкинг, карта стартапов России и барбекю в стартап-доме Радара в Казани.

Смотрите или слушайте, ищите интересные проекты, лайкайте и делитесь своими впечатлениями:

• Яндекс Музыка

• Apple Podcasts

• VK Video

• YouTube

• Rutube

Спасибо организаторам за их вклад в развитие стартап-индустрии страны!

Очевидный ответ…

Я не верю что это так просто, и так легко!
Но вот прямо щас сижу и сморю tcpdump и офигеваю...

Смотри: клиент заходит на сайт (https).
Сайт отвечает ему: у меня такой сертификат.
Клиент идет в интернет проверить сертификат.
РКН режет эту проверку.
Клиент не верит серверу и не заходит на него.

Легко!

Да не может такого быть!

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

У нас в гостях: Инна Пристягина, руководитель отдела развития в PVS-Studio и Юлия Резниченко, директор по маркетингу в EvApps.

Посмотреть и послушать можно ещё тут:

• Наш сайт

• Rutube

• YouTube

• Mave

• Яндекс.Музыка

Приятного просмотра! Будем рады вашим комментариям!

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

По данным hh.ru, в 2026 году ситуация сильно изменилась в сторону работодателей, и это характерно не только для IT. В марте hh.индекс (соотношение количества активных резюме к количеству активных вакансий) составлял 11,4 — и это сигнализирует о высоком уровне конкуренции соискателей за рабочие места. Для сравнения: в марте 2025 индекс был на уровне 5,9 и отражал здоровое соотношение между работодателями и соискателями на рынке. 

Что касается именно IT, то по сравнению с мартом 2025 опубликованных вакансий для IT-специалистов стало меньше на 36%, а резюме — больше на 25%. hh.индекс вырос вдвое — с 11,6 до 22,9. Исследование Хабра и Экопси подтверждает эти данные. Если 2024 год был периодом активного роста — с высокими бюджетами, расширением штатов и появлением новых работодателей, — то в 2025 году динамика изменилась.

Рынок вошел в фазу структурных изменений — с замедлением роста зарплат, усилением конкуренции среди специалистов и ростом неопределенности.

Итак, почему же мы не волнуемся о том, что внезапно прикроем найм? Если коротко, то мы просто не можем себе это позволить. Шесть собственных дата-центров уровня Tier III, свои managed-сервисы, запуск новых продуктов, появление новых клиентов. Еще и коллеги постоянно придумывают что-то новое. Сейчас, например, направление ML развивают. Ну тут просто рук не хватает, сами понимаете.

А если хотите больше подробностей, то переходите по ссылке. Там есть исследование, а в конце — розыгрыш легендарных плюшевых Тирексов!

На этой неделе — серия бесплатных открытых вебинаров для разработчиков, архитекторов, DevOps‑инженеров, аналитиков и специалистов, которые работают с AI‑инструментами.

Все вебинары проходят в рамках онлайн‑курсов OTUS и проводятся преподавателями‑практиками. Это возможность познакомиться с экспертами, посмотреть на формат обучения изнутри и задать вопросы по теме.

4️⃣ мая

➡ 20:00. «Интерфейсы в Golang изнутри»
_{Разберём, как устроены интерфейсы в Go, что происходит под капотом и почему понимание внутренней механики помогает писать более предсказуемый код.}

5️⃣ мая

➡ 20:00. «Postgres + JSON: реляционная мощь, документная гибкость»
_{Поговорим о том, как использовать JSON в PostgreSQL, когда это оправдано и как совместить строгую реляционную модель с гибкостью документного подхода.}

➡ 20:00. «Архитектурные решения в backend‑разработке»
_{Обсудим, как принимать архитектурные решения в backend‑проектах, где проходит граница между полезной инженерной дисциплиной и избыточным усложнением.}

➡ 20:00. «Ansible: быстрый старт»
_{Практический вводный вебинар для тех, кто хочет автоматизировать рутинные задачи администрирования и быстрее перейти от ручных действий к воспроизводимой инфраструктуре.}

➡ 20:00. «Как не допустить ошибок при написании пользовательских историй (User Story)?»
_{Разберём типичные ошибки в User Story и посмотрим, как формулировать требования так, чтобы они были понятны команде разработки и полезны для продукта.}

6️⃣ мая

➡18:00. «Методы работы с LLM: промпт‑инжиниринг, LoRA и RAG»
_{Поговорим о практических подходах к работе с большими языковыми моделями: от промптов до дообучения и retrieval‑augmented generation.}

➡ 19:00. «Разработка проекта на Kotlin: коллаборация человека, архитектурных шаблонов и ИИ‑команды»
_{Практический вебинар о том, как совмещать инженерный подход, архитектурные паттерны и AI‑инструменты при разработке Kotlin‑проекта.}

➡ 20:00. «Rust в деле: пишем многопользовательский чат с сервером, клиентом и CLI»
_{На примере чата посмотрим, как Rust применяется в реальной задаче: сервер, клиентская часть, CLI и работа с многопользовательским взаимодействием.}

➡ 20:00. «Ключевые тренды AI Governance в 2026 году»
_{Обсудим управление AI‑системами, риски, регулирование, ответственность и подходы, которые становятся важными для компаний, внедряющих искусственный интеллект.}

➡ 20:00. «LangGraph + MCP в Cursor IDE: создаем автономного агента для глубокого анализа Google Trends»
_{Практический вебинар о создании AI‑агента с использованием LangGraph, MCP и Cursor IDE для анализа данных Google Trends.}

7️⃣ мая

➡ 20:00. «Стоп рутина: как self‑service деплой экономит ресурсы команды»
_{Поговорим о self‑service deployment: как снять часть операционной нагрузки с команды, ускорить поставку изменений и сделать процесс деплоя понятнее.}

➡ 20:00. «Настройка удобного рабочего окружения для Python‑проекта»
_{Разберём, как подготовить рабочее окружение для Python‑разработки, чтобы меньше времени тратить на хаос в зависимостях и больше — на сам код.}

➡ 20:00. «От кода до Kubernetes за полтора часа»
_{Посмотрим путь приложения от локального кода до запуска в Kubernetes и разберём базовые шаги, которые помогают понять production‑подход.}

➡ 20:00. «Тестирование микросервисов на Go: почему ваш сервис ломается под 1000 RPS»
_{Разберём, почему микросервисы могут вести себя нестабильно под нагрузкой, и какие подходы помогают находить проблемы до того, как они попадут в продакшен.}

➡ 20:00. «Как бизнес‑аналитик управляет рисками при разработке IT‑продукта?»
_{Поговорим о роли бизнес‑аналитика в управлении рисками: от требований и коммуникации со стейкхолдерами до влияния на итоговое качество продукта.}

➡ 20:00. «Качество C#‑кода: от модульных тестов к системному подходу»
_{Разберём, почему качество кода не сводится только к unit‑тестам, и как выстраивать более системный подход к поддерживаемости C#‑проектов.}

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

Традиционные инструменты мониторинга ИТ-инфраструктуры хорошо справляются с контролем «здоровья» железа: они отслеживают доступность узлов, загрузку процессоров, свободное место на дисках.  Но когда возникает проблема на уровне бизнес-приложений, классическая система мониторинга говорит только: «Пользователи жалуются, что всё тормозит». Корень проблемы может скрываться как на стыке сетевых сегментов, так и в скрытой деградации канала, переполненных буферах оборудования или ошибках на уровне TCP. Спасение в такой ситуации — решения класса NPM (Network Performance Monitoring), они помогут точно диагностировать проблему. Скажем: маршрутизатор перегружен YouTube-трафиком из отдела маркетинга, и это вызывает потерю пакетов для 1С.

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

В новом видео Станислав Грибанов, руководитель продуктов NDR и NPM компании «Гарда», расскажет подробнее о том, какие задачи закрывают NPM-решения, и на примере продукта «Гарда NPM» разберёт практические сценарии использования.

Еще больше видео о технологиях и трендах в сфере сетевой безопасности и защиты данных — на нашей странице «ВКонтакте» и на сайте.

4 мая Microsoft подтвердила: Defender с обновлением сигнатур от 30 апреля начал детектировать легитимные корневые сертификаты DigiCert как Trojan:Win32/Cerdigent.A!dha — и в ряде случаев не просто предупреждал, а удалял их из хранилища доверенных корневых сертификатов Windows.

Под удар попали два конкретных сертификата (`0563B8630D62D75ABBC8AB1E4BDFB5A899B24D43` и DDFB16CD4931C973A2037D3FC83A4D7D775D05E4), которые вырезались прямо из ветки реестра HKLM\SOFTWARE\Microsoft\SystemCertificates\AuthRoot\Certificates\. Часть пользователей, не разобравшись, переустанавливала Windows — решив, что машина реально заражена.

Что произошло на самом деле. Defender оперативно добавил правила обнаружения после инцидента у DigiCert: злоумышленники атаковали сотрудника поддержки через вредоносный ZIP под видом скриншота, получили действительные сертификаты и использовали их для подписи малвари — в том числе компонентов кампании Zhong Stealer. DigiCert отозвала 60 сертификатов. Логика детекта сработала, но зацепила слишком широко — накрыв заодно и легитимные корневые.

Проблема исправлена в Security Intelligence 1.449.430.0 и новее. Свежее обновление также восстанавливает ранее удалённые сертификаты — дополнительных ручных действий Microsoft не требует.

Для меня как CIO этот инцидент — хорошая иллюстрация того, насколько хрупкой может оказаться цепочка доверия к сертификатам. Один взломанный сотрудник поддержки у CA, несколько выданных сертификатов — и антивирус крупнейшего вендора начинает «лечить» легитимную инфраструктуру. Если у вас есть системы, критически зависящие от конкретных корневых сертификатов (VPN, внутренние PKI, подписанные агенты мониторинга), стоит проверить, не прилетело ли обновление сигнатур незаметно в нерабочее время и не унесло ли что-нибудь с собой.

Источники:

• Разбор инцидента на Anti-Malware.ru

TG @CIOlogia

Не потому что ты ленишься. А потому что всё остальное время — встречи, переписка, уведомления, «быстрые вопросы» в чате — это не работа. Это шум, который притворяется работой.

По данным Hubstaff 2026, средний офисный сотрудник проводит в состоянии реальной концентрации лишь 25–37% рабочего дня. Остальные 61% — это переключение между задачами, митинги и реакции на чужие приоритеты. У менеджеров ещё хуже: глубокий фокус занимает всего 27% времени.

И это не частная проблема — это системная. ActivTrak фиксирует: за год средняя сессия глубокой работы сократилась ещё на 8%. Корпоративная культура «занятости» буквально пожирает способность думать.

Что с этим делать?

Первое — перестать считать «занятость» синонимом продуктивности. Ты можешь провести 8 часов в офисе и не создать ничего ценного.

Второе — защитить свои лучшие часы физически. Тайм-блокинг: 90 минут с утра — только одна задача, никаких мессенджеров. Это не роскошь, это гигиена.

Третье — сократить встречи. Исследования показывают: минус 40% встреч = плюс 71% к продуктивности. Большинство созвонов можно заменить голосовым сообщением или коротким текстом.

No-Meeting Day — когда целый день без звонков — это уже не стартаперская экзотика, а норма в сильных командах.

Твои 2–3 часа концентрации — это и есть ты в лучшей форме. Вопрос только в том, кому ты их отдашь: своим целям или чужим срочностям.

Удобнейшая фича таблиц в Google Sheets — возможность фильтровать данные по различным условиям. Но есть одна проблема. Если документом пользуется несколько людей, злоупотребление этой функцией приводит к хаосу. «Кто опять изменил таблицу?»

Решение: использовать режимы фильтрации.

Создать режим фильтрации можно двумя способами:

• Выбрать в главном меню «Данные / Создать режим фильтрации»

• Нажать на калькулятор рядом с названием таблицы и выбрать «Создать режим фильтрации»

Плюсы такого подхода:

1. Режим фильтрации не меняет исходную таблицу.

2. Его можно сохранить под удобным именем.

3. На сохранённый режим можно дать ссылку.

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

В Excel есть похожая функция, находится в меню «Вид / Представление листа».

23 апреля 2026 года Canonical выпустила Ubuntu 26.04 LTS Resolute Raccoon. Для меня это старт большого проекта. Работа Linux-администратора в крупной компании подразумевает создание «золотого образа», который потом годами будет крутиться на сотнях машин.

В мои задачи входит поддержка систем управления конфигурациями. И большая часть хостов для пользователей крутится на подготовленной Ubuntu с нужным набором программ, политиками, настройками рабочего окружения, сертификатами, репозиториями, ограничениями, автозапуском, удалённым доступом и прочей инфраструктурной обвязкой. Срок поддержки заявлен до 2031 года. Для корпоративной среды это главный аргумент: если сейчас нормально подготовить дистрибутив, на нём можно спокойно жить ещё 5 лет.

Первое знакомство.

Canonical в документации указывает для Ubuntu Desktop 26.04 минимум 6 ГБ RAM, 2 GHz dual-core CPU и 25 ГБ. В чистом виде, без swap-файла, система заняла у меня около 6.6 ГБ на диске. Потребление оперативки на старте чуть меньше 2 ГБ. На фоне этого официальная рекомендация в 6 ГБ RAM выглядит как оценка для комфортной работы. Думаю после загрузки всех требуемых пакетов, браузеров с десятками вкладок, мессенджерами, антивирусами, агентами и прочими пожирателями ресурсов будет в самый раз. После тестовой установки нескольких тяжеловесных приложений, система ощущается плавной и отзывчивой. Дальше предстоит выяснить что поменялось в системе, где могут сломаться сценарии Puppet, не поедут ли настройки dconf/gsettings и ещё тысячи других мелочей.

Что нового в «Решительном еноте»?

Если сравнивать с 22.04 (которая до сих пор остается основной рабочей лошадкой во многих конторах), то это довольно крупный технологический скачок.

• Ядро Linux 7.0. Ubuntu 26.04 базируется на новой мажорной версии ядра. Это поддержка самого свежего железа, оптимизации в работе планировщика, а также свежие фичи в сетевом стеке.

• GNOME 50 принёс улучшения в адаптации интерфейса под небольшие экраны, аппаратное ускорение записи экрана, прокачанный remote desktop и более плавную работу. GNOME-сессия теперь работает только на Wayland. Старый добрый X11 не бросили (он работает через XWayland), но стандартная сессия как X.org больше не запускается. Здесь есть риск что все настройки связанные с графикой и удалённым доступом могут сломаться.

• Также Canonical удалила PreLogin и PostSession скрипты. Это может задеть корпоративные сценарии, например синхронизацию домашней директории при входе/выходе или очистку временных данных.

• Расширилось использования Rust в системе. Это помогает бороться с целым классом ошибок памяти, что всё равно не делает утилиты полностью безопасными.

• APT 3.1. Наконец то история операций и команды для отката: apt history-info, apt history-undo, apt history-redo, apt history-rollback. Вещь полезная, особенно когда случайно удалил лишнее.

Так же появилось несколько изменений, которые важны для администратора.

• Dracut — новый механизм сборки initramfs по умолчанию. Он отвечает за ранний этап загрузки системы: подготовку драйверов, модулей, шифрования дисков и всего, что нужно до старта основной ОС.

• TPM-backed full-disk encryption — полнодисковое шифрование с привязкой ключей к TPM-чипу. Система может разблокироваться автоматически, если проверка целостности прошла успешно. Это удобно, но требует аккуратности при обновлениях BIOS или замене платы.

• CUDA и ROCm в репозиториях Ubuntu — упрощённая установка инструментов для вычислений на GPU, что полезно для ML.

Итог

Первое впечатление у меня положительное. Система установилась без сюрпризов, занимает умеренно места, по памяти выглядит адекватно, интерфейс работает плавно. В системе заявлено довольно много новых технологий, что обещает начало долгого марафона по настройке и тестированию. Будем смотреть, как Енот покажет себя в «боевых» условиях.

Не так давно я писал несколько постов о своем opensource движке, при помощи которого можно вести свой блог. И естественно мне за это навтыкали в комментариях, мол - какая нахрен CMS в 2026 году? Кому она вообще нужна?

Решил исследовать этот вопрос более тщательно и неожиданно для себя открыл одну важную вещь - узконаправленная CMS скорее всего действительно не нужна. А вот как инструмент для быстрого развертывания сайтиков - еще очень как.

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

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

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

Так вот к чему я? Прежде чем переносить сайт с тильды - я перелопатил штук 15 действующих CMS, на которых сейчас клепают сайты - включая всем известный WP и менее известную InstantCms. И ни один двиг не дал того, что мне было нужно.

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

Ни один движок этого не дает. (Ну или может я плохо искал).

Тут конечно я должен подвести к своей CMS - а вот моя так умеет! Пользуйтесь!

Сейчас вы подумаете: «Ага, сейчас он начнет впаривать свою CMS!» А вот нет. Не буду.

Потому что вопрос реально открытый: а нужна ли своя CMS в 2026 году? Или проще наваять на php под конкретного клиента мини-админку для управления сайтом-визиткой?

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

Авито:

1. Всё адово тормозит при рендере. Ему надо дать сильно подумать внутри браузера, прежде чем на что-то уже можно будет нажать. "эти компутеры в космос запускать можно, а вы одну кнопку нормально сделать не можете". Тупая фраза, но мысль передаётся.

2. Даже если сайт уже загружался ранее, то каждый раз он всё равно что-то подгружает и о чём-то там думает, прежде чем дать нажать на какую-нибудь элементарную кнопку, типа сортировки объявлений по дате на поисковой выдаче. Я жму на выпадающий список, а он не выпадает. Почему вы каждый раз заново грузите какой-то лютейший вагон .js - файлов, которые отвечают за эту кнопку и не даёте её нажать, пока это всё не прогрузится, ваши зумеры ещё не изобрели кеширование? Ребатя не понимают таких простых сайто-дизайнерских вещей, что кнопка не может не-нажиматься, если ты её уже показал.

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

4. Непродуманные элементы управления в принципе дофига где. Много слабо интуитивного, неудачные расположения, пропадающие элементарные фильтры в непредсказуемых местах. В одной категории фильтр "Б\У" есть, а если подняться в родительскую - уже нет. Почему? Например контр-интуитивен и туп сам факт того, что нельзя просто написать в строке поиска used:1 pricerange:100-500 и просто вывалить кучу всего бу из любых категорий от 100 до 500 руб. Какие-то выпадающие менюшки вокруг логотипа "авито" такие, что раскрываются и загораживают сам логотип, если ты попытался прицелиться в него (чтобы перейти на главную) и чуть промахнулся. Жмёшь на какой-то пункт этой менюшки в итоге.

Я вот просто в целом экономически не понимаю как так получается. Что за АвтоВАЗ? Там у вас победило "можно, а зачем"? За что вы платите 450к/сек фронтендерам? Видимо просто за "желательно ничего не сломать, но внедрить новую кнопку от партнёра". Ну ладно, допустим - корпорация, все заняты митингами и KPI, работать некогда, а исследовать внутренности google chrome и всё оптимизировать - тем более никто не даст. А в гугле почему дают? Там просто денег больше? Там это почему работает, хотя их ЦК КПСС в разы жирнее авитовской корпорации.

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

Извините, просто подумал вслух о помоечном состоянии user interface сабжа. Интересны скорее законы скатывания продукта в хламину и невозможность выделить бюджет на сравнительно небольшой отдел, доводящий лицо проекта до идеала, причём при условии бесконечных толстых потоков денег. Нельзя уволить на мороз какого-нибудь там директора департамента по HR или корпоративного психолога и закинуть освободившиеся 700 тыр в месяц в какого-нибудь гения в области google-chrome движка?

Давайте же разберем наш Designer(название сайта)!

1. шаблоны они конечно есть и в фигме но у нас есть и заданные шаблоны

2. Презентация, помимо статических баннеров вы можете создать и презентацию

3. Анимации:в сайте присутствуют инструменты для анимаций с разными скоростями эффектами

4. Экспорт: вы можете экспортировать в пнг веб сайт итд также можете и загрузить html/css код и посмотреть как он будет выглядеть

5. Все абсолютно бесплатно

На этом все мне всего лишь 15 лет надеюсь вы поддержите мой проект и перейдете в него если хотите расскажите о нем друзьям вот ссылка на сайт:https://designerweb.base44.app/

И наш тик ток:designer web

Спасибо за внимание ,также приложил скриншот

Cознание — это нелокальный, то есть недетектируемый никакими приборами внешний объект, который управляет вашим телом. Мы ввели термин, который называется qualia-оператор. qualia означает субъективный опыт. Оператор означает, что этот субъект управляет вашим телом. То есть, проще говоря, у вас есть душа.

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

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

Теперь, а как проверить эту синхронизацию эмпирически? А есть случаи наблюдаемые, где человеку после трансплантации сердца, вот ему пересаживают чужое сердце, и он как будто начинает ощущать память другого человека, донора этого сердца. То есть мы в модели прямо постулируем, что это остаточный эффект от вот той прошлой запутанности, которая была между qualia-оператором и его интерфейсом до этого. И это строго по ЭБЭ более логичное объяснение феномена, нежели то, что предлагает современная наука сейчас. Потому что совершенно с необходимостью не выводится.

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

Мы постулируем, что запутанность qualia-оператора и тела происходит в первую очередь через сердце. То есть покуда сердце работает, он остаётся запутанным с телом, но учитывая то, что произошло повреждение мозга, он не может оперировать этим телом. И следовательно, происходит вот этот разрыв. Ты ничего не помнишь, что было во время вот этого обморока, потому что твой мозг перестал функционировать рабочим образом. Однако сам qualia-оператор, само сознание, оно никуда не делось. Оно осталось запутанным вместе с телом. То есть запутанность своим паттерном существует до того, пока сердце бьётся.

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

Код реальности | Андрей Загидуллин Трудная проблема сознания РЕШЕНА. Куда мы уходим во сне и ПОСЛЕ СМЕРТИ

TLDR: TOML — удобный формат конфигураций, но ему не хватает поддержки null. Создатели языка осознанно отказались и отказываются добавлять null. Я столкнулся с этой проблемой при слиянии TOML-конфигураций в своём Python-проекте и решил её, форкнув популярные библиотеки и добавив в них поддержку значения null : tomli-null (парсер) и tomli-w-null (генератор).

TOML — популярный с недавних пор язык конфигурационных файлов, сочетающий избегающий проблемы других языков:

• TOML стандартизован, имеет типы данных, позволяет кодировать вложенные структуры (привет, INI);

• TOML относительно прост и парсится без хитростей (привет, YAML),

• синтаксис TOML легко читаем, поддерживает комментарии и не имеет нюансов вроде ошибок от далёких скобок и лишних запятых (привет, JSON).

TOML, согласно спецификации, "стремится быть минимальным форматом для файлов конфигурации, который легко читается благодаря очевидной семантике". С "минимальностью" языка в принципе можно поспорить — там и отдельные типы для даты/времени (4 штуки, 3 из них имеют варианты синтаксиса), и сахар в числовых литералах вроде 0xFF00_0000, и непростой синтаксис для ключей (чтобы допускать и сочетать простые ключи, составные ключи, произвольные ключи в кавычках).

Но вот что я совершенно не ожидал и проглядел, когда выбирал TOML основным форматом для человеко-редактируемых структур данных в своём проекте, — что в TOML нет null. Вообще. Это осознанное решение создателей языка. Разные аргументы против null, прозвучавшие за это время:

• "Если значение не определено, пару ключ-значение просто нужно не указывать." Нужно, не можно.

  Случаи, когда в приложении значение по умолчанию отличается от null, игнорируются.

• "null создаёт неоднозначность между значением null и отсутствием пары ключ-значение."

• "Если мы разрешим null, это повлияет на всю систему типов; например, целое число теперь будет не "целое число", а "целое число или null"."

  ???

• "Если очень нужно, вы можете использовать специальные значения по своему усмотрению: 0, -1, "", "null", [], {}. Ещё можно использовать дополнительные поля для обозначения наличия значения (типа { present=true, value=100500 }, или null_values = ["key_a", "key_c"])."

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

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

Для меня наличие null в подобном языке было само собой разумеющимся, я даже не думал об этом, когда разрабатывал сложный проект на Python, где файлы TOML пишутся и читаются человеком, пишутся и читаются программами, сливаются друг с другом. Когда я наконец-то напоролся на практике на отсутствие null (при слиянии конфигураций), менять всё на YAML было уже слишком поздно, а костыли добавили бы слишком много сложности.

Поэтому я форкнул пару библиотек и добавил в них поддержку null самым очевидным образом, не нуждающимся даже в примерах — просто литерал null на стороне TOML соответствует None на стороне Python.

• tomli-null — парсер, форк tomli (tomli включена в Python 3.11 как tomllib);

• tomli-w-null — генератор, форк tomli-w.

(100% покрытие тестами прилагается само собой.)

P.S. PyPI очень... интересным образом показывает информацию об авторах из пакета, несколько раз напоролся, пока пытался убрать автора оригинальных библиотек из поля "для связи" на сайте.

Мы любим тестирование и любим о нём рассказывать. Недавно мы, QA-лиды Настя и Катя, выступили перед студентами НГТУ, НГУ и Бауманки. Ниже — как всё прошло, что ценного вынесли для себя и почему горящие глаза студентов так заряжают.

Настя Золотых, технический руководитель группы QAA

Я люблю свою работу и люблю о ней говорить: и с коллегами, с которыми находимся в одном контексте, и с людьми извне — это крутая возможность посмотреть на свой опыт под другим углом и челлендж по объяснению на непривычном языке, с аналогиями и примерами не из мира IT. Так что когда появилась возможность выступить перед студентами АВТФ НГТУ с обзорной лекцией о профессии — я ни секунды не сомневалась, что это точно для меня.

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

Отдельно порадовала реакция ребят — около 20 вопросов про текущее и будущее тестирования, про карьерные перспективы и начало пути. Плюс позитивный фидбек от преподавателя.

Для меня это особенно ценно, потому что когда я заканчивала институт и выбирала профессию, то ничего не знала про QA, про это нигде не рассказывали — всё тестирование вокруг было в основном ручным, что меня не вдохновляло. Поэтому я пошла в бекенд-разработку и лишь спустя два года нашла своё настоящее призвание. Если кому-то из ребят я смогу помочь пораньше найти подходящую роль — буду по-настоящему счастлива!

Катя Лахтина, руководитель группы тестирования UGC (это я)

У меня было два выступления перед студентами НГУ и Бауманки, рассказывала про тестирование: что это за профессия, как устроена наша работа в 2ГИС, какие мифы существуют вокруг тестирования и как дела обстоят на самом деле. Делилась тем, какие возможности открывает эта сфера, и почему она важна.

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

Ещё мне важно говорить о культуре тестирования. Я собеседую кандидатов на вакансии тестировщиков и вижу, насколько разной бывает атмосфера в их командах.

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

А ещё такие встречи невероятно вдохновляют. Видеть, как у студентов загораются глаза, как они подходят после выступления, задают вопросы, интересуются тестовыми заданиями — это очень заряжает. Через их вопросы можно понять, как они мыслят, и это безумно интересно. В такие моменты понимаешь, зачем всё это — чтобы кто‑то из них вдруг подумал: «А вот это, кажется, моё».

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

Ранее космический корабль «Орион» с экипажем лунной миссии «Артемиды II» вернулся на Землю. Это событие произошло спустя чуть более чем девять суток после запуска. Приводнение спускаемой капсулы «Ориона» в Тихом океане произошло в 20:07 по времени Восточного побережья США (03:07 мск 11 апреля) в нескольких десятках километров от американского города Сан‑Диего (штат Калифорния). За время этой миссии экипаж пролетел 1,1 млн км, побил рекорд дальности полёта от Земли и сделал 7000 снимков Луны (фотографии путешествия к Луне, вокруг Луны).

Ракета‑носитель SLS с космическим кораблём «Орион» в рамках миссии «Артемида II» стартовала в среду в 18:35 по местному времени (01:35 мск, 2 апреля) с площадки Космического центра имени Джона Кеннеди (штат Флорида). Экипаж миссии: астронавты НАСА Рид Вайсман, Кристина Кук и Виктор Гловер, а также канадский астронавт Джереми Хансен.

Если повезло и после воды процессор выжил, а ушатали его прогревом - есть шансы что аппарат оживет и если да, то будет крутая статья с его оживлением, обзором, а я начну ходить с ним как с основным. Это же моя мечта!!!

Привычка — это важный инструмент изменения образа жизни, потому что он позволяет автоматизированно выполнять полезные действия, не задействуя волевой ресурс.

Раньше считали, что необходим 21 день, для получения устойчивой привычки, но в основном это касается простых повторяющихся действий, например, как пробуждение в одно и то же время.

Новый метаанализ рассмотрел закрепление более комплексных и сложных привычек, связанных с изменением образа жизни, в том числе в отношении питания и тренировок и пришел в медианному значению — 59–66 дней. А большинству более сложных изменений образа жизни требуется от 2 до 5 месяцев, чтобы стать автоматическими.

Вот несколько практических рекомендаций по тому, как правильно отрабатывать привычки.

Не одна, а много.

Я бы рекомендовал всегда помнить, что «питание» и «тренировки» — это не одна привычка, а комплекс маленьких.

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

«Недобрал сегодня белка на обед -> день и так провален -> вечером объемся мороженым».

Определите одну область, которую будете улучшать. Касаемо питания, я обычно рекомендую начать с оптимизации потребления белка и овощей. А можно и тут с чего-то одного: или белка, или овощей.

Определите триггер.

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

По сути, это триггер действия. Заранее планируйте, какое именно поведение хотите выполнить, когда вы это сделаете и как именно вы это сделаете.

Не просто: «Я постараюсь чаще ходить в зал».

А: «Я буду ходить утром перед работой, завтрак будет заранее продуман, а спортивная сумка будет собрана с вечера».

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

Желательно ещё заранее представить себе этот сценарий в голове.

Запланируйте награду сразу после привычки.

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

Склеивание привычек

Один из эффективных подходов — интегрировать новые привычки с уже существующими, создавая рутину.

Мы не просим себя “стать дисциплинированным”. Мы прикрепляем новое действие к тому, что у нас уже получается каждый день.

То есть не: «Ешь больше белка».

А: «Каждый раз, когда я завтракаю, в этом приёме пищи должен быть один понятный источник белка: яйца, творог, йогурт, мясо, рыба, протеин или бобовые».

Не: «Начни тренироваться регулярно».

А: «Во вторник и пятницу после завершения рабочего дня я не принимаю решение, идти или не идти. Я просто закрываю ноутбук, надеваю заранее приготовленную форму и еду/иду в зал».

Вот еще несколько частых вариантов таких «склеек», которые я использую, работая с подопечными:

Каждый сладкий перекус = после нормальной еды.

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

Каждый поход в магазин = базовая корзина.

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

Каждый вечер = подготовка одного элемента на завтра.

Не нужно готовить 12 контейнеров. Достаточно сварить яйца, разморозить мясо, поставить крупу, купить йогурт, нарезать овощи. Один элемент уже снижает трение.

Каждый завтрак = один фрукт или овощ.

Каждая доставка еды = плюс салат/овощи/дополнительный белок.