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

В прошлой статье мы начали разговор о паттернах микросервисов (Часть 1). Ну что ж, давайте продолжим!

Паттерн «API-шлюз» (API Gateway)

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

Я хочу, чтобы вы задали себе один вопрос и честно на него ответили. Когда в последний раз вы получали настоящее удовольствие от программирования? Оглядываясь назад, я понимаю, что не испытывал подобных ощущений, наверное… уже лет десять. Удовольствия у меня не было ни от JavaScript, ни от Python, ни от Ruby или C — ни от чего. Когда я говорю «удовольствие» — я имею в виду ощущения человека, которого во время работы над неким проектом переполняет искренний восторг. Этот человек постоянно ловит себя на такой мысли: «Ох, ну какая ж круть. Поверить не могу, что моя безумная идея и правда сработала!».

Например, я писал маленькую игру-«рогалик». У меня была такая идея: «Готов поспорить, что у меня получиться воспользоваться этим вашим алгоритмом Дейкстры для соединения комнат при генерировании карты, сначала инвертируя карту, а потом его запуская. Вероятно, мне удастся прокопать отличнейшие туннели между комнатами». То было благословенное время, когда я пытался справиться с этой задачей, и при этом не чувствовал, что C++ мне мешает. Мне тогда удалось решить эту задачу, попутно многому научившись. Потом у меня появилась такая мысль: «Интересно, получится мне взять пользовательский интерфейс, сделанный на FTXUI, и просто напрямую его отрендерить в окно визуализации SFML?». Как и следовало ожидать, у меня всё отлично получилось. И хотя это было не так уж и сложно, я по ходу дела много узнал о том, как в C++ обрабатывается юникод. Ни одна из этих задач лёгкой не была, но все их, в принципе, можно было решить, и я не могу напридумывать себе достаточно много «подводных камней», которыми C++ мог бы помешать мне сделать то, что я хочу. Это — то, что я называю «удовольствием».

Эта статья будет полезна новичкам в разработке или тем, кому нужно освежить знания перед собеседованиями. Как ни странно, но вопросы о том, как устроен HashMap, всё ещё встречаются среди интервьюеров.

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

Главная идея статьи - это показать как заставить ЭТО (kotlin & maven toolchain) работать вместе. Детального описания Maven toolchain здесь не будет, но есть краткое описание новых улучшений.

Решение нестандартное, попахивает немного хаком.

Вкратце о Maven toolchain.

Эта фича позволяет подключать нужную версию jdk (или других инструментов) автоматически. До апреля 2024 года maven toolchain плагин был довольно слабенький (по сравнению с gradle toolchains).

Но вот недавно (в апреле 2024) подъехала новая версия, которая поддерживает новые фишки, как в gradle.

...

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

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

Простая система частиц на SFML C++

Приветствую всех, кто интересуется графикой и программированием! Сегодня мы погрузимся в увлекательный мир создания систем частиц с помощью библиотеки SFML на C++. Эта тема открывает широкие возможности для визуализации различных эффектов, от простых искр и дыма до сложных взрывов и магических заклинаний в играх и других приложениях.

Системы частиц — это мощный инструмент для генерации динамических визуальных эффектов. Они основаны на идее создания множества мелких объектов (частиц), каждый из которых обладает собственными параметрами, такими как положение, скорость, цвет, размер и время жизни. Управляя этими параметрами, можно добиться самых разнообразных результатов.

Создадим отдельный класс для управления системой частиц.

Назовём его ParticleSystem. Ниже реализация кода данного класса.

Допустимые глобальные переменные и предполагаемая экономия памяти.

Вот уже 20 лет я преподаю программирование в университете Буэнос-Айреса. На курсе программной инженерии мы изучаем паттерны проектирования, и одна и та же «схема» повторяется раз за разом, вызывая почти де жа вю. Я убедился в этом на нескольких проектах и при обращении со свободным ПО, которым мне приходилось пользоваться:

Как «по волшебству» в коде возникает паттерн синглтон.

2023 год мы с колегой занимаемся монтажом отопления и вдруг на просторах интернета коллега замечает ролик про майнер, который охлаждается водой. Тут приходит одна незамысловатая мысль. Возможно ли будет интегрировать этот аппарат  в систему отопления дома и зимой получать бесплатное отопление. Как оказалось далее, ДА!)
Первые часы был небольшой шок, это вообще законно, греть дом еще и помимо этого получать прибыль с майнинга.

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

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

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

