2/9/2014 6:25:08 AM

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

Я плотно работал с TFS фактически с момента его появления (с 2005-й версии и до версии 2010-й) не только как разработчик, мне приходилось и устанавливать, и администрировать, и заниматься правкой шаблонов проектов, и настраивать CI.
Я осуществлял две такие миграции “с TFS на что-то ещё” и здесь я попытаюсь рассказать почему, как и что.

Давайте сначала посмотрим, что представляет из себя TFS.
TFS – это набор инструментов, включающий в себя систему контроля версий, систему управления задачами, билд-систему и систему тестовых окружений (TestLabs). Эти системы интегрированы в единую экосистему, всё это интегрируется c Visual Studio и работает практически “из коробки”.

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

Source Control

Система контроля версий в TFS централизована. Это означает, что у вас в компании (или “в облаке” в случае 2012-й версии) есть некий “центральный сервер”, с которым работают разработчики. С точки зрения системы контроля версий работа сводится к операциям CheckOut (взять файл для правки) CheckIn (“загрузить” исправленный файл) и операциям по работе с бранчами.

TFS в своей работе опирается на Read Only атрибут файлов в локальной файловой системе на машинах разработчиков: при CheckOut этот атрибут с файла снимается, а при CheckIn ставится обратно. Казалось бы – мелочи, но это означает, что для того, чтобы начать править файл, нужно связаться с сервером и сообщить ему об этом. При этом сервер сам ведёт реестр файлов и их статусов для каждого компьютера каждого разработчика. Конечно, можно вручную снять атрибут и поправить файл если сервер, например, недоступен, но это означает, что позже придётся “объясняться” с TFS на предмет того, что же тут происходит.
Существует ещё возможность временно “уйти в оффлайн”, продолжать работать, а потом снова “выйти в онлайн”, и TFS сумеет обнаружить изменения и позволит сделать CheckIn, но это означает, что на период работы “оффлайн” разработчик начисто лишается системы контроля версий, работая лишь с кучкой файлов на диске. Ни откатить что-то на момент “как было”, ни посмотреть историю изменений, да и вообще никаких плюсов системы контроля версий в этом режиме не предусмотрено. Её нет на этот период – системы контроля версий.
При переходе обратно в режим “онлайн” локальные файлы будут проанализированы системой и TFS предложит “объясниться” с ней на предмет того, что и как изменилось. “Объяснения” эти бывают не из лёгких, особенно в случае обнаружения конфликтов.

Бранчи в TFS тоже создаются на центральном сервере. Локально каждый бранч представляет собой отдельную папку на диске с копией файлов репозитория. Если разработчик хочет сделать ветку, ему нужно создать бранч на сервере и скачать его себе на локальный диск. Разработчик, таким образом, не может быстренько “на минуточку” создать для себя ветку что-то попробовать, поэкспериментировать и т.д. Всё, что связано с бранчами – это серьёзная церемония, в связи с наличием которой разработчики, использующие TFS бранчами практически не пользуются. Это просто неудобно, а слияние бранчей настолько плохо, что ещё и требует недюжей аккуратности и запаса нервов. В связи с этим, разговаривая с командой, использующей TFS на предмет бранчей, часто можно столкнуться с парадоксом Блаба по отношению к бранчам (или ещё можно сказать “парадоксом фаната Apple”: “а мы это не пользуем”, “а нам это и не надо” и т.д.). На самом деле это происходит не потому, что “не надо”, а потому, что инструменты настолько плохи, а возможности настолько неудобны, что использование их делается нецелесообразным.

Давайте сравним это, например, с популярной системой контроля версий Git.  О Git напимано много и я не буду описывать принципы его работы, скажу лишь о разнице по отношению к TFS.

В случае с Git отсутствует т.н. “центральный репозиторий”. Каждый разработчик на своём локальном компьютере имеет собственную копию репозитория. Поэтому разработчик никогда не остаётся без системы контроля версий, даже если он полностью изолирован от всего остального мира, он может продолжать работать, иметь доступ к истории, делать вносить изменения и добавлять ревизии в систему контроля версий.
Не нужно понимать это неправильно: скорее всего в компании будет некий сервер с неким репозиторием, который будет назван “центральным” и который будет считаться “источником правды” (source of truth). Но это назначение – логическое, а не физическое. В топологии Git это всего лишь ещё один репозиторий, который люди “договорились” считать главным. Физически разработчик может равно получить код как с “главного” репозитория, так и с репозитория своего коллеги или откуда-нибудь ещё.
Убивающе сильной стороной Git является работа с бранчами. Поскольку каждый разработчик имеет свою собственную копию репозитория, он может создавать бранчи локально. Причём создание бранча не требует создания новой копии в отдельной папке и т.д, это совершенно не занимает времени (милисекунды) и не требует никаких усилий. Становится более удобной парадигма работы: “а ну-ка я попробую так” – переключился в бранч – поработал – не понравилось – переключился обратно – понравилось – слил с “основным” своим брачем и т.д.
Для тех, кто читает об этом впервые, парадокс Блаба будет мешать понять удобство этого инструмента, но этому просто нужно отдавать отчёт :)

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

Я знаю, что из командной строки TFS можно заставить слить два бранча, не связанных непосредстенным наследованием, но скорее всего слияние в этом случае будет ещё более болезненным, чем это можно себе представить. К тому же TFS будет скатываться в режим baseless merge, а тут уж, как говорится, $YOUR_GOD в помощь.

В то время как локальные бранчи – это дело каждого отдельного разработчика, статегия релизов, фич, хотфиксов и т.д. – это стратегия компании. В случае с Git быстро установить простой, удобный и понятный цикл разработки и систему очень просто. Плюс для этого существуют удобные инструменты. Для примера рекомендую оригинальную статью “A successful Git branching model” либо её перевод на русский язык и неплохое дополнение к переводу.

