Открытая платформа .NET Core работает практически на всем: Windows, Mac и десятке Linux-систем. Но еще есть SDK и Runtime. Раньше .NET Core SDK не поддерживался на чипах ARMv7/ARMv8, на которых работает Raspberry Pi. Но все изменилось. Подробнее о способах запуска под катом!

CUDA всем хороша, пока под рукой есть видеокарта от Nvidia. Но что делать, когда на любимом ноутбуке нет Nvidia видеокарты? Или нужно вести разработку в виртуальной машине?

Я постараюсь рассмотреть в этой статье такое решение, как фреймворк rCUDA (Remote CUDA), который поможет, когда Nvidia видеокарта есть, но установлена не в той машине, на которой предполагается запуск CUDA приложений. Тем, кому это интересно, добро пожаловать под кат.

Все мы любим отлавливать ошибки на этапе компиляции, вместо исключений времени выполнения. Их устранить проще всего, компилятор сам показывает все места, нуждающиеся в исправлении. Хотя большинство проблем можно обнаружить только при запуске программы, все же мы стараемся сделать это как можно раньше.

SSH — очень мощный и гибкий инструмент, но, как показывает практика, не все понимают, как он работает, и правильно его используют. Слово Secure входит в аббревиатуру SSH и является одним из ключевых аспектов протокола, но часто именно безопасности уделяется недостаточное внимание. В этой статье я хочу рассказать о нескольких типичных ошибках при работе с SSH, а также о моментах, о которых часто забывают.

В предыдущих частях Краткое содержание:

«Часть 1»
I Вступление
II Анализ рынка решений
1. Стандартизация функций систем, представленных на рынке
2. Недостатки существующих систем
3. Вызовы при создании системы поддержки производства информационных систем
III Проектирование базовой структуры системы
1. Деление решаемых проблем по типам

«Часть 2»
2. Требования и задачи для них
3. Спецификации и задачи для них
4. Сборки и задачи для них
5. Анализ фазы проектирования

IV ПРОЕКТИРОВАНИЕ ЭЛЕМЕНТОВ ИНФРАСТРУКТУРЫ СИСТЕМЫ

Среди бесчисленных видов волшебства созидание предоставляет большую свободу. Каждый созидает по-своему. Выкладывайся на полную и найди собственную форму.
(Сказка о хвосте феи)

Продолжим начатое в предыдущей части разрушение привычных шаблонов и конструирование других, новых.

В предыдущей части «Часть 1» Краткое содержание:

I Вступление
II Анализ рынка решений
1. Стандартизация функций систем, представленных на рынке
2. Недостатки существующих систем
3. Вызовы при создании системы поддержки производства информационных систем
III Проектирование базовой структуры системы
1. Деление решаемых проблем по типам

2. Требования и задачи для них

Сперва сосредоточимся на проблеме, как может быть организована работа, касающаяся требований к создаваемому продукту. Ее исполнители и авторы скорее всего так или иначе завязаны на функции по сбору и анализу информации. Люди неординарные и немного консервативные, под них и будем подстраиваться.

I Вступление

Ставишь себе невозможную цель и развлекаешься этим, если можешь. Ведь такое занятие интересно само по себе, поскольку изначально перед тобой заведомо невыполнимая задача, а что может быть увлекательней, чем невозможное
Иосиф Александрович Бродский.

За свою многолетнюю ИТ практику мне пару раз посчастливилось поучаствовать в проектах, затрагивающих тему автоматизации техпроцесса самого что ни на есть производства информационных систем. По разным причинам команде нужен был свой уникальный продукт, позволяющий выполнять подобные задачи. Например, в одном интересном проекте на платформе 1С, организуя процесс управления разработкой и внедрения ПО, требующий оперативности принятия мер (если что-то пойдет не так), помимо общепринятых активностей, мы создали подсистему, автоматизирующую сбор замечаний пользователей, непосредственно в самом продукте, так сказать на острие атаки. Прямо в свой рабочей среде, да что там среде, прямо на форме с конкретными данными, пользователи самолично могли создавать сообщения для разработчиков: об ошибках, замечаниях, предложениях и т.п. А там на обратном конце коммуникации, в глубоком тылу, программисты в системе управления разработкой, помимо описания ошибки, оперативно могли увидеть: сборку продукта, место локализации базы данных, форму, и наконец сами данные, с которыми связано возникновение ошибки. Это позволило разработчику прямо из задачи по устранению ошибки переходить в продуктивную среду и видеть воочую все то, что лицезрел пользователь, создавая сообщение. Согласитесь, что это очень удобно.

Добрый вечер! В этой публикации я расскажу о своей самоделке, задумал которую я достаточно давно. Но реализовал только сейчас.

