Бэкенд

Введение

В данной статье будет рассмотрена практическая интеграция MongoDB с веб-приложением на Go, построенным на базе маршрутизатора Gorilla Mux. Цель — получить минимальный, но функциональный REST API с поддержкой CRUD-операций над сущностью Book, при этом соблюдая лучшие практики структурирования кода.

Материал рассчитан на разработчиков, знакомых с Go, HTTP API и основами работы с базами данных.

Выбор стека

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

Привет, Хабр! Сегодня я расскажу про реализацию матричного умножения и особенности разработки для GPU. Познакомлю вас с устройством GPU, объясню, чем отличается программирование от привычного для CPU, какие нюансы нужно учитывать для эффективной реализации операций GEMM. А затем сравним производительность разных подходов к реализации.

Я сделал простейшую утилиту для регистрации в контейнере по атрибутам на интерфейсе\реализации. Добавил тесты а так же поддержку IServiceCollection.

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

Многие разработчики при обсуждении основ Clean Code называют одни и те же принципы — чаще всего упоминаются DRY, KISS и YAGNI. Эти концепции прочно закрепились в профессиональном сообществе и воспринимаются как обязательная часть хорошего кода.

Принцип RUG упоминается значительно реже. Чаще всего о нём узнают с опытом, а многие применяют его интуитивно, даже не подозревая, что для этого подхода существует отдельное название и формулировка.

Сегодня я хочу поговорить о принципе RUG и о том, какие рекомендации он даёт по написанию программного обеспечения.

RUG (Repeat Until Good) — это принцип, который говорит: можно повторять один и тот же код, пока это разумно.

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

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

Я буду использовать TypeScript, так как этот язык знаком большинству разработчиков. 😁

Всем привет! 👋👋👋👋👋 Мы Java-разработчики Т-Банка: Андрей, Арсений, Роман, Константин и Константин. Собираем интересные новости, статьи, туториалы и другие материалы из мира Java-разработки и делимся этим со всем сообществом.

Лето в разгаре, а Java-мир не останавливается ни на день. Пока кто-то разъезжается в отпуска, инженеры Oracle и энтузиасты экосистемы выкатывают один апдейт за другим. В этом выпуске вас ждут: JEPs для JDK 25 и 26 — от стабильного JFR до удаления Applet API, милестоны Project Reactor и Spring Framework 7, обновления от Micronaut, Apache Camel и GraalVM, день рождения Kotlin и революционные новости от JetBrain, пачка интересных видео с Java One’25 и Inside Java, обзоры книг, туториалов и просто полезные статьи на каждый день. А еще 30 августа нас ждет встреча на JVM Day в Москве!

Заваривайте кофе и читайте — от инженерных мелочей до изменений, которые могут повлиять на архитектуру ваших приложений. Поехали! 🚀

Apache Kafka — король асинхронного взаимодействия в микросервисных архитектурах. Но что если нужно получить ответ сразу?

Перевод от команды Spring АйО шаг за шагом покажет, как превратить Kafka в инструмент синхронной коммуникации — с настройкой ReplyingKafkaTemplate, топиками для ответа и тайм-аутами.

Привет! Меня зовут Антон Головенко и я backend-разработчик команды Search-Quality в Авито. Вот уже полтора года я ускоряю производительность поиска и повышаю его надежность, а также участвую в интеграции новых продуктов. В статье расскажу о том, как мы тестировали Redis под нагрузкой, с какими проблемами столкнулись, как их решали и какие выводы сделали. Заголовок звучит кликбейтно — но вы скоро поймёте, что он полностью оправдан.

Вполне логично предположить, что сократитель ссылок — довольно простой сервис как с точки зрения пользователя, так и под капотом. Но что, если, взяв за основу такую простую задачу, построить целую распределенную систему?

Мой шортенер начинался как простая практика с Go и gRPC после всех ОГЭ:), где должно было быть 3 сервиса: тг бот, API gateway и ядро. Но с каждым днем идей все больше, энтузиазм растёт, я стал делать упор на высокие нагрузки, и постепенно мини‑практика начала становиться боевой event-driven машиной. В этой статье я хотел бы подметить интересную мысль: даже самая простая вещь может быть реализована сложно.

Библиотека функций к Script-fu

После написания объектной системы для Script‑fu я задумался над примерами, на которых хорошо бы было проверить эту систему. Я прошерстил уйму литературы, но хороших примеров использующих все возможности ООП в литературе встречается крайне мало. Ну что толку реализовывать класс List в Лиспе? А класс Stack? Примерами подобных классов пестрят книжки по Си++. Всё было не интересно, но вот я встретил книжку «Теория вычислений для программистов» Тома Стюарта, и вот примеры из неё, написанные на Ruby, показались мне интересными. Да в Ruby нет множественного наследования, но есть возможность создавать миксины, что несколько сглаживает этот недостаток. И вот делая примеры из этой, безусловно замечательной(с точки зрения теории вычислений), книжки я заметил, что мой код получается более длинный чем код Ruby. И это происходит не только из за наличия операторов в Руби. Сами определения классов и методов в Руби получаются компактнее, и требуют меньше кода. Сможем ли мы что нибудь сделать, чтобы «догнать» Руби в «краткости» кода?!

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