Резюмируя: система контроля версий TFS построена на основе “устаревшей” модели, она неудобна во многих аспектах работы и накладывает ряд странных ограничений. В то же время другие системы контроля версий (например Git) подобных недостатков лишены, плюс добавляют множетво полезных возможностей. Так почему же не выбрать Git?
Microsoft тоже понимает это, поэтому добавляет поддержку Git в TFS как может, но на мой прямой вопрос “если я всё равно использую Git, зачем мне подключать его к TFS и использовать через TFS, в чём смысл?”, заданный несколько раз на разных конфренциях и событиях, прямого ответа дано ни разу не было. Ну на самом деле, не могут же они прямо ответить: “Люди хотят использовать Git, а нам нужно продавать TFS, поэтому мы как-то вкорячим Git в TFS и будем продолжать его продавать” :)

Builds

TFS имеет встроенную систему билдов, позволяющую организовать Continuous Integration (CI, “постоянную интеграцию?”). В данном случае мы имеем TFS Server как центральный сервер билд-конфигураций и можем организовать некоторое количество отдельных (виртуальных) машин, называемых билд-агентами (build agents), которым TFS Server будет давать задачи и которые будут непосредственно заниматься тяжёлой работой – компиляцией, сборкой и т.д.
Билд можно сконфигурировать таким образом, чтобы он запускался вручную, или по расписанию, или в случае изменений в системе контроля версий.

Всё это очень удобно, кроме конфигурации и поддержки всего этого дела. Раньше, в первых версиях TFS, конфигурировать билд нужно было посредством написани MSBuild-скрипта. Для тех, кто не сталкивался – задача не из приятных. И, казалось бы, можно ли сделать процесс ещё более неудобным, чем ручное написание XML-файло с довольно размытой спецификацией? Оказалось – можно, и в следующих версиях Microsoft перевёл конфигурации билдов на Windows Workflow Foundation (который, кстати, был фактически убит чуть позже самой MS) и “прикрутил” к билдам соответствующий визуальный редактор WWF. Всё стало громоздко, невнятно и ещё менее удобно.

Но хорошо, редактор – это на любителя. Однако, опять же, про бранчи: создав бранч в TFS придётся настроить отдельный билд для этого бранча. Пусть сделать это уже не так сложно: конфигурацию билда можно хранить внутри бранча и она, как любой код, так же будет частью бранча.
Но всё же это нужно сделать – раз, и всё же нужно для каждого бранча идти в администрирование билдов и создавать отдельный билд, указывая бранч и конфигурацию. Это если у тебя есть права, а если нет – то кто-то у кого есть должен это сделать. А потом ещё и удалить, когда удаляется уже ненужный бранч.
А бранчи будут. Даже если вы берёте пример с фанатов Apple и заявляете “нам бранчи не надо”. Пусть не фичи, пусть не дивелоперские, но будут бранчи релизов, будут бранчи хотфиксов, как без этого.

Давайте посмотрим на альтернативы, скажем, на JetBrains TeamCity. Если вы “дотнетчик”, то вы пользуетесь ReSharper, то вы знаете, что JetBrains делает хорошие инструменты для разработчиков. TeamCity один из них.
Установка сервера прозрачна и безболезненна. Установка билд-агентов автоматизирована: нужно просто пойти и нажать на ссылку. TeamCity автоматически определяет параметры каждого агента (версии ОС, установленных фреймворков и т.д.) и способен автоматически выбирать подходящие агенты: билд проектов, использующих .net framework 4.5 не будет запущен там, где установлен только 3.5. Плюс, конечно, явно указать какая конфигурация может быть запущена на каких агентах.
Настройка конфигурации билда делается очень удобно и визуально: указываем файл solution, версию visual studio (или msbuild, по вкусу), запускать ли юнит-тесты, какие артифакты (результаты) билда нужно сохранить и т.д. Всё очень удобно. Артифакты потом всегда можно скачать или посмотреть прямо из веб-интерфейса, для любой версии.
Имеются дополнительные приятные “фишки”:
- Встроенный патчер assembly.info файлов, позволяющий автоматически задать версию билда.
- Встроенный nuget-сервер – идея выше всяких похвал. Вы теперь можете “развязать” зависимости от “общих” проектов и библиотек: TeamCity будет собирать библиотеку и публиковать её как nuget-пакет. Остальные проекты и solution’ы будут просто получать nuget-версию, это безумно удобно.
- Возможность автоматически ставить метку в систему контроля версий в процессе билда (удобно для релизов и хотфиксов)
- Возможность “перезапустить” любой билд любой версии – автоматически возьмёт ту же самую ревизию из системы контроля версий и будет работать с ней.

Бранчи, конечно бранчи! В случае использования Git, например, одна билд-конфигурация будет работать со всеми бранчами данного репозитория! Это значит, что создавая/удаляя бранч не нужно трогать/конфигурировать билд-систему, все бранчи автоматически получают CI! 
Естественно, в интерфесе видно какой именно бранч собирается/собрался/упал.

Плюс многое, многое другое. Например, зависимости билдов друг от друга разного рода. Самое простое -  “когда успешно соберётся А начать собирать Б”. Самое распространённое: “когда я запускаю Deploy-билд, взять артифакты (результаты) из последнего успешного билда А и работать с ними (деплоить куда-то)”. Или не “из последнего”, а “из версии, которую я укажу”. И много чего ещё.

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

Резюмируя: разница в удобстве и возможностях билд-системы TFS и TeamCity огромна. TeamCity даёт гораздо больше возможностей, с которыми работать гораздо более удобно. Я лично не вижу смысла использовать билд систему TFS даже в том случае, если есть желание использовать TFS для всего остального. Естественно, TeamCity поддерживает систему контоля версий TFS (как и десяток других), но тут выше головы не прынгешь, как с теми же бранчами.

Управление задачами

Сразу скажу, что отличной системы управления задачами я пока ещё не встречал. Тут же скажу, что система управления задачами в TFS на мой взгляд ужасна. Здесь всё: и пользовательский интерфейс, и настройка процесса, и миграция на более новые версии процесса, и репортинг, и трекинг… С этой стороны у TFS ужасно всё. А ведь это как раз та часть, которая должна быть максимально удобной для команды разработчиков.
Я даже не буду тратить время на описание всего этого дела ибо любой, кто сталкивался с этой стороной TFS, от разработчика до Самого Большого Начальника скажет, что работать с эти неудобно, а кто пытался это дело автоматизировать/кастомизировать, добавит ещё и ремарку о том, что всё это очень не гибко.

