Когда говорят «мы ускорили выполнение нашего запроса в N раз» это значит, что сначала сделали плохо а потом начали думать как улучшить.
Так я думал раньше.
Software Engineer
Когда говорят «мы ускорили выполнение нашего запроса в 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 страниц). Читать «Кабанчика» непросто, не так трудно как Хофштадтера, но и не так просто, как Вольфрама. Но не смотря на то, что книга написана давно, в ней неплохо отзываются некоторые современные проблемы.
Queue
(очередь) — структура данных на диске или в оперативной памяти, которая хранит ссылки на сообщения и отдает их копии consumers
(потребителям). Queue
представляет собой Erlang-процесс с состоянием (где могут кэшироваться и сами сообщения). 1 тысяча очередей может занимать порядка 80Mb.
Binding
(привязка) — правило, которое сообщает обменнику в какую из очередей должны попадать сообщения.
Продолжаю публикацию расширенных транскриптов лекционного курса "PostgreSQL для начинающих", подготовленного мной в рамках "Школы backend-разработчика" в "Тензоре".
В этой лекции углубимся в расширенные возможности команды SELECT
: как можно "сложить" и "вычесть" выборки (UNION/INTERSECT/EXCEPT
), или запомнить и использовать в рекурсивных запросах (CTE
), что дают оконные функции (WINDOW
) и соединения (JOIN
).
Как обычно, для предпочитающих смотреть и слушать, а не читать - доступна видеозапись.
Самое страшное слово для инноватора или очень уж упёртого студента, который проходит практику у вас в компании: «Зачем?»
Знаете почему? Потому что в 80% случаев ответа вам на этот вопрос не дадут. Давайте разберёмся, причём здесь Оккам и что ему от нас нужно.
Ваш аккаунт