Доступно про асимметричное шифрование

На днях попалась очень хорошая статья про основы асимметричного шифрования – написана доступным языком, очень рекомендую для прочтения.

Асимметричное шифрование. Как это работает?

Posted in Почитать | Tagged , , , , | Comments Off on Доступно про асимметричное шифрование

Spring Boot + JaCoCo

Если вам понадобится прикрутить анализ покрытия тестами Spring Boot проекта, правильной отправной точкой на текущий момент будет изучение вот этого pom.xml: http://www.eclemma.org/jacoco/trunk/doc/examples/build/pom.xml а не какого-нибудь другого 😉

Posted in Main menu | Tagged , , | Comments Off on Spring Boot + JaCoCo

Философско-романтический пост про архитектуру ПО

“Архитектура – это то, что трудно изменить на поздних стадиях разработки. Поэтому ее должно быть как можно меньше.”

Мартин Фаулер

Различия между архитектурой и дизайном

Различия между архитектурой и дизайном

Этот романтический пост навеян вчерашней встречей #uadevclub, посвященной теме Архитектуры, дизайна и реализации ПО. Вы дождитесь когда коллеги опубликуют на сайте видео и презентацию доклада и когда их посмотрите, возвращайтесь сюда. А я пока оставлю тут свои заметки, чтобы не забыть 😉 .

Итак, немного философии о том, какие мысли мне пришли в голову после четырехчасовых разборов полетов о том, где же проходит грань между архитектурой дизайном и реализацией. Continue reading

Posted in Main menu, Soft | Tagged , , | 1 Comment

Spring 3 MVC + Maven + JBoss

Если вы задаете себе вопрос, как быстро разобраться с разработкой на базе Spring MVC, возможно, вам будет полезно познакомиться с одним из имеющихся уже архитипов. На днях, коллега познакомил меня с замечательным архитипом: jboss-spring-mvc-archetype.

Сгенерированный в результате проект будет очень удобен в изучении Spring MVC, т.к. состоит из минимально необходимого набора компонент. И да, самое главное, этот проект действительно рабочий, он действительно собирается и легко деплоится в JBoss 7 😉 .

Для того чтобы сгенерировать проект из командной строки, необходимо просто выполнить следующую команду:

mvn archetype:generate -DgroupId=com.your.package.name -DartifactId=your-project-name -DarchetypeArtifactId=jboss-spring-mvc-archetype -DarchetypeVersion=1.0.0.Final -DarchetypeGroupId=org.jboss.spring.archetypes

В результате в текущей директории будет создана директория your-project-name в которой вы найдете все необходимые компоненты для быстрого старта.

Не забудьте, что для начала работы вам необходим предустановленный Maven с объявленной системной переменной M2_HOME.

Так же, если вы хотите работать с проектом в Eclipse, вам нужно конвертировать проект следующей командой:

mvn eclipse:eclipse

Удачи!

Другие статьи на эту же тему:

 

Posted in Java, Main menu | Tagged , | Comments Off on Spring 3 MVC + Maven + JBoss

Дизайн-шаблон Visitor из портфолио GoF (Часть 2)

На днях, коллеги обвинили меня в том, что я забыл дописать вторую часть статьи про Visitor. Я проверил, и действительно, это так 🙁 . Поэтому, сегодня мы продолжим знакомиться с этим дизайн-шаблоном. Первую часть статьи вы сможете найти тут: Дизайн-шаблон Visitor из портфолио GoF.

Давайте начнем “улучшать” предыдущий дизайн с того, что постараемся сделать так, чтобы наша структура файловой системы (ФС) не нарушала “Open-Close Principle”. Для этого нам необходимо обеспечить следующее:

  • Операции объявленные в интерфейсе Node, должны быть “универсальными”;
  • Кол-во этих операций должно быть сведено к минимуму;

Дизайн ФС, удовлетворяющий "Open/closed principle"

Соответственно, мы объявим всего одну-единственную операцию +accept(visitor:Visit). Не пугайтесь, дальше станет понятнее.

На что похожа эта операция?! Она похожа на входную дверь вашего дома, через которую к вам в гости может зайти как “Сантехник”, так и “Электрик”. “Друзья” и “Враги” тоже смогут проходить в вашу дверь, но только в том случае, если они будут реализовывать интерфейс Visitor, по имени которого и был назван сам шаблон. Я не зря перечислил друзей и врагов – смысл в том, что кол-во типов “посетителей” которые буду посещать вас и вашу библиотеку может разрастаться со временем без больших проблем для вашего проекта, но при одном “НО!”. Об этом “НО”, мы поговорим в конце статьи, поэтому, наберитесь терпения.

Все вышесказанное возможно только благодаря тому, что с точки зрения полиморфизма все “посетители” для классов вашей библиотеки буду равнозначны и соответствовать типу Visitor. Сам же интерфейс Node, теперь навязывает всем своим наследникам только один метод, который будет достаточно несложно реализовать в каждом из классов.

Теперь давайте разберемся с посетителями:

Visitor

Интерфейс Visitor определяет три перегруженных метода +visit(type:Type) для каждого типа данных с которым он сможет иметь дело. Тут вам может показаться, что мы противоречим сами себе и начинаем нарушать OCP, но уже в другой части дизайна 😉 . Отчасти вы будете правы, это и есть как раз то “НО!”, которое нам еще предстоит изучить. Но на самом деле разгадка прячется в том факте, что на самом деле контракт Visitor не будет расширяться, т.к. вряд ли вы сможете придумать в нашей файловой системе нового наследника Node. Понимаете?! Суть в том, что кол-во классов наследников Node у нас не будет расти, а значит и количество перегруженных методов visit(…) в будущем не увеличиться. Это, кстати, позволит нам избавиться от применения instanceof в нашем коде.

В тоже самое время, этот подход позволяет каждому конкретному посетителю работать с конкретным экземпляром класса наследника Node по своему, правильно реализуя конкретный метод visit(…). Под правильной обработкой мы можем понимать, как реализацию бизнес-логики, таки отсутствие таковой или генерирование исключительной ситуации.

Диаграммы готовы, теперь осталось понять как они взаимодействуют, разобраться во всей “магии” происходящего в классах.

В первом приближении использование шаблона выглядит следующим образом: Клиент, при возникновении конкретной потребности, создает (лично, либо через делегата) экземпляр конкретной команды, например “Сантехника” (обязательно реализующей интерфейс Visitor) и отправляет его в метод accept(Visitor visitor) конкретного экземпляра структуры, над которой нужно провести определенную операцию. Конкретный элемент нашей файловой системы, получив экземпляр посетителя (он не знает о его конкретном типе и работает с ним исключительно как с посетителем), вызывает у него метод visit(this) и передает самого себя в качестве аргумента. Очень часто на этом метод visit и заканчивается, но не обязательно 😉 .

Внимательно перечитайте последний абзац – именно в нем и объясняется работа шаблона.

Далее, если помните, в посетителе методы visit(…) перегружены под каждый тип данных и соответственно либо компилятор, либо виртуальная машина (VM) обеспечат подстановку нужного виртуального метода во время выполнения кода. Т.е. по сути мы избежали использование instanceof, переложив его вызовы на компилятор и VM. Сами же методы могут быть реализованы по разному – что позволяет, например, MkDirVisitor-у при посещении директории создать в ней новую поддиректорию, а при посещении файла – выбросить исключение, и т.д. и т.п.

В данном случае, мы получаем библиотеку посетителей, которая не нарушает ни OCP, ни LSP. А это значит, что мы можем свободно наращивать библиотеку наших команд в файловой системе, не перерабатывая саму ФС, просто реализовывая в каждой из команд по три метода для каждого элемента (Dir, File, List).

Теперь давайте поговорим про “НО”:

  • Все вышесказанное, справедливо только при условии, что структура данных (в нашем случае ФС) не будет разрастаться, т.к. появление нового наследника Node чревато для нас полной переработкой всей библиотеки команд 🙁
  • Внедрение шаблона Visitor оправдано в том случае, когда кол-во команд заранее не известно и будет расширяться / сужаться в будущем;
  • Шаблон плохо реализуется в платформах не поддерживающих перегрузку методов (например, Flex).

Ну, и напоследок – задание для пытливых и внимательных умов: Наверняка в ходе изложения вы захотели реализацию метода accept(Visitor visitor){visitor.visit(this);} вынести в абстрактный класс!? Что бы избежать copy/paste 😉 . Возможно ли это и если да, то в каком случае?

