Дмитрий Филимонов

Удобнее всего писать в еще одном процессе. Его задачей было бы ожидать данные из очереди по get() и писать все полученное в файл. Очевидно, тут есть проблема, что процесс никогда не завершится, но она легко решается: в главном процессе вы ждете завершения всех процессов-воркеров по join(), после чего посылаете в очередь какое-нибудь "интересное" значение (я бы послал None), после чего ждете завершения процесса-писателя опять же по join(). При виде "интересного" значения пишущий процесс завершается. Ну и главный процесс тоже завершается, соответственно. Как будто бы выглядит не очень красиво, НО это нормально: нужен какой-то механизм, который бы сказал, что "в очередь больше не придут", что мы и делаем в главном процессе. Можно расширить очередь, кидать исключения, но, думаю, None вполне достаточно. Кстати, для этого можно использовать Pipe() в случае с процессами, но я бы точно не стал так делать, потому что зачем? :)

Меня, кстати, недавно что-то подобное тревожило, искал инфу и понял, что эта задача очень похожа на шаблон producer-consumer, только у нас производящий процесс еще и обрабатывает данные, а получающий процесс только пишет. В C#, кстати, есть специальная коллекция, которая может "закрыться". А вот что пишет по этому поводу Java:

A BlockingQueue does not intrinsically support any kind of "close" or "shutdown" operation to indicate that no more items will be added. The needs and usage of such features tend to be implementation-dependent. For example, a common tactic is for producers to insert special end-of-stream or poison objects, that are interpreted accordingly when taken by consumers.

Special end-of-stream or poison objects, КАРЛ! Это я как бы оправдываюсь, что нормальное решение предлагаю. :)))

Писать в главном процессе неудобно. В таком случае мы не можем вызвать join() у воркеров, поэтому нужен иной способ убедиться, что задачи закончены. Кажется, что для этого можно использовать методы task_done() и join() у очереди. Можно было бы затолкать адреса серверов в очередь (пусть будет q_in), в воркере делать q_in.get(), обрабатывать данные и класть в другую очередь (назовем ее q_out), после чего вызывать q_in.task_done(). НО у нас снова блокирующий метод q_in.join(), который ждет завершения всех задач. Т.е. такая возможность тут не катит. Да даже если бы он не блокировал, то все равно пришлось бы делать sleep() в цикле, что совсем некрасиво. Тут правильно вызывать блокирующий get() в пишущем процессе и завершаться по получению какого-то сигнала. Этим сигналом будет либо отправка "интересного" значения (и в случае записи в главном процессе это сделать некому, х̶о̶т̶я̶ ̶м̶о̶ж̶н̶о̶ ̶с̶д̶е̶л̶а̶т̶ь̶ ̶о̶т̶д̶е̶л̶ь̶н̶ы̶й̶ ̶п̶р̶о̶ц̶е̶с̶с̶ ̶д̶л̶я̶ ̶э̶т̶о̶г̶о̶,̶ ̶г̶о̶в̶о̶р̶и̶т̶ ̶и̶з̶в̶р̶а̶щ̶е̶н̶е̶ц̶), как я уже сказал выше, либо же можно ввести еще одну сущность, назовем ее "глобальный счетчик". Т.е. он должен уменьшаться после того, как в очередь складывается результат. А главный процесс может проверять, не равен ли этот счетчик нулю после того, как сработал get() на очереди. И если равен, то выйти из бесконечного цикла, заджойниться к воркеркам, и завершиться. Но ведь это менее красиво, чем отдельный пишущий процесс: придется создать глобальную переменную и если с тредами можно было бы обойтись простым локом, то в случае с процессами там какой-то геморрой 100%, я никогда так не делал, ведь глобальные переменные - зло. В общем, с какой стороны не подойти, нужно писать в отдельном процессе, иначе можно изобрести что-нибудь.

Хочу еще пару вещей тут заметить.

