"никто не может пообещать, что сделанное на техдне обязательно пойдет в работу, будет дополишено и в конечном итоге окажется на проде"
"специальная встреча с продюсером и лидами команд, где рассматриваются все результаты"
И чем это тогда существенно отличается от обычной разработки? Все это на нормальной работе можно сделать без специального дня - поднять проблему, обсудить/создать тикет, приоритезировать его, если надо. В здоровом коллективе это может сделать любой, а не ПМ/ПО/Арх из башни цвета слоновой кости.
Так-то идея выделять время на "сделать что-то по фану" неплохая, но в данном примере слишком много ограничений, которые весь фан убивают.
Кажется, что многие из этих изменений будут ловиться даже простым токенизатором, который выкидывает комментарии. И для случая, когда списывают 1-в-1 или просто переименовывают переменные, это достаточно. Вставка случайных элементов, возможно, решается добавлением "забывчивости" в токенизатор. (Говнокод на эту тему можно посмотреть тут, будет время, может прогоню на датасете). Но хотелось бы видеть сравнение с JPLAG и аналогами, чтобы было понятно, насколько предложенное решение лучше.
Насчет применения: одним из возможных приложений может быть проверка студенческих лаб/заданий.
Отмечу, что в упомянутой в начале статье упомянуты не какие-то синтетические методы выстрелов в ногу, а "основанные на реальных событиях". Стоит учесть, что это 2016 год, 5 лет назад. Сам язык мы начали использовать еще до официального релиза 1.0, и некоторые концепты, очевидные сейчас, тогда были еще новы.
ookami_kb
Судя по всему, вы запускаете с использованием JUnit4. В нем действительно оборачивается простой ассерт в org.junit.ComparisonFailure. Однако ассерт чуть посложнее уже не будет оборачиваться:
Скриншот
С JUnit5 ситуация чуть повеселее. Есть баг в IntelliJ, суть которого в том, что интеграция не всегда работает, если запускать тесты через gradle (как это раньше делал я). И еще один связанный баг зарелизят в следующей версии.
В итоге если запускать тесты не через gradle, а через Idea (настраивается это через Settings → Build, Execution, Deployment → Gradle → Run tests using), то и в JUnit5 будет показываться сравнение, но только для простого isEqualTo:
Скриншот
Спасибо за ваше замечание, узнал много интересного:)
Занятно, на это даже есть тикет у AssertJ. Вечером посмотрю, т.к. opentest4j в проекте идет от junit-jupiter-engine и не очень понятно, как правильно от этого избавиться.
Так в том-то и дело, что если использовать только zig, то там с тем же успехом можно получить квадратичную сложность. В некоторых случаях это будет хуже чем с обычным ДДП,
Мораль сей басни такова: если приходится иметь дело с бинарным деревом поиска — работайте с ним как со splay tree, т.е. при любом действии с любым узлом дерева делайте этот узел корнем.
Очень странный вывод. Люди целые статьи пишут про сравнение поведения различных ДДП в зависимости от сценария использования, а тут такое однозначное утверждение. Конкретно в этом случае квадратичный случай в худшем случае меняется за счет того, что splay-дерево — самобалансирующееся и имеет логарифмическую амортизованную сложность операций. Но с тем же успехом подошло бы любое самобалансирующееся дерево — красно-черное или АВЛ, например.
Кроме того, тупое поднятие в корень без использования процедур zig, zigzag и zigzig может все равно привести к линейной сложности операции. Про комбинацию этих трех процедур есть доказательство, что там все будет ок, а если, например, использовать только zig (им тоже элемент в корень можно поднять), то можно получить квадратичную сложность операции в худшем случае.
Спасибо за ответ. Я в целом согласен с вашем мнением. У меня сложилось впечатление, что схожая позиция о важности culture fit вырабатывается во многих компаниях. Именно этим и вызвана моя фрустация от несоответствия заголовка статьи и ее содержания: я ожидал получить новую информацию про отбор по culture fit, а получил статью с противоречиями про отбор по формальным и полуформальным параметрам.
Мне кажется, что это комплексная проблема. Не выстроен процесс документирования и обмена знаниями -> информация в доках неактуальна и/или не знаешь где смотреть -> все к этому привыкли -> теория разбитых окон — дока плохая, и улучшать ее все тяжелее и тяжелее -> уже не лезешь в доку, потому что ее считай что нет -> «проще спросить» -> выученная беспомощность, когда сам уже не можешь разобраться ни с чем новым и спрашиваешь у других вместо попыток разобраться/обращения к докам.
У вашего компилятора. Потому это канонический пример undefined behavior.
https://en.cppreference.com/w/cpp/language/eval_order
Можно "сделать что-то по фану", но:
"делаешь что-то связанное с проектом"
"у кого-то может быть реально много задач"
"можно просто выбрать из списка"
"на время техдней объединяться в мини-команды"
"никто не может пообещать, что сделанное на техдне обязательно пойдет в работу, будет дополишено и в конечном итоге окажется на проде"
"специальная встреча с продюсером и лидами команд, где рассматриваются все результаты"
И чем это тогда существенно отличается от обычной разработки? Все это на нормальной работе можно сделать без специального дня - поднять проблему, обсудить/создать тикет, приоритезировать его, если надо. В здоровом коллективе это может сделать любой, а не ПМ/ПО/Арх из башни цвета слоновой кости.
Так-то идея выделять время на "сделать что-то по фану" неплохая, но в данном примере слишком много ограничений, которые весь фан убивают.
Кажется, что многие из этих изменений будут ловиться даже простым токенизатором, который выкидывает комментарии. И для случая, когда списывают 1-в-1 или просто переименовывают переменные, это достаточно. Вставка случайных элементов, возможно, решается добавлением "забывчивости" в токенизатор. (Говнокод на эту тему можно посмотреть тут, будет время, может прогоню на датасете). Но хотелось бы видеть сравнение с JPLAG и аналогами, чтобы было понятно, насколько предложенное решение лучше.
Насчет применения: одним из возможных приложений может быть проверка студенческих лаб/заданий.
Отмечу, что в упомянутой в начале статье упомянуты не какие-то синтетические методы выстрелов в ногу, а "основанные на реальных событиях". Стоит учесть, что это 2016 год, 5 лет назад. Сам язык мы начали использовать еще до официального релиза 1.0, и некоторые концепты, очевидные сейчас, тогда были еще новы.
Тем временем:
В России впервые зарегистрировали более 800 смертей от COVID за сутки
За сутки в России выявили 21 932 новых случая заражения коронавирусом SARS-CoV-2
https://www.rbc.ru/society/12/08/2021/6114dae19a7947d4d004a538
Решение интересное, но, кажется, что некоторых кейсах это проще сделать через xxd.
выведет что-то вроде:
Идея затащить логи в кокпит — интересная, хоть и немного странная. Спасибо за статью, хотелось бы все-таки посмотреть плагин подробнее на github'e.
Еще помогает открыть developer tools почему-то. Возможно поэтому не воспроизводится у разработчиков хабра:)
Баг бесит, у меня такое постоянно.
Статья вызывает впечатление, что кто-то открыл для себя акторы и спешит поделиться с миром.
Недавно появился, так что этого минуса больше нет
ookami_kb
Судя по всему, вы запускаете с использованием JUnit4. В нем действительно оборачивается простой ассерт в
org.junit.ComparisonFailure. Однако ассерт чуть посложнее уже не будет оборачиваться:С JUnit5 ситуация чуть повеселее. Есть баг в IntelliJ, суть которого в том, что интеграция не всегда работает, если запускать тесты через gradle (как это раньше делал я). И еще один связанный баг зарелизят в следующей версии.
В итоге если запускать тесты не через gradle, а через Idea (настраивается это через Settings → Build, Execution, Deployment → Gradle → Run tests using), то и в JUnit5 будет показываться сравнение, но только для простого isEqualTo:
Спасибо за ваше замечание, узнал много интересного:)
Занятно, на это даже есть тикет у AssertJ. Вечером посмотрю, т.к. opentest4j в проекте идет от junit-jupiter-engine и не очень понятно, как правильно от этого избавиться.
Вот как выглядит у меня что в Community 2020.1.2, что в 2019.3.3
А какая у вас версия IntelliJ?
В игровой форме изучить можно здесь:
https://learngitbranching.js.org/
Так в том-то и дело, что если использовать только zig, то там с тем же успехом можно получить квадратичную сложность. В некоторых случаях это будет хуже чем с обычным ДДП,
Очень странный вывод. Люди целые статьи пишут про сравнение поведения различных ДДП в зависимости от сценария использования, а тут такое однозначное утверждение. Конкретно в этом случае квадратичный случай в худшем случае меняется за счет того, что splay-дерево — самобалансирующееся и имеет логарифмическую амортизованную сложность операций. Но с тем же успехом подошло бы любое самобалансирующееся дерево — красно-черное или АВЛ, например.
Кроме того, тупое поднятие в корень без использования процедур zig, zigzag и zigzig может все равно привести к линейной сложности операции. Про комбинацию этих трех процедур есть доказательство, что там все будет ок, а если, например, использовать только zig (им тоже элемент в корень можно поднять), то можно получить квадратичную сложность операции в худшем случае.
Есть минус — по умолчанию нельзя подписаться на все комменты в своем боге.
Спасибо за ответ. Я в целом согласен с вашем мнением. У меня сложилось впечатление, что схожая позиция о важности culture fit вырабатывается во многих компаниях. Именно этим и вызвана моя фрустация от несоответствия заголовка статьи и ее содержания: я ожидал получить новую информацию про отбор по culture fit, а получил статью с противоречиями про отбор по формальным и полуформальным параметрам.
Мне кажется, что это комплексная проблема. Не выстроен процесс документирования и обмена знаниями -> информация в доках неактуальна и/или не знаешь где смотреть -> все к этому привыкли -> теория разбитых окон — дока плохая, и улучшать ее все тяжелее и тяжелее -> уже не лезешь в доку, потому что ее считай что нет -> «проще спросить» -> выученная беспомощность, когда сам уже не можешь разобраться ни с чем новым и спрашиваешь у других вместо попыток разобраться/обращения к докам.