O primeiro dia, ou melhor, noite do InterCon, foi sensacional. Primeiro tivemos o dinossauro, Maujor, falando sobre acessibilidade e as dificuldades de desenvolver um site acessível.

Quem já se preocupou com isso sabe o quão difícil é desenvolver um site acessível. Existem dificuldades técnicas de desenvolvimento, sim, mas o mais complicado é desenvolver a empatia com o público e suas diferentes necessidades. Existem padrões que podem nos auxiliar, padrões de cores, de movimentos, de sons, etc, mas por mais que ajudem, ainda não são suficientes. Este é o caso em que o usuário realmente é crucial no desenvolvimento.

Segundo o Dino, acessibilidade começa com HTML, quer dizer, HTML 5, semântica, marcação HTML bem feita, estruturada e pensada.
Mas a jornada da acessibilidade vai muito além – precisamos compreender a usabilidade. Se você tentar implementar técnicas de acessibilidade sem ter conhecimentos robustos de usabilidade, é provável que seu site esteja fadado a ser inútil.

Outro ponto importante que Maujor levantou, é que acessibilidade precisa ser pensada desde o início. Sabe a ideia do mobile first, security first, e por ai vai? Então, agora temos o acessibility fisrt. Sim, amigos, precisamos pensar desde o rascunho.

Além disso, Maujor também deu algumas dicas sobre a extensão para navegadores Wave, que é capaz de verificar a acessibilidade do seu site. Ademais, temos um padrão chamado A11Y, que é um tipo de numerômetro de acessibilidade.

Depois de Maujor, foi a vez de Clement Ho, engenheiro front-end do GitLab, falar sobre o poder da iteração. Foi uma palestra que não falou apenas de código, mas até da iteração entre equipes. A ideia principal é que a interação é proposital e intencional. Se você for criar algum tipo de interação, seja na sua equipe ou no seu site, você precisa saber o porquê de estar fazendo isso.

Primeiro ele falou sobre a iteração no projeto. Sabemos que o modelo cascata é algo praticamente morto, e o modelo ágil é o que mais nos baseamos para gerenciar nossos projetos, sejam Scrum, Kanban, Lean, Smart ou Sprint.

E o motivo disso é porque entendemos como funcionam os projetos. Eles são praticamente organismos vivos. Nascem com algum propósito (requisitos) e com os ensinamentos dos pais (clientes), mas ao longo da sua vida são influenciados por muitas outras pessoas (stakeholders do projeto).

Além disso, um projeto realmente cresce como uma criança, ou seja, o desenvolvimento do projeto nunca acontece de primeira. Primeiro vem um passo, depois outro, e um tombo. Assim, incrementalmente vamos adicionando features no projeto. Primeiro ele faz o básico, nosso primeiro entregável, e na sequência outro, e outro. E esse processo leva ao ciclo de vida ágil.

Planejamento, design, build, teste, review, plan…

Isso só nos diz algumas coisas. Nas palavras de Clement: “A iteração é ágil” e “Iteração é uma vantagem competitiva”.

Quando falamos em vantagem competitiva, a primeira vez pode nos parecer estranho. Porém, vantagem competitiva faz total sentido.

Vamos voltar e fazer um paralelo ao modelo cascata. Quando o problema acontecia, todo o projeto estava perdido, porque os erros se tornavam dependentes.

Quando você pensa em iteração no projeto, automaticamente precisa pensar em entrega contínua, e assim, em uma mudança viável mínima (MVC). É muito barato voltar uma feature e continuar com uma solução que funcione do que reconstruir tudo do zero, mas tomar decisões pequenas, pensando sempre a curto prazo pode tornar a entrega final lenta. Entretanto, sacrificar ganhos a curto prazo faz com que sejamos capazes de colher benefícios a longo prazo. Fica a dica, pequeno Padawan.

Se pensarmos em refatoração de código, fica muito simples entender. Se o seu código estiver separado em blocos, é muito mais simples implementar um novo serviço, assim como voltar um serviço. Agora, pensando pelo lado do usuário, temos também um ganho de performance do nosso site, por exemplo. Se carregarmos assincronamente, de acordo com a interação do usuário, tornamos nossa solução uma experiência agradável.

Durante a palestra, Clement deu vários exemplos de como desenvolveram isso dentro do GitLab, e como continuam fazendo. A primeira versão do Git possuía apenas autopublishing, deploy e add imagens snapstho testing. A versão atual já possui componentes, localização, ferramentas para melhorar a contribuição e outras. Até então não havia sido utilizado o danger ou CLI, pois o objetivo era o entregável que pudesse ser completado.

