xUnit Test Patterns: Refactoring Test Code / Шаблоны тестирования в xUnit: рефактор тест кода

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

Шаблоны тестирования в xUnit стала последней книгой для меня и иронично самой сложной. Эту книгу я отыскал на Амазоне и решил: «она большая и, наверное, содержит много материала, о котором я никогда не слышал». В реальности мой рационал не мог быть дальше от правды. Книга действительно содержит много информации и однозначно полезной, однако у книги есть несколько фундаментальных проблем, которые в совокупности сводят коэффициент полезного действия фактически к нулю. Но, пойдём по порядку.

Первая проблема – длина книги! Она слишком большая! Книгу стоило разбить на две отдельные книги: первые 300 страниц – все что нужно знать, вторые 500 страниц ещё раз и с глубокими примерами и добавочными мыслями. Если бы я писал книгу, то однозначно бы сжал ее до 350 страниц и на этом концерт был бы закончен.

Вторая проблема – механизм доставки! Все сухо, с определениями, повторами и со странной структурой. Автор жутко напоминает профессора, который готов бубнить что-то 3 часа подряд, не взирая на аудиторию или её отсутствие. В какой-то момент (после 350-ой страницы) я реально стал задумываться, если автору платят по количеству слов в книге. Я предположу одно: возможно когда книга такая длинная, то сложно следить за изложением мыслей и структурой. Однако пишут же хорошие и очень длинные книги по фантастике?!?!?

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

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

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

Финальные мысли: книга в принципе хорошая, однако советовать её всем не могу! Книга прийдется по вкусу тем кто уже знаком с темой и хочет по максимуму выжать все что можно. Однако давать её программистам для улучшения навыков, того не стоит! Есть куда более полезные книги: Разработка через тестирование по примерам и Искусство модульного тестирования с примерами C# не говоря о блогах и других ресурсах. Автор мог бы сделать шикарный материал, если бы убрал все выше описанные недостатки и сфокусировался на рецептах.

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

Итого:
+: Огромное количество информации по тестированию
-: Слишком длинная
-: Изложение довольно сухое
-: Много повторений и рекламы другой книги
-: Излишний фокус на фрейворки по тестированию ( которые уже устарели )
=: Книга для тех кто хочет выучить тему вдоль и поперек. Однако рекомендовать её программистам я бы не стал – слишком низкий возврат по инвестициям. Есть куда более полезные книги для практического применения, не говоря о блогах и других ресурсах!

Название: xUnit Test Patterns: Refactoring Test Code
Авторы: Gerard Meszaros
Обложки:

Toyota 14 principles / 14 принципов Тойоты

Легко рационализировать как Форд/ДжиМ/Крайслер стали огромными и успешными мировыми авто-производителями — Америка богата ресурсами, стабильна и никогда не была в полной разрухе. Однако не легко понять как Тойота, будучи в стране с очень ограниченными ресурсами и пост-военном хаосе, смогла стать успешным и крупнейшим мировым авто-производителем. Книга «14 принципов Тойоты» раскрывает секреты успеха.

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

Поскольку Тойота является авто-производителем, в книге описание крутится вокруг массового производства деталей и автомобилей. Однако тут стоит притормозить и отметить, что Генри Форд придумал коверную сборку после наблюдения за работой мясной фабрики. А делегация от Тойоты, приехавшая в Мичиган на “Румяную” фабрику Форда, привезла домой новые идеи по производству автомобилей, наблюдая за работой Американских супермаркетов! Отсюда можно сделать вывод, что правда в еде, но более рациональный вывод — решения не должны находиться в каких-либо рамках.

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

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

И тут поделюсь своим домашним (не профессиональным) опытом: моя жена и я переодически планируем череду задач – мелкие жизненные “проекты”. Однако моя жена достаточно забывчивая и задачи часто не выполнялись вовремя или не выполнялись вообще. Я, со своей технологической башни потратил достаточно денег на органайзеры, телефоны, смарт-часы и другие высоко-технологичные решения, которые, если верить “продавцам”, решат все проблемы! Однако результат не изменился, задачи не выполнялись вовремя, проекты растягивались и это было не прикольно, потому что пришлось бы отложить отпуск. Решение пришло с нескольких сторон: “принцип использую простые решения”, “принцип сделай поток визуальным” и простая kanban доска, которую я тупо сделал на кухонной стене используя простую изоленту (для покраски) и фломастер. Результат? Ошеломительный! Мне даже не приходится жене ни о чем напоминать. Задачи выполняются, а если зависают, сразу видны, и тут же проводится референдум (почему, кто, когда и как) — моментальная переорганизация.

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

