Блог Александра Кондуфорова

Подкаст DotBand #3 - Outsourcing

2012-01-04T14:41:00.001+02:00

Поучаствовал в записи третьего подкаста DotBand на тему аутсорсинга. Поговорили о том, как проекты попадают в аутсорсинговые компании, что с ними происходит до момента старта и как обсуждать с клиентом техническую реализацию, какие бывают проекты и как их оценивать на входе, а также о многом другом. Это мой первый опыт, там есть ляпы, но надеюсь, что получилось интересно и информативно :) Если есть, что добавить или с чем поспорить – comments are welcome!

Послушать подкаст можно на официальной странице: http://www.dotband.com/2012/01/3-outsourcing.html.

Большое спасибо Диме, Толику, Антону и Максу за приглашение!

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

2012-01-01T12:32:00.001+02:00

В первую очередь хочется поздравить всех с наступившим Новым годом! Желаю в 2012 исполнить все, что вы запланировали и о чем мечтаете, а то мало ли :)

2011 год выдался довольно продуктивным на различные поездки, поэтому неплохих фотографий получилось довольно много. Кроме этого летом приказал долго жить наш старичок Canon A620, служивший верой и правдой 5 лет, и ему пришлось срочно искать замену. В качестве замены был куплен Canon 60D (тушка) и объектив Sigma 17-70mm F2.8-4.0. Не могу сказать, что я уже освоился с этим девайсом, но я потихоньку учусь. В планах на январь купить еще один небольшой фотоаппарат (мыльницу) достаточного качества для того чтобы можно было ее брать с собой туда, куда взять зеркалку либо тяжело, либо жалко: байдарочные походы, горнолыжный отдых, некоторые велопокатушки и соревнования, и т.д.

Фотографии разделены на тематические группы по несколько фотографии в каждой. На главной будет всего 3 фотографии, остальные под катом.

Пейзаж

Псел, Михайловка

Spring Mountains, США

Храм Изиды, Большой Каньон, США

Дерево на склоне, Большой Каньон, США

Город

Большой канал, Венеция

Мосты Флоренции

“Вавилонская башня”, Сиена

Живописный комьюнити, Лас-Вегас

Кафе, Львов

Архитектура

Санта Мария делла Салюте, Венеция

Дамба Гувера на Колорадо

Отель Венецианец, Лас Вегас

Скульптура

Ангел, Венеция

Скульптура мальчика в садах Боболи, Флоренция

Памятник Пуччини, Сиена

Памятник Шевченко, Львов

Животные

Есть чо?

Заяц в лесу

Собак

Нора хищника

Люди, портрет

Разное

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

Аутсорсинг и продуктовая разработка

2011-12-29T21:38:00.001+02:00

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

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

Сразу хочу извиниться перед теми, для кого эта информация будет сродни откровениям кэпа, но очень хочется внести ясность в этот вопрос.

Итак, компании, так или иначе занимающиеся разработкой ПО, можно условно разделить на 2 группы:

производящие ПО для собственных нужд или с целью самостоятельного распространения (продукты и услуги)
предоставляющие услуги по разработке ПО для сторонних заказчиков

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

С точки зрения рынка разработки ПО, это самое ПО, в свою очередь, также можно разделить на 2 группы:

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

Если и другие классификации ПО, но нам они сейчас не очень интересны.

Понятно, что custom solutions могут разрабатываться как внутри самой компании (in-house), так и на заказ у какого-нибудь вендора. Но ведь и продукты со “стартапами” не всегда разрабатываются внутри компании, которая потом эти продукты продает.

Если скрестить это все, то получим следующую картинку:

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

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

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

Распределенные транзакции (Distributed Transactions) и их настройка

2011-12-26T22:51:00.001+02:00

Каждый программист, работающий с данными, сталкивался с обычными транзакциями той или иной базы данных. Основная задача транзакций – обеспечить consistency данных после завершения операции: изменения либо успешно сохраняются от начала и до конца, либо полностью откатываются, если что-то пошло не так. Даже если вы ни разу не писали в SQL коде ключевые слова BEGIN TRAN, COMMIT TRAN или ROLLBACK TRAN или нечто подобное, это еще не значит, что вы их не использовали. Все ORM, реализующие паттерн unit of work (Entity Framework, NHibernate и др.) объединяют операции по изменению данных в транзакцию перед сохранением.

Транзакции хорошо работают в рамках одной базы данных, но если у вас распределенная система, которая требует сохранения данных в разных базах на разных серверах, а иногда и платформах, то нужна более тяжелая артиллерия – распределенные транзакции (distributed transactions, DT).

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

Truly Understanding .NET Transactions and WCF Implementation

Работа вложенных транзакций отлично расписана здесь:

Understanding nested transaction scopes

Также не забывайте про MSDN:

http://msdn.microsoft.com/en-us/library/w97s6fw4(v=VS.90).aspx

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

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

1) Сконфигурировать WCF для поддержки DT

Распределенные транзакции не поддерживаются в режиме basicHttpBinding, поэтому нам нужно использовать хотя бы на wsHttpBinding, в binding которого нужно прописать атрибут transactionFlow=”true”:

<wshttpbinding>
    <binding name="wsConfig" transactionflow="true">
         <security mode="None" />
    </binding>
</wshttpbinding>

2) Установить специальные атрибуты в интерфейсе сервиса и его методов

Необходимо добавить атрибуты TransactionFlow для метода в контракте и свойства атрибута OperationBehavior TransactionScopeRequired и опционально TransactionAutoComplete в реализации метода:

[ServiceContract] 
public interface IServiceContract 
{ 
    [OperationContract] 
    [TransactionFlow(TransactionFlowOption.Allowed)] 
    string ServiceMethod(string param1, string param2); 
}

public class Service : IServiceContract 
{ 
    [OperationBehavior(TransactionScopeRequired = true, TransactionAutoComplete = true)] 
    public string ServiceMethod(string param1, string param2) 
    { 
      // some server-side operations with database 
    } 
}

Атрибут TransactionFlow принимает несколько опций: Allowed обозначает, что метод сервиса может вызываться как из кода, обернутого в TransactionScope, так и из обычного. Mandatory требует наличия TransactionScope, а NotAllowed (по умолчанию) заставит сервис игнорировать транзакции на клиенте вообще.

3) Создать на стороне клиента транзакцию, внутри которой вызвать метод WCF сервиса

Выглядит это приблизительно так:

public static string DoSomethingWithRemoteCall(string param1, string param2) 
{ 
    string result = null; 

    TransactionOptions options = 
        new TransactionOptions { IsolationLevel = IsolationLevel.ReadCommitted, Timeout = TimeSpan.FromSeconds(300) }; 
    using (TransactionScope scope = new TransactionScope(TransactionScopeOption.RequiresNew, options)) 
    { 
        // some client-side database actions 

        using (var ecommerceFactory = new ChannelFactory("Staging")) 
        { 
            ecommerceFactory.Open(); 

            var proxy = ecommerceFactory.CreateChannel(); 
            bool success = false; 

            try 
            { 
                result = proxy.ServiceMethod(param1, param2); 
                success = true; 
            } 
            catch (Exception ex) 
            { 
                // log exception 
                return;

            } 
            finally 
            { 
                if (success) 
                    ecommerceFactory.Close(); 
                else 
                    ecommerceFactory.Abort(); 
            } 
        } 

        // other possible client-side database actions
        scope.Complete(); 
    } 

    return result; 
}

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

TransactionOptions позволяет задать некоторые параметры транзакции. В нашем случае это уровень изоляции (значение по умолчанию Serializable не рекомендуется из-за опасности возникновения дедлоков) и таймаут операции (5 минут).

При создании TransactionScope мы указываем параметр TransactionScopeOption.RequiresNew, что не позволит никакому другому коду обернуть наш метод в свою транзакцию. Подробнее вложенные транзакции описаны здесь.

Внутри TransactionScope в случае, если мы действительно хотим закоммитить транзакцию, мы делаем вызов scope.Complete(). Если нам нужно транзакцию откатить (как в случае с catch в примере), мы просто не вызываем Complete(). Вызывать Complete() нужно после всех клиентских операций с базой данных, которые происходят внутри транзакции, иначе у вас случится ошибка, что connection или provider уже закрыт.

Обратите внимание, что в коде сервиса из предыдущего пункта нет никакого намека на TransactionScope, кроме атрибутов TransactionFlow и OperationBehavior. Он там и не нужен, для стандартного сценария атрибутов достаточно. Однако никто вам не мешает создавать свои вложенные транзакции, как с опцией Required (используем родительскую транзакцию), так и с опциями RequiresNew (новая независимая транзакция) и Suppress (код не будет выполнятся в родительской транзакции).

4) Запустить сервис и клиент

И вуаля – все работает. Или не работает? Говорите, полезли странные ошибки выполнения?

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

1) Убедиться, что на всех клиентах и серверах (здесь и далее - включая сервера баз данных и веб-сервера) установлена и запущена служба Distribution Transactions Coordinator. Именно эта служба отвечает за координацию ваших распределенных транзакций.

