Entrevista com o palestrante da conferência RubyRussia, Godfrey Chan

Olá pessoal! Em 6 de outubro, Moscou sediará a conferência RubyRussia - o bom e velho RailsClub, mas com um novo nome. Os palestrantes deste ano: Aaron Patterson, Charles Nutter, Godfrey Chan, Maciej Mensfeld, Markus Schirp e muito mais. E, claro, 600 participantes, as melhores empresas com estandes no lobby e um incêndio após a festa.

Tradicionalmente, antes da conferência, falamos sobre os tópicos mais relevantes em Ruby e Rails. Hoje apresentamos a você Godfrey Chan - um ex-time principal do Rails, trabalhando em Tilde, onde ele está dividido entre criar um Skylight inteligente do Rails Profiler, trabalhando no Ember.js e desenvolvendo JavaScript no TC39. Tim Leader, da Evrone Dmitry Matveev, fez perguntas importantes aos nossos hóspedes.




Vamos começar com algumas perguntas sobre o seu relatório sobre o RubyRussia?

Eu não quero revelar todos os segredos! Meu relatório é chamado "Descer ao metal". Vou falar sobre como escrever um código Rubu bastante estranho usando metaprogramação para criar algo semelhante ao JavaScript. Obviamente, não conseguiremos escrever um analisador e tempo de execução completo do JavaScript, mas mostrarei algumas mágicas que farão com que um código semelhante ao JavaScript seja executado no Ruby usando o tempo de execução nativo do Ruby. É divertido, pelo menos eu realmente gosto disso. Essa é a mesma técnica com a qual você pode escrever coisas como rspec, rake ou outras DSLs no Ruby. Vou mostrar aos alunos como o Ruby analisa e executa seu código e quais ganchos você pode usar. Eu acho que o relatório não será apenas divertido, mas também ensinará algumas coisas úteis sobre metaprogramação em Ruby.

Legal! Ou seja, haverá dicas práticas, certo?

Não tenho certeza de que será possível focar neles, mas acredito que a partir desses 30 minutos você aprenderá algo útil para si mesmo.

Ótimo! Eu acho que o relatório será interessante para programadores experientes e iniciantes. Certo?

Espero que sim. Pelo menos vou tentar.

A propósito, ontem li seu artigo no Medium sobre o repensar da educação em ciência da computação. O artigo é muito interessante e eu concordo com os pensamentos sobre as diferenças entre o ensino universitário clássico e os cursos modernos para programadores. A propósito, por que você decidiu se tornar um programador?

Só por acaso, nunca planejei trabalhar como programador, para mim foi um hobby. Eu realmente gostava de mexer nos computadores, era fácil criar algo para fazer - excluir acidentalmente arquivos do sistema ou cavar mais fundo no registro do Windows. Então eu queria algo mais. Depois da escola, comecei a fazer cursos sobre desenvolvimento de sites. Fiquei encantado com a oportunidade de criar algo novo no computador. Mas logo percebi que isso não era suficiente para mim. Eu poderia criar algum tipo de jogo de computador em HTML, mas esse kit de ferramentas era bastante limitado. Um dia, meu professor me deu um livro sobre PHP. Eu li tudo e, inesperadamente, descobri um novo mundo de possibilidades, que oferece muito mais que HTML e CSS. Foi muito legal, depois disso comecei a ler mais e mais livros sobre esse assunto. O próximo idioma que aprendi foi Java. Uma vez eu li sobre Ruby na Linux Magazine (na verdade não sobre Ruby, mas sobre Rails, é claro), e achei que seria ótimo aprendê-lo. A partir daí tudo começou e, como uma bola de neve, rola até hoje.

E então você mudou para Ruby, certo?

