В первой части вы изучите основы о том, как модель акторов и Akka.NET работают.

Концепции, которые вы узнаете

---

В *NIX системах есть tail утилита, встроенный мониторинг изменений в файле, которую Windows не имеет. Мы пересоздадим tail для Windows и в процессе будем изучать фундаментальные вещи.

В первой части мы узнаем:

1. Как создать вашу собственную ActorSystem и акторы.
2. Как отправлять сообщения акторов и как обрабатывать различные типы сообщений.
3. Как использовать Props и ActorRef в построении слабосвязанных систем
4. Как использовать пути акторов, их адреса, и ActorSelection для отправки сообщений акторам
5. Как создать потомков акторов (child actors) и иерархию акторов, и как контролировать потомков используя SupervisionStrategy
6. Как использовать жизненный цикл актора чтобы управлять поведением запуска, выключения и перезапуска актора

Добро пожаловать в Akka.NET Bootcamp. Это бесплатный курс для самостоятельного обучения, подготовленный парнями из Petabridge.

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

Мы начнем с некоторых основных акторов и постепенно будем подходить к большим и более сложным примерам.

Этот курс для самостоятельного обучения — вы можете выполнять его в любом темпе на ваше усмотрение. Вы можете подписаться здесь и каждый день получать по одному уроку Akka.NET на ваш email (на английском языке — от перев.) если хотите.

