Привет! Меня зовут Дмитрий Ли, я тимлид одной из команд разработки бэкенда в Badoo.

Когда я впервые стал тимлидом, я стал активно посещать конференции и читать умные книги об управлении командой. Однако в моей работе после этого менялось немногое. Я читал о том, каким я должен быть, в чём должен развиваться, но мне было неясно, что конкретно для этого нужно делать.

Мне пришлось не раз и не два наступить на одни и те же грабли, прежде чем я разобрался, что мешает наладить и улучшить мою работу. Поэтому для выступления на Saint TeamLead Conf я решил собрать из своего нынешнего опыта советы, которых мне не хватало на старте моей карьеры управленца. Эти вещи сильно упростили бы мне жизнь, если бы я знал о них раньше. 

Рецепты, которыми я хочу поделиться, в большей степени пригодятся начинающим тимлидам: я записал их как своеобразное наставление себе самому несколько лет назад. Эта статья написана по мотивам моего доклада на TeamLeads Conf.

Во вчерашней статье Python в Mobile development, в которой речь шла о библиотеке KivyMD (коллекции виджетов в стиле Material Design для использования их в кроссплатформенном фреймворке Kivy), в комментариях меня попросили рассказать о процессе сборки пакета для платформы Android. Для многих этот процесс, к сожалению, был и остается чем-то из ряда магического шаманства и не подъёмным для новичков делом. Что ж, давайте разбираться, так ли на самом деле все сложно и действительно ли я маг и волшебник…

В этом посте я хотел сделать демо Nginx VTS + Prometheus + Grafana. Для демо необходимо было чтобы upstream могли выдавать разные http коды. Это могли сделать следующие проекты: Mockify, написанный на Golang, и WireMock, написанный на Java.

Небольшое оглавление

• установка и настройка Nginx VTS + Prometheus + Grafana;
• Mockify — легкое, конфигурируемое эмулирование API, написанное на Golang;
• Сравнение использования CPU для Mockify, написанный на Golang, и WireMock, написанный на Java.

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

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

Уже запущена тестовая сеть и на официальном сайте есть два интересных документа, проливающих свет на то, как будет функционировать этот проект. Это описание TON, 132 страницы (ссылки на страницы в тексте указаны в круглых скобках, (45)) и описание блокчейна, 120 страниц (ссылки на страницы указаны в квадратных скобках, [55]). Виртуальная машина и язык программирования смарт-контрактов в этой статье рассматриваться не будут, кому нужно — разберёт сам, а кто не разберёт — тому не нужно.

Я для вас прочитал и попытался выделить моменты, интересующие простого обывателя (меня), оставив в стороне очень важные, но малопонятные выкладки, формулы и доказательства, все они изложены в первоисточниках выше. Надеюсь, что моё краткое изложение пригодится тем, у кого не нашлось времени или желания самолично изучить эти интереснейшие документы.

Итак, что такое Telegram Open Network (TON)?

Создать аккордеон, faq, спойлер и подобное, можно при помощи Div и JavaScript.
Но лучше: Details и Summary

Поддерживается всеми современными браузерами и это семантически правильно оформленный код, при использовании которого будут плюсы:

1. Людям с ограниченными возможностями проще будет пользоваться вашим сайтом! Их софт (скринридеры и подобное) прекрасно понимает html5 теги и будет правильно обрабатывать их и правильно информировать людей о содержимом.
2. Улучшится связанность текста, и поисковики смогут более качественно индексировать сайт, так как будут лучше понимать, как связаны между собой видимый и скрытый текст.
3. Будет доступно управление элементами с клавиатуры и других устройств.
4. Уменьшается количество javascript кода, который нужно подгружать, что увеличивает скорость загрузки страницы, скорость обработки и корректность.
5. Улучшаются показатели в Lighthouse, Google PageSpeed и других подобных инструментах.
6. Работает при выключенном javascript.

Однажды, исследуя глубины интернета, я наткнулся на видео, где человек обучает змейку с помощью генетического алгоритма. И мне захотелось так же. Но просто взять все то же самое и написать на python было бы не интересно. И я решил использовать более современный подход для обучения агентных систем, а именно Q-network. Но начнем с начала.

Обучение с подкреплением

В машинном обучении RL(Reinforcement Learning) достаточно сильно отличается от других направлений. Отличие состоит в том, что классический ML алгоритм обучается уже на готовых данных, в то время как RL, так сказать, сам создает себе эти данные. Идея RL состоит в том, что помимо самого алгоритма, который называют агентом, существует среда(environment), в которую этот агент и помещается. На каждом этапе агент должен совершать какое-то действие(action), а среда отвечает на это наградой(reward) и своим состоянием(state), на основе которого агент и совершает действие.

