Pull to refresh
198
0
Максим Аршинов @marshinov

В саббатикале

Send message

Устранение дублирования Where Expressions в приложении

Reading time 4 min
Views 21K
Допустим, у вас есть товары и категории. В какой-то момент клиент сообщает, что для категорий с рейтингом > 50 необходимо использовать другие бизнес-процессы. У вас достаточно опыта и вы понимаете, что где сегодня 50 завтра будет 127.37 и хотите избежать появления магических чисел в коде, поэтому делаете так:

    public class Category : HasIdBase<int>
    {
        public static readonly Expression<Func<Category, bool>> NiceRating = x => x.Rating > 50;

       //...
    }

    var niceCategories = db.Query<Category>.Where(Category.NiceRating);

К сожалению, этот номер не пройдет, если вы хотите выбрать продукты из соответствующих категорий, потому что NiceRating имеет тип Expression<Func<Category, bool>>, а в случае с Product нам потребуется Expression<Func<Product, bool>>. То есть, необходимо осуществить преобразование Expression<Func<Category, bool>> => Expression<Func<Product, bool>>.

    public class Product: HasIdBase<int>
    {
        public virtual Category Category { get; set; }

       //...
    }

    var niceProductsCompilationError = db.Query<Product>.Where(Category.NiceRating); // так нельзя!

К счастью, осуществить это довольно просто!
Код под катом
Total votes 22: ↑18 and ↓4 +14
Comments 82

Как мы попробовали DDD, CQRS и Event Sourcing и какие выводы сделали

Reading time 9 min
Views 75K
Вот уже около трех лет я использую в работе принципы Spec By Example, Domain Driven Design и CQRS. За это время накопился опыт практического применения этих практик на платформе .NET. В статье я хочу поделиться нашим опытом и выводами, которые могут быть полезными командам, желающим использовать эти подходы в разработке.

Факты, цифры, код
Total votes 39: ↑39 and ↓0 +39
Comments 45

Немного о нетрадиционном маппинге

Reading time 2 min
Views 8.2K
Многие знают про отличную библиотеку AutoMapper. С преобразованием Entity -> Dto проблем обычно не возникает. Но как обрабатывать обратный маппинг в случае, когда в API приходит корень агрегации? Хорошо, если read и write — контексты разделены и писать можно из Dto. Чаще, однако, нужно выбрать соответствующие сущности из ORM по Id и сохранить агрегат целиком. Занятие это муторное, однако зачастую поддающееся автоматизации.
Особый TypeConverter увидеть желаешь
Total votes 17: ↑13 and ↓4 +9
Comments 9

Разумное АОП для поклонников IOC-контейнеров

Reading time 8 min
Views 18K
Я очень не люблю boilerplate. Такой код скучно писать, уныло сопровождать и модифицировать. Совсем мне не нравится, когда тот самый bolierplate перемешан с бизнес-логикой приложения. Очень хорошо проблему описал krestjaninoff еще 5 лет назад. Если вы не знакомы с парадигмой AOP, прочитайте материал по ссылке, он раскрывает тему.

Как на момент прочтения этой статьи, так и сейчас меня не устраивают ни PostSharp ни Spring. Зато за прошедшее время в .NET появились другие инструменты, позволяющие вытащить «левый» код из бизнес-логики, оформить его отдельными переиспользуемыми модулями и описать декларативно, не скатываясь при этом в переписывание результирующего IL и прочую содомию.

Речь пойдет о проекте Castle.DynamicProxy и его применении в разработке корпоративных приложений.
Следуй за белым кроликом
Total votes 11: ↑11 and ↓0 +11
Comments 29

9 ¾ действительно полезных советов по работе над крупными проектами

Reading time 4 min
Views 26K

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

Но случается и так, что мы беремся за работу над большими проектами. Под «большими» я понимаю композицию следующих факторов:
  1. Более 50 проектов в solution’е. Назначение не всех из них вы знаете
  2. Билд и выкладка длятся более 5 минут
  3. Над кодом работают десятки или сотни человек в разных офисах (возможно и странах)
  4. Существует четкое разделение труда и область ответственности каждой команды
  5. Существуют строгие регламенты, стандарты оформления кода, прохождение ревью является обязательным критерием выполнения задачи
  6. Учет рабочего времени производится позадачно, анализируются причины расхождения оценок и реальных трудозатрат

Бюрократия в этом случае – необходимое зло, тем ни менее, действующее на нервы. Чтобы избежать потерь драгоценных клеток я советую сразу подготовиться к тому, что придется поменять свой привычный workflow. Хорошая новость состоит в том, что, переучившись, вам не составит труда поступать также и на небольших проектах. Скорее всего, ваши коллеги будут приятно удивлены такой педантичностью
Читать дальше →
Total votes 23: ↑19 and ↓4 +15
Comments 26

