História
Conheça a história por trás da criação do HyperFluxCMS
Havendo tantos sistemas de CMS no mercado, sendo muitos deles gratuitos (mais ou menos), por que criar mais um? Quais as vantagens? O que ele teria de diferente? Veja aqui.
Atualmente existem vários sistemas CMS disponíveis no mercado, e muitos deles se dizendo gratuitos. Alguns são cheios de recursos, tem ampla base de usuários e são utilizados até por grandes portais. Então por que dedicar tempo e esforço para criar mais um?
Pois é. Há pouco mais de um ano, eu nunca imaginei que algum dia estaria lançando um CMS desenvolvido por mim e minha equipe. Já tive experiência desenvolvendo outros softwares gratuitos de código aberto. Mas não num projeto tão ambicioso como o HyperFlux CMS.
Tudo começou quando eu decidi criar um site para divulgar ideias e projetos desenvolvidos pela minha empresa, pelas empresas parceiras e, de vem em quando, algum outro projeto de outra pessoa ou empresa que me autorizasse e eu achasse interessante para o público. Idéias e projetos de design 3D, apps, produtos, equipamentos eletrônicos, hobbies, etc.
Ouvi dizer que o Wordpress era "o cara". Praticamente todo lugar que oferece serviços de hospedagem de sites tem suporte a Wordpress. Grandes portais o usam. Muitos sites famosos usam. É gratuito. Tem uma imensa comunidade de usuários. Tem centenas de "plug-ins" e milhares de temas.
"Me convenceu. Vou desenvolver meu site usando esse treco!", pensei.
Baixei e instalei o XAMPP para começar a desenvolver localmente meu site. Baixei e instalei o Wordpress. Ok, foi fácil.
O próximo passo era escolher um tema. Já não é tão fácil. Existe um oceano de temas. Mas pelo menos 95% deles são temas para páginas estáticas. Ou seja, você cria uma página com texto e imagens e deixa ela lá, pra sempre. Sempre que tiver alguma atualização você tem que editar a página.
Esse modelo é suficiente para muitas empresas: escritórios de advocacia, clínicas de estética, assessoria contábil, hotéis, confeitarias.
Mas não era o que eu procurava. Eu procurava algo mais dinâmico, tipo um portal de um jornal, com vários artigos já na página inicial e que pudesse ser fácil de atualizar toda vez que um artigo dentro do site for criado ou editado.
Dentre o universo de temas, bem poucos, diria que uns 5% ou menos, se enquadram nesse perfil que eu precisava. Ok, encontrei um que achei legal, instalei e pronto.
Aí veio a primeira decepção. A imensa maioria dos temas tem uma versão gratuita e cheia de limitações (por exemplo, você não pode mudar as cores ou fontes, etc). E para poder usar algo além do básico, também tem cobranças mensais ou anuais. E que não são baratas, podendo chegar a centenas de dólares por ano.
Pensei que com o plano básico gratuito do tema que eu escolhi eu conseguiria por no ar o site que eu queria.
Aí começou a tortura. O Título do site? Não dá pra mudar a fonte. O subtítulo? Nem a fonte, nem o tamanho. O tamanho da imagem de rodapé? Necas. O tamanho das "thumbnails" dos artigos? Nem sonhando.
Mesmo assim, continuei insistindo. Pensei que espiando e olhando os arquivos HTML e CSS (muitas dezenas deles), conseguiria achar o local onde pudesse escolher a fonte, o tamanho dos thumbnails, etc.
Fui uma amostra grátis do inferno. Clicava no título da página, "inspecionar elemento" e ele pertencia a 36 classes diferentes. Eu tentava achar em qual dessas classes CSS estava definido que ele começava a 49 pixels depois da margem direita, quando na verdade eu queria que fossem 16. Aí achava algum lugar, mudava e não dava efeito. Aí achava em outro lugar e outro, e não funcionava. Até que eu descobria que a posição era calculada por uma função CSS "calc (isso mais aquilo menos aquele outro vezes 1.2 menos 2,7% do div parent, mais 2% da largura da página...)". E então quando eu conseguia mudar, acabava desalinhando outros elementos que antes estavam na posição que eu queria :(
Para piorar, as declarações CSS que determinavam a posição de um elemento da página usam fórmulas e cálculos diferentes de outro. Eu queria que o título do site ficasse alinhado com o texto. Mas enquanto um deles usava "2% da página + 27 pixels + 20pt - 1.5em", o texto de parágrafo usava "32 pixels -2.5em +1% da largura da janela". Coisas assim. Como resultado, uma página que parecia bonita em resolução 1024p com 100% de zoom ficava toda desalinhada em qualquer outra condição.
Pra piorar ainda mais, muitos dos JavaScripts e CSSs que o sistema carregava eram externos. Uma infinidade deles, tornando mais difícil ainda entender e ajustar as propriedades.
Enfim, posicionar os elementos, definir os tamanhos e as fontes que eu queria me tomaram MUITO tempo e algumas caixas de ansiolíticos e antidepressivos. E mesmo assim não ficaram como eu queria, mas ficaram perto do aceitável.
Ok, tendo o site mais ou menos parecido com o que eu queria, hora de adicionar funcionalidades. Talvez uma galeria de imagens. Legal, o Wordpress tem plugins para isso. Uma busca avançada. No site do Wordpress também tem plugins para isso. Um carrossel? Tem plugin.
Segunda decepção: Assim como os temas, a maior parte dos plugins são muito limitados ou não me atendiam. Mas... pagando mensalidades que podem chegar a dezenas de dólares por mês, o céu se abriria e meus sonhos se realizariam.
Não. Não aceitaria pagar várias centenas de dólares por ano para manter três ou quatro funcionalidades do meu site que nem tinha a menos expectativa de retorno financeiro.
Abri mão das funções que eu queria e segui em frente usando somente o que havia de graça.
"Poxa, todo mundo usa essa desgraça. Tem que ser bom", pensei. "Não é possível que eu seja a única pessoa no mundo que queria essa ou aquela funcionalidade no site sem ter que vender meus órgãos internos. Alguém já deve ter feito funcionar algo parecido com o que eu espero", pensei.
Nem me lembro direito o que eu procurava, acho que minha mente bloqueou a memória para prevenir maiores traumas. Acho que tinha a ver com um sistema de busca ou com fazer um menu interativo.
Procurei, procurei, procurei e não consegui fazer funcionar do jeito que eu queria.
Fui procurar ajuda nos fóruns da comunidade Wordpress, como a que existe no StackOverflow.
Pânico. Dor. Desespero. Humilhação. Aparentemente tinha como fazer o que eu queria... se eu mexesse no código-fonte do Wordpress. Isso significa mexer no código-fonte em PHP.
A linguagem PHP é conhecida por ser uma das mais hediondas já criadas, quase um crime contra a humanidade. A linguagem PHP é como uma criança de cinco anos encapetada e com sono. Quem o criou o ama, quem o conhece desde pequeno diz "ah, ele é bonzinho, só tem que saber lidar com ele", mas quem é de fora não suporta e tem vontade de empurrar num poço bem profundo, escuro e úmido.
Eu guardo minha cota de ódio para o Javascript. Já usei ASP clássico. E prefiro perder a ponta do dedão do pé num acidente embaraçoso envolvendo um bode, um bolo de amendoim e uma placa de trânsito do que gastar meu tempo e esforço aprendendo MAIS UMA linguagem interpretada e não-tipada (principalmente PHP), e ainda mais se fosse só para fazer um sitezinho.
Me conformei em não ter o recurso que eu queria. Continuei trabalhando no design e no conteúdo do meu site.
Após mais de um mês usando todo meu tempo livre, sábados, domingos, feriados e madrugadas contornando todas as limitações do Wordpress para enfim ter um site que chegava a 90% do que eu queria, me dei por satisfeito.
Comecei a criar as páginas de conteúdo e as imagens do meu site. Criei umas duas dezenas de páginas de conteúdo. Isso usando o servidor que instalei localmente. Então pensei: Como eu vou fazer pra subir isso pro meu site?
Então lembrei que o Wordpress usa banco de dados tipicamente MySQL. Ok, um banco de dados open source e gratuito. Epa. Mas e se também tiver pegadinhas e letras miúdas igual os temas e plugins?
Dei uma checada e... ufa. Existem versões corporativas ultra-mega-power do MySQL, mas não era o caso para eu me preocupar. A versão gratuita seria mais do que suficiente para meus propósitos...
...Se dependesse da Oracle (atual mantenedora do MySQL). Mas NÃO dos provedores de hospedagem.
Vendo os planos de hospedagem da maior parte dos provedores, quase todas oferecem banco de dados MySQL gratuito. Mas. com. várias. limitações. Alguns deles limitam o tamanho do banco de dados, outros limitam a quantidade de bancos de dados, outros limitam até mesmo o número de registros no banco de dados.
Por exemplo, alguns planos de hospedagem oferecem 50GB de hospedagem do site, mas desses apenas 1GB pode ser usado para MySQL. Outros limitam o número de acessos simultâneos ao banco de dados, o que significa que, por exemplo, somente 10 usuários podem estar acessando seu site ao mesmo tempo, e se mais algum entrar naquele momento, vai ser recebido com mensagem de erro horrorosa.
Novamente, me resignei com mais essa limitação. Afinal, não tinha grandes pretensões para meu site.
Decidi então subir o conteúdo do meu site para o servidor de hospedagem. Mas... como fazer isso?
Sou desenvolvedor das antigas. Cheguei a usar dBase e Clipper. MySQL não deveria ser muito diferente. Em algum lugar do meu PC estaria o arquivo, ou meia dúzia deles, com o banco de dados que armazenaria o conteúdo que eu tinha criado com tanto empenho. Mas onde?
Como eu usava o XAMPP Portable, procurei na internet e achei a localização dos arquivos. No meu caso, "E:\progs\xampp\mysql". Beleza. Seria só achar os arquivos usados pelo Wordpress e subir no site.
Abrir a pasta e novamente senti dor e desespero. Mais de 400 arquivos dividos em cerca de 40 pastas. E ainda sobraria o trabalho de descobrir onde esses arquivos ficariam no meu servidor, se é que eu teria acesso a eles.
Vi na Internet que não era assim que se fazia. O banco de dados deveria ser exportado através de linhas de comando ou aplicativos de migração, depois no servidor ele deveria ser importado igualmente através de linhas de comando ou ferramentas, para enfim, ter meu site no ar. Ô disgraaaaçaaaaa!!!
Novamente, como uma alma pecadora condenada ao purgatório, aceitei o triste destino que é a trabalheira danada que um pobre cara que só queria ter um sitezinho tem que passar.
Mas não hoje. Antes de ter esse novo trabalho, decidi que iria tirar um tempo para descansar. E que antes de perder tempo publicando, ia pedir opinião de amigos e parentes sobre o visual do site, para só então ter meu sonhado sitezinho.
Me afastei do projeto por uns dias para voltar ao meu trabalho principal.
Juro que durante esse período não mexi em nada no site, nem nos arquivos da pasta onde ele estava.
No dia que eu ia subir o site para meu provedor de hospedagem, dei uma revisada nele e ... TCHARAMM!!!
O site estava completamente desfigurado. Não sei se foi alguma atualização automática do Wordpress, algum sistema de reparação, algum componente do sistema que reverteu ou corrompeu os arquivos HTML e CSS que eu tinha ajustado com tanto carinho, se era um dos zilhões de arquivos hospedados em sites externos que o Wordpress e os seus temas usam... Não sei. Só sei que parecia que o site tinha sido atropelado por um trem. E que o trem ainda deu ré pra ter certeza que destruiu bem destruído.
Xinguei tanto o Wordpress, seus criadores, quem o divulga, quem diz que é a melhor coisa do mundo. Xinguei tanto que tive que inventar uns palavrões novos. Xinguei até a quinta dimensão, porque não existia em nenhuma linguagem criada por humanos termos fortes o suficiente para descrever meu ódio.
Foi quando eu desisti de vez de usar o Wordpress.
Ah, mas existem outros CMSs famosos, como o Joomla e o Drupal, certo?
Sim. Mas o trauma e ódio foi tão grande que eu decidi não arriscar perder mais tempo e alma para correr o risco de acontecer tudo de novo. Foi quando eu decidi criar o HyperFluxCMS.
O HyperFluxCMS seria criado para ser gratuito mesmo (sem letras miúdas, sem limitação de funcionalidades), com código-fonte aberto, totalmente auto-contido (sem precisar usar CSSs, fontes e javascripts de sites externos) e leve. Muito leve. Tanto na execução do lado do servidor, mas principalmente para o visitante do site, que muitas vezes o acessa de algum lugar com internet lenta e ruim e não quer esperar vários segundos até o site carregar dezenas de arquivos, javascripts, css, fontes, de vários sites diferentes.
Quanto à linguagem? Como eu disse, eu não queria aprender PHP. E decidi que não iria usar. Decidi usar um ambiente diferente, ainda que isso limitasse bastante o uso do sistema.
Como eu tinha bastante experiência em C, C++ e C#, decidi usar este último como base para o desenvolvimento. Como resultado, o meu CMS teria uma velocidade excepcional comparado com o PHP que é interpretado, mas com limitações de somente rodar em servidores Windows.
Teoricamente, o .NET Core 8, usado como base para o projeto inicial, poderia ser instalado em servidores Linux e rodar o HyperFluxCMS, desde que ele tivesse o .NET Core 8 instalado compatível com a plataforma. Mas prefiro não contar com isso. Alguém pode tentar fazer rodar em servidores Linux, mas eu lavo minhas mãos.
Infelizmente a imensa maioria dos provedores de hospedagem no Brasil usam servidores Linux. Isso limita bastante o público. Mesmo assim, decidi manter a escolha de Windows/.NET por causa da velocidade dos programas criados nessa plataforma, o fato de C# ser compilado e assim poder detectar a maioria dos erros e bugs em tempo de desenvolvimento e também suporte nativo do .NET Core a vários recursos que o HyperFluxCMS precisaria, como manipulação de imagens e de bancos de dados sem ter que depender da boa vontade e da confiabilidade de código externo alheio desenvolvido por terceiros.
Também optei por usar banco de dados SQLite. Meus testes comprovaram que, em um projeto bem planejado e executado, essa configuração permite manter um site com muitas dezenas de milhares de artigos com um desempenho aceitável, que é suficiente para a imensa maioria das aplicações a quem o HyperFluxCMS se destina.
Além disso, o uso de banco de dados SQLite possui a vantagem de ser extremamente simples fazer backup e também migrar para outro servidor, se você concluir que o provedor de hospedagem do seu site não estiver sendo satisfatório. Conteúdo, postagens, configurações, etc. são guardados em um único arquivo.
Decidi também fazer com que os artigos/páginas/postagens/publicações dos usuários não fossem criadas usando bloquinhos de arrastar, e sim usando alguma linguagem de marcação, para permitir algumas funcionalidades que não seriam possíveis ou confiáveis em uma interface "drag-and-drop": a possibilidade de criar e editar conteúdo de forma offline, em qualquer computador, para publicar depois e a possibilidade de copiar-colar conteúdo de uma postagem para outra, inclusive entre sites diferentes.
E assim, depois de muitos meses de trabalho, nascia o HyperFluxCMS.
Artigos mais recentes
Você também pode gostar