Итого:
+: Простое изложение
+: Примеры и байки
+: Обсуждения каждого принципа и его применения
+: Без воды и ступы
-: Отсутствие критики принципов и производственной системы Тойоты
=: Книга хорошая и я однозначно рекомендую ее читать – отличный возврат на инвестицию времени и денег. Да, мы все думаем, что наша работа не имеет ничего общего с конвейерной сборкой, но это не так, в любой работе можно найти повторяемые задачи и оптимизировать их!

Название: Toyota 14 principles
Авторы: Jeffrey K. Liker
Обложка:

Замена котла

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

Вот вам простая математика: новый (такой же) котел стоит $600 + налоги. Срок службы такого котла в районе 8-10 лет. 8 лет умножаем на 12 месяцев в год на 20 долларов в месяц = $1,920 или за 10 лет = $2,400.

Установка котла довольно проста, в особенности с последними технологиями водяных и газовых труб! Больше не нужно ничего варить, паять или сверлить. Водяные трубы (холодная и горячая) прикручиваются к котлу, а с другой стороны тупо насаживаются на исходные трубы и само-затягиваются – Shark Bite. С газом все получилось примерно так же просто, так как котел почти такой же по размерам, то труба подходила почти идеально, минус чуть-чуть выгнуть медную подводную трубу. При подключении используется толстая чёрная металлическая сборная труба, которую пришлось разобрать как конструктор лего и собрать обратно на новом котле. Все достаточно просто – лей не жалей специальную пасту на резьбу, потом затягивай, НЕ вытирай избыток пасты (пусть будет) и вуаля. Последнее и не менее важное – заменить выхлопную трубу, так как мой новый котел был на 2 инча ниже, пришлось купить новую выхлопную тубу, отмерить, отрезать ножницами по металу, скрутить и труба само-замкнется. Далее вставить вместо старой трубы, чтобы все сидело плотно, но без лишних усилий! Важный момент! Если ваша выхлопная труба состоит из многих частей и находится под углом, то не меняйте угол! Можно угол наклона увеличить, но не нужно уменьшать – помните, горячие газы стремятся вверх, чем меньше сопротивлений и больше угол, тем лучше.

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

1. Читаем инструкцию
2. Ставим ручку в позицию “пилотный огонь”
3. Давим на ручку – газ пошел
4. Нажимаем на кнопку искры – продолжаем нажимать до 90 секунд или пока не загорится.
5. Когда котел разгорелся, через пару секунд начнет мигать светодиод с перерывом в 1 секунду – все работает нормально
6. Переводим ручку в желаемую (по температуре) позицию
7. Идем пить пиво

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

Spy the Lie / Шпио́нство за ложью

Эту забавную книгу я обнаружил на одном блоге по программированию, в листе «любимых» книг. Идея мне понравилась: как определить когда люди пытаются от тебя что-то скрыть.

Техники и методики были написаны сотрудниками ЦРУ и использовались по прямому назначению. Однако книга не раскрывает все секреты мастерства, по понятным причинам. Но делится довольно интересными и серьезными техниками, которые на мой субъективный взгляд полностью эффективны.

Авторы дают много примеров и анализа в попытке познакомить читателя с ситуациями, разговорами, строением предложений и физиологической реакцией. Из личного опыта скажу: в таком деле нужна практика, если вы когда-либо покупали б/у авто с рук, то знаете, что разговаривать с продавцом довольно важно. Если продавец начинает кривить, отвечать на другой вопрос и так далее, то это еще не повод бежать, но точная заметка, что надо копать дальше. Пример из личной жизни: «авто когда-нибудь было в аварии?», ответ: «нет, пока я ездил на авто, я никогда не попадал в аварию» – перевод на Русский: я не знаю или не хочу раскрывать полную историю автомобиля, но я на нем не бывал в аварии. Повод уходить от покупки? Нет! Это повод очень серьёзно посмотреть на все стыки в корпусе, в моем случаем были видны признаки аварии.

