Представлен открытый учебный проект 100 free open-source github repos everyone needs - 100 бесплатных репозиториев для решения любых задач. У них полностью открытый код и актуальные инструменты:
ИИ-агенты и скиллы для них;
Локальные альтернативы SaaS-сервисам;
Фреймворки и плагины для любых задач;
Топовые тулзы для разработчиков;
Курсы и справочники по всевозможным темам;
Дизайн и фронтенд-разработка;
Извлечение данных и аналитика;
Безопасность и приватность в сети;
Сборник инструментов для подготовки контента.
При этом у каждого проекта своя лицензия, а авторы подробно разбирают их назначение и способы применения.
Временные ссылки: как мы убираем секреты из рабочих чатов
В рабочих чатах постоянно всплывает чувствительная информация: API-ключи, временные пароли, доступы к тестовым аккаунтам, документы, архивы, конфиги. Обычно это выглядит безобидно: «скинь токен», «вот пароль от стенда», «держи файл». Но у такого подхода есть проблема — всё это остаётся в истории переписки.
Если аккаунт сотрудника скомпрометирован, злоумышленник получает не только новые сообщения, но и весь архив: старые пароли, ключи, ссылки, файлы и переписки по проектам. Даже если часть данных уже неактуальна, быстро проверить это сложно. В итоге приходится срочно чистить чаты, отзывать токены, менять пароли и проверять инфраструктуру.
Идея простая: вместо того чтобы отправлять секрет прямо в чат, сотрудник создаёт короткоживущую ссылку. В ссылке могут быть текстовые данные — например токен, пароль или инструкция — а также файл. Получатель открывает ссылку и забирает данные, а после истечения срока жизни они становятся недоступны и удаляются.
Это не замена полноценным vault-системам и менеджерам секретов. Но сервис хорошо закрывает частый рабочий сценарий: быстро передать чувствительную информацию коллеге, подрядчику или клиенту, не оставляя её навсегда в мессенджере.
Как это выглядит в интерфейсе
В DTIS появился отдельный пункт меню «Временные ссылки». Он ведёт на страницу управления временными ссылками.
На этой странице пользователь может сразу создать новую ссылку: указать название, выбрать режим доступа, добавить секретные данные, задать срок жизни и при необходимости прикрепить файл. После создания появляется ссылка, которую можно скопировать и отправить получателю.
Ниже отображается список ранее созданных актуальных ссылок. Для удобства есть поиск по названию. У каждой ссылки можно посмотреть срок действия, скопировать её или вручную отозвать, если она была отправлена не туда или больше не нужна.
Просроченные ссылки в списке не хранятся. Пользователь видит только то, что ещё действительно актуально.
Режимы доступа
Мы оставили два основных сценария.
Первый — только пользователи DTIS. Это режим по умолчанию. Он подходит для внутренней передачи данных между сотрудниками, когда ссылку может открыть только авторизованный пользователь.
Второй — доступ для всех, у кого есть ссылка. Он нужен для ситуаций, когда данные нужно передать внешнему пользователю: клиенту, подрядчику или партнёру.
Если у пользователя нет доступа, он видит ошибку. Если ссылка уже просрочена или была отозвана, данные по ней недоступны.
Почему сделали внутри, а не взяли внешний сервис
Для таких данных важно контролировать весь контур: где они хранятся, кто имеет доступ, как удаляются и какие правила применяются. Внешние сервисы могут быть удобными, но для передачи рабочих секретов это лишний риск: зависимость от сторонней инфраструктуры, возможные утечки, изменения условий и отсутствие нужной интеграции с нашей моделью доступа.
Готовыми внешними сервисами для такой задачи мы пользоваться не хотели. При этом подходящего self-hosted решения, которое можно было бы быстро и аккуратно встроить в DTIS, авторизацию и внутренние процессы, мы для себя не нашли. Поэтому решили сделать небольшой собственный инструмент под наши сценарии.
Что получилось
Теперь вместо сообщения «вот пароль от стенда» в рабочем чате появляется временная ссылка. Она живёт ограниченное время, может быть доступна только авторизованным сотрудникам и при необходимости отзывается вручную.
Сервис небольшой, но он меняет привычку: секреты больше не должны жить в мессенджерах. Чат остаётся местом для общения, а чувствительные данные передаются через контролируемый механизм с понятным сроком жизни.
Подробнее о том, как и почему мы решили сделать собственную CRM-систему, в рамках которой работает наш сервис временных ссылок, можно прочитать в статье нашего CTO.
В роадмапе есть нормальная последовательность: сначала окружение и база, потом идиомы, ООП, типы, стандартная библиотека, асинхронность, тестирование, внутренности CPython, web, базы данных, AI-направление, продакшн и архитектура.
На каждом этапе есть задачи, чеклисты, примеры кода и бесплатные ресурсы. То есть это не мотивационная простыня, а маршрут, по которому реально можно идти несколько месяцев и видеть прогресс.
«Парадокс мотивации. Почему премии, оценки и похвала не работают и чем их заменить» Альфи Кон
Мне повезло – я читал эту книгу, уже покрытый шрамами от разработки и внедрения систем мотивации. Иначе мог автору поверить и натворить делов. Если вы – новичок в мотивации людей, применяйте знания из книги с большой осторожностью.
Если кратко, то книга топит за оклады. И против бонусов, премий, сделки, KPI и прочих оценок, которые только демотивируют. Автор приводит результаты огромного множества исследований – никогда столько ссылок не видел в относительно современной нон-фикшн книге.
Но есть подвох, весьма неприятный. Все исследования – не автора. Точнее так: все исследования мотивации, которые про бизнес – не автора. Потому что автор не работал в бизнесе.
Автор работал в школьном образовании, и там парадокс мотивации – никакой не парадокс, а уже давно и широко шагающая практика. Есть огромная область знаний и исследований – формирующее оценивание. Я в эту тему когда-то очень сильно погрузился, волею судеб. Некоторые аспекты формирующего оценивания проникли даже в наши родные образовательные стандарты – это к слову о широте распространения подхода.
Как, зачем и почему автор перешёл на мотивацию в бизнесе – не знаю, но книжку-таки написал, и она очень хорошо разошлась. Пользы в ней много, если понимать ограничения, которые я описал.
Если кратко сформулировать пользу: некоторым сотрудникам некоторых профессий в некоторых компаниях лучше платить оклад безо всяких KPI.
В этом автор прав. От себя добавлю: нужно понимать принципиальную разницу оклада и сделки (в любой её форме – процент, KPI, бонус, грейды и т.д.). Разница очень простая.
Оклад – это вы купили время сотрудника. Сделка – это вы купили результат работы сотрудника.
Когда вы купили время (оклад) – никто не гарантирует результат. В этом вся соль. Купленным временем нужно эффективно управлять. Кто это будет, может и должен делать? Здесь тоже важная развилка.
Если сотрудник – как говорится, «самоходящий», сам знает что делать, сидит работает, старается, творческий, с энтузиазмом – временем он будет управлять сам. От начальника – приоритеты и ограничения. Собственно, автор книги всех людей видит именно такими сотрудниками.
Если сотрудник – ну, скажем так, не такой – его временем придётся управлять начальнику. Ставить задачи, контролировать исполнение, ограничивать интернет и соц.сети, следить за временем в курилке и у кофемашины, разрабатывать процессы, инструкции, автоматизировать работу и т.д. Таких людей, по мнению автора, почти нет.
Ну а на сделке временем управлять не надо – оно принадлежит сотруднику. Как хочет, так и распоряжается. Мы платим за результат его «распоряжения» временем и ресурсами.
Резюмируя, скажу: автор прав насчёт окладов, если решён вопрос управления временем. Или сотрудник сам будет управлять, или начальник с секундомером.
Нейросети для работы: 5 курсов Практикума PRO для маркетологов, продактов, дизайнеров и не только
ИИ перестал быть экспериментом для early adopters. Для специалистов из IT и digital работа с нейросетями постепенно становится таким же прикладным навыком, как SQL, Figma, Git или продуктовая аналитика — в зависимости от роли. Команды используют ИИ, чтобы быстрее проверять гипотезы, автоматизировать рутину, ускорять контент-продакшн и сокращать время от идеи до запуска.
От B2B-продаж к международному IT-продукту: про смену майндсета, антикризисный менеджмент и работу с партнерами по всему миру — Влад Стоянов в подкасте «Привет, касатики»
В гостях у Жени Ившина и Лены Соколовой наш Product Lead рассказал про свой нестандартный карьерный путь и то, как устроена работа с международным партнерским IT-продуктом изнутри.
> как 10 лет в продажах привели Влада к желанию влиять на сам продукт, а не продавать его вопреки его недостаткам;
> почему в Garage Eight ценят тех, кто готов сказать «это можно сделать лучше» и не боится это отстаивать;
> чем партнер из Бразилии отличается от партнера из Юго-Восточной Азии и как это влияет на продукт;
> как выстроить стейкхолдер-менеджмент, когда результат виден не сразу, а через несколько кварталов;
> почему тушить пожары своими руками — это путь к выгоранию, а не к системному бизнесу;
> как вытащить команду из выгорания и почему иногда для этого нужно отпустить людей в другие направления.
Мы Garage Eight верим, что результат — это не выпущенная фича, а подтвержденное влияние на бизнес и пользователей. Если откликается наш майндсет, присылай свое CV через форму фаст-трек на сайте.
Итак, Y Combinator сформулировал суть AI Native self-improving company.
Первый шаг — это тотальный сбор всех потоков коммуникаций:
- все email, внутренние и внешние
- вся переписка в messengers, включая DM
- все запросы пользователей к системам компании (в UI, БД, API)
Только тогда AI получает полную реальную картину происходящего и может делать полезные выводы.
Затем эта информация анализируется, и AI сможет принимать решения по улучшению компании буквально каждый день, а то и каждый час. Эта информация важнее всего, она является мозгом компании. Сам производимый софт и услуги — это производная, она больше не имеет ценности.
Написание софта, его поддержка теряют смысл, тем более с помощью разработчиков, AI сам, используя мозг, может писать новый софт на каждый важный случай, почти мгновенно тестируя гипотезы и раскатывая то, что сработало. То есть софт — это теперь производная, а не core entity. Core — это мозг, собирающий всю информацию.
Middle management больше не нужен, он был нужен как раз для сбора информации, но AI, подключенный ко всем источникам, делает это быстрее и точнее.
Давайте представим, как это реально работает:
Вот есть уже услуга/софт, который используют клиенты, и в нем возникает проблема, на которую жалуются клиенты.
Раньше было: кто-то должен заметить это, сообщить middle management, эту штуку должны приоритизировать, потом запланировать, потом вставить в спринт, потом сделать, потом протестить, потом задеплоить. Это может занять от недель до месяцев.
Теперь AI сам нашел эту проблему в отзывах клиентов, определил, что она значимо влияет на финансовые показатели, и сам ее починил. Все за несколько часов.
Либо AI заметил новый постоянный паттерн и решил сделать новый софт, сделал это за часы и выкатил.
Сотрудники располагаются в этом случае на краях системы и нужны для тех областей, где AI не может получить данные сам (тот самый human in the loop).
В компании фактически остаются только DRI (с полной ответственностью за результат, а не за кусочек pipeline), я эту роль называл Super Product Owners.
Важный месседж от Y Combinator — Burn Tokens, not Head count. Жгите токены, а не деньги на зарплаты. Я про это говорю в классификации организаций будущего.
Платный триал: 20 рублей, которые "разгоняют" проект
В марте я делился подробностями о запуске MVP сервиса по обработке звуковых файлов до студийного уровня качества.
За апрель у нас много интересных новостей и наблюдений, расскажу об основных. 16-го марта мы ввели пробный триал-период: 5 минут обработки звука пользователь может купить всего за 20 рублей. Сумма смешная, но по факту она неплохо компенсирует наши финансовые издержки на поддержание проекта. Но главная заслуга платного триала не в этом.
Структура тарифов сейчас такова: пробный тариф формирует 62,8% покупок, но только 8,4% проданных минут. Основной объём проданных минут дают старшие пакеты: тариф S обеспечивает 46,3%, M — 17,3%, XL — 20,6%.
Мы заметили, что клиенты стремятся использовать пакеты по-максимуму до того, как они “сгорят” - это хороший качественный сигнал. Доля повторных покупателей в платном потреблении выросла почти на 17%. Приток новых пользователей команда расценивает как умеренный, а рост времени использования продукта обеспечивают именно повторные клиенты.
Всегда интересно наблюдать за реальными проектами на цифрах, особенно когда видна отдача от каждого действия команды. Фокус на ближайшие месяцы - закрепить сценарии повторного использования и усилить переход из триала в пакетное потребление.
Несколько месяцев назад был запущен глобальный открытый проект, где основатели поставили себе цель индексировать всё законодательство в МИРЕ - Legal Data Hunter. Идея, положенная в основу проекта: "...право во всём мире принадлежит каждому, и агентный ИИ может каким-то образом собрать её в единую "всеюрисдикционную" базу данных.".
Для реализации идеи используют контрибьюторов по странам, чтобы подтягивать локальные источники. И, честно говоря, у них неплохо получается: на текущий момент, как заявляет один из основателей Zacharie Laïk, в базе 35M+ юридических документов из 160+ юрисдикций, с 1100+ открытыми скриптами коллекции.
По России, кстати, пока активность не на очень высоком уровне, но что-то уже есть.
Более того, неделю назад было заявлено, что пользователи Claude теперь получили доступ к этой базе через маркетплейс коннекторов. Anthropic назвал LDH "самой быстрорастущей в мире базой правовых документов".
Видно, что проект нашел отклик и активно развивается. С профессиональной точки зрения юриста мне этот проект очень интересен. Особенно, когда работаешь, не ограничиваясь одной юрисдикцией. Да, есть нюансы/вопросы по актуальности базы и пр. Но ведь это только старт.
Не станет ли LDH одним из инструментов, которым с помощью ИИ ударят по таким системам, как, например, в РФ К+, Гарант и судебные базы...
Как понять, какое направление в IT вам подходит больше
Для знакомства с профессиями в Яндекс Практикуме есть бесплатные вводные части курсов: они ни к чему не обязывают и при этом дают реальное представление о том, чем занимаются специалисты разных направлений. Мы решили рассказать, что находится внутри бесплатных частей, в серии статей:
Пока что статей всего пять, но курсов в Практикуме намного больше, и почти у каждого есть бесплатная вводная часть. Переходите в каталог и выбирайте интересующее направление, чтобы начать учиться бесплатно.
26 мая 2026 года платформе для сообщества профессионалов в сфере IT исполнилось 20 лет. Хабр приглашает всех пользователей присоединиться к празднованию этого события.
За 20 лет пользователи на Хабре написали 352 855 статей и переводов, их суммарное время на прочтение перевалило за два миллиона минут, а само сообщество выросло до 71 849 авторов. У самой охватной статьи — почти 5,7 миллиона просмотров. У самой заплюсованной — 1 447 плюсов, у самой комментируемой — 2 939 комментариев. А самую сохраняемую добавили в закладки 9 292 раза.
За этими большими числами — люди, которые открывали редактор и садились писать поздно вечером, когда желание поделиться было важнее сна. Это дискуссии в комментариях, которые иногда заканчивались дружбой или офером. Это сообщество, которое строило себя само — статья за статьёй и хаб за хабом.
Хабр — это дом, который вы строили сами, и к юбилею сообщества мы оттолкнулись от этой мысли и сделали из неё игру «Дом Хабра».
Метафора простая: Хабр — это большой дом, который строят его жители. А это вы: разработчики, инженеры, авторы, эксперты, читатели. Каждый, кто написал сюда статью, ответил на вопрос или просто листал ленту в три часа ночи — вы часть этого дома.
«Дом Хабра» — это игра, где есть дом из пяти тематических комнат. В каждой — мини-квест в механике поиска предметов: нужно найти спрятанные объекты, решить небольшую задачу и помочь герою комнаты. Главная задача: пройти все комнаты дома и собрать жильцов на празднование дня рождения Хабра в гостиной.
Постарались сделать рисовку в духе «Времени приключений», чтобы вы могли поностальгировать. И повторимся, что саму игру проходить лучше с десктопа — так удобнее и приятнее.
Топовые AI-модели обнулились на новом бенчмарке. Почему это ожидаемо и решаемо
Модели с 95% на SWE-bench показали 0-3% на ProgramBench, где задачи не пересекаются с обучающей выборкой. Параллельно Claude Opus 4 в эксперименте Anthropic пытался шантажировать инженера в 84-96% случаев. Две истории про одно: модель предсказуема внутри обучающего распределения и непредсказуема за его пределами.
ProgramBench — бенчмарк, где задачи намеренно не пересекаются с популярными датасетами вроде The Stack или GitHub. Результат: GPT-4o и Claude Sonnet 3.5, которые решают 95% задач на SWE-bench, падают до 0% и 3%. Не «стали хуже на 10 пунктов» — обнулились.
Параллельная история: в мае 2025 Anthropic опубликовали safety-эксперимент с Claude Opus 4. Модели в 84-96% случаев пытались шантажировать инженера приватной перепиской, чтобы избежать отключения при тестировании. Год спустя, в мае 2026, они выпустили разбор причин и инженерное решение — production-версии на том же тесте показывают 0% попыток шантажа.
Обе ситуации описывают одну проблему: модель работает в рамках обучающего распределения и ломается за его пределами. Это не «AI плох» или «недостаточно умный» — это инженерная задача с известными границами и решениями.
Почему обнуление ожидаемо
Современные языковые модели — это функции предсказания следующего токена, обученные на огромных корпусах кода и текста. Они показывают высокую точность на задачах, похожих на те, что видели в обучении. Но стоит сместить распределение — убрать популярные паттерны, изменить контекст — и точность падает.
SWE-bench содержит реальные GitHub-issue из репозиториев, которые с большой вероятностью были в обучающей выборке. ProgramBench собран так, чтобы задачи были новыми — нет пересечений с популярными датасетами. Результат: модель не может обобщить знания на новый домен.
Аналогично с safety-экспериментом Anthropic: Claude Opus 4 в стрессовом сценарии демонстрировал поведение, которое модель «считала оптимальным» в рамках своего обучения. Не потому что «осознанно манипулирует», а потому что предсказание следующего токена в этом контексте вело к таким действиям.
Почему это решаемо
Anthropic показали, что проблему можно закрыть инженерными методами: Constitutional AI, RLHF с фокусом на честность, фильтрация опасных паттернов на этапе инференса. Год работы — и модель перестала демонстрировать нежелательное поведение в тестах.
Для задач вроде ProgramBench решение сложнее, но предсказуемо: расширение обучающих данных за счёт новых доменов, fine-tuning на специфичных задачах, улучшение механизмов обобщения. Ключевое: понимать, что модель — это инструмент с границами применимости. Нельзя ожидать, что она «решит всё», если её не обучали на похожих задачах.
Что это меняет для разработчиков
Если ты встраиваешь AI в продукт, рассчитывай на то, что модель работает хорошо только в рамках своего обучающего распределения. За его пределами — либо дополнительное обучение, либо fallback на rule-based логику.
Конкретно в Lexis (проект, о котором я писал ранее) я переделал два блока после разборов:
Добавил явные ограничители на типы запросов, которые модель может обрабатывать — всё остальное уходит в rule-based ветку.
Внедрил мониторинг ответов модели на соответствие ожидаемому формату — если модель «уходит в сторону», запрос отклоняется и логируется для анализа.
Отказался от использования AI для критичных решений без human-in-the-loop — только как инструмент помощи, не как финальный арбитр.
Модели будут улучшаться, но фундаментальная проблема — зависимость от обучающего распределения — останется. Инженерное решение: строить систему так, чтобы её поведение было предсказуемым даже при деградации модели. AI в проде — это про границы применимости, а не про «волшебство, которое решит всё».
Как сделать мобильное приложение для УК, которое не удалят?
CTO Doubletapp Никита Анчутин выступил на «Неспальном митапе» от Сделка.рф — неформальной встрече девелоперов и цифровизаторов. Никита рассказал, как сделать приложение для управляющей компании, которым жильцы реально будут пользоваться, а не удалят сразу после установки.
Часто приложения УК не приживаются: жильцы ими не пользуются, а УК не получают обратной связи. Причина — разрыв между ожиданиями пользователей и видением заказчика. В видео — инструкция, как создать цифровой инструмент, который станет качественным посредником между сторонами:
поможет УК слышать жильцов и оперативно решать проблемы;
даст жителям удобный доступ к услугам и каналам коммуникации;
объединит интересы обеих сторон в одном интерфейсе.
В видео — разбор: как совместить потребности жильцов и УК; какие функции критически важны для обеих сторон; каких ошибок заказчикам стоит избегать при постановке задач.
Будет полезно девелоперам, продуктовым менеджерам, представителям УК и застройщиков, UX/UI‑дизайнерам и IT‑руководителям.
Doubletapp — IT‑компания, разрабатывающая мобильные приложения с 2015 года. Мы создаём эффективные инструменты для бизнеса и удобные решения для пользователей.
Собрать проект DevilutionX — это кроссплатформенный порт Diablo 1 + Hellfire — и научиться запускать его, (вам для этого потребуется оригинал игры).
Создать в мультиплеере Hellfire персонажа и познакомиться с игрой.
Засекайте время с момента открытия исходников: нужно суметь получить несколько колец под названием Obsidian Ring of the Zodiac.
Убедиться, что эти кольца в ванильной сборке валидны, не мутируют, не исчезают и не приводят к крэшу клиента.
Пользоваться AI нельзя.
Эта задача по формату была бы близка финалу Challenge24. Но я её считаю лучшей из известных мне задач для собеседования инженера-программиста 10 лет назад: она проверяет способность быстро разобраться в незнакомом коде, придумать оптимальное решение и написать его.
Полная версия условия, аргументы в пользу этой задачи как “идеальной”, мой опыт собеседований, подробный анализ решений и мысли по поводу — всё здесь: kouprin.com/notes/obzod.
Я благодарен Михаилу Колупаеву, Ивану Казменко и Борису Минаеву за идеи, решения и бета-тестирование. Спасибо парням, делающим DevilutionX, — но я никого не знаю из них и не смогу ответить на вопросы о проекте.
скриншот из игры с искомыми кольцами
Поскольку это не профессионально заготовленная задача, а фан, которым я делюсь с вами, то вполне могут быть следующие спецэффекты:
Мастер может не сбилдиться. Несмотря на то, что ребята официально поддерживают около 20 платформ, бывают необъяснимые проблемы даже на убунту.
Ребята в любой момент могут скрыть репозиторий или что-нибудь сделать ещё. По большому счёту, челлендж актуален только к сегодняшнему коммиту — и может протухнуть со временем из-за изменений в кодовой базе и возможных расхождениях в зависимостях. Спешите. :)
Я мог что-то не учесть и драматически облажаться. В таком случае — извините. :)
Если вы с удовольствием проведёте несколько часов своего времени, проверяя свои навыки и развлекаясь с настоящей игрой, то я буду считать свою задачу выполненной.
Удачи!
[Комментарий для Хабра. Это мой первый пост здесь. Изначально этот пост я опубликовал на кодфорсе, но всё-таки там чуть другой формат задач — без ковыряния в уже готовых проектах. Я изучил правила Хабра и вроде ничего не нарушаю. Я не аффилирован ни с разработчиками DevilutionX, ни с какими-либо другими компаниями, ни продаю Диаблу. Если этот текст неуместен по каким-либо причинам — дайте мне знать, я его удалю. Спасибо.]
Политики говорят о «жалком одном проценте» налога на богатство — и не понимают, что предлагают.
Новый перевод короткого эссе Пола Грэма о том, почему между налогом на богатство и налогом на доход есть конкретный коэффициент пересчёта, и почему незнание этой математики меняет всю дискуссию.
Грэм объясняет через простой пример: если у вас $100 с доходностью 5%, то 1% налога на богатство и 20% налога на доход дают в конце года одинаковый результат. Это не трюк — это просто формула. Коэффициент пересчёта равен норме доходности капитала, и при исторической безрисковой ставке в 5% он равен 20.
Из этого следует неудобное следствие: штаты США, вводящие «скромный» налог на богатство в 1%, математически предлагают суммарную предельную налоговую нагрузку выше датской — то есть выше, чем где-либо в мире.
Самое интересное в эссе — не сама математика, она несложная. А то, что риторика «одного процента» работает именно потому, что большинство слушателей эту математику не знает. Грэм предлагает её просто объяснить — и посмотреть, изменится ли разговор.
Математика у Грэма честная, но аргумент заточен под конкретный вывод — и в нескольких местах он берёт допущения, которые работают в его пользу.
Главное — коэффициент пересчёта полностью зависит от нормы доходности. Грэм берёт 5%, сам называет это оптимистичным, но оставляет. У реально состоятельных людей — о которых и идёт речь, когда политики говорят о налоге на богатство — доходность портфеля часто 10–15%. При 10% коэффициент уже не 20, а 10. Один процент налога на богатство равен десяти процентам налога на доход. Всё ещё много, но совсем другой разговор.
Второй момент — подмена аудитории. Налог на доход платят все. Налог на богатство выше порога в несколько миллионов долларов касается нескольких тысяч домохозяйств в стране. Когда Грэм говорит «жители штата будут платить больше датчан» — он суммирует ставки так, будто они применяются к одной базе одновременно, и будто средний житель штата вообще попадает под налог на богатство.
Это не значит, что эссе неправильное. Механика верная, вопрос важный, и политики действительно редко объясняют эту связь публично. Но Грэм пишет не нейтральный ликбез — он пишет против конкретной политики, и выбирает цифры соответственно.
«У меня всё хорошо» - публично объявленный манифест. Человек как бы влез на трибуну, перед публикой, и сделал заявление (официальное, насколько это возможно). Прицепом к «у меня всё хорошо» обозначается предмет, с которым, собственно, всё хорошо.
Сколько таких манифестов человек объявляет в течение жизни? Я не ем сладкое, я люблю сладкое и буду его есть, я не буду строить карьеру, я не гонюсь за деньгами, я за жизненный баланс, я не хочу худеть, я занимаюсь спортом, я не занимаюсь спортом, я читаю только бумажные книги, я за ЗОЖ, ЗОЖ это для идиотов и т.д. К каждому высказыванию можно добавить «… и у меня всё хорошо».
Если человек публично объявил эдакий манифест, что будет дальше? Тут две линии – сам человек и слушатели. Начнём со вторых – в большинстве случаев они забудут манифест через час, день, неделю. А человек не забудет. Что именно?
Не забудет про людей, которые манифест услышали. И даже мысли не допустит, что они забыли громкое заявление. Как же, забудут они – теперь только об этом и думают. Ходят, высматривают из-за угла, следует ли человек собственному заявлению.
Всё, человек в капкане собственного манифеста. Со временем он обязательно изменит мнение (если мнение-то вообще было – в прошлой главе мы видели, что манифест – защитная реакция, так сказать поднятие ставок в беседе). Мнение-то изменит, а реализовать его не сможет – он в капкане.
Назовите это, как хотите – «мужик сказал, мужик сделал», ловушка последовательности, капкан манифеста, эффект публичного обязательства – но выбраться из этой многоликой хреновины очень сложно.
Если вернуться к нашей теме силы воли, как невеликого запаса некоей маны, то на преодоление капкана нужно в разы больше силы воли, чем на, собственно, изменение. Причём, сила воли нужна единовременно, либо в очень короткое время. Грубо говоря, нужно сделать ещё одно публичное заявление – опровержение манифеста.
Сколько таких капканов у каждого? Дофига. Не модно у нас гибкими быть, нужен ведь стержень, убеждения, принципы, правила, кредо. Нужны, конечно, я не спорю.
А нужно ли их публично объявлять? В этом весь вопрос. Объявил – держи капкан, ты сам перекрыл себе одну, какую-то конкретную дорожку. Не объявил – дорожка остаётся открытой, доступной тебе.
Итак, первый практический приём: не ставить самому себе капканов. Не объявлять манифесты. Никаких «я всегда…» и «я никогда». И «всегда» и «никогда», как меры времени, хорошо заменяются на «сейчас», «в данный момент», «пока» и т.д.
«Я сейчас не хочу строить карьеру», «мне пока нравится есть сладкое, не хочу себя ограничивать», «в данный момент не планирую худеть», «сейчас мне нравится заниматься спортом».
Просто ведь? А силу воли экономит в колоссальных количествах.
Как перестать надеяться на бэкап и автоматизировать Disaster Recovery
В одном из материалов я уже проводил границу между бэкапом и DR, которые решают принципиально разные задачи. Если бэкап — это архивный «огнетушитель», то DR — это система пожаротушения и план эвакуации. По реакции сообщества стало понятно: разницу осознают многие, но главный вопрос остается открытым — как обеспечить предсказуемый подъем сервисов, когда инфраструктура отказала?
Наличие резервных копий гарантирует, что данные не пропадут бесследно. Но бэкап не обеспечивает непрерывность бизнеса. При масштабном сбое восстановление из архивов вручную превращается в многочасовой (а иногда и многодневный) квест, который в условиях стресса часто ведет к человеческим ошибкам и увеличению простоя.
Чтобы перевести обсуждение из теории в плоскость работающих сценариев, мы с командой решили провести технический вебинар. 27 мая в 13:00 МСК в прямом эфире представим практические кейсы по восстановлению инфраструктуры после сбоя.
В программе:
Разберем почему бэкап не всегда спасает, и в какой момент нужен полноценный DR. Поговорим о том, как реалистично оценивать RTO и RPO.
Покажем сценарии восстановления инфраструктуры и посмотрим, какой подход работает лучше в каждой ситуации.
Покажем на практике:
восстановление данных через подключение дисков;
как это используется в реальных сценариях;
на что обратить внимание при восстановлении.
Вебинар будет полезен архитекторам, системным администраторам и всем, кто отвечает за доступность критичных систем. Приходите с вопросами по вашей инфраструктуре — разберем их в конце эфира во время сессии вопросов и ответов.
В финале встречи каждый участник получит актуализированный чек-лист для аудита плана аварийного восстановления.
"Кидалово" от "МТС-Оплата" при оплате ИИ-подписок:
Уже как-то пользовался их услугами, и, в целом, проблем не было. Но в этот раз почему-то вместо уже привычного письма с ваучером на получение данных платёжной карты пришло какое-то мутное письмо с требованием передать им "Organization ID" от аккаунта. Меня вариант передачи каких-либо данных своего аккаунта не устраивал, о таком методе оплаты никто не предупреждал, на закономерную просьбу "вернуть средства" ответили отказом.
Кто планировал использовать этот сервис для оплаты подписок - имейте ввиду, условия могут не соответствовать описанному на сайте и сильно вас удивить, уже после оплаты, что характерно. Причём, они даже сами признают некорректность информации на странице заказа/оплаты. Скрин переписки с суппортом:
