Utilizando muitas gems no seu projeto?

novembro 9, 2016 4:00 pm Publicado por Deixe um comentário

Uma das coisas bem azeitadas e que funcionam muito bem no mundo Ruby, e consequentemente no mundo Rails, é o gerenciamento de dependências de recursos externos ao seu projeto através das gems, onde podemos incorporar várias funcionalidades interessantes de maneira fácil, rápida e segura – algumas vezes.

Rodas e rodas

Sempre que começamos a falar sobre esses recursos externos, vem a frase “claro, já tem pronto, para que inventar a roda?”, como se fosse uma máxima de maneira genérica para todas as situações. Isso não é verdade, pois às vezes não precisaríamos da roda inteira, especialmente se ela fosse de liga leve feita com alumínio, magnésio, silício, titânio e/ou estrôncio, cromadas e pneus de F1. Nesse caso, não estamos reinventando a roda, mas utilizando mais do que realmente necessário, o que pode ser à primeira vista uma vantagem mas que mais tarde pode se provar um problema na manutenção. Pode ser que o que precisávamos mesmo era uma roda simples, de carroça, que resolveria o problema de maneira efetiva, com parcimônia e eficiência. E que se fosse necessário fazer uma na mão, também não daria tanto trabalho.

roda-de-carroca

Círculo de confiança

Além da confiança que temos automaticamente no recurso associado ao projeto, em relação ao fato de que o seu código vai cumprir o prometido – seja na medida do que é necessário ou entregando mais do que precisamos -, temos também a confiança de que o código sendo associado está livre de quaisquer problemas de segurança. Hoje as pessoas têm se esquecido bastante disso em parte porque várias ferramentas que utilizamos fazem a verificação de autenticidade do código, como os pacotes que são instalados/atualizados em distribuições GNU/Linux como o Ubuntu. Se você não conhece como funciona esse processo, aqui tem um link legal sobre o assunto. Outra parte em que as pessoas se esquecem bastante disso é porque, sinceramente, estão se lixando para esse assunto, o que é um erro que só vai dar dor de cabeça quando acontecer alguma coisa bem ruim no computador da pessoa.

Existem algumas maneiras de garantir que a autenticidade do código da gem que está sendo instalada venha da fonte esperada, inclusive eu já comentei sobre isso algum tempo atrás, em um artigo falando sobre gems assinadas, que podem garantir a autenticidade do código e também adicionar uma camada de segurança, pois para que a gem tenha lido liberada, ela tem que ser assinada com a chave do desenvolvedor. Mesmo se alguém roubar o computador do desenvolvedor responsável pela gem, a pessoa ainda teria que saber a senha de assinatura, e vamos convencionar que alguém que assina o seu código não vai ter uma senha como “123456”. Aqui tem um artigo interessante sobre essa confiança no código. Mas, mesmo assim, se o código for autenticado, temos que confiar que ele não vá fazer nada nocivo. Difícil ocorrer algo do tipo, mas existe o RubySec para dar uma “policiada” na coisa e algumas ferramentas para ajudar a policiar a segurança do seu projeto.

circle-of-trust

Exagero

Às vezes parece que fazer uma aplicação é entrar na sessão de Lego da loja de brinquedos, abrir todas as caixas que têm pecinhas legais e sair juntando tudo. Ok, em uma loja de brinquedos isso seria bem legal, mas em uma aplicação, calma lá. É fácil ser seduzido por uma roda de liga leve cromada bonitona como exemplificado no começo do artigo, mas, assim como qualquer linha de código adicionada é uma linha que você ou alguém vai ter que manter mais tarde (aqui tem um artigo legal sobre isso), qualquer dependência não tão bem pensada no seu projeto vai com certeza te assombrar de alguma forma no futuro. Ou talvez não. Algumas gems são simples, diretas, com chance de ter pouca probabilidade de aumentar a complexidade tanto das dependências como do seu próprio código. Algumas vão carregar a memória com uma cascata recursiva de dependências, insistir em brigar com as outras, com o framework, com a própria linguagem, e aí, parceiro, a coisa complica. O item 5 deste artigo relaciona alguns desses problemas.

capitao-nascimento-vai-dar-merda

Tendo uma ideia do tamanho da paulada

Para inspecionar como andam as dependências do seu projeto, existe um método bem prático. Vamos precisar instalar o graphviz no sistema operacional, se já não estiver instalado:

$ sudo apt-get install graphviz

Instalar a gem (vejam que não estou falando para colocar no Gemfile do projeto e gerar mais uma dependência!):

gem install ruby-graphviz

e rodar o seguinte comando:

$ bundle viz

que vai gerar um arquivo chamado gem_graph.png no diretório corrente. Em uma aplicação Rails criada vazia, vai ser algo assim (clique para ampliar):

gem_graph

Mensagem do anunciante:

Experimente a Umbler, startup de Cloud Hosting por demanda feita para agências e desenvolvedores e ganhe até R$ 100 em créditos!

Source: IMasters

Categorizados em:

Este artigo foi escrito pormajor

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *