Привет, Хабр. Очень много много сейчас слышно про Кубернетис и Docker. Про них не знает наверное, только ленивый. Но есть и другие варианты работы с контейнерами. Предлагаю перевод статьи одного энтузиаста, который решил изучить похожие инструменты.
User
Я провёл более 600 технических интервью — и вот пять проблемных мест, которые я заметил у кандидатов
9 min
Translation
Недавно я провёл 600-е собеседование на interviewing.io (IIO). Хотелось бы поделиться опытом, рассказать, как я подхожу к интервью, и пролить свет на типичные проблемы у кандидатов. Каждый интервьюер на IIO индивидуален, поэтому ваши результаты могут отличаться. У нас на платформе сформировалось замечательное сообщество, где каждый работает над улучшением своих знаний, навыков и результатов интервью.
Мы оцениваем людей по трём четырёхбалльным шкалам. Оценка «один» означает плохой результат, а «четыре» — очень хороший. Я обычно вначале даю кандидату три балла, а затем прибавляю/отнимаю очки по мере интервью.
Каждый интервьюер отдаёт предпочтение какому-то одному аспекту. Лично я проявляю некоторую предвзятость в сторону скиллов «общение» («коммуникация») и «решение проблем», которые мы обсудим ниже.
Пробное интервью на interviewing.io
Мы оцениваем людей по трём четырёхбалльным шкалам. Оценка «один» означает плохой результат, а «четыре» — очень хороший. Я обычно вначале даю кандидату три балла, а затем прибавляю/отнимаю очки по мере интервью.
Каждый интервьюер отдаёт предпочтение какому-то одному аспекту. Лично я проявляю некоторую предвзятость в сторону скиллов «общение» («коммуникация») и «решение проблем», которые мы обсудим ниже.
Что же такое GitOps? Его свойства и недостатки
12 min
Полтора года назад мы переводили пару статей о том, что такое GitOps. С тех пор этот термин (и сам подход) набрал ещё большую популярность в среде DevOps-инженеров, особенно эксплуатирующих Kubernetes. В то же время у меня появилось свое видение того, какие у него проблемы и каким он должен быть. Поделиться этими мыслями я решил в получасовом видео — смотрите его либо читайте основную выжимку, если предпочитаете текст:
Почему SOLID – важная составляющая мышления программиста. Разбираемся на примерах с кодом
14 min
Привет! Меня зовут Иван, я сотрудничаю со львовским офисом EPAM как Solution Architect, а карьеру в IT начал 10 лет назад. За это время заметил, что многие любят работать на проектах, которые начинаются с нуля. Однако не всем удается построить систему, которую будет все еще легко поддерживать и развивать спустя год.
Вполне естественно, что вместе с разрастанием системы будет повышаться и ее сложность. Успех разработки такой системы будет зависеть от того, насколько хорошо вы держите под контролем ее сложность. Для достижения этой цели существуют дизайн-паттерны, лучшие практики, а главное – принципы проектирования, такие как SOLID, GRASP и DDD.
В данной статье я хочу акцентировать внимание на том, что SOLID – важная составляющая мышления разработчика, которую нужно развивать и тренировать.
Я покажу несколько примеров с кодом, где нарушаются принципы SOLID. Мы выясним, к каким последствиям это может привести в долгосрочной перспективе и как это можно исправить. На мой взгляд, статья будет интересна как back-end, так и front-end разработчикам разных уровней.
Вполне естественно, что вместе с разрастанием системы будет повышаться и ее сложность. Успех разработки такой системы будет зависеть от того, насколько хорошо вы держите под контролем ее сложность. Для достижения этой цели существуют дизайн-паттерны, лучшие практики, а главное – принципы проектирования, такие как SOLID, GRASP и DDD.
В данной статье я хочу акцентировать внимание на том, что SOLID – важная составляющая мышления разработчика, которую нужно развивать и тренировать.
Я покажу несколько примеров с кодом, где нарушаются принципы SOLID. Мы выясним, к каким последствиям это может привести в долгосрочной перспективе и как это можно исправить. На мой взгляд, статья будет интересна как back-end, так и front-end разработчикам разных уровней.
Самый маленький офисный пакет в мире
8 min
Translation
Всем нам знаком традиционный офисный пакет — текстовый редактор, электронные таблицы, программа для создания презентаций, возможно, приложение для создания диаграмм или заметок. Всё это мы видим в Microsoft Office и в Google Docs. Все эти программы мощны и объёмны. Но каким будет минимальное количество кода, требуемое для создания офисного пакета?
Эргономичная раздельная клавиатура. Iris
9 min
Компьютеры, железо, IT в целом это такая область, которая развивается просто невероятными темпами. Вот только клавиатуры развиваться не хотят.
Мой первый комп появился 20 лет назад, тогда у меня был огромный ЭЛТ монитор. Весил он примерно 800 тонн, при своих 15 дюймах. Если сейчас на такой посмотреть, то у вас вытекут глаза. Может быть кто-то помнит модемы из 2000 года? Это жутко медленный модем, который трещал подключаясь по телефонной линии. Сейчас у нас есть 4g даже в часах. Даже молчу про процессоры, память, оперативку. Там развитие сумасшедшее.
А что там с клавиатурами?
Как получить доступ к ресурсам Kubernetes Pod
8 min
Translation
В начале работы с Kubernetes обычно забывают о настройке ресурсов контейнеров. На этом этапе достаточно убедиться, что образ Docker работает и его можно развернуть в кластере Kubernetes.
Но позднее приложение требуется развернуть в продакшен кластере вместе с другими приложениями. Для этого нужно выделить ресурсы для контейнера и убедиться, что их достаточно для запуска и работы приложения, а в других запущенных приложениях не возникнет проблем.
Команда Kubernetes aaS от Mail.ru перевела статью о ресурсах контейнеров (CPU & MEM), запросах и ограничениях ресурсов. Вы узнаете, какие преимущества дают эти настройки и что произойдет, если их не установить.
Топ-12 лучших систем управления тестированием 2020
10 min
Каждый проект уникален и у каждой команды свои запросы. Однако всех нас объединяет желание работать с качественными инструментами, которые экономят время и позволяют QA-специалистам тестировать качественнее и быстрее, в идеале чтобы TMS могла совмещать ручное и автоматизированное тестирование.
Мы вновь проанализировали проверенные временем и новые системы управления тестированием, которые сейчас популярны на рынке. Выбрали функции, которые должны быть в Test Management System нашей мечты, сравнили возможности продуктов и изучили отзывы пользователей. Делимся списком инструментов, один из которых точно подойдёт вашей команде.
Здесь нет рейтинга, у каждого инструмента есть свои преимущества и недостатки. В основном инструменты тест-менеджмента платные, однако у всех есть бесплатная пробная версия.
Мы вновь проанализировали проверенные временем и новые системы управления тестированием, которые сейчас популярны на рынке. Выбрали функции, которые должны быть в Test Management System нашей мечты, сравнили возможности продуктов и изучили отзывы пользователей. Делимся списком инструментов, один из которых точно подойдёт вашей команде.
Здесь нет рейтинга, у каждого инструмента есть свои преимущества и недостатки. В основном инструменты тест-менеджмента платные, однако у всех есть бесплатная пробная версия.
Мониторинг Node.js-приложения
7 min
Здравствуйте! Меня зовут Ренат Саматов, я возглавляю фронтенд-направление в линейке продуктов Витрина. Большая часть наших проектов рендерится на сервере. Сегодня мы побеседуем об одном из важнейших аспектов SSR-приложения: о мониторинге.
Даже в 2020-м мониторинг Node.js-приложения является непростой задачей. Node.js — среда выполнения JavaScript, однопоточного языка программирования с динамической типизацией. Интерпретатору и среде исполнения предоставлены широкие полномочия, что очень легко может привести к утечке памяти или высокой нагрузке на процессор. Node.js работает асинхронно (псевдопараллельно), однако если одна функция блокирует поток или очередь событий, производительность приложения начинает сильно проседать.
В этой статье я расскажу о том, как контролировать ваше Node.js-приложение и быть уверенным в том, что проблем с утечкой памяти, ресурсов процессора и блокировкой потока не возникает. Мы побеседуем об управлении производительностью приложения (Application Performance Management, APM) и метриках, на которые следует обращать внимание. Погнали!
Пока все праздновали мой день рождения, я до утра чинил кластер — а разрабы валили на меня свои ошибки
7 min
Вот история, которая навсегда перевернула мой подход к работе девопса. Еще в доковидные времена, задолго-задолго до них, когда мы с парнями только задумывали свое дело и фрилансили на случайных заказах, мне в телегу упало одно предложение.
Компания, которая написала, занималась аналитикой данных. Ежедневно она обрабатывала тысячи запросов. К нам они пришли со словами: ребят, у нас есть ClickHouse и мы хотим автоматизировать его настройку и установку. Хотим Ansible, Terraform, Докер и чтобы это все хранилось в гите. Хотим кластер из четырех нод по две реплики в каждой.
Стандартная просьба, каких десятки, и нужно такое же хорошее стандартное решение. Мы сказали «окей», и через 2-3 недели все было готово. Работу они приняли и начали переезжать на новый кластер Кликхауса с помощью нашей утилиты.
Коллеги, вы меня огорчаете
12 min
В июле и августе 2020 года я, с подачи Григория Петрова, проводил для компании Evrone технические интервью на позицию Senior Golang Backend developer. И, видимо, буду вынужден продолжать проводить, о чём ниже.
Задача формулировалась как «найти человека, который сможет задать и поддерживать высокий уровень профессионализма в применении языка Go». То есть, сформулирована она была по-человечески, перевод на канцелярит — мой. Под эту задачу я сформировал новый опросник вместо того, которым пользовался несколько лет — старый был с жестким закосом под DevOps. Методику, которой я пользуюсь для создания опросников и количественной оценки соответствия кандидатов, я излагал в своем докладе «Техническое интервью как инженерная задача» на конференции Saint TeamLead 2019.
И вот что я хочу сказать вам, коллеги: вы меня огорчаете.
Задача формулировалась как «найти человека, который сможет задать и поддерживать высокий уровень профессионализма в применении языка Go». То есть, сформулирована она была по-человечески, перевод на канцелярит — мой. Под эту задачу я сформировал новый опросник вместо того, которым пользовался несколько лет — старый был с жестким закосом под DevOps. Методику, которой я пользуюсь для создания опросников и количественной оценки соответствия кандидатов, я излагал в своем докладе «Техническое интервью как инженерная задача» на конференции Saint TeamLead 2019.
И вот что я хочу сказать вам, коллеги: вы меня огорчаете.
Путь к Федеративному GraphQL
11 min
Translation
Программисты любят хорошие истории, поэтому надеюсь что пятилетний путь к композитному API с помощью GraphQL в боевой среде (на пике выдающей 110 запросов в секунду при 100мс задержке) будет интересен.
[Если вы спешите, проскрольте ниже к урокам и гляньте на открытый код graphql-schema-registry]
NodeJS: 12 пакетов для продуктивности разработчика
6 min
Translation
Менеджер процессов для продакшна с балансировщиком нагрузки. Обёртки над отладкой и хуками Git, защита express-приложений через HTTP-заголовки, утилита в более чем 180 функциями для работы с датами и другие инструменты, которые сэкономят ваше время. Подборка особенно полезна начинающим разработчикам NodeJS, но может порадовать опытных скептиков.
HDTree: настраиваемое дерево решений на Python
17 min
Translation
Представляем настраиваемую и интерактивную структуру дерева решений, написанную на Python. Эта реализация подходит для извлечение знаний из данных, проверки интуитивного представления, улучшения понимание внутренней работы деревьев решений, а также изучение альтернативных причинно-следственных связей в отношении вашей проблемы обучения. Она может использоваться в качестве части более сложных алгоритмов, визуализации и отчётов, для любых исследовательских целей, а также как доступная платформа, чтобы легко проверить ваши идеи алгоритмов дерева решений.
Как собрать продукт за полчаса, не прибегая к программированию?
8 min
Recovery Mode
Некоторое время назад мы провели вебинар с Вадимом Михалёвым, CEO Rocketslides, Codesign и Habit Hero, на тему “Что можно собрать без кода: Zero coding с практическими примерами”. Здесь мы расскажем о том, что обсуждалось на вебинаре, а посмотреть его самостоятельно вы можете, перейдя по ссылке.
Предметно-ориентированная микросервисная архитектура от Uber
16 min
Translation
Прим. перев.: недавняя статья от Uber Engineering рассказывает о путешествии этой крупной компании к своей улучшенной версии микросервисной архитектуры. Несмотря на то, что некоторые интернет-пользователи не без причин увидели в новом подходе «всего лишь применение принципов DDD к микросервисам», статья снискала огромный интерес у сообщества разработчиков и других инженеров. А посему — рады представить её русскоязычную версию, подготовленную специально для хабра.
В последнее время активно обсуждаются недостатки сервис-ориентированных архитектур и, в частности, микросервисных архитектур (МА). Всего несколько лет назад многие с готовностью переходили на МА из-за их многочисленных преимуществ: гибкости в виде независимых развертываний, прозрачной принадлежности, повышения стабильности систем и лучшего разделения ответственности. Однако не так давно ситуация изменилась: микросервисный подход стали критиковать за склонность серьезно увеличивать сложность, из-за которой иногда бывает тяжело реализовать даже тривиальные функции. (Мы рассказывали об этом в докладе «Микросервисы: размер имеет значение, даже если у вас Kubernetes» — прим. перев.)
В настоящее время в Uber насчитывается около 2200 критических микросервисов, и мы испытали все достоинства и недостатки этого подхода на себе. В течение последних двух лет Uber пыталась сократить запутанность микросервисного ландшафта, попутно сохранив преимущества данной архитектуры. С помощью этой публикации мы планируем представить наш обобщенный подход к микросервисным архитектурам, получивший название «Domain-Oriented Microservice Architecture» (DOMA).
Введение
В последнее время активно обсуждаются недостатки сервис-ориентированных архитектур и, в частности, микросервисных архитектур (МА). Всего несколько лет назад многие с готовностью переходили на МА из-за их многочисленных преимуществ: гибкости в виде независимых развертываний, прозрачной принадлежности, повышения стабильности систем и лучшего разделения ответственности. Однако не так давно ситуация изменилась: микросервисный подход стали критиковать за склонность серьезно увеличивать сложность, из-за которой иногда бывает тяжело реализовать даже тривиальные функции. (Мы рассказывали об этом в докладе «Микросервисы: размер имеет значение, даже если у вас Kubernetes» — прим. перев.)
В настоящее время в Uber насчитывается около 2200 критических микросервисов, и мы испытали все достоинства и недостатки этого подхода на себе. В течение последних двух лет Uber пыталась сократить запутанность микросервисного ландшафта, попутно сохранив преимущества данной архитектуры. С помощью этой публикации мы планируем представить наш обобщенный подход к микросервисным архитектурам, получивший название «Domain-Oriented Microservice Architecture» (DOMA).
Как мы побеждаем неопределенность в Delivery Club
15 min
Друзья, всем привет! Меня зовут Коля Архипов, я отвечаю за Research & Development в Delivery Club.
Наша команда решает наукоёмкие задачи внутри FoodTech-платформы: мы разрабатываем компоненты, основанные на алгоритмах и данных, которых в платформе DС много. В процессе решения мы сталкиваемся со множеством неопределенностей как со стороны бизнеса, так и со стороны разработки.
Материал получился объёмным и, я надеюсь, полезным для вас. Поэтому рекомендую поставить чайничек и заварить вкусный кофе, я сделал так сам, пока работал над этой статьей.
Сегодня расскажу о гонке, которую наша команда прошла за последний год. Аналогия возникла сама собой — мы работаем в очень динамичной компании, лидере рынка FoodTech в России. Мы стремительно развиваем разные направления бизнеса, и это действительно драйвит! Мы не только успешно пришли к финишу, но и получили много инсайтов в процессе «гонки». Этим и хочу поделиться с вами.
Статья появилась после доклада на конференции РИТ++ 2020. Для тех, кто любит видео, — ищите его в конце статьи.
Прикладное целеводство. Доклад Яндекса
12 min
Зачем нужны цели? Как их формулировать? Какие проблемы могут возникнуть? По случаю Я.Субботника Pro я подготовил доклад, основанный на нескольких годах опыта ведения целей для команд в Яндексе.
Лучшие практики bash-скриптов: краткое руководство по надежным и производительным скриптам bash
6 min
Translation
Shell wallpaper by manapi
Отладка сценариев bash — это как поиск иголки в стоге сена, тем более, когда новые дополнения появляются в существующей кодовой базе без своевременного рассмотрения вопросов структуры, логирования и надежности. В таких ситуациях можно оказаться как из-за собственных ошибок, так и при управлении сложными нагромождениями скриптов.
Команда Mail.ru Cloud Solutions перевела статью с рекомендациям, благодаря которым вы сможете лучше писать, отлаживать и поддерживать свои сценарии. Хотите верьте, хотите нет, но ничто не может сравниться с удовлетворением от написания чистого, готового к использованию bash-кода, который работает каждый раз.
В статье автор делится тем, что узнал за последние несколько лет, а также некоторыми распространенными ошибками, которые заставали его врасплох. Это важно, потому что каждый разработчик программного обеспечения в определенный момент своей карьеры работает со сценариями для автоматизации рутинных рабочих задач.
Ты можешь писать безупречные ТЗ, но какой в этом толк, если разработчик твой плачет?
9 min
Tutorial
В далекой-далекой галактике трудится сферический product owner. Он бегло пишет заметки на салфетке и молча отдает ее разработчикам. А вскоре получает готовый продукт, который на 100% соответствует его ожиданиям. Даже если продукт этот – сложный кроссплатформенный сервис с блэкджеком и адаптивностью.
Возможно ли такое на практике?