Subscribe Twitter

воскресенье, 17 августа 2014 г.

Книга "Illustrated C#"

Эта книга довольно не плохо объясняет базовые вещи.

воскресенье, 6 июля 2014 г.

Небольшая заметка по поводу RhinoMocks

RhinoMocks имеет разные варианты использования, и порой может слегка вводить в заблуждение. Я например, вот про этот аспект регулярно забываю, если долго не пишу тесты на Rhino: Стаб не имеет ожиданий и предназначен для тестирования состояния класса, но при желании ожидания для стаба можно установить и уже тестировать поведение. Если мы напишем:
    public interface IFoo
    {
        void Method1();
        void Method2();
    }

    public class TestedClass
    {
        private IFoo _foo;

        public TestedClass(IFoo foo)
        {
            _foo = foo;
        }

        public void TestedMethod()
        {
            _foo.Method1();
            _foo.Method2();
        }
    }

    [TestMethod]
    public void Test1()
    {
        MockRepository repository = new MockRepository();
            
        IFoo foo = repository.Stub<IFoo>();
        //IFoo foo = repository.StrictMock<IFoo>();
        //IFoo foo = repository.DynamicMock<IFoo>();
            
        //foo.Expect(x => x.Method1());
        //foo.Expect(x => x.Method2());        

        repository.ReplayAll();

        TestedClass test = new TestedClass(foo);
        test.TestedMethod();

        repository.VerifyAll();
    }
то тест благополучно пройдет, так как у стаба по умолчанию нету ожиданий. Но стоить только указать в ожиданиях вызов хоть одного метода, и stub начинает вести себя как самый настоящий StrictMock и в отличии от DynamicMock'a ругается на вызов любого непредусмотренного метода. Также, можно при желании "избавить от каких либо обязательств" StrickMock "застабив" все его методы :)
    IFoo foo = repository.StrictMock<IFoo>();
    foo.Stub(x => x.Method1());
    foo.Stub(x => x.Method2());  
и в таком случае нам уже не важно, вызывалось ли что-то в тестируем классе :)

вторник, 1 января 2013 г.

Threading in C#. Joseph Albahari

Закончил читать "Threading in C#". Хорошая обзорная книга. Дает представление об определенных тамах, в которые при необходимости можно углубиться используя другой ресурс. Как вариант, может быть очень полезна при подготовке к собеседованию.

PS. Не забыть о термине "Примитивы синхронизации" :)

четверг, 15 ноября 2012 г.

Создание экземпляра интерфейса.

Немного шокирует, что эта штука будет работать :)
using System;
using System.Runtime.InteropServices;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            // ухты !!!
            IFoo i = new IFoo("Hello");
            i.Print();

            Console.WriteLine(i.GetType());

            Console.ReadLine();
        }

        [Guid("40DCF1C3-C39D-4BB0-B967-1391C56E2852")]
        [CoClass(typeof(Foo))]
        [ComImport]
        interface IFoo
        {
            void Print();
        }

        class Foo : IFoo
        {
            private string _message;

            public Foo(string message)
            {
                _message = message;
            }

            public void Print()
            {
                Console.WriteLine(_message);
            }
        }
    }
}

К интерфейсу (во время компиляции!) "подвязывается" экземпляр дефолтового класса (что-то типа Activator.CreateInstance(Type.GetTypeFromClsid(GUID OF COCLASSTYPE)), и дальше все работает так, будто бы мы явно создавали экземпляр конкретного класса. Вникать историю развития COM особого желания нету, но пример забавный. К сожалению, трудно представить реальное применение этой фичи.

суббота, 1 сентября 2012 г.

IT Jam 2012

Сходил на IT Jam 2012. Если верить организаторам, то пришло более 3000 человек. Бедный "Олимпийский", просто не выдержал такого наплыва посетителей:) Из докладов был на: 1. "Value Driven - The Future of software development". Cristopher Marsh. Если честно - чуть не уснул... 2. "Deja vu". Greg Young. Было бы неплохо, если бы названия докладов небыли настолько размытыми. Местами было интересно, но мы решили пойти общаться с .NET-чиками, в итоге думаю, что выиграли. Вообще, формат IT Jam в этом году подразумевал живое общение. Ребята вешали на шею таблички с ключевыми словами (к примеру многопоточность, или NoSQL), по поводу которых с энтузиазмом отвечали на вопросы всех желающих. Как по мне, было гораздо полезнее и интереснее, чем слушать официальных докладчиков у проекторов. Грег, с нашим парнем (не знаю имени) нарисовали "страшную" диаграмму, и бурно обсуждали какие-то очереди. Вникнуть не вышло, так как вокруг собралось куча народа, и было плохо слышно. Пообщался с парнем из команды Resharper'a - умен:) Как я понял, вопросом по поводу оптимизации производительности Resharper его немного замучали. На автапати можно было пойти в "Lucky pub", но туда пришло очень много людей, нормально поесть было просто невозможно. Поэтому, сделав круг мы вернулись к олимпийскому, и сели в "Баварском доме пива". Программисты очень часто говорят о работе, но если честно, то от такого количества умных слов (или от шума, который подняли человек 20 голодных программеров:) ) - у меня разболелась голова. Было бы круто, если бы у нас было побольше мероприятий с более технологическими докладами. Например, в стиле Роя Ошерове (Roy Osherove) про TDD, но можно без песен:) Сходить что-ли в клуб анонимных разработчиков ?

понедельник, 9 июля 2012 г.

Scrum and XP from the Trenches

Прочитал Scrum and XP from the Trenches. Пожалуй, для быстрого знакомства самое оно. Книга очень легко читается, и примеры из книги близки к жизни. К сожалению, скрам вовсе не является панацеей, и как любую методологию его можно довести до абсурда. Но, как минимум это лучше чем ничего. Интересно, что многие команды, даже практически не зная ничего о скраме, интуитивно к чему-то подобному приходят. Могу сказать, что скрам точно не будет работать в украинской говно шарашкиной конторе, где владелец бизнеса (не надо мне расказывать о волшебных стартапах) находится слишком близко к разработчикам. Человек просто не захочет мириться с тем, что у команды есть голос, и воспримет стендапы, ретроспективы и планнинги как бесполезную трату времени и его денег. В теории, конечно, можно кому-то что-то объяснить (доказать), но на практике, рядовой сотрудник (а еще больше тимлид) просто бесцельно подорвет свое здоровье.

суббота, 16 июня 2012 г.

PATTERNS OF PARALLEL PROGRAMMING

Читаю Шаблоны паралельного программирования. Очень хорошо объясняется как различные проблемы решались без новых фич 4-ого фреймворка, и как элегантно они решаются с ним. Ну а этот пример, вообще шедеврален:)
int data1 = 42;
string data2 = "The Answer to the Ultimate Question of " +
               "Life, the Universe, and Everything";
Task.Factory.StartNew(()=>
{
    Console.WriteLine(data2 + ": " + data1);
});