Saturday, December 19, 2009

Отпуск в Чехии #1: Чехия и Прага

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

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

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

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

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

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

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

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

Прага

У Праги очень интересная история. В Средние века это был не один город, а несколько маленьких (Старе место, Нове место, Мала страна), не говоря уже про замки (Пражский град и Вышеград), которые, расширившись до предела, стали подпирать друг дружку в буквальном смысле этого слова. Стена одного города граничила со стеной другого, в каждом городе было свое местное самоуправление (ратуша), свои правила и законы, что, конечно же, не способствовало особому росту городов. Долго так продолжаться не могло, поэтому в какой-то момент времени города объединили в один - Прагу.

IMG_6347 IMG_6486
Староместская и Новоместская ратуши

Расцвет Праги пришелся на правление Карла IV. Карл IV по значению для чехов - как Петр I для россиян. Это был воистину сильный правитель, реформатор, поборник мира, науки и искусства. Во время его правления расцвела не только Прага, но и Чехия в целом. Именно Карл IV построил знаменитый Карлов мост, который прочно связал два берега Влтавы, основал Карлов университет (один из первых в Европе), перестроил Вышеград и Пражский град, а также заложил первый камень в постройку собора Св.Вита в Пражском граде, основал Нове место, а затем объединил все Пражские города в один, обнеся его единой каменной стеной. Прага того времени стала не просто столицей Чешских земель, но еще и столицей Священной Римской империи, так как именно Карл IV был избран ее императором.

IMG_6469 IMG_6100
Карл IV, Карлов мост

Затем были Гуситские войны, истерзавшие страну, переход от готики к ренессансу и барокко, потеря статуса столицы империи в пользу Вены, где надолго обосновались Габсбурги, недолгое восстановление статуса императорской резиденции во времена Рудольфа II, потеря национальной идентичности, языка, веры, и их болезненное восстановление в XIX веке...

IMG_6056
Рудольфинум, галерея искусств Рудольфа II

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

IMG_6125  IMG_6457 IMG_6327
 IMG_6047IMG_6447  IMG_6520 IMG_6561
 IMG_6863 IMG_7462

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

IMG_6148
Папомобиль

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

IMG_6119
Странные бревна :)

Кто отгадает - тому пирожок :)

Продолжение о других чешских городах следует...

Sunday, December 6, 2009

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

Продолжаем традицию публикации интересных подкастов после почти полугодового перерыва:

Подкаст о том, что должны знать разработчики о базах данных в целом, и SQL Server в частности. Например, стоит ли использовать GUID (и, главное, какого типа) или identity field, что делать для улучшения производительности SQL Server, как правильно использовать и обслуживать базу данных в больших приложениях и многое другое, включая советы по железу и виртуализации. В общем, не совсем про программирование, но для общего развития однозначно полезно, а на некоторых проектах даже необходимо.

Советую всем ASP.NET-разработчикам: что будет нового в ASP.NET 4.0 от одного из програм менеджеров Microsoft. Новый взгляд на будущее WebForms и MVC, интеграция с Dynamic Data, ASP.NET Ajax, улучшенная генерация HTML кода в стандартных контролах, и т.д. На самом деле, они проходятся по далеко не всем фичам, но в целом неплохо. Больше можно увидеть здесь, или почитать полный список на официальном сайте. Наконец-то Microsoft сделало реальное обновление ASP.NET, которого все ждали уже несколько лет. WebForms избавляется от "лишнего жирка", что не может не радовать.

Сказал А, нужно говорить и Б - дал ссылку на подкаст про WebForms 4.0, нужно давать аналогичную на MVC 2.0 :) Скотт и Фил, которые вместе участвовали в создании MVC 1.0, обсуждают новые возможности MVC 2.0. Надо сказать, что изменения не столь радикальны, как в 1.0, полный список можно глянуть здесь. Часть команды перебросили на внедрение фич MVC в WebForms и другие улучшения в ASP.NET, поэтому в результате получилось меньше, чем мы все ожидали, но все-таки развитие продолжается.

Отличный подкаст с одним из авторов StackOverflow.com, Jeff Atwood, с которым Скотт обсуждает принципы и практики правильного создания высоконагруженных вебсайтов в .NET-стеке на примере StackOverflow.com. Использование LINQ to SQL, оптимизация Ajax, JavaScript minification, GZIP-компрессия, CDN, переключение SQL Server в менее агрессивный locking-режим, и много другое.

И напоследок немного не о .NET, а о Ruby. Отличный подкаст с человеком, который перешел из .NET в Ruby on Rails и теперь сравнивает не только эти технологии, но и языки программирования. Просто потрясающе, не знал, что в Ruby все так интересно - надо бы присмотреться к динамическим языкам и к Ruby on Rails.

У меня уже почти готова подборка на следующий выпуск. Stay tuned! ...если вам это интересно :)

Sunday, November 15, 2009

Материалы доклада по Entity Framework 4.0

Наконец-то появилось время разобраться с видео доклада по Entity Framework 4.0 :) Так что выкладываю, кому интересно:

Видео находится здесь: http://cid-be683ad8462aaeaf.skydrive.live.com/browse.aspx/.Public/Uneta?uc=1&sa=650758507. Придется качать 5 частей архива, а потом объединять Rar'ом, т.к. больше 50 Мб одним куском заливать нельзя. Можно было бы выложить на RapidShare или другие "условно бесплатные" файл-хостинги, но там тоже есть ограничения (как правило, 100 Мб), да и качать бесплатно не слишком приятно. YouTube/Rutube тоже не подходят - там 10-минутное ограничение, да и не совсем по теме... Если кто знает, куда можно выложить 250 Мб видео (почти час по длительности) одним куском - подскажите, плз.

А презентация живет здесь: http://www.slideshare.net/AlexMerle/new-in-entity-framework-40

PS. Спасибо всем, кто пришел, и отдельное спасибо Андрею Каще за съемку! :)

Upd 16.10.2009: Выложил примеры из доклада туда же, где и видео:

http://cid-be683ad8462aaeaf.skydrive.live.com/self.aspx/.Public/Uneta/EF4TestApp.zip
http://cid-be683ad8462aaeaf.skydrive.live.com/self.aspx/.Public/Uneta/NorthwindPocoSamplePart2.zip

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

