Привет, Хабр! Мы в Badoo активно работаем над производительностью PHP, поскольку у нас достаточно большая система на этом языке и вопрос производительности — это вопрос экономии денег. Более десяти лет назад мы создали для этого PHP-FPM, который сначала представлял собой набор патчей для PHP, а позже вошёл в официальную поставку.

За последние годы PHP сильно продвинулся вперёд: улучшился сборщик мусора, повысился уровень стабильности — сегодня на PHP можно без особых проблем писать демоны и долгоживущие скрипты. Это позволило Spiral Scout пойти дальше: RoadRunner, в отличие от PHP-FPM, не очищает память между запросами, что даёт дополнительный выигрыш в производительности (хотя этот подход и  усложняет процесс разработки). Мы сейчас экспериментируем с этим инструментом, но у нас пока нет результатов, которыми можно было бы поделиться. Чтобы ждать их было веселее, публикуем перевод анонса RoadRunner от Spiral Scout.

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

Enjoy!

1. Вступление

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

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

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

Профессии программиста, как и большинству других профессий, приходится учиться каждый день в течение нескольких лет, а, по большому счету, и всю жизнь. Вначале ты осваиваешь набор базовых знаний в объеме N семестровых курсов, потом долго топчешься по различным граблям, перенимаешь опыт старших товарищей, изучаешь хорошие и плохие примеры (плохие почему-то чаще).

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

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

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

Но если для нас действительно важно качество кода, который пишут люди, работающие вместе с нами, то попробовать все же стоит!

Свежая подборка со ссылками на новости и материалы. В выпуске: PHP 7.4.2 и другие релизы, Stringable RFC, обзор PHP 8, порция полезных инструментов, 4 ближайших митапа, видеозаписи с конференций, стримы и многое другое.

Приятного чтения!

В недавней переведенной статье “Можно ли взломать самолёт” меня возмутили выводы в конце:

В заключение, взлом самолёта через GPS, радиоканалы и т.п. теоретически возможен, но потребует невероятного объёма работы, много планирования, координирования действий, много оборудования. И не стоит забывать, что в зависимости от высоты самолёт перемещается со скоростью от 300 до 850 км/ч.

Наверное, оригинальная статья достаточно старая. Еще лет 10 назад, чтобы генерировать радиосигналы со сложной модуляцией или расширением спектра необходимы было очень дорогое оборудование, производства Rohde & Schwarz, Keysight, Anritsu или Spirent. Всего четыре крупных производителя в мире. Под каждую технологию радиосвязи был отдельный дорогой прибор. Цены в 100 k$ никого не удивляли. И на тот момент, действительно, чтобы провести атаку на канал радиосвязи, необходимо было привлекать очень большой ресурс.

В предыдущих публикациях мы уже не раз рассказывали о полезных утилитах для работы с нашим облачным хранилищем. Сегодня мы поговорим ещё об одном интересном, простом в обращении и — не побоимся этого слова — уникальном инструменте. Знакомьтесь: rclone. Разработчики описывают его краткой и ёмкой фразой «rsync для облачных хранилищ».

Основная функция rclone — это синхронизация данных в хранилище и на локальной машине. Утилита несомненна окажется полезной для широкого круга пользователей облачного хранилища. Её можно использовать и для резервного копирования, и в работе со статическими сайтами…

Есть у rclone и опции, которых нет ни у одного другого инструмента аналогичного плана. Подробнее обо всём этом мы расскажем ниже.

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

Привет, Хабр! Меня зовут Алексей Рыбак, я – глава разработки в Badoo. В феврале в нашем московском офисе Badoo проходил Techleads-митап, где я рассказывал про наш процесс Performance Review. Эта статья написана по мотивам моего выступления.

Много лет назад я пришёл на должность разработчика в одну компанию и вскоре стал свидетелем необычной сцены. Тимлид соседнего отдела подозвал своего подчинённого посреди рабочего дня и довольно громко и развязно сказал ему: «Слышь, на вот тебе денег. Сгоняй в магазин, купи вискаря и закуски». 

