Vitalii Tsybulnyk / Виталий Цыбульник

On Software Development / О софтверной разработке

About the author

    Vitalii Tsybulnyk
Vitalii Tsybulnyk is a Software Engineering Manager at Mictosoft Azure.
E-mail me Send mail

Activity

Recent comments

Disclaimer

The opinions expressed herein are my own personal opinions and do not represent my employer's view in anyway.

© Copyright 2008-2018

20 Years of Microsoft Windows Upgradeability in 10 Minutes


Categories: Microsoft
Posted by Vitalii Tsybulnyk on Thursday, March 10, 2011 10:26 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Inside Windows Azure

Cloud Computing and Windows Azure were the leading subjects of PDC 2010 last fall. Fortunately, there are a lot of amazing videos of the presentations available, and Inside Windows Azure by Mark Russinovich is definitely my favorite. Mark provides a very clear 'big picture' review of Windows Azure's features and internal arrangement. He gives just the right amount of technical details to be useful to a wide audience, from cloud application developers to software product owners and company leaders. I highly recommend this video to anybody who is interested in modern IT trends in general and cloud computing in particular.

Posted by Vitalii Tsybulnyk on Friday, January 14, 2011 4:06 PM
Permalink | Comments (0) | Post RSSRSS comment feed

Что случилось с Бобом Маглиа?

Последние несколько дней большинство ИТ-изданий обсасывают тему аннонсированного Стивом Балмером ухода из Microsoft Боба Маглии (Bob Muglia), президента Server and Tools Business (STB) - третьего по величине и самого быстро растущего подразделения Microsoft. Как инсайдер, работающий в STB уже третий год, я не смог молча пройти мимо этой темы. Вся информация об этом событии исходит из письма Стива Балмера сотрудникам компании, в котором он сообщает о том, что назрела необходимость в смене руководства STB, и в связи с этим Боб Маглиа вскоре покинет эту должность, а по собственному решеню - и Microsoft. Полный текст письма доступен на сайте Microsoft, а также существует русский перевод этого письма. Мало кто упоминает о том, что на самом деле письму Балмера предшествовало письмо самого Боба, сообщающего о своём уходе. Общий тон этого письма и частота повторения в нём слова "integrity" только подтверждает основную версию происшедшего как то, что Боб стал неугоден Балмеру и был брутально выброшен за ненадобностью. Оба письма содержат по несколько упоминаний "cloud" и "Azure", что наводит на логичное умозаключение, что именно недостаточная компетентность Боба в новомодном облачном курсе компании и стала причиной, а некоторые далекоидущие издания уже пророчат президентское кресло Боба синьер вице-президенту по серверным и облачным технологиям Аматабу Шриваставе (Amitabh Srivastava). Основываясь на столь очевидной версии происшедшего, некоторые издания  опубликовали достаточно эмоциональные и довольно однобокие опусы в сторону жестокости высшего руководства Microsoft, "давшего двойную пощёчину" Бобу, в виде "признания заслуг перед компанией" вышвырнувшего "23-х летнего ветерана" на улицу не смотря на тот "головокружительный успех", к которому он привёл STB в последние несколько лет. Но как и в большинстве историй, существует и обратная сторона, о существовании которой можно узнать из комментариев к публикациям людей, более близко знакомых с деятельностью STB, Боба и Microsoft в целом за последнее время. Не поддерживая ни одну из версий, я лишь приведу здесь наиболее яркие "но", взятые из официальных источников, и позволяющие пролить немного света на то, что же на самом деле случилось с Бобом Маглиа:  - "Никто не увольнял Боба и не выпихивал его за двери. Балмер искал ему другое место в компании, но Боб не захотел его и решил уйти".  - "Компании нужна свежая кровь, кто-то моложе".  - "Как сотрудник Майкрософт на протяжении 23-х лет, Боб совсем не тот бедный парень, заслуживающий жалости - он получал акции компании с незапамяных времён".  - "Совершенно очевидно, что Майкрософту нужно обновление. Сеть людей в компании очень прочна и не поощряет нестадартные подходы".  - "Если бы всё было так хорошо с STB под Бобом, этой ситуации не произошло бы. Большинство людей жалуется, что Microsoft не понимает бизнес модели современных технологий, почему же тогда столько людей плачет по поводу ухода динозавра?"  - "Это могло произойти из-за пренебрежительных комментариев, которые Боб позволил себе в адрес Silverlight на MIX10. И Балмер, и он сам извинялись потом за это".  - "Прошу прощения, но пришло время ему или принять другую позицию в компании, или уйти. Я подозреваю новый руководитель с новыми идеями по поводу современных технологий поможет Microsoft в долговременной перспективе".

Categories: Cloud & Azure | Microsoft
Posted by Vitalii Tsybulnyk on Tuesday, January 11, 2011 10:13 AM
Permalink | Comments (1) | Post RSSRSS comment feed

О готовности к повышению и парадоксе самооценки

Система служебных уровней и выдвигаемые для каждого уровня требования существенно разнятся от компании к компании и от одной специальности к другой, однако проблема определения и самоопределения уровня сотрудника согласно установленной леснице уровней была и будет всегда и везде. Если условно обозначить цифрами от 0 и далее уровень владения сотрудником определённой компетенцией, то получаем характерную картину, отражающую текущее состояние гипотетического сотрудника X по шкале уровней компании Y: Рис.1   Рис.1  Рис. 2 Под необходимыми сотруднику компетенциями разные компании и разные должности могут понимать совершенно разные вещи, например для девелоперов это обычно технические знания и умения, способности к решению проблем, скорость освоения новых технологий и т.п. Количество этих компетенций также очень сильно зависит от компании, например в Microsoft их 33 (из которых выделяют 6 основных), в компаниях поменьше с более узкой специализацией их может быть например 1-2. Под уровнями тоже в разных компаниях понимают разные вещи, в компаниях покрупнее уровень каждого сотрудника - формальная, известная сотруднику и его менеджеру цифра (или буква), в компаниях поменьше как правило просто выделяют Junior, Middle, Senior, но суть от этого не меняется. Проблему, которую я хотел бы обсудить в этом посте, наглядно демонстрирует Рис. 1: каков итоговый уровень сотрудника на этом графике? 1? 2? Ответ на этот вопрос далеко не однозначен и зависит как от политики компании, так и от конкретного менеджера, проводящего оценку сотрудника. Вопрос становится ещё более интригующим для ситуации на Рис. 2. В небольших компаниях ответ на этот вопрос обычно определяется как некое среднее от уровней владения всеми важными компетенциями, т.е. для небольшой компании на рисунках скорее всего показан сотрудних уровня 2. В компаниях типа Microsoft ответ как правило будет менее утешительным: формальный уровень сотрудника устанавливается на уровне самой слабой из учитываемых компетенций, т.е. на обоих рисунках показан сотрудник уровня 1. Пожалуй такие компании имеют право на такую политику - раз уж какая-то компетенция установлена как определяющая для роли - значит сотрудних должен обладать ею в опрелелённой мере, иначе выполнение задач подвергается риску, который компания не может и не хочет себе позволять. В совокупности с тем, что и количество учитываемых компетенций существенно больше, получаем существенное затруднение в карьерном росте. Однако у такого подхода есть и позитивная сторона: достигнув определённого уровня в небольшой компании, вы никогда не знаете что вас ждёт при переходе в другую. Например, Senior Developer в небольшом стартапе может оказаться Middle или даже Junior при переоде в другой, где система оценки другая. Если же определённый уровень достигнут в компании с большим числом компетенций и с оценкой "по наинизшему уровню" - можно быть спокойным что это уже гарантированняй уровнень при переходе как внутри, так и вне компании. При переходе же в небольшую компаню кровень как правило можно даже с лёгкостью повысить. Ситуация усугубляется ещё и тем, что я наблюдаю у 4-х из 5-ти сотрудников и называю парадоксом самооценки, который заключается в том, что человек как правило оценивает сам себя по наиболее сильной из своих компетенций. Например, сотрудник на Рис. 2, сравнивая себя с другими сотрудниками, наверняка считает себя достойным уровня 3, т.к. при сравнении он учитывает наиболее сильные ("любимые") свои компетенции. Этот парадокс часто приводит к недовольству сотрудника и имеет два решения: решение "снизу" и решение "сверху". Решение "снизу" - сотрудник просто переходит в компанию, где слабые компетенции не учитываются, и таким образом получает тот уровень, по которому оценивает себя сам. Решение "сверху" - компания делает систему оценок и набор компетенций максимально прозрачной для сотрудников, проводится работа по их разъяснению, а менеждер распределяет задачи и прикладывает усилия таким образом, чтобы развить именно слабые компетенции в каждом из сотрудников. К сожалению, решение "сверху" - это долгий и тяжёлый путь без гарантии успеха, далеко не все могут и хотят тратить время на его прохождение, а это уже древний, как сам человек парадокс: кем же лучше быть - живой собакой или мёртвым львом? При этом я и сам затрудняюсь сказать кто в данном случае собака, а кто лев - оставим это каждому для самооценки .

Categories: Management | Microsoft
Posted by Vitalii Tsybulnyk on Friday, September 3, 2010 6:36 PM
Permalink | Comments (0) | Post RSSRSS comment feed

Немного об облаках

Несмотря на шумиху в прессе и в умах, которую пару последних лет производит Майкрософт по поводу своей (и не только своей) "облачной" (cloud) стратегии, очень многие опытные разработчики и руководители всё ещё не совсем представляют как эти изменения отражаются (отразятся) на их непосредственной профессиональной деятельности. Хорошим примером для меня стало то, что когда я сообщал своим коллегам в Майкрософт (а также экс-коллегам, друзьям и просто знакомым соратникам по цеху) о своём переходе в команду разработки Windows Azure, наиболее распространённой реакцией была "А что он делает этот Windows Azure?" Поэтому я и решился на написание этого поста - одним махом дать представление о прогрессе в облачном движении вообще и том вкладе, который в это движение делает Microsoft.   Для меня концепцию "облачного" движения проще всего раскрывать в сравнении с каким-либо другим технологическим скачком человечества, позвольте мне остановиться на примере изобретения и внедрения электричества.   Облака вчера.  Основные идеи cloud computing совершенно не новы. По сути, "облаком" можно назвать любой ресурс или приложение, используемое параллельно несколькими (многими) пользователями. Пожалуй даже самые первые суперкомпьютеры, с которыми большое число пользователей работало по принципу терминального доступа, уже можно относить к первым образцам "облака". Этот этап в создании и освоении "облачной" идеи можно сравнить с периодом 1650-1700 гг, когда Отто фон Герике экспериментировал со своей электрической машиной по извлечению искр из натираемого шара, которые и были по сути первыми экспериментами с электричеством. Однако технологии быстро развивались, и появление в конце 1980-х Интернета можно смело назвать зарождением "облачной" идеи в том виде, в котором мы её знаем сегодня: хост-провайдеры предоставляли платформу, на которой владельцы приложений могли разворачивать свои веб-приложения для использования их в качестве сервисов. Проводя параллели с освоением электричества, это период с 1700 по 1825 годы, когда такими учёными как Вольт, Фарадей и Ом были открыты, сформулированы и использованы все основные законы электростатики и электродинамики. Однако до массового использования этих знаний оставалось ещё пол века. Если бы мы в это время подошли к случайному прохожему и спросили "как вы относитесь к электричеству?", нас мы скорее всего встретил недоумённый взгляд.   Облака сегодня. Что же произошло два или три года назад такого, что послужило толчком всей этой "облачной лихорадке", которую мы наблюдаем сегодня? Попросту говоря, технологии и инфраструктура Интернета достигли уровня, достаточного для того, чтобы всерьёз говорить о предоставлении совершенно любых приложений в виде интернет-сервисов. Интернет стал такой же неотъемлемой частью нашего быта, как водопровод, телефон и то же самое электричество, которое достигло аналогичного этапа в своём развитии в 1870-х годах, когда были сконструированы первые электрогенераторы и начали строиться первые электростанции, а на улицах Парижа вспыхнули первые дуговые электролампы. Windows Azure - это по сути и есть электростанции, которые позволяют потребителям облака не заботится о построении облачной инфраструктуры, достаточно просто купить этот сервис у людей, делающих это профессионально. Покупая доступ к облаку Microsoft, Amazon, Google или любому другому, вы избавляете себя от необходимости крутить динамо-машину и трансформировать полученное электричество, вы просто подключаетесь к линии электропередач и платите за количество потреблённых кВатт-часов. Облака завтра. Собственно будущее облаков вобще и  Windows Azure в частности и натолкнуло меня на написание этого поста. Многих потребителей не устраивает зависимость от централизованой электрической сети - хочется и гарантий независимости, и 100% надёжности. Точно так, многих в облачной идее смущает именно вопрос безопасности конфиденциальных данных размещённых в публичном облаке, а также надёжности предоставляемого сервиса. Для 95% потребителей надёжность и безопасность data-центров того же Microsoft на две головы превосходит надёжность того, что они могут построить сами. Однако оставшиеся 5% (а в будещем это число может расти) хотят и могут платить за то, чтобы иметь надёжное облако и безопасное для себя и только для себя. Именно для этой категории пользователей  Microsoft анонсировал Windows Azure Platform appliance - платформу  Windows Azure, которую клиенты смогут разворачивать на своих собственных data-центрах. Таким образом для пользователей, инвестирующих в разработку своих сервисов под Windows Azure сейчас, гарантируется что они могут быть в будущем перенесены в приватные data-центры на базе Windows Azure Platform appliance:       We are delivering a game-changing cloud service with Windows Azure.  Windows Azure is the world’s first all-purpose cloud platform that allows customers to focus on creating business solutions without worrying about the underlying infrastructure.  At the same time, we are enabling customers to build their own cloud within their custom environments using our Windows Server, SQL Server, and System Center products. Building on these unique assets, at WPC, we took a big step forward with the announcement of the Windows Azure Platform appliance, a turnkey cloud platform that customers can deploy in their own datacenters, spanning from hundreds to thousands of servers. When we announced the launch of the first wave of the Windows Azure appliance, we effectively changed the cloud game in the industry.  Through this announcement, we’re making cloud computing more accessible than ever before by taking everything we've learned through running clouds ourselves (Hotmail, Bing, Microsoft Online Services, etc.), packaging it up, and delivering it to the industry.  With the help of companies like Dell, eBay, Fujitsu, HP and others, we believe this innovative step will change the face of cloud computing. With the announcement of the Windows Azure appliance, Microsoft has redefined cloud computing by being the only vendor that is delivering across all aspects of the cloud. Мне кажется, что это один-в-один повторяет тенденцию использования особо энерго-зависимыми учреждениями (и частными лицами) электрических мини-генераторов или портативных электростанций чтобы обезопасить себя от перебоев с поставками электроенергии и от стратегической зависимости от этих поставок, что в очередной раз подверждает теорию спиральности технического прогресса, когда все новые идеи и открытия всегда отражают некие старые, только уже в новом качестве.

