Lviv .NET User Group

Mobilination!

2011-12-09T18:48:00.000+02:00

Оригинал тут: http://softserve.ua/press-center/news/mobilination-22122011

Міні-конференція Mobilination

09 Грудня / Новини компанії

22 грудня вперше, за підтримки компанії SoftServe, відбудеться міні-конференція - Mobilination. Цього дня, ми запрошуємо на зустріч усіх, хто цікавиться мобільними технологіями, мобільними пристроями, мобільним майбутнім у бізнесі та в побуті. Доповідачі будуть ділитися своїми дослідженнями і досвідом, говоритимемо про можливості та тренди у цій галузі.

Запрошуємо послухати:

Василя Милька (SoftServe) - “The World is Not Flat”.

“Mobility is not a mobile phone. It is about doing business off the office, it is about consuming off the store.”

Дмитра Малєєва (SoftServe) - “Darwin theory of Mobile evolution”.

“Let’s travel from the beginning of the mobile world, and see who is stronger now, who lost in past, and who will be king of the hill in future!”

Рустама Іскандарова (SoftServe) -“How to fit Elephant in a box”.

“Discover opportunities and limitations from technology and user experience perspective.”

Олексія Орлова(SoftServe) - “Golden rush for enterprise mobility”.

“Size of the mobility pie. Structured approach to enterprise. Impact of enterprise golden rush for mobilization on outsourcers and developers.”

Отличный подкаст, отличных людей

2011-12-09T13:37:00.002+02:00

Коллеги,

Хотел бы прорекламировать отличный подкаст: http://www.dotband.com/

Посвященный .NET с гиковским нотками:)

Больше подкастов интересных и хороших!

October' Lviv .NET User Group Summary

2011-10-21T18:18:00.003+03:00

Привіт!

Після двохмісячної перерви відбулась жовтнева зустріч, яка розпочалась з неочікувано великої кількості бажаючих прийти - в першу годину відкриття зареєструвалось 45 учасників, а вже через два дні, коли кількість учасників перевищила 100 довелось закривати реєстрацію.

І зустріч виправдала очікування: Остап Коркуна, інженер з Facebook, не лише лаконічно і доступно описав, як працює найбільша в світі соцмережа, а й привідкрив штору на цікаве та яскраве життя в стінах офісу Марка Цукерберга і його команди з 2500 людей.

Продовжив зустріч Діма Малєєв розповіддю про три машчних абревіатури - SOA, SaaS i S+S. Кожен з учасників отримав хороше домашнє завдання дослідити ці теми детальніше.

І завершив жовтневу зустріч Роман Крайовський з оглядом тенденцій росту молодого покоління ІТ спеціалістів в Україні і які якості потрібні українській ІТ індустрії щоб вийти на наступний рівень.

Далі - більше і цікавіше...
До нових зустрічей :)

Lviv .NET User Group.

2011-10-12T15:33:00.002+03:00

Всем привет,

Неожиданно опять встреча!

Место проведения - SoftServe, Володимира Великого 52, 19:30.

Дата: 20 октября

Докладчики:
1. Остап Коркуна, Facebook. Остап - львовянин работающий в Facebook. Он нам расскажет о том как живется в Facebook, какие технологию используются, как попасть, и т.д.

2. Дима Малеев, SoftServe. Тема: "WTF SOA SaaS S+S"

3. Рома Крайовский, GlobalLogic. Рома расскажет о том какие тенденции на рынке труда, какими умениями надо обладать, и куда все это катится:)

Регистрация тут: http://bit.ly/lvivdotnet15

Важно!Регистрация обязательна! Без нее мы не в силах Вас пустить.

РЕГИСТРАЦИЯ ЗАКРЫТА!БОЛЬШЕ МЕСТА НЕТУ :(

Новое коммьюнити! Привет, Тестеры!

2011-09-27T18:38:00.000+03:00

Ура! Ура! Ура!

Случилось то, чего так долго ждала темная сторона девелопмента! У тестеров появилось свое коммьюнити! Ура!

Репост:

Коллеги,

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

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

Более того, на мероприятии выступят почетные гости каждого ИТ-сообщества - Слава Панкратов и Александр Орлов.

План мероприятия:
19:30-19:45 Открытие, чай с печеньками :)
19:45-20:25 Александр Орлов "Человеческий фактор в QA"
20:25-21:05 Слава Панкратов "Про карьеру в тестировании"
21:05-21:30 Закрытие, знакомства, неформальное общение.

Ждем Вас в пятницу 30.09 в конференц-зале SoftServe, вул. В. Великого, 52

Карта: http://bit.ly/nbE81g

Форма регистрации: http://bit.ly/oU6I22

Не пропустите, мероприятие обещает быть интересным и увлекательным.

Генеральный спонсор: http://softserve.ua/

Информационная поддержка:

http://testers.lviv.ua/

256 день в году!

2011-09-13T10:44:00.001+03:00

Коллеги,

Мы Вас категорически поздровляем с этм чудесным днем! Желаем Вам самого, что ниесть безбажного кодинга, приятного рефакторинга, сговорчивых QA и понятливых заказчиков! А ещё конечно же - отличной погоды в семье, здоровья, и исполнения Всех целей и желаний!

С Уважением,
-Администрация юзер группы!

WP7 Хакатон во Львове

2011-09-12T16:26:00.000+03:00

А вот наши друзья с WP7Rocks! проведут во Львове Хакатон! Можно поучавствовать!

Последнее время проводить хакатоны стало модно. Мы тоже не хотим отставать от моды, поэтому решили провести хакатон "Windows Phone 7 Rocks!" для всех любителей платформы Windows Phone 7.

Что нас ждет:

24 часа нонстопа разработки приложений для Windows Phone 7;
море общения с разработчиками мобильных приложений;
обучающий видеокурс по разработке для Windows Phone 7 от компании Pluralsight!
воркшопы и презентации.

Условия участия:

команда до 3 человек;
наличие ноутбука с ОС Windows с установленными Windows Phone 7 SDK;
телефон под управлением Windows Phone 7 (если нет – тогда мы постараемся найти телефон для вашей команды – об этом укажите в анкете ниже);

Если вы пишите софт для других мобильных платформ – Android, iPhone, Symbian – мы также ждем вас на хакатоне, где вы сможете обменятся идеями, сравнить различные платформы и пощупать реальные устройства под управлением Windows Phone 7.

Участники хакатона получат памятные сувениры, а победители получат ценные призы от Microsoft Украина и главного партнера мероприятия – компании SoftServe.

Детали тут!

1 Октября! Uneta+

2011-08-19T17:15:00.000+03:00

Живая коммуникация и обмен опытом между разработчиками в IT-сфере сильно затруднены: такова специфика работы. Чтобы объединить профессионалов отрасли и навести мосты между их сетями, компания Digital Cloud Technologies проводит конференцию UnetaPlus. Она посвящена проблемам отрасли: новые тренды, тенденции софтостроения, последние приложения индустрии.

Начало работы запланировано на 1 октября, 9.00 (суббота). Формальная часть конференции завершится в 18.00, и начнется неформальная часть вечера: фуршет для участников.

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

Вы работаете в сфере IT и давно хотели живого общения с опытными мастерами отрасли? Не упустите шанс попасть на UnetaPlus!

Больше тут - http://uneta.ua/

Lviv .NET User Group #14

2011-07-28T17:50:00.003+03:00

Привіт!

Як справи? Як літо минає?

Щоб обговорити хто як проводить сонячні теплі літні дні ми знову зустрічаємось!

Коли: 4 серпня, четвер. Старт о 19:30

Де: офіс GlobalLogic (вул.Шептицьких, 26), GL-Club (5 поверх, на вході стоятиме наша людина і пояснить як туди потрапити)

В програмі:

Доповідь 1: Андрій Микитюк - Project Coordinator, Certified Scrum Master @ SoftServe Inc. - "Технології креативності"

Доповідь 2: Сергій Смертін - Senior Software Engineer @ EPAM Systems - "Symfony2: Next generation PHP"

Доповідь 3 (в стилі Pecha Kucha): Роман Крайовський - "Комп'ютерна соціалізація - як все починалось"

Афте-паті: піца, пиво, квас, турніри з теккена і мортал комбата

+ сюрприз від компанії GlobalLogic ;)

Як видно, ми розширяємо кордони - як географічно, періодично проводячи зустрічі в різних локаціях, так і тематично - говоримо не тільки про .НЕТ, а й про те, що допомагає нам бути максимально ефективними в своїй роботі і робити новий крок в особистому рості.

Прохання зареєструватись тут. (потрібно для замовлення піци і пива)

До зустрічі ;)

Новая юзер группа Львова! Lviv EDGE User Group!

2011-07-05T15:58:00.000+03:00

Копипаста со страници группы:

Всім привіт!

Хочу представити нову спільноту - EDGE Lviv.

Метою створення є поширення знань та досвіду по передовим та складним технологіям серед розробників.
За форматом спільнота буде подібна до інших львівських юзер груп.
Принциповою відмінністю є відсутність прив'язаності до певних платформ та акцентування уваги на складних та нових речах. Тобто EDGE Lviv буде в першу чергу цікава тім/тех лідам та сініорам або просунутим розробникам, які вже ствердились як розробники і шукають нових викликів.

Враховуючи розміри львівського ІТ, тем для доповідей буде більше чим достатньо!
Якщо у вас є думки як можна покращити спільноту або ідеї щодо більш ефективніших шляхів обміну досвідом, буду завжди радий почути!

З повагою,
Зеник

Сайт группы

Lviv .NET User Group - 13 щасливих зустрічей за плечима! Попереду більше...

2011-07-02T14:43:00.001+03:00

Доброго суботнього ранку, друзі!

Перша зустріч в новому році житті юзер групи відбулась і, варто зазначити, відбулась успішно незважаючи на свій "нещасливий" порядковий номер.

Конференц-зал СофтСерва був заповнений до останнього стільчика учасниками зустрічі, серед яких ми впізнали як добре знайомих, постійних, активних учасників, так і з радістю провели бойове хрещення піцою, пивом і мортал комбатом для новачків.

Власне, доповіді.

Діма Малєєв вирішив нікого не дивувати сюрпризами і виступив блискуче!

В залі відчувався тріскіт черепних коробок і викручування звилин, тому що думка про явище "Enterprise Architecture" змінювалася в корені з кожним наступним слайдом і словесним піруетом спікера. Хтось пригадав, що таке писати софт для 50-річних бухгалтерів, хтось подивився на не-ІТ-шні реалії під новим кутом зору, а основна думка, яку Діма точно доніс до аудиторії - ми пишемо софт не заради самого софта, а заради того, що СЕО десь там на верху цього самого ентерпрайзу хоче продати в країни третього світу 300 млн тапочок в наступному році, і про це потрібно говорити в кожному новому рядку коду, на якій технології він би не був написаний.

Домашнє завдання: http://en.wikipedia.org/wiki/Zachman_Framework

З радістю пишу наступні рядки.
З радістю, тому що юзер група поповнюється не тільки новими слухачами, а й новими доповідачами.

Дебют Андрія Івачевського (Tech Lead, GlobalLogic Lviv) був присвячений оптимізації веб аплікацій на стороні клієнта.
Андрій детально і точно розкрив всі сучасні реалії пов'язані з проблемами, які постають перед веб розробниками, тендеції розвитку останніх і, що найважливіше, показав практичні шляхи їх усунення заради задоволення клієнта, який побачить бажану сторінку в свому браузері на декілька десятків мілісекунд швидше аніж в нашого конкурента!

Коментарі і запитання впродовж виступу і після його зваршення свідчать, що тема була знайомою і наболілою для присутніх в залі.

Андрій - well done! Як то кажуть, пиши ещё!

Користуючись нагодою хочу передати привіт і подяку компанії SoftServe, яка люб'язно прийняла гостей юзер групи в свому офісі, нагодувала піцою і напоїла пивом під удари Лю Кенга і Шиви від джойстиків завзятих геймерів. Дя-ку-є-мо!

Дальше - більше. Побачимось через місяць.

Хакатон Львов

2011-06-21T16:47:00.000+03:00

http://www.developers.org.ua/calendar/650/

Пройдет: 9 — 10 июля

Место:офис GlobalLogic, ул. Шептицких, 26

Многие программисты уже знают, что такое Хакатон по-киевски.
Теперь мы едем у файне мiсто Львiв!
Правила те же — 24-х часовой марафон программеров и разработчиков, которые в регламентированное время должны написать работающую к финалу мероприятия программу или хак. Ну и, конечно же, продемонстрировать своё творчество остальным самостоятельно или всей командой. Язык и технология — на ваше усмотрение. Веб, десктоп или mobile. Самое главное — чтобы было интересно!

Программа

16:00 — 16:30 Старт Хакатона. Полчаса даем на анонс идей своих проектов и поиск команды для тех, кто пока «неопределился».
19:30 — 21:30 Tech Talks. Для тех, кто не сильно занят кодированием — блок технических докладов, 15 минут на доклад. Темы разные, от mobile & agile до NET и gamedev.
Ночью — чемпионат по Xbox/шашкам/мафии, гитара и прочие необходимые компоненты Хакатона
15:00 вск — регистрация выживших команд и проектов на демо
15:30 — 16:15 Демо! Каждая команда получает 4 минуты времени перед аудиторией
16:15 — 16:30 Голосование и награждение победителей
17:30 — до конца Афтерпати для самых стойких

Регистрация

Мероприятие бесплатно для участников, при условии предварительной регистрации. Приходить без регистрации тоже можно, но тогда приготовьте плз 50 грн с команды. :) Регистрация простая — оставьте комментарий к событию со своим именем и количеством людей в вашей команде.
Приглашаем всех на ДЕМО-часть, посмотреть что же смогли сделать участники за 24 часа.

Tech talks

В этот раз мы хотим расширить программу Хакатона техническими докладами. Рассчитываем на 7-10 докладов, каждый по 5-10 минут. Темы практически любые, ищем докладчиков! Пишите в комментарии или мне на ischenko@gmail.com.

Lviv .NET User Group# 13.

2011-06-20T11:23:00.002+03:00

Всем привет,

Мы взяли небольшой перерыв, но снова вернулись! 30 июня, 19:30, офис компании SoftServe на В.Великого 52!

Темы встречи:

1.Enterprise Architecture on MS Stack. Малеев Дмитрий
2.Optimizing Client-Side Performance. Андрій Івачевський

Линк на регистрацию тут!

"Патерн Вівторка" #25: Інтерпретер (Interpreter)

2011-05-31T03:17:00.002+03:00

Якась уявна компанія веде дуже дивний бізнез. Вони скупляють усе барахло, яке люди виставляють під час так званих "гаражних" розпродаж, набивають ними вантажівки, а в кінці робочого дня пробують порахувати на скільки вони того набрали і за скільки зможуть продати в інший час у іншому місці. Оскільки більшість речей із розпродажі запакована у якісь старі упаковки, а також тому що багато чого має хаотичний спосіб розташування у вантажівці інколи порахувати загальну ціну важко. Але якщо ми знаємо поточний контекст цін, граф речей у вантажівці, то це зробити можна. Компанія також унікальна тим, що відповідальнісь за рахунок загальної суми покладається на вантажівку. Певним чином вона знає що повинна додати ціну усіх упаковок, кожна упаковка знає що вона повинна додати ціну чи то упаковок чи то речей і т.д.

ІНТЕРПРЕТЕР

Інтерпретер це дизайн патерн, що дозволяє описати граматику певної мови, за допомогою чого можна записати речення на цій мові та інтерпретувати його значення.

Говорячи про наш дещо дивний приклад, мовою буде вантажівка/упаковка/різні речі, реченням буде поточне заповнення вантажівки, а значенням речення буде загальна ціна речей всередині.

Існує два види виразів у мові: такі які можна зрозуміти одразу, такі вирази називаються термінальними (terminal expressions), та такі які вимагають застосування граматичних правил мови, їх називають нетермінальними виразами (nonterminal expressions).

Проводячи паралелі із нашим прикладом, термінальним виразом буде старий телевізор, ноут або ліжко, оскільки ми зараз знаємо ціну на них, а нетермінальни виразом буде упаковка у яку закинули 3 ноутбуки, в такому випадку потрібно буде ще рахувати скільки коштуватиме вміст такої упаковки.

Глянемо на вихідний код прикладу:

Ось вирази які використовуються у нашій мові:

// Abstract expression
    public abstract class Goods
    {
        public abstract int Interpret(CurrentPricesContext context);
    }

    // Nonterminal expression
    public class GoodsPackage : Goods
    {
        public List<Goods> GoodsInside { get; set; }

        public override int Interpret(CurrentPricesContext context)
        {
            var totalSum = 0;
            foreach (var goods in GoodsInside)
            {
                totalSum += goods.Interpret(context);
            }
            return totalSum;
        }
    }

    // Terminal expression
    internal class TV : Goods
    {
        public override int Interpret(CurrentPricesContext context)
        {
            int price = context.GetPrice("TV");
            Console.WriteLine("TV: {0}", price);
            return price;
        }
    }

    // Here other terminal expressions go (Laptop, Bed)

Як можна побачити GoodsPackage знає про те як його можуть зрозуміти, а саме коли він просумує ціну речей всередині. У нашому прикладу мова дуже вже проста із тільки одним правилом, але у інших мовах усе буде набагато складніше. Для прикладу у якійсь уявній мові пов'язаній із обрахунками такими правилами нетермінальними виразами зможуть бути “+”, “-”, “/”, “*”, “Sqrt”, “Integral”, або ще щось інше. Така мова також буде мати ширший вибір термінальних виразів.

Залишилися ще дві речі які відіграють помітну роль у патерні. Це контекст (context), який відображає глобальну інформацію для процесу інтерпретування. У нашому прикладі це контекст сьогоднішніх цін у певному місті. Ще однією роллю у патерні є клієнт, який відповідає за отримання (створення) речення та виклику методу інтерпретації. Нижче наводиться тільки код клієнту, оскільки код контексту не є дуже важливим.

public void RunInterpreterDemo()
        {
            // create syntax tree that represents sentence
            var truckWithGoods = PrepareTruckWithGoods();
            // get latest context
            var pricesContext = GetRecentPricesContext();
            // invoke Interpret
            var totalPriceForGoods = truckWithGoods.Interpret(pricesContext);

            Console.WriteLine("Total: {0}", totalPriceForGoods);
        }

        private CurrentPricesContext GetRecentPricesContext()
        {
            var pricesContext = new CurrentPricesContext();
            pricesContext.SetPrice("Bed", 400);
            pricesContext.SetPrice("TV", 100);
            pricesContext.SetPrice("Laptop", 500);
            return pricesContext;
        }

        public GoodsPackage PrepareTruckWithGoods()
        {
            var truck = new GoodsPackage() { GoodsInside = new List<Goods>() };

            var bed = new Bed();
            var doubleTriplePackedBed = new GoodsPackage() { GoodsInside = new List<Goods>() { new GoodsPackage() { GoodsInside = new List<Goods>() { bed } } } };
            truck.GoodsInside.Add(doubleTriplePackedBed);
            truck.GoodsInside.Add(new TV());
            truck.GoodsInside.Add(new TV());
            truck.GoodsInside.Add(new GoodsPackage() { GoodsInside = new List<Goods>() { new Laptop(), new Laptop(), new Laptop() } });

            return truck;
        }

А ось вивід:

Bed: 400
TV: 100
TV: 100
Laptop: 500
Laptop: 500
Laptop: 500
Total: 2100

І ще одне дуже важливе: Інтерпретер це такий дизайн патерн, який швидше за все вам ніколи не пригодиться у житті. Він має дещо специфічне застосування.

Моя табличка Патернів

Lviv .Net User Group #12! День рождения удался :) Впечатления

2011-05-16T15:25:00.007+03:00

Всем привет,

Ура мы выжили! 12-я встреча прошла на ура! Еще раз всех поздравляю с нашим маленьким праздником, — "С денем рождения Lviv Dot Net Usergroup!"

Сразу хочу сказать огромное спасибо докладчикам.

Денис Пасечник, интересно и со вкусом рассказал о современных способах менеджмента проектов на базе технологии Microsoft. Особенно порадовал пример с подкачкой колес, уверен что все после этой встречи сездили на СТО и подкачали :)

Юлиан Слободян, раскрыл нам тайну "денежной трубы" Twitter’а :) Теперь мы с уверенностью можем заявить, что CIA, FBR и ФСБ мониторят наш трафик. *ага, за вами уже выехали, чмаки СБУ* И показал на практике как эту трубу можно использовать с помощью технологии StreamInsight. Лично для себя в обоих докладах нашел много информации для практического применения, чем и занялся в Понедельник.

Встреча прошла в новом помещении компании MalkosUA, в Доминант плаза на Угорской. Компания очень тепло встретила нас и предоставила в наше распоряжение огромнейший зал (легко вместилось бы и 100-150 человек),обставила и оформила его, накормила нас пиццами, напоила колами и соками и подарила нам вкуснейший торт, с логотипом нашей user group! Ну а XBox и пиво, уже стали просто неотъемлемыми атрибутами наших встреч :)

Кстати, каждый из презенторов получил ценные подарки. Опять футболки и рюкзачки, подумали вы? Неееет! MalkosUA и тут посуетились, и предоставили нам возможность дарить ценные книги, на английском языке, ага прямо с amazona, еще тепленькие :) Денис получил Rework от 37 signals, а Юлиан, толстенную C# 4.0 in Nutshell.
Так что теперь у вас еще больше мотивации делать доклады!

По средним подсчетам на эту встречу пришло больше 40-а человек. Это больше половины зарегистрированных и мы сделали выводы, что:

