Entrevista com Aaron Patterson, presidente da Conferência RubyRussia 2018

Oi Continuamos uma série de entrevistas com palestrantes na conferência RubyRussia . Aaron Patterson (aka tenderlove ) é membro da equipe principal do Ruby e da equipe principal do Rails, um engenheiro de software líder em uma pequena startup chamada GitHub. Pavel Argentov conversou com Aaron antes de sua segunda viagem à Rússia.



Vamos começar com a pergunta padrão. Qual é a sua história pessoal de rubi? Como você pegou esse trem? Conte-me sobre suas realizações? Você fez do mundo um lugar melhor?

Eu descobri o Ruby em 2006. Eu era então um programador Java. Vamos começar ainda mais cedo: eu era um programador Perl e depois me tornei um programador Java, mas não queria ser um javista.

Porque

Quando escrevi em Perl, já tínhamos nossa própria estrutura da web. Havia muito do que o Rails tinha: você poderia simplesmente mudar o código, recarregar a página e verificar o que aconteceu. Tudo apenas funcionou. Quando mudamos para o desenvolvimento Java, ficou assim: você precisa recompilar tudo - levará 10 minutos para que você possa verificar todas as alterações feitas. Eu gosto de linguagens dinâmicas como Perl mais que Java. Era esperado o Perl 6. Então, enquanto esperava o Perl 6, aprendi sobre Ruby. Pensamento: “Uau! É disso que eu preciso! Então comecei a fazer Ruby - no meu tempo livre, por exemplo, para projetos paralelos. Você sabe, apenas por diversão. Tudo começou com isso. Finalmente, em 2008, eu já consegui um emprego no Ruby.

Já era Rails?

Sim, meu amigo decidiu iniciar uma startup. - Vamos usar o Rails. Deseja trabalhar conosco na mesma empresa? Sou assim: - Sim, claro, ficarei feliz em trabalhar nos “trilhos”! Foi assim que eu comecei.

Honestamente, eu não gostei do meu trabalho nesta empresa. Portanto, em qualquer oportunidade, no local de trabalho, escrevi código-fonte aberto. Isso foi feito da seguinte maneira: - Ok, o projeto levará 2 dias. Depois terminei o assunto em algumas horas e usei o resto do tempo para o código aberto.

O que chamamos: "Não bata na lombada!" Sento-me aqui calmamente, reparando o primus. Deixe-me em paz, pliz!

Sim! Então, aqui eu comecei a trabalhar muito com código aberto. Neste trabalho, comecei a escrever Nokogiri e geralmente trabalhando no meu código-fonte aberto Ruby. Então eu geralmente entrei em código aberto. Ele simplesmente "fez uma contribuição" até que um dia se juntou às equipes Ruby Core e Rails Core.

Então, como você foi parar na equipe principal do Rails?

Acabamos de encontrar bugs e desenvolvemos aplicativos Rails. Encontrei bugs, eu os corrigi e enviei patches. Acabei de enviar patches. No final, eles estão cansados ​​do fato de eu estar apenas dirigindo solicitações pull.

Agora, tome as coisas em suas próprias mãos, certo?

Sim, com certeza! Em suma, foi como um ataque de força bruta!

Parece razoável! Então, qual é a sua contribuição geral ao Rails?

Eu trabalhei muito em quase todas as partes da estrutura. Principalmente no Active Record. Eu gosto especialmente de fazer correções de bugs e melhorar o desempenho. O motivo desse anexo é que ele melhora os aplicativos de alguém. Todos ficam felizes se o aplicativo melhorar e você não precisa fazer nada para isso. É por isso que gosto de trabalhar nisso.

Você faz alguns refinamentos "pequenos" que fazem tudo funcionar. Mas você não precisava arquitetar coisas "grandes"?

