Java *

При разработке плагинов для Jira периодически приходится использовать библиотеки, которых в Jira нет, поэтому их нужно установить вместе с разрабатываемым плагином. В Jira сторонние библиотеки можно упаковать в плагин двумя способами:

Указать у сторонней библиотеки область видимости компилирования, и тогда классы из этой библиотеки будут упакованы в jar-файл разрабатываемого плагина. Для этого необходимо в файле pom.xml написать:

  <dependency>
            <groupId>com.google.code.gson</groupId>
            <artifactId>gson</artifactId>
            <version>2.2.2-atlassian-1</version>
	<scope>compile</scope>   
</dependency>

Собрать плагин таким образом, чтобы jar-файл сторонней библиотеки находился в папке dependencies файла obr разрабатываемого плагина.

Как известно, баги есть во всех программах. Есть множество способов борьбы с ними: юнит-тесты, ревью, статический анализ, динамический анализ, дымовое тестирование и так далее. Иногда для искоренения определённого бага полезно сочетать разные методики.

Я разрабатываю Java-инспекции в IntelliJ IDEA, которая большей частью написана на Java. В некотором смысле я нахожусь в привилегированном положении по сравнению с другими программистами: доработать статический анализатор IDE, чтобы находить новый класс ошибок — это моя прямая рабочая обязанность, которая при этом же позволяет найти и обезвредить баги в этой же самой IDE. Хочу поделиться одной такой историей успеха.

Довелось мне тут на днях побывать на очередном собеседовании. И задали мне там вот такой вот вопрос. Что на самом деле выполнится (с точки зрения транзакций), если вызвать method1()?

public class MyServiceImpl {
  
  @Transactional
  public void method1() {
    //do something
    method2();
  }

  @Transactional (propagation=Propagation.REQUIRES_NEW)
  public void method2() {
    //do something
  }
}

Ну, мы же все умные, документацию читаем или, по крайней мере, видео выступлений Евгения Борисова смотрим. Соответственно и правильный* ответ знаем (правильный* — это такой, который от нас ожидает услышать тот, кто спрашивает). И звучать он должен примерно так.

«В связи с тем, что для поддержки транзакций через аннотации используется Spring AOP, в момент вызова method1() на самом деле вызывается метод прокси объекта. Создается новая транзакция и далее происходит вызов method1() класса MyServiceImpl. А когда из method1() вызовем method2(), обращения к прокси нет, вызывается уже сразу метод нашего класса и, соответственно, никаких новых транзакций создаваться не будет».

Но знаете, как это бывает, вроде и ответ правильный уже давно знаешь. И применяешь это знание регулярно. А вдруг раз… и неожиданно задумаешься: «Подождите-ка, ведь если мы используем Spring AOP, то там могут создаваться прокси и через JDK, а могут и с CGLIB; а еще возможно, что CTW или LTW подключили. И что такой ответ всегда будет верен?».

Ну что ж: интересно? Надо проверить.

Это третья статья серии, посвящённая использованию класса Optional при обработке объектов с динамической структурой. В первой статье было рассказано о способах избежания NullPointerException в ситуациях, когда вы не можете или не хотите использовать Optional.
Вторая статья посвящена описанию методов класса Optional в том виде, как он появился в Java 8.
Эта статья описывает методы класса, появившиеся в Java 9.
Четвертая статья посвящена необходимому (с точки зрения автора) дополнению к этому классу. Ну а в пятой статье я рассказываю о том, где внутри класса следует применять Optional, подвожу итоги и дарю каждому читателю, дочитавшему серию до конца, ценный подарок.

Классу Optional посвящено немало статей и tutorials, в том числе этот и этот на Хабре.
Большинство из них рассказывают как вызываются методы этого класса. Я в этом tutorial делаю упор на то зачем, почему, в каких случаях можно (а скорее даже нужно) применять тот или иной метод класса. Я думаю, это очень важно, ибо как показал опрос после первой статьи этого tutorial, далеко не все Java — программисты вошли во вкус использования всей мощи методов этого класса.
Для лучшего объяснения методов класса я буду использовать более сложные и наглядные примеры, чем в большинстве других tutotials — кофеварку, фильтрационную установку, миксер и т.д.
Это вторая статья серии, посвящённая использованию класса Optional при обработке объектов с динамической структурой. В первой статье было рассказано о способах избежания NullPointerException в ситуациях, когда вы не можете или не хотите использовать Optional.
В этой статье мы рассмотрим все методы класса в том виде, как их предоставляет Java 8. Расширения класса в Java 9 рассмотрены в третьей статье этой серии. Четвертая статья посвящена необходимому (с точки зрения автора) дополнению к этому классу.
Ну а в пятой статье я рассказываю о том, где внутри класса следует применять Optional, подвожу итоги и дарю каждому читателю, дочитавшему серию до конца, ценный подарок.

