Привет, Хабр! Представляю вашему вниманию перевод статьи "Docker Tips: Clean Up Your Local Machine" автора Luc Juggery.

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

Считается, что построение CI/CD - задача для DevOps. Глобально это действительно так, особенно если речь идет о первоначальной настройке. Но часто с докручиванием отдельных этапов процесса сталкиваются и разработчики. Умение поправить что-то незначительное своими силами позволяет не тратить время на поход к коллегам (и ожидание их реакции), т.е. в целом повышает комфорт работы и дает понимание, почему все происходит именно так.

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

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

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

Все примеры изначально писались для СУБД SQLite, но почти всё из этого применимо также и к другим СУБД.

Здесь есть и примеры довольно сложных запросов с агрегирующими функциями, триггерами, длинными подзапросами, с оконными функциями. Помимо этого, часть примеров посвящена работе с SQL в Python, используя sqlite3, pandas, polars. Этот список запросов с комментариями можно использовать как наглядное пособие для изучения SQL.

Всем салют!

Хочу рассказать вам историю о том, как я начинал с уровня — «не могу решить даже 1 easy задачу из 10» до уровня — «могу решить каждую вторую medium задачу» и прошел несколько coding сессий в таких компаниях как Meta, Booking, Careem, Avito...

Привет, Хабр! Меня зовут Олег Хромов, в МТС я руковожу центром «Управление разработкой». В статье расскажу, как мы оцениваем производительность IT-специалистов. Универсальные методы работают плохо, поэтому мы пришли к специально адаптированному для IT подходу под названием DevX. Именно его я и советую применять.

Почему я затрагиваю эту тему? Дело в том, что в МТС я взаимодействую с большим количеством кодеров в МТС и моя главная задача — сделать их счастливыми и эффективными одновременно. Подробнее обо всём этом — под катом.

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

Я решил посвятить свою первую статью SQL. Вопросы, рассмотренные ниже мне задавали на собеседованиях на позицию python-разработчика. Естественно отвечать правильно получалось не всегда, а если точнее то чаще не правильно, однако проведя N часов в рефлексии я составил перечень ответов, которыми пользуюсь до сих пор.

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

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

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

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

Часто, став руководителем, человек воодушевляется: сложные задачи и новые цели кажутся по плечу, хочется всех заонбордить, пробовать лучшие практики и создать классную атмосферу в своей команде. В реальности всё иначе, и большинство негативных моментов связано с темой увольнения людей. Многие тимлиды откладывают сложные решения на потом или предпочитают считать офбординг не своей задачей, что заниматься этим должен кто-то другой. Но увольнение — это целый процесс с последствиями для всей команды, проекта и бизнеса. Последние исследования говорят, что стоимость замены одного специалиста на рынке труда — это от 40 до 200 % годового фонда оплаты труда сотрудника. Число, достойное внимания. Поэтому каждому тимлиду и руководителю важно учиться управлять датой увольнения своих людей.

За основу этой статьи взято выступление Веры Маневич, HRD в Одноклассниках. Она больше 18 лет в HR на различных ролях пипл-менеджмента. Преподаёт в MBA, ментор на getmentor.dev. Мы рассмотрим разные грани работы с офбордингом и увидим его глазами тимлида. Разберём, почему люди уходят, можно ли управлять датой увольнения, как построить культуру офбординга и говорить на эту тему с командой.

Всё началось с того, что команде, с которой я работаю, предложили заказ на миграцию приложений из Docker Compose «во что‑нибудь более масштабируемое, отказоустойчивое и гибкое». Например, Ansible или Kubernetes. И всё это прекрасно, но у меня возникли проблемы. Как системному аналитику и по совместительству PM проекта, с минимальным опытом в DevOps, пришлось изрядно попотеть с пониманием многих вещей, касающихся Kubernetes. Под катом подробно о статьях и книгах, которые помогли мне разобраться с оркестратором, понять, чего хочет заказчик, сформировать требования к работе системы в целом, отказоустойчивости, масштабированию и безопасности.

Привет! Я Наталья Калачева, Frontend-разработчик в AGIMA. Эта статья посвящена правилам, которые помогают упростить поддержку и расширение приложений на Vue. Тут я рассказываю, как организовать хранение компонентов, стилей и плагинов, когда использовать стор и полезные функции Vue. Первые 3 принципа я опубликовала вчера. Здесь еще 3.

Привет! Меня зовут Наташа Калачева. Я Frontend-разработчик в компании AGIMA. Vue — один из самых популярных фреймворков JS, его используют для разработки SPA и PWA. А его главные плюсы — это понятная, четкая документация, готовая структура и низкий порог входа.

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

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

Следуя этим рекомендациям, вы сможете создавать более эффективные проекты.

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

Привет, меня зовут Максим Кульгин. Написал из нашего опыта, как с минимальными вложениями (насчитал прямых затрат на 95 500 руб.) можно сделать ИТ-бизнес в России. В этой статье вы не найдете такие термины, как: 'выгорание', 'питч', 'custdev', 'ментор', 'product market fit', 'k8s', 'mrr/cac/ltv', 'burn rate', 'криптокочевник', 'номад' и т. п. Просто шпаргалка по приземленным этапам, которые проходили мы сами.

Я никого не учу, пишу свое мнение из личного опыта, не считаю, что написанное ниже истина и уверен, что есть множество других «тропинок на вершину горы Фудзи». Более того, если вы поделитесь своим опытом в комментариях — буду признателен. Исхожу из того, что у вас в команде есть минимум два человека (техника и маркетинг). Сделал статью в виде простых шагов от идеи до рабочего бизнеса с максимальной детализацией, где это возможно. Разумеется, я учел не все, ведь скорее всего ваш путь будет отличаться от нашего.

Подчеркну — речь пойдет про то, как запустить ИТ- бизнес «с нуля» (пусть это будет SAAS, например — сервис транзакционных почтовых рассылок, взамен покинувших наш рынок западных аналогов) до первой выручки. Уже потом надо будет учить упомянутые в заголовке статьи нужные и важные термины.

Итак…попробую расписать по шагам.

1. Идея. Кто-то говорит, что идея имеет решающее значение, а кто-то уверен ровно наоборот — «идея ничего не стоит». Все наши рабочие идеи приходят от запросов клиентов, которые готовы за них платить, а все то, что придумали сами — потерянные деньги и время. Лично мне, например, нравится идея сделать SAAS для транзакционных писем, даже зарегистрировал домен mailcheap.ru (дальше регистрации дело не дошло).

Миша – удивительный чувак. Поразительный и заразительный. Лучший руководитель в региональной IT-компании. Ещё и офигенный программист.

Мы разговаривали всего полчаса, а он успел меня заразить. Вот вы сейчас о чём подумали? Ну, явно не о насморке… Наверное, что он увлечённо рассказывает о повышении эффективности? Новых технологиях? Цифровизации? И я прям такой наслушался и кинулся статью писать?

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

И его лень заразительна. Так заразительна, что мне лень писать много букв. В кои-то веки буду краток.

На протяжении жизни мы привыкли опираться на свой опыт при оценке успешности того или иного планируемого действия как смена работы, заведение отношений, возможности подтянуться тридцать раз или красиво выступить на публику. Если опыт был положительный, то мы с большей вероятность предполагаем позитивный исход, если негативный - наоборот.

И здесь невольно приходит аналогия с банковской скоринг-системой (имел опыт работы в МФО в 2016-2018 годах, так что моё представление о скоринге, вероятно, устарело), которая анализирует данные множества заёмщиков и выдает свой вердикт. Все понятно и логично.

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

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

В какой-то момент времени я превратился в педанта брюзгу. В фильмах малейшие нестыковки и провалы в логике портят мне весь просмотр. В чатах меня бесит it's вместо its. А в статьях про программирование... Всё плохо. За меня всё уже сказал @AlexanderAstafiev, я лишь процитирую:

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

Самое забавное, что, по моим ощущениям, везде я вижу одни и те же классы проблем. Я даже запилил сервис, где можно закинуть код и получить код ревью, и, собрав немного статистики, понял, что 50 типов ошибок достаточно, чтобы покрыть большую часть проблем в чужом коде. Но выборка у меня была небольшая, и я подумал: а что, если проверить много кода?

Всем привет! Я Ирина, руководитель по обеспечению качества в Тинькофф Страховании. Тинькофф давно не просто банк, а экосистема со множеством направлений, такими как Инвестиции, Мобайл, Страхование, Бизнес и прочие. В каждом направлении есть ИТ-команды, которые постоянно что-то улучшают, развивают, разрабатывают и релизят. При этом в каждой команде свои процессы и подходы к метрикам.

В конце 2020 года перед нами встал вопрос: как придумать инструмент для измерения качества, который бы мог применяться не в отдельной команде, а в целой компании? В этой статье я расскажу, как мы внедряли единые метрики, с какими проблемами столкнулись, куда движемся сейчас и почему метрики — это важно.