В качестве аналога здесь можно посмотреть на Jira с плагином Greenhopper. Здесь и гораздо большая гибкость, и более приятный пользовательский интерфейс, и более удобная отчётность (как в использовании, так и в настройке).

Технические детали Jira я тоже описывать не буду, лучше опишу о том, как именно мы использовали этот продукт в процессе разработки так сказать “на пике эффективности”.

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

Положения были следующие:
- в Jira находится backlog, т.е. список фич (stories), которые нужно сделать в продукте.
- в начале итерации (каждые 2 недели) команда организовывала митинг, в процессе которого решала, какие именно stories (из Jira) она будет делать в течение итерации. Stories обсуждались, принималось решение о том, как именно (технически) будет делаться каждая story, т.е. для каждой story создавались tasks. Время митинга – 20-30 минут максимум. Часто – гораздо меньше.
- для каждой story заводилась одна жёлтая карточка (сама story) и несколько белых (tasks). Это быстро, прямо в процессе обсуждения, сидит человек с фломастером и пишет на карточках.
- каждая белая карточка (task) оценивалась в человеко-часах. Обычно, если число превышало 2 рабочих дня, task пересматривался: слишком большой, возможно его можно разбить на пару поменьше.
- Tasks не заводились в Jira. Это – детали имплементаци, никому кроме команды не интересные и, когда работа уже сделана, не имеющие никакого смылса. Так зачем же тратить время и засорять Jira?
- Stories, которые команда решила делать в итерац��и, помечались меткой с номером итерации (опционально).
- в конце итерации Stories, которые были успешно выполнены, помечались как “готовые” в Jira.

Что происходило в процессе итерации:
- Stories, выбранные командой, располагались на доске в порядке приоритета выполнения (stories вертикально, tasks – горизонтально для каждой story).
- Все члены команды одновременно работали над задачами в порядке приоритета. То есть, не Вася работает над S1, Петя над S2, в Коля над S3, как часто бывает, а все вместе работают над S1, потом над S2, потом над S3. Просто брали одну белую карточку за другой из S1, пока она не сделана, потом переходили к S2 и т.д. Это сильно повысило эффективность, как командной работы, так и в плане того факта, что если мы что-то не успеваем, то мы не успеваем сделать S5, а не имеем S1..5 все сделаны на 90%, но ничего не готово. Плюс это сильно повысило эффективность тестирования, ибо пока когда разработчики сделали S1 и переходят к S2 тестеры уже могут начать тестировать S1, найти там баги и повесить их на доску (ниже).
- Баг, найденный в процессе итерации в разрабатываемой фиче, не считается багом. Это не баг, это – незавершённая работа. Тестер решает, что делать: переложить карточку обратно или завести новую. В большинстве случаев просто заводится новая task-карточка и вешается на доску. Разработчики потом, когда берут следующую задачу, видят: о, в S1 появилось что-то недоделанное, это имеет приоритет над S2, следовательно берём и доделываем. Таким образом, баги, найденные в процессе итерации в разрабатываемой фиче не заводятся в Jira. Ибо с истрической точки зрения не важно, что ты там случайно пропустил, но потом тут же нашёл и исправил, пока ты не сдал в продукт готовую функциональность.
- Баги, находящиеся вне контекста итерации (найденные где-то в чём-то, что уже сдано в продукт), являются обычными stories, так же, как и фичи.
- Тестеры – это часть команды. Поэтому задачи тестеров – это такие же задачи внутри итерации, связанные с разрабатываемыми stories. Это такие же карточки на доске, так же проэстимированные. Например “написать автоматический тест для фичи А” и т.д. Причём начать писать тесты, тест-кейсы и т.д. можно ещё до того, как story будет полностью готова, ибо вся команда знает после планирования, как это должно работать и что должно быть сделано. Тестеры так же полноценно работают в процессе итерации, а не находятся в положении, когда им в конце сбросили “нате, тестируйте теперь над чем мы 2 недели возились!”.

Таким образом мы имеем “чистенькую” картинку в Jira, где у нас в порядке приоритета расписаны фичи продукта, а команды эти фичи реализуют в процессе итераций. Идея в том, что если после итерации S1 сдана, то она сдана полностью: разработана и протестирована. Done-Done, что называется.

Резюмируя: вся эта ужасная сложность с воркайтемами в TFS совершенно не нужна и только замедляет процесс работы. Интерфейс TFS не располагает ни к быстрой удобной работе, ни к быстрому созданию воркайтемов, ни к видению полноты картинки. Jira гораздо более удобна в этой связи, но и тут не нужно перебарщивать. Не нужно пихать в Jira (и в TFS) вообще всё, достаточно иметь там приоритизированный список фич продукта и иметь его в достаточно детальном виде, где каждая фича “атомарна”, автономно тестируема и имеет смысл с точки зрения бизнес-видения. Не нужно пихать в Jira/TFS задачи типа “изменить схему БД”, “написать адаптер для API” или “создать юнит-тест для Х”. Это не имеет никакого смысла, лучше использовать доску.
Если у вас нет физической доски, и вы хотите использовать “электронную”, опять же, Jira+Greenhopper делает это гораздо удобнее TFS.
Про “физическую доску”. В конце каждой итерации мы проводим небольшой митинг (10-15 минут максимум) на предмет “что мы сделали хорошо, что плохо и что в следующий раз будем/не будем делать”. С тех пор, как мы перешли на физические доски, практически каждый раз каждый член каждой команды (команды было три) в категории “что хорошо” отмечал, что физическая доска с карточками – это очень хорошо. Нравилось всем. Так что я сильно рекомендую.

Wiki/Документация

TFS предлагает Sharepoint. Здесь, я думаю, можно и закончить сравнение, ибо это одно из худших решений для ведения документации/wiki, которое можно предположить.

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

