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

А где обычный в подобных случаях конт-вопрос от ogrudko - в чем цель воркаута, и как эта цель пересекается с христианством вообще ?

Открыл "Исповедь и святое причастие". Там в качестве образца приведен список основных грехов, для определения своего внутреннего духовного состояния: грехи перед Богом, против ближнего, против самого себя. При беглом просмотре - какие из них соотносятся с воркаутом, а какие нет

ps: "Грех - это не факт в биографии, который можно легкомысленно забыть. Грех - это 'черная печать', до конца дней пребывающая на совести и несмываемая ничем, кроме Таинства Покаяния. Грех обладает растлевающей силой, способной вызвать за собой цепочку последующих, более тяжких прегрешений..."

Глупость. Надеюсь ты и сам это понимаешь.

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

зы: я сталкивался с рассылкой (давно это было - автоматизировал отправку нескольких сотен писем с вложением секций многотомных архивов)... Заводится несколько пользователей, и рассылка делается с переключением обратного адреса. Сервер не определяет исходящие сообщения как спам - потому что отправители разные. К тому же отправления пачек сообщений запускалась через рандомные задержки (автоматизация рассылки) - это тот же подход, что и рассылка спама. Нужно лишь вынести в опции критерии цикличности переключений списков отправителей, и ресурсов под спам - и ты заморишься распознавать спам сообщения. Ладно, как хочешь.

WasD не стоит полагаться на метод выявления спамера по сообщениям с частотой нескольких постингов в секунду. Спамить могут и програмно, и руками. Частота спама может варироваться - от множества сообщений в секунду, до 1 сообщения в сутки (интервальное, с рандомной задержкой). Если защита будет прикручена тривиальная - она очень скоро может устареть... ее обойдут.

можно еще определять и сохранять в базе IP адрес пользователя. Понятное делр, что он динамический, и меняется... но как правило, в сесии спам-рассылки ийпишник не меняется. По IP можно определять регион (город)... и если после опрелеления спамера проходит бан, а затем с этого же региона делается запрос на регистрацию нового пользователя - вероятно это потенциальный спамер.

Зы: можно ввести списки - например список исключений. В списке исключений (админы, и проверенные люди - 100% не спамеры) - не фильтровать, не банить. Этот список на просмотр и корректировку доступен только админам... другие пользователи и знать не будут о такого рада дискриминации
Список подьзователей "под колпаком" - потенциальные спамеры (стаж небольшой, сообщений в форуме нет)... Если пользователь общантся на ыоруме и видно что он не спамер - он нереносится в список провереннвх людей...

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

По спам-зашите - вводится список фраз для бана. Фразы типичные для бана. Проанализировать характерные фразы в спам-сообщениях - и внести их в список.
На уровне движка на форуме делать анализ сообщений...
При определении такой фразы - можно банить пользователя... на сутки.
Или не банить сразу, а на уровне сайта на уровне форума отмечать признак "спам-сообщения" от пользователя. Если пользователь "частит" с сообщениями (например каждые 5 минут детектится от него спам) и они все распознаются как спам - бан на пользователя, с удалением его спам-сообщений.

как вариант, разрешать отправлять сообщения на форум пользователям с репутацией. И дать возможность накармить репутацию. +к репутации это рекомендация кого-то из старожил + к репутиции рассматривается "заявка" на ютубе (и в профиле) в виде своих подтягивани, или тренировки... или стишок на табуретке.

А если оставить для пользователя поле для ввода сообщений - вот и дневник сюда можно перетащить(на свою стену), а другим пользователям - комментить и тролить...

Статистику активности можно постить от имени автобота (с аватаркой автобота). Можно выделять области сообщений цветом. Например, твои сообщение отображаюся в ленте диалогом справа, сообщения тебе - слева. Автобот выдает просто балоны сообщений - не подвязанные к сторонами и каким-то другим цветом


Что-то типа такого Или типа такого

Все течет все меняется.. я ожидал, что ты ответишь что-то в ноте: "наш ресурс ориентирован не на общение, а на предоставление информационного контента.. не в пример ВК".
Твой же ответ на этот раз более гибок - не принимаешь, но по крайней мере уже не отрицаешь

