Андрей Аксенов ( shodan, Разработчик поискового движка Sphinx)

Про что доклад? Сразу хочу предупредить, что, несмотря на более интересное название в первом слайде, интересно все равно не будет.



И про менеджмент тоже не будет. Т.е. и секция – ложь, и название – ложь, и даже название такое интересное, увлекательное, завлекающее, которое в первом титульном слайде – тоже ложь. На самом деле будет скучно. Готовьтесь.



Про что доклад и, вообще, зачем доклад?



Я предполагаю, что доклады со всякими общими словами о том, что хорошо быть здоровым и богатым, а больным и бедным быть плохо, и поэтому надо хорошо учиться, есть много каши и много всего уметь – я уже несколько раз такие доклады делал. Я опасаюсь, что кроме Олега Бунина, который вынужденно присутствует на всех конференциях Олега Бунина, никто эти доклады уже не помнит, потому что, понятное дело, период карьерного полураспада типичного программиста составляет 3 месяца до перехода на следующую работу. Ну, что поделать? Тем не менее, я-то тоже их помню, поэтому захотелось сделать доклад, который не просто про то, что надо хорошо кушать кашу, а попытаться дать какие-то конкретные советы насчет того, какую конкретно кашу кушать, т.е. именно изучать для того, чтобы качать свою родную мозговую мышцу и, как следствие, мощно над собой расти.

Чисто теоретически, все, что хочется доложить в этом божественном докладе, должно присутствовать в учебном плане любого нормального технического вуза по соответствующей специальности, которая готовит типа «программистов». По факту, мы все знаем, как готовят «программистов»: «Кто умеет пользоваться Microsoft Word?» – «Нет, сложно, валит». О, вот человек, который сегодня устроился в Авито, а прошлый раз устроился в Куратор, а где работает, я вообще не знаю. Он умеет пользоваться Word, единственный из зала. Но это слишком сложно. Ты уже вообще кандидат наук. Для того, чтобы зачет сдать, возможно, достаточно запустить Word. Поэтому придется справляться самим по себе.



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

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



Собственно, давайте к мясу, наконец, сколько можно?! Как именно хорошо бы уметь? По большому счету, вопрос чисто религиозный. И религии есть как минимум две. И, наверняка, еще могут быть определенные какие-нибудь миксы. Я считаю, что по той простой причине, что, к несчастью, за последние несколько лет развития технологии доступны вообще каждому первому, а не только специалистам из NASA, которые ровер на Марс сажают. Системы и тогда еще – лет 10-20-50 назад – местами были не сильно простые, а со временем становятся все более и более сложными. Вот примеры эволюции систем, доступные каждому, они на слайде изложены.

Значит, Windows 10. Притворимся, что это чужие слайды. Windows 10 много сложнее, чем CSV файл. А три вопросика после MySQL – это, вообще, очень сложно. Зачем там три вопросика? Это чтобы специально был повод для флейма. Я ж не мог там написать, что венцом эволюции MySQL является Postgres, например. Тут же чуваки из Mongo порвали бы и наоборот. Поэтому никто не будет спорить с тем, что у движка Unreal версии 4 картинка много лучше, чем у Commander Keen платформера на 286. С базами данных и конкретно на этой конференции вопрос открытый, поэтому я испугался.

Сложность систем постоянно растет. Кому-то эти системы приходится разрабатывать, потом еще, не дай Бог, поддерживать. Отчизна требует героев. Значит, иллюстрация тезиса простой системы. Примерно, такая вот:



Что в этой системе прекрасно? Она сделана из палки, веревки, ее практически невозможно сломать. Выкопать камень из пола довольно затруднительно и сделать так, чтобы солнце не всходило, ну, тоже, ядерная зима… Тем не менее.



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



Это осложняет.



Заметьте, хочу отметить, что идеалом в моем понимании и, надеюсь, не только в моем, является не картинка №3, и даже не картинка №2, а картинка №1. Идеальная система выглядит вот так – палка, веревка, способна использовать любая обезьяна, в том числе прямоходящая. Простые системы – это хорошо, они же и идеал.



Моя религия по поводу того, что сложные системы – это плохо, заключается в том, что человек, который специализируется только на вытачивании конкретного вида гаек даже для системы №2, применим довольно плохо и проблемы в системе в целом решать точно не способен. Даже на стыке своей долбанной гайки с соседней шестеренкой тоже могут возникнуть ненужные сложности. Моя религия простая – я за универсалов. Как в древней русской присказке – он и спляшет, и споет, и по морде надает. Иначе просто невозможно становится решать проблемы на стыке задач, систем, индустрий и т.д. Невозможно придумать даже какие-то решения. Ты, блин, на своем фронтенде ничего не знаешь о том, как оно происходит в бэкенде. Что ты можешь придумать, как упростить фронтенд, чтобы сделать бэкенд, который с квалификацией матерого индуса пишет? Как облегчить его жизнь? Ты не знаешь, вообще, что там происходит. Там черный ящик. Надо иметь хотя бы какое-то маленькое понимание происходящего.

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



Герои. Тут несколько раз я недостаточно часто произносил слово «герои», но на слайдах оно возникало. Чем мерить этот т.н. героизм? Медали дают не всем, надо по другой карьерной лестнице двигаться, чтобы медаль. И общепринятые метрики под названием «вот у нас, короче, красный диплом, зеленый, синее лицо, герои 19-го уровня» только в warcraft бывают. Чем мерить – непонятно. Можно уметь верстать HTML как бог. Ты являешь таким героем-универсалом? Непонятно. Героем-специалистом? Наверное, да.

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



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

Понятное дело, что проще всего заниматься саморефлексией, чем проводить соцопросы. Как умножить кватернионы, я наизусть не помню, но где подсмотреть – знаю, и как оно, в принципе, устроено, тоже знаю. Как писать на том или ином конкретном фреймворке – вообще не мое, но с другой стороны, как говорил Виталя Свет Луговский, очередной ублюдочный императивный недоязычек. О, господи, дайте методичку, через два дня пойдем в продакшн, баги чинить. Или RTMP. Я не знаю, как он устроен внутри, я знаю, на кого написать со сцены так, чтобы второй ряд увидел радугу, а я попал в нужного мне человека.



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



Ну и, конечно, всегда есть божественная внешняя мера твоего героизма под названием «собеседование». Понятное дело, что внутренний HR-отдел мерой не является. Вот внешнее собеседование – это да.



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

Следующий вопрос: а что «все» конкретно? И следующий вопрос: а насколько хорошо знать-то?

У меня единственная гипотеза, почему доклад поставили в секцию «Менеджмент». Для каждого конкретного человека я не готов немедленно сказать, на каком уровне ему обязательно, с моей точки зрения, знать это, это и это. Это, наверное, задача как раз менеджера того человека. А проверочные вопросы и уровни понимания того или иного момента примерно такие.

Значит, мне кажется, что есть ряд таких принципиальных уровней понимания:

• слышал о том, что бывает;
• умею поставить MySQL из пакета и исправить в нем одну настройку;
• Монти был дурак, мы напишем свой новый MongoDB сами;

и отдельный интересный пункт:

• мы не просто можем написать новый клевый MongoDB сами, мы его действительно беремся и делаем.

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

И основной супер-мега тезис про то, что надо бы, как минимум, понимать самый первый уровень понимания. Нулевого-то нет, вообще, не знаю. А, что, HighLoad? Не, не слышал. Но в принципе, HighLoad++. Сколько лет прошло, а все никак не могу запомнить, что он «++».



И основная длинная часть доклада – это такой гигантский список ключевых слов, который неверен, неполон и нет никакого смысла это переписывать, но кто-нибудь все равно сфотографирует.

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

