Когда решаться на Waterfall?

^^image source

Incremental & Iterative & Iterative+Incremental

Incremental подходит только в простых, ясных проектах.

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

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

Принимаем решения по архитектуре как можно позденее (Set-based design), имея множество концептов, которые мы проверяем и поддерживаем паралельно, отбрасывая отдельные, только после того, что они явно оказываются в действительной среде (где мы разрабатываем продукт/проект) не состоятельными или другие точно оказываются лучше. 

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

Класный ресурс для быстрого обмена файлами

https://transfer.sh/

Windows CMD useful commands

Calculate the size of a directory with its files tree inside:

dir /s dirname

Mob Programming

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

Парное програмирование происходит в паре, где есть две роли:
Driver - думает и реализует гипотезы через код
Obsorver - наблюдает за введенным кодом и проясняет, что необходимо

В Mob Programming добавляется еще одна роль и проиходят изменения в обязанностях ролей Driver и Obsorver:
Navigator - думает над решением и говорит водителю, что и как кодировать вплоть до директивного указания: строка, переменная.
Driver - выступает в роли smart imput device: выполняет строго то, что говорят, не думает как лучше и не спорит с видиньем штурмана
Obsorver - наблюдает молча за введенным кодом, и думает про дальнейшие шаги в решении

Эта модель возможна от 3х человек в команде. Водитель всегда один. Штурманов может быть несколько, но чаще один, который обращается к другим, когда в чем-то не уверен или ему нужно обратиться к областям знаний, которых у него нет. Наблюдателей может быть много.

Доступ во внешнюю Web UI of Kubernetes

Скорее всего админ поддерживаемого кластера скинет файл config для ~/.kube/ как первый шаг для доступа к кластеру кубера. Если с текущей локальной машины приходится работать только с одним кластером, значит больше никаких танцев делать не нужно. Если приходится работать со многими, то тогда нужно переименовать файл на имя кластера и работать с дополнительным ключем --kubeconfig=[CLUSTER_NAME] в командах.

Обычно, в первую очередь Web UI защищается от внешнего мира basic http auth. В файле ~/.kube/config можно найти креденшиалсы.

Далее будет предложен вариант авторизации либо через Kubeconfig файл либо через Token.
Чтобы достать токен для админа для такого логина, запускаем следующую команду:

$ kubectl  -n kube-system describe secret $(kubectl -n kube-system get secret | grep admin-user | awk '{print $1}')

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

electronjs

https://electronjs.org/ - платформа для кросплатформенной разработки десктопных UI приложений