• Мониторинг бизнес-процессов Camunda
    0

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

  • AMA с Хабром #23. Чёрная пятница в Хабр Киоске
    +1

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


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

  • Путь от вычислительной машины к машине координационной
    +4

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

  • Как я искал пацанский движок для блога
    0

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

  • Выбор библиотеки ассертов для проекта на Kotlin
    +1

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


    Скриншот

    image


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


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


    Скриншот

    image


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

  • Выбор библиотеки ассертов для проекта на Kotlin
    +1

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

  • Выбор библиотеки ассертов для проекта на Kotlin
    0

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


    Скриншот

    image

  • Выбор библиотеки ассертов для проекта на Kotlin
    0

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

  • 7 достойных курсов по изучению Git и Github
    +1

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

  • Сортировка выворачиванием
    +1

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

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

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


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

  • Как я искал пацанский движок для блога
    0

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

  • Собеседования в разработку: друзей выбирают
    +1

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

  • Эффективный поиск информации в работе
    0

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

  • Собеседования в разработку: друзей выбирают
    0

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


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

  • Собеседования в разработку: друзей выбирают
    0

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


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


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

  • Собеседования в разработку: друзей выбирают
    +1

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


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


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

  • Конец хайпа: Что ждёт язык Scala дальше
    0

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

  • Конец хайпа: Что ждёт язык Scala дальше
    0

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


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

  • Конец хайпа: Что ждёт язык Scala дальше
    0

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

  • Конец хайпа: Что ждёт язык Scala дальше
    0

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

  • Конец хайпа: Что ждёт язык Scala дальше
    0

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

  • Конец хайпа: Что ждёт язык Scala дальше
    0

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


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

  • Конец хайпа: Что ждёт язык Scala дальше
    –1

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

  • Конец хайпа: Что ждёт язык Scala дальше
    +4

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


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


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


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


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


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

  • Как убить на мелкий скрипт кучу времени или история одного пулл-реквеста
    0

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

  • Индексируемое бинарное дерево
    0

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


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

  • Индексируемое бинарное дерево
    0

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

  • Индексируемое бинарное дерево
    0

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

  • Программист-фанатик. Конспект часть 3 + конспект-таблица. Планирование и камешек в ведре воды
    +2

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

  • Индексируемое бинарное дерево
    0

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

  • Как китайские стратагемы помогают в работе
    +1

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

  • Как получить по индексу элемент из бинарного дерева за приемлемое время?
  • Функциональное программирование — это не то, что нам рассказывают
    0

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

  • Microsoft создаёт новый язык программирования, основанный на Rust
    0

    Embrace, extend and extinguish

  • Формула расчёта простых чисел и оптимизация перебора делителей
  • Redis Stream — надёжность и масштабируемость ваших систем сообщений
    +1

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

  • Сократить бэкапы на 99.5% с hashget
    +1

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

  • Бельгиец создал автомат для продажи лайков и подписчиков
    +1

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

  • Как работать со множественными запросами. Композиция, Reducer, ФП
    +2

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