А, вы про end-to-end. Для них мы перед прогоном всей пачки тестов чистим базу. И обеспечиваем независимость тестов, чтобы они могли бежать в параллель. В нашем случае достаточно, чтобы каждый тест бежал за свою бизнес-дату. И, конечно, есть отдельный тест, который проверяет, что бизнес-даты у тестов не пересекаются.
Вы имеете в виду как в Might and Magic? Который не Heroes. Я играл в седьмую, восьмую и девятую версии, и мне они в своё время очень нравились, несмотря на устаревшую даже на тот момент графику.
Пожалуй, стоит добавить, что есть библиотеки, в которых поддерживаются коллекции примитивных типов, например:
Trove (больше не поддерживается);
Eclipse collections;
FastUtil;
HPPC;
Koloboke;
Neo4j Primitive Collections;
Наверняка сейчас есть и какие-то ещё.
Правда, я помню случай, про который рассказывал Сергей Куксенко, когда сравнивал ConcurrentHashMap с Trove-мапой, и нашел случай, когда ConcurrentHashMap оказался быстрее, несмотря на то, что там лежали обьектные типы. Это было потому, что для определения того в какую корзину (bucket) положить элемент, в Trove использовался оператор % (остаток от деления), а в ConcurrentHashMap – наложение битовой маски, которое работает, когда длина массива – степень двойки. И в многопоточной среде это было важно, потому операция остаток от деления может исполняться одна на ядре, а наложений битовой маски может быть несколько в параллель. В интернете можно найти таблицы для разных процессоров, у каких операций какого параллелизма можно достичь.
Нет единственно верного разделения или выделения ответственностей для классов, функций, методов, модулей, пакетов и т. д.
Единственного верного нет, но есть предельный случай, до которого, например, доходят в книжке Growing Object-Oriented Software, Guided by Tests (GOOS).
Они разделяют классы/методы до упора, пока они делятся по зонам ответственности. Пользователя, и права пользователя они бы точно разделили.
Я не говорю, что это хорошо, просто слово "единственный" напомнило эту книжку.
с телефона еще странный глюк, когда длина строки кода становится шире экрана, то курсор становится высотой две строки, и буквы набираются/удаляются сразу на двух.
Чтобы это обойти, приходится разбивать строки на короткие, а прямо перед отправкой собирать обратно в длинные с помощью бэкспейса.
почти всегда лучше один скан по таблице + аналитическая функция.
Что-то вроде
select p.driver_id,
p.cnt,
p.avg_cnt
from (select q.driver_id,
q.cnt,
avg(q.cnt) over () as avg_cnt
from (select r.driver_id,
count(1) as cnt
from rides r
where city_id = 123 -- Berlin
and ride_date >= to_date('2021-11-01', 'YYYY-MM-DD')
and ride_date < to_date('2021-12-01', 'YYYY-MM-DD')
group by r.driver_id) q) p
where p.cnt > p.avg_cnt;
Насчет драйвера не знаю, но я чуть выше писал, что у меня тоже была проблема с перегорающими через полгода-год GX53. Сейчас я поставил лампы Osram, и пока ни одна не перегорела.
Я тоже регулярно меняю Икеевские (Ledare) лампы, когда они перегорают, или начинают мигать (обычные «груши» Е14 и Е27). Лампы X-Flash GX-53 гарантированно умирали через полгода-год работы. Я пользовался их бесплатной заменой, но потом мне это надоело, и я поставил вместо них Osram, и пока ни одна не перегорела.
У Икеевских ламп, по крайней мере у Ledare, очень приятный оттенок света. Пробовал покупать, например, Наносвет с CRI > 95, но они реально жёлтые, как будто кто-то надел желтый плафон на белую лампу. Через какое-то время привыкаешь, конечно, но с Икеей такого эффекта нет.
Объем тестирования остался прежним. Тесты переписали, конечно. У нас был такой монолит, в котором не было dependency injection, и поднять для тестов можно было только все целиком. А в микросервисах мы всё сделали по уму, да ещё в части сервисов перешли с мавена на грейдл, что тоже дало ускорение билдов с тестами.
Помодульно запускать было можно, наверное, просто никто такое разделение не сделал.
Для решения целиком у нас есть отдельные end to end тесты, но они и с монолитом были. Ускорили мы юнит- и интеграционные тесты путем выделения его частей в микросервисы.
CDC у нас буквально несколько тестов, в основном потому что очень мало вызовов через REST, почти всё идет через мессаджинг.
Присоединяюсь. Мы начали отрезать куски от монолита, когда в большой распределенной команде у этого монолита тесты проходили час. И после первых N итераций у нас стало несколько сервисов, у каждого время пробегания тестов не больше 10 минут, а чаще около пары минут.
Я думаю, что тут важно, чтобы рядом были люди на том же уровне развития в какой-то области. Вы сами пишете, что вы джуниор, и у сеньоров могут быть другие проблемы, с которыми они сталкиваются.
Это так работает во многих областях. Например, в качалку новичку веселее идти с другом-новичком. И наоборот, экспертам в какой-то области интересно обсудить какие-то сложные проблемы с другими экспертами. Так что желаю вам найти кого-то, кто проходит похожий с вами путь.
И да, присоединюсь к предыдущим комментаторам, что игры не зло. Я значительно лучше узнал английский, играя в Final Fantasy VII.
Кстати, не подскажете, вы используете MVCC в MS SQL, или по-старинке блокировки? Это на моей памяти единственная СУБД, которая умеет и так, и так, но родилась как блокировочная. А поддержку MVCC ей добавили, если не ошибаюсь, в 2005-м
да и пусть выполняется, раз в минуту – это и так аппроксимация выполнения всё время.
Если ваш бизнес перевести в эти термины, то получится что-то вроде:
пользователь набрал заказ и нажал «заказать» – в систему прилетел заказ, и те пункты, что в него вошли (тут придется сделать синхронно);
мы его сохраняем в базу безо всякой логики, пользователю пишем «в обработке», и при сохранении еще откладываем order_id в очередь, например, складского сервиса;
складской сервис забирает пачку order_id из очереди, списывает с остатков, генерирует команды «упаковать» по каждому складу, и тоже кладет эти команды в очередь; как только сформированы команды, меняем статус заказа на «набираем на складе»
работники склада (ну или роботы) упаковывают конкретные товары, и, как только упаковали, меняем статус конкретной order_line_id на «упаковано», и откладывают еще в одну очередь order_id;
еще какой-то сервис читает эту очередь, и проверяет по всем прилетевшим order_id, все ли товары по заказу набраны; когда набраны, меряем статус заказа на «собран», и опять кладем order_id еще в одну очередь;
Еще один сервис читает эту очередь, и человек (или робот) отдает заказы курьерам, меняем статус заказа на «отдан курьеру»
Как только заказ доставлен (когда курьер прокликал это у себя), мы опять же сохраняем это событие безо всякой логики в базу, и кладем order_id еще в одну очередь;
и еще один сервис читает эти order_id, делает какие-то завершающие шаги (например, отправка емейла), и переводит статус соответствующих заказов в «исполнен»
Я, конечно, несколько утрировал пример, но, думаю, идея понятна. Что мы сохраняем события без логики. Что можем, обрабатываем в фоне, и, где можем, батчами.
Оракл нам гарантирует выполнение джобы в единственном экземпляре. Если я правильно помню, в таком случае один запуск джобы будет сразу идти за другим.
А так задачу единственности джоба можно решить многими способами: например, можно сделать сервис, который будет брать блокировку в базе или в каком-нибудь кластере, можно поднять один под в кубернетесе, если он есть
А, вы про end-to-end. Для них мы перед прогоном всей пачки тестов чистим базу. И обеспечиваем независимость тестов, чтобы они могли бежать в параллель. В нашем случае достаточно, чтобы каждый тест бежал за свою бизнес-дату. И, конечно, есть отдельный тест, который проверяет, что бизнес-даты у тестов не пересекаются.
мы с базой только так и тестируем. Приводим нужные таблицы в изначальное состояние (fixture), делаем, что нужно, и проверяем конечное состояние.
Мы пишем на Джаве, поэтому обычно используем для наката датасета, и для проверки (assert'а), библиотеку dbUnit.
Вы имеете в виду как в Might and Magic? Который не Heroes. Я играл в седьмую, восьмую и девятую версии, и мне они в своё время очень нравились, несмотря на устаревшую даже на тот момент графику.
Пожалуй, стоит добавить, что есть библиотеки, в которых поддерживаются коллекции примитивных типов, например:
Trove (больше не поддерживается);
Eclipse collections;
FastUtil;
HPPC;
Koloboke;
Neo4j Primitive Collections;
Наверняка сейчас есть и какие-то ещё.
Правда, я помню случай, про который рассказывал Сергей Куксенко, когда сравнивал ConcurrentHashMap с Trove-мапой, и нашел случай, когда ConcurrentHashMap оказался быстрее, несмотря на то, что там лежали обьектные типы. Это было потому, что для определения того в какую корзину (bucket) положить элемент, в Trove использовался оператор % (остаток от деления), а в ConcurrentHashMap – наложение битовой маски, которое работает, когда длина массива – степень двойки. И в многопоточной среде это было важно, потому операция остаток от деления может исполняться одна на ядре, а наложений битовой маски может быть несколько в параллель. В интернете можно найти таблицы для разных процессоров, у каких операций какого параллелизма можно достичь.
Единственного верного нет, но есть предельный случай, до которого, например, доходят в книжке Growing Object-Oriented Software, Guided by Tests (GOOS).
Они разделяют классы/методы до упора, пока они делятся по зонам ответственности. Пользователя, и права пользователя они бы точно разделили.
Я не говорю, что это хорошо, просто слово "единственный" напомнило эту книжку.
с телефона еще странный глюк, когда длина строки кода становится шире экрана, то курсор становится высотой две строки, и буквы набираются/удаляются сразу на двух.
Чтобы это обойти, приходится разбивать строки на короткие, а прямо перед отправкой собирать обратно в длинные с помощью бэкспейса.
Я и не критикую, просто хотел дополнить ваш ответ, исходя из своего опыта
почти всегда лучше один скан по таблице + аналитическая функция.
Что-то вроде
Мы используем Flyway с ораклом, всё работает, как надо.
у вас в выводе перевод неправильный.
В оригинале
inherent – это как раз «врождённый», а не «приобретённый»
А почему Spark, а а не sqoop? Sqoop же как раз сделан для миграции между реляционными базами и Хадупом, и обратно.
Насчет драйвера не знаю, но я чуть выше писал, что у меня тоже была проблема с перегорающими через полгода-год GX53. Сейчас я поставил лампы Osram, и пока ни одна не перегорела.
Я тоже регулярно меняю Икеевские (Ledare) лампы, когда они перегорают, или начинают мигать (обычные «груши» Е14 и Е27). Лампы X-Flash GX-53 гарантированно умирали через полгода-год работы. Я пользовался их бесплатной заменой, но потом мне это надоело, и я поставил вместо них Osram, и пока ни одна не перегорела.
У Икеевских ламп, по крайней мере у Ledare, очень приятный оттенок света. Пробовал покупать, например, Наносвет с CRI > 95, но они реально жёлтые, как будто кто-то надел желтый плафон на белую лампу. Через какое-то время привыкаешь, конечно, но с Икеей такого эффекта нет.
Объем тестирования остался прежним. Тесты переписали, конечно. У нас был такой монолит, в котором не было dependency injection, и поднять для тестов можно было только все целиком. А в микросервисах мы всё сделали по уму, да ещё в части сервисов перешли с мавена на грейдл, что тоже дало ускорение билдов с тестами.
Помодульно запускать было можно, наверное, просто никто такое разделение не сделал.
Для решения целиком у нас есть отдельные end to end тесты, но они и с монолитом были. Ускорили мы юнит- и интеграционные тесты путем выделения его частей в микросервисы.
CDC у нас буквально несколько тестов, в основном потому что очень мало вызовов через REST, почти всё идет через мессаджинг.
Надеюсь, ответил
Присоединяюсь. Мы начали отрезать куски от монолита, когда в большой распределенной команде у этого монолита тесты проходили час. И после первых N итераций у нас стало несколько сервисов, у каждого время пробегания тестов не больше 10 минут, а чаще около пары минут.
Я думаю, что тут важно, чтобы рядом были люди на том же уровне развития в какой-то области. Вы сами пишете, что вы джуниор, и у сеньоров могут быть другие проблемы, с которыми они сталкиваются.
Это так работает во многих областях. Например, в качалку новичку веселее идти с другом-новичком. И наоборот, экспертам в какой-то области интересно обсудить какие-то сложные проблемы с другими экспертами. Так что желаю вам найти кого-то, кто проходит похожий с вами путь.
И да, присоединюсь к предыдущим комментаторам, что игры не зло. Я значительно лучше узнал английский, играя в Final Fantasy VII.
Кстати, не подскажете, вы используете MVCC в MS SQL, или по-старинке блокировки? Это на моей памяти единственная СУБД, которая умеет и так, и так, но родилась как блокировочная. А поддержку MVCC ей добавили, если не ошибаюсь, в 2005-м
Пожалуйста :-)
Всегда рад хорошей дискуссии
да и пусть выполняется, раз в минуту – это и так аппроксимация выполнения всё время.
Если ваш бизнес перевести в эти термины, то получится что-то вроде:
пользователь набрал заказ и нажал «заказать» – в систему прилетел заказ, и те пункты, что в него вошли (тут придется сделать синхронно);
мы его сохраняем в базу безо всякой логики, пользователю пишем «в обработке», и при сохранении еще откладываем order_id в очередь, например, складского сервиса;
складской сервис забирает пачку order_id из очереди, списывает с остатков, генерирует команды «упаковать» по каждому складу, и тоже кладет эти команды в очередь; как только сформированы команды, меняем статус заказа на «набираем на складе»
работники склада (ну или роботы) упаковывают конкретные товары, и, как только упаковали, меняем статус конкретной order_line_id на «упаковано», и откладывают еще в одну очередь order_id;
еще какой-то сервис читает эту очередь, и проверяет по всем прилетевшим order_id, все ли товары по заказу набраны; когда набраны, меряем статус заказа на «собран», и опять кладем order_id еще в одну очередь;
Еще один сервис читает эту очередь, и человек (или робот) отдает заказы курьерам, меняем статус заказа на «отдан курьеру»
Как только заказ доставлен (когда курьер прокликал это у себя), мы опять же сохраняем это событие безо всякой логики в базу, и кладем order_id еще в одну очередь;
и еще один сервис читает эти order_id, делает какие-то завершающие шаги (например, отправка емейла), и переводит статус соответствующих заказов в «исполнен»
Я, конечно, несколько утрировал пример, но, думаю, идея понятна. Что мы сохраняем события без логики. Что можем, обрабатываем в фоне, и, где можем, батчами.
Оракл нам гарантирует выполнение джобы в единственном экземпляре. Если я правильно помню, в таком случае один запуск джобы будет сразу идти за другим.
А так задачу единственности джоба можно решить многими способами: например, можно сделать сервис, который будет брать блокировку в базе или в каком-нибудь кластере, можно поднять один под в кубернетесе, если он есть