Андрей Пронин

Начните, пожалуй, с Маркса.

Фронтенд Angular, бакэнд на Flask.

вот ты сам оценил адекватно ситуацию и выводов тут немного, один из них - пережить эту яму
1) если уходить на фриланс, то быть психологически готовым к поиску первых заказов (может оказаться долгим)
2) если устраиваться на удаленку, быть готовым врать про возраст (говорить 18-19) и опыт (говорить год пишешь что-то для себя), никто проверять все равно не будет, не наглеть и устроиться на junior'a
к сожалению в этим двух пунктах нужно будет смириться с тем, что то, что ты хочешь не всегда возможно здесь и сейчас.
Понятно, что хочется выбрать оптимальный путь по скорости развития + финансы + интересная сфера, но, к сожалению, с твоими вводными вариантов немного. Будь то фриланс или удаленка - не выбирай фултайм, оставь время на изучение смежных языков и доп. информации и отдых. Успехов и удачи в поисках, с большой вероятностью у тебя все получится!

Можете, трудности только у вашего работодателя

Однозначно Graphviz!
В AsciiDoc, например, есть плагин. Тогда прямо в тексте достаточно написать:

digraph {
    graph [rankdir=TD,ranksep=0.5,fontname=Arial]
    node [shape=box,fontname=Arial,fontsize=12,style="rounded"]
    edge [fontsize=8, fontname=Arial]

    user [shape=diamond, label="User", fillcolor=yellow, style="rounded,filled"]
    nginx [label="Nginx Web Server \n (http://ctxm.ornet.org)", style="bold,rounded"]
    jenkins [label="Jenkins"]
    nexus [label="Nexus"]
    sonar [label="Sonar"]
    postgres [label="PostgreSQL"]
    openldap [label="OpenLDAP"]
    volumes [label="volumes\n (data persisted here!)", constraint=false,color=gray, fillcolor=gray, style="rounded,filled"]

    user -> nginx[label="access", style=tapered, penwidth=3 ]

    nginx -> nexus[label="\/nexus"]
    nginx -> sonar[label="\/sonar"]
    nginx -> jenkins[label="\/jenkins"]
    nginx -> volumes [label="volumes-from",color=gray]
    openldap -> volumes [label="volumes-from",color=gray]
    postgres -> volumes [label="volumes-from",color=gray]
    jenkins -> openldap
    jenkins -> nexus
    jenkins -> volumes [label="volumes-from",color=gray]
    nexus -> openldap
    nexus -> volumes [label="volumes-from",color=gray]
    sonar -> postgres
    sonar -> openldap
    sonar -> volumes [label="volumes-from",color=gray]
}

А на выходе это даст картинку:

Лучше всего ум, как инструмент познания, развивает философия. Вот ей и займитесь... разумеется, не пренебрегая и другими науками (инструментами познания), и тем же самым презренным контентом - сырьем, которое натренированный ум будет критически перерабатывать, превращая в незамутненное знание :)

были занятия по азам программирование микропроцессоров, но толком не объясняли ничего.

С чего начать выздоровление?
Обратился к врачу с болями в животе, врач сделал клизму, но боли не прошли. А хотелось бы выздороветь.

Ответ лично мне представляется очевидным: либо сменить врача, либо заняться самолечением, т.е. самостоятельным изучением микропроцессоров и их программирования. :)

Если выберете второй вариант, начните с физики, схемотехники логических элементов и архитектуры / устройства микропроцессоров. Потом переходите к информатике, учите ассемблер, C и, возможно, VHDL. как можно быстрее купите себе плату (да хоть ту же Ардуину) и учитесь писать программы. Других путей к выздоровлению не существует.

Вот как это выглядит с т.з. работодателя

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

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

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

Вообще, это делается как-то так:

1. Формулируются ожидания с т.з. бизнеса. В данном случае понятие "дико медлено" нужно выразить как-то объективно. Например. Имеем: поиск по ключевой фразе А при объеме данных Х заниманет N секунд. Поиск по ключевым фразам типа Б вообще невозможен. Требуется: поиск по фразе А и Б должен занимать не более N/10 секунд для объема данных до Х*1000.
Формулируются внятные тесткейсы и пишутся тесты производительности, позволяющие позже проверить, достигнуты ли эти ожидания.

2. Анализируется архитектура на предмет возможности / трудозатрат для введения новой технологии. Если архитектура типа Новогодней елки (тронул в одном месте - посыпалось все), то на этом введение может и закончиться, т.к. окажется, что для этого понадобится 90% переписать заново. Если же архитектура это позволяет, то проблему сначала нужно изолировать (абстрагировать поиск каким-то интерфейсом / фасадом). Для этого (если их еще нет) пишутся тесты, закрепляющие функционал, потом рефакторится код.

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

