C# *

NetFlow это сетевой протокол, созданный компанией Cisco Systems для учёта сетевого трафика. Наиболее распространёнными версиями данного протокола являются 5 и 9. Девятая версия более гибкая так как используются шаблоны, согласно которым присылаются данные. В пятой версии данные присылаются согласно спецификации.


Система сбора информации о трафике по протоколу NetFlow состоит из следующих компонентов:

• Сенсор. Устройство (маршрутизатор, L3-коммутатор) собирающее статистику по проходящему через него трафику;
• Коллектор. Занимается сбором данных от сенсора и помещает их в хранилище;
• Анализатор. Анализирует данные, которые собрал коллектор и формирует отчёты.

О разработки части функций анализатора на C#, а точнее разбор пакетов NetFlow я и расскажу

Исследуя обширные пространства интернета мне пришлось потрудиться над тем как же все таки создать не тяжеловесный код на asp.net c# для обработки так называемых «свиных ушей», которые содержат классическую модель родитель-потомок в базе данных. Сразу оговорюсь база в SQL Server 2008, который уже имеет возможность работы с иерархическими данными в ОТВ (CTE — английский вариант аббревиатуры).

Автоматизация получения реестра запрещенных ресурсов средствами C#, OpenSSL и фильтрация средствами RouterOS на базе оборудования MikroTik



Внимание! Статья изменена согласно последних изменений на 19/03/2014

Долгое время я искал в сети пример простейшего tracker-а на C#, но, к сожалению, мои поиски успехом не увенчались. Поэтому я решил попробовать себя в написании tracker-а на C#, а получив более-менее рабочую версию — поделиться опытом ее создания со всеми. А заодно и получить как можно больше советов по ее усовершенствованию.

Но давайте начнем с начала…

Приветствую!

Вдохновленный статьёй Эстафета из 50-ти квайнов попробовал повторить действо, но только на C# и n=2, получилась неплохая задачка!

В начале работы junior разработчиком мне пришлось столкнуться с таким малопонятным для меня на то время понятием, как Inter-Process Communication. Это была полная дикость для начинающего программиста, который и в рамках логики одного приложения ориентировался то с большим трудом. Стоит упомянуть, что проект написан на Delphi, а сам механизм IPC реализован с помощью File Mapping и Windows Messages.
Что удивительно, узнал я том, как вся эта система работает изнутри, спустя едва ли не год, когда пришлось маленько с ней повозиться. И только тогда я окончательно осознал, насколько высококлассной была её реализация, а API – удобен. Кому интересна реализация чего-то похожего на вышеупомянутую систему под С# – прошу под кат.

Привет, Хабр!

Вы уже наверное догадались, о чем этот пост. Да-да, мы рады представить вашему вниманию свежий ReSharper 8, наш плагин для повышения производительности и качества кода при разработке в Visual Studio. Благодаря участию в партнерской программе Microsoft Visual Studio нам удалось оперативно привести ReSharper 8.0 в соответствие с недавно объявленной версией Microsoft Visual Studio 2013 Preview. Теперь продукт поддерживает целых пять версий Visual Studio, включая 2005, 2008, 2010 и 2012. Когда произойдет окончательный выпуск Visual Studio 2013, при необходимости будет выпущено поддерживающее его обновление для ReSharper.



«Восьмерка» включила в себя улучшения и нововведения в следующих областях:

• Автодополнение кода;
• Навигация;
• Поддержка XAML;
• Поддержка CSS;
• Новые рефакторинги;
• Новый механизм коррекции ошибок «fix in scope»;
• Шаблоны для создания наборов файлов;
• Архитектурные инструменты в ReSharper;
• Упрощение работы с расширениями.

Кроме того, ReSharper 8 выходит за рамки Visual Studio: теперь мы предоставляем бесплатный автономный инструмент с сотнями инспекций кода, доступных в ReSharper, а также функцией поиска дубликатов в коде. Новый продукт под названием ReSharper Command Line Tools можно интегрировать с вашим Continuous Integration сервером или системой контроля версий.

Мы рады сообщить, что только что поступил из типографии тираж нового издания книги «CLR via C» Джеффри Рихтера!
Четвертое издание книги охватывает версии .NET Framework 4.5, а также Visual Studio 2012 и C# 5.0.

Добрый день!

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

За примером реализации прошу под кат.

Несмотря на некоторый скепсис, по поводу первой части материала, как и обещал, публикую результаты, и то как они были получены.
В основном манипуляции производились с данными, хранимыми в Excell, таблицы которого сформированы по 3НФ, поэтому в некоторых местах кода вместо индексов используются данные из ячеек. Итак согласно алгоритму необходимо получить коэффициент клуба и климатическую характеристику города, в котором этот клуб принимает соперников = команда: {климат, рейтинг} — это и есть основная цель. Поехали.

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