Posted by Vitalii Tsybulnyk on Friday, July 16, 2010 10:33 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Пирамидальная карьера Рико Мариани

Rico Mariani занимает позицию Partner Software Architect в Microsoft и является неиссякаемым источником профессиональной мудрости для множества работающих с ним людей. На одной из недавних презентаций, приуроченных к Microsoft Engineering Forum в этом году, Рико рассказал своё видение успешной карьеры IT профессионала, что волшебным образом совпало с моим представлением, так что я не смог не привести его здесь. Рико образно изображает успешную карьеру в виде геометрической фигуры - пирамиды. Пирамида в данном случае выступает как противоположность башни, когда карьера строится на опыте определённого рода, совершенствуясь лучше и лучше в этой определённой области, то такую модель карьеры можно сравнить с высоким зданием с небольшим основанием. Вам кажется "как быстро я расту, как стремительно движется моя карьера", однако скрытый недостаток такой модели в том, что на определённой высоте "уже никто не захочет ложить кирпичи на такую башню из-за угрозы падения". В то же время уже поздно расширять основание, т.к. "вы уже слишком высоко, вы уже не можете вернуться к основам". "Намного лучше начать с широкого базиса и строить вверх, опираясь на него и постоянно расширяя его ещё больше по мере роста". Широкий базис включает разнородные знания и умения, опыт работы в разных ролях и областях, что даёт очень устойчивое и надёжное основание для роста вашей карьеры вверх, образуя таким образом треугольник. Этот треугольник может быть неидеальным, с несколькими "пиками" в разных местах, однако именно широкое основание даёт представление об устойчивости этой фигуры. "Такая карьера намного труднее, занимает дольше, но это даёт лучший результат в долговременной перспективе". Для меня прелесть такой карьеры в том, что вы никогда не оказываетесь в ситуации, когда вы выросли настолько, насколько могли, и на этом ваша карьера достигла естественного максимума. При такой модели вы всегда можете переместиться "в сторону" вместо "вверх" и продолжить своё "строительство" там. Это перемещение может быть сменой технологий (desktop-> web, server -> client), ролей (manager -> individual contributor) или даже дисциплин. Так мы получили треугольник, но ведь пирамида - это трёхмерная фигура. Что же в данном случае символизирует это третье измерение, что делает пирамиду объёмной? Этим третьем измерением Рико называет вашу индивидуальность, то что вас увлекает, обогащает, интересует в этой жизни. Это может быть семья, игра на музыкальном инструменте, путешествия, выращивание растений - всё что угодно, что приносит вам радость от жизни. Величайшая неординарность и одновременно жизненная мудрость Рико заключается в том, что он вносит этот аспект вашей личности как неотъемлемую и органичную часть успешной карьеры. Мудрость эта, во-первых, заключается в том, что вы не сможете всегда на 100% выкладываться в своей работе, если она лишает вас того, чем вы занимаетесь, чем вы живёте всё остальное время. Карьера никогда не должна убить эту вашу индивидуальность, поглотить всего вас. К сожалению, приходится видеть людей, не учитывающих этого и посвящающих всего себя работе, и это работает год, работает два, пока человек не превращается в раздражённого зомби, не удовлетворённого ни работой, ни всей своей жизнью в целом. Только счастливый, довольный своей жизнью человек может стабильно быть креативным и продуктивным в своей работе, а значит построить долговременную, устойчивую карьеру. Вторая мудрость - даже вне работы, вы всё ещё тот же человек, и тот жизненный опыт, те умения и качества, что вы приобретаете вне работы, те решения, которые вы принимаете, они обогащают всего вас, и вашу "рабочую" часть в том числе, они позволяют воспользоваться опытом и креативом, накопленным в повседневной жизни, в профессиональных целях. Человек, живущий богатой и полноценной жизнью, создаёт более широкий и устойчивый (основание пирамиды) базис для своей профессиональной карьеры.

