Антон Иванов

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

То есть у тебя данные сообщения от клиента. Ты их разбиваешь на тренировочные и тестовые, проводишь необходимые трансформации. И отдаешь классификатору. У многих классификаторов, даже метод есть predict_proba (предсказать вероятности), именно, для таких кейсов.

Ключевое, здесь это классификация, а какого то самого лучшего алгоритма или нейронной сити нет, надо моделировать и смотреть.

через сам php никак, только с помощью ffmpeg

Есть 3 варианта, позволяющие двухсторонний обмен сервер-клиент:
- WebSockets
- Server-Sent Events
- Long Polling

Есть библиотеки которые являются обёрткой над этими транспортами и выбирают лучший исходя их возможностей клиента. Для .Net это SignalR, для Java и Kotlin не знаю, но можете поискать по ключевым словам.

И еще, до кучи, ответ со StackOverflow https://stackoverflow.com/questions/11077857/what-...

location ~* \.(jpe?g|gif|png|svg)$ {
    if ($arg_moderation = "on") { 
        rewrite ^ /upload/system/no-avatar.jpg break;
    }
}

Если либа лежит у вас, то можно обернуть код во что-то типа:

{
  const window = {
    get location(){
      debugger;
    }
  }
  // код
}

Фигня такой подход - появится еще одна мадам, придется переделывать структуру таблицы?
Делаешь 2 таблицы - users и messages
users
id, name

messages
userid, msgid, message

и работаешь с ними через джойны.

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

По сути это два абсолютно разных SPA

Немного банальностей:
1. Бизнес не даст ресурсов на переписывание проекта с 0: время и большие риски
2. Бизнесу как правило все-равно какое говно там крутится, лишь бы деньги приносило.
3. Если более-менее адекватное руководство - нужно донести идею постепенного рефакторинга кода по мере необходимости в процессе фикса багов и разработки новых фич и тем самым аргументировать что на разработку новых фич/фикс багов нужно больше времени.

Как я бы делал:
1. Тесты на существующие функции (если возможно, видел методы в контроллерах с мешаниной вызовов методов моделей, созданием DTO и сохранением их через репозиторий, прямых http-запросов и запросов в бд на 1000+ строк, покрыть такое тестами - невозможно)
2. Составить план рефакторинга, где отметить что и где надо сделать, коротко, в основном для команды разработчиков.
3. Постепенно рефакторить старый код по мере взаимодействия с ним.
4. Новый код - писать сразу правильно, для взаимодействия со старым кодом где нет возможности/времени его переделать - делать какие-то адаптеры, что бы не распространять токсичный код.
5. Как оперативная мера защиты от SQL иньекций можно поставить что-то вроде этого https://github.com/nbs-system/naxsi
6. Мониторинг кода, который не используется - pinba.org , по мере обнаружения такого кода - удалять безвозвратно (в крайнем случае есть VCS, я надеюсь). Начать с более высокоуровнего кода - контроллеры, напримерю. Плюс IDE в этом могут помочь и grep.
7. Как вариант - новые фичи можно пилить в отдельном проекте (v2), крутить оба и постепенно переходить на новый, со временем старый (v1) выкинуть (и начать делать новый - v3 :-) )

Нужно использовать witness server

Попробуйте с MutationObserver, примерно так:

var observer = new MutationObserver( function(mutations) {
    mutations.forEach(function(mutationRecord) {
        console.log('стиль изменён');
    });    
});

var target = document.getElementById('flash-messages');
observer.observe(target, { attributes : true, attributeFilter : ['style'] });

Очень крутой вопрос, прямо хочется бегать по кругу, размахивать руками и кричать.
Ну... как-бы... ВСЕХ дыр стоит остерегаться!
И того, что вам вместо аватарки шеллскрипт зальют, и того, что вместо поискового запроса будет sql инъекция, и того, что в вашу форму с оплатой заказа прилетит "левый" запрос сформированный при помощи XSS. И это не полный список возможных неприятностей, если что. А полный список будет сильно зависеть от того, какие вообще злоумышленник сможет делать запросы и есть ли в обработчиках этих запросов хоть какие-то проверки.

Общие правила примерно такие:
1. Проверяйте и/или фильтруйте все данные, которые приходят со стороны пользователя
1a. Убедитесь, что эти запросы не ddos, не брутфорс и не xss.
2. Наймите хорошего сисадмина, который будет следить за безопасностью и обновлениями OS и компонентов вебсерера.

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

Вы забыли s в resources
resources :din_pages

У вас `authorized` это лямбда. Тоесть это функция, которая будет выполняться каждый раз, когда запрос придёт в рельсы.
А вот это `!authorized`, это отрицание от лямбды, оно всегда будет ложью. Это не отрицание результата выполнения лямбды, это отрицание для самого объекта лямбды.

2.3.1 :001 > ->() { false }
 => #<Proc:0x00000001f744e0@(irb):1 (lambda)>
2.3.1 :002 > !(->() { false })
 => false

Никакой разницы. В класс выносят, если слишком много логики в условии. У вас одна только строчка, поэтому достаточно лямбды. Это просто вопрос читаемости кода.
Но я бы вообще никогда не выносил в класс, так как придется каждый раз искать этот класс, лезть в него и разбираться в нем. Лучше, когда всё в одном месте.
Ну и этот ответ на SO морально устарел: сейчас ложить что-то в lib очень плохо. Но где тогда хранить эти классы, я не знаю — обычно это решается в рамках конкретного проекта, каждый делает, как ему удобно.
В дополнение, статья о том, как разбивать routes.rb на несколько модулей: blog.arkency.com/2015/02/how-to-split-routes-dot-r...