Если вам нужна wiki для проекта, или вы хотите делать публичную документацию, или что-то в этом роде, то не нужно ставить для этого TFS, чтобы получить SharePoint. Лучше возьмите Confluence.

Интеграция

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

Система контроля версий. TFS интегрирован в Visual Studio, можно делать checkin/checkout и другие операции прямо из студии. Однако Microsoft, решив поддерживать Git, точно так же сделал точно такую же интеграцию Git в Visual Studio. Визуально – всё то же самое. Для тех, кому нравится как VS работает с контролем версий TFS – всё будет точно так же. Однако, в случае с Git, есть и другие варианты: начиная от командной строки до сторонних плагинов к Visual Studio. Лично я довольно много пользуюсь командной строкой, а в качестве интеграции со студией предпочитаю сторонний плагин, так как он даёт мне больше опций. Ваш выбор.

Билд. TFS билды, поддерживают только TFS (может что-то изменилось в последнее время?). TeamCity из коробки поддерживает десяток разных систем, включая и TFS, и Git. Причём поддерживает лучше и удобнее (бранчи, история, интерфейс, настройка, я писал выше). TeamCity интегрируется в VisualStudio (хотя я не понимаю, зачем это надо).
TeamCity к тому же имеет отличные возможности интеграции чего угодно (действительно чего угодно: всё, что мы можем захотеть сделать в процессе билда может очень просто отрапортовать назад в TeamCity, где мы можем сделать фактически что угодно с результатом).
TeamCity при этом уже интегрирована с инструментами типа анализ покрытия тестами, fxcop и т.д.

Управление задачами. А здесь как раз то место, когда интеграция “из коробки” в TFS проигрывает интеграции сторонних компонентов. Например, для того, чтобы ассоциировать изменение с задачей в TFS нужно найти задачу в списке и пометить галочкой. В случае интеграции “сторонних компонентов” достаточно просто указать номер задачи в комментарии к изменению – и всё будет ассоциировано автоматически.

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

Заключение

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

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

6/2/2012 8:50:11 AM

Две недели на машине по Великобритании удались как нельзя лучше.


View Larger Map

К сожалению, я забыл включить логгинг на GPS в начале пути и сделал это уже в Южном Уэльсе. Поэтому розовая линия маршрута начинается оттуда и идёт “по часовой стрелке”. А ведь до этого тоже что-то было, например тот же Bath… :)

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

  1. Машину брали на прокат в Avis (на 13 дней). В принципе, можно брать и в Hertz, и в Sixt, но у Avis как раз подвернулись весенние скидки, что определило выбор. В принципе, какие-то скидки у кого-то есть всегда, нужно только найти ;)
  2. Проблем с WiFi не было никаких. Он есть бесплатный практически везде в пабах-барах-кафешках-ресторанах. Есть несколько бесплатных сетей, работающих по территории Великобритании. Там только нужно бесплатно зарегистрироваться.
    Например, “Moto” часто можно встретить на заправках, где есть еда-кофе вроде Burger King, Costa и т.д.
    ”The Cloud” можно встретить где-нибудь в городах в публичных местах.
    Ни один B&B или отель не предлагал интернет за деньги, всегда был бесплатный (хоть и не всегда хорошего качества).
  3. Там, где нет WiFi очень пригодилась WiFi-точка с 3G-симкой. Мы взяли две симки оператора O2, так как нам сказали, что у них самое лучшее покрытие. Лена пользовалась своим iPhone, а я свою симку поставил в WiFi-точку, чтобы иметь доступ к интернет и с таблета и с телефона (который в виду отсутствия симки превратился просто в карманный компьютер).
    3G в Британии есть не везде. Частенько имелся только Edge (E на индикаторе) или даже GPRS (или что-то такое же медленное, кружочек на индикаторе). Была даже более странная ситуация – в каком-то городке телефон не видел сети вообще никакой. Причём выезжаешь “в поле”, где только бараны и фермеры – и вот вам нормальный 3G. Въезжаешь обратно – опять ничего.
    Быть может у них там какой-то конфликт с O2, а симок других операторов у нас не было :) Возможно нужно было взять одну от Vodafone, но нам, честно говоря, хватало.
    Note: при покупке симки для 3G в Британии вам везде будут говорить, что с WiFi-точкой она работать не будет, а будет только с телефоном. А такую, чтобы работала, можно купить только с “родной” WiFi-точкой, которая стоит £20. Но это неправда. Всё отлично работает :)
  4. Отелей никаких нигде заранее не бронировали. План был такой: по ходу решаем, куда едем дальше. И он отлично себя оправдал!
    К вечеру приезжали на место и уже там определялись где переночевать. Преимущество отдавали Bed & Breakfast, в отдельных случаях брали отели. Bed & Breakfast это обычно частные дома, в которых хозяева сдают комнату и с утра готовят завтрак. Знаете, это когда дети выросли и разъехались, а комнаты остались :)
    По качеству это гораздо лучше и “душевнее” среднего отеля, а по цене обычно дешевле. В среднем B&B обходились нам в районе £60-£70 за ночь. Получается, что приличный B&B в Британии дешевле плохонького отельчика без завтрака в Австралии :)
    Процедура поиска комнаты простая: приезжаешь на место, открываешь Booking.Com, Kayak и TripAdvisor (есть приложения для Android, iPhone, можно и браузер использовать) и смотришь, что есть вокруг. Выбор обычно хороший. Ну и просто проехать по улицам – таблички B&B встречаются очень часто, очень распространено это там. Впрочем, почему нет, если подумать? Почти пассивный доход.
    Note: Иногда бывает, что цены, указанные на booking.com и т.д. не совпадают с теми, которые говорят на месте. Иногда они предлагают цену даже дешевле (видимо потому, что уже день/вечер и лучше сдать, чем не сдать), а иногда – дороже. В последнем случае нужно только ткнуть пальцем в booking.com и цена сразу встаёт на место :)
  5. Бесплатный паркинг в мелких городах – не проблема. Но в крупных и людных (Эдинбург, Йорк, Кэмбридж, Оксфорд) это проблема большая. В таких городах предлагается использовать Park & Ride – бесплатные парковки на окраине города + супер дешёвые автобусы до центра. Доезжаешь, бросаешь машину и едешь гулять. Но это не всегда удобно, так как автобусы перестают ходить часам уже к 7 (а по выходным и раньше),  а парковки не всегда предполагают стоянку ночью.
    Это и есть те “отдельные случаи”, когда мы брали отели. Мы искали недорогой отель в центре города со своей бесплатной парковкой. Обычно находили пару-тройку с пометкой “осталась всего одна комната!”. Пометка, кстати, честная – я проверял :)
    Так в Эдинбурге мы останавливались в самом центре города, в Йорке – “внутри стен” в 5 минутах пешком от исторического центра. Машина там не нужна, в городе, поэтому она просто стоит на парковке, зато всегда есть доступ к своим вещам и уезжать проще.
    Note: Если нашёлся подходящий отель с паркингом, лучше позвонить туда и спросить, действительно ли он есть и есть ли на паркинге места. Обычно паркинг не закрепляется за конкретным номером, поэтому кто успел – тот успел. Ну и заодно попросить попридержать оставшийся номер так как “я вот уже тут, в городе, и уже через 15 минут буду у вас”.
  6. Погода в Британии сами знаете, не ахти: тучи и дожди. Поэтому погоду лучше брать свою! Мы взяли чуток из Сиднея и возили с собой. Поэтому все две с лишним недели над нами на чистом небе светило яркое солнце, температура была 24-26 градусов по всему маршруту. А среди местных, как говорится, “На небе только и разговоров, что о море” :) Везде в пабах, на улицах, на рыбалке (да, мы и с рыбаками пообщались) народ обсуждал, насколько замечательные погоды нынче стоят и как это необычно.
    И вокруг много-много-много красных людей. Потом им будет плохо. Но это ведь потом ;)
    А ведь это всего-навсего мы приехали покататься :) Вот мы уехали – и теперь там опять холодно и дожди.

