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

      Допустим, у вас есть товары и категории. В какой-то момент клиент сообщает, что для категорий с рейтингом > 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); // так нельзя!
      

      К счастью, осуществить это довольно просто!
      Код под катом
    • Как мы попробовали DDD, CQRS и Event Sourcing и какие выводы сделали

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

        Факты, цифры, код
      • Немного о нетрадиционном маппинге

          Многие знают про отличную библиотеку AutoMapper. С преобразованием Entity -> Dto проблем обычно не возникает. Но как обрабатывать обратный маппинг в случае, когда в API приходит корень агрегации? Хорошо, если read и write — контексты разделены и писать можно из Dto. Чаще, однако, нужно выбрать соответствующие сущности из ORM по Id и сохранить агрегат целиком. Занятие это муторное, однако зачастую поддающееся автоматизации.
          Особый TypeConverter увидеть желаешь
        • Разумное АОП для поклонников IOC-контейнеров

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

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

            Речь пойдет о проекте Castle.DynamicProxy и его применении в разработке корпоративных приложений.
            Следуй за белым кроликом
          • 9 ¾ действительно полезных советов по работе над крупными проектами


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

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

              Бюрократия в этом случае – необходимое зло, тем ни менее, действующее на нервы. Чтобы избежать потерь драгоценных клеток я советую сразу подготовиться к тому, что придется поменять свой привычный workflow. Хорошая новость состоит в том, что, переучившись, вам не составит труда поступать также и на небольших проектах. Скорее всего, ваши коллеги будут приятно удивлены такой педантичностью
              Читать дальше →
            • Немного особой контейнерной магии

                В прошлой статье я привел пример фабрики для получения реализаций 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);
                }
                

                Задача
                Избавить прикладных разработчиков от необходимости написания контроллеров, проекций и сервисов.
                Решение под катом
              • ASP.NET Core сегодня: за и против

                  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.

                  Дино и Морис отвечали на английском языке, ниже мы публикуем перевод их ответов.
                  Читать дальше →
                • .NET-разработка: девять вопросов взрослым

                    .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 Никита Цуканов.
                    Читать дальше →
                  • Рентабельный код 2: крадущийся DDD, затаившийся CQRS

                    • Tutorial

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

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

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

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

                    Как ни прискорбно, придется признать – мы сами закладываем себе мины. В первой части я подробно разобрал основные риски в разработке ПО и описал технологические и методологические способы ослабления этих рисков. За прошедший год я получил множество комментариев, основной смысл которых сводился к следующему: «все круто, но с чего начать и как все это будет выглядеть в реальном мире». Действительно, первый текст носит скорее теоретический характер и представляет собой каталог ссылок. В этой статье я постараюсь привести как можно больше примеров.
                    Читать дальше →
                  • Как перестать беспокоиться и начать лучше продавать разработку ПО

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



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


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

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

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

                      Данная статья – не совсем скрипт для продажи в привычном понимании слова. Скорее попытка построить мостик между «техническим» и «бизнес» — мышлением и помочь тем, кто испытывает сложности с презентацией и отстаиванием итеративного подхода к разработке.
                      Читать дальше →
                    • БЭМ с человеческим лицом и интеграция с backend

                        Верстка современных 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, уменьшить количество соответствующего кода
                        • Снизить время на модификацию существующего кода
                        • Уменьшить количество ошибок при модификации, особенно регрессии
                        • Научиться создавать и верстать адаптивный дизайн эффективно

                        Читать дальше →
                      • Рентабельный код

                        • Tutorial


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

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

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

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

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

                        С моей точки зрения спокойная рабочая обстановка вместо авралов и бонусы – неплохая мотивация, чтобы начать заботиться об этом.
                        Читать дальше →
                      • Ubiquitous Language и Bounded Context в DDD


                          Domain-Driven Design: Tackling Complexity in the Heart of Software Эванса — лучшая книга о проектировании действительно больших enterprise-приложений, что я читал. Видимо это мнение разделяют многие другие разработчики и проектировщики, потому что Entity и ValueObject, Repository и Specification встречаются почти в каждой большой кодовой базе. Но вот незадача, Ubiquitous Language (единый язык) и Bounded Context (контекст предметной области) в чужом коде я не видел ни разу. И здесь зарыта очень большая собака.
                          Выкапываем собаку
                        • Вещи, которые мы хотим сделать «потом»

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



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

                            Если не хотите ходить по моим граблям, добро пожаловать под кат.
                            Читать дальше →
                          • Как ExpressionTrees помогают тестировать WebApi

                            • Tutorial
                            Всем хороши 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"}));
                            

                            Как выяснилось, это вполне можно реализовать применив немного уличной магии деревья выражений
                            Читать дальше →
                            • +11
                            • 4,4k
                            • 3
                          • Планирование сроков и бюджетов для фрилансера

                              Вот уже почти три месяца я уволился из офиса и работаю на «вольных хлебах». «Халтуры» попадались и до этого, но я не брал более одного проекта и делал лишь то, что входило в мою широкую, но не безграничную область компетенции.
                              Я занимаюсь «программированием под ключ». Специализируюсь на проектах, требующих смежной компетенции, обычно я работаю с заказчиками долго — по нескольку лет. Я за то, чтобы исполнитель и заказчик работали вместе и помогали друг-другу найти оптимальное видение проекта. Мой процесс разработки выглядит так:
                              Читать дальше →
                            • Как релизится GitHub

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

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



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

                                К счастью Джейсон после доклада еще какое-то время находился рядом со сценой и я смог расспросить его с пристрастием о том как они это делают.
                                Читать дальше →
                              • The Good, the Bad and the Ugly code


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

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

                                  Почему именно эти критерии? Сразу оговорюсь, речь сейчас идет о разработке ПО для бизнеса (enterprise application). Критерии оценки кода для систем реального времени, самолетов, систем жизнеобеспечения и МКС отличаются.
                                  Читать дальше →
                                • Continuous Integration для самых маленьких

                                  • Tutorial

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


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

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

                                  • Tutorial

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

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

                                  Итак, наш Product Owner попросил команду разработать калькулятор…
                                  Под катом user stories, тестовые сценарии, автоматизация и запуски по расписанию из Team City
                                  • +15
                                  • 37,9k
                                  • 2