DEV Community: Hiago Brenha

Afinal, o que é Stack Overflow?

Hiago Brenha — Thu, 24 Nov 2022 23:07:43 +0000

Se você ta lendo isso aqui, eu tenho 99,9% de certeza que em algum momento o StackOverflow acabou salvando sua manhã, tarde ou madrugada e tudo que eu posso dizer pra você sobre isso é: Seja muito bem vindo ao clube.

Mas você já se questionou de onde veio o nome StackOverflow ou o que ele significa? Eu já, nos primórdios dos meus estudos com programação aonde eu gastava mais tempo lendo e relendo tópicos nesta plataforma do que realmente escrevendo código.

Esse questionamento me voltou a mente em uma conversa com alguns amigos que utilizam o site todo santo dia, sendo até mesmo muito ativos dentro da comunidade mas que não fazem ideia do que é um Stack Overflow.

Call Stack

O Call Stack tem um trabalho simples e extremamente importante, orientando em aonde estamos no código para que possamos rodar aquelas instruções na ordem correta para que tudo funcione como o planejado.

De uma outra forma, pense nele como literalmente uma pilha com a ordem de chamada das funções do seu código. Um espaço na memória que vai armazenar as funções que você chama no seu código, adicionando um novo item ao topo da pilha sempre que você chama uma nova função e removendo este ao término da sua execução.

E agora, o questionamento que talvez você esteja se fazendo é o que acontece no caso de uma função chamar outra. Isso é bem simples se seguirmos o que já foi explicado, a função que foi chamada vai novamente para o topo da pilha e passa a ser executada, sendo retirada e dando lugar a próxima assim que terminar e assim sucessivamente. Acho que já deu pra entender né?

Stack Overflow

Podemos resumir ele como sendo um problema causado por chamar várias e várias funções uma dentro da outra, aumentando em muito o tamanho da nossa Call Stack, até o momento em que o nosso código acaba por se quebrar.

Acredite ou não, isso é surpreendentemente fácil de se fazer com uma recursão não muito bem pensada ou coisas parecidas, como exemplicado a seguir:

function inception(){
    inception()
}

incepetion()

Como da pra imaginar, essa função vai ficar se chamando infinitamente, aumentando o tamanho da Call Stack até essa acabar quebrando e nos retornando um Uncaught RangeError: Maximum call stack size exceeded.

Uma coisa interessante é que antigamente os navegadores não tinham esse erro, eles simplesmente rodavam o código infinitamente até eventualmente crashar completamente, muitas vezes até mesmo travando o computador do usuário. Esse erro surgiu para evitar esse tipo de problema.

Resumindo, o Stack Overflow nada mais é do que colocar carga demais em uma Call Stack, fazendo com que a mesma acabe quebrando.

E com essa leitura você acabou de adquirir um conhecimento para puxar aleatoriamente em uma call com seus colegas enquanto espera o ambiente de desenvolvimento carregar ou quando fica um silêncio na hora do build.

O JavaScript não é seguro...

Hiago Brenha — Mon, 12 Sep 2022 22:11:37 +0000

Recentemente Douglas Cockford, criador do JSON fez um pronunciamento bem interessante.

A melhor coisa que podemos fazer hoje ao JavaScript é aposentá-lo

Ele segue por uma linha que se encaminha para o lado da evolução da linguagem e como isso ficou complicado devido a como a linguagem está inflando cada vez mais e consequentemente se tornando mais difícil de corrigir em sua base.

É um ponto interessante e com toda certeza muito importante a ser abordado e levado a frente, no entanto, o que me chamou atenção foi outra coisa, uma que estava nos comentários: segurança.

Um contexto geral.

O JavaScript tem um grande objeto global que você provavelmente já usou bastante, o Window. Basicamente, podemos dizer que todo código está rodando no mesmo lugar o tempo inteiro, o que torna esse código vulnerável a qualquer tipo de extensão maliciosa, já que a mesma pode acessar dados sensíveis e alterar comportamentos sem dificuldade, por estar rodando no mesmo lugar.

Esse "recurso" é interessante por permitir coisas que muitas vezes são utilizadas por biblitocas, sendo o exemplo mais famoso o JQuery que insere algumas coisas diretamente no objeto global. Por outro lado, permite que você altere o comportamento padrão de algumas funções nativas do JavaScript e isso pode ser um problema de segurança.