Книга конечно же не является пособием «молодого бойца», однако хорошо подойдёт всем кто хочет проводить конструктивные интервью/беседы, так как основная цель и задача не давить на человека, а заставить его самого, свободно рассказать правду, всю правду и ничего кроме правды. Единственная критика, которая приходит мне в голову: есть разница когда идёт профессиональное интервью в ЦРУ / полицейском участке и разговор между двумя людьми в офисе – если кто-то не хочет говорить, то в одном случае могут быть последствия, а в другом – развернулся и ушёл.

Итого:
+: Хорошее изложение
+: Примеры
+: Просто и эффективно
+/-: Написана для общей публики – без глубины
-: Короткая – хотелось больше примеров и теоретической отработки материала
=: Книга интересная и, пожалуй, стоящая, но без практики может оказаться бесполезной.

Название: Spy the Lie
Авторы: Philip Houston, Michael Floyd, Susan Carnicero, Don Tennant
Обложка:

Гараж

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

Идея с гаражом была достаточно простая — сделать так, чтобы:

  • гараж остался гаражом на две машины, а не стал складским помещением;
  • место для технического обслуживания и ремонтных работ с автомобилем;
  • все под рукой – расположить инструменты и расходники на виду, чтобы не рыскать по шкафам и коробкам когда нужно что-то делать;
  • дополнительное место для поделок;
  • минималистично и мобильно, если нужно работать над чем-то большим (например БТР) то можно быстро переорганизовать гараж;
  • чилл место — можно посидеть, выпить рома и раскурить сигару.

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

Чирз!

Test-Driven Development by example / Разработка через тестирование по примерам

«Мы не стали программистами чтобы убивать людей…» – uncle Bob.

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

Я не знаю почему начал с такой «оптимистической» ноты — когда я сел писать мысли о прочтенной книге, именно эта цитата пришла в голову. Исторически я начал программирование довольно традиционно — пишешь код, потом тыкаешь в программу и вроде все работает. Года 4 назад мне повезло и я работал с людьми, которые практиковали TDD (разработка через тестирование) ремесло. Я присосался на сколько мог и с того момента стал поклонником методики. Традиционно, программисты знают как «правильно» писать код и тесты, однако не все субъективные «правила» тесто-писания улеглись в моих мозгах. Некоторые из них меня напрягали, зудели и всячески не хотели приживаться. Визуально некоторые из правил выглядели так: если деталь куда-то не влазит, то по «правилам» нужно взять молоток, да побольше, и бить, пока не влезет, а когда расплющенная деталь влезла в разбитый корпус, тогда берешь напильник и замазку — «эх, говорил же тебе, что все влезет!!!».

Я никогда не умел забивать (привет дяде Роме и уже сгнившему забору на даче). По этой причине я продолжил изучать эту тематику. С опытом и дополнительными знаниями, я понял, что нет точных/абсолютных правил написания тестов, есть только основные (Three Laws Of TDD by uncle Bob). Все зависит от системы, кода и кучи других не сильно замысловатых факторов.

По иронии судьбы, к моменту «прозрения» я наткнулся на эту книгу. Кент Бэк обнаружил TDD технику в “древних” книгах по программированию и решил возродить ремесло. В этой книги Кент затрагивает многие темы, начиная от базовых примеров и заканчивая ответами на тяжелые вопросы: «а когда тест считается слишком большим?». Автор затрагивает многие типичные проблемы, которые вы рано или поздно встретите в TDD разработке, и даёт как конкретные, так и философские ответы. Этот материал является, на мой субъективный взгляд, основой, так как в индустрии можно найти много разных интерпретаций, в особенности, если смотреть TDD дебаты на YouTube-е.

Если вы заинтересованы в ремесле, стоит читать книгу, однако подготовьтесь — первые 40 страниц могут показаться нудными и тривиальными, однако не стоит их пропускать. Автор разбивает темы на под-темы и короткие отдельные главы — с одной стороны это немного раздражает, но со временем медленно вырисовывается шаблон. Шаблон служит как пример: мышления и написания кода. Очень интересно проходит параллель между изложением книги и программированием. Чувствуется, что автор книгу не писал, а программировал — название самой книги на 100% отображается в материале!

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

Итого:
+: Структура, примеры и дискуссии
+: Наглядно от и до
+: Содержит все основы
+: Где использовать и какие существуют ограничения техники
+/-: Изложение местами оставляет желать лучшего
=: Отличная книга, которую стоит читать всем программистам. Я жалею, что не наткнулся на эту книгу всего пару лет назад.

Название: Test Driven Development: By Example
Авторы: Kent Beck
Обложка:

Кодофон / Хакафон в RouteOne 2018

В конце 2018 года моя компания решила устроить кодофон (хакафон) — одно из самых интересных событий, которое могу вспомнить. Я решил принять участие. После формирования команды, мы потратили большое количество времени на подготовку, тренировки и исследование потенциального продукта. В итоге мы воплотили в жизнь небольшой гибрид идеи нашего дизайнера и того, что “прилепилось” за время изучения тематики. После тяжких 3.5 дней работы, мы презентовали наш продукт судьям. С отрывом всего в один голос, мы заняли первое место!!!

Я постараюсь найти видео, а пока оставлю тут фотки:

First, break all the rules / Сначала надо нарушить все правила

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

Книга написана для менеджеров: “Изучая неудачи, вы не найдете пути к совершенству. Только изучая совершенство, вы обретете совершенство.”, но пригодится не только им. На мой субъективный взгляд. книга довольно хорошая, даже если отбросить исследования и описанный статистический анализ. Много рецептов, с которыми я согласен, по меньшей мере из моих личных наблюдений.

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

Другой, не менее интересный, но более спорный рецепт — проводите свое время (время менеджера) с самыми лучшими работниками — помогайте им. Моя личная предвзятость просто кричит: “Что за бред? У всех есть потенциал! Нужно лишь помочь!!!”. Однако за мое недолгое время в индустрии я заметил, что из уже отличных работников можно получить ещё больший результат если им помогать, убирая с дороги бюрократию, шелуху и предоставляя то что они просят. С другой стороны, сколько я не тянул за собой отстающих, как только я отпускал, то все возвращалось на круги свои – печально, но пока что таков мой личный опыт.

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

Итого:
+: Рецепты и техники
+: Опыт успешных менеджеров
+: Интересные исследования
+/-: Изложение не самое лучше
+/-: Местами отдает догмой
=: Хорошая книга, которая не обязательна, но может вполне пригодиться, если вы стоите во главе (чего либо) и в особенности если вы менеджер. Если есть время, то инвестируйте — читайте.

Название: First, Break All the Rules: What the World’s Greatest Managers Do Differently
Авторы: Marcus Buckingham, Curt Coffman
Обложка:

Поездка в Монреаль

Этой зимой мы решили вернуться в провинцию Квебек и посетить культурную столицу Канады. Поездка была на 3 дня, а это значит все по быстрому – первые впечатления самые верные?

Минусы:

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

Нам довелось немного поездить по Монреалю и, положа руку на сердце, скажу: качество дорог не впечатляет. Пару раз попадались такие выбоины, что можно легко оставить колесо прямо там. И тут вписывается другой момент – везде платная парковка, такого я даже в Торонто не видел! Приезжаешь в спокойный район, видишь – обычная улочка с домами и машинами, ничего приметного, а все равно нужно платить. И вроде население Монреаля не большое, да и мест хватает, а нет… взял да выложил. Справедливости ради, отмечу, что цены на парковку не высокие, но если вы весь день передвигаетесь с места на место, то деньги начинают складываться. С учетом выше описанного, невольно напрашивается вопрос: так почему дороги такие раздолбанные?

Мои заметки:

По моему субъективному мнению, ехать в Монреаль стоит летом, так как летом проходят фестивали, да и гулять по городу будет намного приятней. Однако у нас сложилось иначе, поэтому первый день (21 декабря) прибывания встретил нас дождем. Гулять по старому Монреалю в дождь не самое приятное время провождения, но мы смогли пройти 30000 шагов и посетить Базилика Нотр-Дам, Рынок Бонсекур, Crew and Collective Cafe, Montreal Museum of Archaeology, старый порт и другие места.

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

В плане денег, Монреаль вполне доступен, однако стоит бережно относиться к посещению ресторанов. Выбирайте места заранее и не парьтесь о модных ресторанах. Мы посетили несколько таких мест и остались с осадочным чувством. Так, Brasserie T! не оставил никаких эмоций, но при этом «хороший» счет. С другой стороны гастрономия Schwartz’s оправдала надежды – вкусно, весело и доступно. Так же не покидайте Монреаль пока не отведаете бубликов из St Viateur Bagel Shop.

Итого:

Монреаль – классный город! Но! Знайте заранее зачем вы туда едите. Я лично хотел бы вернуться в Монреаль летом, когда проходят фестивали и провести время именно в этой среде.