Привет, меня зовут Билл «LtRandolph» Кларк. Я работаю техническим руководителем команды создания чемпионов LoL. За последние несколько лет я успел поработать в разных отделах разработки League, но единственное, чем я был постоянно одержим — это технический долг. Мне нужно найти его, понять его и, при возможности, устранить его.

Когда разработчики обсуждают любую существующую технологию, например патч 8.4 League of Legends, то часто упоминают технический долг. Я называю техническим долгом код или данные, за которые придётся расплачиваться будущим разработчикам. Этой печальной стороне разработки ПО посвящено бесчисленное количество постов, статей и определений. В своём посте я хочу обсудить виды технического долга, с которыми мне пришлось встретиться при работе в Riot, и рассказать о модели, которую мы начали использовать в компании. Если бы меня попросили выделить самый важный урок, который можно извлечь из этой статьи, то я сказал бы, что это описанная ниже метрика «инфицирования».

Метрики

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

В начале марта в американском городе Джексонвилле завершилась встреча международной рабочей группы WG21 по стандартизации C++. На встрече добавляли фишки в C++20, подготавливали к выпуску «превью» новых компонентов и полировали до блеска шероховатости языка.

Хотите посмотреть на новости и узнать:

• Почему это тут золотая медаль справа?
• Как там поживает кросплатформенный SIMD?
• Что будет если 4000 поделить на последнюю пятницу февраля?
• Какие подводные камни нашлись у сопрограмм?
• Какие крутые фишки для многопоточного программирования будут в скором времени доступны?

Привет, я Тони Альбрехт (Tony Albrecht), инженер в Riot. Мне нравится профилировать и оптимизировать. В этой статье я расскажу об основах профилирования, а также проанализирую пример С++-кода в ходе его профилирования на Windows-машине. Мы начнём с самого простого и будем постепенно углубляться в потроха центрального процессора. Когда нам встретятся возможности оптимизировать — мы внедрим изменения, а в следующей статье разберём реальные примеры из кодовой базы игры League of Legends. Поехали!

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

Действуем по старой схеме: я для вас отсматриваю подряд 10 докладов, делаю краткое описание содержимого, чтобы неинтересное можно было выбросить. Кроме того, с сайтов собираю ссылки на слайды и описания. Полученное сортирую и выдаю в порядке увеличения рейтинга — то есть в самом низу будет самый крутой доклад. Оценки — это не лайки на YouTube, а собственная оценочная система, она круче лайков.

Предыдущие части: JBreak 2017, JPoint 2017 (обе конференции были про Java).

На этот раз объектом изысканий будет Heisenbug 2017 Moscow — известная конференция для тестировщиков (а также программистов и менеджеров команд, как написано на главной странице сайта).

В посте присутствует зашкаливающее количество картинок и ссылок на YouTube. Осторожно, трафик!

Disclaimer: Все описания являются моим личным мнением. Всё написанное является плодом моего больного воображения, а не искажёнными цитатами докладчиков (это предостережение написано для того, чтобы докладчики меня не побили). Если кого-то случайно обидел — пишите в личку, разберёмся. Но в целом, давайте думать так: если бы BadComedian каждый раз спрашивал у Фонда Кино, что ему стоит говорить или не говорить — снял бы он хоть один ролик?

Я знаю, о чём вы подумали: «Ещё одна скучная статья про DRY? Нам их мало, что ли?».

Возможно, вы правы. Но я встречаю слишком много разработчиков (junior и senior), применяющих DRY так, словно они охотятся на ведьм. Либо совершенно непредсказуемо, либо везде, где можно. Так что, судя по всему, в интернете никогда не будет достаточно статей о принципе DRY.

Если кто не знает: принцип DRY — это "Don't Repeat Yourself" (не повторяйся), и впервые о нём упомянуто в книге The Pragmatic Programmer. Хотя сам по себе этот принцип был известен и применялся задолго до появления книги, однако в ней ему было дано название и точное определение.

Итак, без лишних рассуждений отправимся в путешествие по чудесной стране DRY!

Предисловие

Данная статья очень субъективна и основана на моём опыте в ИТ-индустрии (Я разработчик с 10-и летним стажем и опытом работы в различных проектах, командах и странах (Казахстан, Канада)). Уверен, что многие не поддержат мою точку зрения и могут назвать эту статью «плачем динозвара», но всё-же хочу поделиться ею…

Что такое DevOps

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

С моей точки зрения основная задача DevOps — снижение затрат для бизнеса (что хорошо, но часто это идёт в ущерб качеству продукта).

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

Рассказывать айтишникам про психологию то еще дело, некоторые читатели скажут: «Bullshit!», и вообще не поверят, потому что психологию, даже прикладную, нельзя назвать точной наукой. Тем не менее, задача этой статьи — показать и доказать вам, что некоторые модели действительно работают. В основе доклад Сергея Котырева из UMI на РИТ++ 2017, от его лица дальше и пойдет повествование.



Я — IT-предприниматель с 20 летним стажем. Так получилось, что с самого начала карьеры мне пришлось управлять людьми. Как выпускник технического вуза и айтишник, я изначально понял, что люди сложно поддаются алгоритмизации, и вообще осознанию, пониманию и прогнозированию.

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

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

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

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

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

Данную статью меня побудил написать тот скрытый и для каждого свой смысл должности/роли Team Leader. Многие хотят им стать, многим интересно что там, "под капотом", работы в этой должности. Поэтому кому интересно узнать еще одно мнение об этом всем безобразии, то прошу под кат.

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

Эта статья — вольный пересказ доклада, который я посетил на конференции GOTO Berlin 2017: A Crystal Ball to Prioritize Technical Debt.

