Pull to refresh
64
0
Александр Светкин @whisk

User

Send message

Как не надо объяснять людям задачи и изменения

Level of difficultyEasy
Reading time11 min
Views11K


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

Быть руководителем в ИТ сегодня = быть переговорщиком.

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

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

Ещё нужно понимать, что не со всеми людьми работает логика. Есть прогрессивные разработчики, есть early adopters, есть люди-юристы, есть динозавры-кинестетики. Начну, пожалуй, как раз с последних, потому что в нашем кровавом энтерпрайзе они создают реальные проблемы.
Читать дальше →
Total votes 25: ↑21 and ↓4+25
Comments19

Разработчик с мозгом груга

Reading time14 min
Views89K

Введение


это сборник мыслей о разработке программ собранный разработчиком с мозгом груга

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

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

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

Ещё больше-больше ДУМАЮТ, что они разработчики с большим мозгом и им она тоже не понравится

(груг раньше думал груг с большим мозгом, но потом всё понял)

это ладно!

груг надеется, что тебе понравится читать и может ты научишься на много-много ошибка груг совершил за длинную жизнь программиста
Читать дальше →
Total votes 223: ↑197 and ↓26+209
Comments81

Взгляд изнутри на надёжность сервисов Facebook

Reading time13 min
Views15K
Когда Facebook «лежит», люди думают, что это из-за хакеров или DDoS-атак, но это не так. Все «падения» за последние несколько лет были вызваны внутренними изменениями или поломками. Чтобы учить новых сотрудников не ломать Facebook на примерах, всем большим инцидентам дают имена, например, «Call the Cops» или «CAPSLOCK». Первый так назвали из-за того, что когда однажды соцсеть упала, в полицию Лос-Анджелеса звонили пользователи и просили его починить, а шериф в отчаянии в Твиттере просил не беспокоить их по этому поводу. Во время второго инцидента на кэш-машинах опустился и не поднялся сетевой интерфейс, и все машины перезапускали руками.

Элина Лобанова работает в Facebook последние 4 года в команде Web Foundation. Участники команды зовутся продакшн-инженерами и следят за надежностью и производительностью всего бэкенда, тушат Facebook, когда он горит, пишут мониторинг и автоматизацию, чтобы облегчить жизнь себе и другим.



В статье, основанной на докладе Элины на HighLoad++ 2019, расскажем, как продакшн-инженеры следят за бэкендом Facebook, какие инструменты используют, из-за чего возникают крупные сбои и как с ними справиться.
Total votes 26: ↑25 and ↓1+39
Comments5

Введение в криптографию и шифрование, часть первая. Лекция в Яндексе

Reading time20 min
Views243K
Чтобы сходу понимать материалы об инфраструктуре открытых ключей, сетевой безопасности и HTTPS, нужно знать основы криптографической теории. Один из самых быстрых способов изучить их — посмотреть или прочитать лекцию Владимира ivlad Иванова. Владимир — известный специалист по сетям и системам их защиты. Он долгое время работал в Яндексе, был одним из руководителей нашего департамента эксплуатации.


Мы впервые публикуем эту лекцию вместе с расшифровкой. Начнём с первой части. Под катом вы найдёте текст и часть слайдов.

Total votes 96: ↑92 and ↓4+88
Comments29

15 тривиальных фактов о правильной работе с протоколом HTTP

Reading time7 min
Views234K
Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.
Читать дальше →
Total votes 191: ↑186 and ↓5+181
Comments120

Как проверить паспорт на действительность

Reading time6 min
Views205K


Реквизиты паспорта — не просто набор цифр, в них закодирован вагон информации. Если правильно расшифровывать и сопоставлять реквизиты, подозрительные документы мгновенно всплывут на поверхность. Продукты HFLabs уже 14 лет проверяют клиентские данные в банках, страховых, телекомах и другом крупном бизнесе. Расскажу, как мы распознаем ошибки в российских паспортах.
Читать дальше →
Total votes 100: ↑98 and ↓2+130
Comments258

Continuous integration в Яндексе

Reading time10 min
Views36K

Поддержка огромной кодовой базы с одновременным обеспечением высокой производительности большого числа разработчиков — это серьезный вызов. В течение последних 5 лет в Яндексе идет разработка особой системы непрерывной интеграции. В данной статье мы расскажем про масштаб кодовой базы Яндекса, про перенос разработки в единый репозиторий с trunk-based подходом к разработке, про то, какие задачи должна решать система непрерывной интеграции для эффективной работы в таких условиях.