Podemos até mesmo estender esse assunto para a gigante maleabilidade do JS, que também leva a falta de segurança. Isso, todavia, já tem uma solução que é amplamente conhecida e até mesmo utilizada, o TypeScript.

Uma nova linguagem

Segundo o Crockford, temos falhas no JavaScript que não podem ser corrigidas e o inchaço nas funcionalidades saiu de controle já que a linguagem está em constante evolução ao invés de constante melhoria em sua base, o que torna uma melhoria ainda mais complicada.

O pai da extensão do JS, sugere uma nova linguagem chamada E, uma criação conjunta entre o próprio CrockFord e alguns outros integrantes. Este seria uma linguagem orientada a objetos e planejada para tornar a computação mais segura.

Entretanto, sejamos realistas aqui. Essa mudança parece um pouco grande demais para vir assim do nada, principalmente se pensarmos que literalmente todos os navegadores usam o JS para a manipulação da DOM. Mudar isso seria um grande problema e seria uma mudança de longo prazo.

Como o próprio Crockford admitiu, ele nem sequer tem a linguagem pronta ainda e sua concepção é bem complexa e provavelmente vai demorar para termos algo concreto para podermos testar. Além disso, as empresas e desenvolvedores precisariam tomar a iniciativa de começar a aprender a linguagem e implementar ela em suas aplicações, o que me parece uma manobra arriscada visto que a princípio, seria uma linguagem com poucos recursos, bibliotecas e uma comunidade muito pequena.

E então?

Olha, eu concordo que tem muitas coisas contra o JavaScript, porém, ele tem um ponto muito forte e que provavelmente é o que eu mais gosto na linguagem, sua comunidade incrível e extremamente prestativa.

Eu acompanho bastante os grupos da ECMA e um que estou de olho é o TC39, isso por conta de um de seus membros chamado Leo Balter, o qual acompanho desde antes de decidir qual área de programação eu iria seguir.

Entre as propostas do TC39 nós temos Decorators, algumas melhorias para o Locale, melhoras para os arrays e por ai vai. Entre todas essas ideias uma fez meus olhos brilharem ao bater o olho, o ShadowRealm.

ShadowRealm

O que este chuchuzinho aqui faz é basicamente criar um contexto que tem seu próprio objeto global que não a Window, e com isso, funciona sem compartilha recursos de forma global com outras partes da aplicação. É como se separássemos o código do restante.

Usando o exemplo que é proposto dentro da própria publicação do Balter:

const sr = new ShadowRealm();

// Sets a new global within the ShadowRealm only
sr.evaluate('globalThis.x = "my shadowRealm"');

globalThis.x = "root"; //

const srx = sr.evaluate('globalThis.x');

srx; // "my shadowRealm"
x; // "root"

Nesse código, nós criamos a propriedade x tanto dentro quanto fora do ShadowRealm (sr), ambos com valores diferentes, e podemos ver que ambos estão completamente isolados um do outro.

Uma limitação interessante e que é importante ser pontuada é que o SR consegue apenas transportar dados primitivos (String, Number, BigInt, Symbol, Boolean, undefined e null). Outros tipos como objetos ou arrays não são permitidos. Isso é importante quando pensamos em manter a separação total dos ambientes já que objetos e arrays carregam referências do local aonde são criados.

Ainda assim, podemos contornar esse problema com outro recurso muito interessante do ShadowRealm. Ele consegue compartilhar funções e valores retornados por essas funções, como no exemplo abaixo:

const sr = new ShadowRealm();

const wrappedFn = sr.evaluate('(x) =; globalThis.foo = x');

wrappedFn(42);

globalThis.foo; // undefined

sr.evaluate('globalThis.foo'); // 42

Não quero me extender demais nisso então vou deixar aqui o link para o post original dos autores do ShadowRealm. Vale a pena dar uma boa olhada nele e no Github da proposta

No final das contas...

O JavaScript tem seus problemas, isso é fato. É uma linguagem dinâmica até demais muitas vezes e acaba ficando confusa de tantas funções que possui, sendo algumas bem desnecessárias. Não é um exemplo de segurança também.

No entanto, acho improvável que essa linguagem seja simplesmente abandonada agora. É a linguagem mais popular segundo a pesquisa realizada pelo StackOverflow e é extremamente utilizada na Web já que é o padrão para manipular a DOM.

Com isso em mente, é importante olhar para o que temos e tentar trabalhar em cima disso. O ShadowRealm é um exemplo excelente de como a linguagem pode sim melhorar e se tornar muito mais agradável no quesito de segurança.