2) Убедиться, что на всех клиентах и серверах включена поддержка распределенных транзакций. Для этого запускаем Control Panel –> Administrative Tools –> Component Services, идем в Computers –> My Computer –> Distributed Transaction Coordinator –> Properties (контекстное меню) и устанавливаем на вкладке Security следующие параметры:

Network DTC Access
Allow Remote Clients
Allow Inbound
Allow Outbound

3) Разрешить работу Distributed Transactions Coordinator во всех установленных брандмауэрах, включая Windows Firewall:

4) Убедиться, что все ваши клиенты и сервера находятся в одной локальной сети. В большинстве случаев так оно и есть, но есть исключения, и если вы тот самый счастливчик, то вам придется немного попотеть, реализовывая поддержку протокола WS-Atomic Transaction (WS-AT), который упоминается в общей статье. Если вы тот самый счастливчик, которому надо начинать настраивать WS-AT, то вот еще пара полезных статей:

Configuring WS-Atomic Transaction support (MSDN)

Building transactional Web services with WebSphere Application Server and Microsoft .NET using WS-AtomicTransaction

5) Для работы DTC по локальной сети: все машины должны пинговаться по netbios-имени.

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

Больше деталей здесь: Warning: the CID values for both test machines are the same

7) Если ничего не помогло: поставить и запустить DTCPing и посмотреть, что она говорит. Очень хороший способ, когда ничего другое не помогает:

Troubleshooting MSDTC issues with the DTCPing tool

Paypal: работа с 3rd party merchant accounts

2011-12-03T17:02:00.001+02:00

Интеграция с Paypal – вещь не сложная. Paypal поддерживает два типа API: Name-Value pairs (URL-based) и стандартный SOAP, а также несколько сервисов для работы, из которых самые распространенные Website Payments Standard и Website Payments Pro (Express Checkout и Direct Payments). Paypal также предоставлят Sandbox для тестирования и достаточно подробную документацию по каждому продукту и типу интеграции. Это если вкратце.

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

Для того, чтобы ecommerce сайт работал с Paypal, необходимо иметь Paypal merchant аккаунт, на который идет вся оплата за товары и услуги, продаваемые на сайте. Для авторизации на Paypal для аккаунта генерируются т.н. API Credentials: Username, Password и Signature/Certificate (лучше использовать Signature). Как это делается, в деталях рассказывается в документации. То есть механизм простой: веб-приложение передает запросы на Paypal, используя три параметра API Credentials, а Paypal таким образом “знает”, с каким merchant аккаунтом идет работа, грубо говоря, кому перечислять деньги за товары.

Все это замечательно работает, когда у вас в приложении “хостится” один продавец, и так работает наверно 95% всех ecommerce-сайтов, от простейших шаблонных электронных магазинов до более серьезных решений. Но в случае реализации сложной торговой площадки, на которой может работать множество торговцев, вроде Amazon.com, eBay.com или etsy.com, этого становится недостаточно. Есть два способа решения этой задачи.

Первый способ очевидный: пусть каждый merchant сгенерирует себе API Credentials и укажет их в своем профиле торговой площадки. Тогда при работе с выбранным Paypal API нужно будет всего лишь подставлять нужные credentials – и вуаля. Однако если посмотреть на профили того же Amazon или eBay для торговцев, то можно увидеть, что они просят ввести только Merchant account email. И никаких паролей или API credentials! Это и есть второй способ интеграции, не так хорошо задокументированный.

Упоминание об этом способе почему-то достаточно хорошо скрывается в документации к функциям API и фактически встречается лишь в описании работы с Name-Value pairs API и на форумах (кстати, форумы Paypal очень полезны, но гуглом не индексируются, поэтому лучше искать прямо там). Вот оно:

То есть можно сгенерировать API Credentials для всего приложения и динамически подменять лишь SUBJECT поле для каждого запроса, таким образом говоря Paypal, с каким merchant сейчас идет работа. И все бы хорошо, да только NOTE там указан не просто так. Paypal API достаточно мощный и дает возможность обращаться к некоторой внутренней информации merchant аккаунта, поэтому необходимо, чтобы merchant дал разрешение на определенные операции. Эти разрешения merchant может задать в Profile –> API Access –> Grant API Permissions. Далее нужно ввести API account username торговой площадки, которой даются разрешения и в появившемся списке выбрать те разрешения, которые нужны. Например, для работы с Express Checkout нужно выбрать как минимум:

Use Express Checkout to process payments

Также полезными могут оказаться:

Authorize and capture your PayPal transactions – если оплата проходит в 2 этапа: авторизация и захват/списание денег
Refund a transaction on your behalf – для возврата денег в случае возврата товара
и некоторые другие (полный список есть здесь)

Дальше – больше. Процесс разрешения прав можно упростить для торговцев еще сильнее, если использовать т.н. Paypal Permissions Service. Этот сервис предоставляет возможность интеграции торговой площадки со специальными страницами разрешения прав на Paypal. То есть пользователю-торговцу достаточно лишь кликнуть ссылку или кнопку на сайте торговой площадки, и он будет автоматически переброшен на страницу Paypal с уже выбранным набором прав для разрешения, необходимых вашему приложению. Пользователю останется лишь подтвердить разрешение.

Тестирование этого процесса также заслуживает внимания, так как там притаилась еще одна небольшая засада. Вам необходимо создать 2 (!) различных sandbox-аккаунта, один из которых будет использоваться для создания API Credentials веб-приложения, а второй – для создания тестовых merchant-аккаунтов, которые будут якобы продавать товары. И неважно, что merchant (или seller) аккаунты можно создать и на основном sandbox аккаунте, вам не удастся сконфигурировать нужные права и Paypal будет возвращать непонятные ошибки.

Надеюсь, для кого-то эта информация окажется полезной и сэкономит время.

Онлайн-курсы от Стэнфорда

2011-11-19T19:45:00.001+02:00

Многие программерские ресурсы уже раструбили эту новость, но, может, кто-то еще не слышал. Полтора месяца назад Стэнфордский университет запустил бесплатные онлайн-курсы по Artificial Intelligence и Machine Learning. Эксперимент оказался довольно удачным (хотя отзывы по курсу AI и хуже, чем по ML) и с января по март запускается вторая волна курсов, 8 9 по Computer Science и 2 по Enterpreneurship:

1. Machine Learning — jan2012.ml-class.org
2. Introduction to Computer Science — www.cs101-class.org
3. Natural Language Processing — www.nlp-class.org
4. SaaS and Software Engineering — www.saas-class.org
5. Human-Computer Interaction — www.hci-class.org
6. Game Theory — www.game-theory-class.org
7. Probabilistic Graphical Models — www.pgm-class.org
8. Cryptography — www.crypto-class.org
9. Design and Analysis of Algorithms — http://www.algo-class.org/
10. Technology Entrepreneurship — www.entrepreneur-class.org
11. The Lean Launchpad — www.launchpad-class.org

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

Курсы можно проходить в одном из двух режимов: Basic или Advanced track. В Basic треке вы просматриваете лекции и отвечаете на еженедельные тесты. При этом никто ничего от вас не требует. В Advanced треке в дополнение нужно делать лабораторные работы, которые будут проверяться преподавателями. Работы оцениваются, их нужно сдавать вовремя, за опоздание начисляются штрафные баллы. В конце курса в случае Advanced трека будут подведены итоги, и вы получите письмо от преподавателя с вашими результатами. Никаких сертификатов и прочего – все знания, что успели ухватить – все ваше.

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

Я решил записаться на 3 курса: Machine Learning, Natural Language Processing и Game Theory. По первому очень хорошие отзывы, да и просто любопытно сравнить с тем, чему нас учили, вторым я немного занимался в университете, а третий просто интересно прослушать – на нашей специальности (ПОАС) теории игр не было, но встречаюсь с ней все чаще. Не уверен, что хватит времени пройти все по Advanced треку, но во-первых, всегда можно перейти на Basic или вообще отказаться, а во-вторых, я думаю начать проходить Machine Learning сейчас с первой группой, включая лабораторные работы, чтобы в январе-марте сэкономить себе время на этом курсе.

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

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

PPS. Курсы добавляются как грибы после дождя. Появился еще один курс, на этот раз по дизайну и анализу алгоритмов: http://www.algo-class.org/

Будущее Silverlight

2011-06-28T15:03:00.001+03:00

Очень странно наблюдать поднявшуюся в последний месяц истерию по поводу того, что Microsoft якобы “разочаровался в WPF/Silverlight” и планирует смену курса в сторону набирающего популярность HTML5. Тема вовсю обсуждается на форумах MSDN, в комментариях серьезных блоггеров, на Хабре и даже в твиттере. Несмотря на явную невозможность нативной разработки под Windows при помощи ыHTML5/JS, у этой истерии, безусловно, есть корни. Осенью прошлого года официальные лица Microsoft уже обронили несколько фраз о переосмыслении стратегии развития Silverlight, а в начале июня подлили масла в огонь, показав Windows 8 с возможностью разработки на HTML5/JS и ни словом не обмолвившись о Silverlight. Если погуглить по фразе “Windows 8 silverlight”, то можно найти кучу криков о смерти Silverlight и плач тысяч разработчиков, которые выбрали Silverlight своей основной платформой для разработки и теперь считают себя брошенными на произвол судьбы. Добил фанов технологии .NET Community Manager Pete Brown, который высказался ясно и в то же время очень неопределенно:

