Как ФРАНЦИЯ ВЛЮБИЛА мир в АВТОМОБИЛИ

        В свободное от работы/технологий время я люблю почитать или посмотреть что-нибудь на отвлеченные темы. Что-нибудь не напрягающее мозг, не требующее вдумчивого изучения, и в тоже время не пресное. А интересно-информативное. Из последнего что мне понравилось - Как ФРАНЦИЯ ВЛЮБИЛА мир в АВТОМОБИЛИ от Стаса Асафьева:

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

     До этого у него же выходили фильмы про автомобилестроение США, Японии и Германии - https://www.youtube.com/watch?v=04ZjgbMTolc&list=PLybBpPCOgFt4IANUx-EvScY8W9mbGpGYo 

Немного юмора

        Вчера младший сын(6 лет), собираясь на очередное занятие на которое он не хотел идти в сердцах сказал: 

  - У меня собачья жизнь! Я Живу как собака!

На что старший(8 лет) ему ответил: 

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

 В общем утешил так утешил.

Ошибка, которую я совершил дважды

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

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

net::ERR_INCOMPLETE_CHUNKED_ENCODING & PMM (Percona MySQL Monitoring and Management)

            Спустя 3 месяца безоблачной работы Percona MySQL Monitoring and Management (PMM) начал хандрить: Graphana перестала открываться, говорит что  что-то не догрузилось. В Chrome Dev Tools видно что это действительно так - несколько запросов к JS файлам окончились с net::ERR_INCOMPLETE_CHUNKED_ENCODING.
          Вылечил вот так: 

• Заходим в докер контейнер PMM: docker exec -it <PMM container id> /bin/bash
• Перезапускаем графану: supervisorctl restart grafana
• Перезапускаем Nginx: supervisorctl restart nginx
• Вуаля! и все заработало. 

Безопасности пост... или безисходности

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

           История номер 1: Жила была форма загрузки документов, где-то в жопе админки. Написана хер знает когда и хер знает кем. Она была защищена паролем. Но потом добавили модный self-onboarding, и любой хмырь теперь может создать аккаунт и получить доступ к админке. Но ее конечно никто на уязвимости не проверял. Ей же только "свои" пользуются. Выяснилось что если через эту форму загрузить файл image.jpg.php то форма считает его картинкой, а веб сервер - выполняемым PHP файлом. А потом ты просто загружаешь вместо документа файл с одной единственной строчкой: <?=`$_POST[1]`?> И вуаля - remote code execution и сервер у тебя в кармане. Можешь делать с ним все что хочешь

            История номер 2: мало кто знает/помнит, но у FPM протокола нет авторизации.  И если вы ненароком написали в конфиге PHP-FPM listen=0.0.0.0:9000 или просто listen=9000 то это равнозначно: 

  Так как никакой авторизации нет, ничего не мешает сделать запрос к примеру к /usr/local/lib/php/PEAR.php.  PHP-FPM ничего не знает про root directory. Все эти ограничения проверяются на уровне веб сервера(Nginx). А если ты эту проверку обходишь - ты можешь делать все что тебе заблагорассудится. Доступ к PEAR - это полноценный remote code execution. Только shell за тебя заботливо предустановлена системным администратором. 

          Но мы то думаем что мы все умные, и не будем php-fpm вешать на внешний порт. Мы будем unix socket использовать. Ну или 127.0.0.1 на крайний случай. Но тут на помощь нам приходит Мистер Докер! 

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

Мораль сей басни такова: 

• Держи все сервера за высоким забором/VPN. Иначе хер уследишь
• Проверяй что тебе загружают. Даже если форма доступна только для "своих"
• Держи то что загружено - на отдельном домене, где нет никакого выполнения PHP кода. Пусть на этом домене все отдается как статика. Это и для производительности не плохо, и для безопасности. В таком случае даже если к тебе загрузят гавно - они смогут его только обратно скачать и ничего более

Ошибки которые мы обожаем повторять - API для мобильных приложений

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

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

            А бэкэнд разаработчики не понимают специфики мобильного приложения - то что зарелизив/опубликовав его однажды - ты уже никак не сможешь его изменить. Ты не можешь "закатить" его назад.  Эта операция, довольно привычная для бэкэнд разработчика, совершенно не возможна в мире мобильной разработки. И отсутсвие этого понимания часто порождает проблемы. Итак перейдем к практической части: о чем необходимо подумать заранее чтобы потом не было мучительно больно? 

Как мы будем обновлять приложение ? 

         Предположим что мы накосячили в релизе и что-то пошло не так. Как мы можем заставить пользователя обновить его приложение (чтобы перейти на новый билд) без ошибки. Здесь как всегда два решения - очевидное и правильное. 

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

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

Как мы будем обновлять API приложения?  

Ответ на этот вопрос немного проще - всегда нужно использовать версионирование  хэндлеров мобильного АПИ. Самый простой способ - всегда включать версию  хэндлера в request path. То есть request path должен быть не просто /handler-name/, а либо /v1/handler-name/ либо /handler-name/v1/  Это требование должно быть обязательным вообще для всех API, не только для мобильного API. Но как правило это понимают только те кто ввязался по полной в SOA архитектуру.  В более простых проектах об этом как правило не задумываются.        

А что если данными сессии беда ?

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

Более практичным будет предусмотреть еще одну стандартную ошибку, которую может вернуть любой хэндлер мобильного API: Please login again. То есть если мы сбросили пользователю пароль(иногда такое приходится делать) - мы можем в ответ на любой запрос к API ответить - "пожалуйста авторизуйся еще раз" и проблема решена. Либо если нужно обновить данные которые загружаются один раз при входе в мобильное приложение - мы всегда можем вернуть данный код ошибки и пользователь зайдет в мобильное приложение еще раз.

Про безопасность

Не надо надеятся что запросы мобильного приложения никто не видит. С помощью Burp Suite их можно очень легко посмотреть. И рано или поздно найдется тот кто захочет посмотреть запросы/ответы. И если там вместо сессионного токена будет что-то типа  customer_id=121212, то рано или поздно это всплывет наружу. Не надейтесь на авось - сразу используйте что-то вроде JWT token

Ну и напоследок

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

Рецепт самого тупого отдыха

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

11/11 2020

        Последние 2 года 11/11 обходил меня стороной. И я скучал по нему. Не с точки зрения шопинга. Сам я не шопоголик ни разу. А больше с точки зрения эмоций, драйва. Эти ощущения когда время за полночь а графики нагрузки бьют все рекорды и ты сидишь и думаешь - выдержит или не выдержит ? Где на этот раз порвется ? Где мы облажаемся ? 

           В общем таких эмоций у меня не было со времен Лазады. Но в этом году наконец-то я снова в строю. Первый 11/11 с новой командой успешной пройден. Сделали за сутки 9x от дневной нормы. И в 3 раза больше чем на 10/10 месяцем ранее. В общем я разваливаюсь от усталости но я счастлив. 

#крымнаш, послесловие

        Вот уже неделю как мы вернулись из Крыма. Когда ты приезжаешь из солнечных +27(а столько было когда мы уезжали)

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

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

        Приехал бы я в Крым еще раз ? Возможно да. Возможно я бы захотел посмотреть оставшиеся места, ибо 1 неделя для Крыма - это не о чем. Очень много всего осталось не увиденного. Но не обещаю. Рекомендовал бы я съездить в Крым ? Один раз однозначно. Но не за пляжным отдыхом - он тут ни о чем. А за достопримечательностями. Одни дворцы чего стоят. Хотя в семье не без урода: Юсуповский дворец закрыт, дворец Дюльбер - это просто действующий санаторий. Делать там нечего. До Ласточкиного гнезда мы так и не смогли проехать - там где Яндекс проложил дорогу стоял закрытый шлагбаум.

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

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

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

#крымнаш, Севастополь - я люблю тебя!

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

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

В общем за тот день что мы там провели, мы посмотрели примерно половину того что планировали. Так что еще разок точно надо туда съездить. 

        Отдельно скажу про дорогу Ялта-Севастополь. Она проложена очень живописно, по пути есть много смотровых площадок (но нужно ехать в обратном направлении - Севастополь-Ялта, иначе будет очень неудобно останавливаться на смотровых площадках).

#крымнаш, часть 3

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

В моем личном рейтинге на первом месте конечно Ливадийский дворец:

На втором месте - дворец Воронцова:

Ну и на третьем - дворец в Массандре. Не потому что он самый плохой. Просто первые два просто шикарны. 

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

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

Крымское вино

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

Оказалось что Inkerman делает прям отличное вино.  Могу смело порекомендовать этот мускат.

Далее идет бутылка самого знаменитого винзавода в Крыму - Массандра.

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

Он тоже оказался очень не плохим. Уже в ходе написания поста я узнал что Валерий Захарьин оказывается купил завод Инкерман - https://www.vedomosti.ru/business/characters/2019/10/06/812952-vinodel-valerii-zaharin Рекомендую почитать его интервью. Мужик просто молодец. Если будет больше таких людей то Крымское вино  у меня перестанет ассоциироваться с бормотухой за 300 рублей.  Я купил уже 3 ящика всякого, разного. Так что продолжение следует, так сказать :-) 

#крымнаш продолжение

       Итак, продолжаю писать про свои впечатления от посещения Крыма.

• Пляжи - как на лазурном побережье. И это не комплимент. Эта сраная галька. Я не отношу себя к йогам и любителям ходить по горячим камням. Так что это прям жирный минус в карму Крыма. 
• Отельная инфраструктура - тут все на мой взгляд не очень здорово. Есть пару отелей высшей ценовой категории. Про них я к сожалению ничего сказать не могу - ибо 650 тысяч за отдых в Крыму платить не готов (столько стоило проживание в отеле Villa Elena на мои даты), есть мелкие отельчики/комнаты в частных домах - очень бюджетненько и трэшово. А вот если хочется классического пляжного отдыха по турецкой схеме - вариант только один - Ялта Интурист. Больше насколько я знаю подобных отелей в Крыму нет. А ведь это самый популярный отдых у наших соотечественников.
•  Мне хотелось бы какой-то вариант по середине - комфортное проживание за вменяемые деньги. Ничего из отелей не выбрал,  выбрал апартаменты в комплексе бизнес класса в 20 метрах от моря. Внутри квартиры все отлично - деревянный паркет, диваны из белой кожи, мебель из массива, оригинальные картины на стенах. Короче человек который эту квартиру обставлял - явно это делал для себя и в средствах не нуждался. Как выяснилось потом - он работает в Нафтогазе не последним человеком. Да и саму землю под строительство комплекса походу отцапали у находящегося неподалеку ботанического сада. В общем место шикарное, собственный причал для яхт, СПА-центр. Весь проход к морю походу раньше был огороженным. Забор там и сейчас стоит, но калитка открыта. И зевающий охранник провожает прохожих скучающим взглядом. В общем я так и не понял что он там и от кого охраняет. В общем году в 2008 когда это все построили - я уверен это было топовое место. Сейчас все ржавеет, зарастает паутиной, краска облупливается, плитка разваливается. В общем лифты, лестницы, коридоры - находятся в плачевном состоянии. В доме куча квартир выставлено на продажу, но по довольно конским ценам. В общем видно что старая Крымская элита сюда приезжать уже не хочет, ибо негоже работникам Нафтогаза во вражеский Крым ездить, а новая крымская элита еще не понаехала. Поэтому на обслуживание комплекса положили жирный болт. 
• Про людей. Обычные люди с улицы производят очень хорошее впечатление, доброжелательны, все подскажут. На дорогах в основном вежливо ездят. Но те кто работают в турбизнесе - те еще мрази. Мой личный рейтинг возглавляют парковщики. Те что оккупировали места около всех туристических достопримечательностей и предлагают оплатить 300рублей за парковку. А в противном случае угражают что-то сделать машине. Одну с проткнутым колесом я видел на площади около Воронцовского замка. Ялтинская набережная полна мудаков которые разводят на фотки, тоже 300 рублей просят. Люди которые сдают жилье бесят своей показной радушностью.  Ну не то чтобы это плохо - я не ожидал что меня тут будут в десна целовать. Просто не терплю в людях фальши. В других странах я уверен все также, но толи они показушничать умеют лучше, толи я за счет разницы в культуре и плохого понимания языка этой фальши не улавливаю.

#Крымнаш или мои первые впечатления

            Вот уже 3 дня как я коротаю ковидные выходные в Крыму, хотелось бы поделится первыми впечатлениями.  Сразу оговорюсь, что они упорядочены в хронологическом порядке (по мере их получения) а не по важности или еще чему-то. 

• Собственно первое впечатление - это крымский мост и дороги к нему. Мост просто бомба - по своей продуманности, технологичности и качеству исполнения. Трасса Керчь -Симферополь - образец того какими должны быть дороги. Это тот случай когда дорогу классную сделали а камеры поставить забыли. По ней можно спокойно ездить 160-180 без риска для жизни. И она бесплатная! Об этом правда напоминает только ограничение в 90км/ч - стандартное для бесплатных дорог. Но как я уже говорил камер нет - поэтому насрать. 
• Со стороны материковой России дороги гораздо худшего качества. Единственное исключение наверное это новый участок трассы М4 между Воронежем и Ростовом-на-Дону - это прям километров 150 идеально ровной и освещенной дороги. На ней можно дать волю всем лошадкам которые обычно топчутся под капотом в московских пробках. Особенно все плохо с дорогами на Таманском полуострове и Краснодарском крае. Как только съезжаешь с М4 в сторону Крымского моста начинается жопа.  Там были только дороги районного значения, соединяющие между собой райцентры и станицы. И проходящие по середине станиц. Как построили Крымский мост - весь траффик хлынул через эти села, они все там буквально задыхаются от трафика. Ведь раньше Таманский полуостров был транспортным тупиком. 
• В октябре в Крыму градусов на 5 теплее чем в Краснодарском крае, на Таманском полуострове. Там было примерно +20, в Крыму  +25.
• Доехав до Симферополя ты понимаешь какие раньше были дороги в Крыму(до Путина) - они реально были убитые. И сейчас там не сильно что изменилось.
• Езда по серпантинам - это то еще развлечение. Тормоза кипят, расход топлива сильно вырос.
• Яндекс навигатор очень плохо работает в Крыму. Он несколько раз заводил нас на очень узенькие петляющие дорожки, которые явно не предназначены для сквозного проезда по ним.  Во неторых местах ты едешь между зданиями и между машиной и стенами останется по 10-20см пространства. Даже челок и машина не могут разойтись на этих дорожках. Это все усугубляется большими перепадами высот и резкими поворотами. В общем езда по склонам Ялты и Гурзуф-а - это испытание не из легких.
• Набережная Ялты - это нечто особое. От нее веет атмосферой советских времен. Ты вспоминаешь сцены из советских фильмов и ты прям чувствуешь - вот оно самое. Идеальный отдых советского человека.
• Карточки принимают почти везде. Единственное - ApplePay/Google Pay/ Samsung Pay - не работают. Нужно иметь физическую карту при себе.
• Сервис: До приезда в Крым нас многие пугали рассказами об ужасном сервисе. Тут по моему опыту многое зависит от ценового сегмента. Если ты хорошо платишь - то и сервис получаешь нормальный. Если ты берешь самое дешманское предложение а сервис ожидаешь как в Турции - ну ты сам себе злобный буратино. Нельзя получить европейский сервис по советским ценам. Конечно есть колоритные чуваки который зычным голосом ведьмака кричат Жиииилье!!!  Но снимать жилье у них или в нормальном отеле - это ваш выбор.
• 
  

Грусти пост

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

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

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

Про уровень сервиса

          Интересное открытие сделал для себя. Оказывается у официалов BMW просто отвратный сервис.  До этого я 7 лет ездил на Hyndai. Могу честно сказать - сервис там на порядок лучше. Может потому что они работают в высоко-конкурентном сегменте, где полно альтернатив и с них 3 шкуры дерут за каждого потерянного клиента. Но официалы BMW они в конец охеревшие. Уровень сервиса - как в сельском магазине. Официалы реально думают что владельцы BMW - никуда не денуться, что у них нет альтернативы и они все равно купят новый BMW. А я почему-то на 90% уверен что мой следующий автомобиль будет другой марки.  Сроки поставок запчастей - конские. Сроки ремонта постоянно переносяться. Горите в аду, друзья мои.

Богородица. Земной путь (2017) Документальный фильм

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

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

 

Мелочь, а приятно

      Давным давно я писал генератор swagger спецификации по аннотациям - https://github.com/yvasiyarov/swagger. То есть ты пишешь API, а перед хендлером в комментарии пишешь аннотацию этого метода. Потом вызываешь генератор и он автоматом генерирует swagger спецификацию API и поднимает рядом веб клиента. 

                   Потом я его забросил, так как появились более продвинутые реализации. И тут недавно мне снова понадобился swagger генератор и я начал смотреть что же есть из актуального. Самым продвинутым на текущий момент является https://github.com/go-swagger/go-swagger. Каково же было мое удивление когда в его документации я обнаружил: 

      

The toolkit has a command that will let you generate a swagger spec document from your code. The command integrates with go doc comments, and makes use of structs when it needs to know of types.

Based on the work from https://github.com/yvasiyarov/swagger.

В общем мелочь, но приятно когда не забывают сказать спасибо :-)

https://regex101.com/

      Хочется сказать огромное спасибо ребятам которые сделали https://regex101.com/. Я думаю трудно даже представить сколько труда было вбухано в создание этого инструмента. Но получился реально классный инструмент для отладки регулярок. Он мне тонну времени с экономил. 