Несколько месяцев назад мы встретились с Олегом Шелаевым, Developer Advocate компании ZeroTurnaround (далее — ZT). С тех пор Олег успел стать Java Champion (поздравляем!) и… покинуть ZT. Да, если откладывать интервью в долгий ящик, с героем может случиться разное.

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

• о гипотезах и их проверке;
• о блоге RebelLabs;
• о разнице между продуктами и услугами;
• о профилировщике XRebel;
• о конференции GeekOUT и проекте VirtualJUG;
• о простых и сложных цепочках в маркетинге.

Вот видео:


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

Наверное вам уже приходилось иметь дело с объектами, которые меняют свою структуру по законам своего внутреннего развития или в зависимости от внешних условий. На практике это означает, что части объекта для внешнего мира могут быть иногда доступны, а иногда – нет.
Какие это могут быть объекты? Многие сервисные компании, торговые предприятия и банки предоставляют различные виды услуг в зависимости от времени суток. Различные устройства могут выполнять или не выполнять те или иные действия в зависимости от своего состояния. Если вы читаете этот текст с экрана смартфона или ноутбука, он может перестать его показывать, если заряд аккумуляторов опуститься ниже определенной границы.
В этой и последующих статьях этого tutorial мы рассмотрим простые объекты с динамической структурой, способы их моделирования и использования в Java с помощью методов класса Optional.
Про использование методов этого класса написано немало, в том числе и на русском языке, в том числе и на Хабре. В этой серии статей я попытаюсь посмотреть на проблему пошире, рассмотреть преимущества и недостатки выбранного решения проблемы, а также альтернативные подходы.
В этой первой статье цикла мы поговорим о том, как не используя Optional в Java можно обходиться без NullPointerException. Я надеюсь, вы увидите, что без Optional жить можно, но с ним жизнь должна стать приятнее. Вторая статья этой серии посвящена описанию методов класса Optional в том виде, как он появился в Java 8, а третья — описанию методов класса, добавленных в Java 9. Четвертая статья посвящена необходимому (с точки зрения автора) дополнению к этому классу. Ну а в пятой статье я рассказываю о том, где внутри класса следует применять Optional, подвожу итоги и дарю каждому читателю, дочитавшему серию до конца, ценный подарок.

В последней версии Java Microbenchmark Harness (JMH) появился новый профайлер — dtraceasm, долгожданный порт perfasm на Mac OS X, который умеет показывать ассемблерный профиль Java-бенчмарка.

Блиц-опрос показал, что не всем понятно, как в принципе возможно, получив на входе Java-метод, на выходе показать ассемблерный листинг скомпилированного метода с самыми горячими инструкциями, их распределением и небольшим профилем вида "А еще 5% времени виртуальная машина провела в методе Symbol::as_C_string(char*, int)".

В процессе портирования perfasm выяснилось, что на самом деле™ все не очень сложно и появилось желание рассказать, как такой профайлер устроен.

Для понимания статьи крайне желательно ознакомиться с JMH, например, посмотрев на примеры его использования.

IntelliJ IDEA содержит тысячи инспекций для Java-кода. Большинство из них работает как продвинутые регулярные выражения: по определённому шаблону они ищут фрагменты программы, которые выглядят как опечатки, избыточны, некрасивы или могут работать медленно. Но есть инспекция совсем другого рода. У неё несколько странное название: «Constant conditions & exceptions». В действительности она выполняет анализ потоков данных в Java-методах с помощью так называемого «символьного выполнения». В результате такого анализа могут обнаружиться некоторые подозрительные факты. Вот некоторые примеры таких фактов:

• Разыменование ссылки может привести к NullPointerException
• Условие всегда истинно или ложно
• Индекс массива всегда за пределами допустимых границ
• Приведение типа может привести к ClassCastException