40 человек пришедших по доброй воли, означает, что вам интересно, и группа движется в правильномнаправлении.
постепенно костяк группы формируется, и остаются те кто действительно заинтересован в её развитии.
Доклады становятся всё интереснее.

Итоги:

Ровно 12 встреч за год, показатель стабильности и заслуга основателей, идейного и духовного лидеров группы — Димы Малеева и Ромы Крайовского, за что им спасибо.

Постоянная посещаемость, и активное участие в жизни группы, за что спасибо вам, дорогие пользователи, без вас група существовать не может.

Цели:

Расти, сделать Львовское комюнити, одним из лучших и интереснейших в Украине.

Вырастить новых докладчиков. Давать еще больший заряд мотивации и полезной информации пользователям,помните движение — жизнь!

Фотографии со встречи

P.S from Dima:

Очень приятно что впечатления писал в этот раз не я, и услышать столько теплых слов в свою сторону. У Нас (меня с Ромой) очень многое бы не получилось, без:

1. Вас пользователи группы. Сосбтвенно именно с Вами мы формируем коммьюнити.

2. Пети Процаха, того кто постоянно следит за нашим гугл календарем, исправляет ошибки, и напильником обработал дизайн нашего блога.

3. Макс Титов и Йосып Прокопяк, без этих двух жизнерадостных гавриков не было бы костяка. :)

4. Дима Андреев, самый молодой член нашей комманды:) Делай фотки и дальше!

"Патерн Вівторка" #24: Проксі (Proxy)

2011-05-10T23:08:00.006+03:00

Спробуйте себе уявити у процесі знешкодження бомби? Невже не лячно? Навіть якщо вам важко таке уявити або ви вважаєте що й так ніколи нічого подібного не будете робити, комусь всештаки приходиться знешкоджувавати бомби час від часу. Можу поручитися, що сапери, за винятком тих які хильнули чвертку, також відчувають страх перед вибухівкою. На наше щастя зараз є багато різних технологій, які дозволяються обійтися без присутності людити під-час знешкодження вибухового матеріалу. Більше того робот може проробити дещо більш складніші операції аніж людина, оскільки він точніший і більш потужніший (проте напевно неповороткий). Принаймні в робота не трясуться руки на відміну від сапера-напідпитку.
Комунікація із таким роботом звісно безпровідна, керування здійснюється за допомогою кінекту, або якогось костюму або принаймні супер джойстиків, робот також має панель управління на собі, яка б дозволила керувати ним безпосередньо на місці, на випадок якщо якийсь внучок Бен Ладена буде блокувати сигнал до робота.

ПРОКСІ

Проксі це дизайн патерн, що підміняє реальний об'єкт та надсилає запити до нього тоді коли це потрібно, проксі також може ініціалізувати реальний об'єкт, якщо той до того не існував.

Говорячи про приклад вище реальним об'єктом є робот (RobotBombDefuser) це купа важкого залізаччя яким ми можемо керувати за допомогою віддалених контролів (RobotBombDefuserProxy). Так як чудо-кінект установка передає сигнали на робот вона звісно знає як приєднатися до справжнього робота і передавати йому сигнали від ваших рухів. Насправді щось подібне відбувається коли ви приєднуєтеся до віддалених сервісів і викликаєте якісь методи на них.
Проксі також часто використовується коли потрібна лінива ініціалізація. В такому випадку реальний об'єкт не буде створений допоки не буде звертання до якихось методів. Всередині проксі методу добаляється перевірка чи справжній об'єкт не ініціалізований і якщо ні, то тоді ініціалізує його.

Давайте глянемо на наш приклад. Ось сам робот:

public class RobotBombDefuser
    {
        private Random _random = new Random();
        private int _robotConfiguredWavelength = 41;
        private bool _isConnected = false;

        public void ConnectWireless(int communicationWaveLength)
        {
            if(communicationWaveLength == _robotConfiguredWavelength)
            {
                _isConnected = IsConnectedImmitatingConnectivitiyIssues();
            }
        }
        public bool IsConnected()
        {
            _isConnected = IsConnectedImmitatingConnectivitiyIssues();
            return _isConnected;
        }
        private bool IsConnectedImmitatingConnectivitiyIssues()
        {
            return _random.Next(0, 10) < 4; // immitates 40% good connection, aka. very bad
        }

        public virtual void WalkStraightForward(int steps)
        {
            Console.WriteLine("Did {0} steps forward...", steps);
        }

        public virtual void TurnRight()
        {
            Console.WriteLine("Turned right...");
        }

        public virtual void TurnLeft()
        {
            Console.WriteLine("Turned left...");
        }

        public virtual void DefuseBomb()
        {
            Console.WriteLine("Cut red or green or blue wire...");
        }
    }

Основні методи, що роблять усю роботу є WalkStraightForward, TurnRight, TurnLeft, DefuseBomb. Є також методи, які з'єднуться безпровідно та перевідка чи є з'єднання (IsConnected) вони потрібні для більшої реальності цього прикладу. Можливо вони несуть додатковий шум, якщо так то можна їх упустити при читанні коду.

А ось реалізація самого Проксі. Проксі завжди має посилання на реальний об'єкт і часто наслідується від того ж класу яким є реальний об'єкт.

public class RobotBombDefuserProxy : RobotBombDefuser
    {
        private RobotBombDefuser _robotBombDefuser;
        private int _communicationWaveLength;
        private int _connectionAttempts = 3;

        public RobotBombDefuserProxy(int communicationWaveLength)
        {
            _robotBombDefuser = new RobotBombDefuser();
            _communicationWaveLength = communicationWaveLength;
        }

        public virtual void WalkStraightForward(int steps)
        {
            EnsureConnectedWithRobot();
            _robotBombDefuser.WalkStraightForward(steps);
        }

        public virtual void TurnRight()
        {
            EnsureConnectedWithRobot();
            _robotBombDefuser.TurnRight();
        }

        public virtual void TurnLeft()
        {
            EnsureConnectedWithRobot();
            _robotBombDefuser.TurnLeft();
        }

        public virtual void DefuseBomb()
        {
            EnsureConnectedWithRobot();
            _robotBombDefuser.DefuseBomb();
        }

        private void EnsureConnectedWithRobot()
        {
            if (_robotBombDefuser == null)
            {
                _robotBombDefuser = new RobotBombDefuser();
                _robotBombDefuser.ConnectWireless(_communicationWaveLength);
            }

            for (int i = 0; i < _connectionAttempts; i++)
            {
                if (_robotBombDefuser.IsConnected() != true)
                {
                    _robotBombDefuser.ConnectWireless(_communicationWaveLength);
                }
                else
                {
                    break;
                }
            }
            if(_robotBombDefuser.IsConnected() != true)
            {
                throw new BadConnectionException("No connection with remote bomb diffuser robot could be made after few attempts.");
            }
        }
    }

Таким чином наш проксі просто передає запити до справжнього об'єкту і завжди перед тим перевіряє чи з'єднання не пропало, і якщо пропало пробує тричі його відновити. Якщо і після цього не виходить, то викидується помилка.

Ось використання проксі:

public static void Run()
        {
            int opNum = 0;
            try
            {
                var proxy = new RobotBombDefuserProxy(41);
                proxy.WalkStraightForward(100);
                opNum++;
                proxy.TurnRight();
                opNum++;
                proxy.WalkStraightForward(5);
                opNum++;
                proxy.DefuseBomb();
                opNum++;

                Console.WriteLine();
            }
            catch (BadConnectionException e)
            {
                Console.WriteLine("Exception has been caught with message: ({0}). Decided to have human operate robot there.", e.Message);

                PlanB(opNum);
            }
        }

        private static void PlanB(int nextOperationNum)
        {
            RobotBombDefuser humanOperatingRobotDirectly = new RobotBombDefuser();

            if(nextOperationNum == 0)
            {
                humanOperatingRobotDirectly.WalkStraightForward(100);
                nextOperationNum++;
            }
            if (nextOperationNum == 1)
            {
                humanOperatingRobotDirectly.TurnRight();
                nextOperationNum++;
            }
            if (nextOperationNum == 2)
            {
                humanOperatingRobotDirectly.WalkStraightForward(5);
                nextOperationNum++;
            }
            if (nextOperationNum == 3)
            {
                humanOperatingRobotDirectly.DefuseBomb();
            }
        }
    }

В коді вище видно використання проксі для робота, а також "план Б", якщо неможливо приєднатися до робота. В такому випадку створється пряме посилання на робота і методи виконуться уже безпосередньо на ньому. Код може виглядати чуть складо із-за opNum та nextOperationNum, які були додані щоб зімітувати довиконання операції після обірвання зв'язку. Див. вивід нижче.

Вивід:

Did 100 steps forward...
Turned right...
Exception has been caught with message: (No connection with remote bomb diffuser robot could be made after few attempts.). Decided to have human operate robot there.
Did 5 steps forward...
Cut red or green or blue wire...

Моя імплементація дещо відрізняється від пропонованої у книзі "банди чотирьох" тим що проксі і справжній об'єкт не наслідуються від одного суперкласу або інтерфейсу. Але мені здається що така реалізація є більш частою тепер. Особливо у різних фреймворках. Наприклад ORM, або якийсь мокін фреймворк вимагають від вас мати віртуальні методи. Я думаю що тепер ви здогадуєтеся чому.

А ось UML-діаграма чудасії, яку ми закодили:

Моя табличка Патернів

Lviv .NET User Group #12. Happy birthday, Group!

2011-05-04T17:30:00.006+03:00

Всем привет,

Неожиданно 12 встреча! В неожиданном месте: офис компании MalkosUA: Угорська 14, офис центр "Доминант".

Встреча пройдент 13 мая, в 19:30.

Регистрация тут: ТУТ

Докладчики:
"ALM using Visual Studio 2010", Денис Пасечник, Microsoft - UA
"A Breakthrough Guide to Microsoft StreamInsight", Юлиан Слободян, SoftServe System Architect

Карта доезда тут.
С уважением,
-Дима

Lviv .Net User Group #11. Впечатления

2011-04-10T16:38:00.000+03:00

Всем привет,

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

Потом выступил Юлиан Слободян с докладом про "Mono". Отличный доклад, не ожидал что мне будет так интересно.

Потом выступил Андрей Будай. Андрей наш постоянный докладчик, и именно на докладе решился что Андрей в течении наших групп будет проводить мастер классы по WCF. Чтож,я уверен что все будет очень интересно!

После пиво и пицца!

Спасибо компании SoftServe за материальную и организационную помощь!

Всем спасибо, дальше будет интересно!

Lviv .Net User Group #11

2011-03-29T09:38:00.001+03:00

Нежданно - негаданно , мы снова с Вами:)

19:30, 7 апреля, офис компании SoftServe, Володимира Великого 52 - Lviv .Net User Group #11.

Темы докладов:
1."Mono" - Юлиан Слободян, SoftServe
2."WCF" - Андрей Будай, SoftServe

Важно: регистрация обязательна! Нам необходимо знать на какое число людей рассчитывать. В этот раз те кто не зарегестрировался - не будут иметь возможности войти.

Регистрация обязательная тут.

Welcome to Azure. Настройка

2011-03-06T21:54:00.001+02:00

Я ненавижу докторишек! Они делают прививки! - Они делают уколы! - Они сверлят зубы бормашинами!!!

Докторо Айболит(с)

Теперь Мы знаем как оно крутится внутри, как работает, и сколько платить:) Давайте теперь обсудим как с этим всем взаимодействовать.
Перво-наперво я бы хотел поговорить о такой библиотеке как Microsoft.WindowsAzure.Diagnostics. С помощью этой библиотеки наша аппликация на ажуре сможет с , собственно, Ажуром и общаться:) Что вообще мы сможем сделать с этой библиотекой:
1. Проверить хоститься ли наша программа на клауде.
2. Получить конфигурацию
3. Получать ссылку на файл и хранить его в локальном кэше.

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

protected void Page_Load(object sender, EventArgs e)
        {
            if (RoleEnvironment.IsAvailable)
            {
                Response.Write("Кручусь на ажуре");
            }
            else
            {
                Response.Write("Не, не кручусь на ажуре");
            }
        }

Наша страничка нам напишет где мы есть. Вся радость в том, что эту библиотеку можна использовать в любой аппликации, а не только в ASP.Net аппликациях. Тоесть, вы можете писать библиотеки которые будут вести себя по разному в зависимости от того, висят ли они в облаках или нет. Очень помогает сохранить деньги, например, представим:
1. Есть программа, которая раз в 10 секунд проверяет определенные данные в базе. Когда она стоит на машине клиента - это ОК.
2. Есть веб сайт, который для получения данных использует туже библиотеку. Тоесть дергает базу каждые 10 секунд.
Хотя так часто данные ему и не нужны. Тут два варианта - или переписать библиотеку - тогда у вас получится уже две библиотеки, каждую из которых надо суппортить. Или же написать простой if который проверит или программа на ажуре, и поставит соответствующий промежуток времени для получения новых данных.

Определение сервиса
Помните, в прошлых главах мы когда создавали новую ажур аппликацию - получали файл ServiceDefinition.csdef. Так вот, этот файлик не так прост, ибо в нем можно задавать очень много настроек вашего приложения, например таких как:
1. Количество доменов для апгрейда ( помните мы с вами обсуждали апдейт кода накаткой, вот оно!:) )
2. Ендпоинты ваших веб сервисов. Допустим вы хотите использовать нестандартные порты, или иметь адрес определенного вида.
3. Partial || Full trust . Собственно, как Вы зададите этот сеттингс, так IIS на машине на которой будет крутится Ваша веб роль будет к ней относится, и давать те или иные права.Тут все зависит от Вашего приложения, и что Вы хотите разрешить ему делать.
4. Конфигурации. Это уже обсуждалось.
5. Сколько вам необходимо места на локальном диске виртуальной машины, на которой будет крутиться Ваша роль.
6. Ну и какая виртуалка Вам нужна.

Собственно, чтобы не быть голословным, давайте посмотрим на тепершнее сосятоние нашего конфигурационного файла:

Как видим, вся конфигурация начинается с описания роли И ее ендпоинтов, где мы указываем протокол и порт. Опять же, тут же и присутствуют собственные конфигурационные элементы, такие как "MyCustomeSettingInAzure".
Естественно если Вы - гик красноглазый:) то будете все настройки вводить напрямую через xml, мы же, блондинки, пользуемся возможностями Visual Studio.

Теперь давайте провернем финт ушами, и создами ещё одну веб роль.
Для этого просто тыцните правой кнопкой мыши по проекту Azure и выберите New Web Role Project. В выпавшем окне выберите любой тип проекта для Вашей веб роли. После того , как студию создала новый проект, давайте опять взглянем на *.csdef файл:

Как видим, была созданная секция для второй веб роли в которой мы можем вводить отдельные для нее настройки!

А можна ли создать веб роль только внутри Ажура?
Да. В настройках вы можете задать тип ендпоинта как Internal. Тогда к вашей веб роли ( скорее всего это будет WCF сервис, я очень сомневаюсь что кому-то захочется создать веб сайт на который смогуть ходить только Web роли:) ).
Порт в данном случае не задается, ибо он будет динамическим.

Че там в настройках вообще?
Да, давайте более внимательно присмотримся к панели настройки ролей, я ее даже опять приаттачу:)

Итак, что мы можем тут настроить:
.Net Trust Level
Тут выбор не велик: Partial или Full Trust. В течении разработки , очень желательно чтобы Вы использовали Partial Trust уровень. Тогда, сама система будет ограничивать ваше приложение от того, чтобы оно там не натворило делов:) Если же Вашему приложению нужно делать такие вещи , как C++, Reflection, P/Invoke ( вы гик:)) тогда используйте Full Trust уровень.

Instances
Тут мы определяем какое количество веб ролей запустить на виртуалках определенной мощности:) Перед тем как менять эти значения - считаем деньги. Да, кстати интересный факт - Azure SLA на то что Ваше приложение будет доступно 99.95% времени работает только тогда, когда каждой веб роли у вас минимум 2 инстанса.

STARTUP ACTION
Просто определяете как Visual Studio запустит Ваше приложение когда вы тыкните F5.

А что там с локальным хранилищем данных?
Оно таки есть, но как обычно с определенными ограничениями. Локальное хранилище данных - это временно хранилище данных, которое свое у КАЖДОЙ роли. Тоесть шарить данные между ролями через локальное хранилище данных не получится. Крепитись:)
Важно ещё то, что если ваша Веб Роль загнется - сгорит вмка, вы случайно ее удалите, и т.д - Вы не вернете эти данные.
Перед тем как использовать локальное хранилище данных - подумайте дважды, а потом ещё разок - будут ли эти данные нужны Вам в будущем, планируете ли Вы их использовать в нескольких ролях - и толко тогда решайте - использовать ли сервиса хранения данных, или же использовать локальное хранилище данных.

Нафига оно тогда надо?
Тут тоже все элементарно - если говорить про сервисы хранения данных - они могут висеть где-то на других виртуалках, хороше если в том же помещении, а локальное хранилище данных находится именно на той виртуалке на которой крутится роль. Потому оно просто быстрее.

И че, как его создать?
Тут два метода - или вы гик или блондинка:) Я как блондинка буду делать все через графический интерфейс. В свойствах роли выбираем закладку "Local Storage":

Тут Вы можете создать новый Local Storage, задать ему имя и размер, и задать хотим ли мы чтобы данные стирались когда роль перегружается. Кстати, максимальный размер локального хранилища данных для одной роли - 20 гигабайте. Если Вам надо больше 20 гигабайт - скажите мне , что за временные данные вы храните?:)

Итак, методом блондинки мы создали локальное хранилище данных. Давайте посмотрим что нагенерилось в нашем конфигурационном файле?

Гики могут радоваться и смотреть что они потом могут делать руками:) Как видим мы создали локальное хранилище данных с именем "LocalStorage1" , с размером 100 мегабайт и очисткой при перезагрузке роли.

Ну ок, мы создали. И что дальше?
А дальше мы можем записывать туда разные данные:) Кстати тут то нам и пригодится библиотека про которую я заикнулся в самом начале.
Давайте напишем небольшой кусок кода:

LocalResource myStorage = RoleEnvironment.GetLocalResource("LocalStorage1");
System.IO.File.WriteAllText(myStorage.RootPath + "Temporarydata.txt","я пишу в хранилище локальных данных");

Через объект LocalResource мы можем получить так же информацию об имени нашего хранилища, и интовое значение которое скажет максимальный объем локального хранилища данных.

Давайте добавим немного кода, чтобы показать как много мы знаем про локальное хранилище данных:

/// 
        /// Handles the Load event of the Page control.
        /// 

        /// The source of the event./// The  instance containing the event data.protected void Page_Load(object sender, EventArgs e)
        {
            LocalResource myStorage = RoleEnvironment.GetLocalResource("LocalStorage1");
            System.IO.File.WriteAllText(myStorage.RootPath + "Temporarydata.txt","я пишу в хранилище локальных данных");

            Response.Write("Name of the Local Storage = " + myStorage.Name);
            Response.Write("Maximum size of the Local Storage = " + myStorage.MaximumSizeInMegabytes.ToString());

            //считывание данных
            Response.Write("In local folder we stored = " + System.IO.File.ReadAllText(myStorage.RootPath + "Temporarydata.txt"));

        }

Теперь пару слов об очистке локального хранилища данных при перезагрузке роли. Давайте подумаем, когда может произойти перезагрузка роли?
а. Сгорела машина на которой висела виртуалка. Бывает. Переподымается копия вашей виртуалки.
б. Апгрейд. Вы проапгрейдили конфигурацию Вашей роли, или заменили код. Для того чтобы изменения вступили в силу необходимо перезагрузить компьютер. :) Майкрософт вей!
в. Мануально.

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

RoleEnvironment.RecycleRole();

Собственно вот и все о чем я хотел поговорить сегодня. В следующем посте я хочу обсудить с Вами вопросы сертификатов, и на кой они необходимы.

Полезные ссылки:

http://msdn.microsoft.com/en-us/library/ms364059(v=vs.80).aspx - как программировать Partial trust системы.

http://msdn.microsoft.com/en-us/magazine/cc163990.aspx - Beware of Full Trust Code

Welcome to Azure. Дела железячные...

2011-03-02T09:00:00.003+02:00

Живой или мертвый, ты пойдешь со мной!

Робокоп

В предыдущем посте мы проговорили о том, как Ажур управляет серваками, что такое фабричный контроллер, и что такое фабрика. Так же мы зацепили немного тему о том как апдейтить код.

Сегодня же давайте поговорим, о железячной части Ажура.

Мы несколько раз говорили про виртуальные машины, и то что фабричный контроллер реплицирует себя на каждую машину. Все виртулки крутятся на Windows Server 2008 Enterprise Edition x64. Всей виртуализацией занимается Hyper-V. Собственно он и занимается тем что постоянно подымает и опускает виртуалки.Так как использование электроенергии очень важный момент, гипервизор смотрит сколько ядер на физическом компьютере используется в данный момент, и пытается заставить определенное количество ядер на полную мощность, другие же в это время кладутся спать:) чтобы использовать как можно меньше электроенергии.

Как происходит подключение новой ноды?

Когда новый сервер добавлен в Ажур - это просто голый сервак, в котором нету НИ-ЧЕ-ГО, только хард. Когда нода добавленна, на него устанавливается Windows PE - это такой себе предустановочный Windows( Micorosft мечтал что эта версия ОС заменит легендарный DOS), единственная цель которой была подготовка компьютера к установки полной операционной системы.

После этого ОС коннектиться к фабричному контроллеру, и начинает установку образ Windows 2008 Core на сервер. После этого образ разварачивается, и у нас получается компьютер с установленным Windows 2008.После этого, фабричные контроллер перегружает виртуалку, и на ней размещаются необходимые виртуалки.

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