ПРИМЕЧАНИЕ: На текущий момент учебный курс рассчитан на использование C# в качестве языка программирования.
Мы намерены добавить поддержку F# в будущем
(Также мы принимаем F# pull-реквесты)

Что вы узнаете

В учебном курсе Akka.NET вы изучите, как использовать акторы Akka.NET для создания реактивных, параллельных систем. Вы узнаете, как создать приложения, которые, возможно, казалось невозможным или очень-очень трудным до изучения Akka.NET. После учебного курса вы будете чувствовать себя более уверенно в решении сложных и больших проблем, чем раньше.

Для дотошных

В последнее время в среде разработчиков серверных приложений часто возникают споры о том, как лучше управлять фалами и какая технология обеспечивает более быстрые чтение/запись файлов. В сети стали появляться статьи и статейки о сравнительной производительность локальной файловой системы и GridFS. Или о хранении файлов в реляционной базе как BLOB против хранения на жёстком диске в файловой системе. Вот и я решил ввязаться в этот противостояние. Сегодня мы будем сравнивать производительность и накладные расходы MongoDB 2.6.7 x64 GridFS против MS SQL Server Express 2012 v11.0.5058.0 x64 против NTFS. Для эксперимента была использована платформа Windows 7 x64 SP1 на AMD Athlon(tm) II X2 250 Processor 3.00 GHz c 4ГБ ОЗУ 1033 MHz и HDD 600 Gb SATA 6Gb/s Western Digital VelociRaptor 10000rpm 32Mb. После каждого теста компьютер перезапускался, а базы обнулялись. Производительность будем рассматривать на примере файлового сервера на C# под .NET 4.5, код которого прикреплён к статье.

Первый предварительный релиз ASP.NET 1.0 вышел практически 15 лет назад и с тех пор миллионы разработчиков использовали его чтобы создавать и запускать различные приложения., а мы на протяжении этих лет добавляли в совокупности колоссальное количество кода и возможностей.

Я сегодня сильно взволнован из-за того что пишу новость о новом релизе ASP.NET, над которым работает наша команда, и который называется ASP.NET 5. Этот релиз – одно из самых значимых обновлений архитектуры, которое мы делали когда-либо. В рамках этого релиза мы сделали ASP.NET более компактным, модульным и кросс-платформенным, а также ориентированным на облачные хостинги. ASP.NET 5 Preview доступна для скачивания в последнем Visual Studio 2015 CTP, которая стала доступна совершенно недавно.

Я долгое время был разработчиком систем для десктопа. Сначала это был WinForms, потом более мощный и гибкий WPF. С тех пор прошло много времени и курсирует множество слухов и мнений о том, что WPF завершает свою жизнь, ведь сейчас столько разговоров о том, что можно писать настольные приложения на JS. А еще Microsoft усиленно двигает в массы платформу WinRT для разработки новых приложений. Это не могло меня и коллег оставить равнодушным.

Так почему же мы, команда GoSharp конференции (да, да, это о C#), решили сделать акцент на десктопной разработке в разрезе WPF? Далее я хочу показать какие светлые и темные моменты есть в существующем положении фреймворка и почему все же стоит в него вкладывать силы и время.



Существует мнение, что развитие десктопной разработки остановилось в своем развитии и для этого есть несколько предпосылок. Одна из них – остановка, или даже лучше сказать стагнация, в самой базе, в визуальном фреймворке WPF. Значительных обновлений для него не было вот уже лет 5, как может показаться. Официальный тулкит давно не обновлялся, точнее с февраля 2010 года, т.е. вот как раз те самые 5 лет. При этом компании, специализирующиеся на кастом-компонентах, как например DevExpress и Telerik успешно выпускают обновления и составляют планы на будущее относительно WPF. Даже если вы ориентированы на новинки, то компоненты для WinRT все равно используют концепции и общую структуру XAML, который никуда не уходит.
Далее мы хотим представить причины, по которым WPF некоторые считают неактуальным, и опровержение этих причин.

Данная статья входит в получившийся цикл статей о системе документирования Doxygen:

1. Документируем код эффективно при помощи Doxygen
2. Оформление документации в Doxygen
3. Построение диаграмм и графов в Doxygen

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

Что мы можем накопать в Интернетах про самое свежее, о чем есть только слухи? Наш ответ – ничего, что могло бы пролить свет на вопрос. Например, что такое DNX? Репозиторий проекта нам говорит:

DNX (среда исполнения .Net) – содержит код, необходимый для загрузки приложения и его работы, в том числе систему сборки, SDK и CLR хоста.

Лично мне до недавних пор это не говорило ровным счетом ничего, как, наверное, и вам. А ведь это – будущее ASP.NET.

Или, например, многие не понимают, отчего все сходят с ума от возможности запуска ASP.NET 5 на Linux под новейшим ядром CoreCLR… А ведь не сегодня – завтра начнут появляться вакансии разработчиков ASP.NET под Линукс и все мы с вами вдруг поймем: мы старики, а молодые – уже изучили и знают, захватив все дорогостоящие вакансии.

И вообще… Сколько рантаймов сейчас? Куда делся мир с одним-единственным CLR, и почему он вдруг перестал всех устраивать??

Продолжая тему JIT-компиляции .NET'a, сегодня мы рассмотрим диспетчеризацию методов у интерфейсов, generics (как классов, так и отдельных методов вместе с реальными сигнатурами); производить отладку релизных сборок с оптимизациями; разберемся с истинным предназначением типа System.__Canon (это не то, что Вы подумали).

Привет, коллеги!

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

Прежде всего хотим сказать, что быть вегетарианской конференцией мы не планировали, поэтому (но не только) мы сменили площадку и меню теперь будет с мясом!



Первая конференция UI Desktop & Business Application (11 апреля) посвящается «невидимым» с облаков разработчикам настольных корпоративных приложений и в целом всем, кто занимается разработкой и поддержкой бэкенда или разработкой сложного корпоративного интерфейса.

Сейчас почти все митапы и конференции посвящены тому, как перейти в облака или как клево написать сайт. Но до сих пор огромное количество разработчиков создают или поддерживают десктопные приложения, и они могут чувствовать себя обделенными. Мы хотим собрать их вместе, где все внимание будет сосредоточено на их проблемах в решении задач энтерпрайза, чтобы могли поделиться знаниями о своих подходах к решению различных задач.  Мы собираем – профессионалов своего дела, чтобы они поделились с вами своим опытом. Чувствуете себя профессионалом, есть интересный случай из практики, решение которого может быть полезно коллегам?

Тематика докладов:

• разработка системы обновлений
• системы плагинов — MEF
• интересные бизнес-кейсы связанные со стационарной разработкой
• фреймворки для UI, тестирование UI
• встраивание в систему
• особенности или какие-то интересные возможности связанные с EF
• и так далее, все что специфично для Windows программ

Регистрация уже началась. Воспользуйтесь возможностью приобрести билет по начальной цене.

Несмотря на то, что подавляющему большинству приложений не требуется воспроизводить звуковые эффекты, иногда возникает ситуация, когда без звукового эффекта не обойтись. Тогда возникает закономерный вопрос, как воспроизвести звуковой эффект в приложении Windows Phone 8?

Обратившись к документации по Windows Phone Silverlight, можно найти следующие статьи Media for Windows Phone и Playing a sound effect. Исходя из содержания документов можно прийти к мнению, что есть только два способа воспроизведения эффектов в приложениях: использовать MediaElement или XNA. Рассмотрим каждый из этих способов более подробно.

Воспроизведение звуковых эффектов с помощью MediaElement

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

Методы расширения ToArray и ToList — удобный способ быстро преобразовать перечисляемую последовательность (например, Linq-запрос) в массив или в список. Однако, в них есть кое-что беспокоящее меня: оба эти метода очень неэффективны, если они не знают количество элементов в последовательности (что почти всегда происходит, когда вы используете их в Linq-запросе). Давайте сперва рассмотрим метод ToArray (ToList имеет несколько отличий, но принцип практически такой же).

Довелось как-то раз отлаживать вот такой код на C#, который «на ровном месте» падал с NullReferenceException:

	public class Tester {
		public string Property { get; set; }
		public void Foo() {
			this.Property = "Some string"; // NullReferenceException
		}
	}

Да, вот на этой самой строчке с присвоением свойства падал NullReferenceException. Что за дела, думаю — неужели рантайм перестал проверять наличие экземпляра перед вызовом экземплярных методов?

Как оказалось — в некотором роде да, перестал. Правда, и компилятор оказался не тем, за кого себя выдаёт, да и проверки вовсе не гарантированы рантаймом… Подробнее — под катом.

В прошлом году мы провели две конференции .NEXT: в апреле в Питере и в декабре в Москве. Поскольку в этом году апрель у нас и так перегружен мероприятиями, мы решили перенести питерский .NEXT на начало июня.

Итак, в пятницу, 5 июня в Санкт-Петербурге в гостинице «Пулковская» пройдет третья независимая конференция для .NET-программистов .NEXT. Конференция соберет более 400 человек непосредственно на площадке и более 100 человек в онлайне.



Традиционно среди наших спикеров будут:

• лидеры .NET-хабов хабрахабра
• ведущие инженеры JetBrains
• евангелисты Microsoft

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

Я хочу поделиться со всеми читателями интересной темой, с которой столкнулся совсем недавно, и мне она понравилась. Развитие этой темы доставило мне удовольствие и добавило немного опыта в копилку. Вероятно, многие, а может и нет, сталкивались с пулом соединений БД. После ознакомления с этой интересной опцией мне захотелось написать статью и поделиться ею с вами. Возможно, статья получится немного длинной, но я думаю, что данный пост кому-то все же будет интересно почитать, и его заинтересует данная тема. Может быть наработки с этой статьи кто-то использует в своем проекте, в любом случае, мне будет интересно ее писать и рассказывать ее вам.

Данная статья входит в получившийся цикл статей о системе документирования Doxygen:

1. Документируем код эффективно при помощи Doxygen
2. Оформление документации в Doxygen
3. Построение диаграмм и графов в Doxygen

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

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

Что такое фильтры исключений?

Фильтры исключений (Exception Filters) — новая фича C# 6, которая позволяет устанавливать специфические условия для блока catch. Этот блок будет исполнятся только в случае, если указанные условия выполнены. Проиллюстрируем синтаксис небольшим фрагментом кода:

public void Main()
{
  try
  { 
    throw new Exception("E2");
  }
  catch(Exception ex) when(ex.Message == "E1")
  {
    Console.WriteLine("caught E1");
  }
  catch(Exception ex) when(ex.Message == "E2")
  {
    Console.WriteLine("caught E2");
  }
}

Данная статья входит в получившийся цикл статей о системе документирования Doxygen:

1. Документируем код эффективно при помощи Doxygen
2. Оформление документации в Doxygen
3. Построение диаграмм и графов в Doxygen

Это первая и основная статья из упомянутого цикла и она представляет собой введение в систему документирования исходных текстов Doxygen, которая на сегодняшний день, по имеющему основания заявлению разработчиков, стала фактически стандартом для документирования программного обеспечения, написанного на языке C++, а также получила пусть и менее широкое распространение и среди ряда других языков.

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

Наверняка, прочитав заголовок, вы уже поняли, что речь идет про CLRium, который уже анонсирован в Москве (03-04 апреля) и Санкт-Петербурге(29-30 мая). Но теперь его оффлайн могут посетить жители города Екатеринбурга.

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

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

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

Чем мы еще выделяемся? Ценой! Всего за 2,000 можно сходить на семинар и, возможно, получить новое хобби, которое отогреет вас, как программиста и даст не один день беспрерывного кодинга нового расширения на Студию или копания в ядре CoreCLR.

Полный список тем выступлений и ссылки на регистрацию — под катом

Каждый C#-разработчик знает, что C#-компилятор переводит исходный код программы в промежуточный язык под названием Intermediate Language (IL). А за превращение IL в последовательность машинных команд чаще всего отвечает Just-In-Time-компилятор (JIT). Да, на сегодняшний день есть NGen, Mono AOT, .NET Native, но JIT-компиляция всё ещё лидирует в мире .NET-приложений. А вот работает этот самый JIT, знают далеко не все. Если брать в расчёт только реализацию .NET от Microsoft, то стоит различать JIT-x86 и JIT-x64. А ещё за дверями стоит RyuJIT который уже совсем скоро займёт почётное место основного JIT-компилятора. А если вы любите старые версии .NET, то полезно знать, что в разных версиях CLR логика работы JIT отличалась. Исходники у нас теперь открыты, вы можете их посмотреть и осознать, насколько же это большая и сложная тема. Сегодня мы не будем пытаться охватить её, а лишь кратко посмотрим на несколько интересных особенностей отдельных версий JIT-компиляторов. Итак, сегодня в номере:

• Почему короткий метод может не быть заинлайнен и как этого избежать
• JIT-баги: опасные и беспощадные
• Кто и как разматывает циклы
• Чем отличается размотка маленьких и больших циклов

Чем больше я пишу на C# 6, тем больше убеждаюсь в том, насколько оператор ?. (null coalescing operator) помогает писать чистый простой и понятный код. Сегодня я покажу 4 ситуации, в которых он может быть очень полезен.

Большая вложенность

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

var location = default(string);
if (vendor != null)
{
    if (vendor.ContactPerson != null)
    {
        if (vendor.ContactPerson.HomeAddress != null)
        {
            location = vendor.ContactPerson.HomeAddress.LineOne;
        }
    }
}

Но теперь у нас есть C# 6, с ним код можно привести на намного более читаемому виду:

var location = vendor?.ContactPerson?.HomeAddress?.LineOne;

Оператор ?. сделает так, что как только в одном из свойств цепочки окажется null, дальнейшее вычисление выражения производится не будет. Посмотрим ещё несколько примеров.