Программирование *

«Потерянное интервью» было вовсе не о компьютерах. Это был чертёж эры искусственного интеллекта и приговор традиционному менеджменту.

В 1995 году Стив Джобс пребывал в изгнании.

Десять лет назад его выгнали из Apple. Он возглавлял NeXT – нишевую компьютерную компанию, и Pixar – крошечную анимационную студию, ещё не выпустившую «Историю игрушек». Ему было сорок, когда он оказался в комнате со съёмочной группой передачи Triumph of the Nerds («Триумф чудаков»).

Он дал откровенное, без купюр, 52-минутное интервью. Но из-за нелепой ошибки при пересылке мастер-кассета затерялась где-то между Лондоном и США. Она пропала бесследно.

Лишь в 2011 году, вскоре после его смерти, режиссёр обнаружил VHS-копию, пылившуюся в гараже.

Смотреть её сегодня – жутковатый опыт. Джобс говорил не о девяностых. Он описывал законы цифрового мира, который достигнет зрелости лишь в 2026 году. Он предрёк «смерть менеджера среднего звена», «преимущество 100 к 1» в разработке и ловушку «процесса вместо сути».

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

Всем привет.

Почти 15 лет я не писал на Хабр. Я не сошел с ума (см. предыдущий пост в профиле), всё в порядке, просто дело в том, что не было достойной темы. И вот впервые за 15 лет мне сильно захотелось поделиться с обществом своим небольшим открытием.

В двух словах — вчера придумал инструмент для ревью чата с ИИ по аналогии с ревью гитлаба. Дипсик написал ТЗ, код, сопроводительные документы и статью для Хабра.

Я не нашел на хабре достойного представления фрейморка Jaspr сообществу и решил представить сам. Flutter, безусловно, хорошая магия: один код для всех платформ, в том числе и Web. Но за магию приходится платить. Платить мегабайтами загрузки, муками с SEO и ощущением, что ты принёс на пляж боулинг — вроде и весело, но как-то не к месту. Команда Flutter и сама честно говорит: Flutter Web создан для веб-приложений, а не для веб-сайтов. Для сложных дашбордов, PWA, для всего, что живёт за логином — да. Для контентного сайта, блога, лендинга — увы.

Знакомьтесь, Jaspr. Веб-фреймворк на Dart, который осознанно отказывается от канваса и пиксельной магии Flutter в пользу старого доброго HTML и CSS. Он выглядит как Flutter, ощущается как Flutter, но на выходе даёт то, что поисковики и браузеры любят и понимают: обычный HTML-документ и DOM. А попробовать на вкус его можно здесь.

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

Английский в IT это не просто язык общения. Это инструмент доступа к знаниям, возможностям и рынку труда.

Многие уже используют GitHub Copilot Chat каждый день: @workspace, режимы вроде ask/edit/agent и быстрые правки кода стали частью рутины. Проблема в том, что стандартный агент в чате — универсальный, а значит часто даёт усреднённые ответы.

На практике стандартного чата часто становится недостаточно. Без заранее заданных правил агент не учитывает специфику проекта и принимает решения «по умолчанию». Такие ответы могут быть корректными технически, но часто не соответствуют вашим внутренним конвенциям и архитектурным ограничениям. В итоге это приводит к постоянному ручному управлению контекстом. Документацию и эталонные файлы приходится каждый раз явно добавлять в запрос, а роль, стек и стиль — задавать заново для каждой новой задачи.

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

Всем практикующим программистам приходится конкатенировать строки. Именно конкатенировать, у нас не какой-то там JavaScript или PHP, у нас в C++ это называется вот таким заумным словом. Программисты на других языках без излишних мудрствований строки просто "складывают", даже не особо задумываясь об этой операции. Ведь что может быть проще, чем

return "The answer is " + str_answer + ", count is " + count;

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

Мы привыкли думать абстракциями. Нас учили, что мир состоит из объектов: у «Собаки» есть метод Bark(), а у «Пользователя» — поле Email. Мы тратим недели на споры о чистоте интерфейсов и иерархии наследования, свято веря, что инкапсуляция — это ключ к успеху. Но пока мы строим эти ментальные замки, наш процессор... скучает.

Современный CPU — это невероятно мощный вычислительный монстр, способный обрабатывать миллиарды операций в секунду. Но у него есть ахиллесова пята — память. Пока ваш код прыгает по указателям от одного объекта в куче к другому, процессор простаивает в ожидании данных, совершая те самые «cache misses».

Data-Oriented Design (DOD) — это не просто очередной паттерн. Это «таблетка реальности», которая предлагает перестать проектировать программы вокруг сущностей и начать проектировать их вокруг данных.

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

Когда «горячий» ключ кэша истекает одновременно у всех, происходит cache stampede: тысячи запросов синхронно проваливаются в БД и кладут её за секунды, даже при 95% hit rate.

Защита простая: stale-while-revalidate, случайное раннее обновление (jitter / probabilistic expiration) и single-flight (mutex), чтобы в БД уходил один запрос, а не 10 000. Цена — несколько секунд устаревших данных, зато без упавшей базы. Подробнее - в новом переводе от команды Spring АйО.

В 2026 году российский IT-рынок продолжит рост и может приблизиться к 4,5 трлн ₽. При этом компании меняют подход к инвестициям: выбирают решения с быстрым и измеримым эффектом. Например, вкладывают в развитие AI-проектов, масштабирование IT-инфраструктуры или создание собственных разработок. 

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

Здравствуйте!

Цель статьи - поделиться опасениями от использования ОТЛИЧНЫХ AI-ассистентов и услышать мнение сообщества по их поводу.

Я C# разработчик, и в своей работе в 90% случаев использую VisualStudio. 50% моей работы - создание типовых RESTful сервисов для бэкэнда нашего продукта. Еще процентов 30% - работа с обработкой изображений и видео. И процентов 20% рабочего времени я трачу на различные R&D исследования разной степени сложности.

В 2023 году ChatGPT плотно захватил умы прогрессивного человечества. Мы развлекались как могли. А я в свою очередь стал использовать ChatGPT, а затем и DeepSeek для рутинных задач. Например, сгенерировать набор классов по JSON, отредачить текстовку и т.п. Работа не всегда была выполнена чисто - то напутает с типами данных, то поломает стилистику. В общем приходилось ревьювить каждую генерацию. Но в целом, это здорово помогало экономить время. К тому же мало помалу я составил идеальные промты для каждой задачи, и казалось вот оно светлое будущее.

Затем появился Copilot и часть своих задач я начал выполнять непосредственно в VS. Copilot научился нативно интегрироваться в IDE, представлял удобнейший инструмент для включения результатов своей работы в код и остальные плюшки. Коллеги, между тем, на месте не стояли и расширяли набор сценариев взаимодействия с Copilot. Да и сам Copilot предлагал все более интересные модели.

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

Привет! Это команда Яндекс Практикума. В конце 2025 года мы провели исследование рынка и узнали, как меняются требования работодателей и к чему стоит готовиться джуниору Go-разработчику при трудоустройстве. Рассказываем самое важное.

Цель данной статьи - предоставить сравнение методов решения СЛАУ и их эффективности в разрезе времени решения и нормы невязки, характеризующей точность решения. В статье приводятся результаты решения для числа уравнений от 50 до 3000. Приводится сравнение результатов решения для методов: Гаусса, LU декомпозиции, компактной схемы исключения, QR декомпозиции, декомпозиции, методов вращений, релаксации и градиентного спуска.

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

Введение

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

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

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

«Контейнер скомпрометирован». С этих слов начался трёхчасовой ночной кошмар с утечкой данных и полным отчётом об инциденте. Всё из-за банального запуска контейнера от root с лишними правами.

Тут не нужно быть хакером или гуру DevSecOps. Проблема в том, что безопасность попросту игнорируют. В новом переводе от команды Spring АйО — 11 конкретных шагов, которые помогут вам избежать катастрофы: от запуска от непривилегированного пользователя до минимальных образов, сканирования уязвимостей, изоляции сетей и настройки профилей безопасности.

Если вы разворачиваете контейнеры в продакшене — это руководство должно стать вашей чеклист-основой. Ошибка может стоить очень дорого.

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

Странный вопрос, не правда ли? У AI-агентов, конечно, есть разные проблемы, но вряд ли их можно обвинить в медлительности. Спросите, как говорится, любого, какие у него ощущения от AI, и первое, что вы услышите, будет что-то вроде: «AI за 3 часа сгенерировал мне 100 тысяч строк кода». Разве это можно назвать медлительностью?

На этом месте можно было бы и разойтись: 100 тысяч за 3 часа. Покажите мне человека, который способен хотя бы в половину этого, — и «я съем свою шляпу». Но я по‑прежнему утверждаю, что AI-агенты слишком медленные. Не верите? Добро пожаловать под кат…

Когда запускаешь pytest --cov код выполняется как обычно, но в конце появляется отчёт о покрытии. Как pytest узнаёт, какие строки выполнились? Ответ в sys.settrace, это низкоуровневый хук, который позволяет перехватывать каждый шаг интерпретатора.

На этом механизме построены coverage.py, pdb, PyCharm debugger, hunters, и десятки других инструментов. Разберём, как это работает изнутри и почему трассировка устроена именно так.

Привет! Меня зовут Николай, я C++‑разработчик в SimbirSoft. Я подготовил цикл статей, в которых хочу поделиться своим опытом проектирования библиотек на примере решения геометрических задач и разобрать три популярных подхода к организации кода. В этой статье я расскажу про классическое наследование с виртуальными функциями и использование шаблонов. В продолжении будет еще подход, следи за обновлениями профиля.

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

Для комфортного чтения материала потребуется уверенное владение базовым синтаксисом C++, понимание принципов объектно-ориентированного программирования, а также общее представление о шаблонах и виртуальных функциях. Текст ориентирован на разработчиков среднего уровня, но может быть полезен и тем, кто только начинает глубже разбираться в архитектуре C++-библиотек.