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

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

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

Это классический кейс для 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 часто это из коробки умеют.

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

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

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

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

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

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

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

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

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

Стоит содержания команды разработчиков более года. Примерно как квартира.

Вопрос космического масштаба. Полагаю, что не существует единого понятия hi-end класса. Это как в ресторане попросить "принесите самое вкусное блюдо". Стоимость проекта? Объем кода? Нагрузка? Изящество кода? С какой командой это делать? Лично мое понимание профессионализма и высокого класса - это когда клиент доволен и поставленные задачи решены, несмотря на неожиданные препятствия и противоречия.

Нюансы реализации, естественно, совершенствуются и удачные ходы приходится собирать по крупицам.

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

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

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

Для новичков статей и учебников миллион. Чем дальше в лес, тем меньше информации в обучающем формате и вообще информации. В предельном случае максимального углубления в технологии, одиночество, т.к. не будет людей с кем посоветоваться, потому что они еще уроки для начинающих не освоили.

В качестве практических действий, чтобы ответ не был слишком обобщенным, предлагаю подписаться на Youtube-каналы Академии Яндекса - там попадаются интересные фишечки, до которых самостоятельно можно долго доходить.

www.youtube.com/channel/UCTUyoZMfksbNIHfWJjwr5aQ

Англоязычные рассылки:

css-weekly.com

javascriptweekly.com

nodeweekly.com

Естественно, любимый БЭМ :)

getbem.com

ru.bem.info

Успехов в совершенствовании.

Делается стандартными возможностями Chrome Dev Tools (проще, чем в предыдущих ответах). Во вкладке инспектора Sources измененные файлы показаны со звездочкой. В контекстном меню выбрать Save и первый раз указать локальный файл. Потом спрашивать не будет. Удобная последовательность: подвигал блок, ткнул по ссылке на файл, Cmd-S. Подробно с картинками: devcoma.blogspot.com.br/2012/07/change-css-and-sav... UPD: сейчас оно само сохраняется после изменения свойств блока в инспекторе, если ранее была привязка к файлу.

Метатег keywords полезен для внутреннего применения, если вы используете собственный поиск по сайту.