sazhyk

Работаю на удаленке - официально.

Все просто.

1) присылают тебе по электронной почте документы - распечатываешь, подписываешь, отправляешь (в 2 экз).
2) Работодатель подписывает, ставит печать, отсылает тебе.
3) По мере необходимости связываешься с бухгалтерией и делаешь нужные тебе справки итд.

Я будучи во Владивостоке, работаю официально в Москве, даже ипотеку себе оформить смог. Работодатель прислал все по почте (все справки).

Поставьте уже squid который написан, оттестирован и прекрасно под windows работает.

Знание nix-подобных систем не только актуально, но очень востребовано и перспективно. Притом востребованность знаний операционных систем семейства linux огромна, так как куча оборудования, гаджетов, девайсов работает под их управлением: мобильные устройства, телефоны, промышленные компьютеры, различные информационные системы военного назначения, космические и другие отрасли, где очень важна безопасность и цена ошибки просто огромна. А как известно именно linuxы зарекомендовали себя в этих отраслях и сферах. А следовательно нужны люди, специалисты, профессионалы, которые способны эти системы администрировать, программировать, настраивать, использовать в разработке, использовать в работе, адаптировать под те или иные условия.
На счет того куда вам двигаться, тут все зависит от ваших интересов и увлечений. В любом случае, если вы станете хорошим профессионалом в своей сфере, не важно в какой, то будете хорошо вознаграждены. Будь то это разработка под мобильные устройства, администрирование серверов, защита информации в сетях, разработка комплексов важных для безопасности и прочее и прочее. Чем глубже вы разбираетесь в тонкостях и внутренностях операционных систем, тем круче вы будете по сравнению с другими специалистами.
Для более глубокого понимания unix могу порекомендовать книгу "Вахалия. UNIX изнутри" - написано просто, является классикой computer science. Ну и вообще не забывайте про общие знания и концепции теории операционных систем как таковых, сетевого взаимодействия, основ программирования и прочего. Ведь в мире IT-индустрии все технологии очень взаимосвязаны и из одного вытекает другое, все переплетено и это все развивается ежесекундно.

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

Придумайте себе сеть организации. С доменами Active Directory, с внутренней почтой (сначала, допустим, на linux/FreeBSD/postfix/dovecot, а потом -- на Exchange, или наоборот), с внутренними DNS и DHCP-серверами.

С файловыми серверами, доступ к которым на уровне доменных учётных записей и групп распределяется. И запилите эту сеть на виртуальных машинах. Несколько виртуальных серверов Windows/Unix, парочку клиентских станций с виндой/линуксом.

Поднимите свой веб-сервер, нарисуйте на нём простенький веб-сайт на базе какой-нибудь популярной CMS типа Joomla, Wordpress, чо-там-ещё-нынче-модно.

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

А потом сделайте так, чтобы VPN-канал между филиалами был зарезервирован через двух разных провайдеров, да причём переключения производились автоматически и абсолютно прозрачно для клиентов. В этом вам поможет динамическая маршрутизация и протоколы OSPF или BGP.

Факультативно -- можете поднять в удалённом филиале так называемый RoDC -- read-only domain controller :-)

Вот когда всё это запилите, то приходите за новым заданием.

А если же не собираетесь валить из города, или нет никакой вообще возможности устроиться в контору с юниксами и нано-технологиями, то лучше переориентироваться на программерство. Программерам найти удалённую работу значительно проще, чем админам.

Например, 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 огромна, но во многих местах реализована не шибко юзерфрендли.