Tag Archive | tufao

Por que eu migrei o projeto Tufão para o github?

Há um projeto de software livre que eu iniciei chamado Tufão. O objetivo do projeto era tornar a linguagem C++ amigável para desenvolvimento web. A diferença é que por muito tempo desenvolvimento web fazia o contrário de me atrair e isso só mudou depois que conheci o Node.js, que acabou influenciando na arquitetura do Tufão. Há muitos e muitos meses atrás, o Tufão era hospedado no Google Code, mas devido a alguns motivos eu acabei migrando para o github.

Motivos da mudança

Eu migrei o Tufão para o github pelo simples motivo de que a linguagem de marcação usada para customizar a página inicial do projeto no Google Code não suporta listas aninhadas muito bem.

  • Listas
    • Profundamente
      • Aninhadas

O motivo da migração pode parecer decepcionante, então eu vou dizer que outro motivo da migração é que eu finalmente pude deixar a documentação do projeto online, pois o Github gera um site online para você a partir do branch especial gh-pages e uma documentação online é algo que eu queria muito. A tentativa de converter a documentação gerada pelo Doxygen para a wiki do Google Code foi um resultado bem ruim. E na época que eu usava o Google Code acabava oferecendo a documentação gerada como uma opção download, uma tarefa bem inconveniente. E essa gambiarra nem funcionaria hoje em dia, pois “devido a mal uso da funcionalidade”, a Google desativou a funcionalidade.

Experiência pós-github

O primeiro impacto que o github trouxe para o projeto, é que antigamente você não tinha um jeito fácil de oferecer o download dos binários do projeto, então eu parei de oferecer binários para a plataforma Windows (que a partir de agora você tem que gerar por sua conta), assim como os usuários pararam de encher meu saco com essa tarefa que pode ter uma explosão combinatória, pois o ambiente de desenvolvimento pode variar muito entre sistemas diferentes.

O segundo impacto que o github trouxe, é que ele mapeia muito bem a natureza distribuída do git e tornou-se muito fácil contribuir para o projeto. Você pode conferir no próprio github que há pessoas modificando cópias próprias do projeto, assim como houveram outros contribuidores além de mim.

O terceiro impacto que o GitHub trouxe foi me deixar viciado em MarkDown. É o requisito #1 para caixas de textos de qualquer serviço na web. Eu uso gists secretos para manter minhas listas de tarefas, pois há suporte a MarkDown, eu escrevo minhas propostas usando MarkDown, eu faço slides para apresentações usando MarkDown, eu uso e abuso do MarkDown…

Uma característica que eu notei é que o bug tracker do Google Code aparentava ser mais completo, mas para um projeto do tamanho do Tufão, isso ainda não impactou negativamente o projeto. Só para citar como exemplo, eu podia anexar arquivos arbitrários a comentários que eu fizesse aos bugs registrados, no Google Code. No GitHub eu só aprendi a anexar imagens. Acho que até o bugtracker do serviço launchpad é mais completo e acho que o github não vai mudar, pois essa simplicidade torna o serviço dele mais “user-friendly”, que é a mesma desculpa para eles ignorarem as reclamações do Linus Torvalds.

Why is it a bad idea to rewrite Tufão build system under qmake

Since Tufão 0.4, I’ve been using CMake as the Tufão build system, but occasionally I see some users reimplementing the qmake-based project files and I thought it’d be a good idea to explain/document why such rewrite is a bad idea. This is the post.

Simply and clear (1 reason)

It means *nothing* to your qmake-based project.

What your qmake-based project needs is a *.pri file to you include in your *.pro file. And such *.pri file *is* generated (and properly included in your Qt-installation) by Tufão. You’ll just write the usual “CONFIG += TUFAO” without *any* pain.

Why won’t I use qmake in Tufão ever again (long answer)

Two reasons why is it a bad idea:

  • You define only one target per file. You need subdirs. It’s hard.
    • The Tufão unit testing based on Qt Test requires the definition of separate executables per test and the “src/tests/CMakeLists.txt” CMake file beautifully defines 13 tests. And with the CMake-based system, all you need to do to add a new test is add a single line to the previously mentioned file. QMake is so hard that I’d define a dumb test system that only works after you install the lib, just to free myself from the qmake-pain.
  • There is no easy way to preprocess files.
    • And if you use external commands that you don’t provide yourself like grep, sed or whatever, then your build system will be less portable than autotools. Not every Windows developer likes autotools and your approach (external commands) won’t be any better.
    • All in all, it becomes hard to write a build system that will install the files required by projects that use QMake, CMake or PKG-CONFIG (Tufão supports all three).

