Сначала благодарности :)
Автору — за толковый подход. Всех читающих прошу обратить внимание, как человек подошел к вопросу: изучает документацию, придумывает задачи, решает их, делает выводы. При всей кажущейся банальности так делают минимум (!) людей. Говорю это как человек, который помог приобщиться к Java технологиям десятку человек.
Далее хочу обратить внимание на комментраии товарищей metakeycocojumber. Очень и очень взвешенные и адекватные мысли.
И, наконец, по сути вопроса.
Совершенно не хочу повышать энтропию и писать сюда еще список технологий, которые можно учить — это вам подскажет опыт, здравый смысл и рынок. Я приведу лишь пример из жизни, иллюстрирующий важность базовых вещей над производными.
Я работаю с Java уже более 7 лет и поучаствовал в проектах различного масштаба. Одним из них был небольшой проект по созданию ряда прототипов для оценки технологий a-la in-memory storage (Terracotta, Gigaspaces, Coherence). Одно из требований к прототипу звучало как «разработка с использованием базовых библиотек Java». Так как одной из задач была грубая оценка производительности веб-приложения, которое должно было общаться с такого рода storage системами, то мы «закатав рукава» писали простые сервлеты, вспоминали как их корректно использовать в мультипоточной среде, как работают всевозможные lock и thread-safe классы из java.util.concurrent. И при этом ни Spring'ом, ни Hibernate'ом, никаким MVC фреймворком там и не пахло.
Прошло время, я уехал в Калифорнию, участвую в разработке высоконагруженного веб-ресурса и уверяю вас: количество используемых фреймворков дикутется реальным нуждами. Решение об использовании того или другого принимается на основе оценки его производительности, расширяемости и т.д. При этом достаточно много «велосопедов» изобретено заново из-за того, что существующие фреймворки не удовлетворяют требованиям производительности.
Мой посыл в том, что понимание базовых вещей (что находиться ниже Hibernate, Spring, Struts или JSF, над каким протоколом построен SOAP или как проходит общение между сервером и клиентом в GWT) — очень важно. Знание нижележащих уровней позволят вам строить предположения о принципиальном устройстве работы неизвестных вам фреймворков, задавать правильные вопросы когда очередной адепт фреймворка А утверждает, что ничего подобного вы доселе не знали, понимать что ничего волшебного в проприетарных продуктах от IBM, Oracle и иже с ними нет, а построены они на тех же базовых вещах.
В моем понимании, знание базовых вещей в Java для человека, который собирается провести некоторое время с этим языком так же необходимо, как знание базовых алгоритмов и структур для инженера, считающего себя разработчиком программного обеспечения.
Прочел ваши комментарии на тему «DVCS vs CI». Полностью согласен с тем, что с помощью различных «внешних» воздействий можно попытаться решить проблему «integration без continuous», но это определенно будут компромисные решения.
Всем, кто интересуется вопросом противостояния двух парадигм систем контроля вресий, рекоммендую ознакомиться с комментариями belonesox приведенными выше.
Прежде всего хотел поблагодарить автора за хороший цикл статей. Больше всего нравиться взвешенный (без «максим» и «низложений») подход к описанию конфигурационного менеджмента.
Я длительное время использую различные централизованные системы контроля версий (CVS, SVN, Perforce), но недавно приобрел начальный опыт с git. В связи с этим хотел поделиться своим взглядом на выбор СКВ для проекта.
Из моего опыта, выбор СКВ всегда диктовался принятыми практиками работы (как инженерными так и управленческими) в команде/проекте. Последние 3 года, команды, с которыми я работал, применяли наборы Agile практик, из которых наибольшее отношение к обсуждаемой теме имеет «Постоянная интеграция» (Continuous integration). Использование указанной практики с централизованной системой версий, современным CI сервером (TeamCity, Hudson, Bamboo) и покрытии модульными и интеграционными тестами позволяло поддерживать основную ветку всегда в рабочем состоянии, готовой к Release Candidate в любой момент времени.
В случае с git мы утратили эту способность — разработчики удерживали код на своих станциях и синхронизация кода стала происходить гораздо реже. Команда пришла к выводу, что мы можем добиться частой синхронизации и применения CI к некоторой «собирательной» ветке, но сама природа использования децентрализованной СКВ не подталкивает к этому и вынуждает к применению «административных» мер.
Ни в коем случае не умаляю важности децентрализованных СКВ для open-source разработки или для случаев, которые описал автор (Владивосток — США), но в команде, где разработчики коммитят часто и интеграция происходит постоянно я не обнаружил преимуществ децентрализованной СКВ над централизованной.
Недавно нашел в Сети статью про аналогичную ситуацию от Мартина Фаулера (Martin Fowler), который разбирая преимущества и недостатки децентрализованных СКВ, смоделировал до боли похожую ситуацию.
Для интересующихся вопросом его рассуждения можно почитать в статье FeatureBranch.
Автору — за толковый подход. Всех читающих прошу обратить внимание, как человек подошел к вопросу: изучает документацию, придумывает задачи, решает их, делает выводы. При всей кажущейся банальности так делают минимум (!) людей. Говорю это как человек, который помог приобщиться к Java технологиям десятку человек.
Далее хочу обратить внимание на комментраии товарищей metakey cocojumber. Очень и очень взвешенные и адекватные мысли.
И, наконец, по сути вопроса.
Совершенно не хочу повышать энтропию и писать сюда еще список технологий, которые можно учить — это вам подскажет опыт, здравый смысл и рынок. Я приведу лишь пример из жизни, иллюстрирующий важность базовых вещей над производными.
Я работаю с Java уже более 7 лет и поучаствовал в проектах различного масштаба. Одним из них был небольшой проект по созданию ряда прототипов для оценки технологий a-la in-memory storage (Terracotta, Gigaspaces, Coherence). Одно из требований к прототипу звучало как «разработка с использованием базовых библиотек Java». Так как одной из задач была грубая оценка производительности веб-приложения, которое должно было общаться с такого рода storage системами, то мы «закатав рукава» писали простые сервлеты, вспоминали как их корректно использовать в мультипоточной среде, как работают всевозможные lock и thread-safe классы из java.util.concurrent. И при этом ни Spring'ом, ни Hibernate'ом, никаким MVC фреймворком там и не пахло.
Прошло время, я уехал в Калифорнию, участвую в разработке высоконагруженного веб-ресурса и уверяю вас: количество используемых фреймворков дикутется реальным нуждами. Решение об использовании того или другого принимается на основе оценки его производительности, расширяемости и т.д. При этом достаточно много «велосопедов» изобретено заново из-за того, что существующие фреймворки не удовлетворяют требованиям производительности.
Мой посыл в том, что понимание базовых вещей (что находиться ниже Hibernate, Spring, Struts или JSF, над каким протоколом построен SOAP или как проходит общение между сервером и клиентом в GWT) — очень важно. Знание нижележащих уровней позволят вам строить предположения о принципиальном устройстве работы неизвестных вам фреймворков, задавать правильные вопросы когда очередной адепт фреймворка А утверждает, что ничего подобного вы доселе не знали, понимать что ничего волшебного в проприетарных продуктах от IBM, Oracle и иже с ними нет, а построены они на тех же базовых вещах.
В моем понимании, знание базовых вещей в Java для человека, который собирается провести некоторое время с этим языком так же необходимо, как знание базовых алгоритмов и структур для инженера, считающего себя разработчиком программного обеспечения.
В заключении отыскал старую статью A new breed: Framework Java Coder? как раз в ключе моего поста.
Желаю вам удачи, вы на верном пути.
P.S. Intellij IDEA — вещь! Использую с версии 4.0 (2003 год, если не ошибаюсь).
Всем, кто интересуется вопросом противостояния двух парадигм систем контроля вресий, рекоммендую ознакомиться с комментариями belonesox приведенными выше.
Я длительное время использую различные централизованные системы контроля версий (CVS, SVN, Perforce), но недавно приобрел начальный опыт с git. В связи с этим хотел поделиться своим взглядом на выбор СКВ для проекта.
Из моего опыта, выбор СКВ всегда диктовался принятыми практиками работы (как инженерными так и управленческими) в команде/проекте. Последние 3 года, команды, с которыми я работал, применяли наборы Agile практик, из которых наибольшее отношение к обсуждаемой теме имеет «Постоянная интеграция» (Continuous integration). Использование указанной практики с централизованной системой версий, современным CI сервером (TeamCity, Hudson, Bamboo) и покрытии модульными и интеграционными тестами позволяло поддерживать основную ветку всегда в рабочем состоянии, готовой к Release Candidate в любой момент времени.
В случае с git мы утратили эту способность — разработчики удерживали код на своих станциях и синхронизация кода стала происходить гораздо реже. Команда пришла к выводу, что мы можем добиться частой синхронизации и применения CI к некоторой «собирательной» ветке, но сама природа использования децентрализованной СКВ не подталкивает к этому и вынуждает к применению «административных» мер.
Ни в коем случае не умаляю важности децентрализованных СКВ для open-source разработки или для случаев, которые описал автор (Владивосток — США), но в команде, где разработчики коммитят часто и интеграция происходит постоянно я не обнаружил преимуществ децентрализованной СКВ над централизованной.
Недавно нашел в Сети статью про аналогичную ситуацию от Мартина Фаулера (Martin Fowler), который разбирая преимущества и недостатки децентрализованных СКВ, смоделировал до боли похожую ситуацию.
Для интересующихся вопросом его рассуждения можно почитать в статье FeatureBranch.