Você dirá qual é o problema para o desenvolvedor de dispositivos móveis antes de escrever o back-end. O principal é que a API deve ser conveniente, compreensível e flexível. Mas achamos que não.
No AppsConf, todos pensamos que às vezes precisamos ir além do desenvolvimento móvel e bombear o chapéu da letra T no modelo em forma de T. Aqui, por exemplo, conheça as linguagens de servidor um pouco mais profundas do que: "Ouvi dizer que Ruby morreu". E um pouco mais amplo - isto é, não apenas com os populares, mas também nas segundas filas e até nas subterrâneas.
Para você se inspirar na idéia da faixa introdutória, gravamos uma entrevista com Nikita Sobolev. Eles estavam indo para falar sobre linguagens de programação, mas acabou sobre os programadores. Seja bem-vindo, se você acha que é melhor ser apenas um bom desenvolvedor, e não um desenvolvedor de Android ou iOS, e especialmente se você não concorda com isso. Sexta-feira é a hora de discutir.
- Como você gosta da ideia de toda uma faixa de relatórios de revisão sobre várias tecnologias, do back-end ao front-end na conferência sobre desenvolvimento móvel, que chamamos de Introdutório?
Nikita Sobolev, CTO da wemake.services, autora da metodologia Repeatable Software Development Process, organizadora de ElixirLangMoscow, membro do Comitê do Programa Python de Moscou , Python Conf ++ , palestrante frequente em conferências de TI e defensora da qualidade do código .
Na minha opinião, esta é a melhor faixa em uma conferência móvel.
Não gosto muito da ideia de especialistas restritos. Estou muito mais perto da ideia de uma pessoa em forma de T - ou seja, uma pessoa que é bem versada em uma coisa, mas com um amplo horizonte de compreensão de problemas na área de assunto.
Infelizmente, parece-me que os desenvolvedores móveis, nesse sentido, são por conta própria. A questão é agravada pelo fato de serem muito dependentes do fornecedor. Grosso modo, a Apple fechará - eles sairão no frio.
Portanto, eu realmente gosto da idéia da pista introdutória e do fato de os convidados da conferência serem convidados a olhar em volta, descobrir o que os outros têm, adotar sua experiência e melhorar a si mesmos como especialistas em termos de amplitude de pontos de vista.
- Para quais outras conferências essa idéia é relevante?Para tantos. Eu tenho em mãos um exemplo de Python. A última vez que convidamos Go, Elixir e Julia. Este ano, quero convidar o front-end e o Haskellist (a
propósito, o Call for Papers já está aberto ). Como os desenvolvedores de Python também são diferentes, muitos deles funcionam como full-stack, também é útil para eles obter conhecimento de fora.
- Você acha que os desenvolvedores de dispositivos móveis estão mais dispostos a olhar ao redor, porque se tornou necessário para o desenvolvimento profissional, ou sempre foi assim, apenas a comunidade amadureceu?É difícil julgar com precisão a última vez que escrevi um aplicativo para dispositivos móveis em 2010. Minha língua principal era o Java, peguei o Objective-C e escrevi um aplicativo para iOS. Fiquei inspirado, pensei, agora vou começar a fazer tudo isso. Mas não: não havia gerenciamento de memória, não havia bibliotecas, não havia gerenciamento de dependências, o sistema de construção era nojento. Desde então, não analisei cuidadosamente essa área.
E agora vejo várias tendências que naturalmente atraem trabalhadores móveis para “programação séria”.
No passado, os idiomas eram altamente especializados nessa área. Objective-C foi apenas para o desenvolvimento da Apple. E agora, por exemplo, eles estão tentando puxar o Swift para o servidor e fazer algo nele. Java para o back-end e para Android eram duas linguagens diferentes. E agora Kotlin é mais ou menos semelhante para ambos. O JavaScript apareceu no mundo do desenvolvimento de aplicativos móveis, e esse é um tipo de linguagem de servidor e, ao mesmo tempo, uma linguagem para o frontend.
Existe uma infraestrutura única que começa a interessar as pessoas. Se o desenvolvimento móvel anterior (no meu caso, este é 2010) estava completamente fora de alcance, agora tudo está diferente.
Além disso, a aproximação é dos dois lados. Uma integração mais estreita da plataforma oferece às pessoas a capacidade e a necessidade de seguir essa integração.
- Mas se a integração em si é direcionada ao desenvolvedor de dispositivos móveis, por que ele deveria entender os idiomas para o back-end?Eu tenho uma resposta filosófica para esta pergunta.
Se você quer ser um desenvolvedor de Android, provavelmente não precisa entender o back-end. E se você quer ser apenas um desenvolvedor - é claro, é necessário.
Um desenvolvedor é alguém que resolve problemas do mundo real com código. Consequentemente, as decisões podem ocorrer em qualquer lugar, inclusive em um aplicativo móvel, em um servidor, em um front-end. Um bom desenvolvedor pode resolver em princípio qualquer problema do mundo real usando ferramentas de desenvolvimento.
É claro que existe uma entrada para cada uma dessas ferramentas, o acúmulo de prática etc., mas uma fixação rígida em uma tecnologia, na minha opinião, é prejudicial para o indivíduo envolvido nela.
Pelo menos a tecnologia está se tornando obsoleta. Os idiomas populares há 15 anos agora quase nunca são usados. A habilidade de constantemente desenvolver e aprender coisas novas, olhando para os vizinhos, é extremamente importante para qualquer desenvolvedor. Em particular, é importante entender o back-end, porque o back-end é fundamental para todo o desenvolvimento, hoje tudo de alguma forma se comunica com o servidor.
Além disso, com certeza, os usuários de mobilidade não se sentem à vontade com outros desenvolvedores que acham mais fácil encontrar um idioma comum. O front-end e o back-end ainda estão mais próximos do que o desenvolvedor de aplicativos móveis para qualquer um deles. Meu relatório ajudará em certa medida a resolver o problema da comunicação humana, ajudará a integrar.
Quão profundo ou superficial você precisa entender é outra questão. Especialmente se estamos falando de um desenvolvedor de dispositivos móveis que, seja o que for que diga, precisa se aprofundar em seu campo.
Sou a favor do fato de que você precisa olhar ativamente ao redor e no passado. É importante estudar a história do software e da programação. Se você não conhece a história, reinventará muitas coisas que você já inventou e abandonou por razões completamente objetivas. Dirijo um
canal de telegrama onde compartilho links para projetos interessantes de código aberto, sem estar vinculado ao idioma, e tento destacar idéias importantes.
- Um desenvolvedor de aplicativos móveis tem ideias gerais suficientes ou não?Depende, antes de tudo, do meio ambiente. Se uma pessoa tem necessidade de influenciar diretamente o back-end em sua empresa: para definir tarefas mais corretas para ela, para participar do processo, talvez para gerenciar essas pessoas, você precisará descobrir isso profundamente.
Mas se você está envolvido apenas no desenvolvimento móvel, basta ter uma idéia superficial do que está acontecendo lá, quais idiomas, problemas, soluções populares. Para essas pessoas,
meu relatório sobre o Saint AppsConf também é calculado. Naturalmente, uma apresentação profunda não pode ser feita em um relatório.
- O que mais um desenvolvedor precisa para ser um desenvolvedor legal?- A capacidade de ler e entender o que é lido.
- Capacidade de escrever, expressar seus pensamentos por escrito.
- A capacidade de falar para expressar esses pensamentos verbalmente.
- Capacidade de ouvir e ouvir outras pessoas.
- Compreendendo a área de assunto. O desenvolvedor deve entender o que está fazendo, porque resolve o problema da vida de maneiras técnicas.
- E, claro, entenda a técnica.
Parece-me que essas habilidades são suficientes. Tudo o resto pode ser deduzido destes ou descartado.
- Então você acha que precisa entender a área de assunto?Limitado, é claro, mas necessário. Por exemplo, temos simultaneamente 3-4 projetos, é claro, não entendo todos perfeitamente, mas entendo os conceitos básicos com os quais trabalho. Como eles estão interconectados, como eles afetam o dinheiro, onde está a despesa, onde está a receita, por que tudo isso é necessário para os negócios.
E eu aconselho outros desenvolvedores também. Em nossa empresa, elaboramos documentação para eles, como o negócio funciona, quais problemas resolvemos, por que isso não pode ser resolvido manualmente. Às vezes, contratar uma pessoa para que uma vez, por exemplo, tenha passado por um diretório de mercadorias, é mais barato. Se automatizarmos o processo, você precisará entender o porquê.
- Vejamos um exemplo. Se você escreve um serviço de entrega para uma padaria, precisa entender como a entrega funciona, mas não precisa entender os tipos de bolos que essa padaria assa?E em alguns tipos de pães também. Porque alguns pães podem ser armazenados por uma hora e por dois dias. Por conseguinte, a sua entrega será diferente.
- No seu relatório, você promete considerar vários idiomas populares de uma só vez, vários idiomas da segunda linha e vários idiomas do subterrâneo profundo. Quais idiomas eles serão?Não vou usar as linguagens que os participantes da conferência já podem conhecer: Kotlin, Java, JavaScript. Não faz sentido falar sobre eles se a maioria do público já está familiarizada com eles. Decidi falar sobre idiomas que as pessoas certamente não conhecem, porque os aplicativos móveis não escrevem para eles. Há muito por onde escolher.
Eu basicamente amo linguagens de programação. Sem uma tarefa específica. Eu gosto da linguagem de programação como uma ideia. Algumas pessoas pensaram: “Existe um conjunto de problemas que podem ser combinados e resolvidos de uma só vez. Vamos criar uma linguagem para isso. ” Ele resolverá uma lista específica de problemas. E outro idioma resolverá outros problemas, porque geralmente todos os problemas não podem ser resolvidos de uma só vez.
Eu realmente gosto de observar quais problemas cada idioma resolve e por que pode ser necessário na prática. A própria linguagem se torna um objeto de arte intelectual para mim. Um grande número de pessoas trabalhou, pensou, projetou, otimizou. Isso é muito interessante, então eu sigo muitas linguagens de programação.
Os idiomas que escolhi para o relatório têm várias características interessantes. Em primeiro lugar, eles são controversos. Nenhuma delas é uma linguagem que seja finalmente boa em tudo na consciência da comunidade.
Todo mundo sabe que o Python é lento, mas ainda é a linguagem mais popular, é usada em qualquer lugar. Vou tentar explicar por que é usado.
E por falar em Ruby, a primeira coisa que as pessoas dizem é que Ruby está morto. De fato, os desenvolvedores Ruby agora mais do que em qualquer outra linguagem se preocupam com a arquitetura e implementam um grande número de idéias de outras linguagens - funcionais, orientadas a objetos e fazem disso algo muito interessante.
Se falamos sobre o Go, o Go tem um escopo muito restrito de aplicabilidade, mas, na esteira do hype, todos começaram a escrever sobre ele.
Cada um dos idiomas que eu escolhi representar durante o discurso tem algum tipo de conflito.
Como personagem de uma boa história. E a essência do conflito é que algumas coisas funcionam bem e outras não. Este conflito estará na cabeça do relatório.
- Você acha que precisa escolher seu idioma para cada tarefa, projeto?Essa é uma boa ideia, mas não funciona na prática. Exatamente onde começamos. Existem programadores para Android, existem programadores em Python que, quando você mostra o código Ruby, que é a mesma coisa, apenas no perfil, eles dizem: "Oh não, tudo é incompreensível, não quero entender".
É claro que gostaria que as pessoas fossem mais versáteis e capazes de escolher um instrumento para a tarefa, mas acontece que as pessoas sabem uma coisa e sempre usam essa ferramenta.
O fator de contratação também é adicionado aqui. Por exemplo, em nossa empresa, não podemos escolher entre TypeScript e Python. Mas, se eu precisar contratar um desenvolvedor de Elixir, procurarei por ele a vida toda. Conheço esses desenvolvedores, mas não tanto, e não para que eu possa atraí-los rapidamente para mim. Portanto, você precisa moderar suas ambições e se adaptar ao mercado e aos clientes, que também têm uma pilha limitada de acordo com o mercado.
- Você promete uma visão subjetiva de quase 10 idiomas completamente diferentes. Você está realmente familiarizado com todos eles, escreveu algo sobre todos eles?Com cada um de maneiras diferentes, mas, é claro, eu tentei todos eles pelo menos até certo ponto.
Por exemplo, no Rust, escrevo código-fonte aberto e, no pônei, escrevi 15 linhas de código, li o tutorial, admirei e agora quero mostrar aos participantes da conferência. Para que eles também sejam inspirados pela idéia.
- Obviamente, em um relatório, você não poderá fornecer uma imagem e compreensão completas de cada idioma. Por que as pessoas devem ir ao seu relatório e não pesquisá-lo no Google?O motivo é que, quando uma pessoa viva diz, é completamente diferente. Um relatório, em certa medida, é sempre um show. Quando as pessoas vão ao show, elas recebem não apenas conteúdo, mas também emoções. Quando você pesquisa no Google, você obtém apenas conteúdo. Se você estiver interessado, você fará uma busca no Google de qualquer maneira. E o formato do discurso de uma pessoa viva permite popular e facilmente obter conhecimento interessante.
- Quais serão os principais elementos do seu "show"?Existem muitos idiomas, todos eles são legais, mas não há nada para escrever.
Existem muitos idiomas populares para resolver seus problemas de negócios: contratação, clientes, bibliotecas. Mas todos se tornaram populares por um motivo. Como regra, a principal razão é que eles são muito simples. Eles são baseados em conceitos simples, fáceis de começar, mas difíceis de continuar.
Existem linguagens de nicho e conceitos complexos muito interessantes já estão aparecendo nos quais você pode construir algo grande e confiável: Rust com seu excelente compilador, Elixir com sua máquina virtual absolutamente perfurante, Haskell com seu sistema de tipos, etc. Mas eles não podem se tornar populares apenas por causa do alto limite de entrada.
A maioria dos desenvolvedores que desejam aprender algo usa idiomas populares e escreve para eles. E a questão de por que algo mais pode ser necessário não surge, porque nesses projetos com os quais eles trabalham, nada mais complicado é necessário.
É muito importante para o desenvolvedor entender as limitações da ferramenta.
Para entender a limitação, você precisa descansar na testa, combater um problema e, em seguida, dar um passo atrás e olhá-la à distância. Somente nos relatos de pessoas que trabalham com algo há muitos anos é que isso se manifesta. E conheço bem essas pessoas, acumulei vários casos e sei onde me apoiar. E posso resumir minha experiência e a experiência de outras pessoas.
- Escrever “Hello world” em Haskell já é um grande feito, mas isso não é suficiente?Sim, você precisa ferver na comunidade de funcionários. Para ouvir quais problemas eles resolvem, quais relatórios eles fazem - para que você possa entender a seção.
Por exemplo, na comunidade Haskellist, o problema de entrada é muito agudo. Eles ainda não conseguem resolvê-lo e tornam seu idioma mais amigável para iniciantes. Historicamente, Haskell usa uma sintaxe completamente diferente e regras completamente diferentes, apenas para escrever pelo menos alguma coisa. Mesmo um desenvolvedor experiente, a princípio, não estará totalmente claro o que está acontecendo neste código.
E o problema não está apenas na programação funcional. Se você começar a se familiarizar com as funcionalidades do Elixir, será muito mais fácil. Elixir é muito semelhante em sintaxe ao Ruby. No começo, você não verá a diferença, pode escrever da mesma maneira que no Ruby. E só então fica claro que essa é uma linguagem funcional. Você não percebe isso até algum momento e depois descobre oportunidades adicionais para si mesmo. Você entende que, de fato, é construído sobre princípios completamente diferentes. Conhecendo essa base, torna-se fácil mudar para uma linguagem funcional menos amigável.
A ordem é importante.
- Além das línguas e idiomas populares, como você diz, da segunda série, que é pelo menos até certo ponto ouvida, você apresentará outras completamente desconhecidas. Por exemplo, o que é esse pônei?Pony é uma linguagem de programação de código aberto, orientada a objeto, modelo de ator, segura de recursos e de alto desempenho. Ou seja, fortemente tipado, com memória segura, linguagem do ator. Ele é muito jovem e muito interessante.
Seus desenvolvedores criam uma linguagem na qual você pode criar um número muito grande de atores, como no Elixir, mas esses atores têm garantia de tipo seguro. Os limites de aplicabilidade dessa linguagem ainda são completamente incompreensíveis. Mas eu diria que ele pode acessar o Go, e apoio ativamente tudo o que pode acessar o Go.
- Se todos os idiomas têm deficiências e limitações, o que fazer? O que fazer sobre isso?Sofrer. E continue procurando a excelência técnica. Este é um sonho inatingível para qualquer engenheiro, mas o processo de encontrar essa excelência é um grande objetivo.
Saint AppsConf após 10 dias. O Comitê de Programa selecionou 35 relatórios e 12 reuniões, entre as quais cada desenvolvedor móvel encontrará idéias úteis para resolver problemas do dia a dia e para o desenvolvimento profissional e pessoal. Encontro você nos dias 21 e 22 de outubro em São Petersburgo!
Uma pergunta bônus para quem deseja compartilhar sua experiência, mas, por algum motivo, ainda não se tornou um orador. Você costuma falar, por que precisa e o que o motiva?Eu tenho três objetivos:
- Divirta-se, eu realmente gosto de conferências, é divertido e interessante.
- Local - encontre desenvolvedores e clientes.
- Global - para melhorar nossa indústria . Vejo muitos problemas e quero influenciar positivamente e tirar o mal do mal.
Um palestrante em uma conferência pode influenciar uma indústria através de uma audiência. Ele da tribuna pode provar seu ponto de vista e motivar as pessoas a mudarem.