Так как любая виртуальная машина в Ажуре все же является модифицированной версией Windows Server 2008, мы можем собрать данные с информацией об ОС на которой крутится та или иная роль. Давайте напишем небольшуюю программку, которая выведет нам необходимую информацию!

Как уже прежде рассказывалось - создайте проект Azure с одной веб ролью ASP.NET. Откройте файл Default.aspx и в кодбихайнде впишите следующее:

/// 
    ///
    /// 

    public partial class _Default : System.Web.UI.Page
    {
        /// 
        /// Handles the Load event of the Page control.
        /// 

        /// The source of the event./// The instance containing the event data.protected void Page_Load(object sender, EventArgs e)
        {
            var computer = new Microsoft.VisualBasic.Devices.Computer();

            Response.Write(string.Format("Computer Name:{0}
",computer.Name));
            Response.Write(string.Format("OS Name:{0}
", computer.Info.OSFullName));
            Response.Write(string.Format("OS Version:{0}
", computer.Info.OSVersion));
            Response.Write(string.Format("OS Platform:{0}
", computer.Info.OSPlatform));
            Response.Write(string.Format("Processor Count:{0}
", System.Environment.ProcessorCount.ToString()));
            Response.Write(string.Format("CLR Version:{0}
", System.Environment.Version.ToString()));
            Response.Write(string.Format("Current Directory:{0}
", System.Environment.Version.ToString()));
            Response.Write(string.Format("Time since last restart:{0}
",  GetTimeSinceLastRestart()));
            Response.Write(string.Format("Domain Name:{0}
", System.Environment.UserDomainName));
            Response.Write(string.Format("User Name:{0}
", System.Environment.UserName));
            Response.Write(string.Format("CPU Name:{0}
", GetCPUName()));
            Response.Write(string.Format("Architecture:{0}
", GetArchitecture()));
        }

        /// 
        /// Gets the current directory.
        /// 

        /// 
        private string GetCurrentDirectory()
        {
            try
            {
                return System.Environment.CurrentDirectory;
            }
            catch
            {
                return "unavailable";
            }
        }

        /// 
        /// Gets the time since last restart.
        /// 

        /// 
        private string GetTimeSinceLastRestart()
        {
            try
            {
                TimeSpan time = new TimeSpan(0, 0, 0, 0,
                    System.Environment.TickCount);
                return time.ToString();
            }
            catch
            {
                return "unavailable";
            }
        }

        /// 
        /// Gets the name of the CPU.
        /// 

        /// 
        private string GetCPUName()
        {
            try
            {
                using (ManagementObject Mo = new
                    ManagementObject("Win32_Processor.DeviceID='CPU0'"))
                {
                    return (string)(Mo["Name"]);
                }
            }
            catch
            {
                return "unavailable";
            }
        }

        /// 
        /// Gets the architecture.
        /// 

        /// 
        private string GetArchitecture()
        {
            try
            {
                using (ManagementObject Mo = new
                   ManagementObject("Win32_Processor.DeviceID='CPU0'"))
                {
                    ushort result = (ushort)(Mo["Architecture"]);
                    switch (result)
                    {
                        case 0:
                            return "x86";
                        case 9:
                            return "x64";
                        default:
                            return "other";
                    }
                }
            }
            catch
            {
                return "unavailable";
            }
        }
    }

В результате Вы должны видеть что-то вроде этого:
Computer Name: XXX
OS Name: XXX
OS Version:6.1.7600.0
OS Platform:Win32NT
Processor Count:4
CLR Version:4.0.30319.1
Current Directory:4.0.30319.1
Time since last restart:3.05:28:43.1420000
Domain Name:WORKGROUP
User Name:XXX
CPU Name:Intel(R) Core(TM) i5 CPU 661 @ 3.33GHz
Architecture:x64

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

public partial class _Default : System.Web.UI.Page
    {
        /// 
        /// Handles the Load event of the Page control.
        /// 

        /// The source of the event./// Theinstance containing the event data.protected void Page_Load(object sender, EventArgs e)
        {
                var processes = Process.GetProcesses();

                foreach (var process in processes)
                {
                    Response.Write(string.Format("ID:{0}, Name:{1}
",process.Id, process.ProcessName));
                }
        }
    }

В результате получим, нечто вроде:
ID:4332, Name:w3wp
ID:588, Name:services
ID:6108, Name:OSE
ID:376, Name:conhost
ID:388, Name:svchost
ID:3144, Name:svchost
ID:2280, Name:cvpnd
ID:5700, Name:conhost
ID:1956, Name:taskhost
ID:5904, Name:DiagnosticsAgent
ID:4316, Name:AdobeARM
ID:5520, Name:chrome
ID:768, Name:svchost
ID:1552, Name:explorer
ID:368, Name:smss
ID:2140, Name:AsSysCtrlService
ID:4304, Name:conhost
ID:1688, Name:svchost
ID:3512, Name:vmnetdhcp
ID:7648, Name:chrome
ID:4968, Name:conhost
...

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

Вот где-то так вся эта радость и работает:)

Информация в основном взята с книги "Azure in Action.".

Полезные ссылки:

http://ru.wikipedia.org/wiki/Microsoft_Hyper-V - что такое Hyper-V и с чем его едят.

http://ru.wikipedia.org/wiki/Windows_Preinstallation_Environment - очень удивился когда узнал про существование данной ОС, потому советую почитать. Достаточно познавательно.

http://itknowledgeexchange.techtarget.com/cloud-computing/how-azure-actually-works-courtesy-of-mark-russinovich/ - как работает Windows Azure by Mark Russinovich.

http://ru.wikipedia.org/wiki/VHD_(%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82_%D1%84%D0%B0%D0%B9%D0%BB%D0%B0) - именно в этом формате лежат все виртуалки на Azure

http://msdn.microsoft.com/en-us/library/ee924680.aspx - описание всех релизов Azure OS. Будет интересным для прочтения разного рода системным администраторам, ибо также включает в себя описание заплаток которые предустановлены на систему.

http://msdn.microsoft.com/en-us/library/gg433107.aspx - достаточно интересная стать о фичи в CTP которой даже небыло:) Надеюсь что у меня дойдут руки и до нее, чтобы напсать че за зверь и с чем его едят. Пока данная фича находится в бете.

http://msdn.microsoft.com/en-us/library/gg433048.aspx - сбор диагностики в Windows Azure.

"Патерн Вівторка" #23: Медіатор (Mediator)

2011-03-01T11:17:00.001+02:00

Вже трохи часу пройшло від коли я написав попередній “патерн вівторка”. Чесно кажучи не знаю що було справжньою причиною цієї задержки.

Я трохи думав над тим який має бути приклад для Медіатора і мені на думку нічого кращого ніж класичний приклад із UI не спадало. Потім ще пару варіантів аж поки не спало на думку взаємодія нейронів. Я ще трохи подумав і в голову прийшла геніальна ідея (звичайно я не ручаюся, що більше такого прикладу немає, але я його придумав сам). Наш мозок є медіатором для різних частин тіла. Мозок ідеально підходить під опис дизайн патерну медіатор.

Просто спробуйте уявити, якби кожна із частин вашого тіла знала одна про іншу. Якщо б ваше око бачило щось приємне, то воно мало б знати як напряму зв’язатися із ногами і змусити їх рухатися у заданому напрямку. Або якщо б вас хтось вдарив в живіт, ваш живіт б мусів навчитися захищатися руками. Живіт може й боліти, тоді він буде мусіти знати про цілу систему м’язів, щоб змусити тіло прийняти лежаче положення. І взагалі для будь-чого, що приймає інформація і опісля якісь дії мають бути прийняті. Взаємодія описана вище, як багато-до-багатьох не є природньою для нашого тіла. Проте, чомусь, вона часто застосовна деякими програмістами до їхнього коду. Спочатку, поки програміст все пише по свіжому, такий код працює нормально, але із часом він перетворється на суцільний спагетті безлад в якому розібратися важко і змінити поведінку, не поломавши чогось тоже складно.

Наше тіло має одну центральну систему, яка аналізує прийняті сигнали і здійснює потрібні реакції. Це можна застосувати і до коду, який ми пишемо.

МЕДІТОР

Медіатор – це дизнай патрен який централізує взаємодію між компонентами таким чином послаблюючи їхню зв’язаність.

Медіатор елегантно спрощує розуміння взаємодій між компонентами. Це полегшує підтримку коду у майбутньому, але, оскільки логіка централізована, може стати досить складним, зрештою чим наш мозок і є.

Нижче наведено демонстрацію прикладу в дії:

Як видно мозок знає як діяти в різних ситуаціях і які частини тіла слід задіяти. То як це відбувається?

Мозок (Mediator) знає про кожну частину тіла (Colleague), а кожна частина тіла знає про свій мозок, тому може передавати сигнали йому та приймати їх. Звичайно кожна частина тіла виконує ще й свою безпосередню функціональність.

Базовий клас Colleague (знає про мозок)

// Colleague
        class BodyPart
        {
            private readonly Brain _brain;

            public BodyPart(Brain brain)
            {
                _brain = brain;
            }

            public void Changed()
            {
                _brain.SomethingHappenedToBodyPart(this);
            }
        }

Конкретна реазізація Colleague може вигладати так:

class Ear : BodyPart
    {
        private string _sounds = string.Empty;

        public Ear(Brain brain)
            : base(brain)
        {
        }

        public void HearSomething()
        {
            Console.WriteLine("Enter what you hear:");
            _sounds = Console.ReadLine();

            Changed();
        }

        public string GetSounds()
        {
            return _sounds;
        }
    }

Як бачимо вухо (Ear) може чути (HearSomething) і може видати звуки на аналіз мозку (GetSounds). Деякі чатини тіла мають іншу функціональність. Як для прикладу реалізація класу обличчя (Face):

class Face : BodyPart
    {
        public Face(Brain brain)
            : base(brain)
        {
        }

        public void Smile()
        {
            Console.WriteLine("FACE: Smiling...");
        }
    }

Медіатор або Мозок (Brain)

Як і слід було оцікувати клас медіатор є досить громіздким оскільки він відповідає за “розрулювання” ситуації. Можливо вам не сподобається так як реалізовано цей конкретний мозок, але це не є аж на стільки важливо. Важливо зрозуміти як воно діє.

// Mediator
    class Brain
    {
        public Brain()
        {
            CreateBodyParts();
        }

        private void CreateBodyParts()
        {
            Ear = new Ear(this);
            Eye = new Eye(this);
            Face = new Face(this);
            Hand = new Hand(this);
            Leg = new Leg(this);
        }

        public Ear Ear { get; private set; }
        public Eye Eye { get; private set; }
        public Face Face { get; private set; }
        public Hand Hand { get; private set; }
        public Leg Leg { get; private set; }

        public void SomethingHappenedToBodyPart(BodyPart bodyPart)
        {
            if (bodyPart is Ear)
            {
                string heardSounds = ((Ear)bodyPart).GetSounds();

                if (heardSounds.Contains("stupid"))
                {
                    // attacking offender
                    Leg.StepForward();
                    Hand.HitPersonNearYou();
                    Leg.Kick();
                }
                else if (heardSounds.Contains("cool"))
                {
                    Face.Smile();
                }
            }
            else if (bodyPart is Eye)
            {
                // brain can analyze what you see and
                // can react appropriately using different body parts
            }
            else if (bodyPart is Hand)
            {
                var hand = (Hand)bodyPart;

                bool hurtingFeeling = hand.DoesItHurt();
                if (hurtingFeeling)
                {
                    Leg.StepBack();
                }

                bool itIsNice = hand.IsItNice();
                if (itIsNice)
                {
                    Leg.StepForward();
                    Hand.Embrace();
                }
            }
            else if (bodyPart is Leg)
            {
                // leg can also feel something if you would like it to
            }
        }
    }

Чесно кажучи мені самому сподобався цей приклад.

UML

Як уже запитували багато раз я додаю трохи UML. Клікайте на картинку, щоб придивитися до деталей.

Моя табличка Патернів

Welcome to Azure. Кто - кто в теремочке живет?

2011-03-01T08:52:00.001+02:00

Медведь и полез в теремок. Лез-лез, лез-лез – никак не может влезть и говорит:

– А я лучше у вас на крыше жить буду.

– Да ты нас раздавишь!

– Не-е, не раздавлю.

– Ну, тогда полезай!

Полез медведь на крышу и только уселся – трах-тарарах! – затрещал теремок и весь развалился. Еле-еле успели из него выскочить мышка-норушка, лягушка-квакушка, зайчик-побегайчик, лисичка-сестричка, волчок-серый бочок – все целы и невредимы.

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

Достаточно инетерсно почитать как все-таки Микрософт докатился до жизни такой - создание своего облачного сервиса. Казалось бы - продавали всем бы Форточки, до офисы, и не тужили бы:) Микрософт увидели, что ихние заказчики требуют все более гибкие решения, не только для ихнего корпоративного сектора, но и для собственных решений. Ещё одним фактором стало - "озеленение" IT:) Для нашей страны - это не столь актуально, хотя для более развитых стран - это очень важно. Суть простая - чем больше Ваша компания употребляет электричества - тем больше она платит налоги. Все потому, что чем больше Ваша компания тратить энергии - тем больше ее надо выработать, а это в свою очередь приводит к тому, что в атмосферу выкидывает все больше ядовитых веществ. Потому, чтобы запустить свои решения, клиентам Микрософта, приходилось покупать датацентры, нанимать администраторов, обустраивать инфраструктуру, вообщем всячески ухаживать за железками. Микрософт увидели, что надо, и что это очень поможет людям ( да и че греха таить - поможет бабла отгрести:) ) - вышли с Ажуром. Пока у них получается:) При том что качество сервиса все более растет. Итак, из чего состоят "облака"?...

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

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

Третья генерацтя - это то,чем дышит теперешний Микрософт. Теперешний датацентр - это контейнер:) Знаете, такие контейнеры в которых перевозят что-то на кораблях? Вот именно в таких (почти) контейнерах живут серваки Микрософта. В одном таком контейнере можна разместить от 1800 до 2500 компьютеров. Каждый контейнер имеет вход для электричества, охлаждения, и сети. К тому же, он защищен от воздействия окружающей среды, потому может стоять хоть на улице ( кстати, многие датацентры находятся под октрытым небом! ). Очень удобно - приехала фура, выгрузила контейнер - подключили питание, охлаждение и сеть - и вот у вас на 2500 компов больше:)

Вообщем выглядит круто - куча железок, можна поставить ещё кучу и все будет работать:)
Как же оно там все работает?
Окей, давайте представим, о чем мы думаем когда пишем обычну аппликацию - о том чтобы написать! Нас не волнует в данный момент сколько там памяти осталось, как грузится процессор, не перегревается ли чего-нить. Обо всем этом за нас думает компьютер!
Теперь давайте подымемся на более верхний уровень - Мы пишем приложение для большой корпорации, которое будет испольщованно огромным количеством людей, отделов, компаний. Все это должно хранится в одном месте, данные должны сохраняться, а также все это должно лекго расширятся. Вот тут то и появляются новые загадки и головная боль! Мы должны думать о куче вещей, типа лоад балансера, ДНС, прт этом вы должны контролировать разрешения для разных типов пользователей. Вообщем, чем больше система - тем больше Вам надо думать как оно все будет взаимодействовать.

Windows Azure - делает очень много вещей для Нас:) Вы не будете тратить столько времени на инфраструктуру, как тратили когда управляли своим датацентром. Теперь, когда Вы пишете, аппликацию для крупной компании , и при этом хостите ее в Облаках - Ажур сам решит вопросы связанные с сетью, с восстановлением в случае поломки аппаратуры, и т.д, и т.п. Тоесть Вы сможете полностью сконцентрироваться на напсании аппликации, а не на настройке оборудования.

Фабрика
Помните, я писал про Бога всех машин в Ажуре?:) Именно фабрика им и является!
Давайте сразу разделим два понятия - фабрика и контроллер фабрики. В двух словах - фабрика - это операционная система, в тоже время контроллер фабрики - это ядро этой системы:).

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

Как видим, без контроллера фабрики, в Ажуре вообще мало чего происходит, но также, контроллер занимается тем, что распределяет ресурсы. Он анализирует модель вашего сервиса, сколько и где ресурсов осталось, и на основании этих данных размещает Вае приложение на том или ином сервере.
Кстати, сущностями Ваших сервисов управляет также он. Каждый раз когда мы размещаем Веб роль на ажуре, для каждой веб роли поднимается отдельная виртуальнам машина. Если Ваше приложение вдруг зависло, то контроллер попытается восстановить работу Вашего приложения. По моим наблюдениям - он просто рестартует машину.Перед тем, как захостить Ваше приложение на ВМ, контроллер пропускает ее через ряд тестов, чтобы определить что виртуальнам машина работает хорошо, и что оборудование работает достойно вашего приложения:) Согласитесь, неприятно если Ваше приложение обвалится после 10 минут работы из-за сгоревшегно оборудования.

Моедль сервиса (Service Model)
Помните в прошлом посте, мы задавали два конфигурационных файла? Вооооот. Мы задавали модель сервиса. Тут мы определяем:
а. Конфигурацию того, что есть Наш сервис.
б. Как сервисы коммуницируют друг-с-другом.
в. Сколько экземпляров Ваших сервисов будут крутиться в Ажуре.

Дак *.cscfg очень похож на web.config
Спасибо, кэп, где-то так и есть:) И даже больше, мы можем хранить там свои настроки.
Для этого нужно вначале открыть файл с расширение *.csdef и определить там наш аттртбут:

Как видим я добавил секцию под название ConfigurationSettings с настройкой под названием MyCustomSettingInAzure. Теперь давайте откроем файл с разширением *.cscfg и добавим туда значение нашего параметра:

Как видим значение нашего параметра "ыыы", что сразу показывает Наш интеллект:)

Для того, чтобы считать этот параметр в коде надо написать такую строчку:

var trollsSays = RoleEnvironment.GetConfigurationSettingValue("MyCustomSettingInAzure");

Также в конфигурационном файле Вы можете указать какую конфигурацию виртуальной машины должно использовать ваше приложение. Для того чтобы задать этот параметр - стоит зайти в настройки вашей веб роли. Внимательно продумывайте этот шаг - потому как чем круче виртуальную машину Вы выберите - тем дороже она вам обойдется. Не стоит на блог брать машину с 16 гигами оперативки, и 4 ядарми.

Ниже преведнны типы машин , и цены за их сипользование:

Compute Instance Size	CPU	Memory	Instance Storage	I/O Performance	Cost per hour
Extra Small	1.0 GHz	768 MB	20 GB	Low	$0.05
Small	1.6 GHz	1.75 GB	225 GB	Moderate	$0.12
Medium	2 x 1.6 GHz	3.5 GB	490 GB	High	$0.24
Large	4 x 1.6 GHz	7 GB	1,000 GB	High	$0.48
Extra large	8 x 1.6 GHz	14 GB	2,040 GB	High	$0.96

Как видите, самая дорогая тачка стоит практически 1 доллар в час - приблизительно 720 долларов в месяц - дороговатое удовольствие для блога, не находите?

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

Что такое статический апдейт? (Static Upgrade)
По сути - статический апдейт это когда Вы меняете ВСЕ! Допустим в случае когда у Вас поменялась архитектура аппликации, или добавились какие-то компоненты. В таком случае очень любят использовать VIP замену. VIP - это Virtual IP, а не то что Вы подумали:) По сути, это тот момент когда Ваш staging среда меняется айпишками с продакшен машиной.
А на ней вы уже делаете загрузку новой версии Вашего сервиса. Потом замена айпишками происходит опять.

Что такое апдейт по накатке? (Rolling Upgrade)
Это такой апдейт, в течении которого Вы заменяете не всю аппликацию, а только часть. Помните, в течении такого апдейта нельзя поменять сервисную модель вашей аппликации.

Как вся эта радость проходит?
Представте что у Вас есть 10 машин, на которых крутиться Ваша веб аппликация. Вы хотите проапдейтить аппликацию, потому как некоторые странички потерпели изменения. В процессе апдейта по-накатке, фабричный контроллер отключает айпи адрес ноды из своего лоад балансера, тоесть он уже не будет перенаправлять запросы от клиента на эту машину, после чего останавилвает эту машину. После остановки машины, заливает на нее новый код, и опять запускает. Как только машина запустилась, фабричный контроллер подключает айпи адрес а лоад балансеру, и переходит к другой машине. Логично, что такой апдейт возможен только в случае более одной веб роли:)

В следующих своих постах я постараюсь покрыть больше железячную часть Azure. Дальше будет.

Полезные ссылки:
http://www.microsoft.com/windowsazure/compute/default.aspx - описание web/worker ролей. Цены.

http://www.microsoft.com/windowsazure/offers/#tcoCompare-LB - калькулятор который Вам поможет легко подсчитать TCO вашей аппликации в Windows Azure.

http://www.datacenterknowledge.com/archives/2009/11/18/microsofts-windows-azure-cloud-container/ - статья про датацентры Ажура.

Welcome to Azure. «Hello, Azure»!

2011-02-27T15:49:00.003+02:00

Интересно то, что как только я начал писать аб Azure многие начали кричать что теоретические знания - фигня, а надо практические. А ажура нету у нас в стране, и вообще:) Вообще все это выглядит как lame excuses:)

Почему кодить под ажур сейчас возможно?
Все просто, есть эмулятор, которые эмулирует почти все фичи ажура. Тоесть уже сейчас Вы можете пробовать писать или переводить свое программы на использование клауд технологий.

Зачем кодить под эмулятор?
Честно скажу - как работает на эмуляторе, и как работает на клауде - разные вещи. Особенно если эмулятор крутиться на той же машине :) Хотя механизм разработки - один и тот же для обоих вариантов.
Эм, клауды очень активно входят в нашу жизнь! Через несколько лет - любое программирование будет расчитанно на то что Ваши приложения можна будет использовать хоть на клаудах, хоть минимум на веб фермах. Лучше готовится к этом сейчас, чем когда придет время начинать учиться :) Так что , хочеш мира - готовся к войне.

Вступительное слово на этом будем считать оконченным:) Теперь вперед к созданию нашего первого приложения!
Для начала хочу Вас обрадывать - если Выкогда нибудь создавлаи приложение ASP.Net, ты Вам нехватало всего лишь процентов 10 чтобы запустить его на клаудах:) Вероятнее всего - любое приложение можна запустить на клаудах, и это отлично:) Но дорого. Помните - мы платим за то что мы используем. Приложение которое оптимизированно для клауда - может делать тоже самое что и Ваше приложение, но при этом стоить в несколько раз дешевле. В будущем я попытаюсь написать цикл статей которые будут рассказывать о том как программировать приложение именно для облачных сервисов. Как сказал, один из тренеров по Azure :" Ажур, клевая система , хоть и дорогая - зато учит писать клевый код".
Так что, чем не мотивация?:)

Итак, что нам необходимо для начала разработки под Azure:
1. Visual Studio 2010
2. Windows 7, 2008
3. Azure SDK. Скачать можно тут: http://www.microsoft.com/windowsazure/getstarted/default.aspx

Ну вот мы собственно и вооружены, и готовы принять бой.
После установки SDK дополнительно устанавливаются такие аппликации:

Compute Emulator - это эмулятор Azure Compute Services. Собственно та часть Ажура где будут крутится сервисы, сайты, и тп.

Storage Emulator - эмулятор сторадж сервисов. С помощью этого эмулятора Вы можете пользовать Queue, Blobs, Tables на своем компьютере.

С SDK конечно же поставляются и темплейты для проектов Visual Studio.

ASP .NET Web Role - тип веб роли для веб сайтов написанных на ASP.Net
ASP .NET MVC 2.0 Web Role - тип веб роли для веб сайтов написанных на ASP.NET MVC 2.0
WCF Service Web Role - тип веб роли для WCF сервисов
Worker Role - тип проекта для воркеров
CGI Web Role - превед похапе:)

Как я уже говорил работа приложения на эмуляторе и на реальном клауде - очень отличается. Потому нашел небольшую табличку которая описывает различия:

Feature	Local Environment	Cloud Environment
Storage environment access	The local storage environment uses a special account key for access.	This will be different from your cloud key.
Storage environment access	The local storage does not support the use of HTTPS.	Cloud storage supports both HTTP and HTTPS.
Storage performance	The performance of the local storage is not representative of cloud storage. It is only meant for a few local connections, nothing more.	The performance of the cloud based storage should be expected to be much faster
URI management	Because of the lack of the Azure DNS system locally, storage URI's are different in the local environment.	URI’s are based on Azure DNS system.
Storage management	The local storage subsystem will not provide extended error information.	Cloud storage provides extended error information.
Blob storage	Blobs in the local store are limited to 2GB in size.	BLOBs in the cloud can be as big as 50GB.
Table authentication	Local tables only use Shared Key Lite authentication.	Uses Shared Key and Shared Key Lite authentication.

Вот такая табличка вышла:)