На хабре публикуют перевод статей про участие в open source продуктах и складывается впечатление что жизнь, полная энтузиастов, где-то за границей. Что новичку страшно участвовать в крупных проектах, что у него обязательно должны быть там кураторы и его pull request вместе с ним точно пройдет через все круги ада.

Опыт друга, новичка в open source, говорит об обратном. Первый его pull request #11680 приняли в звездный spring-boot без обсуждения и без единого комментария от мейнтейнеров. Его исправления будут доступны уже в версии 2.0.0.RC1



Не боги горшки обжигают. Рассуждения о возможности стать контрибьютором крупного проекта на github…

Нам с mpryakhin, моим коллегой из CleverDATA, удалось съездить в британскую столицу на Java-конференцию  – Jax London 2017. На прошлой неделе вы уже читали о Chaos Engineering, lambda выражениях, катастрофичных багах и Continuous Delivery Java приложений в контейнерах.

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

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

Так как цена был подъемная (10 000 р. за основы языка — java core) и в QA знание языка программирования является жирным плюсом — то я, недолго раздумывая, согласился.
Постараюсь кратко описать плюсы, минусы, а также свои впечатления от данного мероприятия.

Начну с плюсов

1) Онлайн занятия (как плюс так и минус). Постигать программирование удобно дома, необходим только нормальный инет и микрофон. Ехать никуда не нужно, обучаться можно, лежа на диване в пижаме, попивая кофеек.

Для участников курсов весь вспомогательный материал расшарен и находится в открытом доступе.Все видеозаписи занятий выкладывались на google диск, а книги и доп. материалы можно было найти на гит лаб. Там же задавалась домашка. Для программирования использовали IntelliJ IDEA, домашку для проверки отправляли в репозиторий на Bitbacket через GIT (да-да, с ним тоже обучали работать). Несомненный плюс онлайна заключается в том, что все необходимое для занятий расположено на трех соседних вкладках браузера.

2) Относительно небольшая группа учащихся. На момент когда я начинал занятия, в группе было 4 человека. А учитывая, что преподавателей было 3, то они могли уделить достаточно внимания и, в какой то степени, индивидуальный подход каждому ученику.

3) Хороший преподавательский состав. В менторах были ребята с неплохим опытом работы в программировании. Они хорошо объясняли материал. Старались подробно разбирать задачи, и почти всегда были на связи. При возникновении вопроса можно было договориться, созвониться по скайпу и в тот же день решить проблему, даже если занятия в этот день не было.

Алоха, пипл! Меня зовут Олег Анастасьев, я работаю в Одноклассниках в команде Платформы. А кроме меня, в Одноклассниках работает куча железа. У нас есть четыре ЦОДа, в них около 500 стоек более чем с 8 тысячами серверов. В определенный момент мы поняли, что внедрение новой системы управления позволит нам более эффективно загрузить технику, облегчить управление доступами, автоматизировать (пере)распределение вычислительных ресурсов, ускорить запуск новых сервисов, ускорить реакции на масштабные аварии.

Что же из этого получилось?

Представим, что в коробке находятся кот, радиоактивное вещество и колба с синильной кислотой. Вещества так мало, что в течение часа может распасться только один атом. Если в течение часа он распадётся, считыватель разрядится, сработает реле, которое приведёт в действие молоток, который разобьёт колбу, и коту настанет карачун. Поскольку атом может распасться, а может и не распасться, мы не знаем, жив ли кот или уже нет, поэтому он одновременно и жив, и мёртв. Таков мысленный эксперимент, именуемый «Кот Шрёдингера».



Класс Optional обладает схожими свойствами — при написании кода разработчик часто не может знать — будет ли существовать нужный объект на момент исполнения программы или нет, и в таких случаях приходится делать проверки на null. Если такими проверками пренебречь, то рано или поздно (обычно рано) Ваша программа рухнет с NullPointerException.

Эта статья возникла из-за одной моей ошибки и двух багов — по одному в Chromium Headless и ChromeDriver. В результате пришлось собрать всё это из исходников (в статье есть подробнейшая инструкция), отладить цепочку взаимодействия Selenium<->ChromeDriver<->Chromium в отладчике IntelliJ IDEA и Microsoft Visual Studio, покопаться в Java, C++ и JS.

