Ума не приложу как раньше люди жили без блокчейна? Где деньги брали, как зарабатывали? Без ИИ?

Сейчас ИИ всё напишет как надо, остаётся только контролировать, денежные потоки перенаправлять...

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

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

Естественно, а что были еще какие-то сомнения?

Это помошник а не решатель

А мне ответ подходит

---

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

Прогнозы, непосредственно связанные с потерей арктического морского льда и потеплением в Арктике (на что указывает график):

1. Ускоренное потепление в Арктике (Арктическое усиление):
   • Прогноз: Арктика будет продолжать нагреваться в 2-4 раза быстрее, чем в среднем по планете.
   • Механизм: Меньше льда означает меньше отраженного солнечного света (ниже альбедо) и больше тепла, поглощаемого более темным океаном, что создает положительную обратную связь. Это явно проявляется, когда мы видим постоянно низкие объемы льда.
2. Воздействие на арктические экосистемы и коренные народы:
   • Прогноз: Серьезные нарушения морских и наземных экосистем Арктики.
   • Примеры: Потеря охотничьих платформ для белых медведей и тюленей; изменения в миграционных путях рыб; стресс для моржей и других видов, зависящих ото льда. Традиционный образ жизни коренных народов, зависящий от стабильного льда и предсказуемых условий, будет все больше подвергаться угрозе.
3. Таяние вечной мерзлоты:
   • Прогноз: Усиление таяния вечной мерзлоты (многолетнемерзлых пород) в Арктике.
   • Последствия: Высвобождение мощных парниковых газов (углекислого газа и метана), заключенных в мерзлой почве, что еще больше ускорит глобальное потепление (еще одна петля обратной связи). Повреждение инфраструктуры (зданий, дорог, трубопроводов), построенной на вечной мерзлоте.
4. Открытие арктических морских путей и добыча ресурсов:
   • Прогноз: Повышение доступности Северного Ледовитого океана для судоходства и добычи ресурсов (нефть, газ, полезные ископаемые).
   • Последствия: Потенциальные экономические выгоды для некоторых, но также значительные экологические риски (разливы нефти, загрязнение, нарушение морской жизни) и геополитическая напряженность.

Более широкие глобальные прогнозы, обусловленные общей тенденцией потепления, которую отражает потеря арктического льда:

1. Глобальное повышение уровня моря:
   • Прогноз: Продолжающееся и потенциально ускоренное повышение уровня моря.
   • Механизм: Хотя таяние самого морского льда существенно не повышает уровень моря (он уже вытесняет воду), общая тенденция потепления, вызывающая потерю морского льда, также приводит к таянию материкового льда (ледников, ледниковых щитов Гренландии и Антарктиды) и вызывает тепловое расширение океанской воды. Потеря отражающего морского льда способствует этому общему потеплению.
   • Последствия: Береговая эрозия, усиление наводнений, проникновение соленой воды в пресноводные источники, перемещение прибрежного населения.
2. Изменения погодных условий и экстремальные погодные явления:
   • Прогноз: Более частые и интенсивные экстремальные погодные явления по всему миру.
   • Механизм: Быстрое потепление Арктики может нарушить атмосферные циркуляционные паттерны, включая струйное течение. Это может привести к более устойчивым погодным условиям, таким как продолжительные волны жары, засухи в одних регионах и сильные дожди или несезонные похолодания в других.
   • Примеры: Более интенсивные ураганы/циклоны (из-за более теплых океанских вод), сильные засухи, разрушительные наводнения, интенсивные волны жары.
3. Закисление океана:
   • Прогноз: Продолжающееся увеличение кислотности океана.
   • Механизм: Основным фактором глобального потепления и потери арктического льда является увеличение содержания CO2 в атмосфере. Значительная часть этого CO2 поглощается океанами, образуя угольную кислоту.
   • Последствия: Ущерб морским организмам с раковинами из карбоната кальция (кораллы, моллюски, некоторый планктон), что нарушает морские пищевые цепи.
4. Воздействие на глобальное биоразнообразие:
   • Прогноз: Значительная нагрузка на экосистемы по всему миру, ведущая к миграции видов, проблемам с адаптацией и вымиранию.
   • Механизм: Быстрое изменение климата опережает способность многих видов адаптироваться или перемещаться в более подходящие места обитания.
