Евгений

Wagtail

В каждом фреймворке своя реализация. Кто-то предпочитает вручную реализовывать данную функциональность. Я сталкивался и с тем, и с другим.

У меня на работе сейчас в Django проекте используется самописная система, в которой автоматически генерируются поля вида title_en, title_zh_cn для каждого из определенных языков в settings.LANGUAGES. В других проектах пользовался готовой библиотекой для Django: django-modeltranslation.

В самой продвинутой CMS для Django используется свой подход: Creating a multilingual site.

Как правило, в серьезных библиотеках для реализации REST API уже есть либо встроенная поддержка throttling, либо при помощи сторонних приложений. Например, в Django Rest Framework: Throttling

Python сейчас востребован, хорошо оплачивается, плюс он интересен. Если говорить о веб-разработке, то гораздо проще и интереснее заниматься этим на Python.

Ну а что касается перспектив, то это туманный вопрос. Если вам хочется узнать то, что происходит под капотом, то это все-таки даже не C# надо изучать, а C и C++. Ну и одно другому не противоречит. Процесс узнавания того, что под капотом не требует извращаться и писать для веб на C/C++. Можно заниматься веб-разработкой на Python параллельно изучая C по исходникам ядра или nginx.

Именно, вы все очень туманно понимаете. Названия тегов - h1, h2, и т.д. - это семантика. Цвет и размер шрифта - это оформление. Любым тегам могут средствами CSS присвоить любой шрифт и любой цвет. h2 в корзине может иметь другой размер и другой цвет, нежели h2 в основном теле страницы.

Вам надо с нуля почитать хорошее руководство по HTML и CSS.

Это философский вопрос. Если человек адекватный, пусть и не технарь, можно попытаться спокойно объяснить. Если человек неадекватный, то никакие объяснения не помогут, не надо даже пытаться, все равно будут сплошные проблемы. Он пойдет на какую-нибудь фриланс-биржу, там найдет «разработчика бэкенда с огромным опытом», который пообещает сделать ему бэкенд за 3 дня и 1500 рублей. Будет делать три месяца, в итоге выкатит неработающий ужасный код, потом другой разработчик будет 6 месяцев пытаться привести это в работающее состояние, тем временем заказчик, возможно, осознает свою ошибку и станет чуточку умнее. Или не станет.

Я в дорогих коммерческих сайтах не вижу ни того, ни другого.

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

Ровно месяц назад я отказался от дорабатывания сайта, который писал человек, пишущий в своем профиле на Upwork, что он:
1) Закончил МГУ
2) Закончил сложные нетривиальные курсы на Coursera
3) Имеет 5 лет опыта разработки веб-сайтов
4) и другие регалии

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

Я бы посоветовал еще переключиться с PHP. PHP был изначально спроектирован (если данное слово вообще подходит к PHP) для новичков. Примитивный язык для создания домашних страниц.

Большой толчок к понимаю дало бы изучение других технологий и языков. Все-таки, несмотря на то, что развитие PHP происходит, оно происходит в достаточно замкнутой и ограниченной тусовке. Как-то вот на Хабрахабре была статья: что лучше, ORM или прямые запросы к базе. Я почитал из любопытства... Ну да, с такими ORM действительно легче и удобнее писать сырые SQL запросы.

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

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

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

Мне кажется, предугадать, что будет через 10 лет, очень сложно. Все равно придется не раз переучиваться. Единственное, что стоит исключить из рассмотрения — PHP. Он вряд ли что-то даст в плане развития мышления или карьеры, разве что плохие привычки.

То, что вы написали как преимущества Javascript - спорно. Зато у Javascript есть пара огромных недостатков
1) это язык-костыль, сляпанный кое-как (да в курсе, что ситуация исправляется, но не радикально)
2) это язык с очень низким уровнем входа, соответственно, часто придется сталкиваться с плохим кодом, потому что большинство разработки на Javascript идет методом копипастинга кусков из Интернета

Взгляните, например, на вопросы по Javascript здесь. Очень много вопросов демонстрирует что задающие их люди не изучили даже основы языка, не понимают, где у них Javascript, где jQuery, где HTML и где DOM.

Но разработчик на JS от голода точно не умрет, впрочем, так же, как и разработчик на Python. Субъективно мне кажется, что почти любой язык приятнее Javascript для изучения и разработки. Не люблю я его с давних пор.

Можно использовать свой self-hosted сервер комментариев, например, isso: https://posativ.org/isso/

У нас довольно примитивная система. Проект на Django, хранится в mercurial, есть две ветки: staging и production. Все изменения (за исключением совсем срочных багфиксов) по умолчанию идут в staging. При релизе изменения из staging пушатся в production, на сервере самописный shell скрипт выполняет pull и перезапускает сервер. Скрипт запускается вручную.

Еще используется buildout, который управляет всеми зависимостями проекта, два конфигурационных файла. В окружении разработчиков используется конфигурация, в которую включены django-debug-toolbar, в которой определены безопасные умолчания (например, использование песочницы PayPal вместо настоящего аккаунта PayPal, и т.п.). На сервере используется конфигурация без средств отладки.

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