Я подумал: «Да ладно! Странно всё это...». Но ситуация повторялась ещё несколько раз. Проработав в компании какое-то время, я понял, что подобное поведение там было нормой. Одни команды дружили против других, процветала подковёрщина, а топ-менеджмент абсолютно никак не реагировал на это. Я ушёл оттуда, несмотря на то, что и задачи были интересные, и условия неплохие. Но моральный климат был невыносим. 

Так считал не только я: сейчас этой компании уже нет. Но в тот момент я понял, насколько важно работать с неформальными отношениями, насколько существенное влияние они могут оказать на бизнес в целом. Причём работать с ними должны прежде всего линейные руководители, а не HR-менеджеры или штатные психологи, потому что именно руководители ежедневно находятся в контакте со своими подчинёнными. 

Но тимлиды в IT-сфере, как правило, сами выросли из разработчиков, инженеров и не имеют специального образования в областях психологии и методологии управления. Из-за этого зачастую менеджеры понимают свои задачи довольно узко: решать проблемы бизнеса, выполнять план и т. п. А зачем нянчиться со взрослыми людьми, им непонятно. 

В последние десять лет я занимаюсь тем, что руковожу командами разработки, семь из них — в Badoo. Эта статья написана по мотивам моего  выступления на Saint TeamLead Conf 2019: в ней я попытаюсь объяснить, как и зачем нужно работать над неформальными отношениями в коллективе. 

Введение

Диаграмма классов UML позволяет обозначать отношения между классами и их экземплярами. Для чего они нужны? Они нужны, например, для моделирования прикладной области. Но как отношения отражаются в программном коде? Данное небольшое исследование пытается ответить на этот вопрос — показать эти отношения в коде.

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

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

Привет, в августе мы проведем в Москве митап с докладчиками из других городов, встречей BeerPHP и трансляцией официальной части для всех, кто не сможет присоединиться.

Сегодня начинаем представлять докладчиков. Сергей Жук приедет на митап из Брянска — в его городе нет тусовки, а ему есть что рассказать об асинхронном PHP: он написал об этом книги, серию статей и не только. Ниже — расшифровка недавнего подкаста об этом, ссылки на прослушивание и просмотр выпуска, а также детали о самом митапе.



Пётр Мязин aka PQR: Сегодня со мной на связи один из главных знатоков ReactPHP. Сергей, недавно я заходил на сайт reactphp.org и обнаружил тебя на главной странице. Ты достаточно много пишешь по теме, у тебя даже есть свой канал с видеороликами-инструкциями. Расскажи, как ты к этому пришел, что тебя зацепило в ReactPHP?

Думаем, вы заметили, что Skyeng активно участвует в жизни PHP-сообщества России. Но даже с нашими возможностями и ресурсами организовать или принять участие в мероприятии не в Москве или Питере бывает затруднительно. Еще сложнее приходится тем, кому есть чем поделиться с сообществом, но он просто не знает о существовании PHP-тусовки в своем городе или регионе.

Так что мы решили сделать полезную вещь: календарь мероприятий, связанных с PHP, а к нему приложить перечень площадок, заинтересованных компаний и спикеров в виде открытого репозитория на GitHub. Зачем нам это? Мы твердо знаем, что IT-жизнь есть и за пределами МКАД и КАД — в регионах — так что решили поделиться этой информацией со всеми желающими!

Привет, завтра мы собираем за одним столом руководителей разработки из разных известных компаний — обсудим 6 вечных вопросов: как замерять эффективность разработки, внедрять изменения, нанимать и так далее. Ну а накануне решили поднять седьмой вечный вопрос — что читать, чтобы расти?

Профессиональная литература — сложный вопрос, особенно если говорить о литературе для руководителей в сфере IT. Чтобы понять, на что потратить вечно не хватающее время, мы опросили подписчиков канала «Тимлид Леонид» и собрали подборку из полусотни книг*. А затем добавили отзывы наших тимлидов к самым популярным. Так как список ниже глубоко субъективен и основан на отзывах незнакомых вам людей, оценивать литературу мы будем в «сферических совах».

