Наблюдение : про кодобазы

Для начала отсылка на  видео -  кому будет интересно посмотрят потом. 

https://www.youtube.com/watch?v=XL1sKnMSfwU

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

Интересный прием который при определенных условиях (высокоуровневые языки прогиаммирования, мощные IDE) избегать/нивелировать интеграционные проблемы, которые очевидны и не решаемы (академически) в том случае когда реопзиторий с кодом не один. 

Аналогичная практика (если мне не изменяет память) существует в Google, аналогичная практика в Facebook и опен-сорсный инструмент который помогает жить с этой парадигмой.

Хорошая ли это практика или нет - покажет время.

В любом случае возникает вопрос - как не заблудиться в больщой кодобазе если она упакована в один репозиторий.

Напочитать: Технический выпуск

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

Но тем не менее.

1. Отличный обзор того что такое Guava и как ее готовить
http://www.infoq.com/presentations/Guava

2. Длинный и может быть не самый лучший рассказ о том что такое DropWizard, но в нем хорошо изложена мотивация того нафига он нужен.
http://www.infoq.com/presentations/Dropwizard

3. Я давно смотрю на Gradle и до сих пор не понимаю нафиг оно вообще.
Но тем не менее.

Рассказ о том что такое таски в Gradle
http://habrahabr.ru/post/167227

и рассмотрение Gradle Артемом Кошелевым (поддерживаю Артема по всем пунктам)
http://artkoshelev.github.io/posts/getting-started-with-gradle/

Видео с Клуба Анонимных Разработчиков в Киеве про build tools
http://video.yandex.ua/users/xpinjection/view/345/#hq

4. Тестирование с использованием виртуальных машин уже давно не является чем-то особенным.
Вслед за распространением самой идеи появляются и инструменты.
http://sourceforge.net/projects/rf-virtualbox-lib-py/
В 2011 году я создавал нечто подобное, но библиотекой это так и не стало.
От себя могу сказать что подобного рода библиотеки строятся поверх command-line-интерфейсов.

Такие интефейсы есть и у VirtualBox (reference, интересная статья ), и у VmWare WorkStation (ссылочка на reference)

5. Грядет. Я только об этом успел подумать, а умные дядьки из гугла уже давно подумали. И уже даже сделали.
Модульные девайсы, кастомизация своими руками, сменные модули.
Project Ara 

6. Как  нынче преподают java в Таллине
Код тут - https://github.com/zeroturnaround/java-fundamentals

7. Обновление Android SDK - поддержка фич Java 7.

• String в switch-case выражениях;
• Сокращенное описание generics (diamond operator <>);
• Обработка исключения для нескольких типов (catch (E1 | E2 e));
• Знаки подчеркивания в числовых константах (1_234_567);
• Двоичные константы (0b0001).
• Автоматическое управление ресурсами (try-with-resources)

Хабра.



Менеджерское.
Подпишусь под каждым словом.

Скажу честно, построить эту систему удалось не сразу. Много раз не получалось, я скатывался назад. Один из примеров: как только я для увеличения ответственности отменил контроль над приходом в офис (первый раз это было примерно в 2002 году), моментально были сорваны все сроки сдачи журналов, типографии стонали, сроки отгрузки были нарушены. Я снова ввел жесткую дисциплину, а сам начал думать, что же не так. Потом опять ввел свободный график, и опять не получилось, через два года еще раз — и опять провал… Сейчас мы работаем в режиме свободного графика и четырехдневной рабочей недели. Что для этого понадобилось? Замена людей на более взрослых, серьезных и адекватных. Взрослых с точки зрения психологической зрелости. Заменив людей, я впервые смог уехать из страны на полгода. Еще один бонус для меня лично — отсутствие унизительного для меня контроля, необходимости отдавать приказания.

Важно понимать цену перехода на четвертый тип управления. Люди, способные к самоорганизации, стоят намного дороже. Риски высоки — мы не знаем заранее, кто потянет, а кто нет, соответственно в любом случае поначалу будут срывы. Если мы даем людям свободу, надо приготовиться, что будут ошибки, за которые придется платить. Кроме того, есть руководители, которые тащатся, раздавая указания, и для них просто по стилю такая система не подойдет.

Link: О дуализме Maven

Собственно глубокая мысль от Мартина Фаулера
И куда как менее глубокая мысль и сумбурно изложенный пример в отношении средств сборки от Нила Форда.
Оба из одной компании, ThoughtWorks.

С мыслью "дедушки" Фаулера я согласен - потенциал инструментов, которые дают степень расширяемости указанную в первой статье действительно велик.

Однако пример приведенный Фордом мне кажется, как минимум, не очень удачным - я бы даже сказал некорректным.

Maven дал экосистеме Java стандарт.
Тот, кто работал в аутсорсинге (и часто менял проекты) в 2005-2009 гг. и выкачивал из svn проекты с произвольной структурой, файлом build.xml и папочкой lib со всеми джарниками внутри  - меня поймет.
Особенно когда ты выкачиваешь такой проект с какого-нибудь сервера заказчика в Гондурасе.

Если вы не делаете что-то действительно особенное или принципиально новое - maven вам может быть и не подходит,но скорее всего вы просто его не правильно готовите.

Вопрос о расширяемости maven в томже  контексте - может быть Форд и прав.
Но это опять же вопрос знаний - если вы уже пишете на java, развернули проект с нуля на maven, то написать плагин тоже не составит труда.