Физически покупка уже работает, и найти нужную форму тоже уже можно, минуя указанную промо-страницу — непосредственно через каталог. Пресс-релиз, видимо, на подходе.
Просто у вас второй и третий пункты тоже очень категоричны.
Эт все из опыта. Я неоднократно видел проблемы, которых можно было бы избежать, потратив какое-то разумное время на проектирование. Точно так же, как не видел ни одного использования ОРМа в более-менее серьезном проекте, где в итоге не пришли бы к прямому выполнению SQL-запросов или не вносили бы изменений в архитектуру исключительно, чтобы исправить проблемы ОРМа.
Пример: заказчик захотел добавить новое поле к учётке пользователя
Так если изменения постоянны, то скрипты миграции можно не заносить в релизную ветку. Можно же просто сохранить новую схему таблиц и зафиксировать в документации, что после такой-то ревизии код несовместим с предыдущими релизами.
В общем, опять же — у меня хватает примеров хранения sql-кода в репозитории, когда заносятся или пакеты (если СУБД их поддерживает), или функции, сгруппированные в файлы на подобие пакетов (если СУБД не поддерживает пакеты).
Я в чём-то не прав?
При желании, можно извратиться как угодно. Вам самому не кажется странным, что вместо одной сущности — СУБД — у вас добавляется еще две: кэш и орм? Как же принцип K.I.S.S? =) Ну да ладно.
Продолжение спора, в общем-то, непринципиально, ага.
Вы чересчур категоричны.
Я могу аргументировать каждое свое предложение.
А Вы?
Переменные — нужны.
Более того, переменные в большинстве известных мне языков программирования СУБД есть.
Массивы не везде, но не для всех проектов и нужны.
Приведите пример, пожалуйста, для чего нужны массивы в бизнес-логике платежной системы?
Да нет, я всего лишь к тому, что кривой код можно написать на чем угодно. И более того — большинство кривого кода написано не на языках хранимых процедур СУБД.
их трудно хранить в текстовых файлах
Чем?
кроме hibernate есть много других orm, не столь тормозных и без костылей
ORM без костылей — это нонсенс просто из определения ORM. Просто потому, что маппинг множеств и отношений между множествами в объекты влечет кучу проблем. Всегда. Могу предложить ссылку на классику на эту тему.
каким боком orm может нарушить acid принципы в субд
Ну, конечно, ОРМ обеспечивает все буковки аббревиатуры гораздо лучше, чем сама СУБД.
у вас есть положительный пример использования бизнес-логики в базе данных
За последние четыре года я сделал как минимум три крупных проекта Мэйл.Ру, используя логику приложения в СУБД. В разных СУБД, надо сказать. И везде это было оправданно. И везде работает. Нагрузки — от сотен хитов в секунду до десятков тысяч.
С другой стороны, это всего 35-70 писем в неделю.
Хотя, видимо, это как повезет, поскольку лично мне падает от силы около 10 писем в неделю. Однако на мой ящик на собственном сервере падает в разы больше спама. Вот интереса ради даже посчитал: 770487 за неделю отфильтровал мой антиспам, который фильтрует сильно хуже мэйлового. При том, что ясчик на Мэйле сильнее засвечен.
Но эт так, лирика…
Интереснее другое — какого рода спам падает к вам?
Хтмл с кучей текста или с минимум текста и ссылкой на какой-нить укорачиватель?
Вы забыли.
А люди из Яндекса, Рамблера, ВКонтакте, Гугла постоянно помнят, что он есть…
О чем это говорит? =) Ну, наверное, о том, что Вы не работаете в этих уважаемых конторах.
Понятно.
А как считаете, сколько в сутки спам-писем падало бы в Ваш ящик без спам-фильтров?
И сколько из них должно отфильтровываться?
Только не в идеальном мире с искусственным интеллектом, а в нашем земном?
Не приходило в голову, что в Агенте нет рекламы потому, что Мэйл зарабатывает на рекламе в других своих проектах достаточно, чтобы позволить ее отсутствие в мессенджере?
Кстати, вот вам еще домен без рекламы: edu.mail.ru/
На Мэйле стояла витрина.
А год назад сделали свою платежку
В общем, опять же — у меня хватает примеров хранения sql-кода в репозитории, когда заносятся или пакеты (если СУБД их поддерживает), или функции, сгруппированные в файлы на подобие пакетов (если СУБД не поддерживает пакеты).
При желании, можно извратиться как угодно. Вам самому не кажется странным, что вместо одной сущности — СУБД — у вас добавляется еще две: кэш и орм? Как же принцип K.I.S.S? =) Ну да ладно.
Продолжение спора, в общем-то, непринципиально, ага.
Я могу аргументировать каждое свое предложение.
А Вы?
Переменные — нужны.
Более того, переменные в большинстве известных мне языков программирования СУБД есть.
Массивы не везде, но не для всех проектов и нужны.
Приведите пример, пожалуйста, для чего нужны массивы в бизнес-логике платежной системы?
Чем?
ORM без костылей — это нонсенс просто из определения ORM. Просто потому, что маппинг множеств и отношений между множествами в объекты влечет кучу проблем. Всегда. Могу предложить ссылку на классику на эту тему.
Ну, конечно, ОРМ обеспечивает все буковки аббревиатуры гораздо лучше, чем сама СУБД.
За последние четыре года я сделал как минимум три крупных проекта Мэйл.Ру, используя логику приложения в СУБД. В разных СУБД, надо сказать. И везде это было оправданно. И везде работает. Нагрузки — от сотен хитов в секунду до десятков тысяч.
Перефразирую: «Взаимодействие кучи кривонаписанного кода приводило к трудноотлавливаемым багам».
Перефразирую: «Отсутствие возможности поООПить — ужасно».
Перефразирую: «Мне пофиг на производительность, ACID и прочую фигню. Да и с SQL у меня плохо».
А вот теперь фраза от меня: и слава святым!
2. Нормально спроектированная система в миграции не нуждается.
3. ОРМ — говно.
Хотя, видимо, это как повезет, поскольку лично мне падает от силы около 10 писем в неделю. Однако на мой ящик на собственном сервере падает в разы больше спама. Вот интереса ради даже посчитал: 770487 за неделю отфильтровал мой антиспам, который фильтрует сильно хуже мэйлового. При том, что ясчик на Мэйле сильнее засвечен.
Но эт так, лирика…
Интереснее другое — какого рода спам падает к вам?
Хтмл с кучей текста или с минимум текста и ссылкой на какой-нить укорачиватель?
А люди из Яндекса, Рамблера, ВКонтакте, Гугла постоянно помнят, что он есть…
О чем это говорит? =) Ну, наверное, о том, что Вы не работаете в этих уважаемых конторах.
А как считаете, сколько в сутки спам-писем падало бы в Ваш ящик без спам-фильтров?
И сколько из них должно отфильтровываться?
Только не в идеальном мире с искусственным интеллектом, а в нашем земном?
www.exler.ru/expromt/16-12-2005.htm
И куча других способов сделать то же самое.
И не только на Мэйле.
Веб 2.0.
Но вообще — что Вам даст список адресов?
По нему даже спам не разослать…
Кстати, вот вам еще домен без рекламы:
edu.mail.ru/
Еды?