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

Раньше я объявлял приватные свойства и методы так:

Раньше вы криво создавали объекты и у вас получалась кривая реализация паттерна "модуль". Да и "свойства и методы" ваши приватные они как бы не совсем свойства и методы, это просто переменные (статические свойства в терминах java) и функции.

Или я что-то упустил?

Инкапсуляция в javascript достигается и достигалась ранее за счет модулей (сокрытие переменных в дочернем скоупе.

let privateStaticVar = 'foo';

// то что экспортируется - то публичное
export default class MyClass() {
    constructor() {
    }
}

// или

export default (function () {
    let foo = 'foo';

    return class FooBar {
         constructor() {
         }
    };
}());

Ну и в es2015 добавились символы как простой вариант сделать настоящие приватные переменные, ну и еще есть weakmap.

const privateFoo = Symbol('foo');

export default FooBar {
    constructor(foo) {
       this[privateFoo] = foo;
    }
}

Сделайте нормальный клон testlink в рамках опенсурса. Платных сервисов хватает, а вот среди опенсурс решений только это ищадие ада.

Почитайте про реализацию BigInt

https://github.com/ibiwan/swift-bigint/blob/master... - вот например.

Laravel бери и не мудри. Если нет нормального опыта работы с javascript (jquery не считается) - лучше не брать angular. Лучше погоди чутка пока не релизнится ng2, по ng1 слишком много булшита написано, достаточно вопросы на тостере глянуть.

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

Мокают сам DAO, никто в здравом уме не мокает Connection/DataSource и т.д. поскольку поддерживать такие тесты выходит слишком дорого - проще написать простенький интеграционный тест, который использует реальную базу данных.

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

А ели у вас отфильтрованная коллекция есть в контроллере, то вывести ее длину вообще не проблема.

зачем они вообще нужны в работе, ведь всё хорошо и без них?

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

Словом, если вы разберетесь с принципами SOLID и GRASP, а так же в принципе с ООП (сокрытие состояния, обмен сообщениями между объектами разных типов), то паттерны будут появляться сами по себе.

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

n-layered архитектура - это просто архитектура построенное на рандомном количестве слоев. оно определяет базовые принципы разделения ответственности и все такое, но на этом все.

onion - тут уже идет уточнение, что мол в самом сердце у нас core-domain, сущности, базовые бизнес правила. От него уже идет дальше domain layer, application layer и т.д. То есть сначала мы проектируем core-domain а потом уже все остальное.

Есть еще гексагональная - это опять же уточнения для n-layered архитектур, что мол каждый слой отделен друг от друга за счет dependency inversion. На границах слоев всегда есть интерфейсы, а у внешнего слоя - реализация. Потому ее называют "архитектура портов и адаптеров".

Пожалуй выложу чуть более "няшную" ссылку, в допллнение к Алексей Уколов

jwt.io

Работы на скала мало, но специалистов еще меньше, так что особо конкуренции там нет. Следовательно работу найти можно.

Есть непонимание процесса написания правильных тестов.

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

Добавил я продукт и что мне мониторить?

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

Если такого метода нет, то нам надо подменить List на мок, но ваш код этого не позволяет сделать. Опять же это мы уже тест на реализацию завязываем, а стало быть наши тесты становятся хуже. Но коль уж мы пошли по этому пути можно просто length померять.