Новая работа Google предлагает архитектуру нейронных сетей, способных имитировать врожденные инстинкты и рефлексы живых существ, с последующим дообучением в течение жизни.

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

Хабр, привет!

Сделал подборку из 22-х сайтов для изучения английского языка.
Подборка поможет изучить английский легко, без зубрежки и учебников.

Приступим!

Учить лексику

Плагины, мобильные приложения и сайты, которые помогут перевести и запомнить незнакомые термины с русского на английский и обратно.

ЛеоПереводчик

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

Хабр, привет. Перевел пост, который идёт строго (!) в закладки и передаётся коллегам. Он со списком блокнотов и библиотек ML и Data Science для разных отраслей промышленности. Все коды на Python, и размещены на GitHub. Они будут полезны как для расширения кругозора, так и для запуска своего интересного стартапа.



Отмечу, что если среди читателей есть желающие помочь, и добавить в любую из подотраслей подходящий проект, пожалуйста, свяжитесь со мной. Я их добавлю в список. Итак, давайте начнём изучение списка.

Перед каждым сервисом, генерирующим хотя бы 1 Мбит/сек трафика в интернете возникает вопрос: «Как? по TCP или по UDP?» В прикладных областях, в том числе и платформах доставки уже сложились предпочтения и традиции принятия подобных решений.

По идее, если бы, к примеру, однажды один ленивый разработчик не попробовал развернуть свой ML на Python (потому что только его и знал), мир скорее всего никогда не проникся бы такой любовью к презренному «супер-джава-кодерами» языку. А сегодня слабости этого языка в прошлом контексте применения безоговорочно обеспечивают ему первенство в развертывании и запуске многочисленных майнерских А/Б.

Сравнивать можно многое: ARM с Intel, iOS и Android, а Mortal Kombat с Injustice. И нарваться на космический холивар, поэтому вернемся к теме доставки огромных объемов разноформатного контента.

Десять лет назад все были абсолютно уверены, UDP — это что-то про негарантированную доставку. Если нужен надежный протокол — это TCP. И вопреки традициям в этой статье мы будем сравнивать такие, кажущиеся несравнимыми вещи, как TCP и UDP.


Осторожно, под катом 99 иллюстраций и схем и все важные.

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

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

Наша компания с 2008 года занимается преимущественно управлением инфраструктурами и круглосуточной технической поддержкой веб-проектов: у нас более 400 клиентов, это порядка 15% электронной коммерции России. Соответственно, на поддержке очень разнообразная архитектура. Если что-то падает, мы обязаны в течение 15 минут это починить. Но чтобы понять, что авария произошла, нужно мониторить проект и реагировать на инциденты. А как это делать?

Я считаю, что в организации правильной системы мониторинга происходит беда. Если бы беды не было, то мой спич состоял из одного тезиса: «Установите, пожалуйста, Prometheus + Grafana и плагины 1, 2, 3». К сожалению, теперь так не работает. И главная проблема заключается в том, что все продолжают верить во что-то такое, что существовало в 2008 году, с точки зрения программных компонентов.

В отношении организации системы мониторинга я рискну сказать, что… проектов с грамотным мониторингом не существует. И ситуация настолько плохая, если что-то упадёт, есть риск, что это останется незамеченным — все ведь уверены, что «всё мониторится».
Возможно, всё мониторится. Но как?

Все мы сталкивались с историей наподобие следующей: работает некий девопс, некий админ, к ним приходит команда разработчиков и говорит — «мы зарелизились, теперь замониторь». Что замониторь? Как это работает?

Ок. Мониторим по старинке. А оно уже изменяется, и выясняется, что ты мониторил сервис А, который стал сервисом B, который взаимодействует с сервисом C. Но команда разработчиков тебе говорит: «Поставь софт, он же должен все замониторить!»

Так что изменилось? — Всё изменилось!

Давайте поговорим о покупке электронных компонентов в интернете. Я собрал список интересных отечественных и зарубежных магазинов:

а) которые заточены под любителей DIY и делают свои собственные крутые продукты: конструкторы, модули, обучающие курсы и т.д.;

б) для профи, с широкой номенклатурой электронных компонентов.

Продолжение: Часть II: зарубежные магазины

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

Kubernetes абстрагируется от физических компьютеров, которыми управляет. Только скажите ему, сколько надо памяти и вычислительной мощности, — и все получите. Ифраструктура? Не, не слыхали.