Вам точно нужно писать по мере поступления данных? Быть может, это не нужно. Ведь там постоянные открытия/закрытия файла будут, это тоже некий оверхед, нужно ли это по-настоящему? Кроме того, нужны ли именно процессы? Там сложная обработка данных, сколько она времени занимает относительно ввода/вывода? Если некритично мало, то лучше использовать треды, в таком случае с ними все может оказаться быстрее. Кроме того, с тредами появляется возможность использовать глобальные объекты, которые я все-таки использую, хотя они и зло. Можно, например, вместо Queue использовать list/set/dict. В cpython они является threadsafe, но лучше на всякий случай использовать локи в таком случае, они вносят совсем небольшой оверхед, но при этом 100% защитят от интересных проблем (я бы сделал класс LockedIterator в таком случае, чтобы было универсально для всего). Главный плюс в том, что они значительно быстрее, чем Queue, даже с локами (по моим тестам, хотя, думаю, можно это и нагуглить). А ведь вам, по сути, прелести Queue и не нужны, если юзать треды. То есть вы уверены, что процессы + плавно писать в файл - это быстрее/удобнее/лучше, чем просто сделать треды без Queue, дождаться завершения, все записать в файл? Хотя тут тоже могут быть сложности с оперативой, если очень много писать нужно.

Кроме того, а почему не, например, ansible? Он умеет опрашивать хосты и принимать в себя плагины на питоне. Кроме того, там есть асинхронные задачи, я их не использовал, но, по-моему, они справятся.

SELECT U.name, C.text
FROM comments C
INNER JOIN users U
ON C.user_id = U.id
AND C.id = (
    SELECT id 
    FROM comments 
    WHERE user_id=U.id
    ORDER BY id DESC
    LIMIT 1
)

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

p.s. Хорошим тоном в таких вопросах является выкладывать код (и попытки запроса) на sqlfiddle и добавлять перед словом "начинающий" фразу "тотально ленивый и желающий, чтобы кто-нибудь сделал все за меня".

Думаю, что где-то косяк с MTU. Хорошо и наглядно проблема описана тут - habrahabr.ru/post/136871 - стоит подебажить в этом направлении.

Единственная причина, которая обосновывает нескольких демонов и которая мне известна: OpenVPN однопоточный, а поэтому в многоядерной системе планировщик будет кидать процесс с ядра на ядро, но все ресурсы таким образом вы не утилизируете. Если запустить несколько OpenVPN процессов, то теоретически вы должны эффективнее использовать процессор. Это актуально в том случае, если у вас большой канал, например гигабитный или выше, и тормозит шифрование/обработка пакетов.

Что касается именно скорости соединения, то больше, чем ваш канал, вы не получите, запустите хоть десяток каких угодно VPN. Провайдер зашейпит ваш трафик, т.е. все пакеты свыше некоторого лимита будут отброшены (простейший случай).

Соответственно, в вашем случае (10Мбит/с) нет никаких причин поднимать несколько процессов, поднимать бондинг (у которого, кстати, есть разные алгоритмы и не каждый из них будет эффективен именно для увеличения пропускной способности). Вот если бы у вас было несколько каналов с разной пропускной способностью, тогда да, смысл бы имелся.

Мог бы предложить потюнить OpenVPN, однако, кажется, вы и так это сделали. Прирост скорости также может дать отключение компрессии, фикса mss и т.п.

Тостер, ну почему ты не сохраняешь где-нибудь в local storage сообщения, которые не дописаны? Ааааа! В общем, написал, закрыл вкладку, пишу снова.

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

Понятие алгоритма (машина Тьюринга) императивно. Первые архитектуры компьютера, описывающие как хранить код и данные (архитектура фон Неймана и т.п.), тоже императивные. Императивно/дискретно работает "физический мир полупроводниковой логики". Императивная парадигма является "родной" для компьютера. А ООП - это продолжение, эволюция императивной парадигмы.