Além disso, muito do que se trata de segurança parte de nós como os desenvolvedores. Querendo ou não é nossa responsabilidade estudar tanto quanto possível a parte de segurança da informação para saber como lidar com os dados dos nossos usuários.

O código que mandamos para o usuário é código perdido, já está na maquina dele e ele pode fazer o que quiser com isso e ter outra linguagem não muda esse fato. Cabe a você como programador, saber contornar esse problema e controlar o máximo possível o que o usuário vai ter acesso.

Devo aprender mais de uma linguagem de programação ?

Hiago Brenha — Wed, 24 Aug 2022 03:59:19 +0000

Vou ser direto e reto: eu pessoalmente acredito que sim, todos programadores independentemente da area de atuação, seja web, software, mobile ou qualquer outra, deveria sim saber pelo menos uma linguagem de programação que não a sua "principal" linguagem, isso além de acrescentar em repertório também vai ajudar em muito seu desempenho com sua linguagem "principal". Mas vamos com calma para que eu possa explicar meu ponto.

A tecnologia está sempre mudando

Quando começamos a programar acabamos desenvolvendo um certo afeto por alguma linguagem em específico e investimos completamente nosso tempo de aprendizado nela, o que aumenta ainda mais este vinculo entre o programador e a linguagem. Pode ser a primeira que você resolveu aprender, a mais simples pra você, ou a que acabou por sanar melhor suas necessidades e gostos, todos temos essa linguagem que acaba se encaixando melhor a nós.

Porém, todos sabemos que não existe uma tecnologia que seja bala de prata, ou seja, que consiga solucionar todo e qualquer problema, diferentes linguagens tem diferentes propósitos e servem a diferentes fins e a história nos mostra isso muito bem.

A não muito tempo as aplicações web eram em sua grande maioria feitas utilizando PHP com seu back-end, uma stack que era conhecida como LAMP (Linux, Apache, MySQL, PHP), porém com o tempo Django e Flask começaram a se tornar bem populares e então o "P" começou a fazer referencia a Python e não mais a PHP. O JavaScript que até esse ponto servia apenas como uma linguagem utilizada dentro dos navegadores para fazer interações simples, agora poderia ser usado no Back-end com o Node.js e com isso surgem novas stacks e os desenvolvedores precisam novamente se adaptar e começar a dar atenção a este novo mercado.

Agora vendo esses pontos durante a história e o mercado atual podemos ver que nenhuma dessas tecnologias sumiu, elas continuam aqui, isso porque servem diferentes propósitos e são úteis de diferentes maneiras. O JavaScript é muito versátil e permite construir uma aplicação inteira usando somente uma linguagem, o PHP é prático e pode ser usado de forma versátil na maioria das hospedagens sendo assim ótimo para projetos mais simples e ainda assim podendo ser usado em projetos mais complexos, já o Python com o Django ou o Flask é capaz de produzir aplicações altamente escaláveis de uma forma bem simples dado o poder de processamento da linguagem.

Ser um especialista

O argumento que mais vejo sendo usado contra a ideia de ser um desenvolvedor poliglota é que para aprender mais de uma linguagem é necessário pagar o alto preço de não ser um "expert" na sua linguagem principal. Muitas pessoas acreditam veementemente que aprender outra linguagem seria perder tempo que poderia ser usado aprimorando a sua favorita, e isso faria de você menos capacitado com sua linguagem principal para ter uma segunda que poderia acabar não sendo tão útil.

Nesse momento você espera que eu discorde, porém não é bem assim, eu não concordo mas não discordo completamente. Realmente, você está colocando esse tempo que poderia ser usado melhorando sua linguagem mais usada em outra que talvez não seja tão necessária, entretanto, eu como atleta que já praticou diversos esportes vejo que praticar um deles te ajuda muito em outro. Antes de começar com o Karate, eu joguei futebol por mais ou menos 5 anos e por conta disso além de uma alta resistencia fisica eu ganhei muita força nas pernas que me foi extremamente útil como artista marcial.

Olhando programação com o mesmo ponto de vista, eu como desenvolvedor JavaScript tive uma melhora muito grande no meu conhecimento de estruturas de dados, memória e algoritmos quando decidi aprender Python já que esta linguagem trabalha muito melhor com essas coisas e graças a isso minhas aplicações desenvolvidas com JavaScript tiveram uma melhora impressionante na sua velocidade de resposta e na sua arquitetura, foi um tempo extremamente bem investido.

Novos horizontes

