Começando o Projeto Ágora (PrAgora) ou: Escolhendo um framework PHP para um projeto novo

Esse post marca o anúncio público do Projeto Ágora (apelidado de PrAgora por questões de Google Fu). A idéia desse projeto nasceu da minha desilusão com a política. Minha curta experiência em política partidária me indicou que não existe democracia interna em organizações brasileiras, especialmente partidos políticos.

Será que as organizações não implementam esses processos por falta de vontade ou de condições tecnológicas? Se for por ausência de condições tecnológicas talvez seja algo em que eu possa dar alguma contribuição, ainda que modesta. Pensei então que poderia haver um sistema que servisse de base tecnológica para organizações que quisessem democratizar seus processos internos.

De maneira objetiva quero implementar principalmente dois módulos:

  • Um de proposições, em que seja possível “positivar” as proposições de maneira que, ao atingir certa quantidade de upvotes a proposição seja discutida/debatida nas lideranças da organização – evitando que as lideranças deixem certas propostas “debaixo do tapete”;
  • Outro de votações, em que seja possível votar em propostas, e que, mediante configuração, seja possível visualizar quem votou no que, proporcionando transparência ao sistema;

Propositalmente não irei implementar funcionalidades que já existem em outros espaços tais como:

  • Sistema de comunicação por tópicos (já existente em sistemas de fóruns ou grupos de e-mail);
  • Comunicação rápida (já existente em sistemas como Whatsapp ou Telegram);

Fiz questão que o primeiro commit fosse em um simbólico 7 de setembro. Mas desde lá não havia escrito uma linha de código pois estava maturando a idéia.

Decidi então que hoje pode ser um momento propício para mais alguns passos.

O primeiro passo foi escolher a tecnologia. (In)felizmente hoje existe uma infinidade de possibilidades tecnológicas então existe o risco da paralisia por indecisão diante desses múltiplos caminhos.

Para me ajudar defini alguns princípios para o projeto. Como eu quero que o projeto seja usado por organizações de muitos tipos ele tem que ser:

  • Fácil de instalar e de usar
  • Baseado em tecnologias baratas, se possível gratuitas e livres

Inicialmente escolhi a linguagem PHP pois um ambiente PHP é algo relativamente simples de configurar e amplamente disponível em hospedagens compartilhadas por aí. Além disso, como eu estou atualmente trabalhando como professor de Programação Web achei que seria interessante me inteirar um pouco melhor do ecossistema PHP.

Bom, até mesmo por esse ser um side project, achei que não seria pertinente fazer um projeto totalmente do zero então o próximo passo foi escolher um framework PHP.

Após algumas leituras: “10 Best PHP Frameworks To Use in 2021” e especialmente “Os Frameworks PHP mais Populares para Usar em 2022” separei principalmente Codeigniter, Cakephp, Slim e Fuelphp esses por terem menos dependências segundo o segundo link citado.

Também considerei em alguns momentos anteriores usar o Laravel mas olhei o site do Laravel e achei a documentação básica muito ruim: ela primeiro explica, em detalhes, cada conceito do framework ao invés de ser mais direto ao ponto. Não acho essa uma boa abordagem para frameworks web. Ou seja, antes de mostrar as vantagens ele tenta entrar nos meandros do mesmo. Também procurei fontes alternativas ao site oficial mas aparentemente a documentação introdutória do Laravel, se existe, é principalmente em vídeos, o que eu não considero o ideal.

Fiz uma busca no Google Trends para ter uma idéia de popularidade também, afinal se o objetivo é que o projeto seja popular acho que esse aspecto não pode ser desprezado.

O resultado foi o da imagem abaixo:

Quem quiser refazer essa pesquisa com outros parâmetros pode fazê-la no seguinte link: https://trends.google.com.br/trends/explore?q=%2Fm%2F02qgdkj,%2Fm%2F09t3sp,Slim%20php,Fuel%20PHP,Laravel%20php

Adicionei o Laravel na pesquisa acima mais para ter um parâmetro. Confesso que eu achava que o Laravel tivesse um destaque bem maior nessa pesquisa. Segundo essa fonte o CodeIgniter está com uma popularidade semelhante ao Laravel.

Também consultei essa página do Slant: https://www.slant.co/topics/1183/~best-php-frameworks que mostra o Slim PHP como o preferido dessa comunidade.

