«Не верьте продавцам страха»: поговорили про ИИ и разработку с Тимуром UlbiTV
Недавно в гости на подкаст к нашему техлиду Саше Стародубцеву заглянул фронтенд-мастодонт и автор популярного YouTube-канала и Telegram-сообщества Тимур UlbiTV.
В выпуске ребята обсуждают:
заменит ли ИИ разработчиков;
агентов и автоматизацию разработки;
вайб-кодинг и качество кода;
найм, стажеров и джунов в эпоху ИИ;
обучение с ИИ и пет-проекты;
эволюцию и будущее разработки.
От ядра Linux до дообучения языковых моделей: открытые вебинары недели
Как устроить обмен сообщениями между сервисами, найти причины сбоев в распределённой системе, превратить бизнес‑требования в понятные задачи или подготовить модель к работе в реальной среде?
С 3 по 6 августа эксперты OTUS проведут 24 бесплатных демо-урока по разработке, инфраструктуре, архитектуре, аналитике, машинному обучению и другим направлениям. Выбирайте интересующую область и присоединяйтесь.
Системное администрирование, сети и безопасность
3 августа, 20:00. «Что такое модуль ядра. Как его написать, собрать, запустить». Записаться
3 августа, 20:00. «MPLS для корпоративных сетей: мифы, реальность и практика». Записаться
3 августа, 20:00. «Какие результаты должен давать DevSecOps‑проект бизнесу и команде». Записаться
4 августа, 20:00. «OpenTelemetry — наблюдаемость на блюдечке». Записаться
Разработка и программирование
3 августа, 20:00. «Использование брокера сообщений Apache Kafka в распределённых очередях». Записаться
3 августа, 20:00. «Оживляем код: первые шаги в ООП на Python». Записаться
3 августа, 20:00. «Go: управляем памятью как профи. Массивы, слайсы и мапы». Записаться
4 августа, 20:00. «Многозадачность в Python: асинхронность, процессы, потоки». Записаться
4 августа, 20:00. «Секреты межсервисных запросов: как сделать приложение быстрым и надёжным». Записаться
5 августа, 20:00. «Битва нативных платформ: Spring Boot 4, Quarkus, Micronaut, KMP, Go и Rust». Записаться
5 августа, 20:00. «Как AI меняет работу C#‑разработчика». Записаться
Архитектура, системный и бизнес‑анализ
4 августа, 19:00. «Будущее корпоративного архитектора: навыки, тренды, технологии». Записаться
4 августа, 20:00. «Как аналитику работать с рисками». Записаться
5 августа, 20:00. «Влияние нефункциональных требований на архитектуру». Записаться
5 августа, 20:00. «MVP глазами бизнес‑аналитика: от идеи до первых функций». Записаться
6 августа, 20:00. «Пользовательские сценарии на реальном примере: от бизнес‑требования заказчика до формулирования задачи для разработчика». Записаться
Машинное обучение и работа с данными
4 августа, 20:00. «PostgreSQL как память ИИ‑агентов: MVCC, очереди и партиции под нагрузкой». Записаться
5 августа, 20:00. «Сделайте модель своей: дообучение LLM методом QLoRA без кода». Записаться
6 августа, 18:00. «Практика работы с Docker — ввод модели в эксплуатацию». Записаться
6 августа, 20:00. «Базовая структура ML: задачи, pipeline, метрики и функции потерь». Записаться
Битрикс24
3 августа, 20:00. «Кастомизация компонентов в Битрикс24». Записаться
4 августа, 19:00. «Эффективная работа с диском Битрикс24». Записаться
Управление проектами
5 августа, 20:00. «Оценка проекта: от интуитивных догадок к системному подходу». Записаться
Тестирование игр
4 августа, 20:00. «Как стать тестировщиком игр: первый шаг в GameDev». Записаться
Больше открытых вебинаров августа по разработке, инфраструктуре, аналитике, управлению и другим направлениям собрали в дайджесте месяца.
Один оператор сравнения чуть не удалил тысячу пользователей
На днях наводил порядок в логике автопродления подписок Telegram-бота.
Казалось, задача на полчаса.
Если кратко: у пользователя заканчивается подписка, и бот проверяет дату планируемой оплаты.
Если срок подписки истёк и продления нет, то пользователь попадает в очередь на удаление. Всё просто.
Проблема обнаружилась случайно.
Я решил прогнать сценарий сразу на нескольких тестовых пользователях. Один из них только что оплатил подписку, но бот всё равно пометил его как кандидата на удаление.
Сначала я подумал, что платёж не успел записаться в базу. Проверил – платёж записался.
Потом начал искать проблему в часовом поясе. Тоже нет.
Дальше полез смотреть SQL-запросы, логи, время выполнения задач. Потратил на это больше часа и уже начал подозревать, что где-то появилась гонка между обработчиком платежей и задачей проверки подписок. Стал разбираться…
Причина оказалась намного проще: в фундаменте не стоял тот оператор сравнения.
Вместо subscription_end < now
я написал subscription_end <= now.
Из-за этого подписка была просроченной не только после истечения срока, но и ровно в момент его окончания. Если время проверки и обновления совпадало, пользователь попадал в удаление по граничному условию.
Если задача проверки запускалась в тот же момент, когда обновлялась дата окончания подписки, пользователь попадал в удаление при совпадении времени окончания и времени проверки .
В большинстве случаев этого не происходило, но иногда баг воспроизводился. Именно такие баги самые неприятные, потому что они появляются случайно.
И чем больше пользователей становится, тем чаще начинают всплывать.
В тот момент у меня была тестовая база, поэтому последствия не были бы критичными. Максимум, произошло бы несколько некорректных удалений.
Но я сразу представил, что было бы в продакшене. Если бы ошибка попала в релиз, задача удаления прошлась бы по всем пользователям, которые удовлетворяли этому условию.
И если совпали бы время запуска задачи и обновление подписок, ошибочно удаленных пользователей было бы несколько сотен или тысяч.
Что изменил:
1. Перенастроил удаление: теперь оно происходит не сразу.
Пользователь сначала получает статус "ожидает удаления", а сама операция выполняется отдельной задачей через некоторое время.
2. Настроил перепроверку актуального состояния подписки через x часов, чтобы отсечь ложные срабатывания.
Если пользователь оплатил доступ или подписка продлилась, удаление отменяется.
3. Добавил тест на этот сценарий, чтобы избежать повторения <=ошибки.
Раньше я проверял только обычные случаи.
Теперь отдельно проверяются пограничные значения времени.
Мораль:
даже очевидные условия нужно проверять на границах.
Смотришь на условие и кажется, что ошибиться невозможно. Но однажды выясняется, что была допущена элементарная ошибка, которая убила тонну времени.
Всегда нужно помнить о границе условий. Именно там чаще всего и живут самые неприятные ошибки.
Есть ощущение, что подобные баги зачастую находятся не в сложной логике, а в самых очевидных местах?
Интересно, как вы предостерегаете себя от таких стыдных ошибок?
Открытый проект .MD this page позволяет преобразовать веб-страницу в чистый Markdown, готовый для ChatGPT, Claude, Gemini и других нейросетей. Решение очищает код сайта от рекламы, баннеров и другого мусора для отправки на обработку в ИИ. Есть предпросмотр, экспорт в .md и опция для мгновенного копирования сайта.
Как Kubernetes, Jira и Keycloak не помогли выпустить продукт
Небольшой повод похвастаться: меня начали звать на технические аудиты не только по работе, но и просто как специалиста.
Первый кейс сразу интересный. Есть команда из трёх разработчиков, больше 30 репозиториев, Kubernetes, Helm, Argo CD, Keycloak, Jira и куча другой инфраструктуры. Нет только новой версии приложения, которую заказчик может нормально открыть в браузере.
У заказчика уже есть работающий продукт примерно на 3000 активных пользователей в месяц. Пользователи покупают подписку и получают доступ к текстам, фотографиям и видео.
Заказчик решил обновить приложение и нанял отдельную команду. Прошло довольно много времени, но внятного результата он так и не увидел.
Разработчики говорят, что проблема в непонятном ТЗ. Заказчик говорит, что команда не отвечает на вопросы, не доводит решения до конца, а то, что показывает, регулярно не работает.
Меня позвали разобраться.
Первым делом я попросил доступ к коду. Код лежит в собственном GitLab. Правда, сам GitLab периодически тоже лежит, поэтому попасть туда получилось не сразу.
Когда доступ появился, меня встретила авторизация через Keycloak.
Напомню: разработчиков трое.
Спрашиваю, как деплоят. Kubernetes, Helm, Argo CD. Открываю список репозиториев, а их больше 30. Часть занята общими библиотеками и Docker images, но большая часть приходится на отдельные сервисы.
Потом выяснилось, что у команды есть собственные registry, Jira, Grafana, VictoriaMetrics и ещё пачка инфраструктурных компонентов.
Всё это работает на мощностях заказчика. Точнее, периодически работает. То GitLab недоступен, то проблемы с кластером, то ломается ещё что-нибудь. А отдельных людей, которые могли бы постоянно следить за этим зоопарком, нет.
Старая версия приложения продолжает обслуживать пользователей. У новой тоже есть production-контур, но он сильно отстаёт от dev и пока не соответствует требованиям.
Frontend вроде бы существует. Но вживую я его до сих пор не видел, только на скриншоте.
Сколько функций действительно готово, тоже непонятно. Приёмочные испытания ещё не начались, потому что критерии приёмки всё ещё согласовывают.
Получается странная картина. Инфраструктура уже сложная. Репозиториев много. Инструментов ещё больше. А общего понимания, что считается готовым продуктом, до сих пор нет.
Дело не в том, что Kubernetes, Jira или Keycloak плохие. Вопрос в том, зачем всё это понадобилось именно сейчас и кто должен это обслуживать.
Если команда из трёх человек построила инфраструктуру, за которой не успевает следить, значит, сложность уже стала проблемой. Особенно когда она не помогает быстрее выпускать продукт.
Поэтому моя первая рекомендация заказчику простая: упростить инфраструктуру до уровня, который команда реально может поддерживать. Уменьшить количество движущихся частей и сначала научиться стабильно доставлять продукт пользователям.
Забавно, что это полная противоположность истории с The Signal.
Там ребята быстро выкатились на Vercel, но забыли настроить RLS в Supabase. А когда я поднял логи и метрики, мне сказали, что это уже какой-то очень серьёзный подход.
Тут всё наоборот. Логи есть. Метрики есть. Kubernetes есть. Даже Argo CD есть. А работающий frontend пока существует для меня только на скриншоте.
Обе крайности плохие. Можно месяцами строить идеальную инфраструктуру и не выпустить продукт. А можно выкатиться за вечер, забыв про безопасность, логи и бэкапы.
Нормальный вариант где-то между ними: работающий пользовательский сценарий, понятные критерии готовности, минимальная безопасность, логи, метрики и повторяемый деплой.
А вы в какой крайности?
Друзья, я просто обязан сказать огромное спасибо всему сообществу Хабра за вашу поддержку и активность под статьей о моем проекте Kakehashi!
Вдохновившись вашими отзывами, вчера вечером я опубликовал проект на Hacker News. Результат превзошел все ожидания: прямо сейчас тред держит 204 поинта, а репозиторий набрал более 220 звезд на GitHub.
Проект попал в радар к хардкорным системщикам со всего мира. Среди тех, кто дал звезду, оказались инженеры из команд Cursor, Fly.io, Astro, создатель пакетного менеджера Pixi, разработчик Redox OS и в дискуссии на HN был легендарный автор утилиты Cydia @saurik.
Но мне особенно приятно и дорого то, что самый первый импульс, первые звезды и конструктивный фидбэк проект получил именно здесь. Вы дали Kakehashi тот самый стартовый заряд, благодаря которому он смог громко заявить о себе на международной арене.
Огромное вам спасибо!
P.S. Хотел опубликовать в хаб «Я пиарюсь», но интерфейс не пропустил из-за нехватки кармы (нужно 30). Поэтому публикую в профильные хабы как апдейт к прошлой статье. Надеюсь на понимание!
Проект: https://github.com/wie-project/kakehashi
Статья на Хабре: https://habr.com/ru/articles/1065502/
Пост на Hacker News: https://news.ycombinator.com/item?id=49145937
MCP 2026-07-28: что действительно изменилось
Главное изменение — MCP стал stateless на уровне протокола. Убрали обязательные initialize, initialized и Mcp-Session-Id. Версия протокола и возможности клиента теперь передаются в каждом запросе, а сведения о сервере можно получить через server/discover. Любой запрос может обработать любой экземпляр сервера — без sticky sessions и общего хранилища сессий. Состояние приложения никто не запрещает: просто передавай явные идентификаторы вроде browser_id в аргументах инструментов.
Что ещё важно:
Долгие операции получили нормальный жизненный цикл. Tasks позволяют вернуть taskId, а затем проверять состояние через tasks/get, передавать дополнительные данные через tasks/update и отменять работу через tasks/cancel. Но Tasks не появились с нуля — раньше это была экспериментальная часть ядра, теперь её переработали и вынесли в официальное расширение.
Протокол стал удобнее для эксплуатации. Заголовки Mcp-Method и Mcp-Name позволяют маршрутизировать запросы, не разбирая JSON. Появились стандартные подсказки для кеширования — ttlMs и cacheScope, а также единые поля для передачи OpenTelemetry Trace Context.
Переработано общение сервера с клиентом. Вместо произвольных server-to-client запросов сервер теперь может вернуть input_required, после чего клиент повторяет исходный запрос с ответом пользователя. Подписки на изменения вынесены в subscriptions/listen.
Extensions стали полноценной частью экосистемы. Новые возможности теперь можно развивать отдельно от ядра. Первые заметные расширения — Tasks и MCP Apps. Последнее позволяет серверу отдавать интерактивный HTML-интерфейс, который клиент показывает в изолированном iframe.
Есть важные ломающие изменения. Все результаты теперь содержат resultType. Roots, Sampling, Logging и старый HTTP+SSE объявлены устаревшими. Схемы инструментов получили полноценную поддержку JSON Schema 2020-12. Если ты пишешь MCP-клиент или SDK, этот пункт может оказаться важнее MCP Apps.
Авторизацию подтянули ближе к реальному OAuth/OIDC. Добавили проверку iss, привязку учётных данных к конкретному issuer и уточнили регистрацию клиентов и работу с refresh-токенами.
В сухом остатке: remote MCP перестал требовать обязательную протокольную сессию и стал гораздо больше похож на нормальный stateless JSON-RPC поверх HTTP. Для продакшена это означает более простое горизонтальное масштабирование, маршрутизацию и кеширование. Остальные изменения полезны, но в основном касаются новых возможностей и миграции клиентов.
Андрей Карпаты рассказал о текущем состоянии работы нейросетей по промпту «нарисуй пеликана на велосипеде»:
Мы начинаем выходить за рамки тестирования LLM, например, с помощью запроса «создать SVG‑изображение пеликана на велосипеде». В качестве примера для обобщения, мне было интересно, что бы сделал Opus 5, если бы я дал ему первый абзац «Властелина колец», бюджет в 1 млн токенов (~$10) и попросил три рендера на JavaScript. Opus потратил около двух часов и написал 5500 строк кода, которые (процедурно) отрисовывали историю. Это немного коряво, но забавно. Но немного поразительно, что LLM должен размещать и координировать различные полигональные объекты в координатах (x,y,z) и писать код, который анимирует все это, и что он вообще что‑то делает.
Мне также нравятся подобные примеры, потому что никто в здравом уме не стал бы тратить время на написание чего‑то настолько уникального, но у LLM хватает выносливости и терпения, так что это пример того, как мы переходим от «никто бы этого не сделал» к «конечно, почему бы и нет, это же ~бесплатно». Возможно, таких примеров гораздо больше. Но меня вдохновляет создание гипер‑пользовательских миров, в которые можно было бы погружать игроков, например, чтобы они могли участвовать в истории «Властелина колец» в качестве NPC‑зрителя, или одного из персонажей, и так далее. Что‑то вроде эфемерной GTA X по запросу.
И последнее: область миров/игр выявляет слабость LLM: им трудно проверять свою работу, потому что они не способны эффективно и интуитивно воспринимать видео или играть в игры внутри них. В данном случае, Opus 5 пришлось очень медленно и кропотливо делать скриншоты в разных точках, и это несколько раз приводило к ошибкам и создавало кучу глюков. Пример тех самых возможностей (мультимодальные функции, игровой процесс), которым, на мой взгляд, пока ещё явно не хватает.
Представлен открытый проект pdf-inspector на Rust от команды Firecrawl. Это PDF-парсер, который умеет быстро обрабатывать страницы документов. Проект преобразует содержимое в Markdown, но при этом сохраняет структуру документа и таблицы. Решение работает без ограничений, код опубликован под лицензией MIT.
Cделал простой файл со словами, в которых часто встречаются ошибки. В нем, в основном, простые слова как из личной практики изучающего английский, так и те, ошибки в которых я сам слышал от других учеников.
Список, конечно, рассчитан на тех, кто уже видел слова и предназначен для самопроверки. Чтобы убрать ошибки, нужно обязательно проверять новые слова (по другому сложно, так как правила чтения в английском имеют множество исключений), или читать не самые сложные тексты вслух, повторяя за диктором, возможно, что у вас обнаружатся и другие слова для исправления. Иногда кто-то другой может поправить, иногда можно услышать правильную версию от другого говорящего.
Похожие файлы публикую в канале
ChatGPT помнит меня. И это пугает
Недавно поймал себя на одном нехорошем ощущении.
ChatGPT теперь помнит не только содержание текущего чата. Он помнит мою машину, разговоры с врачами, проекты, над которыми я работаю, статьи, которые писал. Иногда достаточно намекнуть: «мы это уже обсуждали», — и он действительно продолжает разговор с того места, где мы остановились.
И вот тут становится не по себе.
ИИ знает обо мне уже очень много. Слишком много!
Где же приватность, конфиденциальность?
Не разговаривать с ним на эти темы? Шифроваться? Как вариант да. Но и комфортность общения пропадает, разговоры с оглядкой, конспирация…
А что будет через несколько лет? Не окажется ли так, что он будет помнить обо мне больше, чем я сам?
И сразу вспоминаются посты ИИ-энтузиастов, которые строят сложные системы из агентов, моделей, циклов, внешней памяти… А потом неожиданно начинают говорить о создании собственной цифровой копии.
Еще недавно это звучало как фантастика.
Но ведь подобные идеи появляются уже не впервые.
Когда вышел iPod, многие сравнивали плейлисты известных людей и пытались по ним делать выводы об их характере и привычках.
Потом журналисты называли iPhone «вторым Я», потому что в нем оказалась значительная часть жизни человека.
Однажды мой знакомый попросил помочь с компьютером. Больше всего он переживал за жесткий диск. Там были фотографии, музыка, письма — часть его жизни. Потерять диск означало потерять часть самого себя. И что останется без этой части?
Тогда мне пришла на ум еще одна ассоциация. Космонавты перед стартом идут к ракете, а в руках у каждого небольшой чемоданчик, соединенный со скафандром. В нем находится система жизнеобеспечения.
Похоже, человечество постепенно носит такой «чемоданчик» уже много лет. Сначала фотографии и документы. Потом смартфон. Теперь — ИИ, который начинает помнить не только наши файлы, но и наши мысли, проекты, привычки и историю общения.
Возможно, это просто очередной этап развития технологий.
А возможно — начало совсем другой эпохи, в которой цифровая память станет продолжением человеческой личности.
В общем, ассоциаций много, а вопрос один - неужели мы действительно движемся в эту сторону?
Раздел "Открытые реестры" сайта ФИПС лежит уже не первый день... интересно - в чем причина...
Причем сам сайт доступен, можно посмотреть каталог свидетельств о регистрации ПО, например... но при попытке просмотра карточки самого свидетельства выходит ошибка...
Иногда выходит 404 от сервера Payara версии 5.193...
посмотрим, поднимется ли он с утра понедельника...
P.S.: понятно, что это не критичный вроде бы сервис и т.п.... но в целом много вопросов в голове возникает на связанные темы об эффективности работы ИТ в бюджетной сфере...
Как хиппи спасли физику
Краткое описание книги Дэвида Кайзера 'Как хиппи спасли физику'.
Дэвид Кейзер описывает события, связанные с неформальной группой фундаментальной физики (Fundamental Fysiks Group). Группа собиралась на неформальные встречи в семидесятые годы в Беркли и большинство участников истории живы в настоящее время. С точки зрения автора именно данная группа сыграла большую роль в становлении квантовой информатики, хотя в настоящее время деятельность группы практически не упоминается в учебниках.
В основе истории лежит известная теорема Белла, которая привела к пересмотру взглядов на основания квантовой механики. Нарушение неравенств Белла в последующих экспериментах показало, что квантовые состояния удаляющихся частиц остаются взаимосвязаны между собой и призрачное действие на расстоянии (spooky action at a distance) - это реальность.
В те времена размышления об основаниях квантовой механики не поощрялись. Принцип послевоенного развития квантовой механики в США сводился к лозунгу 'Заткнись и вычисляй' (shut up and calculate). Размышления на тему, что говорят нам уравнения квантовой механики об устройстве мира, только вредили получению постоянной ставки профессора. Два примера. Джон Клаузер (John Clauser) первым провел экспериментальную проверку неравенства Белла в 1972 году (вместе с Фридманом). Цитированию статей Клаузера в настоящее время позавидует любой физик. Однако в те времена Джону Клаузеру при всем его старании не удалось получить академическую позицию. Интерес Клаузеру к неравенству Белла в те времена был слишком далек от общепринятых убеждений в академическом сообществе. Алан Аспект (Alain Aspect) в начале восьмидесятых годов хотел улучшить эксперименты Клаузера-Фридмана. Он встретился с Беллом, чтобы обсудить с ним условия проведения эксперимента. Первым вопросом Белла стал 'Есть ли у вас уже постоянная позиция?'.
Группа фундаментальной физики была создана для обсуждения вопроса как устроен мир и на этом пути не было запрещенных тем и табу. Какую роль в мире играет квантовая нелокальность? Может ли квантовая нелокальность быть связана с сознанием? Есть ли связь между паранормальными явлениями и теоремой Белла? Есть ли аналогии между восточным мистицизмом и квантовой механикой? Могут ли психоактивные наркотики активизировать паранормальные способности в человеке? Это только некоторые вопросы, активно обсуждавшиеся на заседаниях группы. Естественно, что разные участники группы по-разному относились к восточному мистицизму, паранормальным явлениям и влиянию наркотиков. Тем не менее картина, воссозданная в книге, наглядно показывает, что демаркация между наукой и не наукой крайне затруднена. Даже позиция, кажущаяся абсурдной, может привести в дальнейшем к полезным результатам.
В книге прекрасно воссоздана атмосфера американского общества того времени. Интересно показано, как происходит финансирование науки в США. Разные судьбы участников группы фундаментальной физики показывают разные возможные пути удовлетворения своих интересов и любопытства. Академическая наука - это только один из возможных путей. Другие возможности - это независимая работа как консультанта, создание собственной фирмы, или даже наука как хобби на социальном пособии. Ряд участников группы стали профессиональными писателями, книги которых дали им финансовую независимость. Финансирование от государственных фондов и военных организаций переплетается с деньгами от филантропов и бизнеса. Дэвид Кейзер убедительно показывает, что наука является частью общественной жизни и разделение между тем, где кончается наука и начинается жизнь, практически невозможно.
David Kaiser, How the Hippies Saved Physics: Science, Counterculture, and the Quantum Revival, 2011.
Антипаттерн при работе с VPS: почему не стоит постоянно работать под root?
Работать под root на VPS удобно: перед командами не нужно вводить sudo. Но ошибка может затронуть весь сервер, а безопасность VPS требует разделять обычные и административные действия.
Почему работа под root удобна и опасна? В Unix доступ к файлам и управление процессами зависят от пользователя и его групп. Root может изменять системные файлы, управлять службами, пакетами и сетью. При постоянной работе под root ошибка в команде способна затронуть системные файлы и службы. Опечатка в пути команды удаления или ошибка в скрипте, запущенном от root, может стереть системные файлы, изменить права на каталоги и остановить сервисы. При запуске от обычного пользователя ущерб чаще ограничен его правами. Украденный ключ, разрешающий вход под root, или пароль этой учётной записи сразу дают административные права. Ключ обычного пользователя даёт доступ только с его правами. Получение root-прав зависит от настроек sudo, пароля, уязвимостей и ошибок конфигурации.
Как правильно: отдельный пользователь и sudo.
В Ubuntu или Debian создайте пользователя и добавьте его в группу sudo:
adduser operator usermod -aG sudo operator
Добавьте публичный ключ в файл .ssh/authorized_keys в домашнем каталоге нового пользователя и проверьте вход по SSH. Затем задайте параметр в
/etc/ssh/sshd_config: PermitRootLogin no
Проверьте конфигурацию и примените изменения без разрыва текущих подключений:
sshd -t && systemctl reload ssh
Мини-чек-лист безопасного старта на VPS
• Отдельный пользователь создан, команды запускаются через sudo.
• Публичный ключ добавлен, приватный защищён парольной фразой.
• Вход по SSH под root отключён.
• Обновления системы устанавливаются регулярно.
Проверьте настройки доступа к VPS: создайте отдельного пользователя с sudo, протестируйте вход по SSH и только после этого отключите вход под root.
Все, что нужно знать про нового главу Apple — пожилая пользовательша принесла на ремонт Apple Cinema Display 2004 года выпуска, который сломался впервые за 22 года. Cinema Display был первым проектом в Apple, над которым работал лично Джон Тернус. Устройство всё ещё работает, но дисплей в последнее время не в лучшей форме.
Добавил "галерею фишек" и документацию для акбуры, разумеется галерею написал на самом кастомном dsl
Можно ли быстро выучить иностранный язык? Все зависит от того, насколько далеко вы готовы пойти, можно только сказать определенно, что на уровне туриста усилий нужно очень мало. А вот для учебы, работы на английском, да даже чтобы просто читать статьи без перевода и вести беседу с коллегой на узкоспециализированные темы требуются годы практики. Сколько именно - зависит и от потраченного времени и от способностей, ни один специалист не сможет дать гарантию достижения результата "через год".
Все знают из официальных источников, что, чтобы достичь, например, уровня C1 в английском, нужно обучаться 800 часов. Если по часу в день, то это больше двух лет. Имеются в виду часы, когда кто-то обучает, и исправляет ошибки. Но официально не пишут, как оно должно выглядеть распределение этих часов во временном промежутке, отсюда и появляются курсы "С1 за три месяца" "Учи английский за 15 минут в день" и желающие приобрести такие курсы, чтобы расправиться с английским раз и навсегда. Также непонятно, сколько нужно заниматься самостоятельно. Я могу только из своего опыта сказать, что очень много.
Мне всегда казалось, что в любой сфере, чем дальше вы в нее погружаетесь, тем больше времени приходится тратить в день. Профессионалы тренируются два раза каждый день, не считая образа жизни, а любители могут ходить в зал 3-4 раза в неделю, и иметь вредные привычки, потому что цели у них разные.
Однако на сайте Кембриджа отмечается как раз обратное, "не обязательно увеличивать часы по контролем учителя". Тут можно казалось бы поставить точку. Но тут же выясняется, что это потому что "с повышением уровня открываются дополнительные возможности по самостоятельному изучению языка, включая общение с носителями языка". То есть, подразумевается принцип "с повышением уровня нужно заниматься больше". А вот на низких уровнях нужен запредельный настрой и дисциплина, чтобы изучать самостоятельно, при этом усваивая правильное произношение и значения слов.
Повышение количества времени на обучение выглядит логично, ведь нужно освежать в памяти старое и усложнять/заменять имеющиеся шаблоны. По достижению определенного уровня, если язык не использовать, то его уровень будет неуклонно падать. Также сложно "изучать по 10 часов в день", а такие гайды я тоже видел, думается, что принцип, что нельзя больше четырех часов продуктивно заниматься интеллектуальной деятельностью, вполне применим и к иностранным языкам.
Возьмем стандартное расписание, которое используют многие онлайн школы - два раза в неделю по 45 минут, если до уровня B1 хватит этих уроков, и небольшой домашней работы, то дальше уже многие не идут или не прогрессируют, потому что временные затраты на изучение становятся не очень привлекательными по сравнению с потенциальной выгодой от будущего владения английским. Ну или конечно, потому, что это уже вполне высокий уровень.
Важно, что формальный пройденный уровень не гарантирует знания. Например, я сам проходил восемь лет назад курс от "Pre-Inermediate" до "Upper-Intermediate" в одной онлайн школе, делал все задания подряд, и управился чуть менее чем за год. Но потом, когда у них закончились уроки по программе, я решил пойти к другому учителю, и там достаточно четко выяснилось, что можно смело сбрасывать два уровня.
Выходы, конечно, есть, любой изучающий, как кембриджские авторы и говорят, как можно раньше должен находить возможность заниматься самостоятельно. Без самостоятельной работы, в рамках только программы учебных заведений или под руководством преподавателя можно повысить уровень, если заниматься с ними каждый день и при этом выполнять все предусмотренные задания.
Но для большинства такое плотное обучение невозможно, поэтому лучше как можно раньше поменять свое отношение к языку, включить его в жизнь в виде потребляемой информации или собеседников. И чем дальше вы продвигаетесь, тем больше должен быть процент такой самостоятельной работы.
Тогда, когда вы перестанете работать под контролем кого-то, язык останется с вами и уровень будет постепенно расти.
«Скажите спасибо, что с хлебом останетесь»: почему авторы ИИ-гайдов переходят к снобизму в комментариях?
Знаете ощущение когда сказать, что я "****л" это ничего не сказать?
Такое ощущение у меня возникло от статьи https://habr.com/ru/articles/1064580/ и комментариев автора @Alexey_Begin
При прочтении статьи и комментариев видно как автор унижает разработчиков в ключе "вы ещё не доросли до вайбкодинга". Почему это остатёся на хабре?
Жалоба в саппорт подана. Но удивляет равнодушие и не способность ответить агрессивному инфоцигану. Всем добра и справедливости.
С structural уязвимостью оберточного AI-бизнеса: почему следующий уровень — это агрегаторы
Сейчас на рынке AI происходит массовое явление, которое можно описать мемом про «волка в бикини». Один видит успешный продукт, другие начинают слепо копировать его форму, не меняя суть.
Но в случае с ИИ это явление приобрело масштаб эпидемии не из-за человеческой глупости, а из-за падения стоимости разработки до нуля. Давайте разберем, как это меняет структуру рынка и где здесь возникает бизнес-уязвимость.
Шаг 1. Что скопировали все (базовая архитектура)
Посмотрите на 90% AI-сервисов, появившихся за последний год. Их бизнес-модель выглядит максимально просто:
Пользователь → Чат-бот (обертка) → Одна модель (GPT / Claude / DeepSeek)
Предприниматель не строит инфраструктуру. Он делает удобную оболочку, берет API и продает доступ.
Шаг 2. Почему это произошло именно сейчас
Раньше создание такого сервиса требовало денег на разработчиков. Сегодня сам ИИ (тот же Claude) пишет фронтенд, бэкенд и дизайн за неделю. UX паттерны чат-ботов стандартизированы, их легко скомпилировать.
В результате на рынок вылилось переизбыток абсолютно идентичных продуктов. Стоимость входа упала, барьеры исчезли.
Шаг 3. Появление структурной уязвимости
Когда рынок перенасыщен идентичными одноуровневыми продуктами, всегда открывается структурная уязвимость. Она заключается в том, что становится выгодным создать следующий уровень абстракции.
Архитектура меняется с этой:
Пользователь → Чат-бот → (GPT или Claude)
На эту:
Пользователь → Чат-агрегатор → Множество чат-ботов/моделей → (GPT, Claude, DeepSeek, Gemini)
Шаг 4. Почему агрегатор забирает рынок
Пользователю в 2026 году уже в большинстве случаев плевать, какая именно модель работает под капотом. Ему не нужен «доступ к Claude» или «доступ к GPT». Ему нужно решить задачу: написать код, перевести текст, сделать анализ.
Агрегатор снимает с пользователя необходимость выбирать. Он работает по принципу ИИ-агента (то, что сейчас продвигает Microsoft): пользователь не открывает разные программы, он отдает команду, а система сама решает, куда ее направить:
Запрос на код → уходит в Claude.
Поиск и анализ → уходит в Gemini.
Локальная быстрая задача → уходит в локальный DeepSeek.
Пользователь сидит за одним столом и заказывает всё что угодно из всей отрасли.
Шаг 5. Аналогия с парком аттракционов
Представьте парк развлечений.
Текущие оберточные боты — это люди, которые стоят у каждого аттракциона и продают отдельный билет: на колесо обозрения, на тир, на карусель.
Агрегатор — это единое приложение парка. Вы покупаете абонемент, заходите и просто говорите: «Хочу покататься». Система сама ведет вас на свободный аттракцион.
Когда на входе в парк стоит 500 продавцов отдельных билетов (оберточных ботов), спрос на них падает, потому что появился один человек у входа, продающий удобство выбора.
Итог
Бизнес-уязвимость «волка в бикини» на рынке AI не в том, что клоны делают плохой продукт. А в том, что массово копируя устаревающую одноуровневую архитектуру Пользователь-Бот-Модель, они сами подготавливают почву для своего собственного поглощения агрегаторами нового типа.
Строить еще одну обертку под одну модель — это продавать билет на карусель, когда напротив уже открывается касса всего парка. Пишите что не умеет ИИ в 2026 - году).
Апдейт карты AI safety грантов и программ (1 августа)
Прилетел свежий апдейт.
Что горит в августе
2 авг - FASR: fully funded резиденция в Cambridge, security + hardware verification
6 авг - FAST (SASH): 5 дней в Сингапуре, AI control и open-weight security
8 авг - DeepMind x Schmidt x CAIF x ARIA: пул до $10M на multi-agent safety
8 авг - TARA: бесплатно, ARENA-курс, APAC
9 авг - Better Futures Fellowship: удаленка, AGI preparedness
9 авг - Sentient Futures Incubator: welfare / digital minds
16 авг - Longitude DC Intensive: техническая safety в policy
16 авг - GovAI Research Scholars: открылась, London / DC, 1 год
17 авг - AIAF Fellowship: $12k + компьют, удаленка, техническая alignment
18 авг - SPAR (менти): part-time, удаленка
23 авг - Lightcone Commons и Corrigibility Research Fund
Что добавилось нового
Программы и феллоушипы: AIXI Labs, AIAF Fellowship, FASR, FAST, Syntony, TARA, Sentient Futures, Longitude, Iliad Intensive, AISB, Better Futures, Frame, Generator, BASE, Atlas Computing.
Фонды и гранты: Iliad RFP, AIAF grant, Paradigm 3, Halcyon Futures, Lightcone Commons, IFP Launch Sequence, AI Safety Research Fund, Corrigibility Research Fund, микрогранты Leo Gao, CLR Fund.
Суммы и дедлайны меняются, так что перед подачей всегда проверяйте официальную страницу.
---
Mrs Wallbreaker or: How I Learned to Stop Worrying and Love the AGI.
About AI Risk, AI Alignment, AI Safety, AI Ethics
https://t.me/MrsWallbreaker
