Хоккейная амуниция

          Хотел бы поделится своим опытом в выборе/эксплуатации хоккейной амуниции. Мои дети довольно давно играют в хоккей и за это время я опытном путем выяснил:

• Коньки и клюшки должны быть только Bauer/CCM.  Эти две детали хоккейной экипировки на топовом уровне никто еще не научился делать. 
• Клюшки True - красивые, легки - но хрупкие.
• Клюшки vikkela - в принципе не плохой вариант для маленьких детей, до 8-9лет так как являются одними из самых легких. Но опять же хрупкие.  На подростковом возрасте они будут быстро ломаться
• Наши клюшки Заряд прям порадовали - за свои деньги оказались прям очень достойным вариантом. Но дизайн не обновляется, по сравнению с другими выглядит убого. Они почему-то не понимают что для детей это важно. 
• Шорты - в принципе любые можно брать, тут главное чтобы удобно сидели на поясе. Но самые удобные Bauer серии Ultrasonic
• Нагрудник - марка тоже не принципиально, у всех есть хорошие модели. Нужно смотреть чтобы наплечные чашечки не болтались, нормально были закреплены. У Bauer есть неудачная серия, где эти чашечки из "сверхлегкой пены" плохо закреплены и болтаются постоянно. 
• Налокотники, наколенники, краги - тоже без разницы какой фирмы.  Все что там пишут про ультрасовременные технологии на 99% брехня. Все эти граммы ни на что особа не влияют.  Главное чтобы ребенку в этом удобно было. 
• Защита шеи - только Ice Armor. Для меня остается загадкой почему никто не додумался кроме Ice Armor сделать нормальную защиту шеи. 
• Баулы - лучше брать НЕ Bauer/CCM. Они переоценены. Ничем в лучшую сторону не отличаются. Я экспериментировал с разными формами. Стоячие чуть удобнее если в раздевалке мало место, но сильно дороже. Сейчас остановился на классических прямоугольных баулах. У тех же Ice Armor очень не плохие баулы получились.
• Шлемы - вообще никакой разницы между брендами нет. Главное подобрать его по форме/размеру головы, чтобы не мотался на голове туда-сюда, и не жал (даже чуть-чуть не должен жать). Иначе он во время тренировки намокает, и еще больше жать начинает.  
• Термобелье - тоже всякого перепробовал. 
• Самые топ конечно Bauer, но неоправданно дорогой. Но у меня есть комплект который четвертый год уже носят каждый день. Надписи постирались уже, затяжка в одно месте - но в общем и целом почти как новый. Никаких тебе катышков, липучки тоже работают как новые.  В общем если денег не жалко - прям рекомендую
• Mad guy - тоже ок, но катышки появляются и оно на ощуп холодное. Когда еще в раздевалке холодно - прям совсем не очень. Дети ныли от него постоянно
• Goal& Pass - самое лучшее по отношению цена-качество. 
• Носки - Bauer конечно самые лучшие, но они довольно тугие. Особенно когда ноги влажные - прям тяжко одеваются. Ну и они пипец какие дорогие. За эти же деньги можно 3 пары Goal&pass купить. Или 5 пар noname носков. В общем я сейчас высокие гольфы от noname продавцов покупаю - норм заходит

SDLC models/Software development methods/Software development models

            Я решил освежить и систематизировать свои знания по SDLC models/Software development methods/Software development models. Я признаюсь честно, будучи программистом я с отвращением относился ко всем этим методологиям и тем кто их продвигает.  У меня всю жизнь была предельно простая методология разработки: Нормально делай, нормально будет!  Ну а сейчас думаю - негоже мне быть невеждой до старости, надо просветится. 

           Вы знаете - почитав весь вечер про все эти Agile/Scrum/Lean/Kanban у меня ощущение как будто я методичек от Лайк Центра начитался. Успешный успех повсюду. По сути все эти "методы" - маркетинг чистой воды. Бородатые мужики в 1960-х придумали предельно простые вещи - чтобы написать какой-то софт тебе нужно:

1. Собрать требования к софту
2. Спроектировать его
3. Спланировать разработку
4. Разработать
5. Протестировать что ты понаписал
6. Задеплоить в прод
7. Поддерживать

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

Специально для тех бедолаг кому больше нечем заняться кроме чтения моего недоблога, спецкурс - история развития software development methods за 5 минут. Не благодарите.

1. Waterfall - вот как раньше мосты разрабатывали, так и софт будем писать. Собрали требования, спроектировали, построили, сдали в эксплуатацию. Все по порядку, никакого agile. Ну что вы хотели, мосты ведь не agile ни разу. 
2. Prototyping - эту методологию тоже из традиционной инженерии взяли. Прежде чем огромный мост бабахать, может маленький сделать из говна и палок ? Так быстрее будет гораздо, и заодно поймем какой нам мост нужен прежде чем все в полный рост делать 
3. Iterative and incremental development - ну это первый метод разработки который придумали именно для софта. Додумались что в отличии от моста, софт можно писать по частям. То есть выкатил первую версию с одной фичей, потом собрал требования для второй фичи, разработал и выкатил вторую фичу. В общем мы все до сих пор примерно так и работаем
4. Spirital development - вот первая ласточка технического маркетинга, буллшита по нашему. Из 1986 года напомню. Чувак(Barry Boehm) подумал - а что если мы будем задачу решать в цикле, и на каждой итерации этого цикла, будем проводить оценку рисков и выбирать наиболее подходящую методологию разработки для данной итерации. В общем чувак добавил бюрократии в виде оценки рисков, ну и все остальное как в iterative and incremental development. Но главное его изобретение я считаю - он изобрел технический маркетинг в методологиях разработки. Ибо после него маркетингового буллшита стало в разы больше
5. Rapid Application Development (RAD) - в 1991 году James Martin понял невероятное - клиентам гораздо проще пальцем показывать чем читать/писать огромный толмуды с требованиями. Напомним что в классическом waterfall - тебе нужно на первом этапе выдать разработчикам все требования ко всем фичам в формализованном виде(в виде текста), а потом подписать их своей кровью и не менять их после этого. Какая-то немыслимая херня по нашим временам. А James Martin понял что если сначала, на этапе сбора требований быстро сделать на коленке что-то, что выглядит примерно как тот софт который тебе нужно написать (прототип), и заставить клиента расписаться кровью на прототипе - то вероятность того что в итоге клиент получит именно то что он хочет, сильно повышается по сравнению с 500-страницами требований в виде текста. Ну и еще он понял что потом этот прототип не обязательно выкидывать после, его можно улучшать итеративно, и даже давать клиенту им пользоваться. В общем prototype + iterative and incremental development+marketing = RAD. Причем этот маркетинг я уже застал в своей программистской карьере. Borland  Delphi, Borland C - это все было уже RAD-остным.
6. Extreme programming -  вот где маркетинговый буллшит развернулся в полную силу. Kent Beck решил, а что если мы возьмем все хорошее, что есть в существующих методологиях разработки ПО и сделаем это на максималках(extreme)? Чем не новая методология ? К примеру code review на максималках - это pair programming. Что, до него pair programming никто не занимался ? Неужели чтобы сесть вместе с джуном и показать ему как писать код, тебе нужна новая методология ?  Что самое интересное, Kent Beck разработал эту методологию когда работал в Chrysler над их бухгалтерской системой. Начал он там работать в 1996, в 1999 написал книгу про extreme programming, а в феврале 2000-го этот проект закрыли.  Прям успешный успех, не правда ли ? В это же время саму Chrysler купила Mercedes Benz. Наверное потому что в Mercedes набирали программистов которые по одному умели работать, а в Chrysler все по двое сидели.
7. Scrum - а дальше ребята подумали, iterative and incremental development звучит слишком понятно, по этому книжку не напишешь. А что если мы это все пере-назовем своими словами и добавим ритуалов по вкусу ? Чем не новая религия для программистов ? Сказано -сделано, так и появился scrum.  Ребята отличились тем что изобрели новую профессию - scrum-master. Типа как scrum-священник. Ведь у каждой религии должен быть священник который бы следил чтобы все ритуальные митинги соблюдались ?
8. Lean software development - а дальше Mary Poppendieck and Tom Poppendieck прочитали книжку про Toyota и ее  систему управления производством. И тут они подумали - что если взять все хорошее из существующих методологий, переназвать терминами из книг по TPS, то получится вполне себе новая методология. Поэтому не долго думая в 2003 году они выпустили книгу Lean Softwware Development и подружились с тусовкой agile-балоболов и счастливо колесят по миру продавая свое "изобретение". 
9. Kanban development - а дальше случилось мое любимое изобретение, Kanban. Ребята "изобрели" kanban доску и построили вокруг этого не хухры-мухры а целую методологию. Цитата из википедии - "Kanban approach aims to manage work by balancing demands with available capacity, and by improving the handling of system-level bottlenecks". А то до вас никто не балансировал запросы на IT capacity с ее фактической доступностью. Вы первые такое придумали. Увидели что на kanban доске куча задачь в QA зависла. Собрали совещание - что же нам делать ? Наверное нужно количество тестировщиков увеличить! Бинго! 

