Когда проводится один статистический тест на значимость различий, всегда есть шанс (ошибка первого рода = 5%, на уровне значимости p=0.05) получить ложный положительный результат случайно. Эта ошибка означает, что мы можем ложно утверждать, что значимое различие существует, притом, что в реальности этой значимости нет.

Когда проводится несколько однотипных тестов подряд, каждый из них имеет 5% шанс на ложный положительный результат. Если коррекция отсутствует, то вероятность, что хотя бы один из этих тестов даст ложный положительный результат, быстро возрастает.

Предположим, что делается 20 однотипных тестов. Вероятность того, что получится ложный положительный результат равна 1 - (1 - 0.05)^20 ≈ 64%.

Когда я только знакомился с принципами SOLID, я искал понятные статьи на Хабр. При этом пришлось прочитать не одну статью, и полное понимание пришло сильно позже. Хотелось бы, чтобы новички на более простых примерах смогли почувствовать, о чем эти принципы.

Привет! Меня зовут Евгений Константинов. Я занимаюсь разработкой инструментов автоматического тестирования в Яндексе. В этой статье хочу рассказать про историю создания инструмента Testplane

Testplane поможет вам:

- протестировать разные сценарии в любом браузере; 

- проверить вёрстку с помощью скриншотного тестирования; 

- выполнить тестирование ваших React-компонентов;

- запустить клиентские unit-тесты в контексте браузера. 

Привет, Хабр! Меня зовут Сергей Соловьев, я разрабатываю интерфейсы международных платежей в Тинькофф Бизнесе. Уверен, многие хотят писать надежный, поддерживаемый, но при этом лаконичный код. Как найти баланс?

TypeScript упрощает разработку веб-приложений ценой роста кодовой базы. В большинстве случаев накладные расходы, связанные с аннотацией типов, невелики и полностью компенсируются выигрышем в надежности и поддерживаемости кода. TS всеми силами пытается облегчить нам работу за счет мощной системы вывода типов, но компилятор языка не всесилен, и порой нам приходится самим указывать, какие типы мы хотим видеть.

Частный случай решения проблемы сужения типов — функции-тайпгарды. Это полезная фича языка, но ее применение может привести к появлению однотипного кода и даже увеличить риск возникновения багов. В статье рассмотрим проблемы, связанные с использованием функций-тайпгардов и один из способов их решения — создание обобщенных фабрик.

Главная рекомендация - отказаться от лимитов!

А теперь подробнее.

Когда у вас много пользователей используют один кластер Kubernetes, возникает вопрос - как задать квоты, чтобы и приложениям хватало ресурса, и не случилось ситуации, когда из-за одного прожорливого соседа страдают все поды на ноде? 

Начну с того, что самым распространенным способом является задание request и limit по CPU и RAM. С оперативной памятью все достаточно просто - при превышении потребления, OMM-Killer остановит процесс. А вот с CPU есть целый ряд нюансов и возможностей наступить на грабли.

Это происходит из-за того, что ресурс процессора делится не долями, а по времени. 

Это можно представить так

Можно ли с помощью GitHub анализировать работу, не заглядывая в монитор сотрудника — без скриншотов и тайм-трекеров?

Я Александр Кириллов, технический директор компании Evrone. Больше 20 лет я посвятил разработке. В этой статье поделюсь с вами опытом, который собрал за время работы с распределенными командами. Расскажу о том, как, не нарушая приватность разработчиков, следить за качеством работы на проектах и отслеживать нежелательные паттерны с помощью метрик в Jira и Git.

Меня зовут Алексей Шарапов. Я занимаюсь построением процессов и командами в AkBars Digital. В нашем формате работы девопсы погружены в продуктовые команды, то есть у нас не сервисная модель. Еще я разрабатываю наше внутреннее облако, автоматизирую и запускаю проекты на Kubernetes. В статье рассмотрим оба аспекта моей работы: немного поговорим про командное взаимодействие и немного про инструментарий.