Normalmente, sempre que faço algo arquitetônico no Rails, é algo dentro. Por exemplo, a arquitetura de trabalhar com URLs, associações, dispositivos dentro do roteador - algo assim. Nenhuma dessas coisas será necessariamente perceptível. Eles podem ser vistos pelo usuário, mas isso não está no formato: "Aqui está, a coisa real!" Eu tento manter esse estilo. Eu acho que isso é realmente bom, porque David ( DHH - P.A.) gosta de fazer Novos Recursos Finos Brilhantes. Em vez disso, digo para mim mesmo: “Bem, então, vamos fazer desses seus Recursos Finos. Você olha, e a verdade sairá linda! ”

Sim, alguém tem que fazer todo o trabalho manual. Por exemplo, sua apresentação na conferência será sobre certas partes profundas da engenharia do Ruby em geral e do Rails em particular. Qual é realmente a apresentação?

Na verdade, vou falar sobre Ruby internals. Não inventei todo o discurso até o fim.

GC, performance, tudo isso, vida, universo, 42?

Estou pensando em falar sobre o coletor de lixo, o processo de compilação do Ruby e o bytecode. Basicamente, sobre o bytecode em uma máquina virtual e como isso se relaciona com o coletor de lixo. Sobre algumas das melhorias de desempenho que fiz no GC. Não espero falar muito sobre Rails.

Nossa conferência costumava ser chamada de Rails Club. Nossos organizadores pensaram e renomearam toda a idéia, principalmente porque Matz disse que nunca participa de conferências com a palavra "Rails" no título. Então, agora somos "Rússia Ruby"!

Então, eu vou falar sobre Ruby internals!

Na sua opinião, o que os programadores do Rails devem fazer para obter melhor desempenho em seus códigos?

Existem várias estratégias. Primeiro, em termos gerais, não faça nada de especial. Basta escrever sua inscrição. Inicie, obtenha clientes, feedback, etc. Analise imediatamente os gargalos detectados. Nunca trabalhe com gargalos até que o trabalho real com os clientes os revele. Se você lida com gargalos que realmente não são, é uma perda de tempo. Esse tempo pode ser usado para novos recursos. No entanto, acho que muitos diriam a mesma coisa, então vamos falar sobre o que realmente afeta o desempenho. Primeiro, basta olhar para as consultas do banco de dados que a página faz. Esta é a primeira linha de defesa - tente reduzir o tempo gasto em solicitações específicas. Consultas em si - automatize e reduza. Você não acredita quantas vezes esquecemos de adicionar um índice. Ha! Portanto, faça pelo menos o índice no lugar certo.

Realizo entrevistas técnicas e imagino como as pessoas esquecem mesmo quais índices são em geral. Por que você precisa se preocupar com isso ... Bem, o que você diz sobre outras coisas que os rubistas devem saber? Que coisas técnicas um rubista deve saber para fazer seu trabalho melhor?

Existem algumas dessas peças. O primeiro, eu acho, é conhecer a própria linguagem Ruby. Aprenda o idioma com muito cuidado. O segundo é entender bem o UNIX.

Você é o primeiro "meu" orador a dizer que precisa conhecer o UNIX. Então, eu pessoalmente vim para Ruby do mundo UNIX. Eu trabalhei no Linux, FreeBSD e toneladas de código Perl. Eu vim para Ruby como outro Perl para fazer meus negócios com o administrador de sistemas e só então descobri que também era uma linguagem da web. E assim, você diz que precisa conhecer o UNIX. Como e porque?

É importante estudar os padrões POSIX e como eles interagem com o sistema operacional, porque você encontrará isso assim que começar a dimensionar. Você ...

... deve saber quem é o General Feiler e por que ele está lendo meu arquivo?

Haha sim! Você precisa saber o que altera o desempenho. Talvez você não precise memorizar isso especialmente de cor, mas saiba que eles (chamadas do sistema - P.A.) existem e como pesquisá-los no Google, porque você definitivamente encontrará essa economia. Eles serão importantes porque o aplicativo foi implantado em um servidor UNIX, portanto, você precisa entender como o aplicativo irá interagir com o sistema operacional no qual será executado. Outro ponto importante é que, se você adquiriu essa habilidade no UNIX, pode aplicá-la, por exemplo, em outros idiomas. Se você encontrar algum problema, sempre poderá começar a partir deste ponto. Esta é talvez a principal coisa que recomendo aos programadores que estudem.