5. Воздействие на здоровье человека:
   • Прогноз: Увеличение рисков для здоровья.
   • Примеры: Тепловой стресс от волн жары, респираторные заболевания из-за ухудшения качества воздуха (например, от лесных пожаров, которые также связаны с изменением климата), распространение трансмиссивных заболеваний (поскольку насекомые перемещаются в новые районы), воздействие на психическое здоровье.
6. Проблемы с продовольственной и водной безопасностью:
   • Прогноз: Увеличение рисков для продовольственной и водной безопасности во многих регионах.
   • Механизм: Изменения температуры и режима осадков, увеличение засух и наводнений, а также воздействие на опылителей могут нарушить сельское хозяйство. Таяние ледников может угрожать запасам пресной воды для миллионов людей.

Важные соображения:

• Петли обратной связи: Многие из этих прогнозов включают петли обратной связи (такие как арктическое усиление и таяние вечной мерзлоты), которые могут ускорить изменения.
• Переломные моменты (точки невозврата): Существует опасение, что некоторые земные системы могут достичь переломных моментов, за которыми изменения станут самоподдерживающимися и их будет гораздо труднее обратить вспять. Потеря летнего морского льда в Арктике считается одним из таких потенциальных переломных моментов.
• Действия человека – ключ к решению: Эти прогнозы не являются неизбежными, если будут предприняты значительные и быстрые действия по сокращению выбросов парниковых газов и адаптации к уже происходящим изменениям. Будущая траектория сильно зависит от глобальной политики, технологических инноваций и общественных выборов.

График арктического морского льда – это суровое визуальное напоминание о том, что климатическая система нашей планеты претерпевает быстрые изменения с далеко идущими последствиями.

Пообсуждаем?

Не вижу что обсуждать, отрицательных последствий больше чем положительных и вообще не уверен, что это будет работать

Что мешает писать тестовые методы прямо под тем методом, который тестируешь?

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

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

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

Историю можно конечно разбавить играющими красками и преданностью элитам, не спящим ночами и придумывающим новые NFT и 3D spiele. Однако мне до сих пор непонятно, до какой поры Барсика будут терзать крепкими выражениями, ведь он является охранником окружающей среды и выбросов СО2;)

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

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

Меняем!

Ну чё, поменял?

Не вижу что обсуждать, отрицательных последствий больше чем положительных и вообще не уверен, что это будет работать

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

NUnit

у него есть неприятная особенность. Тесты по одному выполняются, а в параллель, довольно часто нет.

Попробуйте xUnit и FluentAssertions - жизнь сразу покажется лучше

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

Ну можно вынести тесты в partial :)

Почему тесты следует выносить не просто в другие классы, а в другие проекты/сборки:

1) не стоит нагружать классы ненужной логикой (S из SOLID :D).

2) вынося тесты в другой проект убирается соблазн вызвать какой-нибудь "тестовый" метод из продуктивного кода (например какую-нибудь инициализацию)

3) у конечного продукта нет зависимости от сторонних библиотек (а значит их не надо устанавливать на клиентской машине, не надо объяснять клиенту что это за библиотеки, не надо следить за лицензиями, меньше потенциальных конфликтов итд)

4) меньше размер конечного софта (сейчас уже не так актуально... но разница в пару сотен МБ вполне может быть)

Это первое, что пришло в голову.

1) не стоит нагружать классы ненужной логикой (S из SOLID :D).

А TDD говорит, что всё должно быть вокруг тестов - они главнее логики. Так что нагружай свои классы тестовыми атрибутами и не жужжи. ))

3) у конечного продукта нет зависимости от сторонних библиотек (а значит их не надо устанавливать на клиентской машине, не надо объяснять клиенту что это за библиотеки, не надо следить за лицензиями, меньше потенциальных конфликтов итд)

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

Как-то давно, в одной крутой новосибирской конторе, лидере своего рынка и всё такое, все классы были атрибутами обвешаны. Местный гуру-архитектор, по совместительству недавний 23-летний сеньёр, выучил новую фичу и пихал её везде. ))

Это первое, что пришло в голову.

Когда такое случается, сразу забывайте и выкидывайте из головы. )))

А TDD говорит, что всё должно быть вокруг тестов - они главнее логики.

Ничего подобного TDD не говорит :) Это твоя (неправильная) интерпретация ;)

Так что нагружай свои классы тестовыми атрибутами и не жужжи.

Опять ерунда :) Я вообще не понимаю как ты остаешься в профессии с такими познаниями?

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