“You all saw a very small technology demo of Windows 8, and a brief press release. We’re all being quiet right now because we can’t comment on this. It’s not because we don’t care, aren’t listening, have given up, or are agreeing or disagreeing with you on something. All I can say for now is to please wait until September. If we say more before then, that will be great, but there are no promises (and I’m not aware of any plans) to say more right now. I’m very sorry that there’s nothing else to share at the moment. I know that answer is terrible, but it’s all that we can say right now. Seriously.”

Сентябрь, о котором идет речь – это конференция Build, на которой ожидается релиз Silverlight 5, Windows Phone 7 Mango, а также первые настоящие презентации Windows 8 с объяснениями дальнейшей стратегии компании.

Безусловно, можно подождать еще 2.5 месяца и узнать, какую роль Microsoft отводит для Silverlight в своей новой концепции. Но ждать еще долго, а некоторые решения нужно принимать уже сейчас. Попробуем разобраться сами.

Итак, что у нас есть из не очень хорошего:

Microsoft, безусловно, немного разочарована скоростью распространения Silverlight и его положением на рынке. И хотя процент установки Silverlight в браузерах уже достаточно высок (на данный момент около 75%, http://www.riastats.com/), но он все равно еще недостаточен и не дает технологии стать по-настоящему популярной.
Другая проблема Silverlight – его неполная кроссплатформенность. Поддержка Windows и Mac – это, конечно, где-то 90-95% рынка десктопов (а, может, и больше, если верить http://gs.statcounter.com/#os-ww-monthly-201005-201105), но с точки зрения разработки широкопользовательских веб-приложений остается непокрытым весь Linux’овый зоопарк. Не добавляет очков и слабая поддержка SEO.
На мобильных платформах подержка Silverlight вообще стремится к нулю. Ни iOS, ни Blackberry, ни Android не поддерживают Silverlight и вряд ли будут стремиться к этому. Единственная платформа, где он поддерживается – это WP7, правда, не в браузере. Но доля WP7 на рынке мобильных устройств (http://itc.ua/news/gartner_android_yavlyaetsya_samoj_populyarnoj_os_dlya_smartfonov_53536) и количество заказов на разработку WP7 приложений пока настолько малы, что серьезно раздумывать о карьере разработчика мобильных приложений пока не получается.

В то же время несмотря на все эти недостатки Silverlight уже занял свою определенную нишу, где он очень силен, в первую очередь благодаря скорости разработки и возможностям, недоступным стандартному HTML/JS клиенту:

Enterprise и LOB RIA приложения (нивелируются проблемы слабой кроссплатформенности и распространенности)
веб-приложения, в которых пользователи готовы установить плагин ради получения доступа к продвинутым возможностям, а не уйти к конкурентам (не e-commerce)
мультимедиа-приложения с красивой и сложной анимацией, поддержкой video streaming
кроме того, Silverlight пока остается основной платформой для разработки под Windows Phone 7

С чем же связано то, что Microsoft, вложившая 4 года и миллионы долларов в разработку и продвижение кроссплатформенной .NET-технологии, потихоньку смотрит в сторону HTML5/JS? И что же все-таки будет с Silverlight дальше?

Во-первых, любой компании, которая производит ОС, важно привлекать как можно большее количество разработчиков на свою сторону. Silverlight и WPF требуют от не .NET-разработчиков изучения слишком многого. А возможность сделать пусть и простое, но все же приложение под Windows 8 на HTML5/JS – это шанс. Тем более, что Windows 8 позиционируется и как операционка для планшетов – а это очень перспективный рынок. Уверен на 99%, что в сентябре на Build будет сказано о полной поддержке WPF (а куда ж он денется?), а также Silverlight как минимум на уровне разработки таких же приложений, которые будут разрабатываться на HTML5/JS.

Во-вторых, есть ощущение, что Microsoft пойдет на еще один непопулярный, но очень важный с точки зрения развития своей мобильной платформы шаг – даст возможность разрабатывать нативные приложения на HTML5/JS в Windows Phone. Думаю, начиная с восьмой версии, чтобы поддержать версионирование, но, может, и в Mango (7.5) добавят. Криков о помощи будет еще больше, но Microsoft нужно догонять убегающие iOS и Android. Разработчики мобильных приложений под iOS и Android не торопятся переносить свои приложения под WP7 в том числе и потому, что это требует совсем других навыков. Если бы у Microsoft было хотя бы 40% рынка, они могли бы закрыть глаза на простоту разработки, но с текущими 6% им некуда деваться.

В-третьих, Silverlight никуда не уйдет из web’а в ближайшие 3-5 лет. Его доля будет по-прежнему неуклонно расти, приложения будут разрабатываться, но вот из своей ниши он вряд ли выйдет. Этому будет мешать развитие HTML5 и рост рынка веб-приложений под мобильные устройства. Конечно, Microsoft может попробовать разработать Silverlight-плагины для мобильных операционных систем и браузеров, но это огромные деньги, а эффекта практически не будет.

В поддержку Silverlight на нативном уровне верится еще меньше. Такое возможно лишь на Android, и то лишь благодаря Mono, который и сам находится в непонятном статусе. Еще возможно продвижение Silverlight на Symbian, благо с Nokia есть договор, но какой смысл? Ведь есть готовый WP7, который можно ставить на устройства. На фоне же прогнозов о росте использования мобильных веб-приложений и снижения нативной разработки (это банально намного проще и дешевле!) смысла вкладываться в эту сферу вообще нет.

Ну, и в-четвертых, отдельно стоит сказать пару слов о Silverlight vs. HTML5, вернее даже plugins (Flash/Silverlight) vs. HTML5 (это отдельная фишка: под угрозой HTML5 сейчас объединяются даже ранее враждовавшие разработчики Flash/Flex и Silverlight :)). На эту тему сломано уже очень много копий (почитайте отдельно, если вам интересно), но ясно одно: HTML5 не покрывает всех возможностей Silverlight и Flash/Flex, поэтому их рано списывать со счетов. Кроме того, как все правильно отмечают, плагины пополняются новой функциональностью быстрее, чем развивается HTML и обновляются версии браузеров. Если же отвечать на вопрос: что лучше использовать в качестве клиента в каждый конкретный момент времени, то советую почитать два отличных поста:

Лично я себя намного комфортнее чувствую в разработке обычных ASP.NET MVC приложений, чем Silverlight, но это не значит, что нет приложений, для которых использование Silverlight будет более выгодным или дешевым. Особенно если мы говорим о портировании WPF-приложений в веб.

А вы что думаете по всему этому поводу?

Итальянские впечатления – 4. Кухня

2011-06-21T09:31:00.001+03:00

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

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

Паста в Италии считается первым блюдом (!). Привычных нам жидких супов в Италии почти нет, а то, что они называют супом, мы скорее можем назвать пюре. Паста – это общее название макаронных изделий, которые, как правило, подаются с различным соусом. Видов макарон в Италии очень много: кроме привычных нам maccheroni, vermicelli и spaghetti, есть еще пара десятков неизвестных bigoli, tagliatelli, tortiglioni, penne, fusilli, flocchi, fertalle, lasagne, raviolli, gnocci и т.д. Немного больше об итальянской пасте можно почитать в вики. Паста очень вкусная, но здесь важно подобрать подходящий соус. Мы пару раз ошибались. К пасте почти всегда подают тертый пармезан в отдельной посуде.

Основные блюда сильно зависят от региона. В Тоскане, например, больше мясной кухни, в Венеции и других “морских” городах – морепродуктов.

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

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

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

Ну, и напоследок о сладостях. Мы перепробовали большое количество “итальянского” мороженого (продается шариками), которое на удивление стоит дешевле, чем у нас. В основном очень вкусно. Также пробовали несколько пирожных и традиционные сиенские сладости.

На этом итальянская серия заканчивается и начинаем снова писать серьезные вещи :)

Итальянские впечатления – 3. Венеция

2011-06-19T18:53:00.001+03:00

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

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

Венецианская республика была одной из самых сильных морских и торговых держав Средневековья. Ее островное местоположение давало ей защиту от экспансии с суши, а со штапелей судостроительных верфей каждый день спускался на воду новый торговый или военный корабль. Венеция славно поживилась в IV Крестовом походе, когда в хитростью направила усилия крестоносцев на православную Византию с целью возврата власти свергнутому императору Исааку II Ангелу. В результате похода республике отошло больше трети территории бывшей Византийской империи, власть в Константинопольской гавани, торговая монополия на территории свежесозданной на руинах Византии Латинской империи, а также огромное количество богатств и предметов искусства, которые были вывезены в Венецию после разграбления Византии. Такой вот ход конем. Венецианская республика (которая на деле была аристократическим государством), по сути сидела между западом и востоком, зарабатывая на этом. Торговля и промышленность процветали, а народ постоянно богател. Однако это было начало конца.

Уничтожив Византию, которая защищала Европу от мусульманского Востока, Венеции пришлось самой столкнуться с турецкой экспансией после падения Константинополя в 1453 году. Европейские страны стали искать другие торговые пути и нашли их, открыв морской путь в Ост-Индию, а также заодно Америку. Великие географические открытия сместили акцент торговли в сторону Атлантики и Индийского океана, а постоянные войны с Османской империей ослабили республику. За два века османы отняли у Венеции значительную часть ее владений. Добил Венецию Бонапарт, захватив ее без сопротивления в 1797 году и уничтожив республику.

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

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

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

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

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

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

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

И самое главное – не забудьте прокатиться на ~~гондоле~~ вапоретто по Гранд-Каналу! Вапоретто – это венецианский морской трамвай, единственный вид общественного транспорта в островной Венеции, где нет и намека на автомобили или автобусы. На один из маршрутов можно сесть на площади Сан-Марко и доехать до ж/д вокзала и Пьяццале Рома (автобусная станция), или наоборот. Вапоретто двигается медленно, останавлиясь по очереди на каждом берегу канала, давая возможность рассмотреть дворцы и мосты с таких ракурсов, которые недоступны с берега. Поездка занимает около часа. Насчет гондол – решайте сами. Удовольствие стоит 100 евро за 40 минут, в гондолу может сесть 5-6 человек. У нас не было компании, и мы посчитали, что 100 евро на семью – оно того не стоит.

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

Итальянские впечатления – 2. Тоскана

2011-05-30T10:14:00.001+03:00

Тоскана – это регион в Италии, центром которого является Флоренция. Кроме Флоренции, в нее входят такие известные города как Сиена, Пиза, Лукка и Гросетто. Тоскана считается самой красивой областью, это место происхождения итальянского Возрождения, на территории которого сосредоточены около половины всего культурного наследия Италии.

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

Фьезоле, Бивильяно

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

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

Дорога до Фьезоле – это затяжный малоинтересный подъем. Сам же Фьезоле – интересный городок, в котором можно посмотреть главную площадь, монастырь и развалины амфитеатра, а также передохнуть перед дальнейшей дорогой. Из Фьезоле открывается красивый вид на Флоренцию, но по своему опыту могу сказать, что вид с площади Микеланжело намного интереснее.

После выезда из Фьезоле начинается сельская местность, где встречаются как небольшие поселки, так и настоящие виллы, стоящие посередине виноградников и оливковых садов. Дорога постоянно идет вверх и километров через 10 холмисто-лесистая местность сначала переходит в красивый лес, а затем – в оголенные холмы.

По дороге постоянно гоняют байкеры на крутых мотоциклах. А еще через несколько километров мы приезжаем в Бивильяно. Бивильяно – это небольшой симпатичный городок, но по большому счету делать там нечего. Зато дорога назад – это просто сказка! Стоило вкручивать педали в горку столько километров, чтобы потом оставить ноги в покое и просто катиться назад. Хорошая погода, ветер в лицо, любимый человек рядом и прекрасные виды вокруг – что еще нужно для счастья?

Из Фьезоле стоит возвращаться другой дорогой – через Вивильяно. Дорога идет по настоящему лесному серпантину, а потом выходит в сельскую местность западнее Флоренции. Здесь очень много красивых вилл и сочных лугов, в общем, красиво.

Лукка

Поезда в Лукку отправляются из Флоренции каждый час. Итальянские поезда – это отдельная тема для разговора. Чистые и удобные вагоны, никакой тряски во время движения, хотя крейсерская скорость – 130-140 км/ч. При поворотах поезд наклоняется как самолет, чтобы плавнее войти в поворот. Разница между междугородними поездами и пригородными “электричками” невелика. Последние даже комфортнее, чем украинские экспрессы типа Харьков-Киев.

Лукка – небольшой городок на запад от Флоренции, всего около 85 тысяч жителей. В нем уникальная планировка: центральная историческая часть ограничена крепостными стенами, причем диаметр внутренней части – больше 4 км. В Лукке есть что посмотреть, на довольно небольшом участке – куча площадей, соборов, статуй и других достопримечательностей. Порадовало, что туристов намного меньше, чем во Флоренции, и в то же время кафешек и магазинчиков вполне достаточно, чтобы хорошо отдохнуть.

Город лучше всего осматривать на велосипеде. Его можно арендовать во многих местах возле крепостной стены. 2.5 евро – час, 7.5 евро – 5 часов. Кататься можно не только по центру города, но и по крепостным стенам, которые служат для прогулок и отдыха горожан и гостей города. По стене шириной 10-20 метров проходит вело-пешеходная дорожка, по краям которой посажены деревья и разбиты лужайки. Бастионы используются как парки и смотровые площадки. На дорожке постоянное движение – гуляют семьи с детьми, бегают трусцой молодые и пожилые люди, катаются на велосипедах туристы и даже спортсмены. Вообще, итальянцы очень спортивны, занимаются своим здоровьем, все сухощавы и подтянуты, никакого ожирения, несмотря на обилие теста в национальной кухне.

Мы прокатались почти по всей стене и объехали все основные достопримечательности города. Жителям города очень повезло. Центр – привычные для средневековых итальянских городов каменные джунгли, деревьев и зелени мало или вообще нет. Зато это с лихвой компенсируется возможностью выйти на стену и там погулять, поваляться на траве или покатать детей в коляске. Детей вокруг очень много, мы часто видели пап с колясками – итальянцы традиционно трепетно относятся к семье и семейным обязанностям.

Вообще, если ехать жить в Италию, то Лукка – превосходный выбор. Есть исторический центр, где радуется глаз, места отдыха, зеленая парковая зона, спортивная культура. Недалеко – Флоренция и Пиза, можно съездить на море. Вокруг – горы, наверняка есть трекинговые маршруты и зимние курорты.

Сиена

До Сиены мы тоже добирались на поезде. Сиена – городок еще меньший, чем Лукка, всего 55 тыс. человек. Трудно поверить, что в Средние века Сиена по-настоящему боролась с Флоренцией за господство в регионе и вела кровопролитные бои на протяжении нескольких столетий (Гфельфы и Гиббелины).

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

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

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

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

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

Все фотографии из Тосканы можно посмотреть на пикасе: Фьезоле-Бивильяно, Лукка и Сиена. В следующий раз я расскажу о Венеции и итальянской кухне.

Итальянские впечатления – 1. Флоренция

2011-05-29T13:57:00.001+03:00

Чуть больше месяца назад мы с Леной съездили в отпуск в Италию. Мы посетили 4 города, осмотрели множество достопримечательностей, попробовали настояющую итальянскую кухню и, надеюсь, смогли немножко прочувствовать эту замечательную страну. И пока еще не все впечатления, эмоции и воспоминания потускнели, хочется их сохранить где-нибудь на память.

Сначала немного об организационных моментах. До Италии и назад мы добирались на самолете, рейс Киев - Венеция Тревизо лоу-коста Wizzair. Тревизо – это на самом деле не Венеция, а городок в 30 км от нее. В Киеве мы тоже вылетали не из Борисполя, а из Жулян, куда Wizzair недавно полностью перебазировался. Не знаю, как кому, а мне это даже понравилось: небольшие аэропорты, людей немного, все происходит очень быстро. И если не считать процесса получения багажа в Киеве (толпу людей, которые забирают свой багаж в тесной комнатушке прямо из рук работников аэропорта), аэропорт Жулян тоже вполне неплох.

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

Итак, двухчасовый перелет, сорокаминутная поездка на шаттле за 5 евро – и мы в Венеции. Мы не брали туристическую программу, ехали “дикарями”, потому что предпочитаем выбирать сами, что смотреть и когда. Однако какой-то план у нас все же был, подтвержденный забронированными гостиницами: 7 ночей во Флоренции с разъездами по Тоскане и 2 ночи в Венеции. В Рим мы решили в этот раз не ехать вообще – невозможно все успеть. Венеция была прихвачена за компанию лишь из-за того, что туда был рейс, но справедливости ради нужно отметить, что я очень рад, что мы там побывали.

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

Флоренция

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

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

Купол собора Санта-Мария-дель-Фьоре (Дуомо) знаменит тем, что до сих доподлинно неизвестно как он был построен. Для XIV-XV века постройка такого купола была очень сложной инженерной задачей, которую осуществил Филиппо Брунеллески. Росписи купола тоже достойны восхищения. Их можно увидеть вблизи, если заплатить за вход на смотровую площадку купола. В нижней части росписей – ад, в верхней, конечно же, рай. Фрески очень крупные, снизу это невозможно оценить. С купола открывается красивый вид на центральную часть Флоренции – в общем, рекомендую посетить.

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

Большая часть произведений искусства города были созданы на заказ. Династия Медичи в своем стремлении доказать превосходство Флоренции над другими городами Тосканы и Италии (в основном над Сиеной) нанимала архитекторов, скульпторов, художников и ювелиров, которые творили один шедевр за другим.

Сейчас Флоренция – это город, зарабатывающий сумасшедшие деньги на туристах. Его посещают около 2 млн. человек в год. Конечно, это не Венеция с ее 20 млн., но все же в городе очень много гостиниц разного калибра, кафе/ресторанов, туристических лавок, модных магазинов и, конечно же, туристов. В то же время этот город еще не стал жертвой туристического бизнеса (и я надеюсь, никогда не станет). Видно, что в центре живет много местных жителей, по узким улочкам на мопедах и велосипедах едут на работу и домой взрослые, гуляет молодежь.

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

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

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

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

Мы пообщались с несколькими итальянцами на улице. Они нас спрашивали про Украину, мы их – про Италию. Итальянцы считают, что мы тут очень бедно живем, раз приезжаем к ним на заработки. Во многом они правы, конечно. Мы пытались их переубедить, показать нашу страну с хорошей стороны. Впрочем, итальянцы не сильно в восторге и от своего положения – кризис сильно ударил по стране, а мафия и коррупция все еще живы. Наш гид-итальянка сказала российской группе, к которой мы примкнули, сакраментальную фразу: “А это Дворец Правосудия. Дворец есть, правосудия нет. Ни у вас, ни у нас. Остается уповать лишь на Божье правосудие!”. Еще поговорили о футболе, конечно же, куда ж мы без этого :)

