Привет, на связи ProductStar! Быть тимлидом — это не просто занимать руководящую позицию в команде. Это значит быть наставником, мотиватором и стратегическим партнером для подчиненных. Как лидер, вы отвечаете за результаты работы всей команды, но ваши обязанности не заканчиваются на контроле выполнения задач. А еще тимлиды сталкиваются с одной из самых серьезных проблем — быстрым выгоранием. Обо всем этом нам рассказал Алексей Власов.
Пользователь
Семантики доставки событий в распределенных системах
Павел Агалецкий, ведущий разработчик в юните Platform as a Service в Авито, рассказал про семантики или гарантии доставки сообщений, и почему с ними не всегда просто разобраться.
Чего ждут коллеги разных уровней от тимлида
Обычно под требованиями и ожиданиями от тимлида подразумевают набор навыков, знаний и обязанностей. Его формализуют в виде матрицы компетенций и используют, чтобы объяснить, что должен уметь руководитель команды. При этом мало говорят о том, чего ждут и что хотят получить от тимлида люди, с которыми он постоянно взаимодействует на работе.
Меня зовут Евгений Рейх, я руководитель разработки кластера Goods Classified в Авито. Это около 100 человек, или 10 команд, в подчинении. Больше 15 лет я занимаюсь разработкой и руковожу командами в разных компаниях. На собственном опыте знаю, какие ожидания есть у коллег. К тому же я еженедельно провожу четыре-пять собеседований на руководящие должности в Авито и понимаю, что требуется от тимлида.
Текст основан на выступлении для Avito TeamLead meetup. Он будет полезен и действующим тимлидам, и тем, кто только собирается начать руководить командой.
Тестирование исполняемого кода Go
«Каждый, уважающий себя программист, осваивая новый язык пишет свой логгер» (с) давно было, источник цитаты канул в Лету, в общем — забылся.
Собственно вся история вопроса началась тут. Когда-то, около 3 лет назад, осваивая новый для себя язык, тоже написал свой логгер. ... Подчистки и улучшения конечно же сопровождались покрытием тестами и бенчмарками. И вот тут, для себя, сделал «открытие», что в Golang всё не совсем так, ... И так.
Для статьи был взят стандартный, библиотечный логгер из пакета log...
Примечание: поставил уровень "сложный", т.к. моя первая статья и писать "просто" для меня очень сложно. Статья для всех, кому интересно что творится под капотом Go.
Go To Memory
Как и многие языки, Go часто использует магию под названием хип (heap). Обычно, когда мы пишем наши джейсоно-гонятели, мы просто не задумываемся об этом, хоть и знаем, что это «где-то есть». Давайте попробуем заглянуть в кроличью нору поглубже и увидеть не только то, какими методами аллокатор Go старается облегчить программисту жизнь, но и то, из чего он состоит в целом.
Меня зовут Антон Киреев, я бэкенд-разработчик с опытом работы больше 11 лет. В настоящее время работаю техлидом в Авито. В жизни мне нравятся две вещи: приносить пользу своей работой и проводить свободное время с семьёй. Именно поэтому я люблю делать что-то быстро, но качественно, а потом отдыхать. Для этого я постоянно учусь и пытаюсь докапываться до сути вещей. Сегодня поговорим, как наша любимая Гошечка работает с памятью.
Почему ваши ежедневные стендапы не работают и как это исправить
Перевод статьи Лукаса Ф. Косты "Why your daily stand-ups don't work and how to fix them" с некоторыми размышлениями переводчика (выделены курсивом).
Ежедневные стендапы — классический пример выученной беспомощности. Мы все знаем, что они отстой. Тем не менее, мы ничего с этим не делаем. В наши дни мы проводим стендапы потому что нам так говорят, а не потому что они решают какие-то конкретные проблемы.
Как правильно имитировать Agile?
Подобная статья должна была появиться раньше, лет десять или пятнадцать назад, когда Agile только начинал внедряться в ИТ-компаниях. Сколько можно бы было избежать ошибок, проблем, конфликтов, , если бы менеджеры сразу подходили к вопросу правильно, не отвлекаясь на лишние действия …
Зато за это время накопился опыт "внедрений" Agile в разных условиях, в разных компаниях, который следует обобщить и повсеместно распространять.
Вопросы и ответы для собеседования Go-разработчика
Структурирование информации — очень полезный навык. И дабы привнести некоторый порядок в этап подготовки к интервью на должность Golang разработчика (и немножко техлида) решил записывать в этой заметке в формате FAQ те вопросы, которые я задавал, задавали мне или просто были мной найдены на просторах сети вместе с ответами на них. Стоит относиться к ним как к шпаргалке (если затупишь на реальном интервью — будет где подсмотреть) и просто набору тем, которым тебе стоит уделить внимание.
Я постарался копнуть в каждый вопрос чуть глубже чем, возможно, надо бы — что бы у читателя был не только короткий ответ на вопрос, но и некоторое понимание "а почему именно так устроена та или иная штука". Более того, крайне рекомендую ознакомиться и с ссылками на источники, что будут под ответами — там вы найдете более развернутые ответы.
Да, это очень объемный пост, и вряд ли его можно вдумчиво осилить за один подход, но поместив его в закладки он, возможно, когда-то сослужит вам добрую службу (читать его можно по частям, находясь в метро или между вечными совещаниями; да и Ctrl + F
никто не отменял). Ещё ему очень не хватает оглавления для удобной навигации между вопросами, но у хабраредактора нет возможности генерировать TOC (если будут запросы об этом в комментариях — сделаю его руками). Об очепятках, пожалуйста, пишите в личку.
Разработчик в стране DBA: как оптимизация запросов БД окончилась обнаружением «подводных камней» и багрепортом в MariaDB
Эта история про то, как искать виновника торможения запросов, если база и бэкенд переводят стрелки друг на друга; почему при обновлении базы не стоит раньше времени завершать нагрузочное тестирование; а также о том, что не всегда во встроенных инструментах оказываются те, что упомянуты в документации.
Ну а начиналось все очень мирно: мы хотели немного подтянуть сайт под обновленные требования Google.
Блокировки MySQL: виды, проблемы и способы обнаружения
Рано или поздно любой разработчик или администратор СУБД, имеющий дело с MySQL, сталкивается с проблемой блокировок. Всё дело в природе MySQL как системы с конкурентным доступом на чтение/запись. Я расскажу о видах блокировок в MySQL, их преимуществах и недостатках, о проблемах, которые они вызывают, а также дам полезные советы по обнаружению и способам борьбы с блокировками.
Go и MySQL: настраиваем пул соединений
Каждый день мы пишем код в условиях высоких нагрузок, и нередко в таких случаях сталкиваемся с проблемами, связанными с базой данных. Мы в компании используем MySQL, поэтому я расскажу про конфигурирование соединений с этой базой данных. Пройдемся по основным моментам, на которые нужно обращать внимание при работе с MySQL средствами языка Go:
• немного затронем основы клиент-серверного протокола MySQL, его базовое устройство и принципы работы;
• дальше перейдем к Go части и разберем реализацию пула соединений;
• будем двигаться от конфигурирования соединений к выполнению запросов, параллельно заглядывая в код драйвера.
Надеюсь каждый для себя найдет что-то полезное.
Автономный способ обхода DPI и эффективный способ обхода блокировок сайтов по IP-адресу
Существует два распространенных типа подключения DPI: пассивный и активный.
Пассивный DPI
Пассивный DPI — DPI, подключенный в провайдерскую сеть параллельно (не в разрез) либо через пассивный оптический сплиттер, либо с использованием зеркалирования исходящего от пользователей трафика. Такое подключение не замедляет скорость работы сети провайдера в случае недостаточной производительности DPI, из-за чего применяется у крупных провайдеров. DPI с таким типом подключения технически может только выявлять попытку запроса запрещенного контента, но не пресекать ее. Чтобы обойти это ограничение и заблокировать доступ на запрещенный сайт, DPI отправляет пользователю, запрашивающему заблокированный URL, специально сформированный HTTP-пакет с перенаправлением на страницу-заглушку провайдера, словно такой ответ прислал сам запрашиваемый ресурс (подделывается IP-адрес отправителя и TCP sequence). Из-за того, что DPI физически расположен ближе к пользователю, чем запрашиваемый сайт, подделанный ответ доходит до устройства пользователя быстрее, чем настоящий ответ от сайта.Сравнение подходов к реализации распределенных транзакций для микросервисов
Как архитектор-консультант в Red Hat, я имел возможность поработать над множеством проектов для наших клиентов. У каждого из них есть свои особенности, которые, однако, имеют некоторые общие черты. Большинство клиентов хотят знать, как скоординировать запись в несколько систем одновременно. Ответ на этот вопрос обычно включает подробное объяснение двойной записи, распределенных транзакций, современных альтернатив, а также возможных сценариев сбоев и недостатков каждого подхода. Как правило, именно в этот момент заказчик понимает, что разделение монолитного приложения на микросервисы - долгий и сложный путь, обычно требующий компромиссов.
Приёмы ускорения кода на JS и других языках: подборка от разработчика поиска Яндекса
Некоторые из приёмов будут полезны и тем, кто пишет на других языках. Все способы разделены на группы по убыванию специфичности: от наиболее общих до конкретных. Почти все примеры кода взяты из реальных проектов, из реального продакшена.
- Организационные
Культура разработки performance-first
Бюджет скорости
Performance mantras - Те, что можно использовать независимо от языка и его реализации
Смена языка или фреймворка
Смена алгоритма
Оптимизация алгоритма
Вынос инвариантов на уровень выше
Boolean short circuit
Досрочный выход из цикла
Предвычисление - Для языков/фреймворков, в которых нет ленивых вычислений и приёма copy-on-write
Shortcut fusion
Ленивое вычисление
Copy-on-write
Оверинжиниринг - Зависящие от железа
Разворачивание мелких циклов
Предсказание ветвлений (Branch prediction)
Доступ к памяти: направление итерации
Доступ к памяти: [i][j] vs [j][i] - Для языков со сборкой мусора
Мутабельность
Zero memory allocation или GC-free - Специфичные для JavaScript
Антипаттерн: накопление строк в массиве
Антипаттерн: Lodash _.defaults
Idle Until Urgent
Даунгрейд кода: ES6 → ES5 - Примеры из код-ревью
Почему мы перешли с Oracle на PostgreSQL, и как это сделать
Всем привет!
Сегодня расскажем о сравнительно новой для нас теме — про перевод приложения с Oracle на Postgres Pro (далее в тексте везде сокращу до PG). В общем смысле тема не столь уж нова — многие компании этим также занимаются или даже уже прошли этот путь. Так, например, на ежегодной конференции pgConf всегда есть несколько интересных докладов по этой теме (https://pgconf.ru/). Если говорить о формальностях, то мы реализуем инициативу согласно (Приказ Министерства связи «Об утверждении плана по импортозамещению программного обеспечения» от 01.02.2015 № 96). По факту — ещё и денег экономим, слезая с "лицензионной иглы". На эту тему можно отдельную статью написать, а в этой речь пойдёт о программной стороне вопроса. Кому интересно, добро пожаловать под кат.
Гайд начинающего тимлида
В данной статье хотелось бы помочь разобраться в профессии начинающим тимлидам, или тем, кто об этом только думает.
Всё это я проговаривал на вебинаре в Хекслете тут https://www.youtube.com/watch?v=y_HkXvFovAc
Однако я уверен, что есть такие люди, которым не хочется 2 часа смотреть вебинар, а хочется за 15 минут прочитать структурированный текст. Поэтому я размещу его тут, в надежде на то, что он найдет своего заинтересованного читателя.
Общий стаж моей работы в ИТ - около 14 лет. Я начинал с системного администрирования, потом перешел в разработку, поработав как в аутсорсе, так и в продукте. Не один раз проходил путь от рядового разработчика до тимлида.
Мифы об асинхронном PHP: он не по-настоящему асинхронный
В последнее время было достаточно много обсуждений производительности в PHP. И даже несмотря на то, что у нас есть PHP8, JIT и куча других улучшений, многие по-прежнему продолжают жаловаться на то, что PHP "недостаточно производительный". Что PHP - это язык, подходящий только для модели запрос-ответ. Что PHP слишком медленный и его не нужно использовать для высоконагруженных систем. С одной стороны от части всё это правда. Если мы строим какую-то систему, для которой вопрос производительности критичен, то использовать классический блокирующий PHP явно не стОит. Большая часть функций и библиотек PHP созданы для работы в традиционном блокирующем окружении, что уже подразумевает собой не самую высокую производительность. Однако PHP может работать быстро, более того, он может работать очень быстро. Как? Обычно у нас может быть две причины, из-за чего будет проседать производительность: мы либо совершаем какие-то сложные вычисления, либо у нас есть блокирующй ввод-вывод. Первое к сожалению (или к счастью) мы не можем решить в PHP. Но блокирующий ввод-вывод для PHP совсем не проблема. В PHP-сообществе есть люди, которые пишут асинхронный код уже на протяжении несколько лет. Конечно одновременно с этим бОльшая часть сообщества по-прежнему считает асинхронный PHP - дикостью. Я часто слышал: "Ты наверно совсем отчаянный, если собираешься писать что-то асинхронное на PHP". По правде говоря, у нас у всех есть это предубеждение, что PHP не подходит для подобного рода задач. И в большинстве случаев это предубеждение основано на неверных представлениях о самой "асинхронности". Неверные предубеждения в свою очередь ведут к неправильным ожиданиям, что в свою очередь приводит к разочарованию и обвинениям в том, что PHP "не по-настоящему асинхронный".
Микросервисы — комбинаторный взрыв версий
Во времена когда мир IT постепенно переходит на микросервисы и инструменты вроде Kubernetes, все более заметной становится лишь одна проблема. Эта проблема — комбинаторный взрыв версий микросервисов. Все же IT сообщество полагает, что сегодняшняя ситуация значительно лучше, чем «Dependency hell» предыдущего поколения технологий. Тем не менее, управление версиями микросервисов весьма сложная проблема. Одним из доказательств этому могут служить статьи вроде «Верните мне мой монолит».
DBA: «Кто-то слишком много ест!»
Тема "распухания" таблиц и индексов из-за реализации MVCC - больная для пользователей и администраторов PostgreSQL.
Однажды я уже поднимал ее в статье "DBA: когда пасует VACUUM — чистим таблицу вручную", разобрав на конкретных примерах, насколько драматический эффект для производительности запросов может оказывать невовремя проведенный или бесполезно отработавший из-за конкурентных транзакций VACUUM.
Но, помимо влияния на скорость, есть еще и факт влияния на занятое место. Наверное, вы сильно удивитесь, если таблица с единственной "живой" записью после успешного прохода autovacuum продолжит занимать гигабайты пространства на дорогих SSD.
Сегодня немного поисследуем структуру хранения данных в файлах и копнем pg_catalog - схему с описанием базы PostgreSQL, чтобы понять, как можно определить таблицы, которые явно занимают подозрительно много места.
Ваш компьютер больше не принадлежит вам
Все, приплыли, вы заметили?
Заголовок делает отсылку к предсказаниям Ричарда Столлмана 1997 года.
И Кори Докторов так же предупреждал нас.
На новых версиях macOS, вы просто не можете запустить ваш компьютер, открыть текстовый редактор, книгу, писать или читать без логирования вашей активности, которая с легкостью отправляется на сторонние серверы и хранится там во веки веков.
Information
- Rating
- Does not participate
- Location
- Россия
- Registered
- Activity