Железо. Ключевое слово «железо». Чего надо современному разработчику/DBA/проджект-менеджеру/кому-нибудь там еще, наверное, в зависимости от размера конторы, вплоть, до тех. директоров. В которых побольше тех. директорам западло, но желательно поднимать про то, что есть в компьютере CPU, RAM, диск и сеть. Это понимать обязательно. Понятно, что они, в принципе, есть, еще желательно понимать не то, что они есть, а то, что есть процессора, они бывают разные, у них такие скоростные характеристики, частоты, энергопотребление, такие-то ходовые характеристики при работе с этой самой памятью, диском и сетью. Чего можно ожидать от вашего компьютера? Вы знаете, сколько операций в секунду с так называемым диском вашего мобильного телефона можно ожидать? А сколько с диском в вашем лаптопе? А чем HDD от SSD отличается? Сколько операций? Какой порядок? Какая латентность на доступ к памяти? Высокопроизводительную систему сложно построить без хотя бы общего понимания происходящих внутри, в железе, процессов.

Дополнительным бонусом неплохо бы знать про видео, звук и прочие периферийные устройства, начиная от тупых usb-портов и заканчивая сложными скоростными fiber chanel и прочими интересными железками. Понятное дело, что вряд ли вы должны помнить наизусть распиновку электрическую usb-кабеля 3.0, и чем она отличается от 3.1, работая программистом на PHP. Некоторые помнят, вот что самое интересное, мощные люди, гвозди бы делать… Но общее представление о том, что все эти ключевые слова есть, и они сильно влияют на устройство системы иметь необходимо.

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



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

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

Хотелось бы, чтобы люди, даже если пишут на PHP, понимали, что 1 Мб – это не просто 17 объектов класса user, а это еще и 8 с чем-то млн. бит, а каждый бит – это, например, пол среднего скучного объекта класса user. Сами понимаете, что два разных значения для пола – это на сегодня скучно. Мальчик, девочка, Кэйтлин Дженнер, не определился, и то и другое, по четным одно, по нечетным другое.

Хотелось бы, чтобы каждый первый натурально хотя бы общее представление имел о том, что бывают частоты у процессоров разные, латентности доступа к той или иной памяти разные, кэш-память, которая может сильно подосрать. Бывает одно ядро, а бывает много, может несколько потоков бежать одновременно, некоторые из этих потоков могут, к несчастью, быть фальшивыми, т.н. гипертрейдинг. Божественная технология! Дает тебе процессор в полтора раза дороже, у которого по циферкам в два раза больше ядер, ты на нем проект компилируешь, а он, тварь, компилируется в полтора раза медленней. Отключаешь 4 ядра – все, нормализовалась ситуация, отличная технология. Люблю, что есть сил. Хорошо, что отключить можно. Иногда неплохо. Неплохо представлять, что есть векторная обработка, что Intel победил всех и на сервере, и на десктопе, но он, к несчастью, еще в лаптопы, планшеты, мобилы и прочая шняга, альтернативная архитектура. Местами возникает вопрос энергопотребления. Наверное, единственное, где не возникает вопрос энергопотребления – это на десктопе. Сколько жрет батарейка в мобиле, как бы, важно, и сколько жрет стойка в серверной, тоже почему-то важно. Блин, приходится думать.



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

Что на следующем уровне? На следующем уровне софта у нас живет операционная система. Чем занимается ОС по уставу? Менеджментом всех подряд тех ресурсов, менеджмент которых не хочется писать самому.

Кто хочет написать новую реализацию раскидывания тредов по ядрам? Или для того, чтобы файл можно было открыть, написать, свои личные выстраданные 15 тыс. строк кода на ассемблере? Есть, кстати, до сих пор такие. Т.е. я до сих пор абсолютно уверен, что в любом поколении есть визионер, которого прет от писания на ассемблере, и он хочет на ассемблере написать все. И успешно долбится в стену головой. Возможно, нам повезло, и один такой герой есть даже в зале, но я бы не признался на его месте, я как-то сильно обсираю. Все остальные все-таки пользуются готовыми ОС. Зачастую ни хрена не представляя, что там происходит внутри. Хотелось бы, чтобы представление было, о том, что там внутри. Менеджер памяти, дисков, файлов, сокетов, тредов и прочих радостей жизни, что бывают системные вызовы.