Впервые увидел этот эффект еще в детстве. Меня попросили помочь, подержать и посветить автомобильным стробоскопом на маховик двигателя автомобиля. Мотор запустили и после чего я увидел на вращающемся маховике, почти не подвижную насечку, которая стояла на одном месте, а маховик при этом вращался. После чего родилась идея сделать вентилятор и стробоскопом остановить его. Идею спустя какое то время реализовал, на лампе ИФК-120, тиристоре КУ202 с обвязкой, поигрался и закинул в дальний угол, но вот лет 6 тому назад увидел японское видео с левитацией воды. Так и родилась идея повторить этот трюк с левитацией капель. Долго не доходили до реализации руки и вот наконец то, сбылась мечта…

Каждый новый год начинается с 10 дней безумного, оторванного и безудержного веселья, лыж, коньков лежания на диване и курсирования от холодильника к вазе с мандаринами. Любимые фильмы, мультики, встречи гостей, работа (куда ж без неё) и толпы детей, жён, мужей, родителей вокруг. И как-то даже грустно становится, что эти дни проходят в такой атмосфере. А потом сонливость на работе, снеки в столах, литры кофе — в общем, как встретишь новый год, так его и проведёшь.

И даже если не верить в энергетику пограничных дат, приметы и обычаи, выходить на работу после 11 дней расслабоне тоже весьма чревато. Чтобы не было обидно за бесцельно прожитые дни, нужно их организовать правильно: развлечения, книги, спорт и активные игры, общение и обучение. Так будут застрелены сразу несколько зайцев: переключение внимания, отдых на фоне смены деятельности, новые знания и навыки, вдохновение.

С этой статьей я продолжаю публиковать целую серию статей, результатом которой будет книга по работе .NET CLR, и .NET в целом. Вся книга будет доступна на GitHub (ссылка в конце статьи). Так что Issues и Pull Requests как всегда приветствуются :)

Существует область памяти, про которую редко заходит разговор. Однако эта область является, возможно, основной в работе приложения. Самой часто используемой, достаточно ограниченной с моментальным выделением и освобождением памяти. Область эта называется «стек потока». Причем поскольку указатель на него кодируется по своей сути регистрами процессора, которые входят в контекст потока, то в рамках исполнения любого потока стек потока свой. Зачем же он необходим? Давайте вместе окунемся в мир низкоуровневых структур, на основе которых работает все: начиная от DOS программ и заканчивая .NET Framework, установленным поверх Windows 10.

Итак, разберем элементарный пример кода:

void Method1()
{
    Method2(123);
}

void Method2(int arg)
{
    // ...
}

В данном коде не происходит ничего примечательного, однако не будем его пропускать, а наоборот: посмотрим на него максимально внимательно.

Примечание

Глава, опубликованная на Хабре не обновляется и возможно, уже несколько устарела. А потому, прошу обратиться за более свежим текстом к оригиналу:

• CLR Book: GitHub, оглавление
• CLR Book: GitHub, глава
• Релиз 0.5.2 книги, PDF: GitHub Release

Всем добрый день. Я хочу представить на суд общественности (ещё один) простой способ сделать локализацию приложений. Стандартный механизм с ресурсными сборками меня не устраивает по следующим причинам:

1. Получая значение локализованной строки в коде, очень хочется полагаться на всю мощь ООП и подсказки компилятора. Очень неприятно собрать проект в вечером в пятницу, а утром в субботу получить звонок от впахивающих overtime QA на тему того, что кто-то невнимательный написал GetResource(«asdf») вместо GetResource(«assf»), и теперь что-то падает или отображается неверно, а проект в понедельник уже сдавать в печать…
   
   
2. (В продолжение предыдущего пункта...) Писать string foo = language.Ui.PromtDialog.AdditionalQuestion просто приятнее, чем string foo = Resources.GetResource(«Ui_PromtDialog_AdditionalQuestion»). Да, в том числе и за счёт подсказок компилятора.
   
   
3. Иногда локализовать нужно не строки, а целые объекты. Например, существительное (строка + род М/Ж/С/Мн) и прилагательное (строка М + строка Ж + строка С + строка Мн). Пихать в ресурсы сериализованную строку, а потом доставать и десериализовать каждый раз? Мсье знает толк в извращениях…
   
   
4. Ресурсный файл — это плоский список строк, а хотелось бы, чтобы данные всё-таки имели более сложную иерархическую структуру, по которой не нужно ползать с помощью Ctrl+F.
   
   
5. Создание нового языка должно быть настолько простым, насколько это возможно. Локализовать приложение должен быть способен человек, умеющий обращаться с компьютером и владеющий нужными языками. И ему для этого не нужны ни Visual Studio, ни возня с созданием ресурсных сборок.

Ещё одно обязательное требование — возможность простой привязки к локализации элементов UI. Желательно — одновременно и WPF, и WinForms.

В этой короткой заметке хочу рассказать о прекрасной программе для поиска утечек памяти под Visual Studio--Visual Leak Detector.
Она удивительно проста в использовании и выдает подробную информацию о найденных утечках, а на хабре пока не упоминалась.