Você acha útil o rubist conhecer alguma outra língua? É possível ser um bom programador em Ruby sem saber nada fora do Ruby?

Boa pergunta Honestamente, eu não sei. Todos os bons especialistas que conheço conhecem outras línguas. No entanto, não sei se é necessário aprender outras línguas para se tornar um bom programador de Ruby. Eu acho que acontece que as pessoas aprendem outras línguas.

Boa observação! Do ponto de vista médico, quanto mais idiomas uma pessoa conhece, mais isso atrasa o aparecimento da doença de Alzheimer.

Haha

Depois dos 40 você tem que pensar nessas coisas ...

Estou chegando aos 40 anos! É bom para mim saber!

Vamos falar sobre o próprio Ruby. Ruby é uma linguagem com um ótimo passado. Ele tem futuro? Há pouco tempo, eu estava em São Petersburgo em uma das maiores conferências de TI que já vi na Rússia. A comunidade ruby ​​local não estava representada nesta conferência. Eu sempre tive que fazer apologética para Ruby: Ruby NÃO ESTÁ TÃO TÃO morto, eles ainda escrevem Ruby. A propósito, Ruby tem o framework web mais conhecido - e tudo mais. Todos os grandes idiomas do mercado agora têm algum tipo de ferramenta de desenvolvimento web. Vá, Rust, tanto faz. Qual é o lugar do Ruby nesse ecossistema e o “Ruby com um ótimo passado” tem futuro?

Eu acho que há vários aspectos na resposta a essa pergunta. Existem muitas linguagens diferentes para as quais existem estruturas da Web, mas ainda acho que se você as examinar do ponto de vista da ergonomia do desenvolvedor, Ruby estará no topo de qualquer maneira. É fácil de usar e fácil de vender. O problema é que Ruby não é mais "novo e brilhante". As pessoas querem se deixar levar por algo novo. Eles querem pegar o próximo trem depois do Rails.

Eles querem o cheiro de um carro novo!

Sim Sobre o futuro ... Há muitos desenvolvimentos em Ruby, especialmente sobre o JIT e com o que Koichi: guilds trabalha. Eu diria que Ruby definitivamente tem um futuro, mas todos terão que trabalhar duro para isso. Se fizermos o esforço certo, o futuro certamente será.

Ruby tem alguma perspectiva em outras áreas além do desenvolvimento web? Ou você conhece algum exemplo em que Ruby agora é usado fora do desenvolvimento da web?

Boa pergunta! É difícil responder, porque eu lido apenas com questões de desenvolvimento da web.

Eu pergunto porque é do meu interesse pessoal. Caras da comunidade Python, por exemplo, gostam de se gabar de seus sucessos na computação científica.

Eu sei que há um grupo trabalhando em ferramentas científicas em Ruby. Mas acho que a alternativa real para Ruby é a administração do sistema.

Como podemos trazer desenvolvedores de outros idiomas para a nossa comunidade?

Esta é realmente uma boa pergunta! Acho que precisamos nos concentrar na ergonomia do desenvolvimento, no que torna o desenvolvimento de aplicativos da Web o mais fácil possível. Precisamos nos concentrar em reduzir o limite de entrada para novos desenvolvedores que embarcam e escrevem aplicativos da web. Então, atrairemos mais novos programadores.

É hora da pergunta de hollywood sobre JavaScript. Você sabe, existe um ditado: "tudo o que puder ser reescrito em JavaScript será necessariamente reescrito em JavaScript". Você acha que o Rails também será reescrito em JavaScript? Conversamos sobre a ergonomia do desenvolvimento de Ruby. Esta é a melhor coisa sobre o Rails. Um dos programadores russos mais famosos disse que "muitas línguas são boas, mas apenas Ruby tem Rails". No entanto, os desenvolvedores de JavaScript tendem a questionar isso. Como podemos competir com JavaScript? Ou devemos arranjar uma simbiose com ele?

