Отчет о Microsoft SWIT 2010

Наверно, уже все знают, что в конце прошлой недели (2-3 декабря) в Киеве прошла конференция MS SWIT 2010. Ее участники и организаторы писали об этом событии в твиттере, на хабре, и в своих личных блогах. А так как я тоже там был с моими коллегами из AltexSoft, мед-пиво пил, то мне тоже хотелось бы поделиться своим видением и некоторыми размышлениями.

Сначала немного о стратегии

Если анализировать то, что говорилось в кейнотах и тематику большинства докладов, то одна из основных стратегических целей Microsoft на данный момент – развитие облачных технологий. Azure появился года два назад, но если раньше стеку технологий и инструментарию очень многого не хватало, то сейчас ситуация обстоит намного лучше. Microsoft уже открыла несколько больших дата-центров во всех уголках мира и судя по всему планирует хорошо зарабатывать на их “аренде”. Кроме того, внедряется идея продажи личного облака в датацентре: покупаем контейнер нужного размера (мощности), привозим себе в организацию (или даже домой), подключаем коммуникации и сетевые компьютеры – и вуаля, все работает. Нужно сказать, что с точки зрения ПО здесь все тоже уже намного лучше: все основные продукты Microsoft уже переведены на сервисную модель и доступны для установки в облако и для использования оттуда.

Похоже, мы все ближе и ближе возвращаемся к идее использования терминалов: у обычных пользователей будет домашний нетбук (возможно, с большим экраном), планшет или мобильное устройство, на котором будет минимум программ и максимумально широкий канал в Интернет, откуда все эти программы и будут запускать в режиме SaaS. Google тоже идет по той же дорожке со своей Google Chrome OS, которая будет внешне работать практически из браузера.

С точки зрения хостинга различных веб-приложений, здесь тоже работа не стоит на месте. На данный момент Windows Azure уже поддерживает PHP, Python, Ruby и Java. Причем PHP и Java – с довольно неплохим дополнительным набором инструментов, включая SDK и плагины к Eclipse, которые позволяют работать с облаком почти так же удобно, как из Visual Studio. Можно сделать вывод, что Microsoft хочет стать очень весомым игроком на рынке хостинга приложений в частности и облачных технологий в целом. И это, конечно же, правильное решение: облака и SaaS-решения сейчас набирают популярность, и если удастся перетащить в облако корпоративных клиентов – это сулит очень большие прибыли компании.

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

Следующая тема – конечно же, Windows Phone 7. Честно говоря, был очень удивлен, когда не услышал о нем ровным счетом НИ-ЧЕ-ГО в кейнотах. Тема-то животрепещущая, телефоны только-только появились на прилавках магазинов и рынок разработки под WP7 только начинает открываться. Ну да ладно, надеюсь, трех докладов по теме было достаточно для общего понимания, а заинтересовавшиеся найдут более полное и структурированное описание концепции и обучающие материалы в Интернете.

 

Если говорить о собственных впечатлениях, то с одной стороны, мне устройство нравится как разработчику и потенциальному обладателю, а с другой – все-таки видны некоторые проблемы первой версии, которые наверняка исправятся в течении полугода или с выходом следующей версии OS. Так что ко времени когда мой Sony Ericsson выйдет из строя (а он уже подает такие признаки), можно будет уже всерьез задуматься о WP7 vs. Android или iPhone.

Самое интересное начинается, если посмотреть ситуацию на рынке мобильных устройств. По данным Gartner у Windows Mobile в Q3 2009 было 8%, а в Q3 2010 – всего 3% рынка. При этом Android вырос с 3.5% до 25.5% за счет Symbian, RIM и Windows Mobile, а iPhone/iOS почти не изменил процентное соотношение, тем не менее продав почти в 2 раза больше устройств, чем в 2009 году. То есть рынок вырос почти в 2 раза за один год! С выходом WP7 ситуация для Microsoft должна улучшится. У Microsoft есть полноценная платформа разработки, полный спектр инструментов и армия .NET-разработчиков. В любом случае нам, как потребителям, конкуренция между платформами Symbian, iPhone/iOS, Android, WP7 уж точно не помешает – чем больше производителей, тем больше возможностей, качественнее устройства и дешевле цены.

В связи с этим хочется сказать, что ближайшие полгода-год – это лучшее время для выхода на рынок разработки под WP7. Причем с точки зрения аутсорсинга тоже. Реклама Microsoft идет усиленными темпами, устройства становятся все популярнее, а приложений на них все еще мало. Так что если есть время и желание – придумывайте идею и реализуйте ее. А если своих идей пока нет – возьмите топ приложений для Android и iPhone – я думаю, это улучшит вашу креативность :) Благо, в этот раз инструментарий для разработчиков уже под рукой и давно известен – это Silverlight и XNA. Если у Microsoft все получится с этой платформой , то со временем выйти на рынок со своим продуктом будет все тяжелее и тяжелее.

Теперь о докладах

Остальные доклады были точечные, зато их спектр был достаточно широким. Участники могли послушать про ASP.NET MVC, jQuery, ASP.NET Dynamic Data, F#, TPL/PLINQ, SQL Server 11, Workflow Foundation 4.0, Entity Framework 4.0 Code-First, Sharepoint 2010, различные возможности Visual Studio 2010 для QA и архитекторов и даже Agile-разработку. Список докладов до сих пор висит на сайте SWIT. Возможно, со временем там будут и видео, которые можно будет посмотреть.

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

