Сергей Рогожкин

Мой повседневный вариант, который охватывает только часть сценариев: в личном кабинете есть кнопка "подключить бота", которая генерирует код подключения и выводит инструкцию "активируйте бота и введите код".

Можно перейти по ссылке на бота или найти вручную на телефоне по имени. Ввод кода в самом боте может быть отдельной командой или даже единственной командой для ботов-уведомителей. Пока не подключили, в кабинете висит состояние "выписан код 123-456-789, ждем подтверждения в боте".

Websocket использую как индикатор, что "на сервере поменялось", пересылая минимум информации. С клиента наверх через ws ничего не отправляю. Клиент понимает, что надо дернуть API, имеет при себе сессионные ключи и шлет полноценный запрос. Иначе путаница с данными. У некоторых клиентов ws не работает и надо заменить на другой метод. Основная логика "дернуть API и поменять состояние клиента" остается неизменной.

Подход имеет право на жизнь в личных кабинетах, списках заказов и т.п. не слишком быстро обновляемых данных. WS соединение висит, почти не потребляя трафика и отправляет числа для индикаторов кол-ва заказов.

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

Теперь представьте магию. Вы создаете заказ, который приводит к множеству параллельных, последовательных и очень сложно-разветвленных задач (резервирование на складе, отправка уведомлений, списание средств ит.п), в глубине которых что-то обламывается. Поскольку сервисы изолированы и почти ничего не знают друг о друге, надо всех причастных заставить вернуть "как было" через общий канал. Обломавшийся микросервис, зная ключ операции, кидает в шину сообщение "операция (id) не удалась, без подробностей". Далее все микросервисы: 1) откатывают операцию по id, если уже сделали 2) перестают реагировать на такой id, если еще не дошли запросы.
Итого: система вернулась в первоначальное состояние в целостном виде.

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

Это классический кейс для GeoDNS. Сделать два(или больше) сервера на разных континентах, синхронизировать как-то между собой и в зависимости от ip запроса по геобазе резолвить ip ближайшего на один и тот же домен. Естественно, для домена должен быть прописан свой специально настроенный dns сервер.
Например:
https://kb.isc.org/docs/aa-01149
komivlad.net/blog/bind-named-geoip-otdaem-raznye-i...
и т.д.
Теоретически должны быть готовые сервисы GeoDNS, но как-то не попадалось.

PS/ просто прописать несколько ip на один домен не прокатит, т.к. они равномерно распределятся и закешируются, кому как повезет.

Для Go есть неплохая библиотека для подсчета рейтов: https://github.com/paulbellamy/ratecounter Пользователя хорошо бы ассоциировать с ключом, чтобы не заморачиваться с источниками трафика, а ключу сопоставить набор обновляемых счетчиков. Как хранить ключи и счетчики - дело вкуса. Если порог превышен, получите-распишитесь HTTP 429 Too Many Requests. Это если самому. Вообще библиотеки для REST часто это из коробки умеют.

Простыми словами в чем проблема Графа Куэль: https://tonsky.livejournal.com/309037.html

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

Считать, что "все хотят повышения продаж" или "повышения конверсии" - очень смелое предположение. Моя практика показывает, что это не так. Может получиться, что основная проблема "не те покупатели" или "аудитория не понимает смысл продукта", хотят номинально сайт, а нужно совсем другим заниматься. Теоретически сайт можно сократить до одной страницы текста у которой задача донести мысль до пользователя. Какую мысль - очень сильно зависит от организации. Если мысли нет, ну тогда успехов в дизайне и приемке работы ;)

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

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

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

Никак, даже через iptables. Докер только сам может ограничить доступ. Используйте директиву --network=host при старте контейнера, чтобы он пробрасывал порты не в дефолтную сетку bridge, а только для хоста, извне недоступную.

Если сократить подробности, репликация идет в один поток, что и является узким местом. Даже если слейв в 10 раз быстрее, это все равно упрется в 1 поток на мастере.

Решить вопрос, полагаю, можно пересмотром архитектуры приложения, не базы. Может быть придумать схему, когда пишущие клиенты будут сразу в несколько хранилищ писать параллельно.

Тоже поделюсь картинкой. Почти три года аппарату. В основном на зарядке, изредка на часок автономно, полный разряд примерно раз в полтора-два месяца. Постоянно гонять заряд-разряд ради показателей нет смысла. Говорят важнее не перегревать и не держать батарею полностью разряженной. Идеал - вентилируемая подставка.

Включите дизайн копируемого сайта в передаваемые заказчиком информационные материалы и добавьте в договор два пункта об ответственности:

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

- В случае предъявления Исполнителю претензий или исков по поводу нарушения им авторских и/или смежных прав третьих лиц в связи с использованием Информационных материалов, предоставленных Заказчиком, во исполнение условий настоящего Договора, Заказчик обязуется урегулировать такие претензии или предпринять иные необходимые действия, исключающие возникновение расходов и убытков у Исполнителя. А в случае возникновения расходов и убытков у Исполнителя, возместить их в полном объеме.

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

Любой проект можно сделать лучше. Гораздо интереснее творчески переработать и это уже не будет плагиатом, но отдельной работой проектировщика.

Вот обзор методов как асинхронно получать сообщения с сервера (вышеупомянутый комет - один из вариантов): stackoverflow.com/questions/11077857/what-are-long...

Раньше делал врукопашную через веб-сокеты. Сейчас можно интеллигентнее.

Вот хорошая обертка вокруг вебсокетов, реализующая паттерн подписки на события: wamp-proto.org Перед отправкой тяжелого аякс запроса, клиент устанавливает вебсокет-соединение и подписывается на событие "обновление %". Серверная часть внутри цикла отсылает сообщения подписчикам.

Нет никаких сферических "профи" и "не профи". Каждый разработчик пытается выявить и решить противоречия, пробует разные техники. С тестами (даже написанными через 2 недели после) вы будете чувствовать себя гораздо комфортнее психологически. Просто пишите тесты хоть тушкой, хоть чучелом. Но это тактический прием.

Более важно, полагаю, предусмотреть и поддержать максимальное количество сценариев(юзкейсов) использования продукта, причем наиболее простыми средствами. Главный показатель качества: попали в паттерн привычного поведения пользователя и сделали ему лучше. Количество багов нельзя рассматривать в отрыве от сути продукта.

Убрать редкие и сложные фичи, которые нужны 10% пользователей может дать для качества больше, чем все тесты.

$(selector).is('*') вернет true, если есть элемент. Выход из "скрипта" зависит от контекста, как правило достаточно просто сделать return из колбэка при несоответствии условий.

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

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

Правильно было бы купить эскиз за фиксированные деньги, в районе 5-10 тысяч за вариант. Если понравилось, заказать еще. Прямо так и сформулировать: "есть 10 тысяч, сделайте за эти деньги насколько посчитаете уместным проработанное видение моего задания; если мне понравится, работаем дальше". Называется оплачиваемый тендер.

Youtube не умеет бороться со спамом. Это их серьезная проблема, которую не скрывают. Левые аккаунты без видео, с которых идут приветы, могут даже блокировать, но регистрируют их тоннами. Так что только фильтры в почте.