На этом у меня все. Ждем новых методологий разработки.

Метрики в разработке

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

       Наконец-то я нашел адекватное исследование на эту тему - https://queue.acm.org/detail.cfm?id=3454124 Я крайне рекомендую прочитать его прежде чем внедрять эти метрики. Они предлагают метод называемый SPACE. В рамках этого метода они предлагают использовать 5 измерений: удовлетворенность, производительность, активность, коммуникативность и эффективность. В каждом измерении они предлагают ряд метрик которые можно измерить, либо измерений которые могут быть использованы как прокси-метрики для целевых метрик. К примеру удовлетворенность саму по себе измерить трудно, но можно легко замерить уровень текучки в коллективе (turnover), которая  может служить в каком-то приближении прокси-метрикой для удовлетворенности (не удовлетворен =>уходишь). Мне лень переводить все, поэтому дальше просто короткое обобщение на английском:

• Satisfaction and well-being dimension
• Best captured with surveys. To assess the satisfaction dimension, you might measure the following:
• Employee satisfaction. The degree of satisfaction among employees, and whether they would recommend their team to others.
• Developer efficiency. Whether developers have the tools and resources they need to get their work done.
• Burnout. Exhaustion caused by excessive and prolonged workplace stress.
• Productivity and satisfaction are correlated, and it is possible that satisfaction could serve as a leading indicator for productivity; a decline in satisfaction and engagement could signal upcoming burnout and reduced productivity
• Performance dimension - is the outcome of a system or process.
• Can be measured with following metrics
• Quality. Reliability, absence of bugs, ongoing service health.
• Impact. Customer satisfaction, customer adoption and retention, feature usage, cost reduction.
• Activity dimension - is a count of actions or outputs completed in the course of performing work. Metrics can be:
• Design and coding. Volume or count of design documents and specs, work items, pull requests, commits, and code reviews.
• Continuous integration and deployment. Count of build, test, deployment/release, and infrastructure utilization.
• Operational activity. Count or volume of incidents/issues and distribution based on their severities, on-call participation, and incident mitigation.
• Communication and collaboration dimension - capture how people and teams communicate and work together. Following are examples of metrics that may be used as proxies to measure communication, collaboration, and coordination
• Discoverability of documentation and expertise.
• How quickly work is integrated.
• Quality of reviews of work contributed by team members.
• Network metrics that show who is connected to whom and how.
• Onboarding time for and experience of new members
• Efficiency and flow dimension - capture the ability to complete work or make progress on it with minimal interruptions or delays, whether individually or through a system Some example metrics to capture the efficiency and flow dimension are:
• Number of handoffs in a process; number of handoffs across different teams in a process.
• Perceived ability to stay in flow and complete work.
• Interruptions: quantity, timing, how spaced, impact on development work and flow.
• Time measures through a system: total time, value-added time, wait time.

Также авторы исследования разъясняют как этот метод можно применять для SRE команд и управления инцидентами.

Есть хорошее исследование предложенное DevOps Research and Assessment (DORA) - https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance 

Они предложили простой фреймворк из метрик (изначально 4-х метрик, reliability добавили потом), которые довольно легко измерять:

• Deployment Frequency—How often an organization successfully releases to production
• Lead Time for Changes—The amount of time it takes a commit to get into production
• Change Failure Rate—The percentage of deployments causing a failure in production
• Time to Restore Service—How long it takes an organization to recover from a failure in production
• Reliability - represent availability, latency, performance, and scalability

Это сильно проще чем SPACE фреймворк, но они сознательно убрали из рассмотрения все не техническое - мотивацию, удовлетворенность и тд. 

Ну и в завершении обзора подходов к оценки производительности команд - набор метрик для платформенных команд:

• Platform adoption rate - Measures how many product teams or services actively use the platform against those that don't.
• Mean time to onboard (MTTO) - mean time to unboard
• Platform service uptime
• Feedback loop duration - Tracks the average time from when users provide feedback to when the platform team addresses it.

Метрики довольно простые и логичные, но не все из них легко реализуемы на практике (я имею ввиду автоматизированное измерение)

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

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

