Кстати, а где-нибудь еще кроме Elite полет реализован, как вращение корабля вокруг своей оси, плюс задирание/опускание носа? Везде и всюду космос на колесах, буквально езда вперед-назад и влево-вправо. В Элите прямо чувствовалось отсутствие верха и низа, никакой даже условной плоскости в которой происходит движение. Ничего подобного больше не встречал.
Просто думаю, почему ж у меня в памяти отложилось, что в вебсокете одновременно может быть только одно сообщение? Очевидно что-то же заставило меня так думать…
Насчет сотен не скажу, но сразу несколько вебсокет-соединений могут иметь смысл — одновременно в вебсокете может находиться только одно сообщение, либо «туда», либо «оттуда», поэтому при большой интенсивности может иметь смысл открыть два соединения, одно, например, для интенсивного получения данных, а второе для относительно редкой отправки своих реакций на сервер. А может еще и третье — для пушей сервера других событий. Больше ничего в голову не приходит.
Говоря о вознаграждении, можно отметить, что на уровне компании существует прозрачная система премирования, которая привязана к выполнению личных целей сотрудников.
Если накат liquibase сделан отдельным джарником, который нужно отдельно запускать, то могут быть проблемы, но если он классически часть проекта, то накатится сам точно так же, как на БД развернутую обычным методом.
Это уже зависит от того, что используется в вашем проекте. Если это java+spring boot, в котором вы используете spring-data, то вы можете просто инжектнуть себе в тест бин соответствующего репозитория, и через него заполнить БД. По факту-то тест работает с реальной БД в контейнере, и работать с ней можно ровно так же, как с обычной базой. Testcontainers же это не про заполнение БД, да и вообще не про БД, а про поднять контейнер, а потом удалить его, когда нужда в нем исчезнет. А уж что в этом контейнере будет не суть важно, может кафка, а может и rabbitmq.
При использовании аннотации TestContainers будет создаваться новый docker-container с базой для каждого тестового класса, зачем нам это? Не разумнее ли запустить одну базу для всех тестов (например из общего тестового класса осуществить BeforeAll container.start())?
Рано или поздно — и скорее рано — продукты жизнедеятельности одних тестовых классов начнут мешать другим тестовым классам. Добавим сюда произвольный порядок выполнения тестов и то, что некоторые тесты сознательно могут тестировать некое деструктивное поведение, чреватое возникновением «мусора», и готов вывод — тестовая среда должна быть изолированной. На уровне каждого конкретного теста такая изоляция не эффективна и затратна, значит на уровне тестового класса — что и имеем.
Почему не наполнять тестовую БД данными из какого-нибудь sql-скрипта, а не осуществлять BeforeEach repo.save()? Ведь это во-первых, лишнее взаимодействие с логикой, которое никак не проверяется, я уже молчу что в каждом классе прописать надо не забыть этот сетап..
Посмотрим с точки зрения человека, который вынужден чинить покрасневший тест, который написан не им. Он смотрит в тест, и видит конкретный сетап над которым производятся тестовые действия. Если этот сетап отдельный для каждого теста, то вообще хорошо — с пределах теста ясно что делается, над какими данными делается, и какой ожидается результат. А вот «общее заполнение чем-то сторонним» — это самый большой кошмар, какой только может быть. Один тест починил — и сломал еще пяток, потому что все они не явно связаны через данные.
У вас и правда искревленное представление об айти. Мне, как айтишнику, важно чем я, как айтишник, буду заниматься устроившись на работу в один из брендов — и банк тут мало чем отличается от любого другого места, где пишут код. А какая конкретно вам польза от теоретически написанного там софта в общем-то до фонаря, рейтинг не про это.
Полная история создания игры Elite (1984). Часть 2
Полная история создания игры Elite (1984). Часть 2
Полная история создания игры Elite (1984). Часть 2
Пара HTTP-заголовков, о которых, похоже, не знают разработчики
Убьет ли HTTP/2 лонг поллинг и вебсокеты?
Убьет ли HTTP/2 лонг поллинг и вебсокеты?
Убьет ли HTTP/2 лонг поллинг и вебсокеты?
Собеседование наоборот: РТЛабс, МойОфис, Лига Цифровой Экономики, Контур, НЛМК, Nexign / часть 2
Засмеялся.
Обзор топ-5 полезных утилит для Docker
Как мотивировать команду нефинансовыми методами, поддержать сотрудников в трудные времена и завоевать их доверие
Читайте в нашей новой книге «НИКАК».
День шутера. Краткая ретроспектива
Testcontainers: тестирование с реальными зависимостями
Testcontainers: тестирование с реальными зависимостями
Битва брокеров сообщений: RabbitMQ, Kafka, AWS SNS/SQS
Testcontainers: тестирование с реальными зависимостями
Рано или поздно — и скорее рано — продукты жизнедеятельности одних тестовых классов начнут мешать другим тестовым классам. Добавим сюда произвольный порядок выполнения тестов и то, что некоторые тесты сознательно могут тестировать некое деструктивное поведение, чреватое возникновением «мусора», и готов вывод — тестовая среда должна быть изолированной. На уровне каждого конкретного теста такая изоляция не эффективна и затратна, значит на уровне тестового класса — что и имеем.
Посмотрим с точки зрения человека, который вынужден чинить покрасневший тест, который написан не им. Он смотрит в тест, и видит конкретный сетап над которым производятся тестовые действия. Если этот сетап отдельный для каждого теста, то вообще хорошо — с пределах теста ясно что делается, над какими данными делается, и какой ожидается результат. А вот «общее заполнение чем-то сторонним» — это самый большой кошмар, какой только может быть. Один тест починил — и сломал еще пяток, потому что все они не явно связаны через данные.
Битва брокеров сообщений: RabbitMQ, Kafka, AWS SNS/SQS
DLQ есть и в кролике.
Что будет, если от разработчиков не отстать: умирающая команда
Рейтинг IT-брендов работодателей 2022: новый ландшафт рынка
Рейтинг IT-брендов работодателей 2022: новый ландшафт рынка
История успеха ZX Spectrum и культовые игры для него