Как стать автором
Обновить
0
RubyRussia
Конференция разработчиков на Ruby и RoR

Интервью со спикером конференции RubyRussia Годфри Чаном

Время на прочтение 16 мин
Количество просмотров 1.3K
Всем привет! 6 октября в Москве пройдет конференция RubyRussia — cтарый добрый RailsClub, но с новым именем. Спикеры этого года: Aaron Patterson, Charles Nutter, Godfrey Chan, Maciej Mensfeld, Markus Schirp и не только. Ну и конечно, 600 участников, лучшие компании со стендами в холле и огненное афтепати.

Традиционно, перед конференцией мы разговариваем о самых актуальных темах в Ruby и Rails. Сегодня знакомим вас с Godfrey Chan — ex-Rails core team, работает в Tilde, где разрывается между созданием умного Rails-профайлера Skylight, работой над Ember.js и развитием JavaScript на TC39. Тим-лид из Evrone Дмитрий Матвеев задал нашему гостю важные вопросы.

image


Давай начнем с пары вопросов о твоем докладе на RubyRussia?

Не хочу раскрывать все секреты! Мой доклад называется «Dropping down to the metal». Расскажу о том, как с помощью метапрограммирования написать довольно странный код на Rubу, чтобы сделать что-то похожее на JavaScript. Конечно, мы не сможем написать полноценный парсер JavaScript и исполнительную среду, но я покажу кое-какую магию, которая заставит кусок JavaScript-подобного кода выполняться в Ruby используя нативный Ruby runtime. Это весело, по крайней мере, мне очень нравится. Это та же техника, с помощью которой можно написать вещи типа rspec, rake или других DSL на Ruby. Покажу слушателям, как Ruby парсит и запускает ваш код, и какие хуки можно использовать. Думаю, что доклад будет не только веселым, но и научит некоторым полезным вещам о метапрограммировании в Ruby.

Круто! То есть будут и практические советы, верно?

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

Отлично! Думаю, доклад будет интересен как для опытных программистов, так и для новичков. Правда?

Надеюсь, что так и будет. По крайней мере, я постараюсь.

Кстати, вчера прочитал твою статью на Medium о переосмыслении образования в computer science. Статья очень интересная, и я согласен с мыслями о различиях между классическим университетским образованием и современными курсами для программистов. К слову, а почему ты сам решил стать программистом?

Просто счастливая случайность, никогда не планировал работать программистом, для меня это было чем-то вроде хобби. Мне очень нравилось возиться с компами, там легко было придумать себе занятие — случайно удалить системные файлы или поковыряться в реестре Windows. Потом мне захотелось чего-то большего. После школы я начал ходить на курсы по созданию веб-сайтов. Я был в восторге от возможности создавать что-то новое на компьютере. Но вскоре я понял, что и этого мне мало. Я мог создать некое подобие компьютерной игры на HTML, но этот инструментарий был довольно ограничен. Однажды, мой учитель дал мне книгу по PHP. Я прочитал ее всю и, неожиданно для себя, открыл целый новый мир возможностей, который дает гораздо больше, чем HTML и CSS. Это было очень круто, после этого я стал читать все больше книг на эту тему. Следующим языком, который я изучил, стала Java. Однажды я прочитал про Ruby в журнале Linux Magazine (на самом деле не про Ruby, а про Rails, конечно), и подумал, что было бы здорово изучить его. Оттуда все началось, и, как снежный ком, катится по сей день.

И так ты перешёл на Ruby, да?

Я открыл для себя Ruby примерно в то время, когда начал изучать Computer Science в колледже, так что одновременно я занимался еще и Java, C ++, Haskell и не только, изучал сразу много языков программирования. В рамках учебы у нас не было заданий по Ruby, а мне он очень нравился, так что я всегда старался использовать именно его на тех классах, где можно было выбрать технологию самому. Ну и в своих сторонних проектах тоже. Когда я окончил колледж, я решил искать работу, связанную с Ruby. Это было просто, ведь Rails тогда был на пике популярности: множество стартапов использовало эту технологию. Так интерес стал моей работой.