Ao final, o palestrante deixou algumas perguntas para ajudar os desenvolvedores a direcionar seu projeto em relação a iterações.

• Qual o objetivo da sua iteração?
• Como o escopo pode ser mais simples?
• Quais os efeitos colaterais da iteração?
• Sua iteração é facilmente reversível?

Além disso, nosso engenheiro oriental nos deixou mais um ensinamento: é importante ter uma pessoa que seja o owner do projeto, porém, é necessário que todas as pessoas possam interagir/colaborar com o projeto, pois todos veem o mundo de forma diferente. O Gitlab é aberto, então qualquer um pode contribuir com o projeto, estando nele ou não.

Logo após Clement, quem assumiu o palco foi Andreza Leite, falando sobre Model Driven Development, ou MDD (não recomendamos fazer a busca por essa sigla no Google).

Andreza falou da importância do entendimento de “Projeto Vs Modelo”. Quando temos uma sensação de crise em nosso projeto, ela costuma ocorrer pela falta de um modelo condutor. Os modelos nos ajudam a entender melhor a solução que queremos implementar, mas ela falou sobre linguagens de domínio específicas.

Aqui temos uma enorme dificuldade, que é sair de um modelo gráfico e chegar a uma aplicação. Precisamos primeiro compartimentar e dividir essa linguagem. É necessário o desenvolvimento de meta modelos, e é preciso o entendimento de cada elemento do modelo.

O processo do MDD é baseado no seguinte processo: análise, design, implementação e avaliação (opcional).

A palestrante salientou os benefícios deste tipo de solução. O MDD, dado o seu processo de desenvolvimento se torna uma solução mais rápida, principalmente se você desenvolver vários modelos. Quanto mais modelos, menos código é escrito. Quanto menos código, mais rentável e menos pessoas são envolvidas no processo. Mas não se engane, essa metodologia faz com que você precise de profissionais extremamente especializados, principalmente no conhecimento do domínio.

Negócios e área de TI precisam estar mais alinhados do que em soluções comuns. Entretanto, existe um certo benefício para os desenvolvedores. Se você não gosta de se preocupar com regras de negócio, você pode se dar bem aqui. A regra de negócio já é definida, então, quando chega na mão do desenvolvedor, ele pode apenas implementar o código, pois todas as regras já foram muito bem especificadas. Sendo assim, temos softwares menos suscetíveis a erros e temos o modelo servindo de documentação

Mas, como sabemos que não existe bala de prata, nem tudo são flores. O processo em si tende a ser bem rígido e as ferramentas são limitadas. Além disso, o time de requisitos precisa estar muito ciente do que é possível ser realizado, senão o modelo se torna impossível de ser desenhado e implementado.

Ademais, a equipe precisa personalizar a solução, caso o time de requisitos não tenha o conhecimento necessário. O uso de versionamento é algo difícil de se implementar devido ao fato de ser um modelo gráfico e não textual. Como se não fosse o suficiente, você precisa de uma equipe extremamente experiente e que se detenha nas tecnologias disponíveis. A inovação pode distrair – pensar em maneiras diferentes pode emperrar o projeto.

Para fechar a noite, tivemos nada menos do que o criador do PHP, Rasmus Lerdorf. Rasmus começou falando sobre a sua vida, sua cidade natal, história da web e seu desenvolvimento ao longo dos anos. “É muito mais do que o PHP! É para além disso, afinal, LAMP não foi um acidente!”, comentou.

Ele lembrou ainda de como a internet era construída naquela época. “Eu não gostava na época do pessoal das ciências da computação. Eles acreditavam que só quem tem diploma na área poderia construir a internet. Imagina o que seria dela se só doutores, diplomados e coisa e tal pudessem construir a internet?”.

Em seguida, entrou no desenvolvimento da própria linguagem, desde o PHP 5.3 até o PHP 7.3.

Ele abordou as novidades que essa versão deve trazer, como acionar referências à listas, a nova função sobre fpm e a is_countable(). Além de citá-las, ele abordou as melhorias que elas trarão para os desenvolvedores. Outro ponto abordado foram as novas DCEs que a versão trará. Para finalizar sua apresentação, Rasmus salientou como o PHP evolui para se tornar uma linguagem mais escalável, robusta e limpa.