Влад ov7a

Идея затащить логи в кокпит — интересная, хоть и немного странная. Спасибо за статью, хотелось бы все-таки посмотреть плагин подробнее на 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 tree, т.е. при любом действии с любым узлом дерева делайте этот узел корнем.

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

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

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

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

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

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

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

Я и не говорил ничего про обязательность высшего. Как у вас тогда нанимаются студенты младших курсов и люди без образования — все по исключениям? Тогда наверно эти факторы не такое уж и влияние имеют — зачем на них делать акцент?

Правила у вас по моим впечатлениям плюс-минус обычные, только противоречивые. Каких-то новых инсайтов лично я не увидел.

Повторюсь, что в статье нет ничего про друзей — прокомментируйте пожалуйста, почему вы считаете, что по этим правилам вы выбираете именно друга, а не просто сотрудника или хотя бы человека, подходящего по культуре.

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

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

Сама статья не оправдала заголовка — про друзей в ней ничего нет.

Я не говорю, что для скалы порог входа высокий. Я тоже могу рассказать несколько историй про то, как быстро люди начинают на ней писать.
Я про то, что у питона он ниже. Еще раз — я ни в коем случае не против скалы. Просто говорю, что питон начал отъедать ее аудиторию для спарка. Я уже не знаю, как вам еще доказать, что это не «сказки» — зайдите что ли в чат русского сообщества apache spark в телеге или посмотрите программу Spark AI Summit — там есть чисто питонячий трек.

Для действительно тяжелых задач — да, на скале будет быстрее. Для того, чтобы проверять гипотезы — вряд ли. Тут уже разница есть, когда нужно реальная оптимизация, недостижимая сменой алгоритма. Но api pyspark предоставляет почти полностью идентичный скале, выполняется все на экзекуторах. Если большая часть обработки — на spark sql или через стандартные методы, то питон там будет проседать в основном только из-за боксинга/анбоксинга. По сетке гонять все равно дороже.

В любом случае порог входа ниже для питониста. Если даже взять среднюю температуру по больнице в виде запросов “spark scala” и “spark python” на hh, то получим 134 против 211.

Так про то и речь. Раньше дата-анализ на спарке был либо на голых rdd, либо на java-либах. Сейчас эту нишу отъел питон.

В тестах? Весьма странно — имхо, у scala test больше возможностей и гибкости, чем у любой котлиновской библиотеки тестов или junit того же самого.

Вот вы сами сказали что модели пишут на питоне, а потом в проде на java переписывают. Если на скале удобнее — чего ж на ней-то не пишут?
В спарке в том то и прикол, что очень многим от него начинает быть нужен только spark sql. А там без разницы практически на чем писать. Вот и пишут дата сайентисты на питоне спарковские джобы. Т.е. основной язык, где разрабатывается что-то новое, уже не факт, что scala.

Ок, перефразирую вопрос — при каких условиях для нового проекта будет использоваться Akka? Эти условия те же, что были до появления котлина с корутинами?

Disclaimer: я не фанат котлина, но мне кажется, что он неплохо отжирает долю ниш скалы.

Поверх континуаций акторы строятся легко. Представьте, что вы разработчик, который одинаково знаком с akka и корутинами — новый проект на чем будете начинать?

Мне кажется, что статья оторвана от реальности.
Начало вроде многообещающее — хорошая затравка про ниши, где scala хороша. И почти нет реакции на то, что стало с ней сейчас, причем в комментах к оригиналу это подметили.

Spark застрял со старой версией (всем миром ему помогали на 2.12 выкатываться), некоторые библиотеки еще не смогли (например, elasticsearch-hadoop). Ну и как выше писали в комментах, мигрировать не очень просто. И все больше скалу в спарке вытесняет питон.

Из ниши «better java» скалу со свистом вышвырнул котлин — а в статье про него ноль упоминаний. И у того же котлина уже есть плюс-минус рабочее решение с js и native. У скалы вроде как тоже, но котлин в этих направлениях развивается гораздо активнее. Scala-js по маргинальности примерно одинакова с хаскеллем на фронте. Native там же примерно. Да и graalvm тоже маячит.

Akka уже теснят всякие корутины и project loom. Реактивным программированием сейчас тоже никого не удивишь.

Dotty вроде как дает надежду и уже почти готов, но опять же в статье про него тоже ни слова.

Ожидал от статьи какого-то обоснованного позитива и подсветку направлений, где скала сильна и имеет хорошие перспективы. Но в статье этого нет. Такое ощущение, что скоро скала останется в банках, легаси и у маргиналов.

Если упростить, то да. Уточню, что тут отправка идет не через бота, а через основной аккаунт (как будто бы это был клиент), и надо сделать пару дополнительных обработок, но это не очень существенно.

Насчет проверки моего примера — согласен, я ошибся, и думал, что балансируется по весу, а не по высоте на его основе. Меня не покидало ощущение, что что-то не так: вроде у вас похожее с АВЛ-деревом условие (высоты левого и правого деревьев отличаются не более чем на единицу), но при этом у вас только 1 поворот на операцию, а в АВЛ их может быть два.
Вот пример: {8, 4, 30, 2, 6, 10, 36, 9, 12,38, 13, 14, 15 };
https://ideone.com/recc7a
При его последовательной вставке в ваше дерево получится справа высота два, слева — 5. Явно нарушается ваш предполагаемый инвариант про баланс высот. Хотелось бы иметь формальное доказательство, что у вас там действительно логарифмическая высота — не факт, что найденый мой пример делает самый худший дизбаланс, наверняка можно похуже найти.

Насчет удаления — не согласен. У вас же после 1 поворота идет выход из цикла, значит при вставке отбалансируется только самый нижний кусочек.

При удалении тоже надо балансировать, иначе можно поудалять листья таким образом, что дерево будет иметь линейную высоту.
Кроме того, попробуйте вставить в ваше дерево последовательно числа от 1 до 1000 — если я правильно понял ваш код, то высота в вашем дереве будет в районе 250 вместо ожидаемой 10-20

Если у вас не сбалансированное ДДП, то тогда и сложности операций у вас будут в худшем случае линейные (в среднем все равно логарифмические).

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

У меня какое-то дежавю.
https://habr.com/ru/post/479142/
Повторю свой комментарий оттуда — чем ваша идея отличается от дерева порядковой статистики, которое давным-давно описано в Кормене?

А как в итоге правильно разрулить ситуацию из "Дайте возможность сохранить лицо"?

Еще в Кормене описано подобное как дерево порядковой статистики.
https://books.google.ru/books?id=UVg1LPacgRcC&pg=PA366&lpg=PA366&dq=дерево+порядковой+статистики&source=bl&ots=_VcQMlhYFC&sig=ACfU3U2jkcg12kdbh8ql4p9_S4f4iCmTrw&hl=ru&sa=X&ved=2ahUKEwjHuImmhqnmAhWlw8QBHTrHDNAQ6AEwBnoECAoQAQ#v=onepage&q=дерево%20порядковой%20статистики&f=false
Чем ваше решение отличается?

Зависит от языка? В той же scala у всех есть equals(). Может имеется ввиду не равный, а идентичный (та же ссылка)?

Embrace, extend and extinguish

https://en.wikipedia.org/wiki/Formula_for_primes

Тема интересная, но хотелось бы увидеть сравнение с другими системами сообщений — например, кафкой или rabbitmq

Интересная идея.
Как определяется http-ссылка на "оригинал"?
Что будет, если дистрибутив/пакет экзотический и его нигде нет?
Что будет, если ссылки на оригинал протухнут?

Это далеко не свежая идея https://rg.ru/2017/06/07/v-moskve-nashli-avtomat-dlia-nakrutki-lajkov-i-podpischikov.html
А в Китае фермы для накруток держат уже несколько лет

Кажется, ваш reducer — это просто функтор. А сама идея — обычный конечный автомат, он же FSM.