Сегодняшняя статья основана на полугодовом опыте глубокого использования Claude Code и кучи набитых шишек. Надеюсь, это будет полезно.

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

В этой статье я хочу обсудить несколько вещей: как Claude Code работает изнутри, почему контекст засоряется и как с этим бороться, как правильно проектировать Skills и Hooks, как правильно использовать Subagents, как архитектура Prompt Caching влияет на всё, и как написать действительно полезный CLAUDE.md.

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

Я отношусь к тому постепенно вымирающему поколению разработчиков, которым выпала странная привилегия писать программный код в его самой чистой, первозданной форме, создавать каждую строчку вручную, собственными руками и головой, без всяких умных копайлотов-помощников, без промптов, без автодополнения, которое якобы знает что ты хочешь написать лучше тебя самого. Голая логика алгоритмов, литры выпитого кофе и мигающий курсор в пустом файле открытой IDE, когда мозг пытается удержать в своей “оперативной” памяти всю архитектуру системы целиком. 

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

Я делал это не потому, что меня кто-то заставлял или потому что так требовало начальство, а просто потому что сам процесс создания работающей системы из ничего, исправление хитрых багов, построение сложных систем из простых компонентов – всё это было по-настоящему весело, приносило какое-то детское удовольствие от созидания. Когда наконец откидываешься в кресле от монитора после многих часов работы, смотришь на то что построил своими руками, и видишь что всё работает как задумано, и думаешь: "Да, я, блин, чертов гений, это всё сделал только я, и никто мне не помогал". Ну разве что SO и немного гуглежки.

Содержание

• Введение
• Величины, типы и операторы
• Структура программ
• Функции
• Структуры данных: объекты и массивы
• Функции высшего порядка
• Тайная жизнь объектов
• Проект: электронная жизнь
• Поиск и обработка ошибок
• Регулярные выражения
• Модули
• Проект: язык программирования
• JavaScript и браузер
• Document Object Model
• Обработка событий
• Проект: игра-платформер
• Рисование на холсте
• HTTP
• Формы и поля форм
• Проект: Paint
• Node.js
• Проект: веб-сайт по обмену опытом
• Песочница для кода

Привет, Хабр! Меня зовут Данила, мне 21 год, и за последние 2,5 года я успел поработать в роли разработчика программного обеспечения для встраиваемых систем — в основном на базе STM32. В этой статье я хочу поделиться тем, как я вообще пришёл в эту сферу, с чего начинал, какие грабли собрал и какие выводы сделал по пути.

Экосистема дистрибутивов Linux разнообразна и предлагает множество вариантов с разными особенностями. Выбор зависит от целей, уровня подготовки, оборудования и предпочтений пользователя. Этот обзор поможет подойти к выбору осознанно и углубиться в изучение Linux. Обмен опытом в сообществе способствует общему росту знаний.

Особенность Go — удобный механизм конкурентности. Создавать конкурентные задачи в парадигме языка можно буквально «бесплатно» и предельно просто: достаточно написать ключевое слово go перед вызовом функции — и она начнет выполняться в отдельном потоке.

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

Elixir - язык, вызвавшийся заново открыть Erlang современному миру. Синтаксис без приятных сердцу, но уже архаичных знаков пунктуации; культура разработки с особым вниманием к качеству и удобству инструментов; полноценный набор решений для написания web-сервисов; стандартная библиотека без груза в несколько десятилетий и настоящие макросы.

Если задуматься, то непосредственно в самом языке не так уж и много нового. Действительно, зная и Elixir и Erlang, можно представить как код на одном языке будет выглядеть на другом. Хотя и не всегда - в Elixir имеются выражения, которым нет эквивалента в Erlang. Как же они работают? Очевидно, Elixir раскрывает их в какой-то дополнительный Erlang код на этапе компиляции. Иногда можно интуитивно представить в какой, а иногда (спойлер) компилятор может подкинуть пару сюрпризов.

Эта статья - обзор преобразований, которые проходит код на Elixir прежде чем попасть в компилятор Erlang. Мы посмотрим на условные выражения вроде if и cond, уделим внимание точке, посмотрим на приключения с with и for, приоткроем тайны протоколов и удивимся оптимизациям, которые Elixir умудряется производить.

Я хочу вдохновить вас или, возможно, даже просто познакомить с теми типами игр, которые очень хорошо идут в Steam и могут быть сделаны небольшими командами разработчиков. Пожалуйста, играйте в эти игры, делайте заметки, смотрите на то, как они устроены.

Ровно месяц назад VK объявила о закрытии проекта мессенджера ICQ — спустя 28 лет после его выпуска. Завершилась работа серверов и закрылась возможность авторизоваться. Для продолжения общения VK рекомендовала перейти на продукты «VK Мессенджер» и «VK WorkSpace».

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

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

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

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

Резюме статьи:

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

Доброго времени суток, дорогие читатели! Сегодня я затрону одну интересную тему — графические дисплейные сервера и протоколы в Linux. В этой статье я расскажу вам о архитектуре X11 и Wayland, историю их создания и наконец-то сделаем вывод: Иксы на мороз, или вейланд на помойку?

Еще в далеком 2016 году вышла Fedora 25 с окружением GNOME 3.22 на базе дисплейного сервера Wayland. А в RHEL 10 выкинут X11 на мороз. Релиз RHEL 10 намечен на 2025 год, CentOS Stream 10 — на 2024 год. Для обеспечения работы приложений, требующих X11, будет использоваться XWayland. Таким образом, в 2029 году (к моменту окончания первого этапа поддержки RHEL 9) стоит ожидать появление первого аппаратного обеспечения, не поддерживающего X11.

И как я думаю — будущее за Wayland. Но пока X11 является стандартом. Давайте разберем это!

Объём специфичных знаний, которые требуются рядовому программисту игр, даже если он только начал свою карьеру, вызывает у меня «лёгкую» тоску. Это одна из причин, почему большая часть людей, которые «горят делать игры», отсеивается на этапе технических собеседований (обычно их больше одного). Это нормально и грустно. Добавьте сюда, что нефундаментальные знания, вроде инструментов, библиотек и движков, приходится обновлять где‑то раз в 5–7 лет. Не вижу тут, что игрострой сильно отличается от других областей разработки. Если бы лет 15 назад «добрый я» скинул на почту список книг, которые придется прочитать и осмыслить, армия собранных граблей не была бы столь большой и разнообразной, и без ручек половинной длины. Осторожно, в конце статьи будет супердлинная картинка (взята с github отсюда, с разрешения автора).

Вступление