Сергей Сергеев: а в чем ирония? автор явно работает абсолютно вчерную. Если при этом при обороте <100k он смотрит на экономию долей процента - идея платить 3-10к в месяц за ведение ип/ооо его явно не прельстит. А платежек кто работает с физиками - я лично не знаю.
Boy: это как раз не проблема. если приложение выстреливает, то в первые 2-5 дней рост идет по экспоненте.
А вот если у приложения стоит куча покупных 5, хвалебные отзывы - а реальные люди видят что это треш и ставят единицу - это палится достаточно легко.
Boy: без разницы. у них есть план по типу приложений которые надо продвигать в определенное время. условно весной - приложения для туризма, неделя перед 1 сентября - приложения для учебы, итд итп. Явно выраженной цикличности нет, надо узнавать и общаться.
Кирилл Горелов: я затрудняюсь сказать как работает именно эта штука.
Я имел дело с smpp в 2009 году, и у нас задача была наоборот - получать смски на короткий номер.
Подключались мы к билайну, мтс и региональным отделениям мегафона.
У каждого оператора была а) своя базовая версия smpp б) книжечка страниц на 20 в чем реализация оператора отличается от выбранной базовой версии.
Возможно с тех пор стало лучше.
Возможно отправка смс проще чем приемка.
Но в любом случае что бы получить smpp доступ к отправке - таки надо иметь объемы.
gvozd1989: зачем делать деплой через git-ftp? можно не настроить хуки, зацепить к ним что угодно от phpci до собственного bash скрипта из 5 строчек - и все будет само выкладывать
Артём Щурин:
Статические объявления вычисляются во время компиляции скрипта.
Попытка присвоить этим переменным значения, являющиеся результатом выражений, вызовет ошибку обработки.
z0rgoyok: это вопрос бизнес логики уже а не клиент сервера.
Сделайте третий метод в апи "курьер получил уведомление что заказ доставлен ему".
Если отзыв не приходит в течении некоторого времени - шлите смс/звоните голосом, Etc
z0rgoyok: не должно быть у курьера возможности ничего отменить.
если запрос на сервер ушел - то пока мы не получили от сервера ответ с состоянием - все должно блокироваться.
z0rgoyok: я так понимаю это резервирования заказа за курьером? кто первый успел тот и молодец?
Тогда все очень просто:
Шлем запрос на сервер "я доставлю этот заказ". Сервер обрабатывает запрос и отвечает статусом заказа в текущий момент (свободен, твой, не твой)
Если обрыв связи - просто шлем этот запрос еще раз, и так в цикле до тех пор пока таки не получим ответ от сервера.
Тут главное что бы сервер корректно обрабатывал такое поведение и спокойно отвечал каждый раз "чувак, заказ твой, все хорошо"
Viktor Koltcov: Идея в том что каждый из запросов не ломает ничего сам по себе.
Т.е клиент отправляет подтвердение на сервер - допустим до сервера оно дошло и тут случился обрыв связи.
Клиент просто берет и отправляет это же подтверждение еще раз - сервер видит что такое уже было и говорит "ok".
На случай долгих разрывов можно дополнительно реализовать метод запроса статуса подтверждения, но это уже излишне как мне кажется
bernex: вообще это ресурсоемкий запрос к сожалению очень.
В самом общем виде можно писать
select * from order
where
order_id IN (select order_id from order_position WHERE good_id = 2)
AND
order_id NOT IN (select order_id from order_position WHERE good_id in (3,4))
Этот запрос не будет использовать индексы, но зато наиболее читаем)
