В Роскосмосе распространено мнение, что коммерческие успехи компании SpaceX объясняются исключительно господдержкой и искусственно заниженной ценой на ракеты — демпингом. Компания Илона Маска оставила Роскосмос практически полностью без коммерческих заказов на тяжелые ракеты, поэтому оправдание приходится искать в происках Пентагона, Госдепа или ЦРУ. Пора отделить факты от домыслов и узнать в чем секрет коммерческого успеха SpaceX.

Предисловие

Довольно часто пользователи, разработчики, администраторы и т д СУБД MS SQL Server встречаются с проблемами производительности БД или СУБД в целом.

В данной статье будут даны общие рекомендации по настройке оптимизации как БД, так и всей СУБД в целом. Также будут даны основные рекомендации по взаимодействию приложения .NET и MS SQL Server. Будут даны примеры решения на большинство из приведенных ниже рекомендаций.

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

Сегодня команда ASP.NET анонсировала, что проект Blazor был перемещён в репозиторий организации ASP.NET. Мы начинаем стадию эксперимента, чтобы понять сможем ли мы развить Blazor в поддерживаемый продукт. Это большой шаг вперёд!



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

В этом посте я хочу поглубже поговорить о технических деталях для тех, кому интересно как же это работает.

CQRS — это стиль архитектуры, в котором операции чтения отделены от операций записи. Подход сформулировал Грег Янг на основе принципа CQS, предложенного Бертраном Мейером. Чаще всего (но не всегда) CQRS реализуется в ограниченных контекстах (bounded context) приложений, проектируемых на основе DDD. Одна из естественных причин развития CQRS — не симметричное распределение нагрузки и сложности бизнес-логики на read и write — подсистемы Большинство бизнес-правил и сложных проверок находится во write — подсистеме. При этом читают данные зачастую в разы чаще, чем изменяют.

Не смотря на простоту концепции, детали реализации CQRS могут значительно отличаться. И это именно тот случай, когда дьявол кроется в деталях.

Привет, Хабр! 14 сентября было объявлено о выпуске первой версии SignalR для ASP.Net Core, в связи с чем я решился перевести заметку, посвященную даному событию, немного её дополнив. Оригинал заметки доступен в блоге на MSDN.

Что нового?

SignalR для ASP.Net Core является переписанной с нуля версией оригинального SignalR. Новый SignalR проще, более надёжен и легче в применении. Несмотря на эти внутренние изменения, мы старались сделать API библиотеки наиболее близким к предыдущим версиям.

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

Даже если вам повезло и ваш продукт имеет минимум зависимостей от внешних сервисов, скорее всего внутри он разбит на компоненты (классика жанра — backend/frontend), которые можно и нужно тестировать по отдельности. Это значит, что внешней зависимостью уже является api соседнего компонента, команда разработки которого совсем не горит желанием предоставлять вам инструменты для управления его состоянием.

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

Решить эту проблему может мокирование API внешних систем.

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

В данной статье я опишу Mountebank: инструмент, который позволяет быстро и очень гибко мокировать API прямо из автотестов без необходимости писать свой веб-сервис.

Возможности mountebank'а:

• мокирование API на протоколах tcp, http, https, smtp;
• мокирование неограниченного количества API одновременно;
• гибкое переопределение логики mock-API прямо во время тестов используя конфигурационный API mountebank'a;

Репозиторий является посредником между слоем доступа к данным и доменным слоем,
работая как in-memory коллекция доменных обектов. Клиенты создают декларативные
описания запросов и передают их в репозиторий для выполнения.
  — свободный перевод Мартина Фаулера

EntityFraemwork предоставляет нам готовую реализацию паттернов Repository: DbSet<T> и UnitOfWork: DbContext. Но мне часто приходится видеть, как коллеги используют в своих проектах собственную реализацию репозиториев поверх существующих в EntityFraemwork.

Чаще всего используется один из двух подходов:

1. Generic Repository как попытка абстрагироваться от конкретного ORM.
2. Repository как набор запросов к выбранной таблице БД (паттерн DAO).

И каждый из этих подходов содержит недостатки.

Я хочу рассказать про созданный мною web редактор для «визуального программирования» и его историю создания.

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

В этом руководстве мы рассмотрим создание с нуля full-stack приложения с использованием Redux и Immutable-js. Применив подход TDD, пройдём все этапы конструирования Node+Redux бэкенда и React+Redux фронтенда приложения. Помимо этого мы будем использовать такие инструменты, как ES6, Babel, Socket.io, Webpack и Mocha. Набор весьма любопытный, и вы мигом его освоите!

Почти 4 года назад мы написали одну из самых популярных статей в рунете про проектирование больших проектов с таким же названием, как и эта: часть 1 и часть 2. Только на Хабре её прочитало более 170 тыс. человек, а вообще она публиковалась в самых разных изданиях мира. Более 1000 стартапов использовали наработки из этой статьи для проектирования, и это только те, о которых я слышал и которые нам писали. Но время не стоит на месте, а мы постоянно развиваемся. С тех пор наша технология проектирования значительно эволюционировала и стала еще лучше. В этой статье мы опишем нашу обновленную технологию проектирования и покажем много живых примеров для каждой стадии.

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

Этот пост призван помочь тем, кому, как и мне, внезапно стало тесно с Movie Maker.

Видеоредакторы почти не интересовали меня до прошлого месяца, пока с друзьями мы не задумали снять что-нибудь оригинальное к Новому году. Креативность наша ограничилась тем, чтобы, говоря терминами прежде мне неизвестными, применить эффект “Разделение экрана” (Split Screen). То есть реализовать нечто такое:

