К сожалению, мир машинного обучения принадлежит python.
Он давно закрепился, как рабочий язык для Data Science , но Microsoft решила поспорить и представила свой инструмент, который легко можно интегрировать с экосистемой, которой сейчас пользуется весь мир. Так появился ML.NET, кросс-платформенная и открытая система машинного обучения для разработчиков .NET.
Как мы столкнулись с неожиданным багом в .NET 5, расследовали возникшую проблему, и что же из этого вышло.
Одним прекрасным днём было принято решение о переводе рабочего проекта с .NET Core 3.1 на .NET 5. Миграция оказалась проще, чем это было, например, при переходе с .NET Core 2.1 на .NET Core 3 из-за меньшего количества доработок. По сути потребовалось просто изменить TargetFramework на net5.0, обновить несколько библиотек и поправить пару мест в коде, которые стали deprecated, чтобы в будущем это было не так больно делать.
Привет. В этом очерке расскажу, как я реализовывал компиляцию математических (численных и логических) выражений в делегат при помощи Linq Expression.
Навигация: Проблема · Правила компиляции · Компилятор · Дефолтные правила · Красивый API · Производительность · Примеры работы · Читать полностью »
Время от времени я встречаю людей, пытающихся выразить API в терминах IQueryable<T>. Почти всегда это плохая идея. В этой статье я объясню почему. В кратце, IQueryable<T> — это один из лучших примеров заголовочного интерфейса (Header Interface), предлагаемых платформой .NET. Его почти невозможно реализовать полностью.
Эта статья о проблемах реализации API на основе интерфейса
IQueryable<T>. Это не претензия к интерфейсу как таковому. Кроме этого, это не претензия к замечательным методам LINQ, доступным для интерфейсаIEnumerable<T>.
Можно сказать, что IQueryable<T> — это одно сплошное нарушение принципа подстановки Лисков. Я буду использовать закон Постела, чтобы объяснить почему это так.
Принцип устойчивости, также известен как закон Постела в честь Джона Постела: «Будь либерален к тому, что принимаешь, и консервативен к тому, что отсылаешь (Be liberal in what you accept, and conservative in what you send)».
«Сказать программисту, что уже есть библиотека, делающая Х, — это то же самое, что сказать музыканту, что уже есть песня про любовь» (с)
Есть разные способы посмотреть, чем занят сервер под Windows: можно зайти по RDP и открыть Task Manager или Process ExplorerЧитать полностью »
Высокоуровневые языки программирования популярны, но существуют области, в которых придется использовать неуправляемые реализации библиотек. Это могут быть вызов специфических функций ОС, низкоуровневый доступ к устройствам, необходимость быстродействия в алгоритмах и другие. Под катом я расскажу, с чем можно столкнуться во время путешествия в unmanaged code и что стоит взять с собой.
Эта статья является развёрнутым комментарием к другой статье. Обычно я прохожу мимо, но сейчас меня почему-то задело.
Та статья представляла из себя практически «идеальную подборку заблуждений в вакууме». Причём они (заблуждения) являются довольно популярными и постоянно встречаются в различных блогах и подборках «99 вопросов для собеседования», «как пройти собеседование на джуниора» или в данном случае «шпаргалка по C#».
Мой переход на F# в качестве излюбленного языка был слегка усеян препятствиями. Примерно через десять лет почти постоянного использования C# у меня пробудилось любопытство, когда я услышал об этом другом #-языке. Моя первая реакция была той, которую с тех пор видел у других C#-разработчиков — отрицание, — C# является хорошим языком, и мне с ним комфортно, так зачем тратить силы на изучение другого? Но любопытство осталось — и, по крайней мере, несколько раз выделил вечер, чтобы прочитать базовый вводный пост и попытаться написать каких-нибудь ката на F#. Это не прижилось, потому что я просто чувствовал себя потерянным и не мог воплотить свой опыт использования C# в ощущение даже отдаленного комфорта с F#. Достаточно легко опустить фигурные скобки, немного замяться, чтобы не забыть let вместо var — но как сделать то, что я хотел?
Тогда я этого не осознавал, но, на мой взгляд, наблюдал потенциальный недостаток в том, как F#-разработчики говорят, описывают и представляют свой язык внешнему миру. Существует обширная база материалов обо всех возможностях и функциональности F#: Algebraic Data Types, Exhaustive Matching, Type Inference и т.д. Есть много статей, посвященных тому, как решать широкий спектр задач с помощью F#. Но, как мне кажется, не хватает чего-то вроде следующего: некоторых указаний о том, как взять то, что вам уже удобно в C#, и перевести их на F#. Так что мне интересно, можем ли мы как-то закрыть этот недостаток.
Анализатор PVS-Studio регулярно пополняется новыми диагностическими правилами. Что интересно, часто диагностики обнаруживают подозрительные фрагменты кода еще до окончания всех работ. Например, в процессе тестирования на open-source проектах. Одной из подобных интересных 'находок' и хотелось бы поделиться сегодня с вами.
Это очередная статья из цикла о том, как я работаю с устаревшими устройствами, добавляя им больше возможностей и упрощая взаимодействие. Однако в этот раз я не стал брать чужие разработки и заставлять их работать, а написал своё собственное приложение, поскольку аналогов для него просто нет.