PHP: Асинхронность и производительность

     Никогда не думал что буду когда-нибудь снова писать про PHP. Но Жизнь напоминает что никогда нельзя говорить никогда. Итак: последния веяния программистской моды докатились с 5-ти летним опозданием до PHP. Лучше поздно чем никогда, заметит PHP программист и с этим трудно не согласится. 

      Если погуглить "promises in php" то реализация https://github.com/guzzle/promises окажется на 3-ем месте по популярности. Ничего удивительного что одноименный HTTP клиент вызывает у php-коммьюнити дикий восторг. Асинхронный, на промисах... и похеру что внутри сидит все тот же curl_multi_exec(если быть совсем честным не только он. есть еще варианты fall-back-а в случае недоступности curl).  В общем с точки зрения архитектуры GuzzleHTTP и в правду не плох. Но вот производительность он убивает напрочь. Я заменил в одном из нагруженных хенджлеров GuzzleHTTP на примитивный синхронный HTTP клиент(тоже curl based) и получил прирост примерно в 2 раза меньшее время ответа. Реально вместо 1000-1200ms стало 500-600ms. Отсюда вывод - не надо усложнять. Если вам нужно сделать всего 1-2 HTTP запроса - вам не нужна асинхронность, промисы и прочие красивые штуки. И если вам важно время ответа - то асинхронность вам скорее всего тоже не нужна. Асинхронность - это оптимизация пропускной способности, возможность одновременно сделать 20 запросов. А если вам нужно только 2 - сделайте их последовательно и будет сильно быстрее(как это не парадоксально).

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

Философии пост

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

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

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

Теперь еще и немного IOS разработчик

        Я не люблю зависеть от других людей, особенно в плане понимания/реализации своих идей. Мне проще самому залесть в код, почитать его и понять что происходит в системе и принять решение о том что и как нужно делать. А иногда и закодить все самому. Примерно так я стал немного IOS разработчиком. 

          Что хочется сказать - после простоты Golang конечно чувствуется перегруженность Swift. Огромное количество синтаксических конструкций, огромное количество правил их применения. Такое ощущение что хотели всем угодить, чтобы у всех все было. В общем я считаю что надо стараться упрощать вещи, а не усложнять их. Также бросается в глаза что многое похоже на Rust. Не знаю кто там на кого влиял, но определенная степень влияния имеет место быть.

           

Vector и Rust

      В последнее время к сожалению не так много нового удается узнать, из того что бы зацепило.  Все основном приходиться get shit done заниматься, не вдаваясь в подробности. Но недавно наткнулся на коллектор логов под названием Vector (vector.dev). Запустил в проде, посмотрел сколько он памяти/cpu ест и удивился. Там что-то вроде 60mb всего. Решил заглянуть внутрь - а там Rust. Тут то я и проникся к нему уважением. Ибо при такой нагрузке то же самое на Golang кушало бы заметно больше ресурсов. Тоже filebeat написаный на Golang - оказалось тем еще говном, слабо пригодным к использованию в нагруженном проде. В ozon его переписали и заменили своей поделкой, которую к сожалению никто не торопиться выкладывать в open source. 

           Дальше я принялся разглядывать Rust. Его девиз - zero cost abstraction. Где-то я уже видел подумал я. А точно, то же самое старина Bjarne Stroustrup вещал:

Только ему приходится поддерживать совместимость с миллиардами строк плюсового кода написанного за последние 30 лет. А у создателей Rust такой цели нет. И надо сказать - у них пока очень не плохо получается. Я не знаю насколько прокачен компилятор Rust в плане оптимизации, но теоретически то что получается на выходе должно быть то же самое как если бы это написать на плюсах с использованием умных указателей, контейнеров и прочих конструкций без которых современный плюсовый код не мыслим.

Node.js event loop monitoring

       Практически в каждой статье по  Node.js и о том как правильно разрабатывать бэкэнд на JavaScript есть пространные рекомендации на тему event loop. О том что не надо занимать event loop на долго иначе другие запросы не будут обрабатываться и прочие прелести однопоточного программирования. Но при этом нигде не сказано как именно мониторить выполнение этих рекомендаций.  Даже такие простые вещи как event loop delay зачастую измерялись не правильно.  За примерами далеко ходить не надо. В prom-client - официальной библиотеки для мониторинга node.js приложений через prometheus event loop delay мониторился через вызов setImmediate() несколько раз в минуту.  

       Очевидно что event loop delay это характеристика которая меняется гораздо чаще. Мерить ее несколько раз в минуту это все равно что вычислять среднегодовую температуру по 3 измерениям в году. В общем эта метрика показывала только самые грубые задержки, и была в общем бестолкова. 

       На самом деле в недрах perf_hooks была спрятана возможность для гораздо более точного измерения event loop delay - perf_hooks.monitorEventLoopDelay() Через эту функцию можно запустить измерение event loop delay на уровне libuv, и делать это не раз в сколько-то времени а на каждом обороте event_loop. Собранные данные кладутся в гистограмму, поэтому можно увидеть не только мгновенное значение, которое большой ценности не представляет, но и min/max + перцентили. 

        Сегодня мой очередной пул реквест ждавший своего часа долгие пол года слили в мастер - https://github.com/siimon/prom-client/pull/278 Так что скоро эти метрики будут доступны всем.  Для более полного понимания того как работает event loop и какие функции на каком этапе event loop вызываются я всячески рекомендую прочитать документацию libuv - https://github.com/libuv/libuv/blob/v1.x/docs/src/design.rst На мой взгляд она сильно более толковая чем официальная документация Node.js - https://nodejs.org/uk/docs/guides/event-loop-timers-and-nexttick/

