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

Когда говорят «мы ускорили выполнение нашего запроса в N раз» это значит, что сначала сделали плохо а потом начали думать как улучшить.

Так я думал раньше.

Привет, Хабр! Я Женя, архитектор интеграционной платформы в Точке, отвечаю за асинхронный обмен сообщениями между внутренними сервисами, за ESB и за брокеры сообщений.

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

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

💬 На самом деле, моя идея написания тестов на архитектуру настолько проста, легко реализуема и при этом полезна, что я до сих пор толком не понимаю, почему я не встречал материалов на эту тему, и сама тема всё ещё не используется повсеместно 🙂
Статья написана по следам моих докладов на трёх крупных ИТ-конференциях, на каждой из которых ко мне подходили архитекторы и разработчики российских бигтехов, говорили, что я очень точно попал в их боли и предложил суперпрактику, которую они теперь будут внедрять. На всех трёх конференциях я получил высшие оценки от аудитории, а на двух из них доклад был признан лучшим в своей секции. В конце статьи приведена ссылка на видео доклада с одной из конференций.
В статье я поделюсь своей идеей и OpenSource-реализацией решения для написания тестов, разберу примеры тестов на небольшой учебной микросервисной архитектуре, а также расскажу про личный опыт и профит от применения этой практики.
Для разработчиков монолита тоже есть небольшой бонус: в OpenSource-репозитории появилась реализация и примеры тестов на архитектуру модульного монолита.

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

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

Эта статья — моя подборка приёмов и техник, которые помогут писать лаконичный и производительный код на Go без лишних костылей и велосипедов.

Речь пойдёт о:

полезностях для конкурентного программирования

приёмах в Go в целом, таких как использование iota, работа с ошибками, вывод интерфейса и т.д.

методах оптимизации работы со слайсами

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

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

Я немного опоздал, соревнования проводились в январе. И на Java. Меня не особо интересует Java, зато давно интересует оптимизация кода на Go.

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

Специальная теория относительности - удивительная теория, которая опровергла многие представления о мире, в которых человечество не сомневалось всю историю своего существования.

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

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

Для иллюстраций я написал интерактивный визуализатор СТО, работающий в браузере. Ссылка на него и исходники проекта в конце статьи.

Более 10 лет разработчики на Go жаловались на отсутствие структурированного логирования в ядре Golang. Участники сообщества Golang даже создали несколько собственных пакетов, таких как Logrus, Zap и Zerolog. В 2023 году, команда разработчиков Google Go наконец-то представила Slog — высокопроизводительный пакет для структурированного ведения логов в стандартной библиотеке Go. Мы перевели гайд о возможностях slog.

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

Мое наблюдение состоит в том, что мы — разработчики и продукты, сильно переусложняем, осознанно или нет, но всякие «„Архитектурные комитеты“, „Планирования“, „Апрувы у 50 отделов“ и деплои в 2-часовые окна, простыни текста сопровождающие простейшие фичи — это просто какой‑то бич современной разработки. Умные дяди с 20 летним опытом за плечами, с невозмутимыми лицами сутки напролет на созвонах обсасывают простейшие вещи вроде замены кнопки. Что это? Следствие усложнения программного обеспечения или засилие не тех людей не на тех местах? Или следствие входа в индустрию новичков, стремящихся простое сделать сложным?

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

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

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

Общая тенденция развития технологий характеризуется рывками и спадами. Рассмотрим, например, массовое перемещение человеческих тел. Изначально применялись лошади и повозки, которые постепенно стали сложными, и эта технология превратилась в отдельную индустрию. Затем внезапно появились поезда. Про лошадей быстро забыли, и фокус сместился на новое направление. Пар стал объектом исследований и превратился в сложную науку. Параллельно развивались дизель и электричество. В определенный момент паровые двигатели ушли в прошлое, и все перешли на дизель и электричество. Аналогично сейчас происходит переход на электромашины, требующие значительно меньшего количества жидкостей.

Технологии эволюционируют и функционируют, а новые технологии их полностью заменяют. Считаю, что сейчас наступает эпоха, когда технологии фреймворков и Электрона могут быть вытеснены генеративными AI. Рассмотрим несколько примеров.

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

Не смотря на то, что книга написана еще в 2014-2016 годах (первое издание в O’Reilly вышло в 2018-м), «Кабанчик» не теряет, а только приобретает актуальность. Разрабатывая высоконагруженные приложения для финтеха и управляя разработкой таких систем, я нахожу много полезного в книге Клеппмана. При этом если отобрать дюжину разработчиков, то «Кабанчика» читали от силы несколько из них.

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