Эта статья рассчитана на широкий круг читателей, которые хотели бы узнать, что такое Реактивное Программирование. Цель этой статьи — сформировать у вас базовые Ментальные Модели Реактивного Программирования (ММ РП), не вдаваясь в технические детали.

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

В одной Enterprise системе жила-была компонента. Эта компонента собирала данные от пользователей о неком продукте и записывала их в банк данных. И состояла она из трёх стандартных частей: пользовательского интерфейса, бизнес-логики на сервере и таблицы в банке данных.

Работала компонента хорошо, и несколько лет к её коду никто не притрагивался.

Но вот однажды, ни с того ни с сего, начали твориться с компонентой странные дела.

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

Основной тезис этой статьи: Разработку программного обеспечения следует рассматривать как материализацию идей посредством трансформации ментальных моделей в программный код.
В статье описывается парадигма материализации идей в программной инженерии (engl.: RPSE: Reification as Paradigm of Software Engineering).

Практически любое изложение истории компьютеров начинается с упоминания изобретенного в древнем Египте абака. В зависимости от детальности изложения далее перечисляются изобретения китайского варианта абака, различных видов счетов с костяшками, вычислителей на основе зубчатых колёс, изобретения и промышленного выпуска арифмометров Тома де Кальмару, изобретения разностной машины Чарльзом Бэббиджем и т.д. вплоть до появления современных компьютеров. От абака до iPad история компьютеров представляется как цепочка изобретений изделий из дерева, металла и других материалов.

Однако, первые компьютеры (computers) были людьми! И эта статья о том, как они из людей превратились в то, что мы имеем сейчас.

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

В этой статье мы рассмотрим вопрос, стоит ли Optional использовать во всех тех местах, где могут появиться нулевые значения. Я приведу также мнение Brian Goetz, архитектора языка Java v Oracle об этом классе, и конечно, исполню данное в прошлой статье обещание — поощрю каждого читателя, прочитавшего все статьи серии, ценным подарком.

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

Если сервис возвращает Optional, о причине мы ничего не узнаем. Значит надо использовать что-то похожее на Optional, но содержащее информацию об ошибке в случае неуспеха.

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

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

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

«Принципу Анны Карениной» посвящено немало научных публикаций и даже отдельная статья в Википедии. Применим к ИТ и программированию? А может он уже работает против вашего проекта?

Подвержены программисты эмоциональному выгоранию больше чем представители других профессий? Если да — какие факторы риска сушествуют и как с ними бороться?

Напомню: арность (англ. arity) — это количество параметров функции. Соответсвенно мульти-арные (это слово можно писать вместе или раздельно) функции — это функции с несколькими параметрами. В Java 8 были введены функции с одним и двумя входными параметрами. А как быть если параметров больше?

Нет, это не опечатка. В этой заметке речь пойдет не о структурах, а именно о текстурах программного кода.