Hierbas de Mallorca

        Я, как наверное и многие другие, люблю во время поездок накупить всякой дичи, и потом по приезду пробовать. Как правило добрая половина всего этого добра потом отправляется в утиль. Но иногда бывают исключения. На этот раз меня приятно удивил Hierbas de Mallorca: 

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

Мониторинг GC(Garbage Collector) в Node.js без использования нативных модулей

       С пол года назад я послал в официальный prometheus клиент для Node.js pull request с реализацией мониторинга GC Node.js без использования нативных моделей. В  Node.js начиная с восьмой версии есть интерфейс perf_hooks который позволяет немного заглянуть под копот V8 и установить обработчик на некоторые события. Одно из этих событий - запуск сборщика мусора. Собственно подписавшись на него мне удалось собрать эту статистику и экспортировать ее в прометей в виде гистограммы https://github.com/siimon/prom-client/pull/274 

       Сегодня, спустя примерно полгода мне удалось пропихнуть его в мастер.

Как Тиньков построил банк

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

• Плоская управленческая структура, минимум иерархии и бюрократии
• Банк много раз эволюционировал. От первоначального замысла в виде «почтового банка» рассылающего карточки почтой России к «интернет банку», привлекающему клиентов через онлайн. А затем превратился в «финансовый супермаркет» или как это сейчас можно называть «супер приложение»
• Всю критически важную экспертизу имеют внутри. Не пользуются услугами рекламных агентств, а сами закупают трафик у площадок и сами оценивают его эффективность. Не пользуются аутсорс разработкой, а развивают собственную ИТ команду. Предпочитают использовать собственные ИТ решения, а не покупать коробочные продукты за много миллионов долларов
• Любой рекламный канал рано или поздно умрет. Постоянно ищут новые рекламные каналы. Важным является не знание где сейчас дешевле трафик, а умение находить новые каналы и умение находить новые способы работы с рекламными каналами
• Надо освежить в памяти темы:
• Наивный байесовский классификатор
• логическая регрессия
• композиции деревьев
• gradient boosting
• кластеризация - EM алгоритм
• обучение с подкреплением
• Принципы ведения бизнеса
• Нетолерантность к убыткам. В бизнес плане должен быть определён момент выхода в 0, и это должно быть не через 5 лет
• Стабильность команды.
• Личные качества первичны. В меньшей степени смотрит на профессиональные качества а в большей на человеческие/личностные
• Параноидальность. Даже если ты достиг больших высот, не думать что ты уже всего достиг а ещё выше задирать себе планку. Стремление к перфекционизму. Не любит хвалить сотрудников.
• Вовлечённость основателя решает
• Горизонт планирования. Нужно думать хотябы на 5 лет вперёд
• Прочитать - Питер Тиль, от нуля к единице
• Обслуживание это всегда расходы. Сократить их - нормальное желание любого менеджера. Но важно почувствовать ту грань когда сокращение расходов ведёт к ухудшению качества обслуживания
• 15% чатов обрабатывается чат ботом. У ozon.travel около 0.5-1%
• 70% звонков обрабатываются на WebOffice - веб версии консоли колл центра, в которой работают сотрудники работающие из дома
• Переход к модели маркетплейса, заработок на комиссиях минимум 50% прибыли 
• Идея состоит в том что в любом бизнесе самая дорогая операция - привлечение клиентов. В cost per order расходы на маркетинг всегда самые большие(одни из самых больших). Причём с увеличением объёма продаж эти расходы даже в расчете на заказ как правило увеличиваются(исчерпание источника трафика). Соответсвенно если у тебя есть один продукт(банковский) и ты уже один раз заплатил за привлечение пользователя, ты также можешь продать ему что-то ещё и в этом случае стоимость превлечения пользователя в этом заказе будет 0. На этом и основана идея маркетплейса - положить рядом как можно больше продуктов которые могут быть интересны для клиентов банка, продавать им эти продукты и брать комиссию 
• Нельзя доверять стартапам/компаниям в которых основатель/CEO сам не вложился в бизнес значительной частью своего состояния. Если ты сам вложишься своими кровными деньгами в бизнес которым управляешь - то ты совершенно по другому будешь относится к деньгам компании, совершенно по другому будешь работать на компанию (ты будешь бояться потерять свои деньги вложенные туда). И никакие опционы на 0,01% акций такого чувства ответсвенности не дадут 

