Shopify — это один из крупнейших конкурентов Amazon в сфере онлайн‑ритейла. В компании работает около 10 000 человек. Shopify, в отличие от Amazon — централизованной торговой площадки, предлагает коммерческим структурам платформу для создания их собственных онлайн‑магазинов и веб‑сайтов. Shopify — это одна из крупнейших технологических организаций, в которой применяется полностью удалённый режим работы. Она перешла к такой модели в начале 2020 года. Это — одна из последних компаний такого размера, которая не переводит сотрудников обратно в офисы. По крайней мере — пока не переводит.

Shopify находится в самом разгаре внесения серьёзных изменений в свои процессы разработки ПО и в свою систему распределения сотрудников по уровням. Новая система основана на концепции «мастерства». В её рамках существующие уровни делятся на более мелкие части. Компания планировала ввести в строй эти новые «уровни мастерства» в мае, но она немного отстаёт от графика. Правда, даже учитывая это, изменения в уровнях сотрудников уже начались.

Я поговорил с несколькими инженерами‑программистами и менеджерами, которые сейчас работают в Shopify. Мне было интересно узнать от них о том, как в компании работает система уровней сотрудников, что вкладывается в понятие «мастерство», почему компания решила сделать то, что сделала. В этом материале мы исследуем следующие вопросы:

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

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

Привет! Меня зовут Саша и я обычный программист, который пишет код, документацию иногда пишет статьи или посты, но уж точно и не любит и не касается всех этих банковских дел. В этом я придерживаюсь принципа “Настроил один раз — работает и не трогай”, но в 2022 все пошло не по плану.

Привет, Хабр! Меня зовут Тимур, я тружусь ML-инженером в одной сибирской IT-компании.

Данная статья представляет собой руководство по Poetry. Я постарался покрыть все основные сценарии использования и возможности данного инструмента: создание проекта, работа с зависимостями из различных источников, управление виртуальными окружениями, сборка и публикация.

В качестве бонусов - готовая GitLab CI джоба для сборки и публикации пакетов, а также шаблон Dockerfile для multi-stage сборки образов в проектах с использованием Poetry.

Добро пожаловать под кат!

Инструкция написана для сервиса github. Вам нужно войти в свой аккаунт или зарегистрироваться.

Все команды вводятся в терминале.

Шаг 1

Делаем fork (копию) нужного проекта. Переходим в свой аккаунт и заходим в только что созданный fork.

Недавно я получила одобрение своего бизнес плана от испанской компании Enisa (которая выдает официальное резюме вашему проекту) и вместе с ним ВНЖ Испании на 3 года.

Бизнес‑план и все документы я писала и подавала самостоятельно, по инструкции от ребят из чата «Стартап‑виза в Испании», и решила написать эту статью, собрав ее из рассказов и рекомендаций, которые почти каждый день пишу друзьям и знакомым, обращающихся с просьбой описать подробности.

История закона о стартапах

Этот закон существует с 2013 года, и много наших соотечественников получали по нему ВНЖ, но 21 декабря 2022 года в него внесли некоторые изменения.

Во‑первых функцию ревью и оценки бизнес‑плана передали в Enisa, во‑вторых увеличили срок выдаваемого ВНЖ(с 1 года до 3 лет). До апреля у Enisa не было новых регламентов, а когда они появились, началась некоторая чехарда (и продолжается до сих пор), но мой стартап был одобрен как раз во время этой пересменки.

С новым регламентом добавились еще изменения — теперь нужно показывать на счету фаундера совсем другие суммы (суммы выросли, но зато появилась возможность демонстрировать другие активы, не только деньги на счетах), сократятся сроки приема (через полгода после принятия регламентов, сейчас сроки еще плавают), и бизнес‑план теперь загружается не в свободной форме, а по форме Enisa, у них на сайте.

Глубокое понимание внутреннего устройства DRBD позволяет более тонко настраивать работу системы и правильно планировать ресурсы. К счастью, у команды DRBD уже есть отличная документация, которая довольно подробно разбирает эту тему. Мы опирались на нее в своей работе, и решили перевести и выложить в открытом доступе 17-ю главу — как удобную шпаргалку по внутреннему устройству DRBD. Так что это не обычная статья, а перевод части официальной документации (исходная нумерация разделов сохранена).

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

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

Привет, Хабр! Мы много разговариваем про найм, и решили запустить новую рубрику — разбор резюме. В ней наши профессиональные HR, которые регулярно просматривают сотни резюме, будут смотреть на присланные CV специалистов и советовать, что в них можно улучшить. Делать мы это будем именно с точки зрения HR-специалистов: они расскажут, что именно их бы оттолкнуло, а что — привлекло. Начнем с резюме бэкендера и дальше пойдем по другим профессиям.

Так исторически сложилось, что последние 5 лет своей продуктовой разработки я работаю с микросервисами вокруг брокеров сообщений (преимущественно RabbitMQ и Kafka).

И все это время меня не покидало чувство некой неудовлетворенности и неполноценности инструментария, который был мне доступен.

Приходя из мира HTTP фреймворков ты чувствуешь себя как будто на костылях - ни тебе hotreload'а, который есть практически в любом wsgi-asgi сервере, хочешь тестировать - поднимай контейнеры окружения или мокай зависимости (особенно удобно в CI, ага), не забудь о реконнектах, логировании, трассировке и тд и тп.

И вот, таская от сервиса к сервису ворох всех этих проблем (и код который эти проблемы решает), до меня дошла гениальная идея: оформить весь однотипный код, общий для всех сервисов в единый пакет!

Так появился на свет фреймворк Propan.

Продолжаю цикл статей по разработке ETL-процессов на Python. На этот раз мы преобразуем синхронный etl-процесс из статьи Пишем ETL-процесс на Python в асинхронный.

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

У «Эффективного Менеджмента» всего 2 всадника Апокалипсиса: жадность и глупость. Остальных просто оптимизировали за ненадобностью, достаточно и этих. К сожалению, достаточно для того, чтобы время от времени в разных концах света происходили техногенные катастрофы. Аварии, крушения, взрывы и прочие происшествия, которые можно было бы избежать, если бы руководство компаний уделяло внимание борьбе критическим рискам. Или хотя бы не способствовало их скорейшему приближению.

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

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

Всем привет. Меня зовут Добрый Кот Telegram.

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

Вошли и вышли, приключение на 20 минут)

От коллектива FR-Solutions и при поддержке @irbgeo Telegram : Продолжаем серию статей о K8S.