И, как ни странно, начиная с этого уровня, уже может появляться, вполне себе понятная, практическая выгода для «программиста», для человека, эксплуатирующего систему. Понимая, как устроена ОС, где там что может затыкаться, ты не просто в режиме каргокульта команды mstat и iostat, oprofile и т.д. вводишь в консоль, а в правильном, верном порядке с пониманием происходящего. За счет этого можно раз в 5-10 быстрее разобраться в какой-то проблеме, если у тебя затык именно на уровне ОС. Что-то в aeroswap ушло. OM killer опять продуктивный application-сервер убил, в четвертый раз за последнюю неделю на этой машинке. Не зная этого, сложно разбираться.

Бонусом неплохо бы понимать не просто про наличие управляемых ОС ресурсов, сеть, диск и т.д., а еще и про протоколы на уровне ниже. Что, дескать, не просто есть черная коробочка «ОС» и в ней еще более черная коробочка «файл-система», а хотя бы общее представление иметь о том, какие там примерно структуры данных в этой файл-системе, какая операция во что выливается. Опять-таки, никто не требует, чтобы честный и очень сильный программист на Haskell, который 130 уже не жмет, уже 140 жмет, наверное, качается же постоянно. Никто не требует даже от сильного программиста на Haskell уметь за вечерок написать новую реализацию X4FS. Но я уверен почему-то, что именно сильный программист на Haskell, тем не менее, представляет, какие там структуры данных, операций и какое действие из своей вполне себе пользовательского уровня программы к чему приводит. То же самое с железными протоколами, по которым процессор с памятью говорит, это все-таки на предыдущем уровне, а мы железки не паяем.



Двигаемся дальше по нехитрой иерархии разработки долбанного софта. Где-то оттуда, мы еще не вылезли из подвала. Там где-то совсем глубоко зарыты железо, поверх него операционка, поверх нее всякие… Я не знаю, принято ли в вебе все это дело называть middleware, в годы древние работы в GameDev оно называлось middleware, т.е. тот промежуточный слой, который ты сам не пишешь, который ты пользуешь. Никто ж не пишет свой физический движок или 3D-движок, или еще какой-нибудь еще движок очередной. Лучше всех по задумке и полное говно по факту. Все пользуются нормальными человеческими MySQL, Mongo и т.д.

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

Но все знают, что есть определенная святая троица, которая в каждый момент меняется. MySQL, Mongo и Memcached на сегодня. Годится как святая троица? MySQL потому что привычно, Mongo потому что webscale, а Memcached потому что парочки ключ-значение, стыдно класть в MySQL и в Mongo. Ну, зачем по такой мелочи тревожить таких уважаемых людей? Но эта святая троица от года к году может меняться. Но ею, к несчастью, не ограничиваются, есть еще масса смежных технологий. Желательно иметь представление о том, что, кроме MySQL, PostgreSQL бывает, например.

Но у меня не хватит времени, если я буду по каждому слову в детали лезть, поэтому приходится ограничиться словом «базы», например. Но базами опять не ограничивается современная достаточно сложная система, которая делает что-нибудь полезное. Понятно, что гостевая книга ограничивается, но странно ее называть сложной системой. Области, в которых, скорее всего, так или иначе в одной из них, а, может быть, не в одной, придется разбираться – они, опять же, на слайде.

Что-то надо знать про доступные вам базы, что-то надо знать про доступные вам веб-сервера, уметь замотивировать матом решение поставить lighttpd вместо nginx. Это очень важно. Местами придется что-то знать про видео, кому-то придется что-то знать про звук. Вряд ли всем придется знать все, но общее представление иметь не бесполезно.

Сюда же, я цинично запихиваю всякие увлекательные технологии от Hadoop’a до Spark’a и прочего, которое в более модных middleware’ных категориях с клевыми базвордами типа bigdata, cloud, cloud, cloud и т.д. Мы говорим cloud, подразумеваем hadoop, мы говорим hadoop – подразумеваем cloud. И Apache – наш рулевой.

Этот слайд мне дико не нравится. Все остальные еще кое-как, куда не шли. В этом, к несчастью, каждое отдельное слово – отдельная наука, по которой надо писать еще больший drill-down. Но – все, чем могу.

Поднимаемся дальше. Процессор есть, ОС есть, софт выбрали. Собственно, надо на чем-то писать наше приложение.