К сожалению, я не смог побывать на всех докладах (на все три трека одновременно не успеешь), поэтому из виденных мною выделю доклады Андрея Терехова по F# (самый зрелый и интересный для меня доклад, единственный, где мне показалось, что я сижу не в Киеве на SWIT, а как минимум на NDC), Дмитрия Малеева по ASP.NET MVC 3.0 (тема не особо позволяла ему разбежаться, но как он зажег, молодец!) и Александра Манжулы по TPL/PLINQ (затянул доклад, но сразу видно, что парень основательно готовился, хотел рассказать побольше, и самое главное – смог визуализировать эту достаточно сложную тему и подать ее так, что не понять мог только ленивый). Хотелось бы также похвалить Константина Косинского – у него всегда хорошие доклады, так как он разбирается в том, о чем рассказывает, что случалось далеко не всегда на конференции, и кроме этого, он хорошо подает материал.

Вообще, самый главный мой вывод из конференции – это то, что в споре что важнее, мастерство докладчика (под этим я понимаю не только умение подать материал, но и предварительно его структурировать, подготовить презентацию, примеры) или быть профессионалом в теме, побеждает мастерство докладчика. Мало в совершенстве владеть материалом. Если ты не можешь его интересно подать – отдача будет низкой. В то же время отличный докладчик может сделать запоминающийся доклад даже из темы, в которой слабо ориентируется. В идельном докладчике это соотношение должно быть где-то 70 на 30, как и у идеального педагога.

Напоследок, об организации

С точки зрения организации все было также хорошо. Уведомления по email, горячая линия, трансфер до места проведения, обилие еды, чая и кофе, развлечения (XBOX, Kinect), афтепати – все было организовано на должном уровне. Фото и видео с девчонками, танцующими под Kinect, обошли твиттер и небольшую часть рунета :) Ребята, бывавшие на других подобных мероприятиях и видевшие больше меня говорили, что это далеко не предел, что много чего можно было сделать лучше, и я им верю – есть еще куда расти. Но Москва-то ведь тоже не сразу строилась, правда?

Отдельная благодарность за возможность посмотреть keynote Scott Guthrie на конференции Silverlight Firestarter в онлайне. Посмотрели на возможности Silverlight 5.0 :).

А теперь немножко покритикую. Постараюсь быть конструктивным:

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

2) Многие доклады были обзорными, уровня 100, иногда даже просто рекламными, в них было мало полезного для серьезных разработчиков. Конечно, они тоже нужны, но также хотелось бы больше технических докладов, уровня 400 или хотя бы 200. Да и неплохо было бы указывать уровень доклада в расписании. Возможно, это конференция не того формата, но тогда где найти ТОТ формат? DevDays? Там ситуация очень похожая, если мне не изменяет память. Локальные user groups? В общем, пока под вопросом.

3) Некоторые доклады были не согласованы. Было много повторов, когда одно и то же рассказывают по очереди разные докладчики. Даже по кейнотам это было заметно.

4) Хотелось бы увидеть больше приглашенных докладчиков. Думаю, это сразу же поднимет уровень посещаемости конференции. Понимаю, что привезти Phil Haacked или Scott Hanselman будет очень сложно, но может кто-то еще согласится?

Ну вот и все. Хочется еще раз сказать спасибо организаторам. Надеюсь, SWIT 2011 будет и он будет ярче и круче, чем SWIT 2010.

Взвешенный подход к Agile

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

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

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

Также мне всегда было непонятно, почему тот же Scrum часто огульно описывается как панацея от всех бед, хотя совершенно ясно, что он подходит не для ВСЕХ проектов, и не для ВСЕХ команд. Как и waterfall, как и TDD, как и что угодно, серебряной пули же нет. В некоторых случаях Scrum просто менее эффективен, чем другие методологии, а иногда совершенно не подходит.

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

Сначала появилась статья, в которой хорошо описывались основные проблемы и давалась краткая выжимка фактов с предложением “быть честными”: http://www.whattofix.com/blog/archives/2010/09/agile-ruined-my.php (русский перевод здесь: http://experience.openquality.ru/agile-ruined-my-life/)

“Люди думают, что можно взять увечный проект, который уже не жилец, добавить немного Agile и заявить, как это было круто. Да ладно, ребята, никого так провести не удастся. Все точно знают, что это пропаганда. Хуже того, вовлеченные эксперты оказываются последними, кто узнает о тщетности таких действий на публику. На своем опыте они «обучаются» неправильным вещам и «делятся» своим знанием с новыми командами, продолжая дерьмовый цикл.”

“Одна из первых истин, которой учат в Scrum-классах: Scrum – не волшебная пуля. Оставшуюся часть времени вам говорят, что это лучшее изобретение человечества после нарезного хлеба. Все мы встречались и работали с парнями, у которых всегда есть ответ на любой вопрос – нужно только спросить. Решения уже приняты для любой задачи, которая у вас может быть. Такие люди чрезвычайно раздражают. Все равно что говорить со стеной. Плохо, плохо.”