É verdade que apenas Ruby tem Rails. Se você olhar as estruturas da Web para JavaScript, não acho que elas sejam comparáveis ​​ao Rails em termos de ergonomia do desenvolvimento. O fato é que, como estamos escrevendo aplicativos da Web, teremos que trabalhar com JavaScript. Devemos fazer parte da comunidade JavaScript. É útil termos uma simbiose. Se você pode executar qualquer idioma no servidor, por que deveria ser JavaScript? Mas a linguagem é boa e acho que precisamos trabalhar simbioticamente. A facilidade de desenvolvimento ainda está do nosso lado e é especialmente apreciada na comunidade Rails. Então, você veio à conferência de TI e teve que trabalhar como representante de Ruby lá?

Foi bem informal, porque eu nem tinha camisetas sobre minha empresa ou idioma. Então, acabei de encontrar o grupo mais brilhante de jovens que se tornaram pitãoistas e começamos a conversar.

Para nós, é bom trabalharmos juntos com outros idiomas e não competir com eles. Pessoalmente, acho que programar em Ruby é muito mais fácil e agradável do que em outras linguagens. Porque não Estamos falando de outras linguagens de programação e se devemos conhecê-las. Eu acredito que é importante que os rubistas aprendam outras línguas. Algo como Java, Haskell, ou algo mais funcional como Elixir ou Lisp, algo assim. Eu acho que é útil estudar paradigmas diferentes, porque quando você aprende coisas novas, você pode tirar isso e usá-lo em seu próprio idioma. Uma boa característica do Ruby é que podemos usar técnicas de vários idiomas em nossos programas.

Sim, temos, por exemplo, ferramentas para programação funcional ou execução de mapa / redução ou outra coisa.

Sim, podemos usar tudo isso. Se você usar um idioma que incentive essas técnicas, poderá encontrar uma maneira melhor de resolver o problema. Não tenho certeza de que é necessário estudar outros idiomas para ser um bom especialista, mas este estudo definitivamente me ajuda. Sinceramente, passo 50% do meu tempo programando em C.

C torna os dedos mais fortes!

Estou programando em C para que outros possam programar em Ruby.

Os internos do Ruby são escritos em C puro, e não em ++?

Em um limpo. Seria bom se mais desse código fosse escrito em Ruby, mas, para ser sincero, algumas das principais coisas por razões de desempenho devem ser escritas em C. Uma das coisas que estou fazendo ... Precisamos melhorar o perfil da memória. Portanto, estou trabalhando nas ferramentas de criação de perfil de memória no Ruby. Como todos os interiores estão escritos em C, tenho que escrever ferramentas em C. No trabalho, escrevo muito código.

Como está o Ruby com a FFI e coisas assim?

O FFI funciona bem o suficiente se você tiver uma biblioteca C em seu trabalho que precise de uma ou duas funções. Se algo é mais complicado ... Então tudo é mais complicado. Quando você trabalha com FFI, basicamente escreve um código C semelhante ao Ruby. No entanto, você ainda precisa fazer coisas misteriosas, como gerenciamento de memória. Pessoalmente, acho mais fácil alternar entre esses mundos se você usar C para gerenciar memória etc. E em outros casos, eu mudo para Ruby.

Em Ruby, temos interfaces para outros idiomas?

Algumas interfaces com JavaScript. Eu vi um cara que estava envolvido em tarefas científicas, então ele fez interface com o Python.

Ele interage diretamente com o tempo de execução do idioma?

Sim exatamente. Não é como um bombardeio ou algo assim ... O projeto ainda é muito experimental. Quando ele faz uma demonstração, ele diz que "tudo funciona, mas pode cair!"

Conheço um monte de especialistas famosos que criaram Rust. Por que você acha que as pessoas fizeram isso e como estão?

Eu gosto de Rust, acho que é uma linguagem muito boa. A razão pela qual as pessoas vão para o Rust ... elas querem um idioma com mais recursos de segurança do que o C fornece. Seria realmente incrível reescrever Ruby em Rust. Eu pessoalmente sou um grande fã de Rust, eu o amo.

Como isso pode ser útil? É mais seguro, mais rápido ou o quê?