Хотелось бы, чтобы тот самый анонсированный в заголовке highload-гуру понимал, что бывают разные языки программирования – скриптовые, нативный код, ненативный, чем отличается, какие есть методы исполнения байт-кода, у кого какой компилятор, насколько плохой, с одной стороны. И общие принципы справляться с этими самими языками программирования, с другой стороны.

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

Все кладем все в Git, да, ок. Все согласны все в Git класть? Я все в Git’е храню. А в GameDev никто не работает? Т.е. терабайт asset’ов никто в Git не клал? Ни у кого после этого дата-центр не взрывался буквально от перегрева? Вот опять тот самый случай, когда хотелось бы понимать, что ни Git ‘ом единым и некоторые виды штук не обязательно класть в Git.



Многие уже заскучали, поэтому я хочу вас обрадовать – это формальный экватор. И 3/4 времени по таймингу доклада – это ровно половина списка ключевиков. У меня еще два бонус-трека есть. И здесь должен быть обязательный котик, потому что все любят котиков.



Задумайтесь над этим простым, но в то же время гениальным слоганом в следующий раз, когда вы будете коммитать в ваш проект. Мне кажется, что если можно весь доклад, все это растекание мыслей даже не то, что по древу, а по лесу деревьев, свести к одной мысли, то пусть это будет эта мысль. Следующий раз, когда коммитаешь, вспомни котика. Он не всегда одобряет то, что ты делаешь. Иногда, наверное, одобряет.



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

Как ни странно, я не так давно это осознал, в смысле не 40 лет назад, а меньше, но внезапно осознал, что ежедневная работа программиста заключается в работе с одной структурой данных. Одной. И эта структура – вектор. В этом плане выгодно отличаются программисты именно на PHP, потому что те программисты на PHP, которые прочитали методичку из предыдущего пункта, №4, про устройство языков, знают, что векторов, они же массивы, в PHP нет. Там есть только ассоциативные массивы, т.е. хэши, тем самым программист на PHP является в некотором виде венцом творения, потому что программист на других языках в ежедневной деятельности могут использовать только массивы, и будет отличный рабочий день, и все будет работать, и все будет хорошо. А вот программист на PHP не такой. Он обязательно каждый день использует хэши, даже если он их использует как обычные массивы с индексами от 0 до 100.

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

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

Т.е. не каждый день, а если повезет, то и не каждый месяц, но возникают такие задачи, которые в вектора и хэши не укладываются. И здесь начинается вся эта херня. Мало нам массивов, векторов, хэшей, надо еще знать про списки, про деревья, про очереди, про их скоростные характеристики, чего стоит, что вставить, чего стоит, чего поискать, что по памяти во что выливается и т.д. Как с ними работать, как их комбинировать между собой, сделать хэш деревьев. Не, хэш деревьев не модно, давайте очередь деревьев. Все еще не модно, очередь деревьев founder in the bother (?). Есть и такие. Не дай бог, кто-нибудь когда-нибудь реализует в любом из моих проектов, убью сразу, но они есть.

В момент, когда мы все это на алгоритмическом уровне реализовали, вам присваивается почетное звание либо математика, либо студента. Лучше студента, потому что студента еще можно научить, а математик – это диагноз. Математик – это кондом, который весь код пишет, как на Фортране, как в 72-ом научили. Т.е. все переменные строго: a, b, c, d, e. Когда кончаются, то aa, bb, cc. Юниты, моки, ассерты, логи, комментарии? Не, не слышал, в 72-ом на перфокарте каждый бит экономили. Не надо так делать. И хотелось бы, чтобы все присутствующие понимали, что не надо так делать и что, к несчастью, каждое из слов на слайде полезно иногда, а не пустой звук. Слава богу, хоть один слайд про код был. А может второй будет?



Однопоточный код писать легко и приятно. К несчастью, какая-то сволочь анонсировала 10-ядерную мобилу. Это значит, что в предательской близости от самого дорогого я ношу 12 ядер, а не привычные 2. А это значит, что все там будем, и код придется всем писать в расчете на то, что исполняется даже локально в довольно параллельной среде с массой потоков и со всеми сопутствующими сайд-эффектами.