The reasons above are the important reasons, but there are others like the fact that documentation is almost as bad as the documentation for creation of QtCreator plugins.

The ever growing distance from QMake

When Tufão grows, sometimes the build system becomes more complicated/demanding, and when it happens, I bet the QMake-based approach will become even more difficult to maintain. The most recent case of libtufao.pro that I’m aware of had to include some underdocumented black magic like the following just to meet the Qt4/5 Tufão 0.x demand:

You like a CMake-based Tufão

The current CMake-based build system of Tufão provides features that you certainly enjoy. At least the greater stability of the new unit testing framework requires CMake and you certainly want a stable library.

QMake hate

In the beginning, QMake met Tufão requirements of a build system, but I wouldn’t use it again for demanding projects.

But I don’t hate QMake and I’d use it again in a Qt-based project if, and only if, I *know* it won’t have demanding needs. Of course I’ll hate QMake if people start to overuse it (and creating me trouble).

And if you still wants to maintain a QMake-based Tufão project file, at least you’ve been warned about the *pain* and inferior solution you’ll end up with.

Fixing Tufão (accidental) ethical mistakes

Today I’ve spent some minutes of my time to fix the metadata of the Tufão git repo. The issue makes difficult to gather who author owns which lines of the code, which can be a problem if you want give merit for the real coders (maybe this is related to ethics) and if you want to contact the authors later for actions that only can be done by the copyright owner (eg. change license). This incorrect info was introduced by misuse of the git tool.

First, I must admit that I was wrong and the issue was entirely caused by ignorance of my git’s knowledge at the time. The issue was not made on purpose. You can see an example here, where I mentioned the original author on the commit message to give the appropriate credit (my intent). But there are also cases where I failed to even make such mention.

Every commit you make using the git tool has an associated author and if you don’t specify the author explicitly, git will use the global config. This metadata is used by commands such as git shortlog -s and git blame. The solution is simply: Just set the author explicitly using the –author argument.

Now the git repo history mentions authors such as Paul Maseberg and Marco Molteni.

Lastly, but not least, I want to let you know that I believe the problem is solved. If you find something that I missed, just fill a bug on the github and I’ll fix it.

FISL 14 – slides da palestra sobre Tufão

Apresentei a palestra sobre o Tufão no FISL 14. Estava um pouco nervoso e acabei omitindo muita coisa que planejava discutir inicialmente, além de falar um pouco rápido também no começo da apresentação. Além disso, eu tinha preparado a palestra para pessoas iniciantes e foi um pouco inesperado encontrar pessoas experientes (tive que pular várias explicações que planejava fazer inicialmente), mas isso me deixou feliz quando perguntas sobre “o porquê” junto de algum argumento chegavam. De qualquer forma, colocando os slides e o vídeo aqui para quem estiver interessado. Farei um post sobre o restante do FISL separadamente, mais legal.

Slides

E me arrependi de não ter colocado uma imagem-bônus que quebrasse um pouco das regras dos “bons costumes” que acabam criando uma barreira entre o palestrante e a plateia. Decidi que todas as minhas palestras, a partir de agora, terão uma imagem divertida.

Palestra sobre o Tufão no FISL14

Tive uma palestra aceita no FISL14 e o tema da palestra é a framework Tufão.

Espero mostrar rapidamente o histórico do projeto e usar o tempo restante para a motivação, reservando 10 minutos ao final para perguntas. A motivação deve incluir uma pequena explicação de como funciona a web e seus principais pontos, comparações, becnhmarks (esse é um item mais difícil), limitações, exemplos e um “tutorial”.

Devo preparar uma nova aplicação de exemplo que explora características presentes no Tufão.

Tufão 1.0.0

After a long time developing Tufão, it finally reached 1.0 version some hours ago. I’ve spent a lot of time cleaning up the API and exploring the features provided by C++11 and Qt5 to release this version.

This is the first Tufão release that:

  • … breaks config files, so you’ll need to update your config files to use them with the new version
  • … breaks ABI, so you’ll need to recompile your projects to use the new version
  • … breaks API, so you’ll need to change your source code to be able to recompile your previous code and use the new version
  • … breaks previous documented behaviour, so you’ll need to change the way you use features that were available before. But don’t worry, because the list of these changes are really small and are well documented below.

Porting to Tufão 1.0

From now on, you should link against tufao1 instead of tufao. The PKGCONFIG, qmake and CMake files were renamed also, so you can have different Tufão libraries in the same system if their major version differs.

The list of behavioural changes are:

  • Headers are being stored using a Hash-table, so you can’t easily predict (and shouldn’t) the order of the headers anymore. I hope this change will improve the performance.
  • HttpServerRequest::ready signal auto-disconnects all slots connected to the HttpServerRequest::data and HttpServerRequest::end slots before being emitted.
  • HttpFileServer can automatically detect the mime type from the served files, so if you had your own code logic to handle the mimes, you should throw it away and enjoy a lesser code base to maintain.

Most of the errors related to API changes are caught at compile-time and you can use the Qt5′s new connection syntax and C++11′s override keyword to catch the remaining errors.

News

The list of changes:

  • The project finally have a logo (made by me in Inkscape)
  • Deprecated API was removed
  • Url and QueryString removed in favor of QUrl
  • Headers refactored to inherit from QMultiHash instead of QMultiMap
  • HttpServerResponse
    • Constructor’s options argument is optional now
    • setOptions method added
    • Constructor takes a reference to a QIODevice instead a pointer
  • HttpServerRequest
    • Constructor takes a reference to a QAbstractSocket instead a pointer
    • socket method returns a reference instead a pointer
    • url returns a QUrl
    • data signal was changed and you must use readBody method to access body’s content
    • the upgrade’s head data is accessed from the request body from now on
    • now the object auto-disconnects slots from data and end signals right before emit ready
    • setCustomData and customData methods added
      • Now HttpServerRequestRouter use these methods to pass the list of captured texts
  • HttpServer uses reference instead of pointers in several places
  • AbstractHttpServerRequestRouter refactored to explore lambdas features
  • Tufão’s plugin system fully refactored
    • It’s using JSON files as configuration
  • AbstractHttpServerRequestHandler::handleRequest
    • It uses references instead pointers
    • It receives 2 arguments instead of 3
  • One more abstraction to sessions created to explore lambdas
  • WebSocket
    • startServerHandshake is taking references instead pointers
  • LESS POINTERS and MORE REFERENCES
    • This change exposes a model more predictive and natural
    • I’m caring less about Qt style and more about C++ style
      • But don’t worry, I’ll maintain a balance
  • Using scoped enums
  • HttpFileServer uses/sends mime info
  • Interfaces don’t inherit from QObject anymore, so you can use multiple inheritance to make the same class implement many interfaces
  • HttpUpgradeRouter introduced
    • HttpServer::setUpgradeHandler also
  • Updated QtCreator plugin to work with QtCreator 2.7.0 and Qt 5

The future

I want to improve the Tufão’s stability and performance, so now I’ll focus on a minor relase with unit testing and some minor changes.

After Tufão 1.0.1, I’ll focus on BlowThemAll.

Bonus

You can see a visualization video based on the history of commits below.

This release deserves a wallpaper, so I made one. See it below:

Tufão wallpaper

You can download the source of the previous wallpaper here.

What are you still doing here? Go download the new version right now!

Tufão 0.4 lançado

Eu perdi as contas de quantas horas eu gastei lendo a documentação do CMake, mais RFCs, documentação de outras frameworks web e outras fontes de informação para lançar essa nova versão com tão poucas novidades. São elas:

  • Uso do sistema de build CMake
    • Possibilidade de instalar diferentes versões maiores em paralelo
    • Suporte a PKGCONFIG adicionado
  • Suporte a sessões
  • Documentação melhorada

JSON-RPC 2.0 sobre WebSockets com Tufão + Phobos-RPC (Qt)

Sou uma pessoa que simpatiza com jogos e, ultimamente, estive trabalhando em um jogo orientado a disputas multiplayer pertencente ao gênero Bomberman. Para implementar a arquitetura de jogo sugerida pelo time de desenvolvimento, desenvolvi algumas bibliotecas auxiliares. E nesse post vou documentar como combinar as duas bibliotecas para permitir chamadas de métodos remotas (RPC).

