Продолжение. Начало здесь.

Как все это использовать?

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

Вступление

Знаете, что я заметил? Мы очень много времени уделяем кастомизации цифрового пространства. Это начинается со смены обоев и тем рабочего стола, переходит в долгий подбор скина в Aimp (Winamp, для староверов) и заканчивается оформлением цифрового рабочего места.

Как только я меняю среду разработки или редактор кода, то первым делом лезу в цветовые схемы и ищу любимые цвета. У программистов уже сложились целые культы вокруг определенных цветовых палитр. Что лучше — Obsidian или Monokai? Можно мне Selenitic, только фон более темный? И все в таком духе. Бывало, что ко мне приходили друзья и, прежде чем начать показывать свой проект, меняли тему на другую, более привычную для них. Это раздражает, но я их понимаю.


… на самом деле комикс не о цветовых схемах, но он отлично походит.

Когда меня спрашивают, что в первую очередь нужно знать о прохождении технического собеседования, я всегда отвечаю одинаково: приготовьтесь говорить.

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

Переведено в Alconost

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

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

В недавнем интервью с Джоном Скитом мы пришли к выводу, что профессиональная работа с любой технологией подразумевает умение диагностировать проблемы и понимать, как ваши приложения работают под капотом. Вдогонку к тому разговору, я узнал у Саши goldshtn Гольдштейна, одного из лучших в мире экспертов по производительности .NET, автора книги «Pro .NET Performance», на какие инструменты следует обратить внимание .NET-разработчикам.

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

Заинтересовавшись вопросом скорости работы операций упаковки и распаковки в .NET решил опубликовать свои небольшие и крайне субъективные наблюдения и измерения по этой теме.

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

Собеседование на английском — дело непростое. Но хорошее планирование и подготовка ключевых моментов сделают этот процесс более приятным и безобидным.

Предлагаем вновь спуститься на низкий уровень и поговорить о безопасности прошивок x86-совместимых компьютерных платформ. В этот раз главным ингредиентом исследования является Intel Boot Guard (не путать с Intel BIOS Guard!) – аппаратно-поддержанная технология доверенной загрузки BIOS, которую вендор компьютерной системы может перманентно включить или выключить на этапе производства. Ну а рецепт исследования нам уже знаком: тонко нарезать реверс-инжинирингом имплементацию данной технологии, описать её архитектуру, наполнив недокументированными деталями, приправить по вкусу векторами атак и перемешать. Подбавим огня рассказом о том, как годами клонируемая ошибка на производстве нескольких вендоров позволяет потенциальному злоумышленнику использовать эту технологию для создания в системе неудаляемого (даже программатором) скрытого руткита.

Кстати, в основе статьи – доклады «На страже руткитов: Intel BootGuard» с конференции ZeroNights 2016 и 29-й встречи DefCon Russia (обе презентации здесь).

Опираясь на материал, описанный в первой, второй и третьей частях данной статьи, мы продолжим обсуждение темы обработки исключений в Windows x64.

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

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

Я познакомился с этим термином в процессе чтения DDD Эванса. На Хабре есть статьи с описанием практического применения паттерна и проблем, возникающих в процессе реализации.

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

Классическая реализация шаблона проектирования выглядит так:

public interface ISpecification
{
    bool IsSatisfiedBy(object candidate);
}

Что с ним не так применительно к C#?

1. Есть Expression<Func<T, bool>> и Func<T, bool>>, сигнатура которых совпадает с IsSatisfiedBy
2. Есть Extension-методы. alexanderzaytsev с помощью них делает вот так:
   
   

   public class UserQueryExtensions 
   {
     public static IQueryable<User> WhereGroupNameIs(this IQueryable<User> users,
   string name)
     {
         return users.Where(u => u.GroupName == name);
     }
   }
   

   
   
3. А еще можно реализовать вот такую надстройку над LINQ:
   
   

   public abstract class Specification<T>
   {
     public bool IsSatisfiedBy(T item)
     {
       return SatisfyingElementsFrom(new[] { item }.AsQueryable()).Any();
     }
   
      public abstract IQueryable<T> SatisfyingElementsFrom(IQueryable<T> candidates);
   }
   

В конечном итоге возникает вопрос: стоит ли в C# пользоваться шаблоном десятилетней давности из мира Java и как его реализовать?

Data Access Layer – одна из наиболее больных тем.
Написание хорошего слоя доступа к данным – это не тривиальная задача. Примеров реализации невероятно много, но адекватных среди них единицы.
Можно ли считать реализацию шаблона Repository — DAL?
Вот что предлагают MS msdn.microsoft.com/en-us/library/ff649690.aspx

А вот и местные работы habrahabr.ru/post/52173
Варианты довольно нормальные.
Но когда я вижу

