Campus Party BSB 5 - Eu fui! [PT-BR]

(For the English version: link)

Animes, Games e Tecnologia: O que eles tm em comum? Bastante, mas quando mistura tudo voc acaba com caos!
E essa foi minha maior impresso do CPBSB5.

Primeiro eu gostaria de agradecer a Rocketseat pela oportunidade j que ganhei o ingresso deles. Na verdade, mesmo estando aqui em Braslia, eu no fazia ideia de que ia ter o evento. Na sexta anterior eu checando as notificaes do Discord vi que ia ter e que iriam sortear ingressos mesmo nunca ganhando nada eu tentei quando recebi o email confirmando que tinha ganhado eu fiquei surpreso e ansioso, j que seria o primeiro evento do tipo que iria participar.

Mas voltando ao caos, no entenda errado, porque um caos bom. Em um palco se falava sobre crypto e noutro sobre minerao de asteroides. Em um momento estava vendo um contedo extremamente tcnico, virava a cabea e ouvia um som alto, pessoas jogando jogos de dana e outras pessoas andando de cosplay e o Gandalf calmamente acenando em encorajamento (quem sabe, sabe).
Tinha muita coisa e pouco tempo, ento cada um aproveitou o evento da maneira que achou melhor. Eu fiquei pulando de palestra em palestra, outros acho que ficaram jogando e aproveitando a internet super-rpida que ficava disposio, vi muitos em grupos, pessoas em cosplay, pessoas programando, outros fazendo coisas mais manuais e, claro, muita gente movida a miojo, cafena e pouco tempo de sono.

Top Aprendizados (no exaustivo)

Eu me concentrei em palestras de tecnologia e programao e nas horas vagas, aquelas com a chamada mais interessante (dica para quem for fazer um evento que o ttulo das palestras vale bastante!).

No tem como resumir dias de eventos em um texto, mas vou tentar filtrar as coisas mais importantes e tambm adicionar um pouco de minha prpria experincia e pesquisas que fui fazendo sobre os temas.

Uma coisa importante de notar que as palestras tinham entre meia e uma hora, e no importa to bom as pessoas palestrando sejam, no tem como passar muita coisa em um tempo to curto (e olha que teve gente que tentou!).
Ento eu encaro como menos questo de tentar realmente ensinar a fundo um problema e mais de trazer a tona um assunto que fica para voc, ouvinte da palestra de procurar e ir atrs daqueles tpicos que realmente te chamaram a ateno.

Segurana: OWASP Top 10

1. Quebra de Controle de Acesso
2. Falhas Criptogrficas
3. Injeo
4. Design Inseguro
5. Configurao Insegura
6. Componente Desatualizado e Vulnervel
7. Falha de Identificao e Autenticao
8. Falha na Integridade de Dados e Software
9. Monitoramento de Falhas e Registros de Segurana
10. Falsificao de Solicitao do Lado do Servidor

Vi mais de uma palestra onde OWASP e segurana no geral foi o tema de palestras. algo MUITO importante, mas muitas vezes negligenciado. Um bsico talvez aparea no meio de um curso ou vdeo que tenha visto aqui e ali, quem sabe exista um mdulo de segurana, mas o quo profundo realmente o assunto normalmente abordado?

Relacionado ao assunto a diferenciao de autenticao e autorizao.
A maneira mais simples para diferenciar os dois:

• Autenticao: quem voc?
• Autorizao: voc pode estar aqui?

Sabendo disso, podemos voltar ao TOP 1 do OWASP e tomar como padro NEGAR qualquer acesso por padro e depois liberar o acesso de quem for autorizado. E mais do que isso, segmentar o que possvel fazer pelo CRUD (create, read, update, delete), ou seja, acessos diferentes para ler, escrever, atualizar e deletar significaria que fica mais difcil algum simplesmente conseguir acesso total, e se adicionar a isso uma segmentao por rota/feature, ento dificulta ainda mais algum querendo fazer algo que no pode.
Esse um bsico, e claro que existe mais: isso no vale apenas para pessoas, mas para mquinas tambm, seu servidor precisa ter todos esses arquivos ali? Deixar arquivos de versionamento, de environment e muitos outros simplesmente jogados l, mesmo que normalmente no se tem acesso, se algum adivinhar que existe um .env l e que o servidor usado simplesmente serve o que existe, ento s questo de tempo at um problema acontecer...
E falando nisso, como esto os logs de acesso? Voc tem logs certo?
No? Como vai saber se existe gente tentando acessar o seu servidor ento? Como vai saber quando realmente entraram e o que fizeram l? Ou ento, se j no entraram e fizeram alguma coisa?
Sem nenhum limite, literalmente s questo de tempo at conseguir acesso, e embora no corrija o problema, colocar limites de acesso pode pelo menos diminuir o estrago causado.
Seja para limitar acesso a um servidor ou login a uma aplicao, uma das estratgias impor um tempo de backoff entre tentativas. Quanto mais voc erra, mais tempo precisa esperar entre novas tentativas.
J indo agora para o mundo frontend, erros acontecem, mas necessrio um equilbrio entre erros que ajudam o usurio e genricos o suficiente que no exponham informao que no deveriam.

No exemplo, o erro ajuda? Sim? voc sabe por que houve o erro, no entanto muita informao.
O caso clssico no meme o de voltar email OU password incorretos ou mesmo quando se tenta recuperar uma senha, mostrado apenas que foi enviado email para recuperar senha independente do email estar cadastrado ou no. Isso porque apenas saber que um email est cadastrado j muita informao.
Ao mesmo tempo, um erro muito genrico oops, houve um erro! genrico demais e no ajuda o usurio... foi erro dele? Problema no servidor? Nisso, parte responsabilidade de quem faz o backend de devolver status HTTP corretos e do frontend de usar isso para mostrar algo que ajude. E a, sabe de cabea pelo menos o que cada faixa de status codes faz?

Outro ponto de segurana a quantidade de informao transitada e neste caso, quanto menos melhor. comum ver um cadastro que deveria ser simples, no entanto se estende por pginas e pginas perguntando coisas que no precisa saber.
E claro que depois, para mostrar tudo isso, so necessrias mais pginas ou ento... tabelas para mostrar tudo isso.
E como estamos na internet, lembrar da criptografia, ou seja, o cadeado que significa que tudo transitado com TLS e mesmo se algum tentar espiar no que est sendo transmitido, no vai ter acesso aos dados trafegados.
E se no fosse o bastante... se proteger mesmo de quem estiver autenticado e autorizado! Validar e sanitizar todos os inputs de usurios para evitar que qualquer coisa potencialmente danosa (Top 3: Injeo).
Finalmente, lembrar que mais do que s escrever cdigo, usamos bastante cdigo de outras pessoas. Ento o mnimo manter tudo atualizado nas verses de patch. Ou mesmo abandonar verses que no so mais ativamente suportadas.

Design, Dados e Experiencias de Usurio

Seja um frontend ou slides de uma apresentao, saber mostrar uma informao mais do que simplesmente jogar um monte de nmeros e letras na tela.
Para criar uma boa experiencia, primeiro essencial investigar os dados.
Olhe a imagem abaixo e tente responder: quantas cores existem aqui? Qual tem mais peas?

Diferentes experincias chamam por diferentes apresentaes, ento necessrio saber com o que est lidando para poder utilizar a melhor visualizao para o que se quer mostrar.
No caso de apresentao de dados, importante no s jogar os dados na tela, mas explicar o que cada um, assim como um ttulo para grficos e fontes.
Finalmente, contextualizar o que significa os dados j que voc sabe o que est sendo mostrado e os outros talvez no saibam. No s isso, sem essa contextualizao, no tem como saber se o que est sendo apresentado bom ou ruim.
Agora, com a contextualizao e mesmo explicaes de fatos relevantes possvel resumir muita informao em apenas uma imagem que realmente pode viver o ditado de uma imagem vale mais de 1000 palavras.
E a resposta para perguntas l em cima?

No somos bons com dados jogados, eles simplesmente no funcionam para ns. Uma pequena classificao j ajuda, mas ainda assim no mostra tudo.
Uma vez que os dados so organizados j possvel ver alguma coisa, mas para facilitar o consumo dessa informao, saber apresentar visualmente necessrio.
A pergunta que fica : quando percebeu que existe uma pea cinza?

O que leva para uma parte mais de design e UX (experiencia de usurio): O cliente tem sempre razo, mas ser que isso mesmo?
Mais do que o cliente, quem programa precisa pensar no no cliente e sim no USURIO!
Minha experincia que, se eu simplesmente dissesse sim para o que meus clientes acham que querem, eu faria um monte de planilha de Excel, s que no navegador.
S porque o que o cliente quer, no significa que o que o usurio precisa ou o que vai gerar mais valor para ele (e as vezes para o prprio cliente!).
Ento a ideia no pensar no cliente e sim: O usurio tem sempre razo. O que significa que a culpa no do usurio no saber usar, e sim da pessoa que fez o design de conhecer quem so seus usurios, suas limitaes e fazer algo que seu usurio possa j sair usando.
Assim como com cdigo que fazemos. Se algum vem e te diz que o cdigo est confuso, no adianta explicar para a pessoa ou colocar alguns comentrios, o necessrio refatorar o cdigo para que a dvida no exista. ( um pouco exagero, sim, mas no geral bom sempre tentar refazer de uma maneira que minimize qualquer dvida do que tentar explicar/comentar, o que deveria ser apenas um ltimo recurso.)
E ento entra as 10 heursticas de Nielsen (s procurar e ler mais sobre o assunto):

