Пою что вижу, или вижу, что пою?

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

Привет, Хабр!

Не так давно мы сами себе поставили задачу — построить SPA-приложение. Сложное, большое, быстрое, с поддержкой множества устройств, без утечек памяти. К тому же, постоянно развивающееся, чтобы его было легко поддерживать. В общем, как мы и любим — всё и сразу.

Тема SPA-приложений и javascript-приложений в целом не нова, но нам не удалось найти даже на платных ресурсах основательных руководств по разработке приложений. Они являются скорее рассказом о той или иной MV*-библиотеке, чем примером для подражания. При этом не рассматриваются примеры разбиения по слоям, построения иерархий наследования и тонкостей наследования в javascript и т.д.

Мы попробуем зайти с другой стороны и описать, скорее, ход мыслей при разработке (с кодом и ссылками), чем какой-то конкретный инструмент. Начать мы вынуждены с уровня hello world, чтобы задать одну стартовую точку для читателей и писателя. Но уже со второго раздела повествование резко ускорится.

Мы считаем, что данная статья будет полезна:

1. Front-end разработчикам, у которых уже есть небольшой опыт, но хочется вырасти.
2. Back-end разработчикам, которым в какой-то момент пришлось начать заниматься js-разработкой и которые чувствуют некую неуверенность при работе с javascript.
3. Верстальщикам, которые начали заниматься js-разработкой и хотели бы прокачать свои навыки.

Чтиво получилось весьма объемистым, но надеемся, что настолько же полезным.

В данной статье я попытаюсь описать несколько способов, а точнее 6, как добавить security для rest сервиса на Java.

Перед нашей командой была поставлена задача найти все возможные способы добавить security к rest сервису. Проанализировать все за и против и выбрать наиболее подходящий для нашего проекта. Когда я начал искать такую статью в Гугле ничего подходящего не нашел, а были лишь фрагменты и мне пришлось собирать эту информацию по крупицам. Так что думаю, данная статья будет полезна и другим Java разработчикам, пишущим back-end. Я не буду утверждать, что какой-то из этих способов лучше или хуже, все зависит от поставленной задачи и конкретного проекта. Поэтому какой из шести способов подходит больше всего вашему проекту решать только Вам. Я постараюсь описать принцип каждого из подходов и дать небольшой пример с использованием Java и Spring Security.