Особенно меня зацепил конец книги - про "стартаперов" и отношение к деньгам. Это правда на 200%. Почему тот же Wildberries гораздо успешнее Озона ? потому что Wildberries строит основатели, люди который там все сделали за свои деньги, и поэтому там мотивация совсем другая, она на 2 порядка выше чем у наемного менеджера, владеющего 0.01% акций. Основатель вкладывает душу в свое детище, а CEO каждые 3-5 лет меняется. По большому счету наемному менеджеру хочется продержаться у руля по больше, чтобы побольше акций завестилось, и побольше позолотить себе парашут перед уходом. Можно сколько угодно говорить про мотивацию, стремление к успеху и тд - но KPI собственного обогащения - это единственное что заложена нам подкорку, то о чем мы думаем в первую очередь. Все остальные мотиваторы стоят на ступеньку ниже.

ARC - Adaptive Replacement Cache / ZFS

          Одним из самых известных отличительных качеств ZFS является ARC кэш(Adaptive Replacement Cache). В теории он обеспечивает примерно в 2 раза более высокий cache hit rate по сравнению с классическим LRU.  Алгоритм ARC был предложен  Nimrod Megiddo and Dharmendra S. Modha и описан в следующем whitepaper - https://www.usenix.org/legacy/events/fast03/tech/full_papers/megiddo/megiddo.pdf 

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

           Реальная реализация которая находится в module/zfs/arc.c немного сложнее теоретической: 

• Она работает с блоками разного размера
• Она адаптируется к memory pressure. Если памяти не хватает размер обоих списков снижается
• Не все страницы могут быть вытеснены в каждый момент времени. Если есть внешние ссылки на страницу, она не может быть вытеснена.

Реализация AVL дерева в Solaris/ZFS

          Меня всегда интересовали реализации структура данных на практике. Возьмем к примеру AVL-tree. С точки зрения теории все довольно понятно - сбалансированное двоичное дерево, поиск за log n, вставка от константы до log n. Но кроме O(n) есть еще реальное время выполнения операций, и при не слишком большом N это время гораздо важнее чем теоретические выкладки. Да, если N - очень большое то O(n) решает, но в реальной жизни случаи с очень большими N не так часто встречаются. Поэтому практические приемы используемые при реализации той или иной структуры данных не менее важны чем сам алгоритм. Собственно, в чем особенности реализации AVL дерева в Solaris/ZFS ?

1. Написано на голом C, без классов (как и все то что должно работать в ядре)
2. Не полезная нагрузка "вставляется" в узлы дерева, а наоборот - структуры данных необходимые для реализации дерева внедряются в те объекты которые планируется класть в дерево. Если быть точным - это даже не объекты а структуры (в терминах C). В результате - и payload и сами структуры данных дерева образуют единых блок данных. В результате резко повышается memory cache locality, в два раза снижается фрагментация данных (в классической реализации узел дерева это одна структура данных, в ней сидит указатель на собственно payload)
3. Рекурсия не используется, только итерации. Для этого каждый узел дерева содержит указатель на родительский узел. Даже на C рекурсия медленнее чем цикл. Другая причина - этот код должен работать в ядре, где размер стэка не большой.
4. Реализация не содержит блокировок - предполагается что тот кто использует структуру данных сам знает - нужно ли синхронизировать доступ к ней и если это необходимо - взял нужную блокировку
5. Реализация не содержит выделений памяти. Все функции принимают на вход указатели на предварительно выделенные блоки памяти там где это необходимо. За счет этого достигается:
1. Предсказуемость времени выполнения того или иного вызова. Выделение памяти это довольно рискованная в парадигме kernel-программирования операция которая может занять непредсказуемое время и завершиться непредвиденным результатом
2. Абстрагирование  структуры данных от используемых механизмов выделения памяти.
6.  Используются разные структуры данных на 32 и 64 битных платформах. Вся работа с структурами данных ведется через макросы. На 64-битной платформе флаги и другие мелкие значения упаковываются в младшие биты указателей. На 64-битной платформе младшие биты указателей всегда равны нулю. 
7. Данные которые используются в наиболее часто вызываемых функциях, например avl_find() располагают в первых 64 битах структуры данных. Таким образом гораздо выше вероятность того что эти данные уже находятся в кэше процессора
8. Вместо обычных конструкций ветвления if (больше) then {right} else {left} при обходе дерева используется node = node->child[compare(value, data)]. Почему так ? потому что branch prediction процессора обрабатывает if then конструкции хорошо только тогда когда вероятность переходя по одной из ветвей сильно выше, например при обработке ошибок. В случае прохода по дереву вероятность  пойти по левой и правой ветки примерно одинакова, что будет приводить к miss-prediction и сбросу конвеера процессора. Конвеер современных CPU очень глубокий, поэтому сброс конвеера - это довольно затратная операция. Поэтому вместо этого указатели на левый и правый child помести в массив, и результат сравнения искомого значения с тем что хранится в текущей ноде используется как индекс для получения указателя на следующий элемент дерева. В исходном кода мне кажется это будет понятнее - https://github.com/zfsonlinux/zfs/blob/2476f103069e83e17d2c9cec4191af34a7996885/module/avl/avl.c#L256 

          