Embora o primeiro lugar do Slant esteja diferente do Google Trends, o Fuel está mal posicionado em ambos e acabei descartando o Fuel por esses critérios.

Restou então nesse ponto CodeIgniter, Cakephp e Slim. Dei uma olhada na documentação dos três e embora as três parecem bem melhores do que a do Laravel me chamou atenção positivamente no Slim uma informação bem destacada de como fazer o deploy de uma aplicação.

Porém, consultando a própria documentação vi que tanto CodeIgniter quanto Slim não possuem um módulo de autenticação integrado ao framework. Esse funcionalidade é provida através de plugins de terceiros. Talvez isso faça sentido para algumas aplicações porém não é o meu caso então considerei um parâmetro importante.

Nesse ponto, pelos motivos expostos acima, eu já estava mais inclinado a escolher o Cakephp. Também preciso ser intelectualmente honesto e dizer que eu já tive uma experiência prévia com Cakephp e que a experiência na ocasião foi relativamente positiva. Digo relativamente pois na época eu vinha do mundo Rails e usar Cakephp, na época, me pareceu um downgrade pessoal. Em minha defesa, foi um projeto em equipe e não uma EUquipe como é o caso, nesse momento, do PrAgora.

Pretendo fazer outras postagens sobre o PrAgora mas quem quiser acompanhar com mais detalhes pode seguir o projeto pelo Github: https://github.com/viniciusalveshax/PrAgora

Deixo a pergunta pra você que chegou até aqui: o que você achou do processo descrito acima? O que faria diferente? O que achou interessante?

PS: No commit sobrecitado o nome do repositório consta como democracyOS. Optei por renomear o projeto por vários motivos: primeiro que democracyOS, por si, é um pouco clichê. Sem mencionar que eu não estou desenvolvendo um Sistema Operacional. Além disso nesse período refleti um pouco e acho que o que eu queria tentar reproduzir é uma espécie de Ágora grega (pelo menos na versão romantizada que a palavra remete – não sou especialista em história da Grécia, desculpem). Por último, mas não menos importante, achei divertido que Ágora tem uma grafia semelhante com a palavra Agora do português. E esse urgência de algo que precisa ser feito hoje, e não amanhã também condiz com a minha visão para o projeto.

Linguagens interpretadas e linguagens compiladas

Existe um número enorme de linguagens de programação. Mesmo levando em consideração somente as principais elas podem ser contadas em centenas: https://en.wikipedia.org/wiki/List_of_programming_languages. Portanto é natural que existam diversas maneiras de classificar as linguagens de programação.

Uma das classificações possíveis e que pode gerar dúvidas para iniciantes é quanto ao modo em que as linguagens são implementadas. Existem duas principais maneiras de implementar uma linguagem de programação: através de um compilador ou através de um interpretador.

Esse texto busca esclarecer esses conceitos e as diferenças entre eles. Dependendo qual foi a primeira linguagem que você aprendeu ou pretende aprender um dos dois pode parecer ser mais “natural” para você.

Programa compilado

Uma das linguagens de programação mais antigas, o Fortran, usava o caminho da compilação e pode-se dizer que durante muitos anos esse caminho foi o dominante no projeto de linguagens. Linguagens como C e C++ que por décadas dominaram o mercado usaram esse método.

Qual é a proposta da compilação?

A idéia é ter um programa, chamado de compilador, que irá ler um arquivo escrito em uma linguagem de alto nível (C, C++, Fortran, etc) e irá transformar esse resultado em código binário executável.

Esse código geralmente é um programa independente que pode ser executado mesmo que o compilador seja, por exemplo, desinstalado.

Veja, por exemplo, a imagem abaixo, na qual um programa (escrito na linguagem C) é compilado com o gcc (gcc é a sigla para Gnu C Compiler) e depois que o programa final é gerado (essa etapa da geração se chama compilação) podemos simplesmente executar o arquivo “programa” que foi gerado.

Nesse caso mesmo que o programa “gcc” fosse desinstalado, o programa final poderia ser executado sem problemas. Da mesma maneira poderíamos copiar o programa para outro computador e o mesmo também funcionaria (desde que o ambiente disponível para EXECUÇÃO estivesse disponível). Poderíamos até mesmo deletar o arquivo fonte original exemplo.c e o programa continuaria executando.

Ou seja: na implementação via compilador temos duas etapas bem separadas e relativamente independentes: a COMPILAÇÃO, na qual o programa é gerado, e a EXECUÇÃO do programa.

