Revisão droidcon SF

Olá Habr! Meu nome é Alexander Kolobanov, sou líder de equipe do Android na FunCorp. Em novembro, eu estava em um droidcon em San Francisco. Sob o corte, uma pequena revisão da conferência, notas de viagem e algumas fotos.

Por que voar tão longe?

As conferências Droidcon são realizadas não apenas nos EUA, mas também na Europa. É mais e mais barato voar para lá, mas com base na minha experiência, posso dizer que a localização geográfica decide. Quanto mais a conferência estiver perto da sede do Google e de outras empresas de TI, maior a probabilidade de que palestrantes famosos participem dela.

Além disso, diferentes organizadores em lugares diferentes, e apenas o nome deles os une. Portanto, você precisa olhar para cada cidade separadamente. Na minha opinião, o droidcon NYC é geralmente uma cartola. Do europeu, eu mencionaria o droidcon London - uma conferência digna sobre a qualidade da organização e o nível dos relatórios. Para desenvolvedores de Android da Europa, talvez seja o principal. O droidcon em Berlim e Viena, onde eu também visitei, é mais adequado para iniciantes e desenvolvedores de nível intermediário, e oradores eminentes e relatórios hardcore sobre eles são muito raros.

Se compararmos o droidcon SF com seus colegas russos, seus organizadores pensam menos em coisas como comida (café) - e na conveniência dos participantes. Ninguém envia planos detalhados de como chegar lá, 20 lembretes de que sua conferência será em breve, não cria bots e plataformas para discussão e tudo mais. Sem cãibras, navegação super detalhada e uma variedade chique de nishtyakov. Aqui, em primeiro lugar (assim como no segundo e terceiro), a parte técnica e o nível dos relatórios. Isso não significa que alguns relatórios mais ou menos podem vazar para o programa, mas, em geral, o droidcon SF é uma conferência de desenvolvedores para desenvolvedores, onde há apenas conteúdo de ponta e oradores eminentes.

Diante de tudo isso, eu diria que o programa da conferência em San Francisco foi de alto nível. Não houve relatórios francamente hacky com a recontagem de tutoriais no developer.android.com.

Despesas de transporte e outras

Os Estados Unidos não são um país barato e, se você voar de nossas partes, é improvável que você possa economizar muito em voo. Além disso, todos precisam de um nível diferente de conforto para viver, e o que é aceitável para um não é adequado para outro.

Um conselho universal que sempre funciona: compre ingressos e reserve acomodações com antecedência. Você pode tentar procurar por bilhetes com desconto e analisar mais de perto as vendas. Há muitas informações sobre essas coisas em sites e em grupos especializados em redes sociais dedicadas a economizar em viagens. Você deve olhar para as companhias aéreas de médio porte, que geralmente oferecem serviços não piores do que íngremes e caros. Bem, em geral, no transatlântico, geralmente o serviço é do nível de todos, independentemente da classe. As companhias aéreas de baixo custo não voam a essas distâncias (e bem, provavelmente). E como o custo de um voo é uma parte significativa do orçamento da viagem, é melhor combinar uma viagem à conferência com férias, se, é claro, houver essa oportunidade. Há algo para ver e fazer nos EUA.









Os táxis nos estados são tradicionalmente caros. Portanto, conselhos: use o transporte público ou o estacionamento de carros (é quando um táxi pega várias pessoas que viajam em rotas semelhantes e compartilham o custo da viagem). Entre as cidades, é melhor viajar de ônibus ou alugar um carro. O preço do estacionamento na cidade é muito alto e as condições são difíceis e estranhas (por exemplo, você não pode estacionar das 8h às 22h na segunda quinta-feira do mês - fique e conte), enquanto as pistas são muito convenientes e seguras, e as pessoas na estrada são geralmente não agressivas e previsíveis .

Se falamos de moradia, aqui você não poderá economizar muito, especialmente em cidades caras como São Francisco. Para os amantes, o surf é de treinador, mas o resto é o mesmo - reserve com antecedência.



Local de encontro

