German Jet

1. Я кладу все вьюхи отдельно, модельки отдельно, коллекции отдельно и т.д. Некоторые складывают по бизнес-сущностям ("по экранам", "по страницам").
2. Любой модульной системой (на данный момент времени SystemJS и ES6 модули), из расчета один класс -- один файл.
3. Сразу начинайте использовать дата-байндинг: rivets.js, ractive, vue.js, сэкономите массу времени. Ознакомьтесь со списком расширений -- пригодится.

P.S. Обратите внимание на всякие хорошие практики в ООП, типа S.O.L.I.D. Кстати, осваивать ember/angular и т.п. необязательно, но поглядеть стоит -- будет понятнее, какие недостатки есть в Backbone и как их обходить.

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

"Доверяй, но проверяй". И конечно же зависит от поставленных задач:

Если нужно быстро собрать работающий прототип, то приложения - хороший вариант.

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

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

Для проверки решения существуют разного рода аудиторские конторы, сервисы и стандарты, которые и на безопасности проверят, и на нагрузку если нужно.

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

Блин, да это же джанго, он сам явно подталкивает к одной структуре приложения.
Одно приложение на 1 логическую и независимую часть сайта. Например, интернет-магазин должен включать в себя каталог продукции и функционал для заявок. Потому что они взаимосвязаны. А вот новостную часть на этом сайте надо выносить в отдельное приложение, так как новости обычно почти не связаны с заказами и товарами как таковыми.
Ещё в каждом приложении можно создавать папку static, куда класть все статические файлы. Но так обычно поступают разрабы "плагинов" для джанги. В рамках сайта можно коласть в 1 папку static в корне проекта, но разделяя js и css файлы (чтобы вёрстка не было в 1-м суперогромном css файле, в котором хрен чо найдёшь). Потом сборщики должны всё собирать и минимизировать.
Шаблоны раскидывай по папкам, соблюдая иерархию. Т.е. если есть приложение shop, то в корневой папке templates создай layout.html, а все шаблоны магазина клади внутрь templates/shop, наследуя. Также можно хранить шаблоны внутри приложения, но опять же, это обычно используют разрабы "плагинов", хотя сам принцип хорош.

Есть два варианта хранения данных об авторизованном пользователе:
1) В куки (так по умолчанию используется в асп.нет): необходимые данные (claims) шифруются machineKey и отдаются пользователю в http-only куках, таким образом при каждом запросе на сервер они присылаются, расшифровываются и далее можно проверить в необходимых местах.
плюсы: полностью stateless, нет надобности обращаться к БД
минусы: при необходимости "выбить" сессию со стороны сервера нужно поднимать более сложную логику и хранить флаги в промежуточном хранилище (проверять что если для такого-то пользователя требуется завершить, то такие действия, иначе другие);
2) Ключ сессии: после успешной аутентификации авторизуем пользователя и claims храним на сервере в быстрой памяти или БД (key-value), где ключ - ключ сессии, значение - любые данные.
плюсы: есть полный контроль состоянием авторизации (как и возможность завершить сессию со стороны сервера, так и сменить пользователю роль(или другие параметры) "на лету")
минусы: организация доп. прослойки - кэша или хранение в БД (медленно), при перезапуске/падении сервиса сессии клиентам потребуется перелогиниться.

1
1.1 В куки писать или ключ сессии или шифрованные данные о пользователе, сессия - абстрактное понятие (это пара: ключ и данные), ключ должен быть защищенным, т.е. трудным к копированию (хотя бы зрительно трудно запомнить), уникальным (чтобы не возникло коллизий: двум разным пользователям выдался один и тот же ключ, т.е. это не должна быть хэш-функция от логина-пароля или IP или чего-то неуникального).
1.2 В асп.нет существуют атрибуты авторизации (в которых можно расставлять проверки на требование таковой, роль, конкретный пользователь), в общем смысле логика такова: поступил запрос на сервер, далее нужно посмотреть к какому ресурсу идёт обращение (защищенному или свободному), если ресурс защищен, то проверить куки (ключ сессии или шифрованные данные), расшифровать/получить данные о сессии из кэша и предпринять решение: пускаем или не пускаем (отдаём 401/403 или отдаем 200/404/...).
1.3 Завести на сервере (в кэше или БД) словарь , при алгоритме проверки сессии добавить условие проверки на наличие записи в словаре.
1.4 С нескольких - словаря не нужно.

2
2.1 Даже если пользователь входит через ВК всё равно нужно отдавать свои ключи сессий/шифрованные данные, а вот внутри данных уже хранить access_token от вк-шной сессии, так очень маленькая вероятность, что токен ВК утечет, а если утек ключ сессии, то действия будут ограничены только функционалом сайта.
2.2 После расшифровки куки или данных по ключу сессии делать доп запрос на сервер ВК с токеном, который сохранился при аутентификации (access_token), запрос простой, например получить имя пользователя, если ВК выдал что токен просрочен или ошибку, то сессию закрывать или куки с данными обнулять.

