Всем привет! Меня зовут Даниил Николаев и я frontend-разработчик в компании "Исходный Код"

На каждом kickoff нового проекта всплывает один и тот же сценарий: один разработчик топит за утилиты Tailwind, второй отстаивает чистоту и надежность CSS Modules, третий по привычке тянет проверенный CSS-in-JS, а кто-то просто молча открывает .scss и выходит из созвона.

В этой статье мы опустим споры о «красивом синтаксисе» и разберем инженерную сторону вопроса: кто на самом деле платит за динамику — сборка или браузер клиента.

Заглянем под капот ключевым подходам в мире React (для уровня middle и middle+): разберем классические CSS Modules, ушедший в maintenance mode styled-components, Emotion, современный Tailwind v4 на движке Oxide и перспективный zero-runtime (Linaria, Vanilla Extract). Посмотрим, что реально происходит с CSSOM, reflow и рендером в браузере, а в конце — соберем практическую матрицу выбора без фанатизма и хайпа месяца.

Всем привет! Меня зовут Антон Рыков и я backend-разработчик в компании "Исходный Код".

Пять CRUD-эндпоинтов. К обеду я понял: бизнес-логика заняла минут двадцать. Остальные два часа ушли на UUID вместо автоинкремента, одинаковые DTO с валидацией и ручную уборку временных файлов на стейджинге. Пальцы работали. Голова — нет.

Почти любая команда на Symfony рано или поздно упирается в ту же стену: фреймворк перестаёт быть помощником и превращается в конвейер. make:entity → вырезать integer id → прикрутить трейт дат → руками разобрать $request в контроллере. Снова. И снова.

DX — это не красивая тема в терминале. Это меньше трения между архитектурным решением и кодом. Правильная лень — точечная автоматизация того, что вы и так делаете каждый день.

В статье — четыре уровня, которые убрали это трение у меня. Настроите PhpStorm так, чтобы скелет JSON-экшена появлялся по Tab. Уберёте ручной json_decode и isset через MapRequestPayload и строгие DTO. Научите MakerBundle сразу генерировать сущности с UUID и вашими трейтами. Перенесёте cron в PHP через Scheduler - расписание

Всем привет! Меня зовут Денис, я senior frontend‑разработчик в компании «Исходный код».

Недавно на работе мне предложили попробовать себя в роли технического интервьюера. Я подумал, что этот опыт стоит описать как для собственного осмысления, так и для коллег‑разработчиков, которые только начинают проводить собеседования. Здесь не будет жестких инструкций или менторских советов. Это скорее честный, субъективный взгляд изнутри, который, надеюсь, поможет вам сделать собственные полезные выводы.

Вкратце расскажу предысторию. Наша компания открыла две вакансии в команду веб‑разработки. Мы искали middle и senior.

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

Привет, Хабр! Мы «Исходный Код», и сегодня хотим поделиться нашим опытом построения и перезапуска медиастратегии IT‑компании.

Когда мы начинали 4 месяца назад, перед нами стоял типичный для рынка вызов: построить экспертный статус, раскачать охваты, наладить перфоманс в бренд‑медиа и, самое главное, привлечь сильных специалистов в команду через контент. Мы стартовали буквально с нуля на конкурентном рынке.

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

Привет! Я Максим Савченко, iOS-разработчик. Эта история началась с вопроса, как сделать живую форму в духе иконки Siri — и довольно быстро уехала в другую сторону: аттрактор Лоренца на сотнях тысяч, а потом и на миллионе частиц, где и расчёт, и отрисовка живут на GPU.

Вся схема держится на одной идее: состояние частиц на CPU больше не возвращается. Compute-шейдер читает один буфер, пишет в другой, render-pass сразу рисует результат, на следующем кадре буферы меняются местами.

В статье разбираю это по шагам: математика и выбор интегратора, ping-pong-буферы, compute/render-пайплайн, point primitives и additive blending. А в конце — GPU Frame Capture и замеры на физическом iPhone. Спойлер, который я сам не ожидал: RK4 в этой конфигурации оказался далеко не самым дорогим местом. Основная цена ушла в отрисовку и overdraw.

Если коротко: это не гайд «как нарисовать красивую картинку», а разбор того, зачем вообще лезть в Metal и где кадр упирается на реальном устройстве.

Мы списали uv со счетов. А потом он ускорил наш CI на 80%

В Python-сообществе вокруг uv уже несколько месяцев шум: быстрый резолвинг, один инструмент вместо зоопарка утилит и обещание ускорить привычный workflow. Звучит хорошо — пока не проверишь на своём стеке.

Мы так и сделали. Взяли один микросервис: Python 3.14, 37 прямых зависимостей, 153 пакета в lock-файле, приватные пакеты и внутренний Nexus. Ожидание было простым: если uv действительно быстрее Poetry, миграция окупится сама.

Локально получилось наоборот. Резолвинг — да, быстрее. Установка по готовому lock-файлу — нет, иногда даже медленнее. Эксперимент закрыли и остались на Poetry.

Через несколько недель пришлось вернуться. Не из любопытства, а из-за алерта Trivy и сюрпризов Poetry 2 с корпоративными индексами. И вот тогда uv показал себя совсем в другом месте — в CI.

В статье разберем:

- почему локальный бенчмарк uv vs Poetry нас обманул;
- как Poetry 2 сломал привычную разработку без VPN;
- зачем мы писали парсер poetry.lock → requirements.txt и почему это оказалось костылём;
- как точечная замена Poetry на uv sync в пайплайне сократила время с 5:10 до 2:50;
- почему в итоге uv стал единым стандартом и локально, и в CI.

Коротко: если инструмент не выиграл с первого прогона — это ещё не значит, что он бесполезен. Часто вы просто мерили не то узкое место.

Всем привет! Меня зовут Никита Нагорнов, я iOS-разработчик в компании «Исходный Код». В этой статье разберем, как запускать локальные LLM на iPhone.

Поговорим про:

1. Архитектуру Apple Silicon и Unified Memory — почему не можем использовать всю доступную память;

2. Память, квантование и KV Cache — где приложения начинают падать и как это отловить;

3. Core ML и MLX — чем отличаются, где какой быстрее и почему нельзя всё запускать на нейронном процессоре;

4. Температуру и троттлинг — что происходит с телефоном на длинной сессии;

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

Я не планировал переписывать приложение React Native на C++.

Большая часть приложения прекрасно работала на TypeScript: экраны, формы, валидация, навигация, логика продукта — все это находилось именно там, где нужно. 

Проблема была более узкой и специфичной: нам нужно было, чтобы один фрагмент логики работал с производительностью, близкой к нативной, оставался общим для Android и iOS и при этом был доступен из JavaScript через обычный типизированный API.

Поначалу все звучало слишком просто. Написать интерфейс на TypeScript, позволить Codegen генерировать контракты, перенести основную логику на C++, зарегистрировать модуль на обеих платформах и использовать его из React Native как любой другой модуль.

Спойлер: да, это работает.

Чистый модуль Turbo Native на C++ действительно может дать вам одну реализацию для Android и iOS, типизированную границу через Codegen, меньшие накладные расходы, чем у старого Bridge, и удобный способ повторного использования существующего кода на C или C++ внутри приложения React Native.

Спойлер номер два: код на C++ — это не самая сложная часть.

Самое сложное начинается вокруг: CMake, NDK, Xcode, Objective-C++, время жизни среды выполнения JSI, регистрация модулей, границы потоков, владение памятью, обработка ошибок, сборки Expo, сторонние библиотеки и вопрос, который никто не хочет задавать слишком поздно — действительно ли этот модуль должен быть нативным?

В этой статье я подробно расскажу о создании C++ Turbo Native модуля для React Native: где этот подход полезен, где он добавляет скрытые затраты на поддержку, чем отличается регистрация для Android и iOS, почему важна обертка TypeScript и почему сам TurboModule должен оставаться «тонким».

Мы добавили кэширование, чтобы ускорить работу бэкэнда.

Затем кэширование нарушило авторизацию.

Поначалу ситуация казалась безобидной. Сервису Symfony требовался JWT-токен для взаимодействия с внешним API. Запрос нового токена перед каждым вызовом был неэффективным, поэтому мы сохранили его в кэше и использовали повторно.

При нормальной нагрузке все работало.

При нагрузочном тестировании токен истекал, и несколько запросов одновременно проходили через один и тот же поток. Каждый из них видел пустой кэш и запрашивал у внешнего API новый JWT. Внешний API аннулировал предыдущий токен каждый раз, когда выдавал новый.

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

Решение заключалось не только в использовании общего Memcached, ведь проблема была не в хранилище, а в праве на обновление общего состояния.

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