Как стать автором
Обновить
20
0
Влад @ov7a

Пользователь

Отправить сообщение

Можно "сделать что-то по фану", но:

  1. "делаешь что-то связанное с проектом"

  2. "у кого-то может быть реально много задач"

  3. "можно просто выбрать из списка"

  4. "на время техдней объединяться в мини-команды"

  5. "никто не может пообещать, что сделанное на техдне обязательно пойдет в работу, будет дополишено и в конечном итоге окажется на проде"

  6. "специальная встреча с продюсером и лидами команд, где рассматриваются все результаты"

И чем это тогда существенно отличается от обычной разработки? Все это на нормальной работе можно сделать без специального дня - поднять проблему, обсудить/создать тикет, приоритезировать его, если надо. В здоровом коллективе это может сделать любой, а не ПМ/ПО/Арх из башни цвета слоновой кости.

Так-то идея выделять время на "сделать что-то по фану" неплохая, но в данном примере слишком много ограничений, которые весь фан убивают.

Кажется, что многие из этих изменений будут ловиться даже простым токенизатором, который выкидывает комментарии. И для случая, когда списывают 1-в-1 или просто переименовывают переменные, это достаточно. Вставка случайных элементов, возможно, решается добавлением "забывчивости" в токенизатор. (Говнокод на эту тему можно посмотреть тут, будет время, может прогоню на датасете). Но хотелось бы видеть сравнение с JPLAG и аналогами, чтобы было понятно, насколько предложенное решение лучше.

Насчет применения: одним из возможных приложений может быть проверка студенческих лаб/заданий.

Отмечу, что в упомянутой в начале статье упомянуты не какие-то синтетические методы выстрелов в ногу, а "основанные на реальных событиях". Стоит учесть, что это 2016 год, 5 лет назад. Сам язык мы начали использовать еще до официального релиза 1.0, и некоторые концепты, очевидные сейчас, тогда были еще новы.

Тем временем:


В России впервые зарегистрировали более 800 смертей от COVID за сутки
За сутки в России выявили 21 932 новых случая заражения коронавирусом SARS-CoV-2
https://www.rbc.ru/society/12/08/2021/6114dae19a7947d4d004a538

Решение интересное, но, кажется, что некоторых кейсах это проще сделать через xxd.


xxd --include filename

выведет что-то вроде:


unsigned char filename[]={ 0x48, ...}; 
unsigned int filename_len = 123;

Идея затащить логи в кокпит — интересная, хоть и немного странная. Спасибо за статью, хотелось бы все-таки посмотреть плагин подробнее на github'e.

Еще помогает открыть developer tools почему-то. Возможно поэтому не воспроизводится у разработчиков хабра:)


Баг бесит, у меня такое постоянно.

Статья вызывает впечатление, что кто-то открыл для себя акторы и спешит поделиться с миром.

Недавно появился, так что этого минуса больше нет

ookami_kb
Судя по всему, вы запускаете с использованием JUnit4. В нем действительно оборачивается простой ассерт в org.junit.ComparisonFailure. Однако ассерт чуть посложнее уже не будет оборачиваться:


Скриншот

image


С JUnit5 ситуация чуть повеселее. Есть баг в IntelliJ, суть которого в том, что интеграция не всегда работает, если запускать тесты через gradle (как это раньше делал я). И еще один связанный баг зарелизят в следующей версии.


В итоге если запускать тесты не через gradle, а через Idea (настраивается это через Settings → Build, Execution, Deployment → Gradle → Run tests using), то и в JUnit5 будет показываться сравнение, но только для простого isEqualTo:


Скриншот

image


Спасибо за ваше замечание, узнал много интересного:)

Занятно, на это даже есть тикет у AssertJ. Вечером посмотрю, т.к. opentest4j в проекте идет от junit-jupiter-engine и не очень понятно, как правильно от этого избавиться.

Вот как выглядит у меня что в Community 2020.1.2, что в 2019.3.3


Скриншот

image

А какая у вас версия IntelliJ?

В игровой форме изучить можно здесь:
https://learngitbranching.js.org/

Так в том-то и дело, что если использовать только zig, то там с тем же успехом можно получить квадратичную сложность. В некоторых случаях это будет хуже чем с обычным ДДП,

Мораль сей басни такова: если приходится иметь дело с бинарным деревом поиска — работайте с ним как со splay tree, т.е. при любом действии с любым узлом дерева делайте этот узел корнем.

Очень странный вывод. Люди целые статьи пишут про сравнение поведения различных ДДП в зависимости от сценария использования, а тут такое однозначное утверждение. Конкретно в этом случае квадратичный случай в худшем случае меняется за счет того, что splay-дерево — самобалансирующееся и имеет логарифмическую амортизованную сложность операций. Но с тем же успехом подошло бы любое самобалансирующееся дерево — красно-черное или АВЛ, например.


Кроме того, тупое поднятие в корень без использования процедур zig, zigzag и zigzig может все равно привести к линейной сложности операции. Про комбинацию этих трех процедур есть доказательство, что там все будет ок, а если, например, использовать только zig (им тоже элемент в корень можно поднять), то можно получить квадратичную сложность операции в худшем случае.

Есть минус — по умолчанию нельзя подписаться на все комменты в своем боге.

Спасибо за ответ. Я в целом согласен с вашем мнением. У меня сложилось впечатление, что схожая позиция о важности culture fit вырабатывается во многих компаниях. Именно этим и вызвана моя фрустация от несоответствия заголовка статьи и ее содержания: я ожидал получить новую информацию про отбор по culture fit, а получил статью с противоречиями про отбор по формальным и полуформальным параметрам.

Мне кажется, что это комплексная проблема. Не выстроен процесс документирования и обмена знаниями -> информация в доках неактуальна и/или не знаешь где смотреть -> все к этому привыкли -> теория разбитых окон — дока плохая, и улучшать ее все тяжелее и тяжелее -> уже не лезешь в доку, потому что ее считай что нет -> «проще спросить» -> выученная беспомощность, когда сам уже не можешь разобраться ни с чем новым и спрашиваешь у других вместо попыток разобраться/обращения к докам.

Возможно я не разобрался, но для того, чтобы отбирать по культуре, наверно, стоит как-то эту культуру определить? И как-то более конкретно обрисовать, хотя бы на единичных примерах, как понять, соответствует ли ей человек или нет? Например, вы пишете, что спрашиваете кандидата о том, какие у него мотивы. А результат-то какой? В чем инсайт? Если он хочет только деньги — сразу в мусорку? А если с горящими глазами говорит «хочу к вам и только к вам, потому что вы клевые» — сразу берете? Зачем вы вообще о мотивах спрашиваете?


С образованием вы сами себе противоречите, о чем вам в комментах писали. Даже в комменте, на который я отвечаю. Если хорошая корочка ничего не гарантирует, и отсутствие корочки — тоже ни о чем не говорит, то в чем важность-то? Чтобы было о чем поговорить? Или чтобы резюме было проще фильтровать (см. анекдот про «не люблю неудачников»).

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность