Приветствую, коллеги! Это снова @ProstoKirReal. В прошлом цикле статей я с вами обсуждал работу интернета (Часть 1, Часть 2, Часть 3, Часть 4, Часть 5), но я специально обошел стороной самую важную часть – как биты данных передаются по локальным сетям между компьютерами и через интернет между материками.

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

Информации очень много. Точного объема статей я пока не знаю, но обещаю разложить все по полочкам максимально емко и понятно.

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

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

Я провел исследование российского рынка автозапчастей B2C – и знаете что? Большинство предпринимателей в этой нише совершают одну и ту же ошибку: они пытаются конкурировать ассортиментом и ценами, когда клиенту нужно совсем другое.

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

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

Эта статья предназначена для разработчиков, архитекторов и технических лидеров, которые ищут способы оптимизации производительности и масштабируемости своих систем.

Продолжение статьи об архитектурных паттернах для масштабируемости приложений.

Эта статья предназначена для разработчиков, архитекторов и технических лидеров, которые ищут способы оптимизации производительности и масштабируемости своих систем. Она поможет понять:

Когда стоит использовать более простые подходы (например, шардирование, репликацию, CQRS) вместо того, чтобы сразу переходить к микросервисам.

Какие trade-offs возникают при выборе каждого из паттернов или архитектурных решений.

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

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

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

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

Привет! Меня зовут Илья Валяев, я data science team lead поискового ранжирования в Авито. В статье расскажу, как у нас всё устроена система ранжирования, какие технологии используем и как именно улучшаем поисковые выдачи. 

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

Меня зовут Андрей Комягин, я СТО компании STM Labs. Мы занимаемся разработкой очень больших распределённых высоконагруженных систем для различных отраслей и в своей работе широко используем open-source решения, в том числе СУБД Redis. Недавно я подробно рассказывал об этой системе на конференции Saint HighLoad++, а теперь с удовольствием поделюсь основной информацией с читателями Хабра. Итак, поехали.

Разработчики, которые используют Go, сталкиваются с задачей выжать максимальную производительность из каждой строки кода. Но что делать, если оптимизировать уже нечего, а увеличивать скорость всё равно надо?

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

Привет, на связи ProductStar! Быть тимлидом — это не просто занимать руководящую позицию в команде. Это значит быть наставником, мотиватором и стратегическим партнером для подчиненных. Как лидер, вы отвечаете за результаты работы всей команды, но ваши обязанности не заканчиваются на контроле выполнения задач. А еще тимлиды сталкиваются с одной из самых серьезных проблем — быстрым выгоранием. Обо всем этом нам рассказал Алексей Власов.

Павел Агалецкий, ведущий разработчик в юните Platform as a Service в Авито, рассказал про семантики или гарантии доставки сообщений, и почему с ними не всегда просто разобраться.

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

Меня зовут Евгений Рейх, я руководитель разработки кластера Goods Classified в Авито. Это около 100 человек, или 10 команд, в подчинении. Больше 15 лет я занимаюсь разработкой и руковожу командами в разных компаниях. На собственном опыте знаю, какие ожидания есть у коллег. К тому же я еженедельно провожу четыре-пять собеседований на руководящие должности в Авито и понимаю, что требуется от тимлида.

Текст основан на выступлении для Avito TeamLead meetup. Он будет полезен и действующим тимлидам, и тем, кто только собирается начать руководить командой.

«Каждый, уважающий себя программист, осваивая новый язык пишет свой логгер» (с) давно было, источник цитаты канул в Лету, в общем — забылся.

Собственно вся история вопроса началась тут. Когда-то, около 3 лет назад, осваивая новый для себя язык, тоже написал свой логгер. ... Подчистки и улучшения конечно же сопровождались покрытием тестами и бенчмарками. И вот тут, для себя, сделал «открытие», что в Golang всё не совсем так, ... И так.

Для статьи был взят стандартный, библиотечный логгер из пакета log...

Примечание: поставил уровень "сложный", т.к. моя первая статья и писать "просто" для меня очень сложно. Статья для всех, кому интересно что творится под капотом Go.

Как и многие языки, Go часто использует магию под названием хип (heap). Обычно, когда мы пишем наши джейсоно-гонятели, мы просто не задумываемся об этом, хоть и знаем, что это «где-то есть». Давайте попробуем заглянуть в кроличью нору поглубже и увидеть не только то, какими методами аллокатор Go старается облегчить программисту жизнь, но и то, из чего он состоит в целом.

Меня зовут Антон Киреев, я бэкенд-разработчик с опытом работы больше 11 лет. В настоящее время работаю техлидом в Авито. В жизни мне нравятся две вещи: приносить пользу своей работой и проводить свободное время с семьёй. Именно поэтому я люблю делать что-то быстро, но качественно, а потом отдыхать. Для этого я постоянно учусь и пытаюсь докапываться до сути вещей. Сегодня поговорим, как наша любимая Гошечка работает с памятью.

Перевод статьи Лукаса Ф. Косты "Why your daily stand-ups don't work and how to fix them" с некоторыми размышлениями переводчика (выделены курсивом).

Ежедневные стендапы — классический пример выученной беспомощности. Мы все знаем, что они отстой. Тем не менее, мы ничего с этим не делаем. В наши дни мы проводим стендапы потому что нам так говорят, а не потому что они решают какие-то конкретные проблемы.

Подобная статья должна была появиться раньше, лет десять или пятнадцать назад, когда Agile только начинал внедряться в ИТ-компаниях. Сколько можно бы было избежать ошибок, проблем, конфликтов, , если бы менеджеры сразу подходили к вопросу правильно, не отвлекаясь на лишние действия …

Зато за это время накопился опыт "внедрений" Agile в разных условиях, в разных компаниях, который следует обобщить и повсеместно распространять.

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

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

Да, это очень объемный пост, и вряд ли его можно вдумчиво осилить за один подход, но поместив его в закладки он, возможно, когда-то сослужит вам добрую службу (читать его можно по частям, находясь в метро или между вечными совещаниями; да и Ctrl + F никто не отменял). Ещё ему очень не хватает оглавления для удобной навигации между вопросами, но у хабраредактора нет возможности генерировать TOC (если будут запросы об этом в комментариях — сделаю его руками). Об очепятках, пожалуйста, пишите в личку.

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

Ну а начиналось все очень мирно: мы хотели немного подтянуть сайт под обновленные требования Google.