Оглавление

1. Введение
2. Инициализация приложений Prism
3. Управление зависимостями между компонентами
4. Разработка модульных приложений
5. Реализация паттерна MVVM
6. Продвинутые сценарии MVVM
7. Создание пользовательского интерфейса
   
   1. Рекомендации по разработке пользовательского интерфейса
8. Навигация
   1. Навигация на основе представлений (View-Based Navigation)
9. Взаимодействие между слабо связанными компонентами

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

При построении модели взаимодействия между модулями, необходимо знать отличия между подходами, чтобы знать, какой из них применить в конкретном сценарии. Библиотека Prism предоставляет следующие подходы:

• Использование команд (Solution commanding). Используйте для реагирования на действия пользователя.
• Контекст региона (Region context). Используйте для передачи контекстной информации от host-элемента управления к представлениями в регионе. Этот подход в некотором роде аналогичен DataContext, но не полагается на него.
• Общие службы (Shared services). Вы можете вызвать метод на сервисе, который, в свою очередь, сгенерирует событие, на которое могут быть подписаны получатели. Используйте этот подход в том случае, если все остальные подходы не применимы.
• Агрегация событий (Event aggregation). Для передачи сообщений между моделями представлений, презентерами, или контроллерами при отсутствии ожиданий о непосредственной реакции на сообщение.

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

Оглавление

1. Введение
2. Инициализация приложений Prism
3. Управление зависимостями между компонентами
4. Разработка модульных приложений
5. Реализация паттерна MVVM
6. Продвинутые сценарии MVVM
7. Создание пользовательского интерфейса
   
   1. Рекомендации по разработке пользовательского интерфейса
8. Навигация
   1. Навигация на основе представлений (View-Based Navigation)
9. Взаимодействие между слабо связанными компонентами

Навигация на основе представлений (View-Based Navigation)

Несмотря на то, что навигация на основе состояний может быть полезна в сценариях, описанных ранее, тем не менее, навигация в приложении часто требует замены одного представления на другое. В Prism, такой вид навигации называется «навигация на основе представлений (view-based navigation)».

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

• Цель навигации — контейнер для добавляемых, или удаляемых представлений — может обрабатывать навигацию разными способами при добавлении и удалении представлений, или может визуализировать процесс навигации по-разному. Во многих случаях, целью навигации является обычный Frame, или ContentControl, и представления просто отображаются внутри этих элементов управления. Однако существует множество сценариев, когда целью навигации является другой вид элементов управления, таких как TabControl, или ListBox. В таких случаях, навигация может потребовать активации или выделения уже существующего представления, или добавление нового представления.
• Приложению часто будет требоваться, каким-либо образом идентифицировать представление, к которому должна быть выполнена навигация. Для примера, в web-приложениях, страница, к которой выполняется навигация, напрямую идентифицируется по URI. В клиентских приложениях, представление может быть идентифицировано по имени его типа, по расположению файла ресурсов, или множеством других способов. В составных приложениях, состоящих из слабо связанных модулей, представления зачастую определены в раздельных модулях. Отдельные представления, в таких случаях, должны иметь возможность быть идентифицированы без создания дополнительных зависимостей между модулями.
• После идентификации представления, процесс его создания и инициализации должен быть тщательно скоординирован. Это особенно важно при использовании паттерна MVVM. В таком случае, представления и соответствующая модель представления должны быть созданы и ассоциированы друг с другом во время совершения навигации. В случае использования контейнера внедрения зависимостей, такого как Unity, или MEF, при создании модели представления и/или представления может потребоваться использование особого механизма конструирования.
• MVVM паттерн позволяет отделить UI приложения от его логики взаимодействия с пользователем и бизнес-логики. Однако процесс навигации может охватывать как UI, так и логику приложения. Пользователь может начать навигацию внутри представления, в результате чего представление будет обновлено. Но часто будет требоваться возможность инициировать и скоординировать навигацию из модели представления. Важным аспектом для рассмотрения, является способность чётко разделить навигационное поведение между представлением и моделью представления.
• Приложению часто может потребоваться передавать параметры, или контекст, представлению для его корректной инициализации. Для примера, если пользователь производит навигацию к представлению для редактирования информации о выбранном клиенте, ID этого клиента, или его данные, должны быть переданы в представление, для отображения в нем корректной информации.
• Многим приложениям необходимо тщательно координировать навигацию для уверенности, что будут выполнены определённые бизнес-требования. К примеру, пользователю может быть показано всплывающее сообщение о некорректности введённых им данных, во время попытки навигации к другому представлению. Этот процесс требует координации между предыдущим и новым представлениями.
• Наконец, большинство современных приложений позволяют пользователю производить навигацию к предыдущему, или к следующему представлению. Аналогично, некоторые приложения реализуют свой рабочий процесс, используя последовательность представлений, или форм и позволяют пользователю производить по ним навигацию вперёд или назад, добавляя или редактируя данные, перед тем, как завершить задачу и отправить все сделанные изменения одним пакетом. Такие сценарии требуют некоторого механизма журналирования, для того, чтобы последовательность навигации могла быть сохранена, повторена, или предопределена.

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

