На хабре как раз считается хорошим тоном аргументированный диспут, коих тут валом. А вот субъективные необоснованные агрессивные хамские выпады редко встречают всеобщее одобрение.
Давайте проверим эту гипотезу на примере прямо этой самой ветки комментариев.
Сначала следует "субъективный необоснованный агрессивный хамский выпад" с рейтингом -19:
защитники Столлмана, так и не поняв смысла открытого письма, всё ещё собирают подписи, как будто это что-то меняет
А дальше начинается "аргументированный диспут, коих тут валом" с рейтингом +7:
оскорбленная за других феменистка, которая на хабре появилась ради рассказов про цисгендерных угнетателей, вздумавших пасть раскрыть, и сюда придёт рассказывать про то, какие сторонники Столлмана дураки
Ну и в обратную сторону. Попробуем угадать рейтинг комментария со следующими фразами:
шестипроцентных клоунов… когда их закидали ссаными тряпками… обиженные снежинки
Да, совершенно верно, ни одной необоснованной субьективной оценки, +17.
Получается что да, на хабре все работает ровно так, как вы и написали.
Зачем? Да хотя бы ради той самой научной честности, которая декларируется в начале статьи. Хотите занимать стороны и подгонять решение под ответ — я не против, но не пишите о научности тогда.
Я имел ввиду, что, если автор не заметил даже той очевидной проблемы со статистикой, на которую я указал выше, можно ли надеяться, что все остальное в его логике рассуждений верно. Претензия же была не к коду, а к непонимаю предметной области.
Но вообще да, было бы интересно перезапустить все рассчеты, взяв только промежуток до 1 апреля, и посмотреть, устоят ли остальные выводы.
Да, к 1 апреля они уже очевидно проигрывали по коммитам. Но автор пишет в своем выводе (который я и процитировал) не об этом. Он пишет "коммитов в репозиторий противников за последнее время практически не было". А откуда им взяться, если они уже месяц не принимают подписи? И график у него не до 1 апреля, когда сравнивать было еще корректно. Это же явная манипуляция статистикой. Не очень хорошо такое допускать, особенно после раздела "Замечание о научной честности".
Видно, что репозиторий сторонников гораздо активнее. Коммитов в репозиторий противников за последнее время практически не было. Репозиторий сторонников продолжает обновляться.
Странно, у вас хватило сил собрать статистику по звездам и коммитам, но почему-то не хватило прочитать первую строчку README к репозиторию противников, которая еще и выделена жирным к тому же:
As of April 1, 2021 00:00 UTC we are no longer accepting signatures.
Я сейчас не обсуждаю, кто прав и кто виноват в истории со Столлманом. Я лишь говорю, что в погоне за "правильными" выводами, вы сравнили яблоки с апельсинами и не заметили этого как минимум в одном месте. Можно ли доверять остальным выводам в вашей статье, или они так же притянуты за уши — вопрос.
Спасибо за статью! Я думаю, очень многие и так разделяют негативное отношение к хиберу, но здесь оно изложено последовательно и систематично, и это хорошо.
Возможно истинная философия JPA какая-то другая (не могу нагуглить)
Вы передали все верно. Этот анти-паттерн называется "active record".
суд проводит несостоятельное различие между реализуемым кодексом (который был признан охраняемым авторским правом в предыдущем постановлении) и его объявлением
Оставляли бы хоть ссылку на оригинал, раз сами не можете перевести.
Дополнение с элементом пиара: если не хочется ставить promtail на машины, можно слать логи из джавы напрямую, используя, например, loki-logback-appender.
Мне кажется, если бы человека года так с 2007 по 2021 держали в плену и заставляли писать на Java 1.6 и EJB, то после освобождения и знакомства с современными концепциями и языками программирования, разорванный шаблон должен был бы породить текст как раз вроде этого.
Вроде бы уже прошло достаточно времени (7 лет с релиза восьмерки), чтобы даже самые отъявленные ретрограды поняли, в какую именно сторону развивается Java как язык, и поубавили градус хейта в сторону ФП.
Думаю, компании, получающие основную прибыль на международных рынках и зависимые от международной инфраструктуры (github, aws, gcp и т.д.), будут активнее двигаться в сторону эвакуации спецов в более вменяемые юрисдикции. Какие-то российские IT-стартапы в будущем мы вряд ли увидим.
IT-конторы, которые обслуживают госов, будут видимо еще активнее переползать на внутреннюю инфраструктуру и пытаться зеркалить сервисы, необходимые для более-менее сносной разработки (типа dockerhub, npm или maven central).
Ничего не имею против Glances, но мотивационная часть статьи
отброшены вместе с чрезмерно усложнёнными корпоративными хреновинами вроде Prometheus и RabbitMQ
особенно с последующим
Нас, конечно, интересует InfluxDB и последующий вывод из неё в графану.
намекает как минимум на некоторую предвзятость автора.
Возможно, node_exporter + prometheus + grafana было бы даже проще в конфигурации для вашего случая. И это вполне легковесное решение, причем на одном техстеке с гарантировано бесшовной интеграцией. Почему же вы называете это "усложнёнными корпоративными хреновинами", особенно по сравнению с glances + influxdb + grafana?
Увы, чтобы критиковать, необязательно обладать таким же послужным списком, достаточно иметь грамотные аргументы
Вот вы вроде раскритиковали Панчина, Докинза и Хокига. Хотелось бы теперь увидеть те самые "грамотные аргументы", желательно по пунктам, чтобы легче было воспринимать.
HttpClient на NIO (11) — а разве это нельзя реализовать самому?
Можно, но довольно трудозатратно. Да и зачем, если вот он уже написан. Через несколько лет, он уже будет в каждом утюге, но конкретно сегодня 30-40% людей все еще сидят на 8, к сожалению.
Ну в смысле — костыли это понятно, неохота, но если они возможны — то это вполне может быть дешевле миграции.
Это же не просто костыли, это тормозные костыли. Локи вместо CAS, массивы байтов в хипе вместо direct buffers.
Ну джава, к счастью, не заканчивается на хадупе. Те, кто держит большие флоты в облаках для работы своих 24/7 сервисов, будут рады каждому сэкономленному метру памяти и каждой миллисекунде уменьшающегося latency. В зависимисти от масштаба, разница в стоимости виртуального железа на месяц или год может многократно покрыть стоимость перехода, который делается один раз и не очень долго.
Вот прям если не лень — можете мне назвать список фич, которые были внедрены с Java 8
Могу перечислить то, из-за отсутствия чего лично я вынужден придумывать многоэтажные костыли уже несколько месяцев: VarHandles (9), нормальный HttpClient на NIO (11), absolute bulk read/write для ByteBuffer (14).
Давайте проверим эту гипотезу на примере прямо этой самой ветки комментариев.
Сначала следует "субъективный необоснованный агрессивный хамский выпад" с рейтингом -19:
А дальше начинается "аргументированный диспут, коих тут валом" с рейтингом +7:
Ну и в обратную сторону. Попробуем угадать рейтинг комментария со следующими фразами:
Да, совершенно верно, ни одной необоснованной субьективной оценки, +17.
Получается что да, на хабре все работает ровно так, как вы и написали.
Зачем? Да хотя бы ради той самой научной честности, которая декларируется в начале статьи. Хотите занимать стороны и подгонять решение под ответ — я не против, но не пишите о научности тогда.
Я имел ввиду, что, если автор не заметил даже той очевидной проблемы со статистикой, на которую я указал выше, можно ли надеяться, что все остальное в его логике рассуждений верно. Претензия же была не к коду, а к непонимаю предметной области.
Но вообще да, было бы интересно перезапустить все рассчеты, взяв только промежуток до 1 апреля, и посмотреть, устоят ли остальные выводы.
Да, к 1 апреля они уже очевидно проигрывали по коммитам. Но автор пишет в своем выводе (который я и процитировал) не об этом. Он пишет "коммитов в репозиторий противников за последнее время практически не было". А откуда им взяться, если они уже месяц не принимают подписи? И график у него не до 1 апреля, когда сравнивать было еще корректно. Это же явная манипуляция статистикой. Не очень хорошо такое допускать, особенно после раздела "Замечание о научной честности".
Странно, у вас хватило сил собрать статистику по звездам и коммитам, но почему-то не хватило прочитать первую строчку README к репозиторию противников, которая еще и выделена жирным к тому же:
Я сейчас не обсуждаю, кто прав и кто виноват в истории со Столлманом. Я лишь говорю, что в погоне за "правильными" выводами, вы сравнили яблоки с апельсинами и не заметили этого как минимум в одном месте. Можно ли доверять остальным выводам в вашей статье, или они так же притянуты за уши — вопрос.
Описанный вами механизм вполне жизнеспособен, он уже более 6 лет используется для распределенной обработки данных в Apache Spark, например.
Допустим, передо мной выбор: изучить JDBCTemplate, Jooq или JPA. Почему я должен инвестировать свое время именно в JPA?
Спасибо за статью! Я думаю, очень многие и так разделяют негативное отношение к хиберу, но здесь оно изложено последовательно и систематично, и это хорошо.
Вы передали все верно. Этот анти-паттерн называется "active record".
Оставляли бы хоть ссылку на оригинал, раз сами не можете перевести.
Дополнение с элементом пиара: если не хочется ставить promtail на машины, можно слать логи из джавы напрямую, используя, например, loki-logback-appender.
Да примерно такое же, как и ООП, когда там нельзя даже вызывать методы у примитивных типов.
Докопаться можно до всего при желании.
Мне кажется, если бы человека года так с 2007 по 2021 держали в плену и заставляли писать на Java 1.6 и EJB, то после освобождения и знакомства с современными концепциями и языками программирования, разорванный шаблон должен был бы породить текст как раз вроде этого.
Вроде бы уже прошло достаточно времени (7 лет с релиза восьмерки), чтобы даже самые отъявленные ретрограды поняли, в какую именно сторону развивается Java как язык, и поубавили градус хейта в сторону ФП.
100 человек — это все только сотрудники JB или независимые контрибьюторы тоже?
Думаю, компании, получающие основную прибыль на международных рынках и зависимые от международной инфраструктуры (github, aws, gcp и т.д.), будут активнее двигаться в сторону эвакуации спецов в более вменяемые юрисдикции. Какие-то российские IT-стартапы в будущем мы вряд ли увидим.
IT-конторы, которые обслуживают госов, будут видимо еще активнее переползать на внутреннюю инфраструктуру и пытаться зеркалить сервисы, необходимые для более-менее сносной разработки (типа dockerhub, npm или maven central).
Серьезно?
Ничего не имею против Glances, но мотивационная часть статьи
особенно с последующим
намекает как минимум на некоторую предвзятость автора.
Возможно, node_exporter + prometheus + grafana было бы даже проще в конфигурации для вашего случая. И это вполне легковесное решение, причем на одном техстеке с гарантировано бесшовной интеграцией. Почему же вы называете это "усложнёнными корпоративными хреновинами", особенно по сравнению с glances + influxdb + grafana?
Вот вы вроде раскритиковали Панчина, Докинза и Хокига. Хотелось бы теперь увидеть те самые "грамотные аргументы", желательно по пунктам, чтобы легче было воспринимать.
https://www.youtube.com/channel/UCGk5wyYgpGKuu5Wkjg0WIzQ/videos — Сергей Попов, лекции по астрофизике. Есть как популярные, так и более академические (с формулами)
Можно, но довольно трудозатратно. Да и зачем, если вот он уже написан. Через несколько лет, он уже будет в каждом утюге, но конкретно сегодня 30-40% людей все еще сидят на 8, к сожалению.
Это же не просто костыли, это тормозные костыли. Локи вместо CAS, массивы байтов в хипе вместо direct buffers.
Ну джава, к счастью, не заканчивается на хадупе. Те, кто держит большие флоты в облаках для работы своих 24/7 сервисов, будут рады каждому сэкономленному метру памяти и каждой миллисекунде уменьшающегося latency. В зависимисти от масштаба, разница в стоимости виртуального железа на месяц или год может многократно покрыть стоимость перехода, который делается один раз и не очень долго.
Могу перечислить то, из-за отсутствия чего лично я вынужден придумывать многоэтажные костыли уже несколько месяцев: VarHandles (9), нормальный HttpClient на NIO (11), absolute bulk read/write для ByteBuffer (14).