• Почему следует избегать использования JPA/Hibernate в продакшене
    0
    Основной недостаток JPA в том, что разработчики не хотят его осваивать )).

    Допустим, передо мной выбор: изучить JDBCTemplate, Jooq или JPA. Почему я должен инвестировать свое время именно в JPA?

  • Почему следует избегать использования JPA/Hibernate в продакшене
    –5

    Спасибо за статью! Я думаю, очень многие и так разделяют негативное отношение к хиберу, но здесь оно изложено последовательно и систематично, и это хорошо.


    Возможно истинная философия JPA какая-то другая (не могу нагуглить)

    Вы передали все верно. Этот анти-паттерн называется "active record".

  • Oracle против Google: Верховный суд принял сторону Google в споре об авторских правах
    +11
    суд проводит несостоятельное различие между реализуемым кодексом (который был признан охраняемым авторским правом в предыдущем постановлении) и его объявлением

    Оставляли бы хоть ссылку на оригинал, раз сами не можете перевести.

  • Spring Boot приложение в Kubernetes с Postgresql и Loki
    0

    Дополнение с элементом пиара: если не хочется ставить promtail на машины, можно слать логи из джавы напрямую, используя, например, loki-logback-appender.

  • Доказательное программирование
    +2

    Да примерно такое же, как и ООП, когда там нельзя даже вызывать методы у примитивных типов.


    Докопаться можно до всего при желании.

  • Доказательное программирование
    +12

    Мне кажется, если бы человека года так с 2007 по 2021 держали в плену и заставляли писать на Java 1.6 и EJB, то после освобождения и знакомства с современными концепциями и языками программирования, разорванный шаблон должен был бы породить текст как раз вроде этого.


    Вроде бы уже прошло достаточно времени (7 лет с релиза восьмерки), чтобы даже самые отъявленные ретрограды поняли, в какую именно сторону развивается Java как язык, и поубавили градус хейта в сторону ФП.

  • Большой разговор с новым Kotlin Project Lead Романом Елизаровым
    0

    100 человек — это все только сотрудники JB или независимые контрибьюторы тоже?

  • РКН замедляет Twitter
    0

    Думаю, компании, получающие основную прибыль на международных рынках и зависимые от международной инфраструктуры (github, aws, gcp и т.д.), будут активнее двигаться в сторону эвакуации спецов в более вменяемые юрисдикции. Какие-то российские IT-стартапы в будущем мы вряд ли увидим.


    IT-конторы, которые обслуживают госов, будут видимо еще активнее переползать на внутреннюю инфраструктуру и пытаться зеркалить сервисы, необходимые для более-менее сносной разработки (типа dockerhub, npm или maven central).

  • Viomi SE: «Покофон» из мира роботов-пылесосов
    +5
    Хабы: Высокая производительность, Алгоритмы

    Серьезно?

  • Мощный мониторинг за пять минут с помощью Glances
    +10

    Ничего не имею против Glances, но мотивационная часть статьи


    отброшены вместе с чрезмерно усложнёнными корпоративными хреновинами вроде Prometheus и RabbitMQ

    особенно с последующим


    Нас, конечно, интересует InfluxDB и последующий вывод из неё в графану.

    намекает как минимум на некоторую предвзятость автора.


    Возможно, node_exporter + prometheus + grafana было бы даже проще в конфигурации для вашего случая. И это вполне легковесное решение, причем на одном техстеке с гарантировано бесшовной интеграцией. Почему же вы называете это "усложнёнными корпоративными хреновинами", особенно по сравнению с glances + influxdb + grafana?

  • В открытом доступе опубликованы 40 самых важных научно-популярных книг на русском языке
    +3
    Увы, чтобы критиковать, необязательно обладать таким же послужным списком, достаточно иметь грамотные аргументы

    Вот вы вроде раскритиковали Панчина, Докинза и Хокига. Хотелось бы теперь увидеть те самые "грамотные аргументы", желательно по пунктам, чтобы легче было воспринимать.

  • Наука и рациональность на YouTube (авторские плейлисты)
    0

    https://www.youtube.com/channel/UCGk5wyYgpGKuu5Wkjg0WIzQ/videos — Сергей Попов, лекции по астрофизике. Есть как популярные, так и более академические (с формулами)

  • Как мы переходили на Java 15 или история одного бага в jvm длиной в 6 лет
    0
    HttpClient на NIO (11) — а разве это нельзя реализовать самому?

    Можно, но довольно трудозатратно. Да и зачем, если вот он уже написан. Через несколько лет, он уже будет в каждом утюге, но конкретно сегодня 30-40% людей все еще сидят на 8, к сожалению.


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

    Это же не просто костыли, это тормозные костыли. Локи вместо CAS, массивы байтов в хипе вместо direct buffers.

  • Как мы переходили на Java 15 или история одного бага в jvm длиной в 6 лет
    0

    Ну джава, к счастью, не заканчивается на хадупе. Те, кто держит большие флоты в облаках для работы своих 24/7 сервисов, будут рады каждому сэкономленному метру памяти и каждой миллисекунде уменьшающегося latency. В зависимисти от масштаба, разница в стоимости виртуального железа на месяц или год может многократно покрыть стоимость перехода, который делается один раз и не очень долго.


    Вот прям если не лень — можете мне назвать список фич, которые были внедрены с Java 8

    Могу перечислить то, из-за отсутствия чего лично я вынужден придумывать многоэтажные костыли уже несколько месяцев: VarHandles (9), нормальный HttpClient на NIO (11), absolute bulk read/write для ByteBuffer (14).

  • Как мы переходили на Java 15 или история одного бага в jvm длиной в 6 лет
    +1

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

  • Сражение Linux на поприще Windows
    +3

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

  • Сражение Linux на поприще Windows
    +2

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


    Просто дайте себе отчет в том, что когда-то вы инвестировали довольно много времени, чтобы научиться что-то делать в винде. Почему в линуксе вы ожидаете мгновенного результата?

  • Manticore Search — форк Sphinx: отчёт за 3 года
    +1

    Спасибо за такой подробный и исчерпывающий ответ!

  • Manticore Search — форк Sphinx: отчёт за 3 года
    +1
    Всё это позволит писать данные в Manticore Search вместо Elasticsearch из Logstash, Fluentd, Beats и им подобных.

    Возможно, тут как раз подходящее место, чтобы задать вопрос, который мучает меня довольно долго. Зачем нужно складывать логи приложений в системы полнотекстового поиска? Лично мне очень сложно представить себе реальный пример, когда для поиска по логам нужно что-то сложнее grep или его микросервис-аналога типа Grafana Loki.

  • Как законтрибьютить в опенсорс, чтобы не сгореть со стыда
    0
    С недавних пор на GitHub появилась программа GitHub Sponsorship: на страничку любого человека или проекта можно зайти, и там будет кнопка спонсорства.

    Тут надо уточнить, что получать деньги в Россию и страны СНГ через GitHub (пока еще?) нельзя.

  • Java Optional не такой уж очевидный
    +1

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


    И да, как я уже указал, Optional вам при первом же чтении даст корректный NPE в рантайме. Потому что контракт, что все поля инициализированные, а необязательные — empty. Если мы ожидаем, что поле инициализировано, а оно оказалось null, NPE — это ровно то, что и должно произойти.


    С @Nullable вы давите NPE (что вообще говоря не самоцель), но лишаетесь возможности различить ситуацию неинициализированно по ошибке / необязательно без значения, потому что и то и другое в этом случае — null.

  • Java Optional не такой уж очевидный
    0
    Не понял.

    Поясню на примере:


    class B {
      @Nullable
      public A field_a_a;
      @Nullable
      public A fielda_a_;
      @Nullable
      public A fielda_aa;
      @Nullable
      public A fieldaa_a;
    }
    class MyAbstractBlaBlaBlaBuilder {
      public B build() {
        var b = new B();
        b.field_a_a = field_a_a;
        b.fielda_a_ = fielda_a_;
        b.fieldaa_a = fielda_aa;
        b.fieldaa_a = fieldaa_a;
        return b;
      }
    }

    Если бы вместо @Nullable был Optional — вы бы на первом запуске отловили NPE. С @Nullable такая фигня может оставаться незамеченной довольно долго.


    в отличие например от Option в Scala

    В Scala с этим так же, как и в Java, разве что с линтерами получше.


    Они там и не нужны — IDE автоматически выводит nullability из контрактов над методами или самого кода.

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

  • Java Optional не такой уж очевидный
    0

    Начиная с Java 9 ваш пример можно записать чуть более приятным образом с помощью ifPresentOrElse (и тут меня опередил комментатор выше). Конечно, для тех, кто привык к императивному коду, это будет менее читаемо, чем явный if. И в целом соглашусь, что Optional в императивном коде выглядит чужеродно.


    С использованием nullable-аннотаций, на мой взгляд, есть несколько проблем:


    1. нельзя отличить неинициализированное по ошибке поле от необязательного без значения
    2. аннотации для локальных переменных выглядят сильно хуже, чем Optional
    3. для null нет никаких средств композиции, для Optional есть flatMap
    4. здесь был бы рад ошибиться, но вроде для Java нет какого-то стандартного статического анализатора nullable-аннотаций, чтобы можно было запускать на CI, например
  • Java Optional не такой уж очевидный
    +1

    Справедливости ради, if постоянно не надо писать. Можно: foo.map(f -> f.bar).map(b -> b.baz).

  • Почему в InVision затаскивают микросервисы обратно в монолит
    0

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

  • Новая версия нашего самописного плагина, который скачали 250 тысяч раз
    0

    Это очень круто, поздравляю!


    Графана делает много крутых компонентов для мониторинга, которые вдохновляют. Я вот тоже не так давно настолько протащился от их системы централизованного сбора логов Loki, что начал делать свой первый серьезный open-source проект Logback appender, чтобы облегчить интеграцию Java-приложений с Loki. Цифры пока конечно скромнее, около 100 уникальных скачиваний за 2 месяца. Но я верю, что Loki наберет популярность в Java-комьюнити и хорошенько потеснит ELK, в том числе благодаря моему проекту :)

  • Почему в InVision затаскивают микросервисы обратно в монолит
    +2

    Попробую резюмировать.


    Избранная группа инженеров начала разбивать приложения на части, которые, по их мнению, соответствовали границам ответственности команд. Это было сделано для того, чтобы команды могли работать более независимо, деплоить независимо и повысить свою продуктивность.

    Изначально был выбран неверный критерий разбивки монолита на микросервисы. Сам автор это признает.


    По мере миграции команд на современную платформу сервисы, за которые отвечали эти команды, приходится передавать остающимся legacy-командам.

    Не самый рациональный подход к миграции, когда не во время, а уже после после перехода на новую платформу надо все равно поддерживать старую.


    Микросервисы — это не «микро». У них «правильный размер»

    К чему это словоблудие про "правильный размер"? Неужели реально где-то есть взрослые люди, которые воспринимают технические термины буквально?


    большинству технологий не требуется «независимое масштабирование»

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


    Вот и весь рассказ. История одного конкретно взятого провала проектирования архитектуры и тех, кто за это отвечал. Зачем лить столько "воды" про Таноса и гордость за команду? Мне кажется, вместо Таноса тут больше бы подошла отсылка к фильму "Идиократия".

  • Еще раз про try и Try
    0

    Ну да, про это как раз был мой первоначальный комментарий. Try просто класс, который все равно откуда придет, — это так только на прикладном уровне. На библиотечном уровне вы не будете подключать все подряд с целью минимизации зависимостей (и как следствие проблем у юзеров вашей библиотеки), поэтому там стандартная поставка имеет большое значение.

  • Еще раз про try и Try
    0

    Хм… а я вот как-то стал очень разборчивым после всех этих депендеси хеллов в спарко-хадупе и прочих замечательных фрейморках, которые не могут без того, чтобы скачать пару гигабайт из мейвен централа, а потом на старте навернуться с чем-нибудь типа NoSuchMethodError. Лучше я возьму десять утилитарных zero-dependency либ, с каждой из которых легко разобраться в отдельности, чем одного огромного монстра, с котором непонятно что делать.

  • Еще раз про try и Try
    0

    Очевидно же почему: чтобы не навязывать пользователю вашей библиотеки нерелевантных решений и чтобы избежать jar hell.


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


    Понятно, что если у вас в описании к библиотеке написано, что она про FP и fault tolerance в Java, тащить vavr логично. Но я же говорю про библиотеки в общем случае.

  • Еще раз про try и Try
    +1
    Так что Scala в этом месте от Java почти не отличается.

    Если вы автор библиотеки, например, вы скорее всего не будете тащить внешнюю зависимость от vavr или чего-то подобного. Соответственно, весь ваш арсенал будет ограничен тем, что есть в стандартном наборе. Так что отличия есть, и они весьма существенны.

  • Scala 3: избавление от implicit. Тайпклассы
    0

    Вряд ли выход Scala 3 привлечет этих людей обратно. Пока все выглядит так, что разработчики языка решили отойти и не конкурировать с котлином за нишу better java.

  • Scala 3: избавление от implicit. Тайпклассы
    +2

    Примеры же просто демонстрируют новый синтаксис. Моноид, я думаю, выбрали потому, что удобно показывать разницу между методом, привязанным к типу (unit), и методом, привязанным к экземпляру (combine).


    Если вас интересует какой-нибудь сравнительно простой пример прикладного использования тайпклассов, и при этом аллергия на теорию категорий, я бы рекомендовал посмотреть сюда. Это очень простая библиотека для чтения конфигов. В качестве упражнения, можно попробовать сделать такую же функциональность на "классическом ООП" без тайпклассов.

  • Scala 3: избавление от implicit. Extension-методы и неявные преобразования
    +1

    Хм… было бы интересно узнать, какие еще есть опции. Вот хочу я сделать библиотеку для сериализации JSON. Естественно, пользователи этой библиотеки могут захотеть сериализовать любой класс, который у них есть. Какие у меня есть варианты кроме наследования/рефлексии/оберток с одной стороны и тайпклассов с другой?

  • Scala 3: избавление от implicit. Extension-методы и неявные преобразования
    0
    implicit, который позиционируется как некие type class

    Следующая статья как раз будет про тайпклассы в Scala 3. Stay tuned!


    implicit поведение это всегда зло

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

  • Scala 3: избавление от implicit. Extension-методы и неявные преобразования
    +1
  • Вам не нужны юнит-тесты
    0
    Но ответственность за эти ошибки плавно перекочевала с плеч разработчиков на плечи тестировщиков. Как-никак, это они назвали себя Quality Assurance – а раз проводишь проверку качества, делай это качественно

    Вот это мне особенно понравилось! Реально ведь встречаются люди, которые так думают.

  • Scala 3: новый, но необязательный синтаксис
    0
    Теперь нужно сосредотачиваться на этих end, читать их (а вдруг там не end?), тогда как скобки обычно просто воспринимаются в фоне.

    Справедливости ради, по гайдлайну этот пример на картинке нужно переписать как-то так:


    package newsyntax:
    
        abstract class C():
    
            def this(x: Int) =
                this()
                if x > 0 then
                    var y = x
                    while y > 0 do
                        println(y)
                        y -= 1
                else
                    x match
                        case 0 => println("0")
                        case _ =>
    
        end C
    end newsyntax

    Это и компактнее и, имхо, читабельнее. На картинке сделано с кучей end просто для понимания соответствия старого кода и нового.

  • Scala 3: новый, но необязательный синтаксис
    0

    Вроде бы есть попытка пофиксить это. Но у меня не завелось. Возможно, в M2, на которой я тестил, этого еще не было.

  • Scala 3: новый, но необязательный синтаксис
    0

    На данный момент на последний вопрос ответило 25 человек. Это, конечно, сложно назвать репрезентативной выборкой, но то, что количество людей, писавших до Scala на Python и Haskell в сумме больше, чем на Java — для меня сюрприз. Возможно, Одерски не так уж неправ, вводя этот новый синтаксис.