Вот так. Следите за анонсами Winking smile

4/3/2012 11:09:21 AM

Disclaimer: Внутренних паспортов в Австралии нет. И если не собираешься ехать куда-то за границу, то он и не нужен. Паспорт нужен только для заграничных поездок. Поэтому, чтобы тем, кто читает мою писанину из России было понятнее, я использую термин “загранпаспорт”. Иначе люди путаются. Но здесь это называется просто Passport, и в разговоре с “местными” я тоже говорю “паспорт”. Поэтому тем, кто читает мою писанину из Австралии я пишу этот disclaimer :) 
Вообще-то и в России ведь тоже на загранпаспорте написано “Паспорт”, а не “Заграничный Паспорт”.

Процедура получения загранпаспорта здесь отличается от российской. В России ведь как было: надо пойти в ОВИР, взять форму, заполнить, взять справку с работы, снова придти в ОВИР, подать документы, через месяц снова придти в ОВИР и забрать паспорт.

В последний раз когда я получал загранпаспорт в России форму можно было скачать, но заполнить правильно было невозможно (во всяком случае в условиях костромской реальности): будут придираться и посылать до тех пор, пока ты не пойдёшь в указанный “офис” (на самом деле подвал) на другом конце города, и не заплатишь 150 рублей за то, что странный дядька двумя пальцами заполнит эту форму за тебя. Вот тогда все ошибки моментально перестают быть существенными, их оказывается можно исправить прямо в кабинете в программе, которая сканирует бланк, или же прямо на бумаг�� ручкой. А без дядьки – никак нельзя, что ты.

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

В Австралии тоже нужно заполнять форму, но делается это прямо на правительственном сайте. В форме не нужно перечислять места работы/службы/отсидки за последние 10 лет, фактически она содержит только базовую информацию: имя, место рождения, адрес, номер прав… После заполнения можно просто скачать PDF с уже заполненой формой с сайта и поставить в нём свою подпись.
Кроме этого нужно ещё найти человека, который может подтвердить, что ты – это ты. Требования к такому человеку не такие драконовские, как при подаче заявления на получение гражданства, это может быть любой гражданин, у которого, например, уже есть загранпаспорт, действительный как минимум ещё два года.

В форме заявления этот человек должен указать, что он знает “подателя сего” лично уже более года. Так же он должен подписать с обратной стороны фотографии текстом: “Это на самом деле фотография Василия Пупкина” и поставить роспись.

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

На почте нужно играть в игру “убеди китайца, что всё в порядке”. Задачки бывают разных уровней сложности, от “эти две страницы напечатаны разными чернилами – непорядок” (правильный ответ “и чо?”) и до “оригинальное свидетельство о рождении маленькое, зелёное и книжечкой, а перевод – А4, нужно переделать, чтобы было одинаково!” (правильный ответ – попытаться доказать, что свидетельство о рождении вообще не нужно и его нет в списках требований, а если вдруг хочется, то бытие не определяет сознание главное – это содержание, а не форма).
Мне попался квест “слишком большие поля, надо чтобы было меньше, мы, конечно, можем принять, но…”. На этом квесте я проиграл и форму перепечатал.

Фишка, опять же, в том, что на почту ходить легче, чем в ОВИР (и гораздо быстрее, ибо не надо с утра номерки писать на ладошках). А для получения паспорта ходить вообще никуда не надо (я надеюсь) :)

Стоимость австралийского паспорта выше в 7 раз, чем стоимость российского и выдаётся он на срок 10 лет, если я правильно помню. А за “символическую” доплату в $170 можно получить паспорт в течение двух дней вместо двенадцати.

В общем, подготовка к поездке в Великобританию, которая будет первой нашей поездкой в качестве граждан Австралии, идёт.

3/5/2012 11:08:14 AM

В процессе рассмотрения ASP.NET Web Api в связке с Telerik Kendo UI (кстати, весьма рекомендую) из состава полученой мною недавно (бесплатно!) лицензией на Telerik Premium Collection и возникла эта тема.

Из API-метода хотелось бы вернуть некую структуру неизвестного заранее формата.
То есть, например, Kendo Grid ожидает на вход json вида:

[{firstName: Alexey, lastName: Raga, luckyNumber: 28},
{firstName: Mithun, lastName: Chackraborty, luckyNumber: 12}

]

Для одного грида может быть такая вот структура, для другого – другая, настраивает всё это сам пользователь (что где и как показать).
Ну и вообще иногда приходится вернуть что-то, структура чего неизвестна на этапе разработки.

”Собирать” форматированное значение вручную тоже, в общем-то, не хочется.
Кроме того, в Web Api реализован автоматический Content Negotiation, что означает, что данные будут возвращаться в том формате, в котором их хочет получить клиент: Xml, Json, OData, может что-то ещё… В этом свете форматировать строки руками вообще выглядит крайне глупо.

В результате раздумий и экспериментов получился такой вот простой вариант решения проблемы: создать “динамический” класс-контейнер, который будет уметь сериализовываться во что там клиент с сервером договорятся:

[Serializable]
public sealed class RowContainer : DynamicObject, ISerializable
{
    private readonly IDictionary<string, object> _values 
        = new Dictionary<string, object>();

    public object this[string memberName]
    {
        set { _values[memberName] = value; }
    }

    public override bool TrySetMember(SetMemberBinder binder, object value)
    {
       _values[binder.Name] = value;
        return true;
    }

    void ISerializable.GetObjectData(SerializationInfo info, StreamingContext context)
    {
        foreach (var value in _values)
            info.AddValue(value.Key, value.Value);
    }
}

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

Наследование от DynamicObject позволяет использовать полученый тип как динамический:

var list = new List<RowContainer>();

dynamic row = new RowContainer();
row.Name = "Alexey";
row.LastName = "Raga";
row.LuckyNumber = 28;
list.Add(row);

row = new RowContainer();
row.Name = "Mithun";
row.LastName = "Chakraborty";
row.LuckyNumber = 12;
list.Add(row);

А реализация индексатора позволяет, в случае необходимости, добавлять значения полей как в коллекцию:

row = new RowContainer();
row["FirstName"] = "Bruce";
row["LastName"] = "Willis";
row["LuckyNumber"] = 666;
list.Add(row);

Теперь можно просто вернуть это дело из метода Web Api и пусть Content Negotiator там сам разбирается как и в каком формате его передать клиенту:

// GET /api/<controller>/id
public IList<RowContainer> Get(int id)
{
    var list = new List<RowContainer>();

    //fill in the list somehow

    return list;
}

P.S. Понятное дело, что можно и тип поприличнее назвать, и TrySetValue реализовать, и, может быть TryGetIndex/TrySetIndex (хотя обычный индексер отлично справляется), но это всё мелочи :)

2/29/2012 1:18:55 PM

Сегодня двадцать девятого февраля две тысячи двенадцатого года мы стали гражданами Австралии.

Так и просится на язык фраза “мы столько для этого сделали”, но, если подумать, то дело-то было одно: сидеть и ждать.

Возможность получить гражданство Австралии появляется после четырёх лет обладания статусом “постоянного резидента” (permanent resident) Австралии. Три из этих четырёх лет мы прожили здесь, в Сиднее.
Один, самый первый год мы заканчивали дела/контракты в Бельгии и переезжали. Но на вопросы “как, уже? вы же всего три года тут!” я отвечаю “а чего тянуть-то?” :)

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

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

Ещё один интересный момент: в очереди за талончиком на тест передо мною стояла арабская женщина с коляской. Когда подошла её очередь и она протянула свой загранпаспорт клерку, тот очень удивился. “Зачем Вы сюда пришли? – спросил он. – Вы же только что приехали, приходите в две тысячи пятнадцатом!”. Удивительно, кто-то хотел гражданство совсем уж сразу :)

Тест компьютерный, вида “вопрос – несколько вариантов ответа”. На тест даётся что-то около сорока пяти минут, реально требуется что-то около семи. Я закончил за пять с небольшим.
Очень удивило то, что лаборантка сказала, что некоторые этот тест не сдают. Как это можно не сдать – непонятно.

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

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

Видеоролик

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

Мэр зачитывает телеграмму министра

После этого нужно произнести “присягу” (обязательства):

From this time forward, under God,
I pledge my loyalty to Australia and its people,
whose democratic beliefs I share,
whose rights and liberties I respect, and
whose laws I will uphold and obey.

С настоящего момента и далее, перед лицом Бога
Я обязуюсь быть лояльным к Австралии и её народу
Чьи демократические убеждения я разделяю
Чьи права и свободы я уважаю
И чьи законы я буду поддерживать и уважать.
(перевод мой, вольный)

Интересно, что можно выбрать вариант без слов “under God” (перед лицом Бога). Мэр просит сначала принести присягу тех, кто с Богом, а потом, отдельно, “безбожников”. Как-то на работе я спросил коллегу-британца, который недавно проходил эту церемонию, какой вариант выбирал он. Тот ответил: “Поскольку Бога не существует, он не обидится на меня за то, что я его не упомянул”.
Мы специально никакой вариант не выбирали (просто не указывали, какой мы хотим), поэтому нам, видимо по-умолчанию, достался “божественный” вариант. Я вспомнил про Мэтта и подумал, что даже если Бог существует, он не обидится на меня за то, что я его упомяну. И сказал “under God”.

Присяга

После произнесения слов “присяги” резидент официально становится гражданином.
Далее следует торжественная выдача сертификатов.

Вручение сертификатов

Незадолго до церемонии мэр повредил ногу, поэтому при вручении сертификатов он сидел. Весёлый мужик. Сел на кресло в своей красной мантии и говорит фотографу: “ну, а ты чего хочешь на рождество?” :) И вообще шутил постоянно.

Вот так. Теперь мы граждане и можно делать австралийский загранпаспорт. С таким паспортом можно без визы ездить в Европу, Британию (очень пригодится в мае) и практически весь остальной цивилизованный мир. В Белорусию виза нужна, но на этот случай есть российский паспорт :)
Для поездки в США нужно зарегистрироваться на сайте в интернете. Ура, больше не придётся проходить собеседование и платить $150 за трёхчасовое сидение в очереди :)

