Понадобилось мне написать некое ASP.NET WebApi приложение, и клиентское приложение на Javascript с использованием этого API. Решено было писать на ASP.NET 5, заодно и изучить новый релиз.

Если бы это было обычное MVC приложение, я бы использовал cookie-based аутентификацию, но кросс-доменные запросы не позволяют передавать куки. Следовательно, необходимо использовать token-based аутентификацию.

Microsoft предлагает свою реализацию — JwtBearerAuthentication. Но охота же самому во всем разобраться. Поэтому я решил написать свою реализацию — BearerAuthentication.

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

Представляю вашему вниманию перевод документа "Coding Guidelines for C# 3.0, 4.0 and 5.0".

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

Статический анализатор кода VisualStudio (который также известен как FxComp) и StyleCop могут автоматически применять многие из правил кодирования и оформления путем анализа скомпилированных сборок. Вы можете сконфигурировать их таким образом, чтобы анализ производился во время компиляции или был неотъемлемой частью непрерывной или ежедневной сборки. Этот документ просто добавляет дополнительные правила и рекомендации, но его вспомогательный сайт www.csharpcodingguidelines.com предоставляет список правил анализа кода, необходимых в зависимости от того, с какой базой кода вы работаете.

Недавно передо мной встала следующая задача: необходимо сравнить множество пар объектов. Но есть один нюанс: объекты — самые что ни на есть object'ы, а сравнивать нужно по всему набору публичных свойств. Причём совершенно необязательно, что типы сравниваемых объектов реализуют интерфейс IEquatable<T>.

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

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

Хочу поделиться нашим opensource-решением для генерации docx документов, которое позволяет заполнять документы по шаблону, оформление которого можно менять в Word без переписывания кода.

Для начала — немного вводных.

Что нам было нужно от шаблонизатора

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

Рисунок Алексея Андреева
Описания книг взяты с сайта Лаборатория фантастики

Если вы регулярно используете Git, то вам могут быть полезны практические советы из этой статьи. Если вы в этом пока новичок, то для начала вам лучше ознакомиться с Git Cheat Sheet. Скажем так, данная статья предназначена для тех, у кого есть опыт использования Git от трёх месяцев. Осторожно: траффик, большие картинки!

Содержание:

1. Параметры для удобного просмотра лога
2. Вывод актуальных изменений в файл
3. Просмотр изменений в определённых строках файла
4. Просмотр ещё не влитых в родительскую ветку изменений
5. Извлечение файла из другой ветки
6. Пара слов о ребейзе
7. Сохранение структуры ветки после локального мержа
8. Исправление последнего коммита вместо создания нового
9. Три состояния в Git и переключение между ними
10. Мягкая отмена коммитов
11. Просмотр диффов для всего проекта (а не по одному файлу за раз) с помощью сторонних инструментов
12. Игнорирование пробелов
13. Добавление определённых изменений из файла
14. Поиск и удаление старых веток
15. Откладывание изменений определённых файлов
16. Хорошие примечания к коммиту
17. Автодополнения команд Git
18. Создание алиасов для часто используемых команд
19. Быстрый поиск плохого коммита

Вниманию читателей «Хабрахабра» представляется перевод статьи Хану Коммалапати и Тома Кристиана об внутреннем устройстве .NET. Существует альтернативный вариант перевода на сайте Microsoft.

В статье рассматривается:

• Системный домен (SystemDomain), Домен общего доступа (SharedDomain) и домен по умолчанию (DefaultDomain)
• Представление объекта и другие особенности организации памяти
• Представление таблицы методов
• Распределение методов

Используемые технологии: .NET Framework, C#

Содержание

1. Домены создаваемые начальным загрузчиком
2. Системный домен
3. Домен общего доступа (разделяемый)
4. Дефолтный домен
5. Загрузчик куч
6. Основы типов
7. Экземпляр объекта
8. Таблица методов
9. Размер базового экземпляра
10. Таблица слотов метода
11. Описатель метода
12. Карта таблиц виртуальных методов интерфейсов и карта интерфейса
13. Виртуальное распределение
14. Статические переменные
15. EEClass
16. Заключение

Я расскажу о применении различных способов аутентификации для веб-приложений, включая аутентификацию по паролю, по сертификатам, по одноразовым паролям, по ключам доступа и по токенам. Коснусь технологии единого входа (Single Sign-On), рассмотрю различные стандарты и протоколы аутентификации.

Перед тем, как перейти к техническим деталям, давайте немного освежим терминологию.

• Идентификация — это заявление о том, кем вы являетесь. В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, итд.
• Аутентификация — предоставление доказательств, что вы на самом деле есть тот, кем идентифицировались (от слова “authentic” — истинный, подлинный).
• Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.

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

Аналогично эти термины применяются в компьютерных системах, где традиционно под идентификацией понимают получение вашей учетной записи (identity) по username или email; под аутентификацией — проверку, что вы знаете пароль от этой учетной записи, а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.

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

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

В предыдущей части были рассмотрены основы уровней изоляции транзакций. Здесь я постараюсь копнуть чуть глубже и рассказать при помощи каких инструментов MS SQL Server реализует уровни изоляции.

Как вы могли видеть в предыдущем разделе, существует два способа поддержания изоляции:

• Основанный на блокировке ресурсов
• Основанный на создании версионной копии ресурсов.

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

Мне часто приходилось сталкиваться с тем, что люди прекрасно понимают, что такое транзакции в базе данных и для чего они нужны, но при этом не всегда умеют ими правильно пользоваться. Безусловно, для достижения 80-го уровня сакрального знания нужно иметь не один год опыта и прочесть множество толстенных книг по SQL. Поэтому в этой статье я даже не буду пытаться описать всё, что может быть связано с транзакциями в MS SQL. Я хочу затронуть один простой, но очень важный вопрос, который разработчики часто упускают из вида – уровни изоляции транзакций.
Несмотря на то, что тема очень проста, во многих источниках она освящается плохо – информации либо очень мало, либо очень много. Т.е. прочитав 5-6 кратких теоретических определений невозможно их применить на практике. Для уверенного понимания предмета статьи нужно обращаться к специализированной литературе, но там информации на столько много, что далеко не каждый может уделить необходимое время для её усваивания.
Сегодня я хочу поделиться своим простым рецептом, который помог мне раз и на всегда запомнить особенности уровней изоляции транзакций и по сей день помогает без проблем принимать взвешенные решения о выборе необходимого уровня.

Вступление

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

Что такое DevOps?

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



Методология DevOps довольно молодая — появилась в 2007 г. и развилась в сообществе IT-профессионалов, что обусловило ее практическую направленность.

Когда и как используют DevOps?

DevOps используют при разработке сложных проектов с развитой инфраструктурой. Использование подходов DevOps полезно, когда:

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

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



Для ускорения взаимодействия команд Development и Operations используют средства автоматизации. Мы можем автоматизировать:

• Управление релизами.
• Мониторинг установленных приложений и доставку команде разработчиков отзывов о работе установленного приложения.

Далее будут описаны средства автоматизации, предлагаемые Microsoft.

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

Доброго времени суток, уважаемые читатели!

Данный пост будет интересен тем, кто использует SQL Server Management Studio (SSMS) при работе c SQL Server.
Речь пойдет о расширении SQL Refactor Studio для SSMS.
Данное расширение позволяет значительно сэкономить время на ежедневных рутинных операциях.

Мое знакомство с облаком Azure началось еще во время практики в DataArt. На третьем месяце обучения к моему ментору Диме пришел коллега Антон и сказал, что ему нужен кто-то для маленького демонстрационного проекта. Так мы и познакомились.

Антон – человек увлеченный и очень активный, умеет вдохновлять идеями. Практика давно закончилась, через какое-то время Антон расстался с DataArt, но продолжает активно интересоваться и продвигать Microsoft Azure, часто консультирует наших коллег по Azure-технологии и предлагает поучаствовать в разных тематических событиях. В частности, он проводит разные семинары, тренинги, встречи, посвященные этому облаку, и не так давно в Киеве было создано первое в нашей стране Ukrainian Azure Community.

Это группа единомышленников, которые активно интересуются технологией, делятся полученными знаниями и общаются на тему Azure. Раз в месяц-два проходят встречи, каждая посвящена отдельной теме. Часто эти встречи проходят как раз в киевском офисе DataArt.

Темой встречи, где, в частности, выступала я, выбрали обмен сообщениями при помощи разных Azure-сервисов. Мы услышали об Azure Storage Queues, Azure Service Bus Queues, Azure Service Bus Topics & Subscriptions.

Поделюсь технической частью. Существует три типа моделей обмена сообщениями.


Рис. 1

В случае с моделью А сообщение отправляется напрямую от отправителя к получателю. Это самая простая модель, но у нее есть недостатки:
— сложно масштабировать (да-да, это ж облака!);
— легко потерять сообщения (например, получатель уходит в офлайн);
— сложно реализовать retry policy.
Из-за этих недостатков в Azure в основном используются модели Б (сообщение попадает в своеобразный брокер, получатель «забирает» его оттуда) и В (сообщение попадает в брокер, а брокер отправляет его получателю).

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

• увеличение скорости чтения/записи данных, что позволяет уменьшить время отклика системы;
• обеспечения «общей памяти» для различных экземпляров, что является одним из необходимых условий горизонтального масштабирования
• снижение стоимости, за счёт более редкого обращения к базе данных (чтение из БД является более дорогой операцией, по сравнению со чтением значения из кеша)

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

Главная цель данной статьи – помочь преодолеть страх, который возникает у тестировщиков ПО (как начинающих, так и опытных) к предстоящему интервью в связи с незнанием грядущего.

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

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

В данной статье хотел бы рассказать про набор полезных дополнений к Visual Studio, которые могут в значительной мере облегчить разработку баз данных на основе MS SQL Server.
Основными преимуществами использования SSDT я бы выделил следующее:

• возможность простого изменения (refactoring) схемы базы (можно переименовать колонку таблицы и все Views, Functions и Stored Procedures ссылающиеся на неё автоматически будут исправлены для отражения изменений)
• создание юнит тестов для базы данных
• хранение структуры базы данных в Source Control
• сравнение схемы/данных c возможностью генерации скрипта для приведения схемы/данных к требуемому состоянию

Безусловно на этом плюсы использования SSDT не заканчиваются, но остальное не так сильно впечатляет, как то, что упомянуто выше. Если вас интересует, как воспользоваться этими и другими преимуществами — прошу под кат.

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