Кроме того, обслуживание или изменение проекта в будущем станет легким. Таким образом, вы в конечном итоге сэкономите деньги, время и ресурсы. Если вы хотите, чтобы проект развивался более плавно, то рекомендуется жить по этим законам.

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

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

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

У вас нет остеохондроза позвоночника и никогда не было.

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

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

В результате незначительной компрессии корешка может наблюдаться ирритация (раздражение) корешка, которое МОЖЕТ выражаться в ощущении боли. А может и не выражаться...

Ку! Меня зовут Евген, и я Автоматизатор тестирования на Python. В этой статье я расскажу как из вопроса ко мне «на сколько% у нас покрыта API автотестами?» Я выдал базу в виде регламента по автоматизации API.

Привет! Давайте знакомиться. Меня зовут Илья, я являюсь Lead QA и SDET. Сегодня я хотел бы поделиться своим опытом создания платформенных решений в области автоматизации тестирования, а также рассказать о работе с уже существующими платформами. В данной статье я собрал все плюсы и минусы, которые заметил за время своей работы, чтобы понять, насколько платформы полезны и когда их стоит внедрять.
Прежде чем углубляться в тему, важно договориться о терминах, чтобы мы говорили на одном языке. Давайте синхронизируемся по терминам!

Во времена пика интереса к NoSQL базам данных простоватые K-V хранилища были несколько обойдены вниманием - отчасти это понятно, вещь не очень "инновационная", можно даже сказать старинная. В то же время своя "ниша" у них находится до сих пор (не считая того что они используются в более сложных БД в качестве индексов).

В то же время в обычной SQL-ной базе проекта порой "не хватает" такого общего K-V хранилища для разнородных (семантически) записей. В своих проектах я такую обычно завожу. Среди коллег этот подход порой вызывает негатив :)

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

Много лет работаю со студентами московских вузов и представляю, как там преподают английский язык. Не жалуются (в силу очень специфических причин) студенты только трёх: МГЛУ, МГИМО и МФТИ.

В коридорах только и разговоров, что английский всем нужен. Но вот всё что-нибудь неладно: то «языки – не моё», то «не могу сдвинуться с мёртвой точки», то «языковой барьер»... Что за атмосфера мистики вокруг иностранных языков? Почему до сих пор нет признанной технологии качественного учебного процесса и подготовки преподавателей?

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

Советы и мнения по поводу изучения языков часто подкрепляются тем, что так сказал-де переводчик-синхронист или профессор иняза. Люди, хорошо владеющие языками (в том числе преподаватели), часто имеют несовместимые с реальностью представления о том, как их надо изучать. Это не парадокс: почти везде языки дают плохо, и реально выучивают их, как правило, довольно способные люди. Для них не нужно особого преподавательского мастерства или специальных приёмов – они воспримут любой способ подачи материала. Что-то сами додумают. А потом всю жизнь рассказывают, как замечательно «это работает».

У нас был spring и hibernate
Мы твёрдо знали, что OAuth2.0 это хорошо, а принцип "Api first" ещё лучше.
И нам дали ровно 48-ь часов чтобы создать работающую инфраструктуру с возможностями авторизации, отслеживания метрик, динамической маршрутизацией запросов и раздачей конфигураций сервисам "на лету". Кроме того от нас хотели получить "best practics" по работе с БД в коде и лёгкой поддержке ролевой модели.

Для решения задач автоматизации рутинных процессов для системных администраторов и DevOps чаще всего используются или bash-сценарии или python. Первое решение косвенно используется и в описании Dockerfile, поскольку сценарий исполняемых команд принципиально ничем не отличается от запуска скрипта в какой-либо shell, второй подход чаще ассоциируется с автоматизацией, связанных с взаимодействием с хранилищами данных. Но несправедливо было бы обойти стороной возможность создания исполняемых сценариев на языке Kotlin, которые могут стать полноценной заменой bash-сценариям.

В этой статье мы рассмотрим несколько примеров использования Kotlin Scripting (KTS) для автоматизации в распределенной системе, будем использовать долгоживущие скрипты с ожиданием заданий через RabbitMQ, а также поработаем с файловой системой, внешними сервисами, а также попробуем использовать KTS для сборки Docker-контейнеров.

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