Много лет назад в Яндексе никаких особенных правил в разработке сервисов не было: каждый отдел мог использовать любые языки, любые технологии, любые системы деплоя. И как показала практика, такая свобода не всегда помогала двигаться вперед быстрее. В то время для решения одних и тех же задач часто существовало несколько собственных или open-source разработок. С ростом компании такая экосистема работала всё хуже. При этом мы хотели остаться одним большим Яндексом, а не разделиться на множество независимых компаний, потому что это дает массу преимуществ: много людей делают одни похожие задачи, результаты их труда можно использовать повторно. Начиная от разнообразных структур данных, типа распределённых хеш-таблиц и lock-free очередей, и заканчивая множеством разного специализированного кода, который мы написали за 20 лет.

Читать дальше →
Total votes 52: ↑47 and ↓5+42
Comments100

Как сократить код-ревью с двух недель до нескольких часов. Опыт команды Яндекс.Маркета

Reading time6 min
Views23K

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


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


Для начала надо представить, какой флоу в разработке у нас принят:


Читать дальше →
Total votes 47: ↑43 and ↓4+39
Comments42

Разбор квалификации чемпионата по программированию среди бэкенд-разработчиков

Reading time7 min
Views30K

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


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



В этот раз мы придумали шесть задач, для каждой из которых можно было придумать несколько альтернативных формулировок: одна придуманная задача порождала сразу четыре! Тем самым варианты получились сопоставимыми настолько, насколько это вообще возможно.


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

Читать дальше →
Total votes 37: ↑35 and ↓2+33
Comments7

Load Average в Linux: разгадка тайны

Reading time18 min
Views220K


Средние значения нагрузки (Load averages) — это критически важная для индустрии метрика. Многие компании тратят миллионы долларов, автоматически масштабируя облачные инстансы на основании этой и ряда других метрик. Но на Linux она окутана некой тайной. Отслеживание средней нагрузки на Linux — это задача, работающая в непрерываемом состоянии сна (uninterruptible sleep state). Почему? Я никогда не встречал объяснений. В этой статье я хочу разгадать эту тайну, и создать референс по средним значениям нагрузки для всех, кто пытается их интерпретировать.

Читать дальше →
Total votes 127: ↑125 and ↓2+123
Comments25

Можно ли считать статистику при малом количестве данных?

Reading time6 min
Views15K
В целом ответ – да. Особенно, когда есть мозги и знание теоремы Байеса.

Напомню, что среднее и дисперсию можно считать только, если у вас имеется определенное количества событий. В старых методичках СССР РТМ (руководящий технический материал) говорилось, что чтобы считать среднее и дисперсию необходимо 29 измерений. Сейчас в ВУЗах немного округлили и используют число 30 измерений. С чем это связано – вопрос философский. Почему я не могу просто взять и посчитать среднее, если у меня есть 5 измерений? По идее ничто не мешает, только среднее получается нестабильным. После еще одного измерения и пересчета оно может сильно измениться и полагаться на него можно начиная где-то с 30 измерений. Но и после 31го измерения оно тоже пошатнется, только уже не так заметно. Плюс добавляется проблема, что и среднее можно считать по разному и получать разные значения. То есть из большой выборки можно выбрать первые 30 и посчитать среднее, потом выбрать другие 30 и тд … и получить много средних, которые тоже можно усреднять. Истинное среднее бывает недостижимо на практике, так как всегда имеем конечное количество измерений. В таком случае среднее является статистической величиной со своим средним и дисперсией. То есть измеряя среднее на практике мы имеем в виду «предположительное среднее», которое может быть близко к идеальному теоретическом значению.

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

Читать дальше →
Total votes 28: ↑27 and ↓1+26
Comments49

Тестирование производительности веб-сервиса в рамках Continuous Integration. Опыт Яндекса

Reading time9 min
Views37K

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


В нашем сервисе рекламных технологий тестирование работает в рамках методологии Continuous integration, более подробно об организации которой мы расскажем 25 октября на мероприятии Яндекс изнутри, а сегодня мы поделимся с читателями Хабра опытом автоматизации оценки важных продуктовых метрик, связанных с производительностью сервиса. Вы узнаете, как доверить анализ машине, а не следить за ними на графиках. Поехали!



