Как известно, Docker умеет создавать виртуальные сети для безопасного и удобного сетевого взаимодействия внутри контейнеров. В этой статье мы рассмотрим, как именно он это делает на примере базовых манипуляций с сетью в рамках одного хоста с операционной системой Linux.

Начиная с Java 19 нам доступны виртуальные потоки, которые отличаются от обычных, тем что умеют освобождать поток операционной системы во время блокирующих I/O операций. Для этого на уровне JVM был реализован механизм сохранения в хипе и восстановления из хипа стека вызова. Проще говоря, были реализованы полноценные корутины на уровне JVM.

И это небольшая революция, на которую мало кто обратил внимание. Само API для таких нативных корутин непубличное, доступно через класс jdk.internal.vm.Continuation, в котором есть методы yield() и run() для сохранения и восстановления стека вызова соответственно. Но получить доступ до него несложно, нужно лишь добавить пару аргументов в строку запуска JVM (либо воспользоваться инструментом, который позволяет обходить ограничения JPMS).

Поэтому представляю свою небольшую библиотеку для доступа к нативным корутинам на Java: https://github.com/Anamorphosee/loomoroutines.

X11 это тот механизм на чем работает весь графический интерфейс Unix подобных ОС.

Но мало кто знает как он работает на самом деле. Потому что с годами он оброс слоями и слоями библиотек, которые стремятся скрыть саму сущность протокола.

А протокол в своей сути прекрасен. Он лаконичен и почти совершенен.

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

А все книги и статьи по использованию X11 описывают это через библиотеки прокладки типа XLib и XCB, и даже, что хуже, GTK или Qt.

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

Как бы то ни было, если кому-то интересно как все работает на самом деле, пожалуйста под кат.

Когда я писал свой первый gradle-плагин, я проверял его работоспособность следующим образом:

1. Опубликовал версию n в plugins.gradle.org
2. Проверил опубликованный плагин вручную на тестовом проекте
3. Нашел ошибку/доработал, увеличил версию n=n+1, затем снова пункт 1

Такой вот PDD (Publish Driven Development). Сегодня поговорим о том, как писать эффективные тесты на собственные gradle плагины.

Привет! Меня зовут Александр Поляков, я руководитель команды i18n-разработки в Фантехе Яндекса. Мы помогаем сервисам компании выходить на международные рынки, а именно решаем задачи, связанные с интернационализацией и локализацией интерфейсов.

В этом посте расскажу:

• какие именно решения для интернационализации фронтенда мы разрабатываем;

• какие есть правила форматирования данных для разных локалей и как определять эти локали;

• о проблемах переводов в современных реалиях.

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

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

Хочу поделиться интересным приложением, которое значительно упрощает процесс веб-тестирования.

В роли QA-инженера, активно тестирующего веб, я часто сталкиваюсь с необходимостью изменения запросов/ответов API, статус кода ответа и других параметров. Иногда возникают ситуации, когда фронт готов, но доработки с бэка еще предстоит дождаться.

Тут на помощь приходит Requestly! 

Недавно попался на глаза примерно такой кусок запроса, и тут прекрасно примерно все:

• множество чтений из CTE (хоть и единственной записи, но все же);

• извлечение по каждому ключу текста с раскастовкой в jsonb;

• извлечение каждого отдельного json-ключа в каждое отдельное одноименное поле;

• "ручное" преобразование текстового представления массива в json в текстовое представление PostgreSQL.

А как - правильно?

Hola, Amigos! Меня зовут Ярослав Цемко, я Flutter-разработчик в компании заказной разработки Amiga. Сейчас я расскажу об очень крутом плагине, который помог нам решить проблемы, связанные с адаптацией контента под разные дисплеи в одном из наших проектов.

Привет %username%, эта статья про то, как поместить Rust приложение в Docker и получить образ размером с бинарный файл (6 Мб). А также про причины, которые привели к переходу с NodeJS на Rust. Отдельная пара слов о проблемах вначале, переходе на Go, и том, как команда Rust устранила эти проблемы за пол года.

TL;DR Dockerfile в конце статьи и ссылка на example репозиторий

Еще одна статья о том, как можно применять Spring Cloud Config Server при выборе Git репозитория как хранилища конфигураций приложений в облаке и не только в облаке.

Ранее я рассказывал о том, как запустить PostgreSQL в Docker. Тогда речь шла об использовании «ванильных» образов Postgres и поднятии одного хоста. В большинстве случаев этого достаточно как для тестов, так и для экспериментов, но нужно понимать, что в промышленной эксплуатации чаще всего используются высокодоступные (отказоустойчивые, кластеризованные) конфигурации PostgreSQL.

Сегодня я покажу, как запустить уже целый кластер PostgreSQL в Docker, а также в тестах через Testcontainers, и как вручную инициировать смену мастер-хоста.

Приветствую. Меня зовут Устюжанин Игорь. Мне довелось поработать в разных ролях при разработке ИТ-продуктов - от инженера-программиста до руководителя продукта. Этот опыт я получил в компании СКБ Контур, куда пришел разработчиком аж в 1999 году, будучи студентом 4-го курса.

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

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

Shopify — это один из крупнейших конкурентов Amazon в сфере онлайн‑ритейла. В компании работает около 10 000 человек. Shopify, в отличие от Amazon — централизованной торговой площадки, предлагает коммерческим структурам платформу для создания их собственных онлайн‑магазинов и веб‑сайтов. Shopify — это одна из крупнейших технологических организаций, в которой применяется полностью удалённый режим работы. Она перешла к такой модели в начале 2020 года. Это — одна из последних компаний такого размера, которая не переводит сотрудников обратно в офисы. По крайней мере — пока не переводит.

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

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

Привет, сегодня будет объёмная и обстоятельная статья о низкоуровневом профилировании и дигностике производительности. Многократно в комментариях к докладам и статьям пользователи высказывали пожелание увидеть не просто перечисление шаблонов "как нужно" и "как не нужно", а целостную историю. Поэтому вот вам статья про конкретный кейс и его историю :). Не удивляйтесь, что начнём мы с JPA, хотя казалось бы где оно и где ассемблер. По ходу дела вы всё поймёте.

Меня зовут Саша Шульгин, я руковожу агентством Purrweb. За последние пару лет наша команда сделала 5 проектов с арабским интерфейсом. Это, конечно, не 50, но какой-то опыт уже есть. Пока делали проекты, собрали базу знаний. Я решил, что такое нельзя держать только у нас в Notion, поэтому делюсь с вами, как адаптировать приложения для Ближнего Востока.

Всем привет!

В этой статье я бы хотел поделиться инструментом, который мы в Okko используем для UI-автотестов для клиентских приложений платформы Android. 

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

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

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

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

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