Опять же, спасибо всем, кто пришёл нас поддержать и отдельное спасибо Максу за работу фотографом!

Нас много!

12/10/2011 3:55:53 PM

Прибрался на рабочем слоле. Стало красивее.

desktop

Tags:

Live | Other

12/10/2011 10:46:28 AM

У меня нет LiveJournal и он мне не нравится. Но вот Лена отчего-то странного к нему прикипела и пользуется.
А зато мне нравится Windows Live Writer для написания блог-постов. Удобненько всё, визуально. Я и сейчас в нём пишу. 
В отличие от того же LiveJournal, в котором Лена периодически руками вставляет какие-то теги, отдельно заливает фотографии и потом вставляет адреса, опять же руками… Она, мне кажется, больше с HTML работает, чем я и скоро знать его будет лучше…

LiveJournal имеет “стандартный” интерфейс, который имеют большинство блог-платформ и который поддерживается Live Writer’ом, но, к сожалению, феномен “was not invented here” добрался и до LJ и развитие поддержки стардартных протоколов они остановили, а вместо этого придумали свой собственный интерфейс, которого не понимает никто.
Таким образом Live Writer хоть и может работать с LJ, но на очень базовом уровне (сколько ребята осилили от общепринятого протокола): нет возможности управлять видимостью постингов, нет возможности добавить теги и т.д.

Поэтому мне пришла идея попробовать написать расширение для Live Writer, которое бы позволило работать с этой платформой более полно. Ниже я напишу что получилось, а ещё ниже – как это получилось.

Что.

Итак, после установки расширения в списке расширений появляется следующий пункт:

При нажатии на него пользователь увидит вот такое вот окошечко, во время показа которого система подключится к LJ и получит сведенния об имеющихся тегах и пользовательских группах:

Естественно, ничего подобного не произойдёт в том случае, если текущий выбраный блог в Live Writer не LJ. В этом случае вообще ничего не произойдёт :)

После этого в текущий пост будет вставлен невзрачного вида блок со специфичными для LJ параметрами:

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

При клике на этот информационный блок Live Writer (как и в случае других плагинов) сбоку покажет сайдбар, где эти самые специфичные для LJ параметры и редактируются.

В текущей бета-версии можно задавать теги для постинга а так же ограничивать видимость для определённых пользовательских групп. Ещё там можно задать текст для “ката” (тег <lj cut>).

Больше, в общем-то, пока в плагине ничего нет. А, нет, если посмотреть на первую картинку, то там ещё один пунктик есть: Add LJ User (добавить LJ-пользователя), но это мелочи.

Скачать версию плагина (beta1) можно здесь: http://storage.raga.name/Wlw4LJ-beta1.zip
Установить тоже просто: разархивировать и скопировать те два файла, что там есть, в каталог
"c:\Program Files (x86)\Windows Live\Writer\Plugins"
Если такого каталога с “x86” нет, то используется каталог без оного, то есть "c:\Program Files\Windows Live\Writer\Plugins".

Вроде работает, посты-картинки постит, драфты даже уважает…

Как.

Теперь самое весёлое, “для тех кто понимает” ;)
Так как у LJ свой API, то, очевидно, необходимо написать свой провайдер, умеющий работать с этим API. Провайдеры в WLW есть, наследуйся да пиши, а вот возможность подключить собственный провайдер туда добавить отчего-то забыли. Поэтому механизм добавления нового провайдера называется DirtyHack и выглядит (в коде) соотвествующе.

Аналогично в WLW отсутствует возможность (либо я таковой не нашёл) хоть какого-то хука на запуск приложения или на его инициализацию. И никакие хаки тут не помогут. Любой плагин получает управление только в момент его вызова.
Поэтому функциональность добавления LJ-специфичного провайдера (тот самый DirtyHack) срабатывает в момент первого вызова плагина (нажатия на Add LJ Attributes). Это в чём-то лимитирует, так как при наличии хука на стар приложения можно было бы использовать некие имеющиеся, но скрытые для “оригинального” LJ-провайдера элементы управления. А когда пользователь уже нажал – ну, тут уже поздно.
Кроме того в WLW отчего-то невозможно добавить кнопки управления на Ribbon. Этому я не поверил и проверил, потом не поверил снова и проверил опять, но со словами “ну как так можно-то!” отстал. Ну, либо, опять же, не нашёл. Поэтому – только меню Add LJ Attributes. А так бы, конечно, хотелось бы Ribbon-панельку добавить.

Про протокол, опять же.
Я поскольку ленив, то писать имплементацию XmlRpc-протокола для общения с LJ мне не хотелось. Я поискал в интернете и обнаружил некую библиотечку с названием lj_net, которая, вроде как, общается с LJ и имеет все нужные мне функции и которую люди в разных поделках типа моей и используют.
Но, видит небо, более ужасного кода я не встречал уже давно. Иногда это смешно, иногда – страшно. Ответа на вопрос почему ЭТО сделано ТАК не существует.
Пришлось рефакторить, конечно, стало куда лучше, хотя и не идеально.

Идеально было бы таки написать уже свой XmlRpc провайдер (благо WLW содержит низкоуровневый набор для работы с XmlRpc), надо только его использовать. Для пользователя, конечно, разницы никакой практически, но тем не менее…

Плюс ещё есть набор фич, которые можно реализовать, от moods и до странной и повергающей меня в ступор функциональности “этот пост могу видеть только я!”. Ведь, если его можешь видеть только ты, зачем ты его в социальную сеть-то постишь, человече?! Положи себе в записную книжку, в файлик, в EverNote какой-нибудь, но в блог-то зачем?!
Ан нет, фича, говорят, страсть как полезна и нужна :)

Планы.

Может быть буду обновлять, если будет хватать рук.

12/4/2011 5:16:40 AM

Съездили в консульство, проголосовали.

