• BPM в компании: пусть решают процессы
    +5

    Если бы космический корабль!
    Когда клиенту нужно наладить доставку продуктов из пункта А в пункт Б, где хватило бы мотоцикла с коляской или для особо продвинутых — электромобиля на солнечных батареях, тебе продают железную дорогу, позиционируя как наилучшее и самое перспективное решение на рынке грузоперевозок. Комплект включает в себя: рельсы, шпалы, паровоз (1шт.), лицензию на использование, толстую инструкцию по монтажу, экспресс-курсы для клиента на роль путейцев, машинистов, кочегаров, вагоновожатых и станционных диспетчеров.


    Далее за отдельную плату провайдер продает вагоны, но как правило весь комплект имеющихся вагонов задвигается клиенту сразу и полностью: и пассажирские, и цистерны, и холодильники, и вагоны для перевозки автомобилей, и крупного рогатого скота, и австралийских кенгуру, и впридачу вагон-ресторан, вагон-туалет, вагон-интернет и вагон-казино с блекджеком и женщинами (просто раньше были юзкейсы, а вагоны остались). И вот все это добро зачастую колесит в одном составе.


    Весь монтаж и использование делается исключительно силами свежеобученных "специалистов" клиента под зорким присмотром провайдера, который следит за соблюдением концептуальности монтажа (best practices) и правильным использованием "средств разработки" — лопаты, лома и кувалды. Обязательная "поддержка" паровоза производится провайдером за периодическую плату, которая состоит в оперативном объяснении клиенту, в чем была его вина в случае взрыва котла или схода поезда с рельс: неправильная эксплуатация локомотива или некачественный монтаж путей.
    Любые претензии к провайдеру не принимаются во внимание. Низкая скорость доставки или паровоз не едет в горку — покупайте второй паровоз и используйте в сцепке! Поэтому большинство клиентов на особо сложных участках колеи использует своих лошадей для "подтаскивания" локомотива (а иногда и поездную бригаду), т.к. на второй паровоз денег запланировано не было. Доходит даже до случая, когда поезд с локомотивом на всем участке приводится в движение исключительно лошадьми, но это уже крайность.


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


    Звучит шизофренично, но это краткое иносказательное описание моего более-чем-десятилетнего опыта работы с BPM.

  • BPM в компании: пусть решают процессы
    +4
    Зачем BPM бизнесу? BPM — это концепция управления бизнесом через бизнес-процессы.

    Просто в такой форме бизнесу наглядно и доходчиво объясняют концепцию конечного автомата и срубают за это деньги.


    У нас для вас две новости: хорошая и так себе. Хорошая: BPM уже существует. Так себе: мало кто знает, что с этим делать.

    Это я все периодически слышу более чем 10 лет. Уж извините за упоминания, "работал" (хотя тут больше подходит глагол, обозначающий действие сексуального характера) со стеком IBM Websphere, с Oracle SOA Suite, немного ковырял JBoss SOA platform и небольшие BPM вроде Activiti и Bonita — все клянутся, что это вазелин для вашего бизнеса и без него никак. В итоге практически нигде эти решения не работают по-нормальному по ряду причин концептуального, технического и политического характера. А возни и расходов с ними на порядок больше.


    Среди использующих Pega компаний — лондонский аэропорт Хитроу, MasterCard, City Bank, Morgan Chase и многие другие.

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


    В банках кейс, как правило, включает в себя все действия с момента обращения клиента (например, запрос на получение кредита, опротестование операции по карте) до полного решения данного вопроса (к примеру, выдача кредита)

    Это то, что продают на презентации продукта. Первый пример процесса в tutorials ко всем BPM — это Loan Broker. И как правило на этом все заканчивается.


    Работая в действительно нетривиальных и сложных проектах, разработчики могут использовать и прокачивать свои навыки: Java SE, Java EE,

    Согласно моему плачевному опыту, основную часть работы все-равно приходится делать именно в "этих самых навыках": Java SE, Java EE, и пр. И в определенный момент сама БПМ начинает уже мешать, а потом сильно мешать. И в итоге принимается решение переписать весь модуль на Java без участия БПМ.


    На самом деле, Pega сама по себе — будущее автоматизированных систем управления (АСУ) и корпоративных информационных систем (КИС).

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

  • Java EE 8: краткий и весьма оптимистичный обзор новых возможностей
    0

    С нулевыми зависимостями — это тоже миф. Обычно ВАР содержит еще тонны артефактов и велосипедов, не предоставляемых JEE API.
    Ну и традиционный троллинг: раньше чтобы протестировать простой бинчик, нужно было сбилдить весь проект, запаковать его в ВАР/ЕАР, запустить контейнер, задеплоить артефакт, и вызвать нужный метод через какой-нибудь remote api (EJB, JAX-WS, JAX-RS), посмотреть ошибку в логах сервера, попытаться понять с каким фрагментом кода она связана, закорректировать код и повторить операцию. В JEE8 есть какие-нибудь улушения на этот счет?

  • «В ЕЕ всегда есть альтернатива» — Дмитрий Александров (T-Systems) о Java EE / EE4J
    +3

    Просто, делая приложение под WebSphere, вы уже будете иметь проблемы :) Не покупайтесь на обещанные "стандарты": конфигурация каждого контейнера делается отдельно, мэппинг ресурсов JNDI у всех разный, помимо стандартных дескрипторов для каждого контейнера приходится вставлять свой пропиетарный дескриптор, кроме я не умомянул пропиетарные "расширения" стандарта. Ну и как всегда, стандарты стандартами, а у каждого контейнера внезапно всплывают свои "нежданчики".


    P.S. Как там с тестингом у микропрофайла? До сих пор юзается костыль Arquillian?

  • MockK — библиотека для mocking-а в Kotlin
    0

    Не знаю насколько релевантно: есть библиотека, которая позволяет пускать агента из уже с запущенного кода без нужды указывать -javaagent:
    https://github.com/electronicarts/ea-agent-loader
    Запуск агента производится через определенный OpenJDK-шный JMX — весь инструментарий для рантайм инжиниринга вналичии. Я так пускаю EclipseLink JPA с динамическим weaving-ом в рантайме.

  • Spark — Потрясающий веб-микрофреймворк для Java
    0

    В системах, где нужны привилегии суперпользователя, обычно имеется iptables:
    iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT --to a.b.c.d:8080

  • Необычный митап про Java в Питере 30 октября
    +1
    Как вы думаете, в современной автомобильной промышленности при каких обстоятельствах автоконцерн вкладывается в разработку своего собственного стеклоподъемника, а не возьмет готовый, хороший и стандартный агрегат?

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


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

  • Spark — Потрясающий веб-микрофреймворк для Java
    0

    Я думал, Вы забросили этот проект. Ан-нет, уже даже достаточно юзабельная версия! На выходных попробую. Из пожеланий: добавить автоматический генератор врапперов к JS-библиотекам из TypeScript на DefinetlyTyped.

  • Spark — Потрясающий веб-микрофреймворк для Java
    +1

    Клиент-сайд состоит из двух частей: фреймворка и библиотеки виджетов. В качестве фреймворка довольно давно использую GWT + GQuery + RestyGWT. Доволен. Из печалек: медленная компиляция и неудобный дебаг в superdevmode. В качестве библиотеки виджетов можно использовать GWTBootstrap, GWT-Material, gwt-polymer-elements, любую CSS-based библиотеку, или даже интегрировать практически любой bullshit.js.


    Про упомянутый Vaadin: да, подтормаживает (постоянная синхронизация состояния виджетов с сервером), спорно годится для интернет-проектов, но для энтерпрайзных админок и дэшбоардов — самое то. При помощи GWT можно использовать весь widgetset Vaadin-a на клиентской стороне без использования серверной части, что значительно разгоняет UI. Кроме того, есть полностью js-ный Vaadin Elements. Из печалек: из пресловутый Vaading Grid тормозит гораздо больше на клиенте, чем на сервере.


    P.S. Хочу попробовать подергать Kotlin.js. Кстати, если уж о котлине заговорили, то вот фреймворк со схожим функционалом: https://github.com/Kotlin/ktor

  • «Если бы сейчас начали сначала, снова выбрали бы Scala»: Tinkoff.ru о Scala-разработке
    +1
    Напрашивающийся первый вопрос: почему в компании сделали неочевидный выбор в пользу Scala

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


    С одной стороны фильтр вхождения в язык достаточно высок и сразу отсеивает большую часть любителей и непрофессионалов. То есть программист на скале — это "мозги" с уже достаточно высоким профессиональным уровнем, большим багажом знаний и способностью к самостоятельному обучению. С другой стороны действуют факторы, позволяющие осуществлять жесткий контроль и экономию средств на работниках, потому как:
    1) рынок трудоустройства на скале черезвычайно ограничен (куда вы еще денетесь с подводной лодки?)
    2) большинство людей со знанием скалы приходит без требуемого опыта (а где еще им его накопить?), что используется как аргумент при приеме на работу
    3) акцент в основном делается на молодых людей, которым еще предстоит "набраться опыта", для которых работа в компании позиционируется как "неплохой шанс" с заявкой на светлое будущее.
    Плюс одновременно можно не беспокоиться об утечке кадров, решений и экспириенса из компании. Получается тройной профит!


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

  • Периоды звездных суток в радиоактивном распаде
    0

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

  • «Паттерны» функционального программирования
    +4

    Потому что основа функционального программирования — это stateless-операции над аргументами функции. Когда мы добавляем внешний изменяемый state в качестве, например, базы данных, то теряется идемпотентность функций, и результат композиции становится непредсказуемым. Чтобы жестко зафиксировать последовательный порядок применений функций, требуется использовать специальную монаду IO, с которой программирование фактически становится императивным. Кроме того, результат вычисления функции — это уже не просто Response, а еще и измененный State. То есть красивая идеальная схема HttpResponse = WebApplication(HttpRequest) уже не работает, и проблема здесь будет не в getCustomerFromDatabase(), а в updateCustomerInDatabase().
    Поэтому для data-driven приложений функциональное программирование не лучший выбор.

  • Исправляем 7 распространенных ошибок обработки исключений в Java
    0
    Checked исключения — это вариант возвращаемого значения с приятным бонусом в виде неявного завершения блока кода, вместо проверок возвращаемого методом кода (результата) — ловишь исключение.

    И кто вам мешает делать то же самое с unckecked? Разница лишь в том, что вас не обязуют это делать непосредственно в вызывающем методе. Если хотите, unchecked эксепшны — это вариант возвращаемого значения с неявным завершением блока, добавляемый для всех методов по умолчанию. Но основное назначение эксепшнов — это именно раннее завершение блока, а вот как раз бонус — это возвращаемое значение. Кроме того, когда требуется именно возврат определенного осмысленного значения, лучше использовать монады типа Optional или Try — для эксепшнов осмысленное значение редко выходит за рамки типа эксепшна и сообщения со стектрейсом.


    А насчет заворачивания исключений многократно могу лишь сказать так: руки кривые и излишнее проектирование.

    То есть архитектурный леер должен выставлять наружу делати реализации? :) Для самостоятельного осмысления требуется расставить эксепшны в throws:


    interface ConfigReader {
      Properties readConfig() throws ???;
    }
    class SQLConfigReader implements ConfigReader {
      Properties readConfig() throws SQLException;
    }
    class FileConfigReader implements ConfigReader {
      Properties readConfig() throws IOException;
    }
    class URLConfigReader implements ConfigReader {
      Properties readConfig() throws MalFormedURLException, IOException;
    }

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

    Справедливо. Однако Java Api просто пронизан checked-исключениями. То есть либо перехватывайте и обрабатывайте, либо перехватывайте и врапьте, либо извольте отписаться в throws. И если уж затронули тему Java Api, то почему MalformedURLException и ParseException checked, а NumberFormatException unchecked, хотя все они возникают при парсинге текста.


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

    И это будет последним костылем перед тем, как полностью перейти к unchecked.


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

    class MyService {
      void init(ConfigReader configReader) {
        // configReader -- это интерфейс.
        // В какой конкретный класс смотреть компилятору,
        // чтобы определить, какие исключения тут могут быть выкинуты?
        configReader.readConfig();
      }
    }
  • Исправляем 7 распространенных ошибок обработки исключений в Java
    –1

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


    Есть расхожий паттерн о том, что эксепшны низких уровней нужно заворачивать в собственные более внятные: например при чтении конфигурации SQLException или IOException завернуть в свой ConfigurationException. Это плохо, потому как затрудняет абстракциям верхнего уровня получить внятный доступ к причине (в каком из цепочки getCause() он лежит?). В случае же, когда этого не требуется и абстракции верхнего уровня абсолютно пофиг на тип эксепшна, нет никакого смысла в заворачивании.


    Checked должны быть эксепшны, связанные с бизнес-логикой: валидацией данных, некорректным состоянием, etc. Эксепшны, связанные с ресурсами должны быть только unchecked, и это ошибка дизайна Java API.

  • Исправляем 7 распространенных ошибок обработки исключений в Java
    0

    Ошибка одна — перехват исключений. В подавляющем большинстве случаев его в бизнес-коде вообще не должно быть. Практически всегда обработка исключений — это удел абстракций верхнего уровня, где как правило нет особой необходимости сильно различать тип эксепшна. К сожалению в Java checked exceptions обязуют перехватывать непосредственно в вызывающем методе, хотя практически всегда это не его ответственность. В частности в Java все исключения доступа к ресурсам checked: IOException, SQLException, JMSException, etc… Архитекторы посчитали, что вызывающий метод во что бы то ни стало просто обязан позаботиться о том, что если вдруг что-то пойдет не так. Реально же бизнес-код вообще не должен заботиться об ошибке доступа к ресурсам также как и не должен заботиться об InterruptedException или OutOfMemoryError — это должны компоненты верхнего уровня универсальным способом, например откатить транзакцию.

  • 7 правил хорошего тона при написании Unit-тестов
    0
    1. Третье правило настоящего джентльмена — следи за путями.

    Что за треш? Paths.get(".", "log", "service.log") позволит вам навсегда забыть о File.separator.

  • Почему я ненавижу Spring
    +2
    Большинство джунов не в состоянии не только написать такой, но и понять зачастую. Поэтому посты типа "я ненавижу..." следует читать с солидной долей скепсиса.

    Это понятно. С другой точки зрения, джун, который мало-мальски в состоянии распарсить файл и запихнуть его в базу данных, при попытке сделать это на Spring Batch наполняется лютой и праведной ненавистью.

  • Обратная сторона Spring
    0

    На мой взгляд основная проблема спринга, превращающая его из фреймворка в книгу заклинаний, состоит в повсеместном использовании аннотаций. Аннотации в java были придуманы для определения метаданных в коде. Но строить на их основе некий расширяемый метаязык для определения контекста приложения — это вкорне неверная идея, аннотации для этого не приспособлены. Расставленные в коде аннотации сематнически никем не контролируются, кроме рантайма: @EnableWebMvc я могу вообще поставить на любой объект, не обязательно на @Configuration — никто меня не ограничит.
    Есть гораздо более удобные, правильные и открытые способы задания конфигурации контекста без аннотаций, например Guice.
    Спринг же пытается всю задачу замести под ковер, оставляя пользователю лишь набор заклинаний и рецептов для описания бизнес логики, которые нужно использовать в определенном порядке, иначе просто не взлетит. Это очень эффектно для демонстраций и презентаций, но в реальных проектах при попытке заглянуть под ковер и что-то там изменить всегда сопряжена с головной болью и геморроем.

  • Почему я ненавижу Spring
    +7
    1. огромное количество библиотек и реализаций. Попробуйте навелосипедить свой spring-security c каким-нибудь oauth собственнм сервером и клиентом.

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


    Альтернативу @Transactional с нетривиальнм двухфазным коммитом (например БД + Очередь в единой транзакции).

    Двухфазный коммит делает не Spring, а стороннияя библиотека-координатор, например Atomikos, Narayana, etc. Spring @Transactional делает лишь наивный автоматический прокси на коммит/роллбэк, который также легко сделать вручную при помощи java.lang.reflect.Proxy, AspectJ или ByteBuddy. В реальных проектах практически всегда требуется вручную контролировать сбои и взависимости от типа ошибки нужно помимо роллбека повторить транзакцию, реинициализировать ресурс, отрапортовать о сбое, собрать метрики… Вот вам и свой @Transactional. Кроме того есть мнение, что XA вообще не рекомендуется использовать...


    но опять же время на изучение и не меньшее время чтобы все это подружить между собой

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


    Представьте, что у вас ушел 1-2 ключевых разработчика, кто делал ваши велосипеды и потом найдите и пофиксите сложный баг.

    Ваши 1-2 разработчика писали когда-нибудь bean postprocessors? Скорей всего они намолотили кучу кривой прикладной магии ввиде специфических @Заклинаний. Разобраться почему не проксируется бин, кто его процессит и в какой последовательности и почему вдруг что-то перестало работать — никто не будет. Девелоперы как правило понавтыкают костылей, чтобы хоть как-то решить требуемую задачу.


    Куча проблем за вас решена

    И на ровном месте создана другая куча. Если все так просто — почему на SO Spring держится в топе? Как правило всегда есть более простое и элегантное решение каждой конкретной проблемы. Spring же пытается влезть без вазелина везде, где это только возможно, вцелом значительно усложняя архитектуру и упрощая лишь какие-то конкретные простые случаи использования. Кроме того, подобное упрощение имеет негативный эффект: куча кодеров, не понимая принципы работы, начинает копипейстить туториалы и SO, допуская архитектурные ошибки. И, столкнувшись с проблемами или с незнанием того, как что-то конкретное сделать на спринге, начинают грязно костылить.


    Сделать достаточно сложный проект на spring-boot для быстрого старта как прототип относительно несложно

    Сделать демку типа "хелло-ворлд" с кучей подключенных технологий. В реальном проекте требуется более полный контроль над кодом, где в итоге все плюсы ввиде средств автоматического бутстрапа превращаются в огромные минусы.

  • Рано закапывать Java
    +3

    Вобщем-то на Java ввиду особенностей языка как раз нельзя написать нормальный DSL. Лямбды немного улучшают ситуацию, но не сильно. В частности, проблемы возникают с описанием иерархической структуры и со ссылками на проперти (которые всегда будут не type-safe). Стандартрый способ — клепать билдеры, но с ними получается очень гормоздко. Поэтому практически всегда для описания структур используют сторонний язык типа XML.


    P.S. В Java 8 идентификатор _ объявлен как deprecated, а Java 9 вообще запрещает его использовать.

  • GitHub переходит на GraphQL
    0

    Те, кто юзают в бэкенде Java и Hibernate знают о такой вещи как JPA 2.1 Entity Graphs. Фактически это та же идея, что и GraphQL.

  • Как защищаться от атаки вируса-шифровальщика «WannaCry»
    +1

    У нас пострадали в основном крупные компании.
    http://www.elmundo.es/tecnologia/2017/05/12/59158a8ce5fdea194f8b4616.html


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

  • Выход Java 9 снова отложен
    +1
    Вы хотите сказать в том же IBM отдельно сидят люди, которые участвуют в JCP и отдельно те, кто пишет софт и причем первые не общаются со вторыми? Не проблема ли это IBM

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


    Поэтому еще год назад от них были призывы "если вы видите какие-то проблемы у вашей библиотеки/фреймворка при переходе на Jigsaw — напишите нам!".

    Это когда еще мало-мальски стабильной девятки не было? Есть очень много решений, базирующихся на classpath. SLF4J использует classpath для поиска бэкенда для логгинга и настроек. Чтобы это сработало в модульной среде, библиотека должна быть изменена концептуально. И все остальные библиотеки, использующие SLF4J, будут ждать, пока мейнтейнеры соизволят выпустить его модульную версию, а также модульную версию всех своих зависимостей. И так с каждыми библиотеками, фреймворками и тулзами для сборки, тестинга и, наконец, продуктами. Период перехода может затянуться лет на 5 или больше, и все это время придется поддерживать две версии. В итоге экосистема сплитанется на две — модульную и classpath-ную.


    А теперь главный вопрос: в чем реальный профит модульности?

  • Выход Java 9 снова отложен
    +3

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

  • CSS Grid Layout. Быстрый старт
    0

    Наконец-то в браузере появятся нормальные лейауты! FlexBox вместе с GridLayout покрывают практически всю необходимость разметки в приложениях.
    А вообще, как-то странно: именно производители "того самого браузера" изначально предложили и пилили спецификацию GridLayout, теперь же хуже всех ее поддерживают.

  • Влияние ambient-музыки на процесс написания кода
    +6

    Дааа! Респект за упоминание Ultimae Records!!! В свое время они выпускали годную серию сборников псайбиента под названием Fahrenheit Project. Рекомендую всем! Просто офигительное звучание и очень интересные наработки! Из Solar Fields очень нравится его первый альбом Reflective Frequencies. Упомянутые Asura больше работает в стиле Slow Trance, а вот их бывший музыкант Aes Dana делает чистый dark ambient. Также вместе с Solar Fields они запилили неплохой проект H.U.V.A. Networks на том же Ultimae но по мне, так он слишком атмосферный — люблю тяжелые драм секции. Вобщем, лейбл Ultimae Records — номер один для любителей псайбиента.


    Еще тащился от проекта Vibrasphere — в основном они работают в PsyTrance, но у них есть прям сказочные псайбиентные треки. Жаль, что закрылись.

  • Модульные приложения на Java. Как?
    0

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


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

  • Модульные приложения на Java. Как?
    0

    А вот интересно, как вы все это пускаете в devmode? По стандартной схеме build-pack-deploy? Или плагин какой используете?
    И мне кажется, не совсем аргументирована модульность приложения. Внутренне — да, имеет смысл для кода и тестов. Но с точки зрения деплоя лучше иметь единственный артефакт, нежели груду джарников.
    Если необходима модульность, по-моему лучше будет разбить приложение на микросервисы и стартовать каждый в отдельной JVM/контейнере, как это делается сейчас. Единственный сценарий, который приходит на ум — платформа для деплоя различных приложений и микросервисов с разным циклом разработки. Что-то типа ESB или AppServer. Фактически там он в осносном и используется.

  • Как с помощью maven работать с библиотеками, которых в maven нет
    +2

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

  • Как с помощью maven работать с библиотеками, которых в maven нет
    0

    Есть одна проблема с локальным репозиторием — для мультимодульного проекта придется корректировать путь к нему в каждом pom.xml, так как project.badedir будет у каждого модуля свой.

  • Открытое письмо рекрутерам IT-сферы
    +1

    По поводу IT-рекрутинга в блоге у yegor256 понравилась фраза: "You're Just the Mayonnaise in a Bad Sandwich"

  • Многократное использование кода в микросервисной архитектуре — на примере SPRING BOOT
    +2

    У меня сложилось такое впечатление, что сейчас под трендом "микросервисы" пытаются втюхать Spring Boot, Rest и иногда каким-то образом припаять Docker. И если посмотреть в Google Trends, то собственно так оно и есть. То есть чтобы в мозгу разработчика четко отложилось: java-приложения, оказывается, можно разрабатывать без контейнера, но для этого нужен Spring Boot, который нам даст Rest. И это теперь называется микросервисами.


    Тем не менее, 10 лет назад в эпоху засилия SOA и JavaEE, когдя я писал что-то вроде:


    @WebService
    public class AddService {
        @WebMethod
        public int add(int a, int b) {
            return a+b;
        }
        public static void main(String[] args ){
            Endpoint.publish("http://0.0.0.0:1234/AddService", new AddService());
        }
    }

    не было подходящего названия для этого. Люди недоумевали: если это java-приложение, то где интерфейс с кнопочками? Если это веб-приложение, то где сервер приложений, куда оно должно деплоиться? Здесь даже не было более-менее знакомого слова "Spring". И вплоть до того, что клиенты отказывались принимать работу, поскольку не знали каким словом это назвать (мой клиент все-таки придумал название — "тамагочи"))).


    Теперь же я любое решение, которое не требует контейнера, я с гордосью называю "микросервис" и вопросов не возникает.

  • Новый GC Epsilon. У джавы может не быть сборки мусора. Шок. Сенсация
    +2

    Практическая полезность была бы кстати, если бы JVM умела бы делать быстрый hot-restart: прибиваются все треды, освобождаются все системные ресурсы, но при этом оставлялся бы PermGen с классами, сгенеренной статистикой выполнения и предкомпилированным кодом.


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


    Что это даст? Процессинговые треды, имеющие OutOfMemory хандлер смогут обработать ситуацию: закрыть ресурсы, вернуть ошибку клиенту, сообщить в кластер, что нода отвалилась, и при необходимости рестартнуть после сборки мусора. Чтобы при вызове хандлеров не было повторного OutOfMemory вся аллокация ведется в отдельно зарезервированной области.


    Таким образом можно реализовать быстрый перезапуск процессинга без реальной необходимости перезапуска системы.

  • Начинается разработка OpenJDK 10
    +1

    Де-факто в Java есть проперти. И описаны они в стандарте JavaBeans при помощи геттеров и сеттеров. И многие сторонние фреймворки и библиотеки не привыкли работать напрямую с полями, а вместо этого делают интроспекцию пропертей.


    В общем случае некорректно думать о пропертях как о полях для хранения данных. Пропертя позволяют скрыть логику хранения данных и добавить дополнительный функционал как валидация значений, lazy-инициализации, связанные значения, события, etc. Ну и естественно, сделовать принципам ООП и переопределять поведение при наследовании.


    А в DTO геттеры и сеттеры действительно не нужны. Я по возможности стараюсь их делать immutable со всеми полями public final. Есть неплохой проект на этот счет Immutables.org.

  • Начинается разработка OpenJDK 10
    0

    Вещь, которая изо дня в день бесит в java — геттеры сеттеры. Пусть сделают человечный property в качестве сахара. Дабы не быть голословным:


    class Test {
      private String vasya;
      public String getVasya() { return this.vasya;}
      public void setVasya(String vasya) { this.vasya = vasya;}
    }

    Итак, для описания одного лишь свойства vasya мы повторили это слово 7 раз в общей сложности затратив 17 слов! Думаете все? Нет. Добавьте еще javadoc-описание свойства к гетеру и продублируете его же в сеттере.


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

  • IntelliJ IDEA 2016.3: Java 8 и ES6, улучшенные отладчик и интерфейс, и многое другое
    0

    В Entity финальное поле, может, и не нужно. А вот при создании immutable-объектов, если используется сериализация отличная от Java, требуется определить пустой конструктор, где нужно инициализировать все final nonnull-поля (кстати, забыл в примере пометить как поле nonnull) дефолтными значениями. Если раньше все прокатывало с null-ами, то теперь требуется определить некие "пустые" объекты для каждого из полей.


    Я считаю, что нарушение контракта — это как раз вставка проверок на nonnull в рантайме, т.к. изначально эта аннотация планировалась исключително для warning-ов при компиляции. И с @SuppressWarnings код должен компилироваться и работать корректно.

  • Модуляризация в JavaSE без OSGI и Jigsaw
    0

    Очень интересно! Как я понял, MavenClassLoader по дефолту автоматически загружает все зависимости в один модуль. Если я хочу изолировать некоторые зависимости в отдельные модули, я их загружаю отдельно, а затем использую вариант с parent-ом — зависимости заново загружаться не будут?

  • Как платить программистам меньше
    –2

    Юмор понятен. Но вот реальный способ платить меньше.
    Выдавайте часть зарплаты различными социальными бонусами: карты на обеды, проезд в общественном транспорте, мед. страховка, абонемент в спортзал, etc… Вроде как для работника сумма та же, а вы экономите на налогах (НДС, подоходный).

  • IntelliJ IDEA 2016.3: Java 8 и ES6, улучшенные отладчик и интерфейс, и многое другое
    0

    Не подскажете, кто теперь насильно вставляет проверки на null для @Nonnull параметров? Это компилятор или IDE? Сейчас апдейтнулся и сломалась половина тестов с ошибкой:


    Caused by: java.lang.IllegalArgumentException: Argument for @Nonnull parameter 'correlationId' of services/storage/CorrelationStorage$Correlation. must not be null
    at services.storage.CorrelationStorage$Correlation.$$$reportNull$$$0(CorrelationStorage.java)

    Просто есть куча immutable классов с публичным конструктором и параметрами @Nonnull. Чтобы работали всякие JPA и сериализаторы, добавляю приватный конструктор по умолчанию, который вызывает публичный с нулами:

    class Bean {
    public final String param;
    public Bean(@Nonnull String param) {this.param = param;}
    @SuppressWarnings("all")
    private Bean() {this(null);}
    }

    До 16.3 все работало. Где отключается?

  • Реализация гарантированной асинхронной доставки сообщений
    +2
    Оговоримся, что Rabbit MQ у себя в production мы не используем из-за невозможности его работы с XA.

    Вместе с тем вы используете Rest, который вообще как бы не транзакционный. Странная мотивация.


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

    Вопрос на засыпку: что делать, если мой любимый http вернул timeout? Rest обработал изменения или нет?
    В вашей схеме каждый Rest-сервис должен локально записывать транзакции и автоматически игнорировать их при повторном вызове.