“Работает ли Agile для распределенных команд? Смотря по обстоятельствам. Можно ли использовать двухнедельные отметки для оценки проектов? Смотря по обстоятельствам. Работает ли Agile в проектах по разработке встроенного ПО? Смотря по обстоятельствам. Черт! Всё зависит от обстоятельств. Порой как бы сильно я ни пытался быть вежливым, честным и открытым, я становлюсь похожим на тех ребят из Матрицы, когда вы смотрели ее первый раз. Они говорят много, но на самом деле это мало что значит. Звучит напыщенно, но по сути чепуха. Ненавижу давать такие советы. Знаю ребят, которые ненавидят их слушать.”

Были и другие статьи, все перечислять не имеет смысла. Но написать эту заметку меня натолкнул Боб Мартин, написавший статью “What Killed Waterfall Could Kill Agile”, в которой высветил проблему элитарности, присутствовавшей в водопадной разработке и проявляющейся, как он считает, в Scrum. Конечно, Боб выгораживает XP и наезжает на Scrum, но его слова не лишены смысла:

“The elitism engendered by Waterfall was being attacked. Neither Scrum nor XP had any role for an elitist who assumed authority without taking responsibility. In Scrum, the rule of the team is stronger than the rule of an Architect or Designer. Contributions are welcome, but not necessarily followed.”

“I didn’t think thousands of people would be lining up to get their certifications. But I had not considered the lure of elitism. It didn’t occur to me that this special training course, coupled to the term Certified Scrum Master, would become a wedge to break the alignment between authority and responsibility.”

“Indeed, the role of Scrum Master is considered so important, that it requires certification to obtain. If your Scrum team does not have a Certified Scrum Master, then something must be wrong with you.”

“The elitism is back, and it’s growing. More courses with certifications are available, and even more are envisioned. Other training companies are offering their own certifications. After all, the lure of elitism is a great moneymaker. The snowball is rolling down the mountain, and getting bigger with each turn.”

Agile – это хорошо. XP, Scrum, Kanban, Lean содержат множество прекрасных практик и подходов, как технических, так и организационных, которые помогают создавать отличные продукты, справляться с сложностью, изменениями. Но нужно действительно быть честными и не превращать его в бизнес.

Google AI Challenge

Недавно из блога Плахова узнал про конкурс Google AI Challenge. Конкурс очень интересный, и битвы топ-ботов очень впечатляют (для примера: один, два и три). В результате меня так зацепила простота идеи и в то же время сложность алгоритмов, что я тоже решил попробовать свои силы.

Google AI Challenge – это конкурс, в котором соревнуются не люди, а запрограммированные боты. Правила очень просты и основаны на игре Galcon. Есть двухмерная карта с планетами, каждая из которых характеризуется двумя параметрами: количеством войск и их приростом за ход. Планеты могут быть нейтральными, а могут принадлежать одному из двух соперников. Количество войск на нейтральных планетах не увеличивается. За ход одна или несколько планет могут отправить несколько флотов с определенным количеством войск в направлении других планет. На карте учитываются расстояния между планетами, поэтому на то, чтобы долететь, каждому флоту требуется несколько ходов. При прибытии флота на нейтральную или вражескую планету происходит схватка, в которой побеждает тот, у кого больше войск. Таким образом, чтобы захватить планету, нужно отправить на нее флот или несколько флотов с количеством войск на 1 больше, чем у противника. В то же время не нужно забывать, что за время прибытия вашего флота на планету количество войск на ней может увеличиться как за счет прироста населения, так и за счет быстро переброшенных войск противника. Это если вкратце, на самом деле количество вариантов бесконечно велико и это-то и составляет прелесть конкурса.

Писать ботов можно почти на любом языке программирования, включая даже JavaScript и PHP. Стартовые наборы (стартовый бот + соперники) есть для Java, Python, C++ и C#. Для остальных языков придется писать стартового бота самому.

Немного о своем текущем опыте. На данный момент я засабмитил вторую версию бота. Первую – в четверг, вторую – сегодня (воскресенье).

Первую версию я писал три вечера и основной целью было добиться, чтобы он научился побеждать 5 тестовых ботов на 100 картах (доступны в стартовом наборе) в большинстве случаев. Если описывать алгоритм в общем, то бот умел делать оптимальные первые хода, захватывая нейтральные планеты, защищать свои планеты (только самозащита на данном этапе) и очень неоптимально атаковать противника. Такого простого алгоритма оказалось достаточно, чтобы побеждать тестовых ботов в 99-100 случаях из ста. И этого оказалось достаточно, чтобы будучи засабмиченным в контест мой бот попал в топ-800, болтаясь там между 600 и 800 местами. К слову, на данный момент соперников чуть меньше 4000.

Во второй версии я научил бота коллективной защите и пофиксил пару багов. Это то, чего ему очень не хватало в битвах с соперниками. Конечно, это не даст ему возможность попасть в топ-100, но, надеюсь, он поднимется на 100-200 мест вверх.

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

В соревновании очень своеобразное ранжирование. Моего первого бота судьба сходу свела с ботом из 4-й сотни и после победы он сразу попал в топ-300. Затем, правда, был долгий путь вниз, пока он не сбалансировался в районе 700-го места. Второй же бот попал на товарища с 3100-какого-то места и после победы поднялся всего лишь на 3000-ю позицию. Не возникает сомнений, что за пару дней схваток он поднимется выше как минимум до того же 700-го места, но все-таки процесс выбора первого боя немного странноват. Random, что ли?

Если я вас заинтересовал, то сообщаю главную информацию. Соревнование будет длится еще почти целый месяц (!), до 27 ноября, так что у вас есть все шансы попробовать.

