Андрей Титов

Потеоретизирую по этому вопросу из своего опыта.
Я писал и внедрял программы для работы сотрудников.
До того использовались широко известные программы, но подходили они постольку-поскольку.

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

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

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

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

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

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

Как выразить это какими-либо цифрами - просто затрудняюсь даже представить...

Где распакован архив со скалой, какая у вас переменяя PATH, SCALA_HOME, JAVA_HOME, какая java?

Если все идеально, то удалите всю скалу и скачайте заново дистрибутив.

В главном меню:
Code -> Convert Java File to Kotlin File
И, разумеется, нужно установить плагин

Еще можно так:

наработанный опыт сообщества

Вы путаете теплое с мягким.

UML - это язык для рисования схем, которым пользуются для того, чтобы нарисовать классы и их взаимосвязь. С паттернами программирования никак не связано.

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

Ну у них XML-ка разрослась, и они разбили её на две (layout.xml инклудит content.xml). Чтобы этого не было, при создании новой Activity из гуя выбирайте не "Blank Activity", а "Empty Activity"

Да, можно, уже и клиент есть на Python https://github.com/leandrotoledo/python-telegram-bot

При клике на категорию в каталоге, в качестве модели в роут передается сама модель категории (как у вас app/router.js и написано), и стадия загрузки модели пропускается, так как модель уже есть.

Когда вы перезагружаете страницу, то модель роута грузить как ей и полагается так как это не переход по ссылке.

Потому и отличия.

Вам в link-to нужно передавать не модель категории, а его id если хотите чтобы model в роуте выполнялся всегда.

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