C# *

Под мерой производительности UI будем понимать количество откликов на действия пользователя в единицу времени. А под откликом — запрашиваемую пользователем реакцию приложения.

Малым временем отклика можно объяснить ряд предпочтений пользователя:

1. Предпочтение аналоговых интерфейсов цифровым (когада возникает задержка на обработке цифрового ввода);
2. На заре Windows, — предпочтения пользователей работать с DOS программами в «текстовом режиме», а с не GUI аналогами в Windows (время отклика в текстовом режиме тогда было заметно меньше на сходной платформе);
3. Предпочтение реальных игровых консолей их эмуляторам (эмуляторы часто имеют время отклика отличное от времени отклика оригинальных консолей);
4. Предпочтение пользователей iOS и Android относительно WinCE и Symbian (среди прочего, например в iOS ставилась цель быстрого отклика и поддержки 60 FPS, Android хотя и не ставил таких целей был заметно отзывчивее WinCE и Symbian);
5. В автомобилях — неоднозначное отношение пользователей к автоматическим коробками передач, электронной педали газа и некоторым другим системам вносящим задержку между управляющим воздействием и реакцией на него (это относится к наименее продвинутым версиям этих решений).

Большое время отклика является по сути «обратной связью с запаздыванием», про которую более подробно можно прочитать тут: «Обратная связь с запаздыванием в кране с горячей водой, марсоходе и демографической пирамиде».

В последнее время пришлось интегрировать внутриигровые покупки в свою игру и встал вопрос, а какой же плагин для этого использовать под Unity3D? Есть такие вещи как OpenIAB, Prime31, Unibill и Soomla. Более мелкие вещи брать в расчет не будем, ибо некоторые из них либо не обновляются вообще, либо имеют какие-то критические проблемы. Кто хочет знать, почему выбор пал именно на Soomla, и как его интегрировать прошу под кат.

У нас сотни программных проектов на поддержке, некоторые из них поддерживаются нами почти десять лет. Нетрудно догадаться, что понятие maintainable кода (переведу это понятие как код, легкий в поддержке) является у нас одним из основных. По счастливому стечению обстоятельств легкий в поддержке код также является и легким для (unit-)тестирования, легким для освоения новыми членами команды и т.д. Скорее всего, это связано с тем, что для создания maintainable кода приходится озаботиться хорошей архитектурой проекта и завести несколько хороших привычек.
В этой статье и поговорим о таких привычках, благодаря которым часто хорошая архитектура получается сама собой. Постараюсь также иллюстрировать все хорошими примерами.

Данная статья посвящена работе по исследованию возможности обучить простейшую (относительно) нейронную сеть «слушать» музыку и отличать «хорошую» по мнению слушателя от «плохой».

Цель

Научить нейронную сеть отличать «плохую» музыку от «хорошей» или показать, что нейронная сеть на это неспособна (данная конкретная ее реализация).

Статья «Навыки .NET-разработчика» была первым моим аналитическим исследованием востребованности навыков на рынке труда, в котором я показал потребности близкого к нам российского рынка в специалистах моей профессии. В этом материале я представляю сравнение с зарубежным рынком. Говорят, что наш IT-рынок в целом и используемые нами технологии в частности отстают от Запада на несколько лет. Давайте вместе посмотрим «за рубеж» и попробуем понять, так ли это и есть ли нам чему поучиться.

Код Serbench находится на GitHub.

Начало проекта

Этот бенчмарк проект начался со статьи “Serializers in .NET v.2” на GeeksWithBlogs.net. В статье было рассмотрено довольно много имеющихся под .NET сериализаторов. Но, чтобы превратить эту статью и соответствующий код в настоящий бенчмарк, надо было сделать несколько улучшений.

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

Во-вторых, сериализаторы сильно отличаются по интерфейсам. Наш бенчмарк не должен заставлять сериализатор следовать нашему выбору интерфейса. Наоборот, бенчмарк должен быть настолько гибким, чтобы каждый сериализатор мог бы использовать наиболее подходящий для него интерфейс. То есть надо передавать в бенчмарк дополнительные параметры конкретного сериализатора.

Онлайн-планировщики хороши тем, что позволяют получить доступ к вашему календарю с любого устройства. При этом не стоит беспокоиться о сохранности данных в случае проблем с компьютером или смартфоном или о синхронизации расписаний между устройствами. Однако, количество инструментов, предназначенных для создания таких планировщиков может вызвать недоумение. Существуют JavaScript календари, .NET календари. Календари могут быть сторонними плагинами для популярных фреймворков или одним из компонентов этих фрейморков. Доступны также и stand-alone календари с возможностью интеграции с другими продуктами. Задача этой статьи — рассмотреть четыре разных .NET компоненты с целью помочь выяснить, на какой из них стоит обратить внимание и какой лучше подходит для пользователей разного уровня.



Вот список претендентов на сегодня:

— DayPilot ASP.NET Event Calendar
— DHTMLX Scheduler .NET
— Devexpress ASP.NET Scheduler
— Telerik .NET Scheduler

Для сравнения мы создадим базовый календарь, попутно обратив внимание на то, насколько хороша документация, и посмотрим, какие возможности он предоставляет и как выглядит. Поскольку процесс создания такого приложения в целом проходит одинаково для каждого из инструментов (создание календаря, базы данных для хранения событий и связывание их вместе), в статье мы не будем приводить пример кода. Вместо этого обратим внимание, насколько просто создать базовое приложение в первый раз с использованием документации.

Итак, приступим.

Использование исключений для контроля хода выполнения программы (flow control) — давняя тема. Я хотел бы суммировать этот топик и привести примеры правильного и неправильного использования исключений.

Знаменитая игра Джона Конвея «Жизнь», благодаря своей простоте, занимательности и поучительность, реализовывалась программистами так много раз, что уступает вероятно только пресловутой сортировке «пузырьком».

Приведу, тем не менее, еще один вариант исполнения этой замечательной игры, целиком основанный на технологии LINQ в среде .NET — простой, компактный, без циклов и многомерных массивов.

В статье речь пойдет о крошечном усовершенствовании проекта Fody.MethodDecorator с добавлением возможности декорирования асинхронных методов.

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

В последнее время стало очень популярным нововведение под названием лента (Ribbon). Autodesk не стал отставать от жизни и, начиная с 2009 автокада, тоже начал использовать ленту.

Мы рассмотрим пример создания вкладки на ленте для 2010 автокада и рассмотрим несколько сопутствующих «проблемных» вопросов. Почему для него? Да потому что в 2009 лента была еще «сырая» (но там тоже можно так сделать), и потому что для последующих автокадов (2011-2013) код будет анологичен.

Вариантов добавить свою вкладку на ленту несколько:

• создать файл АПИ (cui) со своей лентой и подгружать его. На мой взгляд самый плохой и проблемный вариант. ИМХО
• создать вкладку на ленте программно — этот вариант и рассмотрим
• создать вкладку используя технологию WPF — я не стал разбираться

Примечание: Я не буду углубляться в каждую мелочь и «красиво» все описывать — пример не сложный. Да и я так красиво излагать не умею.

Пример рассматривается с учетом, что вы знаете как писать (хотя бы самые простые) плагины для автокада средствами .net. Для работы я использую Microsoft Visual Studio 2010.

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


В тот же момент я подумал: ведь мессенджер вообще и Telegram в частности это идеальный способ взаимодействия с клиентом. Зачем нам приложение, чтобы доставлять последние новости если это можно просто прислать их в чат?

Зачем вам приложение для заказа такси, когда вы можете написать в чат любимому оператору такси «хочу такси в Домодедово от м. Южное через 35 минут» — и такси заказано. Зачем вам приложение для заказа из кафе, когда можно написать в чат «хочу двойной эспрессо и бейгл с осетром» — и осталось только послать свой адрес. Таких примеров использования чата может быть огромное множество.

В тот же день я написал небольшой пост в клубном новостном сообществе TJournal, где предложил в рамках предстоящего хакатона AngelHack написать продукт и создать демонстрационного бота: для подписки на новости и уведомления из этого сообщества. Через четыре дня Павел Дуров официально запустил поддержку ботов, а еще через две недели мы победили на AngelHack в номинации от IBM с проектом Leecero. Под катом большая история…

Это краткое введение в криптографию под .NET для чайников, как и следует из заголовка. Здесь будут простые вещи и никаких углубленных знаний.

Некоторое время назад попался мне твит о том, что знакомый стал использовать новый тестовый опенсорсный фреймворк Fixie и очень этим доволен. Так, что даже решил исправить все тесты в своем проекте на новый движок. После такого, я просто не мог оставаться в стороне и даже не взглянуть, что это за зверь такой и чем он так радует окружающих.

Далее я хочу представить вам обзор фреймворка, его возможности, и понять, действительно ли это новое слово в тестировании, стоит к этому присмотреться или же можно пройти мимо и забыть.

Как сказано на самом сайте, Fixie – Conventional Testing for .NET. Т.е. тестирование по соглашению. Под соглашениями здесь понимается то, к чему мы в целом привыкли – все операции выполняются на основе «устного» договора, джентельменского соглашения об именовании. Ближайший пример – scaffolding. Это когда мы договорились, например, что тестовые классы содержат слово Test, или что тестовые классы должны быть публичными и ничего не возвращать.  Тогда такие классы будут распознаны как тестовые. И больше никаких атрибутов и всего такого прочего. Просто классы и методы.

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

Часто ли вы задумываетесь – почему что-то сделано так или иначе? Почему у вас микросервисы или монолит, двухзвенка или трехзвенка? Зачем вам многослойная архитектура и сколько у вас вообще слоев? Что такое бизнес-логика, логика приложения, презентационная логика и почему все так разделено? Посмотрите на свое приложение – как оно вообще спроектировано? Что в нем и где находится, почему это сделано именно так?
Потому что так написано в книжках или так говорят авторитетные личности? Какие ВАШИ проблемы решает тот или иной подход/паттерн?
Даже то, что на первый взгляд кажется очевидным, порой бывает очень сложно объяснить. А иногда, в попытке объяснения, приходит понимание того, что очевидные мысли были и вовсе ошибочны.
Давайте попробуем взять какой-нибудь пример и изучить на нем эти вопросы со всех сторон.

Я бы хотел обсудить принцип разделения ответственности (Separation of Concerns, SoC) в контексте ORM, а также посмотреть почему этот принцип так важен. Также мы рассмотрим примеры нарушения границ ответственности между доменной логикой и логикой сохранения данных.

Я много раз сталкивался с задачей динамической генерации кода (например, при написании эффективного сериализатора или компилятора DSL). Это можно делать разными способами, какой из них лучший – дискуссия для отдельной статьи. По ряду причин я предпочитаю Reflection.Emit и CIL (Common Intermediate Language) и расскажу, с какими проблемами пришлось столкнуться на этом пути, а также об их решении: умной обертке над ILGenerator – GroboIL из библиотеки Graceful Emit.

Хочу отметить при этом, что иногда встречаются ситуации, когда у нас нет большого выбора: например, при написании сериализатора необходимо иметь доступ к приватным полям, и приходится использовать IL. Кстати, известный сериализатор protobuf-net содержит несколько сотен IL-инструкций.

Если вы ни разу не сталкивались с использованием IL-кода, то статья может показаться сложной для понимания, поскольку содержит много примеров кода с использованием IL. Для получения базовых знаний рекомендую прочитать статью Introduction to IL Assembly Language.

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

• Сканирование локальной сети, получение IP-адреса, HostName, Mac-address;
• Создание "magic packet" и отправка.

Вот так примерно выглядит созданная программа:



Итак, приступим к выполнению первого пункта.

В качестве предисловия

Наверное, многие из вас в своей практике сталкивались с задачей сбора почты с ряда ящиков. Зачем это может быть нужно? Наверное, потому что это универсальный механизм обмена данными между системами. Множество библиотек под любые языки, реализующих SMTP, POP3, IMAP, готовые решения по реализации стэка сообщений (как я сложно назвал почтовый ящик...) и т.д.

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

Кому достаточно приведенного ниже кода — дальше могут не читать:

         foreach (var mailbox in mailboxes)
                using (var client = new Pop3Client())
                {
                    client.Connect(Hostname, Port, false);
                    client.Authenticate(User, Password);

                    var count = client.GetMessageCount();
                    for (var i = 0; i < count; i++)
                    {
                        Mail = client.GetMessage(i + 1);
                        var cat = SortMail(Mail);
                        DoSomething(Mail, cat);
                    }
                }

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

На старте проекта часто может возникнуть вопрос о выборе средств разработки и если в одних случаях ответ на этот вопрос следует из потребности совместимости с библиотеками и приложениями, то в других ответ не очевиден.

Отдельных статей требует рассмотрение выбора Java или же интерпретируемых языков. Они будут предпочтительнее, чем С++ или С# в некоторых случаях, однако вынесем такие случаи за рамки данной статьи и сфокусируемся на сравнении С++ и С#.

Для ясности обозначу, что под C++ буду понимать unmanaged код, а под C# — managed код. В статье можно было сравнить managed и unmanaged, но это было бы менее полезно практический. А mixed код, хотя он и представляет некоторый интерес, оставим по большей части за рамками данной статьи.

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