Немного особой контейнерной магии

Reading time 4 min
Views 8.2K
В прошлой статье я привел пример фабрики для получения реализаций IQuery, но не объяснил механизм ее работы
_queryFactory.GetQuery<Product>()
    .Where(Product.ActiveRule)
    .OrderBy(x => x.Id)
    .Paged(0, 10) // получаем 10 продуктов для первой страницы

// Мы решили подключить полнотекстовый поиск и добавили ElasticSearch, не вопрос:
_queryFactory.GetQuery<Product, FullTextSpecification>()
    .Where(new FullTextSpecification(«зонтик»))
    .All()

// Или EF тормозит и мы решили переделать на хранимую процедуру и Dapper
_queryFactory.GetQuery<Product, DictionarySpecification, DapperQuery>()
    .Where(new DictionarySpecification (someDirctionary))
    .All()

В данном материале я хочу поделиться техникой регистрации необходимых компонентов сборки по соглашениям. Сейчас у меня под рукой кодовая база с другой реализацией CQRS, поэтому примеры будут отличаться. Это не принципиально: основная идея остается неизменной.

Допустим у вас есть такой интерфейс, где ListParams – спецификация, приходящая с фронтенда
public interface IListOperation<TDto>
{
     ListResult<TDto> List(ListParams listParam);
}

Задача
Избавить прикладных разработчиков от необходимости написания контроллеров, проекций и сервисов.
Решение под катом
Total votes 10: ↑9 and ↓1 +8
Comments 5

ASP.NET Core сегодня: за и против

Reading time 6 min
Views 46K
ASP.NET Core имеет все шансы заменить ASP.NET в его текущем виде. Стоит ли переходить на ASP.NET Core уже сейчас? Поговорим об этом с экспертами:

  1. Дино Эспозито (Dino Esposito) – писатель, консультант, тренер и технический евангелист, признанный эксперт и популяризатор концепций DDD и CQRS
  2. Морис де Бейер (Maurice de Beijer) – независимый консультант, MVP и автор онлайн-курса The React Tutorial
  3. Андрей Терехов – full-stack разработчик EPAM, специалист по серверному пререндерингу.



Все трое выступят через неделю в Питере на конференции DotNext с докладами про ASP.NET Core.

Дино и Морис отвечали на английском языке, ниже мы публикуем перевод их ответов.
Читать дальше →
Total votes 31: ↑27 and ↓4 +23
Comments 107

.NET-разработка: девять вопросов взрослым

Reading time 14 min
Views 38K
.NET становится по-настоящему кроссплатформенным: после долгого ожидания наконец объявлена дата релиза ASP.NET Core, JetBrains готовит альтернативу Visual Studio на базе ReSharper и IDEA, Microsoft приобрела Xamarin, сделала Xamarin Community бесплатной, а Mono перевела на MIT-лицензию и наконец, Windows Server 2016 получит поддержку Windows-контейнеров в Docker.

С новыми возможностями нас встречают новые вызовы:
  • Как будет работать один и тот же код под .NET Core и Mono, на Windows и Linux, в docker-контейнере?
  • Стоит ли переходить на .NET Core уже сейчас и как получить максимум от новой платформы?
  • Какие перспективы у Mono и Xamarin?
  • Какие изменения произошли «под капотом» .NET с переходом на Roslyn и .NET Core?

Всего через три недели на конференции DotNext в Питере 20 спикеров выступят с докладами о настоящем и будущем платформы .NET, об оптимизации производительности и многопоточности, о внутреннем устройстве платформы .NET и CLR, о профилировании и отладке .NET-кода.

А пока мы попросили четырех из них поделиться своим опытом и мнениями о грядущих изменениях в мире .NET. На наши вопросы ответили:

  • Ведущий мировой эксперт по производительности .NET-платформы, восьмикратный Microsoft MVP, автор прекрасной книги по производительности .NET «Pro .NET Performance» Саша Голдштейн;
  • Главный разработчик протокола реактивного многопроцессного взаимодействия в Rider Дмитрий Иванов из JetBrains;
  • Ещё один разработчик Rider’a из компании JetBrains, .NET MVP, к.ф.-м.н., серебряный призёр ACM ICPC, постдок в Вейцмановском институте науки Андрей Акиньшин;
  • CTO Promarket и эксперт в области Mono и Linux Никита Цуканов.