Categories: Management | Microsoft
Posted by Vitalii Tsybulnyk on Monday, June 14, 2010 9:44 AM
Permalink | Comments (2) | Post RSSRSS comment feed

Visual Studio Isolated Shell: интегрированная среда разработчика своими руками

ВВЕДЕНИЕ  Думаю, излишне говорить о том, как важен удобный и профессионально выглядящий пользовательский интерфейс для успеха программного продукта. Однако качественный и богатый возможностями пользовательский интерфейс - весьма дорогостоящее удовольствие. Он требует не только существенных дополнительных затрат на разработку дизайна, анализ удобства использования, но и влечёт за собой растущие в геометрической прогрессии затраты на тестирование и отладку. Один из таких классов дорогостоящих интерфейсов - это MDI (multiple document interface - многодокументный интерфейс). Разработка программного продукта с редактором файлов, удобной манипуляцией окнами, toolbox и toolwindow - это на 80% разработка интерфейса, и только на 20% разработка собственно уникальной для вашего продукта бизнес-логики. Использование таких библиотек, как MFC для С++ или Infragistics для .Net, бесспорно, очень помогает, но не спасает в такой ситуации. В данной статье я хотел бы рассказать об ещё одном, сравнительно новом подходе к созданию профессионального многодокументного пользовательского интерфейса от Microsoft под названием Visual Studio Isolated Shell. ОСНОВНЫЕ ПРИНЦИПЫ Visual Studio Isolated Shell представляет собой облегчённую версию оболочки Visual Studio, которую разработчик может использовать для создания собственного продукта. Т.е. в распоряжение разработчиков предлагается вся мощь Visual Studio IDE, включая меню, редактор файлов, toolbox и toolwindow, которую они могут наполнят своей собственной бизнес-логикой и получать таким образом профессиональное приложение с богатыми возможностями графического интерфейса, не уступающими лидерам рынка. У такого использования есть и своя цена - для реализации уникальной бизнес-логики внутри оболочки разработчику предоставляется ограниченный набор инструментов, предназначенный для расширения возможностей стандартной оболочки Visual Studio. Таким образом, архитектура построенного на базе Isolated Shell приложения представляет собой конгломерат из собственно самой оболочки и расширений к ней, реализующих уникальную бизнес-логику приложения.  СОЗДАНИЕ ПРОЕКТА  Isolated Shell впервые появилась в Visual Studio 2008, однако в этой статье я буду ссылаться на Visual Studio 2010 RC, так как в этой новой версии есть ряд усовершенствований и дополнительных возможностей. Для создания собственного проекта Isolated Shell вам понадобится Visual Studio 2010 RC Ultimate/Professional и Visual Studio 2010 SDK RC. После установки VS SDK в списке доступных проектов ('File' -> 'New' -> 'Project') появится 'Other Project Type' -> 'Extensibility' -> 'Visual Studio Shell Isolated'. Создайте этот проект - в окне сразу откроется описание "Starter Kit", которое можно использовать в качестве первого руководства в мир Isolated Shell. Если при создании проекта вы оставили название по умолчанию 'VSShellStub1', то ваше решение состоит из четырёх проектов: VSShellStub1 - ядро оболочки (С++) VSShellStub1UI - проект-спутник (satellite dll) оболочки, содержащий некоторые ресурсы (С++) VSShellStub1.AboutBoxPackage - пример расширяющего вашу оболочку интерграционного пакета (Integration Package), реализующий простой диалог "About Box' (C#) ShellExtensionsVSIX - проект расширения для оболочки, по умолчанию содержащий только интерграционный пакет VSShellStub1.AboutBoxPackage (C#) Cкомпилируйте и запустите решение. Мои поздравления - вы увидете оболочку вашего будущего проекта, весьма напоминающую Visual Studio, но лишённую характерных иконок и прочих логотипов. Пункт меню 'Help' содержит ссылку на диалог "About Box', содержащийся в созданном по умолчанию расширении. РАСШИРЕНИЕ ОБОЛОЧКИ Разработчику предлагаются некоторые возможности по модификации самой оболочки, например в проекте оболочки есть возможность изменить её название, иконку и splash screen. Однако внедрение новой логики реализуется исключительно через модули расширения. Для Visual Studio создан единый и универсальный механизм расширения, доступный в равной мере как для самой Visual Studio, так и для всех систем, построенных на базе Isolated версий её оболочки. Основным концептом расширяемости оболочки Visual Studio 2010 является так называемый VSIX-файл. Это файл, установленный в качестве расширения (extension) для выбранной вами оболочки и содержащий определённого вида манифест и бинарные коды пакетов расширения. Возвращаясь к созданной нами оболочке, VSIX-файл создаётся в результате компиляции проекта ShellExtensionsVSIX. В этом проекте наибольшего внимания заслуживает файл source.extension.manifest, в котором собрано описание VSIX-файла и всех входящих в его состав пакетов расширений. Пакеты расширения могут иметь разное назначение, и основная масса самых востребованых шаблонов собрана на диалоге 'New Project' для языков C# и VB в разделе 'Extensibility'. В этом разделе, например, есть шаблоны расширений редактора файлов, позволяющие встроить в редактор свои собственные графические и логические функции. Однако, ещё более мощным средством расширения оболочки является т.н. Visual Studio Integration Package, доступный разработчикам ещё с версии Visual Studio 2008. В созданной нами оболочке, проект VSShellStub1.AboutBoxPackage и является примером Integration Package. Integration Package позволяет реализовать: собственный пункт меню, при нажатии на который выполняется необходимое вам действие внутри оболочки (например, открытие диалога 'About Box' в нашем VSShellStub1.AboutBoxPackage) собственный Tool Window, реализующий нестандартное внутренее немодальное окно в вашей оболочке с вашим собственным устройством и фукциональностью редактор файлов, позволяющий создавать или редактировайть файлы с определённым нестандартным расширением в модифицированном под ваши нужды редакторе внутренние сервисы вашего приложения, реализующие определённую функциональность, доступную для вызова из других модулей расширения и т.п., чего впролне достаточно для большинства приложений. При создании Integration Package можно выбрать один из языков C#, VB или C++. СОЗДАЁМ СВОЙ ИНТЕГРАЦИОННЫЙ ПАКЕТ Попробуем создать свой собственный новый интеграционный пакет для нашей оболочки. Для этого в решении нажмём 'Add' -> 'New Project' -> 'Other Project Type' -> 'Extensibility' -> 'Visual Studio Integration Package'. Выберем язык C# и включим в наш пакет все три возможности: 'Menu Command', 'Tool Window' и 'Custom Editor'. Откажемся от 'Integration Test Project' и 'Unit Test Project', они нам не интересны на начальном этапе. Если вы не меняли название пакета по умолчанию, то в вашем решении появится новый проект 'VSPackage1'. Включим наш новый пакет в состав оболочки. Для этого откроем файл source.extension.manifest в проекте ShellExtensionsVSIX и нажмём 'Add Content' в разделе 'Content'. На открывшемся диалоге выберем 'VS Package' в качестве content type и проект 'VSPackage1' в качестве source. Компилируем и запускаем оболочку: в группе пунктов меню 'Tools' появился наш собственный пункт меню 'My Command name', открывающий определённое в нашем пакете сообщение в группе пунктов меню 'View' -> 'Other Windows' появился наш собственный пункт меню 'My Tool Window', открывающий определённое в нашем пакете немодальное инструментальное окно диалог 'New' -> 'File' содержит новый раздел 'VSPackage1 Files', позволяющий создать файл с определённым нами расширением *.vspackage1 и отредактировать его в его собственном редакторе Все перечисленные выше названия пунктов меню, инструментального окна, группы файлов и их расширения были сгенерированы по умолчанию при создании нашего интеграционного пакета, однако они легком могут быть заданы в процессе создания или изменены уже после этого. Приведенная процедура создания собственного расширения и включения его в состав нашей оболочки призвана продемоснстрировать достаточную простоту и наглядность этого процесса. РАЗВЁРТЫВАНИЕ ПРИЛОЖЕНИЯ Некоторого внимания заслуживает развёртывание системы, построенной на базе Isolated Shell. В Visual Studio 2008 для развёртывания и автономной работы такой системы необходима была её регистрация с помощью специально получаемых с сайта Microsoft ключей (SLK и PLK), однако в Visual Studio 2010 это требование устранено. Кроме этого, в свой инсталляционный пакет вы должны включить т.н. Visual Studio Shell (Isolated Mode) redistributable package, который обеспечивает всё необходимое окружение для запуска оболочки. После этого развёртывание системы сводится к собственно к установке вашей оболочки со всеми её расширениями. ЗАКЛЮЧЕНИЕ Пожалуй, использование Isolated Shell будет наиболее ценным для IDE-подобных продуктов, таких как дизайнеры определённых файлов, редакторы экзотических языков программирования или другие средства манипуляции наборами файлов и их содержимым, однако круг применения этого мощного средства со временем может оказаться намного шире, особенно учитывая, что Microsoft уделяет расширяемости Visual Studio с каждой версией всё больше и больше внимания.