Essa separação tem algumas vantagens e algumas desvantagens.

Vantagens:

Como o programa gerado é um código binário pronto a etapa de execução tem uma performance maior. Não é preciso usar o processador do computador para decidir como o programa irá se comportar. Certo ou não (dependendo se o programa tem bugs), o seu comportamento já está definido. Esse aumento de performance é significativo e em muitos sistemas nos quais o desempenho é algo MUITO importante pode ser mais interessante usar linguagens compiladas. Por isso que quase todos os sistemas operacionais são gerados a partir do processo de compilação (na verdade existem alguns detalhes adicionais mas isso pode ser tema para outro texto).

O programa, uma vez gerado, não precisa do compilador instalado. Isso permite economia de disco pois em ambientes de produção não precisamos ter o compilador instalado. Em certas circunstâncias isso pode até melhorar a segurança geral de um sistema afinal nunca é recomendável deixar compiladores em sistemas que podem ser alvos de atacantes.

Desvantagens:

O processo de desenvolvimento acaba sendo um pouco mais tedioso pois o desenvolvedor precisa, enquanto está desenvolvendo e testando o sistema, realizar duas etapas: compilar e executar ao invés de uma. Claro que certas automatizações podem ser feitas mas isso leva a outro problema do método de compilação.

A demora na compilação: dependendo da complexidade e tamanho do programa a compilação pode levar vários minutos. Então o desenvolvedor manda o programa compilar e precisa aguardar, às vezes um tempo considerável, até o programa concluir a compilação. Para não mencionar que alguns programas podem consumir algum tempo e nem terminar de compilar, por algum erro de programação por exemplo.

Programa interpretado

Algumas das linguagens mais usadas atualmente são interpretadas: Python, Javascript, Ruby, PHP, etc.

Aqui o processo de desenvolvimento é diferente. Vejamos esse exemplo de um programa em Python.

Observe que aqui, ao invés de compilar o programa o executamos chamando “python3 programa.py”. O que está acontecendo aqui? python3 é um programa que chamamos de interpretador. Ao invés de transformar o arquivo fonte programa.py em um arquivo binário o interpretador lê o arquivo citado, uma linha por vez, e na medida do possível – se não houver erros – vai executando o arquivo.

Esse processo de leitura do arquivo-fonte e interpretação do mesmo é feito a cada execução do programa. Ou seja, o nosso programa python precisa do interpretador e do arquivo fonte em cada uma das suas execuções. Se deletássemos o arquivo programa.py, ao tentar executar novamente a linha “python3 programa.py” resultaria em um erro.

As vantagens e desvantagens são praticamente o inverso de um programa compilado.

Vantagens:

O desenvolvimento é um pouco mais rápido: não é preciso realizar duas etapas para ver o resultado do programa. Além disso o interpretador começa a executar mais rapidamente e assim que um erro é detectado a interpretação para. Em geral, erros simples acabam sendo detectados em menos tempo pois não é preciso esperar o término da compilação.

Desvantagens:

Como o programa é sempre lido e interpretado existe uma perda de performance devido ao retrabalho considerando múltiplas execuções. Além disso o próprio interpretador precisa de um tempo para executar e tomar decisões. Em programas compilados pode-se dizer que a maioria dessas decisões são tomadas na compilação tornando a execução mais rápida.

O interpretador precisa estar disponível senão o programa não funciona. Isso pode levar a um aumento do uso de disco rígido.

Caminhos intermediários

Claro que a divisão acima é essencialmente teórica. Existem inclusive propostas híbridas sendo a de maior destaque a linguagem Java. Em java existe a etapa da compilação porém o resultado da mesma não é um código binário diretamente executável mas sim um código simplificado chamado de bytecode. Esse código, por ser simplificado executa muito rapidamente mas ainda precisa de um tipo de interpretador, que no caso da linguagem Java é chamado de Java Virtual Machine (JVM) ou Máquina Virtual Java.

O Java foi implementado dessa maneira para ter um interpretador mais eficiente porém com a possibilidade de compartilhar código para diversos hardwares (a proposta inicial do Java era escrever um único código e executar o mesmo – através da jvm – em diversos hardwares diferentes, como por exemplo aparelhos celulares).

Hoje muitas linguagens adotam uma solução próxima da linguagem Java. Inclusive muitas linguagens foram adaptadas para gerar bytecode e portanto utilizar a eficiente jvm mesmo que o código-fonte seja criado em outras linguagens.

