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

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

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

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

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

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

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

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

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

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

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

Я постараюсь подключить философию, примеры и "как если бы я говорил в баре с вами".

ЯП - это инструмент. Инструмент всегда взаимодействует с объектом и со средой. Соответственно, вам точно нужно что-то знать про объект и уметь пользоваться инструментом внутри среды, а это потащит дополнительные знания, назовем их "естественными" зависимостями. Насколько глубоко их нужно знать? Тут ответа не бывает: настолько, насколько нужно и хочется. Тут важен баланс и акцент. Если нет строгих параметров на уровне разума, нужно верить интуиции, потому что больше нечему. Для JS-программиста JSON/jQuery/AJAX - это естественные зависимости, их в любом случае не получится обойти. Даю зуб, что вам хватит вечера и немного гугла, чтобы стать чуть ли не LIKE A PRO в этом. Это все форматы хранения данных, либы, парадигмы. Это примерно как прочитать состав у шоколадки по сложности и входному порогу. Скорее всего, вас пугают сложные слова. Примерно как сказать "НАПРАВЛЕННЫЙ АЦИКЛИЧЕСКИЙ ГРАФ", и вы сразу знаете теорию графов, хотя с практической точки зрения суть настолько элементарна, что аж страшно, а вы будете долго прокрастинировать и искать что попроще.

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

Вы можете просто верстать (html/css) и игнорировать программирование в целом. Но естественная среда противится: вы уже (!) пишете на декларативном языке, неплохо было бы узнать об этом подробнее (о языках или даже о типизации), тем более, что крайне близко к вам находится интереснейший язык js, а там моментально вылезут проблемы связывания html и js, разные подходы к этому, целые парадигмы и фреймворки; и вот вам выпадает интересная задача по анимированию svg, вы курите мануал по нужной либе, читаете что-то про reflow/repaint, внезапно узнаете что-нибудь про селекторы. И через какое-то время, будучи все тем же верстальщиком, вы видите архитектурный косяк дизайна, который очень неудобно укладывается в используемые технологии, предлагаете его пофиксить и спасаете команду от факапа через месяц, когда какой-нибудь транзишн наложится на какой-нибудь position: fixed и еще и в Safari упадет анимация и только там, а тут и новая тудушка: "Переделать, нафиг, всю шапку, чтобы ок было". Что-то изменилось в мышлении и картина стала полнее. ВНЕЗАПНО вы уже и инженер, можно сказать, ЗП растет, все дела, рутины меньше стало.

Так вот, о инженерах. Можно выучить, например, Python за пару дней, там же отличный мануал. Но настоящий программист - это инженер, потому что вся суть в архитектуре, во взаимодействии объектов/компонентов и в том, как все это соотносится с задачей. Какой молоток взять, это уже без разницы, как состав на банке прочитать. То есть суть вашей работы заключается как раз в объекте и среде, а не в инструменте. Образно говоря, когда вы сидите в кафе, суть не в чашке чая, а в атмосфере и как вы себя в ней чувствуете, но при этом чашка чая нужна, чтобы заставить вас что-то делать и вписать тем в самым во взаимодействие со средой, поэтому придется научиться красиво пить чай.

Подведу тут черту: естественные зависимости - это норма, а суть в инжиниринге. Можно двигаться по зависимостям дальше. У вас есть интервал, где есть минимальный порог, ниже которого нельзя, и максимальный, где вы "мастер на все руки", что тоже плохо. Между минимальным и максимальным порогом можно двигаться. Взять те же сети: разворачиваете приложение, видите линуху, настраиваете сеть. Можно немного заморочиться и прочитать про основы маршрутизации, буквально 2 вечера, можно еще про сетевой стек в линукс, еще 2 вечера, и уже будет во много раз проще. Кроме того, возрастет культура в целом и если вы программист на бэке, то вам будет проще взаимодействовать с админами. Про OSPF, очевидно, читать не надо, важен баланс. Баланс - это понимание того, на что у вас акцент (вы программист? какой? фронт/бэк? насколько важны сети/ос? проектируете бд? верстаете? интересен ли прикладной кодинг под какую-то ос и так далее...) и насколько интересны естественные далекие зависимости выбранной области.

Так вот, теперь у нас есть естественные зависимости, инжиниринг и баланс между порогами. А не php/jquery/html/css.

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

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

А теперь, собственно, выводы:

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

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

Конечно, люди разные, но я не могу. Лучше это время тратить на личные проекты (опенсорс) и на развитие (новые языки, улучшать фундаментальные знания), либо еще на какое-то хобби (у меня это музыка, например). В долгосрочной перспективе это принесет больше пользы, а качество жизни будет выше. Работать на двух работах, совмещать работу/учебу - все это либо для очень-очень организованных людей (феноменально организованных, которые могут жить четко по плану каждый день), либо для тех, кто особо-то и не вникает (а это напрямую влияет на качество скилла). Кроме того, как не пытался, предел продуктивной работы в сутки - это порядка 6 часов. Все остальное не только не приносит удовольствия, так еще и по качеству получается хуже. Лучше делать одну задачу, "быть медленнее", но делать ее реально круто.

Совсем дефолтовая задача, использовать json.loads().
https://docs.python.org/3/library/json.html

#!/usr/bin/env python

import json

path = 'example.json'

with open(path, 'r') as f:
    data = json.loads(f.read())
    for i in data['employees']['employee']:
        if i['id'] == '3':
            print(i['photo'])

У вас не совсем полный вопрос. Он про ранжирование или про то, как подружить теги со сфинксом? А как теги реализованы? Поэтому я напишу обзорный ответ, который покажет, куда копать, что делать. Сам я использовал однажды 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 не популярен? :(