С какой целью?
В описанную схему ОСМП не вписывается, в качестве моментальной системы оплаты — тоже.
Всё равно придется переться куда-то еще.
Про осмп написано в полной версии статьи, где и первый способ взаимодействия описан.
В очереди, например, char(2). Почти 1300 статусов хватит за глаза.
Пары символов достаточно, чтобы примерно понять статус заявки, если приспичит сделать прямой SELECT.
Быдлокодинг — это программирование без включения головы.
Для данных, которые статичны 99% времени жизни проекта, Вы предлагаете плодить сущности в базе. Причем получать эти данные будете исключительно в веб-интерфейс и устанавливать из него же или из диспетчера. Что мешает завести конфиг (функцию, хэш, константы, что угодно), в котором хранить описание статусов и их коды?
Надо запихать статус в базу — взяли из конфига, запихали.
Надо вывести из базы, вывели построчно, в каждой строке заменили на текстовое представление если нужно.
Тем более, этих статусов по пальцам: «новая», «доставлена в ПС», «можно платить», «какая-то ошибка» (2-3 кода за глаза, дальше все равно в логи диспетчера лезть), «отказ платить», «отмена администратором», «устарела», «оплачена», «услуга оказана». Все остальные статусы — уже излишества. Итого 9-11 кодов максимум. И ради этого городить огород с таблицами, джойнами?
А историю статусов хранить не нужно?
Я считаю, что нет.
Там цепочка простая и часто однозначная: новая → в ожидании → ошибка
или новая → в ожидании → готово → изменился статус → выполнили услугу.
Вот логи диспетчера нужны обязательно.
Включая тексты ответов платежной системы.
Вы не знали, как внедрить карты, а кто-то не знает, как правильно спроектировать подобную систему и в итоге для каждой новой платежной системы Магазин пишет свой костыль. Никто не знает всего, правда?
Тут дело не в том, выпускают ли они карты.
А в том как ими пользуются люди.
Для многих если карта и есть, то, как правило, — это способ получить зарплату и обналичить в банкомате.
У меня, к сожалению, нет данных в каких регионах люди платят картами лучше или хуже.
За такой статистикой нужно к платежным системам обращаться или к тому же Киберплату, Хронопэю или Ассисту.
ОСМП работает по первому методу — с сообщением результатов операции на сайт Магазина.
Я не описывал этот метод, по сути он сводится к еще одной функции веб-интерфейса: определение какой терминал сообщает об оплате, вызове библиотеки, которая обработает этот вызов и вернет номер заявки в нашей системе (если мы опять организовали очередь). Далее библиотека работы с заявками поменяет статус. Фсё.
Но в целом, конечно, хорошо уметь принимать и пластик.
Чем больше методов (я не беру всякую экзотику), тем легче «окучить» пользователя и побудить его оплатить что-либо.
У самого пробег порядка 20 тыс км, т.е. имею некоторый опыт по теме.
Мсье мастер спорта по легкой атлетике?
20 тысяч для вашего возраста — это интенсивность 400–500 км/в месяц в течение последних 2-3 лет.
Более чем достаточно, чтобы стать мастером спорта.
200 км/месяц — норма среднего перво-второразрядника с беге на средние дистанции.
Нет, если постоянно контролировать ритм дыхания.
В этом плане полезно дышать не равномерно, а например, так:
два коротких вдоха, выдох, длинный вдох, выдох.
Можно частично заменить бегом с ускорениями, из круга на стадионе 100-200 с ускоряемся, затем 300-200 метров «отдыха» с обычной скоростью
Тут разные подходы есть.
Я б рекомендовал сериями 100-200-300-400-300-200-100.
И ровно такие же промежутки после каждого этапа ускорения, но не «обычной скоростью», а трусцой 4-5 км/ч.
Или еще вариант — «минута через минуту» 3-4 раза в серии.
Но не в коем случае не чаще 1-2 раз в неделю.
2-3 раза мы бегали при интенсивности 10 двухчасовых тренировок в неделю.
Правда, все это подразумевает нагрузки сверх описанного + желательно стадион.
Мой вам совет:
1. Уберите каунт — лучше обойтись экзистом или вообще вывалиться по no_data_found
2. Откажитесь от явного объявления курсоров.
3. Коммиты скидывайте пачками
4. Вместо установки флагов, лучше пользовать exception
Смотрели в его сторону, но не стали работать.
Проблема именно в том, что он пока мало распространен.
У себя внутри еще можно заюзать, но для общения с «внешним миром» он пока мало пригоден. Общаться приходится. А плодить на проекте много разных сущностей для одного и того же я не очень хочу.
Основной язык — Perl. В Мэйле вообще многие проекты работают на нем.
Фреймворк — свой, в опенсорсе его не найти.
Основные библиотеки — со CPAN'а.
Из внутренних разработок используем как раз либу для работы с JSON, которая быстрее, чем все выложенные на CPAN'e
СУБД — одна из доступных любому веб-девелоперу, подробнее не могу сказать.
Я Вам аналогичный вопрос задам. У меня есть собственные почтовые сервера, собственные домены. Есть некая рассылка, в которой участвуют исключительно продвинутые в плане инета люди (программисты, проджект-менеджеры, руководители компаний), никого лишнего там нет. Для участия в этой рассылке я создал отдельный почтовый ящик на одном из своих доменов, который вообще больше нигде не используется и не светится. Со сложным, несловарным именем. И что ж Вы думаете — через какое-то время на него начал приходить спам.
Вариантов, из-за которых на ящик может приходить спам — массы.
Кроме того, Вы возможно не знаете, но многие ящики, которые сейчас можно зарегистрировать, уже были когда-то зарегистрированы и удалены после неактивности владельца. Возможно, причина именно в этом — когда-то давно ящик уже засветился в спамерских базах.
Ну а то, что на проектах компании публикуются ящики в открытом виде, для меня не новость.
Но у нас весьма и весьма хороший антиспам, чтобы не допустить массового захламления ящиков пользователей. Например, при моей высокой активности на портале, спама мне приходит 5-6 писем в месяц. Для сравнения на вышеупомянутые собственные домены падает по 10-20 тысяч спам-писем в день. Поэтому, извините, но я не верю в «пачки спама», прорывающиеся на ящики Мэйла.
В описанную схему ОСМП не вписывается, в качестве моментальной системы оплаты — тоже.
Всё равно придется переться куда-то еще.
Про осмп написано в полной версии статьи, где и первый способ взаимодействия описан.
В очереди, например, char(2). Почти 1300 статусов хватит за глаза.
Пары символов достаточно, чтобы примерно понять статус заявки, если приспичит сделать прямой SELECT.
Нет, в коде писать
print $status_list->{ $status } || 'Неизвестный статус';Быдлокодинг — это программирование без включения головы.
Для данных, которые статичны 99% времени жизни проекта, Вы предлагаете плодить сущности в базе. Причем получать эти данные будете исключительно в веб-интерфейс и устанавливать из него же или из диспетчера. Что мешает завести конфиг (функцию, хэш, константы, что угодно), в котором хранить описание статусов и их коды?
Надо запихать статус в базу — взяли из конфига, запихали.
Надо вывести из базы, вывели построчно, в каждой строке заменили на текстовое представление если нужно.
Тем более, этих статусов по пальцам: «новая», «доставлена в ПС», «можно платить», «какая-то ошибка» (2-3 кода за глаза, дальше все равно в логи диспетчера лезть), «отказ платить», «отмена администратором», «устарела», «оплачена», «услуга оказана». Все остальные статусы — уже излишества. Итого 9-11 кодов максимум. И ради этого городить огород с таблицами, джойнами?
Я считаю, что нет.
Там цепочка простая и часто однозначная:
новая → в ожидании → ошибка
или
новая → в ожидании → готово → изменился статус → выполнили услугу.
Вот логи диспетчера нужны обязательно.
Включая тексты ответов платежной системы.
Именно это я и понимаю под «первым методом» — когда обмен информацией начинается с платежной системы.
А в том как ими пользуются люди.
Для многих если карта и есть, то, как правило, — это способ получить зарплату и обналичить в банкомате.
У меня, к сожалению, нет данных в каких регионах люди платят картами лучше или хуже.
За такой статистикой нужно к платежным системам обращаться или к тому же Киберплату, Хронопэю или Ассисту.
Впрочем, статья-то не об этом, правда?
Я не описывал этот метод, по сути он сводится к еще одной функции веб-интерфейса: определение какой терминал сообщает об оплате, вызове библиотеки, которая обработает этот вызов и вернет номер заявки в нашей системе (если мы опять организовали очередь). Далее библиотека работы с заявками поменяет статус. Фсё.
Описанные методы взаимодействия с ПС и организация обработки характерны не столько для Магазинов, сколько для агрегаторов вроде Robox'а.
Чем больше методов (я не беру всякую экзотику), тем легче «окучить» пользователя и побудить его оплатить что-либо.
Мсье мастер спорта по легкой атлетике?
20 тысяч для вашего возраста — это интенсивность 400–500 км/в месяц в течение последних 2-3 лет.
Более чем достаточно, чтобы стать мастером спорта.
200 км/месяц — норма среднего перво-второразрядника с беге на средние дистанции.
Урежьте-то цифру.
Нет, если постоянно контролировать ритм дыхания.
В этом плане полезно дышать не равномерно, а например, так:
два коротких вдоха, выдох, длинный вдох, выдох.
Если добровольно — таки да, привыкание гарантировано.
Я уже 6 лет как ушел из спорта, а подсознание помнит… Сны показывает :)
Видимо, только в школе и были.
Подготовка спринтера обязательно включает в себя кроссы несколько раз в неделю.
Тут разные подходы есть.
Я б рекомендовал сериями 100-200-300-400-300-200-100.
И ровно такие же промежутки после каждого этапа ускорения, но не «обычной скоростью», а трусцой 4-5 км/ч.
Или еще вариант — «минута через минуту» 3-4 раза в серии.
Но не в коем случае не чаще 1-2 раз в неделю.
2-3 раза мы бегали при интенсивности 10 двухчасовых тренировок в неделю.
Правда, все это подразумевает нагрузки сверх описанного + желательно стадион.
1. Уберите каунт — лучше обойтись экзистом или вообще вывалиться по no_data_found
2. Откажитесь от явного объявления курсоров.
3. Коммиты скидывайте пачками
4. Вместо установки флагов, лучше пользовать exception
официально
на Хабре
Проблема именно в том, что он пока мало распространен.
У себя внутри еще можно заюзать, но для общения с «внешним миром» он пока мало пригоден. Общаться приходится. А плодить на проекте много разных сущностей для одного и того же я не очень хочу.
Основной язык — Perl. В Мэйле вообще многие проекты работают на нем.
Фреймворк — свой, в опенсорсе его не найти.
Основные библиотеки — со CPAN'а.
Из внутренних разработок используем как раз либу для работы с JSON, которая быстрее, чем все выложенные на CPAN'e
СУБД — одна из доступных любому веб-девелоперу, подробнее не могу сказать.
Вариантов, из-за которых на ящик может приходить спам — массы.
Кроме того, Вы возможно не знаете, но многие ящики, которые сейчас можно зарегистрировать, уже были когда-то зарегистрированы и удалены после неактивности владельца. Возможно, причина именно в этом — когда-то давно ящик уже засветился в спамерских базах.
Ну а то, что на проектах компании публикуются ящики в открытом виде, для меня не новость.
Но у нас весьма и весьма хороший антиспам, чтобы не допустить массового захламления ящиков пользователей. Например, при моей высокой активности на портале, спама мне приходит 5-6 писем в месяц. Для сравнения на вышеупомянутые собственные домены падает по 10-20 тысяч спам-писем в день. Поэтому, извините, но я не верю в «пачки спама», прорывающиеся на ящики Мэйла.