1. Visibilidade do status do sistema
2. Correspondncia entre o sistema e o mundo real,
3. Controle e liberdade do usurio,
4. Consistncias e padres,
5. Preveno de erros,
6. Reconhecimento ao invs de memria,
7. Flexibilidade e eficincia de uso,
8. Esttica e design minimalista, 9
9. Recuperao diante de erros,
10. Ajuda e documentao

Seja frontend ou como mostrar uma informao em um slide, necessrio testes, refatorao e reiteraes. totalmente ok comear com algo mais simples, e conforme consegue feedback, ir melhorando o design e mesmo antes de entregar, as vezes necessrio testar vrias abordagens para validar qual a melhor para dada situao.
Para quem no designer, ou quando est no meio das coisas, as vezes exageramos muito e sequer percebemos, ento necessrio dar uma respirada, olhar outra coisa e ento voltar para ver a baguna que fizemos com a cabea limpa.
Algumas dicas para esttica foram:

• Cores: 60 / 30 / 10Isso sobre as cores: 60% cores neutras, 30% de cor principal e 10% de cor de destaque.
• Hierarquia visualOu seja, destaque apenas para o que for mais importante e mais destaque para coisas mais importantes.
• Whitespace (espao em branco)No caso, no literalmente um espao em branco, mas sim que as coisas tenham espao de suas margens para respirar e no ficar tudo abarrotado.

Independente de haver ou no a disponibilidade de um designer, planejar antes de pr a mo na massa! O famoso mea duas vezes antes de cortar.
E mesmo depois de jogar em produo, deixar um campo de feedback para que os usurios possam te dizer o que est bom e o que est ruim. Nem todos vo, na verdade apenas uma pequena minoria vai dar o feedback, e normalmente quando algo est muito ruim..., mas uma ferramenta para conseguir melhorar sempre o design.

Sobre liderana, senioridade e tcnicas

Perguntaram sobre o soft e hard skill. E uma coisa que disseram foi que ns programadores, muito do que fazermos tudo soft skill.

• Soft X Hard skillHard skill tudo o que sempre feito da mesma maneira. Em outras palavras o uso de ferramentas.No caso de programao, uma linguagem ou framework um hard skill que precisa de tcnica e prtica.No entanto, programao em si uma soft skill, porque tudo depende.
• DependeExistem diversos nveis em programao e talvez possvel medir esse nvel pelo depende.Um jnior tem uma base menor, ento embora saiba fazer, acaba naquela de que quando s se tem um martelo, todos os problemas so tratados como se fossem pregos. Neste caso o depende apenas se tem e como martelar esse problema.Algum pleno j deveria ter uma base melhor, mas ainda sim seu depende limitado nas opes que consegue por em prtica para resolver o problema.Algum snior, no limitado s pelo que sabe, porque aprender uma hard skill algo que deveria ser trivial. Saber que a possibilidade existe e se aplicvel uma das soft skills do snior e mais do que isso, muitas vezes o depende relacionado ao que o cliente quer ou o que o usurio precisa.E depois do snior, o depende deveria morrer! Todo mundo sabe que depende e por isso escolher o caminho a ser seguido para resolver o problema fica a cargo dessa pessoa que transcendeu o snior. E essa escolha no precisa sequer ser a soluo perfeita porque dependendo do problema, esperar por uma soluo perfeita a escolha errada.Inclusive, outro ponto o de trabalhar com outros e neste caso, vrias pessoas geram vrias ideias e ento entra o discordar e se comprometer, mesmo no sendo a soluo que queria, uma vez que o martelo batido, ento todos se comprometem a fazer a soluo escolhida funcionar.

Mas e o que vem depois do snior?
Nem todo mundo quer ser lder, mas todos podem aprender uma coisa ou outra.
A parte de hard skill um mnimo, mas no de todo necessrio. Um erro comum e algo que no existe soluo faz tempo o de colocar em cargos de liderana algum que bom apenas tecnicamente.
Ao fazer isso voc pode perder algum bom tecnicamente e faz uma aposta onde voc pode acabar com qualquer coisa entre um timo e um pssimo lder, mas que mesmo um lder ok uma perda.
Existe sempre a questo se a pessoa quer isso ou no e algo que pode ser treinado, mas um erro pensar ou ter como nica alternativa virar gerente para crescer.

Mas para quem quer aprender sobre isso, mesmo sem ser algo oficial, os pilares da liderana so a mentalidade, os resultados e os relacionamentos.
Influenciar as pessoas (no bom sentido), te ajuda a ter mais espao e voz. E quando voc busca as relaes ganha-ganha, ento voc gera valor mesmo que os outros no vejam dessa maneira em um primeiro momento.
Para isso, necessrio saber como trabalhar em equipe. E no adianta simplesmente esperar que cada um faa sua parte, mas usar da influncia para que as coisas realmente aconteam. E para isso, a confiana essencial (por isso nunca prometa nada! Comunique e entregue sem prometer: possvel sim!) mas sempre trate as pessoas bem, independente do que acha delas.