Читать дальше →
Total votes 28: ↑27 and ↓1+26
Comments6

Как выруливать с legacy code, когда проект нужно было на вчера

Reading time7 min
Views24K
Привет. Меня зовут Иван Мельничук, я Head of Development Department в украинской IT-компании. В публикации хочу поделиться личными профессиональными подходами относительно решения вопроса legacy code в условиях стремительного развития проекта и рассказать о приемах, к которым прибегает наша команда в случаях “когда фичи нужно сдавать “на вчера”.

Разбираемся с проектом


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

image

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

Примерно так же “ведет” себя легаси. Поэтому работа программиста, который взялся за задачу модернизировать и “вдохнуть вторую жизнь” в проект, должна быть в некой степени ювелирной. Большинство программистов пытаются избегать и вообще “спрыгнуть с темы” технического долга. Даже составил хит-парад самых распространенных цитат, которые приходилось слышать от программистов, оказавшихся в условиях legacy:
Читать дальше →
Total votes 38: ↑31 and ↓7+24
Comments16

Покрываем проект smoke-тестами, пока он не сгорел

Reading time9 min
Views48K

Привет, Хабр! Как-то раз на нашем внутреннем семинаре мой руководитель – глава отдела тестирования – начал свою речь со слов «тестирование не нужно». В зале все притихли, некоторые даже пытались упасть со стульев. Он продолжил свою мысль: без тестирования вполне возможно создать сложный и дорогостоящий проект. И, скорее всего, он будет работать. Но представьте, насколько увереннее вы будете себя ощущать, зная, что продукт работает как надо.

В Badoo релизы происходят довольно часто. Например, серверная часть наравне с desktop web релизится дважды в день. Так что мы не понаслышке знаем, что сложное и медленное тестирование – камень преткновения разработки. Быстрое же тестирование – это счастье. Итак, сегодня я расскажу о том, как в компании Badoo устроено smoke-тестирование.
Читать дальше →
Total votes 49: ↑47 and ↓2+45
Comments16

Производительность PHP: планируем, профилируем, оптимизируем

Reading time16 min
Views40K


Привет, Хабр! Два года назад мы писали о том, как перешли на PHP 7.0 и сэкономили миллион долларов. На нашем профиле нагрузки новая версия оказалась в два раза более эффективной по использованию CPU: ту нагрузку, которую раньше у нас обслуживали ~600 серверов, после перехода начали обслуживать ~300. В результате на протяжении двух лет у нас был запас мощностей.

Но Badoo растёт. Количество активных пользователей постоянно увеличивается. Мы совершенствуемся и развиваем нашу функциональность, благодаря чему пользователи проводят в приложении всё больше времени. А это, в свою очередь, отражается на количестве запросов, которое за два года увеличилось в 2—2,5 раза.

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

Под катом я расскажу, как мы подходим к таким задачам, какими пользуемся инструментами, и приведу примеры оптимизаций, идей и подходов, которые мы применяем и которые помогли нам в своё время.
Читать дальше →
Total votes 105: ↑105 and ↓0+105
Comments58

Как развиваться руководителю разработки

Reading time12 min
Views25K



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


Мы выбрали пути развития руководителей разработки темой следующего Team Leader Meetup, который пройдёт вечером 28 ноября в московском офисе Яндекса. Обсудить эту тему можно будет с экспертами из крупных IT-компаний. Регистрация ещё открыта.


В этот раз нашими экспертами стали:


  • Николай Крапивный, руководитель бекенд-разработки, Badoo
  • Роман romas1982 Ивлиев, CTO, mos.ru
  • Александр Поломодов, руководитель отдела исследований и разработки, Tinkoff.ru
  • Борис Тоботрас, директор центра программных решений, Инфосистемы Джет
  • Виктор Ламбурт, руководитель направления рекомендательных продуктов, Яндекс
  • Игорь Кураленок, генеральный директор, Лига Экспертов

Сегодня на Хабре мы задаём им ряд вопросов, чтобы задать тон будущей дискуссии:


1. Какие советы вы бы дали вашему коллеге – сильному разработчику, который недавно, буквально вчера, стал тимлидом? С каких конкретных, понятных действий ему стоило бы начать свою работу в новой должности?
2. Какие книги или статьи вы бы порекомендовали прочитать руководителю разработки? А какие ресурсы имеет смысл изучать на регулярной основе?
3. Сколько времени стоит уделять работе над техническими задачами, а сколько – над задачами, связанными с управлением коллективом? На что ещё может или должен тратить своё время тимлид?
Читать дальше →
Total votes 42: ↑35 and ↓7+28
Comments9