Читать дальше →
Total votes 37: ↑35 and ↓2 +33
Comments 19

Рентабельный код 2: крадущийся DDD, затаившийся CQRS

Reading time 20 min
Views 50K

Трем программистам предложили пересечь поле, и дойти до дома на другой стороне. Программист-новичок посмотрел на короткую дистанцию и сказал, «Это не далеко! Это займет у меня десять минут». Опытный программист посмотрел на поле, немного подумал, и сказал: «Я мог бы добраться туда за день». Новичок посмотрел на него с удивлением. Гуру-программист посмотрел на поле и сказал. «Кажется минут десять, но я думаю пятнадцати будет достаточно». Опытный программист рассмеялся.

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

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

Гуру программист пустился в путь, и пошел прямо через поле. Целеустремленно и прямо. Он достиг цели всего за десять минут.
«Как тебе это удалось?» — спросили двое других — «Как ты умудрился не зацепить ни одной мины?»
«Легко» — ответил он. «Я не закладывал мины на своем пути».

Как ни прискорбно, придется признать – мы сами закладываем себе мины. В первой части я подробно разобрал основные риски в разработке ПО и описал технологические и методологические способы ослабления этих рисков. За прошедший год я получил множество комментариев, основной смысл которых сводился к следующему: «все круто, но с чего начать и как все это будет выглядеть в реальном мире». Действительно, первый текст носит скорее теоретический характер и представляет собой каталог ссылок. В этой статье я постараюсь привести как можно больше примеров.
Читать дальше →
Total votes 30: ↑27 and ↓3 +24
Comments 19

Как перестать беспокоиться и начать лучше продавать разработку ПО

Reading time 7 min
Views 9.3K
Я занимаюсь разработкой ПО для бизнеса и иногда мне хочется пристрелить отдел продаж. Потом я беру себя в руки, вспоминаю, что именно эти ребята приносят в компанию деньги, а программисты, вообще-то висят на затратах. В этот момент приходит просветление: продавцы обладают другим мышлением, другими навыками и, чаще всего, другим образованием. И каждый день им приходится бороться с кучей возражений клиентов из серии «а один подрядчик из Индии пообещал разработать точно такую-же систему в два раза быстрее и дешевле».



Суть проблемы


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

Чтобы хорошо продавать ПО необходимо обладать солидным опытом как в разработке (технологиях, менеджменте и процессах), так и в продажах. Эти компетенции крайне сложно совместить в одном человеке, а когда они совмещаются, такой человек называется «основатель компании» или «исполнительный директор». Я знаю примеры компаний, в которых директор проводит первичную обработку всех заказов на разработку. Обычно потолок роста такой компании 25-30 человек, а директор – перегружен.

Альтернативный вариант – делегировать оценку техническому директору (CTO). Обычно, это второй по перегруженности человек в компании. Кроме того, у технического директора вагон и маленькая тележка других задач. Таскать его на каждый pre sales – не вариант. Я искренне убежден, что любой нетривиальный проект можно разрабатывать только итеративно и только с прототипами. Такой подход до сих пор сложно принять многим клиентам на территории СНГ. Все хотят на берегу зафиксировать сроки и бюджет. К сожалению, это желание не сопровождается техническим заданием, на основании которого можно было бы работать. Хотя с точки зрения клиента конечно задача поставлена чётко и ясно.

Данная статья – не совсем скрипт для продажи в привычном понимании слова. Скорее попытка построить мостик между «техническим» и «бизнес» — мышлением и помочь тем, кто испытывает сложности с презентацией и отстаиванием итеративного подхода к разработке.
Читать дальше →
Total votes 14: ↑12 and ↓2 +10
Comments 10

БЭМ с человеческим лицом и интеграция с backend

Reading time 7 min
Views 10K
Верстка современных web-проектов – это сложно, долго и дорого. Казалось бы, с переходом IE на автоматические обновления, HTML5, окончанием поддержки Win XP все мы должны зажить в сказочной стране с пони и радугой. Почему легче не стало?

  • HTML5 и CSS3 подарили вебу возможность создавать UI, почти не уступающий по сложности и отзывчивости desktop-приложениям. Ничто не дается просто так, HTML, CSS и JS стало в разы больше. Раньше нам хватало трех файлов: styles.css, stupid-ie-must-die.css, scripts.js. Сейчас количество скриптов, стилей, загружаемых шрифтов, картинок измеряется десятками и сотнями. Появилась необходимость в минификации, ускорении рендеринга и организации всего этого барахла в файловой системе.
  • Сайты постепенно перестали быть набором связанных гипертекстовых страничек и стали web-приложениями. Если раньше для многих сайтов достаточно было сверстать «главную» и «внутреннюю» страницы, то сейчас все совсем не так просто. Количество дизайн макетов легко достигает десятков и сотен.
  • Мы все наслушались про лендинг-пейдж, a/b-тестирование и многократное увеличение конверсии за «просто-так». Оставим за бортом вопрос об эффективности этих методик. Дизайн начали переделывать часто – это факт. Известно, что внесение изменений и поддержка – гораздо дороже и сложнее, чем разработка.
  • Появились мобильные устройства и необходимость в адаптивном дизайне. Тестировать стало сложнее и дольше. Цикл исправления найденных при тестировании багов стал дольше. Тестирование UI почти не поддается автоматизации, с ростом функционала время на регрессионное тестирование неуклонно растет.
  • Усложнилась интеграция с backend-кодом, появилась необходимость делать это гораздо чаще.