А сейчас ты используешь Ruby в качестве основного инструмента? Или работаешь с чем-то другим?

На моей нынешней работе в Tilde я не пишу на Ruby так много, как раньше. Я бы сказал, что моя работа — коктейль из JavaScript/TypeScript, Rust, Ruby и иногда Java. Но, так или иначе, вся работа, которую я делаю, связана с Ruby.

Основным продуктом в Tilde является Skylight. Далеко не все компоненты в нем написаны на Ruby: фронтенд — на JavaScript и Ember, бэкэнд на Rails, но вся обработка поступающих данных — это Java и Rust. Но сам по себе Skylight — это инструмент контроля производительности для Rails приложений. В этом смысле вся работа, которую я делаю, по-прежнему связана с Ruby.

Супер! Я сам зарегистрировался в Skylight несколько дней назад для одного из проектов, сейчас тестирую его. Выглядит интересно, и с самого начала понятно, как все работает. Я пока не сильно углубился, но планирую со следующей недели начать пользоваться очень плотно. Надеюсь, смогу исправить некоторые проблемы с его помощью.

Отлично, было бы здорово услышать фидбэк!

Интересно сравнить Ruby с другими языками. Например, с Rust. Ruby очень выразителен, и создан, чтобы сделать код читаемым. Если сравнить его с Python или с C++, C#, Java, они, на мой взгляд, не так легко читаются, как Ruby. Что ты думаешь об этом?

Я соглашусь. Есть два способа «выучить» новый язык. Первый — довольно поверхностный: изучаю основы синтаксиса, играю с примерами, а потом сразу забываю об этом. У меня так было с Go. Я позанимался им на выходных, затем еще пару недель писал на нем небольшие проекты. Но затем у меня не было причин продолжать программировать на Go. Я просто изучал его ради любопытства, и быстро забыл.

С другой стороны, есть JavaScript / TypeScript, Rust и Ruby, которые я использую постоянно. Каждый из этих языков открыл новые возможности для меня, это здорово мотивирует.

Например, когда я начал работать с Ruby, меня привлекла выразительность. Ни один другой язык не позволял делать такие сумасшедшие вещи, как method_missing. Метапрограммирование, выразительность и читаемость кода — ключевые вещи, которые я люблю в Ruby. Было бы круто, если бы другие языки так могли.

Но в них можно делать вещи, невозможные в Ruby. Например, JavaScript. С ним все было совсем не так, как с Ruby, в который я влюбился с первого взгляда. Я начал использовать JavaScript по необходимости, мне нужно было написать браузерный код. Хотим мы или нет, от JS никуда не деться. Если вы хотите написать интерактивное приложение для браузера, такое как Skylight (как раз то, что меня интересовало в то время), то JavaScript — единственный выход.

Я хотел перенести идеи, которые мне нравились в Ruby, в JavaScript, поэтому, в конце концов, стал работать с Ember. Это, в свою очередь, привело меня к TypeScript. Когда пишешь огромный фреймворк, типа Ember, на JavaScript, наличие типов и компилятора для проверки ошибок действительно помогает. JavaScript и TypeScript помогли мне это понять.

Идеи, которым научил меня Rust, очень похожи на TypeScript. Приятно иметь возможность скомпилировать всю программу, и быть уверенным, что она работает. Как по мне — это просто круто. Я работал с компилируемыми языками раньше: с Java и C. В них ты тоже должен ждать, пока код скомпиллируется, но от этого не так много пользы, потому что система типов в этих языках не очень хорошо ловит ошибки. Но в Rust компилятор может гарантировать, что программа не вызовет проблем с памятью, и что во время ее выполнения не будет ошибок сегментации (segfault). Одна из самых сложных вещей в программировании на C — проблемы с памятью, которых очень трудно избежать. Главная фишка Rust для меня — возможность заниматься низкоуровневым программированием, не беспокоясь об этом.

