Загалом зустріч була дуже хороша. Але якось всерівно хочеться більше бачити більше коду. Бо наприклад коли розказується про Monitor.Enter() ну то не ясно що наспраді сталася така зміна: Monitor.Enter(obj); ==> Monitor.Enter(obj, ref someBooleanCrap); На словах воно ніби ясно, але добре б ще бачити наочно. Те саме може стосуватися і інших речей. А відносно тайм менеджменту то презентація також була хороша. Рома, де лінк на ту тулзу? 🙂
p/s На blogspot можна зробити простеньке опитування відносно натупної теми…
Діма, думаю і на твою тему міг би подискутувати, але спізнився 🙂 Зустріч сподобалась, зібралась дуже класна компанія людей, які прагнуть до спілкування та саморозвитку. Можу щось по mono розповісти, тре подумати 🙂
Andriy Buday правду каже про код, було не зрозуміло,які параметри на вхід,що на вихід. Слайди мають бути трохи більш інформативні.
Afterparty рулить 🙂
P.S. Якщо мене не підвів зір то, в прозі зі штатами бага 🙂 Коли результат через plinq був гірший за linq воно, всеодно показало приріст перформансу 🙂
А насчет опроса – зрите в корень:) Если бы у нас было несколько человек, которые готовы сделать доклад, то можно было бы вертеть носом, так как в основном сейчас доклады делают организаторы группы – то тема докладов выбирается ними.
Как я уже несколько раз говорил – развитие группы , в руках участников группы!
Всім привіт! Сьогодні з Дімою зранку пили чай і обмінювались враженнями – скажу від обох підтвердивши Дімині слова: Супер, третя зустріч була просто бомбезна! Приєднуйтесь, не забувайте про зустріч, висловлюйте свої рекомендації і побажання для покращення роботи групи!
Враження позитивні, особливо тому що я почув доповідь на тему яка мене дуже цікавила. Хоча, мабуть, не усі такі зацікавленні у fine-grained concurrency технологіях; людей прийшло десь у 2 рази менше, та й питань практично не було. Мабуть, зміню свій підхід та буду менше питати після виступу, зате більше при очній ставці 1-на-1 під час поглинання різних ласощів – так буде ефективніше і людей не буде напрягати. Щодо коду – не згідний. При нормальному поданні матеріалу код непотрібен, скоріше заважає сприймати головні тези. Можна, звісно, кілька лінійок показати у слайдах презентації. Але усі мають достатній рівень досвіду та знань щоб сприймати інформацію на льоту та правильно її інтерпретувати. На мою думку використання whiteboard із вдалими малюнками помагає більше. У будь-якому випадку багато дуже залежить від вміння доповідача продати себе. Усім дякую за вдало проведений час. PS. Рома – молодець. Цікава, проста та вдало подана доповідь.
Зустріч таки була цікава, і як на мене обидві презентації були на рівні. Хоча для мене особисто друга обірвалась якось нежданно-негадано… За презентації презентуючим – дякую! Також абсолютно не згідний на рахунок "більше коду в презентації". Таке враження, що люди збираються завчити той код:) Для огляду вистачає лінійки 2-х – зрозуміти суть, область застосування, тренд. Всі решта деталі, як треба буде, вспливуть самі собою. Зрештою для цього прототипи й призначені 😉 PS: і за подарунки також дяк!:)
vHalitsyn, ну можеш думати, що я хочу "завчати код", але я всерівно хочу його бачити. Багато відомих спікерів взагалі не юзають слайди. Напр. http://www.hanselman.com/ Ну хоча більшість таки юзає. Основне донести думку до слухачів. Те, що були демки радує.
2Andriy Buday: nothing personal. Але дякую за дозвіл 😉 Я цілком розумію коли код присутній – більше того часто сам волів би побачити пару лінійок(правда таке трапляєцця все рідше і рідше):)
Олександр, нею було б добре скористатися. Але як на мене питання у розвитку .NET UG y Львові не стоїть за площаткою на якій розгортати групу. Воно швидше залежить від кількості активних людей які "встоять" (я думаю ви розумієте, про що я говорю).
Ми, учасники групи, будемо раді сконтактувати із вами і поговорити про розвиток юзер групи у Львові. Покищо приходіть і захопіть своїх друзів.
Якщо хтось ще має якісь ідеї, не встидайтеся пишіть 🙂
Площадка http://www.lvivcommunity.net уже в летаргическом сне более 2-х лет. + Она с самого начала была направлена на ПР компании ArtfulBits, Мы же, хотим создать независимое сообщество, где разработчики могут пообщаться и узнать что нибудь новое. Сейчас, нас поддерживает компания SoftServe ( место и хардвар), только потому, что Я там работаю, и так исторически сложилось что договорится там легче всего, остальным компаниям пока(я надеюсь:) ) это неинтересно.
Привіт! Отримав фантастичний стимул вивчити щось нове 🙂
Сподобалося демонстрація на "живому" коді, який не був просто копі-пастнутий звідкість, а написаний при всіх (лоффкость рук и никкакофо мошенничества) :). Велике спасибі за це.
Стосовно що ще хотілося б.. я гадаю більше переваг перед альтернативними рішеннями… Дуже вірю, що нХібернейт кльова штука, але бачу в ньому дуже сильно LINQ 🙂 .. загалом, то важко осягнути всю МОЩ цієї техгології з одно-годинної презентації… спробуєм її в житті, і сподіваюся, що не пошкодуємо..
yoursen, дуже дякую за коментар. Насправді я дуже старався зробити гарну презентацію. Ті всі "мексиканські серіали" про Nhibernate… і пару погано проспаних ночей.
Доречі, ви можете бути наступним доповідачем на тему Linq to SQL.
Було цікаво, особливо тому що я деякий час працював з ентіті фреймворком, а про нгібернет лише чув, і міг порівняти дві технології, як на мене ентітіфреймворк рулить )) між іншим де мона взяти такий рюкзачок(VS2010)??
Буду відвертим, ця рубрика мені не подобається. Я думаю що якщо люди слухають подкасти, то вони знають коли щось нове приходить за допомогою гугл рідера або ще чогось.
До речі, ще про потоки і Сінглтон. Знайомого на співбесіді питали як код з прикладу може створити 2 інстанси класу. Така ситуація можлива коли сінглтон ще не створений і декілька конкуруючих потоків доступаються до нього. Тоді поки перший потік створює об'єкт, другий встигає пройти перевірку на null і почати створювати другий інстанс. Щоб це обійти потрібно просто залокати перевірку і створення інстансу класу Сінглтону.
Ага, доречі на моєму блозі вже є декілька патернів описаних подібним або околоподібним стилем, але чомусь ніхто їх так високо не оцінює як ви, за винятком декількох друзів. (Може просто ніхто не читав ще 🙂 )
Дмитро, щоб зберегти той самий контракт. (Я це був вказав "Для того щоб зберегти контракт базового класу Car, і щоб мати базовий клас для всіх інших "прибамбасних" функціональностей створимо DecoratorCar, що так само наслідується від Car")
Ну може краще для прикладу було написати ICar тоді було б чіткіше ясно що то контракт.
Хто добереться до коментарів, я б хотів, щоб дав відповідь на таке питання: Чи є клас UnitImagesFactory якимось із факторі дизайн патернів із книжки GoF? Аргументи в додачу буде дуже добре.
нажаль цієї книги не читав, як на мене то цей класс схожий на реалізацію звичайного фекторі ) надіюсь на коментарі інших юзерів групи а якщо їх не буде то на відповідь автора.
пс. таке враження що щастина тексту перекладена гуглом, а то якось читати важко і опечаток трохи є..
ее… я не використовував гугл транслейт. Я перекладав вночі, тому може й багато описок. Знову ж таки питання: чи нормальний стиль у якому той патерн описаний? Я можу попробувати зробити його більш офіційним.
як на мене стиль нормальний, так тримати. Більш офіційно можна описати наступний патерн, побачимо що скажуть користувачі.
Сьогодні говорив з знайомим на рахунок патернів і корисності їх використання, все зводилось до того що патерни вивчити це добре але розумно їх використовувати не завжди получається, тому хотілось би десь почитати про саме проектування, застосування на реальному проекті і тд.
В нас на проекті деякий набір GoF дизайн патернів таки використовується, але дійсно їх багато не запхаєш. А якщо таки запхаєш, то потім із тим кодом дуже фігово розбиратися.
Може порадиш що почитати, думаю такі речі не тільки мене цікавлять… Зараз почав читати "Применение DDD и шаблонов проектирования". Думаю час від часу робити міні звіт в блог по ній, хотя не факт що дочитаю бо я так зрозумів що вони розрахована на трохи вищий рівень ніж зараз у мене.
Класний паттерн. Один з моїх улюблених. І написано доступно, тільки мені здається що на UML діаграмі скорше зображений брідж ніж декоратор. Також на мою думку якщо потрібний лише один декоратор то можна обійтися без базового класу (CarDecorator) і реалізувати зразу ж (AmbulanceCar).
На рахунок докладу "эффективные методы визуализации информации" – мене трошки скоф'юзило.. я очікував почути які існують методи візуалізації, та для якої інформації найкраще використувувати ті чи інші методи (розглянути багато типів діаграм, ітд.)… Це питання було розкрите, як на мене не повністю, тим не менше доклад був дуже цікавим і корисним.. Доклад Рустама – професійний. Дійсно важка тема, яка розкривалася досить глибоко без "водички", потребує осмислення.. Навіть не було питань, які можна задати… Для таких штук необхідно приходити на ком'юніті підготовлений, прочитавши хочаб декілька статей по розкритій темі. Так можна краще зрозуміти і "намотати на вус" викладений матеріал!! 😉
Мне понравились оба доклада. Для меня термин DataInk откровение, люблю минимализм несущий только информацию. По SaaS Сергей очень класно расказал, и подробно и долго 🙂 Я честно забыл вопросы что появились в начале. Жду ссылок на литературку по SaaS Спасибо.
Дійсно розказав усе структуровано. Для всього були чіткі пояснення і прикольні картинки для побудови асоціацій у наших мозгах 🙂 То що у кінці було показано як воно усе мапається на щось реальне варто похвали. Круто!
Нажаль я ще відчуваю якийсь дискомфорт, що багато чого таки ще не розумію. Мені напевно бракує розуміння того як таку архітектуру "конячу" можна розгортати у клієнтів.
Так це Factory Method. Я хотів бути певним, що ніхто не буде казати що це не той патерн, плутаючи його із параметризованим фекторі методом. Також є така штука як CreateMethod, але вона створює об'єкти зазвичай свого класу і практично завжди є статичними методами.
Можна було обійтися тільки із одним декоратором. А на UML таки не брідж зображений, але певно ще бракує стрілки, щоб зобразити, що CarDecorator також наслідується від Car.
А я завжди писав свій аналог для string.IsNullOrWhiteSpace() для перевірки аргументів, адже у більшості випадків рядок з пробілами настільки ж "поганий", як і порожній. Стара топкодерівська звичка:)
>>Але ще одне питання: чи взагалі вам подобається такий синтаксис? Можна закинути всі специфікації у масив і додати тут вкладений цикл. При додаванні нової специфікації просто буде плюс один елемент до масиву. Так можливо нічим не краще, але я б так робив:)
Дякую! як на мене подарунки досить цінні і дивно що так мало людей відгукнулось, адже написати маленьку програму жарт чи щось таке не так вже й важко тому надіюсь на наступний рік конкуренція буде більша і подарунки теж)
PS в моїй програмі використано 64 (!) вікна, на наступний рік мабуть буде 256 ) Всіх з Днем Програміста!
А чому це недолік? З приватними полями і методами працювати не потрібно. Вони тільки для класу. Я б сказав що це теж перевага. ))))
Наприклад ми можемо мати методи CalcTax() – публічний і CalcFullTax() приватний. CalcTax() може викликати CalcFullTax() для "проміжних" розрахунків. Але податківець зможе викликати тільки CalcTax(), що безумовно є перевагою )))
Добре, я згоден. Може я й помилився тут. Я дивився трішки із іншої сторони. Тобто при наслідуванні, яке часто використовується у патернах ми можемо працювати із протектед полями і так далі. Тобто мається на увазі, що може нам треба буде алгоритм, який враховує щось дуже "захайдене" у тому класі.
Якщо інші згодяться із твоїм коментарем, тоді я це перемішу у "переваги" і напишу що я мало думаю 🙂
Це взагалі недолік патерна Відвідувач, класичний: порушення інкапсуляції, так як інтерфейс Елемента має бути досить розвинений для того, щоб Відвідувач зміг виконати свою роботу
Так, щось у тому є. Але із іншої сторони ми всерівно оперуємо тільки паблік властивостамя. Проблема у тому що коли ми будемо писати патерн Відвідувач, ми певно будемо підганяти трішки код під ньго і тоді отримаєму проблему згадану у коменті вище.
Андрію, якщо слідувати теорії сучасної шаблонної розробки (наприклад такої "нудної" штуки як "легка звязаність"), то в принципі "підганяти під патерн Відвідувач" ми взагалі не мали б – практично він повинен використовувати той функціонал який ми йому надали. Тобто наприклад, якщо це електрик, то "Кімната" надає йому тільки відомості про кількість і розташуванн лампочок, тип проводки, метод "ВимірятиСтрумВРозетці" (і т.д. – основні моменти в вас так і описані), а вже він сам ("Електрик") повинен виконати їх обробку (ну тобто тут як ви писали – певним чином відділяється алгоритм тестування електропроводки, але тільки в межах обробки результатів і виведення висновку "дядею Васею-Електріком"). Якщо щось недопоняв – зразу вибачаюсь:)
Андрій, все правильно, так б мало бути. Але як згадано у коментарі від Геннадія, "інтерфейс Елемента має бути досить розвинений". Якщо я правильно розумію Геннадія, то він має на увазі, що коли "Кімната" назовні показує кожну лампочку це дещо порушує інкапсуляцію. Думаю електрику буде мало знати скільки лампочок і де вони є, він захоче на неї подивитися. І ніхто не каже, що інший відвідувач не захоче ще на щось подивитися.
Але взагалі правильно. Все має бути "легко зв'язано".
Знову ж, слабка зв’язність це, звісно, добре, але… Не завжди вона має таке велике значення, і паттерн Відвідувач мабуть один з таких прикладів, адже Відвідувач створенний для використання САМЕ з цією структурою елементів, і ні для якої іншої, він не призначений для повторного використання, а тому залежність від конкретних особливостей реалізації єлементів на мою думку не має таких критичних наслідків. Гадаю, що шкідливим може бути використання тієї частини відкритого інтерфейсу ( що призначений винятково для використання Відвідувачем для реалізації своїх обов’язків, можливо методу "ВимірятиСтрумВРозетці"), іншими классами-Невідвідувачами (які мабуть також забажають використати зручний для них метод "ВимірятиСтрумВРозетці") тут виправдати посилення зв’язності вже складно. Наскільки я розумію, в С++ можливо було вирішити цю проблему за допомогою friend-класів, але в С# – для мене це поки що загадка. А про інкапсуляцію… Так і інкапсуляцію можна порушувати по різному 🙂 Можна все ж таки спробувати абстрагуватися від того, чи зберігає Поверх Лампочки у хеш-таблиці, масиві чи зв’язному списку
Андрію, Геннадій так думав щойно – наче виникає 2 досить сумнівні пролеми – це місце зберігання алгоритму тестування і його розгалуженість (тобто варіанти "логіка в елементі". "логіка в відвідувачі", "логіка і там і там". Мені подобається 3 варіант – тобто Кімната надає інформацію що необхідна для отримання висновків (але вона про це не знає), а вже сам Відвідувач (і лише він для певного набору атрибутів) несе логіку їх обробки. На рахунок інших відвідувачів – вони в принципі теж можуть "ДивтисьНаЛампочку" і "МірятиСтрумВРозетці" – але це їм нічого не дасть якщо вони не реалізують певної логіки досягнення висновку (а якщо реалізують то вони стають електриками:) ).
А про абстрагування – тут до структур даних взагалі не варто привязуватись:) Патерни то швидше філософія в першу чергу 😉
Було досить цыкаво, особливо послухати про MVC 3, вже з нетерпынням чекаю його повного виходу 🙂 В цілому класно, бо взяв для себе багато інформації про тенденції розвитку технологій Microsoft, бо в інформації з інтернету деколи таке понаходиш що аж страшно стає 😀
в большинстве случаев (в реальной жизни) Builder используется "для упрощения конструирования сложных объектов" (it allows to hide construction complexity behind a convenient interface). Рекомендую обращать больше внимания на секцию Consequences в описаниях паттернов. Как показывает опыт – она ниболее полезная из всех
А можно использовать LINQ и вообще обойтись без кастомных експрешенов. Семантика спецификации сохраняется в названии класса спецификации, реализация использует LINQ. Плюс можно реализовать чейнинг спецификаций – с LINQ это тоже просто
Обратите внимание на отличный FSM кит для .NET. Stateless – http://code.google.com/p/stateless/ . Намного проще (и прозрачнее) конфигурируется и работает. И каши (в виде большого количества подклассов) не просит 🙂
уххх, было круто:) очень порадовало что пришло много людей, хотелось бы извиниться за то , что не всем хватило места. В следующий раз мы предусмотрим такую вероятность.
В этот раз выступление вел Макс, который с этим справился на все 100% – так что – МОЛОДЕЦ!
Про доклады – все было действительно круто: Игорь показал что такое воркшоп, Андрей завалил всех полезной информацией.
К сожалению не остался на афтерафтерпати, в следющий раз исправляюсь:)
Дуже сподобався воркшоп! Сам формат був дуже класний, наочний. Одне тільки зауваження. Певно варто було поділити одразу питання на беклог і спринт беклог.. зразу ж зрозуміло було, що на все відповісти часу не вистачить.. заодно ідею беклогу пояснили б 🙂
Встреча была супер! 🙂 Жаль что помещение было маловато, и нам не удалось разбить людей на нормальные команды (blood mess!!!) но ребята заменеджели %) Андрей немного затянул с докладом, но и перебивать его не хотелось(DDD увлекательная тема), люди начали клевать носом, надо больше живых примеров
Хотя дійсно було видно що аудиторія втомилася. Багато інфи. Якщо я б ще приклади на кожен айтем показував то була б +1 година ще. От я наприклад показав живий приклад специфікації – зайняло певно 5 або більше хв.
Доповідь Андрія була оглядовою – тому і вийшло довго. Не скажу що мене втомило, проте деяка затягнутість відчувалась. Вечір п"ятниці мабуть дався взнаки.
>> І лінь шукати, може хто знає? Дія такого локу поширюється на весь AppDomain у який завантажено тип. Ситуація погіршується для domain-neutral типів таких як String.
да, Разор должен быть очень крут. То что не работает IntelliSence в принце ожидаемо, это таки превью, а не RC. Все будет, надо только подождать)
по поводу хелпера/твиттера – неужели стиль нельзя настроить в CSS. Не верится, что единственная настройка, через код.. Надо глянуть на полученный div в FireBug, думаю много станет понятней!)
Багато місця, цікаві доклади, причому нам пощастило послухати Дімін доклад, якій він буде доповідати на http://www.msswit.in.ua/ ,а це ван нє діцкій утрєнік 🙂 Дуже сподобався подарунок, цеж ліцензійна вінда! Народ, цеж купа грошей! 🙂 Буду готувати доповідь та боротись за приз в конкурсі на найкращу доповідь квартала (3 зустрічі)
Як завжди цікавий приклад. Було б непогано доповнити статтю інформацією про Obsarvable Collection, IObserver, IObservable – тим що вже присутнє у .Net-і.
Доволі практичний патерн, думаю при обробці подій дозволяє уникнути багатьох "костилів". Та й архітектура в цілому виглядає досить гнучкою і компактною водночас.
Так, патерн дуже практичний. Мій друг на ньому побудував бота, який хендлить ходи і в залежності від поточних умов хендлер передає обробку наступному у ланцюжку, який вже спеціальну логіку добавляє.
Дуже дякую за коментар. Я думаю що всякі такі речі як ObservableCollection і інше вже вбудоване у можу можна буде подописувати у книгу, але просто вагаюся чи то не буде зайвим.
Все залежить на кого орієнтована книга, якщо виключно на .NET розробників то було б непогано мати інформацію про готові реалізації патернів, але якщо для більшого загалу – то ця інформація може виявитись зайвою.
Гарний приклад для пояснення. Було приємно читати. Описану задачку можно вирішити ще використовуючи більш простіший паттерн – Фабричний метод (Factory Method).
Фабричний метод повертає конкретну реалізацію тільки для одного класу. Тому якщо нам був б потрібен кіт (а не ціле сімейство іграшок) можна було б використовувати фабричний метод.
Також якщо говорити про параметризований фабричний метод, то можна було б мати методи
>> Така реалізація, м'яко кажучи, не є прикладом >> гарного дизайну для задоної задачі.
Так switch, та константи "wooden або teddy або інший тип" будуть. Але це вже нюанси та плюси і мінуси (мінуси в даному випадку) використання кожного з них.
Обидва патерни і абстрактна фабрика і фабричний метод створюють об'єкти. Просто різними способами.
Абстрактна фабрика робить – це через наслідування, фабричний метод – через композицію. Що краще вирішувати від ситуації.
З іншого боку, наприклад якщо необхідно додати нову іграшку то з абстрактною фабрикою доведеться розширити інтерфейс, і тоді доведеться змінювати(доповнювати) всі його імплементації.
І насправді можна обійтись і без switch. Фактично, він буде необхідний якщо використовувати параметризований фабричний метод – тобто передаємо константу або enum і в switch вирішуємо який клас створювати.
Інший варіант – це не параметризований фабричний метод а утворений шляхом наслідування від базового класу. Це вже більш нагадує абстрактну фабрику, але за винятком того що створюється один продукт, а не сімейство. Фактично якщо розглядати методи GetBear і GetCat окремо або виокремити їх в окремий клас – це будуть фабричні методи.
Що ще турбує, так це використання hardcoded рядків на кшталт IToyFactory toyFactory = new WoodenToysFactory(); – це аналогічно використанню констант, оскільки всюди у коді буде прив’язка до конкретного екземпляру і існує бажання винести частину «new WoodenToysFactory()», хоча констант тоді (DI/IoС як приклад) не уникнути, але вони будуть лише в одному місці коду.
І ще один аспект. Для того щоб створювати нові і нові конкретні продукти доведеться створювати нові реалізації інтерфейсу абстрактної фабрики. Тут на допомогу можуть прийти дженеріки (generic). І кількість реалізацій дуже суттєво зменшитися.
І ще як момент. Тут можна заюзати ще і прототип. Оскільки створювані іграшки відрізняються лише типом – плюшева або дерев’яна. Тому можна клонувати об’єкти і задавати потрібний тип новим об’єктам
Так как я сейчас больше в космосе летаю , но вот увдиел спор фабричный метод , против абстрактной фабрики:
Сейчас вот читаю Apllication Architecture Guide, и там кстати заметил интересную штуку, в секции design practices: prefere composition to inheritance:)
Та я знаю… просто я хочу малювати свої, а на них завжди часу не стає. Дякую. Ще лишилося 3 GoF патерни, думаю що для них таки намалюю, щоб був фул-хаус.
блін, шо ж мене в цей Маврикій занемло? так би кінект і він фон поюзав… але все рівно був радий вас всіх бачити, принаймні через відео чат 🙂
Олег – реально корисна інфа, поділився досвідом, який безцінний. Сподіваюсь послухати тебе в живу через декілька місяців 🙂
Юра – не можу особливо відзначити контент, бо я не бачив ні слайдів, ні демо, але можу сказати, що не зважаючи на те, що я засинав (в мене вже було 12 ночі) все рівно було цікаво слухати. Молодець!
Погоджуюся із всім вищенаписаним. Дійсно було багато нової та цікавої інформації. Розчарував інтерес людей до Віндовс фона. Сподіваюсь, що то через конкурента у вигляді кінекта, а не через байдужість до нової платформи.
Вперше прийшов на зустріч, але собі вирішив, що прийматиму участь і в подальших зібраннях, бо попри те, що я не зовсім девелопер і в напів-.NET тімі, багато для себе почерпнув.
Презентатори викладали свої теми дуже цікаво, чим я пнриємно вражений. Аж до того, що трохи пошкодував про обмежені часові рамки, і що зустріч відбувається ввечері буднього дня.
Ага, і після того, як добряче пострибав граючи в kinect в мене на вечір заколо в боці, а отже я ще й добряче порухався.
Насправді дуже "забойна" зустріч вийшла. Чесно кажучи я не очікував що почую стільки цікавого за один вечір.
Олег дав таку обширну інформацію по Mobile технологіям, що мало явно не показалося. І я ще ніколи не чув стільки про blackberry. Взагалі суперськи! Дуже тобі дякую!
Юра! Про WinPhone 7 ти точно краще розказував ніж "типу MVP" Лутай. ;)… Правда у нього вроді із ноутом пошвидше вийшло.
>> Юра Опришко В вашій презентації сказано, що "сервіси" WP7 (marketplace, accounts) будуть доступні з другого півріччя. Можна дізнатись на які джерела опирались?
В системе AutoCAD, есть такая штриховка с названием SOLID – она заливает замкнутый контур цельным цветом, без узоров.
По теме. Очень информативная и доступная статья – для программистов начального уровня. Все это и остальные детали, которые здесь не затронуты, можно узнать прочитав книжку о паттернах проектирования.
теорія це добре, але якщо перейти до практики…то Ви не зможете зареєструватись для використання Ажур…України в списку країн для реєстрація нема (Росії також)…
Я так розумію, що Ви один мій коментар до першої статті назвали "многие начали кричать" 🙂 Ну це я так написав, до слова…просто прикро, що Україна знову серед африканських країн і що ми розглядаємось лише як джерело дешевої девелоперської сили. На рахунок Ажур, то так…можна нормально девелопити локально. Що і робимо 🙂
України і Росії в списку нема…… Бояться наших "умільців". Літра пива і умілий шорох кнопок під руками українського хакєра Васі Чайникова і Only my application runs on the same infrastructure that Microsoft used moment ago to host their services, Microsoft Services is no more here!
Було всьо супер. Тільки один коментар/побажання, досить цікаво послухати не тільки про технології, але й про реальні проекти, можна загалом, з якими проблеми стикались, які технології використовувались ітд. Не знаю чи таке пожливе через NDA ітд, але думаю було б дуже цікаво послухати багатьом.
Цікаво чи СофтСерв міг б хотя би декілька проектів привідкрити і поділитись досвідом.
CофтСерв згадувався у конексті прикладу 🙂 Просто людині(архітектору чи сеньйору), щоб поділитись інфою треба відповідно дозвіл з сторони компанії/заказчика.
Діма, а для клієнтів ти теж так подаєш інформацію? 🙂 Я думаю що вони просто офігівають із того наскільки їх розуміють тут. А на другий день біжать підписувати контракт із СофтСервом.
Нажаль в мене веб досвіду мало, щоб перейнятися болючістю питань піднятих у другій доповіді, але було дійсно видно як інші люди уважно слухали цю доповідь.
p/s Дякуючи Софтсерву я отримав всоє N-не брендове горнятко.
Дякую організаторам. Я був вперше, але мені сподобалось. Дякую за доповіді по креативності і, особливо, по Symfony2. Знаю, що для багатьох друга доповідь була не зрозумілою, бо навіть мені (працюю з Symfony2 вже кілька місяців) було важко встигати за Сергієм, але тим не менше я дізнався багато цікавого і нового. Піцца і пиво були дуже доречними) Шкода, що не було достойних противників по Тейкену 😉 Тренуйтесь
А коли наступна зустріч?
28 апреля
10x
А про теми доповідей якісь натяки є?
Анонс будет!
Live news from Lviv .Net Community 2nd meeting at http://twitter.com/#search?q=%23lvivdotnet !
Follow us!
Yura Opryshko talks about developing Silverlight apps for Win7 http://twitpic.com/1j3ge7
А где можно посмотреть доклад про SharePoint 2010 с воодушевлением =) ?
Video poka processitsja, kak tol'ko bydet – srazy ge vulogy v nete i dam linki:)
Автор видалив цей коментар.
Лого супер, а от хідер ацтой)))
К счастью организаторы не дизайнеры:) Над хидером думать нет смысла, мы все решаемся переехать на отдельный сайт, но пока руки не дошли:)
А відео з презентацій буде? Особливо цікавить по "24000 Days Of UX" 🙂
видео будет:) только неизвестно когда. процессить видео – это не шубу в трусы запихивать:)
Автор видалив цей коментар.
Було б класно, щоб до презентації "24000 Days Of UX" були додані ті відео(вступне та наступні), які супроводжували презентацію 🙂
К сожалению слайдшара не поддерживает:)
blin, porpavte moje imja pid presentahoju!!!
Vasya a ny Vysia blin
Сделанно:) Сорри
Привіт.
Загалом зустріч була дуже хороша. Але якось всерівно хочеться більше бачити більше коду. Бо наприклад коли розказується про Monitor.Enter() ну то не ясно що наспраді сталася така зміна:
Monitor.Enter(obj); ==> Monitor.Enter(obj, ref someBooleanCrap); На словах воно ніби ясно, але добре б ще бачити наочно. Те саме може стосуватися і інших речей. А відносно тайм менеджменту то презентація також була хороша. Рома, де лінк на ту тулзу? 🙂
p/s На blogspot можна зробити простеньке опитування відносно натупної теми…
Діма, думаю і на твою тему міг би подискутувати, але спізнився 🙂
Зустріч сподобалась, зібралась дуже класна компанія людей, які прагнуть до спілкування та саморозвитку. Можу щось по mono розповісти, тре подумати 🙂
Andriy Buday правду каже про код, було не зрозуміло,які параметри на вхід,що на вихід.
Слайди мають бути трохи більш інформативні.
Afterparty рулить 🙂
P.S.
Якщо мене не підвів зір то, в прозі зі штатами бага 🙂 Коли результат через plinq був гірший за linq воно, всеодно показало приріст перформансу 🙂
Ггггг… Max, вони просто лінувалися кольори міняти. Приросту не було, але колір зелений для plinq всерівно залишився.
Макс, Андрей правду говорит – цвет таки не поменялся, но прироста небыло, было уменьшение перформанса.
Насчет кода – это да. Но его немного тяжело показывать, ибо проектор. Хотя, будем думать:)
Блін, а було ж відчуття вчора, що щось забув 🙁 тепер зрозумів – про зустріч забув.
А насчет опроса – зрите в корень:) Если бы у нас было несколько человек, которые готовы сделать доклад, то можно было бы вертеть носом, так как в основном сейчас доклады делают организаторы группы – то тема докладов выбирается ними.
Как я уже несколько раз говорил – развитие группы , в руках участников группы!
romgun
мы решили что будем высылать напоминания за 2 дня до встречи:)
Я думаю, що можу розказати про:
Managed Extensibility Framework
AutoMapper
NHibernate
Domain Driven Design
Ioc with StructureMap
Всім привіт!
Сьогодні з Дімою зранку пили чай і обмінювались враженнями – скажу від обох підтвердивши Дімині слова: Супер, третя зустріч була просто бомбезна! Приєднуйтесь, не забувайте про зустріч, висловлюйте свої рекомендації і побажання для покращення роботи групи!
Лінк на тулзу є в кінці презентахи. Дублюю: https://www.rescuetime.com/
Andriy Buday,
добався в скайп hmmdima, обговорим:)
А давайте дружити в скайпі! 🙂 свіжі фан-лінки і пізнавальна інфа гарантовано!
додавайте мене rkrayovskyy
і Діму hmmdima (Діма, ти ж не проти? 🙂 )
замутим групу і все як має бути…
шота я торможу чуток… ))
Враження позитивні, особливо тому що я почув доповідь на тему яка мене дуже цікавила. Хоча, мабуть, не усі такі зацікавленні у
fine-grained concurrency технологіях; людей прийшло десь у 2 рази менше, та й питань практично не було. Мабуть, зміню свій підхід та буду менше питати після виступу, зате більше при очній ставці 1-на-1 під час поглинання різних ласощів – так буде ефективніше і людей не буде напрягати.
Щодо коду – не згідний. При нормальному поданні матеріалу код непотрібен, скоріше заважає сприймати головні тези. Можна, звісно, кілька лінійок показати у слайдах презентації. Але усі мають достатній рівень досвіду та знань щоб сприймати інформацію на льоту та правильно її інтерпретувати. На мою думку використання whiteboard із вдалими малюнками помагає більше. У будь-якому випадку багато дуже залежить від вміння доповідача продати себе. Усім дякую за вдало проведений час.
PS. Рома – молодець. Цікава, проста та вдало подана доповідь.
>> А давайте дружити в скайпі!
І що сказав Діма?
Зустріч таки була цікава, і як на мене обидві презентації були на рівні. Хоча для мене особисто друга обірвалась якось нежданно-негадано… За презентації презентуючим – дякую! Також абсолютно не згідний на рахунок "більше коду в презентації". Таке враження, що люди збираються завчити той код:) Для огляду вистачає лінійки 2-х – зрозуміти суть, область застосування, тренд. Всі решта деталі, як треба буде, вспливуть самі собою. Зрештою для цього прототипи й призначені 😉
PS: і за подарунки також дяк!:)
vHalitsyn, ну можеш думати, що я хочу "завчати код", але я всерівно хочу його бачити. Багато відомих спікерів взагалі не юзають слайди. Напр. http://www.hanselman.com/ Ну хоча більшість таки юзає. Основне донести думку до слухачів.
Те, що були демки радує.
Andriy Buday, ну без слайдов – это круто, но в том то и разница – что у них опыта презентаций – очень много:)
Насчет кода – проблема есть, будем думать как решить.
Ещё раз говорю – стунки в скайп:)
2Andriy Buday: nothing personal. Але дякую за дозвіл 😉
Я цілком розумію коли код присутній – більше того часто сам волів би побачити пару лінійок(правда таке трапляєцця все рідше і рідше):)
Почему бы не воспользоваться готовой площадкой Lviv .Net Community – http://www.lvivcommunity.net
Олександр, нею було б добре скористатися. Але як на мене питання у розвитку .NET UG y Львові не стоїть за площаткою на якій розгортати групу. Воно швидше залежить від кількості активних людей які "встоять" (я думаю ви розумієте, про що я говорю).
Ми, учасники групи, будемо раді сконтактувати із вами і поговорити про розвиток юзер групи у Львові. Покищо приходіть і захопіть своїх друзів.
Якщо хтось ще має якісь ідеї, не встидайтеся пишіть 🙂
Олександр, Добрый День,
Площадка http://www.lvivcommunity.net уже в летаргическом сне более 2-х лет. + Она с самого начала была направлена на ПР компании ArtfulBits, Мы же, хотим создать независимое сообщество, где разработчики могут пообщаться и узнать что нибудь новое. Сейчас, нас поддерживает компания SoftServe ( место и хардвар), только потому, что Я там работаю, и так исторически сложилось что договорится там легче всего, остальным компаниям пока(я надеюсь:) ) это неинтересно.
Потому, Мы выбрали путь создания нечто нового.
С уважением,
-Дима
Да, Александр,
Огромное спасибо за пост в вашем коммьюинити:)
С уважением,
-Дима
That was amazing!
Хотілося б бачити коментарі про те як зустріч пройшла із вашої точки зору, чого бракувало, що було супер і т.д.
дада, что то в этот раз тихо как – то:)
Про свої враження я написав на своєму блозу у наступному пості:
http://andriybuday.blogspot.com/2010/07/lviv-net-user-group-my-presenation-on.html
Привіт! Отримав фантастичний стимул вивчити щось нове 🙂
Сподобалося демонстрація на "живому" коді, який не був просто копі-пастнутий звідкість, а написаний при всіх (лоффкость рук и никкакофо мошенничества) :). Велике спасибі за це.
Стосовно що ще хотілося б.. я гадаю більше переваг перед альтернативними рішеннями… Дуже вірю, що нХібернейт кльова штука, але бачу в ньому дуже сильно LINQ 🙂 .. загалом, то важко осягнути всю МОЩ цієї техгології з одно-годинної презентації… спробуєм її в житті, і сподіваюся, що не пошкодуємо..
До наступних зустрічей!
yoursen, дуже дякую за коментар. Насправді я дуже старався зробити гарну презентацію. Ті всі "мексиканські серіали" про Nhibernate… і пару погано проспаних ночей.
Доречі, ви можете бути наступним доповідачем на тему Linq to SQL.
Люди в кого ще які враження?!
а на коли планується зробити наступну доповідь?
Привет,
Думаю следующую встречу логичнее всего ожидать в конце августа:)
Встреча удалась, оба докладчика были на высоте 🙂 Афтерпати рулит 🙂
В следующий раз я буду без машины:)
Було цікаво, особливо тому що я деякий час працював з ентіті фреймворком, а про нгібернет лише чув, і міг порівняти дві технології, як на мене ентітіфреймворк рулить )) між іншим де мона взяти такий рюкзачок(VS2010)??
Bats,
Их осталось очень мало – на третьей встрече их получили все присутствовавшие:)
Обещаю, что возможность получить такие рюкзаки будет, но уже не так просто:)
Можна роздавати тим хто робить презентації чи щось таке…
Andriy Buday,
Банально:) Но часть из них так и раздадим скорее всего. Вернусь из отпуска и будем посмотреть – пока мозг в стенд бай режим:)
Доречі, якщо хтось хоче деріку особисто подякувати, то думаю що можна залишити коментар за наступним лінком:
http://devlicious.com/blogs/derik_whittaker/archive/2010/06/30/speaking-on-mef-at-the-l-viv-net-users-group.aspx
Я напевно б мав щось сказати…
Насправді дуже приємно, що використовуючи мій бренд люди шукали цей сайт.
Але, насправді, я думаю це через те, що я рекламував минулу зустріч поміж друзів, для того, щоб наша кількість була якомого більшою.
google / organic – пошук гугла
google.com / referral – це з гуглрідера, тощо
ідея хороша, а на інші дні теж будуть якісь плани? Пропоную наприклад один день виділити для статей/питань читачів блогу…
Привет:)
Думаю вопросов пока немного, и их можна задавать в любой теме или в скайп чате.
Насчет статей – я ж только за, и частенько про это всем говорю:) Так что – если у вас есть желание написать статью сюда – это только приветствуется!
Раджу змінити другий лінк на постійний http://www.hanselminutes.com/default.aspx?showID=243, коли пізніше хтось зайде на цб сторінку, то він вже буде не актуальний
Завдяки вінницькій дотнет групі наткнувся на цікаві книги
http://msug.vn.ua/blogs/romank/archive/2010/08/04/head-first.aspx
Рекомендую переглянути книгу по патернах 🙂
Буду відвертим, ця рубрика мені не подобається. Я думаю що якщо люди слухають подкасти, то вони знають коли щось нове приходить за допомогою гугл рідера або ще чогось.
До речі, ще про потоки і Сінглтон. Знайомого на співбесіді питали як код з прикладу може створити 2 інстанси класу. Така ситуація можлива коли сінглтон ще не створений і декілька конкуруючих потоків доступаються до нього. Тоді поки перший потік створює об'єкт, другий встигає пройти перевірку на null і почати створювати другий інстанс.
Щоб це обійти потрібно просто залокати перевірку і створення інстансу класу Сінглтону.
Надзвичайно просто та зрозуміло. Розжували все, залишилося лише ковтнути.. 🙂
Описав з фантазією, це плюс. "Сниться дікарю біпкалка" мене трохи поперло, думаю це чепятка ))
А так все гуд, коротко та зрозуміло, так тримати.
Ігор, дякую, я справив. Мабуть то чепятка тому, що я вже сонний добре був 🙂
Гарно написав, thx
Прошу, я стараюся 🙂
Ага, доречі на моєму блозі вже є декілька патернів описаних подібним або околоподібним стилем, але чомусь ніхто їх так високо не оцінює як ви, за винятком декількох друзів. (Може просто ніхто не читав ще 🙂 )
Я правда не зрозумів для чого DecoratorCar має бути нащадком Car. Хтось пояснить доступно?:)
Дмитро, щоб зберегти той самий контракт. (Я це був вказав "Для того щоб зберегти контракт базового класу Car, і щоб мати базовий клас для всіх інших "прибамбасних" функціональностей створимо DecoratorCar, що так само наслідується від Car")
Ну може краще для прикладу було написати ICar тоді було б чіткіше ясно що то контракт.
Чи ти із мене просто прикалуєшся? 🙂 Інакше б цей патерн не називався б враппер, якщо б він не мав тих самих методів, які він враппає.
Все-все, зрозумів…
Із такими темпами у нас скоро Балмер буде виступати 🙂
Хто добереться до коментарів, я б хотів, щоб дав відповідь на таке питання: Чи є клас UnitImagesFactory якимось із факторі дизайн патернів із книжки GoF? Аргументи в додачу буде дуже добре.
нажаль цієї книги не читав, як на мене то цей класс схожий на реалізацію звичайного фекторі ) надіюсь на коментарі інших юзерів групи а якщо їх не буде то на відповідь автора.
пс. таке враження що щастина тексту перекладена гуглом, а то якось читати важко і опечаток трохи є..
ее… я не використовував гугл транслейт. Я перекладав вночі, тому може й багато описок. Знову ж таки питання: чи нормальний стиль у якому той патерн описаний? Я можу попробувати зробити його більш офіційним.
Ну і крім того в оригінальній статті був дещо інший приклад. Тут я його змінив.
як на мене стиль нормальний, так тримати. Більш офіційно можна описати наступний патерн, побачимо що скажуть користувачі.
Сьогодні говорив з знайомим на рахунок патернів і корисності їх використання, все зводилось до того що патерни вивчити це добре але розумно їх використовувати не завжди получається, тому хотілось би десь почитати про саме проектування, застосування на реальному проекті і тд.
В нас на проекті деякий набір GoF дизайн патернів таки використовується, але дійсно їх багато не запхаєш. А якщо таки запхаєш, то потім із тим кодом дуже фігово розбиратися.
Може порадиш що почитати, думаю такі речі не тільки мене цікавлять… Зараз почав читати "Применение DDD и шаблонов проектирования". Думаю час від часу робити міні звіт в блог по ній, хотя не факт що дочитаю бо я так зрозумів що вони розрахована на трохи вищий рівень ніж зараз у мене.
"Чи є клас UnitImagesFactory якимось із факторі дизайн патернів із книжки GoF?"
так, маэмо по суті паттерн Factory Method + кеш
Класний паттерн. Один з моїх улюблених. І написано доступно, тільки мені здається що на UML діаграмі скорше зображений брідж ніж декоратор.
Також на мою думку якщо потрібний лише один декоратор то можна обійтися без базового класу (CarDecorator) і реалізувати зразу ж (AmbulanceCar).
Сіські, має бути рубріка із сіськами, або це не трушна юзер група 🙂
Опитувальнику явно бракує питань. Навіть айтем із "Сіськами" можна було б у ньому додати, для тих хто нічого іншого для себе не знайшов.
Нажаль, не вийшло прийти – обламалось в останній момент. Наскільки я зрозумів доповіді по IE9 не було, launch обмежився футболками).
Лаунч будет 30 сентября. да
Доповідь Сергія була насправді дуже цікавою. Питань не було, тому що він шикарно розклав все по поличках. Хотілось би продовження по цій темі.
На рахунок докладу "эффективные методы визуализации информации" – мене трошки скоф'юзило.. я очікував почути які існують методи візуалізації, та для якої інформації найкраще використувувати ті чи інші методи (розглянути багато типів діаграм, ітд.)… Це питання було розкрите, як на мене не повністю, тим не менше доклад був дуже цікавим і корисним..
Доклад Рустама – професійний. Дійсно важка тема, яка розкривалася досить глибоко без "водички", потребує осмислення.. Навіть не було питань, які можна задати… Для таких штук необхідно приходити на ком'юніті підготовлений, прочитавши хочаб декілька статей по розкритій темі. Так можна краще зрозуміти і "намотати на вус" викладений матеріал!! 😉
Мне понравились оба доклада. Для меня термин DataInk откровение, люблю минимализм несущий только информацию.
По SaaS Сергей очень класно расказал, и подробно и долго 🙂 Я честно забыл вопросы что появились в начале. Жду ссылок на литературку по SaaS
Спасибо.
Сергій дійсно монстр архітектури! 🙂
Дійсно розказав усе структуровано. Для всього були чіткі пояснення і прикольні картинки для побудови асоціацій у наших мозгах 🙂 То що у кінці було показано як воно усе мапається на щось реальне варто похвали. Круто!
Нажаль я ще відчуваю якийсь дискомфорт, що багато чого таки ще не розумію. Мені напевно бракує розуміння того як таку архітектуру "конячу" можна розгортати у клієнтів.
Дякую.
Коли останній термін здачі?
ну, давайте до 12 сентября:) чтобы 13 числа – или сделаем голосовалку, или просто огласим результаты:)
Так це Factory Method. Я хотів бути певним, що ніхто не буде казати що це не той патерн, плутаючи його із параметризованим фекторі методом. Також є така штука як CreateMethod, але вона створює об'єкти зазвичай свого класу і практично завжди є статичними методами.
Класс:)
Андрей, а чем ты таким замечательным пользуешся для рисования диаграмм?
Genius GPen
ах блин, вот для чего нужен планшет:)
Можна було обійтися тільки із одним декоратором. А на UML таки не брідж зображений, але певно ще бракує стрілки, щоб зобразити, що CarDecorator також наслідується від Car.
Do you have any proposition / desires / wishes regarding work of our group?
Таке нагле побажання – на кінець зустрічі купити не тільки алко напої 🙂
а можна діаграми зробити трохи чіткішими а то їх читати важко..
рубрика "Капитан Очевидность у микрофона"
мені сподобалося 🙂
дак никто и не говорил что это квантовая физика:) просто интересные факты:)
Для початківців саме те що треба) В якості закріплення знань рекомендую почитати писання преподобного Джона Скіта "C# In Depth" (2nd Edition)
Ну оцього я точно не використовував ще: string.IsNullOrWhiteSpace().
Мабуть тому, що вони інтродюснули в 4.0 фреймворку той метод…. Але часно кажучи й не було потреби для такої перевірки.
А я завжди писав свій аналог для string.IsNullOrWhiteSpace() для перевірки аргументів, адже у більшості випадків рядок з пробілами настільки ж "поганий", як і порожній. Стара топкодерівська звичка:)
мне нравится, тока я вот никогда его не использовал:)
Невже ніяке 3-д парті не мало подібного API ?
а черт его знает. мож и было, но я видать его с точки зрениия паттерна не рассматривал, потому в голове и не отложилось:)
Автор видалив цей коментар.
Круто! Ніколи не чув про цей паттерн. Так тримати!
>>Але ще одне питання: чи взагалі вам подобається такий синтаксис?
Можна закинути всі специфікації у масив і додати тут вкладений цикл. При додаванні нової специфікації просто буде плюс один елемент до масиву. Так можливо нічим не краще, але я б так робив:)
Прикольно, але тобі не завжди треба робити AND, тобі ще може треба буде робити OR, або інакше комбінувати!
Гарна стаття, дякую
З’явилася третя частина:
http://geekswithblogs.net/BlackRabbitCoder/archive/2010/09/09/c.net-five-final-little-wonders-that-make-code-better-3.aspx
Дякую! як на мене подарунки досить цінні і дивно що так мало людей відгукнулось, адже написати маленьку програму жарт чи щось таке не так вже й важко тому надіюсь на наступний рік конкуренція буде більша і подарунки теж)
PS в моїй програмі використано 64 (!) вікна, на наступний рік мабуть буде 256 )
Всіх з Днем Програміста!
Woho! всіх вітаю 🙂
Класна стаття, як раз вчасно зустрів! Дякую!
первый, конечно.
Я старый скептик, так что поздравлю тогда, когда книга будет закончена 😉
Ok, старый скептик! 🙂
Класс. Спасибо!
Простенько і геніально!
Дякую.
"Очень хочется оформить Нашу группу , как ГО"
для чого?
Если Мы будем ГО, то возможно общение с властями нашего города:) Значит Мы сможем как то влиять на айти престиж нашего региона:)
Думаю що то не найближчого часу плани. Проте, якщо серв захоче таке заспонсорувати, ну то може й має сенс.
Дима, как всегда зачетная призентуха, очень понравилось. Приятные новости по повноду развития групы. Ну и да, афтерпати было всем афтерпати головой 🙂
Мерси:) Если бы не Вы, ничего бы не получилось:)
А чому це недолік? З приватними полями і методами працювати не потрібно. Вони тільки для класу. Я б сказав що це теж перевага. ))))
Наприклад ми можемо мати методи CalcTax() – публічний і CalcFullTax() приватний.
CalcTax() може викликати CalcFullTax() для "проміжних" розрахунків. Але податківець зможе викликати тільки CalcTax(), що безумовно є перевагою )))
Добре, я згоден. Може я й помилився тут. Я дивився трішки із іншої сторони. Тобто при наслідуванні, яке часто використовується у патернах ми можемо працювати із протектед полями і так далі.
Тобто мається на увазі, що може нам треба буде алгоритм, який враховує щось дуже "захайдене" у тому класі.
Якщо інші згодяться із твоїм коментарем, тоді я це перемішу у "переваги" і напишу що я мало думаю 🙂
Це взагалі недолік патерна Відвідувач, класичний: порушення інкапсуляції, так як інтерфейс Елемента має бути досить розвинений для того, щоб Відвідувач зміг виконати свою роботу
Так, щось у тому є. Але із іншої сторони ми всерівно оперуємо тільки паблік властивостамя. Проблема у тому що коли ми будемо писати патерн Відвідувач, ми певно будемо підганяти трішки код під ньго і тоді отримаєму проблему згадану у коменті вище.
Андрію, якщо слідувати теорії сучасної шаблонної розробки (наприклад такої "нудної" штуки як "легка звязаність"), то в принципі "підганяти під патерн Відвідувач" ми взагалі не мали б – практично він повинен використовувати той функціонал який ми йому надали. Тобто наприклад, якщо це електрик, то "Кімната" надає йому тільки відомості про кількість і розташуванн лампочок, тип проводки, метод "ВимірятиСтрумВРозетці" (і т.д. – основні моменти в вас так і описані), а вже він сам ("Електрик") повинен виконати їх обробку (ну тобто тут як ви писали – певним чином відділяється алгоритм тестування електропроводки, але тільки в межах обробки результатів і виведення висновку "дядею Васею-Електріком"). Якщо щось недопоняв – зразу вибачаюсь:)
Андрій, все правильно, так б мало бути. Але як згадано у коментарі від Геннадія, "інтерфейс Елемента має бути досить розвинений". Якщо я правильно розумію Геннадія, то він має на увазі, що коли "Кімната" назовні показує кожну лампочку це дещо порушує інкапсуляцію. Думаю електрику буде мало знати скільки лампочок і де вони є, він захоче на неї подивитися. І ніхто не каже, що інший відвідувач не захоче ще на щось подивитися.
Але взагалі правильно. Все має бути "легко зв'язано".
Знову ж, слабка зв’язність це, звісно, добре, але… Не завжди вона має таке велике значення, і паттерн Відвідувач мабуть один з таких прикладів, адже Відвідувач створенний для використання САМЕ з цією структурою елементів, і ні для якої іншої, він не призначений для повторного використання, а тому залежність від конкретних особливостей реалізації єлементів на мою думку не має таких критичних наслідків. Гадаю, що шкідливим може бути використання тієї частини відкритого інтерфейсу ( що призначений винятково для використання Відвідувачем для реалізації своїх обов’язків, можливо методу "ВимірятиСтрумВРозетці"), іншими классами-Невідвідувачами (які мабуть також забажають використати зручний для них метод "ВимірятиСтрумВРозетці") тут виправдати посилення зв’язності вже складно. Наскільки я розумію, в С++ можливо було вирішити цю проблему за допомогою friend-класів, але в С# – для мене це поки що загадка.
А про інкапсуляцію… Так і інкапсуляцію можна порушувати по різному 🙂 Можна все ж таки спробувати абстрагуватися від того, чи зберігає Поверх Лампочки у хеш-таблиці, масиві чи зв’язному списку
Андрію, Геннадій так думав щойно – наче виникає 2 досить сумнівні пролеми – це місце зберігання алгоритму тестування і його розгалуженість (тобто варіанти "логіка в елементі". "логіка в відвідувачі", "логіка і там і там". Мені подобається 3 варіант – тобто Кімната надає інформацію що необхідна для отримання висновків (але вона про це не знає), а вже сам Відвідувач (і лише він для певного набору атрибутів) несе логіку їх обробки. На рахунок інших відвідувачів – вони в принципі теж можуть "ДивтисьНаЛампочку" і "МірятиСтрумВРозетці" – але це їм нічого не дасть якщо вони не реалізують певної логіки досягнення висновку (а якщо реалізують то вони стають електриками:) ).
А про абстрагування – тут до структур даних взагалі не варто привязуватись:) Патерни то швидше філософія в першу чергу 😉
Було досить цыкаво, особливо послухати про MVC 3, вже з нетерпынням чекаю його повного виходу 🙂 В цілому класно, бо взяв для себе багато інформації про тенденції розвитку технологій Microsoft, бо в інформації з інтернету деколи таке понаходиш що аж страшно стає 😀
Клас! Якщо вкладаєш досить багато зусиль у написання статті, то отримуєш коментарі, які навіть кращі за саму статтю. Це дуже радує. Дякую вам, хлопці!
Андрію, та нема за що 🙂 Аби тільки ті коментарі були корисними, а так то я завжди радий обговорити цікаву річ
Ура, разнообразие полезно!
Чудовий опис.
Може хто має досвід використання якоїсь бібліотеки для deep copy?
Вообще прототип – замечательный паттерн!
Я такого досвіду не маю, але стикався із клонуванням за допомогою сериалізації/десиріалізації.
в большинстве случаев (в реальной жизни) Builder используется "для упрощения конструирования сложных объектов" (it allows to hide construction complexity behind a convenient interface). Рекомендую обращать больше внимания на секцию Consequences в описаниях паттернов. Как показывает опыт – она ниболее полезная из всех
А можно использовать LINQ и вообще обойтись без кастомных експрешенов. Семантика спецификации сохраняется в названии класса спецификации, реализация использует LINQ. Плюс можно реализовать чейнинг спецификаций – с LINQ это тоже просто
Автор видалив цей коментар.
Обратите внимание на отличный FSM кит для .NET. Stateless – http://code.google.com/p/stateless/ . Намного проще (и прозрачнее) конфигурируется и работает. И каши (в виде большого количества подклассов) не просит 🙂
Було справді цікаво. Усім дякую
уххх, было круто:) очень порадовало что пришло много людей, хотелось бы извиниться за то , что не всем хватило места. В следующий раз мы предусмотрим такую вероятность.
В этот раз выступление вел Макс, который с этим справился на все 100% – так что – МОЛОДЕЦ!
Про доклады – все было действительно круто: Игорь показал что такое воркшоп, Андрей завалил всех полезной информацией.
К сожалению не остался на афтерафтерпати, в следющий раз исправляюсь:)
Між іншим двіжок дуже прикольний, реально синтаксис легший від того що використовувався в формсах але те що немає інтелісенс для мвс3 розчарувало ((
Дуже сподобався воркшоп! Сам формат був дуже класний, наочний.
Одне тільки зауваження. Певно варто було поділити одразу питання на беклог і спринт беклог.. зразу ж зрозуміло було, що на все відповісти часу не вистачить.. заодно ідею беклогу пояснили б 🙂
Встреча была супер! 🙂 Жаль что помещение было маловато, и нам не удалось разбить людей на нормальные команды (blood mess!!!) но ребята заменеджели %) Андрей немного затянул с докладом, но и перебивать его не хотелось(DDD увлекательная тема), люди начали клевать носом, надо больше живых примеров
Max, а я ж про час багато раз запитував 🙂
Хотя дійсно було видно що аудиторія втомилася. Багато інфи. Якщо я б ще приклади на кожен айтем показував то була б +1 година ще. От я наприклад показав живий приклад специфікації – зайняло певно 5 або більше хв.
Доповідь Андрія була оглядовою – тому і вийшло довго. Не скажу що мене втомило, проте деяка затягнутість відчувалась. Вечір п"ятниці мабуть дався взнаки.
Респект доповідачам і організаторам :)Все сподобалось.
Дуже чекаємо в GL наступного разу! Будемо намагатися покращити всі умови та сервіс для Вас!
Марія Шкіль
С днем рождения:)
Хе, дякую дуже!
http://geekswithblogs.net/BlackRabbitCoder/archive/2010/05/19/c-system.lazylttgt-and-the-singleton-design-pattern.aspx – цікаве доповнення до статті Андрія, приєднуюсь до вітань
Дуже сумнівний шаблон! Особливо з точки зору TDD (DI і т.і.) і особливо в классичній реалізації (як у прикладі)
Andy, дуже хороша стаття! Дякую.
десь читав, що робити lock (typeof(SomeClass)) трохи зле і краще робити як у статті, на яку посилається Andy:
var mutex = new object();
lock(mutex)
Правда не можу згадати чому )) І лінь шукати, може хто знає?
А варіант з Lazy класний, просто не всім підійде, бо не всі можуть використовувати .NET 4.0
>> І лінь шукати, може хто знає?
Дія такого локу поширюється на весь AppDomain у який завантажено тип. Ситуація погіршується для domain-neutral типів таких як String.
2 Oleh: дякую! ) ти спас мене від гугл-фу ))
Було дуже цікаво, чекаю наступної зустрічі 🙂
да, Разор должен быть очень крут. То что не работает IntelliSence в принце ожидаемо, это таки превью, а не RC. Все будет, надо только подождать)
по поводу хелпера/твиттера – неужели стиль нельзя настроить в CSS. Не верится, что единственная настройка, через код.. Надо глянуть на полученный div в FireBug, думаю много станет понятней!)
думаю з css проблем не буде )
Дима, на семинаре Microsoft ты выступал на тему MVC 3.0. Это будет тот же самый доклад?
Да:) Дима вначале вам расскажет а потом на мссвит:)
Позитивно:) Спасибо!
Діма твій доклад був на висоті, Рома теж молодець доніс суть і досить веселі слайди не заставляли скучати, Сігала будуть згадувати ще довго )))
Бей линуксоидов!
Мені цього разу абсолютно все сподобалося… І доповіді суперські і місця багато і купа піцци.
Багато місця, цікаві доклади, причому нам пощастило послухати Дімін доклад, якій він буде доповідати на http://www.msswit.in.ua/ ,а це ван нє діцкій утрєнік 🙂 Дуже сподобався подарунок, цеж ліцензійна вінда! Народ, цеж купа грошей! 🙂 Буду готувати доповідь та боротись за приз в конкурсі на найкращу доповідь квартала (3 зустрічі)
Скептик-Сігал рулить. Загалом я гарно провів час.
продовжуй в цьому ж дусі, надіюсь що чекати на наступний пост залишилось вже не довго)
пара очепяток:
делаеми
ращличные
Oleh Sklyarenko втоя ава теж би суперово підійшла… Шелдон рулить )
Опечатки – это я умею:)
Презентації були цікаві. Сподобалося як доповідачі відповідали на питання. Хочу ще зустрічі в Львів1 🙂
Як завжди цікавий приклад. Було б непогано доповнити статтю інформацією про Obsarvable Collection, IObserver, IObservable – тим що вже присутнє у .Net-і.
Нормально, попробуєм заюзати:)
Доволі практичний патерн, думаю при обробці подій дозволяє уникнути багатьох "костилів". Та й архітектура в цілому виглядає досить гнучкою і компактною водночас.
Так, патерн дуже практичний. Мій друг на ньому побудував бота, який хендлить ходи і в залежності від поточних умов хендлер передає обробку наступному у ланцюжку, який вже спеціальну логіку добавляє.
Дуже дякую за коментар. Я думаю що всякі такі речі як ObservableCollection і інше вже вбудоване у можу можна буде подописувати у книгу, але просто вагаюся чи то не буде зайвим.
Та тобі дякую!
Все залежить на кого орієнтована книга, якщо виключно на .NET розробників то було б непогано мати інформацію про готові реалізації патернів, але якщо для більшого загалу – то ця інформація може виявитись зайвою.
🙂 цікаво. Але скільки то презентацій тре: 20 сек по 20 слайдів то десь 7 хв презентація 🙂
Вибач, за офтоп: виправ всюди ігрушку на іграшку + інстанс – краще замінити на екземпляр, а так цілком непогано.
Дякую. Мені із тим взагалі треба буде багато працювати.
Гарний приклад для пояснення. Було приємно читати. Описану задачку можно вирішити ще використовуючи більш простіший паттерн – Фабричний метод (Factory Method).
Можливо варто про це сказати.
Фабричний метод повертає конкретну реалізацію тільки для одного класу. Тому якщо нам був б потрібен кіт (а не ціле сімейство іграшок) можна було б використовувати фабричний метод.
Також якщо говорити про параметризований фабричний метод, то можна було б мати методи
Cat CreateCat(ToyType toyType)
Bear CreateCat(ToyType toyType)
//….
у кожному методі був б switch який б реагував на wooden або teddy або інший тип ігрушок.
Така реалізація, м'яко кажучи, не є прикладом гарного дизайну для задоної задачі.
Дуже дякую за зауваження. Можливо дійсно варто згадувати про інші патерни у застосуванні до тих самих задач.
Roman, ще раз дуже дякую за коментар. Коментарі, що змушують задуматися є дуже корисними.
>> Така реалізація, м'яко кажучи, не є прикладом >> гарного дизайну для задоної задачі.
Так switch, та константи "wooden або teddy або інший тип" будуть. Але це вже нюанси та плюси і мінуси (мінуси в даному випадку) використання кожного з них.
Обидва патерни і абстрактна фабрика і фабричний метод створюють об'єкти. Просто різними способами.
Абстрактна фабрика робить – це через наслідування, фабричний метод – через композицію. Що краще вирішувати від ситуації.
З іншого боку, наприклад якщо необхідно додати нову іграшку то з абстрактною фабрикою доведеться розширити інтерфейс, і тоді доведеться змінювати(доповнювати) всі його імплементації.
І насправді можна обійтись і без switch. Фактично, він буде необхідний якщо використовувати параметризований фабричний метод – тобто передаємо константу або enum і в switch вирішуємо який клас створювати.
Інший варіант – це не параметризований фабричний метод а утворений шляхом наслідування від базового класу. Це вже більш нагадує абстрактну фабрику, але за винятком того що створюється один продукт, а не сімейство. Фактично якщо розглядати методи GetBear і GetCat окремо або виокремити їх в окремий клас – це будуть фабричні методи.
Що ще турбує, так це використання hardcoded рядків на кшталт IToyFactory toyFactory = new WoodenToysFactory(); – це аналогічно використанню констант, оскільки всюди у коді буде прив’язка до конкретного екземпляру і існує бажання винести частину «new WoodenToysFactory()», хоча констант тоді (DI/IoС як приклад) не уникнути, але вони будуть лише в одному місці коду.
І ще один аспект. Для того щоб створювати нові і нові конкретні продукти доведеться створювати нові реалізації інтерфейсу абстрактної фабрики. Тут на допомогу можуть прийти дженеріки (generic). І кількість реалізацій дуже суттєво зменшитися.
І ще як момент. Тут можна заюзати ще і прототип. Оскільки створювані іграшки відрізняються лише типом – плюшева або дерев’яна. Тому можна клонувати об’єкти і задавати потрібний тип новим об’єктам
Дякую і приєднуюсь до побажань. Успішного усім 2011-го року.
Уух! Який комент!
Я погоджуюся із твоїми думками. Насправді про різні способи вирішення проблем можна дуже багато говорити.
Дякую.
Я даже с 5 копейками влезу:)
Так как я сейчас больше в космосе летаю , но вот увдиел спор фабричный метод , против абстрактной фабрики:
Сейчас вот читаю Apllication Architecture Guide, и там кстати заметил интересную штуку, в секции design practices: prefere composition to inheritance:)
Із Новим Роком!
вдало добавив… Між іншим замічаю, що щоразу патерни йдуть легші, а очікував навпаки))
Дякі!
Дякую за запрошення, обов'язково прийду 🙂
Гарний малюнок 🙂 Ну і приклад також 🙂
Ех..знову середа…В мене мітінг щосереди в цей час 🙁
До речі, доступні десь презентації і відео з зустрічей? 🙂
Дуже дякую.
Привет,
Презентации есть, а вот видео – нет. Мы камеру забыли включитоь в прошлый раз)
фраза про дівчину у номер змусила дочитати до кінця 😉
гарний приклад, все як завжди на висоті, тільки.. ось UML діаграму ще б – був б фул-хаус 🙂
Та я знаю… просто я хочу малювати свої, а на них завжди часу не стає. Дякую. Ще лишилося 3 GoF патерни, думаю що для них таки намалюю, щоб був фул-хаус.
Когда выложите презентацию Go mobile с этой встречи?
блін, шо ж мене в цей Маврикій занемло? так би кінект і він фон поюзав…
але все рівно був радий вас всіх бачити, принаймні через відео чат 🙂
Олег – реально корисна інфа, поділився досвідом, який безцінний. Сподіваюсь послухати тебе в живу через декілька місяців 🙂
Юра – не можу особливо відзначити контент, бо я не бачив ні слайдів, ні демо, але можу сказати, що не зважаючи на те, що я засинав (в мене вже було 12 ночі) все рівно було цікаво слухати. Молодець!
Погоджуюся із всім вищенаписаним. Дійсно було багато нової та цікавої інформації.
Розчарував інтерес людей до Віндовс фона. Сподіваюсь, що то через конкурента у вигляді кінекта, а не через байдужість до нової платформи.
Вперше прийшов на зустріч, але собі вирішив, що прийматиму участь і в подальших зібраннях, бо попри те, що я не зовсім девелопер і в напів-.NET тімі, багато для себе почерпнув.
Презентатори викладали свої теми дуже цікаво, чим я пнриємно вражений. Аж до того, що трохи пошкодував про обмежені часові рамки, і що зустріч відбувається ввечері буднього дня.
Ага, і після того, як добряче пострибав граючи в kinect в мене на вечір заколо в боці, а отже я ще й добряче порухався.
Дякую за організацію.artf691270
Мудрый, палишься коллабнетом 🙂
Отличная презентация Go mobile with Windows Phone!
Также много нового для себя узнал с доклада Modern mobile development overview
Ггг… то він так свої коментарі номерує. Робота нових привичок навчає.
Насправді дуже "забойна" зустріч вийшла. Чесно кажучи я не очікував що почую стільки цікавого за один вечір.
Олег дав таку обширну інформацію по Mobile технологіям, що мало явно не показалося. І я ще ніколи не чув стільки про blackberry. Взагалі суперськи! Дуже тобі дякую!
Юра! Про WinPhone 7 ти точно краще розказував ніж "типу MVP" Лутай. ;)… Правда у нього вроді із ноутом пошвидше вийшло.
>> Юра Опришко
В вашій презентації сказано, що "сервіси" WP7 (marketplace, accounts) будуть доступні з другого півріччя. Можна дізнатись на які джерела опирались?
Предпологаю что с обещаний МС ЮА
В системе AutoCAD, есть такая штриховка с названием SOLID – она заливает замкнутый контур цельным цветом, без узоров.
По теме. Очень информативная и доступная статья – для программистов начального уровня. Все это и остальные детали, которые здесь не затронуты, можно узнать прочитав книжку о паттернах проектирования.
Супер! Эх, если бы выходной день я бы приехал 🙂
Офтоп конечно, но укр. хабр как-то громко сказано, есть еще как минимум сайт enetri.com, ну и не все что livestreet – хабр
Якщо ви .NET user group то розкажіть про Windows Azure!
Amazon WS можна використовувати для .NET на рівні API і там також є доступні Windows машини
Плюс буде порівняння Amazon vs Azure
У нас группа многогранная:) а про Ажур мы уже говорили, еси че.
Невже буде відбуватись в Четверг? Ура!!!
Не з усіма принципами особисто згоден, але в принципі рекомендації в цілому вірні, сенкс за статтю 🙂
Про амазонівську хмару читав уже трішки матеріалів, масштаб задуму і особливості функціонування справді цікавий, жаль що не зможу послухати 🙁
Нарешті нормальна стаття про Ажур, хоч щось тепер зрозумів. Дякую.
Зустріч вдалася!!!
Я був надзвичайно задоволений доповіддю по Клаудах. Надзвичайно професійно і лаконічно. Круто!
теорія це добре, але якщо перейти до практики…то Ви не зможете зареєструватись для використання Ажур…України в списку країн для реєстрація нема (Росії також)…
Усе було кльово… Докладчики на висоті…
Я так розумію, що Ви один мій коментар до першої статті назвали "многие начали кричать" 🙂
Ну це я так написав, до слова…просто прикро, що Україна знову серед африканських країн і що ми розглядаємось лише як джерело дешевої девелоперської сили.
На рахунок Ажур, то так…можна нормально девелопити локально. Що і робимо 🙂
Автор видалив цей коментар.
України і Росії в списку нема……
Бояться наших "умільців".
Літра пива і умілий шорох кнопок під руками українського хакєра Васі Чайникова і Only my application runs on the same infrastructure that Microsoft used moment ago to host their services, Microsoft Services is no more here!
На яку годину буде зустріч?
Время добавил:) Сорри
можна іще в календар додати? 🙂
Сделанно!
супер! минулого разу хотів прийти, але не скалалось… Тепер мушу, дуже хочеться 🙂
Було всьо супер. Тільки один коментар/побажання, досить цікаво послухати не тільки про технології, але й про реальні проекти, можна загалом, з якими проблеми стикались, які технології використовувались ітд. Не знаю чи таке пожливе через NDA ітд, але думаю було б дуже цікаво послухати багатьом.
Цікаво чи СофтСерв міг б хотя би декілька проектів привідкрити і поділитись досвідом.
Господа,
При чем тут СофтСерв? СофтСерв просто наш спонсор, вот и все. Остальное зависит от доклачика.
CофтСерв згадувався у конексті прикладу 🙂 Просто людині(архітектору чи сеньйору), щоб поділитись інфою треба відповідно дозвіл з сторони компанії/заказчика.
Доповідь про Mono була дуже цікава. Після неї десь 2 дні пробував шось кодити в Monodevelop 🙂 Нажаль не міг залишитися на WCF.
Так тримати!
Плануються 2 доповіді? Якщо так то яка тема другої?
Ще не знаю про що буду доповідати =)
До завтра вирішу
Відчуваю, що це буде мега паті 🙂
Few news about Mono:
http://www.infoq.com/news/2011/05/Mono-Future
http://tirania.org/blog/archive/2011/May-16.html
ну нарешті! 🙂
Діма, а для клієнтів ти теж так подаєш інформацію? 🙂 Я думаю що вони просто офігівають із того наскільки їх розуміють тут. А на другий день біжать підписувати контракт із СофтСервом.
Нажаль в мене веб досвіду мало, щоб перейнятися болючістю питань піднятих у другій доповіді, але було дійсно видно як інші люди уважно слухали цю доповідь.
p/s Дякуючи Софтсерву я отримав всоє N-не брендове горнятко.
Привіт!
Є маленьке питання. Після того як я зареєструвався мені на мило має прийти запрошення? Чи можна приходити без запрошення?
Дякую.
Никаких приглашений:)
Всім, хто просив назви книг:
http://www.koob.ru/toni_buzan/mind_map_book
http://www.koob.ru/edwdebono/
http://www.koob.ru/nollke_m/tehniki_kreativnosti
Дякую організаторам. Я був вперше, але мені сподобалось.
Дякую за доповіді по креативності і, особливо, по Symfony2. Знаю, що для багатьох друга доповідь була не зрозумілою, бо навіть мені (працюю з Symfony2 вже кілька місяців) було важко встигати за Сергієм, але тим не менше я дізнався багато цікавого і нового.
Піцца і пиво були дуже доречними)
Шкода, що не було достойних противників по Тейкену 😉 Тренуйтесь
На конференции будут ребята с команды SQL Azure, Linq to SQL, Entity Framework … и еще куча известных людей …
Ну раз Остап буде, то вже і я прийду)
Привіт!
А коли десь буде книга? дуже цікаво !
Спасибо 🙂
Мы стараемся
Дякую. Обов'язково подивлюсь.
Не встиг зареєструватись 🙁 Вже все, пізно?
Дякую організаторам та доповідачам – було дуже цікаво!
Приходьте ще 🙂
Виникли певні проблеми з доїздом доповідача, тому семінар Грега Янга не відбудеться!
Було класно! Дякую організаторам.
Привіт, а чи планується викладення у вільних доступ відео з даної зустрічі?
Діма, докинь будь-ласка івент в Гугл-календар 🙂
Сделанно:)
А Vagrant буде про Windows бокси?
Как я искал таблетку от синдрома — "у меня на компе работает"
http://www.maxtitov.me/2013/04/presentation-vagrant-pill-from-work-on.html
Комусь прийшов лист про підтвердження реєстрації?
😍