По совету коллег я вкатился в инвестиции с приложением одного известного банка. Тоже показывали графики, говорили о дивидендах и купонах. Тоже предлагались заманчивые реферальные программы. Как итог - часть активов заблокирована, остальные в минусе. Да и банк, к слову, хоть и не пропал, но чудит страшно - то комиссии введет грабительские, то переводы отключит, то деньги за хранение брать начнет. Как думаете, ФБР заинтересуется этим? По мне так налицо мошенническая схема!
Тоже показалось странным правило, поскольку при сравнениях с константой может приводить к yoda-стилю. Хотя далее в 38 правиле это декларируется явно, так что автор, видимо, не против. А меня от него коробит.
Мне кажется сегментированная броня была распространена именно по той причине что наклепать кучу сегментов и набрать из них броню под размер конкретного легионера, скрепив шнурами было куда проще чем подбирать соответствующую по размеру кирасу. Т.е. мускульная броня - более штучный, дорогой экземпляр, подогнанный под владельца, тогда как сегментированную можно было делать без расчета на конкретного человека.
приходится печатать универсальный загрузчик для любой модели в твою игру/программу(я нахожусь пока здесь)
Простите, но зачем? Если ответ - чтоб набраться опыта, то ок. Но как по мне разработка движка и разработка каждого отдельного компонента - это разная работа, и цели у нее разные. По мне так важно соблюдать баланс между собственной разработкой и использованием готовых решений. В частности для импорта моделей есть assimp, работающий со всеми популярными форматами. А иначе недолго до переписывания STL скатиться, что совсем далеко от написания игрового движка, и уж тем более от создания игры.
Еще вопрос - почему в случае отказа какого-то сервиса вы завершаете работу приложения? Если не прошел пинг на внешнюю зависимость не стоило ли перевести приложение в некоторое состояние, которое не проходит readiness пробу, но при этом вполне себе проходит liveness и пытается восстановить потерянное соединение? Не слишком жестко вызывать Shutdown?
На псеводокоде можно. Мне бы подошел любой С-подобный, думаю большинство разработчиков также найдут его понятым. Я в целом о подходе «от негативного сценария». Если просто сказать что есть принципы и их нужно использовать — это такое себе. Если показать что бывает когда их не используешь — будет нагляднее, имхо.
Очередная попытка объяснить принципы SOLID на пальцах. Мне кажется что самый простой способ это сделать — это показать примеры кода «ка не надо делать» и «как надо делать».
Поэтому у меня есть еще 2 оговорки в ответе: что пираты достаточно дальновидны чтоб просчитать ходы наперед, иначе все бы голосовали против: ведь чем меньше людей, тем больше достанется; и что при равной выгоде пираты голосуют одинаково.
> В случае равенства голосов кандидат может иметь решающий голос.
В случае с 2мя пиратам предлагает старший — он кандидат. Его голос решающий. Следовательно, младший не получает ничего.
Ну и вообще у вас во всех случаях учитывается голос только младшего, что странно.
Младший при любом раскладе получает 0 либо 1. Посмотрите на случай с 2мя пиратами. Там младший не получает ничего. Соответственно ему не выгодно убивать 3го пирата.
1 — пираты D и E голосуют против. Пирату B в таком случае выгоднее слить A и самому распорядиться кассой.
2 — В таком случае не самый выгодный вариант для пирата А. Ведь он может иметь больше.
3 — Исходя из этой логики и был дан ответ. Самый выгодный для всех, учитывая условия задачи.
Задача не по писхологии, задача по математике/логике.
98, и по одной получат D и E за свои голоса. Хотя непонятно как они будут голосовать, если выгода равна.
Если считать 100 монет на двоих (с конца), то D получит все, а E 0. Так что для E не вариант доводить до такого исхода.
Если на троих — будет С — 99, D — 0 и E — 1.
На четверых B — 99, C — 0, D — 1 и E — 0.
На пятерых A — 98, B — 0, C — 0, D — 1, E — 1. Так у A получается 3 голоса, а D и E все равно больше никак не получат. Хотя, если пираты не сильно дальновидны, лучше предложить монету C, а не D.
По совету коллег я вкатился в инвестиции с приложением одного известного банка. Тоже показывали графики, говорили о дивидендах и купонах. Тоже предлагались заманчивые реферальные программы. Как итог - часть активов заблокирована, остальные в минусе. Да и банк, к слову, хоть и не пропал, но чудит страшно - то комиссии введет грабительские, то переводы отключит, то деньги за хранение брать начнет. Как думаете, ФБР заинтересуется этим? По мне так налицо мошенническая схема!
Завидую количеству вашего свободного времени белой завистью.
Тоже показалось странным правило, поскольку при сравнениях с константой может приводить к yoda-стилю. Хотя далее в 38 правиле это декларируется явно, так что автор, видимо, не против. А меня от него коробит.
Проблема выбора стандарта уже решена - https://ru.wikipedia.org/wiki/Межславянский_язык
Мне кажется сегментированная броня была распространена именно по той причине что наклепать кучу сегментов и набрать из них броню под размер конкретного легионера, скрепив шнурами было куда проще чем подбирать соответствующую по размеру кирасу. Т.е. мускульная броня - более штучный, дорогой экземпляр, подогнанный под владельца, тогда как сегментированную можно было делать без расчета на конкретного человека.
Простите, но зачем? Если ответ - чтоб набраться опыта, то ок. Но как по мне разработка движка и разработка каждого отдельного компонента - это разная работа, и цели у нее разные. По мне так важно соблюдать баланс между собственной разработкой и использованием готовых решений. В частности для импорта моделей есть assimp, работающий со всеми популярными форматами.
А иначе недолго до переписывания STL скатиться, что совсем далеко от написания игрового движка, и уж тем более от создания игры.
Еще вопрос - почему в случае отказа какого-то сервиса вы завершаете работу приложения? Если не прошел пинг на внешнюю зависимость не стоило ли перевести приложение в некоторое состояние, которое не проходит readiness пробу, но при этом вполне себе проходит liveness и пытается восстановить потерянное соединение? Не слишком жестко вызывать Shutdown?
А зачем вам в (s *ServiceKeeper) release() буферизированный канал по числу сервисов, если ждете вы все равно первую ошибку только?
В случае с 2мя пиратам предлагает старший — он кандидат. Его голос решающий. Следовательно, младший не получает ничего.
Ну и вообще у вас во всех случаях учитывается голос только младшего, что странно.
2 — В таком случае не самый выгодный вариант для пирата А. Ведь он может иметь больше.
3 — Исходя из этой логики и был дан ответ. Самый выгодный для всех, учитывая условия задачи.
Задача не по писхологии, задача по математике/логике.
Если считать 100 монет на двоих (с конца), то D получит все, а E 0. Так что для E не вариант доводить до такого исхода.
Если на троих — будет С — 99, D — 0 и E — 1.
На четверых B — 99, C — 0, D — 1 и E — 0.
На пятерых A — 98, B — 0, C — 0, D — 1, E — 1. Так у A получается 3 голоса, а D и E все равно больше никак не получат. Хотя, если пираты не сильно дальновидны, лучше предложить монету C, а не D.