Для того чтобы увидеть все достопримечательности Флоренции одной недели недостаточно. Мы же выделили себе всего 3.5 дня, а остальное время посвятили 3-м загородкам: Фьезоле-Бивильяно, Лукка и Сиена. О них я расскажу в следующий раз.

Полный фотоальбом из Флоренции можно посмотреть здесь.

Компании + вузы = исследования?

2011-05-20T09:33:00.001+03:00

Только что прочел новость о том, что в ХНУРЭ открыли научно-учебную лабораторию по IT-технологиям. Особенно доставляет несколько моментов:

лабораторию открыли при непосредственном участии EPAM Systems
лабораторию называют “научно-учебной” :)
проректор по научной работе ХНУРЭ говорит (просто на камеру?), что открытие лаборатории позволит улучшить уровень исследовательской работы университета

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

Смешно другое. Каким боком это все к исследованиям и научной работе? Это ведь обычный компьютерный класс + программа обучения студентов, направленная на то, чтобы они знали востребованные на рынке языки программирования и технологии и их уровень адаптации на месте работы был минимальным. Аутсорсинговой компании, которая организовывает подобные курсы, не интересны исследования и научная работа. Об интересах студентов, компаний и вузов я писал 2.5 года назад, но все это до сих пор актуально.

Более того, уверен, что все в ХНУРЭ и других вузах понимают лучше меня, что лучшие студенты, которые уходят на подобные курсы, по сути, потеряны для исследований и научной работы. Их свободное время сначала будет уходить на курсы, потом они пойдут на практику в компанию, потом уйдут туда работать – и все. И произойдет это даже не на 5м курсе, а на 3-4м. Учеба (почти) закончится, диплом будет написан абы как, в аспирантуру студент не пойдет, потому что возможности там заработать нет.

Самое неприятное во всем этом – это то, что в данной ситуации ничего с этим поделать нельзя. Это как раз та модель, когда довольны остаются все стороны: студент получает высокоплачиваемую работу, компании – сотрудников, вуз – хм, в общем, он тоже не остается в накладе. Но это все краткосрочная перспектива. В долгосрочной перспективе студент не получает некоторые фундаментальные CS-знания и исследовательский опыт, предпочитая им изучение инструментов, вуз – талантливых студентов, способных заниматься наукой под руководством преподавателей и аспирантов, компании же не теряют почти ничего, их задачи такие “выпускники” покрывают, серьезных же R&D компаний в Украине нет или почти нет. Две “проигравшие” в долгосрочной перспективе стороны – студенты и вузы – либо не понимают этого (студенты), либо просто живут сегодняшним днем, предпочитая синицу в руке (вузы).

И ситуация не изменится пока в Украине не появится серьезный спрос на исследовательскую работу в области Computer Science и возможность платить за эти услуги. Только тогда вузы смогут удерживать у себя студентов хотя бы на период обучения, давая им другой, не промышленный опыт и знания, в рамках вузов начнут рождаться интересные разработки и стартапы, и курс нашей страны на IT рынке, возможно, сменится с аутсорсинга/аутстаффинга на разработку собственных продуктов и серьезные наукоёмкие исследования.

Прогноз развития рынка разработки ПО

2011-05-15T12:52:00.001+03:00

Disclaimer. Ни один из “прогнозов” не претендует на оригинальность. Скорее это просто наблюдения и попытка их аппроксимировать на ближайшие 5 лет.

1. Плавный переход в веб

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

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

2. Браузер – единственное приложение или Терминалы наносят ответный удар

Наверно, самое часто используемое приложение на домашнем компьютере/лаптопе/нетбуке (нужное подчеркнуть) - браузер. Музыку можно слушать из инета, фильмы, информация, почта, офисные приложения, социальные сети и другие развлечения – тоже там. Google уловил эту тенденцию первым и уже предложил свое решение – Chrome OS. По сути, ОС с единственным пользовательским приложением – браузером. Сейчас эта идея выглядит немного утопично (ведь сколько еще приложений не в вебе!), но в перспективе 5-10 лет, думаю, мы увидим возрождение идеи терминалов в новой форме.

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

3. Развитие “облачных” технологий.

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

Крупные продуктовые компании вовсю копают это направление. “Облачные” сервисы есть у Google (Gmail, Docs, etc.), Microsoft (Exchange, Office 365, Dynamics CRM, etc.), и многих других.

Кроме того, все больше и больше развиваются облачные платформы и для custom-решений. И это не только Amazon EC2, Google App Engine, Microsoft Azure. Очень много хостеров сейчас предлагают услуги облачного хостинга на своих платформах.

4. Значительное увеличение доли мобильных приложений

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

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

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

5. Смещение акцента в разработке мобильных приложений с native в web

Идея проста. Мобильных платформ все больше, доля на рынке так или иначе будет отъедаться даже у текущих лидеров: Apple OS и Android. Если вы хотите, чтобы ваше приложение было доступно не 30% “мобильных” пользователей, а хотя бы 60%, то извольте создать версию своего продукта и под другие платформы. А это очень недешево, технологии и языки программирования везде абсолютно разные, следовательно, создавать новое приложение нужно почти с нуля. А потом еще и поддерживать их все. С веб-приложениями проще – реализация на сервере одна, подстраиваемся под размер экрана и, возможно, меняем немного внешний вид – и готово. С обновлениями тоже все просто. Дешево и сердито. Из плюсов также возможности продажи по подписке, показа рекламы – все это дополнительный заработок.

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

Понятно также, что не все производители приложений вообще стремятся перейти на другую мобильную платформу. Но уже сейчас на рынке есть 2 крупных игрока, хотя бы под них многие будут стараться писать. А ведь еще несколько (RIM, WP7) отдадут все силы, чтобы вмешаться в дележ этого некислого пирога.

6. Уменьшение доли custom решений за счет создания более универсальных продуктов

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

Сложно говорить о каких-то цифрах, их у меня нет. Но, думаю, многие согласятся, что если раньше в разных сферах было много custom решений, призванных решить конкретные нужды конкретного бизнеса или предприятия, то со временем появились универсальные продукты, решающие нужды целого класса таких бизнесов. Примеры: бухгалтерия, CRM, ERP системы, системы обслуживания банков, CMS-ки, eCommerce-платформы, портальные решения (привет, Sharepoint) и т.д.

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

7. Робототехника и интеллектуальные системы

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

Однако, чем дальше, тем больше это направление будет развиваться. Правда, будет ли это происходить в Украине – большой вопрос. Зависит от нас с вами.

А что Вы думаете по этому поводу?

Сертификация Microsoft

2011-03-13T14:36:00.001+02:00

Последние несколько недель я сдаю сертификацию Microsoft. Цель – получить статус MCPD Web Developer 4, т.е. ASP.NET 4.0 Professional Developer.

Для этого есть два пути:

сдать 4 экзамена: ASP.NET 4.0, WCF 4.0, Data Access 4.0 и PRO: ASP.NET 4.0
для тех, у кого есть статус MCPD ASP.NET Developer 3.5 – сдать upgrade-экзамен на 4.0

У меня никаких сертификаций до этого момента не было (не считал, что это нужно, да и сейчас получаю ее не для себя), поэтому мне нужно сдавать 4 экзамена. Три предварительных (MCTS) экзамена уже сдал, остался последний, PRO, но думаю, проблем с ним никаких не будет.

