Нет, все работает на обычном хостинге. Самом обыкновенном. В том-то и прикол. Самое тяжелое было сделать он-лайн отладку пользовательских скриптов при этом.

Ух ты, и такое есть? Вот, блин, как я отстал! А как при обычном хостинге с web, как их, сокетами... юзаться не подскажешь?

Предвосхищая вопросы по выделенному серверу и вебсокетам.

Дело в том, что когда соединение неустойчиво, то сокеты рвутся и требуется восстанавливать соединение с аутентификацией (можно передавать ID предыдущего соединения). А рвется даже когда ты с планшетом или телефоном идешь из цеха в цех, например. И это даже при wifi. А мобильный сокет рвется каждые 15 секунд оператором. Требуется передавать пинги. Не буду рассказывать далее: умных учить-только портить. Выделенный сервер, если у вас SaaS, сколько соединений одновременно должен держать? Это если у вас пять пользователей, то да. Или Гугл на побегушках... Тогда ой! А так попробуйте стартовать на выделенном оборудовании, набирая клиентов.

Для начала опирался на это
Потом узнал, что Аппач более 1200 соединений не держит (какие там 60тыс)
Хостинг подразумевается сторонний (!) Редко кто позволяет держать запущенный процесс более 30 сек.
Создать сокет на PHP не проблема, проблема пробиться через варевол хостинга. У нормального хостера 80 и 8080, тем паче 443, порты заняты. Через 0 и 127.0.0.1 у меня тоже не получилось.

Поделитесь опытом поподробнее, пожалуйста! Но только если Вы работали через стандартный хостиг, а не выделенку или VPS.

Если свой сервер, то нафик PHP - лучше уж на NODE. Потом DDOS атаки предусмотреть. И так далее... А тут статистика: 9 из 10 проектов, хоть и рабочие, а не взлетают. Причина проста - пользователей нет. Ну нет и все, а деньги вложены. Я тут с ужасом натолкнулся на то, что мои потенциальные клиенты не знают, что такое смартфон!!! А я буду заморачиваться, развивать инфраструктуру. Так что решение на ПРОСТОМ хостинге. Плачу хостеру, он там сам рам разбирается с атаками и масштабированием. А как иначе предложить недорогую услугу?

Нет, не смогу. Более того, написано без юнитов. Понимаю, что не правильно, но было не до того. Если сказать честно, то сначала и уверенности, что это все заработает не было. Потом начало оживать, а теперь... Проект разросся. Некоторые куски написаны, лишь бы заткнуть дыру. Вижу, что не оптимально. Тут спрашивали о будущем проекта. Проект рабочий, но на нагрузку в 100 клиентов по 10 пользователей явно сейчас не рассчитан. Главное было найти решения проблем, найти подходы. На бумаге-то красиво было, а стал воплощать... Сейчас можно сказать, что решены концептуальные проблемы. Т.е. определены методы и подходы. По-хорошему надо теперь обобщить, привести к ООП. Но... Не факт, что проект окажется востребован до такой степени, что потребуется что-то переделывать.

дичь какая-то...

как одно из другого вытекает

отзывы:

авторERP для малого бизнеса

щито??
Казуальное поведение оптимальной динамической системы в поле антоганистического воздействия описывается вполне стохатически. Между прочим вполне конкретная фраза. Но выглядит как дичь тому, кто ничего в этом не понимает.

Ок! Обратите внимание, что сначала идет раздел о том, что учет на смартфоне он и есть обычный учет, но только потроха работают на смартфоне. Во втором разделе пишется о том, что мобильный учет - это не учет на мобильном (кстати, правильнее было бы писать сотовом), а учет, обладающий свойством мобильности - подвижности, способности быстро адаптироваться к новым условиям.

Таким образом, заголовок "Мобильный учет на смартфоне" - это учет, который работает на сотовом, но при этом может быть легко и быстро настроен для работы в новых условиях. Учет "мобилен".

Теперь немного сравнений. Если Вы возьмете обычный учет (например, 1С) и добавите поле, то система будет перестраивать данные под новую структуру. В том числе и прежние данные, которым это поле было не нужно. Но добавить - это просто, а удалить... Попробуйте удалить и полезть в документ из прошлого. Все станет колом, если данные из удаленного поля использовались для отображения или вычислений. Т.е. следом надо править и тексты программ. А если после правок потребуется внести документ задним числом, то будете вносить его по новым правилам, а не так, как это было в то время. Учет web1s.ru обеспечивает, благодаря иной организации данных привязку полей и скриптов вычислений по дате. Т.е. документы одного вида могут иметь разную структуру и правила заполнения в зависимости от даты. Вчера вы работали и все вас устраивало. Сегодня обнаружилась проблема и вы что-то меняете. Вчерашний документ будет работать по вчерашним настройкам, а сегодняшний - по новым. Повторюсь - нововведения не ломают прошлое. Мобильному ( не в смысле на мобильном, а подвижному) учету не грозят изменения - делайте их по мере возникновения проблем с учетом.

Это проблему пришлось решать по-другому. Обычно отчет - это то, что обращается к документам и сводит данные. Вы правильно акцентировали - аналитические регистры нужны. Сделан один аналитический регистр для "проводок". Для каждого документа можно (опять же по датам) описать что и откуда брать и куда помещать в регистр учета. Отчеты обращаются к регистру, а потом, если надо, разворачивают информацию по документам. Однако разделено понятие "фильтрация по данным" и "вывод сводных данных". Отчеты занимаются вторым, а первое работает сразу в "журнале" документов или в справочнике. Например, в справочнике товаров, вы можете открыть данные товара и тут же развернуть список документов, которые повлияли на остатки и просмотреть эти документы. В совокупности это покрывает 80% потребности в анализе информации даже без отчетов, где данные сводятся и, при необходимости, раскрываются. Я вообще сторонник применения правила Паретто. Таким образом "версионность" документов отделена от отчетов, так как они напрямую аналитические данные из документов не получают, а берут их через "переходник" - аналитический регистр. Конечно, я описал схематически, концептуально.