А ведь так (аналогично изоляции через протокол) можно и какой-то другой макрос применить ко всем соответствующим протоколу методам/свойствам класса?
К примеру, есть у меня крохотная либа, прокидывающая методы (только async, конечно) и свойства объекта в js-код, вызываемый в WKWebView. Сейчас она сделана на генериках + для кастомных классов свой протокол, который надо реализовать руками, а будет неплохо сделать что-то типа JSExport для протоколов (в JavaScriptCore по сравнению с WKWebView очень удобно объекты прокидывать, достаточно аннотации для протокола).
Случайные из интервала [0,1). Math.random() или что там в вашем языке доступно, количество не влияет (товарищ выше очень понятно объяснил: каждой карте назначили случайное число и выбрали ту, что с самым большим).
что бы не писать обработчики ожидания того что база или сервер стартанул
Надо писать. Тем более в многопоточном/многопроцессном приложении это вообще халява, никаких тебе колбэков или async-await, просто поставить в код вызов типа "WaitForServiceStarted()".
Shared memory – это путь к ручной синхронизации потоков, месту, где стрелять себе в ногу – обыденность.
Возможно, для оптимизации достаточно собирать большие куски данных в локальной памяти и пересылать их целиком. А разделяемая память – на самый крайний случай.
После устранения нестабильности тест TestSharedValue должен не всегда проходить успешно, а всегда фэйлиться. Просто потому, что в реальной жизни он может так сделать, и надо это обнаружить заранее.
Алгоритм Карацубы – это про умножение. Ну и думаю, что там сложение простое: оптимизация из статьи – для суммирования кучи чисел... По сути, вынос части работы из цикла суммирования.
Речь не про суть (там трудно спорить). Речь про то, что вы написали целую статью там, где достаточно одного абзаца.
Насчёт "тестовой инфраструктуры" – обычно она отделена от основного кода и является зоной ответственности команды QA. QA не лезут в код самого проекта, программисты не лезут в тесты. Разумный предел – читать код друг друга, но не модифицировать самим.
Очень много текста, а всё, по большому счёту, сводится к тому, что
Через специально оставленные API тестировать удобнее (кто бы сомневался)
Даём тестировщикам доступ к репе, пусть сами себе их делают (сомнительно... Обычно принято делать наоборот: тестировщики дают программерам заказ на нужные идентификаторы или что там, а не лезут в код сами).
Ну и ещё: такие тесты, конечно, будут реже разваливаться и программистам будет удобнее читать об ошибке, но внезапно есть ситуации, где такой тест пройдет успешно, невзирая на ошибку. Например, элемент с этим id переставили в какое-то место, где юзер его не найдёт никогда. Так что тесты "не через специально оставленную для них дырочку" тоже нужны.
Когда так можно переписать (идеальный случай – перейти к векторным операциям) – прекрасно. Когда от этого код становится труднее читать (бывает и такое) – лучше лишний раз подумать, стоит ли овчинка выделки.
А ведь так (аналогично изоляции через протокол) можно и какой-то другой макрос применить ко всем соответствующим протоколу методам/свойствам класса?
К примеру, есть у меня крохотная либа, прокидывающая методы (только async, конечно) и свойства объекта в js-код, вызываемый в WKWebView. Сейчас она сделана на генериках + для кастомных классов свой протокол, который надо реализовать руками, а будет неплохо сделать что-то типа JSExport для протоколов (в JavaScriptCore по сравнению с WKWebView очень удобно объекты прокидывать, достаточно аннотации для протокола).
Случайные из интервала [0,1). Math.random() или что там в вашем языке доступно, количество не влияет (товарищ выше очень понятно объяснил: каждой карте назначили случайное число и выбрали ту, что с самым большим).
Ну не надо настолько кроить на оптике в 700-долларовом устройстве...
Ну да, но если можно остановить хоть на секунду для создания снэпшота – этого хватит. Куда лучше, чем ждать, пока всё сбэкапится.
Эту функцию всё равно надо писать. Если для тестов ещё можно просто воткнуть sleep, то в проде это неприемлемо.
Снэпшоты прекрасны для консистентного бэкапа без остановки мира, факт.
Кажется, пресс-релиз доверили писать человеку, не знающему математики...
Надо писать. Тем более в многопоточном/многопроцессном приложении это вообще халява, никаких тебе колбэков или async-await, просто поставить в код вызов типа "WaitForServiceStarted()".
10 раз подумайте, прежде чем так делать.
Shared memory – это путь к ручной синхронизации потоков, месту, где стрелять себе в ногу – обыденность.
Возможно, для оптимизации достаточно собирать большие куски данных в локальной памяти и пересылать их целиком. А разделяемая память – на самый крайний случай.
Это странно: ведь раскладываются всегда одинаково, легко можно откалибровать.
Кажется, автор не понимает идею тестов.
После устранения нестабильности тест TestSharedValue должен не всегда проходить успешно, а всегда фэйлиться. Просто потому, что в реальной жизни он может так сделать, и надо это обнаружить заранее.
Алгоритм Карацубы – это про умножение. Ну и думаю, что там сложение простое: оптимизация из статьи – для суммирования кучи чисел... По сути, вынос части работы из цикла суммирования.
Цыган на цыпочках цыкнул на цыплёнка: цыц!
Нехватка кадров всегда была: нужны синьоры и мидлы, джунов не нанимают – мидлам расти не из кого.
Речь не про суть (там трудно спорить). Речь про то, что вы написали целую статью там, где достаточно одного абзаца.
Насчёт "тестовой инфраструктуры" – обычно она отделена от основного кода и является зоной ответственности команды QA. QA не лезут в код самого проекта, программисты не лезут в тесты. Разумный предел – читать код друг друга, но не модифицировать самим.
Очень много текста, а всё, по большому счёту, сводится к тому, что
Через специально оставленные API тестировать удобнее (кто бы сомневался)
Даём тестировщикам доступ к репе, пусть сами себе их делают (сомнительно... Обычно принято делать наоборот: тестировщики дают программерам заказ на нужные идентификаторы или что там, а не лезут в код сами).
Ну и ещё: такие тесты, конечно, будут реже разваливаться и программистам будет удобнее читать об ошибке, но внезапно есть ситуации, где такой тест пройдет успешно, невзирая на ошибку. Например, элемент с этим id переставили в какое-то место, где юзер его не найдёт никогда. Так что тесты "не через специально оставленную для них дырочку" тоже нужны.
Пользователи emacs давно бы заскриптовали и пользовались, как удобно. xkcd#378.
Я так понимаю, не 15 раз из разных мест, а 15 раз подряд из одного места, в цикле. Это материал для новичков же, тут про простые вещи.
Когда так можно переписать (идеальный случай – перейти к векторным операциям) – прекрасно. Когда от этого код становится труднее читать (бывает и такое) – лучше лишний раз подумать, стоит ли овчинка выделки.
В школе учить учиться практически не учат – там учитель даёт конкретные знания. В основном учиться учат в институте. И то не всех и не всегда успешно.