О вреде метода Thread.Abort

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

Давайте в качестве примера рассмотрим различные сопособы прекращения работы созданного вручную потока. Если вы начали знакомство с многопоточностью, с таких чудесных библиотек как WinAPI и не менее чудесных языков программирования как С и С++, то вы наверняка очень быстро поняли, что завершать выполнение потока с помощью вызова функции TerminateThread мягко говоря не стоит. Вызов функции TerminateThread гарантировано приводит к утечкам ресурсов, памяти, некорректному состоянию объектов ядра операционной системы и еще десятку других напастей, после которых корректное состояние приложения – мало вероятно. Вызов этой функции достаточно быстро завоевал дурную славу у разработчиков (благо даже в официальной документации на эту функцию в MSDN черным по английскому сказано, что вызывать ее не стоит) и большинству разработчиков пришлось искать другие способы завершения работы потока, начиная от уведомление рабочего потока с помощью событий (events), заканчивая применением булевого флага, который проверяется рабочим потоком и устанвливается в true для его завершения.

Ретроспектива 2010 года

У каждого блоггера не зависимо от тематики, на которую он пишет, есть своя цель, ради которой он тратит свое свободное время и изливает свое сознание на страницы своего живого журнала. Для одного это может быть способом самореализации (ЧСВ оно такое ЧСВ ;) ), для второго – желание поделиться своим опытом и знаниями с другими, для третьего – систематизация уже имеющихся знаний, для четвертого – способ изучить тему поглужбе и только потом о ней рассказать другим, для пятого – повысить свою стоимость на рынке труда. Для меня каждая из этих целей играет определенную роль, но самое главное, я рассматриваю свои посты, как фотоснимки собственного сознания, на которые можно посмотреть с течением времени и увидеть себя, свой опыт и свое мышление в прошлом; понять, как я думал, чем интересовался, какие решал задачи; это такой себе способ пообщаться с самим собой в прошлом; видеопленка с собственным сознанием и профессиональным опытом. Кроме того, перечитывание своих собственных заметок позволяет значительно быстрее снова погрузиться в ту или иную тему, которая, как ни крути, в современных реалиях начинает с невероятной быстротой выветриваться из головы; не зря ведь старая китайская пословица гласит, что даже выцветшие чернила лучше хорошей памяти.

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

Знакомство с Dynamic LINQ

- Dynamic LINQ, знакомьтесь, это мои читатели.
- Читатели, знакомьтесь, это Dynamic LINQ.    
                           Знакомство читателей с Dynamic LINQ

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

Язык программирования C# в отношении «строгости» типизации является скорее мультипарадигменым: его можно отнести к статическим языкам, однако он в значительной степени поддерживает и динамическую составляющую. Еще начиная с первой версии языка, вы могли достучаться к методу, свойству или полю по его имени с помощью механизма рефлексии, а с появлением ключевого слова dynamic (а точнее с появлением функциональности, скрытой за этим ключевым словом), этот процесс вообще здорово упростился.

Конфигурябельность

Повествование в художественном или разговорном стиле на компьютерную тематику дело не новое. Наверное, одним из первых и самых известных представителей этого жанра является Том ДеМарко со своей замечательной книгой "Deadline. Роман об управлении проектами". Вот и я решил опробовать этот стиль на себе и посмотреть, что из этого выйдет.

*****************

Первые дни работы на новом проекте - очередной стендап. Мы, видите-ли, работаем "по скраму". То, что никто не понимает, для чего это нужно и какие бенефиты мы от получаем от этого процесса - дело второе, но главное, что все (в том числе и заказчик) знают , что у нас есть "Процесс" и мы его рьяно соблюдаем. Ну ладно, скрам, так скрам, назовите вы процесс хоть RUP-ом, только тысячами отчетов не задалбывайте.

На очередном стендапе я стою себе в сторонке, никого не трогаю, народ в это время обсуждает куски какого-то проекта, и тут Славка (лид наш) вспоминает о моем существовании, поворачивается ко мне и говорит:
- Серега, ты же сейчас ни чем особым не занят?
- Да вроде бы нет, - осторожно отвечаю я. - Мне Мэт еще на той неделе обещал подогнать какое-нибудь разумное задание, но так и не подогнал, вот я сижу и дурью маюсь помаленьку.
- Отлично, - говорит Славка, - У меня как раз к тебе заданьице есть. Возьмешься?
- Ну, а чего ж не взяться-то, раз оно есть-то. Давай, конечно.
- Вот смотри, ты же в курсе, что мы переписываем этот Loader с плюсов на шарп? Так вот, заказчик аж кипятком исходится, так хочет, чтобы он был конфигурабельный. Ну, типа, мы в конфиге чего-то прописали, и оно уже как-то по-другому работает.
- Ну, ладно, - говорю. - Идея-то разумная, а что сильно часто им приходилось правки вносить? - спрашиваю.
- Да, х его з, - отвечает Славка, - Народ говорит, что запросов на изменения, дескать, вообще не было, ибо они в этот г#$@о-код даже лезть боялись. Так что я не в курсе, насколько это на самом деле пригодится, но точно знаю, что без конфигурябельности они никуда не хотят.
- Оки, дай мне денек, я поразбираюсь в коде старой системы и в том, что вы уже успели наваять для новой версии, да покумекаю, стоит ли прикручивать сюда эту конфигурабельность аль нет.

Книга Криса Смита «Программирование на языке F#»

Любая методология разработки, инструмент, технология или язык программирования привлекает к себе внимание по разным причинам. Это может быть нечто инновационное и тогда по прошествию десятка или двух лет (!), до него таки дотянутся руки всего остального компьютерного сообщества. Так было практически со всеми идеями, которым пришлось пройти длительный путь от конференций гиков до признания широкой общественностью. Другим способом ворваться в «мейнстрим» является поддержка уже известного вендора, например такого, как компания … Майкрософт. Большинство людей инерционны и не будут вкладывать свои силы в «нонейм» инструменты, пока не удостоверятся, что их капиталовложение будет востребовано. Если же инструментом занимается подобный вендор, то риск изучить что-то, что не пригодится в будущем, очень не велик.

На самом деле такое мнение весьма близоруко, поскольку при изучении нового инструмента, языка или технологии вы развиваетесь, узнаете что-то новое и включая способности применять эти подходы в другом контексте. Это особенно справедливо, когда речь касается новых парадигм программирования, таких как функциональное программирование, которое само по себе не привязано к конкретному языку или технологии.

Microsoft Moles

Moles – это легковесный тул от MS Research, который умеет автоматически генерировать заглушки для интерфейсов и виртуальных методов, а также для sealed классов, невиртуальных и статических методов (!), путем генерации кода, которому позднее можно будет подсунуть нужный делегат, вызываемый вместо определенного метода. Первый тип заглушек называется стабы (stubs), а второй – молы (moles). Именно эту штуку я использовал для тестирования асинхронных операций, о которых я рассказывал ранее, но давайте обо всем по порядку.

Stubs

Давайте рассмотрим такой пример. Предположим, что мы понимаем ценность модульных тестов, а также таких принципов, как Dependency Inversion, и других безумно полезных принципов и паттернов (может быть всех остальных принципов S.O.L.I.D., а возможно даже и F.I.R.S.T.). И дело даже не в том, что мы фанаты тестов или дядюшки Боба, а просто потому, что мы знаем, что высокая связность – это плохо. Поэтому мы стараемся в разумных пределах уменьшить зависимости путем выделения интерфейсов с последующим «инжектом» их в конструкторы классов или в методы, которым эти интерфейсы необходимы для выполнения своих задач.

Знакомство с асинхронными операциями в C# 5

• Часть 1. Асинхронные операции и AsyncEnumerator
• Часть 2. “Реактивные расширения” и асинхронные операции
• Часть 3. Знакомство с асинхронными операциями в C# 5

В прошлый раз мы говорили о том, как можно упростить работу с асинхронными операциями с помощью класса AsyncEnumerator Джеффри Рихтера, а также с помощью библиотеки Reactive Extensions. Однако, как поведал нам недавно Хейлсберг с компанией, счастье таки наступит с выходом новой версии языка C# и нам не понадобится использовать сторонние и не очень велосипеды, при работе с асинхронными операциями.

Идея, которая лежит в основе асинхронных операций в C# 5, очень похожа на ту, которую использовал Джеффри Рихтер в своем классе AsyncEnumerator, только на этот раз помимо нас с вами и старины Рихтера о ней еще узнал и компилятор (что здорово сказывается на вкусовых качествах сего синтаксического сахарка).  Для начала, давайте вернемся к синхронной версии нашего гениального примера, который мы использовали ранее:

static void SyncVersion()
{
    Stopwatch sw = Stopwatch.StartNew();
    string url1 = "http://rsdn.ru";
    string url2 = "http://gotdotnet.ru";
    string url3 = "http://blogs.msdn.com";
    var webRequest1 = WebRequest.Create(url1);
    var webResponse1 = webRequest1.GetResponse();
    Console.WriteLine("{0} : {1}, elapsed {2}ms", url1,
        webResponse1.ContentLength, sw.ElapsedMilliseconds);
 
    var webRequest2 = WebRequest.Create(url2);
    var webResponse2 = webRequest2.GetResponse();
    Console.WriteLine("{0} : {1}, elapsed {2}ms", url2,
        webResponse2.ContentLength, sw.ElapsedMilliseconds);
 
    var webRequest3 = WebRequest.Create(url3);
    var webResponse3 = webRequest3.GetResponse();
    Console.WriteLine("{0} : {1}, elapsed {2}ms", url3,
        webResponse3.ContentLength, sw.ElapsedMilliseconds);
}