Forwarded from CatOps
6 наиболее залайканных докладов с Riga Dev Days с видео.
6. Zero Downtimes with Faulty Solutions, Dimitris Kapanidis, 2017
5. The DevOps 2.0 Toolkit, Viktor Farcic, 2017
4. Gotchas using Terraform in a secure delivery pipeline, Anton Babenko, 2018
3. Fabric8 Camel Microservices for Docker and Kubernetes, Claus Ibsen, 2016
2. Continuous Deployment With Jenkins X and Kubernetes, Viktor Farcic, 2018
1. 360° monitoring of your microservices, Philipp “xeraa” Krenn, 2017
#slides
6. Zero Downtimes with Faulty Solutions, Dimitris Kapanidis, 2017
5. The DevOps 2.0 Toolkit, Viktor Farcic, 2017
4. Gotchas using Terraform in a secure delivery pipeline, Anton Babenko, 2018
3. Fabric8 Camel Microservices for Docker and Kubernetes, Claus Ibsen, 2016
2. Continuous Deployment With Jenkins X and Kubernetes, Viktor Farcic, 2018
1. 360° monitoring of your microservices, Philipp “xeraa” Krenn, 2017
#slides
Medium
6 Best Rated Microservices Talks
From DevOps Toolkit to Monitoring Microservices
Forwarded from HABR FEED + OPENNET
[Перевод] Назад к микросервисам вместе с Istio. Часть 1
https://habr.com/ru/post/438426/
Tags: Блог компании Флант, DevOps, Kubernetes, Микросервисы, Системное администрирование, Istio, service mesh, микросервисы
Author Wimbo on #habrahabr
https://habr.com/ru/post/438426/
Tags: Блог компании Флант, DevOps, Kubernetes, Микросервисы, Системное администрирование, Istio, service mesh, микросервисы
Author Wimbo on #habrahabr
Forwarded from DevOps Deflope News
В течении десятка часов пришло две большие новости:
1. AWS анонсировали выпуск в опенсорс «Open Distro for Elasticsearch» — дистрибуции Elasticsearch с набором компонентов, которых так не хватало в опенсорсном Elasticsearch:
* Security — поддержка разных аутентификаций, rbac на разных уровнях, шифрование трафика и аудит;
* Event Monitoring & Alerting — создание оповещений по данным в индексам;
* Deep Performance Analysis — API для получения метрик производительности кластера;
* SQL Support — поддержка создания запросов к данным с помощью SQL;
Статья от Jeff Barr http://amp.gs/4eWD
Более общая от Adrian Cockcroft http://amp.gs/4eW0
И сам сайт проекта http://amp.gs/4eWa
2. F5 покупает Nginx.
Статья на TechCrunch http://amp.gs/4eWJ
Анонс Nginx http://amp.gs/4eWX
И от F5 http://amp.gs/4eW3
#news #elasticsearch #nginx
1. AWS анонсировали выпуск в опенсорс «Open Distro for Elasticsearch» — дистрибуции Elasticsearch с набором компонентов, которых так не хватало в опенсорсном Elasticsearch:
* Security — поддержка разных аутентификаций, rbac на разных уровнях, шифрование трафика и аудит;
* Event Monitoring & Alerting — создание оповещений по данным в индексам;
* Deep Performance Analysis — API для получения метрик производительности кластера;
* SQL Support — поддержка создания запросов к данным с помощью SQL;
Статья от Jeff Barr http://amp.gs/4eWD
Более общая от Adrian Cockcroft http://amp.gs/4eW0
И сам сайт проекта http://amp.gs/4eWa
2. F5 покупает Nginx.
Статья на TechCrunch http://amp.gs/4eWJ
Анонс Nginx http://amp.gs/4eWX
И от F5 http://amp.gs/4eW3
#news #elasticsearch #nginx
Forwarded from Design Lessons
Книга «Руководство по Figma»
Вышел первый бесплатный самоучитель для дизайнеров по Figma на русском от @slashdesigner. Он поможет быстро освоить инструмент или перейти на Фигму с других редакторов. Фигма детально сравнивается со Скетчем.
К книге прилагается онлайн-проект в Фигме с примерами: bit.ly/figma-examples. Любой читатель может оставлять комментарии в этом файле или скопировать его себе.
Вышел первый бесплатный самоучитель для дизайнеров по Figma на русском от @slashdesigner. Он поможет быстро освоить инструмент или перейти на Фигму с других редакторов. Фигма детально сравнивается со Скетчем.
К книге прилагается онлайн-проект в Фигме с примерами: bit.ly/figma-examples. Любой читатель может оставлять комментарии в этом файле или скопировать его себе.
Forwarded from Архитектура ИТ-решений
Gregor Hohpe (соавтор известной книжки Enterprise Integration Patterns)
Архитектурные диаграммы, как правило, показывают все отдельные части системы, но не иллюстрируют её основное назначение. Изменение этого не только делает диаграммы более выразительными, но и улучшает принятие решений https://architectelevator.com/architecture/show-the-pirate-ship/The Architect Elevator
Showing the pirate ship leads to better decision making
Architecture diagrams tend to show all the individual parts rather than illustrating the system’s key purpose. Inverting this not only produces more expressive diagrams, it also improves decision making.
Очень странная статья https://link.medium.com/YU21l5PKZU вновь разжигающая уже вроде как потухший холивар Sql vs NoSql. Понятно, что поцоны пиарятся, но все-таки тут прямо жыыырно.
Мало того, что сравниваются базы без какого-либо контекста, хотя все(Карл!) нереляционные базы являются нишевыми. Например тот же Hadoop, упомянутый в лонгриде, сейчас, в основном, используется для построения DataLake, где вся фишка как раз в отсутствии структуры данных. Или MongoDb, которая является хранилищем master-данных для стартапов(и только для них!) и призвана сократить порог входа и ТТМ как для разработчиков так и для опсов. Не говоря уже про Cassandra/CH и различные TsDb.
Кароч очень неоднозначно, но историческая ретроспектива прикольная
Мало того, что сравниваются базы без какого-либо контекста, хотя все(Карл!) нереляционные базы являются нишевыми. Например тот же Hadoop, упомянутый в лонгриде, сейчас, в основном, используется для построения DataLake, где вся фишка как раз в отсутствии структуры данных. Или MongoDb, которая является хранилищем master-данных для стартапов(и только для них!) и призвана сократить порог входа и ТТМ как для разработчиков так и для опсов. Не говоря уже про Cassandra/CH и различные TsDb.
Кароч очень неоднозначно, но историческая ретроспектива прикольная
Medium
Why SQL is beating NoSQL, and what this means for the future of data
After years of being left for dead, SQL today is making a comeback. How come? And what effect will this have on the data community?
И, кстати, Postgres как сервис в Azure -- полная шляпа.
Во-первых, нет доступа к конфигу базы и тачки, что автоматом лишает возможности подтюнить базу под свои нужды(какие-то настройки вынесены в гуй, но не все)
Во-вторых, нет возможности настроить sharded-cluster и балансировщик, в итоге что бы обеспечить хотя бы мало-мальский throughput приходится либо коня платить, либо поднимать отдельную виртуалку с pg-bouncer
Кароче, ребята из DataEgret правы: постгрес надо ставить on-premice, иначе будет беда
Во-первых, нет доступа к конфигу базы и тачки, что автоматом лишает возможности подтюнить базу под свои нужды(какие-то настройки вынесены в гуй, но не все)
Во-вторых, нет возможности настроить sharded-cluster и балансировщик, в итоге что бы обеспечить хотя бы мало-мальский throughput приходится либо коня платить, либо поднимать отдельную виртуалку с pg-bouncer
Кароче, ребята из DataEgret правы: постгрес надо ставить on-premice, иначе будет беда
Forwarded from Bang Bang Education
7 основных методов UX-исследований
UX-исследования помогают понять, как создавать продукты и сервисы, исходя из потребностей клиентов.
➖ Сортировка карточек
Самый доступный способ, который подходит для ранних этапов ux-исследования и помогает работать над информационной архитектурой вместе с пользователем. На карточках — слова или фразы, соответствующие контенту или функциям сайта. Респонденты классифицируют карточки или группируют по тому или иному принципу.
Исследование не требует специальной подготовки — можно использовать бумажные карточки, стикеры или онлайн-сервисы для удаленного тестирования.
➖Ревью эксперта
Специалист оценивает пользовательский интерфейс на предмет дизайна, удобства и доступности. Процесс и результат варьируются и зависят от опыта рецензента. Как правило, такой метод помогает очертить границы последующих улучшений перед этапом тестирования.
➖ Айтрекинг
Метод позволяет узнать, что в интерфейсе привлекает внимания пользователя, что приходится перечитывать, к какой области экрана обращается взгляд при просьбе найти тот или иной элемент или функцию и многое другое. Визуализация такого исследования зачастую представлена а виде тепловой карты. Наблюдения за тем, как пользователи в действительности смотрят сайт чаще всего убеждают клиентов и владельцев продуктов в необходимости серьезного подхода к исследованию и тестированию.
➖ Полевые исследования
Это целый блок методик, связанных с наблюдениями и живым взаимодействием с пользователями: кто они, какие у них потребности и стиль жизни, как совершаются практики, связанные с услугой, которую вы предоставляете, как они используют ваш продуктом. Важно сопоставлять ответы пользователей о том, как бы они поступили, с тем, как они поступают на самом деле. При качественном наблюдении полевые исследования дают наиболее ценные инсайты.
➖ Юзабилити тестирования
Наблюдения за тем, как пользователи пытаются решить ту или иную задачу, связанную с сайтом, с какими проблемами они сталкиваются и какие вопросы возникают по ходу. Важное и, пожалуй, единственное ограничение — респонденты должны представлять вашу целевую аудиторию. Наблюдение за ходом такого исследования сильно повышает энтузиазм и участие клиентов в процессе.
➖ Дистанционное юзабилити тестирование
Очевидное преимущество, по сравнению с обычным, в том, что вам не нужно иметь лабораторию для проведения тестов — это сокращает издержки. Другое, важнее, — результаты корректнее, когда пользователь выполняет тестирование в своей привычной, а не лабораторной среде. Вдумчивый подготовленный фидбек пользователя после такого исследования близок по сути к данным полевых исследований, таких как глубинное интервью.
➖ Создание персон
Портрет воображаемого идеального пользователя с описанием его стиля жизни, ценностей, позиции и целей, связанных с продуктом и релевантных. Персоны создаются на основе данных других методов исследований — у них есть предыстория, потрет и высказывания-инсайты. Это стимулирует воображение проектной команды и помогает фокусироваться на пользователе как на живом человек, а не абстракции.
⚫️ Сегодня в 19:00 мы проводим бесплатный вебинар с руководителем команды экспертов по клиентскому опыту в трайбе Digital Business Platform, Cбербанк Алиной Ермаковой. Тема — «Удобство продуктов: как UX помогает делать востребованные сервисы». Регистрация → bangbangeducation.ru/webinars/uxresearch
UX-исследования помогают понять, как создавать продукты и сервисы, исходя из потребностей клиентов.
➖ Сортировка карточек
Самый доступный способ, который подходит для ранних этапов ux-исследования и помогает работать над информационной архитектурой вместе с пользователем. На карточках — слова или фразы, соответствующие контенту или функциям сайта. Респонденты классифицируют карточки или группируют по тому или иному принципу.
Исследование не требует специальной подготовки — можно использовать бумажные карточки, стикеры или онлайн-сервисы для удаленного тестирования.
➖Ревью эксперта
Специалист оценивает пользовательский интерфейс на предмет дизайна, удобства и доступности. Процесс и результат варьируются и зависят от опыта рецензента. Как правило, такой метод помогает очертить границы последующих улучшений перед этапом тестирования.
➖ Айтрекинг
Метод позволяет узнать, что в интерфейсе привлекает внимания пользователя, что приходится перечитывать, к какой области экрана обращается взгляд при просьбе найти тот или иной элемент или функцию и многое другое. Визуализация такого исследования зачастую представлена а виде тепловой карты. Наблюдения за тем, как пользователи в действительности смотрят сайт чаще всего убеждают клиентов и владельцев продуктов в необходимости серьезного подхода к исследованию и тестированию.
➖ Полевые исследования
Это целый блок методик, связанных с наблюдениями и живым взаимодействием с пользователями: кто они, какие у них потребности и стиль жизни, как совершаются практики, связанные с услугой, которую вы предоставляете, как они используют ваш продуктом. Важно сопоставлять ответы пользователей о том, как бы они поступили, с тем, как они поступают на самом деле. При качественном наблюдении полевые исследования дают наиболее ценные инсайты.
➖ Юзабилити тестирования
Наблюдения за тем, как пользователи пытаются решить ту или иную задачу, связанную с сайтом, с какими проблемами они сталкиваются и какие вопросы возникают по ходу. Важное и, пожалуй, единственное ограничение — респонденты должны представлять вашу целевую аудиторию. Наблюдение за ходом такого исследования сильно повышает энтузиазм и участие клиентов в процессе.
➖ Дистанционное юзабилити тестирование
Очевидное преимущество, по сравнению с обычным, в том, что вам не нужно иметь лабораторию для проведения тестов — это сокращает издержки. Другое, важнее, — результаты корректнее, когда пользователь выполняет тестирование в своей привычной, а не лабораторной среде. Вдумчивый подготовленный фидбек пользователя после такого исследования близок по сути к данным полевых исследований, таких как глубинное интервью.
➖ Создание персон
Портрет воображаемого идеального пользователя с описанием его стиля жизни, ценностей, позиции и целей, связанных с продуктом и релевантных. Персоны создаются на основе данных других методов исследований — у них есть предыстория, потрет и высказывания-инсайты. Это стимулирует воображение проектной команды и помогает фокусироваться на пользователе как на живом человек, а не абстракции.
⚫️ Сегодня в 19:00 мы проводим бесплатный вебинар с руководителем команды экспертов по клиентскому опыту в трайбе Digital Business Platform, Cбербанк Алиной Ермаковой. Тема — «Удобство продуктов: как UX помогает делать востребованные сервисы». Регистрация → bangbangeducation.ru/webinars/uxresearch
Forwarded from Maxim Shalomovich
Классный вопрос на самом деле. С одной стороны есть "классика" с вьюпойнтами, достижениями Кратчена, SAD и всем остальным. С другой - есть Agile-команды и проекты с изменениями, эволюционная архитектура и т.д. Через недельку как раз тут - https://lanit-events-org.timepad.ru/event/920546/ - будем об этом говорить (попытаемся по крайней мере). Подключайтесь к онлайн конференции (на первый день очные места уже выбраны), приходите в остальные дни, приходите на круглый стол. Мнение сообщества и опыт реально интересны
lanit-events-org.timepad.ru
Конференция «(ИТ-) архитектор в ИТ-проектах и организациях» / События на TimePad.ru
ЛАНИТ проводит серию вечерних встреч (20, 22, 27 и 29 марта 2019), где представители отрасли поделятся своим пониманием задач архитектора в сфере информационных технологий
Forwarded from Вокруг Kubernetes в VK
Ждали @DevOps Meetup? 21 марта у нас, регистрация только что открылась – и мест не так много: https://corp.mail.ru/ru/press/events/571/
vk.company
VK / @DevOps Meetup #1
21 марта мы приглашаем на первую встречу серии @DevOps Meetup, которая проводится Mail.Ru Cloud Solutions совместно с сообществом DevOps Moscow.
Кстати, меня тут подогрели крутой презой про культуру разработки в Netflix(великом и ужасном):
Forwarded from DevOps Deflope News
Вчера Linux Foundation анонсировал Continuous Delivery Foundation, созданный для развития современных инструментов поставки.
В CDF уже захостились Jenkins, Jenkins X, Spinnaker, Tekton.
Основателях 20+ компаний, включая Netflix,Google,CloudBees,RedHat
http://amp.gs/4hRJ
В CDF уже захостились Jenkins, Jenkins X, Spinnaker, Tekton.
Основателях 20+ компаний, включая Netflix,Google,CloudBees,RedHat
http://amp.gs/4hRJ
CD Foundation
A Neutral Home for the Next Generation of Continuous Delivery Collaboration | CD Foundation
Пока ничего нигде не происходит, затру телегу за проведение собесов(
последнее время очень часто приходилось рассказывать как я провожу тех. собеседования и по каким критериям отбираю кандидатов, так что опишу все тут и буду кидаться ссылками).
Во-первых, я не проверяю софт-скилз, ответственность, усидчивость и все вот это. Для этого, кмк, есть испытательный срок, на котором вылезет 80% косяков, а это и так максимум на который можно расчитывать. Тем не менее я задаю пару общих вопросов, что бы понять общую логику и мотивацию кандидата. Обычно это что-то типа: "что вы делаете для того что бы профессионально расти?(тут я жду, что чувак расскажет про книги, которые он прочитал, курсы, которые прослушал и т.д.)", "какое было ваше самое большое достижение на предыдущем месте работы?"(тупо для затравки), "а какой был самый большой факап?"(тоже вобщем-то для затравки, но так же для понимания того готов ли чувак отвечать за свои косяки. Для того что бы чувак расслабился я, обычно, рассказываю про какой-то из своих залетов), ну и самое главное: "а чему вы научились в результате этого горького опыта?"(надо понять что чувак как-то обрабатывает обратную связь, анализирует свою деятельность и т.п.). Так же, стандартно спрашиваю чем бы чувак на 100% не хотел заниматься на работе и почему(на этом вопросе из кандидата очень часто почему-то вылезает все говно). Вот вобщем-то и все общие вопросы.
Дальше по списку идет опыт работы. Честно говоря, мне кажется, что вот прям заострять внимание тут стоит только если собеседуете синиора-помидора или выше. Дело в том, что джуны и мидлы на работе "работают работу", особо не принимая каких-то решений приводящих к глобальным последствиям. Но прослушать рассказ чувака все же надо, как минимум ради того что бы узнать почему чувак свалил(тут, как не странно, тоже выливается много говна). Для синиоров на этом история не заканчивается, т.к. ретроспектива прошлого опыта -- это единственная возможность понять готов ли чувак принимать решения и нести за них ответственность. Для этого можно попросить рассказать про архитектуру(стек/процессы/что угодно) на последнем месте работы и начать задавать вопросы из серии "а почему так, а не вот так?". Абсолютно не приемлемый ответ тут: "ну это тех. дир(тим.лид/архитектор) решил", т.к. с такими лычками надо уже участвовать в принятии решений и уметь как-то отстаивать свое мнение.
Ну и, собственно, тех. интервью. Тут ваще все просто: надо просто определить минимум скилов для кандидата при котором вы готовы взять его на позицию. У меня это обычно:
+ для джуна -- возможность как-то закрывать тикета (разраб должен знать язык на котором разрабатывает, одмен должен уметь в туллинг как системный так и в IaaC. Причем уметь/знать -- это, конечно же, подразумевает, что уметь надо хорошо)
+ для мидла -- надо уже уметь решать задачи самостоятельно(для разраба нужно уметь в дизайн, понимать как работает его софт и т.д., одмен должен мочь собрать пайплайн, поднять тачки и базы, настроить сети, опираясь на требования/спецификации)
+ синиор, как уже было сказано, должен уметь принимать архитектурные решения. Тут, соответственно , надо зарамсить за архитектуру(софтварную для разраба и деплоймент для инфраструктурщика), понимать как работает система в целом, а не конкретные сервисы, иметь какое-то понимание о трейд-офах и т.д.
Кароч все достаточно просто. Вот и все, вот и все)
последнее время очень часто приходилось рассказывать как я провожу тех. собеседования и по каким критериям отбираю кандидатов, так что опишу все тут и буду кидаться ссылками).
Во-первых, я не проверяю софт-скилз, ответственность, усидчивость и все вот это. Для этого, кмк, есть испытательный срок, на котором вылезет 80% косяков, а это и так максимум на который можно расчитывать. Тем не менее я задаю пару общих вопросов, что бы понять общую логику и мотивацию кандидата. Обычно это что-то типа: "что вы делаете для того что бы профессионально расти?(тут я жду, что чувак расскажет про книги, которые он прочитал, курсы, которые прослушал и т.д.)", "какое было ваше самое большое достижение на предыдущем месте работы?"(тупо для затравки), "а какой был самый большой факап?"(тоже вобщем-то для затравки, но так же для понимания того готов ли чувак отвечать за свои косяки. Для того что бы чувак расслабился я, обычно, рассказываю про какой-то из своих залетов), ну и самое главное: "а чему вы научились в результате этого горького опыта?"(надо понять что чувак как-то обрабатывает обратную связь, анализирует свою деятельность и т.п.). Так же, стандартно спрашиваю чем бы чувак на 100% не хотел заниматься на работе и почему(на этом вопросе из кандидата очень часто почему-то вылезает все говно). Вот вобщем-то и все общие вопросы.
Дальше по списку идет опыт работы. Честно говоря, мне кажется, что вот прям заострять внимание тут стоит только если собеседуете синиора-помидора или выше. Дело в том, что джуны и мидлы на работе "работают работу", особо не принимая каких-то решений приводящих к глобальным последствиям. Но прослушать рассказ чувака все же надо, как минимум ради того что бы узнать почему чувак свалил(тут, как не странно, тоже выливается много говна). Для синиоров на этом история не заканчивается, т.к. ретроспектива прошлого опыта -- это единственная возможность понять готов ли чувак принимать решения и нести за них ответственность. Для этого можно попросить рассказать про архитектуру(стек/процессы/что угодно) на последнем месте работы и начать задавать вопросы из серии "а почему так, а не вот так?". Абсолютно не приемлемый ответ тут: "ну это тех. дир(тим.лид/архитектор) решил", т.к. с такими лычками надо уже участвовать в принятии решений и уметь как-то отстаивать свое мнение.
Ну и, собственно, тех. интервью. Тут ваще все просто: надо просто определить минимум скилов для кандидата при котором вы готовы взять его на позицию. У меня это обычно:
+ для джуна -- возможность как-то закрывать тикета (разраб должен знать язык на котором разрабатывает, одмен должен уметь в туллинг как системный так и в IaaC. Причем уметь/знать -- это, конечно же, подразумевает, что уметь надо хорошо)
+ для мидла -- надо уже уметь решать задачи самостоятельно(для разраба нужно уметь в дизайн, понимать как работает его софт и т.д., одмен должен мочь собрать пайплайн, поднять тачки и базы, настроить сети, опираясь на требования/спецификации)
+ синиор, как уже было сказано, должен уметь принимать архитектурные решения. Тут, соответственно , надо зарамсить за архитектуру(софтварную для разраба и деплоймент для инфраструктурщика), понимать как работает система в целом, а не конкретные сервисы, иметь какое-то понимание о трейд-офах и т.д.
Кароч все достаточно просто. Вот и все, вот и все)
Forwarded from Пятничный деплой
Ещё один awesome, на этот раз про консенсус https://github.com/dgryski/awesome-consensus #consensus #awesome
GitHub
GitHub - dgryski/awesome-consensus: Awesome list for Paxos and friends
Awesome list for Paxos and friends. Contribute to dgryski/awesome-consensus development by creating an account on GitHub.
Forwarded from kamyshev.code
Исследуя GitHub
Некоторое время назад писал о процессе публикации npm-пакета.
Во время поддержки такой флоу, действительно, не требует больших усилий, но при создании нового проекта нужно сделать тысячу вещей, которые следовало бы автоматизировать. Обновление какого-то стандарта — отдельная боль, добавить одно правило линтера в десяток репозиториев — очень неприятно.
Хотелось переложить максимум забот на компьютер, и избежать этой боли. На выходных сделал библиотеку @solid-soda/noscripts, которая содержит в себе все рутинные штуки. Линтер, преттир, генерация новых версий, все там.
Теперь любой проект начинается с установки этой библиотеки.
#автоматизация
Некоторое время назад писал о процессе публикации npm-пакета.
Во время поддержки такой флоу, действительно, не требует больших усилий, но при создании нового проекта нужно сделать тысячу вещей, которые следовало бы автоматизировать. Обновление какого-то стандарта — отдельная боль, добавить одно правило линтера в десяток репозиториев — очень неприятно.
Хотелось переложить максимум забот на компьютер, и избежать этой боли. На выходных сделал библиотеку @solid-soda/noscripts, которая содержит в себе все рутинные штуки. Линтер, преттир, генерация новых версий, все там.
Теперь любой проект начинается с установки этой библиотеки.
#автоматизация