Императивная программа состоит из инструкций, которые что-то меняют в памяти. Если смотреть с минимальным зумом, то много инструкций - это функция. А много функций - это модуль. С точки зрения инженерии ПО важно программе быть максимально модульной, максимально DRY, легко изменяемой, эффективно решающей задачи поставленные и еще много чего. Так вот, кажется, у нас все есть, растащил по директориям кучу файлов, функции/модули/область видимости, но этого не хватит, ведь есть же еще типы, а их надо передавать туда-сюда, обрабатывать. Есть алгоритмы, которым глубоко фиолетово, что обрабатывать, будь то массив, словарь, список, дерево или даже генератор (люблю питон @ пиарю где могу). Кстати говоря, тут можно задуматься о сути итераторов, но это оффтопик.

Во времена популярности ассемблера типов "еще не было". И это вызывало проблемы: множество рутины, множество кода, возможность прострелить себе регистр и так далее. Во времена C были примитивные типы и даже структуры, которые могли хранить данные и указатели на данные. Но все еще как-то неудобно, множество низкоуровневых действий. Нет даже строк, представлять их в виде массива - не слишком удобно, гораздо лучше иметь что-то вроде черного ящика. Где-то в те же времена уже было ясно, что нужно иметь еще более абстрактные типы, которые могут хранить контекст, иметь свои функции (методы), инициализироваться, деинициализироваться. В общем, нужно создавать типы "высокой абстракции", а еще уметь их модифицировать, расширять, комбинировать. И лучше еще с памятью явно не работать. А еще чуть позже популяризовались языки с динамической типизацией, где стало можно не заботиться о типах совсем. Мне даже кажется, что тут уместно сказать, что типов будто "уже не стало". Все есть контейнеры со своей областью видимости. Правда, все это медленно, особенно, если учесть, что динамическая типизация очень любит интерпретацию или динамическую компиляцию. Чем выше уровень, тем все тормознее.

На самом деле все эти идеи были очень давно (ООП, динамическая типизация), еще даже раньше, чем появился C, однако людям было нужно время, чтобы осознать, обкатать.

С ООП теперь все удобно. Кроме модулей и функций есть сложные типы (классы), которые можно свободно создавать, наследовать, регулировать область видимости, заменять методы, использовать интерфейсы, "строить модули внутри модулей", не использовать глобальные переменные, внедрять зависимости, не дублировать код. В языках, реализующих неклассическое ООП, существует еще больше свободы. Можно использовать миксины направо-налево, классы являются объектами, а где-то и классов нет, потому что есть объект и с ним и так все хорошо))

Это все особо важно и нужно в прикладных задачах, где обрабатываются разные данные, выводятся в разных видах или где есть интерфейс пользователя с множеством однотипных элементов. Практически всегда там возникает ситуация, когда нужно определить множество похожих объектов, сделать удобное API, использовать и расширять стороннюю библиотеку. Кроме того, существует множество паттернов, которые можно переносить откуда угодно куда угодно, не думая при этом. В вебе, с учетом того, что 95% приложений крутятся вокруг MVC и его вариаций, ООП очень даже кстати: модельки - это однотипные объекты из однотипных полей, имеющие в себе какую-то логику (свои функции/методы), контроллеры - однотипные объекты (получение данных/параметров запроса, выдача необходимого ответа в нужном виде). Если взять любой фреймворк, то там реализовано множество модулей, которые что-то реализуют: ORM, роутинг, кэш, сессии, request-объекты, response-объекты, какие-нибудь карты сайта, админки, модельки для юзеров, что-нибудь для работы со статикой, формы, локализация... Если нужно что-то расширить, то достаточно посмотреть на API, отнаследоваться, реализовать/заменить метод.

Наверное, нужны какие-то примеры. Вот представьте, что пишете простой сайт, который должен отдавать готовый HTML. Но кроме этого сайт модный, поэтому он полностью ajax (html5 history api), никаких перезагрузок, только первая загрузка страницы, которая выгружает и фронт и стили и отрендеренную страничку, а потом дергаются нужные данные для других страниц (в json, туда кладется отрендеренная часть и еще какие-нибудь важные данные) с бэкенда. Оговорюсь, что это не SPA, а именно full ajax сайт, который все-таки еще рендерится на сервере в каком-нибудь серверном фреймворке. И ваш бэкенд должен отдавать, соответственно, 2 варианта страниц: обычную (как при прямом заходе по ссылке, это и для пользователя и для бота) и json-вариант для других страниц (это уже только для пользователя, соответственно). Вы создаете крутой контроллер, который в зависимости от параметров в GET, либо в зависимости от заголовка рендерит то json, то html. А дальше наследуетесь от этого контроллера и совсем не заботитесь о том, что у вас отдает конкретный контроллер: переопределяете метод с контекстом и отдаете в нем нужные данные, а уж что с ними станет в шаблоне или как их обработает фронтенд, получив из json, - без разницы. Нужно сделать только ajax-контроллер? У вас для него есть класс, осталось опять же только отнаследоваться. Нужно отдавать SEO-заголовки? Можно сделать миксин для контроллера и миксин для модельки и снова переопределить только один метод а-ля get_meta_title и все. Ну, понятное дело, я тут упустил мелкие подробности и все это актуально больше для языка вроде python и подобных (уж на чем пишу), но вот пример ООП-задач.

Или у вас есть либа... Допустим, она зависит еще от трех других либ, плюс предоставляет какое-то API. Выглядит в виде класса, в нем несколько методов, пара публичных, + конструктор, + свойства. Пишете тесты, подменили зависимости объектами-пустышками и все получилось красиво. А как это сделать, использовать ли там какие-то специальные контейнеры или прямо на лету пропатчили класс (̶̶к̶а̶к̶,̶ ̶н̶а̶п̶р̶и̶м̶е̶р̶,̶ ̶м̶о̶ж̶е̶т̶ ̶п̶и̶т̶о̶н̶,̶ ̶п̶о̶т̶о̶м̶у̶ ̶ч̶т̶о̶ ̶о̶н̶ ̶в̶а̶м̶ ̶т̶а̶м̶ ̶н̶е̶ ̶"̶п̶а̶б̶л̶и̶к̶ ̶с̶т̶а̶т̶и̶к̶ ̶в̶о̶й̶д̶ ̶в̶с̶е̶ ̶м̶н̶о̶г̶о̶с̶л̶о̶в̶н̶о̶е̶ ̶и̶ ̶т̶о̶л̶с̶т̶о̶е̶ ̶г̶д̶е̶ ̶м̶и̶н̶и̶м̶а̶л̶и̶з̶м̶"̶), не суть.

Да вот даже возвращаясь к тем итераторам, что я выше затронул. Допустим, есть у вас итератор и нужно сделать его thread safe. То есть при вызове метода, который возвращает следующий элемент, вы должны захватить мьютекс, а потом его отдать. Это легко можно сделать с помощью наследования: просто наследовавшись и обернув нужные методы. Либо с помощью интерфейсов, чтобы было универсально и для каких угодно объектов: реализуется интерфейс итератора в виде класса, который принимает другой итератор и его оборачивает.

Вообще, примеров очень много, они повсюду, особенно, в вебе. Если в таких прикладных задачах не использовать ООП, то я даже не представляю, как тестировать этот код. Как его поддерживать, меняя логику? А как менять компоненты? Как быть DRY? Тут я, кстати, вспомнил про то, что вот, например, есть в C структуры. Это что-то вроде урезанного класса и на самом деле можно реализовать многие штуки с ними, писать отличный код, но он просто будет сложнее в поддержке и по скорости разработки будет очень далеко позади. Ядро линухи выглядит очень красиво и совсем там не лапша. Однажды фиксил драйвер, чтобы заработал 5ггц вай-фай, так вот он был красив и строг внутри. Кстати, в Go классы реализованы в виде структур, но я не смогу подробнее рассказать об этом, т.к. не смотрел этот язык. ООП - это не какая-то супер фича, а это всего лишь подход. Языки же добавляют синтаксический сахар, реализуют классическое ООП (java/c#/c++/etc) или же неклассическое (python, js, etc).

Кроме ООП-парадигмы и процедурной парадигмы есть еще, например, функциональная. Но это отдельная совсем тема. В мультипарадигменных языках можно писать по-разному. Если что-то удобно представляется в виде цепочки функций, выглядит так, как будто нет побочного эффекта или его легко изолировать, то нет стоит городить классы или процедурный ад. Тем более в языках, которые близки к ФП, обычно полно встроенных функций, можно объявлять анонимные функции, почему бы этим не пользоваться. Ну или, например, у вас получился какой-то модуль, в котором не нужна ни инициализация, ни контекст ему не нужен, все выглядит как просто 4 связанные функции, то зачем здесь нужно ООП? Хотя если что-то из этого можно кастомизировать, а вы чувствуете, что это понадобится, т.к. есть объекты, которые будут расширять функциональность, то стоит задуматься. Главное не оверинжинирить.

Сделайте unique index на атрибут nickname в модельке User. Как-то так: nickname = Column(..., unique=True)

И проверяйте так:

try:
    user = User.query.filter_by(nickname=user.nickname).one()
except NoResultFound:
    # ник уникален
    pass
else:
    # ник не уникален
    pass

p.s. Если не нужен результат результат запроса, то можно посмотреть на exists(). Не думаю, что оно критично для подобного рода задач, однако с ним выгрузки данных не происходит.

Снимите кнопочку 3rd в расширении.

p.s. Имейте в виду, что некоторые сайты (преимущественно HTTPS) могут сломаться, если внутри сайта не передавать HTTP Referer (например, Тостер).

У вас не совсем полный вопрос. Он про ранжирование или про то, как подружить теги со сфинксом? А как теги реализованы? Поэтому я напишу обзорный ответ, который покажет, куда копать, что делать. Сам я использовал однажды django-sphinx (ныне заброшенный) для похожих задач (только по тегам не сортировал, ибо задача у меня была по ним уточнять). А вот sphinxit не использовал, поэтому будем рассматривать сначала "голый" сфинкс, а потом уже sphinxit как надстройку. Так что могу где ошибиться, наврать.

Примем, что у вас классическая реализация тегов (тагов? хы) в виде таблички с тегами + many-to-many в табличку с элементами (так, например, делает django-taggit).

В сфинксе есть полнотекстовые поля (по ним он строит специальную структуру (индекс), чтобы быстро искать совпадения по ключевым словам). Они не хранятся в первоначальном виде, только в виде индекса. Есть еще атрибуты, они прикрепляются к индексу, по ним потом можно фильтровать, они именно хранятся в индексе. Это разные числовые значения (типа price или customer_id) или строковые или даже JSON, по ним обычно удобно фильтровать, уточнять запрос. Есть еще MVA - это тоже атрибуты, но представляют из себя множества числовых значений. А как их задать в сфинксе - пример. Вообще, такая возможность (атрибуты и MVA в частности) сделана, чтобы разгрузить БД и нагрузить сфинкс. :)

MVA-атрибуты подходят, чтобы в них хранить тэги и подобное (many-to-many), даже в доках написано:

That is useful to implement article tags, product categories, etc.

Ранжирование - это очень комплексный алгоритм. Для полнотекстовых полей в сфинксе есть специальные ранкеры, среди которых есть алгоритм BM25 и наивные ранкеры, например SPH_RANK_WORDCOUNT, который как раз и выполняет простой подсчет вхождений ключевых слов и учитывает вес поля. По атрибутам же можно фильтровать и сортировать. По MVA тоже можно фильтровать и сортировать.

Дальше буду говорить в рамках языка запросов SphinxQL. Можно еще обращаться к его API, но все равно вы используйте обертку, да и язык запросов как-то попроще для объяснения. В доках встречаются примеры из реализации API на PHP иногда, причем про SphinxQL пояснений нет, но это не значит, что через него нельзя это сделать (или значит, надо смотреть).

Для вашей задачи нужно сделать SELECT с функцией LENGTH() по MVA-атрибуту с тегами, далее по нему отсортировать с помощью ORDER_BY в нужном порядке, а также сделать фильтрацию с помощью WHERE, где указать вхождение тегов в атрибут с помощью оператора IN. Оператор WHERE - это комбайн фильтров по атрибутам и полнотекстового поиска. Таким образом можно рассортировать результаты по длине MVA-атрибута (количеству тегов).

Можно сюда добавить полнотекстовое ранжирование еще (включается с помощью SetRankingMode или с помощью OPTION в SphinxQL) у полнотекстовых полей (по алгоритму BM25, например, что по умолчанию), и сортировать в ORDER_BY и по длине MVA-атрибута с тегами и по WEIGHT() от ранкера (см. доки на предмет примеров); возможно или даже скорее всего, тут придется выбрать еще WEIGHT() в SELECT (раньше он неявно возвращался в ORDER_BY, я это тоже не тестировал). В таком случае будет круто: например, если подряд попадется 50 записей с одинаковым количеством тегов, то они будут отсортированы по весу ранжирующего алгоритма.

В общем, ваша задача красиво решается. Учитывая пример выше, можно с помощью исключительно только сфинкса реализовать и полное совпадение по тегам (сравнивать LENGTH() с количеством тегов в WHERE). И подобное.

Если же теги хранятся как-то неклассически (highload и т.п.), то их в любом случае можно будет достать либо в MVA, либо сделать полнотекстовым полем (в таком случае ранкер SPH_RANK_WORDCOUNT как раз применим). Поэтому суть та же.

Думаю, на все "теоретические" вопросы касательно ранжирования и сфинкса я ответил. Тут есть поле и для хорошего ранжирования и для оптимизации запросов, надо экспериментировать.

Теперь же в рамках sphinxit. Согласно его докам, он умеет и ранкеры включать и на SphinxQL говорить. Надо просто там все это оформить. Не исключены подводные камни, возможно, что-то он не сможет сделать, возможно, где-то и я наврал. По идее нужно уметь делать фильтрацию (тык), сортировку (тык), а тут даже пример, как включать ранкер + описание возможных ранкеров. Кажется, если что, то можно и в селект дописать условие. В общем, все выглядит дружелюбно, удачи!

Кстати, в документации sphinxit в примерах опций (ссылка выше) есть пример, где включен ранкер, но в ORDER BY условие только сортировать по атрибуту name. По идее это должно убить весь смысл ранкера для сортировки, ведь его надо явно указывать в ORDER BY. Видимо, там просто пример, как это конвертится в SphinxQL.

p.s. Странно, что уже как 4+ дня прошло, и на этот вопрос никто не написал ответа. Sphinx не популярен? :(

С ссылками есть проблемы, одним мощным регекспом обойтись сложно. Я уже как-то отвечал на подобный вопрос, лучше использовать linkifyjs.

Все дело в слэше.

Вместо

rewrite ^/admin/$ index.php?type=admin;

нужно

rewrite ^/admin/$ /index.php?type=admin;,

и оно заработает. В вашем примере, который в location, как раз есть слэш.

Что касается второго реврайта (people), то там слэш в конце потерян. Надо сделать так:

rewrite ^people/$ /index.php?type=admin&module=people;

В таком случае www.site.ru/admin/people/ заработает, НО тогда не будет работать без слэша. Можно убрать $, тогда будет работать для любых URL, которые начинаются на www.site.ru/admin/people, т.е. и для www.site.ru/admin/people/ и для www.site.ru/admin/people-f////.

Если нужно для версии со слэшем и без, то можно сделать так:

rewrite ^people/?$ /index.php?type=admin&module=people;

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

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

Какая там музыка, 1-3 часа? Реально? С чем, а с музыкой (и с творчеством вообще) это точно не работает. Я недавно решил накидать ударку для демки, потратил порядка 5 часов на 16 тактов, расставлял всякие крутые фичи, думал, как будет качать. Здоровая еда и спорт - это не про вас, если вы хотите, чтобы музыка качала. Образно, конечно, я говорю.

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

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

Обычно человек чем-то занимается профессионально и чем-то для хобби (в свободное время). Причем хобби вполне может быть профессиональным, но "для себя". Что касается профессиональной деятельности, то можно особо никуда не бежать и при этом развиваться. Уроки по разработке 1-2 часа в день после 8 часов работы? Да ладно, это не работает)) Не бегите так сильно: просто хорошо работайте, старайтесь брать интересные проекты, периодически "горизонтально ходите" по своей области. И все будет хорошо. Вы разработчик? Читайте алгебру по фану, она очень мышлению помогает. Скажите в субботу всем, что вы решили "посидеть за компом", и посмотрите интересный фреймворк или допилите что-то в опенсорс. Делайте главное все это систематически или относительно систематически. И через какое-то время вы поймете, что развитие идет. Главное делайте все круто, что касается работы (чувствуется кривой подход? надо это поправить, это будет и скилл и проекту лучше). И мониторьте разные хабры, модные течения, но не пристально. В общем, кто-то бежит очень сильно, а кто-то медленнее. К качеству это вряд ли имеет какое отношение.