Оформить ссылками можно. Это довольно однотипное (шаблонное) решение.
Другое дело, что "сообщения на форуме" и площадки более интересны в информационном плане, чем детализация списка ссылок на видео, и на комменты к статьям. "Cообщения на форуме" интересны в причину того, чтобы посмотреть последние ответы пользователя, площадки же - чтобы просмотреть список площадок с фильтром по автору, а не только по региону (стране/город).

ps: ты что-то вчера писал про возможное оформление стены
пользователя в виде динамически ленты активности - может тогда "ссылка на сообщения на форуме" утратит актуальность, но фильтрация площадок по автору все ревно интересна. Можно ее либо реализовать в виде ссылки, либо в виде дополнительного (альтернативного) фильтра площадок по автору, а не региону.

WasD, можно сделать так, чтобы число зарегистрированных площадок тоже было ссылкой, как и число количества сообщений на форуме ??
По клику по такой ссылке - переходить на страничку со списком зарегистрированных пользователем площадок, отсортированных по дате регистрации в обратном хронологическом порядке.

Вероятно, пользователи могли бы по такому списку пройтись и переподвязать координаты ими зарегистрированных площадок с "крышь домов" на более точные.

Хм...
Ну это уже что-то.
Попробуйте с конца - какие методы меняют данные реквизитов локации в базе?
МОжет для мониторинга - ввести какие-то параметры, чтобы отслеживать кто вызывает эти меторы - целенаправленно, или по какому-то событию происходит вызов.
И опять таки - логировать ID, время, и новое значние.
Было бы неплохо мониторить еще и старое значение - но это можно сделать на уровне базы (на уровне таблицы), включить тригер onUpdate (или как он там называется) и на уровне тргера прописать - insert into logTable и указать старое и новое значение отслеживаемых реквизитов. Вообщем - логировать. А потом уже думать, имея данные для анализа.

ps: для новых записей и удаления что-то типа onInsert и onDelete - что-то типа этого.

Не только. Есть еще корректировка данных. Когда вызываетя корректировка? На корректировку уходят инициализированные данные. Эти данные - расшаренные ? Отправляются данные фоновым процессом ?
Запрашиваются значения этих переменных откуда - из фонового процессе ? Может ли механизм работы основного процесса сделать изменения расшариваемых данных до того, как фоновый процесс еще не закончил работу ? Лочатся ли адреса переменных, пока фоновый процесс не закончил работу ?

Это так - размышления на скорую руку. Потому что хз что является причиной - мобильное приложение, или процесс на стороне сервера. Это я к тому, что не все так просто - "сели данные в базу и все".

WasD, ужасно смотрится мой предыдущий пост - "многа букафф, ниасилил"
В общем, я озвучил все свои мысли. Не думаю, что я могу что-то подсказать еще. Было бы интересно таки узнать из за чего такой происходит косяк с данными, и как вы собираетесь (и собираетесь ли вообще) его ловить за "хвост"

Полагаю что не так. Может быть несколько ситуаций.
1. Запускается что-то в потоке. И в зависимости от того успеет ли отработать процесс в потоке или нет - происходит изменение данных. Данные на уровне приложения - глобальные. Вот они и сохраняются уже измененными. Это что-то типа того, что происходит с личными данными - сейчас они корректные, а стоит походить по экранам.... и какой-то АсинкТаск изменяет данные на уровне Applicaton (приложения).
Применительно к личным данным - может быть это фоновая синхронизация площадок, может информация об регистраторе какой-то площадки выходи на уровень приложения - и садится в данные пользователя.
Может какая-то описка в коде, или временная переменная - заведенная для дебага, а потом не подчищенная.
2. Я предположил, что это System косячит. По крайней мере - почему площадка села на крышу колледжа, и рядом площадка с такой же картинкой - но по описанию видно что ее точно не System посадил. Может в этом направлении начать смотреть.

Бэкап нужен для того чтобы восстановить изначальные данные, которые сейчас подвязались на крыши домов. Логирование позволит определить какая площадка изменилась, и по статистике увидеть что этому предшествовало - корректировка существующей площадки, или ввод новой. В зависимости от этого анализировать логику - что вызывалось, почему работа с другой площадкой задела эту - может они приграничные по расположению в списках. Может работает какой-то счетчик и вместо корректного позиционирования на элемент списка делается -1, ли +1 смещение.

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

