В переводе статьи пойдёт речь об UndeliverableException в RxJava2 версии 2.0.6 и новее. Если кто-то столкнулся и не может разобраться, или совсем не слышал об этой проблеме — прошу под кат. Побудили к переводу проблемы в production после перехода с RxJava1 на RxJava2. Оригинал был написан 28 декабря 2017, но лучше узнать поздно, чем никогда.
При решении повседневных задач с интерфейсом настольного приложения, реализованного на JavaFX, приходится в любом случае делать запрос на веб-сервер. После времен J2EE и страшной аббревиатуры RMI многое изменилось, а вызовы на сервер стали более легковесными. Как нельзя кстати для подобной проблемы подходит стандарт веб-сокетов и его обмен простыми текстовыми сообщениями любого содержания. Но проблема корпоративных приложений в том, что разнообразность и количество запросов превращает создание и отслеживание EndPoint-ов при наличии отдельно выделенных бизнес-сервисов в жуткую рутину и добавляет лишних строк кода.
А что если взять за основу строго типизированную стратегию с RMI, где между клиентом и сервером существовал стандартный java interface, описывающий методы, аргументы и возвращаемые типы, где добавлялось пару аннотаций, и волшебным образом клиент даже не замечал, что идет вызов по сети? Что если по сети передавать не просто текст, а сериализованные java-объекты? Что если добавить к этой стратегии легкость веб-сокетов и их преимущества возможности push-вызовов клиента со стороны сервера? Что если асинхронность ответов веб-сокета для клиента обуздать в привычный блокирующий вызов, а для отложенного вызова добавить возможность возвращения Future или даже CompletableFuture? Что если добавить возможность подписки клиента на определенные события от сервера? Что если на сервере иметь сессию и подключение к каждому клиенту? Может получиться неплохая прозрачная связка привычная любому java-программисту, так как за интерфейсом будет скрыта магия, а в тестировании интерфейсы легко подменить. Но вот только это все не для нагруженных приложений, обрабатывающих, например, котировки с фондовой биржи.
Есть в IT-отрасли задачи, которые на фоне успехов в big data, machine learning, blockchain и прочих модных течений выглядят совершенно непривлекательно, но на протяжении десятков лет не перестают быть актуальными для целой армии разработчиков. Речь пойдёт о старой как мир задаче формирования и выгрузки Excel-документов, с которой сталкивался каждый, кто когда-либо писал приложения для бизнеса.
Некоммерческая организация Cloud Foundry Foundation (CFF) в конце лета опубликовала рейтинг самых востребованных языков программирования для корпоративных облачных разработок. Согласно их исследованию, лидером стал Java.
Под катом расскажем почему и как его используют ИТ-компании и другие организации.
Хотелось бы поделиться опытом использования payara-micro в разработке корпоративных приложений. Надеюсь, что кому-то сэкономлю время, так как такое решение пришло далеко не сразу. Если вы уже используете Payara или Glassfish в качестве промышленного сервера, или только собираетесь окунуться в мир javaee, то payara-micro и эта статья для Вас.
Вам понадобится web-приложение, которое собирается посредством maven в war-архив, и Java 8 (на более старших работу не проверял).
Итак, вы разработали и натренировали свою нейронную сеть, для выполнения какой-то задачи (например то же распознавание объектов через камеру) и хотите внедрить ее в свое приложение на андроид? Тогда добро пожаловать под кат!
Читать полностью »
GraphQL часто представляют как революционный путь дизайна веб API по сравнению с REST. Однако, если вы ближе посмотрите на эти технологии, то вы увидите, что между ними очень много различий. GraphQL относительно новое решение, исходники которого были открыты сообществу Фейсбуком в 2015 году. Сегодня REST все еще самая популярная парадигма, используемая для предоставления API и взаимодействия между микросервисами. Сможет ли GraphQL обогнать REST в будущем? Давайте посмотрим, как происходит микросервисное взаимодействие через GraphQL API с ипользованием Spring Boot и библиотеки GQL.
Читать полностью »
В прошлых выпусках мы говорили с бывалыми ребятами. Был откровенный рассказ выгоревшего разраба и оптимистичные ответы успешного лида большой компании. Сегодня опрашиваем парня, который только начинает свой путь в ИТ. И по-прежнему ждем заявок от всех, кому тоже охота поболтать.
Читать полностью »
Как стать программистом от безысходности и подняться к вершинам успеха? Сегодня в нашей виртуальной студии на вопросы отвечает Паша asm0dey Финкельштейн. Паша – один из немногих, кто разбирается в создании бэкендов на Kotlin. Кроме того, он пилит опенсорс, активно участвует в жизни сообщества, и, на минуточку, — побывал на почти всех наших московских Java-конференциях.
Дэвид Хэррон, автор материала, перевод которого мы публикуем сегодня, задался следующим вопросом: «Должен ли человек, работавший более 10 лет в Sun Microsystems, в команде Java SE, до последнего вздоха думать лишь о байт-коде Java и создавать экземпляры абстрактных интерфейсов?». Он задавал этот вопрос применительно к себе, и для него платформа Node.js, после Java, оказалась подобна глотку свежего воздуха. Дэвид говорит, что когда он был уволен из Sun в январе 2009 года (прямо перед поглощением этой компании Oracle), он узнал о Node.js. Эта технология его зацепила. Что значит «зацепила»? С 2010-го года он много писал о программировании для Node.js. А именно, написал несколько книг, в том числе — «Node.js Web Development», четвёртое издание которой вышло в этом году. Он подготовил множество небольших материалов о Node.js, опубликованных в интернете. Фактически, он уделил очень много времени и сил, рассказывая о платформе Node.js и о возможностях JavaScript. Почему того, кто раньше занимался исключительно Java, так увлекли Node.js и JavaScript?
