Muitos desenvolvedores de Java conhecem
Stephen Chin . Alguém viu suas transmissões de eventos Java, algumas - entrevistas com outros javistas famosos e outras - reportagens sobre Java no Raspberry Pi. Mas o que há no Twitter ele
@steveonjava - ou seja, mesmo com um nome de usuário, mostra quanto sua vida é dedicada a esse idioma.
Até recentemente, ele trabalhou na Oracle e agora mudou para o JFrog. Pode parecer inesperado: deixe o Oracle quando sua vida é Java? Mas o segundo nome também é bem conhecido dos javistas russos, em muitos aspectos, graças a
Baruh joguch Sadogursky trabalhando lá.
Em breve, os desenvolvedores russos poderão ver pessoalmente Stephen e Baruch na conferência do
Coringa , mas até agora, Stephen nos falou sobre várias coisas, por exemplo, como:
- O que exatamente ele está fazendo agora;
- Como é mais correto que um desenvolvedor se torne um gerente;
- Quão grande você pode criar um cluster de Raspberry Pi (e por que);
- O JavaFX está vivo?
- Como uma motocicleta é útil para um ativista de Java?
Oleg Chirukhin: O JFrog está envolvido em CI / CD e outros, mas é especialmente conhecido pelos javis russos que Baruch trabalha lá. Você provavelmente o conhece, certo?
Stephen: Sim, ele e eu somos grandes amigos. Eu o conhecia antes do chapéu!
Oleg: Agora você é "diretor sênior de relações com desenvolvedores", e a posição de Baruch é chamada "chefe de defesa de desenvolvedores". O que exatamente está por trás disso?
Steven: O DevRel é um monte de atividades diferentes. Incluindo esses advogados, desenvolvedores - pessoas como eu e Baruch falando em conferências com apresentações. Também são eventos para desenvolvedores, comunicação com pessoas em conferências, criação de conteúdo para desenvolvedores e assim por diante. Em geral, agora também estou conectado a tudo isso e vamos aumentar a atividade de trabalho com a comunidade.
Oleg: A julgar pelo seu perfil do LinkedIn, você tem uma carreira muito interessante. Primeiro, você obteve um diploma de bacharel em ciência da computação; depois, por três anos, esteve em administração; depois, por um ano - em programação, e novamente em administração. Por que você teve esses ziguezagues em sua carreira? Em geral, quão razoável é para um júnior mudar seu campo de atividade com tanta frequência?
Stephen: É bastante razoável, é assim que todos devem começar uma carreira! * risos *
Eu diria que uma das dificuldades comuns para as pessoas que conhecem bem seu campo técnico é que o crescimento na carreira é mais fácil de se tornar um gerente. Mas se você se engajar na gerência por um longo tempo, suas habilidades, compreensão da tecnologia e, em geral, o que o torna valioso como líder deixam de se desenvolver. Portanto, estou convencido de que não devemos abandonar a tecnologia. Continue criando algo, continue estudando, continue desenvolvendo. Para uma carreira, isso é apenas o mais importante.
Se necessário, assuma uma posição de liderança e ajude os colegas a crescer - isso é ótimo, fico feliz por isso. Mas depois arregaço as mangas e faço algo específico. Eu acho importante não esquecer que essa é sua principal habilidade como desenvolvedor.
Oleg: É fácil combinar as habilidades de um gerente e um programador em uma pessoa?
Afinal, essas são áreas muito diferentes.
Stephen: Sim, mas eu só lido com gerenciamento em áreas que eu mesmo entendo. Eu sei escrever código, testar, aplicar metodologias ágeis, porque eu mesmo aprendi tudo isso. Além disso, estou envolvido na defesa de desenvolvedores há vários anos, então também tenho habilidades nessa área.
Eu acho que a maioria dos gerentes tem a parte mais produtiva de sua carreira quando, como especialistas em um determinado campo, organizam sua equipe e contribuem para sua eficácia. E então eles são promovidos a gerentes médios típicos, e isso não traz muitos benefícios. Portanto, acredito que, para o sucesso, é necessário não se afastar daquilo em que você é originalmente bom.
Oleg: Você já ocupou o cargo de Chef Agile Methodologist. Tenho até medo de sugerir o que isso deve significar.
Stephen: Bem, todos nós cometemos erros em nossas vidas! * risos *
A certa altura, as metodologias ágeis e a infraestrutura do DevOps começaram a funcionar muito bem para mim. Comecei a ajudar não apenas minha equipe, mas também outras equipes da empresa, e também comecei a ajudar a planejar grandes lançamentos. Até escrevi uma ferramenta em Java para similar. A empresa começou a usá-lo, com o passar do tempo, e, como resultado, graças a isso, conseguimos sair do inferno das tabelas do Excel (se você se encontra nela, sabe como é um lugar terrível).
Mas, ainda assim, trabalhar com metodologias não é tão interessante para mim quanto as tecnologias. Portanto, no final, voltei a assuntos anteriores.
Oleg: Eu sei que você trabalhou muito com JavaFX. O que inicialmente o levou a essa tecnologia?
Steven: Esta é uma história bastante interessante. Mesmo antes de o JavaFX 1.0 ser lançado, eu estava trabalhando em uma estrutura de widget de desktop. Enviei um protótipo dessa estrutura para Joshua Marinacci, da Sun, que na época trabalhava como evangelista em Java. Pessoalmente, eu não o conhecia, embora o respeitasse, por isso não esperava nenhuma resposta. Mas ele respondeu, disse que gostou da ideia e sugeriu experimentar o JavaFX, que na época estava completamente fora de vista. Tive três dias de folga (devido ao feriado) e durante esses três dias reescrevi minha estrutura em JavaFX, após o que Joshua enviou o resultado novamente.
Em geral, foi assim que meu conhecimento do JavaFX começou e meu WidgetFX apareceu. Acho que você sabe que nem tudo correu bem na história dessa ferramenta, mas agora acho absurdo usar o AWT ou o Swing para escrever ferramentas de desktop em Java.
Oleg: Eu concordo completamente. É verdade que o IntelliJ IDEA ainda usa o Swing.
Stephen: Bem, o próprio IDEA foi criado no início dos anos 2000. Obviamente, há pessoas envolvidas no suporte a aplicativos grandes com um grande número de Java2D herdados e, nesse caso, é claro, você não precisa escolher. Mas para novas ferramentas, na minha opinião, é uma loucura usar o kit de ferramentas, que tem mais de 20 anos.
Oleg: O que o JavaFX espera no futuro? Afinal, agora ela deixou de fazer parte do JDK.
Stephen: Bem, o JavaFX continua sendo parte do projeto OpenJDK. Ele foi removido do assembly Oracle, mas esse assembly ainda é comercial agora, portanto a perda é pequena. O que posso dizer - use as compilações JavaFX da Gluon. A propósito, eles também estão envolvidos no JavaFX móvel, em geral, fazem muitas coisas importantes para o ecossistema.
Oleg: E os projetos JavaFX como o seu WidgetFX agora?
Stephen: Especificamente, o trabalho no WidgetFX não está mais em andamento, mas há outros projetos que a comunidade apóia. Em geral, o ecossistema JavaFX é vibrante. Existem muitos casos em que o JavaFX é indispensável e permite que você escreva coisas difíceis de reproduzir em JavaScript.
Oleg: Você tem um projeto Nighthacking - pode nos contar sobre isso?
Stephen: Mesmo antes de começar a trabalhar na Oracle, iniciei uma grande série de entrevistas sob o nome geral Nighthacking. Peguei uma mochila com o equipamento, vim à conferência e gravei em vídeo entrevistas semelhantes às que você está tirando de mim agora.
Usei vários serviços para publicá-los na Internet, mas no final decidi usar o Periscope, o que Chris Thalinger me sugeriu. Esta é uma ótima plataforma para publicar entrevistas e ajudar as pessoas a aprender sobre novas tecnologias.
Além disso, Baruch e eu tivemos a ideia de criar um programa em um formato semelhante sobre o assunto do DevOps. Planejamos lançá-lo em sua conferência do Joker, que será chamada de DevOps Speakeasy.
Oleg: Isso seria ótimo. Até onde eu sei, você viajou de moto com outro desenvolvedor Java que conhecemos, Sebastian Dashner?
Stephen: Sim, viajamos por todo o mundo, estávamos na Europa, no Japão. À primeira vista, pode parecer que uma motocicleta é um meio de transporte estranho, mas quando você precisa visitar dez grupos de usuários diferentes em cidades diferentes em duas semanas, como fizemos no Japão, a motocicleta é muito eficaz.
Oleg: Como você viu muitos grupos de usuários Java em todo o mundo - existem diferenças culturais entre grupos em diferentes partes do mundo?
Steven: Eu acho que há mais semelhanças do que diferenças. Na maioria das vezes, esses grupos existem à custa dos próprios nerds, que os organizam, ou seja, funcionam de forma voluntária. Eu, ao liderar um grupo de usuários na área da Baía de São Francisco, senti isso como uma maneira de ajudar os outros, assim como eles me ajudaram no meu tempo. Grupos de usuários permitem que você compartilhe conhecimento, eu realmente gosto de andar neles, o espírito da comunidade pulsa neles. Para os defensores dos desenvolvedores, é melhor criar grupos de usuários.
Oleg: Você tem muitos vídeos sobre robótica, Raspberry Pi e muito mais. Você faz isso profissionalmente ou é mais um hobby?
Steven: Comecei a trabalhar em robótica, porque na Oracle tínhamos projetos Java para o Raspberry Pi e outras plataformas embarcadas. E então vi que é muito conveniente para o Raspberry Pi ensinar programação para crianças. E eu fiz muito disso, realizei seminários para crianças em várias conferências. Anteriormente, minha filha me ajudou nesses seminários, agora ela mesma realiza os mesmos seminários. Ele conecta sensores embutidos (como sensores de luz, acelerômetros) ao Raspberry Pi, mostra exemplos de códigos muito simples com esses sensores e, assim, ensina as crianças. Graças a essas lições, uma nova geração de programadores poderá aparecer no futuro, cujo interesse pelo código surgiu muito cedo.
Oleg: Talvez um dia ela jogue no Joker. O Raspberry Pi ainda é a melhor plataforma de robótica? Eles dizem que as novas versões superaquecem demais, lembra os tweets de Alexei Shipilev. Embora seja assustador imaginar o que carrega Shipilev os coloca abaixo, conte-nos sobre um uso mais "normal".
Stephen: Para quem se dedica a esse negócio por hobby, a vantagem do Raspberry Pi é que o sistema é muito fácil de carregar: conecte-o a uma porta USB, insira um cartão SD comum e leva meia hora para fazer tudo. Como eu já disse, na Oracle, trabalhei em uma equipe envolvida em sistemas embarcados comerciais - embora eu próprio estivesse envolvido na defesa de desenvolvedores, mas havia muitas pessoas ao meu redor que testaram e configuraram várias plataformas embarcadas. Portanto, para executar as coisas mais simples em um sistema comercial, levou várias semanas para ser gasto.
Plataformas projetadas para desenvolvimento e não para produção não funcionam em muitas áreas e precisam de testes adicionais. Vários problemas surgem, por exemplo, pode não haver drivers para a tela, alguns recursos podem não funcionar, as próprias plataformas geralmente não funcionam (se esses são protótipos). E, em geral, as pessoas estão acostumadas com esse estado de coisas: se você possui uma nova plataforma, para começar a trabalhar nela, precisa gastar cerca de um mês.
Usando as mesmas tecnologias, a Fundação Raspberry Pi no Reino Unido criou uma plataforma fácil de usar na educação, simples, eficiente e com um ótimo ecossistema. Em particular, é bom para quem quer fazer um projeto simples em seu tempo livre - a propósito, escrevi um
livro sobre Java e Raspberry Pi.
O Raspberry Pi remove a maior parte da incerteza que é aberta ao usuário de outras plataformas incorporadas e, com ele, não é necessário o desenvolvimento de componentes para a plataforma. Assim, no Raspberry Pi você pode realizar seus pequenos projetos no seu tempo livre, não precisa ser feito profissionalmente.
Oleg: O lado robótico do Raspberry Pi mudou ao longo dos anos? Eu não fiz isso de propósito, mas até onde eu sei, o Java tem GPIO por padrão. Existem estruturas, ou talvez os próprios fabricantes de hardware forneçam suporte?
Steven: Existem muitos projetos financiados pela comunidade, como o Robo4J: é uma plataforma de robótica na IOT baseada no Raspberry Pi. Outro ótimo projeto com acesso ao GPIO é o Pi4J. Ele usa a mesma biblioteca C de todos os outros, o WiringPi, mas, além disso, fornece um shell Java muito eficiente e com excelente desempenho.
Realizei pesquisas GPIO de baixo nível para simular pinos analógicos. Geralmente, no Raspberry Pi, isso é muito difícil, pois não é um sistema operacional em tempo real. O wrapper Java adiciona pausas para compilação JIT e similares. Mas com a ajuda da biblioteca Pie4J de baixo nível, pude usar o sensor de distância analógico no controlador em Java. Em geral, com o Raspberry Pi, você pode fazer muitas coisas interessantes diretamente do Java. E, claro, além disso, há um grande ecossistema em C, Python e muito mais.
Oleg: Vi que as pessoas criam clusters a partir do Raspberry Pi. Isso tem algum significado prático?
Steven: No Oracle Code One, em breve haverá uma apresentação do projeto em que participei, este é um cluster de 1024 Raspberry Pi.
Como você sabe, não é difícil montar um cluster de 10 ou 20 Pi, embora isso leve bastante tempo. Se o cluster tiver mais de 1000 Pi, há problemas com o consumo de energia, o carregamento de um cartão SD ou através da rede, com a topologia e a infraestrutura de rede corretas - a mensagem entre os nós da rede não deve se tornar um gargalo nos cálculos. Além disso, resfriar uma quantidade tão grande de Pi em uma sala não é uma tarefa trivial. Mas quando superarmos todas essas dificuldades, será o maior cluster de Raspberry Pi do mundo. A propósito, será na forma de uma cabine telefônica azul da polícia britânica - como você sabe o que é uma série de televisão de ficção científica. Espero que não tenhamos violado os direitos autorais de ninguém.
Um grupo desse tipo é como ter uma ferrovia de brinquedo com trens, mas ao mesmo tempo simula uma rede ferroviária em grande escala. De acordo com esse modelo, um trem real nunca pode passar, e a mesma história aqui: um cluster de Raspberry Pi 1024 não será mais poderoso do que uma GPU moderna com várias centenas de núcleos, mas esse cluster é útil para simular o comportamento de grandes sistemas. Além disso, é ótimo para algumas tarefas altamente paralelizadas. Mas muitas vezes a rede ou a velocidade de leitura e gravação de cartões SD se torna um gargalo. E para algoritmos complexos, são precisamente essas coisas que são limitações reais.
Oleg: Sim, e esse cluster pode ser usado como um modelo de treinamento, você pode tentar implantar algo usando o Kubernetes, Docker e alguns produtos JFrog.
Stephen: Por que não? * risos *
Oleg: Você é ex-funcionário da Oracle e faz Java há muito tempo. Como você vê o futuro da linguagem? Talvez seja para GraalVM, Valhalla ou algo assim?
Stephen: Com os lançamentos do Java em um futuro próximo, muitas tecnologias interessantes aparecerão. Os dois mais importantes, um deles que você já nomeou, é o GraalVM. Essa é a infraestrutura do compilador de próxima geração. Estamos falando de um compilador escrito em Java e para Java, que pode funcionar com várias linguagens e que é muito mais fácil de otimizar do que o HotSpot comum. Acho que, a longo prazo, esse compilador superará outros compiladores da JVM e se tornará uma parte importante da arquitetura Java.
Uma vantagem significativa do GraalVM é a compilação AOT. É especialmente útil para dispositivos móveis e incorporados. O código é compilado antecipadamente, o binário é implantado no dispositivo e o tempo de inicialização e a memória necessária são comparáveis ao código em C, Go e outros idiomas. Além disso, a compilação AOT permite trabalhar com microsserviços ou arquitetura sem servidor com muito mais eficiência, onde muitos processos são executados simultaneamente em vários servidores ou em diferentes threads na mesma máquina. Se necessário, você pode executar uma JVM separada para cada contêiner do Docker ou ambiente virtual. Em geral, hoje em dia, para coisas como sem servidor em Java, o GraalVM se tornou quase indispensável.
Outra nova tecnologia interessante na qual a equipe da JVM está trabalhando é a Fibers. Eles permitem criar aplicativos Java de maneira tradicional, com encadeamentos, mas, ao mesmo tempo, têm o mesmo desempenho como se você estivesse usando uma estrutura assíncrona, por exemplo, Vert.x, Node.js ou outra.
Sempre há uma contradição na programação: por um lado, a necessidade de otimizar o desempenho do código, por outro lado, o desejo de escrever código claro e de fácil manutenção. Um sistema com threads é mais fácil de ler e mais fácil de encontrar bugs. Os sistemas assíncronos permitem extrair desempenho adicional do código, já que cada encadeamento é usado ao máximo, pois as solicitações são puxadas dentro de um processo. Mas, para obter essa vantagem, é necessário alterar o modelo de programação, o sistema fica mais difícil de manter. As fibras permitem escrever código com threads, mas ao mesmo tempo têm o desempenho de uma estrutura assíncrona.
Oleg: Na verdade, algumas mudanças já foram feitas no OpenJDK para se preparar para a chegada do Loom. Por exemplo, no
JEP 353: Reimplemente a API do soquete herdado .
Stephen: Até onde eu sei, a infraestrutura básica do Fibers and Loom está sendo implementada, mas não será aberta aos usuários, porque os desenvolvedores não querem que as pessoas trabalhem diretamente com eles. Então agora estamos trabalhando em uma API para fibras.
Oleg: Você usa as últimas versões do Java?
Steven: Claro, eu sempre tenho a versão mais recente. De que outra forma? É verdade que não estou escrevendo código de produção no momento. Ao trabalhar com protótipos ou ao explorar novas bibliotecas e estruturas, não há razão para não usar a versão mais recente do OpenJDK. Se o trabalho acompanhar o sistema em produção, pode ser difícil mudar rapidamente para a versão mais recente.
As grandes organizações têm mais dificuldade em atravessar a fronteira do Java 9. Depois houve modularidade e trouxe muitas outras mudanças. Muitas vezes, muitas das estruturas e tecnologias das quais o projeto depende ainda não foram migradas para o Java 9 e posterior, o que também dificulta a transição. Se essa linha for aprovada, será muito mais fácil atualizar ainda mais, pois as próximas versões (10, 11, 12 e, se eu não misturei nada, em breve 13) são bastante semelhantes. Em termos de compatibilidade, a maior mudança é a modularidade.
Oleg: E saindo do Java Enterprise.
Stephen: Sim.
Oleg: Finalmente, você pode contar algo sobre o seu novo relatório, com o qual você veio ao Joker?
Stephen: Quando você fala muito com os palestrantes, segue os aplicativos apresentados na conferência e, em geral, as tendências do setor, pode ver quanto hype sempre surge em torno de novas tecnologias, sejam bots de bate-papo, sem servidor, aprendizado de máquina, inteligência artificial ou qualquer outra coisa. As pessoas sempre se empolgam com essas coisas por causa de sua novidade; você sempre quer descobrir tudo sobre elas o mais rápido possível.
Mas muitas vezes é difícil determinar se avanços importantes estão realmente por trás desse hype ou se não há nada além do hype. Na
minha palestra no Joker, eu quero resolver isso. , , , , . , , .
Joker. - , — , . — , , DevOps Speakeasy. , -.
: . , , . , — -! , -.