#spam #nl Открыли купальный сезон
Из Амстердама до Северного моря в районе 30 км. Но даже в пределах города есть несколько мест где можно искупаться. Вчера был очень жаркий день и вечером после работы мы поехали на великах в Айбург.
Айбург это район построенный на озере, т.е. буквально на воде. Подробнее о нем можно почитать, например, у Варламова. И в этом районе есть песочный пляж.
Перед тем как купаться мы проверили качество воды на специальном сайте. На дорогу в одну сторону в неспешном режиме уходит примерно 1 час.
До моря мы тоже планируем добраться, но там сильный ветер и волны. Плюс ехать на городских великах может быть долго и не очень комфортно. Возможно придется ехать на поезде.
Из Амстердама до Северного моря в районе 30 км. Но даже в пределах города есть несколько мест где можно искупаться. Вчера был очень жаркий день и вечером после работы мы поехали на великах в Айбург.
Айбург это район построенный на озере, т.е. буквально на воде. Подробнее о нем можно почитать, например, у Варламова. И в этом районе есть песочный пляж.
Перед тем как купаться мы проверили качество воды на специальном сайте. На дорогу в одну сторону в неспешном режиме уходит примерно 1 час.
До моря мы тоже планируем добраться, но там сильный ветер и волны. Плюс ехать на городских великах может быть долго и не очень комфортно. Возможно придется ехать на поезде.
#spam #nl Дар соседства
Вчера в почтовый ящик кинули непонятную коробку. Внутри оказались купоны и скидки в разные заведения на районе.
На сайте написано, что это способ для заведений поприветствовать новых жителей и выделиться среди остальных.
В большинстве случаев есть ограничения, типа скидка €5 при покупке от €30. Нам ничего из этого не нужно, лишний мусор.
Вчера в почтовый ящик кинули непонятную коробку. Внутри оказались купоны и скидки в разные заведения на районе.
На сайте написано, что это способ для заведений поприветствовать новых жителей и выделиться среди остальных.
В большинстве случаев есть ограничения, типа скидка €5 при покупке от €30. Нам ничего из этого не нужно, лишний мусор.
#spam #nl В Нидерландах любят 3D печать
На днях в Амстердаме поставили стальной мост, напечатанный на 3D принтере. Проект предложили еще в 2015, а "печать" начали в 2017. После нескольких тестов мост наконец поставили в городе.
Сейчас он позволяет перейти через канал недалеко от улицы красных фонарей. На самом деле эта установка тоже тестовая. К мосту подключена куча сенсоров, пару лет за ним будут наблюдать и исследовать.
Раз уж заговорили про 3D печать в промышленных масштабах. В апреле этого года люди заехали в "напечатанный" дом, а еще ввели в эксплуатацию самый длинный в мире велосипедный мост напечатанный на 3D-принтере.
Еще до выхода этих новостей, я встретился с инфраструктурой напечатанной бетоном по той же технологии что и дом и мост. В пригороде Амстердама, лестницы транспортного узла привлекли мое внимание необычной структурой.
Скорее всего обкатку технологии начинали с небольших объектов. Кстати там же я увидел и недостаток. Судя по всему из-за слоеной структуры, конструкция получается хрупкой (видно скол на фотке).
Также интересный момент, что в случае с бетонной 3D печатью, не полностью все "напечатано". На фотках моста в статьях, видно что наполнение просто "залито". Возможно это часть печати, а может быть ограничение, которое пока не обошли.
В любом случае, мне нравится наблюдать за прогрессом 3D печати, а вам? Хотели бы иметь в городе подобную инфраструктуру?
На днях в Амстердаме поставили стальной мост, напечатанный на 3D принтере. Проект предложили еще в 2015, а "печать" начали в 2017. После нескольких тестов мост наконец поставили в городе.
Сейчас он позволяет перейти через канал недалеко от улицы красных фонарей. На самом деле эта установка тоже тестовая. К мосту подключена куча сенсоров, пару лет за ним будут наблюдать и исследовать.
Раз уж заговорили про 3D печать в промышленных масштабах. В апреле этого года люди заехали в "напечатанный" дом, а еще ввели в эксплуатацию самый длинный в мире велосипедный мост напечатанный на 3D-принтере.
Еще до выхода этих новостей, я встретился с инфраструктурой напечатанной бетоном по той же технологии что и дом и мост. В пригороде Амстердама, лестницы транспортного узла привлекли мое внимание необычной структурой.
Скорее всего обкатку технологии начинали с небольших объектов. Кстати там же я увидел и недостаток. Судя по всему из-за слоеной структуры, конструкция получается хрупкой (видно скол на фотке).
Также интересный момент, что в случае с бетонной 3D печатью, не полностью все "напечатано". На фотках моста в статьях, видно что наполнение просто "залито". Возможно это часть печати, а может быть ограничение, которое пока не обошли.
В любом случае, мне нравится наблюдать за прогрессом 3D печати, а вам? Хотели бы иметь в городе подобную инфраструктуру?
#blog
Нанес заведения из рейтинга топ 50 пиццерий Европы 2021 на карту - https://doam.ru/50_top_pizza_map_2021/.
Короткая ссылка, сразу на карту: https://doam.ru/50toppizzamap2021
Нанес заведения из рейтинга топ 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 сервере.
Давненько не было ничего на тему 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, дальше батарейки сели. Я как будто начинаю все сначала. Добивал лесенку обратными подтягиваниями.
Новая цель не просто подтягивания, а выход. Я делал его раньше, по очереди, через одну руку. Но хочу делать двумя и с наименьшей раскачкой. Зачем? Для спины. Я чувствую что подтягивания реально мне помогают с позвоночником. В очередной раз убедился, что то, что делаешь на регулярной основе даёт результат. Надеюсь по четвергам, а это день подтягиваний теперь, будет хорошая погода и я не брошу.
Решил вернуться к регулярным подтягиваниям. В OneTwoTrip был турник прямо в офисе и каждый вечер я подтягивался 30-50 раз.
Парни подтягивались в лесенку: сначала все по 1 му разу, потом все по 2, потом по 3. Так до 5 или 6 а потом так же вниз. После единички добивали сколько сможешь ну или столько сколько был максимум в лесенке. Т.е. лесенка до 6 это 36+6=42 подтягивания.
Я сначала стеснялся, потому что на тот момент мог подтянуться максимум 2 раза. Но ребята поддержали и сказали, что даже попытка будет засчитываться. А потом Лёня предложил вместо попыток дотянуться делать наоборот - запрыгивать сразу в верхнюю точку и медленно спускаться, такие себе обратные подтягивания. В общем, в итоге я набрал форму и выровнялся с остальными.
С марта 2020 регулярные подтягивания закончились и мышцы начали дряхлеть. В последнее время снова стал замечать быстрое уставание в спине и руках. В отличие от России, где турник есть почти в каждом дворе, тут в Амстердаме его найти было тяжелее. В итоге приходится ходить 1,5 км на искусственный остров с набережной. Причем этот турник там единственный спортивный снаряд. На этом же острове постоянно ошиваются гуси, работают вместо газонокосилок и все засирают.
В первую тренировку с трудом, но смог сделать лесенку до 6. После этого руки болели дня 3. Во вторую тренировку меня хватило только до 4, дальше батарейки сели. Я как будто начинаю все сначала. Добивал лесенку обратными подтягиваниями.
Новая цель не просто подтягивания, а выход. Я делал его раньше, по очереди, через одну руку. Но хочу делать двумя и с наименьшей раскачкой. Зачем? Для спины. Я чувствую что подтягивания реально мне помогают с позвоночником. В очередной раз убедился, что то, что делаешь на регулярной основе даёт результат. Надеюсь по четвергам, а это день подтягиваний теперь, будет хорошая погода и я не брошу.
#DevopsTuesday
Про сертификацию
Недавно я сдал экзамен 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, но я решил что не буду его сдавать. Облака +- похожи, естественно есть свои особенности, но при необходимости я попробую компенсировать уже имеющимся опытом и своей способностью быстро учиться и разбираться.
Возможно пост получился немного сумбурный, если у вас есть какие-нибудь вопросы по этой теме, задавайте в комментах.
Про сертификацию
• Месяц подготовки (в параллель с работой) • 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, но я решил что не буду его сдавать. Облака +- похожи, естественно есть свои особенности, но при необходимости я попробую компенсировать уже имеющимся опытом и своей способностью быстро учиться и разбираться.
Возможно пост получился немного сумбурный, если у вас есть какие-нибудь вопросы по этой теме, задавайте в комментах.
Amazon
AWS Certified Solutions Architect - Professional Certification | AWS Certification | AWS
Earning AWS Certified Solutions Architect – Professional validates the ability to design, deploy, and evaluate applications on AWS within diverse, complex requirements. Learn more about this certification and AWS resources that can help you prepare for your…
#life Про зарплату
Летом 2010 года, на каникулах после 1-го курса, я по приколу устроился работать в магазин компьютерной техники. Необходимости в этом никакой не было, жил в общежитии, деньги высылала мать, мог бы и дальше балду пинать.
Не знаю что мне тогда ударило в голову, может быть жажда самостоятельности, но я проходил мимо витрины, просто зашел и спросил есть ли у них вакансии.
Тогда я и не представлял как много мне даст эта работа. Во-время испытательного срока нужно было ознакомиться с кучей документации. В ней были прописаны большинство аспектов работы.
И там был раздел про заработную плату. Формула по которой высчитывается ЗП была огромной с кучей разных коэффициентов. На вопрос зачем нам это все знать, начальник отвечал "если ты не знаешь, как рассчитывается твоя зарплата, тебе можно её не платить".
С тех пор, я всегда в курсе, как рассчитывается моя зарплата в каждом месте где работаю. Здесь в Нидерландах ЗП брутто, работодатель выплачивает за тебя примерный налог и страховой взнос. Но так как у меня есть скидка на налоги, расчет усложняется. Бонусы считаются отдельно, а еще есть выплаты, которые не облагаются налогом.
В конце года мне нужно будет заполнить налоговую декларацию и будет перерасчет. Может оказаться, что налогов уплачено больше или меньше положенного. Разбираясь в расчетных квитанциях я и вспомнил эту историю.
Летом 2010 года, на каникулах после 1-го курса, я по приколу устроился работать в магазин компьютерной техники. Необходимости в этом никакой не было, жил в общежитии, деньги высылала мать, мог бы и дальше балду пинать.
Не знаю что мне тогда ударило в голову, может быть жажда самостоятельности, но я проходил мимо витрины, просто зашел и спросил есть ли у них вакансии.
Тогда я и не представлял как много мне даст эта работа. Во-время испытательного срока нужно было ознакомиться с кучей документации. В ней были прописаны большинство аспектов работы.
И там был раздел про заработную плату. Формула по которой высчитывается ЗП была огромной с кучей разных коэффициентов. На вопрос зачем нам это все знать, начальник отвечал "если ты не знаешь, как рассчитывается твоя зарплата, тебе можно её не платить".
С тех пор, я всегда в курсе, как рассчитывается моя зарплата в каждом месте где работаю. Здесь в Нидерландах ЗП брутто, работодатель выплачивает за тебя примерный налог и страховой взнос. Но так как у меня есть скидка на налоги, расчет усложняется. Бонусы считаются отдельно, а еще есть выплаты, которые не облагаются налогом.
В конце года мне нужно будет заполнить налоговую декларацию и будет перерасчет. Может оказаться, что налогов уплачено больше или меньше положенного. Разбираясь в расчетных квитанциях я и вспомнил эту историю.
#book_notes Shape Up или Хватит бегать кругами
За свою карьеру я работал в разных реализациях Agile подхода. Kanban, Scrum и их микс. Последний проект со Scrum "по учебнику" меня жутко нервировал. В нем я особенно четко ощутил, что мы делаем что-то не так.
На мой взгляд слишком много энергии уходило на менеджмент, а работы наоборот делалось мало. При этом чувствовал себя как белка в колесе, мы постоянно начинали новую работу, недоделав старую. Все это выглядело как сильно сломанный процесс.
Сейчас, ретроспективно, я понимаю что попытка найти комфортный процесс разработки в том числе были драйвером смены работы. На собеседованиях пытаюсь поподробнее выяснить как выстроен процесс. Причем зачастую люди не понимают, почему столько вопросов. "Agile у нас Agile". А Agile, на самом деле, у всех разный.
На днях дочитал книгу Shape Up от создателей Basecamp. Читал Remote и Rework от них же и почерпнул много интересного. Не стала исключением и Shape Up.
Не могу сказать, что их подход к разработке идеальный без опыта. Но он точно согласуется с моими выводами. Более длительные циклы (6 недель вместо 2), свобода в формировании задач, отсутствие отвлекающих факторов (саппорт и т.п.), отсутствие эстимаций, конечный результат.
Попытался сделать какие-нибудь выжимки или выбрать цитаты, но не получилось, потому что книга короткая и почти без воды. Лучше читать её полностью.
Вообще Shape Up больше для менеджмента, как наверное и другие их книги. Но я рад что прочитал. Возможно, когда-нибудь удастся попробовать внедрить такой подход где-нибудь.
За свою карьеру я работал в разных реализациях Agile подхода. Kanban, Scrum и их микс. Последний проект со Scrum "по учебнику" меня жутко нервировал. В нем я особенно четко ощутил, что мы делаем что-то не так.
На мой взгляд слишком много энергии уходило на менеджмент, а работы наоборот делалось мало. При этом чувствовал себя как белка в колесе, мы постоянно начинали новую работу, недоделав старую. Все это выглядело как сильно сломанный процесс.
Сейчас, ретроспективно, я понимаю что попытка найти комфортный процесс разработки в том числе были драйвером смены работы. На собеседованиях пытаюсь поподробнее выяснить как выстроен процесс. Причем зачастую люди не понимают, почему столько вопросов. "Agile у нас Agile". А Agile, на самом деле, у всех разный.
На днях дочитал книгу Shape Up от создателей Basecamp. Читал Remote и Rework от них же и почерпнул много интересного. Не стала исключением и Shape Up.
Не могу сказать, что их подход к разработке идеальный без опыта. Но он точно согласуется с моими выводами. Более длительные циклы (6 недель вместо 2), свобода в формировании задач, отсутствие отвлекающих факторов (саппорт и т.п.), отсутствие эстимаций, конечный результат.
Попытался сделать какие-нибудь выжимки или выбрать цитаты, но не получилось, потому что книга короткая и почти без воды. Лучше читать её полностью.
Вообще Shape Up больше для менеджмента, как наверное и другие их книги. Но я рад что прочитал. Возможно, когда-нибудь удастся попробовать внедрить такой подход где-нибудь.
Basecamp
Books by Basecamp
On top of making Basecamp, we write books about how to manage projects and run a business. They're filled with straightforward advice you won't find elsewhere.
#новости
Прочитал новость что Игорь Сысоев отходит от управления Nginx и, в каком-то роде, уходит на пенсию. Можно сказать, что для меня Nginx был бустером карьеры. В 2015 году в Москве, если ты знал как работать с Nginx это 50% успешно пройденного интервью на позицию сисадмина веб-сайтов.
Для меня Nginx всегда выглядел логичным и понятным, работать с ним было просто и он давал отличную производительность. Говорю в прошедшем времени, потому что последние годы с ним не работаю и не знаю, например, насколько они подтянулись в микросервисы, mesh и поддержку k8s.
Помню как на конференции HighLoad толи в 2015, толи в 2016 году Сысоев лично стоял на стенде Nginx, стикеры раздавал и общался с людьми. Создатель компании с доходом в миллионы долларов спокойно пожал руку в ответ, выслушал мои спасибо и ответил на вопросы.
Не знаю как там на самом деле, но для меня Сысоев простой русский мужик, который вписал себя в историю интернета, за это ему респект.
Кстати моё активное изучение Nginx в 2014 году заметно по блогу. В прошлом году даже решил сделать отдельную страницу с советами - Nginx 101, которую пока так и не довел до ума.
Прочитал новость что Игорь Сысоев отходит от управления Nginx и, в каком-то роде, уходит на пенсию. Можно сказать, что для меня Nginx был бустером карьеры. В 2015 году в Москве, если ты знал как работать с Nginx это 50% успешно пройденного интервью на позицию сисадмина веб-сайтов.
Для меня Nginx всегда выглядел логичным и понятным, работать с ним было просто и он давал отличную производительность. Говорю в прошедшем времени, потому что последние годы с ним не работаю и не знаю, например, насколько они подтянулись в микросервисы, mesh и поддержку k8s.
Помню как на конференции HighLoad толи в 2015, толи в 2016 году Сысоев лично стоял на стенде Nginx, стикеры раздавал и общался с людьми. Создатель компании с доходом в миллионы долларов спокойно пожал руку в ответ, выслушал мои спасибо и ответил на вопросы.
Не знаю как там на самом деле, но для меня Сысоев простой русский мужик, который вписал себя в историю интернета, за это ему респект.
Кстати моё активное изучение Nginx в 2014 году заметно по блогу. В прошлом году даже решил сделать отдельную страницу с советами - Nginx 101, которую пока так и не довел до ума.
NGINX
Do Svidaniya, Igor, and Thank You for NGINX - NGINX
With profound gratitude for his contributions to both F5 and the Internet at large, we announce that Igor Sysoev, author of NGINX and co-founder of NGINX, Inc., is retiring to spend time with friends and family and work on personal projects. Спасибо, Игорь.
#блог
Начал, наконец, писать про переезд в Нидерланды в блоге. Но первая статья, внезапно, про Беларусь.
8 месяцев в Минске - https://doam.ru/8_months_in_minsk/
Начал, наконец, писать про переезд в Нидерланды в блоге. Но первая статья, внезапно, про Беларусь.
8 месяцев в Минске - https://doam.ru/8_months_in_minsk/