/*
** 2005 July 8
**
** The author disclaims copyright to this source code. In place of
** a legal notice, here is a blessing:
**
** May you do good and not evil.
** May you find forgiveness for yourself and forgive others.
** May you share freely, never taking more than you give.
**
*************************************************************************
А я замечал за людьми которые живут за границей и привыкли к тому что слово «аппликация» не переводится и используется не только для мобильных приложений, но и для веба, например. Вот как например у человека в ответ которому идет эта ветка.
По Вашему мнению я должен говорить не «дизайн паттерн — фактори», а «шаблон проектирования — фабрика»? Или может Вы расскажите как правильно Java писать и произносить?
Не всегда написание какого то слова значит что это представитель такого быдла человек подвластен макетингу. Иногда просто есть разные семантические контексты среды в которой люди обитают.
Ваше джававозрение полностью соответствует моему, просто этот слой «легкого J2EE» был оставлен за кадром, и я не совсем понял, критиковался он тоже или нет.
Почему это не попадает? Hibernate вполне себе JPA, заменим @Autowired на
@Inject
(хабрапарсер) и будет тоже J2EE стандарт. Я посмотрел только первую часть, но так и не увидел четкого распределения между «легким» J2EE (Spring и компания).
А с идеей «уменьшения джаров» это может дойти до переписывания log4j, apache commons и google collections. Мы же этого не хотим, правда?
Но в общем конечно да, абсолютно согласен с тем, что весь этот большой Ынтерпрайз должен сдохнуть и быть заменен минимум легковесных решений. И то что JSF, EJB это гнилые помидоры, которым место не в нашем (прекрасном) мире.
Я понял претензии к Очень Серьезным Фирмам тм, но не совсем понимаю что происходит с маленькими веб аппликациями. Например я работал в небольшой SEO конторе. Это был мой первый веб проект, поэтому для юай я взял Vaadin (не время было учить и писать сиэсэсы). Чтобы экономить время на написании стандартных запросов, туда же присобачил Hibernate. Чтобы мои валидации легко писались и были не связаны с представлением, я использовал JSR валидации аннотациями. Разбираться самому с лайфсайклом некоторых обьектов, да и чтобы не таскать все через конструкторы/статик методы я использовал Spring, который создавал мои сервисы, имеющие бизнес логику и инжектил их в юай листенеры (например нажатия на кнопку). Ну и конечно не стал придумывать свой велосипед с квадратными колесами, и заюзал Spring Security для авторизации/аутентикации. Конечно Maven для всего этого счастья, не буду же я таскать джары с собой. В результате выходит немало фрэймворков, но работа шла очень быстро, и томкат стартовал за 10 секунд.
Внимание вопрос, как я мог сэкономить время НЕ ИСПОЛЬЗУЯ все эти библиотеки и фрэймворки?
а) если после CI у Вас поломанный транк, значит Вы что — то делаете не так. Каждый коммит сопровождается билдами и тестами, а если они не проходят, все идут дружно помогать тому кто сломал, потому что коммиты остальных зависят от него. Вся идея в CI как раз в вечно здоровом транке.
б) баги сливаются вместе в транк, но там их в разы легче обнаружить, потому что если они живы, то их не нашли тесты и далее их могут найти только QA (в обычной схеме), но в случае CI есть большой шанс что их найдут еще раньше, другие разработчики которые работают с этими модулями. Всяко лучше чем ВНЕЗАПНО за неделю до релиза сломать мэйнлайн нафиг тонной изолированных багов, а потом иди выясняй кто виноват.
в) Смотрите выше. Транк не нерабочий, он вполне проходит тесты и билд, хотя функциональность может быть еще не дописанной (но на это есть тоже ответ в статье).
Я работал в фирме, у которой был (почти, не хватало тестов, но это уже другая проблема, хотя критичная, не спорю) CI, и команда из 80+ разработчиков как раз замечательно уживалась благодаря Jenkins и общему транку.
Я перечитал статей о программировании. Прочитав заголовок ожидал нестандартную структуру данных «белка», думал с воображаемым колесом это как то связанно.
Мартин говорит, что он предпочитает просто не включать его, т.е не добавлять обращение к методу, кнопку на экран, пунк в менюшку, открывать WS и т.д. Согласен что всегда может быть факап, но тот нету серебряной пули и надо плясать от различных факторов, среди которых количество разработчиков (100 кодеров фул тайм над одной системой без CI явно до добра не доведут), насколько взаимосвязаны компоненты системы над которой идет разработка (опять же, чем более связаны — тем больше нужда в CI).
В моей прошлой фирме у нас был отдельный брэнч для релиза и перед каждым релизом в него мерджились из транка. Но тут возникала другая проблема, из за того что релиз был вечный народ чинил баги в релизе и не сливал назад в транк. К тому же мерджи из транка иногда делались «пинцетом», чтобы не вытащить то, что не хотели и в результате транк потихоньку терял свою актуальность. Я думаю, что классический, проверенный временем подход — транк для разработки, брэнч на каждый релиз — имеет наилучший баланс между всех зол. Все понимают что через две недели этот брэнч умрет, и поэтому чинят сначала в транке, чтобы не получить по башке за некромансию из старых брэнчей, с другой стороны люди будут писать легко включаемые — выключаемые фичи и это будет способствовать модулярному подходу (только тут есть опасность закоментированного кода в VCS, что выглядит ужасно). В Вашем случае у меня сложилось впечатление что ваш транк стал релиз кандидатом и люди в нем не работали, т.е не использовали как мэйнлайн и в результате не получали плюшки CI. Тут уже вопрос что важнее для каждой фирмы, на эту тему я уже рассуждал в прошлом абзаце :-)
Об этом пишут в каждом топике про гуглоочки, я гарантирую это!
А вот с доказательствами хуже. Я гуглил на эту тему, но видимо так себе, ибо ответа не нашел. Вот запостил вопрос на Skeptics@SE, посмотрим что скажут.
** 2005 July 8
**
** The author disclaims copyright to this source code. In place of
** a legal notice, here is a blessing:
**
** May you do good and not evil.
** May you find forgiveness for yourself and forgive others.
** May you share freely, never taking more than you give.
**
*************************************************************************
По Вашему мнению я должен говорить не «дизайн паттерн — фактори», а «шаблон проектирования — фабрика»? Или может Вы расскажите как правильно Java писать и произносить?
Не всегда написание какого то слова значит что
это представитель такого быдлачеловек подвластен макетингу. Иногда просто есть разные семантические контексты среды в которой люди обитают.А с идеей «уменьшения джаров» это может дойти до переписывания log4j, apache commons и google collections. Мы же этого не хотим, правда?
Но в общем конечно да, абсолютно согласен с тем, что весь этот большой Ынтерпрайз должен сдохнуть и быть заменен минимум легковесных решений. И то что JSF, EJB это гнилые помидоры, которым место не в нашем (прекрасном) мире.
Внимание вопрос, как я мог сэкономить время НЕ ИСПОЛЬЗУЯ все эти библиотеки и фрэймворки?
а) если после CI у Вас поломанный транк, значит Вы что — то делаете не так. Каждый коммит сопровождается билдами и тестами, а если они не проходят, все идут дружно помогать тому кто сломал, потому что коммиты остальных зависят от него. Вся идея в CI как раз в вечно здоровом транке.
б) баги сливаются вместе в транк, но там их в разы легче обнаружить, потому что если они живы, то их не нашли тесты и далее их могут найти только QA (в обычной схеме), но в случае CI есть большой шанс что их найдут еще раньше, другие разработчики которые работают с этими модулями. Всяко лучше чем ВНЕЗАПНО за неделю до релиза сломать мэйнлайн нафиг тонной изолированных багов, а потом иди выясняй кто виноват.
в) Смотрите выше. Транк не нерабочий, он вполне проходит тесты и билд, хотя функциональность может быть еще не дописанной (но на это есть тоже ответ в статье).
Я работал в фирме, у которой был (почти, не хватало тестов, но это уже другая проблема, хотя критичная, не спорю) CI, и команда из 80+ разработчиков как раз замечательно уживалась благодаря Jenkins и общему транку.
В моей прошлой фирме у нас был отдельный брэнч для релиза и перед каждым релизом в него мерджились из транка. Но тут возникала другая проблема, из за того что релиз был вечный народ чинил баги в релизе и не сливал назад в транк. К тому же мерджи из транка иногда делались «пинцетом», чтобы не вытащить то, что не хотели и в результате транк потихоньку терял свою актуальность. Я думаю, что классический, проверенный временем подход — транк для разработки, брэнч на каждый релиз — имеет наилучший баланс между всех зол. Все понимают что через две недели этот брэнч умрет, и поэтому чинят сначала в транке, чтобы не получить по башке за некромансию из старых брэнчей, с другой стороны люди будут писать легко включаемые — выключаемые фичи и это будет способствовать модулярному подходу (только тут есть опасность закоментированного кода в VCS, что выглядит ужасно). В Вашем случае у меня сложилось впечатление что ваш транк стал релиз кандидатом и люди в нем не работали, т.е не использовали как мэйнлайн и в результате не получали плюшки CI. Тут уже вопрос что важнее для каждой фирмы, на эту тему я уже рассуждал в прошлом абзаце :-)
А вот с доказательствами хуже. Я гуглил на эту тему, но видимо так себе, ибо ответа не нашел. Вот запостил вопрос на Skeptics@SE, посмотрим что скажут.