Евгений

1 шаг - получить базу фундаментальных знаний в выбранной сфере (в это же время можно сформировать некое начальное портфолио)
2 шаг - изучить основы маркетинга для дальнейшего построения общения с клиентами
3 шаг - изучить рынок на предмет ценовой политики для формирования собственной стратегии роста и постановки первоначальной почасовой ставки
4 шаг - оформить профили на фриланс биржах основываясь на знаниях полученных выше и примерах профилей успешных фрилансеров(не копировать, а писать своё)
5 шаг - начинать посылать отклики на проекты, выполнение которых требует не меньше ~70% текущих знаний
6 - повторять 5 шаг, корректируя стоимость часа, до "устаканивания" в среднем рейте по сфере, регулярно обновляю информацию в профилях на биржах и пополняя портфолио завершёнными проектами - с чёткой детализацией выполненных задач в них.
7 - не забывать продолжать развиваться в выбранной сфере и нишеваться в узких направлениях если изначально было выбрано слишком широкое

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

1. переименовываете или удаляете папку .git
2. создаете репозиторий на github
3. дальше по стандарту:

git init
git commit -a
git remote add origin git@github.com:user/reponame.git
git push -u origin master

Потом либо возвращаете старую папку .git, либо используете новый репозиторий.

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

Стандартные решения:
1. самодокументируемый код, составленный так, что читающий может понять что для чего и в какой последовательности работает.
2. описание интерфейсов (назначение метода, тип/суть параметров и т.п.) в форме комментов в коде.
3. автоматическая документация (генерится из комментариев) - эффективно, только если сам код закрыт.
4. модульные тесты, фиксирующие требования к коду и демонстрирующие его использование.
5. описание высокоуровневого дизайна (High Level Design, HLD), описывающий какие элементы существуют, их взаимосвязь друг с другом и основные сценарии взаимодействия.

Работающая документация - это компромисс из этих практик, релевантный конкретной ситуации.

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

Так как же всё таки взять заказ новичку?

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

Герман Греф: Не нужны сегодня программисты. У нас огромное количество программистов, с которыми мы боремся.
Тим кук: Изучайте программирование, а не английский.

Больше кода: что государство может сделать с четырехкратной нехваткой программистов в России? тыц

Япония вводит обязательные уроки программирования в начальной школе тыц

Ведущие муниципальные колледжи США вводят учебный курс «Разработка приложений на Swift» тыц

США выделят на программирование в школах $200 млн в год тыц

В США падает спрос на инженеров и ученых, а на программистов — растет тыц

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

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

Пример сервисов, которые теоретически должны заменять веб-разработчиков:

https://origami.design/
https://atomic.io/
https://webflow.com/

Но почему-то не заменяют? Подумайте над этим.

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

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

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

Алгоритмы: теория и практика.
Алгоритмы и структуры данных

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

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

Все же рекомендую ansible.
Во первых, он не работает как клиент-сервер, а работает полностью по ssh и на стороне сервера ничего устанавливать не нужно.
Во вторых достаточно прост в изучении.
В третьих, поставить ansible - дело 5 минут

Здесь плохо всё, к сожалению.

Начнем с того, что вы неверно наследуете классы. Почему у вас класс, отвечающий за подключение к базе данных является родителем класса, работающим с заказами? Наследование применяется, если можно сказать, что что-то является чем-то. Например, разработчик является работником; компьютер является устройством и тд. Здесь же у вас вообще близко такой логике не получится следовать. Вы должны передавать хотя бы объект для работы с бд через инъекцию, например, в конструктор. В идеале, нужно использовать паттерн репозиторий для работы с базой данных.

Класс SearchOrder у вас не только выполняет запросы, но еще и работает с данными, хранит состояние этих самых данных, фильтрует данные (strip_tags()). Непорядок. Это все нужно разделять. У вас вообще получаются какие-то богообъекты, которые умеют во все.

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

$result = $wrapper->select("SELECT * FROM `tablename` WHERE `id` = :id", ['id' => 5]);

?

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

Зачем вы используете свойства, если можно обойтись обычными локальными переменными:

$this->orderID = (int) strip_tags($orderID);
$this->column = (string) strip_tags($column);
$this->value = (string) strip_tags($value);