Кстати, мой интерес к Rust был связан с Ruby. Я только начал работать в Tilde, и знал, что гем Skylight был написан на Rust. Подумал, что было бы здорово научиться писать нативные расширения для Ruby таким же образом. Я хотел научиться писать на Rust, чтобы не беспокоится о том, как бы не поломать пользовательские руби процессы, как это бывает при неправильном разыменовании указателей в C. Поэтому главной целью изучения Rust для меня, на самом деле, было написание нативных расширений для Ruby.

Как раз сегодня утром работал над проектом с Питером Вагенетом из Tilde, и Шоном Гриффином из команды Shopify и core Rails team. Шон работает над новой версией Active Record, написанной на Rust, чтобы ускорить медленные части. А прямо перед этим интервью я работал над проектом на Rust под названием libcruby-sys, который позволяет писать нативные расширения для Ruby на Rust.

В конце концов, можно сказать, что все языки связаны. Языки, которые я изучаю и на которых программирую, — это просто инструменты, которые позволяют создавать то, что я задумал.

Очень интересно! Круто, что ActiveRecord станет намного быстрее. Насколько я понимаю, сама идея ActiveRecord не поменяется. Я имею в виду, это будет все тот же ActiveRecord, а не что-то вроде Data Mapper?

Active Record на Ruby, конечно, никуда не денется, он активно развивается, его используют. В случае с JRuby это первый выбор. Реализация Шона на 100% совместима с нативным API. Внутренности переписаны на Rust, поэтому все работает быстрее, но для конечного пользователя API не поменяется.

То же самое с проектом, над которым я работаю последние пару лет. Он называется Helix, и связан с моими экспериментами с Rust для создания нативных расширений для Ruby. Было очень сложно начать, из-за кучи вопросов с memory safety, которые надо было решить. Helix позволяет просто сосредоточиться на написании кода на Rust, он сам заботится о том, чтобы скомпилировать его в Ruby-extension.

Думаю, многие использовали JSON gem в Ruby. На самом деле, есть две разные реализации этого гема. Существует чистая реализация на Ruby и расширение на C, которые реализуют одинаковый API. Это не заметно, но если написать `require json`, то скорее всего будет загружена версия на C. Если же текущая платформа не поддерживается, то это будет ruby-версия. Но, опять же, API в обоих случаях используется абсолютно одинаково. Единственное отличие в том, что внутренние компоненты для одного из них реализованы на C, поэтому он работает быстрее. Кроме более высокой производительности, нет никаких отличий. Это и есть цель всех таких проектов — иметь возможность использовать Ruby, который мы любим, но получать преимущества производительности нативного кода, когда это необходимо.

Здорово, что Ruby станет быстрее. Хотя есть мнение, что скорость исполнения не слишком важна для программ на Ruby, но, я уверен, все будут счастливы, если производительность увеличится.

По большей части согласен. В целом это так. Но, серьезно увеличив производительность, мы сможем делать вещи, ранее просто невозможные на данной платформе. Как я уже сказал, я изучил JavaScript, потому что хотел писать программы для браузера, а это невозможно сделать иначе. Я думаю, то же самое верно и для производительности. Мне все равно, если код работает на 20% быстрее. Это хорошо, но это не так важно. Но когда код работает в 10 раз быстрее — это открывает совершенно новые возможности.

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

Это абсолютно верно! Я много раз боролся с низкой производительностью Ruby программ. Приходилось писать много кода на SQL, чтобы все ускорить, переносить часть логики на сторону базы данных, потому что это работает в сотни раз быстрее.

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

