Вы рекомендуете несколько метрик, основанных на том, сколько тесты поймали багов до релиза. Но если тесты автоматически запускаются для pull-request, то довольно сложно оценить сколько багов они поймали, потому что они будут запускаться и для совсем сырого кода. При этом мы скорее хотим так делать, чтобы как можно раньше выявить потенциальные проблемы и ловить их ветках разработчиков, а не в trunk/main.
Мне кажется, вы зря так отмахиваетесь: тяжело представить, что ролей больше 4 млрд, если ид меньше 65к. И вполне возможно, что их можно разместить в непрерывно или блоками. Как указали выше, вы тоже делаете предположение, про выравнивание объекта по указателю, что совсем необязательно
Непонятно, чем в последней задаче различаются игроки. Вроде выбранные векторы в общем случае ничем не отличаются, игроки ходят одновременно, но у одного получается положительный выигрыш, а у второго отрицательный
Как раз в хайлоаде очень часто есть потребность в экспериментах (настройки инстансов, размеры внутренних буфферов и тп), которые вполне может поставить junior под чутким руководством.
Этот вопрос применим и к обычной фабрике - там тоже можно просто вызывать конструкторы.
Стандартные выгоды: вынос общего бойлерплейта (логгирование, кэширование, пул памяти) или возможность передать фабрику как внешний параметр для другого шаблона вроде аллокатора из STL.
Вероятность, что хотя бы одна машина выйдет из строя растет при количестве машин, то есть если буквально читать, как написано в переводе, то мы чаще будем сталкиваться с недоступностью в части данных. В оригинале используются слова "not performing" - здесь это употреблено в контексте репликации, то есть когда данные на всех узлах одинаковы. Соответственно, вы теряете в скорости чтения, но доступность всех данных сохраняется.
P.S. Также по тексту "multiprocessing" переведено как "многопроцессорная", хотя здесь это "многопроцессная" в противопоставлении с многопоточной.
Даже если все пользователи будут знать о ремонте, у вас скорее всего есть лаг обработки данных порядка недели, поэтому весь этот период веса будут некорректно вести в ремонтирующуюся дорогу.
Мне правда интересно, почему это не считается проблемой. Обычно пользователи любят, когда им оперативно показывают дорожные события и как их обойти. Возможно, вероятности у вас сильно ограничены в разбросе и их влияние не так велико.
Повторюсь, что мне казалось бы естественным, снижать влияние вероятности, если ситуация несколько необычная, например, текущая скорость на эдже сильно отличается от исторической.
Что произойдет, если на высоковероятном ребре начнется ремонт? Как вы сможете это почувствовать?
То есть раньше у вас сработало бы переключение на другое ребро по трафику, а сейчас высокая вероятность ребра все равно погонит всех в пробку и вы здесь не получите фидбека, нужного для снижения вероятности. Как будто нужно отрубать вероятности, если скоростной профиль ребра существенно изменился.
Не защищая сбор статистики в МойОфис, стоит отметить что ИТ-компания это не РЖД и даже не Макдональдс, поэтому вовлеченность может сильно отличаться от средней. На графике в источнике тоже отражена зависимость от сфера деятельности.
Видели ли вы когда-нибудь концепт-кары на выставке? И сколько из них в таком виде поехало по улице? Я к тому, перспективы "дальнейшего коммерческого использования" - неизвестны, все может отмениться и поменяться, в том числе и голос. Автор обращался с вопросом: "нужно ли судиться сейчас?" - на сейчас как будто позиция слабовата да и торопиться некуда.
1. Для двунаправленного поиска есть довольно тонкий момент, что неизвестно время прихода на финиш, что важно для оценки пробок. Соответственно, обычно для финиша берется какое-то предсказание, которое может не совпасть с реальным и две волны встретятся в разное время. Для решения проблемы, наверное, нужно продолжать гнать прямую волну, а результаты обратной использовать как эвристику 2. В OSRM есть второй алгоритм - multi-level dijkstra (MLD). Он позволяет обновлять индекс на лету, но тут тоже сильно будет зависеть от скорости устройства и объема данных
Вы рекомендуете несколько метрик, основанных на том, сколько тесты поймали багов до релиза. Но если тесты автоматически запускаются для pull-request, то довольно сложно оценить сколько багов они поймали, потому что они будут запускаться и для совсем сырого кода. При этом мы скорее хотим так делать, чтобы как можно раньше выявить потенциальные проблемы и ловить их ветках разработчиков, а не в trunk/main.
Мне кажется, вы зря так отмахиваетесь: тяжело представить, что ролей больше 4 млрд, если ид меньше 65к. И вполне возможно, что их можно разместить в непрерывно или блоками. Как указали выше, вы тоже делаете предположение, про выравнивание объекта по указателю, что совсем необязательно
Непонятно, чем в последней задаче различаются игроки. Вроде выбранные векторы в общем случае ничем не отличаются, игроки ходят одновременно, но у одного получается положительный выигрыш, а у второго отрицательный
Как раз в хайлоаде очень часто есть потребность в экспериментах (настройки инстансов, размеры внутренних буфферов и тп), которые вполне может поставить junior под чутким руководством.
у слов в языке явно не равномерное распределение, а метод сработал
Этот вопрос применим и к обычной фабрике - там тоже можно просто вызывать конструкторы.
Стандартные выгоды: вынос общего бойлерплейта (логгирование, кэширование, пул памяти) или возможность передать фабрику как внешний параметр для другого шаблона вроде аллокатора из STL.
Не таких уж и малых: x - sin(x) ~= x^3/6 . Ошибка в третьем знаке появляется при x=0.18 - это 10 градусов. На метровой нитке вполне комфортный угол
На сервере должна мгновенно создаваться. На клиенте switch тоже быстро должен работать.
> Кто занимался резолвом конфликтов в свн - тот в цирке не смеется.
А в git что изменилось с этим?
Сделка не произошла, но случилось "неосновательное обогащение" - довольно противоречивая ситуация в гражданском праве.
GPL не требует, чтобы код был публично выложен
Вероятность, что хотя бы одна машина выйдет из строя растет при количестве машин, то есть если буквально читать, как написано в переводе, то мы чаще будем сталкиваться с недоступностью в части данных.
В оригинале используются слова "not performing" - здесь это употреблено в контексте репликации, то есть когда данные на всех узлах одинаковы. Соответственно, вы теряете в скорости чтения, но доступность всех данных сохраняется.
P.S.
Также по тексту "multiprocessing" переведено как "многопроцессорная", хотя здесь это "многопроцессная" в противопоставлении с многопоточной.
Даже если все пользователи будут знать о ремонте, у вас скорее всего есть лаг обработки данных порядка недели, поэтому весь этот период веса будут некорректно вести в ремонтирующуюся дорогу.
Мне правда интересно, почему это не считается проблемой. Обычно пользователи любят, когда им оперативно показывают дорожные события и как их обойти. Возможно, вероятности у вас сильно ограничены в разбросе и их влияние не так велико.
Повторюсь, что мне казалось бы естественным, снижать влияние вероятности, если ситуация несколько необычная, например, текущая скорость на эдже сильно отличается от исторической.
Что произойдет, если на высоковероятном ребре начнется ремонт? Как вы сможете это почувствовать?
То есть раньше у вас сработало бы переключение на другое ребро по трафику, а сейчас высокая вероятность ребра все равно погонит всех в пробку и вы здесь не получите фидбека, нужного для снижения вероятности. Как будто нужно отрубать вероятности, если скоростной профиль ребра существенно изменился.
Предлагаю распечатать инструкцию:
Если я что-то знаю, а кто-то - нет, скажи: "но это же обычный кругозор, неужели вам за всю вашу жизнь не было интересно что делают ..."
Если кто-то что-то знает, а я - нет, скажи: "разве я должен знать эти стопицот фреймвоков и все такое?"
Не защищая сбор статистики в МойОфис, стоит отметить что ИТ-компания это не РЖД и даже не Макдональдс, поэтому вовлеченность может сильно отличаться от средней. На графике в источнике тоже отражена зависимость от сфера деятельности.
Видели ли вы когда-нибудь концепт-кары на выставке? И сколько из них в таком виде поехало по улице?
Я к тому, перспективы "дальнейшего коммерческого использования" - неизвестны, все может отмениться и поменяться, в том числе и голос.
Автор обращался с вопросом: "нужно ли судиться сейчас?" - на сейчас как будто позиция слабовата да и торопиться некуда.
Пока не очень понятно, в чем нарушение лицензии:
1. использование некоммерческое
2. распространения пока не произошло - вроде не релиз был, а демо
Если работа приостановлена, то новая зарплата начисляться не будет. Можно пытаться на треть претендовать, но там уже немного спорно.
1. Для двунаправленного поиска есть довольно тонкий момент, что неизвестно время прихода на финиш, что важно для оценки пробок. Соответственно, обычно для финиша берется какое-то предсказание, которое может не совпасть с реальным и две волны встретятся в разное время. Для решения проблемы, наверное, нужно продолжать гнать прямую волну, а результаты обратной использовать как эвристику
2. В OSRM есть второй алгоритм - multi-level dijkstra (MLD). Он позволяет обновлять индекс на лету, но тут тоже сильно будет зависеть от скорости устройства и объема данных
Интересно посмотреть на то, какие коэффициенты нужно добавить в CTable и как будет выглядеть GetAreaUnion, если:
нужно рассчитать площадь фигуры, заданной точками (контур или внутренность)
другой случай: сами точки получаются, как значения функции
третий случай: пространство искривлено, а коэффициент искривления определяется внешней настройкой
Потому что когда методы виртуальные - это скучно и просто