Свежая подборка со ссылками на новости и материалы. В выпуске: 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 (контекст предметной области) в чужом коде я не видел ни разу. И здесь зарыта очень большая собака.

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

Уйма места, около четверти здания, отведено под зелень. Хотя это могли бы быть рабочие места или залы для совещаний. Откуда у Безоса появилось такое несвойственное расточительство?

Разве что, если обилие зелени в офисе – это и есть экономия…

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

Недавно я выступал на конференции Saint TeamLead Conf 2019, в докладе я рассказал о том, как смог найти ряд проблем в рабочем процессе и потом постепенно поборол их. Здесь я постараюсь описать наиболее ценные практики, которые мне помогли не только наладить рабочий процесс, но и перестать издеваться над разработчиками. У сотрудников изменилось отношение к компании в целом и рабочему процессу.