«Репозиторий – это фасад для доступа к базе данных.»

…

Предпринимая попытки постичь DDD вы наверняка натолкнетесь на этот паттерн, который часто тесно используется вместе с другим, не менее интересным, паттерном «Репозиторий». Этот паттерн предоставляет возможность описывать требования к бизнес-объектам, и затем использовать их (и их композиции) для фильтрации не дублируя запросы.

Пример

Давайте для примера спроектируем домен для простого группового чата: у нас будут три сущности: Группа и Пользователь, между которыми связь многие-ко-многим (один пользователь может находиться в разных группах, в группе может быть несколько пользователей) и Message представляющий собой сообщение, которое пользователь может написать в какой-либо группе:

На первый взгляд нижеприведённый материал может показаться ещё одним банальным «хэллоууорлдом», «туториалом от Капитана Очевидность», коих уже предостаточно на просторах Сети, но это впечатление обманчиво. На деле чтобы добиться того же результата с нуля у WinForms-программиста, не работавшего ранее с Entity Framework Core (не путать с классической Entity Framework) и вооружённого только уже валяющимися в изобилии на просторах Сети туториалами по EF Core и документацией может уйти куда больше времени, чем он наивно ожидал до того, как взялся за дело. Так случилось и со мной. Посему хочу поделиться опытом.

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

Сообщество .Net разработчиков замерло в ожидании выхода C# 7.0 и новых фич которые он принесет. Каждая версия языка которому уже в следующем году исполнится 15 лет принесла с собой что-то новое и полезное. И хотя каждая фича достойна отдельного упоминания, сегодня я хочу поговорить о ключевом слове yield. Я заметил, что начинающие разрабочики (и не только) избегают его использования. В этой статье я постараюсь донести преимущества и недостатки, а также выделить случаи, когда применение yield целесообразно.

yield создает итератор и позволяет нам не писать отдельный класс когда мы реализуем IEnumerable. C# содержит два выражения использующих yield: yield return <expression> и yield break. yield может применяться в методах, операторах и свойствах. Я буду говорить о методах, так как yield работает везде одинаково.

Реализация итераторов в C# (часть 1).

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

От переводчика:
Не так давно мой менее опытный коллега спросил меня о том, для чего используется yield return в C#. Я не очень часто пишу свои итераторы, поэтому, отвечая ему, я сомневался в своих словах. Справившись в MSDN, я укрепился в сказанном, но у меня возник вопрос: “А во что же всё таки компилируется эта инструкция?” К тому моменту, я уже был знаком с переводимой статьёй, однако всё, что в ней сказано, давно “выветрилось”. Статья старая, но мне думается, что она может быть полезна для определённой группы разработчиков, привыкшей читать русскоязычные статьи и документы.

Ссылка на продолжение: реализация итераторов в C# (часть 2)

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

Как и в прошлый раз, статья будет полезна для ознакомления разработчикам младшего и среднего звена. В процессе изучения материала, Вы узнаете как можно обращаться к низкоуровневым DLL WinAPI в C# с помощью P/Invoke, как установить, настроить и удалить из системы мониторы печати, драйвера принтера, само устройство печати, открыть и связать порт для перенаправления входных данных с устройства печати на монитор, познакомитесь с ключевыми моментами применения маршалирования. Так же мы на практическом примере разберёмся, как с помощью нашего API можно удобно манипулировать устройствами печати в системе, узнаем как можно перехватить обработанные данные после печати с принтера и, например, отправить их на сервер.

Предлагаю вашему вниманию перевод статьи о «ловушках» в С#. Данная статья будет полезна начинающим программистам пока еще не знакомым с тонкостями языка.

Приятного чтения.

---

«Это все мелочи, мелочи. Но нет ничего важнее мелочей.»

Предыдущие части

• Часть первая — habrahabr.ru/post/255361
• Часть вторая — habrahabr.ru/post/255523
• Часть третья — habrahabr.ru/post/255825
• Часть четвертая — habrahabr.ru/post/256045

В данной части мы рассмотрим

Здесь мы в общих чертах рассмотрим работу с операторами модификации данных:

• INSERT – вставка новых данных
• UPDATE – обновление данных
• DELETE – удаление данных
• SELECT … INTO … – сохранить результат запроса в новой таблице
• MERGE – слияние данных
• Использование конструкции OUTPUT
• TRUNCATE TABLE – DDL-операция для быстрой очистки таблицы

В самом конце вас ждут «Приложение 1 – бонус по оператору SELECT» и «Приложение 2 – OVER и аналитические функции», в которых будут показаны некоторые расширенные конструкции:

• PIVOT
• UNPIVOT
• GROUP BY ROLLUP
• GROUP BY GROUPING SETS
• использование приложения OVER

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