Descobri Ruby na época em que comecei a estudar Ciência da Computação na faculdade, e ao mesmo tempo também estudava Java, C ++, Haskell e não apenas aprendi muitas linguagens de programação ao mesmo tempo. Como parte de nossos estudos, não tínhamos atribuições de Ruby, e eu realmente gostei dele, então sempre tentei usá-lo nas aulas em que você mesmo podia escolher a tecnologia. Bem, em seus projetos de terceiros também. Quando me formei, decidi procurar um emprego relacionado ao Ruby. Era simples, porque o Rails estava no auge da popularidade: muitas startups usavam essa tecnologia. Então o interesse se tornou meu trabalho.

Agora você usa Ruby como sua ferramenta principal? Ou você está trabalhando com outra coisa?

No meu trabalho atual em Tilde, não escrevo tanto Ruby como antes. Eu diria que meu trabalho é um coquetel de JavaScript / TypeScript, Rust, Ruby e às vezes Java. Mas, enfim, todo o trabalho que faço está relacionado ao Ruby.

O principal produto da Tilde é a Skylight. Nem todos os componentes estão escritos em Ruby: o frontend está em JavaScript e Ember, o backend está no Rails, mas todo o processamento de dados recebidos é Java e Rust. Mas o próprio Skylight é uma ferramenta de monitoramento de desempenho para aplicativos Rails. Nesse sentido, todo o trabalho que faço ainda está relacionado ao Ruby.

Ótimo! Eu mesmo me registrei na Skylight há alguns dias para um dos projetos, agora estou testando. Parece interessante e, desde o início, está claro como tudo funciona. Ainda não me aprofundou muito, mas pretendo começar a usá-lo com muita força na próxima semana. Espero que eu possa resolver alguns problemas com isso.

Ótimo, seria ótimo ouvir feedback!

É interessante comparar o Ruby com outros idiomas. Por exemplo, com Rust. Ruby é muito expressivo e projetado para tornar o código legível. Se você compará-lo com Python ou C ++, C #, Java, eles, na minha opinião, não são tão fáceis de ler como Ruby. O que você acha disso?

Eu concordo Existem duas maneiras de "aprender" um novo idioma. O primeiro é bastante superficial: estudo os conceitos básicos de sintaxe, brinco com exemplos e depois esqueço imediatamente. Foi assim com o Go. Fiz isso no fim de semana e, por algumas semanas, escrevi pequenos projetos. Mas não tive motivos para continuar programando no Go. Eu apenas a estudei por curiosidade, e rapidamente me esqueci.

Por outro lado, há JavaScript / TypeScript, Rust e Ruby, que eu uso o tempo todo. Cada um desses idiomas abriu novas oportunidades para mim, é muito motivador.

Por exemplo, quando comecei a trabalhar com Ruby, fui atraído pela expressividade. Nenhum outro idioma permitiu que você fizesse coisas loucas como method_missing. Metaprogramação, expressividade e legibilidade de código são as principais coisas que eu amo em Ruby. Seria legal se outros idiomas pudessem.

Mas neles você pode fazer coisas que são impossíveis em Ruby. Por exemplo, JavaScript. Tudo era completamente diferente com ele do que com Ruby, pelo qual me apaixonei à primeira vista. Comecei a usar o JavaScript conforme necessário, precisava escrever o código do navegador. Quer gostemos ou não, não há como fugir do JS. Se você deseja escrever um aplicativo de navegador interativo, como o Skylight (exatamente o que eu estava interessado naquele momento), o JavaScript é a única saída.

Eu queria transferir as idéias que eu gostava em Ruby para JavaScript, então no final comecei a trabalhar com Ember. Isso, por sua vez, me levou ao TypeScript. Quando você escreve uma estrutura enorme, como Ember, em JavaScript, ter tipos e um compilador para verificar erros realmente ajuda. JavaScript e TypeScript me ajudaram a entender isso.

