Типичная работа, допустим, на 95% состоит из простой рутины, а, условно, оставшиеся 5% - из поиска неочевидных проблем/внедрения чего-то нового, что требует некоторой эрудиции и глубины знаний. Позиция звучит так, будто вопросы, актуальные для этх 5% не относятся к "реальной вакансии". Но ведь и эту часть работы тоже необходимо выполнять.
Адаптация подвела. Оригинальная книга опирается на Java 7-, до появления Optional<T>, сейчас этот совет звучал бы иначе. А в C# совет тоже работал, но потерял актуальность с недавних пор - завезли свой эрзац-optional в виде признака нуллабельности референсных типов.
Тем не менее, NRE - это однозначное зло, допускать их появление (полагаться на них, как на ассерт, к примеру)- плохая идея.
Плюсов много, да, но не соглашусь, что решение идеально.
Объединение нескольких (списков типов/discriminated unions) ошибок в единственный тип при пробросе ошибок наверх - это боль и туча бойлерплейта маппинга типов, а рефакторинг в таких условиях - дабл-боль. А если еще и вручную проверку результата нужно делать (отстствует аналог растового ?) - трипл-боль, код раздувается огромным количеством шума чуть ли не в разы (получи результат => проверь результат и подними ошибку => распакуй результат).
Обработка исключений этих проблем лишина, т.к. появляется только там, где это имеет смысл, никаких обвязок для проталкивания ошибки наверх и "запаковки типов" не нужно => нет кода - нет и необходимости его поддерживать.
Не возвращайте null! Это источник NullReferenceException ... используйте Nullable для значимых типов, применяйте паттерн Null Object.
Скорее всего подразумевалось противопоставление: "НЕ используйте Nullable, а применяйте паттерн Null Object".
Так же в контексте C# хотелось бы оговорки про nullability.
Используйте исключения, а не коды ошибок.
Все чаще встречаю проекты, где тем или иным образом пытаются делать свои решения в стиле растового Result<TResult, TErr> для обработки возможных/ожидаемых ошибок, а исключения - оставлять лишь фатальным, которые ловить сильно выше с целью только залоггировать. Как ни крути, но исключения - это дорогое удовольствие, подход Errors are values идет в массы.
Индустрия методом проб и ошибок рождает решения, совершенствуется. Очень часто случается, что сценарий использования не совпадает с идеями, на которыми инструмент создавался. На каждом углу трубят, что для каждой задачи - свой инструмент, так как же понять границы применимости и сильные/слабые стороны, если все время не шатать их обсуждением опыта с коллегами? Каждый такой наброс - это приглашение к дискуссии, проверка гипотезы.
Но тут интересно другое:
грязью облить
почему хейт инструмента скорбляет вас лично? Или вы глубоко в душе сами боитесь найти несокрушимый аргумент, разочароваться и пожалеть о том, сколько сил и времени вложили?😉
Используя программу Putty и предоставленные IP адрес и пароль, нужно войти на сервер
Как насчет перевода SSH логина на ключи? Вроде и само собой разумеющееся действие, но инструкция претендует на подробность, а о такой важной штуке ни слова.
"есть csv с такими-то столбцами, надо ее загрузить, отфильтровать, перевернуть и выгрузить в json"
Функционал вряд ли будет висеть в воздухе - его надо будет интегрировать в существующую кодовую базу, что резко поднимает сложность задачи для нейронки.
сейчас проще не поручать
Даже в стирильных условиях кому-то придется проверять выхлоп и допиливать при необходимости.
Поэтому как раз проще рассматривать нейронку - как инструмент в руках человека, а не как автономный заменитель человека.
перед этим обязательно выполним очистку кэша докера через команду: docker system prune -a
Чтобы наверняка - можно еще винды переустановить Должно быть достаточно:
docker compose build --no-cache
перед стартом, чтобы гарантировано получить полностью новые latest-образы сервисов (или сервиса, передав его имя последним аргументом), которые подтянутся при создании новых контейнеров.
нет никакой надобности делать класс "Договор" с методом "Подписать" и другими методами, которые пытаются имитировать действия над договором в реальном мире
Такая необходимость - это работа с требованиями. Гораздо проще жить имея бизнес-слой, который со стороны вызовов будет читаться по буквам требований, а под капотом - осуществлять привязку к технической реальности, вроде схемы БД.
std.stdio.write - шаблонная функция, полагаю, вам намекают на статический полиморфизм. Кстати, в том же C# компилятор умеет делать мономорфизацию для аргументов-типов в дженериках с where T: struct, что позволяет обходиться без боксинга для значимых типов.
Если не отменяет, то комментарий выше не потерял актуальность.
Ну почему же коней, вы выше сами предлагали отталкиваться от вакансии, а теперь почему-то - от кандидата.
Типичная работа, допустим, на 95% состоит из простой рутины, а, условно, оставшиеся 5% - из поиска неочевидных проблем/внедрения чего-то нового, что требует некоторой эрудиции и глубины знаний. Позиция звучит так, будто вопросы, актуальные для этх 5% не относятся к "реальной вакансии". Но ведь и эту часть работы тоже необходимо выполнять.
Адаптация подвела. Оригинальная книга опирается на Java 7-, до появления
Optional<T>, сейчас этот совет звучал бы иначе. А в C# совет тоже работал, но потерял актуальность с недавних пор - завезли свой эрзац-optional в виде признака нуллабельности референсных типов.Тем не менее, NRE - это однозначное зло, допускать их появление (полагаться на них, как на ассерт, к примеру)- плохая идея.
Плюсов много, да, но не соглашусь, что решение идеально.
Объединение нескольких (списков типов/discriminated unions) ошибок в единственный тип при пробросе ошибок наверх - это боль и туча бойлерплейта маппинга типов, а рефакторинг в таких условиях - дабл-боль. А если еще и вручную проверку результата нужно делать (отстствует аналог растового
?) - трипл-боль, код раздувается огромным количеством шума чуть ли не в разы (получи результат => проверь результат и подними ошибку => распакуй результат).Обработка исключений этих проблем лишина, т.к. появляется только там, где это имеет смысл, никаких обвязок для проталкивания ошибки наверх и "запаковки типов" не нужно => нет кода - нет и необходимости его поддерживать.
Скорее всего подразумевалось противопоставление: "НЕ используйте Nullable, а применяйте паттерн Null Object".
Так же в контексте C# хотелось бы оговорки про nullability.
Все чаще встречаю проекты, где тем или иным образом пытаются делать свои решения в стиле растового
Result<TResult, TErr>для обработки возможных/ожидаемых ошибок, а исключения - оставлять лишь фатальным, которые ловить сильно выше с целью только залоггировать. Как ни крути, но исключения - это дорогое удовольствие, подход Errors are values идет в массы.В Rust есть делегирование ошибок (оператор
?и трейтFrom<T>к нему), что позволяет держать happy path таким же чистым, как с исключениями.Индустрия методом проб и ошибок рождает решения, совершенствуется. Очень часто случается, что сценарий использования не совпадает с идеями, на которыми инструмент создавался. На каждом углу трубят, что для каждой задачи - свой инструмент, так как же понять границы применимости и сильные/слабые стороны, если все время не шатать их обсуждением опыта с коллегами? Каждый такой наброс - это приглашение к дискуссии, проверка гипотезы.
Но тут интересно другое:
почему хейт инструмента скорбляет вас лично? Или вы глубоко в душе сами боитесь найти несокрушимый аргумент, разочароваться и пожалеть о том, сколько сил и времени вложили?😉
Как насчет перевода SSH логина на ключи? Вроде и само собой разумеющееся действие, но инструкция претендует на подробность, а о такой важной штуке ни слова.
Функционал вряд ли будет висеть в воздухе - его надо будет интегрировать в существующую кодовую базу, что резко поднимает сложность задачи для нейронки.
Даже в стирильных условиях кому-то придется проверять выхлоп и допиливать при необходимости.
Поэтому как раз проще рассматривать нейронку - как инструмент в руках человека, а не как автономный заменитель человека.
Зачем с ними совмещаться? Добровольно-принудительно мигрировать в сторону ODF.
И огребите неочевидных проблем от чего-то вроде файлов с пробелами в именах.
И не режиссер.
Чтобы наверняка - можно еще винды переустановитьДолжно быть достаточно:перед стартом, чтобы гарантировано получить полностью новые latest-образы сервисов (или сервиса, передав его имя последним аргументом), которые подтянутся при создании новых контейнеров.
А это уже не проблема или ограничение C#. Если надо - кладите структуру в другую структуру и в Span/stackalloc, язык это позволяет.
Такая необходимость - это работа с требованиями. Гораздо проще жить имея бизнес-слой, который со стороны вызовов будет читаться по буквам требований, а под капотом - осуществлять привязку к технической реальности, вроде схемы БД.
std.stdio.write- шаблонная функция, полагаю, вам намекают на статический полиморфизм. Кстати, в том же C# компилятор умеет делать мономорфизацию для аргументов-типов в дженериках сwhere T: struct, что позволяет обходиться без боксинга для значимых типов.Это сработает на этапе JIT-компиляции, а в байткоде - честный callvirt.
Уже сделано - Web Components.
Silverlight тут стоит вспомнить тогда уже, как продолжение идеи WPF c XAML-версткой.