German Jet

Мне кажется, что веб-программист (как и любой другой) должен иметь в запасе парочку других ЯП.
Например, PHP'ку неплохо бы уметь писать hello world на C++ / Java / .NET.
За C++ автоматом потянутся знания о компиляции, системах сборки и т.д.
За Java потянутся знания о серверах приложений (tomcat, wildfly).
Эти знания фундаментальные. Написав свой велосипед на плюсах (например веб-сервер для показа баннеров), вы будете лучше понимать PHP и средства оптимизации / архитектуры и т.д.
Java вас научит ООП, аннотациям и прочему "сахару".

От этих знаний будет легко перейти и к администрированию Linux'а и к пониманию внутренностей Apache Http (например, работа с неблокирующими сокетами).

Ну а вообще, если говорить о Apache Http, то у PHP есть функционал, предоставляемый HTTP сервером - это точно нужно знать.

Гуглить

https://docs.djangoproject.com/en/1.8/howto/deployment/

А чего вы хотите?

Вопрос настолько обширный, что врядли кто-то вам сможет посоветовать актуальную литературу, т.к. нужны примеры.

Большинство хороших архитектурных решений находится в постоянной разработке и люди, которые пишут книги, часто отстают лет на 5 от прогресса. А те, кто не отстает — находятся в творчесском процессе и им некогда писать книги.

По теме могу посоветовать смотреть в сторону ruby/nodejs/go фреймворков для различных веб-приложений и сервисов, каждый фреймворк затачивается под определенную задачу и, если есть желание эффективно работать в этой сфере, вам так или иначе придется это делать — без чтения чужого кода и участия в разработке этих самых фреймворков сейчас никуда, и это полностью заменяет литературу по теме.

Как пример, могу посоветовать сравнить www.sinatrarb.com (ruby), expressjs.com (nodejs) и martini.codegangsta.io (golang). Все они используют схему — создаем приложение, у приложения регистриуем обработчики для get/post/других запросов, в обработчиках получаем объекты request/response, и работаем с ними. Это считается базой для любых веб-сервисов, веб-приложений.

Когда нужны какие-то дополнительные функции — все делается независимо от этих модулей внутри колбеков, которые в них регистрируются и там зоопарк очень большой. Если нужны контроллеры, модели — есть rails, compoundjs, beego. Если нужно сделать REST — обычно, берется синатра + доп. модули, и получается что-то вроде loopback.io

Но, повторюсь, когда это все пишется у тебя на глазах, а цикл создания книги — год-полтора — то за это время технологии уже уходят далеко вперед и хороших книг с такой глубокой проработкой вопроса будет появлятся все меньше.

Я бы сделал так. Переменную endpoint, конечно, можно не инициализировать, а сразу передавать строку в вызов _call_with_endpoint. Но так нагляднее.

class Vehicle(API):
    def _call_with_endpoint(self, lang, fields, account_id, endpoint):
        if type(fields) is list:
          fields = self._format_fields(fields)  
        return self._api_call(endpoint=endpoint,
                              fields=fields,
                              language=lang,
                              account_id=account_id)

    def vehicle_stats(self, lang='ru', fields='', account_id=''):
        endpoint = '/tanks/stats/'
        return self._call_with_endpoint(lang=lang,
                                        field=fields,
                                        account_id=account_id,
                                        endpoint=endpoint)
        

    def vehicle_achievements(self, lang='ru', fields='', account_id=''):
        endpoint = '/tanks/achievements/'
        return self._call_with_endpoint(lang=lang,
                                        field=fields,
                                        account_id=account_id,
                                        endpoint=endpoint)

Есть settings.py и admin_settings.py
Во втором добавлено приложение админки.
Сайт с админкой запускается на отдельном хосте, доступном только внутри корпоративной сети, только определенной группе.
Общедоступный сайт соответсвенно запущен без админки.

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

Как не крутите у Вас буде 1млн итераций, что много. Из более-менее реальных вариантов - вынести этот код из шаблона (генерировать плоский список в контроллере, а затем прокидывать его в шаблон). Т.е. в результате у вас должно быть что-то типа:

{% for el in l %}
<span>{{o1.n}}</span>
{% if el.flag1 %}
...
{% if el.flag2 %}
...
{% endif %}
{% endif %}
{% endfor %}

Хотя шаблоны и компилируются, но в целом выполняются медленнее, чем код. После того, как вы получите метод, генерирующий такой список - кешируйте список (или можно даже закешировать кусок шаблона со списком). Судя по всему это что-то типа хлебных крошек категорий и часто меняться не должен. Так как рендеринг в 3 секунды - ад, то при сбросе кеша этот список надо сразу помещать назад, чтобы не заставлять пользователя ждать. Т.е. должно быть как-то так: сгенерировали новый список, атомарно заменили старый список на новый. Возможно есть еще варианты оптимизации кода (например преобразование списков в словари, исключение повторений в проверках и т.п.)
Также можно извратиться обертками - не делать полный перебор, а сделать метод, который будет применять бинарный поиск к списку, к примеру. И Вы получите не O(N), а O(log2N). Но опять же тут надо смотреть применимость к Вашему коду.

1. Кэшировать
2. Перейти на jinja2

что мешает сделать так:
$url="/success/"; ?

В универе настолько дохрена времени у студентов что можно выучить три языка.

Ходить на оба
Реализовать две проги досрочно, так чтоб

сотрудники компаний

хотели взять тебя на работу, во время учебы

WiFi и GSM это протоколы передачи данных, кнопки на них сделать невозможно.
Вы бредите.

Ради Аллаха, выбросите Вы все эту ерунду, возьмите React для клиента + один из фреймворков для создания серверного API на ноде. Шаблонизировать на сервере это очень специфическая задача, нужная разве что для публикации контента. А приложения лучше писать как SPA (одностраничное приложение, т.е. клиент грузится в браузер и все дальнейшие обмены данными JSON формате через API).

Во-первых, откажитесь от видео-уроков и возьмитесь за учебники. Ни один видео-урок не даст столько знаний и навыков, как хорошая книга. Одно дело - растянутое на полтора часа объяснение того, как написать элементарный "Hello, world!", а другое - хороший учебник, где каждое предложение содержит крупицу новой информации. Плюс видео делает Вас пассивным наблюдателем, а книгу в любой момент можно отложить и попробовать описанное на практике. Плюс, её можно читать на диване ;-) Но это так, к слову.

Если лень учить, значит, не хватает мотивации. Тут два варианта.

Первый уже предлагали здесь: найти интересную задачу и изучать технологии под неё. Например, я хочу написать скрипт, который составит список всех возможных шахматных партий хотя бы на 23 хода, изучаю для этого возможности SQL вообще и PostgreSQL в частности, далее в очереди MongoDB. Хотя мне проще, мне в принципе интересно читать тематические учебники.

Второй вариант - забить. Если вопрос не интересен и к нему не лежит душа, зачем мучить себя? Себя-то ладно, а представьте, сколько мучений испытают те, кто вынужден будет читать Ваш код, написанный без любви?

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

Все очень просто, заведи семью, ипотеку, ребенка, кота.
Лень как рукой снимет.