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 ) вот там - и чему учили вспоминать придется и новому учиться.
А на рабочих проектах (у ремесленников, коих среди программистов большинство нынче) алгоритмы скорее исключение, чем правило. Пару раз сам писал (типа оптимизации распределения ресурсов по куче входных параметров - было очень интересно), пару раз чужие "велосипеды" ремонтировал - куда менее интересно, если помягче сказать. Но обычно - сперва смотришь "стандартные" библиотеки, потом "популярные", а потом принимаешь решение, нужен ли новый велосипед.
главное "потому, что" - это статичность задачи. Рассчитали радиационную защиту, - никто назавтра не придет и не скажет включить в защитный контур наводнения, землетрясения и ураганы. Причем запросы будут не сразу, а постепенно. И потом еще уточнения, типа затопление не водой, а канализацией. В коммерческой разработке не зря стали популярными всевозможные методологии основанные на цикличности. И управлять проще и сроки прогнозировать.
Быстрая однопроходная компиляция, легко читаемый код и при этом полная свобода творчества. А какая была "помощь" в турбо-паскале! С полезными и понятными примерами. Паскаль - отличный язык для быстрого старта и не отбивающий желания программировать.
Уже в "слегка за 30" в Канаде пришел к выводу, что хочу местного образования. С собой был диплом по АСУ 10 летней давности, на его основании и пошел на мастерат. (Master of Applied Computer Science, Concordia University). За время обучения встречал ну где-то с десяток со всех уголков бссср. И вот сказать, что мы сильно отличались ото местных не могу. Вопросы, дискуссии на среднем уровне языка никого не смущали. Вот где была засада, так это в количестве самостоятельной работы. На экзаменах спрашивалось намного больше того, что озвучивалось на лекциях. К коллективным проектам привыкаешь быстро. Основное правило - ничего не пускать на самотёк. Общаться и знать общий прогресс - ключ к успеху.
вот я тоже захотел из за границы отправить альбом. Не получив ответа на вопрос о вариантах оплаты, накидал фоток, посмотреть на опции. Но до опций оплаты не дошел, уткнувшись в поле номера телефона с нестираемой семёркой.
в итоге прибыло в полку загруженных, но не оплаченных альбомов. Добавили б пояснение вначале с ограничениями сервиса, что ли?
Для первого языка важен порог входа. В короткую эпоху десктопных программ Delphi был бесспорным лидером именно поэтому.
Второй момент - на чём учат, тому и учишься. Это опять же к выбору первого ЯП.
Ну а когда в профессию входишь, надо ВСЕГДА ориентироваться на личный комфорт и удовольствие. Ибо, если работать в кайф, то результат всегда лучше. И способствует росту и карьерному, и зарплатному и профессиональному. Ну и плюс жизнь одна, зачем ее тратить на работу, которая не приносить радости?
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 ) вот там - и чему учили вспоминать придется и новому учиться.
А на рабочих проектах (у ремесленников, коих среди программистов большинство нынче) алгоритмы скорее исключение, чем правило. Пару раз сам писал (типа оптимизации распределения ресурсов по куче входных параметров - было очень интересно), пару раз чужие "велосипеды" ремонтировал - куда менее интересно, если помягче сказать. Но обычно - сперва смотришь "стандартные" библиотеки, потом "популярные", а потом принимаешь решение, нужен ли новый велосипед.
главное "потому, что" - это статичность задачи. Рассчитали радиационную защиту, - никто назавтра не придет и не скажет включить в защитный контур наводнения, землетрясения и ураганы. Причем запросы будут не сразу, а постепенно. И потом еще уточнения, типа затопление не водой, а канализацией.
В коммерческой разработке не зря стали популярными всевозможные методологии основанные на цикличности. И управлять проще и сроки прогнозировать.
Быстрая однопроходная компиляция, легко читаемый код и при этом полная свобода творчества. А какая была "помощь" в турбо-паскале! С полезными и понятными примерами. Паскаль - отличный язык для быстрого старта и не отбивающий желания программировать.
Уже в "слегка за 30" в Канаде пришел к выводу, что хочу местного образования. С собой был диплом по АСУ 10 летней давности, на его основании и пошел на мастерат. (Master of Applied Computer Science, Concordia University).
За время обучения встречал ну где-то с десяток со всех уголков бссср. И вот сказать, что мы сильно отличались ото местных не могу. Вопросы, дискуссии на среднем уровне языка никого не смущали.
Вот где была засада, так это в количестве самостоятельной работы. На экзаменах спрашивалось намного больше того, что озвучивалось на лекциях. К коллективным проектам привыкаешь быстро. Основное правило - ничего не пускать на самотёк. Общаться и знать общий прогресс - ключ к успеху.
вот я тоже захотел из за границы отправить альбом. Не получив ответа на вопрос о вариантах оплаты, накидал фоток, посмотреть на опции. Но до опций оплаты не дошел, уткнувшись в поле номера телефона с нестираемой семёркой.
в итоге прибыло в полку загруженных, но не оплаченных альбомов. Добавили б пояснение вначале с ограничениями сервиса, что ли?
Для первого языка важен порог входа. В короткую эпоху десктопных программ Delphi был бесспорным лидером именно поэтому.
Второй момент - на чём учат, тому и учишься. Это опять же к выбору первого ЯП.
Ну а когда в профессию входишь, надо ВСЕГДА ориентироваться на личный комфорт и удовольствие. Ибо, если работать в кайф, то результат всегда лучше. И способствует росту и карьерному, и зарплатному и профессиональному. Ну и плюс жизнь одна, зачем ее тратить на работу, которая не приносить радости?