Авто-мок контейнер от Mark Seemann

Как можно отделить юнит тесты от механизма Dependency Injection? В этой статье описывается паттерн юнит тестов (unit test), называемый автомок (Auto-mocking Container). Его можно использовать для устранения проблемы хрупких тестов (Fragile Test), которые так часто происходят при создании тестируемой системы (system under tests - SUT) при помощи антипаттерна Мать объекта. На этот вопрос отвечает Mark Seemann.

Предисловие переводчика: очередной перевод на этот раз статьи от Mark Seemann о авто-мок контейнерах. Несмотря на то что мне приходится работать с юнит тестами каждый день о концепции Auto mock-ов я узнал не так и двано. Что-бы зделать как можно более доступной информацию о этом полезном подходе к созданию тестовых двойников без лишней боли. И как обычно ссылка на оригинал

Правило молчания и уровни логирования

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

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

Что такое sync over async deadlock

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

Вспомним пример из предудущего поста. По нажатию на кнопку нужно вызвать длительную задачу. Так как наш код асинхронный, код длительной задачи нужно разместить в синхронном коде обработчика нажатия кнопки, для этого воспользуемся техникой sync over async. Т.е. просто дождёмся завершения асинхронной задачи при помощи метода taskName.Wait().

Контекст синхронизации при работе с Task и Thread

При работе в проектах связанными с ui-control или asp.net часто приходится работать с ресурсами доступными в локальном хранилище потока (thread-local storage TLS). К слову: такое поведение можно задать при помощи аттрибута [ThreadStatic] или класса ThreadLocal<T>. При обращении к ним из другого потока платформа dotnet выбросит исключение System.InvalidOperationException с текстом ‘The calling thread cannot access this object because a different thread owns it.’.

Представим себе ситуацию когда в каком-то win-form приложении нам по нажатию кнопки нужно вызвать долгоиграющую задачу. Очевидно, что нужно было-бы создать поток и в этом потоке выполнить эту задачу. Проблематично будет отобразить результат выполнения из созданного потока на UI - ведь ресурсы UI принадлежат одному потоку, а обращаемся мы к нему в другом. Это и есть та вышеописанная ситуация, когда мы столкнёмся с System.InvalidOperationException. Для решения этой проблемы нам придётся подружиться с контекстом синхронизации.

Реализация паттерна saga на C#

Предисловие переводчика: Уже не помню, что сподвигло меня заинтересоваться этим паттерном, скорее всего в какой-то момент мне пришлось столкнуться с javascript библиотекой redux-saga. Знакомство началось с описания паттерна от Bernd Rücker и прекрасной презентации Caitie McCaffrey. После ознакомления с этими материалами у меня всё ещё оставались вопросы. Очень хотелось увидеть этот код “в живую” в виде какого либо PoC-a.

Вашему вниманию представлена статья Clemens Vasters-a, которая поможет разобраться уже в деталях с конкретной реализацией.

Работа с ветками

Данный текст явлется переводом. Оригинал по ссылке

Если вы не знакомы с ветвлением и слиянием веток, предлагаю вам отличную HOWTO Control Source Eric Sink’s. Я предпочитаю модель бранчевания “релизная ветка” (примечание переводчика: подходы к ветвлению указанные по ссылкам немного устарели. По-моему, стоит уделить внимание более современных подходам git-flow, github-flow и gitlab-flow, но понимание сути возможных проблем при миграции изменений думаю может быть полезно).

При подходе “Релизная ветка” вся новая работа происходит в trunk ветке репозитория. Как только продукт приближается к релизу, изменения схемы становятся более редкими и фризятся новые правки. В этот момент, команда создает ветку для релиза. Разработка нового функционала продолжается в транке с изменениями в схеме и всего остального кода. В ветку отправляются только фиксы ошибок. После релиза команда объединяет исправления с ветки в trunk.

Вьюшки, хранимые процедуры и прочее

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

Но сначала…

На самом деле я уже не использую триггеры на протяжении нескольких лет. Это не означает, что триггеры бесполезны, но я, как правило, уклоняюсь от их использования. Jon Galloway опубликовал хороший пример того, что можно сделать с триггерами. Во-вторых, мне мусолят глаза хранимые процедуры. Я пришел из WinDNA идеологической школы, в которой вышеупомянутые хранимые процедуры должны использоваться все время. Сегодня я представляю хранимые процедуры в качестве API слоя для базы данных. Это хорошо, если вам нужен слой API на уровне базы данных, но я знаю множество приложений несущих накладные расходы на создание и поддержание этого слоя API в котором они не нуждаются. В этих приложениях хранимые процедуры часто приносят больше усложнений, чем пользы.

Подготовка основы

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

Предостережения

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

Скрипты изменений

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

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

Три правила

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

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

Работаем с унаследованной базой данных

Как применить патч даже если git морозится

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

Что-бы понять в чём дело можно включить болтливый режим при помощи флага -v –verbose:

$ git apply --verbose feature-name.patch

Если проблема окажется в пробельных символах (whitespace). Можно попробовать проигнорировать или пофиксить их:

Двойной ревёрт или как жить после плохого пулл-реквеста

Представте, что случилась такая ситуация, когда пулл реквест из фиче-бранча оказался немного бажным, но ревьюверы уже приняли его и вмёржили в общий девелоп. Ситуация очень неприятная, особенно если фиче-бранч ВАШ а тесты данную ситауцию почему-то сразу не раскрыли. Фактически, вы заблокировали работу всей команде или того хуже всего проекта с несколькими командами. Как на зло на исправление функционала нужно больше времени чем у вас есть, а злые девелоперы, которые не могут дальше работать уже разжигают костёр обещая Вас на нём поджарить. Что же делаааать?!

Почему я люблю программирование

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

Оригинал

Автоматизация вещей даст вам силу супергероя

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

Безграничное богатство. Теория и практика экономической алхимии. [Пол Зейн Пилцер]

TOC Автор книги Пол Зейн Пилцер достоин внимания своими заслугами как на поприще бизнес деяний - основатель 7ми компаний, как минимум одну из которых вывел на IPO и продал за 435 миллионов USD, так и на литературном поприще.

Об этом эссе (которое почему-то называют книгой, если найдёте что-то большее поделитесь ссылочкой) в одном абзеце:

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