Обычно его можно минимизировать в релизе за счет использования конструкции if (log.isInfoEnabled).
Если в андроидовском SDK такие методы не предусмотрены, стоит написать свой wrapper наподобие того, что сделал автор, и реализовать там эту функциональность.
Ну это может быть бага в JDBC драйвере, но не в коде приложения. Такие баги использовать очень сложно, поскольку они возникают редко, а узнать обстоятельства и проанализировать поведение может только разработчик, которому доступен код драйвера. Взломщику же, который не знает, что за драйвер стоит на сервере, навряд ли получится это сделать.
А у нас было определение такого рода "… тогда и только тогда, когда оно находится в 1НФ и каждый атрибут отношения функционально полно зависит от первичного ключа".
3НФ определялась как отношение, находящееся во 2НФ и не имеющее транзитивных или псевдотранзитивных функциональных зависимостей.
Стоит ли избавляться от XML целиком? На мой взгляд, XML предпочтительнее при регистрации бинов (потому что все в одном месте, очень удобно), но вот когда в XML требуется описывать структуры сущностей (hibernate) — я пас, это слишком муторно.
Ну как бэ мы не обсуждаем проблемы языков оторванно от конкретных ситуаций :)
Груви можно просто взять и подгрузить во время выполнения программы — и в этом вся фишка. Понятное дело, что в остальном разницы особой и нет, если программист не использует вещи, специфичные для груви и программирует так же, как бы программировал на Java. В этом случае груви ему, конечно, ни к чему.
Допустим у вас есть DAO-классы, которые выполняют некоторые запросы к БД. Для того, чтобы что-то в них быстренько поправить, нужно передеплоить приложение целиком. Ну или перезапускать, если у вас не app server, а десктопный свинговый клиент, к примеру. Это неудобно. У меня на работе коллеги написали автоматический деплоер, который подцепляет скрипты из папочки в рантайме. Очень удобно. Причем код, который деплоится в виде скрипта, можно смотреть эклипсом с полноценной подсветкой синтаксиса и интеллисенсом (поскольку IDE может считать его java кодом). Очень удобно для написания скриптов.
Мб, я на самом деле с OSGI не работал, знаю только, что там плагинная система. Но в любом случае написать ручками деплоер скриптов, который периодически сканирует папку и деплоит все что видит, это очень быстро по сравнению с использованием OSGI.
Первая часть, кстати, более информативна, на мой взгляд. А чтобы врубиться в то, как работают ветки, достаточно взять hg и попробовать, прочитав официальный man с вики-страницы проекта — mercurial.selenic.com/wiki/UnderstandingMercurial
Я так понимаю, эти проблемы происходят из того, что при мерже веток в свне остаются обе ветки (и ствол, и бранч). Хотя на самом деле необходимо в этом месте «закрыть» одну из веток (слияние же!). При последующих расхождениях будет создана новая ветвь, которую тоже можно смержить. Т.е. в свн все выглядит так:
| |
|\
| |
| |
А по идее должно быть так:
|
|\
| |
| |
DVCS (например, меркуриал) предлагают более подходящую модель. Ветки могут появляться где угодно и когда угодно, но при слиянии их результатом будет 1 ветка, а не 2. Естественно, влить заново изменения из уже смерженной ветки не выйдет, поскольку они УЖЕ включены в результирующую ветку и являются частью ее истории. Это все равно что просить систему сделать один и тот же коммит 2 раза подряд.
Если в андроидовском SDK такие методы не предусмотрены, стоит написать свой wrapper наподобие того, что сделал автор, и реализовать там эту функциональность.
3НФ определялась как отношение, находящееся во 2НФ и не имеющее транзитивных или псевдотранзитивных функциональных зависимостей.
Груви можно просто взять и подгрузить во время выполнения программы — и в этом вся фишка. Понятное дело, что в остальном разницы особой и нет, если программист не использует вещи, специфичные для груви и программирует так же, как бы программировал на Java. В этом случае груви ему, конечно, ни к чему.
(no joke)
| |
|\
| |
| |
А по идее должно быть так:
|
|\
| |
| |
DVCS (например, меркуриал) предлагают более подходящую модель. Ветки могут появляться где угодно и когда угодно, но при слиянии их результатом будет 1 ветка, а не 2. Естественно, влить заново изменения из уже смерженной ветки не выйдет, поскольку они УЖЕ включены в результирующую ветку и являются частью ее истории. Это все равно что просить систему сделать один и тот же коммит 2 раза подряд.