As idéias que Rust me ensinou são muito semelhantes ao TypeScript. É bom poder compilar o programa inteiro e ter certeza de que funciona. Para mim, é simplesmente incrível. Já trabalhei com linguagens compiladas antes: com Java e C. Você também deve esperar nelas até que o código seja compilado, mas isso não é de muita utilidade, porque o sistema de tipos nessas linguagens não captura erros muito bem. Porém, no Rust, o compilador pode garantir que o programa não causará problemas de memória e que durante sua execução não haverá erros de segmentação (segfault). Uma das coisas mais difíceis de fazer na programação C são os problemas de memória, que são muito difíceis de evitar. A principal característica do Rust para mim é a capacidade de fazer programação de baixo nível sem se preocupar com isso.

A propósito, meu interesse em Rust estava relacionado a Ruby. Comecei a trabalhar na Tilde e sabia que a joia Skylight estava escrita em Rust. Eu pensei que seria ótimo aprender a escrever extensões nativas para Ruby da mesma maneira. Eu queria aprender a escrever no Rust para não me preocupar com a quebra de processos personalizados, como acontece quando os ponteiros são desreferenciados incorretamente no C. Portanto, o principal objetivo de aprender o Rust para mim era, de fato, escrever extensões nativas para o Ruby.

Ainda nesta manhã, eu estava trabalhando em um projeto com Peter Wagenet, da Tilde, e Sean Griffin, da Shopify e da equipe principal do Rails. Sean está trabalhando em uma nova versão do Active Record escrita em Rust para acelerar as partes lentas. E logo antes desta entrevista, eu estava trabalhando em um projeto no Rust chamado libcruby-sys, que permite escrever extensões nativas para Ruby in Rust.

No final, podemos dizer que todos os idiomas estão conectados. Os idiomas em que aprendo e programo são apenas ferramentas que me permitem criar o que tenho em mente.

Muito interessante! Legal que o ActiveRecord será muito mais rápido. Tanto quanto eu entendo, a idéia do ActiveRecord não mudará. Quero dizer, será o mesmo ActiveRecord, e não algo como um Mapeador de Dados?

O Active Record on Ruby, é claro, não vai a lugar algum, está em desenvolvimento ativo, é usado. No caso do JRuby, esta é a primeira escolha. A implementação de Sean é 100% compatível com a API nativa. Os internos são reescritos no Rust, para que tudo funcione mais rápido, mas a API não será alterada para o usuário final.

A mesma coisa com o projeto em que tenho trabalhado nos últimos dois anos. Ele é chamado Helix e está associado aos meus experimentos com o Rust para criar extensões nativas para Ruby. Foi muito difícil iniciar devido a vários problemas de segurança de memória que precisavam ser resolvidos. Helix permite que você simplesmente se concentre em escrever código no Rust, ele cuida de compilá-lo na extensão Ruby.

Eu acho que muitos usaram JSON gem em Ruby. De fato, existem duas implementações diferentes dessa gema. Existe uma implementação Ruby pura e uma extensão C que implementa a mesma API. Isso não é perceptível, mas se você escrever `require json`, provavelmente a versão C. será carregada.Se a plataforma atual não for suportada, será uma versão ruby. Mas, novamente, a API é usada exatamente da mesma maneira nos dois casos. A única diferença é que os componentes internos de um deles são implementados em C, portanto, ele funciona mais rápido. Além do desempenho superior, não há diferenças. Esse é o objetivo de todos esses projetos - poder usar o Ruby que amamos, mas obter os benefícios de desempenho do código nativo quando necessário.

É ótimo que Ruby seja mais rápido. Embora exista uma opinião de que a velocidade de execução não é muito importante para os programas Ruby, tenho certeza que todos ficarão felizes se o desempenho aumentar.

Na maior parte, eu concordo. Em geral, é assim. Porém, tendo aumentado seriamente a produtividade, podemos fazer coisas que antes eram simplesmente impossíveis nessa plataforma. Como eu disse, aprendi JavaScript porque queria escrever programas para o navegador, e é impossível fazer o contrário. Eu acho que o mesmo vale para o desempenho. Não me importo se o código for 20% mais rápido. Isso é bom, mas não é tão importante. Mas quando o código é executado 10 vezes mais rápido, isso abre possibilidades completamente novas.

