Мы в ew.am используем две базы данных — postgresql для почти всех данных, для вещей вроде биллинга, для которых очень важна транзакционность и целостность данных. А MongoDB используем для аналитики, и кучи других вещей, которые сложно запихать в реляционную систему.
Например, в MongoDB мы храним системы достижений, учета посещения одним пользователем профиля другого — пресловутые «ваш профиль недавно смотрели» и т.п.). Ну и интернационализация (i18n) вся в MongoDB лежит, так как скорость доступа очень высока, и можно динамически через админку редактировать эти данные.
Сразу предупрежу, что у нас все на RoR написано, поэтому в этом контексте могу сказать про легкость использования:
В нашем случае, нереляционная база не требует большего количества кода, чем реляционная.
По факту, и с Postgre, и с MongoDB мы работаем через driver и ORM. Для Postgre это стандартный RoR'овский ActiveRecord, а для MongoDB — MongoMapper. Они оба умеют проксировать объекты базы данных на обычные ruby-классы, и транслируют методы-обращения в нужный язык запросов (sql для postgres, javascript api для Mongo).
Так что в итоге количество кода, которое мы пишем, не зависит от хранилища «под капотом», а зависит от сложности бизнес-логики.
Вы это, html и css код генерите в сервлетах, что ли, что перекомпилить каждый раз приходится, когда клиент решил подвинуть что-то на пискель?
Ну, тогда действительно, с таким подходом ну его, эту веб-разработку на java.
Ну тут надо следовать правилу большого пальца, на мой взгляд.
Если собираешься писать аннотацию, то надо быть точно уверенным, что она соответствует следующим условиям:
не имеет побочных эффектов,
будет использоваться десятки и сотни раз в проекте,
легка для понимания (и не допускает двойных толкований своей функциональности даже исходя из своего названия, для облегчения понимания новых разработчиков в проекте).
Если аннотация удовлетворяет этим требованиям, писать стоит. Если нет — надо еще семь раз подумать перед написанием :)
С выводом не согласен.
На мой взгляд, аспекты как раз-таки повышают читабельность кода за счет уменьшения «лишнего кода» (эм, как еще можно перевести boilerplate code? :) и за счет «сокрытия сложности» от конечного разработчика бизнес-логики.
Сравните сами:
public class TaskDao {
Logger logger = Logger.getLogger("com.mycompany.dao.TaskDao");
public void saveTask(Task task) {
EntityManager em = EMF.getInstance().createEntityManager();
EntityTransaction tx = null;
try {
tx = em.getTransaction();
tx.begin();
Разумеется, если глянуть «под капот» аннотации, то сложность можно найти. Но достаточно разобраться лишь раз, что там происходит, и в последствии можно получить куда как более чистый и читабельный код без всяких побочных эффектов.
Я вообще не представляю себе современный проект на java без аннотаций.
Ладно, не хотите ходить в википедии, объясню на пальцах.
Аналогия служит для того, чтобы наглядно, «на пальцах» объяснить собеседнику свою позицию.
И в данном случае VolCh через пример пытается объяснить собеседнику, почему ст. 273 не требует наличия пострадавших для возбуждения уголовного дела.
Естественно, никто (в т.ч. и VolCh) не ставит знак равенства между понятиями «оружие» и «вредоносное ПО».
P.S. К чему цепляться к этим его словам — искренне не понимаю.
Ну ко всему закрытому финансовому софту недоверие, может, и не появится, а вот к любому софту, среди авторов которого числится Жуков В., сильнейшее подозрение точно появится.
Он предполагает, что вы просто выписали из толкового словарика все словосочетания, начинающиеся со слова «тактильная» и постите их сюда.
Пока что смысл в ваших постах не проглядывается. Извините.
Нет, я его сообщение вообще не видел при отправке. Так что комментарий был вам.
Но с ним я тоже не согласен. Главное, чтобы код работал, работал быстро, и поддерживался легко. И не надо никаких идеологий сюда примешивать. Повторюсь, я готов рассуждать о best practicies, о производительности, расширяемости, но не об идеологии.
То есть, вы хотите сказать, что делаете противоестественную вещь, добавляя в язык классы? Ведь, насколько я помню, в спецификации слово «class» встречается только в одном-единственном месте — в списке зарезервированных слов.
Что касается меня, то я пас.
Мне не нравится ваш любимый ООП-через-классы тем, что он «стоит» интерпретатору дополнительных телодвижений. Javascript classes came at cost, ага.
Идеология языка? Что это? Пока интерпретатор может сожрать ваш код, идеология языка в порядке.
Можно рассуждать о каких-то best practicies, perfomance penalties, etc., но не об идеологии.
%)
По моему, мы говорим о разных вещах. Извините, что влез в ваш с asis спор.
Narical говорит, что раздача электронной копии ничем не отличается по факту от того, что мы просто дали почитать книгу друзьям, членам семьи etc.
Ему на это отвечают, что нет, разница есть, и очень большая — электронной копией он может поделиться, в теории, со всей планетой за неделю (а то и быстрее), тогда как бумажной копией (воспользуюсь вашими рассчетами) — хорошо если с 52-мя людьми за год.
Тут нужно уточнить, что спор на эту тему размазан по нескольким тредам в комментариях, просто тут мне показалось удобнее ответить.
Я в русле этого спора и указываю, что, таки, разница между электронной раздачей и «дать почитать книгу» велика, и даже очень.
Что касается вашего примера, то все равно вы не правы и, в случае электронной копии, 52 человека прочитают ее за неделю, и точка. Скорость распространения отличается на порядки. Т.е. бумажную книгу распространить получится быстрее только в случае если реципиенты овладеют, скажем, скорочтением, а скорость распространения электронной копии ограничивает только введенное вами дополнительное условие — что никто из получивших электронную версию больше ни с кем ей не поделится.
Все же, неодинаков.
В случае печатной книги — 52 человека в течении года.
В случае электронной версии — 52 человека за неделю (т.е. за год потенциально 2711 человек), и, к тому же, каждый из них тоже может поделиться поделится книгой.
Например, в MongoDB мы храним системы достижений, учета посещения одним пользователем профиля другого — пресловутые «ваш профиль недавно смотрели» и т.п.). Ну и интернационализация (i18n) вся в MongoDB лежит, так как скорость доступа очень высока, и можно динамически через админку редактировать эти данные.
Сразу предупрежу, что у нас все на RoR написано, поэтому в этом контексте могу сказать про легкость использования:
В нашем случае, нереляционная база не требует большего количества кода, чем реляционная.
По факту, и с Postgre, и с MongoDB мы работаем через driver и ORM. Для Postgre это стандартный RoR'овский ActiveRecord, а для MongoDB — MongoMapper. Они оба умеют проксировать объекты базы данных на обычные ruby-классы, и транслируют методы-обращения в нужный язык запросов (sql для postgres, javascript api для Mongo).
Так что в итоге количество кода, которое мы пишем, не зависит от хранилища «под капотом», а зависит от сложности бизнес-логики.
Вроде с офф. сайта убрали подтверждение, нет?
Гугл не написан на яве, а использует ее в некоторых проектах.
Написаны на java, высоконагруженные веб-проекты.
Ну, тогда действительно, с таким подходом ну его, эту веб-разработку на java.
А мы, к примеру, ничего не перекомпиливаем.
Если собираешься писать аннотацию, то надо быть точно уверенным, что она соответствует следующим условиям:
Если аннотация удовлетворяет этим требованиям, писать стоит. Если нет — надо еще семь раз подумать перед написанием :)
На мой взгляд, аспекты как раз-таки повышают читабельность кода за счет уменьшения «лишнего кода» (эм, как еще можно перевести boilerplate code? :) и за счет «сокрытия сложности» от конечного разработчика бизнес-логики.
Сравните сами:
С:
Разумеется, если глянуть «под капот» аннотации, то сложность можно найти. Но достаточно разобраться лишь раз, что там происходит, и в последствии можно получить куда как более чистый и читабельный код без всяких побочных эффектов.
Я вообще не представляю себе современный проект на java без аннотаций.
А с мыслями в посте в согласен.
Аналогия служит для того, чтобы наглядно, «на пальцах» объяснить собеседнику свою позицию.
И в данном случае VolCh через пример пытается объяснить собеседнику, почему ст. 273 не требует наличия пострадавших для возбуждения уголовного дела.
Естественно, никто (в т.ч. и VolCh) не ставит знак равенства между понятиями «оружие» и «вредоносное ПО».
P.S. К чему цепляться к этим его словам — искренне не понимаю.
Пока что смысл в ваших постах не проглядывается. Извините.
Плюс в карму «за беспокойство» :)
Но с ним я тоже не согласен. Главное, чтобы код работал, работал быстро, и поддерживался легко. И не надо никаких идеологий сюда примешивать. Повторюсь, я готов рассуждать о best practicies, о производительности, расширяемости, но не об идеологии.
Что касается меня, то я пас.
Мне не нравится ваш любимый ООП-через-классы тем, что он «стоит» интерпретатору дополнительных телодвижений. Javascript classes came at cost, ага.
Можно рассуждать о каких-то best practicies, perfomance penalties, etc., но не об идеологии.
По моему, мы говорим о разных вещах. Извините, что влез в ваш с asis спор.
Narical говорит, что раздача электронной копии ничем не отличается по факту от того, что мы просто дали почитать книгу друзьям, членам семьи etc.
Ему на это отвечают, что нет, разница есть, и очень большая — электронной копией он может поделиться, в теории, со всей планетой за неделю (а то и быстрее), тогда как бумажной копией (воспользуюсь вашими рассчетами) — хорошо если с 52-мя людьми за год.
Тут нужно уточнить, что спор на эту тему размазан по нескольким тредам в комментариях, просто тут мне показалось удобнее ответить.
Я в русле этого спора и указываю, что, таки, разница между электронной раздачей и «дать почитать книгу» велика, и даже очень.
Что касается вашего примера, то все равно вы не правы и, в случае электронной копии, 52 человека прочитают ее за неделю, и точка. Скорость распространения отличается на порядки. Т.е. бумажную книгу распространить получится быстрее только в случае если реципиенты овладеют, скажем, скорочтением, а скорость распространения электронной копии ограничивает только введенное вами дополнительное условие — что никто из получивших электронную версию больше ни с кем ей не поделится.
В случае печатной книги — 52 человека в течении года.
В случае электронной версии — 52 человека за неделю (т.е. за год потенциально 2711 человек), и, к тому же, каждый из них тоже
может поделитьсяподелится книгой.