German Jet

пришло понимание, что программирование это не знание языка и фреймворков

Какой вы для себя ответ определили на вопрос что же такое программирование?

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

Стартап? Определите какая потребность не закрыта у вас и друзей и пилите его каждый вечер по часу-два.

Big Data это ведь не самоцель. Вот прошли вы курс допустим. Что вы будете бигдейтить, на каких данных?

Самое главное ответьте себе на вопрос что вам по-настоящему нравится и двигайтесь в эту сторону.

Ну возьмите Heroku.
Там все тоже - только завернуто гораздо удобнее. Минимум телодвижений по администрированию.
А Docker, Ansible, Vagrant - это вы еще увязните в изучении...

Если у вас количество серверов за десяток не выйдет и нет надобности быстро разворачивать новые чуть ли не ежедневно, вам не нужны Doker, Vagrant, Ansible. Вы — не Google.

1. Шарите дамп базы в контейнер (копировать не стоит, т.к. из-за слоёности образов, контейнер может получиться слишком жирным).
2. При сборке запускаете наполнение БД (pg_restore database.dump / mysql < database.sql)

А ещё, если работаете с Doctrine, то можно создавать БД средствами ORM и наполнять фикстурами.

Из jquerийных простенький morris и посложнее flot.
Для Анжелы n3. Для любителей Ember Charts.
Простенькие ChartJS и uvCharts.
Очень легкий и хорошо разжеванный ChartList.
Не менее хорошо разжеванный, но платный, ZingChart.
Поддержку legacy обеспечит FusionCharts - обещают работу на IE6.
Профессионалам понравится список фичей plotly.
Вы бы конкретнее указывали какие графики вам нужны. А то все не подходят, а что нужно - секрет. Хотите создавать свою систему - читайте исходники существующих. - Врятли любая статья будет лучше и более полной чем исходники рабочих библиотек.

Удалить через шаблонизатор дубли здесь будет затруднительно, если это действительно нужно то лучше использовать обработку на этапе views, удалив дубли или выводя статьи через шаблонный тег, в коде которого проверять на совпадения.

Архитектурная ошибка уже допущена на этапе проектирования url. {% url 'articles' article.slug article_page.slug %}. В любом случае будут дубли, т.к. адрес url будет /cat1/article /cat2/article/

Способов избавиться от них два:
1) Статьи отдельно, категории отдельно. /url/catalog/name /url/article/name
В этом случае даже если выводится одна статья несколько раз, url уникален
2) Одна главная категория, url на основании этой категории. Остальные категории второстепенные, отдельным списком.

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

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

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

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

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

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

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

10 лет назад тестировщиком было устроиться проще, компании, которые начали специализироваться на тестировании и компании, которые вводили у себя профессиональное тестирование, находились в начале своего активного роста. Профессия, особенно в странах СНГ, как таковая была еще не очень устоявшаяся.

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

Куда вам идти выбирать лично вам. Работать можно вообще в любой сфере, где вы можете работать.

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

С аяксами достаточно просто, я использую библиотеку axios.js.
Я сейчас тоже перевожу свой проект на vue, постепенно его изучая. Все, что можно, отдается по ajax, все что должно быть в рамках SEO, отдается со стороны сервера, со стороны vue, использую привязку к модели или вызовы по v-click и подобным. Для какого-то интерактива, использую пользовательские директивы. Например кастомная директива связывает конкретный товар из списка товаров с его показом, если он есть в корзине, которая загружается по аякс. В общем, сначала ломал себе мозг, как связать список товаров на странице с корзиной, вот нашел очень хорошее решение -пользовательская директива, и для СЕО хорошо, и интерактивно в обе стороны, и с элементом можно творить все что угодно.
Сейчас делаю пользовательскую директиву, которая подменяет href в ссылках пагинации, на параметры фильтров, которые рисуются через компоненты vue.

Это же Rails, а значит это скорее всего сделано за вас: https://github.com/jorgemanrubia/mailgun_rails
Настраиваете, а потом отправляете обычным способом через ActionMailer
И mailgun - это сервис для отправки транзакционных email, тут подписки не требуются (только в тестовом режиме - в нем вы можете отправлять email только на подтвержденные адреса)

Скрипач не нужен, родной (с)
Аргументы против jq:
- современные браузеры достаточно хорошо поддерживают единый синтаксис современного екмаскрипт(native js)(на самом деле нет).
- сторонняя библиотека, работает медленнее чем натив и в основном состоит из с-сахара (тоже не совсем правда)
- тащить еще один ресурс весом от 64 кб до 200 кб, еще и со сторонних ресурсов замедляет загрузку( правда, но бред)
Аргументы за:
- Современные браузеры как и всегда один другого "ровнее", всегда есть косяки и "нюансы", на которые еще и попадаешь обычно в самый неподходящий момент, в жк обычно все работает одинаково везде, ну или лучше чем в нативе.
- В жк реализована куча плюшек в 1 функцию которые в нативе занимают "многабукав", не каждый начинающий напишет их правильно, да и профи не все напишут оптимально, уверен что в большинстве случаев написанный нативом функционал будет хуже аналога из жк.
- размер мин пакета жк 64 кб, и все они лежат на быстрых цдн серверах. Думаю это последнее что может повлиять на скорость загрузки страницы.
- есть ОГРОМНОЕ количество скриптов написанных с учетом жк, не использовать их глупо, писать свой велосипед - вообще только в целях обучения(не берем крайние случаи когда плагин писал упоротый пингвин).
- Синтаксис и краткость записи - вообще вне конкуренции.
- Старые браузеры никто не отменял, часто заказчик требует чтобы работало в ие8, натив не канает или доставляет море анального удовольствия.
Вывод: Если ты крут в жс, еще и работаешь в ангуларе/ещечетамдляфронта и тебе нужно сделать 2 действия в очень современных браузерах - jquery не нужен, и ты это сам знаешь. Если слова ангулар, вуе и проч для тебя не больше чем шум листвы за окном, а навесить плагинов и эффектов нужно - jquery наше все.

UPD: для всех кто там отписался а ля "в связи (...), исчезновением проблемы совместимости со старыми IE (что и было основным назначением jQuery)." - свежачок