Ну, че, погнали создавать новый проект?

Как и все новые проекты Visual Studio - все начинается с создания нового проекта:)

После установки SDK в проектах у нас появилась такая штука как Cloud, где есть только один тип проекта: Windows Azure Project.

После выбора этого проекта, Вы увидите табличку про которую я писал раньше. Чтобы долго не парится, давайте выберем ASP .Net Web Role. Если её перетянуть в колонку справа - есть супер фича - переименовать:) Называем проект так как нам удобно.

После того как мы создали проект, мы должны увдиеть что-то вроде этого:

Давайте разберем структуру новосозданного проекта:
TestApplication1 - обычная ASP .Net аппликация, ничем не примечательна.
WindowsAzureProject1 - вот тут интересней, это апплкация , которая знает про все веб и воркер роли в проекте. Именно через нее мы можем создавать пекеджи для Ажура, конфигурировать и ещё много всяких вкусностей про которые я ещё поговорю:)

Я думаю, что не буду писать много , как написать простейшее приложение на ASP.Net , потому запустим пустой сайт. Просто чтобы посмотреть что ж творится потом.

Итак, вы увидите, что сайт запустился на отлично, так же в правом углу запестились Compute emulator и Storage Emulator.

Как Ажур знает о том какая конфигурация нашей аппликации?
Если посмотреть в проект Azure, вы увидите два конфигурационных файла:
ServiceConfiguration.cscfg - этот файл поределяет конфигурацию Вашего сервиса, и как им будет управлять Azure. Например, там указывается количество веб ролей, для каждой специфической веб роли ( понимаю, что звучит глупо, но так и есть. Вы задаете сколько виртуахльных машин поднять для заданной веб роли.) Если открыть этот файл, то мы увидим что это обычный XML. Диву даюсь, как люди раньше жили без XML:)

ServiceDefinition.csdef - определяет какие сервисы, являются частью вашей аппликации, и если есть енд поинты, то ихнюю конфигурацию.

Когда мы запустили аппликацию, то можна увидеть, что вместе с ниё дополнительно запустилась консоль эмулятора:

Для начала , давайте покажем UI Storage сервисов.

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

Compute Emulator UI. Think it Geek way!:) Ведь действительно выглядит по-гиковски!

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

Для того чтобы начать деплоймент процесс ваше аппликации на ажур, следует всего лиш кликнуть правой кнопкой на проект Ажура, и выбрать меню Publish. Тут вы можете выбрать две опции:
а. Создать обычный паблиш пакет(Create Service Package Only ). Эта опция будет Вами использована скорее всего только в первый раз. Если выбрать этот пункт, и нажать Ok - откроется папка с двумя фйлами: пекеджом и его конфигурационным файлом, а так же веб портал, на котором вы сможете загрузить ваш пакет, и разместить Ваше приложение на Ажуре.

б. Deploy your Windows Azure project to Windows Azure. Вот это один из самых интересных пунктов меню - с помощью него вы можете загружать свой сервис напрямую через Visual Studio. Причем загружать вы его можете не только сразу на Compute сервисы, но и на сервисы хранения информации. В будущем я более детально остановлюсь на этом, потому как уж больно вкусно это звучит!

Отдельно мне бы хотелось остановится на логировании. Как я уже сказал, то что работает на эмуляторе - будет слегка по другому работать когда захощщенно на Ажуре. Собственно дебагером вы подключиться к коду который крутится в облаках тоже не сможете. Разработчики Ажура не оставили нас, и потому у Ажура есть очень полное АПИ для диагностики. С помощью него вы сможете собирать метрики IIS, Windows Events. Хранить же их можно в любом сервисе хранения данных - это может быть сохранение этих данных в таблицах, и архивация их в блобы:) Вообщем Вы можете фантазировать:)

Полезные ссылки:
http://www.microsoft.com/windowsazure/windowsazure/default.aspx - что такое, и с чем едят, и как использовать Compute сервисы

http://www.microsoft.com/windowsazure/storage/default.aspx - описание сервисов хранения данных в Windows Azure.

http://www.microsoft.com/windowsazure/pricing/ - цены на сервисы.
Кстати, если у Вас есть друзья в Америке, или в любой стране где есть Azure, или может кредитная карточка той страны в которой есть Ажур - сейчас стартует интересная акция - бесплатный Azure до июня:
Sign-up Now For the Free Windows Azure Platform Trial till June 30th, 2011.
Sign-up now to get free access to the following Windows Azure platform resources:

Compute:

750 hours of an Extra Small Compute Instance
25 hours of a Small Compute Instance

Storage:

500MB
10k Storage transactions

Data Transfers:

500MB in / 500MB out

Relational Database:

1G Web Edition SQL Azure database (for 90 days only)

AppFabric Access Control transactions:

100k

AppFabric Service Bus connections:

Больше информации Вы можете найти тут: http://www.microsoft.com/windowsazure/free-trial/default.aspx

http://www.ditii.com/2010/09/03/windows-azure-compute-service-level-agreement-sla/ - Windows Azure Compute Service Level Agreement (SLA). На самом деле очень важный документ, который описывает что Вам гарантирует Azure. Допустим если Вы ожидаете что Ваш сайт - сервис будет доступен в теченеии 99.95% времени, стоит обратить внимание что Вы должны использовать как минимум 2 веб роли.

http://www.microsoft.com/web/platform/phponwindows.aspx?templang=ru-ru - очень интересные компоненты которые позволяют раскручивать решения на PHP. Особенно мне понравилось как об этом написанно на сайте Микрософта, цитирую:

"Да, PHP также работает на Windows Azure, и Microsoft сотрудничает с сообществом в разработке инструментов и SDKs, чтобы облекчить жизнь PHP-разработчикам."

Тут приводится достаточно инетерсный список компонент, среди которых:

Хранилище Windows Azure для WordPress - использование сервисов хранилища Azure, для своих медиа объектов для Wordpress. Собствено, мне кажется об этом стоит задуматься, потому как сервисы хранения в Azure - дешевые как борщ.

PHP-примеры для Windows Azure - а куда без примеров?

Windows Azure AppFabric SDK для PHP - SDK которое позволяет конектится к Azure Service Bus с PHP.

Windows Azure SDK для PHP - используем возможности Azure Compute и Azure Storage Services в своем PHP приложении

Это я просто не мог обойти стороной:

Средства командной строки Windows Azure для PHP - красноглазие вперед! Собственно то что в Visual Studio можна сделать с помощью мышки ( по честняку, в винде все делается точно так же, просто обернуто в красивую упаковку:) ), тут делается через коммандную строку. Хотя думаю ненадолго, и скоро ( а может быть уже ) появятся плагины. Эту штука для создание пакетов для Ажура с Вашим PHP приложением.

На этом на сегодня все! Дальше будет интереснее!

10 Встреча, отчет

2011-02-25T18:51:00.000+02:00

Я таки добрался до блога чтобы поделиться с Вами впечатлениями.

Ну что, рекорд по регистрациям Мы достигли! Впервые было больше ста человек ( 101 больше ста, но 101 так грозно не звучит:) ).

К сожалению, пришло очень мало людей, около 40 человек. Будем надеяться что причина тому - плохая погода!

Теперь о хорошем - доклады просто отличные. Вася как всегда заставил всех задуматься. Я, к примеру, начал бояться технического прогресса (эту мысль на прошлой встрече озвучил Юра, теперь я его понимаю). Доклад был неймоверно понятен, и информативен. Даже вопросов не возникло:)

Зеник. Не ожидал - очень профессиональный доклад. Мне, как человеку который занимается клаудами, было очень инетересно послушать про одного из конкурентов Ажура. Очень структурированно и информативно!

После встречи традиционное афтерпати, и пивопитие. К удивлению доклады прочитали быстро, потому пиццу к тому времени ещё не привезли:) Самые стойкие дождались тратя время на разговоры и обсуждения:) Помните, мы расчитывали на 100+ людей, потому пицц было приблизительно по 1 каждому:) Мы справились!

Традиционно благодарим компанию SoftServ за финансовую и организацинную поддержку, за подарки, за кинект, и за мир во всем мире:) без Вас было бы не так уютно:)

"Tette" спасибо за подарки, самые экстравагантные подарки в Нашей группе:)

Спасибо тем, кто пришли не побоявшись погоды:) Дальше - интересней!

Azure. Базы и остальное зверье

2011-02-24T17:28:00.001+02:00

Про Ажур пишется намного легче. Не уверен в чем причина:) Возможно потому как радостно наблюдать о том как поменялась платформа которую я пропагандировал с 2009 года:) Кстати тогда мне почему-то никто не верил, что облака захватят наш мир. Приятно осознавать что я был прав.

Итак, какая же система без баз данных. Особенно реляционных. Как я говорил прежде, Ажур предоставляет нам сервисы для хранения наших данных, но если вы захотите перевести на сторону Ажура вашу SQL базу, то стоит обратить пристальное внимание на SQL Azure!

Кстати это один из сервисов за развитием которого очень приятно наблюдать. В те времена, когда Микрософт выдавал бесплатные аккаунты на Ажур, эти сервиса назывались SQL Server Data Services, и представляли какуюто недоSQL Server:) Собственно мы могли без проблем конектиться к инстансу нашей "базы" по TDS, но создать базу данных допустим, было неймоверно тяжело.

Теперь это достаточно хорошо сделанные серверра, которые могут заменить Вашу базу которая хоститься,как было сказанно: "под столом":). Самое замечательное в том, что вам не надо будет менять код вашего приложения - стоит тока заменить connection string.

AppFabric

Этот зверь дает нам доступ к 2 очень замечательным возможностям Azure:

a. AppFabric Access Control

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

Электронный магазин. Тут уже система безопасности становится сложнее: есть несколько типов пользователей - одни администраторы - они могут добавлять товары, банить тролей и флудеров:), менять товары. А есть пользователи, которые могут заказть товар, но в свою очередь менять или удалить товар они не могут, как и забанить надоедливого тролля:) Тут в силу вступали роли ползьователей. Подымемся ещё выше!

Крупно производство: тут и корпоративная почта, и шарепоинт портал, и какая нибудь внутренняя система, да и ещё учетка на вход в Windows. В данном случае создавать на каждую программу отдельный аккаунт создаст огромное количество проблем - бухгалтера могут забыть пароль к одной программе, а к другой имя пользователя, ХР могут забыть пороль от аккаунта к шарепоинту, и т.д. Вы можете сказать что можно создавать для каждой системы одинаковые логины и пароли. Представте ситуацию когда пароли надо срочно поменять. Да, для всех 1000 человек в организации. Да, все пароли на все учетки. Я прям вижу как вешается администратор:) Тут то на помощь и приходит такая штука , как Singl Sign-On - одна учетка на кучу сервисов. Яркий пример Live Id - куча сервисом предлагают Вам доступ к своей системе пользуясь только Вашим Live Id. И ненадо запоминать миллион паролей! Вот тут то нам на помощь приходит AppFabric Access Control со своей системой claims.

В будущем я буду больше писать про AppFabric Access Control и про то как это можно использовать.

b. AppFabric Service Bus

Ну это вообще сказка. С помощью этой штуки можна создать централизированную шину к которой будут конектится разные программы и аппликации и посредством этой штуки обмениваться сообщениями:)

Завтра скачаем SDK и создадим новое приложение!

Welcome to Azure! Welcome, че!

2011-02-24T13:20:00.002+02:00

Ага:) Собственно именно так меня и бросает в ежидневном выборе технологий про которую хотелось бы почитать. На этот раз мне на глаза попалась такая штука как Ажур. Правда я опять лукавлю - с Ажуром я столкнулся довольно давно, когда ещё были бесплатные аккаунты:)

Тогда он помнится мне не особо понравился потому как был медленным и добиться вменяемой работы от него было достаточно тяжело:) Теперь в связи с ещё одним проектом мне пришлось опять залезть в облака. Собственно удивляться нечему - на ближайшие 3 года мейнстрим в сторону которого будут развиваться все технологии - мобилити + облака. Ведь представте насколько это удобно иметь в мобильном телефоне неограниченные вычислительные мощности облаков!

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

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

Типов облак достаточно много, это:
IaaS - инфраструктура как сервис - вам предоставляется вычислительная мощность от одного компьютера - до целой веб фермы, а то и связки веб ферм.

SaaS - программное обеспечение как сервис - тут легко, есть програмное обеспечение которое вы можете использовать, при чем все происходит обычно через браузер, а вычислительные операции происходят на серверах провайдера услуги. Яркий пример - docs.google.com

PaaS - платформа, как сервис, - это уже огромный шаг вперед по сравнению со всем остальным - тут нам предоставляется не только инфраструктура, но и ПО. Представте что Ваш сайт использует базу данный MS SQL - Вам прийдется выложить крупную сумму за то, чтобы хотя бы купить SQL Server. Платформа же предоставляет Вам набор инструментов который Вы можете пользоваться - от исполнимой среды - до хрнаилищь данных.

С недавнего момента появились даже такие штуки, как

DaaS - desktop as a service, а так же GaaS - games as a service - последнего мне очень не хватало когда у меня был слабый компьютер - представте себе , что мощности необходимые для нормальной работы игры - не на вашем компьютере, а на серверах провайдера! Ведь теперь даже на самом слабом компьютере можна докачать эльфа до 80! уровня:)

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

Естественно облачные вычисления не лишенны минусов, с первого раза натыкаешся на такое:
1. Это пока дорого. Тоесть не стоит хостить свой блог на клаудах:)
2. У Вас нету физического контакта с Вашим датацентром. Тоесть если сервер глючит - в сердцах пнуть его ногой не получится:)
3. У нас в стране ( Украина ) пока нету Ажура.

Ну что , погнали смотреть что такое Ажур?:)
Облачные вычисление на самом деле - это не так страшно как кажется. Относитесь к этому как к просто большой куче серверов. Которых Вы не видите:)
Когда раньше я тестирова Ажур, то был глубоко обижен на его даш борд - все было достаточно уныло и мне не нравилось. Каково же было мое удивление когда я сегодня зашел на даш борд и увидел возможость выбора сильверлайт версии портала.

Портал стал намного чище и понятнее. Так же очень новой для меня стала кнопка Connect. В момент написания поста, я не біл особо уверен что она значит, но как только я узнаю про ее значение , обязательно напишу в отдельном посте.

3 основные части Ажура:
а. Windows Azure
b. SQL Azure.
c. Windows Azure platform AppFabric

Сегодня я немного напишу о том что такое Windows Azure.
Windows Azure - это операционная система для работа на компьютерах в датацентрах Azure. Собственно вся фишка в том , что мы можем расширять количество компьютеров на которых хостяться наши приложения.

Что можно хостить на Windows Azure?
А что можна запускать на оыбчной операционной системе?:) Ворд, Интернет Експлорер, Контер Страйк - программы которые мы используем каждый день. Вот именно их мы на Ажуре запускать не будем! Я не буду утверждать на 100 процентов, что такого сделать нельзя, но это дорого:)

Приложения которые будут хоститься на ОС Windows Azure скорее всего будут серверные приложения: веб сайт, веб сервис, ВЦФ сервис

Как хостяться аппликации на обычном компьютере? Ага, представте что вы играли в супер марио, и тут он игра вылетела - что сделает аппликация - подчистить все следы аппликации, а некоторые приложения даже перезапустит. Это прекрасно для одного компьютера. А теперь представте что у вас есть тысячи шкафов с серверами. Ваша аппликация в ажуре может хостится на 8 сервере в шкафе 563, и на 9 сервере в 717 шкафу. Тут нам на помощь( ну и на помощь Ажуру:) ) приходят виртуальные машины. Именно с помощью них, ваша апплакиция отделена от других приложений с которыми она делит один сервер.

Windows Azure использует Windows Server 2008 + IIS 7.0. На этом этапе хорошо бы вспомнить про такую штуку как Роли. Каждая виртуальная машина может иметь одну из ролей: Web или Worker.

Web role - это просто аппликация которая может получать запросы через HTTP/HTTPS. Идеальные выбор для всяческих веб сайтов, веб служб, и иже с ними:)

Worker role - это аппликация к которой мы не можем обратиться напрямую. Идеальный выбор для запуска запланированных процессов - например очистки базы данных, и т.д.

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

Но как? Два сайта = два аддреса!
А вот и нет! Все запросы к вашим веб ролям будут проходить через так называемый Network Load Balancer. Эта девайсина знает айпишки Ваших сайтов, и в зависимости от нагрузки Ваших серверов - перенаправляет запрос на одну из веб ролей.

Фабрика
Понятно, что вся эта инфраструктура никогда не запуститься, если не будет централизированного управления всем этим добром:) Вот тут и приходит фабрика! Помните фильм - Матрица? Все люди были подключенные к системе, которая показывала им мультики? Вот где то так и Фабрика управляет всеми виртуальными машинами, а следовательно и всеми веб и воркер ролями.

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

Единственное что не делает фабрика - эмуляция запоминающих устройств, или в терминологии Azure - Storage Services.
Достаточно тяжело представить программу которая бы чего нибудь не записывала. Даже самый элементраный репорт, или лог файл. Потому вопрос хранения данных очень остро стоит для всех облачных сервисов. В Ажуре у нас есть аж три типа хранилищь данных которые мы можем хранить и использовать в своих целях!

Blobs - Binary Large Object - блобы это просто бинарыне файлы. Блобы лежат в контейнерах как файлы в папках. Контейнеры могут быть двух типов: публичные и приватные. Очевидно, что чтобы считать данные из публичного контейнера - нам нинадо знать ничего, и любой человек в интернете может иметь доступ к этим файлам. Для того чтобы считать данные с приватного контейнера нам необходимо знать ключ аусентикации.

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

Tables. Это не реляционные таблички как может показаться с первого раза. Я бы даже сказал что это реперзентация NoSQL базы данных от Microsoft. В данном типе хранилища мы можем хранить что угодно - от строчек, до комплексных классов.

О чем нужно думать в первую очередь?
Могущество неограниченных возможностей может затуманить:) Да , мы действительно не знаем какая пропускная способность в датацентрах Ажура, но мы можем быть уверенны что нам точно хватит:) Главно помнить - что платить тоже нам.

Помните эту фразу которую я повторил уже огромное количество раз:

Мы платим за то что используем!

Этот слоган может быть как и прекрасным моментом для экономии , так и очень болючим ударом по кошельку:
Если у вас был сайт с одной воркер ролью, и вы случайно или специально поставили 10 ролей - помните - цена вырастет в 10 раз!!!