Por exemplo, se você está envolvido em aprendizado de máquina, precisa fazer muitos cálculos complexos. Provavelmente, você não poderá implementar isso no Ruby, porque o Ruby é muito lento. Mas se houver uma interface para interagir facilmente com as bibliotecas de aprendizado de máquina nativas, você poderá trabalhar com o ML, mesmo no Ruby. Você pode escrever código para orquestrar todos os processos com cálculos em Ruby, com toda a sua expressividade e ecossistema de gemas. Para mim, o desempenho é uma ferramenta para trazer novos recursos.

Isso é absolutamente verdade! Eu lutei muitas vezes com programas Ruby de baixo desempenho. Eu tive que escrever muito código SQL para acelerar as coisas, transferir parte da lógica para o lado do banco de dados, porque funciona centenas de vezes mais rápido.

Isso mesmo, mas prefiro mover o código problemático para as extensões nativas do que reescrevê-lo como um microsserviço no Go ou Haskell. Eu acho que é bom poder escrever o máximo de código Ruby possível e mover partes críticas de desempenho em algum lugar com o qual você possa interagir facilmente no Ruby. A oportunidade em si é maravilhosa.

Sim, deve ser mais rápido e fácil, mais eficiente em termos de tarefas de negócios. Não é necessário contratar programadores com habilidades e pilhas diferentes, pois tudo pode ser escrito em Ruby. Isso parece promissor. O que você acha do futuro do Rails? Todo ano, há rumores de que o Rails está morrendo ...

Sou tendencioso porque trabalho para uma empresa cujo principal produto é uma ferramenta de monitoramento de desempenho no Rails. Pessoalmente, não acho que eles estejam morrendo, mas o Rails definitivamente se tornou mais maduro, "amadurecido". Para muitas pessoas da comunidade, isso é algo fundamentalmente novo. Muitos de nós se juntaram à comunidade Rails and Ruby quando o Rails era um tema de hype. Havia muito entusiasmo, muitas inovações. Embora muitas de nossas “inovações” fossem comuns em outros ecossistemas mais adultos. Muito era impossível, porque o ecossistema ainda era imaturo.

Foi um momento muito emocionante. Toda segunda-feira, eu estava ansioso para um novo episódio de RailsCasts. Nova jóia a cada semana. Por exemplo, nesta semana, criamos arquivos PDF, na próxima semana fazemos upload de um arquivo e, em seguida, algo fundamentalmente novo aparece, como empacotador, por exemplo. Foi um momento de novas idéias, emocionante, todo mundo tinha muita energia. Muitas pessoas pensam que Rails ou Ruby estão morrendo porque essas emoções se foram.

E na minha opinião, o ecossistema acabou de amadurecer e se tornar mais estável. Já experimentamos cinco maneiras completamente diferentes de fazer upload de arquivos, e não precisamos fazer isso toda semana. Em termos de emoções, eu definitivamente sinto falta desses tempos. Mas não acho que seja pior agora. Podemos dizer o seguinte: “ok, passamos por todas essas aventuras, tentamos abordagens diferentes, aprendemos lições. E agora escolhemos a melhor opção que todos usarão. ” Eu acho ótimo.

Parte de mim definitivamente sente falta desse impulso, do constante sentimento de mudança e progresso que estava na comunidade Ruby na época. Agora eu vejo isso na comunidade Rust. Lá eu posso experimentar as mesmas emoções. Sim, em Ruby, as paixões diminuíram. Mas, do ponto de vista da produtividade e do trabalho real - nem tudo é ruim. Entendo que uma pessoa que gosta de aprender constantemente coisas novas precisa de tais emoções. Eu os procuro e os encontro em outros ecossistemas. A comunidade está amadurecendo e há menos mudanças. Mas, pessoalmente, combina comigo.

