sazhyk

Например, listen 127.0.0.1:80
А вообще, в документации много способов разграничения доступа описано.

О Боже, где вы этого понабрались? Дело в том, что завист от самого провайдера от части + вы забывайте что есть другие варианты!..
В вашем случае - кроее всего это результат технологии клиджекинга - почитайте: https://habrahabr.ru/post/123923/

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

Когда я захожу на определенный сайт, провайдер видит URL?
- Да.

Поясните, как провайдер видит урл? Едиснтвенный известный мне метод(если не подключатьма ремот-админами) - это МИТМ-атака(а другими словами прослушка трафика/пакетов). Как писал этот же комментатор, это очень накладно и требует ресурсы, поэтому для 10 000-100 000 клиентов это реализовать может только ГУГЛ и еже с ними. Поясню: представьте себе установить анализатор трафика, где посередине между Вами и сайтоми всрывать каждый пакет(причём - типо незаметно). Представили? Так вот, для это нужен копм, программа(уая-шарк например) и потом блуждать в пучине всех полученных данных. Такое делается когда заводят дело, а так... Увы сомневаюсь
Пожтому я и галоголю, что зависит от провайдера.
Когда-то на заре своей деятельности, наша компания лимитировала трафик. Тогда у нас были установлены так называемые шейпера, которфе в зависимости от абоннентксого пакета резали скорость. проверялся исходящий айпи-адрес пакета, сравнивался с абон платой по биллингу клиента, и технически отправлялся дальше лимитированной скоростью. Есть известные программы на лингксе которые этим занимаются, и всем известно что даже в этом случае ни о какой слежке речь не идёт. Нам даже тех ресурсво, тех серверов не хватало, о каком ещё слежение могла идти речь? Наоборот, наша миссия всегда была - нефильтрованный интернет в массы!

ВУА-лЯ

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

Короче общайтесь с сапортом на предмет получения настроек, и пропишите их самостоятельно.

Обычно разделяю предметные области проекта на отдельные приложения. Если какая-то область слишком обширна, то в папке приложения создаю отдельные приложения для подобластей. Для каждого приложения - своя папка templates: это позволяет при большом количестве приложений не путаться в разросшейся иерархии директорий. Кроме того, отправляю всю обособленную статику в директории static каждого приложения: иногда для работы интерфейса пишу JavaScript приложения на Marionette - всегда знаю, где искать нужную кучу скриптов.
Для примера: пишем проект для дилерской сети по распространению и продаже автомобилей. Получается так:

./project_name/
./project_name/settings.py
./project_name/urls.py
./project_name/static/
./project_name/static/css/...
./project_name/static/js/...
./project_name/static/imgs/...
./dealer/
./dealer/admin.py
./dealer/models.py
./dealer/views.py
./dealer/urls.py
./dealer/templates/
./dealer/templates/dealer/
./dealer/templates/dealer/list.html
./vehicles/
./vehicles/admin.py
./vehicles/models.py
./vehicles/logistics/
./vehicles/logistics/models.py
./vehicles/logistics/admin.py
./vehicles/logistics/views.py
./vehicles/logistics/urls.py
./vehicles/logistics/templates/
./vehicles/logistics/templates/logistics/tracking.html
./vehicles/logistics/static/
./vehicles/logistics/static/js/app/tracking/
./vehicles/logistics/static/js/app/tracking/main.js
./vehicles/logistics/static/js/app/tracking/app.js
./vehicles/logistics/static/js/app/tracking/...
./vehicles/sales/
./vehicles/sales/models.py
./vehicles/sales/admin.py
./vehicles/sales/views.py
./vehicles/sales/urls.py
./vehicles/sales/templates/
./vehicles/sales/templates/sales/invoices.html
./vehicles/sales/static/
./vehicles/sales/static/js/app/invoices/
./vehicles/sales/static/js/app/invoices/main.js
./vehicles/sales/static/js/app/invoices/app.js
./vehicles/sales/static/js/app/invoices/...
./static/
./media/
./templates/
./templates/base.html
./templates/...

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

Блин, да это же джанго, он сам явно подталкивает к одной структуре приложения.
Одно приложение на 1 логическую и независимую часть сайта. Например, интернет-магазин должен включать в себя каталог продукции и функционал для заявок. Потому что они взаимосвязаны. А вот новостную часть на этом сайте надо выносить в отдельное приложение, так как новости обычно почти не связаны с заказами и товарами как таковыми.
Ещё в каждом приложении можно создавать папку static, куда класть все статические файлы. Но так обычно поступают разрабы "плагинов" для джанги. В рамках сайта можно коласть в 1 папку static в корне проекта, но разделяя js и css файлы (чтобы вёрстка не было в 1-м суперогромном css файле, в котором хрен чо найдёшь). Потом сборщики должны всё собирать и минимизировать.
Шаблоны раскидывай по папкам, соблюдая иерархию. Т.е. если есть приложение shop, то в корневой папке templates создай layout.html, а все шаблоны магазина клади внутрь templates/shop, наследуя. Также можно хранить шаблоны внутри приложения, но опять же, это обычно используют разрабы "плагинов", хотя сам принцип хорош.

а может он наоборот проработал плохо, и из за неэффективности своей работы принес только убытки компании.

Не не не не... Во всем виноваты менеджеры.

У меня есть действующая доменная почта для гугла и яндекса. Если кратко:
Google Apps — Яндекс
Платно — бесплатно
Фильтры плохи — хорошие
Скорость загрузки низкая — высокая
Возможность пересылать несколько писем отсутсвует — присутсвует
Удобство гугл аккаунта как единственного аккаунта — нет такой опции
Интерграция с гугл диском и гугл докуементами есть — жалкое подобие в виде яндекс диска
Синхоронизация контактов с телефоном отличная — через жопу
Интерфейс ногу сломаешь — отличный
Встроенный календарь отличный — говно
Возможность встраивать приложение для почты (например плагины для систем управления проектами) прямо в веб-морду gmail — нет таких опций (насколько мне известно).
Возможность отправлять письма с задержкой с помощью сторонних платных приложений — бесплатная встроенная возможность.
Возможность создавать любое количество псевдонимов для почты — можно использовать в качестве псевдонима формат типа <номертелефона>yandex.ru
Приятный интерфейс написания нескольких писем без закрытия основного веб-интерфейса — нет такого интерфейса.
Нет уведомления получателя по СМС — есть такое уведомление.

Функциональность Gmail огромна, но во многих местах реализована не шибко юзерфрендли.