Статья будет интересна тем, кто хочет понять, чем им грозит переход на Selenium + Headless Chrome и как с этим жить. А также всем, кто просто хочет немного поглумиться над несчастным быдлокодером.

Под катом есть пачка скриншотов (трафик!).

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

Вначале напомню названия участвующих продуктов. Их три штуки:

• Chromium — это браузер. Небрендированная версия Google Chrome, без автообновлений, анальных следящих зондов, но и без несвободных компонентов типа кодеков.
• Chromium ChromeDriver — это часть Chromium, которая отвечает за управление им с помощью внешних инструментов. Это standalone фронт-сервер (отдельный exe-файл), реализует стандарт W3C WebDriver и использует в качестве бэкенда Chrome DevTools.
• Selenium и его Selenium Chrome Driver — эта штука предоставляет Java API для управления Хромиумом. Джава тут не принципиальна, на JavaScript и jWebDriver было бы то же самое (а на Puppeteer — возможно, нет, ибо он использует DevTools напрямую).

Всё вместе даёт нам в руки браузер, управляемый с помощью API на Java, JavaScript и так далее.

Вспомнили? Поехали дальше.

Введение

В конце прошлого года мне потребовался undo/redo инструмент для Java-проекта, который, помимо стандартных для этого концепта задач, умел бы сохранять историю команд и корректно обрабатывать привязку к меняющемуся адресному контексту (это с прицелом на мой готовящийся проект для Android и его регулярное пересоздание вьюшек). Поискал, не нашел, взялся.

Результатом стала библиотека JUndo.

Нихао!

Введение

Я долго ничего не писал, потому что ЕГЭ само себя не сдаст, но к Балтийскому конкурсу я не мог не написать чего-нибудь классное. Хороших идей из ниоткуда я выдавить не мог, поэтому решил окунуться в абсолютно незнакомую мне на тот момент(пол месяца назад) тему, в мир блокчейна, криптовалют, смарт контрактов и других умных английских слов. На уроках утыкался в телефон, читая множество текстов про блокчейн, peer2peer сети и все такое, постепенно разбираясь. Все пошло легче, когда я начал писать простые прототипы на Javascript'e: в очередной раз убеждаюсь, что в коде все понятнее, нежели на тексте. В итоге, когда я вроде разобрался, я определился с темой работы, которую видно в заголовке статьи.

В первом эпизоде у нас получилось вытянуть информацию из Mesos Marathon прямиком в бины Spring Cloud-а. Вместе с тем у нас появились первые проблемы, одну из которых мы разберём в текущей части повествования. Давайте вспомним нашу конфигурацию подключения к Marathon-у:

spring:  
    cloud:
        marathon:
            scheme: http       #url scheme
            host: marathon     #marathon host
            port: 8080         #marathon port

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

Язык php часто ругают, обычно необоснованно. Особенно удивляет, что javascript ругают меньше. Зачастую это делают люди, которые писали на нем 10+ лет назад, когда язык был действительно чертовски плох, да и разработчики в те времена не задумывались над качеством кода. Посмотрите хотя бы на код wordpress, который до сих пор вызывает шок.

Ругают необоснованно, но проблемы у языка, конечно же, есть, и они серьёзные. Разуметеся, если сравнить последние релизы php7 (с нормальным ООП и строгим тайпхинтингом) и php4, то разница будет колоссальная. Однако и в последних версиях языка не всё гладко, и до java/c# пока что очень далеко. Более того, берусь утверждать, что будущее php тоже довольно сомнительно (с точки зрения типов).

Другими словами, давайте рассмотрим предметно, что хорошо и что плохо в php с точки зрения типизации.

Друзья, мы с kent2171, моим коллегой из CleverDATA, побывали на одной из крупнейших конференций Европы – Jax London 2017, посвященной экосистеме Java и всему, что ее окружает в современном мире, – микросервисной архитектуре, Continuous Delivery, а также культуре и практикам DevOps.

Объем полученной за четыре дня информации оказался настолько огромным, что обзор пришлось разбить на две части. Сегодня мы предлагаем вашему вниманию первую часть, в которой расскажем о Chaos Engineering подходе к построению устойчивых распределенных систем, а также о том, как контейнеризация java-приложений сказывается на процессе разработки и какие преимущества кроме синтаксиса дают lambda выражения. Это основные моменты. Остальное — под катом.