Eu acho que essa é a ordem natural das coisas, e o Rails ainda é bonito. Tudo o que acontece - beneficia os negócios reais que desenvolvem aplicativos comerciais. Eu gosto que o Rails permita abordagens diferentes. Por exemplo, você pode usar pedras preciosas trailblazer ou dry-rb enquanto permanece no contexto do Rails. Você pode usar vários tipos de abstrações no seu código, mas, no final das contas, ainda será um aplicativo Rails. É disso que eu gosto.

Eu definitivamente concordo com você. Eu acho que todo o ecossistema está crescendo. Naquela época, que agora chamamos de "pico" do Rails, muitas novas startups apareceram. Ninguém se importava com estabilidade e estabilidade. Então você recebe um fluxo constante de novas emoções e energia. Agora, muitas dessas empresas cresceram em grandes corporações, como o Github ou o Shopify, e começaram a se preocupar com a estabilidade. Isso é verdade para muitos.

Como comunidade, decidimos coletivamente preferir a estabilidade do que os experimentos. Do ponto de vista da linguagem, ainda há muito espaço para experimentação, porque Ruby permanece o mesmo. A razão pela qual Ruby foi ótima para a experimentação não foi a lugar nenhum. No entanto, a comunidade decidiu se concentrar na criação de coisas que funcionem no Rails, porque o Rails tem sido usado ativamente. Ao escrever uma gema, é provável que você suporte várias versões do Rails, porque existem muitas empresas que as utilizam. Como resultado, os próprios Rails também se tornam mais cuidadosos, não quebram sua API desnecessariamente. Pessoalmente, estou feliz por fazer parte desse processo.

Do ponto de vista comercial, a estabilidade é muito importante. Especialmente para sistemas muito carregados. A estabilidade das interfaces da estrutura facilita o trabalho. Lembro-me dos momentos em que era muito difícil mudar de uma versão do Rails para outra. Por exemplo, no momento em que o aplicativo começou a gerar vários erros devido à codificação incompatível.

O Trailblazer é um ótimo exemplo que mostra o estado atual da comunidade e do ecossistema. Por um lado, o fato de existir existe uma prova muito boa de que ainda há muito espaço para experimentação na comunidade Ruby. Mas acho que se fosse lançado há 5 anos, seria muito mais popular, porque agora construímos um ecossistema muito maior em torno do Rails, com muitas gemas.

No final, você se preocupa mais com o que pode fazer com a pilha familiar. Quando você só precisa escrever um aplicativo que pode faturar, criar arquivos PDF e usar soquetes da Web, muitas pessoas preferem usar o que os outros já usam - nesse caso, você pode compartilhar gemas, discussões, encontrar respostas para o StackOverflow, etc.

Nesse sentido, podemos dizer que parte da comunidade Ruby morreu. Há 5 a 10 anos, você constantemente fazia coisas novas, não se preocupava muito com a compatibilidade, usava as joias mais novas e legais, porque não havia "bagagem" nas suas costas. Agora, a maioria dos projetos na comunidade de "bagagem" acumulou-se decentemente. E aqueles que amam experimentação e inovação mudaram-se para outras comunidades e ecossistemas.

Eu acho que isso é normal.

Também não me importo. É como crescer, outro estágio da vida.

O que você acha da digitação estática? Existe alguma perspectiva de obter os benefícios dessa abordagem no Ruby?

Estou ansioso por isso, porque já experimentei os benefícios dessa coisa no ecossistema JavaScript com o TypeScript. JavaScript é muito semelhante ao Ruby.É uma linguagem dinâmica com digitação gratuita, portanto, possui muita flexibilidade, mas ainda mais erros no tempo de execução. O TypeScript é uma tentativa de criar no JavaScript um sistema de tipos, um superconjunto da sintaxe do JavaScript. Quando você compila o código, o compilador verifica os tipos, verifica se tudo está correto e simplesmente os apaga. Ao excluir todos os tipos dos arquivos TypeScript, você volta ao JavaScript puro.