А что касается того, что хочется делать хобби и делать его круто... Здесь выхода нет, придется отставить спорт, правильное питание, не тратить на это время, да. Переехать поближе к работе, возможно, сменить город на поменьше и делать весь вечер игры или музыку, чтобы качала. Мешать соседям, все это не важно... Как и сердечно-сосудистые заболевания (у меня, кстати, есть зачатки, так что я очень хорошо знаю, что такое аритмии/экстрасистолия, повышенное давление, частые головные боли и так далее).

Семья? Говорят еще, что надо семью. Это все чуть позже (имею в виду детей, т.к. именно они реально обременяют). Не могу представить, как можно жить одному (давно не жил), но если человек рядом понимает, то проблем быть не должно быть.

В качестве вывода:

1) Найти свой темп. Пусть он медленнее, чем у самого медленного человека в мире, но главное - быть качественным.
2) Не гнаться за всем, сделать акцент на самом важном. Обычно, кстати, у человека все интересы смежные или их не более двух (больших таких категорий/классов интересов), так что тут легко сделать акцент на самом важном. Это чувствуется всегда (мой субъективный опыт, исключения вижу оооочень редко).
3) Забить на модные штуки 21 века а-ля спорт, ЗОЖ. Делайте зарядку по утрам и не всегда ешьте фастфуд, и все будет хорошо.
4) Работа... Не то, чтобы это центр вашей жизни. Я для себя уяснил одно только правило: делайте круто то, что вы делайте. Вы можете не брать много проектов/ответственности, уходить с работы строго в 6 и ни минутой позже, в общем, в разное время относиться к работе по-разному. Когда-то стрелять там и блистать идеями, когда-то просто работать, когда-то особо не развиваться и заниматься хобби. Относитесь к ней проще. Такая идея лично мне дает свободу, я лучше работаю так. Тем более, что мы с вами в мире IT. У нас работа совпадает с тем, что интересно по-настоящему. Вы же не пьете чай каждую минуту, потому что он очень крутой? Иногда можно не пить его целый день, но это не важно, вы все равно вернетесь к нему через день или два, потому что он нравится. :)
5) Как успевать все и не быть роботом? Никак :)

p.s. Я старался вас успокоить немного, у вас больше психология, нежели реальные проблемы. Не то, чтобы надо всегда быть таким спокойным, нет. Можно адско побегать неделю или месяц. Вы слишком сильно подвержены влиянию разных течений в обществе, они конфликтуют с видением мира настоящего внутри вас. Надо всегда что-то терять. Нельзя повысить уровень абстракции и не усложнить систему (= повысить входной порог). Нельзя очень напрячь руку и сохранить ее мобильность. И да, нельзя повысить количество занятий, не потеряв в качестве (есть какой-то порог, но ваш план перешел порог нормального человека после 3.5 пункта).

Создаете кастомный фильтр, который достает элемент из dict.

@register.filter
def get_item(v, a):
    return v.get(a)

Теперь в шаблоне можно сделать (или даже для этого использовать переменные):

{{ foo|get_item:1|get_item:3 }}

p.s. Но зачем тут defaultdict, да и вообще dict? Почему нe list?