A conferência foi realizada no Mission Bay Conference Center. Está localizado em um dos edifícios da Universidade da Califórnia em San Francisco. No mesmo prédio, a propósito, há uma biblioteca, uma sala de ginástica e um café. Havia espaço suficiente, apesar do número bastante grande de participantes (mais de 800). Nos corredores, às vezes tínhamos que dar a volta, mas havia espaço suficiente nos corredores para todos, ninguém ficava ao longo das paredes.

O próprio Mission Bay Conference Center está localizado bem perto do centro da cidade (a 10 minutos de táxi do centro). Aqui precisamos fazer uma observação: San Francisco em si é uma cidade bastante compacta. Do centro ao aeroporto, tome cerca de 40 minutos de táxi (um pouco mais na hora do rush). Portanto, problemas para chegar lá não devem surgir em princípio. A única coisa com transporte público nessa área é bastante complicada, então eu preferi pegar um táxi.

A conferência foi alocada em dois andares, duas salas em cada uma: grande e menor. O registro, onde foram emitidos crachás e camisetas, ficava bem na entrada. Apesar do grande número de participantes, tudo correu muito rapidamente. Demorou apenas alguns minutos para obter um crachá. Uma pequena fila surgiu de manhã logo antes da palestra. E as camisetas, a propósito, eram distribuídas em quantidades quase ilimitadas, e não apenas no registro, mas também em muitos estandes. Assim mesmo.

Atrás da área de registro havia um grande salão, do qual todos já estavam se dispersando nos corredores. Também havia uma área de exposição com estandes de empresas patrocinadoras (aliás, havia mais no segundo andar e os prédios mais densos) e pontos de café. Diretamente do corredor, você pode ir a um pequeno parque localizado dentro do campus. Agradável e confortável.

Momentos organizacionais

Tudo estava bem organizado, mas um pouco incomum comparado às conferências russas. Definitivamente, houve menos barulho e mais atenção aos relatórios e ao lado técnico. Da "comida" eram apenas chá e café. Damos muito mais atenção às pausas para café, catering e nutrição em geral. Aqui, além de bebidas quentes, não havia nada. Mais precisamente, na hora do almoço, eles ainda carregavam geladeiras com latas de "Cola". Se você quiser comer - ali, ao virar da esquina, há um café onde você pode comprar um sanduíche. Sem super cuidados e hiper custódia para você. E, a propósito, essa era a norma.

O almoço também foi bastante nominal: uma maçã, batatas fritas e, novamente, um sanduíche. Alimentado formalmente, mas não mais. Muitos estudantes foram almoçar no mesmo parque em bancos.

Mas é especialmente importante notar a parte técnica da organização. Praticamente não houve problemas com o WIFI, apesar de estar aberto a partir do campus. Os alto-falantes são configurados e conectados muito rapidamente, em alguns minutos. Durante o relatório, monitoramos constantemente para que tudo funcionasse bem. Eles até reduziram e adicionaram som quase instantaneamente quando o alto-falante, por exemplo, começou a falar mais alto ou mais baixo. Em geral, eu não notei um único problema e um problema com o equipamento, tudo estava super. A menos que em todos os relatórios os microfones fossem usados ​​ao redor da sala, mas os próprios oradores falaram as perguntas feitas a eles.

Do incomum: eu realmente gostei da sala silenciosa. Apenas uma sala onde você pode simplesmente entrar, tomar um chá, sentar-se com um laptop em silêncio e fazer uma pausa no barulho de uma grande conferência.

O programa