Сменил ласточку на кабанчика

         В сентябре я таки сделал то о чем давно думал - сменил свою ласточку X7 на кабанчика V300d от мерседес. Что я хочу сказать после месяца использования. Кабанчик более практичная машина. Межсервисный интервал в 40т км говорит сам за себя (у X7 ТО нужно было проходить каждые 15т км). 15т км это каждые пол года в моих реалиях. Кабанчик не плохо едет. Заявленные 205км/ч я не пробовал ехать, но 190 по новой платной трассе М12 он уверенно едет. Даже на такой скорости рулится он как тяжелая легковушка, а не как автобус. Места в салоне теперь хоть отбавляй и в багажнике тоже довольно вместительно. Два хоккейных баула влезают в багажник без передвигания сидений. В общем я получил то что хотел. На мой взгляд кабанчик это идеальная машина для большой семьи. То что мы все не влезали в X7 собственно и стало основной причиной смены машины. 

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

      Ну и на последок из ржачного. У мерседеса есть такая система Ad Blue. Для нее есть отдельный бачок куда эту blue нужно наливать. А знаете что это за магическая blue-жидкость? это мочевина. То есть все дизельные мерседесы ездят на смеси дизеля с мочей. В этой связи вспоминается один  известный фильм:

Индия, Вадодара, Гуаджарат

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

• Английский язык для индусов такой же не родной как и для нас. Отсюда все приколы про их произношение и акцент. В больших городах где все перемешано на английском говорят больше, в провинции все на hindi. 
• У индусов и пакистанцев одинаковый родной язык  - hindi. Так же в Индии полно мусульман. Так что разделение на Индию и Пакистан это по сути тоже самое как разделение на Россию и Украину. Некоторые различия есть, но они на самом деле довольно условные. Туда же идут Бангладеш, Непал и Шриланка - это все отколовшиеся части Индии.  Короче Британцы которые все это устроили - лютые пидорасы.
• Кастовая система в самом лютом ее проявлении - тоже плод британского владычества(принцип - разделяй и властвуй). До прихода британцев касты не имели никакого прикладного/практического значения. Они всего навсего описывали род занятий человека (крестьянин, рыбак, портной, сапожник и тд) и не предполагали каких-то практических ограничений в реальной жизни. И их было сильно больше чем те 4 которые описывали британцы. Кастовая система в том виде котором мы ее знаем была введена британцами для того чтобы:
• Облегчить учет и сбор налогов
• Использовать одни касты для контроля других каст. Возвысив касту брахманов, они стали использовать ее для контроля остального населения Индии. То есть контролировали индусов с помощью самих же индусов.
• Кастовая система до сих пор существует. Я опросил коллег сидящих за столом и 2 из них оказались их касты земледельцев, трое - из касты брахманов. Люди до сих пор женяться на представителях своей касты. В сельской местности люди разных каст до сих пор живут отдельно. Но она постепенно изживает себя. Достаточно сказать что текущий примьер-министр Индии - из низшей касты (портных)
• Религиозные правила для разных каст и даже штатов сильно различаются. Кто-то прям веган, кто-то вегетарианец, кто-то спокойно кушает мясо. 
• Вообще европейская/западная кухня не распространена в Индии, так как плохо сочетается с вегетарианстом. В штате Гуаджарат - по умолчанию все блюда вегетарианские. Те что не вегетариснкие помечаются в меню специально - non-vegetarian. 
• Индия довольно молодая страна на самом деле. В текущем виде ей меньше ста лет. Она только пытается построить/найти свою идеологию которая бы объединила все разнообразие народов которое там живет. Недавно они построили статую объединения - самую высокую статую в мире. Это статуя Валлабха́и Пате́ля которого считают одним из отцов основателей современной Индии. Теперь туда туристов и школьников. Типа нашего мавзолея :-)

Как понять что менеджер - мудак ?

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

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

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

       В третьих - перекладывание своей работы (в особенности принятия решений) на других людей. Еще один типичный ход мудака в данной ситуации - а давайте наймем консультанта по надоям. Пусть он все проанализирует и скажет нам как увеличить надои молока. Или - давайте наймем Chief Dоярка Officer (CDO). Это будет специалист по надоям с опытом в банковской сфере и он придет и решит все проблемы.

       В четвертых - мудак всегда будет избегать принятия рискованных решений. Даже если это сверх невыгодно для компании, он все равно выберет enterprise продукт с кучей сопутствующих консультантов. Очень часто для компании это приводит к vendor lock-in. Использование open source продуктов - это трудно. Для этого нужна квалификация, нужно знать границы применимости того или иного решения.  Это риски. Потому что если что-то не работает - кто виноват ? Ты виноват, ты же принял решение использовать open source.  Когда ты покупаешь enterprise продукт - ты с легкостью избегаешь ответсвенности. Ты спрашиваешь у продавцов - оно будет работать ? Продаваны конечно скажут что будет работать как по маслу. Их дело - продать. Поддерживать это все потом будут совсем другие люди.  Если что-то вдруг не работает - ты сразу пальчиком на продавцов показываешь и говоришь - "вот они мне обещали что будет работать". То есть ты сразу как бы не виноват. А продаван уже за тебя премию получил и уже потратил ее. Ему похеру на все. Он тебе скажет - извини ошиблись. Наша enterprise версия это не поддерживает. Но вот enterprise plus с платиновой поддержкой точно решит все проблемы. Но есть один нюянс. Версия enterprise plus может работать только на серверах собранных руками девственниц высоко в горах Тибета. В общем тех кто выбирает IBM никогда не увольняют. А зря.   

Тбилиси - Итоги

 

Вернувшись в Россию мне хотелось бы поделится некоторыми итогами - так сказать моими ощущениями по окончании этой поездки. Я посмотрел наверное все что в Тбилиси можно было посмотреть за неделю. Много гулял, общался с людьми. Страна бесспорно интересная, много чего красивого в ней есть посмотреть, вкусно поесть. Если бы я не знал ее заочно - она возможно поразила бы меня, как меня когда-то поразил Леван. Но по своей воле я бы туда не поехал. Даже в отпуск. Это был бы очень хороший вариант для короткого отпуска - каких-то три часа и ты на отдыхе. Но нет. Ответ довольно простой - я там не чувствовал себя в безопасности. Я не выгляжу как русский и свободно говорю по английски - так что пока я паспорт не достану - меня никто за русского не принимал. Скорее какой-то заплутавший казах или узбек. Но акцент есть и время от времени ты видишь пренебрежительный взгляды, сдачу иногда просто швыряют - типа не нужны там твои русские деньги. То что везде висят украинские флаги - ну и хер с ним. Каждый вешает тот флаг который желает. Это личное дело. Но есть рестораны где прям на столах лежат большие ламинированные объявления где объясняется что ты русский виноват и тебе тут не рады. Я практически уверен что если бы я в этом ресторане был без грузинских коллег - меня бы от туда выставили за дверь. Нет, я уверен что в 99% процентах случаев никто бы тебя не тронул. Но всегда есть шанс в 1% нарваться на какого-нибудь психа который заставит тебя извиняться за что-то. Тем более что вины своей я не чувствую и ни за что извиняться не собираюсь. Разок меня тут тормознула полиция, документы проверили про вещества спросили и увидели что я даже трезв и отпустили. Но общаться с полицией по доброй воле у меня никакого желания нет. Сомневаюсь что там мне кто-то помог бы. 

        Не смотря на все эти негативные моменты на грузин я никакого зла не держу. Они хорошие люди и очень близки нам по ментальности. Ну и не все так однозначно. Большая часть людей несмотря на жесткую промывку мозгов настроена нейтрально по отношению к русским. Это в первую очередь те у кого есть друзья/родственники в России. Ну и старшее поколение - люди кому сейчас 40+. Они еще помнят что раньше мы умели жить нормально. Все остальные - сдержано негативно. То есть как приличные и адекватные люди в морду бить без причины они не будут и даже ничего не скажут в слух. Но прошедшую войну и то что 20% территории проёбано никто не отменял. Только они винят во всем это Россию и Путина. Не они страну проебали, не их президент. А злой Пу, который помешал им устанавливать демократию в их мятежных провинциях. 

Дубайск

         В феврале побывал в Дубае или Дубайске как его иногда называют на русский лад. И не написал ничего. Наверное потому что он у меня не вызвал каких-то эмоций. Ну да небоскребы. Ну я как бы не из деревни приехал, видал я этого добра. И в Шанхае и в Сингапуре. 

Ну прикольно смотрится из далека. Ничего не скажу.

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

Вот как выглядит типичная прогулка по Дубаю - идешь вдоль автобана:

Что и говорить - приятного не много. К берегу моря ты не подойдешь. Публичных пляжей в Дубайске нет. Все застроено коммерческими объектами. Как правило разной степени закрытости клубы или апартаменты:

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

Тбилиси

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

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

Про кухню ничего говорить не буду - тут много сказано до меня и никаких сюрпризов не было. В Москве грузинская кухня точно такая же. Ради хачапури сюда ехать не стоит. 

Из особенностей - что бросилось в глаза. Очень много названий с префиксом - Евро/Western. Ну разве что евро хинкалей нет. Все остальное евро-есть. У нас как-то поостыли к этому чтоли. Я бы даже сказал что в России приставка евро - больше означает что-то дешево-пластиковое, купленое в Леруа мерлен по скидке. А тут наоборот - евро - прям топ название. Копирование западного иногда доходит до абсурда. Вот например Lucky Shaurma

Типо если поверзло - поел, не повезло - траванулся. 

Ну и видно что город развивается. Вот к примеру биткоин киоск:

На заднем плане самокат от местного кикшеринга. В общем прогресс на лицо.

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