Про Story Points можно услышать что угодно. На одной конференции спикер всерьёз говорил: «Story Points — это плохо. Не используйте их вообще. Плохая практика».

Но почему столько хейта? Неужели всё действительно так плохо? Или дело не в Story Points, а в том, как именно их используют?

Меня зовут Семён, я тимлид в МТС Аналитике, бывший Java-разработчик, сертифицированный Scrum Master и преподаватель курса по Java в МФТИ. Веду блог. За годы работы много раз видел, как команды мучаются с оценками задач.

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

Будет и про типовые ошибки, и про работающие подходы — чтобы планировать задачи без лишней боли. Спойлер: идеального способа оценки задач не существует. Зато есть вполне рабочие способы не сойти с ума и при этом нормально планировать работу.

Последние год-полтора я натыкаюсь на статьи и доклады (особенно в англоязычном сегменте) о том, что JOOQ – это современная и более крутая альтернатива Hibernate.

Скажу сразу, что я считаю JOOQ отличной библиотекой (именно библиотекой, а не фреймворком, в отличие от Hibernate). Он прекрасно справляется со своей задачей – работой с SQL в режиме статической типизации, чтобы отловить большинство ошибок на этапе компиляции.

Но когда я слышу аргумент, что время Hibernate прошло и пора все писать на JOOQ, для меня это звучит примерно так же, как то, что время реляционных БД прошло и теперь нужно использовать только NoSQL. Звучит смешно? Но по меркам истории буквально вчера такие разговоры велись вполне серьезно.

Я думаю, дело кроется в непонимании корневых проблем, которые решают эти два инструмента. Этой статьей я хочу ответить на эти вопросы.

Когда речь заходит об авторизации, роли вступают в игру. Если модель плоская, то все просто. Пользователь обладает определенным набором привелегий и при запросе достаточно лишь проверить, что нужное право доступа присутствует в коллекции. Но как быть, если у пользователя могут быть разные наборы ролей для разных сущностей? Например, я обладаю ролью EDITOR в посте в социальной сети, но имею только VIEWER в другом. Также могут быть определены правила наследования. Если админ выдает дает мне роль EDITOR, то я автоматически приобретаю привилегию VIEWER. При этом, если я EDITOR, роль ADMIN у меня не появляется.

Как увязать все эти детали в коде и при этом не превратить продукт в большую кучу грязи? В рамках этой статьи я расскажу вам:

1. Как реализовать наследование ролей в Java?

2. Как протестировать полученную иерархию?

3. Как применить решение в рамках Spring Security?

Всем привет! Меня зовут Семен. Я Java-разработчик и руководитель группы Java-разработки в Центре Big Data компании MTS Digital. В этом посте я хочу поговорить о Release Notes. Что это такое, почему не стоит писать их вручную и какие есть способы автоматизации. Покажу и реальный пример того, как организована  работа с Release Notes в нашем проекте.

Год назад я написал статью про DI в Spring/Java EE. Мой тезис звучал довольно категорично: "DI через конструкторы является единственно правильным. Все остальное – от лукавого". Прошло время, я пообщался с разными разработчиками на эту тему, сменил проект, компанию, провел множество собеседований, отсмотрел большое количество строк на code-review и сейчас могу сказать, что не все так однозначно. Давайте наконец разберемся, как же все-таки инжектить правильно.

Любите Spring? А Spring Data? Я тоже люблю. Если хотите разобраться, почему же возникает этот unexpected transaction rollback, а также быть уверенным, что транзакция отменится, а не закоммитится, добро пожаловать под кат.

NullPointerException - одна из самых раздражающих вещей в Java мире, которую был призван решить Optional. Нельзя сказать, что проблема полностью ушла, но мы сделали большие шаги. Множество популярных библиотек и фреймворков внедрили Optional в свою экосистему. Например, JPA Specification возвращает Optional вместо null.

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

Все мы любим Spring. Или не любим. Но по крайней мере знаем. Если вы Java-программист, то вероятно используете этот фреймворк каждый день в своей работе. Spring — это огромная платформа, которая предоставляет большой функционал. Тем не менее во главе угла стоят две вещи — это DI (Dependency Injection) и IoC (Inversion of Control). Концепции, которые были призваны, чтобы сделать наш код более читаемым и поддерживаемым. Но к несчастью, все оказалось не так радужно. Именно это мы сегодня и обсудим.

Вступление

Название поста действительно «холиварное», но на мой взгляд и у Java, и у популярной библиотеки Guava есть ряд архитектурных проблем, которые в перспективе приводят к двусмысленностям и разногласиям в команде.