• Неизменяемых коллекций в Java не будет – ни сейчас, ни когда-либо
    0
    Все написано правильно. Но говоря по прикладном программировании я очень настороженно отношусь к реализации своих надстроек над стандартными классами. Причин тут несколько
    1. Через 4 года, когда создатель этой надстройки окэшит опцион и пойдет работать в другую компанию — пришедшему программисту достанется еще одна загадка виде «зачем это все придуманно?». Статью на хабе он гарантированно не прочитает и будет использовать фичу как Бог на душу положит
    2. Надстройка гарантированно не будет применяться консистентно в течении времени жизни проекта, что добавить +1 к запутанности проекта.
    3. Имутабельность списков важна, и минимизация контрактов между методами и классами тоже крайне важна. Но часто компактный и простой код, который можно легко изменить значительно важнее. Т.е. если можно сделать код в 3 раза меньше за счет использования bare Java + одной/двух абсолютно стандартных библиотек, то я предпочту меньше кода.

    UPD В текущем проекте вижу библиотечный класс FastByteArray2 созданный в 2004 году — все никак не соберусь с духом заглянуть, что внутри
  • Десктоп мертв, да здравствует десктоп! Собираю хабрастатистику
    +1
    На работе ноутбук + докстанция, выбрал бы десктоп. но надо ездить в командировки. Дома десктоп сам собирал, те готовые которые есть на рынке мне не подходили, либо слабые, либо перекошенная в сторону понтов, а не эффективности конфигурация.
  • Семь «абсолютных истин» джуниора, от которых пришлось отучиваться
    +4
    На редкость толковые наблюдения. Не уверен, что в виде статьи много людей это осознают. К сожалению такие вещи доходят преимущественно с опытом.
  • Всегда ли нужны Docker, микросервисы и реактивное программирование?
    +1
    Сложно не согласиться, к сожалению анти хай не приносит прибыли. Я пробовал писать анти хайповые статьи. Они никому не интересны. А на хайпе многие не очень хорошие вещи бодро выезжают. Увы
  • Когда чтение можно потрогать: обзор ONYX BOOX Monte Cristo 4
    0
    Спасибо, хороший обзор, как раз хочу такую книгу купить, обзор был очень полезным
  • Всегда ли нужны Docker, микросервисы и реактивное программирование?
    +1
    Поддержка сторонним разработчиком это не всегда плюс увы. Но основная проблема с библиотеками они очень редко делают _ровно_ то что вам надо и _ровно_ так как вам надо. И вы вынужденны втаскивать в абстракцию своей системы абстракцию библиотеки. Если вы из нее используете один статичный метод UtilClass.doSomething() — это не проблема, но так бывает редко.
    По поводу времени запуска — смешно совпало — буквально сегодня у меня был достаточно жаркий спор как раз про время запуска. Коллега жаловался на слишком долгий старт.
  • Архитектурный шаблон “Macro Shared Transactions for Microservices”
    0
    Я постарался описать эту проблему. В реальных архитектурах такая проблема есть. Есть ее решения. Но про это мало рассказывают евангелисты микросервисов. «В кишках» там бывает много разных, часть не очень красивых моментов.
  • Архитектурный шаблон “Macro Shared Transactions for Microservices”
    0
    Очередь как ни странно очень легко сделать не падающей. Кластер или вообще PubSub например.
  • Архитектурный шаблон “Macro Shared Transactions for Microservices”
    0
    >>А под капотом у БД происходит не примерно то же самое?
    ну БД под капотом устроена все же несколько иначе. Я не уверен насколько тут уместно проводит параллели, разве что на очень-очень высоком уровне. БД все же скорее императивна.
    >>а разве идея с перекидываем подключения что-то даст по стравнению с моноллитным приложением?
    На самом деле преимущества есть и достаточно ощутимые. Это
    1. разделение цикла разработки, релизов и т.д.
    2. разделение кода на меньшие и значит более понятные куски
    3. разделение абстракций моделирования см bounded models — не надо натягивать абстракцию на весь домен — можно ограничиться его частью.

    Список не полон. Добавлю только, что разделение данных на разные БД это далеко не самое главное преимущество микросервисов.
  • Архитектурный шаблон “Macro Shared Transactions for Microservices”
    0
    Можно, но в чем смысл такой статьи? Хочется что-то интересное придумать и поделиться. Из возраста собирания плюсов я пожалуй уже вырос.
  • Архитектурный шаблон “Macro Shared Transactions for Microservices”
    0
    Ну один из случаев. Проблема то не на пустом месте.
  • Дизайн классов: что такое хорошо?
    0
    Согласен, но нельзя сбрасывать со счетов различия субкультур. Так получилось, что у нас с начальниками плохо. Иногда случайно нанимаем, но они надолго не приживаются (надеюсь я не выдаю страшную тайну). В этом есть свои плюсы и минусы, но в общем как сложилось, так сложилось. Ну и понятно что в качестве коллеги в ряде случаем можно использовать резинового утенка.
  • Дизайн классов: что такое хорошо?
    0
    В завершение я хотел бы поправить DataArt: В приложении на Spring и сроком жизни 5+ лет лучше не писать статических методов вообще.


    Это безусловно хорошая идея, но в реалиях аутсорсинга — не всегда получается энфорсить правила столь строго. Я поэтому предпочитаю писать статью как набор рекомендаций в стиле «Если мы не хотите, чтобы вас сбила машина, возможно вам не стоит перебегать дорогу на красный свет».
  • Дизайн классов: что такое хорошо?
    +1
    говоря о замшелости — есть грубо говоря два способа связывания частей приложения.
    1. из одной функции или процедуры вызвать другую, а из нее третью.
    2. связывание компонент (в нашем случае классов) с помощь какого-то декларативного способа.

    второй способ в целом удобнее, заодно он позволяет делать еще две очень удобные вещи
    1. конфигурирование
    2. управление жизненным циклом. Если компонентам для начала работы необходимо как-то разогреться, то Spring IoC очень удобен.
  • Дизайн классов: что такое хорошо?
    0
    Это хороший и правильный совет. метод должен сохранять какую-то разумную сложности. У меня совсем немного про это есть. Но если честно я на этом не концентрируюсь т.к. я такого кода уже наверное лет 10 не видел. Сейчас в массе народ склонен выносить сложность в путанный и не очевидный дизайн связей. А вот чтобы класс на 1000+ строк — в той части IT которую я вижу это как-то само собой ушло.

    UPD: Вообще тема — как разбить что-то имеющее простой фасад и занимающее 3000+ строк на небольшие разумные кусочки — во многом пересекается с темой статьи, просто тут надо шире трактовать понятие модуля приложения. Это может быть Сервис, модуль Java, библиотека, пакет, фреймворк, класс, функция (классика «а за деревом дерево, а за деревом дерево, ...»). У меня в черной версии было про это, но я убрал т.к. решил, что статья начинает расползаться.
  • Дизайн классов: что такое хорошо?
    0
    соотношение сложность реализации / сложность контракта должно быть высоким. Когда много простых классов образуют сложную систему — получается github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
  • Дизайн классов: что такое хорошо?
    0
    Уточню — перед методами со статическими классами. В комментарии я пожалуй мысль раскрыть не смогу, поля слишком узкие. Советую почитать про IoC контейнеры и зачем они нужны. Сейчас без них приложения пожалуй уже почти и не пишутся. Если коротко, то это жизненный цикл, связывание, конфигурирование в первую очередь и много других не менее полезных фишек во вторую и третью.
  • Дизайн классов: что такое хорошо?
    0
    SearchAnalyzer.getInstance().findFiles(pattern).count(char); — как раз хороший пример дизайна классов.
    Активация связи происходит в третьем классе и метод findFiles наверняка возвращает какой-то осмысленный класс с отдельным контрактом.
    В рамках спринга SearchAnalyzer.getInstance() это скорее @ Component, но это в общем уже детали.
    плохо было бы

    int count = SearchAnalyzer.getInstance().findFilesAndCount(pattern,char);
  • Дизайн классов: что такое хорошо?
    0
    Ну я в общем об этом и говорю в статье :-)
  • Дизайн классов: что такое хорошо?
    0
    Ну тут мы упираемся в ограниченность примера, понятно, что тут обе функции пакуются под один зонтик. В реальности обычно функции бывают достаточно жирные, для того чтобы их разделить.
  • Израильские учёные разработали универсальное лечение против рака
    +1
    Удачи парням, надеюсь у них все получится. Увидим через год, точнее через несколько лет.
  • Всегда ли нужны Docker, микросервисы и реактивное программирование?
    0
    Я вас собственно не заставляю — если вам так удобнее для вас все работает — нет вопросов. Судя по комментариями — для кого-то это имеет смысл, пусть они мучаются без докера, а вы будете им наслаждаться.
  • Всегда ли нужны Docker, микросервисы и реактивное программирование?
    0
    Ну тут сложно сказать точную цифру, думаю сильно зависит от системы, процессора, версии Явы и т.п. я сделал примерную модельку — у меня получается, что для того, чтобы разница между реактивным и блокирующим подходом была заметна если принять, что переключение нитей 20мкс, надо чтобы весь цикл обработки запроса (от начала его чтения сервером) в среднем был не более 500 мкс.
  • Всегда ли нужны Docker, микросервисы и реактивное программирование?
    0
    Выкинуть JVM идея хорошая, но без нее к сожалению программа не работает. Вообще. Никак. Так что выкручиваемся как можем.
  • Всегда ли нужны Docker, микросервисы и реактивное программирование?
    0
    К сожалению на работает так как вы хотите. Нельзя рецепт счастья написать для таких случаев. Слишком много разных критериев надо учитывать, от технических до совершенно субъективных. Мне казалось я написал в виде достаточном для того, чтобы дать дальнейший толчок мысли читателя. Но вот давать рецепт для общего случая — я считаю это не профессиональным.
    Тем более что все быстро меняется и «твердые» рецепты быстро устаревают.
  • Всегда ли нужны Docker, микросервисы и реактивное программирование?
    0
    Я прощу прощения, если я отвечу немного в сторону. В статье я не рекомендую конкретный способ решения проблем, собственно про это можно было бы написать, но это тема для отдельной статьи.
    Мое мнение, что играть в эти игры с перекидыванием задач между не блокирующимися потоками — довольно опасное занятие. Очень легко получить сложный, непредсказуемо работающий код.
    Я бы решал задачу примерно так
    1. обычные требования среднего веб приложения — вообще не использовать реактивный фреймворк, никакой пользы он не принесет. Те 5-10% процентов экономии которые он дает все равно «растворятся» в общих накладных расходах. Длинные, хорошо написанные, последовательные, блокирующиеся, императивные методы — что может быть лучше и понятнее?
    2. Есть длинные задачи — использовать пул тредов и асинхронный запуск задач через org.springframework.scheduling.annotation.Async например. Тут все понятно и все это обычно умеют
    3. если есть какие-то супер плотные, обоснованные бизнесом требования по использованию процессора — использовать например WebFlux — и изолировать его использование в отдельный, как можно более компактный сервис. Никаких жонглированием задачами между пулами внутри не делать — такой код относительно легко написать, но очень тяжело поддерживать.
  • Всегда ли нужны Docker, микросервисы и реактивное программирование?
    0
    человек в теме это я, threads переводится как нити примерно с прошлого века.
  • Всегда ли нужны Docker, микросервисы и реактивное программирование?
    0
    Посмотрите на пакет docs.oracle.com/javase/8/docs/api/java/nio/package-summary.html и саб пакеты он как раз про неблокирующее чтение
  • Всегда ли нужны Docker, микросервисы и реактивное программирование?
    –1
    Сам удивляюсь, почему так переводят. Вообще стандарты перевода отдельная тема, больше всего меня удивляет Исаак Азимов ставшей Айзеком и spice melange ставшее спайсом.
  • Всегда ли нужны Docker, микросервисы и реактивное программирование?
    +3
    если вам нужные транзакции между сервисами, то скорее всего микросервисы не ваш выбор
  • Всегда ли нужны Docker, микросервисы и реактивное программирование?
    0
    Если посмотреть на комментарии, то часть читателей ругается за пропаганду реактивного подхода, а часть за критику и не понимание.
    При этом сам статья, про то, что можно и так и этак, главное осознавать к чему это ведет и какие плюсы и минусы.
  • Всегда ли нужны Docker, микросервисы и реактивное программирование?
    +2
    Вопрос в том, как степень изоляции действительно требуется и делать изоляцию больше чем требуется — это жечь деньги без пользы.
  • Всегда ли нужны Docker, микросервисы и реактивное программирование?
    +2
    Я еще слышал мнение, что на запись и чтение сервисы должны быть отдельным (и жить в разных репах разумеется).
    Я считаю что дробить надо по крупным тесно связанным блокам бизнес логики, скажем так обозримого размера.
  • Монорепозитории: пожалуйста, не надо (часть 2)
    +1
    Спасибо, интересная статья и отдельное спасибо за конкретные цифры.
  • Всегда ли нужны Docker, микросервисы и реактивное программирование?
    0
    ^ this!
  • Всегда ли нужны Docker, микросервисы и реактивное программирование?
    +1
    Нет это все одна статья, написана по мотивам разбора проблем. Одна из существенных проблем вызвана использованием реактивного программирования и главной из причин почему был использован реактивный фреймворк — было «мы хотим реактивную систему».
    Статья строго по реалиям жизни.
  • Всегда ли нужны Docker, микросервисы и реактивное программирование?
    0
    Я имею ввиду, если вам важно 250 мс, то добавочные 30мс внесут заметную погрешность >10%
  • Всегда ли нужны Docker, микросервисы и реактивное программирование?
    +1
    Я думаю сильно зависит от предметной области и того как написано приложение. При правильном подходе скорее не является, чем является, но предметная область, понятно может вносить коррективы.
  • Всегда ли нужны Docker, микросервисы и реактивное программирование?
    0
    Я правильно понимаю, что речь идет о
    "bridge": "none",
    "iptables": "false"

    про что написано — Disabling the default bridge network is an advanced option that most users will not need.
    Как-то это м-м-м «грязно» :-)
  • Всегда ли нужны Docker, микросервисы и реактивное программирование?
    0
    не идиоматично — но увы в коде тех проектов в которых мне доводилось делать — аудит вполне распространено. Понятно, что «по феншую такого быть не должно», но грань тут достаточно тонкая и не все ее в должной мере понимают