Vejo que essa abordagem funciona surpreendentemente bem. As pessoas já criaram um ecossistema inteiro em torno do TypeScript. Eu adoraria ver a mesma história em Ruby. A genialidade da idéia é que o TypeScript é um superconjunto da sintaxe do JavaScript, é uma nova camada, não proíbe o uso de nada do ecossistema do JavaScript. Um programador de formação antigo pode simplesmente interagir com uma versão não tipada do código. Outros desenvolvedores podem obter todos os benefícios da digitação apenas olhando a versão digitada. Mas, em última análise, todos poderão ligar para as bibliotecas da maneira usual. Mesmo se você usar apenas JavaScript padrão, poderá se beneficiar de tipos, por exemplo, usando o preenchimento automático, porque alguém já fez o trabalho de adicionar tipos às bibliotecas JavaScript usadas. Na minha opiniãoO TypeScript é uma grande vitória para todos na comunidade JavaScript, independentemente de você usá-lo diretamente ou não.

, Ruby, . , , , , , , , , Rails, , , , . , Ruby .

. , . : . , , . , , , , . , .

As pessoas que gostam de tipos realmente as usam para documentar o código. Se feito corretamente, o TypeScript faz um ótimo trabalho nisso. Lê quase como código de auto-documentação. Mesmo se você não quiser ver o código digitado, poderá ver a versão JavaScript. Mas porque alguém fez o trabalho de adicionar tipos, você pode gerar documentação para código não digitado.

Eu acredito que o ponto chave aqui é a separação de camadas de abstração. Algumas pessoas estão muito entusiasmadas com os tipos, enquanto outras não gostam muito deles. A história do TypeScript mostra que existe uma maneira de coexistir e compartilhar essas abordagens. Estou um pouco preocupado com a direção em que os tipos estão se movendo no Ruby. Eu, pessoalmente, preferiria encontrar uma maneira pela qual possamos sobrepor tipos sobre Ruby e permitir que as duas opiniões coexistam umas com as outras, em vez de fazer um monte de compromissos.

Alguns anos atrás, Matz veio até nós no RailsClub. Claro, conversamos com ele sobre digitação. Tive a sensação de que ele não era muito otimista. Embora tudo possa mudar.

, , , , , , , , - .

, , , , .

É realmente mais fácil para a maioria e, em muitos casos, para mim pessoalmente. Mas em alguns tipos de programas, por exemplo, no Rails, você cruza a linha. Sem tipos, você precisa armazenar várias informações na sua cabeça ou na documentação. Em algum momento, fica muito pesado, especialmente para um projeto grande como o Rails. Penso que, mesmo para JavaScript, existem aplicações em que as vantagens dos tipos não valem todas as suas complexidades. Mas existem projetos enormes como o Ember que se beneficiaram muito com o uso do TypeScript. Como eu disse, a beleza das camadas é que você acaba com o código JavaScript de qualquer maneira. Você pode escolher uma maneira ou de outra sem afetar a outra metade da comunidade, que não compartilha suas idéias. Pelo menos minha experiência é exatamente isso.

Que conselho você pode dar para iniciantes? Qual será a direção principal da programação nos próximos 5 anos?

Esse é um tópico enorme, que pode ser discutido por muito tempo, mas tenho duas dicas.

Primeiro, em vez de perseguir o mainstream, siga o que lhe interessa. Talvez eu tenha tido sorte, mas ajudou muito. Quando mergulhei em Ruby, comecei a procurar um trabalho que me permitisse escrever nele. Como eu estava muito motivado para aprender mais sobre Ruby, comecei a fazer commits em código aberto, e isso ajudou minha carreira mais tarde. Essa é a primeira dica. Siga o que você está interessado. Se você estiver motivado, a probabilidade de fazer bem seu trabalho é muito maior.