Несколько полезных ссылок:

• Сайт контеста: http://ai-contest.com/
• Секция форума, посвященная стратегии: http://ai-contest.com/forum/viewforum.php?f=17
• Отличная программа для тестирования своего бота: http://ai-contest.com/forum/viewtopic.php?f=18&t=748

Ну, и прочитайте алгоритм, который предлагает Плахов и обсуждение различных стратегий на форумах. Я там не знаю названий половины алгоритмов. Shame on me, в общем.

Кстати, если вы решите использовать C#, то учтите, что на сервере Mono 1.2.6, а это значит, что вы можете использовать только C# 2.0. Организаторов уже давно просили поставить на сервер Mono 2.0 (поддержка C# 3.5), однако те злобно морозятся. Не хотят плодить конкурентов, наверно ;) Подробнее здесь.

Ну, и напоследок. Если есть вопросы – спрашивайте. Если решите поучаствовать, мой аккаунт – AlexMerle. До встречи в бою :)

Железный треугольник

В последнее время на собеседованиях сталкиваюсь с тем, что не все люди, претендующие на роль team/dev lead, знают про железный треугольник. Хочется немного осветить этот вопрос. Сразу скажу, что опытные PM’ы не найдут для себя ничего нового в этой заметке, она ориентирована на тех, кто еще только начинает изучать проектный менеджмент.

Итак, железный треугольник (iron triangle, project management triangle) – это абстракция, описывающая взаимодействие основных атрибутов или характеристик проекта: объема работ, сроков и ресурсов (команды, а следовательно и бюджета). Выглядит он обычно так:

 

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

Смысл этого треугольника в том, что ограничения на объем работ (scope), сроки (time/schedule) и бюджет (cost/budget) должны быть разумными, и любой менеджер проекта должен уметь ими управлять. В противном случае проект рискует стать провальным.

Наверняка каждый, даже не занимающиеся непосредственного управлением проектами, сталкивались с ситуациями, когда оценка на разработку системы или ее куска превышает либо сроки, за которую необходимо сделать работу, либо бюджет, имеющийся у клиента. А может, сталкивался и с такими ситуациями, когда эта самая работа должна быть сделана в указанный срок ограниченными ресурсами (командой). Эту последнюю ситуацию как раз и называют железным треугольником, то есть треугольником, в котором все наши три вершины ограничены и зажаты, и у нас нет свободы действий ни по одной из них. И чем экстремальнее это “зажимание”, тем сложнее команде выполнить взятые на себя (или пообещанные кем-то сверху) обязательства.

Как же бороться с железным треугольником? Так же, как и с deadlock’ами – стараться не создавать предпосылок для его появления :)

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

1. Клиент более важно иметь продукт готовым полностью (ограничен объем работы), и у есть бюджет лишь на определенную команду. В таком случае сроки выполнения работ выбираются нами (отталкиваясь от оценки, а также размера и качества команды) или вообще делаются варьируемыми, если это возможно. Здесь нужно понимать, что этот вариант возможен лишь когда у клиента ограничен месячный или квартальный бюджет, если не хватает бюджета на весь проект, то нужно искать уже пути удешевления производства: покупка или использование сторонних разработок, использование более “дешевой” рабочей силы (аутсорсинг), экономия на качестве. Варьирование сроков здесь никого не спасает.
2. Клиент хочет иметь продукт готовым полностью в указанные сроки. Единственный разумный (!) вариант здесь – увеличение команды. Не очень разумные варианты вроде сверхурочные работы тоже имеют право на жизнь, но их нужно использовать ОЧЕНЬ аккуратно. С увеличением команды тоже есть один нюанс: оно не всегда приводит к желаемому результату. Во-первых, новым людям нужно время на вливание в проект (если он уже идет). Во-вторых, не все задачи хорошо параллелятся – часто задача Б может быть сделана лишь только после завершения задачи А, поэтому добавлять людей для выполнения задачи Б нет смысла. В-третьих, большее количество людей в команде ведет к увеличению времени на их координацию и общение между собой, что увеличивает оценку объема работ и, следовательно, бюджет. То есть, опять же, клиент платит больше. Все это ведет к тому, о чем говорил еще дядюшка Брукс (перефразируя): 9 женщин не родят ребенка за 1 месяц.
3. Клиент хочет иметь продукт в указанные сроки, но у него нет бюджета на увеличение команды. В этом случае единственная наша возможность – это варьирование объема работы, т.е. приоритезация задач проекта и договор сделать лишь те, что мы успеем, с учетом приоритетов. Менее важные задачи рискуют оказаться за границами продукта к дате релиза.

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

В железный треугольник можно попасть и в середине проекта. Причин может быть много: промах в оценке трудозатрат, давление со стороны руководства, в конце-концов, приход на уже идущий плохо спланированный проект. Что делать в случае, когда контракты уже подписаны?

Прежде всего, не паниковать :) Не вы первые, не вы и последние – по разной статистике в IT около 20-25% заваленных проектов, и еще около 45-50% – вышедших за рамки запланированных бюджетов, сроков, либо выпущенных не полностью готовыми (не вся функциональность либо плохое качество).

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

А как вы решаете эту проблему?

Слушаете ли вы подкасты?

Я иногда публикую списки интересных подкастов, уже 4 выпуска набралось, но судя по посещаемости на dev.net.ua и Google Analytics, а также комментариям – эта тема не пользуется большой популярностью. Исходя из того, что на выпуски уходит определенное время, хотелось бы узнать, насколько прослушивание подкастов популярно и стоит ли продолжать делать обзоры.

Я создал два опроса в правой панели: “Слушаете ли вы подкасты?” и “Интересны ли вам обзоры подкастов?”, благодаря которым хочу выяснить эти моменты и определиться с дальнейшими действиями.

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

PS. Добавил третий вопрос. Буду признателен, если ответите и на него.

Список интересных подкастов: выпуск #4

Новая подборка интересных подкастов, которые я бы рекомендовал к прослушиванию. Сегодня разбиваем на категории:

.NET 4.0:

• .NET Rocks #517. Jason Olson Digs into the CLR 4.0

Jason Olson проходит по некоторым новым фичам CLR, C# и BCL. Concurrent GC, side-by-side CLR versions, Memory-Map files, co-variants и contra-variants, Parallel Extensions, немного об обновлениях в языках программирования и новых языках. И да, они наконец-то выкинули CAS и заменили его на более простой механизм. Хотя кто его вообще использовал :)

• .NET Rocks #515. Stephen Walther On ASP.NET AJAX 4.0

Небольшой обзор изменений в ASP.NET AJAX 4.0. От UpdatePanel до полностью кастомных AJAX-запросов и JavaScript-контролов. jQuery теперь "часть" ASP.NET AJAX, переработанный AJAX Control Toolkit - тоже, более того, AJAX Control Toolkit теперь работает не только с WebForms и MVC, но даже с PHP или любым другим back-end'ом. ASP.NET AJAX поддерживает dual data-binding на клиенте, который работает по аналогии с дата контекстом EF или L2S, на сервере его поддерживает WCF Data Services, которые раньше назывались ADO.NET Data Services. На закуску немного о ScriptLoader, history API, Microsoft CDN, Microsoft AJAX Minifier, Sea Dragon и Deep Zoom.

• .NET Rocks #514. Julie Lerman on Entity Framework 4.0

Честно говоря, еще сам не слушал этот подкаст, но судя по транскрипту - довольно любопытно. Foreign Keys, POCO и поддержка DDD разработки и модульного тестирования, Lazy/Deferred Loading, поддержка N-Tier сценариев при помощи Self-tracking entities, T4 templates, Code Only (в общем, все то, о чем я уже когда-то писал), немного о WCF Data Services, а также история о том, как Julie помогала Oren Eini (Ayende) создавать EFProf.

• .NET Rocks #377. Ted Neward and Amanda Laucher on F#

Обсуждение возможностей первого функционального языка программирования, включенного в .NET 4.0. Немного о том, что такое функциональные языки вообще, зачем нужен функциональный язык в .NET и какую пользу он может принести обычным разработчикам, привыкшим к императивным языкам вроде C#, VB.NET, Java или С++, некоторый ликбез по терминологии функциональных языков. Много интересного контента и шуток благодаря Теду.

• Hanselminutes #197. The Dynamic Language Runtime, IronRuby and IronPython with Jimmy Schementi

Интервью с програм менеджером DLR team. Конечно же, обсуждение DLR, который релизится с .NET 4.0, и его двух основных языков: IronRuby и IronPython. Разговаривают об архитектуре DLR, истории развития, возможностях, отличиях Iron-версий языков Ruby и Python от своих оригиналов, IronRuby on Rails :)

Другое:

• Hanselminutes #186. .NET Debugging 101 with Tess Ferrandez

И снова непревзойденная Tess. О чем еще с ней можно поговорить, как не об отладке. Что такое Memory Dump, как его создавать и почему об этом важно знать, что такое Allocated и Committed memory, как пользоваться WinDbg и CDB для отладки "утечек памяти" в .NET и проблем с производительностью, а также некоторые улучшения с отладкой многопоточных приложений в VS2010 и в предыдущих версиях, о которых вы, возможно, не слышали.

• Hanselminutes #202. A different way to do ASP.NET WebForms with WebFormsMVP

Интервью с создателем WebFormsMVP - очень интересного MVP-движка для WebForms. Автор рассказывает, что такое MVC и MVP, зачем использовать паттерн MVP в WebForms приложениях, архитектуре движка, особенностях его использования и том, насколько полно он работает с остальной инфраструктурой ASP.NET. Надо будет обязательно попробовать его в боевом проекте - по идее, должен сберечь кучу времени и сил.

• SpBaltNet #5. SOLID, TDD и прочие показатели качества кода

Приятно, что в нашем уголке мира появляются хорошие подкасты :) В гостях у питерской группы ALT.NET подкаста Александр Бындю и Виталий Стахов. Разговор идет о вполне понятных вещах: принципах ООП (SOLID), TDD, практиках XP, полезных инструментах, развитии программиста и различных вариантах построения и развития команд. Прикольно, что Александр Бындю точно так же понимает разницу между Scrum и XP, как и я.

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

• SpBaltNet #7. Domain-Driven Design и CQRS

Обсуждение Domain-Driven Design и CQRS (Command and Query Responsibility Segregation pattern) с Мишей Чалым и frozen_space. Если про DDD многие хотя бы краем уха слышали, то что такое CQRS для меня для самого тайна :) Где помогает DDD и зачем он нужен, что такое CQRS, его преимущества и недостатки. В общем, самое острие программной инженерии - не пропустите! Подкаст только записали, завтра буду слушать сам.

