Да, забыл ещё, что рёбра одной фигуры не должны пересекаться с рёбрами другой + грани не должны лежать друг в друге.
То, что работает неадекватно - факт, никто не спорит. Почему? Потому что реализовать адекватно эти хитрые случаи трудно. Программиста, готового потратить кучу времени на решение не нашлось. Продукт с открытыми исходниками, бесплатный. Ситуация для таких продуктов обычная, когда относительно редкие и при этом сложные в реализации ф-ии не работают правильно.
Хостинг для node.js не нужен. node.js/npm нужны только в процессе разработки. После npm run build получаются обычные html/js/css файлы, которые нуждаются только в простейшем web-сервере, который отдаст их клиенту в браузер.
1) Хотите писать под мобилки (со всем вытекающими) - Unity. Вакансий довольно много.
2) Хотите писать серьёзные игры под ПК/консоли - UE4. Вакансий в разы меньше.
Для своих хобби-проектов выбрал UE4: 1) сложность его далеко не так высока, как говорят (даже наоборот - есть визуальное программирование - блюпринты); 2) картинка из коробки на голову выше; 3) субъективно - Unity показался в сравнении с UE4 водяным пистолетом.
spaceatmoon, Ну, я так делал когда-то - поднакопил деньжат и - полгода на диване... Эх, хорошо было... Если семью с ипотекой ещё не завёл - почему нет? А потом - снова в бой! :)
beduin01, если файл не расшарен - то я бы вернул "404 / не найдено" или "401 / не авторизован" (в зависимости от специфики). Если упало - "500 / внутренняя ошибка".
От себя добавлю:
1) пишу довольно большой проект, но стараюсь не дублировать классы без необходимости - если для view потенциально доступны все поля исходного класса (класс не содержит секурных данных типа паролей, которые не должны быть видны всем пользователям), то оставляю один общий класс на все случаи;
2) для перекидывания данных между похожими классами стоит научиться использовать спец. штуки типа AutoMapper.
semt1, если пройти по ссылке, то вы увидите, что там как раз больше про GPL написано, чем про LGPL - есть свои тонкости, совсем однозначного ответа на этот вопрос, видимо, нет, т.к. почти нет судебной практики.
Для меня наследование классов - ещё не наследование компонентов. Вот посмотрите, например, как это сделано в HaQuery: помимо наследования кода можно также переиспользовать/расширять HTML-шаблон и частично/полностью переопределять CSS компонента. Также, при наследовании, сохраняется мета-информация о компоненте.
Но я, конечно, плохо разбираюсь в этом... Всего-то десяток лет работы архитектором.. Не то, что вы - наверняка у вас лет 20 опыта! :)
Эх, вам бы почитать про всё это... Сервер-то вы запустили, а вот есть ли у вас серверный код, который будет выполняться - это вопрос... В вашем случае npm start, скорее всего, стартану просто сервер для отдачи статичных файлов... У вас точно есть файл `data.json` в каталоге `api`? :)
Тоже использую похожий подход - если не очень много записей, то на клиенте (работает быстро, не нужно лишнего кода), если много - на сервере (помедленнее, т.к. запросы на сервер при каждом изменении фильтров + нужно писать код для сервера, но зато можно обрабатывать любое кол-во данных).
То, что работает неадекватно - факт, никто не спорит. Почему? Потому что реализовать адекватно эти хитрые случаи трудно. Программиста, готового потратить кучу времени на решение не нашлось. Продукт с открытыми исходниками, бесплатный. Ситуация для таких продуктов обычная, когда относительно редкие и при этом сложные в реализации ф-ии не работают правильно.