Real User Monitoring по взрослому

            Real User Monitoring (RUM) это с первого взгляда довольно простая фигня которую можно чуть ли не за пол дня на коленке запилить. Но если копнуть глубже то понимаешь что большинство реализаций довольно ущербные - те же самые RUM от NewRelic или RUM от Pingdom. Не говоря уже про написанные на коленке варианты.

               Из того что заслуживает внимание - Doppler от Facebook Ребята добавляют в каждый N-й ответ кусок JS-а который выполняет загрузку небольшой картинки с рандомного домена - например  xmdmddddm.dns.facebook.com, тем самым проверяя пессимистичный сценарий полный DNS lookup + HTTP запрос + ответ. Потом загружают еще одну маленькую картинку с того же домена.  Вычтем результат второго эксперимента из первого и получим пессимистичное время DNS lookup.  Второе время - минимальное время загрузки ресурса с сайта FB.  Они также записывают каждый проведенный эксперимент и далее аггрегируют эти  данные по AS-number. Количество автономных систем относительно невелико (около 35к), так что в таком виде данные уже гораздо легче анализировать. 

              Но ребята из dropbox пошли дальше  - https://blogs.dropbox.com/tech/2020/01/intelligent-dns-based-load-balancing-at-dropbox/ . Они сделали свой аналог doppler, с аггрегировали полученные данные  и из них сделали latency-map интернета. Скормили этот map DNS серверам (они используют ns1.com) и используют для latency based балансировки траффика между своими датацентрами. В общем получилась конфетка. 

ZFS monitoring - V2

         Добил наконец-то вторую версию мониторинга ZFS. В ней добавлены метрики получаемые через zpool iostat.   Так как мой первый пул реквест в телеграф до сих пор ждет своего счастливого часа - https://github.com/influxdata/telegraf/pull/6724, этот код пока живет в отдельной ветке - https://github.com/yvasiyarov/telegraf/tree/zfs_zpool_linux2 Все новые метрики также появились в dashboard -  https://github.com/yvasiyarov/zfs-dashboard Теперь он так порядочно распух:

Из интересно-прочитанного

       Довольно интересная статья про монорепу в Яндексе - Arc — система контроля версий для монорепозитория. Доклад Яндекса. Прочитав статью понимаешь что никакая это не система контроля версий - это проложение которое работает поверх SVN и по сути занимается его масштабированием.  Вся монорепа по прежнему лежит в SVN, который обеспечивает единственную операцию - commit в trunk. На Arc лежит масштабирование клиентских операций - их фактически перенесли на сервер, работа с pull реквестами и тд. Пул реквестов в оригинальном SVN нет, но ребятам очень хотелось их. Вот они и навертели их поверх SVN. Но если серьезно - мне нравится их подход к решению проблемы. Он проблемно-ориентированный. Они не сказали - надо все выкинуть к херам и два года пилить свою собственную систему управления исходным кодом, а взяли и решили конкретные проблемы с которыми они сталкивались с минимальным риском для компании. Ведь по сути максимум чем они рискуют - это коммитами в рабочих ветках. А эти данные полюбому сохраняются минимум еще в одном месте - на машине разработчика. Как только ветка вливается в монорепу - за ее сохранность отвечает SVN.

      Прочитал перевод интересной статьи про использование unsafe.Pointer и то какие при этом могут возникать проблемы - https://4gophers.ru/articles/unsafe/#.XhcssCq3p26