Eu acho que é mais seguro. Não tenho certeza se é mais otimizado que C, mas é definitivamente mais seguro. É disso que eu gosto nele. Quando escrevo código C, tenho quase certeza de que não é SEGV, mas não tenho 100% de certeza. Mas quando escrevo em Rust, tenho certeza muito mais. Quando escrevo em C, tenho certeza de que não haverá vazamento de memória. Com o Rust, fica claro como um dia branco que não haverá vazamento de memória. É por isso que eu pessoalmente prefiro Rust ao invés de C. Também comecei a aprender Rust, porque quero escrever extensões para Ruby. Existe um projeto inteiro chamado "Helix" - especificamente para isso. Frequentemente, quando escrevo em C, é como: "OK, tenho uma biblioteca C e tenho que acessá-la do Ruby escrevendo algumas muletas". Usando Rust para isso é um canhão pardal. No meu mundo ideal, tudo, um dia, todo o sistema será reescrito em Rust. Ferrugem será o nosso novo C. Se você precisar resolver rapidamente um problema, escreva em Ruby. E o sistema operacional será feito no Rust. E todos serão felizes.

Rust está maduro o suficiente para isso?

Bem, eu não sei. Eu acho bastante. Na Mozilla, eles a usam - e estão satisfeitos.

Qual é a chance de "ver registros" executando um programa no Rust?

Haha, eu não sei! Esperança baixa! Ver isso não é nada ridículo.

Especialmente quando você inicia algo no navegador.

Sim Uma mensagem sobre uma falha é exibida e você fica assim: "OK". Ha! No trabalho, temos algumas coisas em C ++ e, às vezes, quando ocorre uma falha, eu gosto assim: "Hmm ..."

Quero programar em um idioma, não em um montador de macros! - foi minha piada favorita quando mudei de C para Ruby ...

Você está realmente certo. Sempre que escrevo em C, a questão é o que devo pensar. Eu realmente não penso no problema que está sendo resolvido. Com Ruby, não preciso pensar em tudo isso (economia de baixo nível - P.A.). Eu apenas me concentro na lógica do programa e estou fazendo negócios. Esta é uma das razões pelas quais eu amo tanto Ruby! Quando eu era javista durante o Java 1.3, isso foi antes dos genéricos aparecerem lá. Cada vez que tive que escrever algo como mapa - por exemplo, coleções ou iteradores, tive que fazer “iterator.next ()” e depois converter o valor resultante ... Somente então execute a operação necessária. Então eu comecei a aprender Ruby, onde o mapa já estava em Perl ...

... Oh, um milagre! Bem nas minhas mãos, tenho um objeto do tipo exato de que preciso!

Sim exatamente. Em Java, eu teria que escrever 15 linhas de código para conseguir o que posso fazer como uma única linha no Ruby. Eu escrevia em Ruby, terminava o trabalho muito mais rápido! Em vez de escrever todo esse lixo! Entender isso me chateou muito naquele trabalho. Passei horas em tráfego extra!

Horror existencial!

Exatamente! Foi um ponto de virada. Eu precisava encontrar trabalho em Ruby. Não consigo cortar java até o fim da minha vida!

Pode-se argumentar que Ruby melhora a mente do programador?

, , , . , . , , , . , , , . , .

, 90- . . C++. , « ». «» . Java, Perl. Ruby , .

. -, C++ Java, . , ints. , , . Ruby — . . , . , .

, . . , .

OO Perl. , , OO- . Java, , OO. -. Ruby — , .

, ?

! , : , Ruby — , . , , Ruby, . , , , Ruby . - , : , Ruby- !

. , Emacs Ruby, : « , !»

, , — , , . . , Ruby .

6 . Então, até a conferência! Todos os detalhes no site .

Você pode ler o original em inglês em hype.codes .

E muito obrigado às empresas que apoiam o principal evento Ruby na Rússia:

Parceiro Geral - Toptal
Parceiros Gold - Gett e Cookpad
Parceiros Silver - Instamart , UCHi.ru , JetBrains e Qlean
Parceiro de pós - festa - Teachbase
Parceiros Bronze - Bookmate e InSales