Python *

Кэш-монтирование в Docker — это мощный инструмент, который может значительно ускорить процесс сборки образов в CI/CD. Но его правильная настройка в GitLab требует понимания не только работы BuildKit, но и особенностей взаимодействия с различными конфигурациями GitLab Runner — DinD и DooD.

В этой статье я расскажу об устройстве кэш-монтирования в Docker и как его использовать в GitLab CI/CD. На примере простой сборки Python-проекта покажу готовые решения для кэширования зависимостей, чтобы оптимизировать сборку Docker-образов.

Выбор фреймворка для глубокого обучения — это стратегическое решение, влияющее на скорость разработки, стоимость и масштабируемость. Правило «PyTorch — для исследований, TensorFlow — для продакшена» больше не работает. К 2026 году оба фреймворка активно заимствуют лучшее друг у друга: PyTorch наращивает промышленные возможности (TorchServe, ExecuTorch), а TensorFlow с Keras 3 становится гибче для исследований.

Согласно опросу Stack Overflow Developer Survey 2024, PyTorch (10,6%) и TensorFlow (10,1%) находились примерно на одной отметке по частоте использования у разработчиков, а в исследовательских и AI-first-компаниях уверенно лидирует PyTorch. Но есть нюансы.

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

С точки зрения нейронных сетей мир плоский. Иерархические данные напоминают, что это не так.

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

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

Стандартные нейронные сети в таких условиях жёстко сбоят. Обучите одну модель сразу на всех датасетах — и она расфокусируется из-за различий, станет усреднять функции, которые усреднять не следует. Натренируйте по модели на каждом из датасетов — и получите переобучение, в особенности, если датасеты будут маленькими. Такие обходные манёвры как задействовать статические векторные представления (эмбеддинги) или постоянно наращивать размер сети в сущности не решают ключевую проблему: система запоминает причуды сети, не моделируя её структуру, складывающуюся на уровне датасета. А ведь именно эта структура — залог качественных результатов.

Некоторое время назад я опубликовал статью про генерацию синтетических данных для электродуговых печей (EAF). Идея была проста: реальных промышленных данных нет (они стоят миллиарды или засекречены), а учить ML‑модели на чем‑то надо.

Статья вызвала неожиданно обсуждение. В комментариях собрались профильные инженеры, дата‑сайентисты и те самые «душные физики»(в хорошем смысле), которые заставили меня переписать генератор с нуля. Этот пост — история о том, как проект эволюционировал от простой таблицы с цифрами до сложного симулятора, который прошел аудит экспертов и был разобран на части математическим методом Курамото.

Сегодня мы выходим в продакшн с системой "Шампур Логистик", которая пакует флот из 15 судов и распределяет манифест на 70 000 контейнеров быстрее, чем вы успеете допить кофе.

Это уже не просто «тетрис в вакууме». Мы построили промышленный конвейер на FastAPI и Celery, где математическое ядро с 90% Test Coverage сталкивается с суровой физикой моря: лимитами стекирования в 210 тонн, жестким LIFO-зонированием портов и капризными рефрижераторами.

В этой статье я покажу изнанку системы: как за 16 минут превратить маркетинговый хаос в выверенный цифровой двойник рейса, почему 10% свободного места в трюме — это не ошибка, а осознанная экономия миллионов долларов, и как наш "Шампур" защищает прибыль перевозчика в закрытом море кода.

<cut />

Всем привет! Хочу рассказать не столько про свою модель, сколько про инженерные компромиссы, с которыми я столкнулся во время работы над проектом. Буду рад любой критике.

Речь пойдет о моем проекте edge-weather-forecast — лёгкой нейросетевой модели прогнозирования температуры, которую можно запускать прямо на метеостанции или на простом CPU-устройстве вроде Raspberry Pi.

Приветствую, Хабр! Представляю вам свой фреймворк - ai-sidekick

Мы разберём готовый к работе фреймворк для экспериментов с MCP-tools. А также, на его основе, рассмотрим архитектуру RAG (Retrieval-Augmented Generation) AI-ассистента для поиска информации в вашей собственной базе знаний. Это не набор абстракций в тысячу строк, а минималистичная кодовая база на Python и Docker, которая предоставляет возможность экспериментировать с конфигурациями и кодом под ваши задачи.

Привет! Если у вас когда‑либо был опыт деплоя нейросетки, вы знаете, что обучение — это полдела, а вот добиться шустрого инференса — целое искусство. Часто обученная в PyTorch модель дает замечательные метрики, но стоит попытаться запустить её в приложении начинаются всякие проблемки.

Одно из решений, которое часто выручает — ONNX и ONNX Runtime. Если эти буквы для вас пока ничего не значат — не беда, сейчас разберёмся что к чему. А если вы уже слышали про ONNX, то, возможно, задавались вопросом: «А реально ли ускорить инференс, заморочившись с этой технологией?» Еще как!