Os relatórios foram distribuídos em quatro correntes, quase da manhã à noite. O site foi aberto às 8h e o primeiro relatório começou às 9h. Tudo terminou por volta das 19h. Os tópicos não tinham temas claros. Muito provavelmente, os organizadores distribuíram os espaços por participação estimada para cada relatório. Os principais tópicos incluem CI / CD (como quase todas as conferências Android nos últimos dois anos), testes de interface do usuário (de repente, quase ninguém os possui), Kotlin (onde estamos sem ele agora), arquitetura aplicativos (colete dois desenvolvedores do Android e em breve eles falarão "pela arquitetura"). Em uma palavra, tudo é bastante padrão aqui. Não posso dizer nada de interessante sobre a palestra, apenas foi. Eles falaram sobre o fato de que criamos aplicativos que estão ao telefone de quase todos, moldamos este mundo e como as pessoas interagem e se comunicam nele. Mas lembro-me do discurso de encerramento cômico (embora nenhuma comédia tenha sido planejada) de Romain Guy e Chet Haase, pessoas muito famosas no mundo do desenvolvimento Android que trabalharam por um longo tempo no Google e determinaram como a plataforma está agora. Eu acho que muitos assistiram suas performances no Google I / O (a propósito, muito legal) sobre aceleração de hardware, animações e renderização. Se você não olhou, eu recomendo. Eu não gostaria de falar muito sobre a conversa final da comédia , porque recontar piadas é uma atividade mais ou menos. Melhor ver por si mesmo.
Se você tentar destacar os principais relatórios, será puramente pessoal e depende daqueles que são mais interessantes para mim. Aqui está:

Como criar um pipeline de teste de desempenho a partir do zero por Valera Zakharov do Slack. Grande desempenho, fogo direto. Muitos conselhos práticos e bons e uma experiência interessante. Um relatório sobre o fato de que você não deve criar seu próprio farm de dispositivos se não tiver uma equipe separada para dar suporte a ele. E quão importante é não apenas tornar o aplicativo rápido, mas também constantemente, de confirmação para confirmação, para garantir que continue assim e para não permitir regressões. E se os testes geralmente “fazem barulho” e caem em vão, custam um pouco, porque logo todos começarão a ignorá-los.

Design de API centrado no ser humano , Pierre-Yves Ricau, Square. Aquele que cria o LeakCanary e um monte de bibliotecas igualmente conhecidas junto com outros desenvolvedores da Square. Ele contou como criar uma API externa para as pessoas. Torne-o intuitivo. Portanto, para minimizar a porcentagem de erros para quem o usa. Um bom relatório não é apenas sobre como escrever uma API externa, mas sobre como projetar adequadamente em geral. A propósito, afinal, a API de qualquer módulo do seu aplicativo também deve ser fácil e o mais clara possível, certo?

Construindo para o futuro no Snapchat , Ben Dodson, Gustavo Moura - inesperadamente, mas do Snapchat. Sobre como refazer um aplicativo com mais de 4 anos, é bastante lento e mudou o conceito várias vezes ao longo da vida. E, em geral, agora, primeiro, a câmera e depois o bate-papo. E nem o Retrofit foi quando você o escreveu. A idéia principal é que você não precisa se apressar para reescrever tudo. Seria bom entender suas prioridades e o que você deseja, introduzir métricas e cumpri-las rigorosamente. Embora alguns módulos possam ser reescritos do zero. E sim, isso, de fato, já é um aplicativo diferente e precisa ser apresentado de alguma forma aos usuários; às vezes, apenas substitua silenciosamente um módulo por outro e tente impedir que tudo caia. Baseado em eventos reais.

Havia muitos relatórios interessantes e úteis. Você pode destacar a história dos desenvolvedores do Uber, como eles lutaram com Memória insuficiente. Freqüentemente, não apenas os vazamentos e o enorme consumo de memória levam a eles, mas também um grande número de threads. Afinal, cada thread aloca uma parte da memória para si mesma sob a pilha, por exemplo. Poucos encadeamentos também são ruins: as tarefas que dependem umas das outras, devido à falta de encadeamentos, entrarão no conflito de inanição do encadeamento (como chamaram a situação em que uma tarefa espera pelo resultado de outra e a que é brega não possui um encadeamento para executar). A saída dessa situação é bastante simples: use uma ferramenta para multithreading em todo o aplicativo (eles escolheram Rx) e saiba como ele funciona. No caso de Rx, por exemplo, examine a diferença entre agendadores.

Os desenvolvedores do Facebook apresentaram uma nova biblioteca para trabalhar com imagens Spectrum. Por tradição, a biblioteca do Facebook usa código nativo, incluindo o MozJPEG, que agora é um dos melhores codecs para JPEG. Capaz de codificar, compactar, otimizar, adicionar várias transformações. Em geral, uma funcionalidade bastante interessante, que antes disso era bastante difícil de encontrar de uma forma fácil de usar.