Управляя образами Docker, Kubernetes и приложения делает переносимыми. Разработав контейнерные приложения с Kubernetes, их можно деплоить хоть куда: в открытое облако, локально или в гибридную среду, — и при этом не менять код.

Мы любим Kubernetes за масштабируемость, переносимость и управляемость, но вот состояния он не хранит. А ведь у нас почти все приложения stateful, то есть им нужно внешнее хранилище.

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

К сожалению, некоторые невысокие программисты всерьёз полагают, что Dockerfile с какой-нибудь вообще любой командой внутри — это уже сам по себе микросервис и его можно деплоить хоть сейчас. Докеры крутятся, лавешка мутится. Такой подход оборачивается проблемами начиная с падения производительности, невозможностью отладки и отказами обслуживания и заканчивая кошмарным сном под названием Data Inconsistency.

Если вы ощущаете, что пришло время запустить ещё одну аппку в Kubernetes/ECS/whatever, то мне есть чем вам возразить.

English version is also available.

В предыдущей статье мы рассматривали «Подключение Multipath LUN СХД к VMware ESXi и Debian GNU/Linux». В данной статье продолжаем. Напомню, что используется конфигурация с двумя SAN-свитчами, к каждому из которых, СХД подключена двумя линками.

Подключение Multipath LUN СХД к Windows Server 2012

Multipath Input Output — это система многопутевого подключения блочных устройств. Требуется она для дублирования каналов подключения в целях повышения отказоустойчивости и производительности за счет того, что сервер может обращаться к устройству по нескольким каналам.

Вот так система видит LUN'ы без поддержки MPIO:



Если MPIO по какой-либо причине отключен, требуется включить. Для этого в «панели мониторинга» выбираем меню «управление» и пункт «добавить роли и компоненты».



В «мастере добавления ролей и компонентов» переходим к пункту «компоненты» и выбираем в списке «Multipath I/O», после чего нажимаем виртуальную кнопку «установить».

Всем привет. Как вы, возможно, знаете, раньше я все больше писал и рассказывал про хранилища, Vertica, хранилища больших данных и прочие аналитические вещи. Сейчас в область моей ответственности упали и все остальные базы, не только аналитические, но и OLTP (PostgreSQL), и NOSQL (MongoDB, Redis, Tarantool).

Эта ситуация позволила мне взглянуть на организацию, имеющую несколько баз данных, как на организацию, имеющую одну распределенную гетерогенную (разнородную) базу. Единую распределенную гетерогенную базу, состоящую из кучи PostgreSQL, Redis-ов и Монг… И, возможно, из одной-двух баз Vertica.

Работа этой единой распределенной базы порождает кучу интересных задач. Прежде всего, с точки зрения бизнеса важно, чтобы с данными, движущимися по такой базе, все было нормально. Я специально не использую здесь термин целостность, consistency, т.к. термин это сложный, и в разных нюансах рассмотрения СУБД (ACID и CAP теорема) он имеет разный смысл.

Ситуация с распределенной базой обостряется, если компания пытается перейти на микросервисную архитектуру. Под катом я рассказываю, как обеспечить целостность данных в микросервисной архитектуре без распределенных транзакций и жесткой связности. (А в самом конце объясняю, почему выбрал для статьи такую иллюстрацию).

Так как базы данных Яндекс.Денег вынуждены хранить массу второстепенной и временной информации, однажды такое решение перестало быть оптимальным. Поэтому в инфраструктуре появился распределенный Data Grid с функциями in-memory базы данных на базе Hazelcast.

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

Когда только Dropbox запустился, один пользователь на Hacker News прокомментировал, что реализовать его можно несколькими bash-скриптами с помощью FTP и Git. Сейчас такого сказать никак нельзя, это крупное облачное файловое хранилище с миллиардами новых файлов каждый день, которые не просто как-то хранятся в базе данных, а так, что любую базу можно восстановить на любую точку в течение последних шесть дней.

Под катом расшифровка доклада Славы Бахмутова (m0sth8) на Highload++ 2017, о том, как развивались базы данных в Dropbox и как они устроены сейчас.


О спикере: Слава Бахмутов — site reliability engineer в команде Dropbox, очень любит Go и иногда появляется в подкасте golangshow.com.

Содержание

• Кратко об архитектуре Dropbox
• История развития баз данных и как устроена текущая архитектура Dropbox
• Простейшие операции над базами данных (фейловеры, бэкапы, клоны, промоушены)
• Автоматизация — что управляет всеми базами данных и запускает операции
• Мониторинг
• Тестирование, стейджинг и DRT