Большая статья для тех, кто, как и я, споткнулся об asyncio и так не разгадал до конца «магию» событийного цикла. Попробовал распутать этот клубок через подробный рассказ (в как можно более доступной форме) о внутренних механизмах Линукса и самого asyncio, которые лежат в основе событийного цикла. К концу статьи, надеюсь, магия исчезнет, а взамен придет ясное понимание фундамента. Статья будет полезна и тем, кто работает с asyncio на других платформах.

Django Rest Framework (DRF) - чуть ли не единственный фреймворк для разработки REST на базисе Django. Мой нарратив о Django в прошлой статье заключался в том, что это неповоротливый монолит, который абсолютно не следует best practices и не стремится к ним. Если вдруг вы не задумывались о том, как связаны DRF и Django, то вас может быть немного это удивит - никак. Их делали совершенно разные люди, но каким-то образом они сошлись в общей концепции: игнор хороших практик, перегруженные классы и магия, превращающая разработчика в гадалку.

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

Помедитировав немного над этим, я пришёл к интересным эвристикам.

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

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

Например, существует масса формализованных циклов проектирования (PDCA, OODA, DMAIC, 8D и etc.) — по сути, тривиальных мета-алгоритмов; однако каждый шаг этих алгоритмов — это куда более сложная и нетривиальная задача.

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

Обычно всё начинается с очень простой задачи, которую нужно решить чем быстрее, там лучше. «А можно ли сделать так, чтобы пользователи сами записывались на консультацию через Telegram?» или «кто-то должен отвечать на типовые вопросы клиентов ночью, пока саппорт спит». Как правило, на этом этапе вспоминают о Telegram-ботах, но тут вопросов возникает еще больше. Сколько стоит разработка? Можно ли создать такого бота своими силами? Что для этого нужно? Насколько это сложно? Или вообще, — а что там внутри этих самых Telegram-ботов, кроме команды «/start»?

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

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

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

Так вот, я решил принять этот вызов и самостоятельно, без Дмитрия Шалаева разобраться как похожая стратегия может вести себя на акциях Московской биржи.

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

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

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

Всем привет!

Сегодня Telegram выкатил Bot API версии 9.4. На первый взгляд обновление кажется небольшим, но оно кардинально меняет подход к визуалу ботов. Наконец-то мы получили инструменты для нормального UX/UI дизайна!

Давайте разберем, что нам приготовил Павел Дуров и команда в этот раз.

Если вам интересны подобные материалы, подписывайтесь на Telegram-канал «Код на салфетке». Там я делюсь гайдами для новичков, полезными инструментами и новостями.

📉🐻 Как ИИ получил руки для торговли на бирже

Claude Code уже разбирается в техническом анализе, умеет искать в интернете для фундаментального, может быть запущен удаленно на сервере с iPad через Claude Code on the web, умеет анализировать файлы логов сам программируя python скрипты.

Осталось ли собрать всё это в кучу...

Недавно мне предстояло написать реализацию LogisiticRegression для одного проекта в Школе 21, так что было необходимо разложить всё по полочкам и разобраться в бинарной классификации в целом. Хочу поделиться также этой информацией здесь, потому что не нашла статьи, которая была бы понятна и обширна лично в моём случае.

C помощью Python ищу цветаевские следы в творчестве Ахмадулиной и обнаруживаю диалог поэтических миров двух авторов.

Предыдущие части:

«Геометрическая головоломка на выходные»,
«Электродинамика виртуальной Вселенной»,
«Механика виртуальной Вселенной»,
«Квантовая механика виртуальной Вселенной (Часть I)»,
«Квантовая механика виртуальной Вселенной (Часть II)»
«Релятивизм виртуальной Вселенной»
«Космология виртуальной Вселенной (Часть I)»
«Космология виртуальной Вселенной (Часть II)»
«Электричество, проводимость и сверхпроводимость в виртуальной Вселенной»
«Атом в Виртуальной Вселенной (Часть I)»
«Атом в Виртуальной Вселенной (Часть II)»
«Атом в Виртуальной Вселенной (Часть III) [Химия]»

Здравствуйте, мои уважаемые читатели.

Следующим шагом я хотел приступить к описанию ядра атома в рамках описанной ранее теории. Но по комментариям и при личном обсуждении, пришёл к выводу, что теория хоть и является минималистичной, но всё-же, интуитивному её пониманию сильно мешает то, что всё обсуждение строится в 3+1 геометрических измерениях. С одной стороны — их не 11, как в теории суперструн, но и 4 — это сложно для понимания для неподготовленного человека. Да и, кого я обманываю — даже подготовленному проще оперировать формулами, чем образами в пространствах, размерностью выше трёх. Но в этой модели очень важно понимать её онтологию, суть процесса. Формулы являются лишь языком, позволяющим (вот тут будет тавтология) описать формализм системы и дать возможность оценить её качественно и количественно.

Эти размышления привели меня к мысли о необходимости дать расширенное визуальное описание системы. Я не придумал ничего лучше, чем понизить размерность. Исходно, у нас система представляет собой трёхмерную сферу S³. А давайте рассмотрим такую же модель, но на сфере S². Да, удастся показать не всё — например, спин 1/2 здесь показать не выйдет. Но кое что должно проявиться и дать интуицию.