И напоследок, как всегда, тема попроще :)

• Hanselminutes #194. Hello World: Computer Programming for Kids and Other Beginners

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

Приятного прослушивания!

Слайдкаст по принципам проектирования

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

Должен сказать, я надеялся, что это будет легче. Лепил я его в течении нескольких дней, сначала более-менее приведя в порядок звук (хотя некоторые мои мэканья, неверные стилистические обороты и дыхание кое-где пооставались, извините), потом вдоволь навоевавшись с конвертором презентаций Slideshare (было несколько проблем с нежеланием конвертировать и неверным отображением), и в заключение победив их не самый безбажный редактор слайдкастов. Но все-таки приятно, что на Slideshare есть возможность создавать слайдкасты - это действительно здорово.

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

Надеюсь, кому-то это все будет полезно, несмотря на несколько ошибок в содержании, которые я допустил.

Design Principles

View more presentations from AlexMerle.

Если вдруг слайдкаст не открывается из блога - вот прямая ссылка.

Принимаются любые пожелания по улучшению.

PS. И спасибо Вове Лещинскому за микрофон!

Доклад о принципах проектирования

Готовлю еще один доклад для харьковской Uneta по принципам проектирования.

Основные цели:

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

Доклад будет частично построен на заметке о качественном коде и проектировании. Частично, потому что этот материал пойдет лишь в начало доклада, а в основной его части я планирую все-таки рассказать про популярные на данный момент принципы проектирования (как общие, так и ООП): SoC, DRY, KISS, YAGNI, Low Coupling, High Cohesion, а также пятерку SOLID. Принципов много, и каждый из них, конечно, достоин отдельного небольшого доклада, поэтому придется рассматривать их достаточно поверхностно. Также очень хочется успеть дать какие-то взаимосвязи между ними, чтобы они лучше запоминались, и хотя бы пару примеров. Таким образом, доклад будет больше посвящен теории, а не практике.

Вторым докладчиком будет мой бывший одногруппник Денис Резник. Тема его доклада: “Защита данных в SQL Server 2008 при помощи Transparent Data Encryption”.

Встреча будет проходить в Харьковском национальном университете радиоэлектроники (ХНУРЭ), пр. Ленина 14, ауд. 329 (м. Научная), 5 марта 2010 в 18:25, то есть в эту пятницу вечером.

Если что-то изменится с местом, временем или форматом встречи – я сообщу дополнительно в комментариях.

Жду всех, кто захочет послушать и пообщаться на эту тему :)

Архитектура по Фаулеру

Пару дней назад наткнулся на статью Фаулера "Кому нужен архитектор?" ("Who Needs an Architect?"). Ей уже сто лет в обед, но я ее первый раз вижу.

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

"Whether something is part of the architecture is entirely based on whether the developers think it is important. People who build “enterprise applications” tend to think that persistence is crucial. When they start to draw their architecture, they start with three layers. They will mention “and we use Oracle for our database and have our own persistence layer to map objects onto it.” But a medical imaging application might include Oracle without it being considered part of the architecture. That is because most of the complication is in analyzing the images, not in storing them. Fetching and storing images is done by one little part of the application and most of the developers ignore it."

А вот еще кусочек:

"There is no theoretical reason that anything is hard to change about software. If you pick any one aspect of software then you can make it easy to change, but we don’t know how to make everything easy to change. Making something easy to change makes the overall system a little more complex, and making everything easy to change makes the entire system very complex. Complexity is what makes software hard to change. That, and duplication."

Это волшебно. Рекомендую почитать.

Если понравится, можно почитать еще пару интересных статей на тему архитектуры и проектирования:

Gaperton on Software Architecture - статья Gaperton о похожем с примерами и заодно с пояснениями, как согласуется архитектура с дизайном
The Difference between Marketecture and Tarchitecture - статья о компонентах архитектуры: Market-oriented и Technical-oriented
Is Design Dead? - статья об эволюционном проектировании, много разговоров на тему того, что ХР - это супер-пупер, но в целом есть что полезного почерпнуть

Что думаете?

PS. Поделитесь чем-нибудь интересным на эту тему.

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

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

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

Свойства качественного кода

Какими же свойствами обладает качественный код:

• расширяемость, гибкость (extensibility, agility)
• сопровождаемость (maintainability)
• простота (simplicity)
• читабельность, понятность (readability, clarity)
• тестируемость (testability)

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

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

Итак, теперь мы лучше понимаем, что означают абстрактные слова "хороший код", "правильный код" и т.д. Это код, который обладает полезными внутренними качествами (ценностями).

Как же достичь хорошего кода?

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

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

Внешние способы достаточно результативны, однако они всегда являются лишь дополнением внутренних. Если программист не обладает навыками правильного написания кода и проектирования, парное программирование с более сильным товарищем или code review ему поможет. Но что делать, если они оба не обладают этими навыками? Поэтому для каждого программиста, кроме знания инструмента (языка программирования, технологий) важно также и умение ими пользоваться (я уже когда-то об этом писал). Это 2 разных, ортогональных друг другу направления развития.

Итак, рассмотрим один из внутренних навыков, а именно навык проектирования (design).

Зачем каждому программисту иметь навыки проектирования

Многие программисты думают, что проектирование - это какая-то специальная фаза при разработке ПО, считают ее сложной и не всегда нужной. Строят там какие-то заумные дяди какие-то UML-диаграмки и прочую чушь. Все равно ведь когда будем писать код - будем половину менять и переписывать. Но ведь на самом деле, проектирование - это не только формальная фаза процесса создания ПО (практически любого), а очень важный (я бы сказал даже необходимый) шаг в программировании. А если выкинуть название "проектирование", то это необходимый шаг в любой человеческой активности. Сейчас объясню на примере, почему. Представим себе, что перед нами стоит какая-то задача. Что мы должны сделать перед тем, как начать ее выполнять? По идее, сначала мы должны понять что нам нужно сделать. Вторым шагом нужно разобраться, как мы будем это делать. И только потом - уже собственно делать! Так и в создании ПО. Сначала мы пытаемся понять, что нужно сделать (анализируем требования, или иногда даже анализируем желания клиента и создаем требования по ним). Затем мы пытаемся разобраться как мы будем это делать (по сути, проектируем, как будет выглядеть результат, чтобы не переделывать десять раз). И только потом берем клавиатуру в зубы и идем программировать. Однако здесь важно понимать одну очень важную деталь: результат проектирования (проект) не обязательно должен быть вырезан в камне диаграммах UML и документах, а вполне может быть сделан на доске, куске бумажки или даже просто в голове, если этого достаточно. Так что отсутствие конкретной формальной фазы еще не значит, что программисты не занимаются проектированием какого-то куска кода, базы данных, UI прототипов или даже микро-архитектуры. Занимаются. Это и есть проектирование, просто менее формальное.

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

Технический долг

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

Также эта метафора объясняет, почему иногда приходится писать код быстро, не тратя времени на правильное проектирование. Как и с точки зрения финансов мы берем деньги в кредит/долг для более быстрого достижения поставленной цели, здесь мы это также делаем для более быстрого получения результата. Однако мораль сей басни такова, что не нужно забывать, что за подобные действия мы будем расплачиваться в дальнейшем.
Более подробно о техническом долге можно почитать у Фаулера и Jeff Atwood.

Рецепты правильного проектирования

Хорошо, теперь мы знаем, что есть свойства хорошего кода (ценности), и что проектирование может нам помочь достичь их. Но как это сделать? Какие есть рецепты?

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

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

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

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

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

На вершине пирамидки располаются наши ценности (свойства), которых мы хотим достичь. Чуть ниже располагаются принципы - в какой-то степени они описывают правила, используя которые мы можем достичь наших ценностей. Еще ниже - паттерны, как более низкоуровневые рецепты. И в самом низу - обыкновенный код.

Однако данная пирамидка совсем не обозначает, что нельзя достичь вершины, не зная те же паттерны или принципы. Очень даже можно, вот только не факт, что в полученном результате их не будет :) Да и зачем изобретать велосипед, если можно использовать наработки таких умных и известных инженеров, как Бек, Гамма, Фаулер, Лисков, и множество других. Понимание и разумное использование принципов и паттернов помогает достигнуть вершины быстрее и с меньшими трудозатратами.

Мне кажется, что информации по паттернам проектирования уже очень много, а вот с принципами все не так просто. Поэтому в следующих частях я постараюсь осветить принципы проектирования, и не останавливаться только на SOLID.

Лучшие фотографии 2009 года

Извините, после Нового года программирование в голову лезет слабо, поэтому будет еще одна заметка с фотографиями :) Надеюсь, они вам понравятся, а чуть позже обещаю исправится - снова начну писать на профессиональную тематику.

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

#1 Святыня Харькова

#2 Снегопад

#3 Александро-Невская лавра

#4 Ночь в Русском музее

#5 Исакиевский собор

#6 Карпатский рай

#7 Шипот Карпат

#8 Боржава

#9 Закарпатье

#10 Проселочная дорога

#11 В открытое море

#12 Фиолент

#13 Костел Св. Марии Снежной

#14 Речная прогулка

#15 Чертовка

 

#16 Осень

#17 Закат

#18 Этюд в червоных тонах

#19 Спокойствие

#20 Цвингер

#21 Дрезден

#22 Телч

#23 Святой

#24 Игрушечный город

Отпуск в Чехии #3: Южная Чехия

Чешский цикл:

Отпуск в Чехии #1: Чехия и Прага
Отпуск в Чехии #2: Карловы Вары и Дрезден
Отпуск в Чехии #3: Южная Чехия

---------------------

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

Южная Чехия прекрасна. Нет, не так. Она просто восхитительна! Сложно подобрать слова для выражения восторга от этих мест! Чего стоит только постоянно петляющая между зелеными холмами и лесками дорога, периодически вплетающаяся в лес и змеящаяся в нем зеленым тоннелем с полукругом света где-то в конце. Добавьте к этому золотое начало осени - и вы получите идеальный с точки зрения живописца пейзаж. Если вы играли в NFS5 и помните карты Шварцвальд и Пиренеи, то вы меня поймете...

А теперь немного о местах, которые мы посетили.

Червена Лгота

Червена Лгота - это небольшой средневековый замок первой половины XVI века, расположенный посередине пруда и окруженный лесом с трех сторон. Замок был жилым до Второй мировой войны, после которой его хозяева (немцы) были лишены права собственности и замок перешел государству. Изначально замок представлял собой готическую постройку, но был перестроен в готике и ренессансе в начале XX века.

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

Замок со стороны

Если начать обходить пруд с левой стороны, то вы попадете на красивую лужайку, откуда открывается прекрасный вид на замок. По пруду можно поплавать на лодке, но у нас было мало времени, поэтому не удалось. Но нескольких ребят видели.

Замок со стороны

Замок однозначно стоит того, чтобы его посетить.

Телч

Телч - это город в Чехии, центр которого занесен в список всемирного наследия Юнеско. Основан предположительно в XI веке, а впервые упоминается в письменных источниках в 1333 году, когда Телчский замок был куплен Карлом IV (да-да, тем самым). Меня вообще постоянно в Чехии радовало, как все эти графы, бароны и короли покупали друг у дружки замки и целые города. Кстати, им тоже какое-то время владели Лихтенштейны. Со временем вокруг замка выросло поселение, которое теперь стало небольшим городом.

Центральная Захариева площадь

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

  Чумной столб, фонтанный комплекс, собор

Замок тоже достаточно интересный. Его можно назвать полноценным средневековым замком (все-таки Червена Лгота по размерам намного меньше), хотя он построен в стиле ренессанс, а не в готике. В 2007 году замок победил в чешском конкурсе "Самый сказочный замок" и победил заслуженно. Здесь снимались многие детские фильмы.

Замок снаружи и внутри

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

Центр города из-за прудов

На Пикасе лежат еще несколько фотографий с описаниями: Червена Лгота и Телч.

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

Отпуск в Чехии #2: Карловы Вары и Дрезден

Чешский цикл:

Отпуск в Чехии #1: Чехия и Прага
Отпуск в Чехии #2: Карловы Вары и Дрезден
Отпуск в Чехии #3: Южная Чехия

---------------------

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

Карловы Вары

Карловы Вары - это еще один населенный пункт, основанный Карлом IV (тем самым "Петром I" чешского народа, о котором я упоминал в первой части). Рассказывать легенду об основании города долго, ее можно почитать в Википедии. Также этот город известен под названием Карлсбад (немецкое название). Карловы Вары - один из любимейших курортов советского человека, поэтому он, во-первых, известен всем русским туристам, и, во-вторых, процент русского населения здесь скорее всего наивысший в Чехии, что дает возможность комфортно себя чувствовать всем русским. Карловы Вары известны своими горячими минеральными источниками, а также легендарной Бехеровкой - 13-м "источником".

Набережная

Карловы Вары нужно посещать одним из первых пунктов в Чехии, потому что это не самый интересный город на мой вкус, и смотреться после Южной Чехии он не будет. Да, в Варах красиво, но здесь слишком много лоска и слишком мало истории. Главная улица - сплошной поток гостиниц вперемешку с минеральными источниками, парками и туристическими лавками. Гостиницы построены или по крайней мере стилизованы под XVIII-XIX век. Источники располагаются прямо на улице в разных местах.

Стилизация источников

В самом центре находится самый главный источник - первый. Он является гейзером и его убрали под крышу, оградив со всех сторон стеклянными стенами и сделав что-то вроде большого банного помещения, которое обогревается самим источником. Температура гейзера достигает 72 градусов, струя бъет вверх на 10-12 метров.

Гейзер первого источника - Вржидло

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

  Центр города

Наверху вас ждет несколько улиц с очень красивыми зданиями, парк с прудом, православный храм, а также тишина и спокойствие, которых не хватает главной улице. Здесь начинаешь чувствовать город намного лучше.

Сказка

Немного больше фотографий Карловых Вар можно найти здесь.

Дрезден

Дрезден - это совсем другая история, совсем другой город, город с тяжелой судьбой. Дрезден был сметен с лица земли за одну ночь в 1945 году авиацией Британии и Соединенных Штатов. На город, в котором не было военной промышленности, а в основном мирные жители-беженцы, было сброшено столько бомб, что не осталось ни одного целого здания. Город, который поэты называли Флоренцией на Эльбе, был полностью разрушен... Основная часть города была полностью перестроена во времена ГДР, а исторический центр восстановливали больше 60 лет и, думаю, это еще не все.

Набережная Эльбы

Дрезден не блещет историей, но даже крохотный по меркам Праги исторический центр весьма и весьма красив. Здесь находится всемирно известная галерея искусств Цвингер, замок-резиденция саксонских курфюстов, где располагается Грюнес Гевёльбе (Зеленые Своды) - коллекция драгоценностей Веттинов, опера Земпера, и многое другое.

    Замок-резиденция, внутренний двор Цвингера, опера Земпера

Отдельно стоит упомянуть Фрауэнкирхе (нем. Frauenkirche) - величественную церковь Богородицы, один из наиболее значимых протестантских соборов Дрездена. Саксония - это центр лютеранства. Фрауэнкирхе была полностью разрушена во время бомбардировок и власти ГДР решили не восстанавливать ее "в назидание потомкам". Однако все-таки в Германии есть здравомыслящие люди, поэтому после объединения Германии и выдворения советской власти из страны собор все-таки реконструировали. Сейчас он выглядит очень интересно, в черную крапинку, а одна из стен почти полностью черная. Это старые камни, которые были использованы строителями при постройке нового здания, что, на мой взгляд, является отличным памятником одновременно войне и миру. А также человеческой глупости, которая может привести к войне, смерти и разрушениям...

Фрауэнкирхе

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

Мы и Цвингер

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

Далее будет продолжение о городах Южной Чехии.