Vitaly Karasik

Можете отвечать этим выпендрёжникам, что computer science у всех в школе была.

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

в общем случае это невозможно
docker файл это список команд, которые необходимо выполнить на 'нулевой системе' чтобы приложение заработало

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

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

Безопасность вещь комплексная и многое зависит от конкретной реализации. То что в одном месте закрывается (и то не факт, так как не известна реализация) один вектор мало влияет на общую безопасность.

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

Хотите комплексно подойти к вопросу? Копайте в сторону изучения материалов от OWASP. Например, https://owasp.org/www-project-web-security-testing... Там достаточно много материалов для чеклистов. Или смотрите готовые чеклисты что проверять. Например, https://github.com/0xRadi/OWASP-Web-Checklist (я не говорю что это прям лучший чеклист, но посмотрите на число пунктов для быстрой оценки).

Хотите подойти еще комплексней? Начните с книги для новичков по поиску узявимостей - Ловушка для багов. Полевое руководство по веб-хакингу | Яворски Питер https://www.piter.com/product_by_id/196618476

А далее например обратите внимание на более сложную книгу как строить защиту в приложениях
Безопасно by design | Берг Джонсон Д., Деоган Д., Савано Д. https://www.piter.com/product/bezopasno-by-design
Там уже более основательно доводится доводится мысль как выстраивать защиту на основании архитектуры.

Если по теории, то мне в свое время вот эта книга помогла:
https://www.litres.ru/robert-s-martin/chistaya-arh...

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

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

Еще через пол года прочел третий раз, опять же с оглядкой на личный опыт. И тут я кажется уже совсем въехал. По крайней мере многие проблемы с организацией взаимодействия между компонентами стали разрешаться. И вообще появилось достаточно четкое понимание, как структурировать приложение и где разбивать его на компоненты.
Ну и после 3 прочтения еще помог момент: мне дали с нуля проектировать новое, достаточно крупное приложение на Rust. Притом заказчик кричал "микросервисы - это круто, хочу, хочу, хочу", а тимлид мне сказал "давай монолит, но так чтоб потом легко было распилить, а то все сроки про**ем". Вот тут прямо вообще понимание пришло. Ну и плюс в Rust архитектурные компоненты очень хорошо ложатся на отдельные крейты (это такая единица компиляции в Rust), а компилятор в принципе не дает делать циклические зависимости между крейтами.

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

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

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

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

У вас вероятно очень специфические задачи если производительности ноутбука за "цена вопроса не имеет значения" вас не устраивает.
Ноут лучшее решение.
Альтернативы:
Переносной накопитель. Ниже производительность, нужны современные интерфейсы, ниже надёжность, выше риск утраты включая возможность компрометации информации.
Любая форма rdp или удаленного ПО. Зависимость от сети.
Скриптованное окружение. Высокая сложность, издержки поддержки скриптов.

Ноут лучшее решение, в стационарных условиях к нему подключается внешний монитор или два.

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

Но если желаете более предметно, то вот Вам мои ощущения по поводу Вашей структуры, к которой вы пришли...

Первое, что бросается в глаза - настройки. Да, Вы следуете идеологии Django, которая неявно шепчет всем нам как их компоновать: но это небезопасно. Почему в настройках у вас модули, два из которых отражает какое-то окружение (разработка, боевое и что-то общее между тем и тем)? Исходя из Вашей структуры сразу витает в воздухе вопрос: "А почему настройки боевого окружения вдруг должны быть в репозитории? А как быть с секретным ключом? А безопасно ли это?". Следующий логичный вопрос удобства: почему я, как разработчик, вдруг должен заставлять своих DevOps'ов компоновать и поддерживать за меня настройки в виде файлов (модулей)? Это ведь исполняемый файл и там бесчисленное количество возможностей; более того, это не безопасно. Сейчас бОльшая часть проектов поднимается средствами docker-compose, куберов и прочих прелестей: дико неудобно собирать и поддерживать настройки в виде файлов для каждого запускаемого контейнера (у нас ведь есть переменные окружения). Надеюсь, здесь понятен основной посыл: безопасность и удобство использования.

