DigitalSmile

И еще хотелось бы остаться на платформе до конца, а не переучиваться через 5-10 лет.

Хехе, наивный :)
10 лет назад скажи народу, что на JS будут сервер писать - засмеяли бы. А лет 15 назад пфф. Я уж не говорю у мобильной разработке, которая расцвела полным ходом. Да и даже веб сильно изменился.

Как именно там зарабатывают обычные люди, разработчики

Также как и все - работают на дядю и зарабатывают. А на чем дядя зарабатывает, на том и вы.

На самом деле все очень по разному... Да и большое заблуждение, что Unix-way = бесплатно. Хм ... Ну например 1С для Linux - ОС бесплатная, но ПО под него нет.

Если я лицензирую свой код GPLv2/3(и совместимыми), то как на этом зарабатывать?

Платная поддержка по подписке. Или например сейчас можно делать для опенсурсной платформы платное облако. Хочешь - себе ставь бесплатно, хочешь плати и тебе все из коробочки всучат.

У меня закралось подозрение, что ... "Если я лицензирую свой код GPLv2/3" - вы что, думаете вам начальник разрешит? :D Или стооооп, вы надеетесь работать на себя в карман? На Сях? Не ну удачи, она вам точно понадобится.

PS
На правах ИМХО.

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

Паралельно можете поразбираться с типичными шаблонами проектирования под js: largescalejs.ru

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

Опять же, когда речь идет о реально больших проектах, следует перестать писать на каждый чих свой велосипед. Нужна библиотека для организации маршрутизации - берем готовую. Нужно работать с датами - берем moment.js и т.д. Сборщики вроде того же jspm умеют выдерать из популярных библиотек то что можно (если можно так сделать, скажем с angular2 выдрать только нужные модули можно. а вот с angular1 нет).

Так а почему их не заливать на сайт для которого вы приминяете эти шрифты?
Я к примеру всегда заливаю шрифты или на сайт на котором эти шрифты применяю.
Или на свой сайт заливаю, и с него подключаю.

или если его и не нужно получать по идеологии, то почему?

потому что это создает зависимость директивы от контекста, в котором она используется. Проследите логику

1) работа директивы требует того что бы она была обернута в SomeControeller на уровень выше.
2) директива становится частью SomeControeller, или если быть точным, куска view которым управляет SomeControeller.
3) нет смысла в директиве, так как мы не можем более реюзать ее в другом месте
4) если директива зависит от контроллера SomeControeller, почему бы не вынести из SomeControeller то что нужно директиве в ее собственный контроллер?

как-то так. Все взаимодействие с директивой должно происходить либо через контроллеры директив (параметр require директивы), либо через атрибуты (изолированный scope, bindToController в angular 1.4). И уж тем более странно желание подменять методы контроллера из link.

updated

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

Далее, по поводу обработчиков - яркий пример директива ng-click. Эта директива выглядит как-то так:

function myNgClick() {
    return {
        restrict: 'A',
        scope: {
            callback: "&myNgClick"
        },
        link: function (scope, el) {
            el.bind('click', function (e) {
                scope.$apply(function () {
                     scope.callback({$event: e});
                });
            });
        }
    }
}

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

link директивы нужен ТОЛЬКО для того что бы связать DOM и логику. То есть в 99% случаев в директиве будет только link или только контроллер. Оба - это уже стремно, в этом случае лучше вынести ту логику которую хочется запихнуть в link в отдельную директиву.

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

Пара слов по поводу ng-controller. Это так же директива, которая позволяет привязать к элементу какой-то контроллер. Эта штука по сути (как и ng-include в принципе) нужна только для ускорения разработки и упрощения. В целом же приложение на angular стоит воспринимать как HMVC приложение, состоящее исключительно из деревьев директив. Первый шаг на пути к web-components (по сути ангуляровские директивы послужили неплохим глотком вдохновения).

Как-то так.

Тут мой ответ по связанной теме: Как составить план проектирования проекта?
А кроме того, хочу отметить, что начинать проект с дизайна (если Вы имеете в виду дизайн пользовательского интерфейса) это в большинстве случаев очень плохая практика. Проект нужно начинать с концепции, а потом переходить к информационной модели, потом к структурам данных (как в базе, так и в памяти) и уже потом только понятно, что на экране будет делаться. Исключение могут составлять игры, электронные книги, анимационные, интерактивные и подобные произведения, которые являются в большей степени произведением визуального искусства, чем программным продуктом. Из средств проектирования посмотрите разные реализации UML и RUP (Rational Unified Process), например Rational Rose. Вот, посмотрели, и понравилось - берите, а стало страшно - значит это Вам не нужно. Это для проектов крупных и очень крупных. Что точно нужно, так это уметь рисовать ER-диаграммы на бумажке карандашом, архитектуру модулей программной системы и железную инфраструктуру для развертывания. На большинство вопросов, которые Вы задаете, ответы можно дать только относительно конкретного проекта. Иногда нужны автоматизированные средства проектирования, иногда они не нужны и все можно сделать в уме и сэкономить время. Это очень зависит от задачи и опыта. Но что определенно, так не следует разводить лишней бюрократии,

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

https://docs.angularjs.org/api/ng/service/$http#caching

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

codereview.stackexchange.com

reddit.com/r/cpp

как же задолбали подобные вопросы !
ребята вы к гадалкам бы походили или еще как то на кофе, или ромашку бы заюзали ... что за вопрос ─ какие шансы пробиться ? рынок есть, значит отличные от нуля, а насколько отличные зависит от вас.
За год профессионалом не стать не стать, но джуном/мидлом в зависимости от области запросто, просто начните что то делать.
Если вместо того чтобы работать задавать вопросы насколько реально, то вообще никак, остается тока плакаться на злодейку судьбу, географию ... масовнов и на плохую погоду, а после этого склеить ласты с голоду.

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