Нужно сказать, что сейчас сертифицируется ОЧЕНЬ много программистов. Причина тому одна: недавно Microsoft поменял правила партнерских соглашений для компаний. Поэтому всем компаниям, у которых есть статусы Certified Partner различной значимости, нужно в срочном порядке получать эти статусы заново. Кстати, нужно сказать, что понятия Certified тоже больше нет. Есть различные компетенции, в общем количестве 28 штук, по которым можно получить уровни Silver и Gold. Это действительно выглядит логичнее: компания может иметь хорошую компетенцию в разработке веб-приложений и не иметь никакой в сервисной интеграции, или наоборот, что помогает потенциальным клиентам разобраться в ситуации и обратиться в нужную компанию. Более подробно об этих изменениях можно почитать здесь: https://partner.microsoft.com/rus/40018260.

Одно из обязательных условий получения партнерства – наличие в компании определенного количества сертифицированных специалистов. Например, если ваша компания хочет получить или подтвердить Gold-компетенцию в разработке веб-приложений, то в штате должно быть 4 Web MCPD-специалиста.

Преимущества партнерства для компаний очевидны: улучшение и упрощение продаж, лицензии ПО, MSDN подписка, техническая поддержка и т.д. А вот что дает сертификация самим программистам? It depends.

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

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

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

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

Bing Maps на Windows Phone 7. Полные исходники

2011-03-13T13:16:00.001+02:00

Я планировал сделать целую серию заметок о создании простого Bing Maps приложения на Windows Phone 7, но жизнь вносит свои коррективы. Большое количество работы, сдача сертификации Microsoft, а также планирование отпуска отбирают все свободное время. К тому же, судя по отсутствию комментариев, эта тема никого особо не трогает. Поэтому эта серия останется незавершенной, но я все-таки хочу выложить все исходники проекта – может, кому-то пригодятся для самостоятельного изучения.

Исходники лежат на Google Code. Вот ссылка на папку Downloads проекта: http://code.google.com/p/wp7-wikimapia-client/downloads/list.

Если будут вопросы по коду или теме в целом – обращайтесь.

Bing Maps на Windows Phone 7. Часть 2. Масштабирование карты

2011-02-01T23:47:00.002+02:00

Первая часть серии была посвящена созданию простейшего Bing Maps приложения для Windows Phone 7. Во второй части мы рассмотрим улучшение контролов изменения масштаба карты (zoom) и коснемся интерфейса INotifyPropertyChanged.

Изменение ViewModel

Может быть, вы заметили, что в прошлой части мы установили свойству ZoomBarVisibility значение Visible. Стандартный Zoom Bar выглядит достаточно грубо, кроме того, отображается в нижней части карты, что не очень удобно. Поэтому мы его заменим на наш собственный.

Для начала устанавливаем свойству ZoomBarVisibility значение Collapsed (или просто удаляем его из списка свойств).

Далее нам нужно расширить наш MapViewModel, добавив туда свойство Zoom, которое будет источником данных для свойства ZoomLevel у контрола Map. Добавляем в MapViewModel свойство и некоторые константы для удобства:

private const double DefaultZoomLevel = 4.0;
private const double MaxZoomLevel = 21.0;
private const double MinZoomLevel = 3.0;

public double Zoom
{
    get { return zoom; }
    set
    {
        var coercedZoom = Math.Max(MinZoomLevel, Math.Min(MaxZoomLevel, value));
        if (zoom != coercedZoom)
        {
            zoom = value;
            NotifyPropertyChanged("Zoom");
        }
    }
}

Здесь вроде бы все понятно за исключением NotifyPropertyChanged. NotifyPropertyChanged – это метод-реализация интерфейса INotifyPropertyChanged. Этот интерфейс используется для оповещения классов, которые привязываются (binding) к источнику данных, об изменениях в этом источнике. В нашем случае контрол Map нашей View будет таким образом оповещаться об изменениях в свойстве Zoom.

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

Добавляем в папку ViewModel проекта новый класс BaseViewModel, который будет выглядеть следующим образом:

public class BaseViewModel : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;

    protected void NotifyPropertyChanged(string propertyName)
    {
        PropertyChangedEventHandler handler = this.PropertyChanged;
        if (handler != null && !String.IsNullOrEmpty(propertyName))
        {
            handler(this, new PropertyChangedEventArgs(propertyName));
        }
    }
}

И наследуем класс MapViewModel от BaseViewModel:

public class MapViewModel : BaseViewModel

Работа с представлением

Теперь нам нужно перейти во View и привязать свойство ZoomLevel контрола Map к свойству Zoom модели представления:

ZoomLevel="{Binding Zoom, Mode=TwoWay}"

Добавляем кнопки для масштабирования карты внутрь <canvas>:

<Button x:Name="ButtonZoomIn" 
    BorderThickness="0" Margin="8,200,0,0" Padding="0"
    HorizontalAlignment="Left" VerticalAlignment="Top" 
    Width="72" Height="72"
    Click="ButtonZoomIn_Click">
        <Image Source="Images/Menu/ZoomIn_White.png" />
</Button>
<Button x:Name="ButtonZoomOut" 
    BorderThickness="0" Margin="8,280,0,0" Padding="0"
    HorizontalAlignment="Left" VerticalAlignment="Top" 
    Height="72" Width="72"
    Click="ButtonZoomOut_Click">
        <Image Source="Images/Menu/ZoomOut_White.png" />
</Button>

Соединяем все вместе

Теперь нжуно реализовать обработку нажатий на кнопки. Для этого добавляем обработчики событий для кнопок, которые будут изменять свойство Zoom модели представления, в code-behind файл MainPage.xaml.cs:

private void ButtonZoomIn_Click(object sender, RoutedEventArgs e)
{
    Model.Zoom++;
}

private void ButtonZoomOut_Click(object sender, RoutedEventArgs e)
{
    Model.Zoom--;
}

Добавляем свойство Model в тот же code-behind файл:

protected MapViewModel Model
{
    get { return (MapViewModel)Resources["ViewModel"]; }
}

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

Если говорить строго, то написание логики представления (а в нашем случае это обработка событий и устновка свойства Zoom) – это уже отход от правильной реализации паттерна MVVM. Но в то же время, code-behind страницы – это все еще View, поэтому мы можем сами решать, как оповещать наш ViewModel о событиях UI. Поэтому для начальной реализации приложения мы будем использовать code-behind страницы как прокси к ViewModel для упрощения реализации. В реальном же приложении нам нужно было бы использовать т.н. команды для привязки событий ко View, а не обычные обработчики. Но поскольку Silverlight до сих пор не обзавелся официальной поддержкой команд (за исключением интерфейса ICommand), а писать свои с нуля мы еще не готовы, то пока что отложим этот вопрос на будущее. Если кому-то интересно узнать больше уже сейчас, вот несколько ссылок:

http://weblogs.asp.net/nmarun/archive/2009/12/02/using-icommand-silverlight-4.aspx
http://johnpapa.net/silverlight/5-simple-steps-to-commanding-in-silverlight/
http://blogs.southworks.net/jdominguez/2008/08/icommand-for-silverlight-with-attached-behaviors/
http://houseofbilz.com/archives/2009/05/22/adventures-in-mvvm-commands-in-silverlight/

Добавляем картинки

Итак, логика готова. Нам осталось лишь добавить картинки для кнопок. Для этого создаем папку Images\Menu в проекте и добавляем туда файлы ZoomIn_White.png и ZoomOut_White.png. Скачать все файлы картинок, включая эти две, можно отсюда. Напоследок нам нужно открыть окно Properties для каждой из этих картинок и установить там свойство Build Action в Content вместо Resource. Этим мы убиваем двух зайцев: уменьшаем размер сборки, тем самым сокращая время загрузки приложения, и упрощаем доступ к файлам из приложения.

Запускаем приложение и видим, что у нас появились кнопки масштабирования. Их можно покликать – они работают :)

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

Вся серия:

Часть 1. Введение
Часть 2. Масштабирование карты
Часть 3. Полные исходники

Bing Maps на Windows Phone 7. Часть 1. Введение

2011-01-30T12:45:00.001+02:00

Эта статья содержит примеры кода, подсвеченные с помощью JS SyntaxHighlighter, который почему-то не отрабатывает в Google Reader, а возможно и в других RSS ридерах. Чтобы нормально увидеть код, вам придется перейти в блог. Извините за неудобство.

Недавно я делал code session на встрече харьковской UNETA на тему создания картографического приложения для Windows Phone 7. По моим субъективным ощущениям все прошло неплохо, слушатели помогали мне в написании кода, активно задавали вопросы и поправляли меня, когда я где-нибудь лажал :), а также стойко терпели технические проблемы, связанные со взаимной нелюбовью моего ноутбука и местного проектора, за что им отдельное спасибо. Так как тема программирования под Windows Phone сейчас интересна многим людям, хотелось бы также выложить материалы этого code session в блог.

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

Требования

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

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