Да, это должно быть быстрее и проще, эффективнее с точки зрения бизнес-задач. Не нужно нанимать программистов с разными навыками и стеками, раз уж все может быть написано на Ruby. Это звучит многообещающе. Что ты думаешь о будущем Rails? Каждый год ходят слухи о том, что Rails умирает...

Я предвзят, потому что работаю в компании, основным продуктом которой является инструмент контроля производительности в Rails. Лично я не думаю, что они умирают, но Rails определенно стал взрослее, “заматерел”. Для многих людей в сообществе это что-то принципиально новое. Многие из нас присоединились к сообществу Rails и Ruby, когда Rails был хайповой темой. Было много восторгов, куча нововведений. Хотя, многие наши «нововведения» были обычными вещами в других, более взрослых, экосистемах. Многое было невозможно тогда, потому что экосистема была еще незрелой.

Это было очень захватывающее время. Каждый понедельник я с нетерпением ждал нового эпизода RailsCasts. Новый гем каждую неделю. Например, на этой неделе мы создаем PDF-файлы, на следующей неделе загружаем файл, а затем появляется что-то принципиально новое, такое, как bundler, например. Это было время свежих идей, волнительное, у всех была куча энергии. Многие считают что Rails или Ruby умирают из-за того, что эти эмоции ушли.

А на мой взгляд, экосистема просто созрела и стала стабильнее. Мы уже провели эксперименты с 5 совершенно разными способами загрузки файлов и нам просто не нужно делать это каждую неделю. С точки зрения эмоций, я определенно скучаю по тем временам. Но не думаю, что сейчас стало хуже. Можно сказать так: “ок, мы прошли все эти приключения, попробовали разные подходы, получили уроки. И теперь мы выбрали лучший вариант, который все и будут использовать”. Я думаю, это здорово.

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

Я думаю, что это естественный порядок вещей, и Rails по-прежнему прекрасен. Все что происходит — идет на пользу реальному бизнесу, который разрабатывает коммерческие приложения. Мне нравится, что Rails позволяет использовать разные подходы. Например, можно использовать trailblazer или dry-rb гемы, оставаясь в контексте Rails. Можно использовать различные виды абстракций в своем коде, но в конечном итоге это все равно будет Rails приложение. Это то, что мне нравится.

Я определенно согласен с тобой. Думаю, что вся экосистема взрослеет. В то время, которое мы сейчас называем «пиком» Rails, появлялось много новых стартапов. Никого не волновала стабильность и устойчивость. Тогда вы получаете постоянный приток новых эмоций и энергии. Теперь многие из этих компаний превратились в крупные корпорации, такие как Github или Shopify, и начали заботится о стабильности. Это справедливо для многих.

Как сообщество, мы коллективно решили предпочесть стабильность экспериментам. С точки зрения языка, есть еще много места для экспериментов, потому что Ruby остается тем же. Причина, по которой Ruby был великолепен для экспериментов, никуда ни делась. Тем не менее, сообщество решило сосредоточиться на создании вещей, которые работают на Rails, потому что Rails уже давно и активно используется. Когда вы пишете гем, вы, вероятно, сделаете поддержку несколько версий Rails, потому что есть много компаний, которые их используют. В результате Rails сами также становятся более осторожным, не ломают свой API без необходимости. Лично я счастлив быть частью этого процесса.

С точки зрения бизнеса стабильность очень важна. Особенно, для высоконагруженных систем. Стабильность интерфейсов фреймворка облегчает работу. Я помню времена, когда было очень трудно перейти от одной версии Rails на другую. Например, в тот момент, когда приложение стало выкидывать кучу ошибок из за несовместимости кодировок (encoding incompatible).

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

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

В этом смысле можно сказать, что часть Ruby-сообщества умерла. 5-10 лет назад ты постоянно делал новые вещи, не слишком беспокоился о совместимости, использовал новые и самые крутые гемы, потому что за спиной не было “багажа”. Теперь у большинства проектов в сообществе “багажа” накопилось порядочно. А те, кто любит эксперименты и инновации, переместились в другие сообщества и экосистемы.

