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

Язык проектировался простым, лёгким в освоении, готовым для написания сервисов с первого дня. Он мог бы таким и остаться, если бы не одна проблема. Проблема отбора.

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

Явно ставилась задача — сделать язык достаточно простым, но не настолько, чтобы собеседование мог пройти любой новичок.

На собеседованиях мы слышим или говорим сами, что поиск в массиве медленнее, чем в хеш-таблице. Кто-то даже вспоминает, что поиск в массиве имеет линейную сложность или O(n), а в хеш-таблице — константную O(1). Но работает ли это на практике? Что, если есть ситуации, когда поиск в массиве оказывается быстрее? Давайте не будем торопиться с выводами.

От мессенджеров и видеоплееров до «необходимых для работы» инструментов на десятки гигабайтов. Интернет был, скорее, местом для поиска, а не для реальной деятельности. Но браузер постепенно превратился из простого окна в нечто гораздо большее.

Сначала переехали почта и офисные приложения. Потом пришли трекеры задач, инструменты для дизайна. Даже обработка видео и трёхмерная графика теперь доступна онлайн. И вот, казалось бы, последний бастион — полноценные IDE — тоже дрогнул.
Настройки окружений, специфичные для ОС зависимости, вечные «оно работает у меня» — всё это становится анахронизмом. Удобнее открыть вкладку и просто начать работать без установки, обновлений и потерянных на настройку выходных.

Если вы тимлид, DevOps или поддерживаете живой репозиторий, то наверняка знаете эту ситуацию: нужно быстро поправить README, обновить контент для Pages или внести небольшую правку по итогам рецензирования. Изменений на несколько минут, а дальше стандартный сценарий: клонировать репозиторий, открыть IDE, дождаться индексации, вспомнить, в какой ветке вообще планировалась правка. Сам код при этом простой, а контекст задачи давно понятен.

Мы в GitVerse регулярно сталкивались с такими случаями — и как пользователи, и как команда продукта. Поэтому решили не «делать ещё одну IDE», а упростить именно этот класс задач. Об этом и расскажем в статье.

RooCode — расширение для VS Code с многоагентной системой (встроено 5 Модов: Orchestrator, Ask, Architect, Code, Debug)
Ключевые преимущества: синхронное выполнение задач (предсказуемость), гибкая настройка модов, MCP-серверы для снижения ошибок и количества запросов к LLM
Основная идея настройки: каждый Мод отвечает за свою задачу, Оркестратор распределяет работу между ними
Настройка идёт по спирали: от базовых настроек → скиллы → моды → провайдеры → итеративное улучшение

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

Привет, Хабр!

В каждом проекте рано или поздно появляется логика вида «этот пользователь может редактировать этот пост, а тот нет». И начинается: if ($post->getAuthor() === $currentUser) в контроллерах, в сервисах, в шаблонах. Копипаста расползается, а потом приходит новое требование — «модератор тоже может редактировать, но только в своей категории» — и вы бегаете по двадцати файлам, молясь, что ничего не забыли.

Symfony Voters — механизм, который выносит всю логику авторизации в одно место. Не аутентификации (тип кто ты?), а именно авторизации (что тебе можно?). Разберём, как это работает.

В этой статье, про ИИ, написанной не полностью ИИ, про генерацию изображений - не будет изображений.

В конце этой статьи мы будем запускать эту модель на указанном чипе, но начнем мы с чуть более мощного - он понадобиться чтобы разобраться с проблемой.

Первая проблема с которой я столкнулся - это потребление памяти. Поиски в интернете, описание самой модели говорили о том что она должна помещаться в ~10GB VRAM. Чего должно с запасом хватать для Apple M1 16GB. Однако фактическое зафиксированное потребление памяти составило 21 GB, не зафиксированное 28 GB (после чего я и начал исследование).

Важный момент: agent-pool - это MCP-сервер, который работает и в IDE, и внутри самого Gemini CLI. Воркер может сам делегировать задачи дальше - создавать подгруппы и запускать своих воркеров. На этом строится вся фрактальная оркестрация.

Excel не единственный, кто любит превращать любые данные в даты.

Если вы работаете с датами в JavaScript, то, вероятно, рано или поздно пользовались new Date(someString). Это удобно: передаём строку, получаем объект Date. Но привыкнув к Python, я был удивлён тем, насколько свободно JavaScript обращается с форматами дат. Позвольте мне проиллюстрировать это примерами.

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

Пишете на Go или только начинаете изучать язык? Эта шпаргалка точно сэкономит вам кучу времени. Никакой воды, абстрактных рассуждений и скучных введений. Мы пройдёмся по тем самым ситуациям, с которыми бэкендеры сталкиваются на каждом проекте: конкурентность, сеть, работа с JSON, обработка ошибок, тесты и дебаг.

Можете смело добавлять это в закладки. Забыли синтаксис или паттерн, открыли нужный раздел, скопировали, адаптировали и поехали дальше.

Сейчас в IT забавная ситуация. Одни компании отчитываются о кратном ускорении с ИИ и экономии миллионов рублей. Другие потратили бюджет на лицензии, обучение и евангелизм — и получили команду, которая тихо ненавидит Copilot и пишет код руками, как в 2019-м. Разница между первыми и вторыми не в технологии. Технология одна и та же. Разница — в людях и в том, как с их сопротивлением работают. Или не работают.

