This content originally appeared on DEV Community and was authored by Bruno Noriller
(For the English version: link)
Animes, Games e Tecnologia: O que eles têm em comum? Bastante, mas quando mistura tudo você acaba com caos!
E essa foi minha maior impressão do CPBSB5.
Primeiro eu gostaria de agradecer a Rocketseat pela oportunidade já que ganhei o ingresso deles. Na verdade, mesmo estando aqui em Brasília, eu não fazia ideia de que ia ter o evento. Na sexta anterior eu checando as notificações 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, não entenda errado, porque é um caos bom. Em um palco se falava sobre crypto e noutro sobre mineração de asteroides. Em um momento estava vendo um conteúdo extremamente técnico, virava a cabeça e ouvia um som alto, pessoas jogando jogos de dança e outras pessoas andando de cosplay e o Gandalf calmamente acenando em encorajamento (quem sabe, sabe).
Tinha muita coisa e pouco tempo, então 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-rápida que ficava à disposição, vi muitos em grupos, pessoas em cosplay, pessoas programando, outros fazendo coisas mais manuais e, é claro, muita gente movida a miojo, cafeína e pouco tempo de sono.
Top Aprendizados (não exaustivo)
Eu me concentrei em palestras de tecnologia e programação e nas horas “vagas”, aquelas com a chamada mais interessante (dica para quem for fazer um evento é que o título das palestras vale bastante!).
Não tem como resumir dias de eventos em um texto, mas vou tentar filtrar as coisas mais importantes e também adicionar um pouco de minha própria experiência e pesquisas que fui fazendo sobre os temas.
Uma coisa importante de notar é que as palestras tinham entre meia e uma hora, e não importa tão bom as pessoas palestrando sejam, não tem como passar muita coisa em um tempo tão curto (e olha que teve gente que tentou!).
Então eu encaro como menos questão 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 atrás daqueles tópicos que realmente te chamaram a atenção.
Segurança: OWASP Top 10
- Quebra de Controle de Acesso
- Falhas Criptográficas
- Injeção
- Design Inseguro
- Configuração Insegura
- Componente Desatualizado e Vulnerável
- Falha de Identificação e Autenticação
- Falha na Integridade de Dados e Software
- Monitoramento de Falhas e Registros de Segurança
- Falsificação de Solicitação do Lado do Servidor
Vi mais de uma palestra onde OWASP e segurança no geral foi o tema de palestras. É algo MUITO importante, mas muitas vezes negligenciado. Um básico talvez apareça no meio de um curso ou vídeo que tenha visto aqui e ali, quem sabe exista um “módulo” de segurança, mas o quão profundo realmente o assunto normalmente é abordado?
Relacionado ao assunto é a diferenciação de “autenticação” e “autorização”.
A maneira mais simples para diferenciar os dois:
- Autenticação: quem é você?
- Autorização: você pode estar aqui?
Sabendo disso, podemos voltar ao TOP 1 do OWASP e tomar como padrão NEGAR qualquer acesso por padrão e depois liberar o acesso de quem for autorizado. E mais do que isso, segmentar o que é possível fazer pelo CRUD (create, read, update, delete), ou seja, acessos diferentes para ler, escrever, atualizar e deletar significaria que fica mais difícil alguém simplesmente conseguir acesso total, e se adicionar a isso uma segmentação por rota/feature, então dificulta ainda mais alguém querendo fazer algo que não pode.
Esse é um básico, e é claro que existe mais: isso não vale apenas para pessoas, mas para máquinas também, seu servidor precisa ter todos esses arquivos ali? Deixar arquivos de versionamento, de environment e muitos outros simplesmente “jogados” lá, mesmo que “normalmente” não se tem acesso, se alguém adivinhar que existe um “.env” lá e que o servidor usado simplesmente serve o que existe, então é só questão de tempo até um problema acontecer...
E falando nisso, como estão os logs de acesso? Você tem logs certo?
Não? Como vai saber se existe gente tentando acessar o seu servidor então? Como vai saber quando realmente entraram e o que fizeram lá? Ou então, se já não entraram e fizeram alguma coisa?
Sem nenhum limite, é literalmente só questão de tempo até conseguir acesso, e embora não 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 aplicação, uma das estratégias é 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 é necessário um equilíbrio entre erros que ajudam o usuário e genéricos o suficiente que não exponham informação que não deveriam.
No exemplo, o erro ajuda? Sim? você sabe por que houve o erro, no entanto é muita informação.
O caso clássico não 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 não. Isso porque apenas saber que um email está cadastrado já é muita informação.
Ao mesmo tempo, um erro muito genérico “oops, houve um erro!” é genérico demais e não ajuda o usuário... 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 cabeça pelo menos o que cada faixa de status codes faz?
Outro ponto de segurança é a quantidade de informação transitada e neste caso, quanto menos melhor. É comum ver um cadastro que deveria ser simples, no entanto se estende por páginas e páginas perguntando coisas que não precisa saber.
E é claro que depois, para mostrar tudo isso, são necessárias mais páginas ou então... 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 alguém tentar espiar no que está sendo transmitido, não vai ter acesso aos dados trafegados.
E se não fosse o bastante... se proteger mesmo de quem estiver autenticado e autorizado! Validar e sanitizar todos os inputs de usuários para evitar que qualquer coisa potencialmente danosa (Top 3: Injeção).
Finalmente, lembrar que mais do que só escrever código, usamos bastante código de outras pessoas. Então o mínimo é manter tudo atualizado nas versões de patch. Ou mesmo abandonar versões que não são mais ativamente suportadas.
Design, Dados e Experiencias de Usuário
Seja um frontend ou slides de uma apresentação, saber mostrar uma informação é mais do que simplesmente jogar um monte de números 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 peças?
Diferentes experiências chamam por diferentes apresentações, então é necessário saber com o que está lidando para poder utilizar a melhor visualização para o que se quer mostrar.
No caso de apresentação de dados, é importante não só jogar os dados na tela, mas explicar o que é cada um, assim como um título para gráficos e fontes.
Finalmente, contextualizar o que significa os dados já que você sabe o que está sendo mostrado e os outros talvez não saibam. Não só isso, sem essa contextualização, não tem como saber se o que está sendo apresentado é bom ou ruim.
Agora, com a contextualização e mesmo explicações de fatos relevantes é possível resumir muita informação 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?
Não somos bons com dados jogados, eles simplesmente não funcionam para nós. Uma pequena classificação já ajuda, mas ainda assim não mostra tudo.
Uma vez que os dados são organizados já é possível ver alguma coisa, mas para facilitar o consumo dessa informação, saber apresentar visualmente é necessário.
A pergunta que fica é: quando percebeu que existe uma peça cinza?
O que leva para uma parte mais de design e UX (experiencia de usuário): “O cliente tem sempre razão”, mas será que é isso mesmo?
Mais do que o cliente, quem programa precisa pensar não no cliente e sim no USUÁRIO!
Minha experiência é 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, não significa que é o que o usuário precisa ou o que vai gerar mais valor para ele (e as vezes para o próprio cliente!).
Então a ideia é não pensar no “cliente” e sim: “O usuário tem sempre razão”. O que significa que a culpa não é do usuário não saber usar, e sim da pessoa que fez o design de conhecer quem são seus usuários, suas limitações e fazer algo que seu usuário possa já sair usando.
Assim como com código que fazemos. Se alguém vem e te diz que o código está confuso, não adianta explicar para a pessoa ou colocar alguns comentários, o necessário é refatorar o código para que a dúvida não exista. (É um pouco exagero, sim, mas no geral é bom sempre tentar refazer de uma maneira que minimize qualquer dúvida do que tentar explicar/comentar, o que deveria ser apenas um “último recurso”.)
E então entra as 10 heurísticas de Nielsen (só procurar e ler mais sobre o assunto):
- Visibilidade do status do sistema
- Correspondência entre o sistema e o mundo real,
- Controle e liberdade do usuário,
- Consistências e padrões,
- Prevenção de erros,
- Reconhecimento ao invés de memória,
- Flexibilidade e eficiẽncia de uso,
- Estética e design minimalista, 9
- Recuperação diante de erros,
- Ajuda e documentação
Seja frontend ou como mostrar uma informação em um slide, é necessário testes, refatoração e reiterações. É totalmente ok começar com algo mais simples, e conforme consegue feedback, ir melhorando o design e mesmo antes de “entregar”, as vezes é necessário testar várias abordagens para validar qual é a melhor para dada situação.
Para quem não é designer, ou quando está no meio das coisas, as vezes exageramos muito e sequer percebemos, então é necessário dar uma respirada, olhar outra coisa e então voltar para ver a bagunça que fizemos com a cabeça limpa.
Algumas dicas para estética foram:
- Cores: 60 / 30 / 10 Isso é sobre as cores: 60% cores neutras, 30% de cor principal e 10% de cor de destaque.
- Hierarquia visual Ou seja, destaque apenas para o que for mais importante e mais destaque para coisas mais importantes.
- Whitespace (espaço em “branco”) No caso, não literalmente um espaço em branco, mas sim que as coisas tenham espaço de suas margens para “respirar” e não ficar tudo “abarrotado”.
Independente de haver ou não a disponibilidade de um designer, planejar antes de pôr a “mão na massa”! O famoso “meça duas vezes antes de cortar”.
E mesmo depois de jogar em produção, deixar um campo de feedback para que os usuários possam te dizer o que está bom e o que está ruim. Nem todos vão, 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 liderança, senioridade e técnicas
Perguntaram sobre o “soft” e “hard” skill. E uma coisa que disseram foi que nós programadores, muito do que fazermos é tudo “soft” skill.
- Soft X Hard skill “Hard” skill é tudo o que é sempre feito da mesma maneira. Em outras palavras o uso de ferramentas. No caso de programação, uma linguagem ou framework é um hard skill que precisa de técnica e prática. No entanto, programação em si é uma “soft” skill, porque tudo “depende”.
- “Depende” Existem diversos níveis em programação e talvez é possível medir esse nível pelo “depende”. Um júnior tem uma base menor, então embora saiba fazer, acaba naquela de que “quando só se tem um martelo, todos os problemas são tratados como se fossem pregos”. Neste caso o “depende” é apenas se tem e como martelar esse problema. Alguém pleno já deveria ter uma base melhor, mas ainda sim seu “depende” é limitado nas opções que consegue por em prática para resolver o problema. Alguém sênior, não é limitado só pelo que sabe, porque aprender uma “hard” skill é algo que deveria ser trivial. Saber que a possibilidade existe e se é aplicável é uma das “soft” skills do sênior e mais do que isso, muitas vezes o “depende” é relacionado ao que o cliente quer ou o que o usuário precisa. E depois do sênior, 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 “sênior”. E essa escolha não precisa sequer ser a solução perfeita porque dependendo do problema, esperar por uma solução perfeita é a escolha errada. Inclusive, outro ponto é o de trabalhar com outros e neste caso, várias pessoas geram várias ideias e então entra o “discordar e se comprometer”, mesmo não sendo a solução que queria, uma vez que o martelo é batido, então todos se comprometem a fazer a solução escolhida funcionar.
Mas e o que vem depois do sênior?
Nem todo mundo quer ser líder, mas todos podem aprender uma coisa ou outra.
A parte de hard skill é um mínimo, mas não é de todo necessário. Um erro comum e algo que não existe solução faz tempo é o de colocar em cargos de liderança alguém que é bom apenas tecnicamente.
Ao fazer isso você pode perder alguém bom tecnicamente e faz uma aposta onde você pode acabar com qualquer coisa entre um ótimo e um péssimo líder, mas que mesmo um líder “ok” é uma perda.
Existe sempre a questão se a pessoa quer isso ou não 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 liderança são a mentalidade, os resultados e os relacionamentos.
Influenciar as pessoas (no bom sentido), te ajuda a ter mais espaço e voz. E quando você busca as relações ganha-ganha, então você gera valor mesmo que os outros não vejam dessa maneira em um primeiro momento.
Para isso, é necessário saber como trabalhar em equipe. E não adianta simplesmente esperar que cada um faça sua parte, mas usar da influência para que as coisas realmente aconteçam. E para isso, a confiança é essencial (por isso nunca prometa nada! Comunique e entregue sem prometer: é possível sim!) mas sempre trate as pessoas bem, independente do que acha delas.
This content originally appeared on DEV Community and was authored by Bruno Noriller
Bruno Noriller | Sciencx (2023-04-15T17:10:11+00:00) Campus Party BSB 5 – Eu fui! [PT-BR]. Retrieved from https://www.scien.cx/2023/04/15/campus-party-bsb-5-eu-fui-pt-br/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.