Друзья, перед вами очередной выпуск «Без слайдов» — программы, видеокаста, подкаста, где я беру интервью с интересными мне людьми. Гостем этого выпуска стал Руслан Черёмин aka cheremin, эксперт по Java и Concurrency. Мы поговорили про Java Memory Model, техническое блогерство, культуру эксперимента, фундаментальное образование и многое другое.
Как всегда — под катом расшифровка интервью.
Кому нужны модели памяти и многопоточные велосипеды
— Сегодня мы говорим про технологии. Руслан, три года назад ты рассказывал про модели памяти — говорил, что очень мало людей понимает, что это такое, как устроено и работает. В частности, говорил, что видишь это на собеседованиях. Изменилось ли что-то за последние годы?
— Изменилось: я перестал вести собеседования! Поэтому немножко потерял нить и не наблюдаю это напрямую. Если судить по тому, что читаю, а не по личным впечатлениям — да, сейчас имеется гораздо больше информации, но не уверен, что стало больше понимания. Скорее, все стали задавать на интервью определённые вопросы про модели памяти, соответственно, другая сторона заучила ответы на них. Это тоже неплохо, ведь какую-то часть косяков запомнили — что так делать не надо, а надо делать вот так. Не нужно понимать модель памяти всем.
— Среди твоих коллег, с которыми ты сталкиваешься по работе, есть ли потребность в этих знаниях?
— В действительности выходит, что на глубоком уровне это нужно немногим. Если у тебя в команде есть один человек, который тебе в сложной ситуации может подсказать, то этого достаточно.
Все же говорят, что это сложно, — и это реально сложно. Делать собственные concurrent-алгоритмы— это не то, чем будешь заниматься каждый день, потому что это обычно не окупается. Как правило, ты собираешь из конструктора что-то готовое, где-то подтюнишь в простом случае, и этого достаточно.
— Это паттерны многопоточного проектирования типа «Java Сoncurrency in Practice»?
— Да. Если ты это знаешь, больше 99% задач решишь. Важнее понимать, где проходит твоя граница: чтобы ты понял, когда наступаешь на те полпроцента, где ты не можешь компетентно самостоятельно сделать. Тогда ты идёшь с вопросом.
— Где проходит твоя граница?
— Помимо модели памяти, как некой абстрактной модели, есть ещё множество перфомансных деталей, где всё гораздо глубже. С абстрактной моделью памяти я более-менее разобрался. Это не значит, что всё понимаю — там имеется большая часть про Data Races, и непонятно, нужно ли её понимать ещё для чего-то, кроме как для завершения формальной модели.
А есть другая задача — окей, ты сделал корректный алгоритм, но будет ли он быстрее, чем что-нибудь примитивное, собранное из готового конструктора? Это большой вопрос, потому что люди, которые пишут элементы готового конструктора, которые пишут java.util.concurrent, знают гораздо больше тебя. У них больше ресурсов для того, чтобы сделать хорошее решение.
— С другой стороны, если ты в большой компании разрабатываешь высоконагруженные решения, то знаешь про перфоманс больше, чем те люди, которые это делают в теории — у тебя имеется под рукой куча продакшн серверов, и ты с этим сталкиваешься каждый день.
— Это правда. Но ты сталкиваешься в каком-то конкретном сценарии, и получается, что ниша для самопальных решений – это когда у тебя есть конкретное железо, конкретная версия или диапазон версий Java, конкретный софт. Тут, конечно же, обставить Дага Ли не так уж сложно, если у тебя всё это зафиксировано. Потому что гений Дага Ли в том, что он пытается сделать хороший алгоритм, который работает на целом спектре платформ и виртуальных машин и для целого спектра сценариев использования. И всё это работает на 70-80% от оптимума. Вот это очень круто, для того, чтобы такое делать, нужно в голове очень много всего держать. А когда у тебя есть конкретное железо, есть конкретная версия Java, и пиши бенчмарки — тут тоже нужна какая-то экспертиза, но не заоблачная.
— Был ли в твоей практике опыт, когда ты писал что-то самопальное, и оно начинало работать быстрее в разы?
— Был такой опыт. Другое дело, что ускорение алгоритма в разы ещё не гарантирует, что система также начнет работать в несколько раз быстрее. Ты ускорил конкретную штуку, например, в три раза, что даёт 5% прироста, и это ещё хорошо, если получилось столько. У меня был опыт ускорения конкретного места в разы — просто это не имеет значительного веса в масштабе всей системы.
— Обычно ты переходишь к другому узкому месту?
— Да. Ты открываешь это узкое место, и когда оно становится широким, натыкаешься на следующее, так обычно происходит.
— Получается, что общий прирост производительности не очень большой, и вложения не окупают себя?
— Не всегда, но, как правило, ультраоптимизация отдельного маленького куска окупается редко. Возможно, именно поэтому не так много крутых специалистов, которые это всё дело знают. Думаю, что это будет меняться дальше по мере того, как ядер будет больше, и всё больший процент алгоритмов придётся делать concurrent, чтобы обеспечить вменяемую производительность — это моё видение.
О техническом блогерстве
— Мы с тобой познакомились лет пять назад. Ты тогда серьёзно увлекался всей этой темой, и по concurrency у тебя был один из самых популярных в рунете блогов. Сейчас ты снова пишешь, но всё же немного про другое — то есть, рассказываешь тоже про перфоманс, но уже про Escape Analysis. Ты с этим закончил или будешь развивать это дальше?
— Сам не понимаю. У меня нет планирования на год вперёд — мол, написать серию постов по Escape Analysis. Если есть что-то интересное, про это и пишу.
— Откуда у тебя появилось желание делиться своим опытом с миром?
— Есть большая ценность в какой-то ясности. Сначала ты делаешь что-то понятным для себя, а потом возникает вопрос — может быть, это иллюзия понимания, потому что ты нагрузил себя большим количеством информации? А можешь ли ты это изложить так, чтобы другому человеку было понятно? Это как в математике — можно найти идею доказательства, но потом её надо оформить в доказательство грамотное и формальное. Думаю, из математики и пришла ко мне эта идея — пишу в блог и похожим занимаюсь.
Конечно, есть мотивация писать для других, поделиться опытом, похвастаться, в конце концов — столько же трудился. Но в то же время есть, так сказать, собственная мотивация в том, чтобы ясно изложить мысль, сделать понятной и читаемой. В такой момент понимаю, что тема закрыта, и это придаёт чувство некоторой завершённости.
— Изменилось ли за последние годы твоё собственное понимание области concurrency? Были ли резкие развороты, или оно просто обросло «мясом»?
— Четыре года назад я увлекался формальными моделями — было интересно, как это можно формализовать, как эту сложную тему можно втиснуть в рамки формальной модели. И за это время я понял, что формальная модель — не самое сложное. Формальная модель — это всего лишь такой договор.
В отличие от физических моделей, это гораздо менее фундаментальный договор. Это не договор между природой и человеком — это договор между одними людьми и другими. Вы просто договорились делать так и пытаетесь делать именно так.
Поэтому мне не очень интересно слишком глубоко изучать формальные модели. Дело в том, что за ними стоит какая-то инженерная практика: решения инженеров, которые делают процессоры, решения других инженеров, которые пишут языки программирования, и все они между собой должны договориться. Математическая строгость — это некий компромисс между ними, не очень фундаментальный.
— Ты следишь за тем, что происходит в сoncurrency-interest?
— Слежу. Но, например, за тем, что сейчас происходит с JMM 9, новой моделью памяти, пока не слежу — жду, пока они договорятся до чего-то, что смогу понять. Там есть определённый процент специалистов, которые эту тему знают гораздо лучше меня, и когда я пытаюсь понимать, о чём они говорят… в общем, жду.
— Поговорим об escape analysis. Как тебе пришла идея этим заниматься?
— Это клёвая идея и далеко не молодая, про неё услышал впервые 5-7 назад. Казалось, что это может быть чем-то революционным, если будет хорошо исполнено в Java.
Потому что есть много людей, которые жалуются — мол, мало возможностей, непонятно, как и где память аллоцируется и когда деаллоцируется. Но этого, правда, действительно не хватает — например, я точно должен знать, что N-ый объект лежит от сих до сих. Да и зачем мне в Garbage Collector мусор сдавать. И здорово, когда за меня могут всё это делать — могу расслабиться и получать удовольствие от жизни.
И когда эта идея появилась — вроде бы ещё Sun рапортовал, что это у них будет — я ожидал, что будет взрыв статей по этому вопросу и что эту работу сделают за меня. Я ленивый человек и лучше подожду, пока все напишут. Появился небольшой процент базовых статей, но сложилось впечатление, что просто не выстрелило — будто как-то вроде работает, но положиться на это нельзя. Я периодически пытался возвращаться к этой теме, но всё ещё был ленивым, гуглил и ждал, что кто-то за меня уже сделал эту работу.
Но никто эту работу не делал. И уже потом я читал чей-то горячий код — то ли это быk код Aeron-a, который всё там делал, то ли Chronicle Map Питера Лори.
И я увидел, что человек в горячем месте, где явно не должно быть никаких аллокаций, прямо возвращает объект просто из метода, как кортеж. То есть, он явно рассчитывает на то, что здесь не будет никакой аллокации. Да, я понимаю, что escape analysis должен это убрать, но вижу, что человек уже доверяет этому. Получается, что анализ втихаря дозрел уже до той стадии, когда на него хоть в простых ситуациях, но можно положиться.
Это меня и подтолкнуло, что надо перестать тормозить, взять и попробовать. Так потихоньку всё и выросло.
— Если вкратце, каков результат твоей работы?
— Получается, что в большом проценте сценариев при определённых условиях это действительно работает и работает достаточно надёжно. Но есть несколько неочевидных «но», недостатков, которые если не знаешь, то и не догадаешься, какие они должны быть. Есть более очевидные «но», по которым понятно, откуда они проистекают и как их обойти.
— Если где-то Escape Analysis машина не может сделать, значит, ей не хватает какой-то информации, либо она упирается в какие-то трейд-оффы. Какой обычно информации не хватает и какие трейд-оффы обычно в этом месте появляются?
— Oracle теперь не слишком-то напирает на Escape Analysis, в том числе потому что Value Objects уже в RoadMap-е, которые, с другой стороны, частично решат эту проблему. Алгоритм, по которому работает escape analysis, мутировал, но его узкие места остались такими же, какими и были в 2010 году — кардинально менять их означает выпилить большой кусок и вставить на его место какой-то другой. Не уверен, что в HotSpot на это пойдут. Есть другой алгоритм, который реализован в Graal. У них другой подход и, возможно, он во многих случаях более умный.
— Эта вещь сильно связана с тем, как работает конкретно JIT?
— Да, конечно, escape analysis достаточно вклеен в JIT, но и у него самого есть алгоритмы.
— Как я понимаю, с точки зрения IR-а (внутреннего представления компилятора), Graal и C2 не очень сильно отличаются. То есть, вроде как модель, с которой работает компилятор, очень похожа. За счёт чего и почему в Graal сделано по-другому?
— Я всё-таки не разработчик компиляторов, но моё понимание в том, что спустя 7 лет с момента, когда ты впилил алгоритм впервые, не так-то просто поменять один алгоритм на другой, сильно отличающийся. Да, он уже расползся по всему коду.
У меня есть представление, что Graal как раз и возник как проект, который, возможно, позволит со временем избавиться от какого-то количества исторических наслоений OpenJDK. Потому что принципиальных фундаментальных ограничений нет, но просто объём работы, который нужно проделать, очень велик.
— Ты экспериментировал с Graal?
— Скорее пока читаю, что про него пишут.
Практика расходится с теорией
— Думал ли ты о том, как тебя занесло в эту историю? Почему из всего многообразия технологий ты занимаешься тем, чем занимаешься? Твоя повседневная профессиональная деятельность сильно связана с перфомансом и его оптимизацией?
— Примерно 10% моей работы связано с перфомансом. В остальном я занимаюсь тем же, чем занимается большинство старших разработчиков — жонглирую классикой, «классик сюда, классик туда».
— И насколько часто удаётся обходиться простыми решениями? А сколько приходится сидеть и ломать голову?
— Голову мне ломать, как правило, приходится скорее над дизайном, не над перфомансом. В тех проектах, над которыми работаю, не нужно глубокое его понимание.
— Часто ли твоя практика расходится с теорией? Часто ли реальность, которую ожидаешь увидеть, она отличается от того, что видишь на самом деле?
— Практика расходится с теорией. Я делаю ожидания на основании чего-то, своей интуиции. Например, я читал про алгоритм, каким он был 10-15 лет назад, и понимаю — да, должно сработать. В этом случае чаще получается так, что работает лучше, чем ожидаешь. Всё-таки инженеры не зря свой хлеб едят. Бывают и другие случаи, но по статистике чаще работает лучше ожиданий, нежели хуже. А если сравнивать с кодом OpenJDK, то это очень непростая штука.
— Особенно, видимо, С2-компилятор.
— Да. Поэтому там сложно делать выводы, и можно руководствоваться лишь предположениями.
Про образование
— Напомни, кто ты по образованию?
— Я теоретик, закончил физфак МГУ — занимался там хаотическими процессами.
— Я хаосом тоже занимался в своё время, правда, в математике. Как думаешь, физика, которой ты посвятил много лет, изменила тебя? Что твоё физическое образование даёт тебе как инженеру?
— Одна из важных вещей, которые даёт фундаментальное образование — возможность во всём разобраться, если приложить достаточное количество усилий. Часто ловлю себя на том, что смотрю на какую-то задачу, и возникает ощущение, что она для каких-то особых людей, а я вообще не разберусь. На самом деле могу, если потрачу на это какое-то количество сил. Но проще дождаться, пока кто-нибудь напишет простую статью, которую ты прочитаешь, всё поймёшь и будешь доволен.
Второй важный пойнт — сложно чётко провести границу образования. У каждого человека есть собственный путь через систему образования, каждый проползает своим маршрутом. У меня был не только физфак, был и интернат — СУНЦ МГУ. Там я тоже занимался физикой, но больше математическими науками. И мне сложно сказать, кто я в плане мировоззрения, что больше повлияло — физфак или интернат. Я ведь IT осваивал самостоятельно, и самостоятельный процесс обучения отличается от того, когда учат тебя — появляется ещё свой, другой взгляд.
— Чем ты занимался несколько лет между тем, как стал заниматься серьёзно performance и concurrency, и тем моментом времени, когда закончил физфак?
— Зарабатывал деньги. Ещё на физфаке занимался программированием, сначала не нагрузками — обычным энтерпрайзом небольшого масштаба. Потом какое-то время работал в образовании — в 1С есть отдел, занимающийся продуктами для образования, обучающими курсами. Сначала я делал математический конструктор, который «Живая геометрия», потом дошёл до физических. Математических выпустили пять версий и продолжают выпускать. Это был интересный опыт — некий гибрид программирования и образования, но всё же маленькая работа по масштабу. Client-side софт, много интерфейсных задач, и баланс между сложными алгоритмами и интерфейсом зачастую смещён в «давайте побольше кнопочек».
Потом был Яндекс, где мы занимались симуляцией, и там впервые мне пришлось плотно заниматься перфомансом — у нас была задача смоделировать на ограниченном объёме железа всю сеть Яндекса, с какими-то значительными упрощениями, конечно. Но всё это надо было впихнуть в один сервер, поэтому много с чем пришлось поиграться там, не выходя за рамки здравого смысла. Я не делал супер-трюков и просто жонглировал тем, что у меня было. Оттуда как раз вырос Disruptor причём совершенно случайно — искал что-то другое и наткнулся на него, и он меня почему-то заинтересовал. Потом я познакомился с Вовой Долженко — он крутился вокруг этой темы и работал в Deutsche Bank. Так я и оказался в Deutsche.
«Тыкать палочкой природу»
— Культура физики — это культура эксперимента, которая сейчас отсутствует у людей. Люди не понимают, что это такое и как модель строится, как узнать какие-то свойства модели, как сделать вывод назад в реальность.
— Мне кажется, что всё-таки в естественных науках есть определённый взгляд на то, как «тыкать палочкой природу», он формировался столетиями. Есть значительное количество выпускников того же физфака, так и не успевших понять эту идею, да и я сам вообще теоретик, честно говоря. Руками вообще работать не люблю. Это прививается с лекциями Фейнмана или с чем-нибудь подобным. Просто разные мотивации у людей, которые ставят эксперименты в IT.
Есть естественно-научная мотивация, то есть потыкать палочкой в природу и понять, что происходит. И на первом этапе у тебя нет практической задачи — сначала я пойму, что происходит, потом верну задачу и попытаюсь понять, можно ли результат приложить или нельзя. Получается, что у меня не все модели идут сразу на практику.
— А разве не так происходит, что к тебе прилетает конкретный кейс, где что-то тормозит, и надо разогнать в три раза?
— Да, но есть другой подход, когда к тебе приходит конкретный кейс и всё, что тебе нужно — решить его. Это такой, даже не рискну назвать инженерным, скорее ремесленнический подход. Он не плохой, но они разные в том, что ты либо получаешь некую модель, либо решаешь (или тебе кажется, что решаешь) конкретную задачу.
— То есть, ты можешь взять, не понимая модель, перепробовать 10 разных способов?
— Да, и один из них выстрелит. Потыкать, и если выстрел будет — замечательно, закрыли задачу. Это не обязательно плохо, если какие-то объективные метрики показывают, что задача решена, может быть, это и хорошо. Бизнес не всегда готов платить за научные исследования продолжительностью в месяцы, и не всегда это надо. Всё-таки окупаемость — важная вещь.
Но это разные подходы, и где-то один лучше, где-то второй. И плохо, когда человек не понимает границу между применимостью. Да, понятно, что надо представлять оба подхода и различать их. И когда человек, приученный к подходу «просто решать конкретную задачу», начинает делать бенчмарки и вытаскивать из них какие-то модели, то обычно получается фигня.
— На эту тему есть целая школа— в Скандинавии, кажется. Там один мужик сделал крутую штуку: ты запускаешь определённый набор тестов, и он по результатам бенчмарков строит модель того, как устроен твой процессор. То есть он пытается их по-разному гонять и за счёт этого строит предположение о том, какой здесь кэш — общий или нет, сколько ядер и так далее. И это, получается, тот подход, который на основе бенчмарков пытается понять, что там в реальности.
— Но надо понимать, сколько по времени человек подбирал этот набор бенчмарков, и сколько моделей пришлось перебрать — у него же есть некий набор моделей, из которых он делает выбор. Это совсем не то же самое, что тыкать пальцем вслепую. Здесь есть набор гипотез и есть набор бенчмарков, позволяющих делать выбор из этих гипотез.
— Это трудно. Если 10 лет назад можно было сказать, что у нас есть процессор Intel, у него MESI-протокол когерентности кэшей, то сейчас мы знаем только, что там MESI-подобный протокол когерентности кэшей, но я даже не уверен, что это есть в спеке. По-моему, это закрытая информация. Как жить-то в таком мире, когда тебе не лень узнать что-то, а просто не сообщают информацию?
— Сложно жить, конечно, в таком мире. В этом случае приходится полагаться либо на то, что разработчики JVM договорятся с разработчиками Intel и им втихую всё расскажут, либо что они сами всё выяснят — неплохой вариант, для большого процента случаев это работает. JVM сама сделает работу, которая тебе нужна. В этом направлении и идёт IT — мы всё дальше уходим от железа.
— Это про разделение уровня абстракции. С другой стороны, вся эта штука становится всё сложнее. И дело не в увеличении количества слоёв, а в том, что сложность каждого слоя возрастает. Я боюсь, что через какое-то время попытки построить модель будут не то что трудными, а невозможными — настолько высокая будет сложность.
— Да, возможно и тяжело будет с таким подходом. Но так же надо понимать, зачем тебе это и нужно ли вообще. Хорошая модель нужна людям, которые пишут JVM.
— Я скорее про то, что люди, которые берут 10 стандартных способов и пытаются как-то комбинировать — может быть, они и правы?
— Надо хорошо понимать, зачем ты в эту область лезешь — туда, где стандартные способы не комбинируются или кажется, что не комбинируются. И можно полезть просто из интереса, но тогда практическая ценность результатов под вопросом.
Интерес — это нормальная мотивация, это важная вещь. Отсюда и возникает любовь к своей работе, без которой ничего не получится. Если хочется поиграться, это замечательно. Но если ты полез ради интереса, ты должен это понимать. А если полез с конкретной целью и уверен, что более простые способы не дадут тебе результата, будь готов встретиться с большой сложностью.
Как найти время на саморазвитие
— А ты любишь свою работу?
— Да. Думаю, что мне повезло, так как минимум несколько дней в неделю я её люблю.
— По долгу службы я много общаюсь с разными людьми, и часто жалуются: «Я хотел бы написать статью, сделать доклад или что-то для себя, но начальство не даёт времени нормально поисследовать. Поскольку не могу гарантировать серьёзный прирост, мне обычно говорят: «Перебери 10 способов, которые ты знаешь, скомбинируй из них что-нибудь, и давай дальше, потому что времени на исследование у нас нет, фичи пилить надо». Как ты решаешь этот вопрос?
— Я тоже часто про это слышу, какая, мол, у вас хорошая работа, что у вас есть время всё это исследовать. На самом деле, это некий замкнутый круг — если ты не можешь найти для себя время на самообразование, ты не делаешься достаточно ценным или компетентным сотрудником, чтобы предоставление тебе времени было разумной инвестицией.
Если всё время остаёшься на уровне какого-нибудь Middl-а, ты вряд ли накопаешь что-то полезное, и в этом смысле статистически работодатель прав. Он хочет получить точный результат, а про копания сотрудника непонятно, дадут ли они результат. Конечно, поначалу приходится это делать в своё время, вечерами, но это нормально. Если у тебя нет к этому интереса, то вообще непонятно, зачем в этой области работаешь.
— Ну область можно из-за разумных денег выбрать. Я ездил недавно к друзьям в Тулу, так там они со своими программистскими зарплатами короли Тулы. Приходишь в клуб, и там люди из этой компании. И в Белоруссии то же самое, в Минске приходишь в любой кабак — там айтишники.
— Если ты пришёл в эту сферу только за деньгами, окей — ты средний уровень, и это нормально. Чтобы вылезти выше среднего, нужна какая-то мотивация за пределами денег, и это, думаю, так во всех сферах деятельности. Тебе должно быть интересно.
Если тебе интересно, ты находишь время. Но дальше, как ни странно, становится проще, потому что когда ты уже достаточно заметный специалист, тебе проще объяснить людям, которые занимаются приоритезацией задач, что здесь надо выделить время на то, чтобы решить эту задачу хорошо. И тебе больше доверяют в этом смысле.
— Блоги, юзергруппы, конференции — это публичная деятельность. Помогала ли она тебе в карьере?
— Конечно, помогает. В Deutsche Bank я так и пришёл, не думал подавать туда своё резюме, но оказалось, что я как раз там и нужен.
— То есть, в частности, это тоже способ — копать-копать что-то интересное и показывать наружу?
— Да. Конечно, здесь и опасная штука есть, если ты делаешь только для того, чтобы быть известным, да. Тогда чувствуется эта фальшь, когда человек пишет для того, чтобы сделать себе имя.
— Если говорить про IT-шников, как здесь устроен баланс? Люди больше хотят пиариться, или их прёт, и они хотят систематизировать?
— В том, что я читаю, вижу интерес к теме. Но тут возникает другая задача: надо писать ещё и понятно, а у людей из IT зачастую с этим проблемы.
— Как и с любой коммуникацией. Вот ты занимаешься контактной импровизацией в танце — она развивает в тебе коммуникативные навыки?
— Думаю, что не очень.
— То есть, это про другое?
— Для меня да, хотя многие говорят, что им помогает потом в общении.
— Когда ты начинал писать, был ли в тебе страх быть осмеянным, и прошёл ли он?
— Знаешь, самое интересное, что сейчас больше переживаю за свои посты. Потому что когда я начинал писать, про меня никто не знал — ну, написал что-то глупое, да кто там прочитает. А когда обнаружил, что количество читателей подскочило, и вроде я уже на конференциях выступил, начал по десять раз вычитывать каждый пост. Всё сделать надо аккуратно, вычистить, чтобы никто не придрался.
— Мне кажется, ничего страшного, когда ты написал десять вещей, и одна немного выпадает. Кроме того, ты получаешь фидбэк, и если тебе объясняют, что ты в чём-то не прав, это ведь тоже результат: у тебя картина мира стала чуть более полной в этом месте. Это же офигенно. Ты получаешь этот фидбэк?
— Вот в моём докладе про JMM, которому уже несколько лет, была ошибка, но не только я там ошибся, и это несколько извиняет меня.
— Там у вас была вообще сложная история.
— Да, и эта история повисела в моём блоге год, прежде чем пришёл первый комментатор, который написал: «Чувак, так в сoncurrency-interest написали же, что это неправда!» То есть этот feedback loop затянулся. И я чувствую некую ответственность за то, что какая-нибудь глупость может висеть так долго, потому что люди читают меня и считают, что это всё-таки авторитетная информация.
— Кого из блогеров в этой области ты посоветуешь почитать?
— Несмотря на все недостатки, хорошо пишет Martin Thompson. Думаю, даже недостатки в этом смысле хороши — развивают критическое . Надо читать и думать: «Так. Не ошибся ли здесь Мартин?» И он не боится признавать свои ошибки — честно и пишет, мол, налажал. Ну, и про Лёшу Шипилёва можно уже не говорить.
— Да. Лёша сейчас пишет большие статьи, — мне кажется, главы для книжки готовит.
— Там уже на небольшую книгу написано. Лёша — это пример для подражания, как надо ставить эксперименты.
— Меня порадовал список людей, которые по просьбе Лёши дали фидбэк по его последней статье. Появилось человек 10 мастодонтов, что приятно — появляется большой материал, и люди приходят на помощь друг другу, в данном случае Лёше, и помогают сделать чётче. Это клёво, работа как комьюнити.
— Он пишет фундаментальные статьи, так что не грех позвать таких мастодонтов, ведь такая статья — большой кусок информации, который долго прослужит справочным материалом. Я пишу статьи попроще и потому неловко привлекать того же Алексея, рассчитываю только на себя.
— Кого ещё посоветуешь, кроме Лёши и Мартина?
Nitsan Wakart пишет хорошие статьи, и его тоже несколько достаточно весомых человек ревьюит. Он тоже любит солидные лонгриды, как научные статьи.
— Но у него есть некоторая простота, читать его легко.
— Это тоже отдельное искусство — писать о сложных вещах просто и не заваливать материал. В этом и заключается недостаток русской академической школы, мол, «я вот с этим десять лет промучился, и вы теперь помучайтесь».
Полезные ссылки
- Технический блог Руслана Черёмина
- Выступление Руслана про Disruptor
- Выступление Руслана по Java Memory Model
Автор: JUG.ru Group
