На собеседованиях часто можно услышать вопрос: «Назовите принципы хорошего кода». Даже начинающие, но уже имеющие практический опыт программисты интуитивно понимают: хороший код — это читаемый, переиспользуемый, легко расширяемый и поддерживаемый. Но что обеспечивает эти качества? Ответ кроется в объектно-ориентированном программировании (ООП).
Всем привет! Меня зовут Денис Ланин, я один из старших дизайнеров в Юзтехе. В этой статье я поделюсь опытом создания своего плагина Mirage для Figma, который помогает быстро генерировать тестовые данные в таблицах и облегчает рутинные задачи дизайнеров. Я расскажу о процессе проектирования, с какими сложностями столкнулся, как их решал и что получилось в итоге.
Статья будет полезна дизайнерам интерфейсов, продуктовым специалистам и всем, кто работает с Figma и заинтересован в автоматизации и оптимизации рабочего процесса. Приятного чтения!
Ранее мы говорили о том, как улучшить кэширование наших проектов и правильно загружать поставщиков. А в этой статье мы рассмотрим следующее:
- Как мы можем использовать стратегии предварительной загрузки, включая что такое "магические" комментарии Webpack, и что такое спекулятивная/ручная предварительная загрузка;
- Как мы можем запрашивать данные с сервера, не дожидаясь загрузки наших статических файлов;
- А также какие сторонние или наши собственные решения могут быть использованы для этого.
Ранее мы поговорили о том, как сделать дерево зависимостей нашего проекта максимально чистым и почему это важно для ленивой загрузки. А в этой статье мы расскажем о следующем:
- Как мы должны загружать вендор файлы с точки зрения правильной организации ленивой загрузки.
- Что общего между стратегиями оптимизации "ленивой загрузки" и "кэширования", и как использование одной из них влияет на другую.
- Что такое кэшируемость и как сделать наше приложение максимально кэшируемым.
- А также как правильно настраивать группы кэша в Webpack и не испортить кэшируемость.
Ранее мы обсуждали самые основы ленивой загрузки и то, почему она вообще важна. А в этой статье мы рассмотрим следующее:
- Как бандлеры анализируют файлы исходного кода, строят деревья зависимостей и генерируют файлы для сборки.
- Как они генерируют файлы JavaScript из исходного кода.
- Как браузеры решают, какие сгенерированные файлы следует загружать, чтобы отобразить ленивую страницу/компонент.
- И как мы можем уменьшить размер и количество загружаемых файлов, правильно настроив структуру файлов и корректно используя статический импорт.
Ленивая загрузка - это принцип, который должен быть известен большинству frontend разработчиков. Однако, этот механизм обманчиво прост, и его освоение является гораздо более комплексной задачей, чем кажется многим. Если уже используете Lazy Loading, у вас все равно могут быть серьезные пробелы в знаниях. Но даже если вы считаете, что знаете про ленивую загрузку абсолютно все, освежить память не будет лишним.
В этой статье мы рассмотрим основы ленивой загрузки: что это такое и почему это важно;
как мы можем использовать ленивую загрузку в наших проектах; а также какие части кода следует загружать лениво.
Мы сделали продакшен-решение под сложное ТЗ, собрали всё — от FastAPI и PostgreSQL до ELK и CI/CD. А победили ребята с презентацией в Figma и пустым сайтом.
Жюри сказало, что «всё по бизнес-требованиям».
Рассказываю, как проходил «самый масштабный хакатон страны» и почему он стал фарсом.
При разработке игры в условиях 72-часового джема звук часто становится последней линией защиты, на которую заканчиваются силы. Главная задача прототипа — создать ощущение, что игра «живая и отзывчивая», а звук главный инструмент для этого. В этой статье мы разберем иерархию звуков на реальном примере нашей игры «Выход из строя», созданной на Siberian Game Jam — Ноябрь 2025
Что такое полезное действие и почему оно важно для звука?
Привет, Хабр! Это моя первая проба пера. Статья будет на тему «как разработчик из кровавого Enterprise статейник писал». Может быть интересно либо таким же как я, либо наоборот, ребятам которые занимаются сайтами‑статейниками и подумывают в сторону работы в больших корпорациях. Словом, для всех, кто хочет посмотреть, как оно там, у других. В ходе написания статьи я буду использовать привычную терминологию и пояснять ее. Статья идет от простого к сложному, поэтому если вы из «кровавого Enterprise» — можно пролистать статью до момента деплоя (часть 2).
Привет! Сегодня разберем два подхода в ASP.NET. Blazor и классическую архитектуру MVC (Model-View-Controller). В отличие от обсуждений вроде «Java vs C++», эта тема менее спорная, но очень полезная для понимания современной веб-разработки на .NET.
Привет, хабр! Сегодня хочу рассказать об одной технологии, которая сопровождает нас буквально везде. От процессора в вашем смартфоне до глобальных сервисов вроде YouTube. Речь пойдет о кэшировании.
Да, я знаю, тема кажется избитой. Но когда я впервые осознала, что одни и те же принципы работают на всех уровнях, от крошечного L1-кэша до распределенного Redis-кластера — это было похоже на инженерное просветление. Предлагаю и вам пройти этот путь вместе со мной.
Последние пару лет я регулярно слышал от знакомых велосипедистов одни и те же жалобы на Zwift: "Опять не работает Zwift", "20 евро каждый месяц дорого".
После очередного разговора о проблемах я решил создать альтернативный лаунчер, который решит хотя бы часть из них.
В статье рассказываю:
• Как реализовал серверную обработку интеграций (Garmin, Intervals.icu) для работы без VPN
• Почему выбрал Flask и как интегрировал его с протоколом Zwift
• Как организовал AES-256 шифрование учетных данных
• Какие проблемы возникли с неофициальным Garmin API
• Как сделал современный UI на чистом CSS без React
• Метрики производительности и планы развития
Технический стек: Flask, SQLite, Cryptography, Garth, Jinja2, CSS3.
Получился веб-лаунчер с русским интерфейсом, автоматической загрузкой тренировок и работой всех интеграций без смены стран. Делюсь опытом и кодом.
Всем привет! Сегодня я возвращаюсь с новой порцией TypeScript- и React-магии. Вместе разберем полиморфизм в React, а именно — паттерн as. Зачем он нужен, как его прикрутить без багов и почему это сделает ваши компоненты в разы круче. Как обычно — всё под катом.
15 лет я не писал код, полностью погрузившись в менеджмент. Но LLM вернули мне сверхспособности: в одиночку за два месяца я переписал легаси-проект с 20 тысячами юзеров, который мучил команды разработчиков годами.
Всё благодаря правильной связке инструментов, которые превращают AI в младшего разработчика, архитектора и DevOps одновременно. Делюсь конкретикой: почему терминал лучше IDE для AI-разработки, как управлять контекстом через Rules и MCP, какие модели выбирать для разных задач, и почему фреймворки — ваша защита от галлюцинаций LLM.
Если бы меня 5 лет назад об этом спросили, я бы уверенно сказал, что не сможет. Но сейчас я уже сомневаюсь в этом.
Я уже 26 лет работаю в сфере ИТ и за это время написал немало кода. Месяц назад решил проверить, насколько действительно эффективен искусственный интеллект, и попробовать создать с его помощью сайт. И я его создал — точнее, создал его не я, а он. Вот результат: https://windowrepino.ru/. Я лишь ревьюил код и делал рефакторинг.
Да, его код не идеален и, конечно же, есть что улучшить, но он рабочий и удовлетворяет моим требованиям к нему. Более того, я понимаю, что без него я бы потратил гораздо больше времени и, возможно, обошёлся бы более простыми решениями.
Тут немного подробнее: месяц назад у меня не было даже идеи, как должен выглядеть мой сайт и что я хочу. И за этот месяц я потратил кучу времени на то, чтобы сделать фотографии, изучить архивы и объездить весь посёлок в поисках интересных мест.
Плюс сама работа с фото — выбрать хорошие кадры, обрезать лишнее, что-то поправить, где-то почистить. Всё это вместе с кодом было сделано за месяц.
Да, соглашусь, что если бы я делал такой же сайт ещё раз, то сделал бы быстрее, так как уже знаю, как он должен выглядеть и что на нём будет. Но, повторюсь, у меня даже идеи не было, когда я начинал.
Плюс в течение этого месяца у меня было немало других дел. Например, я занимался установкой и настройкой программного обеспечения для распознавания речи, менял проводку в доме — на это ушло в сумме шесть дней, не считая множества других дел, которые тоже требовали времени.
Всем привет! Недавно я делился своим обзором на Devin, в котором рассказал как потратил 500 долларов на вайбкодинг AI‑редактора и остался не особо доволен – он хоть и справился, но было дорого и долго. Продолжаю поиск своего идеального кодинг‑агента и сегодня разбираюсь в Codex от OpenAI.
Во время выполнения очередного проекта мне пришлось работать с Битрикс ORM, при этом параллельно в системе был инстанс Laravel. Две разные ORM работали с единой базой данных. Не буду вдаваться в причины, по которым был выбран такой подход, и воздержусь от его оценки. Суть в том, что мне приходилось одновременно работать с двумя принципиально разными системами. Этот опыт привел меня к фундаментальному выводу: ORM — не для меня.
Большинство наших «проектов мечты» умирают не потому, что идея плохая, а потому что мы останавливаемся на уровне «ну вот, фронт есть, бэк вроде тоже, как-нибудь допилю оплаты и выложу». Не допиливаем. Потому что платежи, вебхуки, витрина, SEO, публикации — это уже не «интересный код», а «организационная скука».
Проект как раз про то, чтобы скучное сделать готовым и многоразовым. Мы один раз собираем связку: AI → Django/DRF → ЮKassa → деплой → Web Stories → SEO, а дальше в неё можно подставлять вашу идею — не только Mermaid. Mermaid здесь как манекен: на нём удобно показывать, куда вешать оплату, куда прикручивать экспорт, где пускать трафик.
Если у вас в голове крутится мысль «я бы запустил свою фичу, если бы была готовая дорожка к деньгам» — это она.
Все разработчики знают, что такое техдолг.
Но практика показывает, что даже в рамках одной команды люди могут по разному трактовать понятия техдолга, технических задач и пр.
Предлагаю разобраться, что же это такое, откуда берется и что с этим всем можно делать.