A segunda dica que descrevi em detalhes naquele artigo no Medium. Você precisa abordar completamente o processo de aprendizado, porque não importa o que você faça, o aprendizado é uma parte essencial do trabalho. Eu recomendo encontrar boas maneiras de aprender mais do que você já sabe, mudar para áreas que você não está familiarizado e descobrir como criar e alterar padrões de pensamento para diferentes conceitos. O aprendizado é uma das principais habilidades que você deve possuir para se desenvolver na programação.

Eu acho que o ensino superior é importante hoje. Dá às pessoas um profundo entendimento e fundamento que não mudou muito. Os princípios básicos de um computador ou banco de dados são praticamente inalterados. Em níveis mais altos, muitas coisas novas surgem, mas o básico é o mesmo há décadas. Eu acho que o ensino superior é valioso. E você?

Eu concordo, as universidades ainda são importantes. Pessoalmente, recebi muito do ensino superior. No entanto, não gosto do termo "básico". Sempre há algo além do "básico" que você pode aprender. O principal é entender que sempre há algo mais profundo do que você sabe, e está aguardando sua descoberta. E se você começar a cavar, isso provavelmente o ajudará de uma maneira incrível.

, , . . , Ruby. , , Rust Ruby. . , . , . , , , , , . — .

, ?

, . , — , . , .

, . , Rust . Java Rust. , Rust. , . Rust — , .

, — . -, .

Dou aulas de Rust toda semana e toda vez que entendo o quanto não sei sobre ele. Quando tento explicar coisas que, como eu pensava, eu sei, sempre há algo que eu não fazia ideia. Passo muito tempo depois de cada lição para estudar o material que pensei que já sabia. Ótima fonte de experiência.

A propósito, gostaria de agradecer por enviar esta semana no Rails .

ObrigadaEu mesmo não tenho mais tempo para escrever essas cartas, então agora não tenho que agradecer. Os caras que os escrevem agora sabem tudo. E agora, como leitor de boletim informativo, também aprecio muito o trabalho deles.

Recebi essas cartas pelo menos nos últimos 2 anos. É interessante ler às segundas-feiras o que aconteceu semana passada na comunidade Rails!

Foi muito divertido! Estou feliz por ter iniciado este projeto.

Obrigada Vamos falar sobre a conferência por último. Falta apenas um mês para a RubyRussia . O que você espera de uma viagem à Rússia?

Não estive na Rússia e, francamente, não tenho ideia do que esperar. Mas acho que vai ser muito divertido. Estou muito feliz por ter vindo e tenho certeza de que tudo ficará bem. O que devo esperar? Existe algo para o qual eu deveria estar preparado?

Haha, entre outras coisas, teremos uma excelente festa depois do ano passado, todos se lembrarão. Muitas coisas: uma conferência, passeios e muito mais. Vai ser divertido! As pessoas aqui são amigáveis ​​e tenho certeza de que teremos muitos tópicos interessantes para discussão.

Estou ansioso e muito grato pelo convite! De alguma forma, nunca pensei em visitar a Rússia. Mas agora eu percebi que deveria ter feito isso antes. Eu acho que vou me divertir muito!

Espero falar pessoalmente na conferência.

Estou ansioso por isso!

Foi muito interessante conversar! Obrigado pelo seu tempo! Tenham um bom dia! Vejo você em Moscou!

Também estamos esperando por você na conferência! Será possível fazer suas perguntas pessoalmente (e no lendário pós-festa :) em 6 de outubro. O programa chegou e faltam cerca de uma semana para o aumento dos preços. Agora, o bilhete custa 8.000 rublos.

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

, Ruby- :

— Toptal
— Gett
— Instamart , UCHi.ru , JetBrains
— Bookmate InSales