Eu sou um defensor da ideia de olhar para a mesma coisa utilizando vários pontos de vista, é algo bem positivo e que em geral só tem a acrescentar, e aprender outra linguagem é algo que certamente traz isso para você.

Quando apenas temos uma linguagem em nossa caixinha de ferramentas temos nosso campo de visão limitado ao que aquela linguagem consegue fazer e se propõe a fazer e isso faz com que certos projetos ou certas atividades aparentem ser muito mais dificeis do que realmente são.

Vamos olhar, por exemplo, para o ASP.NET Core, eu comecei a aprender programação através do C# e minha entrada no mundo do desenvolvimento Web foi com este simpático framework. Por mais que seja muito eficiente, tenha uma extensibilidade ótima, te dê um alto controle sobre o HTML e o HTTP, tenha uma ótima testabilidade e um excelente sistema de rotas, além, é claro, dos incriveis recursos do C#, este Framework é relativamente complexo de se trabalhar e pelo menos na minha visão não é o ideal para se trabalhar com projetos pequenos já que seria trabalhoso demais faze-los e o retorno não seria dos melhores. Por conta disso eu acabei por pensar que a Web não valeria a pena já que é trabalho demais para pouco retorno pelo menos no começo aonde só temos trabalhos pequenos.

Quando conheci o PHP meu pensamento mudou bastante, já que era muito mais simples desenvolver aplicações pequenas, mas que conseguissem dar conta do que fosse necessário, mas ainda assim era necessário muito controle da sua aplicação para que ela não ficasse confusa conforme fosse ficando maior, e então eu acabei reparando que o ASP.NET Core trabalhava muito melhor com aplicações maiores que precisavam de constante expansão, porém não era tão bom para aplicações menores por conta de ser trabalhoso começar um projeto nele, o PHP, por outro lado, conseguia atender melhor as necessidades de um projeto mais simples e com menor necessidade por extensibilidade.

Um investimento, não um gasto.

Com tudo isso dito fica bem claro que em meu ponto de vista, aprender uma nova linguagem não é um gasto do tempo que poderia ser investido melhorando habilidades já existentes, mas um investimento no seu próprio conhecimento.

Você vai ter a mesma capacidade com todas as linguagens? Provavelmente não, mas no final das contas esse não deveria ser seu objetivo, não da para ser bom em tudo. Vai te ajudar com sua linguagem de programação principal? Muito provavelmente sim. O processo de aprendizagem de outra linguagem acaba fazendo você perceber diferenças entre as linguagens, o que faz você se questionar porque as coisas são feitas de formas diferentes e como isso muda o produto final.

Vou usar um exemplo real da diferença que faz ter a ferramenta certa para o trabalho. Durante a produção da dashboard desse mesmo ‘blog’ eu precisava de um webhook no servidor da API para que sempre que eu fizesse um push no meu GitHub a API fosse reiniciada aplicando as alterações, instalando novos pacotes e etcetera. Eu acabei optando por fazer isso usando um servidor com Node.js e Express, mas isso me rendeu alguns problemas.

Era muito complicado verificar se havia uma modificação no arquivo de pacotes para assim rodar o comando de instalação apenas quando necessário.
Como o comando tinha que ser escrito de uma vez só ele ficava muito comprido e complicado de modificar
Escrever logs e salva-los com o FileSystem do Node as vezes não funcionava (timeout) ou demorava por conta do tamanho dos logs, o que fazia eu perder controle da aplicação
Eu poderia sim, ter resolvido todos esses problemas utilizando o Node, todavia, acabei optando por passar esta parte da aplicação para Python e foi provavelmente a melhor decisão que eu tomei. Tudo ficou bem mais simples, esses problemas desapareceram e eu ainda consegui melhorar essa pseudo-pipeline adicionando mais verificações e processos que melhoraram bastante o processo. É justamente aqui que se diferencia o programador poliglota do não poliglota.

E então?

Com toda certeza é muito importante aprofundar seus conhecimentos em um específico campo, ou nesse caso, linguagem. Contudo, acho importante antes de dar esse grande mergulho, ter mais conhecimento geral.
Em muitos casos saber mais sobre outras arquiteturas, infraestrutura ou outra linguagem pode ser muito mais interessante e importante do que realmente se aprofundar na que você já conhece, tudo vai depender do que você está fazendo e do que precisa para conseguir levar esse projeto a frente.

Lembre-se, não se deve colocar todos os ovos na mesma cesta. Até a próxima.