Название оригинала: Building Windows 8 Apps with C# and XAML
Автор: Дж. Ликнесс
Перевод книги: Заика А. А.
Дата выхода: июль 2013г.

Книга на сайте издательства.
Книга на Ozon.ru

Электронная версия в продаже!

Подробное оглавление
Отрывок

По следам поста Визуализация списков в отладчике Visual Studio или новое слово от «BugAid For Visual Studio», что бы чисто добить тему, хотелось бы рассмотреть возможности расширения BugAid для визуализации вычисления выражения в операторе if.

Три месяца назад ко мне обратился хороший товарищ и коллега по работе с просьбой написать небольшую программу для проведения психологического тестирования. Я, до этого писавший исключительно для мелких нужд офисной автоматизации на vba, vb, vb.net, решил воспользоваться моментом и за время проекта подучить C#. К слову, проект простой, всего 5 психодиагностических методик. Позже оказалось, что мечта его — система распознавания бланков этих методик. Ситуация усложнилась. Стало понятно, что основное количество времени я потрачу на распознавание.

Оглавление

1. Введение
2. Инициализация приложений Prism
3. Управление зависимостями между компонентами
4. Разработка модульных приложений
5. Реализация паттерна MVVM
6. Продвинутые сценарии MVVM
7. Создание пользовательского интерфейса
   
   1. Рекомендации по разработке пользовательского интерфейса
8. Навигация
   1. Навигация на основе представлений (View-Based Navigation)
9. Взаимодействие между слабо связанными компонентами

Во время взаимодействия с пользователем, UI приложения может подвергаться значительным изменениям, в зависимости от того, какие действия должен выполнять пользователь, и с какими данными он работает. Процесс, когда приложение координирует изменения пользовательского интерфейса, часто называют «навигацией (navigation)».

Зачастую, «навигация» означает, что одни элементы управления удаляются, а другие добавляются в пользовательский интерфейс. В других случает, это означает обновление вида уже существующих элементов управления. К примеру, некоторые элементы управления могут скрываться, или сворачиваться, а другие, наоборот, появляться, или разворачиваться. Аналогично, «навигация» может значить, что данные, показываемые в некоторых элементах управления, могут обновляться для отображения текущего состояния приложения. К примеру, при сценарии "master-detail", данные, отображаемые в detail-представлении, обновляются в зависимости от того, какой элемент выбран в master-представлении. Все эти сценарии могут быть расценены, как «навигация», так как пользовательский интерфейс обновляется для отображения внутреннего состояния приложения и того, какую задачу выполняет пользователь в текущий момент.

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

Реализация навигации в WPF и Silverlight часто может быть довольно прямолинейной, так как обе эти платформы предоставляют встроенную поддержку навигации. Однако реализация навигации может стать довольно сложной, при использовании шаблона MVVM, или в составных приложениях, использующих несколько слабо связанных модулей. Prism предоставляет руководство по реализации навигации в подобных случаях.

Когда приходится просматривать элементы списка (массива) в отладчике Visual Studio, например, в окне QuickWatch часто сталкивашься с не удобством просмотра сложного (или длинного) списка данных. Тяжело увидеть, например, значения поля всех элементов списка.
Данный пост показывает несколько «встроенных» способов решения этой проблемы и возможности расширения BugAid.
мало букв, но достаточно картинок.

Модульные тесты используются при разработке программного обеспечения. Они могут быть созданы как после написания исходного кода, так и до этого, все зависит от ваших предпочтений и вероисповедания, либо предпочтений вашей компании. Разработка через тестирование(TDD) вызывает довольно спорное впечатление. Кто-то считает, что это довольно бесполезная вещь, однако склонен не согласиться. Бесполезным TDD назвать точно нельзя. Создание теста покрывающего предполагаемое изменение в программе, а затем написание кода который бы позволил пройти этот тест, заметно упрощает разработку. Модульные тесты так же используются для проверки уже созданного функционала. Однако достичь 100% покрытия кода программы модульными тестами практически невозможно.