Кстати! Как я говорил на докладе, уже вышли обновления Feature CTP для Code Only и Self-tracking entities:

http://blogs.msdn.com/adonet/archive/2009/11/15/updated-feature-ctp-walkthrough-self-tracking-entities-for-the-entity-framework.aspx
http://blogs.msdn.com/adonet/archive/2009/11/12/updated-feature-ctp-walkthrough-code-only-for-entity-framework.aspx

Так что кому интересно - дерзайте :)

Sunday, October 25, 2009

Доклад о нововведениях в Entity Framework 4.0

Готовлю доклад о нововведениях в Entity Framework 4.0. Планирую рассказать о различных проблемах Entity Framework 1.0 и том, какие из них были решены в следующей версии, а также просто про новые фичешки и рюшечки. Планируется даже не столько доклад, сколько workshop – постараюсь показать как можно больше примеров. Для этого скачал себе недавно вышедшую VS2010 beta 2 с обновленной версией EF4 – сижу вот теперь, развлекаюсь... Студия новая очень нравится, а вот Entity Framework, вернее, ADO.NET team подкачал – нигде толком не описаны breaking changes, поэтому застопорился на примерах для Code Only, POCO и Self-tracking entities: для первого не могу найти сборку, которая существовала в beta 1 (CTP1), для вторых – шаблоны T4 в студии. Ну да ничего, как-нибудь прорвемся – уж очень не хочется показывать примеры на beta 1, когда уже вышла beta 2.

Доклад буду делать в пятницу, 30 октября, на очередном харьковском собрании UNETA. Точное место и время пока еще неизвестны, но скорее всего, как обычно, в ХНУРЭ где-то около 18:00-18:30. Владимир Лещинский выложит анонс на dev.net.ua, так что можно будет посмотреть либо там, либо подписаться на комментарии к этой заметке – я чуть позже выложу время и место в комментариях.

Да, а вторым докладчиком будет Майк Чалый. Он будет рассказывать про DDD, причем это будет не просто теория, а рассказ человека, на своей шкуре попробовавшего этот подход. Да и вообще, Миша очень хорошо разбирается в дизайне и архитектуре, поэтому его всегда интересно послушать :)

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

PS. А еще 31 октября мой хороший друг Андрей Каща совместно с Сергеем Лутаем будут делать доклад по Silverlight 3.0 на IT Jam 2009 в Киеве. Я туда, к сожалению, не попадаю, но, может, кому-то другому повезет больше. Список тем можно посмотреть на официальном сайте.

PPS: Встреча будет проходить в Харьковском национальном университете радиоэлектроники (ХНУРЭ), пр. Ленина 14 ауд 301б (м. Научная) 30 октября 2009 в 18-15

PPPS. Внимание! Аудитория поменялась: встреча будет в 329 ауд.

Sunday, August 16, 2009

Быстрый взгляд на NDC 2009

В начале июня в Норвегии прошла Norwegian Developers Conference 2009 (NDC). И по-моему, прошла достаточно незаметно для многих из нас. Вместе с тем, список докладчиков и темы докладов были на очень высоком уровне, поэтому нужно срочно исправлять положение.

Просто для примера, докладчики (те, что у меня на слуху):

  • Robert C. Martin
  • Ayende Rahien
  • Scott Hanselman
  • Ted Neward
  • Phil Haack
  • Jeremy D. Miller
  • Tim Huckaby
  • Rockford Lhotka
  • Roy Osherove
  • Glenn Block
  • Scott Bellware
  • и многие другие

Каждый день был разбит на треки. Треки были самые разные, от общих вопросов программирования и инженерии ПО до разработки веб-приложений, TDD и Scrum/Lean. Каждый доклад пронумерован уровнем (100-400). Доклады очень практичные, мало рекламы, в отличие от многих Microsoft'овых конференций, поэтому must see.

Примеры самых сложных докладов (Level 400):

  • Automatic Recommendation Engine Based on Data Mining
  • Create Compelling Sharepoint Uls Using Silverlight
  • Writing Custom Windows Presentation Foundation Pixel Shader Effects
  • Building Maintainable Enterprise Applications with Silverlight and WPF
  • Asynchronous Systems Architecture for the Web
  • Mocking on the Edge - Isolation at the System Level

На сайте NDC 2009 можно посмотреть видео большинства докладов. Для этого вам придется обзавестись плагином Media Player 11 (например, мне для FF пришлось) и смириться с тем, что первые несколько минут доклада вы не увидите (вот уж не знаю, баг это или фича). Но надо сказать, что ради таких докладов можно пойти на любые жертвы.

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

Думаю, NDC можно спокойно поставить на один уровень с PDC, Mix/ReMix, TechEd, DevConnections, ALT.NET и другими известными конференциями и следить за ней в следующем году - она этого 100% заслуживает.

PS. Roy Osherove выложил ссылки на торренты для скачивания докладов.

Monday, August 10, 2009

Новые возможности LINQ to SQL в .NET 4.0

Вдогонку к моей предыдущей заметке предлагаю посмотреть список новых возможностей LINQ to SQL в .NET 4.0. Переводить не буду, просто дам ссылку на заметку Damien Guard из Microsoft, который работает над этим продуктом:

LINQ to SQL changes in .NET 4.0

Приятно, что L2S тоже развивается, пусть и не такими семимильными шагами как EF, NH и некоторые другие ORM. Я уже когда-то писал на тему развития этих технологий, а именно почему EF больше повезло в плане развития (и, соответственно, финансирования). По всей видимости, L2S будет тихим сапом поддерживаться и понемногу развиваться еще пару версий, а потом просто остановится, когда EF станет достаточно взрослым, продвинутым и быстрым, чтобы удовлетворить требования разработчиков, использующих L2S вместо EF или NH.

Sunday, August 9, 2009

Entity Framework 4.0: выходим на зрелый уровень

Я уже полгода не работаю с Entity Framework, но по былой памяти интерес все равно сохраняется. Как-то совсем упустил из виду, что вместе с выходом Visual Studio 2010 Beta 1 вышла и первая бета Entity Framework 4.0. Более того, спустя месяц ADO.NET team выпустил еще и Entity Framework 4.0 Feature CTP 1 (скачать можно здесь). В CTP 1 вошли еще три новые фичи, которые не успели довести до выхода VS 2010 Beta 1: Self Tracking Entities (о которых я уже немного рассказывал), POCO Template и Code Only.

