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

      Многие знают про отличную библиотеку 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. Чувство сделанного дела, в конце концов. Гораздо приятнее сдать проект во время и видеть улыбку клиента, чем с опозданием в полгода отвязаться от «трудного ребенка»

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