Depois de
recuperar o
fôlego após o
HolyJS de São Petersburgo, lemos todas as críticas da platéia - e descobrimos que tipo de reportagem a platéia mais gostou. E devido ao fato de que durante a conferência houve uma transmissão no YouTube do primeiro salão, alguns desses "favoritos" já estão disponíveis para todos.
Portanto, decidimos falar sobre a conferência passada da seguinte maneira: para descrever vários relatórios que o público gostou (dando exemplos de citações deles) e nos casos em que o relatório foi transmitido ao público, forneça imediatamente um link com um código de tempo. Você pode ter uma impressão geral do evento e participar pessoalmente da história.
Além de relatórios
Mas primeiro, algumas palavras sobre os outros momentos memoráveis do HolyJS:
Primeiro, além das apresentações, desta vez houve três discussões sobre o formato “Birds of a Feather”: vários palestrantes estavam sentados, todos se reuniram e uma discussão informal (sem câmeras e microfones) sobre um tópico em chamas. No total, houve três sessões do BoF com os tópicos "Node.js na empresa", "Otimização do lado do cliente" e "O que, além do JS, um desenvolvedor decente deve saber".
Em segundo lugar, a ação foi suficiente para os estandes de patrocinadores e muitos gostaram especialmente do concurso "Code in the Dark" no estande da VK. Dois participantes sentam-se em laptops e tentam criar uma página em 10 minutos, mas ao mesmo tempo podem ver apenas o layout "correto" e seu código, mas não veem o resultado de suas próprias ações. Mas é visível para o público, permitindo que eles comparem - acabou quase um meme “expectativa e realidade”.
As fotos não transmitem o processo, então tentei gravar um pequeno vídeo no telefone quando o desenvolvedor da VK Timofey Chaptykov estava por trás do laptop. O registro acabou sendo muito amador, mas pelo menos uma ideia dá:
E agora para os relatórios:
Vitaliy Fridman
O fundador da Smashing Magazine tornou-se um triunfo absoluto da conferência: falando com dois tópicos, ele conseguiu ocupar o primeiro e o segundo lugares no ranking de acordo com a classificação do público.
Seis meses atrás, no HolyJS anterior, Vitaliy já conquistou muitos com sua performance de
“Novas aventuras em Responsive Web Design” . Agora, a conferência foi aberta pela "segunda temporada de aventuras de front-end" com novos truques, e Vitaly transmitiu seu estilo reconhecível com toques em inglês:
“O que realmente me surpreendeu foi o
Guess.js . Quem ouviu falar dela? Uma característica interessante. Nós usamos o webpack, fazemos pacotes, temos pedaços. Mas e se usarmos a análise preditiva e o aprendizado de máquina para adivinhar o que será necessário na próxima interação do usuário? O usuário visita o site, podemos prever com o Google Analytics onde ele clicará ou o que fará, e podemos pré-carregar o pedaço que provavelmente será usado. ”
A propósito, o criador do Guess.js é familiar para muitos: é
Minko Gechev , quem
falou sobre a aceleração de aplicativos Angular no HolyJS anterior.
A apresentação de abertura de Vitaly
está na transmissão. E o que havia em seu segundo relatório, "Pequenos truques sujos dos cantos escuros do comércio eletrônico", que ainda não apareceram no YouTube? Considerações sobre como podemos facilitar conversões e aumentar as vendas enquanto trabalhamos em lojas on-line. Por exemplo, como:
“Trabalhei com uma montadora alemã e discutimos se o configurador de carro no local precisa ser responsivo. A julgar pelos nossos dados, ninguém comprou um carro pelo telefone. Por que então responsivo? Mas pensar assim é um grande erro. Porque se uma pessoa quer comprar um carro caro, precisa de tempo para se convencer de que esta é uma boa compra. Precisa brincar com a ideia. E onde temos tempo para isso? Um ponto muito importante está no banheiro. E eles levam um smartphone ao banheiro, não um laptop. ”
Nikolay Matvienko - Decomposição do thread principal no Node.js para aumentar a taxa de transferência
Se após os truques de comércio eletrônico de Vitaliy Fridman alguém tiver a sensação de "interessante, mas os gerentes tiverem dor de cabeça em aumentar a conversão, e eu quero detalhes técnicos mais detalhados", um relatório de Nikolay Matvienko pode ser uma boa opção. Lá, também foi mencionada a experiência de trabalhar em projetos de comércio eletrônico, mas já no contexto de produtividade e cargas de trabalho: quando em determinados dias os pedidos são de magnitude superior ao normal e você precisa suportar esse pico, entenderá esses tópicos. Nikolai dividiu tudo o que acontece no fluxo principal em componentes e descreveu cada um separadamente, por exemplo, assim:
“A renderização no servidor é uma operação típica da CPU que pode demorar 100, 200 e 500 milissegundos. A renderização no Node.js é muito conveniente, mas você precisa pagar pela conveniência - a renderização da renderização bloqueia o loop do evento. Mas há uma solução: use a renderização de streaming, divida esta operação em partes pequenas, renderize-a em pedaços e transmita-a em resposta. "
Há um relatório na transmissão - para que você possa descobrir pessoalmente todos os detalhes técnicos e admirar os slides, que muitos dos comentários elogiaram separadamente.
Kirill Cherkashin - Trabalhando com árvores abstratas de sintaxe JavaScript
Às vezes, em conexão com esses tópicos, surge a pergunta: “tudo bem, isso é profundo e interessante, mas a AST me dará algum resultado prático ou é apenas bom saber para o desenvolvimento geral?” Cyril decidiu mostrar que isso poderia ser útil e começou com um bom exemplo: “Quantos de vocês já esqueceram de remover o console.log do código antes de cometer? E quem acha que ele pode ser encontrado lá regularmente? E se considerarmos esses casos, quem ainda pensa assim? Ok, uma expressão regular tão monstruosa passou em todos os testes que eu consegui pensar, mas a pergunta é: quem quer manter esse código? Em geral, a AST para mim aqui é claramente mais eficaz ".
Como resultado, entre as análises da audiência, você pôde ver as palavras "o relatório foi mais útil do que eu esperava". Talvez alguns desenvolvedores agora estejam salvos do que os fez se expressar regularmente!
Imad Elyafi - Recuperando a Web móvel
Os visitantes do HolyJS anterior podem se lembrar da conversa de Imad sobre a conversão de perfis do Pinterest para o React, onde ele citou os benefícios da migração gradual. E aqui, pelo contrário, ele contou como a web móvel no Pinterest foi completamente refeita. Por que isso é necessário?
“Há três anos, analisamos o estado da nossa web móvel e percebemos que os usuários não gostam disso. Mas sabíamos que nossos aplicativos nativos tinham uma taxa de engajamento 80% maior. Em seguida, tomamos uma decisão difícil de incentivar as pessoas a usar aplicativos (indo a um site móvel, você viu uma oferta para abrir / instalar o aplicativo). E dado o tamanho da nossa equipe, isso foi justificado.
Agora, crescemos e estamos prontos para atualizar. E embora as métricas falem a favor dos aplicativos, elas não medem sensações. Eles não podem avaliar como o usuário não abrirá mais o site, porque ele teve uma experiência desagradável. E quando optamos novamente por promover aplicativos ou investir na Web para dispositivos móveis, escolhemos o segundo. ”
Como resultado, o Pinterest criou o moderno Progressive Web App - e o HolyJS se tornou um caso pouco frequente quando eles falam sobre a PWA não teoricamente, mas com base no uso prático de uma grande empresa. Este relatório
é transmitido, para que você possa descobrir pessoalmente todos os detalhes da experiência de outra pessoa.
Alexey Kozyatinsky - Depurando JS usando o Chrome DevTools como exemplo
Quando uma ferramenta é tão requisitada quanto o Chrome DevTools, parece fácil pesquisar no Google tudo sobre ela. E, provavelmente, é possível encontrar frases semelhantes em algum lugar sem participar da conferência:
“A criação de perfil é dividida em instrumentação (onde no código você chama o horário ao chamar a função) e amostragem (onde você coleta a pilha após um determinado intervalo de tempo e vê em qual função passou o tempo). É importante lembrar que o criador de perfil de CPU no DevTools usa amostragem: essa é provavelmente a única abordagem que funciona bem em JS. A V8 adora compilar seu código quase no nativo e executá-lo muito rapidamente. Se definirmos um cronômetro para verificar novamente o tempo, distorceremos bastante a imagem final. E a amostragem permite calcular um perfil que mostrará o desempenho muito de perto. ”
No entanto, no contexto da conferência, é muito importante que o palestrante seja diretamente um membro da equipe do DevTools, e as zonas de discussão possibilitaram questioná-lo em detalhes após o relatório. E nenhuma transmissão transmitirá esta parte: a oportunidade de se comunicar no idioma nativo com o desenvolvedor de uma ferramenta para ajudá-lo a entender como seu aplicativo funciona. O próprio Alexey também teve o prazer de se comunicar, enfatizando no relatório que era importante para ele se apresentar em São Petersburgo (a cidade onde a equipe do DevTools estava baseada antes de se mudar para a Califórnia). Bem, se ele não tivesse dito isso, alguém poderia ter adivinhado sua origem em Petersburgo. Algo traiu Stirlitz: o número
"239" no
Twitter ou exemplos de Dostoiévski nos slides.
Dmitry Bezhetskov, Vladimir Anufrienko - Portando JS para Elbrus
Aqui eu quero entregar uma medalha separada "pela singularidade da tarefa". Muitas pessoas podem dizer "escrevemos em JS" - e quantas pessoas no mundo podem dizer "transportamos JS para outra arquitetura de processador" e contar sobre isso? Com pouca frequência, em um evento JS, você pode ouvir, por exemplo, o seguinte:
“Elbrus tem especulatividade explícita, em contraste com a especulatividade implícita de x86. Isso significa que, se considerarmos esta função:
function Foo(a) { if (a === null) { return 0; } return a.bar; }
então, usando a especulatividade, podemos executar uma ação "ilegal" lendo o valor do campo bar antes mesmo de saber se "a" é zero ".
É claro que a aplicabilidade prática do conhecimento sobre a arquitetura interna dos processadores Elbrus está em questão. Mas as avaliações do relatório mostram que a profundidade da análise do trabalho dos motores V8 e SpiderMonkey não deixou indiferentes os fãs hardcore. E as seções em espera da pergunta e resposta descobriram por que o LLVM não é usado em linguagens dinâmicas e quando é esperado que uma máquina virtual universal para bytecode apareça.
Palestras: Maxim Yuzva e Ilya Klimov
Finalmente, cada um dos dois dias da conferência terminou com um desempenho em que não se tratava de Service Workers ou processadores VLIW, mas de um desempenho completamente diferente. O primeiro dia foi fechado por
Maxim Yuzva , o segundo por
Ilya Klimov , e suas performances ecoaram: ambos não tentaram contar mil fatos sobre a nova biblioteca de moda, mas sugeriram pensar em quais fatos geralmente precisamos, o que mais precisamos e em que direção desenvolver.
Maxim concentrou-se em momentos de trabalho que estão fora das holivares usuais sobre estruturas. Se você tiver alguma dúvida sobre tecnologia, pode recorrer ao Stack Overflow - mas "como interagir com os colegas" não está escrito lá, e isso também é importante. Após este relatório, a discussão na área de discussão acabou sendo tão tempestuosa e demorada que, de fato, foi obtida uma quarta sessão não planejada do BoF.
A ênfase de Ilya foi colocada em como e o que aprender em um mundo em que a tecnologia está se desenvolvendo tão rapidamente que você ainda não consegue acompanhar todos. Como era de se esperar deste orador, o assunto não ficou sem piadas (o "Lótus amarelo" em geral se tornou um meme local da conferência), mas a mensagem geral foi bastante séria.
Tanto a
primeira apresentação como a
segunda estão disponíveis na transmissão.
E se você estava interessado naqueles relatórios que não estavam na primeira sala, para que você não chegasse à transmissão pública, até agora os vídeos estão disponíveis apenas para os participantes da conferência, mas depois de alguns meses publicaremos tudo no YouTube (e não mais no formato de transmissão "bruto", mas em uma versão cuidadosamente criada). Dizemos adeus a isso e começamos a aguardar o próximo HolyJS, que será realizado em Moscou em novembro.
Finalmente - uma foto particularmente espetacular da sala de conferências:
