sazhyk

Например так если использовать common based views:

from django.contrib.auth.decorators import login_required
class LoginRequiredMixin(object):

    @classmethod
    def as_view(cls, **initkwargs):
        view = super(LoginRequiredMixin, cls).as_view(**initkwargs)
        return login_required(view, login_url=reverse_lazy('login'))

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

А вообще кучу возможных вариантов вам уже в той теме насоветовали.

Мне известно четыре основных способа заработка, напрямую связанных со свободными программами:

— Первый, самый прямой, но от того почему-то всем не менее неочевидный — брать и продавать копии свободных программ. Аудитория: любые конечные пользователи. Примеры: Parted Magic, ряд программок для «Андроида», ну например, «Conversations». Высокоморальность: в полном порядке.

— Второй — это уже известная вами продажа поддержки. А фактически иногда и просто своего имени, когда какая-то реальная поддержка начинается с сумм несколько больших, чем базовый контракт. Аудитория: те, для кого ваша программа есть орудие производства, то есть компании и предприниматели. Пример: уже озвученный вами Canonical. Высокоморальность: в полном порядке.

— Третий — это продажа исключений из авторского лева. Аудиторией будут разработчики несвободных программ, а программа ваша должна быть библиотекой под (как нетрудно догадаться) авторским левом, причем чаще сильным. Суть в том, что для добрых людей ваш продукт свободен на условиях, скажем, GNU GPL или GNU AGPL, а проприетарщики пусть платят за возможность использовать его в своих шкурных интересах. Примеры: GhostScript, MySQL. Высокоморльность: прихрамывает маленько.

— Четвертый — это то, о чем помянул тов. CityCat4 — т. н. free crippleware, то есть полноценная ваша программа несвободна и платна, но у нее есть свободный урезанный вариант. Причем урезано может быть как что-то существенное, так и сущая ерунда. Аудитория: кто угодно. Примеры: Odoo, GitLab, ProcessMaker. Высокоморальность: от невысокой до никакой, смотря сколько отрезано.

И разумеется, все вышеперечисленно можно комбинировать: Qt, к примеру, и поддержку (обучение) предоставляет, и исключения из авторского лева (причем слабого!) продает, и совсем ерундовую несвободную часть имеет. А упомянутый вами Red Hat — продает копии и предоставляет поддержку. А иногда и такое бывает: программка для «Андроида» под названием OsmAnd полностью свободна, но поставляется в Гуглоплэе в двух вариантах: полном за копеечку и урезанном бесплатно. Еще раз: обе версии свободны, то есть никакой моральной проблемы здесь нет.

――

P. S. Я перечислил только способы заработка на программах как таковых, полагая, что схемы, где свободные программы участвуют косвенно, и без того очевидны, но в комментариях только о них и говорят, так что надо, наверное, упомянуть, что да, конечно, свободная программа также может быть:
— Частью продаваемой услуги — чаще всего услуги специфического хостинга, как ставимый здесь в пример Openshift или (если ближе к народу) Feedly.
— Частью продаваемого устройства, причем само устройство может быть как свободным, так и нет. Тысячи их.
— И наконец, просто частью приносящего прибыль техпроцесса. То есть компания пишет (заказывает) программу себе для внутреннего использования и могла бы ее вообще не распространять, но, не считая ее своим «ноу-хау», ведет себя благородно и просто свободно делится ею со всеми. Известнейший пример — Reddit (хотя в последнее время они подскурвились).

――

И не могу все-таки не отметить, что unix-way отношение к свободе имеет такое же, как мелкое к горячему.

И да, и нет. Все зависит от цели. Постараюсь объяснить.

Я уже как-то упоминал про тот факт, что люди воспринимают информацию по-разному. Мой приоритет - книги (а не аудио/видео, например). Мой подход к обучению - step-by-step, от простого к сложному, одна технология в фаворе. Но эта последовательность не линейна - на определенном этапе она становится цикличной, или, что точнее, спиралевидной: в пройденном, как тебе кажется, материале ты начинаешь замечать новые моменты, ранее упущенные из виду.

Пример:
я начинал с Доусона. Проработав капитально, взялся за Лутца. После - Fluent Python, Python Cookbook и иже с ними... (HTML, Django, CSS, работа над собственным проектом - это я все опускаю, как не относящиеся к сути вопроса детали. Говорим только про Python и книги.)

Так вот, к Доусону я больше не возвращался, к Лутцу - иногда возвращаюсь, а "иже с ними" я перечитываю по кругу и каждый раз открываю для себя что-то новое. Это, скорее всего, связано с тем, что всякий раз ты возвращаешься на исходную позицию с уже более прокачанными знаниями/пониманием, отстутствие которых не позволяет охватить все и сразу с первой попытки; плюс, каждый автор преподносит один и тот же материал с другой стороны (другими примерами), что дополнительно углубляет твое понимание пройденого.

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

Замечу, что все вышеописанное базируется на предположении, что вы стремитесь к максимальному развитию в рамках своей технологии. На мой взгляд, нельзя объять необъятное и хвататься за все сразу; step-by-step, как я говорил. Должна быть, по меньшей мере одна крепкая база + сопутствующее. Но эта база должна быть отшлифована до блеска, как птичьи плоды одного из небезызвестного персонажа из бронзы, расположеного на севере парка Боулинг-Грин в Финансовом квартале Нью-Йорка, в двух кварталах южнее Нью-Йоркской фондовой биржи.

Для меня такой базой, в настоящее время, является Python. Ему я и уделяю большую часть времени, распределяя оставшееся на Прочее. А вот когда я абсолютно и полностью исчерпаю Python - буду искать следующую Приоритетную цель на его место. И так далее. Процесс, фактически, бесконечен.

Вот именно поэтому справочник не нужен. В нем просто нет резона. У вас всегда должен быть под рукой актуальный материал, который будет двигать вас вперед. В этом смысле справочник - это некий костыль для постигшего дзен, умудренного опытом Змея, которому уже лень думать, некуда развиваться, но иногда нужно по-быстренькому напомнить себе о временах буйной молодости, воспоминания о которых можно освежить в памяти открыв 135-ую страницу - первый абзац, вторая строка :)

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

P.S. Про литературу в целом можете посмотреть ТУТ.

Чтобы создать файл requirements.txt для своего проекта, выполните следующую команду, находясь в окружении проекта(виртуальном или каком еще):
pip freeze > requirements.txt
Открыв файл, вы увидите:

Django==1.10
django-cors-middleware==1.3.0
djangorestframework==3.4.5
djangorestframework-jsonapi==2.1.0
inflection==0.3.1
...

#!/bin/bash

while true; do
	echo -n "Please enter an folder -> "
	read folderdcheck

	if [ ! -d "$folderdcheck" ]; then
		echo "$folderdcheck is not exist."
		mkdir -p $folderdcheck
		echo "$folderdcheck is created."
		break
	else
		echo "$folderdcheck exist."
	fi

done
echo "Program terminated."

По хорошему, нужно еще делать проверку корректности ввода у этого скрипта.

зачем такие мучения, делайте просто:

echo "Укажите имя папки:"
read Dir
mkdir -p $Dir

если нету то создаст, если есть то ничего страшного, ошибка подавится параметром -p

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