Изображения из доклада и права на них принадлежат автору @AdamTornhill.

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

Но как формализовать понятие технического долга, чтобы объяснить его другим? И, тем более, объяснить это менеджеру так, чтобы получить одобрение на рефакторинг? Как найти все места в проекте, которые нужно по-хорошему переписать, и как определить, какие из них должны быть переписаны в первую очередь?

Если эти вопросы неоднократно у вас возникали, прошу под кат.

Около года назад я писал статью о том, как можно вызывать методы классов написанных на чистом Си++ из любой .NET программы не прибегая к регистрации COM библиотек, C++/CLI и т.п.

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

Язык C++ сложен. Но его сложность проистекает из сложности задач, которые решаются с помощью C++. Каждая фича, которая была добавлена в C++, была добавлена не просто так, а для того, чтобы дать возможность справиться к какой-то проблемой. Ну а уж сочетание существующих в C++ фич делает язык чрезвычайно мощным инструментов. Конкретному примеру того, как это происходит на практике, и посвящена данная статья.

Добавлю еще, что одним из мощных стимулов к написанию данной статьи стало то, что очень часто на глаза попадаются объемные флеймыобсуждения на тему «ООП не нужно» и, особенно, «шаблоны-дженерики на практике почти никогда не нужны». Мне, как далеко не молодому программисту, начинавшему в 1990-ом как раз с инструментов, в которых не было ни ООП, ни шаблонов-дженериков, странно сталкиваться с подобными точками зрения. Но, чем дальше, тем чаще с ними сталкиваешься. Особенно со стороны приверженцев новых языков программирования, вроде Go или Rust-а.

Сложно сказать, чем это вызвано. Может быть людей перекормили ООП (а это так и было)… Может быть задачи за несколько минувших десятилетий сильно поменялись (а это так и есть)… Может быть и просто «вот и выросло поколение»… Как бы то ни было, можно попробовать на примере из реальной жизни показать, что все не так однозначно ©.

Итак, о чем пойдет речь?

Привет, Хабр! Меня зовут Святослав Кулаков, я VP of Engineering в Aurea Software. Вся моя жизнь прошла в Питере: я родился и вырос на улице Союза Печатников напротив Мариинского театра, учился во второй гимназии с углублённым изучением английского языка и физмата, поступил в Университет аэрокосмического приборостроения (ГУАП). После учёбы я работал в нескольких софтверных компаниях в России и США, но в итоге всё вернулся в Санкт-Петербург и оставался тут даже когда это казалось верной дорогой к карьерному болоту.



На основании своего личного опыта я расскажу о том, почему многим IT-специалистам нереально найти в Санкт-Петербурге работу по своему уровню, как работает механизм перетягивания лучших специалистов — как минимум, в Москву, а то и сразу в США или другие страны. И о том, как мне всё-таки удалось найти в родном городе свою лучшую работу на данный момент. Но обо всём по порядку.

Из Санкт-Петербурга в Санкт-Петербург через Санкт-Петербург

Моя трудовая биография началась с позиции Java-разработчика в небольшой софтверной компании в 1999 году. За следующие 9 лет я продвинулся по карьерной лестнице до позиции Эккаунт Менеджера, где мне подчинялось более 100 человек. Кризис 2008 года сбил нас на взлёте, и моей следующей записью в трудовой стала должность Lead IT Process Manager в московском отделении Deutsche Bank. Полтора года спустя мне поступило заманчивое предложение из США: консультировать бизнес-клиентов компании Grid Dynamics в вопросах оптимизации процессов разработки.

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

Ниже я подобрала пять докладов, которые отвечают на вопросы, как проходить собеседования, какие способности нужно развить, чтобы стать успешнее в сфере ИТ, и что делать, чтобы карьера пошла в гору. Осторожно, здесь говорят про бизнес!

Привет, Хабр! Представляю вашему вниманию перевод статьи «What habits made me a better Software Engineer?» от Sonny Recio.

Наши привычки — это ежедневные шаблоны поведения в жизни. Они могут быть как плохими, так и хорошими. Привычки могут быть жизненно необходимыми, например, потребность в еде 3 раза в день. Есть и такие привычки, которые помогают быть здоровым — занятие в тренажерном зале 3-4 раза в неделю. Но есть также привычки, которые портят тело, такие как курение и ежедневное распитие алкогольных напитков.

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

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

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

О книге «Программист-прагматик. Путь от подмастерья к мастеру» Эндрю Ханта и Дэвида Томаса знают, наверное, все, кто занимается программированием, причем многие — в основном из упоминаний в подборках и цитат в более современных статьях. Учитывая, что этот сборник практических советов для разработчиков скоро отметит двадцатилетний юбилей, тот факт, что его до сих пор приводят как источник ценной информации, вызывает уважение. Секрет прост: авторы, хоть и делали акцент на практической применимости своих подсказок, говорили по большей части о фундаментальных принципах построения рабочего процесса. Многие технические моменты, которые упоминаются в тексте, действительно давно устарели, но базовые подходы к разработке, тестированию, взаимодействию внутри команды и с аудиторией остаются актуальными.


Ниже вы найдете конспект первых четырех глав; речь в них идет об авторской концепции самообразования, основах прагматического подхода в программировании и правилах подбора инструментов. Книга очень удобна для «точечного» чтения: материал представляется в виде отдельных параграфов-подсказок, снабженных перекрестными ссылками. За рамками этого конспекта остались примеры из конкретных языков, разбор кейсов из авторской практики, те самые ссылки, упражнения на закрепление и некоторые забавные аналогии, оживляющие текст — так что рекомендую ознакомиться с оригиналом, если какие-то из тезисов вас заинтересуют. Приятного чтения!

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

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

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

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