?

Почему вы стриппите тэги у идентификатора? вы настолько не уверены в том, что влетает в функцию:
strip_tags($orderID);
?

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

if (!is_string($arg)) {
    throw new InvalidArgumentTypeException('string', $arg);
}

Это в идеале. Вы не обязаны это делать, конечно же. Но вот такие проверки делают приложение безопаснее. Хотя, опять же, повторюсь, в 2017 нужно начинать новые проекты на php 7.1+.

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

Кроме всего прочего, почитайте про стандарты оформления кода. Вы им не следуете.

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

Желаю успехов!

Но бесит, что там нет единого собранного файла bundle.js

В шаблоне webpack-simple все скрипты собираются как раз в один файл build.js. Обратите внимание, он подключается в сгенерированный index.html. vuejs-templates/webpack-simple.

Этот файл недоступен в файловой системе при запуске dev сервера, потому что в режиме разработки он находится исключительно в памяти.

так он еще создает кучи других непонятных файлов и при режиме разработки запускает ненужный 'hot-load'.

Давайте разберемся, для чего нужен сервер в режиме разработки для Vue. При написания SPA приложения вы используете кучу библиотек, файлов в разных форматах и возможно еще обращаетесь к стороннему API(например twitter). Плюсом, вам хотелось бы использовать транспайлер, чтобы в js можно было красиво писать стрелочные функции и использовать другие вкусняшки ES2015. А еще это здорово было бы склеивать файлы одного формата в один большой для разных оптимизаций. Плюс, после того как вы измените что-то в одном файле, не пришлось бы тыкать каждый раз на перезагрузку страницы. Примерно эти вещи делает за вас dev сервер с webpack в режиме разработки.

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

Оставить в покое django под портом :8000, а VueJS под :8080. И в nginx как-то слушать их обоих, раздельно, таким образом четко разделить фронт от бэка. Не будет ли проблем?

Проблем с проксированием nginx'ом? Не очень понятно что вы имеете в виду.

Если вам нужен кастомный шаблон vue-cli то вы можете легко его разработать один раз и в дальнейшем использовать: Vue-cli custom templates

Как правильно организовать структуру SPA + Backend

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

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

Эта парадигма оправдана в определенных случаях, как и другие парадигмы.

В случае микросервисной парадигмы вы делите ваше приложение на много микро-сервисов. Давайте придумаем кейс, который может возникнуть в реальной жизни.

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

Ваше приложение схематически выглядит так:

Клиент: хочу авторизоваться => Сервер приложения: отправлю бизнес-логике => Бизнес-логика: спросим базу (данные для авторизации) => База данных: можно => Клиент: я авторизован

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

Теперь, в вашем фронтенде на Vue, например, вы можете отображать нужные вам данные (а соотв. делать запросы в основную базу), только если пользователь авторизован.

Теперь ваше приложение выглядит так:

Клиент: хочу авторизоваться => Фронтенд-микросервис: отправляю микросервису авторизации => Микросервис авторизации: можно => Фронтенд-микросервис: я авторизован, хочу данные => Сервер приложения: отправлю бизнес-логике => Бизнес-логика: спросим базу (данные отображения авторизованному клиенту) => База данных: данные => Клиент: я получил данные

Давайте теперь представим, что вам нужно быстро, а лучше сегодня набросать MVP для демонстрации инвестору или для проверки вашей концепции.

Авторизация? — микросервис — auth0.com
SQL База данных? — микросервис — Google CLOUD SQL
Уменьшаем размер картинок? — микросервис — AWS Lambda

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

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

Давайте посмотрим на ваш пример с Django. Если я все правильно понимаю, то вы хотите использовать все плюсы Django, типа ORM, API доступа к БД, etc, заменив лишь систему шаблонов на Vue?

В таком случае, на мой взгляд, вам нужно реализовать на Django классический REST API и из SPA на Vue обращаться к endpoint'ам вашего API.

Ссылки по теме:
Архитектура микросервисов
SPA-архитектура для CRM-систем: часть 1
SPA-архитектура для CRM-систем: часть 2
AWS Lambda и никаких серверов