A primeira biblioteca que desenvolvi para o projeto foi batizada de Phobos e sua única função é implementar o protocolo JSON-RPC 2.0. Meu objetivo principal durante seu desenvolvimento foi auxiliar o desenvolvimento do BlowThemAll e, assim sendo, alguns fatores, como arquitetura e documentação, foram deixados de lado. O projeto não tem página própria na internet e as “releases” do mesmo encontram-se na página de downloads do BlowThemAll.

Há um segundo projeto que iniciei, batizado de Tufão. É uma biblioteca desenvolvida em cima do Qt que possui uma API similar ao Node.js que pode ser usada para criar aplicações web. Desenvolvi esse projeto de forma bem disciplinada, me dedicando bastante, seja ao projetar sua arquitetura, seja ao escrever sua documentação, seja durante os testes, empacotamento para diferentes plataformas, preparação de uma página decente, criação de exemplos e documentação por fora… Caso queira saber mais sobre o mesmo, visite a página do projeto.

Pré-requisitos

 Esse texto assume que você está utilizando (e tem um pouco de familiaridade com) o QtCreator para gerenciar seus projetos e tem uma boa noção de orientação a objetos. Além disso, esse texto assume que você já instalou o Tufão no seu sistema.

Preparando um novo projeto

A primeira coisa a fazer, é baixar a biblioteca Phobos e seu “adapter” para o Tufão.

Então, usando o plugin do Tufão para o QtCreator, crie um novo projeto usando o template “application“.

Com o projeto criado, extraia o conteúdo dos arquivos baixados para a pasta do projeto e edite o arquivo *.pro do mesmo, de forma que as seguintes linhas sejam adicionadas:

Pronto, você concluiu as etapas iniciais para trabalhar com um projeto usando JSON-RPC 2.0 em C++. A etapa seguinte dependerá se o projeto criado é o servidor ou o cliente.

Preparando um novo projeto (servidor)

Grande parte da “aplicação web” já está pronta, utilizando o “esqueleto” do projeto genérico criado pelo plugin do Tufão. As alterações que você precisa fazer se resumem a criar uma classe para tratar conexões WebSocket e uma classe Handler para ser utilizada pelo RPC.

Comece criando a classe WebServer, que deve herdar de Tufao::HttpServer e deve implementar o método protegido upgrade, que deve ficar assim:

Implemente a classe Handler herdando de QObject e utilizando a macro Q_INVOKABLE na frente da declaração/assinatura dos métodos que você deseja exportar para o cliente remoto.

O último passo é editar o arquivo main.cpp, para que o mesmo utilize a classe WebServer criada. Para isso, só precisa mudar o tipo da variável server dentro da função main, de Tufao::HttpServer para WebServer.

Preparando um novo projeto (cliente)

O cliente tem uma natureza bem diferente do esqueleto genérico de aplicação criado pelo plugin do Tufão e isso requer que você faça mais mudanças que no caso do servidor.

Primeiro, apague as classes (desnecessários para o projeto) NotFound e PluginReloader. Apague também o arquivo de recursos static.qrc e seu recurso associado, notfound.html.

Segundo, apague quase todo o conteúdo da função main, para que se resuma ao seguinte:

Com isso terminaram as remoções necessários do projeto-base. Agora restam as adições, que se dividem em duas partes, relacionadas ao Tufão e relacionadas ao Phobos. Irei comentar o mínimo possível sobre o Tufão, pois o mesmo está bem documentado e torna-se desnecessário que eu faça comentários extras.

Começando pela parte do Tufão, você precisará criar um objeto da classe Tufao::WebSocket e chamar o método connectToHost. Quando o sinal connected for emitido, o objeto estará pronto para ser utilizado.

Do lado do Phobos, você precisará, assim como no servidor, de um objeto Handler, que herde da classe QObject e utilize a macro Q_INVOKABLE na frente da declaração/assinatura dos métodos que você deseja exportar para o servidor remoto (o protocolo JSON-RPC não distingue servidor de cliente e, uma vez iniciada a conexão, ambos podem realizar chamadas remotas, enquanto a camada de transporte permitir).

Invocando métodos remotos

Para chamar métodos remotos, utilize o método JsonRpc::callWith. Os dois primeiros argumentos que ele recebe lembram o método singleShot da classe QTimer, com a diferença que a macro SLOT não cerca o argumento member no método callWith. Os argumentos restantes representam, respectivamente, o nome do método remoto e seus argumentos. Exemplificando:

Be happy

Você pode obter o código-fonte das aplicações desenvolvidas nesse texto aqui.

%d blogueiros gostam disto: