1 февраля старт курса Junior Enterprise Java Developer

Добрый день.
1-го февраля стартуют курсы Junior Enterprise Java Developer.
Происходит набор как в группу в реале — занятия проходят в Центре (пер.Театральный 11/13) по вторникам и пятница 19.00-21.00, так и удаленно — видео лекций становятся доступными с задержкой 1 день. Проверка лабораторных, ответы на вопросы в обоих курсах не отличаются.

Курс рассчитан на слушателей в полной мере владеющих языком Java (скажем, знающих что такое anonymous inner class) и JDK (коллекции, I/O, исключения). Цели курса:
— рассмотреть архитектуру и особенности построения минимального Enterprise-приложения
— изучить на примерах минимальный набор API/библиотек необходимых для создания Enterprise-приложения

План лекций:
1-2: примеры основных шаблонов проектирования (Builder, Singleton, Factory Method, Adapter, Decorator, Composite, Facade, Proxy, Command, Iterator, Listener, Strategy, Template Method).
Литература: Head First «Паттерны проектирования»
Литература: Марк Гранд. «Шаблоны проектирования в JAVA.»
Литература: «Приемы объектно-ориентированного проектирования. Паттерны проектирования»

3-6: построение ER-модели по техническому заданию, трансляция ER-модели в реляционную модель, устройство и администрирование MySQL/InnoDB, SQL.
Литература: Дейт «Введение в системы баз данных». Глава 14

7-8: JDBC API, шаблон DAO, другие шаблоны доступа к данным.
9-12: Servlet API, шаблон MVC, HTTP, начальные сведения о HTML/CSS.

13: Test Driven Development: инструмент создания модульных тестов JUnit.
14: Test Driven Development: инструмент создания mock-ов Mockito.
Покрываем наше приложение модульными тестами.

15: Logging в Enterprise-приложении — Log4j.
— компоненты: loggers, appenders, layouts
— Logger named hierarchy. Два принципа построения иерархии: by locality, by functional areas. Root logger. Level inheritance.
— Configuration: JavaBeans style configuration, propertie files, xml files
— Стратегия реакции на ошибки в appenders
— Concrete: ConsoleAppender, AsyncLogger, DaylyRollingAppander, PatternLayout
— Log4J vs Java logging API vs SLF4J
Литература: «The Complete Log4j Manual»

16: Сборка Enterprise-приложения — Maven.
— default Maven project structure
— artifacts: artifactId, groupId, version, scope
— dependencies: transitive dependencies
— repositories: local, remote, Central Repository
— project build lifecycle: phases, goals, default lifecycle
— plugins/goals: customizing war, choose compiler, configure intergration tests, ...
— configuration inheritance: parent POM, Super POM
— multimodule project
— shortly: Maven vs Ant vs Gradle
Литература: «Maven by Example»

17-20: реализация логики минимального Enterprise-приложения: регистрация пользователя, log in/log out, remember me, хранение корзины покупок, многоязычие, пользователи с различными ролями (пользователь, менеджер, администратор)

21-24: картина «в целом»: Dependency Injection + Inversion of Control шаблоны, функциональные и нагрузочные тесты, работа с информацией, накопленной приложением (отчеты, анализ, статистическая информация).

Обучение состоит из:
— 24 двухчасовых лекций
— проработка литературы (вы получаете всю необходимую литературу в электронном виде и рекомендации на что стоит обратить внимание)
— лабораторные — по каждой теме есть лабораторные для самостоятельно проработки
— ответы на технические вопросы по курсу в skype

По окончании курсов мы организуем собеседования в 4-6 компаний Харькова.

Пример реальной лекции можно глянуть на youtube — «Основы JDBC»

Все занятия ведет профессиональный программист уровня Senior/Lead Developer.

Вы можете связаться в любое время с нашим администратором:
тел: 063-048-76-63
skype: KharkovITCourses

По предварительной договоренности с администратором вы можете посетить любые две лекции бесплатно и пообщаться с лектором.

P.S. Для удаленных слушателей видео со всех лекций будет доступно с задержкой в 1-2 дня.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

За видео огромнейшеееееееееее спасибо, лучшего еще не видел нигде, все четко и понятно. Хотя, когда 1-й раз просматривал, было немного вопросов, но сейчас 2-й раз просматриваю все сначала, все вопросы отпали, уже 2 блокнота списал. Надеюсь, вы не против, если я буду сюда писать вопросы, если возникнут.
П.С. я еще новые видео не успел просмотреть, но заметил, что с утра было 150 видео, а до обеда или после стало 147, это повтор был ?

За видео огромнейшеееееееееее спасибо, лучшего еще не видел нигде, все четко и понятно. Хотя, когда 1-й раз просматривал, было немного вопросов, но сейчас 2-й раз просматриваю все сначала, все вопросы отпали, уже 2 блокнота списал.
Пожалуйста:)
Я считаю, что нельзя считаться «нормальными курсами» без предоставления возможности просматривать слушателям лекции в записи. Рад, если видео Вам помогает.
.
Надеюсь, вы не против, если я буду сюда писать вопросы, если возникнут.
Да, конечно, задавайте. Приветствую любую критику. У меня есть проблемы с обратной связью. Во время лекции слишком сильно сконцентрирован на двухчасовом материале и тяжело понять — нормально ли рассказываю.
.
П.С. я еще новые видео не успел просмотреть, но заметил, что с утра было 150 видео, а до обеда или после стало 147, это повтор был ?
Вверху есть режимы просмотра канала — uploads, playlists, likes, feed, comments. Я рекомендую смотреть в режиме playlists — это куски видео собранные в лекции (обычно одна лекция — это около 3-4 кусков).
Количество лекций должно только расти. В данный момент у нас по лекциям на ютубе занимается около 10 удаленных слушателей. Количество кусков могло уменьшится — возможно была какая-то ошибка оператора и он ее исправлял.

Т.е. материал мы принципиально не удаляем, только если была ошибка оператора (залил дубликаты, лишний раз порезал крупные куски на мелкие, ...).

Я, так понимаю, вторая лекция вышла? Но там в сумме с первой не 13 шаблонов.

Да, так вышло, что сильно сконцентрировался на
— Chain of Responsibility (на примере java.servlet.Filter)
— Decorator (на примере ServletRequestWrapper + ServletResponseWrapper, и примеров из java.io)
— Adapter — примеры из java.io
— Builder — пример StringBuilder и собственный UserBuilder
Остальные шаблоны буду рассказаны в ходе курса.
Приношу извинения, но польза от детального рассказа о Filter + ServletRequestWrapper как введения в Servlet API перевесила здравый смысл:)

Начал смотреть — одна вода. Бла-бла-бла.

Вы могли бы разговаривать корректнее, без наездов?
---
Это первая лекция, вышла очень длинной. Фактически там три части:
1) административная — как будем обучаться
2) общая характеристика курса — что учим, какие темы, как они связаны (SQL, MySQL, JDBC, Servler API, Maven, Log4j, JUnit, Mockito) и «выходы» на третий курс (Middle Java Enterprise Developer — еще в разработке) — jQuery, JSF, Spring, Hibernate
3) Шаблоны проектирования: общая характеристика шаблонов, их роли, литературы + успел разобрать 2 шаблона (Abstract Factory, Iterator)

Вы указали в качестве примера Abstract Factory — фактически все JDBC API. Это не совсем главный пример шаблона.

Нет такого понятия — «главный пример шаблона». Тот пример что в книге GoF — это пример, а не часть определения. Главное — это
Назначение
«Предоставляет интерфейс для создания семейств взаимосвязанных или взаимозависимых объектов, не специфицируя из конкретных классов.»
Тут 100% соответствие.

Ну, ок.
Все же — пара замечаний.
1) странная цепочка — Driver производит Connection, а тот уже производит Statement, PrepareStatement, CallableStatement
2) одновременно существует не один экземпляр Конкретной Фабрики.

1) странная цепочка — Driver производит Connection, а тот уже производит Statement, PrepareStatement, CallableStatement
Да, чуть длиннее чем в «классике»: Абстрактная Фабрика производит Абстрактную Фабрику, которая производит Конкретные Продукты
2) одновременно существует не один экземпляр Конкретной Фабрики.
Да, в DriverManeger одновременно могут присутствовать (быть зарегистрированными) несколько экземпляров Конкретной Фабрики. Селектором выступает jdbc url.

И кому это буквоедство нада???

Это, блин, БУКВОЕДСТВО!
Кому оно нужно???
Какие-то книжные черви собрались тут, надо ПЕДАЛИТЬ! В первую, вторую и третью очередь.

Это Мир Идей.
Проектирование, Архитектура, Дизайн — это оперирование Идеями.
Они предоставляют другой, более высокоуровневый взгляд на вещи.
Если они лично Вам даются с трудом, то это не значит, что они не нужны другим.
Мне вот с трудом дается музыка, балет и живопись:)

Шаблоны — это механизм абстрагирования, они позволяют пройти по цепочке Частное-Общее-Частное или Конкретное-Абстрактное-Конкретное. И вот как раз в моменты переходов крайне важно улавливать ньюансы.

В полку индусов прибыло

Это, блин, БУКВОЕДСТВО!
Кому оно нужно???
Формошлепам не нужно

Жернова аутсорса ...

Не уверен, что InputStream — это хороший пример реализации шаблона Iterator (как у тебя на лекции).

Пример, можно сказать, отвратительный.
Как для обучения шаблонам. Хотелось бы все же иметь методы next() и hasNext() или их аналоги порознь.
Но все по назначению: «Дает возможность последовательно обойти все элементы составного объекта, не раскрывая его внутреннего представления.»

Интересно, что если я правильно помню лекции в универе, то желательно разделять функции на Анализаторы и Генераторы.
Но тогда, самый что ни на есть правильный интерфейс итератора — это три метода:
— boolean hasNext()
— Iterator< T > next()
— T current()

У GoF так и есть:
— virtual void Next()
— virtual bool IsDone()
— virtual Item CurrentItem()

На счет Генераторов и Анализаторов — уже не помню. Киньте ссылку, а?

Так я чо, в метрвый топик пишу? Все, тю-тю, курсы ж стартовали.

Да, курсы стартовали.
Нет, топик не совсем «тю-тю»:
1) на курс есть смысл записываться даже после нескольких пропущенных лекций: пропущенное можно посмотреть на видео + основное (проект) будет впереди
2) возможно кто-то будет задавать вопросы, буду отвечать

import static org.mockito.Mockito.*;
List mockedList = mock(List.class);
verify(mockedList).add("one");
Вот последнюю строчку как сделали — не понял:(
Вот последнюю строчку как сделали — не понял:(
Мдя, а вы бы как сделали? Подумать, кстати, будет куда полезнее для вас. Если уж совсем никак -то меняйте профессию-, посмотрите в код.

Ну извините, если я вас своей тупостью обидел.

Ну извините, если я вас своей тупостью обидел.
Скорее ленью. И не меня.

Медитируйте над сигнатурой

public static <T> T verify(T mock)
Т.е. метод verify возвращает ТОТ ЖЕ ТИП, ЧТО И ПОЛУЧИЛ в виде аргумента.

Mockito — это вообще учебник по «извращениям»:)
---
Да, как понимаю, без генериков такого не сделаешь.
И вот вам аналогичная задачка:
Какое гешефт мы имеем с генерификации класса java.lang.Class< T > ?

А слабо самому что-нибудь полезное придумать? Или только из javadoc таскать?

Ну, может, когда вызываем
f(Class<t> clazz)
с аргументом, скажем, List.class, то там внутри уже знают что это не просто Class, а Class< List >, и могут работать с List, хз

phases, goals
вот тут я как раз застрял. Maven использовал, но всю эту внутреннюю теорию не понял:(

Тут на словах выходит куча синтетических сущностей. Но если кратко:
1) есть Maven
2) есть множество plugins
3) каждый plugin может выполняет несколько goals. но сам plugin пассивен
4) Maven build lifecycle представляет собой запуск последовательности phases. Phase — это абстрактная сущность, просто ее момент времени настает и все.
5) можно связывать определенные goals с определенными phases. Тогда в процессе работы maven-а, он будет проходить через последовательность фаз и дергать goal у плагинов.
.
Главное, что стоит понять: фазы предоставляет сам maven, а goals предоставляют плагины.

В чем еще важно не запутаться, так это в том, что Maven множество вещей делает по умолчанию. Скажем каждый pom по умолчанию берет предком Super POM (что-то типа java.lang.Object). И это не пустой документ!

Расписали лекцию по Maven. Вы меняете топик «на лету»?

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

Скажите, а в чем разница между Реляционной Алгеброй и Реляционным Исчислением? В общем смысле. Зачем тот же Дейт приводит две разных модели?

википедия 5 абзац четко написано

«Реляционная алгебра и реляционное исчисление эквиваленты по своей выразительной силе[4]. Существуют правила преобразования запросов между ними.»
.
Это не ответ.
Это как на вопрос «в чем разница между Java и C#?», сказать что оба языка Turing complete. Вы сравнили их по мощности, но не объяснили зачем их 2. Почему не выбрали для изучения что-то одно?

1) В гугле можно найти, если захотеть.
2) Не знаю, кто такой Дейт, но книг по подобной инф. в инете, трекерах много, можно скачать 3-5 илл 10 если вам оно так важно и найти ответ.
3) Прошло уже 17 часов, вы ответа так и не нашли ?
4) Вы пробовали вопрос в гугле искать, или лучше подождать пока дадут проф. ответ ?

Я не верю, что нельзя найти ответ на этот вопрос за 17 часов.

Скажите, а зачем вы написали этот комментарий? Если у вас тоже нет ответа.
Я хотел получить ответ. От Ивана или кого-то другого.

Дейт «Введение в системы баз данных» — один из трех монстров реляционной теории наравне с Коддом и Дарвеном.

Это не совсем сфера моих интересов, но попробую ответить.
Реляционная Алгебра и Реляционное Исчисление — это два различных по форме полностью математизированных и формализированных подхода для работы с состоянием реляционной базы данных.
Они не противопоставляются друг другу, так как различие проистекает из различия математических фундаментов. Одно является Алгеброй, другое — Исчислением.
Алгебры, зачастую, носят процедурный характер — описывают и исследуют последовательность применения операторов к операндам.
Исчисления, зачастую, носят декларативный характер — исследуют не процесс, а саму формулу. Целиком.
По выразительной мощности — тождественны, результат носит название теоремы Кодда.
SQL — не имеет фундаментального математического основания. SQL является дикой смесью алгебры и исчисления. Посему, для практических нужд учат SQL, а для понимания, скажем, как работает оптимизатор запросов — учат математические основания SQL, но они — это смесь Алгебры и Исчисления.

Еще вопрос — для TreeMap/TreeSet логарифмическое время (O(log(n))) вставки/выборки/удаления это в среднем или в наихудшем случае?

А где-то можно прочитать доказательство, что во вставке и удалении «цену перебалансировки дерева» удается так тонко размазать по множеству вызовов?

Мне кажется это интуитивно понятно, при вставке и удалении затрагиваются только узлы по пути к элементу и непосредственные соседи, т.е. количество операций O(p), где p длина пути, длина пути ограничена высотой дерева, которая O(logn).

Ага, нашел у Кормена — Глава 13 «Красно-черные деревья». Операции поворота и перекрашивания делаются только на пути, а он имеет логарифмическую длину.

Иван, вы могли бы объяснить что такое existential и universal types на примере java?
1) “Wildcards are a restricted form of existential types.”
2) “Raw types are closely related to wildcards. Both are based on existential types.”
---
P.S. Честно говоря, читаю интернеты о existential/universal types — и понять не могу что за фрукт и с чем едят:(
P.P.S. Читал спеку языка, наткнулся, ничего не понял:(

Почитал, пока не очень понял:(

Очень заинтересовал ваш вопрос. Всегда хотел разобраться. Сейчас вычитаю оригиналы по универсальным и экзистенциальным типам данных:
1) «On understanding types, data abstraction, and polymorphism»
2) «Abstract types have existential type»
и отвечу.
Это именно тот случай, когда говорят — «спасибо за вопрос» :)

Начинаю отвечать. Тема очень сложная, так что я в несколько подходов:)
Существует 4 типа полиморфизма («On understanding types, data abstraction, and polymorphism», английская википедия признает 3):
— общего вида: inclusion/subtype + parametric
— специального вида: overloading + автоматическое приведение типов
---
Построить внятную теорию взаимодействия кода полиморфного одновременно и по subtype и по parametric — весьма сложно. Одна из попыток — деления структур данных на универсальные и экзистенциальные.

А зачем это все нужно программисту практику?

Моя идея такова — стоит учить теорию, которая стоит за практикой. Это позволяет упорядочить знания в голове и просто решать задачи.

Позвольте Вам задать одну практическую задачу:

interface Out<T> {
void write(T elem);
}

class Test {
public static void main(String[] args) {
Collection<Integer> collection = new ArrayList<>();
Out<Number> out = new Out<Number>() {
public void write(Number elem) {}
};
Integer last = Util.copyAll(collection, out);
}
}

class Util {
public static _ copyAll(Collection_ collection, Out_ out) {
_ last = null;
for (_ elem : collection) {
out.write(elem);
}
return last;
}
}

Задача — заменить в классе Util знаки подчеркивания так, что бы код компилировался без варнингов, т.е. был типо-защищенным.

А теперь представьте, что моя задача при работе в корпорации — менторить бойцов, то есть, в том числе, объяснять КАК надо решать эту задачу и КАК прийти к решению или убедиться в том, что его нет.

    public static < T > T copyAll(Collection< T > collection, Out < ? super T > out) {
T last = null;
for (T elem : collection) {
out.write(elem);
}
return last;
}

    public static <T> T copyAll(Collection<T> collection, Out<? super T> out) {
T last = null;
for (T elem : collection) {
out.write(elem);
}
return last;
}

Забавно, что когда его видишь и немного подумаешь, оно кажется очевидным.

Но вот почти идентичное

    public static <T> T copyAll(Collection<? extends T> collection, Out<T> out) {
T last = null;
for (T elem : collection) {
out.write(elem);
}
return last;
}

не работает

Вот еще: попробуйте объяснить отношение между безобидными типами:
List
List < T >
List < Object >
List < ? extends Object >
List < ? extends T >
List < ? super T >
1) Кто является чьим супертипом?
2) Разные ли это типы?
3) Когда какой тип использовать?
---
Без хорошей теории это крайне сложно объяснить. Подобрать перебором первое подходящее решение — это не вариант. Вы так никого ничему не научите.

в туториале написано:
1)никто никого
2)разные
3)от ситуации

в туториале написано:
Было бы хорошо ссылку на туториал. Я МОГУ его найти, но так не принято, на что-то ссылаться, не указывая точно на что.
1)никто никого
Неверно.
class Example<T> {
{
List listRaw = null;
List<T> listT = null;
List<Object> listObject = null;
List<? extends Object> listWildcardUpperBoundObject = null;
List<? extends T> listWildcardUpperBoundT = null;
List<? super T> listWildcardLowerBoundT = null;

listWildcardLowerBoundT = listT;
listRaw = listT;
listWildcardUpperBoundObject = listRaw;
}
}

Это не все возможные, но для примера 3 компилируемых присвоения. Из которых следует, что левая часть — предок правой.
Из которых следует, что левая часть — предок правой.
Не следует, с type erasure и не такие штуки возможны.

Не могу согласиться.
Компиляция протекает в два этапа:
1) проверка типов
2) генерация байткода
Type erasure — это процесс во второй фазе.
Относительно первой фазы, как я понимаю, он не «работает»

Есть оговорки, это все справедливо если код находится в одном юните компиляции, ну и по моему пониманию что бы угодить обратной совместимости, type erasure и некоторым другим глюкам java эти проверки ослаблены, и можно привести примеров опасного кода который в совершенном языке в вакууме не компилился бы.

и можно привести примеров опасного кода
Давайте обсуждать конкретику — примеры в студию.
Я утверждаю, что преобразования через raw types — опасны, но идут через явное приведение типов. Т.е. программист явно указывает компилятору — перехожу в режим ручного управления, ответственность беру на себя.
Мое утверждение было относительно примера присвоение БЕЗ ЯВНОГО ПРИВЕДЕНИЯ ТИПОВ.

Я привел пример ниже. Еще меня в этой вашей джаве забавляет что у параметризированной мапы например метод get принимает совсем row Object.

Плата за обратную совместимость. В коллекциях есть такие вот места.

И как же именно параметризированный get ломал бы обратную совместимость?

Java 7 Language Specification:
4.10.2 Subtyping among Class and Interface Types:
“Given a generic type declaration C < F1,...,Fn >, the direct supertypes of the parameterized type C < T1,...,Tn > are all of the following:
• The direct superclasses of C.
• The direct superinterfaces of C.
• The type Object, if C is an interface type with no direct superinterfaces.
• The raw type C.
...”
Т.е. понятие superclass/subclass для параметрически типизированных типов в спецификации четко определены.
О том что List — предок для List<string> четко сказано.
---
Это только пример/часть. Полное описание системы типов на генериках — это несколько страниц текста.

Ну и, конечно, хотелось бы примера в котором

a = b;
компилируется без варнингов, но из-за type erasure нельзя утверждать, что тип правой части не является типом левой части.

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

Вы решили не отвечать на вопрос, а свести все к обсуждению его постановки:)
Думаю, даже если убрать требование отсутствие варнингов — все равно мое утверждение о том, что компиляция присвоения указывает на то, что тип правой части — предок типа левой части, остается верным.
Ну или контрпример в студию.

Вы решили не отвечать на вопрос, а свести все к обсуждению его постановки:)
Почему бы и нет, не вижу смысла отвечать на вопрос, детали которого ты меняешь под себя при необходимости.
Думаю, даже если убрать требование отсутствие варнингов — все равно мое утверждение о том, что компиляция присвоения указывает на то, что тип правой части — предок типа левой части, остается верным.
Хотелось бы что бы ты наконец взял себя в руки, сосредоточился и определился ты хочешь пример: когда не вполняется «тип правой части — предок типа левой части», «тип правой части является типом левой части», или наконец «левая часть — предок правой»
Ну или контрпример в студию.
Пажалуйста
List a = new ArrayList();
List<Integer> b = a;
2)разные
Верно. Но на сколько разные? Почему вот так могу:
interface Example {
void f(int arg);
void f(long arg);
}
Потому, что int и long, видимо, разные.
.
А вот так НЕ могу
interface Example {
void f(List<Object> arg);
void f(List arg);
}
Потому как, видимо, недостаточно разные.
3)от ситуации
Ну это вообще не ответ.
---
Вот конкретный пример — Вам нужен утилитарный метод, получающий коллекцию и возвращающий ее размер. Какую из сигнатур Вы выберете:
class Util {
public static int size0(Collection list) {
return list.size();
}
public static int size1(Collection < ? > list) {
return list.size();
}
public static < T > int size2(Collection < T > list) {
return list.size();
}
}
?
инструмент создания mock-ов Mockito.
А что порекомендуете почитать по Mockito?

Мне вполне хватает целой небольшой “книги рецептов”, которую разместили в Javadoc-е класса org.mockito.Mockito. Все примеры с работающим кодом и от авторов:
1. Let’s verify some behaviour!
2. How about some stubbing?
3. Argument matchers
4. Verifying exact number of invocations / at least once / never
5. Stubbing void methods with exceptions
6. Verification in order
7. Making sure interaction(s) never happened on mock
8. Finding redundant invocations
9. Shorthand for mocks creation — @Mock annotation
10. Stubbing consecutive calls (iterator-style stubbing)
11. Stubbing with callbacks
12. doReturn()|doThrow()|doAnswer()|doNothing()|doCallRealMethod() family of methods
13. Spying on real objects
14. Changing default return values of unstubbed invocations (Since 1.7)
15. Capturing arguments for further assertions (Since 1.8.0)
16. Real partial mocks (Since 1.8.0)
17. Resetting mocks (Since 1.8.0)
18. Troubleshooting & validating framework usage (Since 1.8.0)
19. Aliases for behavior driven development (Since 1.8.0)
20. Serializable mocks (Since 1.8.1)
21. New annotations: @Captor, @Spy, @InjectMocks (Since 1.8.3)
22. Verification with timeout (Since 1.8.5)
23. (New) Automatic instantiation of @Spies, @InjectMocks and constructor injection goodness (Since 1.9.0)
24. (New) One-liner stubs (Since 1.9.0)
25. (New) Verification ignoring stubs (Since 1.9.0)
26. (**New**) Mocking details (Since 1.9.5)
27. (**New**) Delegate calls to real instance (Since 1.9.5)
28. (**New**) MockMaker API (Since 1.9.5)

А Вы, как понял, не используете никакого контейнера для бизнесс-логики (Spring, Guice, EJB)? Без DI/IoC — как-то немодно ...

1) Spring/Guice/EJB — не используем. Достаточно сложные технологии на фоне Servlet/JDBC. Летом стартует курс Middle Enterprise Java Developer — там будет jQuery/JSF/Spring/Hibernate.
2) Свой маленький DI/IoC мы пишем сами. Имеет следующий вид:

public class QuizController extends DependencyInjectionServlet {
private QuizDao quizDao;
private TransactionManager txManager;
@Inject("quizDao")
public void setQuizDao(QuizDao quizDao) {
this.quizDao = quizDao;
}
@Inject("txManager")
public void setTransactionManager(TransactionManager txManager) {
this.txManager = txManager;
}
...
}

Т.е. используем setter injection, а интеграцию DI-контейнера с проектом делаем через обязательного предка.
Это пример контроллера из MVC, которому «иньектируют» источник данных типа DAO и механизм определения границ транзакции — TransactionManager.

Ну уж пошла такая жара — подкиньте, что по DI/IoC почитать?
Заранее спасибо.

Мне нравится:
1) Глава 5 из “Spring Framework Reference” — 5.The IoC container
5.1. Introduction to the Spring IoC container and beans
5.2. Container overview
5.3. Bean overview
5.4. Dependencies
5.5. Bean scopes
5.6. Customizing the nature of a bean
5.7. Bean definition inheritance
5.8. Container Extension Points
5.9. Annotation-based container configuration
5.10. Classpath scanning and managed components
5.11. Using JSR 330 Standard Annotations
5.12. Java-based container configuration
5.13. Registering a LoadTimeWeaver
5.14. Additional Capabilities of the ApplicationContext
5.15. The BeanFactory

2) Обзорная статья Фаулера — “Inversion of Control Containers and the Dependency Injection pattern”

механизм определения границ транзакции — TransactionManager
 — WTF???
Я не мегазнаток JDBC, но все что касается транзакций реляционной базы видимых из java — это методы java.sql.Connection:
1) setTransactionIsolation(int)
2) setAutoCommit(booblen)
3) commit()
4) rollback()

И что тут устанавливать? Транзакция стартует с первым обращение к базе сама — нет метода begin(), коммитится по commit(), ролбэчится по rollback(). Зачем Вы пишете свой какой-то TransactionManager?

На самом «низком» уровне — Вы правы. Стоит конечно добавить упоминание метода
5) rollback(Savepoint)

Но если мы пишем пусть и небольшой, но грамотно спроектированный проект, то нам приходится решать более высокоуровневые задачи. Вопрос номер 1:
— где собственно будут вызываться эти методы connection?
Тут на помощь приходит товарищ МаузерФаулер со своим фундаментальным трудом «Шаблоны корпоративных приложений» и предлагает 5 решений:
— Transaction Script
— Table Data Gateway
— Row Data Gateway
— Active Record
— Data Mapper

Для нашего масштаба задачи я бы предпочел Table Data Gateway. В Core J2EE Patterns его называют DAO (DataAccessObject).
Т.е. скажем для класса бизнесс-объекта Account создается парный класс AccountDAO с волшебным методам:
— AccountDAO.changeMoneyAmount(Account, Money)
весь доступ к базе — DataSource, Connection, Statement, ResultSet ... сосредоточен в этом классе. Логично напрашивается вывод, что старт и commit/rollback тоже должен быть тут же. Один вызов — одна транзакция.
Все красиво, пока мы не хотим В ОДНОЙ ТРАНЗАКЦИИ БАЗЫ ДАННЫХ ИЗМЕНИТЬ НЕСКОЛЬКО СЧЕТОВ.

Но наша архитектура приводит к тому, что изменение каждого счета сосредоточено в методе changeMoneyAmount и связано с отдельной транзакцией.
Тупиковый подход — создать специальный метод AccountDAO.changeMoneyAmount(List<account>, List<money>) или AccountDAO.changeMoneyAmount(List<pair<account, money="">>). В таком случае у нас на каждое отдельное бизнесс-действие прийдется создавать отдельный метод в DAO. Если же наша транзакция охватывает несколько DAO — то наш подход вообще рушится и вырождается в TransactionScript.
Правильный подход — ОТДЕЛИТЬ ОПРЕДЕЛЕНИЕ ГРАНИЦ ТРАНЗАКЦИИ ОТ УРОВНЯ DAO И ПЕРЕНЕСТИ ЕГО В УРОВЕНЬ БИЗНЕСС-ЛОГИКИ.
.
Но поместить в бизнесс-объекты мы его тоже не можем. Не то место. Идея — создать специальный ЧистоСинтетическую/PureFabrication сущность, которой это и делегировать.
.
Обращение с ней в бизнесс уровне может иметь следующий вид:

    private void changeMoneyAmount(List<Pair<Account, Money > > changeList)  {
txManager.doInTransaction(new Callable<Void>() {
@Override
public Void call() throws Exception {
for (Pair<Account, Money> pair : changeList) {
accountDao.changeMoneyAmount(pair.first, pair.second);
}
return null;
}
});
}

Если у Вас одному запросу клиента почти всегда соответствует одна транзакция, то можете воспользоваться шаблоном Open Session In View.

Едрена-матрена ... А попроще нельзя как-то? :)

Эээ ...
Даже не знаю что и сказать.
Есть чудесные простые профессии — кассир, лесоруб, водитель такси.
За что-то же платят такие чертовски большие деньги программистам?
Ну а с другой стороны, если у Вас есть хорошая цель, высокая, светлая — поскорее стать Tech Lead / Architect, получать 3.5К-4.5K и радоваться жизни, то тут — «чем сложнее, тем лучше». В смысле изначально ориентируясь на высокоуровневые/шаблоноориентированные решения вы закладываете хороший фундамент не только в стройность архитектуры проекта, но и в свою карьеру в IT.

Иван, вопрос не в том, что программирование само сложно — а в том, можно ли тот же самый функционал получать меньшей кровью. Ну например я сам джава — программист, мне понятно что вы описываете, и описываете вы правильно, но с другой стороны я на досуге дергаю руби с рельсами и иногда кажется что джава несколько громоздка для простых сценариев. Хотя соглашусь, J2EE без спринга был еще хуже ИМХО.

Дело не в J2EE, а в архитектуре. Из рельсов MySQL так же виден, как и из JDBC. Как вы разграничиваете транзакции? Декларативным образом? Тогда как Вы транслируете это в TCP-вызовы серверу MySQL?

Декларативно не получается. Декларативно — это как раз для джавы (спринг, J2EE) хорошо.

Вы могли бы подбросить ссылку — как в рельсах работают с transaction boundaries?

api.rubyonrails.org/...d-i-transaction

в принципе похоже на то что вы предлагаете

Хотя соглашусь, J2EE без спринга был еще хуже ИМХО
А конкретнее?

Например, можно использовать ту же аннотацию @Transactional или TransactionTemplate. Это про спринг — явно удобнее чем в монструозном EJB.

Ерунда, в Ejb туже роль играет TransactionAttribute

А сам EJB ты находишь таким же удобным как спринг? Я лично нахожу монструозным EJB — как 2 — ую, так и 3 — ю версию, и мне удобнее работать со спрингом в том числе и с транзакциями.

Я нахожу и спринг вполне монстроудобным, моя цитата была исключительно по поводу того что ты ошибаешься в плане отсутствия аналога Transactional в Ejb.

Тут я согласен, в EJB есть конечно декларативное управление транзакциями.

Как по мне EJB вполне ок, вот что монстрообразное в JavaEE так это JSP

Как понимаю, что бы быть Web-контейнером, необходимо поддерживать _И_ Servlet API _И_ JSP. Но в целом, JSP вовсю “выпиливают” из Java EE и заменяют на facelets, как более подходящие для JSF.
.
Может не сильно внимательно смотрел, но в “каноническом” Java EE Tutorial от производителя идет во всю замена JSP->facelets.
.
“Facelets, a display technology that replaces JavaServer Pages (JSP) technology using XHTML files”
.
“JSP technology is considered to be a deprecated presentation technology for JavaServer Faces.”

Или как вариант заменяют на XSLT

а по мне наоборот, JSP был вполне себе симпатичным — сейчас конечно с появлением других шаблонизаторов он выглядит уныло. Просто в JSP обычно скриптлеты пихали — и теги писать надо было, с появлением штук вроде Freemarker я бы уже не юзал JSP.

чем сложнее, тем лучше

вот с этим утверждением я не согласен, мне кажется архитектура должна быть простой максимально, естественно удовлетворяя требованиямпо функционалу и т.д. Даже если 5% функционала требует усложнения архитектуры — стоит мне кажется задуматься а так ли нужен тот функционал.

Усложняя архитектуру, вы конечно повышаете свою важность как архитектора, но проекту это идет во вред. С моей точки зрения важность успешности проекта (и простоты архитектуры) важнее успешности конкретного архитектора.

Стойте, мы все еще говорим про учебный проект, длительностью три месяца? Я описываю как это сделано у меня на курсе.

Если касательно чисто учебного проекта — то в принципе все ок, согласен.

Едрена-матрена ... А попроще нельзя как-то? :)
Попроще обычно — навешиваешь на твой метод анотацию @Transactional и все автоматически саморазруливается фреймворком/контейнером, а ты ни о чем не беспокоишься и смотришь футбол пока суперархитекторы знающие все паттерны наизусть ищут мегабагу в куче паттерно-каноничного кода.

Да, в реальном корпоративном проекте так все и делается. Но у нас два отличия
1) отсутствие контейнера с поддержкой декларативных JTA-транзакций (из известных Spring или EJB)
2) желание «вытащить из-под капота» как это все работает в том же Spring/EJB.
.
По второму пункту мы фактически делаем свой маленький контейнер с IoC и TransactionManager. Написавший такое уже никогда не забудет, что контексты (transaction, security) привязаны к потоку (скажем, через банальную ThreadLocal-переменную).
И поймет, почему нельзя стартовать своих потоков в контейнере.

А материалы к шаблонам проектирования можете подбросить?

Если имеются в виду классичкские шаблоны проектирования GoF, то я своим слушателям рекомендую:
1) «Паттерны проектирования» из серии Head First.
Книга начального уровня, рассчитана на тех, кто еще неуверенно оперирует терминами ООП (делегирование, композиция, наследование, сокрытие, ...).
2) — «Шаблоны проектирования в JAVA» Марка Гранда.
Книга среднего уровня, рассчитана на тех кто предпочитает конкретику (примеры приводятся на Java, в отличии от GoF). Книга также содержит дополнительно ряд идиом/шаблонов, не входящих в GoF, но популярных в Java (Marker Interface, Immutable, ...) и многопоточных шаблонов (Thread Pool, ...).
3) — «Приемы объектно-ориентированного проектирования. Паттерны проектирования» (Design Patterns: Elements of Reusable Object-Oriented Software) авторов Гамма, Хелм, Джонсон, Влиссидес (Банда Четырех == Gang of Four == GoF). Оригинальный источник информации по шаблонам. Книга выше среднего уровня, рассчитана на тех кто предпочитает достаточно высокий уровень абстракции и может рассматривать примеры кода на С++.

Книги идут в порядке повышения уровня сложности.
Если вы разбираетесть более-менее в ООП, рекомендую начинать с Марка Гранда.

Если сортировать в порядке полезности, то спискок стоит перевернуть ))

Ну так первые две — просто разжеванная последняя :)

построение ER-модели по техническому заданию, трансляция ER-модели в реляционную модель
А почему ER-модель, а не UML?

Мы используем ER-модель для предварительного моделирования сущностей и их связей в самом общем виде перед созданием реляционной модели (таблицы, ключи, ограничения).
Набор UML-диаграмм лучше подходит для моделирования модели предметной области перед созданием ее в объектно-ориентированном «несущем» языке.
Т.е. этих два класса инструментов используются перед созданием артефактов в двух различных доменах — реляционном и объектно-ориентированном.

Так вы что ВООБЩЕ UML не используете?

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

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

И что порекомендуете читать? Можете скинуть литературу?

«ПаГаварить» «брОузер» «продуктоционные менеджеры» «апИ» (ради интереса глянул демо-лекцию, уши в ужасе сворачивались).

Могу я подытожить ваше высказывание следующим образом: качеством материала доволен, примеры — наглядны и понятны, непроясненных вопросов не осталось, лектор хорошо ориентируется в материале, и у Вы, в виду отсутствия замечаний по существу, но присутствия «зуда комментирования», оставили то, что было?

Это не дэмо-лекция, это одна из 27 двухчасовых лекций, которые я уже выложил на youtube с октября.

Я читаю таких лекций — 6 в неделю у трех разных групп. Честно говоря, выяснение как корректно ставить ударения в иностранных словах при использовании из в русской речи не стоит в списке приоритетов на первом месте.

План лекций:
1-2: примеры основных шаблонов проектирования (Builder, Singleton, Factory Method, Adapter, Decorator, Composite, Facade, Proxy, Command, Iterator, Listener, Strategy, Template Method).
3-6: построение ER-модели по техническому заданию, трансляция ER-модели в реляционную модель, устройство и администрирование MySQL/InnoDB, SQL.
7-8: JDBC API, шаблон DAO, другие шаблоны доступа к данным.
9-12: Servlet API, шаблон MVC, HTTP, начальные сведения о HTML/CSS.
13-14: Test Driven Development: инструмент создания модульных тестов JUnit, инструмент создания mock-ов Mockito. Покрываем наше приложение модульными тестами.
15: Logging в Enterprise-приложении — Log4j.
16: Сборка Enterprise-приложения — Maven.
17-20: реализация логики минимального Enterprise-приложения: регистрация пользователя, log in/log out, remember me, хранение корзины покупок, многоязычие, пользователи с различными ролями (пользователь, менеджер, администратор)
21-24: картина «в целом»: Dependency Injection + Inversion of Control шаблоны, функциональные и нагрузочные тесты, работа с информацией, накопленной приложением (отчеты, анализ, статистическая информация).
По первым двум пунктам. А что JavaEE джун не должен иметь представление о Core J2EE Patterns ?. По остальным пунктам это скорей курсы на трейни чем на джуна
По первым двум пунктам. А что JavaEE джун не должен иметь представление о Core J2EE Patterns
По ходу курса я в делаю отсылки и к J2EE Core Patterns и к PEAA.

И что вы оттуда используете?

Intercepting Filter — так как любой javax.servlet.Filter им
является
Front Controller — просто объясняю, что так устроено большинтво view-фреймворков (JSF, Struts), но мы используем Page Controller.
Data Access Object — таким образом мы обращаемся к базе
Bussiness Object — таким образом представляем куски модели

По остальным пунктам это скорей курсы на трейни чем на джуна
Ух! Возможно вы работаете в какой-то особенной компании со сверх высокими требованиями к сотрудникам. Тогда интересно, чего же у Вас требуют от junior и middle разработчиков?
В моем мире (город Харьков), человек, разбирающийся в Servlet API, JDBC, Maven, Log4j, Junit, Mockito и использовавший это все на практике последние 3 месяца не считается трейни. Он считается юниором с диапазоном зарплат 500$-1000$.
Возможно вы работаете в какой-то особенной компании со сверх высокими требованиями
В Днепре своя атмосфера

Чертовски интересно:
1) сколько же платят такому трейни в Днепре?
2) и откуда обычно берут (институты? переманивают?)
3) чему его учат на трейни? он, вроде как, в бой уже готов.

Мне тоже так как ниразу не видел живого трейни

Что же тогда должен знать архитект? ;-)

Необходимо, что бы большинство компаний в вашей локации признавали, что ваш уровень выше senior, оплачивали ваш труд выше чем труд senior и давали задачи более общего характера чем для senior.
.
Что знать — не знаю. Такой же вопрос как «Что нужно знать, что быть middle developer?».

Для компании которая вас не знает вы по дефолту джуниор или трейни. ;-)

Я Вам станцую ответ на языке Java:
хороший программист List с неизвестным type variable называет List < ? >, а плохой — List< Object > :)

Type inference — лучше чем raw types :):):)

И как много компаний на это купилось? ;-)

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

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

Я просто немного не пойму чего именно вы хотите от меня:
1) привести список знаний которые необходимы архитектору, по моему мнению
2) привести список знаний которые достаточны архитектору, по моему мнению
3) доказать Вам, что я занимаю позицию архитектора
4) доказать Вам, что я занимал бы позицию архитектора в любой компании
---
Если Вы уточните вопрос, возможно, я смогу на него ответить

Что же тогда должен знать архитект? ;-)

Что знать — не знаю. Такой же вопрос как «Что нужно знать, что быть middle developer?».
человек, разбирающийся в Servlet API, JDBC, Maven, Log4j, Junit, Mockito и использовавший это все на практике последние 3 месяца не считается трейни. Он считается юниором с диапазоном зарплат 500$-1000$.
Для трейни/юниора выходит что знаете, а для middle developer / архитекта не знаете. Верно? ;-)

Ок, попробую сформулировать опираясь на опыт. И так, для того, что бы 50% украинских компаний на собеседовании признали вас J2EE-архитектором необходимо знать примерно следующее:
1) уровень хранилища данных: реляционные базы данных — на уровне Дейта, представления о NoSQL хранилищах (MongoDB, Cassandra, Hadoop).
2) Бизнес-логика: знать работу основных контейнеров — Spring/EJB, основных API: JDBC, JNDI, CDI, JCA, JTA, JPA
3) интеграция — JMS, JAX-RS, WS-*
4) front end: HTTP, Servlet API, JSF/GWT
5) навыки моделирования: ER, UML
6) представление о высоконагруженных проектах, распределенных архитектурах.
7) обладать способностью посмотреть на приложение под разными углами: как распространяются транзакции, как хранится состояние, как работает security, как проект деплоится, как выглядит при тестировании, как разбивается на модули, как распределены риски по компонентам/технологиям.

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

Разве это не должен знать мидл или синьор?

Ну по технологиям — JCA и Cassandra мидлу точно не нужны.
По разносторонним взглядам на весь проект — тоже. В моей практике, типичная задача мидла — реализовывать модуль длительностью неделю. Транзакции, секьюрность, кэширование — уже для него настроено.

Ну и если человеку с такими знаниями предложить 1.5К и должность мидла, думаю не согласится:)

занятия проходят в Центре (пер.Театральный 11/13)
город??

Тысяча извинений.
Город — Харьков.

переулок Театральный 11/13.
Это в районе площади Поэзии — 5 минут от метро Советская или Бекетова

Подписаться на комментарии