Я думаю, что это нормально.

Я тоже не против. Это похоже на взросление, другой этап жизни.

Что ты думаешь о статической типизации? Есть ли перспектива получить преимущества этого подхода в Ruby?

Я жду этого с нетерпением, потому что уже испытал преимущества этой штуки в экосистеме JavaScript с TypeScript. JavaScript очень похож на Ruby. Это динамический язык со свободной типизацией, поэтому в нем много гибкости, но еще больше ошибок во время выполнения. TypeScript — это попытка надстроить над JavaScript систему типов, суперсет JavaScript синтаксиса. Когда вы компилируете код, компилятор проверяет типы, проверяет, что все правильно, а затем просто стирает их. Когда вы удаляете все типы из файлов TypeScript, вы возвращаетесь к чистому JavaScript.

Я вижу, что этот подход на удивление хорошо работает. Люди уже построили целую экосистему вокруг TypeScript. Мне бы очень хотелось увидеть ту же историю в Ruby. Гениальность идеи заключается в том, что TypeScript является суперсетом синтаксиса JavaScript, это новый слой, он не запрещает использовать что угодно из JavaScript экосистемы. Программист старой формации может просто взаимодействовать с нетипизированной версией кода. Другие разработчики могут получить все плюсы типизации, просто взглянув на типизированную версию. Но, в конечном счете, каждый сможет вызывать библиотеки обычным образом. Даже если использовать только стандартный JavaScript, можно получить пользу от типов, например, используя автодополнение, потому что кто-то уже сделал работу по добавлению типов в используемые библиотеки JavaScript. На мой взгляд, TypeScript является большой победой для всех в сообществе JavaScript, независимо от того, используете вы его напрямую или нет.

Вероятно, есть способ сделать это и в Ruby, никого ни к чему не принуждая. Люди, которым нравится типизация, будут выполнять свою работу, и все выиграют от этого, будь то автодополнение в редакторе, или просто знание того, что вся инфраструктура, например, Rails, содержит меньше багов, потому что внутри она использует типы, а это помогает ловить ошибки на этапе компиляции, а не во время исполнения. Мне бы очень хотелось, чтобы в Ruby это стало возможным.

Я полностью согласен. Думаю, что это будет большим шагом к стабильности приложений. А еще облегчит жизнь джуниорам: у них будет меньше шансов делать ошибки. Сейчас нужно быть очень осторожными с именованием переменных, чтобы дать понять, что хранится внутри них. Когда я пишу код, я должен очень ясно выразить, какой тип значения ожидается в той или иной переменной, чтобы меня правильно понял человек, который прочитает мой код. Если у нас будут типы, это станет проще.

Люди, которым нравятся типы, фактически используют их для документации кода. Если все сделано правильно, TypeScript отлично справляется с этим. Он читается практически как самодокументируемый код. Даже если вы не хотите смотреть на типизированный код, вы можете посмотреть JavaScript версию. Но благодаря тому, что кто-то выполнил работу по добавлению типов, можно сгенерировать документацию для нетипизированного кода.

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

Несколько лет назад, к нам на RailsClub приезжал Матц. Мы, конечно, поговорили с ним о типизации. У меня было ощущение, что он не слишком оптимистично настроен. Хотя, все могло поменяться.

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

Я могу ошибаться, но думаю, что идея Матца заключается в том, что проще программировать без типов, чем с ними.

Это действительно проще для большинства, а во многих случаях и для меня лично. Но в некоторых типах программ, например, в Rails, вы переходите грань. Без типов приходится хранить кучу информации в своей голове или в документации. В какой-то момент это становится слишком тяжело, особенно для такого большого проекта, как Rails. Я думаю, что даже для JavaScript есть такие приложения, где преимущества типов не стоят всех их сложностей. Но есть огромные проекты, такие как Ember, которые сильно выиграли от использования TypeScript. Как я уже сказал, красота разделения на слои заключается в том, что в итоге вы все равно получаете JavaScript код. Вы можете выбрать тот или иной путь, не затрагивая другую половину сообщества, которая не разделяет ваших идей. По крайней мере, мой опыт именно такой.

