­­­Какие предметы вам нравились в школе? Я очень любила математику.  Меня завораживали цифры, формулы и логические рассуждения. А самое главное, даже если решать задачу несколькими разными способами – единственно верный ответ всегда будет один. И проверив его, можно быть уверенным, что задача решена правильно.

Сейчас, проектируя программные системы, я тоже решаю задачи, но они принципиально отличаются от математических, где всегда есть единственно верное решение. Если в школе небольшого условия задачи было достаточно, при проектировании это не так. Как говорил итальянский программист Альберто Брандолини: «В прод идут не знания экспертов в предметной области, а предположения разработчиков». Поэтому важно не просто полагаться на своё понимание, а проверять предположения на практике.

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

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

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

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

· Библиотека — узкоспециализированная программа, основной потребитель разработчик.

· Command Line Interface — консольные утилиты, где пользователем может быть кто угодно, а даже если это программист, то он не обязан понимать как CLI устроен внутри.

· Сервисы — Worker, WEB/API/RPC-сервисы и др.

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

- архитектура слоев;
- предметно-ориентированное проектирование (DDD);
- разделение команд и запросов (CQS);
- архитектура портов и адаптеров.

Также будет затронута тема именования файлов .go и вопросы связности (low coupling/high cohesion).

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

Ребята, я вас сейчас разочарую. В «Едином адресе» не одна адресная модель, а несколько. И ни одну из них копировать просто так не нужно. 

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

ScyllaDB — это высокопроизводительная распределённая NoSQL-база данных, совместимая с Apache Cassandra, но в разы более быстрая за счет того, что написана на C++. Однако, несмотря на сверхбыструю скорость работы, можно ли сделать ее еще быстрее?

DeepSeek 1.5B — маленький, но шустрый собрат больших языковых моделей. Работает локально, не требует железа на киловатт.

Внутри — инструкция по установке, настройке и запуску DeepSeek 1.5B на Ubuntu 24.04 с Ollama и Open WebUI.

Почему так сложно пройти первые System Design Интервью? Какие есть подводные камни? Оказывается, что не все понимают базовый алгоритм прохождения, а также нюансы движения по основным этапам.

Меня зовут Владимир и я senior backend в геораспределенной HighLoad системе. Которая выдерживает пиковые нагрузки в млн RPS. Моя страсть System Design. Я успешно прохожу интервью в BigTech компании, а также готовлю учеников. Выделил ТОП-5 ошибок у новичков и готов поделиться их разбором. Подробности под катом.

Привет, Хабр! Я Никита Иванов, техлид команды «Видео» в KION. В ИТ я уже девять лет, а последние пять работаю с Go. Сегодня расскажу, какую задачу считаю идеальной для собеседования на позицию Go-разработчика. Этот текст — переработка моего доклада с митапа МТС True Tech Go, видеоверсию можно посмотреть тут.

Программисты знают, что технические интервью редко бывают простыми. Составить задачу, которая честно проверяет реальные скилы, а не сводит все к банальному FizzBuzz, — отдельное искусство. Ниже поделюсь своим подходом к формулировке таких задач, расскажу о реальном кейсе, нюансах подбора и критериях оценки, которые действительно работают на практике. Думаю, этот текст будет полезен техлидам и менеджерам, а еще разработчикам, которые собираются на собеседование.

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

Привет, Хабр! Меня зовут Егор Толстой, я — ведущий подкаста Podlodka и автор Роадмапа Тимлида. Веду телеграм-канал Teamlead Good Reads, где каждый день делюсь идеями о работе с командами. Публикую перевод интересной статьи для техлидов от технического консультанта Авива Бен-Йосефа, автора книги The Tech Executive Operating System.

«У нас никто никогда не сдаётся!» «Посмотрите, какой хакатон мы провели!» «Мы жёстко закладываем время на борьбу с техдолгом».

На первый взгляд — правильные и вдохновляющие лозунги. Но на деле это просто рекомендации, которым имеет смысл следовать… если вы хотите управлять посредственной командой.

Как технический лидер, вы часто попадаете в ловушку «общепринятых» практик. Но что, если именно эти практики тормозят развитие вашей команды и организации? В этой статье — шесть нестандартных установок. Они могут показаться непопулярными, зато помогут выстроить устойчивую, инновационную и по-настоящему эффективную команду.

Ты что-то ждёшь от коллег из другого подразделение / продукта. Попросил раз. Попросил два. Написал в чат — тишина. Напомнил ещё раз — снова молчание. Знакомо? Что делать дальше? Самый очевидный путь - эскалация. Но точно ли он лучший?

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

Расскажу про свой опыт конфигурирования приложений, разобрав некоторые популярные библиотеки и примеры.

В данной статье расскажу о планировщике Go. Основу материала взял из книги Уильяма Кеннеди Ultimate Go. Вначале поговорим о планировщике OS, после перейдем к планировщику Go и сравним их.

Делюсь личным опытом превращения старенького ноутбука ASUS X552CL (Intel i5-5200U, 12 ГБ RAM, SSD + HDD), выпущенный 12 лет назад, в полноценный домашний сервер под Linux Ubuntu Server 24.04.5 LTS.

Получилось что-то вроде мини-датацентра на дому — он хранит файлы на жёстком диске с бэкапом в облаке, Docker-контейнеры крутит для дата-аналитики и даже имеет легковесный интерфейс XFCE, при этом есть потенциал к росту до терминала для управления умным домом. Расскажу, почему было решено отказаться от WSL на рабочем ноутбуке Huawei, как настроить удалённый доступ через xRDP (чтобы не было чёрного экрана), запустить там Docker, сборку Superset и JupyterLab с Anaconda (с разными версиями Python), прикрутить Samba-шару для домашнего использования и организовать бэкап в облачном хранилище. В этой статье будет немного технических деталей, щепотка шуток и парочка мемов с советскими плакатами.

Всем привет, я Илья Сергунин, веб-разработчик из продуктовой команды Авито. Мы пишем на Go сервис для трейд-ин мобильных телефонов. На его примере покажу, как устроен наш менеджер транзакций.

Go предлагает уникальный и прямолинейный подход к обработке ошибок, отличающийся от try-catch в других языках. Он основан на явной проверке возвращаемых значений, что требует больших проверок, но ведет к более надежному коду. Рассмотрим основы, современные инструменты пакета errors и лучшие практики.

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

И это решит 95% проблем типичного стартапа. Как-то так повелось, что по всему СНГ и его окрестностям на работу набирают зумеров с колоссальным опытом в три года, и они начинают создавать идеальные архитектуры. Да, каждый из вас, как только получает возможность взять на себя хоть малейшую ответственность, сразу вспоминает все прочитанные и не прочитанные книги и пилит свою уникальную архитектуру, непохожую ни на что.

Меня зовут Александр, я CTO компании AppFox. Мы более 10-ти лет занимаемся заказной разработкой и также имеем собственные продукты. 

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