смесь двух языков это наоборот плохо читаемо. пишут на таком гики. пройдет время и тренд сменится. желаю вам вовремя это понять, а то останетесь как старуха у корыта из известной истории про старика и его старуху. старуха тот еще гик была.
aleks-th, английский хорош потому что это язык бизнеса, а язык бизнеса это язык объектов и действий. вот вам пример, вы можете сколько угодно придумывать с другом свой язык жестов но вас выдаст язык тела.
776166, приложение подцепляется к астериск через телефон.
мы делали так. написали свое приложение на телефон под андроид и запустили внешний скрипт на сайте, скрипт управлял телефоном. в админке менеджер нажимал отправку шаблонного текста и он улетал в ввиде смс сообщения.
звонки сперва тоже принимали через железо, все эти провода и трубки достали и подцепились к обычным телефонам.
1. SetResult не убивает поток, а всего лишь говорит потоку, завершись пожалуйста.
2. ManagedThreadId будет одинаковый так как переключения между потоками не было
3. Вам надо установить таймер чтоб увидеть гонку. Асинхронными процессами приложение не руководит поэтому точный момент вы не узнаете, будет по разному.
Егор Полянский, если выбирать схемы то рекомендую начинать с Workflow, помогает упорядочить процессы, применять стоит когда у приложения цепочка действий зависит от нескольких процессов, остальные схемы можно пока пропустить. draw.io
То что вы показали это методология разработки Contract First, где сперва работа архитектора потом работа программиста. Разработчику лучше начинать изучать методологию Code First где сперва код потом архитектура. При правильном подходе паттернов программирования код превращается в расширяемую архитектуру и поддерживать такой проект легче.
Начинать надо с изучения паттернов.
Структура проекта строится через архитектурные паттерны - почитайте луковичную архитектуру https://metanit.com/sharp/mvc5/23.1.php
выделют 3 базовые концепции, слой бизнес логики, слой приложения, слой домена.
концепций может быть больше в зависимости от приложения.
у каждой концепции есть свои фундаментальные задачи.
поначалу будет сложно понимать почему какой то класс должен быть именно там. Берите в руки ИИ и закидывайте вопросами, пока руку не набьете.
после создания шапки проекта начнете писать код- начнете задаваться вопросом что должен делает класс. какой набор методов у него длжен быть, какой набор параметров должен хранить- здесь нужно применять паттерны проектирования и порождения.
Захотите разбираться в глубинах алгоритмов изучайте паттерны поведения
Saboteur, основная моя проблема была в том что 80й порт требовалось отдать для сборки образа. В другой ветке есть описание. Сама настройка контейнера заняла пол часа. там три команды для настройки. Эти же команды так или иначе выполняются для плагинов.
Saboteur Я уже написал у каждого свои фломастеры. В моем случае не имеет смысла сорить мусор там где он не нужен. Работать с контейнерам удобнее не потому что проще а потому что вся инфраструктура в контейнерах прекрасно масштабируется как горизонтально так и вертикально. Например я могу легко подсадить порт дженкинса на https с сертификатами вывести наружу и заблокировать через SSO. Вариантов развернуться куча. В вашем случае эти грабли будут плохо поддерживаемые. И здесь не важно что рядом стоит кубер или сварм или ничего не стоит. Вопрос не в удобстве а в архитектуре.
半径 = float(input("请输入圆的半径: ")) # 半径
圆周率 = 3.14159
面积 = 圆周率 * 半径 ** 2
print(f"半径为{半径}的圆的面积是: {面积:.2f}")
смесь двух языков это наоборот плохо читаемо. пишут на таком гики. пройдет время и тренд сменится. желаю вам вовремя это понять, а то останетесь как старуха у корыта из известной истории про старика и его старуху. старуха тот еще гик была.