Что это значит? Это значит, что в релизной версии 2010-й студии в составе .NET 4.0 этих фич тоже не будет. Daniel Simmons в подкасте .NET Rocks #451 как-то достаточно неясно сказал, что они вроде бы войдут в какой-то следующий релиз после VS 2010, хотя сам EFv4 будет релизиться вместе со студией. Ну, да это не так важно.

А важно вот что: в следующей версии EF разработчики проделали достаточно серьезную работу. Они действительно учли многие комментарии и критику, которые обрушились на первую версию EF, поэтому вторая версия EF с физическим номером 4.0 (Microsoft снова извратила нумерацию с целью упростить жизнь своим sales) будет ощутимо солиднее. Что же мы получим в новой версии:

1) Model First development approach

В EFv1 была лишь возможность сгенерировать модель по базе данных, а EFv4 обладает и обратной возможностью - сгенерировать базу данных по модели. Теперь вы можете сами выбрать, какой подход вам удобнее и работать, используя его. На мой взгляд, может подойти людям, работающим в рамках DDD, где база данных воспринимается как инфраструктура - средство для хранения (persistence) состояния объектов системы.

Подробнее о фиче:
Sneak Preview: Model First in the Entity Framework 4.0

2) Code Only development approach

Конечно, Database First и Model First подходы к разработке покрывают потребности почти всех разработчиков. Однако, также есть люди, которым нравится создавать свою модель прямо в коде. При чем делают они это, как правило, при помощи так называемых fluent-интерфейсов, то есть максимально читабельного кода, который заменяет конфигурирование при помощи XML (то есть EDMX-файлы уходят в прошлое). На данный момент еще не все возможности EDMX-конфигурации обзавелись своими аналогами, да и текущий API сложно назвать fluent, но к релизу, думаю, будет покрыт максимум возможных операций.

Подробнее о фиче:
Code Only design
Code Only enhancements
Feature CTP Walkthrough: Code Only for the Entity Framework
Next version of EF Code Only Design laid out by MS

3) Persistence Ignorance (POCO) support

То о чем так долго говорили и писали, наконец свершилось: ADO.NET team добавил в EFv4 поддержку Persistence Ignorance (PI). В EFv1 все сущности были унаследованы от EntityObject и таким образом "знали" о том, что где-то есть EF контекст, а EF контекст, в свою очередь, мог отслеживать изменения в этих объектах и использовать их в других целях. Такая привязка сущностей к инфраструктуре создавала много проблем с тестируемостью и реализацией сценариев, где нужны чистые POCO-объекты. Теперь же эта проблема решена: вы можете создавать POCO-объекты и при этом у вас сохраняться все инфраструктурные возможности EF: отслеживание и сохранение изменений, lazy/deferred loading, и др. Кроме того, у вас есть выбор, какой способ отслеживания изменений выбрать: snapshot-based или proxy-based, также вы можете создать свои собственные шаблоны для генерации POCO. Фича очень серьезная, возможностей много.

Подробнее о фиче:
Sneak Preview: Persistence Ignorance and POCO in Entity Framework 4.0
POCO in the Entity Framework: Part 1 - The Experience
POCO in the Entity Framework : Part 2 – Complex Types, Deferred Loading and Explicit Loading
POCO in the Entity Framework : Part 3 – Change Tracking with POCO
Feature CTP Walkthrough: POCO Templates for Entity Framework

4) Customization of Code Generation

После описания POCO и Code Only, разумно рассказать немного о механизме, который они частично (или полностью) используют. Если вы помните, первая версия EF генерировала код при помощи такой штуки, как CodeDOM. Надо сказать, что хотя это и мощная технология кодогенерации, кастомизировать ее невероятно сложно. Мы пробовали вклиниваться в процесс генерации EF сущностей на одном из проектов, но возможности там достаточно поверхностные. EFv4 генерирует сущности и класс контекста при помощи T4 (Text Template Transformation Toolkit), что позволяет просто отредактировать существующие текстовые шаблоны или написать и подключить свои - и все готово. Кроме того, переход на более простой способ генерации позволил реализовать и некоторые другие новые возможности, например, POCO или Code Only. Да и вообще, теперь вы можете генерировать все что угодно на основании своей модели - различные адаптеры, DTO, POCO-объекты, возможности кодогенерации почти безграничны.

Подробнее о фиче:
Sneak Peek – Using Code Generation Templates with the Entity Framework 4.0

Как кастомизировать шаблоны T4 в EF:
Customizing T4 Templates
Customizing EDM Code Gen in EF4
Feature CTP Walkthrough: POCO Templates for Entity Framework

5) Testability Improvements

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

Подробнее о фиче:
Sneak Preview: Entity Framework 4.0 Testability Improvements

6) Self-tracking entities

Идея проста - появились новые шаблоны T4, которые позволяют генерировать специальные сущности, не зависящие от ObjectContext и EF, но зато умеющие сами трекать изменения внутри себя. Когда это может пригодится? Например, когда вы хотите сериализовать свои сущности, отправить их куда-то в другое место (на SL-клиент или в другое приложение при помощи WCF-сервиса), сделать там в них изменения (добавить новые, изменить, удалить), вернуть назад и сохранить изменения в базу. Описанный здесь сценарий было очень сложно реализовать в EFv1, теперь это вопрос намного более тривиальный.

Подробнее о фиче:
Self-Tracking Entities in the Entity Framework
Feature CTP Walkthrough: Self Tracking Entities for Entity Framework

7) Deferred loading

В EFv1 в отношении lazy/eager loading было две опции: eager loading, доступный через Include(), и explicit (явный) lazy loading, доступный через метод Load() классов EntitySet и EntityReference. При этом если вам хотелось реализовать неявную поддержку lazy loading, вам приходилось достаточно серьезно извращаться (мы, например, хакали кодогенерацию EF), хотя в LINQ to SQL эта возможность была с самого начала. Теперь же все стало на свои места - все три сценария поддерживаются, причем третий сценарий для отличия от уже существующего lazy loading назвали deferred loading. Зачем - не знаю.

Подробнее о фиче:
Sneak Preview: Deferred Loading in Entity Framework 4.0
A Look at Lazy Loading in EF4

8) Model Defined Functions

MDF - это специальные функции, добавляемые к сущностям, которые описываются на уровне CSDL, то есть концептуальной модели данных. Эти функции могут принимать параметры, выполнять любой eSQL-код внутри себя, и потом возвращать результат. Благодаря такой возможности их можно использовать в eSQL-запросах, а также в LINQ-запросах (если вывести их наверх). В каких случаях они будут полезны в жизни? Сложно сказать, не могу подобрать реальный пример. Разработчики говорят что-то про Reporting Services, Web Services и т.д. - они необходимы там. Поэтому это больше внутренняя фича, которая будет полезна, если вы начнете делать шаги в сторону от стандартных сценариев. Поживем - увидим.

Подробнее о фиче:
Model Defined Functions
Sneak Preview: Model Defined Functions
EF4: Model-Defined Functions Level 1 & 2

Немного больше об истории и причинах их появления:
Update on Computed Properties

9) Foreign Keys support

EFv4 поддерживает новый тип ассоциации, т.н. FK Association. Старый тип ассоциации теперь принято называть Independent Association. FK Association будет полезен в тех случаях, когда вам удобнее работать со связями через первичные ключи, а не с коллекциями и ссылками на реальные объекты - все-таки это иногда намного более производильные операции. При этом надо сказать, что эта фича далась разработчикам очень нелегко, так как она должна поддерживаться не только на уровне EntityObject, но также на уровне proxy-based POCO, snapshot-based POCO, IPOCO и других способов создания модели.

Подробнее о фиче:
Foreign Keys in the Entity Framework

10) SQL Generation Improvements: readability and performance

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

Подробнее о фиче:
Improvements to the Generated SQL in .NET 4.0 Beta1
Checking for EF to TSQL Query Compilation Changes in VS2010 Beta1

Об остальных фичах более кратко:

Checking out one of the new stored procedure features in EF4
A big step for Stored Procedures in EF4
Pluralization support
The much improved EDM Wizard Pluralization in VS2010
Complex Types in the EDM Designer in EF4 and a look at updating complex types in code
More Designer Improvements - Deleting Entities from the model and from the store schema

Также ADO.NET team выпустил пару статей по "правильному" написанию кода для поддержки Repository, Unit of Work и даже N-Tier applications. Почитать можно, но все же, на мой взгляд, там лучше почитать комментарии и ссылку, которые в них:

Using Repository and Unit of Work patterns with Entity Framework 4.0
Sneak Preview: N-Tier development with Entity Framework 4.0

Ну, а утрамбовать это все стоит отличным подкастом .NET Rocks #451, где происходит интервью с уже упомянутым Daniel Simmons, который более детально рассказывает о реализации некоторых вышеуказанных фич.

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

Удачи!

Sunday, August 2, 2009

Ошибки технических менеджеров проектов

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

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

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

Думаю, любой человек, работая под началом разных менеджеров, видел различия в отношении и подходах. У каждого PM свой уровень знания и умений, менталитет, психология, поэтому стили управления отличаются. Но если посмотреть на PM, которые в прошлом были программистами, можно заметить некоторые общие черты и типичные ошибки, которые те совершают. Основная причина этих "типичных" ошибок - менталитет, установленные подходы и шаблоны работы в бывшей роли программиста, а не просто недостаток знаний или понимания процесса управления проектами. Почти любой программист, при условии хороших технических знаний и наличии лидерских качеств, может стать хорошим лидером, но это еще не значит, что он может стать хорошим менеджером. Между "управлением" продуктом, которым, по сути, занимаются DL или TL, и управлением проектом и командой, которым занимается PM есть большая разница.

Ошибка №1. Непонимание целей и задач роли PM

Я уже упоминал, что цели и задачи ролей DL и PM отличаются. Основная задача DL - реализовать продукт технически. Это его сфера ответственности. Основная задача PM - успешно завершить проект в рамках запланированных сроков, бюджета, объема функционала и его качества, таким образом сделав клиента довольным и счастливым. Попутно можно сказать, что основная задача QAL состоит в том, чтобы удостовериться, что полученный в результате выполнения проекта продукт - это именно то, что нужно клиенту и что качество этого продукта соответствует предъявленным требованиям, но QA мы пока что трогать не будем. Таким образом, обязанности PM состоят не только в том, чтобы общаться с клиентом, давать всем подзатыльники, а также писать спецификации и отчеты (изверги, бумажной работы навалили, ужас!), а в том, чтобы создать условия и наладить процесс работы, в рамках которых команда достигнет результата, попутно эффективно управляя требованиями, рисками, различного рода ресурсами (в том числе и человеческими) и т.д. И это все нужно понимать и делать, даже если PM - всего лишь дополнительная роль, которую вам приходится выполнять по долгу службы, а не настоящая должность.

Ошибка №2. Неумение смотреть на проект и продукт с точки зрения клиента (бизнеса)

Менеджер проекта в какой-то степени является промежуточным звеном между командой и клиентом. Поэтому если программист и DL могут позволить себе думать только о реализации и проблемах, связанных с ними, быть "по эту сторону баррикад", то PM уже должен думать не только о команде, но еще и о клиенте, его целях, желаниях и проблемах. Любой продукт, разрабатываемый в рамках проекта, несет для клиента какую-то выгоду (не обязательно финансовую). Если же мы в угоду желания попробовать новую технологию, реализовать эту фичу "по-своему" или даже просто по глупости убиваем эту выгоду - клиент не будет доволен. И PM иногда является единственным носителем полной информации о целях и желаниях клиента. Да, в какой-то степени это еще и обязанность QA, но зачастую они не могут принять решение в момент разработки, а лишь тогда, когда что-то уже сделано. Поэтому лишь PM может вовремя остановить разработку и направить ее в правильное русло. Нужно помнить, что PM является не только адвокатом команды перед клиентом, но и адвокатом клиента перед командой.

Ошибка №3. Считать себя самым умным и самым главным

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

Ошибка №4. Злоупотребление делегированием-исполнением, а не делегированием-руководством (микроменеджментом)

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

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

Ошибка №5. Боязнь показать свое незнание

У программистов это чувство развито очень сильно :) Поэтому довольно часто менеджеру сложно спросить какие-то детали, попросить о помощи - ведь он вроде бы как самый главный в команде (см. ошибку №3), негоже перед подчиненными показывать свою слабость, вдруг перестанут уважать. Достаточно глупо и, к сожалению, иногда весьма критично для проекта. У PM есть куча других обязанностей, поэтому ему часто некогда вникать в детали, новые технологии и подходы разработки. Немудрено, что некоторые люди на проекте, которых вы раньше учили сами, вдруг окажутся осведомлены в чем-то техническом больше вас. Это нормально, не обращайте на это внимания, развивайтесь в свою сторону, и старайтесь наоборот стимулировать профессиональный рост своей команды, ведь чем сильнее команда - тем успешнее будет ваш проект.

Ошибка №6. Поверхностное отношение к команде и ее интересам

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

Ошибка №7. Остановка технического роста

Казалось бы, какое отношение это имеет к управлению проектом? Никакого. Но зато это имеет самое прямое отношение к реалиям жизни. Если бывший программист, став PM, полностью останавливает свой технический рост по принципу "я уже и так достиг всего чего мог в техническом плане, могу забить", то это, по сути, рубание ветки, на которой сидишь. Да, технические навыки не обязательны для того, чтобы быть эффективным менеджером, но тем не менее кто вам даст гарантию, что один из ваших следующих проектов, который будет через год или два, не потребует от вас занятия должности PL, который будет руководить и технической, и организационной частью проекта? Или что на вашем следующем месте работы это не будет обязательным требованием? А будете ли вы тогда достаточно подкованы в новых технологиях или подходах для того, чтобы довести подобный проект до успешного завершения? На мой взгляд, если уж вам так повезло, и вы прошли весь путь от падавана до мастера Йоды в программировании, то не забрасывайте свои технические знания в темный чулан, развивайте их, хотя бы на поверхностном уровне изучайте новые технологии и подходы к разработке ПО, совершенствуйтесь!

Успехов вам и вашим проектам!

Sunday, July 26, 2009

Должен ли PM быть техническим специалистом?

Я уже не первый раз сталкиваюсь с вопросом, должен ли PM быть технически подкованным человеком или нет. Иными словами, должен ли у него быть опыт работы программистом или QA, для того, чтобы успешно вести проекты, связанные с разработкой ПО. И собственно, вопрос здесь даже не в том, возможно это или нет - опыт показывает, что есть нетехнические PM, которые с разной степенью успешности ведут проекты. Но в то же время тот же опыт показывает, что а) таких людей довольно мало, б) им иногда бывает сложнее, в) общественное мнение в лице различных IT-специалистов иногда отрицает эффективность такого PM. Столкнувшись с этим вопросом, я решил провести небольшой опрос среди моих друзей и сотрудников (бывших и нынешних). Выборка была порядка 20 человек (знаю, нерепрезентативная, но я и не старался делать соцопрос, скорее, получить дополнительную пищу для размышлений), люди абсолютно разного уровня и позиций: программисты, QA, BA, девлиды/тимлиды различного плана, и несколько ребят, которые так или иначе выполняют функции PM на своих проектах или ими являются. Задавал я, как правило, один и тот же вопрос, в краткой форме приведенный в заголовке данной заметки, а потом, по ходу дела, спрашивал детальнее, уточнял подробности, иногда дискутировал :) Ответы были разными, некоторые совпадали с моим мнением, некоторые - нет. Но в любом случае, я благодарен всем, кто согласился ответить на эти вопросы, в независимости от точки зрения, т.к. вы помогли мне увидеть бОльшую картину, чем была у меня в голове до опроса. Все-таки опыт у разных людей разный, поэтому одна голова - хорошо, а двадцать лучше. Также я немного потерроризировал гугл, а также сайты вроде www.stackoverflow.com, www.rsdn.ru и прочие уважаемые ресурсы.

Если очень коротко, то результаты опроса были следующими: где-то 40% людей так или иначе высказывались в пользу идеи, что у PM должен быть технический опыт, и что технический PM лучше нетехнического, причем неоднократно подчеркивались 2 мысли: лучший PM - PM-бывший программист, и лучший PM - PM-бывший QA. Я думаю, не стоит уточнять, у кого какое мнение ;) Остальные говорили, что либо технический опыт не имеет никакого значения, а иногда даже мешает, либо нетехнический PM способен эффективно руководить проектом, но все же не любым. Я же хотел бы высказать свои мысли по этому поводу, в том числе навеянные и общением на эту тему.

Чем занимается менеджер проекта

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

Для достижения этих целей, менеджер проекта занимается самыми различными активностями:

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

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

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

Чем отличается должность от роли на проекте

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

PM, менеджер проекта - это как должность/позиция, так и роль, и это часто сбивает людей с толку. Еще более сбивает с толку наличие кучи других лидерских позиций: Project Lead, Team Lead, Tech Lead, Dev Lead, QA Lead, Software Architect, можете продолжить сами. Я тоже раньше не мог точно сказать, кто за что отвечает, чем отличается, и вообще, кто все эти люди и что они здесь делают. Связано это с тем, что в разных компаниях и даже на разных проектах люди на этих позициях выполняют зачастую различные обязанности, а единого реестра как бы и нет... Расскажу, как я это понимаю, а вы если что поправляйте. Проще всего разобраться с Dev Lead и QA Lead - это явно выраженные технические позиции, которые четко совпадают с соответствующими ролями: они отвечают за техническую сторону реализации проекта, то есть разработку и проверку качества продукта. Программируют и тестируют они при этом или нет - не так важно, хотя чаще всего да. Позиции Tech Lead и Team Lead более размыты, человек на этих позициях может выполнять как чистую роль Dev Lead, так и несколько ролей: DL, QAL, иногда также PM, SA, BA. К тому же должность Team Lead может относится и к совсем другим сферам деятельности, по сути, это просто руководитель команды: системных администраторов, технических писателей, дизайнеров, бизнес-аналитиков и т.д.

Позиции Project Lead и Project Manager - самые интересные в этом списке, так как человек на каждой из этих позиций может выполнять кучу ролей: PM, DL, QAL, BA, SA, и др., в зависимости от проекта, и того, что понимается под этой позицией в отдельно взятом государстве, в данной конкретной компании, на конкретном проекте и т.д. Но все же разница здесь тоже присутствует. Обычно PL все-таки является техническим товарищем, объединяющим в себя как управляюще-аналитические роли (PM, BA), так и технические (DL, SA, иногда QAL), а вот PM'ами называют зачастую либо людей, играющих только роль PM, либо роли PM и BA, хотя в общем и целом это тоже далеко не гарантия.

Факторы, влияющие на то, может ли PM быть "нетехническим"

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

Для успешного выполнения проекта в команде должны быть представлены все роли, необходимые для этого. Здесь мы подходим к первому фактору, который влияет на ответ на наш вопрос - специфика проекта. Если на проекте есть готовые требования, скорее всего, вашей команде не нужен человек, выполняющий роль BA (это не значит, что для успеха проекта совсем не нужен BA, просто его работа уже выполнена кем-то другим выше вашей команды), если вам прислали готовые документы по архитектуре и дизайну, значит, вам скорее всего не нужен SA, если проект технически не слишком сложен, возможно, вам достаточно не самой сильной команды, но роль DL все равно придется на кого-то возложить, и этот "кто-то" должен соответствовать уровню этой роли.

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

Еще один немаловажный фактор, который определяет, какие роли будет выполнять человек на должности менеджера проекта - это размер проекта. На небольшом проекте особо не разгуляешься. Если каждому человеку в команде назначить одну роль, то будет, как на картинке, где один копает, а остальные смотрят :), потому что объем "чистых" активностей одной роли невелик или продолжается незначительный период времени, а работы по разработке или тестированию продукта очень много. Поэтому очень часто на небольших проектах PM (или уже скорее PL) выполняет не только менеджерские функции, но еще и является основным техническим специалистом на проекте, который и анализирует требования, и пишет спецификации, и продумывает архитектуру, и руководит тестированием, в общем, и швец, и жнец. Не говоря уже о том, что в таком случае разработка выходит намного дешевле, т.к. достаточно взять одного самородка, дать ему в команду 25 джуниоров - и дело пойдет ;) Шучу, конечно, но в каждой шутке, как известно, доля шутки - я такие ситуации видел не раз. Поэтому это тоже нужно учитывать.

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

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

Есть ли минимальный набор "технических" знаний, необходимых PM?

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

Это же помогает найти ответ и на другой вопрос: можно ли взять успешного менеджера проектов, скажем, в рекламе, и поставить менеджером проекта по разработке ПО? Или можно ли научить человека проектному менеджменту в университете, а потом взять на работу? Можно, но этот человек все-таки должен для начала разобраться в "предметной области" IT-индустрии, прочитать кучу книг, статей, возможно, сдать определенные экзамены, а еще лучше своими глазами увидеть реальные IT-проекты и потренироваться на небольших и не особо критичных. Если у человека есть опыт и он умеет думать и учиться, то все возможно.

Так, может, лучше взять DL или QAL и сделать менеджера проекта из них?

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

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

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

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

Успехов вам!

PS. Еще раз спасибо всем, кого я доставал своими глупыми вопросами :)

Saturday, July 25, 2009

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

Где-то 3 месяца назад я написал первый выпуск списка интересных подкастов. Время идет, новые подкасты появляются и прослушиваются. Подошло время второго выпуска, надеюсь, вам понравится:

В гостях у Карла и Ричарда человек, который не нуждается в особом представлении: Дино Эспозито. Дино рассказывает о том, чем занимается в данный момент времени, об архитектуре веб-приложений (и не только), сравнивает ASP.NET и ASP.NET MVC, а также немного проходится по другим веб-технологиям и библиотекам: AJAX, jQuery, Silverlight. Хороший подкаст для тех, кто хочет немного расширить свой кругозор и, возможно, узнать что-то новенькое.

Эрик Эванс в особом представлении тоже не нуждается. Еще один подкаст об архитектуре, но направленный в сторону не технологий, а подходов. А точнее, одного конкретного подхода: Domain Driven Design. Если вы уже слышали про DDD, но еще не вполне представляете себе, что это, попробуйте послушать рассказ наверно самого основного автора этого подхода к разработке ПО. Кроме DDD, Эрик также затрагивает вопросы сложности крупных приложений, архитектуры, слоев приложений и устаревшего кода.

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

Uncle Bob возвращается! В этот раз Скотт обсуждает с Бобом вопросы, не связанные с SOLID, и даже не касающиеся качественного кода или дизайна. Речь идет о профессионализме. Можно ли считать, что индустрия разработки ПО уже созрела и нас всех с вами можно считать профессионалами? Чего нам не хватает для этого? Что такое быть профессионалом в сфере разработки? А также немного о том, как, по мнению Боба, будет выглядеть программирование через 40 лет. Очень интересный подкаст.

Ну, и напоследок снова нетехнический подкаст. Жена Скотта, Мо, берет интервью у него. Если вы хотите узнать, как и чем живут люди, похожие на Скотта, какие у него и его семьи планы на жизнь, как он умудряется соблюдать баланс работы и семьи, не надоедает ли ему то, что он делает, то это стоит прослушивания. Меня приятно увидило, что у Скотта есть далекоидущие планы, не связанные ни с разработкой ПО, ни тем более с работой в Microsoft. Хотите узнать, какие? Тогда слушайте :)

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

Sunday, June 14, 2009

Снова об IT-образовании

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

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

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

  1. знать техническую базу: устройство компьютера, микропроцессора, и т.д., понимать, что такое ОС, как работают компьютерные сети, что такое интернет
  2. уметь программировать (язык не важен, важно понимание и алгоритмическое мышление)
  3. знать алгоритмическую базу, структуры данных, базы знаний, основы нейросетей, искусственного интеллекта, и т.д.
  4. понимать, что такое качество кода, ООП, шаблоны проектирования, масштабирование, производительность и т.д.
  5. знать хотя бы по одному языку программирования разных уровней, и те или иные технологии по выбору студента и на том уровне, который он хочет знать
  6. разбираться в базах данных (реляционных, объектных), XML и других форматах и способах хранения данных
  7. понимать весь цикл разработки софта (а не просто уметь писать лабы), иметь представление о методологиях разработки, командной работе, QA
  8. быть немного знакомым с best practices of software development: source controls, unit testing, CI, и др., возможно - BDD, DDD, XP-практиками
  9. наверняка, что-то забыл, впишите сами...

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

