Forwarded from Clean Code (TelepostBot)
Как делать хороший Code Review
Многие разработчики, достигнув уровня Senior, сталкиваются при работе над проектами с таким понятием, как code review. Более того, регулярные проверки кода становятся их рутинным занятием.
Это крайне полезный и тонкий процесс, в результате которого можно как сплотить разработчиков, наладить эффективные взаимоотношения и повысить профессионализм участников, так и наоборот: посеять хаос, разочароваться в команде, и того хуже - не вложиться в отведенные сроки. Данная статья опишет основополагающие правила хорошего code review.
Читать статью
#code #reviews
Многие разработчики, достигнув уровня Senior, сталкиваются при работе над проектами с таким понятием, как code review. Более того, регулярные проверки кода становятся их рутинным занятием.
Это крайне полезный и тонкий процесс, в результате которого можно как сплотить разработчиков, наладить эффективные взаимоотношения и повысить профессионализм участников, так и наоборот: посеять хаос, разочароваться в команде, и того хуже - не вложиться в отведенные сроки. Данная статья опишет основополагающие правила хорошего code review.
Читать статью
#code #reviews
Forwarded from Технологический Болт Генона
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
Forwarded from RemarkableCSTalks (Serhii Mariiekha)
Давайте начнем. 🤓
Не смотря на то, что все сейчас городят пачку микросервисов на любой чих, далеко не все знают как делать это правильно. Так что давайте будем смотреть хорошие доклады на эту тему.
Начнем мы с чувачка по имени Adrian Cockcroft. Он стоял за микросервисным развитием в Netflix, консультировал много крупных компаний, а сейчас работает в AWS.
В дальнейшем мы с вами посмотрим парочку его докладов.
https://www.infoq.com/presentations/microservices-review
Не смотря на то, что все сейчас городят пачку микросервисов на любой чих, далеко не все знают как делать это правильно. Так что давайте будем смотреть хорошие доклады на эту тему.
Начнем мы с чувачка по имени Adrian Cockcroft. Он стоял за микросервисным развитием в Netflix, консультировал много крупных компаний, а сейчас работает в AWS.
В дальнейшем мы с вами посмотрим парочку его докладов.
https://www.infoq.com/presentations/microservices-review
InfoQ
Microservices: State of the Union
Adrian Cockcroft discusses success/failure stories of adopting microservices, overviews what’s next with microservices and presents some of the techniques that have led to successful deployments.
Forwarded from Записки админа
⚙️ Тут про опыт работы с Sysdig Falco и Kubernetes рассказывают. Интересно рассказывают.
Про сам Sysdig Falco я как-то писал отдельную заметку у себя. И про Sysdig, кстати, тоже отдельно писал. Почитайте, если не видели.
#kubernetes #sysdig #falco
Про сам Sysdig Falco я как-то писал отдельную заметку у себя. И про Sysdig, кстати, тоже отдельно писал. Почитайте, если не видели.
#kubernetes #sysdig #falco
Forwarded from Українська девопсарня
подвезли http API для Github Actions. Вот это уже серьезный разговор. https://developer.github.com/changes/2020-01-28-actions-api/
(спасибо astlock за шаринг)
(спасибо astlock за шаринг)
GitHub Developer
Actions API
Get started with one of our guides, or jump straight into the API documentation.
Внезапно нашел хороший блог по saltstack (ну как нашел - подсмотрел в чате @saltstack) - https://salt.tips ну и сразу отличная статья там про патчинг модулей https://salt.tips/patching-salt-modules/ #salt #saltstack
salt.tips
Welcome to the Salt Tips
Collection of useful tips and tricks for infrastructure management using Salt
Ух, тут прекрасно все - и статья исходная и ответка от @manandthemachine (с которой я согласен по всем пунктам)
Forwarded from Человек и машина
(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 приложений. Если вас спрашивают подобные вещи, то либо проверяется ваша ИТ эрудиция (что нормально), либо насколько хорошо вы разбираетесь в конкретном вопросе.
Хабр
Что такое I в ACID или вы нам не подходите
Это пост удивления. Я сходил на собеседования в три минских стартапа и в одну небольшую компанию, и вот что из этого вышло. Немного расскажу о себе. Не хвалы ра...
Forwarded from Человек и машина
(2/2) "У текущего поколения нет таких заморочек насчет забивания головы знаниями."
Это очень много говорит о текущем состоянии индустрии и квалификации молодых специалистов.
"Было пару собесов в западные компании. И там акцент был на то, что ты знаешь и умеешь, а не попытках подловить на незнании."
Единственное, с чем могу согласиться. Задача собеседования - узнать, что человек умеет и знает, и (что еще важнее) что не умеет и не знает. Если интервьюер самоутверждается за ваш счет, то стоит только радоваться "проваленному" собеседованию.
"Всегда спрашивайте про проекты."
Зачем? Я могу попросить человека "спроектировать" мне что-нибудь (да хоть Netflix), и это уже даст мне больше информации, чем монолог о прошлых ошибках и достижениях.
Но вопрос "Расскажите о своем самом большом провале" один из моих самых любимых.
"Это еще и поможет выстроить дружелюбную атмосферу. Помните же, что собеседование — это стресс?"
Дружелюбную атмосферу можно выстроить просто улыбаясь и давая человеку небольшие подсказки. Вам достаточно показать, что вы ему не враг.
"(Про опытных разработчиков) Он не станет читать к собесу про ACID и CAP, как студент к экзамену."
Я могу ошибаться, словно выживший, но все опытные разрабы, с которыми я имел дело, прекрасно знали теоретическую базу распределенных систем.
"Не поверите: ремоут может быть продуктивнее работы в офисе."
Налаживать разработку с использованием распределенных команд очень дорого и долго и чаще всего неэффективно. Бизнес не должен перестраивать годами проверенную модель ради хотелок "зумеров", без обид.
"Знаете админское правило 15 минут? Подожди, перед тем, как разбираться с проблемой пользователя. Часто она или решится сама, или станет неактуальной."
Это говорит об отсутствии клиентоориентированности. Про это "правило" слышу в первый раз (хотя начинал, можно сказать с самых низов).
В целом статья интересная и полезная (если вам нечем заняться в туалете или поездке в автобусе), но я очень надеюсь, что советам автора (кроме того, что про "доминирование") никто следовать не будет.
При всем уважении, но собеседования проводят, чтобы нанять лучшего специалиста в пределах бюджета, а не доставить удовольствие кандидату. Не оставить плохих впечатлений... Может быть, но это все еще не приоритет.
Это очень много говорит о текущем состоянии индустрии и квалификации молодых специалистов.
"Было пару собесов в западные компании. И там акцент был на то, что ты знаешь и умеешь, а не попытках подловить на незнании."
Единственное, с чем могу согласиться. Задача собеседования - узнать, что человек умеет и знает, и (что еще важнее) что не умеет и не знает. Если интервьюер самоутверждается за ваш счет, то стоит только радоваться "проваленному" собеседованию.
"Всегда спрашивайте про проекты."
Зачем? Я могу попросить человека "спроектировать" мне что-нибудь (да хоть Netflix), и это уже даст мне больше информации, чем монолог о прошлых ошибках и достижениях.
Но вопрос "Расскажите о своем самом большом провале" один из моих самых любимых.
"Это еще и поможет выстроить дружелюбную атмосферу. Помните же, что собеседование — это стресс?"
Дружелюбную атмосферу можно выстроить просто улыбаясь и давая человеку небольшие подсказки. Вам достаточно показать, что вы ему не враг.
"(Про опытных разработчиков) Он не станет читать к собесу про ACID и CAP, как студент к экзамену."
Я могу ошибаться, словно выживший, но все опытные разрабы, с которыми я имел дело, прекрасно знали теоретическую базу распределенных систем.
"Не поверите: ремоут может быть продуктивнее работы в офисе."
Налаживать разработку с использованием распределенных команд очень дорого и долго и чаще всего неэффективно. Бизнес не должен перестраивать годами проверенную модель ради хотелок "зумеров", без обид.
"Знаете админское правило 15 минут? Подожди, перед тем, как разбираться с проблемой пользователя. Часто она или решится сама, или станет неактуальной."
Это говорит об отсутствии клиентоориентированности. Про это "правило" слышу в первый раз (хотя начинал, можно сказать с самых низов).
В целом статья интересная и полезная (если вам нечем заняться в туалете или поездке в автобусе), но я очень надеюсь, что советам автора (кроме того, что про "доминирование") никто следовать не будет.
При всем уважении, но собеседования проводят, чтобы нанять лучшего специалиста в пределах бюджета, а не доставить удовольствие кандидату. Не оставить плохих впечатлений... Может быть, но это все еще не приоритет.
Forwarded from DevOps&SRE Library
Monoliths are the future
Kelsey Hightower считает, что будущее за монолитами, а не за микросервисами.
https://changelog.com/posts/monoliths-are-the-future
Kelsey Hightower считает, что будущее за монолитами, а не за микросервисами.
https://changelog.com/posts/monoliths-are-the-future
Forwarded from DevOps&SRE Library
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
Бесплатный онлайн практикум DevOps by REBRAIN: Docker
Регистрация - https://clck.ru/JVc7G
Количество мест строго ограничено!
Время проведения:
4 Февраля (Вторник) в 19:00 по МСК
Что будет на практикуме?
🔹Зачем нужен Docker? Обзор самых актуальных проблем. Как Docker их решает
🔹Обзор внутреннего устройства Docker (Контейнерная виртуализация/ Auths/ Docker registry
🔹Собираем и запускаем свой первый Docker контейнер
🔹Обзор систем оркестрации для Docker
Кто ведет?
Василий Озеров - основатель агентства Fevlake (fevlake.com) и действующий Devops-инженер (опыт в Devops более 5 лет). Регулярно выступает на RootConf, DevOpsConf Russia, HighLoad.
Открытые еженедельные DevOps практикумы - https://bit.ly/2CGmm3C
Присоединяйтесь!
Регистрация - https://clck.ru/JVc7G
Количество мест строго ограничено!
Время проведения:
4 Февраля (Вторник) в 19:00 по МСК
Что будет на практикуме?
🔹Зачем нужен Docker? Обзор самых актуальных проблем. Как Docker их решает
🔹Обзор внутреннего устройства Docker (Контейнерная виртуализация/ Auths/ Docker registry
🔹Собираем и запускаем свой первый Docker контейнер
🔹Обзор систем оркестрации для Docker
Кто ведет?
Василий Озеров - основатель агентства Fevlake (fevlake.com) и действующий Devops-инженер (опыт в Devops более 5 лет). Регулярно выступает на RootConf, DevOpsConf Russia, HighLoad.
Открытые еженедельные DevOps практикумы - https://bit.ly/2CGmm3C
Присоединяйтесь!
Флант тут CSI запилил для Яндекс.Облака https://habr.com/en/company/flant/blog/486190/ #flant #yandexcloud
Хабр
Наш опыт разработки CSI-драйвера в Kubernetes для Яндекс.Облака
Рады объявить, что компания «Флант» пополняет свой вклад в Open Source-инструменты для Kubernetes, выпустив альфа-версию драйвера CSI (Container Storage Interf...