отличается сломом привычного темпа и графика работы в команде. Внезапно меняются часы работы, сбиваются митинги, зачастую увеличивается время всевозможных согласований.
Плюс все понимают, что человек там больше отдыхает, чем работает, поэтому стараются не беспокоить, если не сильно важно.
(дисклеймер - у нас официальных воркейшнов нет, но практикуется "задержаться в отпуске" или "съездить на родину по семейным обстоятельствам")
У меня скорее складывается подозрение, что у вас ошибочное представление о том, что такое required и зачем он нужен.
В новых проектах, возможно, контракты на обязательность (кроме DTO) будут через required. А может быть так и останемся во тьме конструкторов с параметрами и прочими фабриками вместо продвинутого ключевого слова. "There are different ways to skin a cat", как говорит мой коллега.
Все еще непонятно, причем тут какая-то валидация. Ключевое слово required вообще с ней никак не связано.
Про валидацию, - потому, что речь о DTO. Проверка атрибута [required] - часть процесса валидации. Смысл там такой же, как и у ключевого слова required - убедиться, что клиент предоставит значение для обозначенного поля. Но атрибут более стандартный, поэтому для нашего ASP.NET API мы использовали его.
Но ведь с required конструктор всё еще запросто может быть без параметров. Что я не так понял в вашем сообщении?
Снова непонятно. Вы осознанно поощряете отсутствие инициализации некоторых полей, но введение required, которое вам бы прогарантировало исправление данной ситуации, вы называете "не готовы менять логику" — т.е. по факту не готовы вручную проинициализировать все пропущенные поля, и сиё утверждение считаете достаточным аргументом против required? Всё так понял, или я снова затупил?
вы так эмоционально не понимаете, будто я вас убеждаю отказаться от использования required в вашем коде.
Когда это ключевое слово ввели, у нас было уже написано очень много кода и все классы, где поля обязаны инициализироваться клиентом имели соответствующие конструкторы. Была мысль использовать его шире, убрав инициализацию в null not nullable fields and properties, но это требовало менять инициализацию в куче мест. И да, для нас это было достаточным аргументом не внедрять эту фичу языка в существующий проект.
required в DTO даже не думали. У нас вся валидация через атрибуты. (DTO используется только API на базе ASP.NET). Интересно, если required поле не было в приходящем json объекте, ASP.NET возвращает такой же 400 bad request с пропущенным полем, как и с [Required] атрибутом? Хлопоты, про которые я говорил - накладываемые ограничения, типа конструктора без параметров. Мы хотели убрать null! инициализацию для not nullable properties, но оказались не готовы для этого менять логику.
Не, ну инструмент интересный, спасибо. Вспомнил про PostSharp, который когда-то пользовался, зашел к ним, а оказалось, что Metalama это их детище! ) Тогда понятно, как получился такой (судя по всему) хороший продукт.
Metalama работает на этапе компиляции, генерируя C#-код, который можно увидеть, отладить и понять без степени в компьютерной магии.
А насколько близко к "классическому подходу" получается сгенерированный код? И как его найти? Если, скажем, я нахожусь в исходном методе с аспектным атрибутом.
всегдашные выводы молодых, которым кажется, что их не понимают и "они не такие". Конечно, они не такие, - они молодые. Ну так и мы были молодыми и многие точно так же не желали "быть как они" и ратовали за свои интересы. И точно так же на нас ворчали и упрекали в "отсутствии пиетета к старшим" (цитата моего начальника в 2000).
короче я как-то не вижу большой разницы между мной тогда и нынешними двадцатилетними стажёрами с которыми работаю и общий язык найти совсем не трудно.
В мотивационную часть я бы добавил, что в перспективе, учитывая текущий тренд, C# выйдет за пределы классического компилируемого ЯП и зайдёт в нишу скриптов. Что сильно расширяет проф. горизонт. Уже сейчас можно просто "выполнить скрипт" dotnet run script.cs - не нужен ни проект, ни среда разработки, только SDK.
А то и просто выполнять команды прямо в консоле (пока правда через установку, например, https://github.com/waf/CSharpRepl ). Классная, кстати, вещь и легко добавляется в терминал для удобного запуска.
Спасибо за статью. А я-то грешил, что LLM меня не понимает из за потенциального конфликта в подробных инструкциях. Вроде бы всё разжевано, да с примерами, а в результате - совершенно неправильный ответ. Мысли поискать "а не системная ли это проблема?" почему-то даже не возникло... Впрочем в итоге всё равно пришел примерно к тем же выводам и принципу "говорить коротко, и по существу".
(если не ошибаюсь, идею тут же на Хабре и подглядел. Давно правда, еще до ковида)
А на этих праздниках (у нас они правда уже кончились) решил сделать озвучалку текстов. Сейчас ИИ наговаривают текст вполне прилично. Я решил попробовать озвучить книжку, но готовые решения, дали весьма посредственный результат. Ударения в русском языке - это тот еще прикол. Опять же не все книги "ё-фицированны" Вот и вылилась идея в небольшой проект для двух-этапной озвучке. Ё-фикация + омографы на основе словарей через и выбор через LLM агента на основе контекста предложения, затем разметка в SSML и уже потом - начитка через Azure speech service.
Так Канада разная, как любая другая большая страна. в Торонто - свои приколы, у нас в Монреале - свои.
Общее охлаждение рынка, наверное есть, но не всё так ужасно. Друге дело, что первую работу найти было всегда трудно. Плюс согласно официальной статистики условные 80% вакансий закрываются через знакомства. И это не считается проблемой, наоборот, компании платят за "приведи друга". Поэтому да, если чувак из поклонников Шамана, вряд ли он найдёт работу через знакомых. Таких упоротых тут крайне мало.
людям проще общаться на родном языке с представителями своей/близкой культуры. Эта проблема есть, и далеко не только в РФ. Кто-то с ней мирится, кто-то борется, кто-то игнорирует.
я за 15 лет работы в 6 разных канадских/американских компаниях встречался и с бытовым расизмом (когда нанимающий менеджер в команду брал только "своих") и с обратной дискриминацией (когда целенаправленно искали женщину - программиста).
мне лично наплевать на то ещё живёт сотрудник, какой он национальности, какую религию исповедует и какая у него сексуальная ориентация (остальным моим коллегам и начальству тоже наплевать).
а откуда вы знаете их пол, возраст, религию и ориентацию?
Но я о том, что для вакансий с полной удаленной без географических ограничений, почти со стопроцентной гарантией будет выбран кандидат из юва, и скорее всего из Индии - это объективная реальность
если допустить, что ваша компания будет процветать и нанимать людей достаточно долго, то в конце концов она будет состоять полностью из индусов...
мой самый большой соблазн - использовать ИИ для реализации. Ну в смысле придумать алгоритм, а код пусть ко-пилот пишет. Типа так-то задачку "сам решил" )
Интересно, а в каких случаях SQL может наоборот дать преимущество при решении задачи? Скажем если входные данные - двумерный массив (день 4, 6 и 7 на текущий момент)? Можно ли как-то эффективно делать в SQL обход "2D лабиринта"?
Большой вопрос к вам, читатели: пробовали ли вы когда-нибудь переписать современную задачу методами, которым вас учили в начале двухтысячных?
Вот через недельку начинается Advent of Code 2025 ( adventofcode.com ) вот там - и чему учили вспоминать придется и новому учиться.
А на рабочих проектах (у ремесленников, коих среди программистов большинство нынче) алгоритмы скорее исключение, чем правило. Пару раз сам писал (типа оптимизации распределения ресурсов по куче входных параметров - было очень интересно), пару раз чужие "велосипеды" ремонтировал - куда менее интересно, если помягче сказать. Но обычно - сперва смотришь "стандартные" библиотеки, потом "популярные", а потом принимаешь решение, нужен ли новый велосипед.
главное "потому, что" - это статичность задачи. Рассчитали радиационную защиту, - никто назавтра не придет и не скажет включить в защитный контур наводнения, землетрясения и ураганы. Причем запросы будут не сразу, а постепенно. И потом еще уточнения, типа затопление не водой, а канализацией. В коммерческой разработке не зря стали популярными всевозможные методологии основанные на цикличности. И управлять проще и сроки прогнозировать.
отличается сломом привычного темпа и графика работы в команде. Внезапно меняются часы работы, сбиваются митинги, зачастую увеличивается время всевозможных согласований.
Плюс все понимают, что человек там больше отдыхает, чем работает, поэтому стараются не беспокоить, если не сильно важно.
(дисклеймер - у нас официальных воркейшнов нет, но практикуется "задержаться в отпуске" или "съездить на родину по семейным обстоятельствам")
В новых проектах, возможно, контракты на обязательность (кроме DTO) будут через
required. А может быть так и останемся во тьме конструкторов с параметрами и прочими фабриками вместо продвинутого ключевого слова. "There are different ways to skin a cat", как говорит мой коллега.Про валидацию, - потому, что речь о DTO. Проверка атрибута
[required]- часть процесса валидации. Смысл там такой же, как и у ключевого словаrequired- убедиться, что клиент предоставит значение для обозначенного поля. Но атрибут более стандартный, поэтому для нашего ASP.NET API мы использовали его.вы так эмоционально не понимаете, будто я вас убеждаю отказаться от использования
requiredв вашем коде.Когда это ключевое слово ввели, у нас было уже написано очень много кода и все классы, где поля обязаны инициализироваться клиентом имели соответствующие конструкторы. Была мысль использовать его шире, убрав инициализацию в
nullnot nullable fields and properties, но это требовало менять инициализацию в куче мест. И да, для нас это было достаточным аргументом не внедрять эту фичу языка в существующий проект.как пример - вы допускаете установку поля в null, но хотите избежать случайного обнуления (когда поле просто случайно опущено).
required в DTO даже не думали. У нас вся валидация через атрибуты. (DTO используется только API на базе ASP.NET). Интересно, если required поле не было в приходящем json объекте, ASP.NET возвращает такой же 400 bad request с пропущенным полем, как и с [Required] атрибутом?
Хлопоты, про которые я говорил - накладываемые ограничения, типа конструктора без параметров. Мы хотели убрать
null!инициализацию для not nullable properties, но оказались не готовы для этого менять логику.Не, ну инструмент интересный, спасибо. Вспомнил про PostSharp, который когда-то пользовался, зашел к ним, а оказалось, что Metalama это их детище! ) Тогда понятно, как получился такой (судя по всему) хороший продукт.
А насколько близко к "классическому подходу" получается сгенерированный код? И как его найти? Если, скажем, я нахожусь в исходном методе с аспектным атрибутом.
буммеры/зуммеры/шумеры...
всегдашные выводы молодых, которым кажется, что их не понимают и "они не такие". Конечно, они не такие, - они молодые. Ну так и мы были молодыми и многие точно так же не желали "быть как они" и ратовали за свои интересы. И точно так же на нас ворчали и упрекали в "отсутствии пиетета к старшим" (цитата моего начальника в 2000).
короче я как-то не вижу большой разницы между мной тогда и нынешними двадцатилетними стажёрами с которыми работаю и общий язык найти совсем не трудно.
Это не нюанс, это нюансище. Чтоб опущенный параметр для всяких Int или Guid выкидывал ошибку валидации, а не инициализировался "по умолчанию".
Мы в конце концов практически отказались от него. Хлопот больше, чем реальной пользы.
а как много у вас команд/людей в них и как часто бывают пуши? Не накладно индексировать при каждом разе? Особенно если не только мастер-бренч...
за идею, кстати, спасибо, надо будет подумать о вариантах.
В мотивационную часть я бы добавил, что в перспективе, учитывая текущий тренд, C# выйдет за пределы классического компилируемого ЯП и зайдёт в нишу скриптов. Что сильно расширяет проф. горизонт.
Уже сейчас можно просто "выполнить скрипт"
dotnet run script.cs- не нужен ни проект, ни среда разработки, только SDK.А то и просто выполнять команды прямо в консоле (пока правда через установку, например, https://github.com/waf/CSharpRepl ). Классная, кстати, вещь и легко добавляется в терминал для удобного запуска.
Спасибо за статью. А я-то грешил, что LLM меня не понимает из за потенциального конфликта в подробных инструкциях. Вроде бы всё разжевано, да с примерами, а в результате - совершенно неправильный ответ. Мысли поискать "а не системная ли это проблема?" почему-то даже не возникло...
Впрочем в итоге всё равно пришел примерно к тем же выводам и принципу "говорить коротко, и по существу".
Мне когда-то зашло сделать свой полётный трекер на базе raspberry pi. Это и интересно, и даёт понимание, как работают системы типа flight radar 24 и можно мониторить "кто тут надо мной летает" ) https://www.raspberrypi.com/tutorials/build-your-own-raspberry-pi-flight-tracker/
Плюс помимо этого, регистрация такой антенны на flight radar 24 даёт права контрибютера https://www.flightradar24.com/build-your-own
(если не ошибаюсь, идею тут же на Хабре и подглядел. Давно правда, еще до ковида)
А на этих праздниках (у нас они правда уже кончились) решил сделать озвучалку текстов. Сейчас ИИ наговаривают текст вполне прилично. Я решил попробовать озвучить книжку, но готовые решения, дали весьма посредственный результат. Ударения в русском языке - это тот еще прикол. Опять же не все книги "ё-фицированны" Вот и вылилась идея в небольшой проект для двух-этапной озвучке. Ё-фикация + омографы на основе словарей через и выбор через LLM агента на основе контекста предложения, затем разметка в SSML и уже потом - начитка через Azure speech service.
Так Канада разная, как любая другая большая страна. в Торонто - свои приколы, у нас в Монреале - свои.
Общее охлаждение рынка, наверное есть, но не всё так ужасно. Друге дело, что первую работу найти было всегда трудно. Плюс согласно официальной статистики условные 80% вакансий закрываются через знакомства. И это не считается проблемой, наоборот, компании платят за "приведи друга".
Поэтому да, если чувак из поклонников Шамана, вряд ли он найдёт работу через знакомых. Таких упоротых тут крайне мало.
людям проще общаться на родном языке с представителями своей/близкой культуры. Эта проблема есть, и далеко не только в РФ. Кто-то с ней мирится, кто-то борется, кто-то игнорирует.
я за 15 лет работы в 6 разных канадских/американских компаниях встречался и с бытовым расизмом (когда нанимающий менеджер в команду брал только "своих") и с обратной дискриминацией (когда целенаправленно искали женщину - программиста).
а откуда вы знаете их пол, возраст, религию и ориентацию?
если допустить, что ваша компания будет процветать и нанимать людей достаточно долго, то в конце концов она будет состоять полностью из индусов...
мой самый большой соблазн - использовать ИИ для реализации. Ну в смысле придумать алгоритм, а код пусть ко-пилот пишет. Типа так-то задачку "сам решил" )
ага, плюс иногда было бы интересно пообсуждать подходы. Удивительно, насколько по разному люди решают эти задачки
Интересно, а в каких случаях SQL может наоборот дать преимущество при решении задачи? Скажем если входные данные - двумерный массив (день 4, 6 и 7 на текущий момент)? Можно ли как-то эффективно делать в SQL обход "2D лабиринта"?
Вот через недельку начинается Advent of Code 2025 ( adventofcode.com ) вот там - и чему учили вспоминать придется и новому учиться.
А на рабочих проектах (у ремесленников, коих среди программистов большинство нынче) алгоритмы скорее исключение, чем правило. Пару раз сам писал (типа оптимизации распределения ресурсов по куче входных параметров - было очень интересно), пару раз чужие "велосипеды" ремонтировал - куда менее интересно, если помягче сказать. Но обычно - сперва смотришь "стандартные" библиотеки, потом "популярные", а потом принимаешь решение, нужен ли новый велосипед.
главное "потому, что" - это статичность задачи. Рассчитали радиационную защиту, - никто назавтра не придет и не скажет включить в защитный контур наводнения, землетрясения и ураганы. Причем запросы будут не сразу, а постепенно. И потом еще уточнения, типа затопление не водой, а канализацией.
В коммерческой разработке не зря стали популярными всевозможные методологии основанные на цикличности. И управлять проще и сроки прогнозировать.