A partir do relatório sobre o Kotlin, chamado Advanced Kotlin , você pode descobrir que é avançado no Kotlin; se você sabe o que são infix e tailrec, distingue entre in e out para o tipo genérico, sabe sobre onde e classes seladas. Bem, você também pode criar um dsl semelhante em lambdas.

Também houve bons relatórios sobre a arquitetura da interface do usuário do Tinder e do Netflix. O primeiro cria, por assim dizer, uma interface do usuário reativa em estados que são alternados por ações e usa o LiveData e o ViewModel de componentes arquiteturais para isso. Estes criaram seus próprios componentes, encerrando uma parte da lógica junto com o View e os conectaram através da implementação do barramento de eventos.

Portanto, havia muitos relatórios bons, e a menção de cada digno de atenção provavelmente levará uma dúzia de páginas. Não era que nenhum relatório fosse francamente ruim. Mas, pessoalmente, não gostei da reportagem de Romain Guy sobre fotografia. Não é apenas como tirar fotos do seu aplicativo, mas simplesmente sobre a teoria da fotografia. Ele é, obviamente, um desenvolvedor respeitado, mas as pessoas pagaram dinheiro por uma conferência sobre desenvolvimento do Android, e não por um curso de fotografia.

Rede

Como tal, não havia espaço para comunicação com os alto-falantes ou pelo menos uma zona especial. Os oradores, em regra, após a apresentação, responderam a perguntas da platéia e, em seguida, os convidaram a conversar informalmente, no estilo de "Eu estarei aqui até o fim - pegue, pergunte, ficarei feliz". Mas há uma nuance. Quase todas as empresas de onde os palestrantes vieram tinham estandes onde não apenas palestrantes, mas também outros desenvolvedores da empresa estavam saindo, portanto, aparecer e fazer uma pergunta de interesse não era um problema. Portanto, as arquibancadas eram interessantes e às vezes muito animadas.

Quem deve visitar o droidcon SF?

Vale a pena visitar esta conferência para aqueles que desejam ouvir os relatórios aplicados de desenvolvedores famosos e também perguntar pessoalmente como e o que funciona para quem. A atmosfera é muito aberta e amigável. Mas eu não recomendaria ir à conferência para aqueles que têm pouca experiência. Os relatórios são bastante complicados, o ritmo da conferência é muito alto. 8 aulas por dia são duras. Tão grave que Slack, por exemplo, distribuiu um kit de sobrevivência - uma bolsa com vitaminas e pílulas para dor de cabeça - em suas bancas. E, como você sabe, em toda piada existe apenas uma fração da piada. Além disso, pelo menos dessa vez, muitos tópicos não eram apenas sobre programação, mas também sobre infraestrutura, sua experiência e prática. Assim, líderes de equipe e gerentes de desenvolvimento também poderão encontrar conteúdo adequado para si no droidcon SF.

Embora o tópico sobre CI, testes e tudo relacionado a ele ainda esteja vivo e muito relevante, pode valer a pena ir para os engenheiros de QA e DevOps. A propósito, uma das minhas observações interessantes: nas empresas representadas, elas costumam falar simplesmente de engenheiros e não as dividem em desenvolvedores, testadores e infraestrutura. Isso se manifesta no fato de que muitos podem mudar de função e, como desenvolvedor, entrar, por exemplo, em uma equipe de infraestrutura. Por que não, ainda engenheiros.

Impressão geral

A impressão geral é extremamente positiva. Eu esperava relatórios mais fracos, mas quase não havia "orientações". Em princípio, eu estava pronto para a organização da comida, ou melhor, sua ausência. Eu esperava que houvesse problemas para entender tudo o que foi dito, mas a maioria dos oradores falou claramente e realmente não acelerou, portanto, em princípio, não houve problemas. Às vezes, demorava um pouco para me acostumar com o sotaque. E a organização técnica e a comunicação informal excederam claramente as expectativas. E essa não é apenas a minha opinião. Houve muitas discussões interessantes no salão e nas arquibancadas entre os relatórios.





PS Os links abaixo são resenhas de outras conferências estrangeiras em nosso blog:
droidcon Vienna
Atlassian
droidcon london
Goto berlin
Cimeira da Web