P.S. Ответы на вопрос вы можете разместить в комментариях к статье. Удачи!

Posted in Java | Tagged , , , | 4 Comments

How-To mvn tomcat:deploy, для TomCat 7.x

Если вы первый раз пытаетесь заставить Maven задеплоить ваше приложение в 7-й Tomcat, вас может поджидать несколько неожиданностей.

Во-первых, ознакомьтесь со списком ролей – manager-gui, manager-script, manager-jmx и manager-status. Вам понадобится, чтобы пользователь, под которым плагин tomcat-maven-plugin будет выполнять деплоймент, входил в роль именно manager-script.

Затем вы можете ознакомится со статьей How to deploy Maven based war file to Tomcat и последовательной выполнив все инструкции, дойти до конфигурироваия tomcat-maven-plugin в вашем pom.xml.

Теперь самое главное – в 7-ке url http://127.0.0.1:8080/manager не работает! Правильный – http://127.0.0.1:8080/manager/text . Если вы все сделали правильно, то mvn tomcat:deploy | tomcat:undeploy | tomcat:redeploy должны заработать без проблем.

Если вам, как и мне, станет интересно, что курили разработчики 7-ки придумав такой “урл”, ответ может скрываться во фразе: “manager-script – Allows access to the plain text interface“. По всей видимости, “../text” противопоставляется JMX и соответственно роли manager-jmx.

  • manager-gui – Allows access to the html interface
  • manager-script – Allows access to the plain text interface
  • manager-jmx – Allows access to the JMX proxy interface
  • manager-status
Posted in Java | Tagged , , | Leave a comment

Как подойти к изучению дизайн-шаблонов проектирования

Мне часто задают вопрос: “Как начать изучать дизайн шаблоны проектирования?” Единого рецепта, естественно, нет. Но, я бы посоветовал следующую маршрут:

  • GRASP
  • SOLID
  • Потом можно взять или книгу притянутую к джаве или почитать Джона Влисидиса «Pattern Hatching» – она есть в переводе на ру.
  • Краем глаза можно глянуть на LePUS3
  • Потом можно глянуть сюда: http://junit.sourceforge.net/doc/cookstour/cookstour.htm
  • Начать читать Мартина Фаулера «Рефакторинг» ( на самом деле связка Рефакторинг + TDD + jUnit + Patterns очень плотная, а Эрик Гамма, Кент Бек и Фаулер чуть ли не друзья 😉 )

Первая итерация – читайте “поверхностно”, во второй раз, после перерыва, уже более вдумчиво.

P.S. И да, не начинайте с GoF

Posted in Soft, Почитать | Comments Off on Как подойти к изучению дизайн-шаблонов проектирования

Что почитать на этой неделе!?

Если у вас стоит вопрос “Что почитать?” обратите внимание на следующие линки:

RESTful Web services: The basics

Build RESTful web services with the Spring 3 MVC HttpMessageConverter feature

Content negotiation

Transaction strategies: Understanding transaction pitfalls

Posted in Почитать | Comments Off on Что почитать на этой неделе!?

Пример использования Hibernate в качестве JPA провайдера совместно со Spring Framework

Ни для кого не секрет, что в настоящий момент Hibernate является стандартом “de facto” в ORM-мире. В то же самое время промышленным стандартом “de jure” является JPA – с этим тоже сложно поспорить. Более того, начиная с версии 3.6.* Hibernate полностью поддерживает стандарт JPA (разных версий), а это значит, что есть возможность вести разработку на базе промышленного стандарта, не отказываясь от любимого многими инструмента. Тем не менее, в сети довольно мало компактных и легких для понимания примеров, иллюстрирующих эту возможность, особенно когда идет речь о связке со Spring Framework. Именно ей (связке Spring + Hibernate as JPA) и будет посвящена эта статья.

Continue reading

Posted in Java, Main menu | Tagged , , | 4 Comments

Domain-Driven Design quickly

На днях закончил читать своеобразную хрестоматию к известной книге Эрика Эванса, книга называется «Domain-Driven Design quickly» и свободно доступна для скачивания на сайте infoq.com .

Continue reading

Posted in Java | Tagged , , | Comments Off on Domain-Driven Design quickly