Categories: Development | Microsoft
Posted by Vitalii Tsybulnyk on Friday, March 19, 2010 4:01 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Автоматическое тестирование UI от Microsoft

Вопрос автоматического тестирования пользовательского интерфейса (UI) по праву считается самым сложным аспектом контроля качества софтверных продуктов. И сложность здесь заключается не только в многообразии пользовательских сценариев и чисто "визуальном" отображении информации, а также и с отсутствием простых и одновременно надёжных инструментов и фреймворков для автоматического тестирования UI. Что же на этом поприще может предложить Microsoft, как "гигант" и "флагман" индустрии? К сожалению, для классических Win32 приложений Microsoft не предлагает ничего, достойного внимания профессионального тестировщика. Однако с появлением .Net Framework (а в особенности WPF) ситуация радикально меняется к лучшему, и иначе как революционным решение Microsoft для managed UI automation я назвать не могу. Заинтересовавшиеся могут сами ознакомится с возможностями System.Windows.Automation, скажу лишь что по надёжности и простоте Вы врядли найдёте что-то лучшее для автоматизации QA десктоп-приложений. Что же касается web, то на рынке уже есть несколько неплохих продуктов для автоматического тестирования веб-интерфейсов, однако для тех, кто работает с технологиями Microsoft, и в частности ASP.NET, советую обратить пристальное внимание на достаточно новую разработку Lightweight Test Automation Framework. Неоспоримыми достоинствами и залогом будущего успеха являются простота и плотная интеграция продукта непосредственно с ASP.NET.

Categories: Development | Microsoft
Posted by Vitalii Tsybulnyk on Wednesday, December 9, 2009 10:33 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Visual Studio on Channel 9

This post is just to let you know that there is 'Visual Studio' topic area on  MSDN Channel 9. Here is the list of my favorite episodes: • C# 4.0 - Questions and reasons behind the answers • Team Foundation Server 2010 • Enterprise Project Management with Visual Studio Team System 2010 • Web Development and Deployment with Visual Studio 2010 • Debugging Parallel Applications with Visual Studio 2010 • Visual C++ 10: 10 is the new 6 • The Future of Visual Studio Extensibility

Categories: Development | Microsoft
Posted by Vitalii Tsybulnyk on Friday, June 12, 2009 6:08 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Visual Studio 2010 (and .Net Framework 4.0) Beta 1

My congratulations to the .Net community and all .Net professionals: .Net Framework 4.0 Beta 1 and Visual Studio 2010 Beta 1 are available for download!   There are a couple of very useful links to read more about new look and new features of these incredible products form Jason Zanders’s (who is actually the General Manager for the Visual Studio team in Microsoft) blog: VS2010: On Triangles and Performance Announcing VS2010 / .NET Framework 4.0 Beta 1! General Download of VS2010 / .NET Framework 4.0 Beta 1   .Net Framework and Visual Studio are the key products for the Microsoft Development Division, so you can hear much buzz around this beta on the pages of other Microsoft managers' blogs. E.g. VS 2010 Extensibility featured on Scott Hansleman's blog: Demo Dashboard and IDE Extensions - Whirlwind Tour around .NET 4 (and Visual Studio 2010) Beta 1 And Visual Studio 2010 SDK also already comes in Beta 1, you can find download link at the VSX Team Blog: Announcing the Visual Studio 2010 SDK Beta 1 Extensibility features are my favorite because I am a part of Extensibility team (Extension Manager and VS SDK are those VS 2010 features which I worked on).

Categories: Development | Microsoft
Posted by Vitalii Tsybulnyk on Friday, May 22, 2009 4:25 AM
Permalink | Comments (2) | Post RSSRSS comment feed

Первый взгляд на Visual Studio 2010

Прежде всего разрешите представить: Jason Zander, General Manager продукта Visual Studio в Microsoft. Его блог не только хороший источник полезной информации о новых продуктах Microsoft "из первых рук", но и своеобразный индикатор политики неразглашения для других членов команды Visual Studio: если информация прозвучала со страниц этого блога, то она более не является коммерческой тайной и может озвучиваться кем угодно. Сегодня я хочу обсудить пост, посвящённый новому интерфейсу Visual Studio 2010. Более детально об улучшениях в UI можно узнать непосредственно из блога Jason'а, я же пройдусь тезисно по основным (на мой взгляд) пунктам:  1. Новый UI Visual Studio сделан на WPF, т.е. выглядит более "кульно" (но пока что работает заметно медленнее). 2. Окна с документами могут покидать границы оболочки VS и существовать как независимые окна, что должно безумно порадовать любителей работы с несколькими мониторами. 3. Строки, в которые были внесены изменения, оттеняются цветными полосками слева. 4. Multi-targeting включает все Framework'и от 2.0 до 4.0 включительно (что есть по сути первым полноценным multi-targeting'ом, т.к. у фреймворка 4.0, в отличие от 3.x, новый рантайм). 5. Extension Manager и Visual Studio Gallery - новый огромный шаг в сторону расширяемости и дополняемости VS. Поскольку это именно та функциональность, к которой приложил руку и ваш покорный слуга, отмечу особо, что для расширений VS не только введено централизованное хранилище, легко доступное из самой VS, но добавлен наглядный мониторинг и менеджмент установленных расширений, а также и разработка всех типов расширений существенно упрощена благодаря новым шаблонам в VS SDK. Если вас заинтересовали нововведения Visual Studio 2010 - очень скоро всё это можно будет попробовать на бета-версии, выход которой запланирован на весну.  

Categories: Development | Microsoft
Posted by Vitalii Tsybulnyk on Tuesday, February 24, 2009 5:48 AM
Permalink | Comments (4) | Post RSSRSS comment feed

SCRUM в Microsoft.

Момент истины - барабанная дробь, и... Да, в Microsoft испльзуют SCRUM! Не уверен, что абсолютно для всех своих продуктов, но для большинства наверняка. Лично меня это обстоятельство весьма удивило, ведь я ещё помню времена появления и бурного продвижения "водопадно-спирального" MSF, когда достаточно уверенное владение MSF требовалось даже для весьма "попсового" сертификата MCSD. У меня ещё где-то валяются пару увесистых справочников по MSF, которые я планировал когда-нибудь заучить наизусть в качестве "идеального" процесса разработки, который испльзует "сам Microsoft!" Не судьба. Видимо ближайшее время этим справочникам место на свалке, как и любой идеологии, в которую уже не верят даже сами её создатели. Удалось пообщаться со старожилами Microsoft, которые ещё работали согдасно MSF, и работали надо признать весьма успешно. Однако после провала MSF в одном из крупных продуктов (как я понимаю, это был Windows Vista, выход которого был задержан на 2 года в том числе и по причине несовершенства процесса), Microsoft массово перешёл на SCRUM, где пребывает и по сей день. Тем не менее, искушённый читатель нверняка знает, что "провозгласить следование процессу SCRUM" и "следовать процессу SCRUM" - это, как говорят в Одессе, две большие разницы. Поэтому немного о том, как именно в Microsoft соблюдается SCRUM:  - работа над продуктом ведётся небольшими командами по 5-10 человек, в которых присутствуют представители 3-х ролей: Developer, QA, Program Manager.  - работа каждой команды над своей частью проекта разбита на небольшие промежутки времени, sprint'ы продолжительностью 20-30 дней, к концу каждого из которых выделенный "кусочек" функциональности доводится до необходимого уровня готовности, задаваемого в начале спринта.  - внутри каждой команды каждый день проводятся 15-тиминутные SCRUM митинги, задача которых - "держать руку на пульсе" спринта, а именно каждый участник спринта говорит о работе за последние 24 часа и на следующие 24 часа. Если возникают вопросы или есть почва для дискуссии, то назначается отдельный митинг, куда приглашаются только заинтересованные участники. Таким образом оперативно устраняются "блокировки" в работе и всегда можно проследить динамику протекания спринта, затраты времени на ежедневные митинги при этом минимальны.  - SCRUM соблюдается также и в том, что называется "атрибутами процесса", а именно в определённой форме документирования задач и их готовности, сбора метрик и т.п. Вы спросите: а как же тогда известные утверждения о том, что в Microsoft у всех всегда есть менеджер и любой сотрудник находится не дальше чем в 7-ми ступеньках от Стива Балмера? Это правда и в этом "изюминка" реализации SCRUM в Microsoft. Помимо SCRUM-команд, которые формируются динамически согласно требований продукта, и все участники которых выступают как равноправные individual contibutors, все сотрудники ещё входят в состав определённых "статических" команд, которые формируются по признаку специализации (может быть команда только developer'ов или только QA, никаких "смешений"). В этих "статических" командах роли уже распределяются в "классическом" иерархическом представлении: individual contibutor, senior individual contibutor, team manager (например developer - senior developer - development manager или QA - senior QA - QA manager). Состав этих команд меняется намного реже, т.к каждый участник такой "статической" комады может учавствовать в одной или нескольких (или ни одной) SCRUM-командах. Менеджер такой команды является непосредственным "начальником" для каждого члена команды, а у менеджеров команд есть в свою очередь свой "специализированный" (development или QA) менеджер продукта, а у тех - general manager продукта, что и представляет собой известную иерархию Microsoft.

Posted by Vitalii Tsybulnyk on Wednesday, January 21, 2009 11:13 AM
Permalink | Comments (8) | Post RSSRSS comment feed

Как пройти собеседование в Microsoft. Часть 3. Очное собеседование.

