Да, все верно, первый пост был опубликован ровно 5 лет назад, 2 декабря 2008 года и назывался “LINQ to Objects. VS2008 SP1 Bug” и был посвящен тому, что в VS2008 следующий код:
UPDATE (заменил Select на Cast), спасибо Eugene Ivanchenko:
var bytes = Enumerable.Range(1, 5).Cast<byte>().ToList();
работал нормально, а в VS2008 SP1 падал с ошибкой. Это теперь мы знаем, что так и должно быть и распаковка типа с конвертацией всегда завершается с ошибкой, но тогда это поведение казалось ошибкой.
С тех пор опубликовано две сотни постов и, что самое главное, мне это продолжает нравитьсяJ
Зачем мне это?
Наверняка многие читатели слышали популярное нынче слово Time Management. А многие, скорее всего, даже используют некоторые методики эффективного управления временем.
Одним из полезных инструментов в этой области является матрица Эйзенхаура . Основная суть ее сводится к тому, что любые дела распределяются по двум осям: важности и срочности.
При этом в первом квадранте находятся «пожары», которых, в идеале, быть не должно; во втором – дела на перспективу; в третьем – ерунда, но которую нужно сделать сейчас; а в четвертом – ерунда, которую можно было бы исключить из своей жизни.
Так вот, основная сложность саморазвития заключается в том, что этот тип дел относится ко второму квадранту: это дело важное, но не срочное.
Если вспомнить историю развития методологий разработки ПО, то появление итеративной модели разработки и короткого цикла «анализ, проектирование, разработка, развертывание» обусловлено несколькими причинами. Во-первых, это управление рисками; благодаря тому, что пользователь видит труды наших дел как можно раньше, то он может скорректировать работу команды существенно раньше.
Во-вторых, короткие итерации позволяют усилить чувство важности результата для всех членов команды, что позволит избежать «пожаров» и работать команде в устойчивом высоком темпе.
Итак, короткие итерации в разработке ПО позволяют держать всю проектную деятельность во втором квадранте, усиливая при этом ощущение срочности получения результата. Аналогично, мы можем попробовать поднять важность вопросов самообразования и сдвинуть их из второго квадранта в сторону первого.
На замечательном тренинге, который вел мой коллега Сергей Новик, мы играли в игру, в которой нам нужно было составить план саморазвития. Он был произвольным и достаточно неформальным, но основная его идея была в том, чтобы каждый прикинул основные активности, которые он будет выполнять для собственного развития с числовыми показателями: прочитать N книг в год; перевести M статей в месяц; опубликовать K постов в квартал и т.д.
Не важно, какие числовые показатели вы выберете и что именно для вас является наиболее оптимальным способом обучения. Важно, чтобы у вас повысилось это самое чувство важности самообучения прямо сейчас. Для меня лично важным мотиватором служит ведение этого блога, для другого это может быть участие в pet- или open source проекте, для кого-то – чтение книг или статей. Важно, чтобы вы нашли стимулы, которые максимально подходят именно вам.
О чем я собираюсь писать в дальнейшем?
У меня, как наверное у любого блоггера, есть список тем, о которых он хотел бы рассказать. Если все идет хорошо, то этот список является такой себе приоритетной очередью, которая постоянно пополняется новыми темами и опустошается за счет публикации статей.
Пока что, у меня с этой очередью все хорошо и там есть целые разделы, о которых хотелось бы рассказать. Среди них такие:
- паттерны в современных .NET приложениях;
- юнит тестирование: Microsoft Fakes + Verification Fakes
- асинхронное и параллельное программирование
- дизайн вообще и DDD, в частности
- C#/.NET (в частности, есть мысли о небольшом цикле об исключениях)
- философия программирования: ФП vs ООП и всякое другое.
Еще у меня есть мысль сделать рубрику, что-то вроде QA. Так что если у вас есть вопросы по дизайну приложений или использованию тех или иных языковых конструкций, присылайте их на почту и я постараюсь их рассмотреть!
Happy blogging-а всемJ
Я как раз хотел задать вам вопрос, а тут такой пост с призывом сделать это :)
ОтветитьУдалитьТема DDD очень интересна, но к сожалению слабо освещена в контексте распределенных систем и/или систем с серьезными требованиями к производительности.
Ради ускорения работы приложения приходится "утончать" логику доменных объектов, либо дублировать ее - делать "обычный" вариант и быстрый, для работы в режиме batch-обработки данных.
Выскажите пожалуйста свое мнение о таких ситуациях
Очень интересный вопрос.
УдалитьВсе дело в том, что под "системами с серьезными требованиями к производительности" понимаются разными людьми разные вещи. Для кого-то 10 запросов в секунды - это уже высокая производительность, а для кого-то 1000 запросов в секунду - это детский лепет.
Но в любом случае, я обратил внимание, что именно бизнес-правила и бизнес-логика практически не когда не является узким местом в плане прозиводительности: обычно все упирается в данные, ввод-вывод, многопоточную обработку или еще что-то подобное. Именно поэтому можно смело начинать работать над полноценной доменной моделью и лишь после профилирования думать о переносе логики в хранимки или думать об "утоньшении" бизнес-слоя.
Обычно, в этом не будет смысла, но все очень сильно зависит от типа логики, объемах данных и требованиях к пропускной способности.
Еще один тонкий момент с DDD - работа в распределенных приложениях. Допустим у нас есть WPF клиент, коммуницирующий с сервером через WCF. Распространенной практикой здесь является отправка клиенту DTO-шек, что приводит к тому, что клиент начинает дублировать логику домена, в частности логику валидации.
ОтветитьУдалитьРешением тут является вынесение такой логики в отдельные сервисные классы, что приводит к уточшению доменных классов со всеми вытекающими (анимичная модель, transaction script), либо работа с доменными классами на клиенте. Минусы второго подхода в том, что нужно либо писать логику сериализации из/в доменные объекты, либо использовать их в качестве интерфейсов между сервером и клиентом (для работы с DataContractSerializer-ом).
Что думаете на этот счет?
Еще хотелось бы услышать ваше мнение об Event Sourcing, в частности какие области применения вы видите для этого подхода. Но это возможно уже тема для отдельного поста.