Не секрет, что C# сегодня популярный и динамично развывающийся язык, в отличие от своего прямого конкурента — языка Java, который в плане функциональности переживает период застоя. Основное неоспоримое преимущество Java — настоящая кросплатформенность, а не унылая и ограниченная, как у C#.

C# — простой язык, благодаря простоте живёт и PHP. Но в то же время он весьма функциональный, и имеет статус «гибридного» языка, совмещая в себе различные парадигмы, встроенную поддержку как императивного стиля программирования, так и функционального.

Как и любой язык, шарп имеет свои тонкости, особенности, «подводные камни» и малоизвестные возможности. Что я имею ввиду? Читайте под катом…

Хочу поделиться недавно приобретенным в C# опытом по загрузке и обработке в памяти больших объемов данных. Все нижеуказанное касается Visual Studio 2008 и .Net Framework 3.5.1, на случай каких-либо отличий в других версиях языка или библиотек.

Итак, у нас возникли следующие задачи:
1. Расположить в памяти до 100 миллионов записей, состоящих из строки, длиной 16 символов (уникальный ключ) и двух целочисленных значений, длиной 4 байта каждый;
2. Быстро находить и редактировать запись по ключу.

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

Вас ожидают две части:

• Создание простейшего решения (solution) со стандартными конечными точками (default endpoints)
• Добавление и настройка конечных точек вручную

Прошло много времени с тех пор, как я написал оригинальный пост Простой пример использования WCF. Это было еще до выхода Visual Studio 2008, и с тех пор многое изменилось. Поскольку множество людей по-прежнему задают вопросы в комментариях к тому посту, давайте посмотрим, что в настоящее время мы должны сделать, чтобы поднять и запустить службу (service), а также обратиться к ней из клиентского приложения.

Иногда полезно представить граф в графической форме, так чтобы была видна структура. Можно привести десятки примеров, где это может пригодиться: визуализация иерархии классов и пакетов исходного кода какой-нибудь программы, визуализация социального графа (тот же Twitter или Facebook) или графа цитирования (какие публикации на кого ссылаются) и т.д. Но вот незадача: количество ребер в графе зачастую настолько велико, что нарисованный граф просто невозможно разобрать. Взгляните на эту картинку:



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