---

1. «Джедайские техники. Как воспитать свою обезьяну, опустошить инбокс и сберечь мыслетопливо» / Дорофеев Максим

TL;DR

Из книги вы узнаете:

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

Я бы всем советовал начинать совершенствование тайм-менеджмента именно с этой книги. Но, если вы прочитали уже несколько книг, то и в этой уверен тоже найдете много техник и идей. Полезно *всем*. Читается просто, язык отличный. Также я выписал все книги из примечаний и вписал себе в бэклог.

Оценка: 6,50 сферических сов.

---

Как говорится, если тебе не стыдно за свой старый код, значит, ты не растешь как программист — и я согласна с таким мнением. Я начала программировать для развлечения более 40 лет назад, а 30 лет назад и профессионально, так что ошибок у меня набралось очень много. Будучи профессором информатики, я учу своих студентов извлекать уроки из ошибок — своих, моих, чужих. Думаю, пришло время рассказать о моих ошибках, чтобы не растерять скромность. Надеюсь, кому-то они окажутся полезны.

Привет, Хабр! Перед вами перевод статьи Роберта Мартина Open-Closed Principle, которую он опубликовал в январе 1996 года. Статья, мягко говоря, не самая свежая. Но в рунете статьи дяди Боба про SOLID пересказывают только в урезанном виде, поэтому я подумал, что полный перевод лишним не будет.

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

• Ни одну программу нельзя «закрыть» на 100%.
• Объектно-ориентированное программирование (ООП) оперирует не физическими объектами реального мира, а понятиями — например, понятием «упорядочивание».

В последние годы на instagram.com появилось много нового. Очень много. Например — средства создания историй, фильтры, творческие инструменты, уведомления, прямые сообщения. Однако по мере роста проекта всё это дало один печальный побочный эффект, который заключался в том, что производительность instagram.com начала падать. В течение прошлого года команда разработчиков Instagram прилагала постоянные усилия к тому, чтобы это исправить. Это привело к тому, что общее время загрузки ленты Instagram (feed page) снизилось почти на 50%.



Сегодня мы публикуем перевод первого материала из серии статей, посвящённых рассказу о том, как ускоряли instagram.com.

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

Дело в том, что ИТ-сфера одновременно бурно развивается (все еще) и в то же время полна множества устоявшихся стереотипов.

Привет!

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

С другой стороны, частые переговоры означают много поездок. Иногда везёт. Вот в Дубае выходные пятница и суббота, а воскресенье — рабочий. При этом рейсы на воскресенье дорогие, и куда выгоднее лететь в пятницу. Встреча по поводу наших разработок по машинному зрению для дронов была на воскресенье, и когда наш переговорщик прилетел, заказчик извинился и сказал, что не получается, и нужно перенести ещё на пару дней. Так у него получились незапланированные выходные. Ну а дальше он закономерно вышел на пляж и уснул. После чего всем говорил, что сгорел на работе. Но интересно не это: дело в том, что ещё один наш коллега как раз застрял посреди тундры. Это примерно два часа вертолётом от Нового Уренгоя, и, кроме вертолёта, там транспорта нет. У него была метель — и, как следствие, нелётная погода. Он прибыл, обследовал талевые канаты и не смог вылететь. К началу истории уже сидел там два дня. Синоптики обещали открыть площадку только ещё через три дня. Из развлечений у него там была еда в столовой на месторождении, настольный теннис с вахтовиками и SMS на телефоне. Вот они друг другу и жаловались, кто и где застрял.

Domain-Driven Design: Tackling Complexity in the Heart of Software Эванса — лучшая книга о проектировании действительно больших enterprise-приложений, что я читал. Видимо это мнение разделяют многие другие разработчики и проектировщики, потому что Entity и ValueObject, Repository и Specification встречаются почти в каждой большой кодовой базе. Но вот незадача, Ubiquitous Language (единый язык) и Bounded Context (контекст предметной области) в чужом коде я не видел ни разу. И здесь зарыта очень большая собака.