Все это заставляет задуматься об оптимизации работы с фронтэндом.


Хочется:
  • Уменьшить время и количество интеграционных работ («натягивание» сверстанного макета на серверную технологию)
  • Повысить повторное использование html, css и js, уменьшить количество соответствующего кода
  • Снизить время на модификацию существующего кода
  • Уменьшить количество ошибок при модификации, особенно регрессии
  • Научиться создавать и верстать адаптивный дизайн эффективно

Читать дальше →
Total votes 15: ↑8 and ↓7 +1
Comments 17

Рентабельный код

Reading time 12 min
Views 65K


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

Разработка ПО – область, подверженная рискам. В нашей сфере при наступлении одного или нескольких рисков, срок поставки рабочей версии может сдвинуться не на привычные и комфортные 10-20%, а на все 150-300%. И надо признаться, что это далеко не предел.

Мы можем либо скрестить пальцы и надеяться, что удача будет сопутствовать проекту во всем, либо признать, что по статистике большая часть проектов по разработке ПО «проваливается» и предпринять дополнительные усилия по ослаблению возможных рисков.
Моя практика показывает, что клиенты крайне неохотно работают по схеме T&M и чаще предпочитают Fixed Price. В условиях зафиксированной стоимости наступление рискового случая означает автоматическое снижение рентабельности проекта: сотрудники получают зарплату ежемесячно, а не за сданные проекты.

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

Почему об этом следует думать разработчику, если есть менеджер?
  1. Не секрет, что если факап случится, менеджмент примет единственное «супер-умное» решение: «давайте поработаем сверхурочно и в выходные»
  2. Премии сотрудники получают тоже обычно за в срок сданные, а не за проваленные проекты
  3. Чувство сделанного дела, в конце концов. Гораздо приятнее сдать проект во время и видеть улыбку клиента, чем с опозданием в полгода отвязаться от «трудного ребенка»

С моей точки зрения спокойная рабочая обстановка вместо авралов и бонусы – неплохая мотивация, чтобы начать заботиться об этом.
Читать дальше →
Total votes 76: ↑68 and ↓8 +60
Comments 26

Ubiquitous Language и Bounded Context в DDD

Reading time 3 min
Views 54K

Domain-Driven Design: Tackling Complexity in the Heart of Software Эванса — лучшая книга о проектировании действительно больших enterprise-приложений, что я читал. Видимо это мнение разделяют многие другие разработчики и проектировщики, потому что Entity и ValueObject, Repository и Specification встречаются почти в каждой большой кодовой базе. Но вот незадача, Ubiquitous Language (единый язык) и Bounded Context (контекст предметной области) в чужом коде я не видел ни разу. И здесь зарыта очень большая собака.
Выкапываем собаку
Total votes 23: ↑16 and ↓7 +9
Comments 42

Вещи, которые мы хотим сделать «потом»

Reading time 6 min
Views 21K
Известно, что ошибки проще не допускать, чем исправлять и чем позже найдена ошибка, тем сложнее ее исправить. Не смотря на это у всех нас есть менеджеры дедлайны и тот кусок кода, который надо бы исправить после релиза.



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

Если не хотите ходить по моим граблям, добро пожаловать под кат.
Читать дальше →
Total votes 39: ↑24 and ↓15 +9
Comments 10

Как ExpressionTrees помогают тестировать WebApi

Reading time 5 min
Views 5K
Всем хороши ApiController'ы, да не создают они WSDL и нельзя просто так взять и получить proxy. Да, ApiController'ы неплохо тестируются unit-test'ами. Но юниты пропускают ошибки транспортного уровня и в целом без парочки end-to-end сценариев как-то неудобно. Можно конечно смириться, взять HttpClient и написать примерно такой код:

HttpClient client = new HttpClient();
client.BaseAddress = new Uri("http://localhost:56851/");

// Add an Accept header for JSON format.
client.DefaultRequestHeaders.Accept.Add(
    new MediaTypeWithQualityHeaderValue("application/json"));

HttpResponseMessage response = client.GetAsync("api/User").Result;

if (response.IsSuccessStatusCode)
{
    var users = response.Content.ReadAsAsync<IEnumerable<Users>>().Result;
    usergrid.ItemsSource = users;

}
else
{
    MessageBox.Show("Error Code" + 
    response.StatusCode + " : Message - " + response.ReasonPhrase);
}

Но как же это муторно каждый раз лезть в описание контроллеров, проверять типы, короче хочется вот так:
var resp = GetResponse<SomeController>(c => gc.SomeAction(new Dto(){val = "123"}));

Как выяснилось, это вполне можно реализовать применив немного уличной магии деревья выражений
Читать дальше →
Total votes 15: ↑13 and ↓2 +11
Comments 3

Планирование сроков и бюджетов для фрилансера

Reading time 3 min
Views 25K
Вот уже почти три месяца я уволился из офиса и работаю на «вольных хлебах». «Халтуры» попадались и до этого, но я не брал более одного проекта и делал лишь то, что входило в мою широкую, но не безграничную область компетенции.
Я занимаюсь «программированием под ключ». Специализируюсь на проектах, требующих смежной компетенции, обычно я работаю с заказчиками долго — по нескольку лет. Я за то, чтобы исполнитель и заказчик работали вместе и помогали друг-другу найти оптимальное видение проекта. Мой процесс разработки выглядит так:
Читать дальше →
Total votes 11: ↑7 and ↓4 +3
Comments 14

Как релизится GitHub

Reading time 3 min
Views 43K
Yac 2013 посетил Jason Rudolph из GitHub. Я считаю его доклад про API был одним из самых интересных на конференции. Яндекс обещал выложить в сеть записи, так что советую на досуге посмотреть его всем, кто не видел.

Но речь пойдет не о докладе. На картинке график релизов GitHub на продакшн.



Когда я услышал цифру, я не поверил своим ушам. У GitHub'а сотни обновлений в неделю. В команде около сорока разработчиков и ни одного QA.

К счастью Джейсон после доклада еще какое-то время находился рядом со сценой и я смог расспросить его с пристрастием о том как они это делают.
Читать дальше →
Total votes 124: ↑121 and ↓3 +118
Comments 67

The Good, the Bad and the Ugly code

Reading time 7 min
Views 30K

Хороший код или плохой? Лично для меня хороший код обладает следующими качествами:
  • Код легко понятен разработчикам разной квалификации и хорошо структурирован
  • Код легко изменять и поддерживать
  • Приложение выполняет свои функции и обладает достаточной, для выполняемого круга задач, отказоустойчивостью

Несмотря на короткое описание, о том, как добиться выполнения трех этих условий, написано много толстых книг.

Почему именно эти критерии? Сразу оговорюсь, речь сейчас идет о разработке ПО для бизнеса (enterprise application). Критерии оценки кода для систем реального времени, самолетов, систем жизнеобеспечения и МКС отличаются.
Читать дальше →
Total votes 47: ↑40 and ↓7 +33
Comments 18

Continuous Integration для самых маленьких

Reading time 12 min
Views 115K

Вы все еще публикуете проект вручную? Тогда мы идем к вам


Под катом гайдлайн по внедрению CI для .NET проектов «с нуля», включающий:
  1. Автоматические ежедневные сборки
  2. Уведомления о проблемах
  3. Интеграцию с баг-трекером и системой контроля версий
  4. Версионирование продукта
  5. Версионирование базы данных
  6. Автоматизированные выкладки и бекапы

Читать дальше →
Total votes 48: ↑41 and ↓7 +34
Comments 46

Исполняемая спецификация: SpecFlow от А до Я

Reading time 8 min
Views 60K

Эта статья является продолжением первой части и раскрывает технические подробности работы с «исполняемой спецификацией» с помощью SpecFlow.

Для начала работы вам понадобится плагин к Visual Studio (скачивается с официального сайта) и пакет SpecFlow (устанавливается из nuget).

Итак, наш Product Owner попросил команду разработать калькулятор…
Под катом user stories, тестовые сценарии, автоматизация и запуски по расписанию из Team City
Total votes 17: ↑16 and ↓1 +15
Comments 2

Information

Rating
Does not participate
Location
Казань, Татарстан, Россия
Works in
Date of birth
Registered
Activity