Когда вы запускаете аппликацию для клауда, Вам необходимо подумать не только о том как ее спроектировать, для того чтобы она испольщовала как можно меньшее количество ресурсов, но и такие вещи как расписание использование ресурсов. Например:
1. У вас есть магазин футболок.
2. Вы заметили что после 6 вечера количество посетителей на Ваш сайт возрастает в 10ки раз.

Это значит что никто не хочет покупать Ваши футболки в рабочее время, но после работы все приходят домой и садяться за компьютер именно с этой мыслью! Неужели из за этого вам необходимо подымать второй а то и третий экземпляр веб роли вашего сайта? Ведь тогда цена вырастет в 2-3 раза. Исчите компромисс - запускайте дополнительные экземпляры только после 6 вечера, и тушите их в 2 ночи. Этим вы заставите цену рости только в течении 8 часов, все остальное время будет работать только 1 экземпляр.

И еще небольшой пост из книжки "Azure in Action", почему использование Azure поможет вам сэкономить деньги:

I don't need to buy any infrastructure to run my application (Мне не нужна инфраструктура для запуска моих приложений)
I don't need to manage the infrastructure to run my application ( я не управляю инфраструктурой для запуска моих приложений)
My application runs on the same infrastructure that Microsoft uses to host their services, not some box under a desk (Мои приложения крутяться на той же инфраструктуре, на которой Microsoft держит свои сервисы, а не на каком нибудь компьютере под столом)
I can scale my application out on-demand to use whatever resources it needs to meet the demands of my application ( Я могу маштабировать по желанию ресурсы инфраструктуры которые необходимы для моей аппликации)
I only pay for the resources that I use when I use it ( Я плачу только за то что использую)
I am provided a framework that allows me to develop scalable software that runs within the Windows ( У меня есть инструменты для разработки расширяемого ПО которое запускается на Windows)
Azure Platform so my applications can run at Internet Scale
I can focus on what I am good at, i.e. developing software ( Я могу сфокусироваться на том в чем я хорош - например разработке(
I can watch Football and drink milkshakes without being disturbed because some idiot pulled out the server power cable so they could do the vacuuming (я могу смотреть футбол и пить коктейли, и меня не потревожат что какой - то идиот вытащил кабель питания чтобы пропылесосить)
Save lots of money ( Сохраняет мноооого денег:))

На сегодня все, дальше будет интересней!:)

А у наших друзей - конкурс!

2011-02-21T23:25:00.000+02:00

Всем привет! Вы читаете книжки - и не знаете как похвастаться этим? У наших друзей с Винници отличный конкурс именно для Вас!

"Как пройти в библиотеку? Новый конкурс для читающих людей!"

Заходите, читайте, пишите, выигрывайте!

Lviv .Net User Group #10! Cloud + Mobility!

2011-02-10T10:33:00.003+02:00

Как Мы и обещали - у Нас новая встреча! Ещё более интресная!

Итак, встреча пройдет 24 февраля, традиционно в помещении компании SoftServe, в 19:30, по аддресу Вл. Великого 52.

Линка на гугл мапс: тут

Помните, что клауды и мобилити - это тренды ближайших нескольких лет и поэтому у нас будут выступать такие бизоны IT:

1. Зеник Матчишин, родитель "Украинского Хабра" - rozrobka.com. Он расскажет нам про Amazon Clouds in Action.

2. Вася Мылько, R&D директор компании SoftServe. Представлять Васю ненадо, те кто был на его выступлении на второй встрече - навсегда полюбили его доклады:) Вася будет рассказывать нам про Mobility.

Важно: регистрация обязательна! Нам необходимо знать на какое число людей рассчитывать. В этот раз те кто не зарегестрировался - не будут иметь возможности войти.

Регистрация тут: http://bit.ly/lvivdotnet10

S.O.L.I.D

2011-02-07T13:53:00.001+02:00

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

S - Single Responsibility Principle

Очень простой принцип - объект должен быть ответственным только за один тип функционала. Роберт Мартин определяет ответственность объекта как причину изминения объекта, и как по мне это золотые слова которые собственно и описывают этот принцип.

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

class SuperClass{
public string GetAccountName()
{
//Some logic of retrieving name
return string.Empty;
}
      public void SendMail()
{
//some logic of sending email here
}
}

Итак, в результате у нас есть объект который умеет как вытаскивать имя пользователя, так и отправлять письма. Если нам потребуется изменить логику отсылки почты, нам прийдется менять этот класс. Или же если имя пользователся вытаскивалось из SQL Server, а нам надо поменять на Oracle - нам опять же прийдется менять этот класс. Логичнее было бы разделить функционал вытаскивания имени и отсылки почты на два отдельных объекта - это бы дало нам больше гибкости, и возможность использовать единожды написанный метод отсылки почты в других компонентах.

O - Open/Closed Principle.

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

Давайте представим ситуацию: Вы пишите систему , которая может обробатывать разные типы платежей: штрафы, кредиты, налоги. Если мы дадим нашему новичку такое задание, скороее всего он напишет что-то вроде этого:

class SuperBankApp
{
public void ProcessPayment( string paymentType )
{
switch (paymentType)
{
case "tax":
//some logic here
break;
case "fee":
//some logic here
break;
case "loan":
//some logic here
break;
}
}
}

Теперь давайте представим, что вдруг добавился ещё один вид платежей - коммунальные услуги. Для того чтобы добавить такой платеж, нам надо лезть в код программы и добавлять ещё один дополнительный случай.

Теперь, после того как мы прочитали лекцию нашему начинающему программисту о том что так писать нельзя, покажем ему пример хорошего дизайна:

а. Давайте создадим общий для всех платежей интерфейс:

public interface IAccount
{
void ProcessRequest();
}

б. Для каждого типа платежей давайте создадим отдельный класс, который будет реализовать наш интерфейс.

в. Давайте внесем некоторые изменения в нашу программу:

public List accounts = new List();
public void AddAccount( IAccount acc)
{
accounts.Add(acc);
}
public void ProcessPayment()
{
foreach (IAccount acc in accounts)
{
acc.ProcessRequest();
}
}

Теперь, если нам понадобиться добавить ещё один платеж - нам не надо будет изменять уже существующий код, вместо этого мы создадим ещё один класс для платежа который будет реализовать наш интерфейс.

Собственно этот принцип может быть поддержан разными методами: абстрактные классы, интерфейсы, полиморфизм, и т.д. Просто выберите метод которые наиболее подходит Вашим нуждам.

L-Liskov Substitution Principle.

Этот принцип был впервые высказан Барбарой Лисков в 1987 году. Собственно принцип сформулирован следующим образом:

Пусть q(x) является свойством, верным относительно объектов x некоторого типа T. Тогда q(y) также должно быть верным для объектов y типа S, где S является подтипом типа T.

Собственно идея принципа достаточно проста - мы должны иметь возможность заменить базовый класс объектом который наследуется от него, и при этом все должно работать прекрасно и программа ломаться не должна. Этот принцип очень тесно связан с принципом Открытости / Закрытости. Давайте поговрим немного детальнее почему.

Давайте представим ситацию - у насть есть базовый класс Shape, и два класса которые унаследовываются от него: Square, Circle. Снова позовем нашего начинающего программиста, и попросим написать метод который принимает на вход объект типа Shape, и при этом выдает нам площадь фигуры которую мы передали. Наш начинающий программист не глуп, и знает что площадь разных фигур вычитывается разными формулами, потому он нам выдал что-то вроде такого:

public void CountArea(Shape sh)
{
if (sh is Square)
{
//count area for square
}
if (sh is Circle)
{
//count area for circle
}
}

Опять представим ситуацию , появилась у нас новая фигура - прямоугольник. Вот собственно и все - надо менять и добавлять новый функционал. А это нарушает принцип открытости/закрытости.

Чтобы все работало и устраивало оба принципа необходимо произвести такие действия:

а. Базовый клас Shape должен задавать виртуальный метод GetArea.

б. Объекты Circle, Sqare должны перегружать этот метод собственной формулой.

в. Теперь нам не надо определять тип объекта переданного в метод чтобы посчитать площадь:)

I - Interface Segregation Principle

Чтобы не размусоливать то что и так понятно - когда интерфей начинает толстеть - он должен быть разбитым на более мелкие интерфейсы.

Я люблю все показывать на примерах, потому давайте представим ситуацию:

а. Есть у нас два объекта: Cat, Dog.

б. Объекты наследуются от интерфейса IAnimal.

в. В предыдущей версии Вашей программы Вам необходимо было реализовать только 1 метод - Walk.

Логично , что метод задавался в интерфейсе. Теперь, допустим нам надо реализовать методы Meow и Bark. Если включить логику, то станет понятно что собака не сможет мяукать, а кошка не сможет гавкать ( хотя кто их знает, экология ж). Если это задание опять же поручить нашему программисту новчику, то скорее всего он задаст методы в интерфейсе IAnimal , и поставит заглушки в методое Bark класса Cat, и в методу Meow класса Dog. Хорошим же решением было бы добавление двух новых интерфейсов ICommonCat и ICommonDog соответственно для классов Cat и Dog. Общие же методы (например Eat) можна задавть все там же в интерфейсе IAnimal.

D - Dependency Inversion Principle

Данный принцип говорит нам:

Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций. Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.

Собственно ситуация стандартная - у нас есть низкоуровневые классы, которые реализут определенный функционал. Есть высокоуровневые классы, которые пользуюясь низкоуровневыми классами собирают весь функционал в кучу.

Давайте представим ситуацию:) у нас есть объект который считывает данные из базы SQL Server , и передают все в класс Engine, которые эти данные обрабатывает. В один прекрасный день нам надо перейти с базы SQL Server на базу Oracle - нам надо менять в объекте Engine все упоминания про один ридер, и заменять другим.Если бы у нас все было устроено на абстракциях - то таких замен было бы в разы меньше.

Давайте опять позовем нашего начинающего программиста, и посмотрим чего он накодил:

public class Worker
{
public void Work()
{
//do some work
}
}
    public class SeniorWorker
{
public void Work()
{
//do some senior work
}
}
    public class Manager
{
public void Manage( Worker simpleWorker)
{
simpleWorker.Work();
}
        public void Manage( SeniorWorker seniorWorker)
{
seniorWorker.Work();
}
}

Как мы видим есть два объекта Worker и SeniorWorker, а также класс Manager который может заставлять обоих работать. Минус - для каждого из Worker надо отдельный метод, ибо мы зависим от класса а не от асбтракции. Давайте сделаем некоторые модификации в наш код:

public interface IWorker
{
void Work();
}
    public class Worker:IWorker
{
public void Work()
{
//do some work
}
}
    public class SeniorWorker:IWorker
{
public void Work()
{
//do some senior work
}
}
    public class Manager
{
public void Manage( IWorker worker)
{
worker.Work();
}
}

С данного примера мы видим что объект менеджер теперь зависит от абстракции IWorker. Потому даже если добавится друго рабочий, нам надо будет всего лиш создать новый класс и унаследоваться от интерфейса IWorker.

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

Lviv .Net User Group #9! Презентации

2011-01-27T15:38:00.000+02:00

Презентации наших доклдчиков:

Юра Опрышко:

Go mobile with Windows Phone

View more presentations from Lviv .Net User Group.

Олег Скляренко:

Modern mobile development overview

View more presentations from Lviv .Net User Group.

Lviv .Net User Group #9! Впечатления

2011-01-27T11:59:00.000+02:00

Всем привет,

Ух и была эта встреча! Опять аншлаг! Это радует, значит Вам интересно!

Встреча прошла в офисе компании SoftServe, пришло по моим скромным подсчетам 40++ людей. С 7 часов можно было поиграть в кинект, где участники разделились на людей который играли, и людей которые смотрели, фан получали обе команды:)

Вел встречу Рома Крайовский с Маврикии по удаленке:) Все были очень рады его видеть, тем более что он был в футболке нашей группы!

После начались доклады.

1. Олег Скляренко - немного затянутая, но ОЧЕНЬ информативная секция. Сразу видно было что Олег очень хорошо понимает область, и хочет донести знания до слушателей. Олег охватил очень большой спектр платформ для разработки под мобильные телефоны: от Java ME до Blackberry.Для себя я почерпнул очень много, за что Олегу спасибо.

2. Юра Опрышко пришел с реальный Windows Phone 7 девайсом, и хоть у него тормозил мой ноутбук:) и была непривычная клавиатура - Юра справился с докладом. Доклад был легким, и веселым. Интересная инфа про то как программировать под Windows Phone 7, какие есть подводные камни , а какие есть вкусности.

Каждый докладчик получил по новой чистой футблоке:) от нашей группы, и от компании SoftServe.

После началась неофициальная часть - кинект, пиво, пица! Все развлекались как могли, устраивали чемпионаты по играм, смеялись с участников, смеялись сами с себя. Вообщем встреча удалась, и мы постараемся чтобы остальные встречи были не менее интересные!

Мы благодарим компанию SoftServe за то что приютила, оказала организационную и финансовую поддержку! Без Вас было бы не так весело и уютно! Спасибо!

Табличка GoF дизайн "патернів вівторка"

2011-01-18T00:09:00.004+02:00

Нижче знаходяться посилання на усі 23 "патерни вівторка" які входять до всім відомої книги банди чотирьох. Для зручної навігації вашій увазі пропонуємо наступну табличку:

Породжуючі патерни	Структурні патерни	Патерни поведінки
Абстрактна фабрика	Адаптер	Ланцюжок відповідальностей
Будівельник	Міст	Команда
Фабричний метод	Компонувальник	Інтерпретатор
Прототип	Декоратор	Ітератор
Одинак	Фасад	Медіатор
	Флайвейт	Хранитель
	Проксі	Спостерігач
		Стан
		Стратегія
		Шаблонний метод
		Відвідувач

Зовсім скоро чекайте електронну книгу із усіма GoF дизайн патернами, граматично відкореговану із глибшими поясненнями і власноручними ілюстраціями (якщо мені на то стане здоров'я) + UML-діаграми до прикладів.

Якщо є якісь побажання до цієї роботи, то будь-ласка давайте знати. Буду дуже вдячний.

А тим часом не забувайте приходити на зустрічі Львівської Юзер Групи, та слідкувати за блогом (і моїм також).

Lviv .Net User Group #9!

2011-01-12T12:53:00.002+02:00

Всем привет!

Мы открываем 2011 год новыми встречами и интересными событиями!
Новая встреча будет , 26 января, офис компании SoftServe, ул. Володимра Великого 52!

Линк на гугл мапс: ВОТ

Мобильные телефоны ( а можна ли их уже называть просто телефоном, или даже смартфоном? ) прочно входят в нашу жизнь. Игроков на рынке все больше и больше, потому мы будем стараться расскрывать эту тему на наших встречах как можно шире!

На этой встрече Вы сможете прослушать:

1. Олег Скляренко с темой: "Modern mobile development overview: platforms, trends, specifics"
2. Юра Опрышко с темой:"Go Mobile with Windows Phone"

Так же традицонное афтерпати!
И ещё одна прекрасная новость:
На этой встрече вы сможете лично пощупать что такое Windows Phone 7, а так же попбровать последнюю разработку Microsoft - Kinect!

Внимание: доклады начинаются в 19:30, но Вы можете прийти в 19:00 чтобы опробовать Kinect до начала встречи. Конечно же сможете сделать тоже самое на афтерпати!

Линк на регистрацию ТЫЦ!

С уважением,
-Дима

"Патерн Вівторка" #22: Адаптер (Adapter)

2011-01-11T23:54:00.001+02:00

Я із деяких причин дуже довго думав над тим який же може бути хороший приклад для Адаптера. Можна приклад коли є операції, які так і називаються ОпераціяА та ОпА, або придумати складний приклад із кучою методів і пропертів в класі що адаптується, але весь цей час в голові у мене крутилася така штукенція, яку ми соваємо у розетку, коли разетка вузька ще СРСР-рівська а ми хочемо запхати шнур для жившення ноутбука із товстою вилкою. Майже така як на картинці збоку, але не настільки жорстока.

Отже у нас є вилка від зарядного пристрою, яка підходить в широкі роз’єми. В одній із квартир у нас усе сучасне, тому NewElectricitySystem має метод MatchWideSocket, яким ми просто можемо скористатися. В іншій квартирі у нас проблемки тому OldElectricitySytem має тільки метод MatchThinSocket. Нажаль ми не можемо собі позволити взяти дрель і роздовбати отвори в розетці – ми купляємо Адаптер, який надає можливість користуватися тою ж функціональністю споживання електричного струму, але із старої системи.

АДАПТЕР

Адаптер – це дизайн патерн, що надає можливість користуватися об’єктом, зміни у який ми не можемо робити, надаючи його функціональність через відомий нашій системі інтерфейс.

// Adaptee
    class OldElectricitySystem
    {
        public string MatchThinSocket()
        {
            return "220V";
        }
    }
    // широковикористовуваний інтерфейс
    // Target
    interface INewElectricitySystem
    {
        string MatchWideSocket();
    }
    class NewElectricitySystem : INewElectricitySystem
    {
        public string MatchWideSocket()
        {
            return "220V";
        }
    }
    // Adapter
    class Adapter : INewElectricitySystem
    {
        private readonly OldElectricitySystem _adaptee;

        public Adapter(OldElectricitySystem adaptee)
        {
            _adaptee = adaptee;
        }
        // А тут коїться вся магія 
        // наш адаптер перекладає із того,
        // що ми (код) не можемо використати наразі у те що ми можемо
        public string MatchWideSocket()
        {
            return _adaptee.MatchThinSocket();
        }
    }
    // Consumer
    class ElectricityConsumer
    {
        // Зарядний пристрій розуміє тільки нову систему
        public static void ChargeNotebook(INewElectricitySystem electricitySystem)
        {
            Console.WriteLine(electricitySystem.MatchWideSocket());
        }
    }

    public class AdapterDemo
    {
        public static void Run()
        {
            // 1) Ми можемо і надалі користувати нашою новою системою
            var newElectricitySystem = new NewElectricitySystem();
            ElectricityConsumer.ChargeNotebook(newElectricitySystem);

            // 2) Ми повинні адаптуватися до старої системи, використовуючи адаптер
            var oldElectricitySystem = new OldElectricitySystem();
            var adapter = new Adapter(oldElectricitySystem);
            ElectricityConsumer.ChargeNotebook(adapter);
        }
    }

Ще одним ім’ям цього дизайн патерну є Wrapper із-за того що він огортає функціональність якогось об’єкту представлючи її у вигляді іншого інтерфейсу.

Насправді в реалізації не є обов’язковим композиція adaptee, наш клас Adapter міг б реалізовувати два інтерфейси – нової і старої системи. Таким чином одного разу створивши його на базі нової або старої системи, зробивши два конструктори (а чому б і ні), ми б могли використовувати його у два боки.

"Патерн Вівторка" #21: Фасад (Facade)

2011-01-04T23:53:00.007+02:00

Уявімо, що ви вирішили провести свої вихідні дуже активно, а тому приїхали на зимовий курорт покататися на лижах. Перед тим як кататися вам добре б було пересвідчитися, що ввечері буде де заночувати і заплатити за проживання, тому ви йдете в місцевий готель і замовляєте собі кімнату у відповідності до ваших вимог. Потім звичайно що треба мати на чому кататися, тому ви йдете взяти лижі на прокат. Для того, щоб підібрати їх вас питаються вашу вагу, і рівень професіоналізму, потім ви підбираєте черевики і палки, для чого вас ще спитають ваш ріст і розмір взуття. Із цим усім на хребті ви йдете до каси і купляєте aбонемент на день. Не знаю як вас, але мене таке ходіння б дістало. Я б хотів якийсь термінал, де вводиш потрібні дані, оплачуєш і тобі зразу мужик видає черевики, лижі, палки, абонемент на день і ключі до номеру в готелі (і дівчину у номер o_O)*, або якщо мені хватає абонементу на день а лижне спорядження я маю, то я купляю абонемент на місці.

ФАСАД

Фасад – це дизайн патерн, що надає єдину “точку доступу” до підсистеми, тим самим спрощуючи її використання та розуміння.

В нашому прикладі фасадом буде термінал-обслуговувальна станція (SkiResortFacade) а підсистемою є ціла купа прокатних будок, кас, і готельних комплексів. Звичайно ми можемо полазити по курорту, якщо вам це подобається, але якщо дивитися із точки зору розробки програмного забезпечення, то якщо кожен собі буде лазити куди хоче і як хоче, то до добра таке не приведе, а лижники-новачки ніколи не будуть знати куди їм йти спочатку.

internal class SkiRent
    {
        public int RentBoots(int feetSize, int skierLevel)
        {
            return 20;
        }
        public int RentSki(int weight, int skierLevel)
        {
            return 40;
        }
        public int RentPole(int height)
        {
            return 5;
        }
    }

    internal class SkiResortTicketSystem
    {
        public int BuyOneDayTicket()
        {
            return 120;
        }
        public int BuyHalfDayTicket()
        {
            return 60;
        }
    }

    internal class HotelBookingSystem
    {
        public int BookRoom(int roomQuality)
        {
            switch (roomQuality)
            {
                case 3:
                    return 250;
                case 4:
                    return 500;
                case 5:
                    return 900;
                default:
                    throw new ArgumentException("roomQuality should be in range [3;5]", "roomQuality");
            }
        }
    }

    public class SkiResortFacade
    {
        private SkiRent _skiRent = new SkiRent();
        private SkiResortTicketSystem _skiResortTicketSystem = new SkiResortTicketSystem();
        private HotelBookingSystem _hotelBookingSystem = new HotelBookingSystem();

        public int HaveGoodOneDayRest(int height, int weight, int feetSize, int skierLevel, int roomQuality)
        {
            int skiPrice = _skiRent.RentSki(weight, skierLevel);
            int skiBootsPrice = _skiRent.RentBoots(feetSize, skierLevel);
            int polePrice = _skiRent.RentPole(height);
            int oneDayTicketPrice = _skiResortTicketSystem.BuyOneDayTicket();
            int hotelPrice = _hotelBookingSystem.BookRoom(roomQuality);

            return skiPrice + skiBootsPrice + polePrice + oneDayTicketPrice + hotelPrice;
        }

        public int HaveRestWithOwnSkis()
        {
            int oneDayTicketPrice = _skiResortTicketSystem.BuyOneDayTicket();
            return oneDayTicketPrice;
        }
    }

    public class FacadeDemo
    {
        public static void Run()
        {
            var skiResortFacade = new SkiResortFacade();

            int weekendRestPrice = skiResortFacade.HaveGoodOneDayRest(175, 60, 42, 2, 3);

            Console.WriteLine("Price: {0}", weekendRestPrice);
        }
    }

Цей дизайн патерн можна розглядати як наступний рівень такого важливого принципу як інкапсуляція. Просто на цьому рівні ми інкапсулюємо цілу підсистему. Великі системи зазвичай здійснюють взаємозв’язок одна із одною за допомогою цього патерну. Космічна станція у космосі стикається із іншою за допомогою одного механізму, а не прикрученні сотні дротів поокремо. Також добрим тоном буде, якщо кожна із збірок які ви пишете має свого роду фасад, щоб її потім можна було легко використовувати із інших частин програми.

Дякую.

* добавив мій друг, після прочитання

Моя табличка Патернів

Новый год и итоги!

2010-12-29T11:48:00.004+02:00

Всем привет!

Через пару дней Новый Год, время когда многие пересматривают события прошедший за этот год, и строят планы на следующий!

Итак, что случилось в нашей группе за этот год:

1. Мы появились! Радует что мы появились на постоянно основе, и в отличии от многих групп - это не группа одного человека:)
2. Мы только начали строить коммьюнити, но радует то, что то что есть у нас - это молодое, но перспективное коммьюнити.
3. Многое что задумали удалось, но многое не удалось:) Мы будем работать над этим!
4. Лично я познакомился со многими интересными людьми, с которыми я бы не познакомился без коммьюнити. Я рад что встретил Вас!

