Пользователь
О времена, о нравы.
Мир переживает пандемию ковида, учёные в сжатые сроки пытаются изобрести вакцину, чтобы спасти как можно больше людей. Но задумывались ли вы когда-нибудь, как влияет на жизни казалось бы банальный недосып?
Он не станет явной причиной смерти человека, ведь каждый сам расставляет приоритеты и решает, спать ему или нет. Отсутствие здорового сна незаметно подтачивает внутренние ресурсы: влияет на восприятие мира, мешает восстановительным процессам и буквально захламляет нам мозг.
«Вот бы вообще не спать, я бы столько всего успевал сделать!» — наверное, так мечтал почти каждый.
Есть и те, кто относятся ко сну с пренебрежением: «Лягу сегодня попозже, часа в 3 ночи». Неважно, остались ли незаконченные дела у человека или он решил досмотреть сериал — так повторяется изо дня в день. А вставать, как всегда, по будильнику в 7:00. Кто-то даже гордится тем, как мало он спит. Подумаешь недосып?
Есть ли тут повод для гордости? Скорее наоборот.
Графовые рекомендательные системы показывают state of the art результаты, но про них редко пишут и еще реже используют в продакшене. В этой статье мы расскажем про опыт Одноклассников в применении графового подхода для задачи рекомендации групп, разберем причем тут нейросети и что делать, если не все рекомендации одинаково полезны для пользователей и портала.
С Elasticsearch сталкиваются многие. Но что происходит, когда хочешь с его помощью хранить логи «в особо крупном объёме»? Да ещё и безболезненно переживать отказ любого из нескольких дата-центров? Какой стоит делать архитектуру, и на какие подводные камни наткнёшься?
Мы в Одноклассниках решили при помощи elasticsearch решить вопрос лог-менеджмента, а теперь делимся с Хабром опытом: и про архитектуру, и про подводные камни.
Мы, в ProtocoleOne, пишем разные проекты и почти все они Open Source. И так уж сложилось, что крутые специалисты живут в разных городах и даже странах и не только в столицах.
Один из таких проектов — PaySuper. Проект для монетизации игровых проектов и упрощения приема платежей.
Я каждый день работаю с множеством крутых парней, списываюсь и разговариваю на утренних созвонах, и, приехав как-то раз в офис, из них всех я встретил… одного.
Все остальные были где-то в “виртуальном” мире, соединенным со мной оптоволоконной линией. И при всем этом нам удается разрабатывать сложные, долгие и крутые (ну по крайней мере я так думаю :) ) проекты.
Как? Давайте попробуем разобраться.
В общем и целом, эта статья — мой личный опыт, но я попробовал его разбавить мнением с “другой стороны”, а именно со стороны тим-лидов и технического директора.
В свободное и не свободное время[1] я развиваю несколько своих проектов на github, а также, по мере сил, участвую в жизни интересных для меня, как программиста, проектах.
Недавно один из коллег попросил консультацию: как выложить разработанную им библиотеку на github. Библиотека никак не связана с бизнес-логикой приложения компании, по сути это адаптер к некоему API, реализующему определённый стандарт. Помогая ему, я понял что вещи, интуитивно понятные и давно очевидные для меня, в этой области, совершенно неизвестны человеку делающему это впервые и далёкому от Open Source.
Я провел небольшое исследование и обнаружил что большинство публикаций по этой теме на habrahabr освещают тему участия (contributing), либо просто мотивируют каким-нибудь образом примкнуть к Open Source, но не дают исчерпывающей инструкции как правильно оформить свой проект. В целом в рунете, если верить Яндекс, тема освещена со стороны мотивации, этикета контрибуции и основ пользования github. Но не с точки зрения конкретных шагов, которые следует предпринять.
Так что из себя представляет стильный, модный, молодёжный Open Source проект в 201* году?
Этот пост является версией моей же англоязычной статьи "How to avoid gotchas in Go", но слово gotcha не переводится на русский, поэтому я буду использовать это слово как без перевода, так и немного непрямой вариант — "наступать на грабли".
Gotcha — корректная конструкция системы, программы или языка программирования, которая работает, как описано, но, при этом, контринтуитивна и является причиной ошибок, поскольку её легко использовать неверно.
В языке Go есть несколько таких gotchas и есть немало хороших статей, которые их подробно описывают и разъясняют. Я считаю, что эти статьи очень важны, особенно для новичков в Go, поскольку регулярно вижу людей, попадающихся на те же грабли.
Но один вопрос меня мучал долгое время — почему я сам никогда не делал этих ошибок? Серьезно, самые популярные из них, вроде путаницы с nil-интерфейсом или непонятного результата при append()-е слайса — в моей практике никогда не были проблемой. Каким-то образом мне повезло обойти эти подводные камни с первых дней своей работы с Go. Что же мне помогло?
И ответ оказался довольно прост. Я просто очень вовремя прочёл несколько хороших статей о внутреннем устройстве структур данных в Go и прочих деталях реализации. И этого, вполне поверхностного на самом деле, знания было достаточно, чтобы выработать некоторую интуицию и избегать этих подводных камней.
Знаете такую книжку «Магическая уборка» (англ.: «The Life-Changing Magic of Tidying Up») Мари Кондо? Это крайне популярный среди домохозяек (но не только) томик про изменение поведения, замаскированный под набор эссе об уборке и организации своего дома.
Если в двух словах, Мари топит за то, чтобы выбросить все лишнее из вашей жизни. Но в отличие от минималистов, которые решили к черту избавиться от вещей из-за карьерного выгорания, у Мари есть четкий метод как организовывать свою жизнь: начать с одежды и вещей, дальше делать это с предметами, мебелью, книгами, телеграфами, вокзалами и далее по списку. Ключевая идея: выкидывать из жизни то, что не приносит радости, а остальное организовать так, чтобы жизнь оказалась более стройной, собранной, благодатной.
Пару месяцев назад Мари запустила одноименное супер-популярное шоу на Netflix. Это большой майлстоун: охват интернет-гиганта — свыше ста миллионов зрителей. В своем шоу Мари делится советами об организации жизни, и хотя ее фокус — это всегда дом, Мари не останваливается на бытовых вопросах.
Я бы сказал так: идея в том, что в эпоху постоянных отвлечений очень сложно найти свою практику центрирования. Для многих людей, которые не готовы нанимать коучей или идти в духовность, Мари заполняет нишу чем-то доступным и простым: работой над собственной средой обитания.
На этой неделе стало известно, что Мари поднимает раунд, лид инвестор — Sequoia Capital, речь идет о сумме $40M. Удивительно то, что речь идет о личном бренде, об истории одного человека, который решил скейлить свою практику. Вероятней всего, через технологии.
Привет и с возвращением! Это вторая часть статьи о настройке кластера Kubernetes на «голом железе». Ранее мы настраивали НА-кластер Kubernetes с помощью внешнего etcd, схемы «ведущий-ведущий» и балансировки нагрузки. Ну а теперь пришло время настроить дополнительную среду и утилиты, чтобы сделать кластер полезнее и максимально приближенным к рабочему состоянию.
В этой части статьи мы сосредоточимся на настройке внутреннего балансировщика нагрузки сервисов кластера — это будет MetalLB. Также мы установим и настроим распределенное хранилище файлов между нашими рабочими нодами. Будем использовать GlusterFS для постоянных томов, которые доступны в Kubernetes.
После выполнения всех действий схема нашего кластера будет выглядеть следующим образом:
