Давно не было!
Pros and cons of monolithic vs. microservices architecture
https://searchapparchitecture.techtarget.com/tip/Pros-and-cons-of-monolithic-vs-microservices-architecture
Size: a a a
2020 January 29
Новый курс на Coursera от Google про автоматизацию различных операций с помощью Python.
http://amp.gs/ulnc
#coursera #automation #python
http://amp.gs/ulnc
#coursera #automation #python
Как делать хороший Code Review
Многие разработчики, достигнув уровня Senior, сталкиваются при работе над проектами с таким понятием, как code review. Более того, регулярные проверки кода становятся их рутинным занятием.
Это крайне полезный и тонкий процесс, в результате которого можно как сплотить разработчиков, наладить эффективные взаимоотношения и повысить профессионализм участников, так и наоборот: посеять хаос, разочароваться в команде, и того хуже - не вложиться в отведенные сроки. Данная статья опишет основополагающие правила хорошего code review.
Читать статью
#code #reviews
Многие разработчики, достигнув уровня Senior, сталкиваются при работе над проектами с таким понятием, как code review. Более того, регулярные проверки кода становятся их рутинным занятием.
Это крайне полезный и тонкий процесс, в результате которого можно как сплотить разработчиков, наладить эффективные взаимоотношения и повысить профессионализм участников, так и наоборот: посеять хаос, разочароваться в команде, и того хуже - не вложиться в отведенные сроки. Данная статья опишет основополагающие правила хорошего code review.
Читать статью
#code #reviews
End to End Immutable Infrastructure Testing: Inspec, Vagrant, Packer and Azure DevOps
https://www.youtube.com/watch?v=vNiZbAkomr4
https://www.youtube.com/watch?v=vNiZbAkomr4
Давайте начнем. 🤓
Не смотря на то, что все сейчас городят пачку микросервисов на любой чих, далеко не все знают как делать это правильно. Так что давайте будем смотреть хорошие доклады на эту тему.
Начнем мы с чувачка по имени Adrian Cockcroft. Он стоял за микросервисным развитием в Netflix, консультировал много крупных компаний, а сейчас работает в AWS.
В дальнейшем мы с вами посмотрим парочку его докладов.
https://www.infoq.com/presentations/microservices-review
Не смотря на то, что все сейчас городят пачку микросервисов на любой чих, далеко не все знают как делать это правильно. Так что давайте будем смотреть хорошие доклады на эту тему.
Начнем мы с чувачка по имени Adrian Cockcroft. Он стоял за микросервисным развитием в Netflix, консультировал много крупных компаний, а сейчас работает в AWS.
В дальнейшем мы с вами посмотрим парочку его докладов.
https://www.infoq.com/presentations/microservices-review
⚙️ Тут про опыт работы с Sysdig Falco и Kubernetes рассказывают. Интересно рассказывают.
Про сам Sysdig Falco я как-то писал отдельную заметку у себя. И про Sysdig, кстати, тоже отдельно писал. Почитайте, если не видели.
#kubernetes #sysdig #falco
Про сам Sysdig Falco я как-то писал отдельную заметку у себя. И про Sysdig, кстати, тоже отдельно писал. Почитайте, если не видели.
#kubernetes #sysdig #falco
2020 January 30
подвезли http API для Github Actions. Вот это уже серьезный разговор. https://developer.github.com/changes/2020-01-28-actions-api/
(спасибо astlock за шаринг)
(спасибо astlock за шаринг)
Внезапно нашел хороший блог по saltstack (ну как нашел - подсмотрел в чате @saltstack) - https://salt.tips ну и сразу отличная статья там про патчинг модулей https://salt.tips/patching-salt-modules/ #salt #saltstack
Флант запилил статью про calico https://habr.com/ru/company/flant/blog/485716/ #k8s #cni #calico
Метапрограммирование в Golang https://levelup.gitconnected.com/metaprogram-in-go-5a2a7e989613 #golang
Ух, тут прекрасно все - и статья исходная и ответка от @manandthemachine (с которой я согласен по всем пунктам)
(1/2) Попался на глаза вот этот пост на Хабре. Впечатления он у меня вызвал очень противоречивые, а раз "в интернете кто-то неправ", то я просто не могу молчать! Подробного разбора не будет, я лишь прокомментирую некоторые пункты. Орфография и грамматика оригинала сохранены.
"Так вот, я завалил три из четыре собеседований, и я хочу об этом поговорить."
Автор (по его словам) обладает колоссальным опытом, был везде и делал всякое, повидал некоторое дерьмо... И это абсолютно не значит ничего. Практика показывает, что даже самые талантливые и умные и общительные и коммуникабельные и ответственные и вообще красавчики/красавицы не попадают в хорошие места. И это нормально.
"В самом деле, зачем смотреть код человека, главная работа которого будет заключаться в том, чтобы его писать?"
На работе от вас ожидают, что вы будете писать "промышленный" код, работая в условиях сжатых сроков и огромного количества зависимостей, в том числе и человеческих. Код "домашних проектов", выложенных на GitHub написан в "пижамных" условиях, где сроков и компромиссов нет. Единственное, чем он может быть полезен - показать, насколько хорошо вы можете организовать структуру проекта и пишете README.
"Это сразу закроет тучу вопросов."
Нет, не закроет. Ваш покорный лично был свидетелем ситуации, когда для специалистов... с низкой компетенцией более опытные товарищи писали красивый код на GH от их имени, ориентируясь как раз на таких нанимателей, которые искренне верят, что GH - показатель мастерства.
"Но и тут можно выкрутиться, дав небольшое тестовое на час-два (только не на месте: для многих собеседование это всё-таки стресс)."
1) Это очень дорого, долго и далеко от реальности (реальные задачи вам не дадут, потому что NDA).
2) Если собеседование, где нужно решить FizzBuzz, для вас стресс, то что будет на работе?
"На моем github два десятка проектов на разных языках, PR'ы в репы Facebook, Microsoft, Mozilla, куча issue в другие проекты. Это же клондайк для оценки как hard, так и soft скиллов."
Это показывает вашу любовь к OSS, только и всего.
"Как часто вы пишете сортировки? [...] А знаете, какие этапы в https-handshake? [...] Но мне хватило 5 минут, чтобы открыть гугл и вспомнить, [...]. И знаете что? Сейчас я опять не помню."
Что говорит о том, что вы не работаете с этим каждый день. Ваш покорный потратил немало времени на низкоуровневое дерьмо, пытаясь разобраться, почему отваливается mutual TLS при работе с Kafka, а знание сложности индексов БД очень помогает при проектировании OLTP приложений. Если вас спрашивают подобные вещи, то либо проверяется ваша ИТ эрудиция (что нормально), либо насколько хорошо вы разбираетесь в конкретном вопросе.
"Так вот, я завалил три из четыре собеседований, и я хочу об этом поговорить."
Автор (по его словам) обладает колоссальным опытом, был везде и делал всякое, повидал некоторое дерьмо... И это абсолютно не значит ничего. Практика показывает, что даже самые талантливые и умные и общительные и коммуникабельные и ответственные и вообще красавчики/красавицы не попадают в хорошие места. И это нормально.
"В самом деле, зачем смотреть код человека, главная работа которого будет заключаться в том, чтобы его писать?"
На работе от вас ожидают, что вы будете писать "промышленный" код, работая в условиях сжатых сроков и огромного количества зависимостей, в том числе и человеческих. Код "домашних проектов", выложенных на GitHub написан в "пижамных" условиях, где сроков и компромиссов нет. Единственное, чем он может быть полезен - показать, насколько хорошо вы можете организовать структуру проекта и пишете README.
"Это сразу закроет тучу вопросов."
Нет, не закроет. Ваш покорный лично был свидетелем ситуации, когда для специалистов... с низкой компетенцией более опытные товарищи писали красивый код на GH от их имени, ориентируясь как раз на таких нанимателей, которые искренне верят, что GH - показатель мастерства.
"Но и тут можно выкрутиться, дав небольшое тестовое на час-два (только не на месте: для многих собеседование это всё-таки стресс)."
1) Это очень дорого, долго и далеко от реальности (реальные задачи вам не дадут, потому что NDA).
2) Если собеседование, где нужно решить FizzBuzz, для вас стресс, то что будет на работе?
"На моем github два десятка проектов на разных языках, PR'ы в репы Facebook, Microsoft, Mozilla, куча issue в другие проекты. Это же клондайк для оценки как hard, так и soft скиллов."
Это показывает вашу любовь к OSS, только и всего.
"Как часто вы пишете сортировки? [...] А знаете, какие этапы в https-handshake? [...] Но мне хватило 5 минут, чтобы открыть гугл и вспомнить, [...]. И знаете что? Сейчас я опять не помню."
Что говорит о том, что вы не работаете с этим каждый день. Ваш покорный потратил немало времени на низкоуровневое дерьмо, пытаясь разобраться, почему отваливается mutual TLS при работе с Kafka, а знание сложности индексов БД очень помогает при проектировании OLTP приложений. Если вас спрашивают подобные вещи, то либо проверяется ваша ИТ эрудиция (что нормально), либо насколько хорошо вы разбираетесь в конкретном вопросе.
(2/2) "У текущего поколения нет таких заморочек насчет забивания головы знаниями."
Это очень много говорит о текущем состоянии индустрии и квалификации молодых специалистов.
"Было пару собесов в западные компании. И там акцент был на то, что ты знаешь и умеешь, а не попытках подловить на незнании."
Единственное, с чем могу согласиться. Задача собеседования - узнать, что человек умеет и знает, и (что еще важнее) что не умеет и не знает. Если интервьюер самоутверждается за ваш счет, то стоит только радоваться "проваленному" собеседованию.
"Всегда спрашивайте про проекты."
Зачем? Я могу попросить человека "спроектировать" мне что-нибудь (да хоть Netflix), и это уже даст мне больше информации, чем монолог о прошлых ошибках и достижениях.
Но вопрос "Расскажите о своем самом большом провале" один из моих самых любимых.
"Это еще и поможет выстроить дружелюбную атмосферу. Помните же, что собеседование — это стресс?"
Дружелюбную атмосферу можно выстроить просто улыбаясь и давая человеку небольшие подсказки. Вам достаточно показать, что вы ему не враг.
"(Про опытных разработчиков) Он не станет читать к собесу про ACID и CAP, как студент к экзамену."
Я могу ошибаться, словно выживший, но все опытные разрабы, с которыми я имел дело, прекрасно знали теоретическую базу распределенных систем.
"Не поверите: ремоут может быть продуктивнее работы в офисе."
Налаживать разработку с использованием распределенных команд очень дорого и долго и чаще всего неэффективно. Бизнес не должен перестраивать годами проверенную модель ради хотелок "зумеров", без обид.
"Знаете админское правило 15 минут? Подожди, перед тем, как разбираться с проблемой пользователя. Часто она или решится сама, или станет неактуальной."
Это говорит об отсутствии клиентоориентированности. Про это "правило" слышу в первый раз (хотя начинал, можно сказать с самых низов).
В целом статья интересная и полезная (если вам нечем заняться в туалете или поездке в автобусе), но я очень надеюсь, что советам автора (кроме того, что про "доминирование") никто следовать не будет.
При всем уважении, но собеседования проводят, чтобы нанять лучшего специалиста в пределах бюджета, а не доставить удовольствие кандидату. Не оставить плохих впечатлений... Может быть, но это все еще не приоритет.
Это очень много говорит о текущем состоянии индустрии и квалификации молодых специалистов.
"Было пару собесов в западные компании. И там акцент был на то, что ты знаешь и умеешь, а не попытках подловить на незнании."
Единственное, с чем могу согласиться. Задача собеседования - узнать, что человек умеет и знает, и (что еще важнее) что не умеет и не знает. Если интервьюер самоутверждается за ваш счет, то стоит только радоваться "проваленному" собеседованию.
"Всегда спрашивайте про проекты."
Зачем? Я могу попросить человека "спроектировать" мне что-нибудь (да хоть Netflix), и это уже даст мне больше информации, чем монолог о прошлых ошибках и достижениях.
Но вопрос "Расскажите о своем самом большом провале" один из моих самых любимых.
"Это еще и поможет выстроить дружелюбную атмосферу. Помните же, что собеседование — это стресс?"
Дружелюбную атмосферу можно выстроить просто улыбаясь и давая человеку небольшие подсказки. Вам достаточно показать, что вы ему не враг.
"(Про опытных разработчиков) Он не станет читать к собесу про ACID и CAP, как студент к экзамену."
Я могу ошибаться, словно выживший, но все опытные разрабы, с которыми я имел дело, прекрасно знали теоретическую базу распределенных систем.
"Не поверите: ремоут может быть продуктивнее работы в офисе."
Налаживать разработку с использованием распределенных команд очень дорого и долго и чаще всего неэффективно. Бизнес не должен перестраивать годами проверенную модель ради хотелок "зумеров", без обид.
"Знаете админское правило 15 минут? Подожди, перед тем, как разбираться с проблемой пользователя. Часто она или решится сама, или станет неактуальной."
Это говорит об отсутствии клиентоориентированности. Про это "правило" слышу в первый раз (хотя начинал, можно сказать с самых низов).
В целом статья интересная и полезная (если вам нечем заняться в туалете или поездке в автобусе), но я очень надеюсь, что советам автора (кроме того, что про "доминирование") никто следовать не будет.
При всем уважении, но собеседования проводят, чтобы нанять лучшего специалиста в пределах бюджета, а не доставить удовольствие кандидату. Не оставить плохих впечатлений... Может быть, но это все еще не приоритет.
2020 January 31
Вот это поворот!
Monoliths are the future
Kelsey Hightower считает, что будущее за монолитами, а не за микросервисами.
https://changelog.com/posts/monoliths-are-the-future
Kelsey Hightower считает, что будущее за монолитами, а не за микросервисами.
https://changelog.com/posts/monoliths-are-the-future
Building SRE from Scratch
Как организовать SRE процессы с нуля.
https://medium.com/ibm-garage/building-sre-from-scratch-485e23985bbd
Как организовать SRE процессы с нуля.
https://medium.com/ibm-garage/building-sre-from-scratch-485e23985bbd