Истории успеха любят все. И на хабре их достаточно много.

«Как я получил работу с зарплатой 300 000 долларов в Кремниевой долине»
«Как я получил работу в Google»
«Как я заработал 200 000 $ в 16 лет»
«Как я попал в Топ AppStore с простым приложением курса валют»
«Как я …» и еще тысяча и одна подобная история.

Это же здорово, что человек добился успеха и решил об этом рассказать! Читаешь и радуешься за него. Но большинство таких историй объединяет одно: ты не можешь повторить путь автора! Либо ты живешь не в то время, либо не в том месте, либо ты родился мальчиком, либо…

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

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

Прим. перев.: Service mesh'и определённо стали актуальным решением в современной инфраструктуре для приложений, следующих микросервисной архитектуре. Хотя Istio может быть на слуху у многих DevOps-инженеров, это довольно новый продукт, который, будучи комплексным в смысле предоставляемых возможностей, может потребовать значительного времени для знакомства. Немецкий инженер Rinor Maloku, отвечающий за облачные вычисления для крупных клиентов в телекоммуникационной компании Orange Networks, написал замечательный цикл материалов, что позволяют достаточно быстро и глубоко погрузиться в Istio. Начинает же он свой рассказ с того, что вообще умеет Istio и как на это можно быстро посмотреть собственными глазами.

Istio — Open Source-проект, разработанный при сотрудничестве команд из Google, IBM и Lyft. Он решает сложности, возникающие в приложениях, основанных на микросервисах, например, такие как:

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

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

Это новая статья из разбора задач с собеседований в Google. Когда я там работал, то предлагал кандидатам такие задачи. Потом произошла утечка, и их запретили. Но у медали есть обратная сторона: теперь я могу свободно объяснить решение.

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

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

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

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

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

Привет! Меня зовут Азат Зулькарняев, я занимаюсь разработкой iOS-приложений в компании Badoo. При создании мобильных приложений большая часть времени уходит на разработку UI, и оптимизация этого процесса всегда является актуальной темой в среде разработчиков. Мой коллега Алексис Сантос написал статью о том, с какими проблемами мы столкнулись и как двигались в сторону их разрешения при работе над этой задачей. Я решил поделиться с вами переводом. Также рекомендую посмотреть запись недавнего доклада Игоря Савельева на Mobius 2018.

Несколько месяцев назад я наткнулся на очень интересный документальный сериал от Netflix — «Абстракция: Искусство дизайна». В нём подробно рассматривается работа дизайнеров из разных сфер: архитектура, графический дизайн, мода и т. д. Нетрудно заметить определённое сходство их работы с деятельностью iOS-разработчиков, занимающихся реализацией пользовательских интерфейсов. В частности, ведя работу над крупным проектом, дизайнеры стараются разбить её на множество мелких задач по принципу «разделяй и властвуй» и получают возможность собрать все элементы воедино на более позднем этапе.

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

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

Но все уже осознали, ведь жить с этим как-то надо. А Java программисты даже неплохо живут. Потому что в Java есть модель памяти — Java Memory Model (JMM), которая предоставляет достаточно простые правила для написания корректного многопоточного кода.

И правил этих достаточно для большинства программ. Если вы их не знаете, но пишите или хотите писать многопоточные программы на Java, то лучше как можно скорее ознакомиться с ними. А если знаете, но вам не хватает контекста или интересно узнать откуда растут ноги у JMM, тогда статья может вам помочь.

Как оптимизировать обработку изображений в рантайме, когда необходимо создать 6 изображений, каждое из которых состоит из последовательно наложенных 15-16 PNG, не получив OutOfMemoryException по дороге?

TL; DR

Поднимаем кластер для обслуживания веб-приложений без записи состояния (stateless web applications) вместе с ingress, letsencrypt, не используя средства автоматизации вроде kubespray, kubeadm и любых других.
Время на чтение: ~45-60 минут, на воспроизведение действий: от 3-х часов.

Преамбула

На написание статьи меня сподвигла потребность в своём собственном кластере kubernetes для экспериментов. Автоматические решения установки и настройки, которые есть в открытом доступе, не работали в моем случае, так как я использовал не-мейнстримовые дистрибутивы Linux. Плотная работа с kubernetes в IPONWEB стимулирует иметь такую площадку, решая свои задачи в комфортном ключе, в том числе и для домашних проектов.

Компоненты

В статье будут фигурировать следующие компоненты:

— Ваш любимый Linux — я использовал Gentoo (node-1: systemd / node-2: openrc), Ubuntu 18.04.1.
— Kubernetes Server — kube-apiserver, kube-controller-manager, kube-scheduler, kubelet, kube-proxy.
— Containerd + CNI Plugins (0.7.4) — для организации контейнеризации возьмем containerd + CNI вместо docker (хотя изначально вся конфигурация была поднята на docker, так что ничего не помешает использовать его в случае необходимости).
— CoreDNS — для организации service discovery компонентов, работающих внутри kubernetes кластера. Рекомендована версия не ниже 1.2.5, так как с этой версии появляется вменяемая поддержка работы coredns в качестве процесса, запущенного вне кластера.
— Flannel — для организации сетевого стека, общения подов и контейнеров между собой.
— Ваша любимая db.

Вы уже слышали о новом подходе JAMstack? Возможность писать веб-приложения на любимом фреймворке, управлять контентом из админ панели, а на выходе получать полностью валидные HTML-страницы построенные согласно с самыми последними рекомендациями SEO, PWA и a11y.

Интересно? Тогда вот список рассматриваемых вопросов в этой статье:

• Что это за новый стек и зачем он нужен?
• Как запустить базовое приложение используя Gatsby?
• Работа с Contentful и создание первой порции данных
• Как связать Contentful и Gatsby используя GraphQL?
• Настроить автоматический деплоймент используя Netlify

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

Те, кто давно занимается поисковой оптимизацией, хорошо знают об операторах расширенного поиска Google. Например, почти все знают об операторе site:, который ограничивает поисковую выдачу одним сайтом.

Большинство операторов легко запомнить, это короткие команды. Но уметь эффективно их использовать — совсем другая история. Многие специалисты знают основы, но немногие по-настоящему овладели этими командами.

В этой статье я поделюсь советами, которые помогут освоить поисковые операторы для 15 конкретных задач.

The Guardian — одна из крупнейших британских газет, она основана в 1821 году. За без малого 200 лет существования архив накопился изрядный. По счастью, далеко не весь он хранится на сайте — всего за какие-то последние пару десятков лет. В базе данных, которую сами англичане назвали «источником истины» для всего онлайн-контента, около 2,3 млн элементов. И в один прекрасный момент они осознали необходимость миграции с Mongo на Postgres SQL — после того, как одним жарким июльским днём в 2015 году процедуры аварийного переключения были подвергнуты суровому испытанию. Миграция заняла без малого 3 года!..

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

Меня зовут Кевин и я хотел бы рассказать о том, как нехитрым способом отделался от рекрутерского спама. Я фронтенд-разработчик с хорошей работой, стою во главе команды из семи человек. Но рекрутеры заваливают меня письмами до такой степени, что иногда просто неохота заходить в почту. Я уже заранее знаю, что там будут они, со всеми этими «Надеюсь, у вас все идет хорошо» и «Нет ли у вас желания побеседовать?». Нет, ни малейшего. Я хочу, чтобы меня оставили в покое заниматься задачами и выполнять работу, которая у меня уже есть.

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

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



Может показаться, что мы отказали пользователю в его мечте о вертикальной реальности, но на самом деле буква К просто стоит на клавиатуре рядом с буквой У.

В этой статье мы разберём один из классических подходов к исправлению опечаток, от построения модели до написания кода на Python и Go. И в качестве бонуса — видео с моего доклада «”Очки верткальной реальности”: исправляем опечатки в поисковых запросах» на Highload++.

Привет, Хабр! Со временем, маркетологам начинает хотеться делать воронки ремаркетинга по событиям, а потом еще и преследовать по всем каналам.

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

Чтобы было проще масштабировать ремаркетинг на другие системы, сейчас мы сделаем синхронизацию событий GA в Метрику, Facebook, VK, MyTarget.


Поехали!

Хотел написать на эту тему подробную статью, но, очевидно, руки не доходят. Посему краткое сообщение. Я разработал и реализовал на нескольких языках в виде прототипного кода версию протокола MQTT под рабочим названием MQTT/UDP. Для нетерпеливых и тех, кому уже всё понятно и очевидно, код на Гитхабе

Зачем

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

За это время я выяснил (да, впрочем, и до того понимал), что главное свойство систем УД — надёжность.

Все системы с центральным узлом по определению ненадёжны. Отсюда — желание получить интерконнект компонент системы (а их в реальном умном доме много) без использования какого-либо центрального хаба.

В самом сердце информационно-поисковых систем Meltwater и Fairhair.ai работает набор кластеров Elasticsearch с миллиардами статей из СМИ и социальных медиа.

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

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