Наверное больше не будем про группу, Вы и так все знаете!

Хочу поздравить Вас с наступающим Новым Годом, пожелать чтоб все Ваши желания в следующем году выполнились и чтобы у Вас всегда было желание и энергия на то чтобы все это воплотить в жизнь! Радости, удачи, семейного счастья, и материального благополучия!

До встречи в следующем году, будет интересно!

С Уважением,
-Дима

"Патерн Вівторка" #20: Абстракнта Фабрика (Abstract Factory)

2010-12-28T01:16:00.001+02:00

Уявімо, що ви прийшли в іграшковий магазин (відіграючи роль діда мороза) і хочете накупляти іграшок дітям (не обов’язково своїм). Одна дитина любить плюшеві іграшки, вона часто із ними лягає у ліжко спати. А інша дитина страшна розбишака, ламає все на світі, рве м’які іграшки і зазвичай віддає перевагу гратися із твердими, дерев’яними іграшками. Двоє дітей хочуть ведмедика і котика і ще купу інших тваринок. На щастя магазин має широкий асортимент іграшок і ви вдосталь закупилися. В один мішок ви накидали дерев’яних іграшок, а в інший плюшевих.

Таким чином, коли ви підійшли до першої дитини, яка любить м’які іграшки, ви витягали із свого мішка спочатку плюшевого ведмедя, а далі плюшевого котика і так далі. Аналогічно ви підійшли до іншої дитини і подарували їй дерев’яного ведмедика і котика, і собаку і слона…

АБСТРАКТНА ФАБРИКА

Абстрактна фабрика – це дизайн патерн, що поставляє інтерфейс для створення сімейств об’єктів.

В нашому прикладі сімейством є іграшки із базовими класами Ведмедика (Bear), Кота (Cat). Абстрактною фабрикою є мішок. Одна із конкретних фабрик повертає дерев’яні іграшки, а інша повертає плюшеві. Тому якщо одна дитина просить котика то їй вернуть котика у відповідності до інстційованого мішка із ігрушками.

Я надіюся, що приклад із аналогіями видався гарним. Ну що подивимося трохи коду?

Абстрактна фабрика та конкретні реалізації (мішки)

Абстратна факбрики визначає інтерфейс, що повертає об’єкти Кота або Ведмедя (базові класи). Конкретні реалізації фабрики повертають конкретні реалізації ігрушок потрібного сімейства.

// abstract factory
    // абстракна фабрика
    public interface IToyFactory
    {
        Bear GetBear();
        Cat GetCat();
    }
    // concrete factory
    // конкретна фабрика
    public class TeddyToysFactory : IToyFactory
    {
        public Bear GetBear()
        {
            return new TeddyBear();
        }
        public Cat GetCat()
        {
            return new TeddyCat();
        }
    }
    // concrete factory
    // конкретна фабрика
    public class WoodenToysFactory : IToyFactory
    {
        public Bear GetBear()
        {
            return new WoodenBear();
        }
        public Cat GetCat()
        {
            return new WoodenCat();
        }
    }

Уже зрозуміло, що як тільки ми маємо якийсь екземпляр фабрики, ми можемо плодити сімейство потрібних іграшок. Тому глянемо на використання:

// lets start with wooden factory
            // спочатку створимо дерев'яну фабрику
            IToyFactory toyFactory = new WoodenToysFactory();

            Bear bear = toyFactory.GetBear();
            Cat cat = toyFactory.GetCat();
            Console.WriteLine("I've got {0} and {1}", bear.Name, cat.Name);
            // Output/Вивід: [I've got Wooden Bear and Wooden Cat]

            /*-------------- 
             somewhere else in the code...
             десь далі в коді...
            ----------------*/

            // and now teddy one
            // а тепер плюшеву
            IToyFactory toyFactory = new TeddyToysFactory();

            Bear bear = toyFactory.GetBear();
            Cat cat = toyFactory.GetCat();
            Console.WriteLine("I've got {0} and {1}", bear.Name, cat.Name);
            // Output/Вивід: [I've got Teddy Bear and Teddy Cat]

Два куски коду майже абсолютно ідентичні – різниця тільки в конктетному “мішку”.

Якщо вас ще цікавлять реалізації іграшок-тваринок, то вони доволі наївні.

public abstract class AnimalToy
    {
        protected AnimalToy(string name)
        {
            Name = name;
        }
        public string Name { get; private set; }
    }
    public abstract class Cat : AnimalToy
    {
        protected Cat(string name) : base(name) { }
    }
    public abstract class Bear : AnimalToy
    {
        protected Bear(string name) : base(name) { }
    }
    class WoodenCat : Cat
    {
        public WoodenCat() : base("Wooden Cat") { }
    }
    class TeddyCat : Cat
    {
        public TeddyCat() : base("Teddy Cat") { }
    }
    class WoodenBear : Bear
    {
        public WoodenBear() : base("Wooden Bear") { }
    }
    class TeddyBear : Bear
    {
        public TeddyBear() : base("Teddy Bear") { }
    }

Абстрактна фабрика є дуже широковикористовуваним дизайн патерном. Дуже яскравим прикладом буде ADO.NET DbProviderFactory, яка є абстракною фабрикою, що визначає інтерфейси для отримання DbCommand, DbConnection, DbParameter і так далі. Конкретна фабрика SqlClientFactory поверне відповідно SqlCommand, SqlConnection і так далі.

Дякую за те що прочитали цей дизайн патерн із моїм прикладом (надіюся унікальним, якщо ні – то я перевинайшов колесо чи то що).

Моя табличка Патернів

"Патерн Вівторка" #19: Стратегія (Strategy)

2010-12-15T01:13:00.002+02:00

Просто як двері – якщо на дворі дощ, то ви берете парасольку і куртку, а якщо палить сонце – то ви берете футболку і сонцезахисні окуляри. Що одівати є вашою стратегією, яку ви міняєте в залежності від обставин. Але замість того, щоб дивитися за вікно яка погода а потім мандрувати до шафки із одягом і вибирати що надягнути а далі, пам’ятаючи яка погода, йти до іншої шафки і брати парасольку або окуляри, ви просто піднімаєтеся із ліжка протираєте очі і вам у руки жінка(чоловік, що маловірогідно) подає потрібний одяг і аксесуари. Іншими словами стратегія на сьогоднішній день просто була подана і ви нею скористалися.

СТРАТЕГІЯ

Стратегія – це дизайн патерн, що зберігає сім’ю алгоритмів і дозволяє їх міняти незалежно та переключатися між ними.

Припустимо що в класі Я (Myself) ми маємо метод піти на вулицю GoOutside() в якому ми вибираємо собі одяг і шуруємо на вулицю.

Метод міг виглядати подібно до ось цього:

public void GoOutside()
        {
            var weather = Weather.GetWeather();
            string clothes = GetClothes(weather);
            string accessories = GetAccessories(weather);
            Console.WriteLine("Today I wore {0} and took {1}", clothes, accessories);
        }

        private string GetAccessories(string weather)
        {
            string accessories;
            switch (weather)
            {
                case "sun":
                    accessories = "sunglasses";
                    break;
                case "rain":
                    accessories = "umbrella";
                    break;
                default:
                    accessories = "nothing";
                    break;
            }
            return accessories;
        }

        private string GetClothes(string weather)
        {
            string clothes;
            switch (weather)
            {
                case "sun":
                    clothes = "T-Shirt";
                    break;
                case "rain":
                    clothes = "Coat";
                    break;
                default:
                    clothes = "Shirt";
                    break;
            }
            return clothes;
        }

воно звичайно добре, але як тільки вам треба буде прилаштовуватися до випавшого снігу, вам прийдеться добавити ще один case в троьхсот місцях. Із одної сторони воно не складно, але із іншої вас може “дістати” або код із методом GoOutside() вже не можна буде міняти. Що тоді?

Тут я наводжу приклад із switch, тому що Strategy – це елегантний спосіб позбутися цього чуда.

internal class Myself
    {
        private IWearingStrategy _wearingStrategy = new DefaultWearingStrategy();

        public void ChangeStrategy(IWearingStrategy wearingStrategy)
        {
            _wearingStrategy = wearingStrategy;
        }

        public void GoOutside()
        {
            var clothes = _wearingStrategy.GetClothes();
            var accessories = _wearingStrategy.GetAccessories();

            Console.WriteLine("Today I wore {0} and took {1}", clothes, accessories);
        }
    }

Як бачимо ми маємо інтерфейс стратегії із двома методами. Нумо глянемо як виглядає стратегія на сонячний день:

public interface IWearingStrategy
    {
        string GetClothes();
        string GetAccessories();
    }

    class SunshineWearingStrategy : IWearingStrategy
    {
        public string GetClothes()
        {
            return "T-Shirt";
        }

        public string GetAccessories()
        {
            return "sunglasses";
        }
    }

Все, що нам залишилося то це правильно проставити стратегію. Ага! Всерівно хтось буде змішений проставити правильну стратегію (жінка, яка встала ранше і глянула у вікно, але вона може зробити це одним свічом, про який ви нічого не знаєте).

var me = new Myself();
            me.ChangeStrategy(new RainWearingStrategy());
            me.GoOutside();

Вивід простий: “Today I wore Coat and took umbrella”

Ще одним (але не моїм) гарним прикладом є зміна стратегії сортування списку в залежності від його розміру. Всі ми знаємо що для малої кількості даних достатньо сортування вставками або якийсь інший простий спосіб, для відносно великих списків найоптимальніше використовувати швидке сортування, а для дуже великої к-ті даних пірамідальне. Так от, алгоритм зберігається у своєму класі і в залежності від кількості елементів ми просто міняємо реалізацію алгоритму.

Моя табличка Патернів

PechaKucha Meetings

2010-12-14T11:45:00.000+02:00

Всем привет,

Как Вы смотрите на то чтобы провести PechaKucha встречу?

http://www.pecha-kucha.org/

Инфа про то, что такое PechaKcuha :)

Мне кажется будет интересно.

С уважением,
-Дима

Запізнілий "Патерн Вівторка" #18: Ланцюжок відповідальностей (Chain of Responsibility)

2010-12-07T23:57:00.005+02:00

Уявіть, що ви пішли із своїми друзями в кафе. Кафе дещо специфічне – мало місця, і коли вам приносять якусь страву зазвичай доводиться передавати її наступній людині за столом. Ваш найкращий друг сів найближче до краю, тому першим він і отримує до рук замовлення. Так як він спав мало зранку і любить щось поїсти із м’ясом, то він ніколи не передесть вам м’ясної страви і напою із кавою, допоки не вип’є хоч одну чашку чогось. Наступним після друга сидете ви, а далі ваша подружка, яка знаходиться біля стіни. Вона отримає все останньою, але на щастя вона хоче тільки капучіно, та й передавати їй уже не треба нікому.

ЛАНЦЮЖОК ВІДПОВІДАЛЬНОСТЕЙ

Я думаю що весь механізм патерну ланцюжка відповідальностей є зрозумілим - ми маємо набір обробників (handler) або відвідувачів кафе, які вміють обробляти команду або їжу у нашому випадку, а якщо обробити її не вдається, то команда передається наступному обробітнику.

Для прикладу із нашим кафе загальним інтерфейсом відвідувача такого дивного кафе може бути такий базовий клас:

public abstract class WierdCafeVisitor
    {
        public WierdCafeVisitor CafeVisitor { get; private set; }
        
        protected WierdCafeVisitor(WierdCafeVisitor cafeVisitor)
        {
            CafeVisitor = cafeVisitor;
        }

        public virtual void HandleFood(Food food)
        {
            // If I cannot handle other food, passing it to my successor
            if (CafeVisitor != null)
            {
                CafeVisitor.HandleFood(food);
            }
        }
    }

Як бачимо по замовчуванню їжа просто передається до наступного відвідувача у ланцюжку, якщо такий є.

Тапер глянемо на реалізацію, яка найбільше підходить вашому вибагловому другові:

public class BestFriend : WierdCafeVisitor
    {
        public List<Food> CoffeeContainingFood { get; private set; }
        public BestFriend(WierdCafeVisitor cafeVisitor) : base(cafeVisitor)
        {
            CoffeeContainingFood = new List<Food>();
        }

        public override void HandleFood(Food food)
        {
            if(food.Ingradients.Contains("Meat"))
            {
                Console.WriteLine("BestFriend: I just ate {0}. It was testy.", food.Name);
                return;
            }
            if (food.Ingradients.Contains("Coffee") && CoffeeContainingFood.Count < 1)
            {
                CoffeeContainingFood.Add(food);
                Console.WriteLine("BestFriend: I have to take something with coffee. {0} looks fine.", food.Name);
                return;
            }
            base.HandleFood(food);
        }
    }

Реалізації ще двох обробітників – Me та GirlFriend мають бути зрозумілими, але всештаки наведемо реалізацію відвідувача-подружки:

public class GirlFriend : WierdCafeVisitor
    {
        public GirlFriend(WierdCafeVisitor cafeVisitor) : base(cafeVisitor)
        {
        }

        public override void HandleFood(Food food)
        {
            if(food.Name == "Cappuccino")
            {
                Console.WriteLine("GirlFriend: My lovely cappuccino!!!");
                return;
            }
            base.HandleFood(food);
        }
    }

Все відносно просто – дівчина хоче капучіно, але вона у ланцюжку остання, пому поки друг ви вип’є щось із кавою капучіно вона не отримає.

А тепер використання – створимо два капучіно, два супи і кусок м’яса, створимо наших відвідувачів кафе, та будемо подавати їжу в руки другові:

var cappuccino1 = new Food("Cappuccino", new List<string> {"Coffee", "Milk", "Sugar"});
            var cappuccino2 = new Food("Cappuccino", new List<string> {"Coffee", "Milk"});

            var soup1 = new Food("Soup with meat", new List<string> {"Meat", "Water", "Potato"});
            var soup2 = new Food("Soup with potato", new List<string> {"Water", "Potato"});
            var meat = new Food("Meat", new List<string> {"Meat"});

            var girlFriend = new GirlFriend(null);
            var me = new Me(girlFriend);
            var bestFriend = new BestFriend(me);

            bestFriend.HandleFood(cappuccino1);
            bestFriend.HandleFood(cappuccino2);
            bestFriend.HandleFood(soup1);
            bestFriend.HandleFood(soup2);
            bestFriend.HandleFood(meat);

Вивід:

BestFriend: I have to take something with coffee. Cappuccino looks fine.
GirlFriend: My lovely cappuccino!!!
BestFriend: I just ate Soup with meat. It was testy.
Me: I like Soup. It went well.
BestFriend: I just ate Meat. It was testy.

Як видно із виводу в консоль, дівчина отримала тільки друге капучіно, а ви були змушені їсти суп без м’яса :)

Що цікаво, мо ми можемо після моєї дівчини підчепити ще один обробітник – скажімо мішечок для собачки і туди скинути, щось що ніхто не захоче їсти. Для цього прийдеться трішки змінити клас, щоб він мав метод на подобі SetNextVisitor абощо.

Моя табличка Патернів

Встреча в 2010

2010-12-07T12:25:00.000+02:00

Господа,

Так как многие начинают праздновать со средины декабря , группа уходит на выходные до 2011!:)

Потому планируйте что следующая встреча пройдет в конце января!:)

С уважением,
-Дима

Запізнілий "Патерн Вівторка" #17: Спостерігач (Observer)

2010-11-30T23:50:00.005+02:00

Багато людей люблять дивитися бокс. Але крім того, що люди його дивляться хтось то все діло фінансує. Левова частка тих фінансів приходить від всяких фанів і азартних гравців, які програють купу грошей ставлячи ставки.

Уявімо що ми маємо боксерську гру і є двоє людей що ставлять ставки – один любить ризиковані ставки, а інши навпаки дуже консервативний, і завжди кладе на того, хто швидше за все виграє бій. Хто такі ці гравці?

СПОСТЕРІГАЧ

Як і не було важко здогадатися гравці – це спостерігачі (Observer), а бійка, на яку вони ставлять гроші є суб’єкт (subject). Вони постійно спостерігають за ходом бійки, щоб змінити свої ставки.

Спостерігач – це дизайн патерн, що дозволяє автоматично реагувати багатьом об’єктам на зміну стану певного іншого об’єкту.

Отже кожен поважаючий себе азартний гравець може оновити свої ставки коли треба буде, тому він має метод Update().

public interface IObserver
    {
        void Update(ISubject subject);
    }

    public class RiskyPlayer : IObserver
    {
        public string BoxerToPutMoneyOn { get; set; }

        public void Update(ISubject subject)
        {
            var boxFight = (BoxFight)subject;

            BoxerToPutMoneyOn = (boxFight.BoxerAScore > boxFight.BoxerBScore) ? "I put on boxer B, if he win I get more!" : "I put on boxer A, if he win I get more!";


            Console.WriteLine("RISKYPLAYER:{0}", BoxerToPutMoneyOn);
        }
    }

    public class ConservativePlayer : IObserver
    {
        public string BoxerToPutMoneyOn { get; set; }

        public void Update(ISubject subject)
        {
            var boxFight = (BoxFight)subject;

            BoxerToPutMoneyOn = (boxFight.BoxerAScore < boxFight.BoxerBScore) ? "I put on boxer B, better be safe!" : "I put on boxer A, better be safe!";

            Console.WriteLine("CONSERVATIVEPLAYER:{0}", BoxerToPutMoneyOn);
        }
    }

Ось сама гра, яку споглядають наші гравці:

public interface ISubject
    {
        void AttachObserver(IObserver observer);
        void DetachObserver(IObserver observer);
        void Notify();
    }

    public class BoxFight : ISubject
    {
        public List<IObserver> Observers { get; private set; }
        public int RoundNumber { get; private set; }

        private Random Random = new Random();

        public int BoxerAScore { get; set; }
        public int BoxerBScore { get; set; }

        public BoxFight()
        {
            Observers = new List<IObserver>();
        }

        public void AttachObserver(IObserver observer)
        {
            Observers.Add(observer);
        }

        public void DetachObserver(IObserver observer)
        {
            Observers.Remove(observer);
        }

        public void NextRound()
        {
            RoundNumber++;

            BoxerAScore += Random.Next(0, 5);
            BoxerBScore += Random.Next(0, 5);

            Notify();
        }

        public void Notify()
        {
            foreach (var observer in Observers)
            {
                observer.Update(this);
            }
        }
    }

Використання:

var boxFight = new BoxFight();

            var riskyPlayer = new RiskyPlayer();
            var conservativePlayer = new ConservativePlayer();

            boxFight.AttachObserver(riskyPlayer);
            boxFight.AttachObserver(conservativePlayer);


            boxFight.NextRound();
            boxFight.NextRound();
            boxFight.NextRound();
            boxFight.NextRound();

А ось її вивід:

RISKYPLAYER:I put on boxer A, if he win I get more!
CONSERVATIVEPLAYER:I put on boxer A, better be safe!

RISKYPLAYER:I put on boxer B, if he win I get more!
CONSERVATIVEPLAYER:I put on boxer A, better be safe!

RISKYPLAYER:I put on boxer B, if he win I get more!
CONSERVATIVEPLAYER:I put on boxer A, better be safe!

RISKYPLAYER:I put on boxer B, if he win I get more!
CONSERVATIVEPLAYER:I put on boxer A, better be safe!

Було дуже коротко і лаконічно. Бо це дуже запізнілий патерн вівторка – майже середи.

Моя табличка Патернів

NuGet. Часть 1.

2010-11-27T13:07:00.001+02:00

Всем привет,