Одни из самых частых вопросов от инженеров, которые я слышу: «Есть проект 10 микросервисов, пора ли запускать его в K8s или нет?» или «У нас есть проект, мы хотим поехать в K8s — надо ли нам это делать или нет?». Мы много занимались его решением, в том числе, с компаниями в формате аудита. Из этого опыта и родилась статья.

В современном мире приложение — это огромная связка микросервисов. Функционально её протестировать сложнее, чем монолит. Кто-то решает это единым staging’ом и чатиком синхронизации: «займу auth на полчасика». Другой уходит с головой в shift-left или тестирует в canary. Разберём, как катнуть веточку сервиса и получить свой личный staging.

Меня зовут Евгений Харченко, я инженер в платформе Авито. В мою ответственность входят процессы и технологии, которые связаны с разработкой кода и внедрением его в продакшен. Сегодня я хочу поговорить о том, как организовать работу с фича-ветками при разработке.

Istio Service Mesh

Мы в Namely уже год как юзаем Istio. Он тогда только-только вышел. У нас здорово упала производительность в кластере Kubernetes, мы хотели распределенную трассировку и взяли Istio, чтобы запустить Jaeger и разобраться. Service mesh так здорово вписалась в нашу инфраструктуру, что мы решили вложиться в этот инструмент.

Пришлось помучиться, но мы изучили его вдоль и поперек. Это первый пост из серии, где я расскажу, как Istio интегрируется с Kubernetes и что мы узнали о его работе. Иногда будем забредать в технические дебри, но не сильно далеко. Дальше будут еще посты.

В один прекрасный летний день к нашей команде пришла коллега из отдела контента сайта и попросила сделать инструмент для публикации информации о работе кафе и туалетов во всех магазинах страны. И все бы ничего, только мы не имеем никакого отношения к кафе и туалетам, а занимаемся “Платформой услуг”, благодаря которой наши клиенты могут нанять профессионалов в ремонте и обустройстве дома.

На мой вопрос: “Почему ты пришла к нам?” — мне был дан простой ответ: “Кафе и туалеты — это тоже услуги для клиентов!” Здесь вспоминаются слова Рене Декарта: “Если бы среди философов навсегда установилось согласие относительно значения слов, то почти все их споры были бы прекращены” (“Правила для руководства ума”).

Мы работаем продуктовой командой, и у меня встал вопрос: как описать наш продукт так, чтобы каждый понимал, что мы делаем и в чем мы можем помочь? Чтобы дать на него ответ, я решил разобраться, что означает само слово “продукт”.

Результат моих изысканий под катом…

Компьютер — это не Интернет

Прогрессивное конспектирование — это инструмент для обрабатывания потребляемой информации так, чтобы получать от этого больше пользы, чем от простого чтения. Выгружая из головы контекст и детали мы можем сохранять разум чистым для принятия нового опыта и знаний.

Современные цифровые технологии позволяют легко "захватывать" информацию из любых источников. Мы пропускаем через себя много информации, но мало из этого, что приносит настоящую пользу, а всё потому, что мы делаем это в неправильное время

Знакома ли вам такая картина описанная в названии статьи и задумывались ли вы над ответом на этот вопрос. Как ни странно один и тот же ответ может подходить для двух этих различных случаев. И там и там выигрывает тот кто правильно понимает и работает с требованиями. Но если копнуть глубже, то обнаруживается что смысл заложенный в ответ в обеих случаях очень сильно отличается.

Разбираем первый случай Для начала рассмотрим структуру требования, как такового. Ссылки что такое требование Если коротко, то у нас получается две составляющие требования. Часть которая относится к управлению. И часть которая описывает собственно содержание. Итого мы имеем управленческие атрибуты и описание сути. К управленческим атрибутам относится автор, критичность, сложность и стоимость реализации, сроки реализации и т. д..