Читал книжку по PHP

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

В общем, я занимаюсь программированием по часу в день уже достаточно долго

Этого совершенно недостаточно, чтобы чему-то научиться. Либо вы ленивы, либо программирование вам не интересно.

А может c# ?
Стандартная библиотека больше на дельфийскую похожа, как по мне.
Что не удивительно https://goo.gl/O5C3hp

python и django учатся быстрее чем php и любой фреймворк для него, большинство php программистов легко переобучаются на python/django

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

> я никогда не смогу быть unix only специалистом, из-за того что microsoft здесь доминирует.
не совсем согласен. Да, стек MS еще доминирует, но с другой стороны, околосетевое оборудование (сервера VPN-доступа, сетевые шлюзы) или отдельные сервисы - почта, NAS - вполне могут быть не на винде. И если ОДНОМУ админу сложно быть unix-only, то В ПАРЕ с виндовым админом - вполне, почему нет? В нормальном предприятии > 2 админов нормальная ситуация, потому что некоторые работы нужно проводить ночью + иногда дежурить или выезжать. Чтобы работать в рамках ТК, два админа - вполне адекватное решение. В штатных ситуациях один вполне может специализироваться на *nix.
Вообще, вам правильно советуют подучить еще какой-нибудь софт. Люди любят более-менее законченные решения, логично что директору хочется, чтобы вы смогли хотя бы почту поднять и админить ее, или поддерживать внутренний сайт.
Вот кстати, корпоративного софта сейчас намного меньше под .NET, Python и Ruby имеют хорошую долю во внутрикорпоративных приложениях, да и сам .NET уже поддерживается гораздо лучше самим MS на unix системах. Следовательно, сейчас > 80% серверов - это про *nix (в IT-специлизированных компаниях еще больше). Огромное количество софта на платформе java куда чаще запускают на linux машинах. Так что учитесь так, чтобы сказать "Здравствуйте. Я могу поддерживать почту/NAS/JIRA/Redmine/Jenkins/Samba, если у вас нет, могу и поднять". И во многих случаях у вас либо уже будет unix, либо (набравшись опыта) вы сами сможете все настроить. О, а DBA это отдельная история. Если совладаете с PostgreSQL, а то и с Oracle, вам будут давать неплохие деньги.
И в конце концов, потеря данных сейчас фатальна или очень нежелательна для большинства компаний. Почти всегда первейшей задачей админа является настройка бэкапов и слежение за ними (работоспособность, "учебные" аварии и т.д.), и на бэкап-машине винда уже просто ни к чему.

В общем, делайте выводы. Мое мнение: если компания не застряла в 90-х, в ней больше 10 сотрудников, и там используется что-то помимо MS Office и виндовых расшаренных папок, то там вполне пригодится unix-админ. Ах да, обязательно выучите парочку скриптовых языков. Например, bash как язык из мира unix, и Python как изначально кроссплатформенный. Когда человек умеет писать скрипты, кончается эникейщик, и начинается системный администратор.

Мне кажется, что просто linux-админы не сильно то и нужны. К хорошему знанию системы имеет смысл приложить хорошее знание какого-то прикладного софта или железа. В чистом виде unix-админы нужны тогда, когда нужно админить AIX+Power или Solaris+SPARC. А если к этому ещё приложены хранилки типа Storwize и коммутаторы Brocade, тогда можно говорить почти о чистом unix-админстве. Второй вариант - это связка unix-админа и DBA. Одним только Linux-ом никого не удивить.

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

CodeIgniter ни в коем сулчае. Это уже забытый и, на фоне других проектов, совсем не удобный и ряхлый фреймворк. Symfony можно, хоть я им и не пользовался. Yii - как по мне так слишком сложный. У Yii все более похоже на plain php, у laravel'а все сделано вместо тебя. Лично для меня это просто идеал, даже не хочется изобретать велосипед. Посмотри документацию Lumen (мини-фреймворк от разраба Laravel) а потом сравни с Yii и решай. Другие можешь даже не смотреть. А работа с Ajax всегда одинаковая, на всех фреймворках.

Если вы работаете на ру. площадках, самый полезный способ будет брать проекты, которые вам показались интересными и делать их. Заказчики в проектах выкладывают материалы (ТЗ, иногда исходники, ссылки на свои сайты) и пишут достаточно подробное описание. Это самый простой способ не придумывать проект, как пыталась делать я (магазин Чайничек, который продает чашки и чайнички), а браться со старта за реальные проекты.

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

Когда значимая часть свободных копейщиков свалит на https://www.upwork.com/ и выполнять прихоти толсто...пых российских менеджеров мобилы станет некому :)

PS: В опилках российских заказчиков, как правило, не умещается простая истина:

A deal is a deal

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

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

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

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

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