Задача сейчас не в том чтобы воспроизвести ошибку, а в том, чтобы локализовать причину подобного проявления. Есть данные, есть процессы. И как увидеть какие действия проводятся с базой преднамеренно, и что меняется непреднамеренно - я так понимаю, что при настоящей организации работающей модели этого не сделаешь. Может сейчас будет введена площадка №4657, а зацепится #1058. Потому что она попадет под фильтр измненений, или потому что она на нее укажет индекс, или хз чего.
В подобных ситуация сперва проводится исследование, а потом уже по результату того исследования делается багфикс.

Это еще раз говорит о том, что нужен некий механизм, позволяющий отмониторить и просигнализировать, что происходит попытка несанкционированного изменения данных, т.е данные меняются, а должны ли они меняться или нет - это уже вопрос второй.
Другими словами, если идет правка #6512, то нужно чтобы как-то система отреагировала, если будет изменены данные и в #1321. Как-то так. Я назвал это логированием. По дате изменений конкретной локации можно было бы определить какое значение было до этого (затерлось), а какой момент (те изменения над какой площадкой проводились в это время еще) - это поможет локализовать причину.
Повторюсь - то что какой-то косяк прошел по базе, это вроде бы как очевидно.



предлагаю логировать. на каждый ID площадки организовать трекинг изменений - статистику изменений (число, время), значение (что было на что меняется), статус строки (новая, апдейт, удаление). Как-то так.
При мониторинге проблемной ситуации, или неясности - делается запрос на таблицу лога. И по хронологии видим последовательность что на что менялось, по каким площадкам, а потом уже начинаем курить исходники - почему такое произошло.


Ой, я не докапывался до этого момента. Полагаю что да.
Могу сказать, что по сути, адрес не имеет никакого значения. Я вообще заморачивался лишь с ЖПС данными. По ЖПС данным гугл сервис выдает адрес для описания, но отправной точкой является именно локация, а не номер дома, который подтягивается по этой локации.

Фикса небыло. А что было ? System. Как он работает. В какой момент. Он сидит сервисом ? может ли он изменять разделяемые переменные (разделяемые - это в смысле глобальные, на уровне приложения).

Может проблема на не уровне приложения, а не уровне сервера (сайта) - может сервис, может процесс по расписанию (или запускается руками) ? Ведь что-то в какой-то момент "пилит" данные! Может динамики изменений сейчас нет (мои площадки августовсвие - не подпорченные), может что-то каждый день портится - рандомно пилится .. исследовать и мониторить нужно.


Посмотри на скриншот. Там какой-то колледж. И адрес площадки в маркере отображен. Я думаю, что ты найдешь ее. И сможешь сопоставить кто их заводил, с каким интервалом. Может System тут не при чем - может он сам жертва того, что локацию этой площадки запилил злобный фоновый процесс...

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

Хм, я могу предположить, что было бы весьма разумно организовать некий коммуникационный протокол между клиентом и сервером. Чтобы отправляю площадку на регистрацию (или корректировку), сервер не просто принимал данные, а отдавал информацию на клиента - например ID принятой площадки. М чтобы клиент после регистрации площадки мог сравнить данные с сервера со своими, которые он до этого отправил на регистрацию. По результату такого сравнения - будет видно, не закосячил ли сервер, адекватные ли данные сели в базу, или со смешением "на крышу дома".
Разумно рассмотреть было бы это на уровне MVP.
И далее, на этом же уровне было бы практично при синхронизации кеша приложения и сервера - не тянуть измененные данные, не переинициализировать кешь, а мониторить - сколько площадок новых, сколько измененных. И делать синхронизацию кеша - по лист списку (либо по кнопке "синхронизировать все").
Этот момент бы мог визуализировать состояние базы сервера - можно было бы мониторить какие площадки изменились, а потом уже пытаться анализировать почему они изменились..
В любом случае, с подходом MVP было бы проще все это замутить