Utilizando muitas gems no seu projeto?
Publicado em Developer
gems rails ruby
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 as vezes não precisaríamos da roda inteira, especialmente se ela for de liga leve feitas 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 estamos 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.
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 em dia as pessoas tem se esquecido bastante disso em parte porque várias ferramentas que utilizamos fazem a verificação de autenticidade do código, como no exemplo 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 vem da fonte esperada, inclusive eu já comentei sobre isso aqui no blog 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 adicional pois para que a gem tenha lido liberada, ela tem que sser assinada com a chave do desenvolvedor. Mesmo se alguém roubar o computador do desenvolvedor responsável da 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.
Exagero
Às vezes parece que fazer uma aplicação é entrar na sessão de Lego da loja de brinquedos, abrir todas as caixas que tem 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 desse artigo relaciona alguns desses problemas.
Tendo uma idéia 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):
Comentários
Comentários fechados.
Sem nenhum comentário.
Artigos anteriores
- Pull requests em modo raiz - sex, 22 de dezembro de 2023, 09:57:09 -0300
- Qual a idade do seu repositório? - ter, 27 de dezembro de 2022, 12:50:35 -0300
- Utilizando ctags em projetos Rails mais recentes - qui, 24 de junho de 2021, 08:23:43 -0300
- Fazendo o seu projeto brotar - seg, 15 de julho de 2019, 08:57:05 -0300
- Learn Functional Programming with Elixir - sex, 02 de março de 2018, 18:47:13 -0300
- Ambiente mínimo - Driver Driven Development - qua, 23 de agosto de 2017, 15:15:03 -0300
- Ambiente mínimo - repositórios de código - dom, 16 de abril de 2017, 13:02:14 -0300
- Ambiente mínimo - terminal e navegador - dom, 02 de abril de 2017, 21:43:29 -0300
- Utilizando muitas gems no seu projeto? - sáb, 29 de outubro de 2016, 11:57:55 -0200
- Desenvolvedores e inteligência artificial - seg, 11 de julho de 2016, 09:09:38 -0300