При этом мы попытаемся реализовать приложение в более-менее правильном стиле, с использованием паттерна MVVM.

Начнем с создания проекта и отображения простой карты.

Создание проекта

Перед тем, как начать программировать для Windows Phone 7, вам нужно убедиться, что у вас есть вся инфраструктура:

Visual Studio 2010 (есть бесплатная версия VS2010 Express for Windows Phone)
Windows Phone Developer Tools (Silverlight for Windows Phone, эмулятор, библиотеки и т.д.)
Bing Maps Silverlight control for Windows Phone
(опционально) XNA Game Studio 4.0
(опционально) Expression Blend (есть бесплатная версия Blend for Windows Phone)

Все это добро бесплатно и его можно скачать с сайта http://create.msdn.com/en-us/home/getting_started. После того, как установите основной пакет, не забудьте также установить October 2010 update to the Windows Phone Developer Tools.

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

Немного о платформе разработки

Как вы уже догадались, писать мы будем на Silverlight. Только не на обычном Silverlight 4, а на т.н. Silverlight for Windows Phone. Эта версия SL отличается от своего настольного брата немного урезанными возможностями и оптимизированной производительностью. В общем-то производительность для телефона – это все, потому что по сравнению с native-приложениями у нас и сам .NET довольно прожорливый, и тем более Silverlight.

Кроме программирования бизнес-приложений (и в более редких случаях игр) на SL, у нас также есть возможность программировать игры (и в более редких случаях бизнес-приложения) на XNA. XNA – это платформа и набор инструментов для разработки игр для Windows, Xbox, Zune и вот теперь еще Windows Phone 7.

Поддержка XNA в Windows Phone – это очень полезная вещь, т.к. разработчики игр под Xbox теперь могут использовать привычные инструменты и модель разработки для программирования игр под мобильную платформу, а также с меньшими трудозатратами перенести существующие игры на WP7.

Отображение карты

Вернемся к практике. После установки необходимых дополнений в Visual Studio появятся новые типы проектов. Поэтому идем в File -> New -> Project и создаем Windows Phone Application проект.

Начнем мы с отображения карты. Здесь все просто. Сначала добавим в проект reference на сборку Microsoft.Phone.Controls.Maps. Затем добавим namespace для Bing Maps контрола, а также сам контрол в XAML главной страницы приложения, попутно заменив основной Grid на Canvas, чтобы нам было проще позиционировать элементы в будущем:

xmlns:maps="clr-namespace:Microsoft.Phone.Controls.Maps;assembly=Microsoft.Phone.Controls.Maps"

<!--LayoutRoot is the root grid where all page content is placed-->
<Canvas x:Name="LayoutRoot">
    <Grid Background="Transparent" Height="768" Width="480">
        <Grid.RowDefinitions>
            <RowDefinition Height="Auto"/>
            <RowDefinition Height="*"/>
        </Grid.RowDefinitions>

        <!--TitlePanel contains the name of the application and page title-->
        <TextBlock x:Name="ApplicationTitle" Grid.Row="0"  Text="My Places" Style="{StaticResource PhoneTextNormalStyle}"/>

	<maps:Map Grid.Row="1" Name="mapPlace" HorizontalAlignment="Stretch" VerticalAlignment="Stretch" 
            ScaleVisibility="Visible"
            ZoomBarVisibility="Visible"
            CopyrightVisibility="Collapsed">

            <maps:Map.Mode>
                <maps:AerialMode ShouldDisplayLabels="True" />
            </maps:Map.Mode>

        </maps:Map>

    </Grid>
</Canvas>

Свойства контрола ScaleVisibility, ZoomBarVisibility и CopyrightVisibility определяют видимость соответствующих стандартных элементов карты. Надо отметить, что стандартный Zoom Bar располагается снизу (что не всегда удобно) + выглядит очень плохо, поэтому немного позже мы его улучшим.

Запустим приложение в эмуляторе. Как видите, приложение показывает карту:

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

Invalid Credentials. Sign up for for a developer account.

Этот текст обозначает, что нам нужно получить Bing Maps Developer Account и сообщить о нем контролу карты. Для этого идем на http://www.bingmapsportal.com/, логинимся туда при помощи Live ID (или сначала регистрируем его), и затем создаем ключ при помощи пункта меню Create or view keys.

Для того, чтобы карта заработала, достаточно установить свойство CredentialsProvider контрола:

CredentialsProvider="AoYOaLG9nor0LXJzvYrL18U8URccNTyacL-qfGUMBdvFseoLbF384hct4JxGVvI9"

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

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

Дополнительную информацию по паттерну MVVM и его примеры для Silverlight можно прочитать на страничке MSDN и в статье в MSDN Magazine.

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

public class MapViewModel
{
    private const string Id = "AoYOaLG9nor0LXJzvYrL18U8URccNTyacL-qfGUMBdvFseoLbF384hct4JxGVvI9";
    private readonly CredentialsProvider credentialsProvider = new ApplicationIdCredentialsProvider(Id);

    public CredentialsProvider CredentialsProvider
    {
        get { return credentialsProvider; }
    }
}

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

Далее привязываем MapsViewModel к представлению в XAML файле страницы. Добавляем namespace:

xmlns:model="clr-namespace:WP7Test.ViewModel"

Говорим нашей View, что ее ViewModel будем класс MapsViewModel, установив свойство PhoneApplicationPage.Resources (перед началом тега Canvas):

<phone:PhoneApplicationPage.Resources>
    <model:MapViewModel x:Key="ViewModel" />
</phone:PhoneApplicationPage.Resources>

Устанавливаем свойство DataContext у Canvas:

<Canvas x:Name="LayoutRoot" DataContext="{StaticResource ViewModel}">

Теперь, когда ViewModel привязан к представлению, можно связать установить свойство CredentialsProvider контрола Map через стандартный data binding:

CredentialsProvider="{Binding ViewModel.CredentialsProvider}"

Вот и все. Запускаем, и видим, что наше приложение больше не показывает белую строчку.

В следующей части мы рассмотрим кастомизацию Zoom Bar.

Вся серия:

Часть 1. Введение
Часть 2. Масштабирование карты
Часть 3. Полные исходники

Создание картографического приложения на Silverlight для Windows Phone 7

2011-01-15T20:13:00.002+02:00

В четверг, 20 января, буду делать доклад на встрече харьковской UNETA на вышеприведенную тему. Хотя это будет даже не доклад, а скорее code session с минимумом теории и максимумом программирования. Постараюсь за 40 минут показать, как создать картографическое приложение на Silverlight для Windows Phone 7. Приложение будет брать данные об объектах из Wikimapia по различным категориям и отображать их на карте (Bing Maps). Покажу как работать с geolocation services, обрабатывать различные состояния приложения, и многое другое. Постараюсь, чтобы все было true MVVM. Ну, или около того :) Отвечу на разные вопросы.

Встреча будет проходить в Харьковском национальном университете радиоэлектроники, пр. Ленина, 14 (ст.м. Научная) 334 ауд., 20 января 2011 г. в 18-30. Официальное оповещение: http://dev.net.ua/blogs/leshchinsky/archive/2011/01/14/UNETA2001201SilverlightWindowsPhone7.aspx

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

Итоги 2010: лучшие фотографии

2011-01-03T17:50:00.001+02:00

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

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

#1 Большая и Малая Сивули

#2 Вид на Малую Сивулю

#3 Лошадки на Перевале Легионов

#4 Набережная Балаклавы

#5 Балаклавская бухта

#7 Форосская церковь

#8 В парке

#9 Черниговский Детинец

#10

#11 Ильинская церковь

Итоги 2010: статистика блога

2011-01-03T17:48:00.002+02:00

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

Итоги 2010 года:

Всего посещений: ~27 тыс. (~39 тыс. просмотров страниц)
Аудитория: ~12 тыс. - Россия, ~10,5 тыс. - Украина, ~2 тыс. - Беларусь, остальное – Штаты, Латвия, Молдова, Израиль, Германия, Казахстан и другие страны.
Самые популярные статьи (по посещениям, все статьи):
NHibernate – где узнать больше?

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

Domain Driven Design: введение

Введение в mock-объекты. Классификация

Методы оптимизации производительности Linq to SQL и Entity Framework.

Самые популярные статьи (по посещениям, статьи 2010 года):
Качественный код и проектирование

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

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

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

Google AI Challenge

Самые комментируемые статьи:
Летаргический сон украинского .NET-сообщества

Domain Driven Design: введение

IT-образование vs. профессиональный рынок

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

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

Планы на 2011 год:

В первой половине ушедшего года я провел опрос, стоит ли разделить блог на два: технический и личный, и получил отзыв, что нетехнические заметки не очень мешают читателям, а кое-кому даже нравятся. Поэтому на текущий момент блог останется в том виде, в котором есть.
На данный момент я планирую серию заметок на тему разработки под Windows Phone 7 на базе приложения, разработанного для конкурса Microsoft SWIT. Если все сложится, то скоро вы их увидите.
Остальное будет зависеть от свободного времени и наличия тем на “поделиться”. Если у вас есть какие-то пожелания, welcome!