Представьте будущее, где искусственный интеллект молча берет на себя рутинную работу в разработке ПО: рефакторинг запутанного кода, миграцию legacy-систем и поиск состояний гонки (race conditions), позволяя инженерам-людям сосредоточиться на архитектуре, дизайне и действительно новых проблемах, которые пока недоступны машинам.

Последние достижения, казалось бы, приблизили нас к этому будущему, но новая работа исследователей из MIT Computer Science and Artificial Intelligence Laboratory (CSAIL) и нескольких партнерских институтов утверждает, что эта потенциальная реальность требует трезвого взгляда на современные вызовы.

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

Наша рубрика «Где работать в IT» — это интервью с интересными айти-компаниями, в которых они делятся подробностями о процессах своей работы. Представители индустрии отвечают на вопросы о найме, условиях, командах и технологиях.

В этом выпуске мы расскажем про компанию DatsTeam, которая разрабатывает рекламные платформы, игры, мобильные приложения и финтех-решения. В команду продуктовой разработки входят PM, PO, инфраструктура, DevOps, SecOps, QA. Основные стеки — JAVA Spring, PHP Symfony, React, iOS, Android.

О том что Huawei обнародует собственный язык программирования новости ходили уже давно. Ещё в прошлом году при поиске работы мне уже предлагали работать с этим языком - правда "не сейчас а вот-вот вскоре" :) На тот момент компилятор и прочие инструменты ещё не были в открытом доступе. Сейчас же страница скачивания - вот она - под Linux, Windows и Darwin (да ещё и плагин к VSCode)!

В этой статье - беглый обзор. Я попробовал скачать-запустить и, пройдясь по разделам документации, описал основные фичи - так что вы можете сэкономить себе время и за 5-10 минут составить представление о Cangjie. Сразу скажу - чего-то оригинального, инновационного - я не заметил. Нет такого, чтобы как с Haskell, Erlang или Rust на первых порах пришлось ломать голову. Для программистов на Java, Go, C++ много будет довольно привычных вещей (можно сказать - "обокрали" эти языки тут и там понемногу).

Всякое про Cangjie писали, начиная от того что там будут только китайские иероглифы - и заканчивая специальной поддержкой для создания приложений с ИИ - ничего этого в данной статье не будет. Иероглифов (кроме как в тьюториалах) не встретил, а поддержка ИИ если и есть, то самого языка она не касается.

Есть нюанс с примерами - Habr естественно не поддерживает подсветку синтаксиса для Cangjie (пока) - а для наглядности это желательно. Пожалуй буду вставлят картинками, за что заранее прошу извинения.

Когда мне понадобилось задеплоить один и тот же контракт в разные EVM-сети с одинаковым адресом — оказалось, что всё не так просто. Даже если всё заранее посчитать и подготовить, любой лишний nonce может всё сломать.

В этой статье я разбираю, как вообще формируется адрес контракта при деплое (при использовании CREATE и CREATE2), зачем появился Deterministic Deployment Proxy, и почему Safe в итоге сделали свою версию — Safe Singleton Factory.

Расскажу, как ей воспользоваться через Remix, Foundry и Hardhat, на что стоит обратить внимание (например, при работе с байткодом), и какие грабли могут ждать при попытке всё упростить.

Спойлер: не ради докладов. Хотя не знаю, я их не смотрел 

Если вы хотите погрузиться в мир техдолгов, балансировок нагрузки, оптимизаций и архитектурных страданий, вам сюда. А если вы хотите найти единомышленников, задать вопрос, который не задашь на Stack Overflow, или просто почувствовать, что вы не один, то вам тем более сюда!

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

Тем не менее, часто во время сборки проекта я, как и многие другие люди, просто втыкаю в монитор и думаю о своём. Кто-то уходит в телефон, кто-то читает статью, кто-то идёт покурить. Ну а я просто раздумываю — что движет людьми в моём опенспейсе? Почему один пришёл в IT за деньгами, а другой — за признанием? А в чём отличие третьего — не ясно даже ему самому.

Разница поколений и разный опыт — всё это влияет на то, как мы думаем, как работаем, как спорим. Порой я ловлю себя на мысли: а что думают они о человеке N? Почему-то снова вспоминаю слова Романа Елизарова:

«Есть категория людей, которые хорошо мотивируются соревновательным моментом… И благодаря ICPC появились многие IT‑специалисты, которые вместо того, чтобы гулять и прожигать жизнь, день и ночь изучали алгоритмы… и получались такие сильные программисты, которых нигде не сыщешь.»

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

По утверждению Роберта Мартина, объектно-ориентированный подход был предложен 1966-м году. Для эмуляции объектов они использовалась возможность языка ALGOL, позволяющая переместить кадр стека вызова функции в динамическую память (кучу).

В этом смысле в 2001 году Гвидо ван Россум переизобрёл объекты, добавив Python 2.2 генераторные функции.

Меня зовут Александр Вирочкин, я руковожу командой инфраструктуры мини-приложений ВКонтакте. За последние два года мы мигрировали один из ключевых сервисов с PHP на Go — путь выдался непростым, но, уверен, наш опыт будет полезен многим. Не все получилось с первой попытки: мы столкнулись с типичными и не очень проблемами, зато смогли по-настоящему оценить роль внутренней PaaS-платформы и экспертизу коллег.

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

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