Пока ехал подумал (никого ни с кем не сравниваю), что, например, режим Пиночета потерпел поражение именно на выборах. Это при том, что Пиночет не то, чтобы там как-то подковёрно, а вполне себе официально имел практически неограниченую личную власть, включая возможность назначать и снимать судей, отменять судебные решения любых инстанций и т.д. И при том, что за несколько лет до этого по результатам референдума население поддерживало Пиночета более чем на 70%.
Или, например, “правительство аппартеида” в ЮАР. Тоже всё выборы.
Опять, это я не пытаюсь провести параллели между текущим режимом в РФ и правительством Пиночета или аппартеида, а к тому, что выборы – это реальный инструмент имеющий реальную силу даже в самых сложных условиях.

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

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

Tags:

Live

11/26/2011 11:55:11 AM

Фоторюкзак CaseLogic SLRC-4 мы купили лет пять назад, спонтанно в аэропорту города Брюссель. Рюкзак оказался довольно-таки неплохим, безотказно служил и в дождь, и под палящим солнцем, и вообще на него когда-то пожизненная гарантия полагалась. И мог бы продолжать служить дальше, если бы мы не приобрели сегодня (в качестве подарка) Kata MiniBee UL-111.

Kata MiniBee UL-111 это “уменьшеная” модель очень успешного и замечательного рюкзака Kata Bumblebee UL-222, который понравился. Мягкие резиновые лямки, вентиляция спины и низкий вес определили выбор.

Более “мелкая” модель была выбрана сознательно исходя из следующих соображений:

  • Прогулки по городу/трекам. Здесь, в принципе, ничего огромного тащить с собой не нужно. Фототехника плюс что-то другое совсем по мелочи.
  • Дальние поездки. Здесь нужно, чтобы вес рюкзака не превышал 7-10 килограмм, иначе не пустят в ручную кладь. Соответственно, пользы от повышеной вместимости Bumblebee тоже оказывается не так много.

Я знаю, что CaseLogic уже давненько не выпускает SLRC-4, а MiniBee UL-111 – это самый новый продукт Kata, но всё же попытаюсь сравнить эти два рюкзака.

CaseLogic SLRC-4 и Kata MiniBee UL-111

По размеру MiniBee чуть-чуть выше, немного толще и значительно шире, чем SLRC-4. При этом по весу SLRC-4 хоть и легче MiniBee, но всего где-то на пару сотен грамм.

CaseLogic SLRC-4 внутриMiniBee UL-111 внутри

Внутри MiniBee повместительнее. На фотографии с CaseLogic в рюкзаке лежит Nikon D700 c надетой линзой 50мм, Nikkor 80-200AFS и Nikkor 105AFS VR. На фотографи с MiniBee к этому всему ещё добавился Tamron 19-53, вспышка и фотобанк. Фотоаппарат в рюкзаке ездит крайне редко, поэтому потенциально место ещё есть.

CaseLogic SLRC-4 - верхний карманMiniBee UL-111 - верхний карман

Верхнее отделение у MiniBee существенно вместительнее, чем у SLRC-4. Туда легко влезает фотоаппарат с “полтиником” и блендой на нём (для понимания размера). Кроме того, у MiniBee есть ещё и кармашек, который предназначен для всякой мелочёвки вроде фильтров, карточек, авторучки, LensPen и т.д. А у SLRC-6 в качестве миникармашка просто сеточка на внутренней стороне “крышки”.

CaseLogic SLRC-4 - боковые карманыKata MiniBee UL-111 - боковой карман

А вот с боковыми карманами ровно обратная история. Боковые карманы с обоих сторон у SLRC-4 просто великолепны. Они большие во всю длину рюкзака, внутри сеточками слелано три кармашка, хочешь пользуй, хочешь – нет. Много чего убирается, например в одном таком кармане у меня обычно лежала вспышка + фотобанк. Во втором – ручки, LensPen, батарейки, ножик, лапки для штатива, пара леденцов и т.д. Плюс снаружи есть ещё по сетчатому кармашку – положить бутылочку воды или зонтик. Или с одной стороны бутылочку воды, а с другой – зонтик. Или две бутылочки воды. Или два зонтика.
У MiniBee ничего подобного нет. Вместо всего этого великолепия – один карман среднего размера. С другой стороны – незастёгивающийся кармашек для бутылки с водой. Допускаю, что в виде бардака в этот карман можно сложить половину того, что я перечислил выше, но слово “бардак” даёт мину десять к полезности.
Я не понимаю, что мешало Kata приделать поверх этого кармана подобные сеточки, да и внутри они бы не помешали, но нет. А ведь я им писал об этом несколько месяцев или год назад! Проигнорировали, конечно, какое им до меня дело.

Kata MiniBee UL-111 - лямки

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

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

А вот дополнительная “растяжка” на груди у MiniBee мне очень понравилась. У SLRC-4 такой нет, поэтому я раньше не сталкивался и был приятно удивлён тем, как, казалось бы, такая маленькая и незначительная деталь меняет удобство ношения рюкзака. Подтянул её – и прямо-таки совершенно по-другому чувствуется. Плюс на BiniBee можно с верхней стороны “подтянуть” лямки чтобы сделать плечи ближе или дальше от задней стенки рюкзака. Это тоже показалось удобным.

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

Отделение для ноутбука – тут паритет между обоими рюкзаками.

Резюме: новый рюкзак нравится. Единственный недостаток для – это недостаток карманов, причём не с точки зрения места, а с точки зрения именно распределения, то есть, нашитых сеточек бы понаделали, и было бы вообще замечательно.

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

Довольны.
А старый CaseLogic SLRC-4 ещё тоже послужит. Выкидывать пока не собираемся.

9/24/2011 2:55:31 PM

Очень классную, по-моему, рекламу по мотивам чемпионата мира по регби крутят по ТВ. Очень нравится.

http://www.youtube.com/watch?v=Bd5ZGLSAHuk

Powered by BlogEngine.NET 2.5.0.6

About the author

Alexey Raga Alexey Raga
.NET software developer.

E-mail me Send mail

Twitter

Widget Twitter not found.

Root element is missing.X


Recent posts

Archive

Disclaimer

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

© Copyright 2014

Sign in