1. Лёгкий дистрибутив
   
2. Легковесное окружение рабочего стола
   
3. Быстрый софт

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

Большинство договоров пишут юристы, а руководители, продажники и клиенты, похоже их не читают. Да их и невозможно прочесть. Много ли людей читают договор с банком или лицензионное соглашение?! Или договор с оператором сотовой связи или провайдером?! Скучное и бесполезное занятие. Всё равно на текст договора чаще всего никак не повлиять в крупных компаниях.  

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

Предлагать клиентам подписать договор, который бы не хотел подписывать сам — хамство.

У нас был договор написанный простым и понятным языком. Но жизнь не стоит на месте и коллеги сказали, что нужен новый договор. И что нужно обязательно обратиться к юристу, чтобы всё профессионально было. Обратились. Получили скучнейшую простыню как у всех. Читать невозможно. 

Привет, меня зовут Сергеев Сергей aka gurugray. Сейчас я «Mentor FrontEnd Community» в компании ManyChat. Вы могли видеть мои лекции по релизному циклу и регламенту работ с системами контроля версий в Школе Разработки Интерфейсов Яндекса (ШРИ).

Меня часто спрашивают какие life-hacks или best-practices я использую при работе с Git'ом и репозиториями проекта.

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

Всем привет! Я CV-разработчик в КРОК. Уже 3 года мы реализуем проекты в области CV. За это время чего мы только не делали, например: мониторили водителей, чтобы во время движения они не пили, не курили, по телефону не разговаривали, смотрели на дорогу, а не сны или в облака; фиксировали любителей ездить по выделенным полосам и занимать несколько мест на парковке; следили за тем, чтобы работники носили каски, перчатки и т.п.; идентифицировали сотрудника, который хочет пройти на объект; подсчитывали всё, что только можно.

Я все это к чему?

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

Моделируем ситуацию

Представим, что мы устроились в молодую компанию “N”, деятельность которой связана с ML. Работаем мы над ML (DL, CV) проектом, потом по каким-либо причинам переключаемся на другую работу, в общем делаем перерыв, и возвращаемся к своей или чужой нейроночке.

1. Наступает момент истины, нужно как-то вспомнить на чем ты остановился, какие гиперпараметры пробовал и, самое главное, к каким результатам они привели.

Я делаю много ревью для чужого кода на Ансибл и много пишу сам. В ходе анализа ошибок (как чужих, так и своих), а так же некоторого количества собеседований, я понял основную ошибку, которую допускают пользователи Ансибла — они лезут в сложное, не освоив базового.

Для исправления этой вселенской несправедливости я решил написать введение в Ансибл для тех, кто его уже знает. Предупреждаю, это не пересказ манов, это лонгрид в котором много букв и нет картинок.

Ожидаемый уровень читателя — уже написано несколько тысяч строк ямла, уже что-то в продакшене, но "как-то всё криво".

• Ролевая модель доступа к данным
• Безопасность данных внутри кластера Elasticsearch
• Безопасность данных вне кластера Elasticsearch