Во-первых, далеко не «один хрен». Я видел продукты, в которых клиент на атомы разбирал каждую поставляемую библиотеку.

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

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

Опять ерунда :) Я вообще не понимаю как ты остаешься в профессии с такими познаниями?

А команды не договариваются о библиотеках? В общей репе контроля либ и их версий нет?

А команды не договариваются о библиотеках? В общей репе контроля либ и их версий нет?

А зачем независимым друг от друга командам выстраивать какие-то ненужные зависимости?

Да и репы у них могут быть разные. Да что там репы, вся инфраструктура и процессы ci, di, релизы - все может быть разное. Команды могут быть в разных юридических лицах на разных континентах

Ну ладно вам то зачем вмешиваться если свое системы так и не придумали и пользуетесь либо одним либо другим пилотом?

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

Интерпретация процессов, на самом деле не имеющих друг с другом ничего общего и различающихся по уровню ЗП значительна. Это я про Pocco с нулевой маржей а то и в минусе, не лучше какой то фабрики медикаментов или больницы....напоминает процессы в батареях проходящих 30 процентов leerlauf.

А команды не договариваются о библиотеках? В общей репе контроля либ и их версий нет?

А зачем независимым друг от друга командам выстраивать какие-то ненужные зависимости?
Да и репы у них могут быть разные. Да что там репы, вся инфраструктура и процессы ci, di, релизы - все может быть разное. Команды могут быть в разных юридических лицах на разных континентах

Команды настолько независимы, что не контролируют, какие версии библиотек и вообще какие библиотеки при разработке одного продукта использюут? А как они вообще стыкуют результаты своего труда?

Команды настолько независимы, что не контролируют, какие версии библиотек и вообще какие библиотеки при разработке одного продуктаиспользюут? А как они вообще стыкуют результаты своего труда?

:) по принципу пазла.

Давай для примера возьмем MVVM модель. Теоретически, такой продукт могут разрабатывать 3 команды. При это View и Model вообще никак не пересекаются. Да собственно говоря в даже с ViewModel нужно договориться только на абстрактном уровне. А дальше просто копируешь 3 дллки в одну папочку (тут есть 2 решения: 1) договориться чтобы имена файлов не конфликтовали или 2) на стадии установки давать файлам случайные имена, а нужный модуль будет сам искать необходимое) и все работает (инсталлятор, конечно, должен знать зависимости и уметь их устанавливать). Короче говоря, команда делает свою часть и кладет ее на «полочку», а менеджер потом собирает эти части в конечный продукт.

PS: не говори, что такое невозможно , тк я принимал участие в создании такой инфраструктуры :) и это реально очень круто работает особенно в крупных проектах, где куча маленьких команд делают один большой и сложный продукт

Т.е. есть кто-то или что-то, кто разгребает всё дерьмо. Ну, значит он сможет разгрести и кучу атрибутов в моём коде. А значит, что я могу писать так, как мне удобно. Так получается.

Единственное, что не пойму

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

Это такая самоцель - всё делать самим? Ну, если клиент платит за изобретение велосипедов и даёт дополнительное время, то можно попробовать.

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

Т.е. есть кто-то или что-то, кто разгребает всё дерьмо.

Кто дерьмо создал, тот его и разгребает :)

Ну, значит он сможет разгрести и кучу атрибутов в моём коде. А значит, что я могу писать так, как мне удобно. Так получается.

За свой код отвечаешь ты и только ты. Ну точнее не "ты", а "твоя команда"... ну скажем человек 3-10 разработчиков (мы же говорим о большом проекте, а не о хэлло ворде).

Так что сначала за кучу атрибутов тебе оторвут руки твои коллеги :)

Это такая самоцель - всё делать самим? Ну, если клиент платит за изобретение велосипедов и даёт дополнительное время, то можно попробовать.

Что значит "все делать самим"?

Разработчики делают свою часть и указывают все зависимости. Зачем это это делается? - чтобы 1) можно было избегать конфликтов и 2) чтобы конечные пользователи знали что у них установлено. Грубо говоря, если твой софт работает на оракле, то клиент должен не только купить твой софт, но и лицензию оракла. Или может оказаться так, что ты решил использовать какую-нибудь бесплатную библиотеку, которую запрещено использовать в коммерческом софте. Или пару лет назад была большая проблема с log4net'ом. Или еще 100500 тонкостей. Конечные пользозователи должны знать что у них устанавливается, какие версии и какие лицензии.