а я бы проверил математику - 64 параллельных теста по 1 секунде, всего 800 тестов - это не 13 минут, а 12 секунд. Мы же про параллельность говорим? 64 много? Может, тесты тяжелые слишком? Может, поставим 32 параллельность? Уже 24 секунды. Но не 13 минут
смотрим что у вас - форкаем базы на рандомный набор тестов. Отлови-ка, что там на что влияет. смотрим на тестконтейнерс - управление разделяемыми ресурсами. Вы можете использовать совместно один докер контейнер с базой - это задокументировано. Уверены, что не нужет отдельный контейнер - успользуйте общий. Не уверены - сдалайте столько наборов тестов со своими докерами, сколько нужно. Хотите один докер на тест - пожалуйста, хотите один на всех - берите, хотите пять на разные взаимоблокирующие наборы - вперед, хотите контурентные с одной базой - хватайте ResourceLock. Есть все
это очень оптимистично, про "узнают". Практика показывает, что простые решения долго приходят, даже если задокументировано. Если человек ушел - чаще всего работу объявляют магией и вне зоны доступа
у вас задача быстро выкатить решение - вы его и пилите. Это не значит, что оно правильное. Ваш подход пока работает, но нарушает принцип изоляции тестов, что может привести к недетерминированному поведению тестов, за что вас проклянут потомки. Работает - ну и ладно, но если строить решение не оглядываясь на вечер пятницы, то это неверный подход. Но мы все понимаем, что "правильно" оторвано от реальности - если устраивает, то и хорошо. Делать 800 копий базы - это канонично. База не должна быть большой для тестов, если это не специализированные тесты "проверим как там прод". Докеры легкие - контейнеры докера в принципе отличаются только данными, запихиваемыми в базу, так как уровни докера (не знаю, как по-русски) это разделяемая память. И делать 800 в параллель не надо - жюнит настраивается, сколько тестов гнать в параллель. Разделяемые ресурсы с локами - это не базы. Это если у вас недоинтеграционные тесты, например, часть из которых завязана на какой-нибудь внешний (необязательно) UserManagementService - вот эти тесты помечаем как нуждающиеся в локе и они не будут выполняться конкурентно (то есть будут только с теми, что не помечены)
testcontainers как раз для изоляции тестов и придумали - все другие сценарии только если по каким-то причинам не подходит этот. Параллельно тесты запускаются стандартными средствами JUnit 5 со свойством junit.jupiter.execution.parallel.mode.classes.default = concurrent
а для доступа к неразделяемым ресурсам используется аннотация ResourceLock на тестах.
А у нас кнопка была в почтовом клиенте "че та мне подозрительно". И вполне неплохо работала, всем благодарности объявляли. Ни разу, причем, настоящих фишеров не было - всегда учебные рассылки, которые тупо отфильтровываются по отправителю. На корп почту никогда ничего не приходило извне,так что если отправитель не в том же домене - это безопасники премию зарабатывают. Рука руку моет...
Вот у нас в Cloudbreak в опенсорсе,так что могу чуток сравнить,не выходя из nda. Тоже выделяются ресурсы от облачного провайдера (все главные) и ставится ПО, процесс совсем не быстрый и с кучей "возможны варианты“ и ещё чаще,увы, "что то пошло не туда". И, интересное дело, тоже решили использовать конечные автоматы. Так как все на джаве и спринге, то был "допилен" spring state machine (Cloudbreak flow) под это дело, состояния в постгресе, в общем - вот где теория программного инженерного подхода встретилась с жизнью, наконец-то. Откаты бизнес транзакций через состояния, персистентность машин... Однако... Это написали давно и нынешнее поколение слегка боится этого кода. Мягко говоря,никого не знаю,кто не пытается избежать этих кусков. Описания FSM даже в специальных фреймворках и dsl слабо читаемы. Из того,что я видел - далее чем прямолинейный код никто не разумеет - местных теории конечных автоматов не учат. Как ни хороша задумка - она привела к слабо поддерживаемом у коду. Судя по всему люди,это писавшие, давно уволились, ибо "улучшили" spring state machine " V1 и апдейтить некому. Так что с переходом на k8s вопроса в переиспользовании не было - будем делать по человечески,а не по академически
Для смарт-карт была вообще отдельная java card. А java-me была слишком ограничена, от собственно жавы она далека, как и жаваскрипт. В общем-то, хотели сделать унификацию, а получили еще один стандарт, который почти никто поддерживать не захотел. Уже в начале десятых годов полноценные java машины работали на платежных терминалах, одной из распространенных была ibm J9. Проблем с перифирией не было практически никаких - жава хорошо работала с библиотеками на С, которые за бутерброд в обед могли написать прожженные программисты прошлых поколений или студенты за ночь. Главное было не давать им работать творчески с памятью... Память терялась на скучной бизнес-логике куда и влезала жава, а драйвера были довольно стабильные.
Терминалы YOMANI, сейчас они YOMANI VeriFone, а тогда делали их, вроде, датчане. Конкретную модель не помню, у нас были первые модели без contactless, а модели с contactless прикручивали уже после релиза на рынок. До этого была у них (производителей) линейка Xenta, где был свой форк Java 1.3, если помню правильно - там SDK был поуродливее, но и было это лет на пять-семь раньше. Их и сейчас можно встретить иногда (широкое распространиение получили в Нидерландах) - тоже кубик, только более икея-дизайн и число-цифровой дисплей.
больше десяти лет назад писал софт (с нуля и до прода) для терминалов в финке (белые квадратики). Писалось все на чистой Java 5 с вменяемым SDK. И стандартная жавовая многопоточность была, и ввод-вывод с файлами и сетью, только GUI был не стандартной библиотеки ну и всякие подписи транзакций с взаимодействием с contactless и проверкой чипов в SDK вендора. Писали в IntelliJ Idea и с junit тестами на локальных машинах. Вроде даже дебажить можно было на терминале, но не уверен. Рядом сидели С-шники с VeriFone и плакали. Мы выкатывали фичи с такой скоростью, что эти терминалы поставили везде и старые выкинули, оставив только, наверное, в метро да в полиции. Ну, пару лет спустя верифон компанию и купил - меня там уже не было... Так что все эти ужасы разработки инжеников и верифонов - мазохизм и жадность владельцев бизнеса.
алгоритм работает и на неотсортированном массиве. К сожалению, выбор данных для иллюстрации неудачный — глаз сразу подмечает сортировку, хотя она не влияет на результат работы.
На самом деле при проходе ищется преобладающий элемент в некоем (возможно, уменьшающемся) подмассиве данных, отбрасывая подмассивы без преобладающего элемента, а потом проверяется, что этот элемент преобладает во всем массиве. За счет того, что проверяется N/2+1 сбить в 0 этот элемент не получится во всех случаях, все равно он вылезет в конце первого прохода, как его не прячь за другими (второстепенными) элементами. Второй проход для проверки ложноположительного результата.
"Тревожный чемоданчик" — это рюкзак 25-30 литров, с которым нужно мчаться под сиренами в бомбоубежище или на места сбора для эвакуации с надеждой вернуться пораньше или вообще когда-то. Все вещи, что больше этого — будут отбирать и выкидывать там же угрюмые люди, думающие о спасении гражданских. Остальные будут или счастливо/случайно выжившие в своем подвале или отстреляны или зарезаны или упрутся в колючку-забор или с голоду-холоду помрут в лесу / пыточном подвале.
мультитул гораздо тяжелее и не так удобно пользоваться при кормежке. Мультитул попадает под категорию "обойдусь". Впрочем, нож тоже редко нужен. В теории нож — вещь первой необходимости. На практике, что есть критерий истины — нет.
Олимпиадник быстрее найдет очень высокооплачиваемую работу и будет набивать шишки там, получая огромные деньги и работая над интересными проектами.
Не-олимпиадник будет тоже набивать шишки, но за гораздо меньшие деньги и надеяться, что когда-то доберется до тех зарплат и проектов. Ну или разгребать за олимпиадником.
Описана работа обычного ThreadPool - FJP решает проблемы, которые при обычном подходе возникают. Это не описано вообще. Принципиальное отличие в подходе WorkStealing, который часто подразумевает рекурсивные алгоритмы. WorkStealing - это не процесс вытаскивания задачи из общего пула, а процесс вытаскивания задачи из очереди другого обработчика, если (и только если) своя очередь пуста. Рекурсия здесь вот при чем - каждый обработчик разбивает задачу на подзадачи и помещает эти задачи в очередь, из очереди они попадают в отдельные очереди каждого обработчика (можно сделать без submission queue но не нужно). Это важно - в отличие от простой реализации пула потоков, очередь исполнения не одна, а отдельно для каждого потока. Это позволяет минимизировать синхронизацию обработчиков и именно ради этого все затевается. FJP спроектирован для мелких, нагружающих именно процессор задач, поэтому минимизация расходов на синхронизацию так важна и поэтому он по дефолту инициализируется количеством потоков равных числу вычислительных ядер.
Проблемы со спиной. Похожее начало, но выход найден. Махнули все, в первую очередь — врачи. Качалку пробовал (малые веса) — не могу, нудятина. Бег с другом за компанию — быстро нафиг. Про всякие зарядки — даже без намека на возможность сделать хотя бы раз полностью. Все решило одно — физ активность, которая увлекла. Начал с тремя годами айкидо, сейчас 7 лет бразильского Джиу джитсу. Кстати, в детстве пытался в кунг-фу -не смог, нудятина показалась. Параллельно с невестой хожу в бассейн. Нудятина. Через силу. Бадминтон — не так плохо, но без интереса. Сейчас зал закрыли — бегаю полчаса. Один или не один. В наушниках или нет. Нудятина, не могу.
Так что единственное, что работает -что понравится. Единоборства -отличные нескучный способ для многих, но не для абсолютно всех. И не всякие. Кому-то зайдет тайский бокс, кому борьба, кому капуейра какая-то.
а я бы проверил математику - 64 параллельных теста по 1 секунде, всего 800 тестов - это не 13 минут, а 12 секунд. Мы же про параллельность говорим? 64 много? Может, тесты тяжелые слишком? Может, поставим 32 параллельность? Уже 24 секунды. Но не 13 минут
смотрим что у вас - форкаем базы на рандомный набор тестов. Отлови-ка, что там на что влияет.
смотрим на тестконтейнерс - управление разделяемыми ресурсами. Вы можете использовать совместно один докер контейнер с базой - это задокументировано. Уверены, что не нужет отдельный контейнер - успользуйте общий. Не уверены - сдалайте столько наборов тестов со своими докерами, сколько нужно.
Хотите один докер на тест - пожалуйста, хотите один на всех - берите, хотите пять на разные взаимоблокирующие наборы - вперед, хотите контурентные с одной базой - хватайте ResourceLock. Есть все
это очень оптимистично, про "узнают". Практика показывает, что простые решения долго приходят, даже если задокументировано. Если человек ушел - чаще всего работу объявляют магией и вне зоны доступа
у вас задача быстро выкатить решение - вы его и пилите. Это не значит, что оно правильное. Ваш подход пока работает, но нарушает принцип изоляции тестов, что может привести к недетерминированному поведению тестов, за что вас проклянут потомки. Работает - ну и ладно, но если строить решение не оглядываясь на вечер пятницы, то это неверный подход. Но мы все понимаем, что "правильно" оторвано от реальности - если устраивает, то и хорошо.
Делать 800 копий базы - это канонично. База не должна быть большой для тестов, если это не специализированные тесты "проверим как там прод". Докеры легкие - контейнеры докера в принципе отличаются только данными, запихиваемыми в базу, так как уровни докера (не знаю, как по-русски) это разделяемая память.
И делать 800 в параллель не надо - жюнит настраивается, сколько тестов гнать в параллель.
Разделяемые ресурсы с локами - это не базы. Это если у вас недоинтеграционные тесты, например, часть из которых завязана на какой-нибудь внешний (необязательно) UserManagementService - вот эти тесты помечаем как нуждающиеся в локе и они не будут выполняться конкурентно (то есть будут только с теми, что не помечены)
testcontainers как раз для изоляции тестов и придумали - все другие сценарии только если по каким-то причинам не подходит этот.
Параллельно тесты запускаются стандартными средствами JUnit 5 со свойством
junit.jupiter.execution.parallel.mode.classes.default = concurrent
а для доступа к неразделяемым ресурсам используется аннотация ResourceLock на тестах.
А у нас кнопка была в почтовом клиенте "че та мне подозрительно". И вполне неплохо работала, всем благодарности объявляли. Ни разу, причем, настоящих фишеров не было - всегда учебные рассылки, которые тупо отфильтровываются по отправителю. На корп почту никогда ничего не приходило извне,так что если отправитель не в том же домене - это безопасники премию зарабатывают. Рука руку моет...
Вот у нас в Cloudbreak в опенсорсе,так что могу чуток сравнить,не выходя из nda. Тоже выделяются ресурсы от облачного провайдера (все главные) и ставится ПО, процесс совсем не быстрый и с кучей "возможны варианты“ и ещё чаще,увы, "что то пошло не туда". И, интересное дело, тоже решили использовать конечные автоматы. Так как все на джаве и спринге, то был "допилен" spring state machine (Cloudbreak flow) под это дело, состояния в постгресе, в общем - вот где теория программного инженерного подхода встретилась с жизнью, наконец-то. Откаты бизнес транзакций через состояния, персистентность машин... Однако... Это написали давно и нынешнее поколение слегка боится этого кода. Мягко говоря,никого не знаю,кто не пытается избежать этих кусков. Описания FSM даже в специальных фреймворках и dsl слабо читаемы. Из того,что я видел - далее чем прямолинейный код никто не разумеет - местных теории конечных автоматов не учат. Как ни хороша задумка - она привела к слабо поддерживаемом у коду. Судя по всему люди,это писавшие, давно уволились, ибо "улучшили" spring state machine " V1 и апдейтить некому. Так что с переходом на k8s вопроса в переиспользовании не было - будем делать по человечески,а не по академически
Для смарт-карт была вообще отдельная java card. А java-me была слишком ограничена, от собственно жавы она далека, как и жаваскрипт. В общем-то, хотели сделать унификацию, а получили еще один стандарт, который почти никто поддерживать не захотел. Уже в начале десятых годов полноценные java машины работали на платежных терминалах, одной из распространенных была ibm J9. Проблем с перифирией не было практически никаких - жава хорошо работала с библиотеками на С, которые за бутерброд в обед могли написать прожженные программисты прошлых поколений или студенты за ночь. Главное было не давать им работать творчески с памятью... Память терялась на скучной бизнес-логике куда и влезала жава, а драйвера были довольно стабильные.
ага, оно.
Терминалы YOMANI, сейчас они YOMANI VeriFone, а тогда делали их, вроде, датчане. Конкретную модель не помню, у нас были первые модели без contactless, а модели с contactless прикручивали уже после релиза на рынок. До этого была у них (производителей) линейка Xenta, где был свой форк Java 1.3, если помню правильно - там SDK был поуродливее, но и было это лет на пять-семь раньше. Их и сейчас можно встретить иногда (широкое распространиение получили в Нидерландах) - тоже кубик, только более икея-дизайн и число-цифровой дисплей.
больше десяти лет назад писал софт (с нуля и до прода) для терминалов в финке (белые квадратики). Писалось все на чистой Java 5 с вменяемым SDK. И стандартная жавовая многопоточность была, и ввод-вывод с файлами и сетью, только GUI был не стандартной библиотеки ну и всякие подписи транзакций с взаимодействием с contactless и проверкой чипов в SDK вендора. Писали в IntelliJ Idea и с junit тестами на локальных машинах. Вроде даже дебажить можно было на терминале, но не уверен. Рядом сидели С-шники с VeriFone и плакали. Мы выкатывали фичи с такой скоростью, что эти терминалы поставили везде и старые выкинули, оставив только, наверное, в метро да в полиции. Ну, пару лет спустя верифон компанию и купил - меня там уже не было... Так что все эти ужасы разработки инжеников и верифонов - мазохизм и жадность владельцев бизнеса.
алгоритм работает и на неотсортированном массиве. К сожалению, выбор данных для иллюстрации неудачный — глаз сразу подмечает сортировку, хотя она не влияет на результат работы.
На самом деле при проходе ищется преобладающий элемент в некоем (возможно, уменьшающемся) подмассиве данных, отбрасывая подмассивы без преобладающего элемента, а потом проверяется, что этот элемент преобладает во всем массиве. За счет того, что проверяется N/2+1 сбить в 0 этот элемент не получится во всех случаях, все равно он вылезет в конце первого прохода, как его не прячь за другими (второстепенными) элементами. Второй проход для проверки ложноположительного результата.
"Тревожный чемоданчик" — это рюкзак 25-30 литров, с которым нужно мчаться под сиренами в бомбоубежище или на места сбора для эвакуации с надеждой вернуться пораньше или вообще когда-то. Все вещи, что больше этого — будут отбирать и выкидывать там же угрюмые люди, думающие о спасении гражданских. Остальные будут или счастливо/случайно выжившие в своем подвале или отстреляны или зарезаны или упрутся в колючку-забор или с голоду-холоду помрут в лесу / пыточном подвале.
пакуйте все внутри рюкзака в легкие мусорные мешки. Легче гермомешка и надежнее всяких накидок от дождя.
мультитул гораздо тяжелее и не так удобно пользоваться при кормежке. Мультитул попадает под категорию "обойдусь". Впрочем, нож тоже редко нужен. В теории нож — вещь первой необходимости. На практике, что есть критерий истины — нет.
Олимпиадник быстрее найдет очень высокооплачиваемую работу и будет набивать шишки там, получая огромные деньги и работая над интересными проектами.
Не-олимпиадник будет тоже набивать шишки, но за гораздо меньшие деньги и надеяться, что когда-то доберется до тех зарплат и проектов. Ну или разгребать за олимпиадником.
Плюс-минус исключения.
Описана работа обычного ThreadPool - FJP решает проблемы, которые при обычном подходе возникают. Это не описано вообще. Принципиальное отличие в подходе WorkStealing, который часто подразумевает рекурсивные алгоритмы. WorkStealing - это не процесс вытаскивания задачи из общего пула, а процесс вытаскивания задачи из очереди другого обработчика, если (и только если) своя очередь пуста. Рекурсия здесь вот при чем - каждый обработчик разбивает задачу на подзадачи и помещает эти задачи в очередь, из очереди они попадают в отдельные очереди каждого обработчика (можно сделать без submission queue но не нужно). Это важно - в отличие от простой реализации пула потоков, очередь исполнения не одна, а отдельно для каждого потока. Это позволяет минимизировать синхронизацию обработчиков и именно ради этого все затевается. FJP спроектирован для мелких, нагружающих именно процессор задач, поэтому минимизация расходов на синхронизацию так важна и поэтому он по дефолту инициализируется количеством потоков равных числу вычислительных ядер.
Как говаривал ТехЛид: я окружен людьми, которые думают, что у них синдром "самозванца". А на самом деле они и есть самозванцы.
Проблемы со спиной. Похожее начало, но выход найден. Махнули все, в первую очередь — врачи. Качалку пробовал (малые веса) — не могу, нудятина. Бег с другом за компанию — быстро нафиг. Про всякие зарядки — даже без намека на возможность сделать хотя бы раз полностью. Все решило одно — физ активность, которая увлекла. Начал с тремя годами айкидо, сейчас 7 лет бразильского Джиу джитсу. Кстати, в детстве пытался в кунг-фу -не смог, нудятина показалась. Параллельно с невестой хожу в бассейн. Нудятина. Через силу. Бадминтон — не так плохо, но без интереса. Сейчас зал закрыли — бегаю полчаса. Один или не один. В наушниках или нет. Нудятина, не могу.
Так что единственное, что работает -что понравится. Единоборства -отличные нескучный способ для многих, но не для абсолютно всех. И не всякие. Кому-то зайдет тайский бокс, кому борьба, кому капуейра какая-то.
это факт — именно это и написано в "от переводчика", а в переводе этого нет.