Uma solução intermediária ligeiramente diferente é rodar código interpretado durante o desenvolvimento e gerar uma espécie de bytecode (usar um compilador) somente no ambiente de produção com o código já plenamente desenvolvido e teoricamente testado.

Conclusão

De maneira geral podemos resumir que devido à melhoria do hardware a implementação via interpretador ganhou força ao longo do tempo. A estratégia da compilação ainda persiste mais utilizada em ambientes nas quais a performance precisa ser extraída ao máximo como, por exemplo sistemas operacionais e jogos. Em outros ambientes nos quais a velocidade de desenvolvimento e alteração dos sistemas tem uma importância maior acaba favorecendo linguagens interpretadas.

Dito isso é importante notar que na verdade nada impede que, na teoria, uma linguagem projetada para ser compilada seja executada através de um interpretador ou que uma linguagem originalmente interpretada não possa ser compilada. Mas, na prática, isso não é muito comum já que linguagens acabam sendo mais adotadas ou em um contexto de compilação, interpretação ou em uma mistura de ambos, caso da linguagem Java.

Resolvendo problema de compatibilidade entre java e javac

Me deparei (sic) com um problema ao tentar executar um código Java.

Primeiro eu compilei o programa normalmente com javac. Porém ao tentar executar o programa apareceu a mensagem de erro abaixo:

Transcrição de parte do erro:

“Error: A JNI error has occurred, please check your installation and try again
Exception in thread “main” java.lang.UnsupportedClassVersionError: Aleatorios has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0″

Usando os comandos which e ls descobri que javac apontava para /usr/lib/jvm/java-11-openjdk-amd64/bin/javac e java apontava para /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java, claramente versões diferentes do Java, o que era condizente com o erro acima. Lembro vagamente de ter alterado a versão do runtime Java (não me lembro o motivo) mas eu acreditava que o javac mudava junto. Parece que não.

Bom, com o comando

sudo update-alternatives --config java

Selecionei a versão mais recente do Java (mesma versão do javac).

E aí agora tudo voltou a funcionar. Espero ter ajudado alguém.

Referência utilizada: https://aboullaite.me/switching-between-java-versions-on-ubuntu-linux/

Palestra Tchelinux Live 2021 – Detecção de objetos com imagens usando Keras e Python

Link da palestra:

Alguns links de referência para quem assistiu a palestra

Apresentação no Tchelinux 2020

Artigos do prof. Ricardo:

https://ricardomatsumura.medium.com/material-de-apoio-para-aulas-de-intelig%C3%AAncia-artificial-e-aprendizado-ce43543e886d

Site do PinguimBots:

http://www.pinguimbots.com/


Artigo no qual baseamos a versão inicial do nosso código:

Código no GitHub

https://github.com/viniciusalveshax/object-detection-2021

Palestra Tchelinux Live 2020

Para quem assistiu a palestra do Tchelinux Live deixo algum material complementar.

Ted Talk – The first 20 hours – Josh Kaufmann:

Trailer do filme Robocop (envelheceu bem):

Robôs da Boston Dynamics (assista com ceticismo):

Dataset utilizado:

Descrição: PALECHOR, Fabio Mendoza; DE LA HOZ MANOTAS, Alexis. Dataset for estimation
of obesity levels based on eating habits and physical condition in individuals from
Colombia, Peru and Mexico. Data in brief, v. 25, p. 104344, 2019.

Onde baixar: https://archive.ics.uci.edu/ml/datasets/Estimation+of+obesity+levels+based+on+eating+habits+and+physical+condition+

Arquivos da apresentação (incluindo o código):

https://github.com/viniciusah/conteudos_diversos/tree/main/tchelinux-live-2020

Para saber mais sobre IA e robótica acesse:

Agradecimentos

Ao prof. Ricardo (http://www.ricardoaraujo.net/) e ao grupo PinguimBots (http://www.pinguimbots.com/) pelo grande aprendizado que propiciou essa palestra;

A organização do evento Tchelinux Live, especialmente Leo Vaz, Diego Costa e Rafael Jeffman;

A todo mundo que prestigiou a palestra e esse texto, incluindo você 🙂

Olá, mundo!

Começando então um novo projeto que eu pretendo utilizar para centralizar conteúdos interessantes que tenham relação com computação e TI