Какой совет ты можешь дать новичкам? Каким будет основное направление в программировании в ближайшие 5 лет?

Это огромная тема, ее можно очень долго обсуждать.Но у меня есть 2 совета.

Во-первых, вместо того, чтобы гоняться за «мейнстримом», идите за тем, что вас интересует. Может быть, мне просто повезло, но это очень помогло. Когда я погрузился в Ruby, я начал искать работу, которая позволила бы мне писать на нем. Поскольку я был очень мотивирован, чтобы узнать о Ruby больше, я начал делать коммиты в open source, и это помогло моей карьере в последующем. Это первый совет. Следуйте за тем, что вам интересно. Если вы мотивированы, вероятность того, что вы сделаете свою работу хорошо, намного выше.

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

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

Я согласен, университеты все еще важны. Я лично много получил от высшего образования. При этом мне не нравится термин «основы». Всегда есть что-то дальше «основ», которое ты можешь изучить. Главное понять, что всегда есть что-то глубже того, что вы знаете, и оно ждет своего открытия. И если вы начнете копать, вероятно, это удивительным образом вам поможет.

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

На твой взгляд, насколько полезно для разработчика заниматься обучением и менторством?

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

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

Я считаю, что наставничество — это хороший способ самому научиться. Когда учишь кого-то, сам учишься делать это намного лучше.

Я каждую неделю даю уроки Rust, и каждый раз я понимаю, как много не знаю о нем. Когда пытаюсь объяснить вещи, которые, как я думал, знаю, всегда обнаруживается что-то, о чем я и понятия не имел. Я трачу много времени после каждого урока, чтобы изучить материал, который, как я думал, уже знаю. Отличный источник опыта.

Кстати, я хотел бы поблагодарить тебя за рассылку «This Week in Rails».

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

Я получал эти письма, по крайней мере, последние 2 года. Интересно по понедельникам читать, что произошло на прошлой неделе в сообществе Rails!

Это было очень весело! Я рад, что начал этот проект.

Спасибо! Давай на последок поговорим о конференции. Остался всего месяц до RubyRussia. Чего ожидаешь от поездки в Россию?

Я не был в России и, честно говоря, понятия не имею, чего ожидать. Но я думаю, будет очень весело. Я очень рад, что приеду и уверен, что все будет хорошо. Чего я должен ожидать? Есть ли что-нибудь, к чему я должен быть готовым?

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

Я с нетерпением жду и очень благодарен за приглашение! Я как-то никогда не задумывался о том, чтобы посетить Россию. Но теперь понял, что должен был бы сделать это раньше. Думаю, я отлично проведу время!

Надеюсь поговорить лично на конференции.

Жду с нетерпением!

Было очень интересно поговорить! Спасибо за уделенное время! Хорошего дня! Увидимся в Москве!

Вас тоже ждем на конференции! Задать свои вопросы лично (и на легендарном афтепати :) можно будет 6 октября. Программа тут, а до повышения цены осталась примерно неделя. Сейчас билет стоит 8000 рублей.

Прочитать оригинал на английском можно на hype.codes.

А тут место для благодарности отличным компаниям, которые подерживают главное Ruby-событие в России:

Генеральный партнер — Toptal
Золотой партнер — Gett
Серебярные партнеры — Instamart, UCHi.ru, JetBrains
Бронзовые партнеры — Bookmate и InSales
Теги:
Хабы:
+6
Комментарии 0
Комментарии Комментировать

Публикации

Информация

Сайт
rubyrussia.club
Дата регистрации
Дата основания
Численность
Неизвестно
Местоположение
Россия

Истории