Сегодня я хочу Вам рассказать что ж такое NuGet. C NuGet я столкнулся когда готовился к докладу про MVC 3.0, и очень рад тому опыту который я получил.

Впервые когда я увидел NuGet я подумал:"Эй, я уже видел это в Джаве!" ( знаете, как в той серии СуасПарка:"Симпсоны уже делали это!":)). Но как же я ошибался, и в последующих постах я Вам расскажу почему.

Итак, что ж такое NuGet?
NuGet - это бесплатный продукт, с открытым кодом который облегчает добавление сторонних библиотек в ваше приложение. NuGet также является участником ASP.NET Gallery в Outercurve Foundation(больше информации про это классный продукт Вы можете найти на домашнем сайте этого продукта: http://nuget.codeplex.com/).

Где, когда, зачем и что облегчает этот продукт?
Вы когда-нибудь устанавливали такую компоненту как Elmah?(http://code.google.com/p/elmah/ ). Если да - то всего лишь посчитайте сколько действий Вам надо совершить чтобы использовать эту компоненту:

1. Используйте любой поисковик чтобы найти эту компоненту.
2. Зайти на домашний сайт Elmah.
3. Нажать на кнопку Скачать
4. Выбрать необходимый пакет ( с исходным кодом, без, и т.д) .
5. Скачать библиотеку.
6. Разархивировать то что было скачанно.
7. Добавить библиотеку в Вашу аппликацию.
8. Поискать как же настраивать эту библиотеку:)
9. Внести необходимые изменения в web.config.
10. Использовать в конце-концов!

Между прочим - очень приличная компонента, реккомендую к использованию.

Как это сделать с помощью NuGet?
Существует вообще два метода: метод блондинки и метод гика:)

Метод блондинки:
1. Кликните правой кнопкой мыши на проект и выберите "Add Library Package Reference..."

2. В строке поиска введите "Elmah" и нажмите Enter.
3. Найдите Elmah в резулитате и нажмите Install.
4. Используйте!

Метод Гика:
1. Нажмите "Ctrl+W" & "Ctrl + Z" или выберите в меню: Tools->Library Package Manager -> Package Manager Console.
2. Введите комманду "Install-Package Elmah" и нажмите "Enter" ( в будущих постах я расскажу что мы делаеми).
3. Ипользуйте!

Как видите никакой камасутры с web.config файлом, поиска версий в интернете, и других вещей которые необходимы для корректной работы компонент. В будущих постах я буду использовать метод гика потому как я ненавижу использование мыши:)

Что же мы сделали?
Library Package Manager - это аддон который вместе с NuGet инсталлируется в Вашу Visual Studio. Эта классная штука предоставляет нам консоль с помощью которой мы можем совершать ращличные действия над пакетами в NuGet. Так же, что хотелось бы добавить - Вы можете сами расширять комманды консоли с помощью PowerShell скриптов, а так же комманды могут расширяться с помощью библиотек которые вы доставляете с помощью NuGet.

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

Как проинсталировать NuGet?
Я проинсталлировал NuGet когда инсталлировал MVC 3.0 , хотя Вы можете пойти на домашнюю страничку этого классного продукта, и скачать его там: http://nuget.codeplex.com/.

Это был первый пост и серии постов про NuGet.

Дальше будет!
-Дима

Lviv .Net User Group #8. Впечатление

2010-11-25T13:59:00.000+02:00

Всем привет,

Вот мы и провели нашу 8 встречу!:) На этот раз нас приютила компания SoftServe в своем новом митинг руме в первом офисе. Митинг рум очень порадовал - новый и уютный. Так же компания SoftServe угощала нас вкусной пиццой и морем пива, за что мы ей страшно благодарны.

Немогу ничего сказать про свой доклад, лучше видно со стороны:) Так что, жду ваши фидбеки!:)

Доклад Ромы Крайовского про то как надо брейнштормить очень удивил людей, многие по другому начали прислушиваться к голосам в своей голове:) Рома получил просто оглушающие апплодисменты, коих и заслужил:)

Потом как обычно было афтерпати, где обсуждалось неймоверное количество тем, холиваров, и тд:)

Всем спасибо что пришли, и не забудьте прийти снова:)

С уважением,
-Дима

"Патерн Вівторка" #16: Компонувальник (Composite)

2010-11-23T09:11:00.005+02:00

Чи ви коли небуть задумувалися чому так багато у цьому світі має деревовидну структуру? Адміністративний устрій країни для прикладу, або ж ваша організація. Топ менеджмент компанії може делегувати роботу робому менеджерам відділів, які відповідно делегують її до ваших прямих менеджерів, а ті в свою чергу дадуть вам якусь роботу. Або для прикладу, XML, має деревовидну структуру, мабуть тому що це найкращий спосіб зберегти дані, що можуть містити дані, які в свою чергу можуть мітити дані, які... Отже, припустимо що вам слід зкомпонувати якийсь складний документ із частин. Деякі застини вміють збирати дані (GatherData), базуючить на відповідній ID-шці. Деякі частини, просто утримують інші частини. Ми побудуємо XML кустарними засобами у цьому прикладі.

КОМПОНУВАЛЬНИК

Компонувальник - це такий дизайн патерн, який дозволяє нам зберігати деревовидну структуру і працювати однаково із батьками та синами у дереві.

Розглянемо інтерфейс що визначає спільні вимоги до батьків і дітей (:

public interface IDocumentComponent
    {
        string GatherData();
        void AddComponent(IDocumentComponent documentComponent);
    }

А тепер реалізація одного із листків у нашому дереві - CustomerDocumentComponent, яка вміє збирати кусок XML, базуючись на ID-шці замовника.

public class CustomerDocumentComponent : IDocumentComponent
    {
        private int CustomerIdToGatherData { get; set; }

        public CustomerDocumentComponent(int customerIdToGatherData)
        {
            CustomerIdToGatherData = customerIdToGatherData;
        }

        public string GatherData()
        {
            string customerData;
            switch (CustomerIdToGatherData)
            {
                case 41:
                    customerData = "Andriy Buday";
                    break;
                default:
                    customerData = "Someone else";
                    break;
            }

            return string.Format("<Customer>{0}</Customer>", customerData);
        }

        public void AddComponent(IDocumentComponent documentComponent)
        {
            Console.WriteLine("Cannot add to leaf...");
        }
    }

А тепер реалізація нелисткових компонентів нашого дерева. Зверніть увагу, що в методі GatherData, ми просто ітеруємо по всіх "отприсках" і викликаємо наш основний метод для збору даних.

public class DocumentComponent : IDocumentComponent
    {
        public string Name { get; private set; }
        public List<IDocumentComponent> DocumentComponents { get; private set; }

        public DocumentComponent(string name)
        {
            Name = name;
            DocumentComponents = new List<IDocumentComponent>();
        }

        public string GatherData()
        {
            var stringBuilder = new StringBuilder();
            stringBuilder.AppendLine(string.Format("<{0}>", Name));
            foreach (var documentComponent in DocumentComponents)
            {
                documentComponent.GatherData();
                stringBuilder.AppendLine(documentComponent.GatherData());
            }
            stringBuilder.AppendLine(string.Format("</{0}>", Name));

            return stringBuilder.ToString();
        }

        public void AddComponent(IDocumentComponent documentComponent)
        {
            DocumentComponents.Add(documentComponent);
        }
    }

Клеїмо частинки докупи:

var document = new DocumentComponent("ComposableDocument");
            var headerDocumentSection = new HeaderDocumentComponent();
            var body = new DocumentComponent("Body");
            document.AddComponent(headerDocumentSection);
            document.AddComponent(body);

            var customerDocumentSection = new CustomerDocumentComponent(41);
            var orders = new DocumentComponent("Orders");
            var order0 = new OrderDocumentComponent(0);
            var order1 = new OrderDocumentComponent(1);
            orders.AddComponent(order0);
            orders.AddComponent(order1);

            body.AddComponent(customerDocumentSection);
            body.AddComponent(orders);

            string gatheredData = document.GatherData();

            Console.WriteLine(gatheredData);

Вивід певно схожий на XML, принаймні я хотів щоб він був таким.

<ComposableDocument>
<Header><MessageTime>8:47:23</MessageTime></Header>
<Body>
<Customer>Andriy Buday</Customer>
<Orders>
<Order>Kindle;Book1;Book2</Order>
<Order>Phone;Cable;Headset</Order>
</Orders>
</Body>
</ComposableDocument>

Варто добавити, що GoF-хлопці пропонують також методи Remove(Component) та GetChild(int) у інтерфейсі компоненту, тому можливо вам захочеться їх добавити. Одне хочу сказати - ніколи не зациклюєйтися на якихось прикладах і однотипних поясненнях. Ваші потреби можуть дещо відрізнятися від того що описано як дизайн патерн, але в той же час воно вам ідеально підходить, просто у вас якийсесь вироджене або ускладнене застосування.

Моя табличка Патернів

"Патерн Вівторка" #15: Команда (Command)

2010-11-16T08:33:00.002+02:00

Ваш босс дуже вимогливий чувак - він ніколи не переймається тим як буде робитися робота і не особливо переймається хто її буде робити - йому головне щоб вона була зроблена як тільки замовник дасть добро. Проте вашому босу ніхто не мішає назначати людей які будуть працювати над роботою. Він вирішив що ви, оскільки ви на високих позиціях у компанії, ідеально підходете для того щоб зібрати бригаду Z, отримати список вимог від замовника і бути готовими запустити роботу людьми із Z, як тільки замовник підпише контракт.

КОМАНДА

Команда - це такий дизайн патерн, що дозволяє інкапсулювати всю інформацію, необхідну для виконання певних операцій пізніше у коді.

В нашому прикладі ви є Командою (Command) - тому що ви інкапсулюєте справжню робочу групу Z, і параметри необхідні для старту роботи (проект і вимоги). Бригада, що є Отримувачем (Receiver) і вимоги, параметри, були вам передані вашим босом - Клієнтом (Client).

Замовник має контакт до вас і може попросити виконати вас усю необхідну їм роботу як тільки запуститься процес після підписання контракту. Замовник це ваш Запускач (Invoker), він знає як попросити вас виконати роботу, але вся робота і виконавці були вже сформовані.

Клієнтський код (Client)

А зараз трошки глянемо на код. Ось клієнський код, - ваш босс:

var customer = new Customer();

            // із певних міркуваня, босс завжди знає, що грошей стає тільки
            // на бригаду Z
            var team = new Team("Z");
            // він також отримав список вимог, що треба буде передати бригаді
            var requirements = new List<Requirement>() {
                   new Requirement("Cool web site"),
                   new Requirement("Ability to book beer on site") };
            // ви повинні бути готові бути викликаним замовником
            ICommand commandX = new YouAsProjectManagerCommand(team, requirements);

            customer.AddCommand(commandX);

            // в компанії також є програміст-герой, що кодує на швидкості світла
            var heroDeveloper = new HeroDeveloper();
            // босс вирішив віддати йому проект A
            ICommand commandA = new HeroDeveloperCommand(heroDeveloper, "A");

            customer.AddCommand(commandA);

            // як тільки замовник підписує контракт із вашим боссом
            // ваша бригада і програміст-герой готові виконати все що треба
            customer.SignContractWithBoss();

Команда (Command)

Тут просто глянемо як виглядають конкретні реалізації команд:

public interface ICommand
    {
        void Execute();
    }


    public class YouAsProjectManagerCommand : ICommand
    {
        public YouAsProjectManagerCommand(Team team, List<Requirement> requirements)
        {
            Team = team;
            Requirements = requirements;
        }

        public void Execute()
        {
            // реалізація делегує роботу до потрібного отримувача
            Team.CompleteProject(Requirements);
        }

        protected Team Team { get; set; }
        protected List<Requirement> Requirements { get; set; }
    }

    public class HeroDeveloperCommand : ICommand
    {
        public HeroDeveloperCommand(HeroDeveloper heroDeveloper, string projectName)
        {
            HeroDeveloper = heroDeveloper;
            ProjectName = projectName;
        }

        protected HeroDeveloper HeroDeveloper { get; set; }
        public string ProjectName { get; set; }

        public void Execute()
        {
            // реалізація делегує роботу до потрібного отримувача
            HeroDeveloper.DoAllHardWork(ProjectName);
        }
    }

Отримувач (Receiver)

Team та HeroDeveloper є отримувачами роботи, що має бути зроблена.

Запускач (Invoker)

Замовник насправді не дуже переймається хто буде робити його роботу, але він чітко хоче її зробити - він викликає метод Execute.

public class Customer
    {
        public Customer()
        {
            Commands = new List<ICommand>();
        }

        public void AddCommand(ICommand command)
        {
            Commands.Add(command);
        }

        protected List<ICommand> Commands { get; set; }

        public void SignContractWithBoss()
        {
            foreach (var command in Commands)
            {
                command.Execute();
            }
        }
    }

Вивід

User Story (Cool web site) has been completed
User Story (Ability to book beer on site) has been completed
Hero developer completed project (A) without requirements in manner of couple of hours!

Ага, а ще дайте мені знати чи взаємодія між цими всіма класами є зрозуміла і чи тут не бракує якоїсь UML-діаграми.

Моя табличка Патернів

Lviv .Net User Group #8. Location changed!

2010-11-12T12:30:00.001+02:00

Всем привет!

Встреча переносится на новое место!

Встреча пройдет в тоже время, в тот же день, в той же компании:)

Только по аддресу: Львов, ул. В.Великого 52.

Линк на локейшн:
http://maps.google.com.ua/maps?hl=uk&q=%D0%9B%D1%8C%D0%B2%D1%96%D0%B2,%20%D0%92%D0%BE%D0%BB%D0%BE%D0%B4%D0%B8%D0%BC%D0%B8%D1%80%D0%B0%20%D0%92%D0%B5%D0%BB%D0%B8%D0%BA%D0%BE%D0%B3%D0%BE%2052

UPD: ответ на вопрос "Почему?": тут лучше зал, и больше места:)

С уважением,
-Дима

Lviv .Net User Group #8

2010-11-10T12:50:00.004+02:00

Всем привет,

Пришло время очередной встречи!:)
8 встерча - 24 ноября, Володимира Великого 52, офис компнии SoftServe, 19:30.

Агенда:

1. Introduction to MVC 3.0. Малеев Дмитрий
2. Let's storm your BRAIN! Рома Крайовский.

Ну и конечно: подарки, пиво, и всяческие приятные мелочи!

Зарегестрироваться можна Тут

С уважением,
-Дима

"Патерн Вівторка" #14: Міст (Bridge)

2010-11-09T09:58:00.002+02:00

Уявімо, що ви володієте будівельною компанією, яка будує дачні будинки і житлові масиви. Зазвичай будівлі є двох типів - або із цегли або із бетонних плит. Оскільки ви бос, то ви вирішили поділити всіх ваших робітників на команди, які будуть вміти робити одні і ті ж операції: BuildFoundation, BuildRoom, BuildRoof. Але оскільки будівлі двох типів вам завжди приходиться тримати два типи різних команд (конкретних команд).

Одного разу виявилося що будівлі можуть бути побудовані із бетонних і цегляних стін одночасно. Так як у кожній із команд вміли працювати тільки із одним типом стін ви були змушені переміщати цілі команди із одного закутка міста в інший. Працівники почали жалітися і навіть запропонували вирішення проблеми. Пропозиція полягає у виділенні маленьких бригад, які спеціалізуються в будуванні кімнат або із бетонних або із цегляних стін. Таким чином тільки ці бригади і можна буде перевозити із одного закутка міста в інше, замість того, щоб мати окремі великі команди. От вона ідея!

МІСТ

Міст - це такий дизайн патерн, що дозволяє розділити імплементацію від її абстракції, таким чином реалізація може бути змінена окремо від абстракції, оскільки вона не наслідується від неї напряму.

Іншими словами наш інтерфейс IBuildingCompany може мати дві конкретні реалізації, такі як NearSeeBuildingCompany та CityBuildingCompany, кожна із яких напевно якось по своєму робить фундамент та кришу, оскільки грунт інший і погода також, але в той же час ми можемо просто і легко змінити реалізацію бригади побудови стін - WallCreator для будь-якої із компаній, щоб будувати або цегляні або бетонні стіни.

Нумо глянемо на BuildingCompany:

internal interface IBuldingCompany
    {
        void BuildFoundation();
        void BuildRoom();
        void BuildRoof();

        IWallCreator WallCreator { get; set; }
    }

    internal class BuldingCompany : IBuldingCompany
    {
        public void BuildFoundation()
        {
            Console.WriteLine("Foundation is built.{0}", Environment.NewLine);
        }

        public void BuildRoom()
        {
            WallCreator.BuildWallWithDoor();
            WallCreator.BuildWall();
            WallCreator.BuildWallWithWindow();
            WallCreator.BuildWall();

            Console.WriteLine("Room finished.{0}", Environment.NewLine);
        }

        public IWallCreator WallCreator { get; set; }

        public void BuildRoof()
        {
            Console.WriteLine("Roof is done.{0}", Environment.NewLine);
        }
    }

І що тут цікавого? Відповідь - властивість WallCreator, яка якраз і є мостом до реалізації.

Код використання

Глянемо на "міст" в дії:

// Ми маємо дві бригади - одна працює із цеглою а інша із бетоном

var brickWallCreator = new BrickWallCreator();
            var conctreteSlabWallCreator = new ConcreteSlabWallCreator();

            var buildingCompany = new BuldingCompany();
            buildingCompany.BuildFoundation();

            buildingCompany.WallCreator = conctreteSlabWallCreator;
            buildingCompany.BuildRoom();

            // Компанія може легко переключитися на іншу команду, яка буде будувати

// стіни із інших матеріалів

buildingCompany.WallCreator = brickWallCreator;
            buildingCompany.BuildRoom();
            buildingCompany.BuildRoom();

            buildingCompany.BuildRoof();

Хіба це не чудово? Вивід, я припускаю, є інтуїтивним, але оскільки я не наводив реалізацій класів BrickWallCreator та ConcreteSlabWallCreator подивимося на нього:

Foundation is built.

Concrete slab wall with door.
Concrete slab wall.
Concrete slab wall with window.
Concrete slab wall.
Room finished.

Brick wall with door.
Brick wall.
Brick wall with window.
Brick wall.
Room finished.

Brick wall with door.
Brick wall.
Brick wall with window.
Brick wall.
Room finished.

Roof is done.

UML - діаграма нижче зображає як структура цього дизайн патерну виглядає і чому його взагалі назвали мостом.

Моя табличка патернів

"Патерн Вівторка" #13: Одинак (Singleton)

2010-11-02T16:45:00.001+02:00

Я знаю що Діма уже написав чудову статтю про Синглтон тут.

Але я всештки ще перекладу свою. Уявімо що нам потрібна глобальна логувальна система в програмі, також нам треба логувати наші повідомлення десь в якийсь файл, при чому нумеруючі повідомлення в не залежності із якого закутка приграми вилетіла помилка.

Як можна це зробити?

ОДИНАК

Клас зображений нижче демонструє просту реалізацію Дизай Патерну Одинак (ця назва чесно кажучи звучить дещо дико. Думаю що може буде краще його називати Синглтон. Як думаєте?)

public class LoggerSingleton {

    private LoggerSingleton(){}
    
    private int _logCount = 0;

    private static LoggerSingleton _loggerSingletonInstance = new LoggerSingleton();

    public static LoggerSingleton GetInstance(){

    return _loggerSingletonInstance;

    }

    public void Log(String message){

    Console.WriteLine(_logCount + ": " + message);

    _logCount++;

    }

}

Отже ми збираємося почати нашу роботу із методу doHardWork і ми хочемо залогувати факт того що вона почалася, що відбувалося і факт того, що вона закінчилася.

Наша "важка робота" може виглядати так:

public static void doHardWork() {

    LoggerSingleton logger = LoggerSingleton.GetInstance();

    HardProcessor processor = new HardProcessor(1);

    logger.Log("Hard work started...");

    processor.processTo(5);

    logger.Log("Hard work finished...");

}

Як бачимо у нас є деякий клас HardProcessor. Що він наспраді робить нас не дуже має хвилювати, але ми б хотіли, щоб було залоговоно коли він створився і коли він виконував якісь підрахунки.

public class HardProcessor {

    private int _start;

    public HardProcessor(int start){

    _start = start;

    LoggerSingleton.GetInstance().Log("Processor just created.");

    }

    public int processTo(int end){

    int sum = 0;

    for(int i = _start; i <= end; ++i){

       sum += i; 

    }

    LoggerSingleton.GetInstance().Log("Processor just calculated some value: " + sum);

    return sum;

    }   

}

А ось вивід програми:

0: Processor just created.

1: Hard work started...

2: Processor just calculated some value: 15

3: Hard work finished...

Я написав цей приклад коли був у поїзді і показав його свому другу, який також є програмістом. Він мені сказав що я написав Моностейт. - Я? Де? Ми поглянули на код і як виявилося що тільки одна змінна в Синглтоні, яку я використовував, _logCount, була статичною в початковому варінті, який я написав. (Зараз вона змінена на змінню інстансу).

То ж в чому різниця між Синглтоном і Моностейтом?

Синглтон можна розглядати як спосіб забезпечення одного інстансу класу для нашої аплікації. Моностейт (Monostate) взагалі кажучи робить те ж що і GOF Синглтон. Всі змінні є статичними, таким чином теоретично ви можете мати багато інстансів Моностейту, але ж статичні дані одні і ті ж для одного і того ж типу.

Таким чином це допомагає також вирішити проблеми багатопоточності.

Давайте глянемо на приклад ще раз. Швидше за все, що логгер не є таким тривіальним, можливо ви захочете добавити функціональні зберігання останнього номера логу і при наступному зчитуванні починати нумерацію саме із того номера.

Але й ваша програма не така вже й тривіальна і логування викликається не тільки із багатьох місць у коді а й із багатьох потоків.

Оскільки конструктор вашого класу працює із IO, то виктачається час на створення екземпляру класу. Таким чином GetInstance() може привезти до ситуації коли ви створете декілька екземплярів класу. Напевно не так вже й добре для вашої аплікації.

На щастя є багато способів вирішити цю проблему. Найчастіше використовується Double-Checked Locking.

public class ThreadSafeLoggerSingleton {

    private ThreadSafeLoggerSingleton() {

      //reads data from some file and gets latest number of message

       //_logCount = got value here...

    }

    private int _logCount = 0;

    private static ThreadSafeLoggerSingleton _loggerInstance;

    public static ThreadSafeLoggerSingleton GetInstance(){

    if (_loggerInstance == null) {

          synchronized (ThreadSafeLoggerSingleton.class) {

            if (_loggerInstance == null)

                _loggerInstance = new ThreadSafeLoggerSingleton();

          }

        }

        return _loggerInstance;

    }

    public void Log(String message) {

        Console.WriteLine(_logCount + ": " + message);

        _logCount++;

    }

}

Є багато способів вирішення проблеми і не всі реалізації DCL працють. Прочитайте ось цю дуже хорошу статтю: http://www.cs.umd.edu/~pugh/java/memoryModel/DoubleCheckedLocking.html

Як можна побачити в методі Log я використовую змінну класу і роблю якісь операції які є майже атомарними. Проте якщо б операції були б складнішими то синхронізація знадобилася б і там.

(Я сьогодні трішки в ауті із часом, тому код майже С#-повський :) )

Моя табличка Патернів

Microsoft Razor. Как настроить UI для хелперов

2010-10-31T15:24:00.003+02:00

Всем привет,

Готовясь к Винницкому PDC я начал более активно копать новый View Engine Razor.

Итак View Engine Razor это основной синтаксис для создания сайтов с помощью Web Matrix, так же мы можем использовать его для создания View в ASP.Net MVC 3.0.

Хорошая новость - мы можем его использовать.

Плохая новость - подсветки и IntelliSense для него нету ( я говорю про MVC 3.0 ).

Как я уже говорил в Razor для нас создали огромное количество хелперов, присутсвуют такие хелперы как :

Twitter
Bing
ReCaptcha
Google Analytics
And much more...

С помощью хелперов мы можем добавить крутые фичи для нашего веб сайта. Допустим, с помощью такого кода :

Мы, практически, ничего не делая добавили отображения твиттера на нашем веб сайте. Выглядит, приблизительно, так:

Как видите, действительно очень просто. Но, я задался вопросом: "А как же конфигурить UI?". Видать у меня слабый "google-fu" потому готового ответа я не нагуглил. Потому, я попробовал использовать хелперы с код бихайнда, и благодаря intelliSense увидел что методы принимают огромное количество опциональных параметров. Кто не знает что такое опциональные параметры - бегом читать:)

Итак, приблизительно такое мы можем увидеть:

Итак, поэксперементировав с Razor, я теперь могу рассказать как же настроить UI для хелперов с Razor кода:)

Например такой код:

Сгенерит нам такую страницу:

да, я знаю что дизайн отвратный, но надеюсь что идея понятна:

1. Смотрим в код бихайнде ИМЯ опционального параметра.

2. В метод хелпера добавляем необходимые изменения.

Буду рад ответить на Ваши вопросы,

-Дима

Зустріч #7. Враження, враження, враження...

2010-10-30T10:14:00.003+03:00

Ось і пройшла 7-ма зустріч .NET юзер групи.

Цього разу вона проходила в офісі GlobalLogic, де нас гостинно приймали, правда, і не без лишніх секюріті заходів - всі були внесені в список, а також у них треба двічі проводити карткою, щоб вийти: спочатку біля турнікету, а потім ще біля самих дверей. Мабуть вони розробляють надзвичайно секретні програми або є інші причини, незрозумілі для нашої логіки.

На зустріч зареєструвалось досить багато людей, близько 80-ти, що стало рекордною кількістю. Нажаль наша кімната вміщала не більше 50-ти осіб і розміститись нам було важко, тому багатьом відвідувачам не вистачало місця. Всі хто не попав, будь-ласка, не розчаровуйтесь, та приходьте наступного разу, GlobalLogic обіцяли, що відремонтують великий зал, спецільно для наших зустрічей :) Ми обов’язково виправимось, та постраємось оперативно реагувати на таку кількість зареєстрованих людей і шукати більше приміщення.

Доповідь 1. Getting Scrum

Ігор Рациборинський розказував нам про Scrum на живому прикладі. Він розбив учасників на декілька команд, кожна із яких заповнила беклог питань, на які Ігор відповідав під-час спрінта-виступу. Було дуже весело та цікаво.

Доповідь 2. Domain-Driven Design

Андрій Будай розказував, вже в котре, про те, що таке спосіб розробки програмного забезпечення відштовхуючись від предментної області. Презентація нижче:

View more presentations from Andriy Buday.

Подарунки

Доповідачі і ще майже 50-тий зареєстрований отримали чудові сумки із написом VS2010, футболки із IE9, а також цікаві книги від GlobalLogic. Зауважте, подарунків стає все більше і більше, тому очікуєм, що саме ви будете наступним доповідачем.

After-Party

Як і завжди афтерпаті вдалось. Люди сперечалися про Erlang, Smalltalk, езотеричні мови програмування, розмірковували про .net фреймворк, майбутнє Java і С++... і все це із пивом та приравлене легкими закусками :)

Ваші відгуки

Оскільки мені пощастило бути учасником цієї зустрічі, то, як на мене, вона вдалася! Люди виглядали задоволеними. Дорогі саучаснєгі, нам дуже важлива ваша думка, пишіть листи з побажаннями, коментарі, та шліть апельсини бочками :)

Update:
Фотографії - http://picasaweb.google.com/eolexe/20101029Lvivdotnet7#
Відео - coming soon

"Патерн Вівторка" #12: Стан (State)

2010-10-26T00:55:00.002+03:00

Уявімо, що ми маємо розробити програму для відправки Замовлень (Orders). Замовлення можуть бути в одному із декількох станів: Новий (New Order), Зареєстрований (Registered), Погоджений (Granted), Відправлений (Shipped), Оплачений (Invoiced), Відмінений (Cancelled).

Також є певні правила, по яких Замовлення може перейти в інший стан. Для прикладу не можна відправити не зареєстроване замовлення.

Крім правил переходу є ще й інші правила, що визначають поведінку вашого замовлення. Наприклад, не можна додати Продукт до Замовлення коли воно є у відміненому стані.

Як можна гарно й чітко реалізувати таку систему поведінки Замовлення?

СТАН

Можливі стани

Щоб поведінка Замовлення і його станів була зрозуміліла, глянемо на наступну діаграму станів (state-chart):

Ми можемо інкапсулювати поведінку що пов'язана із станом об'єкту в класах різних станів, що наслідуються від якогось базового класу. Кожена із конкретних реалізацій буде відповідальна за надання можливості переходу із одного стану в інший.

Класична UML-діаграма дизнайн патерну Стан

UML-діаграма патерну Стан для нашого прикладу із Замовленнями

І як же воно працює?

Для початку зауважимо, що клас Order має поле-посилання на стан _state. Для того щоб приклад вигладав більш правдоподібніше добавимо також товари _products.

   public class Order
    {
        private OrderState _state;
        private List _products = new List();

        public Order()
        {
            _state = new NewOrder(this);
        }

        public void SetOrderState(OrderState state)
        {
            _state = state;
        }

        public void WriteCurrentStateName()
        {
            Console.WriteLine("Current Order's state: {0}", _state.GetType().Name);
        }

        //...

Order делегує специфічну для стану поведінку поточному стану:

   public void Ship()
        {
            _state.Ship();
        }

Наприклад, якщо поточний стан Granted, то метод _stete.Ship() змінить стан Order's на Shipped і якщо потрібно зробить ще якусь специфічну для цього стану роботу.

Код нижче зображає конкретну реалізацію одного із станів. Конструктор базового класу містить параметер типу Order, що дозволяє стану містити поле-посилання на його власника - на Замовлення якому присвоєний даний стан.

   public class Granted : OrderState
    {
        public Granted(Order order) : base(order)
        {
        }
        
        public override void AddProduct()
        {
            _order.DoAddProduct();
        }

        public override void Ship()
        {
            _order.DoShipping();
            _order.SetOrderState(new Shipped(_order));
        }

Якщо вас зацікавив метод DoShipping() то для нашого прикладу він просто виводить що він у процесі перевезення:

   public void DoShipping()
        {
            Console.WriteLine("Shipping...");
        }

Проте логіку яка стосується самого продукту ми можемо виконувати зразу у зовнішніх методах нашого замовлення не перевикликаючи її потім із стану, але це залежить від нас:

public void AddProduct(Product product)
        {
            _products.Add(product);
            _state.AddProduct();
        }

Якщо поточний стан Registered, то швидше за все такий стан не має перевизначеного методу ship(), а має тільки методи addProduct(), grant(), and cancel(). Таким чином метод базового класу буде викликаний. OrderState, він же базовий клас, має всі методи які можуть бути перевизначені у станах, але всі вони плуються ексепшинами, або ж просто виводять щось у консоль як у нашому прикладі:

    public class OrderState
    {
        public Order _order;

        public OrderState(Order order)
        {
            _order = order;
        }

        public virtual void Ship()
        {
            OperationIsNotAllowed("Ship");
        }
        
        // Other methods look similar...


        private void OperationIsNotAllowed(string operationName)
        {
            Console.WriteLine("Operation {0} is not allowed for Order's state {1}", operationName, this.GetType().Name);
        }
    }

Приклад використання

Здійснимо певний перелік операцій із ствонення замовлення, додання до нього нашого улюбленого пива і доставки на дім:

    public static void Run()
        {
            Product beer = new Product();
            beer.Name = "MyBestBeer";
            beer.Price = 78000;

            Order order = new Order();
            order.WriteCurrentStateName();

            order.AddProduct(beer);
            order.WriteCurrentStateName();

            order.Register();
            order.WriteCurrentStateName();

            order.Grant();
            order.WriteCurrentStateName();

            order.Ship();
            order.WriteCurrentStateName();

            order.Invoice();
            order.WriteCurrentStateName();
        }

Вивід:

Current Order's state: NewOrder
Adding product...
Current Order's state: NewOrder
Registration...
Current Order's state: Registered
Granting...
Current Order's state: Granted
Shipping...
Current Order's state: Shipped
Invoicing...
Current Order's state: Invoiced
Press any key to continue . . .

Нумо додамо ще трохи пивка до замовлення, яке вже нам відправили:

       order.Ship();
            order.WriteCurrentStateName();

            //trying to add more beer to already shipped order
            order.AddProduct(beer);
            order.WriteCurrentStateName();

Вивід:

Operation AddProduct is not allowed for Order's state Shipped

Current Order's state: Shipped
Press any key to continue . . .

Інші способи вирішити нашу проблему (не із пивом)

Одним із суттєвих недоліків цього дизайн патерну є розплід векилої кількості класів станів:

Але із іншої сторони саме так ми можемо чітко розділяти поведінку в залежності від станів. Я читав про вирішення цієї проблеми за допомогою таблички на подобі [state|method|state], що зберігає дозволені переходи. Проблема може бути також вирішена за допомогою свіча (мда щось воно не звучить)! Гарно про еволюцію цих підходів можна прочитати в книзі Jimmy Nilsson "Applying Domain-Driven Design and Patterns".

Моя табличка Патернів

Маленькие чудеса:ToDictionary() & ToList()

2010-10-22T08:45:00.001+03:00

Читать чудеса

Local PDC2010

2010-10-20T13:14:00.000+03:00

Всем привет,

Как многие наверное знают, в мире проводится конференция PDC. Крупная в США, и локальные в многих городах. В Украине два города в которых все будет происходить Харьков и Винница. Так что если хотите поучавствовать, вот линки:

Винница

Харьков

Немного слов о конференции:

Конференция Microsoft PDC - это, пожалуй, самая легендарная конференция, проводимая Microsoft. На PDC 1995 был представлен Windows 95, на PDC 2001 был представлен .NET, на PDC 2003 был представлен Windows Longhorn, Avalon (WPF), Indigo (WCF), WinFS (проект закрыт в 2006-ом году) Visual Studio Whidbey, SQL Server Yukon, на PDC 2005 была представлена Windows Vista с .NET Framework 3.0. Сейчас приближается новый виток развития нашей платформы и мы рады пригласить вас на конференцию к нам в гости!

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

Вас ждут интересные доклады, подарки и приятные знакомства. Присоединяйтесь!

С уважением,
-Дима

"Патерн Вівторка" #11: Прототип (Prototype)

2010-10-19T09:55:00.000+03:00

Чи ви коли небуть процювали із Outlook або ж якимось іншим календарем, що дозволяє копіювати календарні зустрічі із одного дня на інший?

Для прикладу уявімо собі, що ваш друг назначив маленьку вечірку із пивом на п'ятницю, 22 жовтня, також він виділив час під вечірку із 7-мої вечора до 3-тьої ночі, поставив високий приорітет, а ще він зазначив, що вечірка в п'ятницю має бути всім до душі, оскільки то останній робочий день. Оскільки ви були запрошені, вечірка пройшна надзвичайно добре. Під кінець вечірки ваш друг вирішив вислати таке ж запрошення на наступну п'ятницю, але оскільки він уже добряче випив, для нього заповнити календарну форму видалося занадто важко. Яку можливість можна добавити в клалендар, щоб вона була використана другом? Швидше за все "copy-paste" функціональність.

ПРОТОТИП

Прототип, це такий дизайн патерн, який дозволяє нам створювати копії об'єктів, що уже визначені на стадії дизайну (наприклад, список можливих типів зустрічей) або ж визначаються під час виконання програми ("п'ятнична вечірка"), таким чином відпадає необхідність заповняти всі елементи об'єкту від А до Я. Вже створені або визначені екземпляри об'єкту називаються прототипічними екземплярами (prototypical instances).

Як уже було описано один приклад використання цього патерну із копіюванням екземплярів об'єктів в час виконання програми, цей дизайн патерн дозволяє нам уникати великої кількості похідних класів. Для прикладу, замість того, що мати такі класи як "5 floors apartment block with 3 rooms flats", "9 floors apartment block with 2-3-4 rooms flats" і "12 floors apartment block with 1-2-3 rooms flats" ми можемо мати просто 3 екземпляри класу ApartmentBlock ініціалізовані вже із потрібними властивостями, а потім ми просто копіюємо один із екземплярів, коли нашій будівельній компанії потрібно збудувати якийсь конкретний будинок десь в місті. Іншими словами ми можемо обійтися від написання подібного: "new ApBlockWith9FloorsAnd234Flats()" або "new ApartmentBlock(){Floors = 9; FlatsDic = {2,3,4}}".

Все чого нам буде достатньо є щось схоже на "_9FloorsApBlock.Clone()". Звичайно ми можемо поєднювати цей патерн із Фабричним Методом, таким чином ми будемо мати метод схожий на "GetMe9FloorsAppBlock()", який всередині буде викликати копіювання прототипічного екземпляру.

Приклад

Нумо глянемо на Прототип (Prototype), що визначає метод Сlone() для всіх наших конкретних прототипчиків.

    public class CalendarPrototype
    {
        public virtual CalendarPrototype Clone()
        {
            var copyOfPrototype = (CalendarPrototype)this.MemberwiseClone();
            return copyOfPrototype;
        }
    }

Нашим конкретним Прототипом є подія в календарі, яка виглядає приблизно так:

    public class CalendarEvent : CalendarPrototype
    {
        public Attendee[] Attendees { get; set; }
        public Priority Priority { get; set; }
        public DateTime StartDateAndTime { get; set; }
        // покищо ми не перевизначаємо метод копіювання
    }

Клієнтський код (Client code) виконується коли ваш друг відкриває календар і правою кнопкою мишки копіює подію, а потім вставляє в інше місце, таким чином автоматично помінявши дату та час початку події.

Глянемо на цей процес:

    public class PrototypeDemo
    {
        public static CalendarEvent GetExistingEvent()
        {
            var beerParty = new CalendarEvent();
            var friends = new Attendee[1];
            var andriy = new Attendee {FirstName = "Andriy", LastName = "Buday"};
            friends[0] = andriy;
            beerParty.Attendees = friends;
            beerParty.StartDateAndTime = new DateTime(2010, 7, 23, 19, 0, 0);
            beerParty.Priority = Priority.High();

            return beerParty;
        }

        public static void Run()
        {

            var beerParty = GetExistingEvent();
            var nextFridayEvent = (CalendarEvent)beerParty.Clone();
            nextFridayEvent.StartDateAndTime = new DateTime(2010, 7, 30, 19, 0, 0);

            // про цей код побалакаємо трішки нижче
            nextFridayEvent.Attendees[0].EmailAddress = "andriybuday@liamg.com";
            nextFridayEvent.Priority.SetPriorityValue(0);

            if (beerParty.Attendees != nextFridayEvent.Attendees)
            {
                Console.WriteLine("GOOD: Each event has own list of attendees.");
            }
            if (beerParty.Attendees[0].EmailAddress == nextFridayEvent.Attendees[0].EmailAddress)
            {
                //В цьому випадку є добре мати поверхневу копію кожного із учасників
                //таким чином моя адреса, ім'я і персональні дані залишаються тими ж
                Console.WriteLine("GOOD: If I updated my e-mail address it will be updated in all events.");
            }
            if (beerParty.Priority.IsHigh() != nextFridayEvent.Priority.IsHigh())
            {
                Console.WriteLine("GOOD: Each event should have own priority object, fully-copied.");
            }
        }
    }

Як можна бачити мій друг зробив копію існуючої події і за допомогою чудо функціоналу drag-drop змінив дату події. Оскільки я сидів із нашим другом, я помітив що я можу змінити свою адресу через цю подію, тому я її поміняв на нову, оскільки вона у мене змінилася. Також оскільки багато кому було погано після вечірки, то ми вирішини що наступного разу не будемо брати аж так багато пива, але оскільки пива не дуже багато, то й пріорітет не може бути сильно великим:

nextFridayEvent.Priority.SetPriorityValue(0)

На перший погляд виглядає, що ми отримали те що хотіли - копію існуючої події із запрошеними, приорітетом та іншими властивостями. Але коли я відкриваю стару подію я помітив що приорітет став нейтральним замість того, щоб бути високим. Як? Причина у тому, що оскільки ми ще не перевизначали метод Clone для нашого прототипу була виконане поверхневе копіювання (MemberwiseClone) зазначене у базовому класі.

Поверхневе копіювання (Shallow copy) копіює тільки прямі поля класу, таким чином залишає ті ж посилання, якщо поле було reference типу, а якщо поле було value-типу, що буде нова копія.

Глибоке копіювання (Deep copy) копіює ціле дерево об'єктів, таким чином що об'єкти мають різні фізичні адреси у купі (heap).

Метод CLONE

Для нашого прототипу ми можемо реалізувати Clone() так як нам заманеться, таким чином я можу реалізувати частково глибоке копіювання. Навіщо це потрібно? Ну я б не хотів щоб моя адреса або інші персональні дані були різними для різних подій, але в той час я хочу бути певним що коли я зробив копію події і змінив приорітет, то він буде поміняний тільки для цієї події.

В дизнай патерні Прототип ми реалізуємо метод Clone. Інколи нам може знадобитися повна глибока копія, яку ми можемо досягнути шляхом ручного копіювання, що може бути складним, за допомогою рефлекшину, що може бути повільно, або за допомогою сериліазації та дисериалізації в новий екземпляр об'єкту, що також може бути досить дорого. Але часто вам може знадобитися часково повне копіювання, як у нашому прикладі. Ось чому багато мов програмування добавили інтерфейс Cloneable, що має бути реалізований вами самостійно. Найбільш підходяща реалізація для нашого прикладу може виглядати так:

      public override CalendarPrototype Clone()
        {
            var copy = (CalendarEvent)base.Clone();

            // this allows us have another list, but same attendees there
            var copiedAttendees = (Attendee[])Attendees.Clone();
            copy.Attendees = copiedAttendees;

            // we also would like to copy priority
            copy.Priority = (Priority)Priority.Clone();

            return copy;
        }

Консольний вивід сказав що все зроблено згідно плану. Оскільки я також маю той же приклад на джаві і в дебаг моді IDEA відображає змінні із однозначними ідентифікаторами посилань (числа після "собачок"), то я ще добавляю скріншот:

Надіюся, що цей короткий опис дизайн патерну не був нудний, тупий і так далі.

Моя табличка Патернів

Lviv .Net User Group #7: "На новом месте..."

2010-10-15T11:42:00.002+03:00

Всем привет,

Вот и прошло две недели с последней встречи! И вот новая! Встреча номер 7 пройдет в новом месте, а именно в офисе компании GlobalLogic!

Встреча пройдет 29 октября, по адресу: ул. Шептицьких 26, в 19:30.

Агенда:

1. Игорь Рациборинский: "Getting Scrum". Наш гость из Киева, ПМ с многолетним стажем.
2. Андрей Будай:"DDD". Один из самых активных участников нашего сообщества, ведущий рубрику "Паттерн Вторника".
Ну и конечно же подарки и афтерпати!

Так же, вы можете внести дату проведения ивента в свой гугл кадендарь. Надо только присмотреться к правой стороне нашего блога:)

Госопода, имена и фамилии будут поданы охране GlobalLogic, чтобы они знали кого пропускать, потому регистрация обязательна!

Регистрация ТУТ!

С уважением,
- Дима.