Итак, если ответом на телефонное собеседование Вам пришло приглашение на очное собеседование - мои поздравления. Независимо от конечного результата, это говорит что Вы достаточно привлекательный сотрудник даже для очень серьёзных и привередливых компаний. Если Вы находитесь в США, дата очного интервью будет очень близкой, но если Вы обитаете на просторах бывшего СССР, куда Microsoftовские менеджеры наведываются раз в пол года, то время до очного тура может колебаться от нескольких недель до нескольких месяцев. Мне повезло попасть как раз перед приездом интервьюеров и у меня было 3 недели на подготовку. Microsoft высылает много материалов и ссылок, подробно раскрывающих все орг. вопросы проведения собеседований в Microsoft, поэтому сосредоточусь на "профильной" подготовке. Для начала дочитайте книгу Как сдвинуть гору Фудзи - головоломка или вопрос из неё может быть задан в любой момент. Затем учите мат. часть, к чему я отношу все алгоритмы (поиск, сортировки) и структуры данных (кучи, деревья), которые Вы только можете осилить за отведённое время. Я штудировал следующие труды (порядок сохранён): 1. Бентли "Жемчужины программирования" 2. Уоррен "Алгоритмические трюки для програмистов" 3. Кнут "Искусство программирования. Том III" 4. Тамре "Введение в тестирование программного обеспечения" 5. Кнут "Искусство программирования. Том II" 6. Макконнелл "Совершенный код" 7. Ховард, Лебланк "Защищенный код" Пусть Вас не смущает пункт №4. В Microsoft на девелоперов ложатся обязанности автоматического и юнит-тестирования кода, так что от всех требуется хорошее понимание процессов тестирования. Более того, в Microsoft есть специальные команды девелоперов, основная обязанность которых - тестовый девелопмент (SDET), которые появились сравнительно недавно и где потребность в кадрах (а значит и вероятность попасть туда) выше. День собеседования. Собеседование для всех выходцев из СССР и близлежащих старан (Румыния и т.п.) проходит в Москве. Microsoft предлагает любой вид транстпорта, включая самолёт, и одну ночь в отеле. Советую не стесняться и воспользоваться всем чтобы быть максимально в форме. На собеседование обычно прилетает несколько человек (менеджеры проектов и HR), которые по очереди собеседуют кандидатов, каждый по 40-45 минут. HR собеседует на предмет общей адекватности, жизненных интересов и психологической готовности уехать на работу в Microsoft. Вопрос, к которому надо быть готовым: "какой проект вы последний раз делали не для работы (а для себя)" или "если бы вы стартовали свой проект (бизнес), что бы это было". Менеджеры собеседуют по предыдущему опыту, технической подготовке и умению быстро въезжать и решать сложные проблемы. Возможные вопросы:  - самое существенное достижение в карьере (конкретный проект и Ваша роль);  - что предпочитаете из списка технологий которыми владеете и почему;  - операции с данными (превратить граф в дерево) вплоть до написания фрагментов кода;  - алгоритмические задачи (индексировать каталог книг, переставить слова в предложении) вплоть до написания фрагментов кода;  - логические задачи и игры. Каждого претендента собеседуют не меньше 3-х интервьюеров. Если Вас прособеседовали 3 раза и "отпустили" - вы не подошли, очень жаль. Если собеседовали 4-6 раз - надежда есть, но нет никаких гарантий. В нашей группе было 6 человек, всех прособеседовали 5 раз (4 менеджера + HR), но взяли только 2-х. Но даже если Вы не прошли - нет повода отчаиваться. Во-первых, Вы потратили время с пользой и приобрели очень ценный опыт. Во-вторых, Вы можете попробовать ещё раз через пол года, когда приедут уже другие менеджеры и всё ещё может получиться. Удачи!

Categories: Microsoft
Posted by Vitalii Tsybulnyk on Monday, December 29, 2008 5:35 AM
Permalink | Comments (5) | Post RSSRSS comment feed

Рабы Майкрософта

Прочитав одноимённую книгу Дугласа Коупленда не смог удержаться от комментариев. Во-первых, настоятельно советую читать книгу в оригинале, т.к. перевод делали ещё в 90-х какие-то "умельцы", и если бы не более поздние комментарии к переводу вконце книги, многие интересные моменты канули бы в пучине лингвистического коллапса .  Теперь по существу самой книги. Хотя автор вынес название компании Microsoft (а точнее его часть в английском написании) в название книги, на мой взгляд, это больше маркетинговый ход или дань моде, чем суть самой книги. Тем не менее, тема Microsoft всёже проходит красной нитью по всему сюжету, занимая ключевое место в жизнях и помыслах главных героев - выходцев из Microsoft. Что касается точности, с которой передана отмосфера  Microsoft конца 80-х - начала 90-х, то я не могу судить об этом, т.к. в это время грыз гранит арифметики в младшик классах . Однако "ощущение присутствия" довольно полное. Остаётся только порадоваться, что канули в лету те времена, когда сотрудники МС проводили 12-18 часов в день на работе, когда они завидовали сотрудникам Apple, а те в свою очередь завидовали им, когда компания-гигант IBM тысячами увольняла сотрудников, когда зарплата девелоперу в Microsoft была 25-30 тыс в год, когда портрет Билла Гейтса почти приравнивался к иконе, когда "перспективность" компании определялась наличием автомобилей сотрудников на парковке возле оффиса в выходной день и так далее. То были времена становления, бурного роста одних и такого же бурного упадка других... Думаю, книга достойна быть прочитанной - каждый найдёт в ней что-то своё... Те, кто недолюбливают Microsoft, найдут немало материала потешиться тем, как всё было. Те, кто восхищается мощью Microsoft, ещё больше порадуются тему невероятному прогрессу, который очевидно произошёл в компании. А те же, кто умеет читать между строк, смогут просто окунуться в самобытный, противоречивый, занудно-весёлый, интеллектуально-ребяческий мир ИТ-шной молодёжи конца прошлого тысячелетия, детьми которого являемся и мы с вами .

Posted by Vitalii Tsybulnyk on Wednesday, December 24, 2008 6:03 AM
Permalink | Comments (0) | Post RSSRSS comment feed

Как пройти собеседование в Microsoft. Часть 2. Телефонное собеседование.