Это, конечно, не все. Со стороны вузов еще нужно перенимать опыт коллег (МГУ, MIT, etc.), хотя бы лекции их посмотреть, отправлять преподавателей на стажировку. Заинтересовывать студентов действительно интересными научными разработками. Брать заказы и гранты у крупных госорганизаций и не только у них. Обновить подходы к обучению программированию, продумать и улучшить программу. Дать студентам бОльшую гибкость в выборе "специальных" предметов: один может хотеть изучать веб-программирование, второй - мобильные системы, а третий - робототехнику, одному нравится LAMP, второму - .NET, третьему - Ruby on Rails. Постоянно держать связь с IT-индустрией нашей страны.

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

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

Monday, June 1, 2009

Путешествие на Закарпатье

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

Ездили мы на Закарпатье впервые. До поездки для меня Карпаты были загадкой - несмотря на то, что я уже однажды бывал в Ужгороде, Львове и Коломые, про сами горы я знал лишь то, что там есть Говерла, и куда-то туда ездят кататься зимой на лыжах толпы моих друзей и сотрудников. Названия Славское, Драгобрат, Буковель при мне упоминались часто, но на привычной карте в моей голове эти места еще размещены не были. Поэтому и хотелось поехать восполнить этот пробел.

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

Поход

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

Инвентарь

Что нужно взять с собой в поход в мае в Карпаты? Как минимум палатку, спальник, каремат (где-то до -5), две пары обуви (непромокаемую на случай дождя или снега и легкие трекинговые кроссовки на остальное время), легкие вещи на день, теплые вещи на вечер и ночь, какую-нибудь защиту от дождя (не зонт), горелку (на случай длительного дождя), фотоаппарат (куда без него!), карту, компас, GPS (опционально), нож, котел, посуду и еду. А, да, еще хорошее настроение! :) Поскольку в этот раз мы собирались поставить рекорд тяжести наших рюкзаков, а в интернете нас постоянно пугали тем, что в селах магазины работают не так часто, как супермаркеты в Харькове (странно, правда?), к сбору еды мы в этот раз подошли серьезно: рассчитали все завтраки, обеды и ужины, и взяли с собой только то, чего нам должно было хватить на неделю похода за вычетом одного набега на местные магазинчики. Надо сказать, мы почти угадали: в поезде назад мы доедали последнюю банку паштета, но все равно брать нужно было меньше! Эту банку паштета (да и не только ее) можно было купить и в Ужгороде, и не устраивать ей экскурсию по горам и весям Карпат в течение 6 дней.

Маршрут похода

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

M-34-131_4

Итак, маршрут получился следующий: оз. Синевир - г. Озерная - с. Верх-Быстрый - вдп. Шипот - Боржавский хребет. После чего мы вышли на центральную дорогу в районе Подобовца, сели там на автобус и поехали в Ужгород.

Надо сказать, что изначально мы планировали совсем другой маршрут. Начинаться он должен был там же, но после второй стоянки мы должны были подниматься вверх на Камянку, перевалить ее, спуститься в Стригальню, потом оттуда доехать до Лозянского, и снова пойти в горы, чтобы полюбоваться Боржавой: через перевал Прислоп (масло масленое, Прислоп - это и есть "перевал") пройти по хребту через горы Ополонок, Граб, Магура-Жиде, дойти до горы Великий Верх, и оттуда спуститься к водопаду Шипот. Но, надо сказать, это я здорово переоценил наши силы и время. Опытные ребята, я уверен, прошли бы этот маршрут за 6 дней, и еще день бы лежали на траве, но у нас в компании лосей не было, поэтому мы топали мало (где-то 4-8 часов в день) и достаточно прогулочным темпом, фотографируя окрестности и кушая орешки.

День 1. Синевир

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

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

  IMG_4113 IMG_4134

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

IMG_4153

За первый день от начала нашего маршрута, коим я считаю пропускной пункт на Синевир, мы прошли максимум километров 5-6 (с учетом поисков ночлега). Ночевка была на высоте 1245 м, поэтому перепад высот составил около 400-500 м. Довольно неплохая разминка.

День 2. Озерная

Утром мы проснулись не очень рано. Пока мы позавтракали, привели себя в порядок, сходили за водой и собрались, было уже полпервого. Знаю, что это очень поздно, но мы и не планировали марш-бросков на этот поход. Пока ребята ходили за водой, я успел сходить на соседнюю полонину, с которой мы вчера пришли, и нашел там тропинку, уходящую вверх серпантином. Довольные тем фактом, что не придется идти абы куда, мы двинулись вверх. Подъем на вершину был довольно крут, мы периодически останавливались передохнуть, но где-то через час-полтора мы были на вершине. 1495 м. С вершины (да и чуть ниже) открывался прекрасный вид на Синевир и окружающие горы. Такой Синевир производил намного лучшее впечатление. Пофотографировав эти изумительные виды и друг друга в снегу, мы собрались с духом и пошли по хребту в сторону Каменки.

  IMG_4285 IMG_4187IMG_4255

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

IMG_4337 IMG_4345

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

IMG_4359

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

Согласно данным нашего GPS, ночевали мы на высоте 939 м. За этот день по самым скромным подсчетам мы прошагали где-то 10-12 км (хотя по карте кажется, что там нет и 6).

День 3. Река Быстрая

На третий день проснулись мы рано, но с выходом снова затянули. У нас даже появилась примета: во сколько не просыпайся - все равно раньше 12 не выйдешь. Собрав вещи, мы выдвинулись вниз по дороге. Рядом с дорогой постоянно текла речушка, с каждым десятком метров прибавлявшая себе воды из боковых притоков. Шли мы по впадине между двух хребтов, можно сказать по каньону реки. Судя по карте дорога должна была нас вывести к деревне и в планах у нас было добраться до нее и стать лагерем где-то на подходе. Места здесь были очень живописные, один раз мы даже видели небольшую косулю, которая спустилась с горы на водопой. Сосновый лес постепенно сдавал свои права лесу лиственному. Периодически стали появляться следы жизнедеятельности человека, пару раз по дороге проезжали машины, которые, судя по всему, ездили на вырубку - больше некуда.

IMG_4413 IMG_4403 

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

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

IMG_4507 IMG_4542

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

За третий день было пройдено около 10 км, а лагерь мы разбили на высоте 626 м.

День 4. Шипот

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

IMG_4663IMG_4631IMG_4625 

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

IMG_4675 IMG_4670

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

Шипот - очень красивый водопад. Высотой 12 метров, он ниспадает каскадом, оглушая своим грохотом. В мае он еще очень полноводен, так как его еще хорошо питают тающие снега Боржавы. Рядом с водопадом проложены несколько горнолыжных трасс, построены подъемники, куча гостиниц, в общем, инфраструктура развита.

 IMG_4736IMG_4886 

Несмотря на то, что до Шипота тоже легко добраться на машине, народу здесь уже почти не было - вечер, да и будни, не суббота, как на Синевире. Мы быстро пофотографировались, поглазели немного, узнали, где можно поставить палатки и пошли наверх - на поляну, на которой периодически собираются "хипари", как нам сказала девушка на проходной. "Хипарей" на поляне не было - еще не День защиты детей, и не Ивана Купала, когда эта поляна почти полностью покрывается палатками. Поляна представляет собой вытянутую по направлению к горам полонину между двумя речными каньонами. С нее открывается замечательный вид на Боржавский хребет, гору Великий Верх, и вниз, на деревню Пилипец. В таком живописном месте можно провести и не один день.

IMG_4738

Вечер был коротким - только мы насобирали дров и поставили палатки, как наступили сумерки. Но в этот день спать не хотелось, поэтому мы долго сидели и общались перед сном.

Палатки мы поставили на высоте 843 м. В это "неходовой" день мы прошли максимум километров 5-6.

День 5. Боржава

На пятый день нашего похода мы устроили наконец дневку. Шипотская поляна подходила для этого как нельзя лучше - есть вода, дрова, прекрасные виды. Днем ребята сходили вниз, разведали обстановку в домиках - мы уже и не собирались там ночевать, но в конце-концов решили, что перед отъездом в Ужгород не помешает нормально искупаться, да и хотелось успеть на 11-часовый автобус, а с нашей манерой собираться для этого на следующий день нам пришлось бы вставать в 7 утра. В результате ребята нашли отличную деревянную мини-гостиницу за 350 грн с четверых (сначала просили по 100 грн с носа), в которой мы и решили пока оставить вещи. Саша и Алена намеревались погулять возле водопада, а мы с Леной хотели сбегать налегке на хребет, раз выдалась такая возможность.

Через поляну шла дорога, по которой мы и начали подниматься вверх. Через час подъема дорога вышла из лесу, и мы вышли на участок, покрытый травой и низкорослым кустарником. Здесь начиналась подъем на хребет. Горы встретили нас не очень приветливо - по небу бродили низкие тучи, без солнца было довольно холодно, а ветер постоянно намеревался сдуть нас вниз. Но мы твердо решили зайти на Полонину Боржава, и увидеть противоположный склон хребта и гору Стой - самую высокую гору Боржавы. Еще через полчаса нам это удалось. Мы вышли на тропинку, идущую по хребту где-то посередине между горами Великий Верх и Гымба. Великий Верх возвышался где-то в километре справа, гора Стой виднелась впереди, а перед нами расстилался вид на долину и близлежащие горы. Мы были почти на 1400 м. Ветер был недетский и собирался дождь, поэтому мы решили не идти на Великий Верх, а начали быстро спускаться вниз. Путь наверх занял у нас полтора часа, путь вниз, с учетом десятиминутного отдыха под горой - час, прошли мы километров 8-10.

IMG_4801 IMG_4806IMG_4824

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

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

День 6-7. Ужгород

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

IMG_4939 IMG_4942 IMG_4951

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

IMG_4960 IMG_4965

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

Ужгород - самый маленький областной центр. В нем проживает всего около 115 тыс. жителей. Расположен он на самой границе со Словакией и недалеко от границы с Венгрией, что в достаточной степени определяет его культуру и образ жизни горожан. Ужгород - один из древнейших славянских городов. На протяжении своей истории Ужгород принадлежал Киевской Руси, Венгерскому королевству, Австрийской империи, Чехословакии, и лишь в 1945 году вошел в состав Украинской ССР. Самые известные памятники архитектуры - Ужгородский замок, римо-католический костел в стиле барокко, греко-католический и православный храмы, ратуша, епископский дворец, филармония (бывшая синагога). Здесь также стоит посетить Закарпатский музей народной архитектуры и быта, ботанический сад, художественный и краеведческий музеи, а также непременно прогуляться по набережным реки Уж и узким улочкам Старого города.

 IMG_5091 IMG_5025  IMG_5083 IMG_4967

Ужгород произвел на нас приятное впечатление. Чистенький, ухоженный, неторопливый. Настоящий кусочек Европы в Украине. Речка тоже порадовала своей чистотой и прозрачностью. С моста можно увидеть кучу форели, которая по какой-то причине не пытается убежать куда глаза глядят, а резвится на полуметровой глубине в больших количествах. Ее здесь запрещено ловить - вот и резвится. В этом маленьком примере - вся культура Закарпатья, где люди живут так, как мы, жители мегаполисов востока, не умеем, и может, никогда уже и не научимся: высаживают деревья, огораживают муравейники, ухаживают за природой, не пачкают реку. Я понимаю, что если бы в Ужгороде было не 115 тыс. жителей, а 2.5 млн, то мы бы еще посмотрели, где было бы чище, но все же мне кажется, что и в этом случае в Уже бы водилась форель, которую можно было бы увидеть с пешеходного моста в центре города...

IMG_4977IMG_5032

Пока мы гуляли по городу, мы нашли кафешку, где можно было посмотреть полуфинал кубка УЕФА, и успели порадоваться победе Шахтера, который через несколько недель стал обладателем Кубка УЕФА. Никогда раньше не смотрел футбол в кафе на улице - это действительно здорово!

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

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

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

  IMG_5150 IMG_5096 IMG_5142

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

IMG_5158 IMG_5184 IMG_5161

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

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