Diary of a Madman
53 subscribers
73 photos
2 videos
114 links
Антон Рябов: doam.ru
Бот для обратной связи: @doam_ru_feedback_bot

Disclaimer: I do not speak on behalf of my employer.
Download Telegram
#spam #nl Открыли купальный сезон

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

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

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

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

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

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

В большинстве случаев есть ограничения, типа скидка €5 при покупке от €30. Нам ничего из этого не нужно, лишний мусор.
#spam #nl В Нидерландах любят 3D печать

На днях в Амстердаме поставили стальной мост, напечатанный на 3D принтере. Проект предложили еще в 2015, а "печать" начали в 2017. После нескольких тестов мост наконец поставили в городе.

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

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

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

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

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

В любом случае, мне нравится наблюдать за прогрессом 3D печати, а вам? Хотели бы иметь в городе подобную инфраструктуру?
#blog

Нанес заведения из рейтинга топ 50 пиццерий Европы 2021 на карту - https://doam.ru/50_top_pizza_map_2021/.

Короткая ссылка, сразу на карту: https://doam.ru/50toppizzamap2021
#DevopsTuesday

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

Основной посыл контейнеров в контексте CI/CD пайплайнов, что контейнер, собранный на рабочей машине разработчика можно легко взять и запустить в окружении, неважно тестовом или проде. Но сколько команд, которые реально так делают?

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

И в этом то и есть обман. Контейнер или в терминах CI/CD - артефакт, собранный на локальной машине и на build сервере, даже из одного и тоже Dockerfile не являются полностью идентичными.

Сам факт того, что рабочая машина может быть на любой популярной ОС Windows/MacOS/Linux, а build сервер скорее всего только на Linux, уже должен наводить на мысли. Более того, я видел когда в Dockerfile есть условия и переменные, в зависимости от того где его собирают.

Я вижу два выхода из этой ситуации:

1. Сборка и, возможно, интеграция, должны проходить на машине инженера и именно этот артефакт должен отправляться по окружениям дальше. Я, кстати, задумывался над таким еще несколько лет назад и смотрел способы прогона Jenkinsfile локально.
2. Рабочая машина инженера вообще не должна участвовать в процессе сборки, а использоваться как тонкий клиент для доступа к редактированию кода. С учетом прогресса Cloud9 и VS Code, и интеграцией последнего в Github это вполне реалистично. CI при этом всегда и полностью будет на build сервере.
#health Про подтягивания

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

Парни подтягивались в лесенку: сначала все по 1 му разу, потом все по 2, потом по 3. Так до 5 или 6 а потом так же вниз. После единички добивали сколько сможешь ну или столько сколько был максимум в лесенке. Т.е. лесенка до 6 это 36+6=42 подтягивания.

Я сначала стеснялся, потому что на тот момент мог подтянуться максимум 2 раза. Но ребята поддержали и сказали, что даже попытка будет засчитываться. А потом Лёня предложил вместо попыток дотянуться делать наоборот - запрыгивать сразу в верхнюю точку и медленно спускаться, такие себе обратные подтягивания. В общем, в итоге я набрал форму и выровнялся с остальными.

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

В первую тренировку с трудом, но смог сделать лесенку до 6. После этого руки болели дня 3. Во вторую тренировку меня хватило только до 4, дальше батарейки сели. Я как будто начинаю все сначала. Добивал лесенку обратными подтягиваниями.

Новая цель не просто подтягивания, а выход. Я делал его раньше, по очереди, через одну руку. Но хочу делать двумя и с наименьшей раскачкой. Зачем? Для спины. Я чувствую что подтягивания реально мне помогают с позвоночником. В очередной раз убедился, что то, что делаешь на регулярной основе даёт результат. Надеюсь по четвергам, а это день подтягиваний теперь, будет хорошая погода и я не брошу.
#DevopsTuesday

Про сертификацию

Месяц подготовки (в параллель с работой)
5 направлений, больше 100 сервисов, 75 вопросов
3,5 часа не вставая с кресла, перед ноутбуком и записывающей веб-камерой

Недавно я сдал экзамен AWS Certified Solutions Architect уровня Professional. Хочу записать зачем и какие выводы сделал.

Стоит сказать, что в прошлом году я сдал похожий экзамен Professional Cloud Architect по облаку Google. Так как это облака, в обоих много внимания уделяется Scalability и Reliability, но мне показалось что в GCP зачастую есть только один сервис/способ решения задачи и он скорее всего "google way", в то время как в AWS много адаптированных решений и вариантов несколько.

Например, у обоих есть сервис для управления SQL базами MySQL/PostgreSQL. Но они немного ограниченны как в размерах, нагрузке так и в отказоустойчивости. Если у вас большая нагрузка/объемы, нужно переходить на другой сервис.

В случае GCP это Cloud Spanner и не получится просто изменить подключение на новый сервис и перетащить данные, придется переписывать приложение. Тут отдельные клиентские библиотеки, изменение схемы и т.д.

А в AWS сервис такого уровня, с шардированием и кросс-регионами это Aurora, который заработает из коробки на тех же клиентах, а миграцию данных можно сделать хоть репликацией, хоть восстановлением из снепшота.

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

Подводя итог сравнения, мне больше понравился экзамен AWS и если вы хотите сдать только один экзамен по облакам, берите его.

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

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

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

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

Что дальше? Сертификаты, имеют срок годности 2-3 года, но пересдавать конечно же я не буду. Из 3 крупнейших облаков остался Azure, но я решил что не буду его сдавать. Облака +- похожи, естественно есть свои особенности, но при необходимости я попробую компенсировать уже имеющимся опытом и своей способностью быстро учиться и разбираться.

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

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

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

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

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

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

В конце года мне нужно будет заполнить налоговую декларацию и будет перерасчет. Может оказаться, что налогов уплачено больше или меньше положенного. Разбираясь в расчетных квитанциях я и вспомнил эту историю.
#book_notes Shape Up или Хватит бегать кругами

За свою карьеру я работал в разных реализациях Agile подхода. Kanban, Scrum и их микс. Последний проект со Scrum "по учебнику" меня жутко нервировал. В нем я особенно четко ощутил, что мы делаем что-то не так.

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

Сейчас, ретроспективно, я понимаю что попытка найти комфортный процесс разработки в том числе были драйвером смены работы. На собеседованиях пытаюсь поподробнее выяснить как выстроен процесс. Причем зачастую люди не понимают, почему столько вопросов. "Agile у нас Agile". А Agile, на самом деле, у всех разный.

На днях дочитал книгу Shape Up от создателей Basecamp. Читал Remote и Rework от них же и почерпнул много интересного. Не стала исключением и Shape Up.

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

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

Вообще Shape Up больше для менеджмента, как наверное и другие их книги. Но я рад что прочитал. Возможно, когда-нибудь удастся попробовать внедрить такой подход где-нибудь.
#новости

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

Для меня Nginx всегда выглядел логичным и понятным, работать с ним было просто и он давал отличную производительность. Говорю в прошедшем времени, потому что последние годы с ним не работаю и не знаю, например, насколько они подтянулись в микросервисы, mesh и поддержку k8s.

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

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

Кстати моё активное изучение Nginx в 2014 году заметно по блогу. В прошлом году даже решил сделать отдельную страницу с советами - Nginx 101, которую пока так и не довел до ума.
#блог

Начал, наконец, писать про переезд в Нидерланды в блоге. Но первая статья, внезапно, про Беларусь.

8 месяцев в Минске - https://doam.ru/8_months_in_minsk/