Open source contributor
Давно хотел написать статью на такую интересную и больную тему как импортозамещение. А именно, как это все выглядит и чем пахнет в той сфере, где я работаю – разработка и производство электронной техники, а конкретно – аппаратуры связи. У меня накопилось множество мыслей, занимательных историй, ознакомиться с которыми будет наверняка небезынтересно даже тем людям, кто далек от этой сферы.
Привет, Хабр! Немного запоздало (ко дню программиста) делюсь подборкой бесплатных книг по программированию. Все они полезные, уровень скорее профессиональный, хотя и для развития от базового тоже подойдет, но, к сожалению, на английском. Среди тем книг: .NET, Алгоритмы, Android, iOS, Angular, C, C++, C#, JS, Linux, Python. В целом, найдется почти любая тема, которая приходит в голову.
Дисклеймер. Все эти книги взяты с одного ресурса, который существует за счет донейшенов. Получить книги можно без осуществления донейшенов, ресурс полностью бесплатный, пожертвования опциональны. Все книги написаны на основе контента со StackOverflow и являются код-ориентированными. Книги со временем обновляются. По ссылкам -- книги, актуальные на 15.09.2021.
Человека далёкого от клиентской разработки на Windows все эти термины определённо путают. И даже среди MS-сообщества регулярно возникают споры жив UWP или мёртв. Причем главный вопрос в этом споре - а что же такое UWP?
Вот уже года 3 Microsoft проводит "рефакторинг" в своём "королевстве". Несколько устав видеть одни и те же споры в твиттере, и оставлять одни и те же комментарии на хабре, я решил расписать как же многочисленные UI-фреймворки MS соотносятся между собой. Кто из них больше мёртв. Возможно, кому-то это поможет в выборе технологии для будущего проекта.
Всем привет! Давно хотел написать эту статью, но материал всё никак не собирался: всё-таки рефакторинг - не на каждый день развлечение. Особенно если крупный. Речь пойдёт о том, как можно использовать Roslyn для лечения разной боли в шарповом коде. Если по центру вашего проекта возвышается огромная куча неудобного легаси и вам страшно на неё смотреть - добро пожаловать под кат. Возможно, мой материал позволит взглянуть на проблему с другого ракурса и понять, что не всё так печально. По идее сам подход может быть применим к любому языку, экосистема которого включает в себя тулинг для компилятора. Но это не точно. Однако, я расскажу всё, что знаю на двух примерах из реальной жизни.
Когда речь заходит о создании .NET библиотеки, части API которой являются платформозависимыми, приходится думать, как всё это оформить в NuGet пакет, да так, чтобы установленная из пакета библиотека работала в разных сценариях (.NET Framework, .NET Core, self-contained app и т.д.). К сожалению, в сети сложно найти инструкцию, которая бы шаг за шагом показывала, как выполнить эту задачу. Данная статья призвана быть такой инструкцией.
В этой статье поделюсь опытом, как уменьшить размер приложения, написанное на C# и независящее от сборки, в 2 – 4 раза.
В своей предыдущей заметке на тему обработки данных лабораторных работ я написал об использовании пакета gnuplot – простого и мощного инструмента для решения подобных задач и графического представления результатов. Однако довольно распространённым является мнение, что студенты, которым я советовал использовать gnuplot, вероятно, изучают программирование и способы визуализации данных, и что для них более естественным и полезным будет практическое применение уже полученных навыков в этой сфере. В этом коротком тексте мы рассмотрим применение python с использованием библиотек scipy для обработки данных и matplotlib для представления результатов.
К сожалению, мир машинного обучения принадлежит python.
Он давно закрепился, как рабочий язык для Data Silence, с чем Microsoft решила поспорить. Так появился ML.NET, кросс-платформенная и открытая система машинного обучения для разработчиков .NET.
В данной статье, я хочу показать, что использовать ml.net - не сложнее, чем остальные варианты, которые есть, на реально работающем примере, ссылку на который оставлю внизу. Это канал в телеграмме, который в автоматическом режиме забирает данные, классифицирует их(это и будем рассматривать) и постит. Кому интересно, добро пожаловать.
Привет, Хаброжители! Паттерны проектирования — удобный прием программирования для решения рутинных задач разработки ПО. Грамотное использование паттернов позволяет добиться соответствия любым требованиям и снизить расходы. В этой книге описаны эффективные способы применения паттернов проектирования с учётом специфики языка C# и платформы .NET Core.
Недавно я столкнулся с проблемой локализации своего приложения и задумался над её решением.
Первым на ум приходить самый очевидный и простой способ - словарь, но он был тут же отвергнут, так как никак не нельзя проверить существует ли строка в словаре на момент компиляции.
ASP.NET Core Blazor — это разработанная Microsoft веб-платформа, предназначенная для запуска на стороне клиента в браузере на основе WebAssembly (Blazor WebAssembly) или на стороне сервера в ASP.NET Core (Blazor Server), но две эти модели нельзя использовать одновременно. Подробнее о моделях размещения написано в документации.
В статье я расскажу о том, как
TL;DR:
Некоторое время назад понадобилось мне в одной Delphi-шной программе много посчитать, но расчеты шли как-то подозрительно долго. Переписывать около 100 kLOC не хотелось- особенно из-за наличия большого количества форм, но предыдущий мой опыт показывал, что если код расчетов перекомпилировать в Lazarus'е (с FPC3.0.4)- то скорость счета возрастает до 2-х раз, и поэтому было очевидно, что конкретно в данном случае компилятор Embarcadero (разных версий) сильно несилен, и надо его менять. С другой стороны, IDE от Embarcadero для рисования GUI- вне конкуренции, а их компилятор на редкость быстрый (оно и понятно- быстро+плохо, или медленно+хорошо). Но ведь вкус кактуса неимоверно притягателен. Профайлинг подручными средствами (tinyprofiler) во всех случаях показывал, что основное время (90%) занимают операции векторной алгебры над большими массивами чисел, а быстрый тест производительности этих процедур показал, что на операциях с этой алгеброй общая "пропускная способность" имевшегося математического ядра составляет для операций типа умножения векторов и скалярных произведений- ~4 ГБ/с, для умножения вектора на матрицу- 1,5-2 ГБ/с, а вот для операций обращения матрицы- проседает до 360 МБ/с (на Core I5 4460 и на Xeon 2660V2, DDR3-1866). Внутре рядом с неонкой используются только 3-х и 4-х мерные вектора и матрицы. В голову пришла мысль, что 4х4 матрица- должна целиком влезать в SSE-регистры процессора и для нее SIMD- очень желательны, а в компилятор Delphi SIMD не завезли, кажется не завезут, и вообще- дальше нижней половины XMM0 не используют. В итоге нарисовалась очень простая задача- реализовать быструю векторную алгебру в минимальном объеме для 3D/4D векторов своими руками- то есть, соорудить стероидный велосипед, о котором в заголовке написано.
И вот здесь мой навык гуглинга дал сбой- мне предлагали купить проприетарные библиотеки, в которых все уже есть, или примеры векторных операций с FP32 на SSE, но нужного FP64 - нету! Под катом- как на SSE руками сделать операцию с вектором для расчетов какой-нибудь физики и вывернуть матрицу наизнанку.
Очень часто при обсуждении многопоточности на платформе .NET говорят о таких вещах, как детали реализации механизма async/await, Task Asynchronous Pattern, deadlock, а также разбирают System.Threading. Все эти вещи можно назвать высокоуровневыми (относительно темы хабрапоста). Но что же происходит на уровне железа и ядра системы (в нашем случае — Windows Kernel)?
На конференции DotNext 2016 Moscow Гаэл Фретёр, основатель и главный инженер компании PostSharp, рассказал о том, как в .NET реализована многопоточность на уровне железа и взаимодействия с ядром операционной системы. Несмотря на то, что прошло уже пять лет, мы считаем, что никогда не поздно поделиться хардкорным докладом. Гаэл представил нам хорошую базу по работе процессора и атомнарным примитивам.
Вот репозиторий с примерами из доклада. А под катом — перевод доклада и видео. Далее повествование будет от лица спикера.
Это расшифровка-перевод доклада Саши Гольдштейна, признанного лучшим на конференции DotNext 2016 Piter. С годами этот доклад стал лишь актуальнее прежнего: появление Mac на ARM-процессорах — еще один пример, почему разработчикам сегодня нужно думать не только о x86-архитектуре.
Речь пойдет о проблемах, с которыми вы можете столкнуться при написании многопоточного кода, если вы думаете, что достаточно умны, чтоб спроектировать свои собственные механизмы синхронизации.
То, что подходит процессорам Intel на архитектурах x86 и x86-64, может не подойти другой архитектуре. Как только вы перенесете свой код на другой процессор, например, на ARM для iPhone и Android, есть вероятность, что он перестанет работать как надо. Проблемы могут быть как очевидными (воспроизводиться с первого-второго раза), так и не очень (возникать только раз в миллион итераций). Вполне вероятно, что такие баги могут добраться до продакшна. Сегодня .NET и, конечно, C++ можно использовать не только на Windows и Intel, но и на других платформах, так что доклад будет полезен многим разработчикам.
Дисклеймер: статья предназначена для продвинутых читателей. Смотрите на свой страх и риск. За частое упоминание барьеров памяти и изменения порядка исполнения инструкций она получила возрастное ограничение 18+.
Как четыре математика решили вопрос о базовых геометрических фигурах, создав полный список тетраэдров с рациональными углами при помощи методов теории чисел.