Если ваше резюме заметили и ваш уровень подготовки подходит для работы в Microsoft, то следующим этапом будет телефонное собеседование. Будьте готовы к тому, что телефонное собеседование может быть и через неделю после отправки резюме (как это было у меня), так что если вы высоко оцениваете свои шансы - лучше начать подготовку заранее. Собеседование проводит на английском языке один из специалистов по подбору персонала из Редмонда, и (по моим впечатлениям) у этого собеседования 3 цели: 1) Пройтись по вашему резюме, подтвердить что вцелом то, что там написано, отвечает действительности, и дополнить необходимые детали. Возможные вопросы: как работает Garbage Collector (для тех кто написал что силён в .Net), назовите 3 любимых технологии (языка программирования), тема дипломной работы, готовы ли рассматривать не-менеджерскую должность (для тех кто был менеджером), что такое стек и очередь и т.п. 2) Выяснить ваш уровень английского. Думаю чтобы пройти их критерий отбора достаточно понимать всё что тебя спрашивают (а говорят они очень чётко и внятно) и чтобы поняли тебя (а у них большой опыть синтаксического разбора ломаного английского). 3) Задать немного вопросов на смекалку или логику. Тут может быть всё что угодно. Самая лучшая подготовка - это прочесть книгу Как сдвинуть гору Фудзи. Мне головоломок не задавали, спросили только как бы я тестировал лифт, но на собеседовании я встречал ребят, которых спрашивали и про 3 лампочки, и про шарики в тёмной комнате и т.п. головоломки описанные в книге. Вот пожалуй и всё. Результат вы узнаете из емейла, который вам обязательно пришлют через неделю-две.

Categories: Microsoft
Posted by Vitalii Tsybulnyk on Friday, December 12, 2008 10:15 AM
Permalink | Comments (2) | Post RSSRSS comment feed

Как пройти собеседование в Microsoft. Часть 1. Отправка резюме.

Вот и пришло время поделиться и моим скудным опытом прохождения собеседования, которое проходит ежегодно огромное количество людей, но тем не менее овеяного не меньшим числом легенд и домыслов. Начать я решил с отправки резюме. Этот этап пожалуй самый простой, но и одновременно по-своему сложный. Первым делом надо определиться куда отправлять резюме. На сайте Microsoft есть возможность отправить своё резюме на любую вакансию любого центра разработки. Однако я бы не стал пользоваться этим способам, т.к. одному Гейтсу известно сколько фильтров и роботов проходят сотни тысяч резюме, отправленных через этот сайт. Я имел выход на одного парня в Microsoft, который поделился прямым контактом HR-а, который с ним работал. За это я упомянул его как того "кто привёл меня в МС" и ему за это дадут денежку. Т.е. я бы советовал отправить резюме непосредственно рекрутеру, но вполне реальтно пробиться и через сайт, надо только отправлять резюме на все возможные вакансии - кто знает где потребности большее и критерии не такие строгие. Далее составляем cover letter. Это, пожалуй, наиболее ответственная часть, т.к. я думаю, что 90% резюме никто не читает и они идут в корзину по причине "неинтересного" cover letter. Приведу свой cover letter дословно: Hello Holly! My name is Vitaly Tsibulnik, I live in Kiev, Ukraine. I am looking for the ability to work in foremost world-wide IT company as Microsoft and grow up in it. I am initiative, perspective, gifted technician with:  - strong academic background (PhD),  - analytical mind,  - substantial experience (5+ years) and knowledge in software development,  - leading and managing abilities and experience. I'd be happy to achieve my goals with your company. Attached is my CV. Thanks for your attention and time. Best Regards, Vitaly Tsibulnik Обащаю внимание, что  - письмо небольшое, не больше 5-6 коротких или 3-4 длинных предложений;  - упомянуто высшее образование (или степень если есть);  - личные качества "initiative, perspective, gifted technician" думаю в разной степени подойдут любому ;  - обязательно упомяните почему хотите в МС: "I am looking for the ability to work in foremost world-wide IT company as Microsoft". Теперь пишем само резюме. Я использовал своё обычное резюме, только добавил вначале развёрнутый параграф о том, почему я хочу в МС и почему МС-у нужен именно такой как я . Не бойтесь себя перехвалить, если вы себя не расхвалите, вами не заинтересуются. В резюме сделайте акцент на образовании, участии в олимпиадах, конкурсах, исследовательских интересах и т.п. - это всё может помочь обратить на себя внимание. И последнее - если вам не ответили. Если прошло 3-4 недели и ответа нет - значит вас не заметили. Скорее всего, вы не прошли робота. Попробуйте перефразировать cover letter и резюме, добавив ключевых слов типа "опытный", "перспективный" и т.п. Думаю, не стоит отправлять резюме по одному адресу чаще, чем раз в полтора-два месяца, а то можно угодить в спам-фильтр (кстати, идея отправить с другого e-mail'а тоже имеет смысл). Пожалуй это всё на эту тему... удачи!

Categories: Microsoft
Posted by Vitalii Tsybulnyk on Tuesday, December 9, 2008 11:32 AM
Permalink | Comments (1) | Post RSSRSS comment feed

Немного важных закономерностей

Пройдя несколько тренингов в Microsoft, захотелось поделиться очень занятным графическим материалом. Зависимости, отображённые на приведённых далее графиках, большинству из нас известны исходя из личного опыта или профильной литературы, однако лишний раз посмотреть на визуализацию этих зависимостей, я думаю, будет не вредно. Итак, Зависимость стоимости исправления дефекта от стадии жизненного цикла проекта, на которой этот дефект был допущен: Вцелом график интуитивно понятен и не требует особых комментариев, однако для меня стала приятным сюрпризом "особенность" на графике для деффектов, допущенных на стадии Architecture, в районе перехода от стадии Construction к System test. Предоставляю каждому осмыслить её самостоятельно, скажу лишь что ранее она мне в литературе не попадалась, хотя на опыте мы несомненно её ощущаем почти всегда.   Успешность (вклад) участника проекта на разных этапах разработки: Несомненно, наибольший интерес представляет разделение здесь "объективной" успешности (сплошная линия) и "субъективной" (пунктирная), т.е. видение своей успешности самим участником. Если "объективная" кривая очевидна и понятна всем, по "субъективную" лично я в литературе никогда раньше не встречал и знал о её существовании только интуитивно. Знание и понимание этих закономерностей ценно не только для менеджера, которому это может помочь в нужный момент поддержать мотивацию членов команды и командный дух, но и для каждого участника, т.к. даёт возможность правильно рассчитать самонагрузку и избежать психологических перегрузок. Думаю, сознательное и умелое использование этих знаний могло бы уберечь немало "сгоревших на работе" или "опустивших руки" девелоперов от ухода из проекта и даже сохранить целые команды, однако только в Microsoft я впервые столкнулся как минимум с пониманием и демострацией этих закономерностей.

Posted by Vitalii Tsybulnyk on Monday, December 8, 2008 7:45 AM
Permalink | Comments (0) | Post RSSRSS comment feed