4. Пишется альтернативная имплементация, которой на стенде заменяется "старая", прогоняются тесты (по функционалу и производительности). Если все прошло удачно - архитектору премию и выкатываем на продакшн. Если облом - архитектору выговор, и все сначала :)

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

На собеседовании я обычно прошу выбрать из послужного списка какой-нибудь один проект (на усмотрение самого кандидата - наиболее крутой: в котором было найдено какое-нибудь особенно интересное решение, или использованы какие-нибудь крутые технологии, или решена какая-нибудь нетривиальная задача... короче, которым он сам гордится) и рассказать о нем подробнее, но, опять же, не в смысле, какие именитые были заказчики или как необъятен был бюджет, а в смысле, что он любимый в нем конкретно сделал, чему научился и чего добился. Обычно уже сам выбор достаточно показателен. (Если чел собеседуется, например, на синьера JEE, а в качестве темы выберет написанный в старших классах школы сайт на PHP, на котором была особенно удачная фотография кошки - это уже повод задуматься.)

А дальше, по мере рассказа, начинаю задавать уточняющие вопросики (на вшивость): ага... тесты писали... а какое было покрытие? А как определяли? А в каком порядке выполнятся тесты из одного класса?.. Так, так... JBoss... а какая версия использовалась? Дескрипторы или аннотации? А что нового появилось в следующих версиях? А сервлеты вручную писали? ...ага, SOAP. А из каких трех частей состоит WSDL? А моки в SOAPUI делали? Ну, и далее - вглубь или вширь, по мере объема знаний кандидата.

У такого подхода есть две стороны. Первая: если человеку есть чем гордиться, он начинает с горящими глазами грузить меня техническими подробностями, снимается ситуация стресса. Из режима "теста" мы плавно переходим в режим беседы на профессиональные темы. Если же начинает мямлить что-то про невероятную важность проекта и свою ключевую роль в нем, но на вопросы не может ответить, т.к. "этим он лично не занимался", а "эти решения принимали другие", то с ним очень быстро все становится понятно и беседу на этом можно заканчивать.

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

Еще по поводу отдельных технологий, о которых заходит речь, прошу кандидата оценить свои познания в ней по пятибальной шкале "1 - первый раз слышу, 5 - эксперт". Для экспертов у меня заготовлены конкретные вопросы из жизни, как правило, примеры кода, иллюстрирующие какую-нибудь нетривиальную хреновину, которые я тут же достаю из папочки и предлагаю совместно разобрать. Эксперт в Яве - хорошо! Давай побеседуем о медели памяти, сборщиках мусора или кеше процессора. Эксперт в SQL - замечательно! Давай попробуем оптимизировать запрос. Эксперт в сетях - чудесно! Давай разберемся, почему падает вот этот долбаный сокет. Опять же, цель этого подхода - отнюдь не завалить самоуверенного кандидата, а именно понять, как человек мыслит, как ищет решения проблем, достаточно ли у него для этого знаний и опыта. Не беда, если кандидат погорячился с самооценкой... тут важно не знание ответа, а именно подход к решению проблемы (т.к. от синьера именно таки ожидается решение проблемы, а не констатация ее сложности).

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

LIMIT имеет смысл только в сочетании с ORDER BY. Например, выдать конфетку трем победителям:

UPDATE users SET candy=candy+1 ORDER BY score DESC LIMIT 3

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

Функции позволяют писать программы, постепенно углубляясь в отдельные аспекты и не теряя при этом "общую картину". Например, в программе нужно получить данные с сервера, распарсить их, что-то посчитать и вывести результаты. Вместо того, чтоб писать простыню, в которой тут же запутаешься, можно разбить код на функции getData() - parseData() - performCalculation() - displayResult(), и постепенно писать их логику, концентрируясь на решении конкретной задачи отдельной функции. Разделение сложной задачи на более простые - это, вообще, основной принцип борьбы со сложностью. Если это делать разумно (т.е. разделять на осмысленные кусочки), то функции, написанные один раз, можно использовать в разных местах программы (повторное использование кода).

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

И еще они позволяют вносить изменения в логику программы, не перекраивая ее для этого целиком (полиморфизм). Если в примере выше вдруг понадобится изменить алгоритм рассчета, достаточно изменить performCalculation() (или даже написать другую функцию performNewSpecialCalculation() и просто изменить вызов).

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

Лет пять назад открыл для себя утилитку F.lux. С тех пор забыл о чувстве песка и рези в глазах после долгого сидения за монитором. Очень рекомендую.

лидер - www.freepik.com/, у него много эксклюзива, а не как у других- сборники со свалок в сети

по иконкам - от него же www.flaticon.com

еще есть всякие all-free-download.com, но там мутнее с лицензией

из относительно бесплатных рекомендую www.kozzi.com ( коззи скис, остался graphicstock.com, на него надо подписаться мылом и потом ловить акции на дешевую годовую)