Сергей Протько

Мне 14 и я встал в тупик!

Вам 14, это нормально.

Я собираюсь стать программистом

Какой язык выбрать в качестве основного?

Английский. Начните с него.

web-dev в качестве серверного языка выбирают PHP, Python,

А как же Ruby? Go? Javascript + Node.js? Erlang?

Для системного администрирования Python,

Да как-то даже Perl еще юзают.

Для создания приложений C#,C++,Python.

Java!, Kotlin, Scala, DLang, Rust, Go... Да и приложения разные бывают.

Какой язык используете вы, и что посоветуете мне?

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

Могу вам только сказать, что если вы осилите эту книжку, то вы уже будете на голову выше среднестатистического джуниора PHP коих на рынке сейчас тьма.

Нормальна ли схема с единой точкой входа

В принципе нормально, все так и делают вобщем то.

ведь, если количество модулей перевалит за 10

Всегда можно вынести что-то в отдельный модуль. Руководствуйтесь здравым смыслом, снижайте связанность (вообще почитайте про low coupling и high cohesion для более адекватной организации модулей).

вешать события на элементы

А ваши модули с табами и т.д. что делают тогда?

Или стоит создать отдельную страницу, на которой будут запускаться тесты mocha на основе уже собранного JS проекта?

Это наиболее удобный вариант. Так же помимо фэнтома рассмотрите вариант с webdriver io, как самый честный вариант тестирования. Медленно... но чтож поделать если вы решили UI тестить (а точнее UI элементы).

Пока я вижу следующую схему: mocha + jsdom

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

если моя функция не предназначена для работы с DOM — я должен снова вернуться к unit-тестам.

Именно так. Если вам не нужен DOM - старые добные юнит тесты.

Имеет ли вообще смысл тестировать, скажем так, такой примитивный код?

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

Возможно у кого-то завалялся репозиторий с похожим кейсом?

Рекомендую вам просто отказаться от прямой работы с DOM. Мне дико нравится подход ангуляра к построению приложений. В нем мы тестируем 10% директив, которым приходится работать с DOM, а все остальное - просто подготовка состояния. Далее в дело вступают биндинги, которые и так оттестированы, и декларативное представление, которое по природе своей тестировать смысла нет.

метод addPeriodicTimer

https://blog.wyrihaximus.net/2015/01/reactphp-timers/

реверт коммиты, чем ребейз отличается от merge, чери пик коммитов, подпись коммитов. Сквош коммитов.

Смотря какой проект. Если до релиза хотя бы MVP пара месяцев - лучше взять ng1.5 и потом мигрировать на 2.0, а если пол года - то можно сразу на двойке. Ну и так же зависит от того, что вам от ng2 нужно. Серверсайд пререндеринг? Тогда лучше второй сразу, но учитывайте риски.

две функции js работали одновременно.

Это невозможно. В JS все работает исключительно последовательно. "одновременность работы" достигается за счет использования event loop.

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

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

man apt-get install
man service
man wget

Что можно почитать, что бы начать в этом разбираться?

Может не надо это вам? Разберитесь с browser-sync для начала и тамошним сервачком. А потом уже опыт браузерсинка можно проэцеировать на nginx.

для работы только прошка. Эйра не хватит.

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

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

Авторизация (а точнее авторизован ли чувак) проверяется в ресолверах маршрутов а не в компонентах.

TDD

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

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

TDD - для одного разработчика, BDD - для команды. А BDD-style assertions для chai - это пафос. По сути это "планирование фич" в рамках библиотек и отдельных объектов. Чуть меньший масштаб. Но ничем от TDD вообще не отличается, хотя если сильно постараться можно так же оценивать ценность фич для пользователей нашей библиотеки и т.д.

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

https://habrahabr.ru/company/bankrot-pro/blog/230441/

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

те, которые вам нужны. Просто так "учить" библиотеки - глупо. Лучше поучите javascript (es2015/2016), прошарьтесь в написании тестов, tdd, bdd, solid, grasp, separation of concerns, dry, kiss, yagni.

Рекомендую почитать вот это: Scrum vs Kanban: Making the Most of Both

книжка читается быстро и легко.

100-300к просмотров/день

ставим сверху varnish и все хорошо.

Не сильно прожорливий, какой впс/сервер у вас, как ощущения?

вы же понимаете, что переменных, которые влияют на производительность ооооочень много?

только если вы дизайнер и верстка это не то чем вы будете заниматься.