Три дня, которые потрясли нас в 2013

Reading time11 min
Views74K


«Если у вас есть сомнения, авария это или нет — то это авария!»
(с) Мудрость предков

Большие сбои в онлайн-проектах происходят редко. А в больших проектах — ещё реже. Конечно, чем сложнее система, тем выше вероятность ошибки. Один час простоя крупных систем, особенно соцсетей, обходится недёшево, и потому в больших проектах прикладывается очень много усилий по предотвращению аварий и снижению негативного эффекта для пользователей. Но иногда то ли звёзды складываются в особенную комбинацию, то ли закон Мёрфи обретает реальную силу, и большие аварии всё же происходят. В истории Одноклассников крупнейший сбой произошёл 4 апреля 2013 года: в течение трёх дней проект был целиком или частично неработоспособен. О том, что же тогда произошло, по каким причинам и как мы с этим боролись, будет наш рассказ.
Читать дальше →
Total votes 78: ↑68 and ↓10+58
Comments39

Привилегированные порты — причина глобального потепления

Reading time12 min
Views30K
Мне 37 лет, что по программистским меркам равняется 99 годам. Я достаточно стар, чтобы помнить первые дни публичного Интернета и первых интернет-провайдеров. Впервые я вышел в онлайн через провайдера, который назывался Internet Access Cincinnati (IAC). Он предоставлял доступ по диалапу к серверу Sun SparcStation 10, где пользователи могли запускать почтенные в своей древности терминальные приложения вроде elm (почтовый клиент), emacs, lynx (текстовый веб-браузер), и конечно IRC.

Позже добавили возможность звонить на терминальный сервер CSLIP (предшественник PPP) и подключаться напрямую к Интернету с собственного компьютера под Linux или Windows (при наличии Trumpet WinSock) с настоящим IP-адресом.

Но вернёмся к той SparcStation. Машина была оборудована двумя CPU, которые работали на чудовищной частоте 33 Мгц, и она могла вместить аж 512 МБ памяти, хотя я сомневаюсь, что слоты там были забиты по максимуму. Оперативная память очень дорого стоила в те времена. Сервер с такими скромными ресурсами обслуживал 50-100 активных пользователей одновременно, обрабатывал почту для десятков тысяч, держал IRC-чат, поддерживал ранний HTTP 1.0 через NCSA HTTPd и добровольно выполнял роль FTP-зеркала для Slackware Linux. В целом он неплохо справлялся с нагрузкой и часто показывал аптайм 1-2 месяца.
Читать дальше →
Total votes 69: ↑61 and ↓8+53
Comments86

Эволюция нейросетей для распознавания изображений в Google: Inception-ResNet

Reading time5 min
Views46K
Буду потихоньку дорассказывать про Inception.
Предыдущая часть здесь — https://habrahabr.ru/post/302242/.
Мы остановились на том, Inception-v3 не выиграл Imagenet Recognition Challange в 2015-м, потому что появились ResNets (Residual Networks).

Что такое вообще ResNets?


Читать дальше →
Total votes 30: ↑26 and ↓4+22
Comments18

CNTK — нейросетевой инструментарий от Microsoft Research

Reading time5 min
Views26K
2015 год был очень богат на события, связанные с нейросетевыми технологиями и машинным обучением. Особенно заметный прогресс показали сверточные и рекуррентные сети, подходящие для решения задач в области компьютерного зрения и распознавания речи. Многие крупные компании опубликовали на Github свои разработки, Google выпустил в свет TensorFlow, Baidu — warp-ctc. Группа ученых из Microsoft Research тоже решила присоединиться к этой инициативе, выпустив Computational Network Toolkit, набор инструментов для проектирования и тренировки сетей различного типа, которые можно использовать для распознавания образов, понимания речи, анализа текстов и многого другого. Интригующим при этом является то, что эта сеть победила в конкурсе ImageNet LSVR 2015 и является самой быстрой среди существующих конкурентов.


Читать дальше →
Total votes 23: ↑23 and ↓0+23
Comments8
1
23 ...

Information

Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Registered
Activity

Specialization

Backend Developer, Program Manager
Lead