(здесь я не сразу понял, что это именно проект, а не приложение; подробности в комментариях)
Едем дальше - core. Почему именно такое название? Понятное дело, ядро, Django в своих исходниках делает и всё такое... Но зайдя в такой проект, сразу ли будет понятно за что отвечает это приложение? Нет. В общем-то даже в документации к Django в quick start название приложения опирается на её главную бизнес-потребность.

Переходим к следующему: папка apps с приложениями. Для начала вроде всё удобно и логично: есть ядро проекта, а есть дополнения к нему а значит их нужно как-то отделить от этого ядра. А что делать если ядро будет всегда одно в проекте? А что делать если дополнительных приложений будет всего одно? А зачем тогда ему целая папка (приложению) если само приложение - и есть папка (или модуль в нашем случае)? Так оставлять или менять уровень вложенности? На самом деле что core, что appN - являются такими же Django приложениями (одинаковыми), а значит и уровень абстракции у них - один; один уровень абстракции говорит нам о том, что и appN нужно класть где-то рядом с core (здесь должно быть другое название как и писал). Часто я вижу в проектах, что core так и остаётся одой единственной core папкой без дальнейшей расширяемости. Вывод - преждевременная оптимизация - вещь нелогичная по сути своей.

Папка template. Здесь я всегда доверяюсь Django и кладу шаблоны в папку приложения (делая ещё две папки - templates, а в ней - папку с названием приложения). Здесь, думаю, подойдёт правило класть то, что используется, ближе к тому месту, где это используется (но с поправкой на рекоммендации оф. документации Django).

Папка static. В среде отладки её быть в принципе быть не должно; обычно вся статика всегда в первую очередь связана с приложением, куда мы её и стараемся класть (как с папкой templates), что является и советом из Django документации.

Папка models. Вынося её куда-то в отличное от папки приложения место, мы сразу же забиваем на автономность самого приложения; приложение сразу же становится зависимым от внешнего кода (чего нужно избегать). Обычно каждое приложение имеет свои модели и не зависит от моделей другого приложения.

venv. Актуально только на компьютере каждого разработчика; по-моему это неудачное решение класть платформо-зависимые файлы под контроль версий.

а как тестировать крупные приложения?

Да точно также.

Как понять, что именно мне нужно покрыть тестами?

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

Ведь по логике нужный каждый кусок покрывать, чтобы быть на 100% уверенным в этом коде?

Да, но полное покрытие - это очень дорого, и часто не оправдано.

По тому, если приоложение большое, а тестов нет:
1. Покрываем самое критичное и важное, без чего просто жить нельзя, если оно поломается.
2. Покрывает то, где много изменений происходит, и есть шанс случайно поломать.
3. Покрываем всё новое, как часть реализации фичи.
4. Юнит тестами ещё есть смысл покрыть всякие общие компоненты, которые используются тупо везде.

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

А vue тут ни при чём.

Скорость света в вакууме 300,000 км/с, расстояние до Японии от Москвы по поверхности земли примерно 7500 км или 15000 км туда и обратно, что дает 50мс задержки. С учетом коэффициента преломления оптоволокна (порядка 1,5) - 75мс. Можно немного сократить, если пробурить канал напрямую вглубь земли и передавать световым пучком в вакууме без оптоволокна.

Но вместе с пингом 40мс вы все равно получите Нобелевскую премию по физике.

На самом деле каналов по прямой до Японии нет, данные идут достаточно сложным маршрутом и не в вакууме и 300мс это более-менее ожидаемый результат. Типичный маршрут для российских провайдеров - Европа - Северная Африка/Средний восток - Юго-восточная Азия - Япония. Можно поискать провайдера у которого есть пиринг с азиатскими IX минуя Европу, чтобы маршрут был "прямее", вы можете получить задержки. скажем, вдвое меньше. Прокси может быть найти сложнее, т.к. надо чтобы был прямой трафик до прокси и от прокси. Имеет смысл посмотреть в точки где может быть пиринг с европейской Россией и Азией, например наш дальний восток или Казахстан. Прокси в Японии скорей всего никакого преимущества не даст, нужен прокси где-то, куда есть более-менее прямой канал от вашего провайдера и откуда есть прямой канал на пиринги в Азии.
Если хотите маленький пинг - вам надо клиентский софт располагать в Японии (возможно вместе с сотрудником), а не прокси-сервер. Для высокочастотного трейдинга его располагают не просто в той же стране, где биржа, но и как можно ближе у того же провайдера или на самой бирже.