Не видя проект сложно понять о чём речь, но могу подсказать из чего исходить. Не помню, как это называется в терминологии smell code - когда класс выполняет работу другого класса и обращается к его методам. В любом случае отталкиваетесь от обратного: конкретные функции должны быть у того модуля, который непосредственно работает с объектом.
Не знаю, мне кажется вещь хоть и не так много кому, но нужная. На самом деле дофига людей в бизнесе ждут такого рода нехитрые, казалось бы, специализированные микросервисы. Просто кто-то не понимает, что есть сама возможность упростить жизнь, кто-то думает что нерентабельно, кому-то [пока] вообще пофиг.
Тут главная трудность - найти "нуждающегося". Увидеть, что у (для) кого-то существует серьёзная задача, которую ты легко решишь и предложить решение. По результату мне особенно нравится блеск в глазах заказчика: "А чё, так можно было??!". И да, за это обычно нормально платят. Ну, типа, как "создание сайта" лет 15 назад тоже было магией. А для кого-то и по сей день))
Хотя, наверное, нет: есть даже csp-политики, запрещающие inline-js. Т.е. скрипт в современных парадигмах должен выполняться "из файла", а html оставаться html"ом. И из этого наверное надо исходить.
Согласен. Ну вобщем-то я о том же говорил. Ид, классы или другие атрибуты - не суть, главное, что есть идентификатор, на который надо навешивать событие. Моё мнение, в рамках обсуждаемого вопроса, навешивание событий on* непосредственно в коде - не лучшая стратегия. Но не уверен: возможно, это просто дело привычки и пагубного влияния фрэймворков типа jQuery, а использовать надо именно предусмотрнные html'ом обработчики.
Не. Лучше через data-, кмк. Вернее так: событие должен ловить некий css-селектор (в т.ч. через data-*). А что делать с этим элементом, сотдержится в дата-атрибутах. Я так делаю. Правда я в js далеко не гуру и, возможно, вообще правильнее dom- элементы заворачивать в какую-то js-обёртку.
Это даже не бумага.
Я вижу это так: на сервере должна быть локальная база (таблица) с объявлениями. Её наполняет CMS в момент создания новости: подставляет текст, ключевые слова и другие нужные параметры. Указыватся сколько времени объявление должно куртиться. Параллельно отправляет по API запрос на создание объявления. Потом по крону на основе данной таблицы через апи делаются остановки-запуски и другие действия с объявлениям. Дальше уже конкретика. Может для каких-то cms даже существуют готовые решения в виде плагинов.
Киви и без того весь в косяках.
Интересный был бы вариант платежной системы, работающей по принципу обменника. Без трансграничных переводов как таковых, а типа с запасом "налички" в одну сторону и в другую. Человек, желающий принимать деньги, регистрируется и получает идентификатор. Там привязка к местным банкам, платежкам, крипте и т.д. Человек, которому надо что-то оплатить, просто платит на идентификатор получателя доступным ему способом, пополняя "резерв" денег в своей стране. А получателю зачисляются средства из "запасов" внутри его страны. При дисбалансе средств внутри платёжки часть денег каким-то образом перемещается из одной страны в другую. Домен ruamoney.com свободен кстати.
