В предыдущих двух статьях мы рассмотрели основы взаимодействия по протоколу SIP.

1. Взаимодействие клиентов SIP. Часть 1 (Простое взаимодействие)
2. Взаимодействие клиентов SIP. Часть 2 (Взаимодействие с использованием Proxy-сервера)

Далее я предлагаю разобраться с такой важной составляющей SIP, как SIP URI. Мы сталкивались с ними раньше, когда говорили о полях From, To и других, однако не уделяли им должного внимания.

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

Привет хабр!

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

"Пфф, ссылки они и в Африке ссылки, чего тут разбираться?" — скажете вы, тогда я задам вопрос:

Что есть что и куда нас приведет?

• http://example.com
• www.example.com
• //www.example.com
• mailto:user@example.com

Если вы не знаете однозначного ответа или вам просто интересно и если вы не боитесь огромного количества трехбуквенных аббревиатур — милости прошу под кат.

Скажите, приходилось ли вам слышать о новых службах Azure: Elasticville, StorageWart и API Gatesian? Разумеется, нет, ведь эти названия были придуманы только что. В этой статье мы делимся с вами шпаргалкой, в которой понятным языком описана экосистема Microsoft Azure.

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

Хитрость в том, чтобы сразу определить значение слова «действительный».

Мы разработчики — технические ребята, так что наиболее логичным будет проверить на соответствие официальным критериям. Вот некоторые примеры валидных адресов email, которые соответствуют критериям.