Надо понимать, как не просто написать 20 строк кода на Фортране, а как его

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

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

Опять целая отдельная наука. Или здесь на этом слайде 3-4 целых науки, т.е. одна про ООП, вторая про паттерны, третья про функциональное программирование, хотя бы какое-то представление, четвертая – про многопоточку. Наверное, пункт №2, который я достаточно развернул, потому что он мне кажется важным, он про многопоточку весь. Вот как бы, хотелось бы.

Я делаю предсказание, что через определенное количество времени просто написанием однопоточного кода уже не отделается вообще никто, даже те, кто пока на фреймворке V8 пишут свои javascript’ы.



Внезапно: пара штук, которые уже непосредственно к коду и всей этой мегапирамидке, на которой этот код исполняется, all the way down, к железу, земле и черепахами, на которых Земля стоит, две важных темы не совсем вверх, но вверх и вбок. Первая – это те самые специализационные темы, которые в каждом проекте будут разные, но, наверное, в каждом проекте все-таки будут, потому что в каждой женщине должно быть что-то маленькое, черное и сморщенное, т.е. изюминка.

Спец. темы – сжатие с одной стороны, и работа с картинками – с другой стороны. Обработка сигналов. Кто-то, наверное, компилятор до сих пор пишет, не все команды, этим занимающиеся, еще вымерли. И тут такой интересный момент и такая интересная религия. Опять-таки, сложно ожидать, что если ты всю свою жизнь писал MapReduce фреймворк в Яндексе, т.е. вообще бесполезный скил, ты его писал-писал, а весь мир на hadoop сидит, чего делать-то? Да и в Google свой фреймворк тоже. У тебя глаз замылен, плохо представляешь, что там происходит в данный момент в науке, которая про картинки или, например, как компиляторы пишут, или где проходит frontier в машинном обучении. Это плохо для тебя. Узкий специалист подобен флюсу – полнота его односторонняя. Этот слайд мне не нравится точно так же, как предыдущий слайд про middleware, потому что опять же ряд из этих тем можно долго и интересно раскрывать. Про одно машинное обучение горячих базворд просто перечислить с десяток толковых техник и границ их применимости и т.д. и т.п. – задача на отдельный маленький курс.



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

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



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



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

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

Следующий вопрос, который может возникнуть, пожалуй: «Зачем мне это все? У меня по наследству квартира в центре Москвы, нормально все с баблом, я на PHP пишу для лулзов, на хер мне знать, как операционка устроена?». Правильный ответ: оно вам не надо, скорее всего. Т.е. мотивация баблом для программиста не работает, для программиста должна работать мотивация для собственного интереса.

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



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



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





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



Пиши код, пиши код, пиши код.



Здесь должны быть некие стандартные мантры.



Сверхцель всего процесса.



Системы сложные и с точки зрения не то, что внешнего человека, работа той или иной большой системы типа того же дата-центра Google может выглядеть как полная магия, но и с точки зрения сотрудника той же самой компании Google она меньшей магией не является. Ну, ок. Ты знаешь, как javascript на страничке какой-то работает, одной из миллиарда. Как работает все остальное ты не имеешь ни малейшего представления. Значит, я считаю, что магии нигде никакой нет, и хотя бы общее представление обо всех местах работы той или иной системы, в принципе, при достаточном упорстве способен составить любой. Дерзайте!

Контакты

» shodan@sphinxsearch.com
» shodan

Этот доклад — расшифровка одного из лучших выступлений на конференции разработчиков высоконагруженных систем HighLoad++.

Если у вас период «карьерного полураспада» больше, чем три месяца и вы готовы прокачивать свою «мозговую мышцу», то мы рекомендуем обратить внимание на обучающую конференцию по разработке высоконагруженных систем HighLoad++ Junior.

Вот, например, некоторые из докладов-погружений этой конференции:

• схема работы HTTP-акселератора;
• сложные типы данных в реляционных СУБД;
• балансировка HTTP-трафика;
  погружение в виртуальную память;
  как устроены базы данных;
  чеклист по MySQL.
  
  
  Интересный набор? Подключайтесь!