Итоги 2010, планы на 2011

2011-01-03T17:38:00.002+02:00

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

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

С Новым годом и Рождеством!

Для меня 2010 год был достаточно сложным и вследствие этого профессионально малопродуктивным. Также в нем было ощутимо меньше путешествий и отдыха. Но в то же время этот год многое мне дал с точки зрения личностного роста, научил преодолевать трудности и радоваться простым вещам. Надеюсь, 2011 год также будет очень плодотворным с этой точки зрения, но хотелось бы получать не так много “направляющих” тумаков от жизни :)

Итак, итоги 2010 года:

Профессиональный рост: Не так много достижений, как хотелось бы. Из нового изученного можно отметить лишь Silverlight (и то еще в процессе) и программирование под Windows Phone 7. Никаких новых языков или технологий, скорее просто накопление опыта в том, что уже есть. Возможно, стал больше понимать в процессе разработки, менеджменте и сопутствующих вопросах. Жажда изучения новых технологий сменилась желанием создавать готовые продукты и решения, использовать свои знания и навыки для решения проблем людей. Интересно анализировать новые проекты, продумывать архитектуру, организовывать работу команды, видеть готовый работающий результат, приятно слышать благодарность клиентов и пользователей, если все получилось. Программировать также все еще интересно, но в основном что-то действительно сложное и необычное, или как минимум, незнакомое.
Community-деятельность: Также затишье. Один доклад на UNETA и один на внутренних tech talks компании, очень редкие заметки и статьи в блоге. Правда, конец года был активный: съездил на SWIT, где познакомился с интересными людьми.
Работа: За последний год наша компания Altexsoft выросла почти в 2 раза, к нам пришли очень сильные ребята, мы перебралась в новый офис, и надеюсь, стали лучше работать. Приятно осознавать, что мы развиваемся, видеть перспективы, работать в отличном коллективе.
Соревнования: Давно не участвовал ни в каких соревнованиях и уже успел забыть этот ни с чем не сравнимый вкус. В конце октября-ноябре поучаствовал в Google AI Challenge, просто ради интереса и разминания мозгов. В результате занял 413 место в общем рейтинге, 45-е место среди C#-стов (к слову, их было очень мало) и вошел в 20-ку по Украине. А главное – получил море удовольствия от for fun programming. Также поучаствовал в конкурсе Windows Phone 7 приложений от лица нашей компании, где прошел в финал. Правда, особого ROI от дальнейшего участия нет, поэтому мы решили не бороться за призовые места.
Личная жизнь: Сильно распространяться о личной жизни я не буду, это мало кому интересно. Главное достижение ушедшего года для нашей семьи – без сомнения, покупка квартиры. Трехмесячная эпопея поиска и покупки квартиры с драматическим финалом счастливо завершена, теперь нас можно назвать харьковчанами :) Работы все еще непочатый край, но это приятная работа: косметическое завершение ремонта, покупка мебели, обустройство квартиры.
Путешествия: В связи с покупкой квартиры в ушедшем году мы смогли позволить себе лишь три поездки: уже ставший традиционным майский поход в Карпаты, летняя поездка в Севастополь и Балаклаву и зимние выходные в Чернигове. Карпатский поход запомнился дождями, грязью и настоящей майской грозой на высоте 1.5 км. Поездка в Севастополь – полузабытым катанием на волнах в шторм, отвесными скалами Затерянного мира–2 и посещением базы подлодок в Балаклаве. Чернигов удивил красивыми куполами храмов и монастырей, парками в центральной части города и уютными кафешками.
Хобби: В 2010 году у меня появилось новое увлечение – я наконец-то исполнил свою детскую мечту и начал заниматься фехтованием. Меня сначала записали на шпагу, но потом судьба распорядилась так, что я попал на саблю, о чем ни капельки не жалею. По моему мнению сабля гораздо динамичнее, в ней больше вариантов действий, сильно развита тактическая составляющая боя. В фехтовании нужно не только иметь хорошую технику и реакцию, как многие думают, но также нужно много думать, быстро принимать решения, какое действие или комбинацию действий совершить в ответ на действия соперника, стараться его обхитрить. А еще, как выяснилось, фехтование дает очень хорошую физическую нагрузку: первый месяц я буквально приползал с тренировки.

Что мне понравилось в 2010 году:

Книги года: Из прочитанных/прослушанных мною на это звание претендуют две книги (если быть точным, то две серии): “Трилогия желания” Т.Драйзера (Финансист, Титан, Стоик) и “Песнь льда и пламени” Дж.Р.Р. Мартина. Первая серия – это известнейшее классическое произведение, описывающее одновременно жизнь уникального человека, и уклад целой эпохи, вторая – очень качественное фентези, которое понравится многим любителям этого жанра.
Фильмы года: Нет, это не “Аватар”. Для меня это без сомнения “Начало” (Inception) Кристофера Нолана. Отличный фантастический фильм с уклоном в философию и психологию. На втором месте – превосходный российский документальный фильм “Счастливые люди” о жизни людей в сибирском поселке Бахта на берегу Енисея и охотничьем промысле.
Подкасты года: В ушедшем году интерес к профессиональным подкастам немного ушел в сторону, возможно потому, что я нашел записи передач радио “Эхо Москвы”, в частности, исторические передачи “Все так” и “Не так”. За год мы с женой прослушали очень много выпусков, просто включая их в фоне дома на выходных. Рекомендую всем любителям истории. Также рекомендую порыться в списке передач и архиве – там ОЧЕНЬ много интересного.
Блоги года: Без разделения на места самые интересные на мой взгляд блоги: Zenegment, блог Дмитрия Нестерука, Gaperton’s blog, Размышлизмы eao197, Не кинокритик, блог Леонида Волкова, блог Дмитрия Шатрова и блог Сергея Доли.

С итогами разобрались, цели/планы на 2011 год:

Профессиональный рост:
Закончить изучение Silverlight. Поучаствовать хотя бы в одном серьезном проекте, чтобы опробовать технологию

Изучить хотя бы один новый язык программирования. Еще не решил: Ruby, Python или F#. Ruby интересен в разрезе программирования на Ruby-on-Rails, Python – как один из промышленных языков, использующихся Google, F# – как представитель функционального мира, со своими законами и мировоззрением. С чего посоветуете начать?

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

Community-деятельность:
Посетить несколько серьезных конференций, как по .NET, так и по другим направлениям

Сделать несколько докладов в Харькове, а если повезет, то и за его пределами

Ведение блога. Надеюсь, получится лучше, чем в прошлом году

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

Работа:
Начать и успешно вести крупный проект в роли лида или руководителя проекта. Хочется получить такой опыт

Путешествия:
Так как у нас с Леночкой не было полноценного отпуска в этом году, а усталость накопилась, очень хочется съездить в начале февраля в Карпаты или, как вариант, весной в Европу (хотелось бы в Италию, а там как получится) как минимум на неделю.

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

Остальное – как получится. Никаких других планов пока нет.

В ближайших постах будут итоги и статистика по блогу за 2010 год, а также лучшие фотографии 2010 года.

Отчет о Microsoft SWIT 2010

2010-12-07T12:44:00.001+02:00

Наверно, уже все знают, что в конце прошлой недели (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

2010-11-24T17:17:00.002+02:00

В последний время все чаще попадается на глаза критика 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

2010-10-31T22:49:00.001+02:00

Недавно из блога Плахова узнал про конкурс 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. До встречи в бою :)

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

2010-07-25T15:43:00.002+03:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2010-03-31T11:24:00.002+03:00

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

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

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

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

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

2010-03-22T23:39:00.003+02:00

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

.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-летний малыш. Мало того, что он помогал отцу в написании книги и примеров для нее на Питоне, но он еще и рассуждает обо всем по-взрослому. Интересно, он просто настолько умен или изучение программирования действительно ускоряет развитие у детей?

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

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

2010-03-11T22:46:00.001+02:00

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

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

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

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

Design Principles

View more presentations from AlexMerle.

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

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

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

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

2010-03-02T18:12:00.002+02:00

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

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

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

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

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

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

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

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

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

2010-02-03T23:56:00.001+02:00

Пару дней назад наткнулся на статью Фаулера "Кому нужен архитектор?" ("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. Поделитесь чем-нибудь интересным на эту тему.

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

2010-01-17T00:17:00.001+02:00

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

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

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

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

расширяемость, гибкость (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 года

2010-01-03T17:40:00.002+02:00

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

#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: Южная Чехия

2010-01-03T15:31:00.001+02:00

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

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

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

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

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

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

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

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

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

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

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

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

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

Телч

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

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

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

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

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

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

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

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

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

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

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

2010-01-02T20:26:00.001+02:00

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

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

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

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

Карловы Вары

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

Набережная

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

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

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

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

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

Центр города

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

Сказка

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

Дрезден

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

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

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

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

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

Фрауэнкирхе

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

Мы и Цвингер

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

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