Здравствуйте, уважаемые хабрапользователи! В предыдущей статье мы рассмотрели стратегическое моделирование с помощью подхода DDD. В ней было показано, как выделять концептуальные границы, в рамках которых решаются отдельные задачи предметной области – ограниченные контексты.

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

Какие алгоритмы используют социальные сети, чтобы осуществлять поиск по графу друзей? Как телекомпании выбирают, какую рекламу показывать, чтобы максимизировать прибыль? Как собрать геном из миллионов фрагментов? Как вычислить кратчайший путь из Нью-Йорка в Маунтин Вью в тысячи раз быстрее, чем это делают классические алгоритмы?

На Coursera появилась еще одна полезная специализация, созданная при участии Яндекса, — «Алгоритмы и структуры данных». Среди преподавателей не только представители Яндекса, Вышки, петербургского Computer Science Center, но и лекторы Калифорнийского университета в Сан-Диего, поэтому на этот раз все курсы специализации англоязычные.



Всего их пять, в конце слушателей ждет финальный проект. Один из них связан с биоинформатикой, второй — с поиском кратчайших путей в настоящих дорожных сетях и графах. В формате специализации все материалы доступны бесплатно. Оплата понадобится только в том случае, если вы захотите отправлять домашние задания на проверку и получить сертификат. Тогда вам нужно будет запрограммировать и сдать около 100 задач в тестирующую систему. Сделать это можно на C, C++, C#, Haskell, Java, JavaScript, Python2, Python3, Ruby и Scala.

Сегодня начинается первый курс — Algorithmic Toolbox. Под катом — программа специализации, информация о преподавателях и их мнение о том, кому она будет полезна и почему.

В статье речь пойдет об одном очень не новом проекте, который создавался совсем в другое время и совсем в других условиях. Это моя старенькая RTS под названием Земля онимодов (Onimod land). Чтобы было сразу понятно, что она собой представляет, можно посмотреть коротенькое видео:

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



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

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

Шел я как-то по дорожке и вяло размышлял на тему того, что опять придется или тащиться в обход, или пачкать обувь. С возмущения типа «вот же дураки это проектируют» мысль плавно перетекла на слышанную когда-то байку про некий наукоград, где дорожки во дворах сперва не сделали вовсе, а потом просто заасфальтировали протоптанные людьми тропинки, получив сеть удобных жителям маршрутов. А оттуда мысль перекочевала к идее «а почему бы не сделать то же самое, но на компьютере?». Разработать программу, которая по заданной карте предскажет, где люди будут топтать газоны и где неплохо бы сделать асфальтовое покрытие?

Под катом — описание алгоритма и пара примеров его работы для реальных питерских дворов.

Известно, что дерево – довольно сложная структура. И если чтение успешно реализуется в том числе рекурсией (которая не лишена своих проблем), то с изменением дела обстоят совсем не хорошо.

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

Классическое концептуальное объяснение зиппера, выглядит как-то так: это взгляд изнутри на древовидную структуру как бы вывернутую наизнанку, вроде вывернутой перчатки.

Это образное объяснение, если поскрипеть мозгами, обычно, конечно же, понимается только отчасти. Далее зипперы откладываются в сторону, потому что «это непонятная какая-то функциональная заморочка, типа монад, потом разберусь».

У автора «потом» уже наступило. Эта статья – попытка дать альтернативное объяснение зипперов (не путать с объяснением для альтернативно одаренных, хотя…) такое, что позволит быстро понять и немедленно начать использовать зипперы в практических задачах.

Мы продолжаем нашу колонку по теме ASP.NET Core очередной публикацией от Дмитрия Сикорского ( DmitrySikorsky) — руководителя компании «Юбрейнианс» из Украины. В этот раз Дмитрий рассказывает о своем опыте разработки модульного кроссплатформенного фреймворка на базе ASP.NET Core. Предыдущие статьи из колонки всегда можно прочитать по ссылке #aspnetcolumn — Владимир Юнев

Из-за специфики моей задачи, последнее время достаточно много приходится размышлять о модульной и расширяемой архитектуре веб-приложений на ASP.NET Core (а до этого — на ASP.NET предыдущей версии). В результате появился ExtCore — небольшой кроссплатформенный фреймворк с открытым кодом, позволяющий буквально простым подключением NuGet-пакета превратить ваше веб-приложение в модульное и расширяемое.

Основные возможности

ExtCore умеет обнаруживать и использовать типы (а также, представления и статический контент), определенные как в проектах (в виде исходного кода или NuGet-пакетов), на которые есть явные ссылки в зависимостях, так и в проектах, которые размещены в определенной папке в виде скомпилированных DLL-сборок.

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

Хотя непосредственно сам фреймворк и не содержит какого-либо функционала, связанного с работой с данными, но все, что для этого необходимо (в т. ч. единый контекст хранилища для всех расширений), реализовано в расширении ExtCore.Data, о котором ниже.

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

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

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

В этой статье я хочу рассказать о своей реализации паттерна под названием Long Polling для фреймворка Nancy. Коду моего модуля уже более четырёх лет, в течение которых он успешно работал в ряде проектов на ASP .Net MVC. На этой неделе я решил оформить его в виде модуля Nancy и выложить на гитхаб для всеобщего блага, поскольку аналогичного решения найти мне не удалось.

С помощью моего модуля буквально за минуту и парой простых действий можно получить надёжный канал обратной связи от сервера к браузеру. Хотите узнать подробности?

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

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

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

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

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