Привет, Хабр. Мы — Сергей Калинов и Андрей Макар-Уваров, руководители бизнес-анализа и фронтенд-разработки в Surf. Несколько лет внедряем ИИ на реальных проектах и видим, что сопротивление ему проходит по вполне узнаваемым стадиям Кюблер–Росса. Разберём, почему разработчики так реагируют.

О проблемах с ИИ-кодингом на Хабре написано уже много. Но хочется перейти к конструктивному подходу: да, наломать дров с ИИ легко, а вот как работать с ним наиболее профессионально?

Известные разработчики вроде Митчелла Хашимото (создателя Terraform и Ghostty) всё чаще говорят что-то в духе «вот тут уже ни строчки кода не написал вручную». При этом Хашимото — противник слопа, и он подчёркивает, что добился от ИИ качественного кода. А что помогает добиваться?

Мы в проекте Kodik подобные вопросы ощущаем особенно остро, потому что в редакторе кода с ИИ делаем… собственно, сам этот редактор кода с ИИ. Так что для нас все проблемы особенно наглядны, а их решения — особенно важны.

Поэтому мы собрали вместе идеи и из опыта мировой IT-индустрии, и из нашего собственного. Это не какая-то «окончательная истина»: сейчас вся планета только разбирается, ни у кого ещё нет полных ответов, и полезно обмениваться опытом. Так что смело дополняйте в комментариях: интересно узнать, что помогает вам, и собрать «общехабровую кладезь знаний». Если кто-то захочет конструктивно возразить, такое обсуждение тоже полезно.

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

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

Все ошибаются. Ничего не поделаешь, shit happens, это нестрашно. Намного хуже, когда сильные, умные люди начинают сомневаться в себе из-за косяков. 

Причём не из-за каких-то критичных провалов, а из-за мелочей: где-то опоздали на пару минут на созвон, где-то пришлось переделывать задачу, где-то что-то не то сказали на встрече. И переживают потом: «Боже, зачем я это сказал вчера? Теперь все думают, что я дурак».

Привет, Хабр. На связи Саша Сергеев, CTO в Профи.ру. Я сам через это проходил. И часто вижу подобный страх ошибок в других. 

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

Собрала актуальный маршрут обучения Claude Code: с чего начать, какие доки и курсы пройти, и как перейти от просто попробовать к автоматизациям (skills/hooks/sub-agents/MCP).

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

Салют, Хабр!

Меня зовут Иван, я разработчик на Go. В SberDevices я занимаюсь реализацией интеграций — обеспечиваю возможность подключать устройства разных брендов к Умному дому Сбер. Он построен на микросервисной архитектуре. Кажется, что всё просто: чтобы интегрировать два умных дома между собой, нужно узнать их протоколы — наборы типов устройств и их возможностей с определёнными форматами их описания — и на основе протокола создать адаптер. Но есть проблема: как правило, каждая модель устройства, например, чайника, уникальна. Нельзя написать универсальную функцию f:SberSH -> PartnerSH , которая будет выполнять преобразования всего множества устройств: сложность задачи масштабируется вместе с их количеством. Но можно упростить и унифицировать процесс создания этих преобразований. Рассказываем, как сделали это в Умном доме Сбер. 

Iceberg становится де-факто отраслевым стандартом при построении lakehouse в России. Для сравнения, на последней конференции smart-data, Iceberg по частоте упоминания уступает только Spark. Это значит, что уверенное владение механикой работы Iceberg становится обязательным навыком для инженеров данных и платформенных команд. Однако на практике большинство команд при внедрении ограничиваются базовыми возможностями, вроде создания таблиц, настройки партиционирования, настройки сompaction-процедур

При этом значительная часть производительности и стоимости эксплуатации Iceberg таблиц определяется менее очевидными деталями: устройством метаданных, стратегиями записи файлов и тем, как движки выполнения используют статистики файлов. Эти аспекты редко оказываются в центре внимания, но именно они часто становятся причиной деградации производительности по мере роста таблиц. На деле же пространство оптимизаций гораздо шире.

В этой статье я разберу несколько неочевидных оптимизаций Iceberg таблиц.

GIL — самая известная «фича» Python, о которой большинство разработчиков знают ровно одну фразу: «мешает многопоточности». Этого хватает для джуна, но не для сеньора.

Статья построена так, чтобы после её прочтения вы могли не только ответить на вопросы по GIL на senior-интервью, но и объяснить коллеге-стажеру, что происходит внутри интерпретатора, когда два потока пытаются одновременно изменить один список.

11 марта 2026 года Cursor опубликовал пост под скромным названием «Как мы сравниваем качество моделей в Cursor». Без громких заявлений. Без атак на конкурентов. Просто пять графиков и спокойное объяснение внутреннего процесса оценки.

ИИ-сообщество в основном отнеслось к этому как к очередному «компания рассказывает о своём бенчмарке». Это было ошибкой.

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

Вот что показал Cursor. И вот чего они не сказали вслух.