^{en.wikipedia.org/wiki/Email_address#Valid_email_addresses}

В первый раз я услышал о CQRS, когда устроился на новую работу. В компании, в которой работаю и по сей день, мне сразу сказали что на проекте, над которым я буду работать используется CQRS, Event Sourcing, и MongoDB в качестве базы данных. Из этого всего я слышал только о MongoDB. Попытавшись вникнуть в CQRS, я не сразу понял все тонкости данного подхода, но почему-то мне понравилась идея разделения модели взаимодействия с данными на две — read и write. Возможно потому что она как-то перекликалась с парадигмой программирования “разделение обязанностей”, возможно потому что была очень в духе DDD.

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

Сразу хочу уточнить что я работал только со связкой CQRS + Event Sourcing, и никогда не пробовал просто CQRS, так как мне кажется что без Event Sourcing он теряет очень много бенефитов. В качестве CQRS фреймворка я буду использовать наш корпоративный Paralect.Domain. Он чем-то лучше других, чем то хуже. В любом случае советую вам ознакомиться и с остальными. Я здесь упомяну только несколько фреймворков для .NET. Наиболее популярные это NCQRS, Lokad CQRS, SimpleCQRS. Так же можете посмотреть на Event Store Джонатана Оливера с поддержкой огромного количества различных баз данных.

Начнем с CQRS

Что же такое CQRS?
CQRS расшифровывается как Command Query Responsibility Segregation (разделение ответственности на команды и запросы). Это паттерн проектирования, о котором я впервые услышал от Грега Янга (Greg Young). В его основе лежит простое понятие, что вы можете использовать разные модели для обновления и чтения информации. Однако это простое понятие ведет к серьёзным последствиям в проектировании информационных систем. (с) Мартин Фаулер

Введение

Вот не люблю я изобретать велосипед и статью я бы эту не написал, но пришлось. Про REST сказано уже довольно много. Многие поставщики веб служб готовы клясться, что их службы являются RESTful. Во время собеседования вы точно услышите хотя бы несколько вопросов про REST, независимо от того это собеседования для бэкенд, мобайл или фронтенд разработчика. Я вот помню как-то во время одного собеседования меня задали такой вопрос: «Вот вы написали в своем резюме, что знайте REST․ Ответьте пожалуйста, какой HTTP код вы получите, если при запросе к RESTful сервису ресурс не найден?». Ответ 404 был принят единогласно. Если честно, я так и не понял, как этот вопрос помог понять знаю ли я REST или нет, но одно могу уверенно сказать: REST понимают далеко не все. Вот некоторые вопросы, которые мучали меня долгое время:

1. Зачем REST стал таким трендовым? Это архитектура была же предложена еще в 2000 году?
2. Что я получу если моя служба будет RESTful?
3. Как определить является ли служба RESTful или нет?
4. Как правильно должны создаваться URL REST служб?
5. Какие http методы и коды должны быть использованы в RESTful службе?

Если вы не можете дать исчерпывающего ответа хотя бы на один из этих вопросов, то продолжайте чтение. Если вы можете однозначно ответить на все эти вопросы, можете привести формат правильного URL, считайте, что GET, POST, PUT, DELETE обязательно должны соответствовать CRUD операциям с ресурсами, то вам обязательно надо продолжать чтение.

1. Введение

В данной статье я хотел бы рассказать об этих трёх буквах, постоянно находящихся на слуху, но для многих являющихся тайной за семью печатями, а так же привести ряд ресурсов, с которыми неплохо было бы познакомиться при желании продолжить развитие в проектировании на основе предметной области (DDD: Domain Driven Design).

Зачем вообще искать IP?

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

• Данные терминалы будут общедоступными и работать в режиме киоска. Поэтому идея добавить на них какую-нибудь панель администрирования, сразу же отпадала, ибо случайный юзер сможет «наклацать» в настройках IP-адреса что ему заблагорассудится.
• Можно было бы зашить в терминалы IP-адрес сервера обновлений, но так как сервер, в моем случае, — это всего лишь десктопное приложение, которое пользователь может запускать на любом компьютере в подсети, то такое решение тоже не подошло.
• Взяв в учет предыдущие два пункта, можно было бы реализовать панель администрирования, со входом по паролю, но, все же, постоянно вбивать новый IP-адрес сервера обновлений — это лишняя головная боль обслуживающему персоналу.

Поэтому от идеи «забирать» я перешел к идее «отправлять» и начал мастерить реализацию автоматического поиска IP-адресов на Python 3.

Здравствуйте, меня зовут Александр Зеленин, и я на дуде игрец веб-разработчик. Полтора года назад я рассказывал о разработке онлайн игры. Так вот, она немного разрослась… Суммарный объём исходного кода превысил «Войну и мир» вдвое. Однако в данной статье я хочу рассказать не о коде, а об организации инфраструктуры проекта.

С выходом .NET Framework 4.0 в состав BCL была добавлена библиотека Task Parallel Library (TPL), реализующая параллелизм на основе задач. В основе библиотеки лежат типы Task и унаследованный от него тип Task. Эти типы являются обёртками для асинхронных операций; они позволяют абстрагироваться от таких технических деталей, как, например, потоки и синхронизировать асинхронные операции друг с другом.

В этой же версии .NET Framework появился мини-framework для кооперативной отмены асинхронных операций. Состоит он из всего трёх типов:

• CancellationTokenSource — создаёт маркёры отмены (свойство Token) и обрабатывает запросы на отмену операции (перегруженные методы Cancel/CancelAfter).
• CancellationToken — маркёр отмены; позволяет несколькими способами отслеживать запросы на отмену операции: опросом свойства IsCancellationRequested, регистрацией callback-функции (через перегруженный метод Register), ожиданием на объекте синхронизации (свойство WaitHandle).
• OperationCanceledException — исключение, выброс которого по соглашению означает, что запрос на отмену операции был обработан и операция должна считаться отменённой. Предпочтительный способ генерации исключения — вызов метода CancellationToken. ThrowIfCancellationRequested.

Механизм отмены через CancellationToken является стандартным для TPL — есть перегрузки методов, принимающих CancellationToken, исключения OperationCanceledException специальным образом обрабатываются и т.д. Однако, как и в любом другом API, есть свои тонкости, хитрости, best practices.

В рамках своей научной активности реализовал так называемый Федеративный Фильтр Калмана (Federated Kalman Filter). В этой статье рассказывается о том, что такое «Федеративный ФК», чем он отличается от обобщенного, а также описывается консольное приложение, реализующее данный фильтр и генетические алгоритмы для подбора параметров его математической модели. Приложение было реализовано с использованием TPL (Task Parallel Library), поэтому пост будет интересен не только специалистам по цифровой обработке сигналов.

UPD1: после прочтения двух недавних статей решил тоже присоединиться к эксперименту/исследованию/авантюре (называйте как хотите). В конце статьи добавил еще один опрос — "Стали бы Вы поощрать рублем такие узко специализированные статьи на Хабрахабре?".

Автор: Вячеслав Михайлов, Solutions Architect.

В этой статье я поделюсь опытом проектирования RESTful API — на конкретных примерах покажу, как делать хотя бы простые сервисы красиво. Также мы поговорим, что такое API и зачем он нужен, поговорим об основах REST — обсудим, на чем его можно реализовывать; коснемся основных веб-практик, которые зависят и не зависят от этой технологии. Также узнаем, как составлять хорошую документацию, затрачивая на это минимум усилий, и посмотрим, какие существуют способы нумерации версий для RESTful API.

Часть 1. Теория

Итак, как мы все знаем, API — application programming interface (интерфейс программирования приложений), набор правил и механизмов, с помощью которых одно приложение или компонент взаимодействует с другими

Почему хороший API — это важно?

• Простота использования и поддержки. Хороший API просто использовать и поддерживать.
• Хорошая конверсия в среде разработчиков. Если всем нравится ваш API, к вам приходят новые клиенты и пользователи.
• Выше популярность вашего сервиса. Чем больше пользователей API, тем выше популярность вашего сервиса.
• Лучше изоляция компонентов. Чем лучше структура API, тем лучше изоляция компонентов.
• Хорошее впечатление о продукте. API — это как бы UI разработчиков; это то, на что разработчики обращают внимание в первую очередь при встрече с продуктом. Если API кривой, вы как технический эксперт не будете рекомендовать компаниям использовать такой продукт, приобретая что-то стороннее.

Теперь посмотрим, какие бывают виды API.

Виды API по способу реализации:

• Web service APIs
  
  • XML-RPC and JSON-RPC
  • SOAP
  • REST
  
  
• WebSockets APIs
• Library-based APIs
  
  • Java Script
  
  
• Class-based APIs
  
  • C# API
  • Java
  
  

Виды API по категориям применения:

• OS function and routines
  
  • Access to file system
  • Access to user interface
  
  
• Object remoting APIs
  
  • CORBA
  • .Net remoting
  
  
• Hardware APIs
  
  • Video acceleration (OpenCL…)
  • Hard disk drives
  • PCI bus
  • …
  
  

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

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

Moq – это простой и легковесный изоляционный фреймврк (Isolation Framework), который построен на основе анонимных методов и деревьев выражений. Для создания моков он использует кодогенерацию, поэтому позволяет «мокать» интерфейсы, виртуальные методы (и даже защищенные методы) и не позволяет «мокать» невиртуальные и статические методы.

ПРИМЕЧАНИЕ
На рынке существует лишь два фрейморка, позволяющих «мокать» все, что угодно. Это TypeMockIsolator и Microsoft Fakes, доступные в Visual Studio 2012 (ранее известные под названием Microsoft Moles). Эти фреймворки, в отличие от Moq, используют не кодогенерацию, а CLR Profiling API, что позволяет вклиниться практически в любой метод и создать моки/стабы даже для статических, невиртуальных или закрытых методов.

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

Вот простой пример, как вы ответите на следующий вопрос: сколько значимых типов из .NET Framework содержит конструкторы по умолчанию? Интуитивным ответом кажется "все", и будете не правы, поскольку на самом деле, ни один из значимых типов .NET Framework не содержит конструктора по умолчанию.

Всем привет! Хочу поделиться своим опытом использования ASP.Net Core и Angular 2 с использованием SignalR.

Будучи программистом 1С, часто приходится решать задачи, которые на 1С решить сложно или невозможно. Очень помогает знание .Net. Но вот, что касается клиентской части сайтов, то здесь много тонкостей (JavaScript, CSS, JQuery итд), которые быстро забываются, если ими не пользоваться.

Angular 2 позволяет значительно упростить создание клиентской части. Так TypeScript значительно ближе к C# (и главное позволяет использовать Руслиш), а с шаблонами несложно разобраться зная Razor и Xaml.

Главное, что вы работаете с данными, по аналогии с WPF. При этом есть куча контролов.

Хочу поделиться с такими же бедолагами как я, или кто только начинает изучение Angular 2, ASP.Net Core, так как потратил значительное время, на поиски материалов для изучения.

Для тренировки на кошках был выбран мой проект 1C Messenger для отправки сообщений, файлов и обмена данными между пользователями 1С, вэб страницы, мобильными приложениями а ля Skype, WhatsApp. Исходники Здесь

Пока не вышел. Net Core 1.2 и NetStandard 2, сейчас нет поддержки клиента для SignalR под .Net Core

Итак, начнем. Для работы нам потребуется:

1. ASP.NET Core + Angular 2 шаблон для Visual Studio
2. Руководство по ASP.NET Core
3. Руководство по Angular 2
4. Руководство по TypeScript
5. Компоненты от PrimeNG
6. Компоненты Bootstrap

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

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

Перед программистами Edison Software была поставлена задача — разработать программные компоненты, обеспечивающие взаимодействие между ПО Axxon Next и Immix. Сервис SureView очень популярен в Великобритании, и дабы укрепить свои позиции на рынке видеонаблюдения, разработчики Axxon Next (ITV) решили совершить хитрый стратегический ход и интегрироваться, отдав исполнение заказа на аутсорс компании Edison Software. На разработку и отладку плагина интеграции ушло 316 часов.



ПО Axxon Next является продуктом российской компании ITV, являющейся разработчиком программного обеспечения для систем безопасности и видеонаблюдения.

Axxon Next — высокопроизводительная система видеонаблюдения, с интуитивно понятным пользовательским интерфейсом, поддерживающая более 6000 наименований IP-устройств и позволяющая строить легко масштабирующиеся системы видеонаблюдения любой сложности. Следует отметить, что полный функционал системы включен в любую лицензию, даже если в ней будет всего одна камера.

ПО Immix является продуктом американской компании SureView systems и представляет собой видео-ориентированную программную платформу, предназначенную для приема тревожных событий из систем видеонаблюдения, контроля доступа, платформ автоматизации и ситуационных систем информирования.

Результатом разработки должен был стать плагин для ПО SureView, предоставляющий возможность использования из ПО SureView следующих возможностей ПО Axxon Next.

• Отображение в ПО SureView живого видео от ПО Axxon Next.
• Проигрывание и управление проигрыванием в ПО SureView архива видео, хранящегося под управлением ПО Axxon Next.
• Управление из ПО SureView поворотными (PTZ) устройствами, подключенными к ПО Axxon Next, включая использование предустановок (Presets).
• Получение в ПО SureView событий о возникших тревожных сообщениях от ПО Axxon Next.

Лежим

Заказчик, чьи сайты я поддерживал ранее, обратился с тем, что сайт лежит и отдает 500 ошибку. У него стандартный сайт на ASP.NET WebForms, не скажу, что очень нагруженный, но бывали проблемы с производительностью базы данных (MS SQL Server на отдельном сервере). Недавно сервер БД поменяли и перенесли данные.

Этот сайт не основной бизнес заказчика, поэтому практически не обслуживался. У него не настроено никакого мониторинга  и сбора метрик и вообще за ним особо не следят.

Данные телеметрии

Какие аномалии бросились в глаза:

1. Процесс w3wp использовал более 50% CPU (обычно сильно меньше).
2. Количество потоков в этом процесс стабильно прирастало (сайт не успевал обслужить клиентов).
3. Диск на сервере БД использовался на 100% (Active Time).
4. Длина очереди обращений к диску с базами проекта была большой (обычно в районе нуля-единиц).
5. Оперативная память на сервер БД использована полностью.
6. Профайлер показал, что есть один горячий метод, который ходит в БД.