Tradução, Subversion e as primeiras percepções
Aproveitando o tempo chuvoso, neste fim de semana dei sequência à tradução do livro “Version Control with Subversion”. Infelizmente o tempo está curto, mas reservei um dia por semana para esta tarefa.
No começo pareceu mais difícil do que eu esperava, afinal eu NÃO FALO inglês, apenas leio e escrevo, e isso tem se mostrado suficiente para a tradução.
Na verdade estou me divertindo com isso e descobri que traduzir me relaxa. Provavelmente, é porque o livro em si é muito bem escrito. O texto é bem claro e gostoso de ler, tornando a tradução uma mera consequência de entendê-lo.
No fim das contas estou ao mesmo tempo aumenando meu vocabulário e aprendendo os fundamentos do Subversion. To comprando dois pelo preço de um.
Espero continuar nesse pique e entregar com antecedência o capítulo, que já está 25% traduzido.
Quem paga a conta do suporte?
Eu estava lendo um artigo do Fábio Telles onde ele contava a história de um cliente que ficou na mão com seu fornecedor de ERP porque o mesmo não dava suporte a novas versões do postgresql. O texto é bastante interessante e aborda a questão do suporte proprietário versus o suporte “livre”.
O “suporte livre” do meu ponto de vista, tem grosseiramente duas conotações, uma a do suporte a software livre, fornecido por empresas, e que é pago, e a outra, do “suporte gratuito”, fornecido em fóruns e listas de demais. O suporte “proprietário” seria o suporte fornecido por empresas, para soluções proprietárias.
Eu não pretendo insinuar que um modelo é melhor que o outro, nem fazer comparativos. Cada modelo é adequado a seu próprio nicho e ponto final. Eu vou discorrer apenas sobre um (dentre muitos) dos aspectos do “suporte” em listas e fóruns.
Pra começo de conversa, lista de email e fórum, nunca tiveram pretensão de ser suporte, ou estou errado? O objetivo de ambas é serem um espaço de troca de informações, ajuda, mas não suporte. Se uma ou outra tomou esse rumo é porque teve público e se adequou ao nicho. Ótimo.
Eu fico pensando: se as empresas cobram pra dar suporte, provavelmente ele tem um custo. Daí eu me pergunto: Quem paga os custos do suporte “gratuito”? Aqueles caras da lista então são uns bobões que dão suporte de graça? Se eles são tão bons, por que é que eles não cobram por isso?
Pois bem, “não existe cerveja grátis”. Quando uma empresa contrata um analista ou técnico de suporte para lhe prestar serviço, esse profissional possui um determinado custo por hora. Naturalmente, todos que trabalham, de uma forma ou de outra, acabam cobrando um “valor/hora” por seu trabalho e/ou tempo. Toda vez que um profissional de TI dá uma dica num fórum ou lista de email, o tempo que ele gastou desde a formulação do texto até o submit final, se converte em investimento. Mesmo que o post esteja errado, outras pessoas vão corrigi-lo, cedo ou tarde. Dessa forma, a informação flui em duas vias, vai e volta. Toda vez que a informação volta, o investimento se converte em valor agregado.
Do ponto de vista do profissional de TI, a grosso modo, toda vez que eu posto algo numa lista ou fórum, eu estou pagando com o meu tempo e o meu valor/hora pelo suporte que a lista me dá. Toda vez que eu utilizo uma dica da lista, eu estou sendo cliente. O interessante é que nesse contexto, quem paga o suporte é quem dá o suporte. Em troca, eu obtenho da lista experiência, know-how e prestígio, que é utilizado no mundo real para incrementar a carreira.
E quem não posta na lista? Está dando calote?
Tecnicamente, não. Ninguém é obrigado a postar nada, todos são voluntários, e eu já ouvi alguns motivos para não postar, tais como:
“Ah, não sou tão bom para postar.”, ou “Já responderam à pergunta, se eu postar serei redundante”, entre outros. Realmente ambas válidas, nada como o bom senso. Na minha opinião seria anti-ético apenas, não contribuir com a intenção de levar vantagem, o que acaba sendo um tiro no próprio pé, visto que o retorno nunca vem…
Enfim, o suporte “gratuito” também é pago, por mais paradoxal que possa parecer. É um custo pequeno que agrega um valor enorme, mas isso não livra a sua empresa de ter na lista de despesas um profissional competente, seja de uma empresa especializada em suporte ou da sua própria equipe de TI.
Iniciando no QT, parte I
Atendendo a pedidos, resolvi fazer breve artigo mostrando com começar a se aventurar com o QT.
Em apanas 20 linhas, contando com as de espaço (sim, o espaço é seu amigo, nunca o abandone) e os cabeçalhos extras, podemos fazer um “Hello World” gráfico, que já utiliza as principais funcionalidades do framework.
Como eu não tenho como testar em outras plataformas, estou assumindo que a plataforma utilizada é algum *nix, e que as bibliotecas de desenvolvimento do QT já estão instaladas, bem como as ferramentas de compilação padrão. Caso o QT não esteja instalado, é hora de dar uma olhada neste link.
O código fonte completo do exemplo pode ser baixado aqui, mas se preferir fazer tudo na mão, crie um diretório qthello num lugar qualquer e dentro dele um arquivo chamado main.cpp com o seguinte conteúdo:
01 #include <qapplication> 02 #include <qwidget> 03 #include <qpushButton> 04 05 int main( int argc , char** argv ) 06 { 07 QApplication app( argc , argv ); 08 QWidget window; 09 QPushButton button( "Hello World!" , &window ); 10 11 window.resize( 300 , 200 ); 12 button.setGeometry( 100 , 85 , 100 , 30 ); 13 14 QObject::connect( &button , SIGNAL( clicked() ) , &app , SLOT( quit() ) ); 15 16 window.show(); 17 return app.exec(); 19 } 20
Agora acesse através de um terminal o diretório criado e digite qmake -project.
Se tudo estiver instalado direitinho, um arquivo chamado qthello.pro deve ter sido criado. Se não houver nenhum qthello.pro no diretório, então revise os passo anteriores.
Com tudo acertado digite no terminal qmake && make. Isso irá compilar o exemplo e se tudo deu certo, um arquivo executável chamado qthello foi criado.
Execute-o com ./qthello e uma janela com um botão deve aparecer.
Ok, vamos agora à parte divertida: o código fonte.
As três primeiras linhas apenas incluem os cabeçalhos referentes às classes do QT que vamos utilizar.
A linha 7 declara uma aplicação QT e passa pra ela os parâmetros recebidos do shell pelo programa. A classe QApplication gerencia o fluxo principal do programa e suas configurações. Ela contém o loop principal de eventos, onde todos os eventos vindos tanto da interface quanto de outras fontes são processados e despachados. Ela também gerencia a inicialização e finalização do programa entre outras coisinhas.
A linha 8 declara um widget que será o nosso elemento gráfico principal.
A linha 9 declara um botão com o texto “Hello World!” e torna o mesmo um “filho” do nosso widget principal. Isso fará com que o botão apareca dentro do widget principal.
As linhas 11 e 12 configuram os componentes quanto à forma e posicionamento.
A linha 14 mostra uma das principais funcionalidades do framework, o Sistema Sinal-Slot.
Sinais e slots são utilizados para realizar a comunicação entre os objetos. Através desse sistema um objeto pode disparar (emit) um evento (sinal) que pode ser capturado e processado por um (ou mais) objeto(s). Sinais e slots são métodos especiais da classe. Basicamente, a emissão de um sinal é traduzida para a chamada ao slot correspondente através do moc (meta-object compiler), que pré-processa o código fonte antes da compilação. Para cada classe que implementar sinais e slots, é gerado um arquivo chamado moc_nomedaclasse.cpp, que depois é compilado junto com o restante do código. Isso tudo é feito de forma transparente e o programador, em geral, não precisa se preocupar com esses detalhes. Em termos práticos, emitir um sinal signigica que o slot associado a ele através de um connect será chamado de alguma forma, com os mesmos parâmetros passados ao sinal. Maiores informações podem ser conferidas na documentação on-line.
No nosso exemplo, o connect associa o sinal clicked() do objeto botão, com o slot quit() do objeto aplicação. Isso significa que ao clicar no botão, um sinal é disparado e posteriormente capturado pelo objeto aplicação, que o processa e então finaliza.
Na linha 16, chamamos o método show() do widget, para que ele se torne visível.
Na linha 17, finalmente passamos o controle do programa para o QT. O método exec() vai disparar o loop principal e todos os seus mecanismos, e só retornará quando a aplicação terminar, no nosso caso, quando app.quit() for chamado através do sistema sinal-slot.
Este simples “Hello World” pode parecer bobo, mas é suficiente para demonstrar algumas das principais funcionalidades do QT, como o main loop, a criação de objetos gráficos e o uso de sinais e slots.
Num próximo post eu vou mostrar com criar nossos próprios sinais e slots e o uso de temporizadores.
Referências:
QApplication
QWidget
QPushButton
Sinais e Slots
Construindo um gerenciador de interface simples para sistemas multi-janelas com QT
Em diversas ocasiões acabei tendo que dar manutenção em interfaces de sistemas com muitas telas, sejam elas gráficas ou em modo texto. Muitas vezes, a quantidade de telas foi crescendo junto com o sistema sem um planejamento prévio, o que sempre levava a um emaranhado de chamadas obscuras, #ifndefs, switches, entre outros monstrinhos.
A primeira vez que eu me deparei com um problema do gênero, foi quando eu estava fazendo a primeira versão de um jogo parecido com o saudoso Elifoot para uma feira no CEFETES. Na época eu me deparei com um conjunto de funções onde elas chamavam umas às outras e só retornavam quando acontecia o gol. Resultado: haja pilha!!! (Não se preocupem, na nova versão isso foi corrigido!)
No caso das interfaces, com várias janelas, e em sistemas onde o planejamento ocorre on-the-fly, é comum termos janelas que chamam outras janelas que fecham as janelas anteriores e assim por diante, deixando pra trás um rastro de destruição e terror. Acredite, você não vai querer nunca dar manutenção num treco desses.
Do pó ao pó…
No meu caso, resovi o problema criando um gerenciador de interface. Um objeto centralizador que controla a criação e destruição dos objetos de interface. Cada objeto, ao terminar suas tarefas, sinaliza para o gerenciador e ele cuida de limpar a sujeira. Assim, um objeto sempre nasce, realiza suas tarefas e morre sem passar o controle do programa para frente, ele sempre volta para o gerenciador.
Note que eu não disse que o gerenciador vai destruir o objeto, mas sim que ele vai fazer a limpeza. Cada objeto tem que ser construído de forma a avisar ao gerenciador toda vez que ele terminar, seja com sucesso ou falha. Muitas vezes o próprio objeto é capaz de “se matar” sozinho e isso é muito útil, tirando um pouco do trabalho do gerenciador, mas não o controle.
Before starting
Eu não tenho a pretensão que esse simples post cubra todos os recursos do QT ou todos os aspectos do gerenciamento de interfaces. Eu apenas vou falar de como EU resolvi um problema pelo qual eu passei. Esse post também é uma homenagem a um amigo paulista-carioca que já teve que descascar um abacaxi desses!
Mão na massa
Eu sou, na maioria das vezes, um programador bottom-up, porém um analista top-down. Isso pode parecer confuso, mas não há razão para pânico, ou quase…
Os objetos precisam trocar mensagens. Para isso o sistema de sinal-slot do QT vai ser de grande ajuda. Os objetos vão mandar sinais ( emit(signal) ) e o gerenciador vai escutá-los ( slots() ).
Por incrível que pareça, o construtor do gerenciador, daqui pra frente chamado de UIM, não possui uma linha de código sequer. Ele apenas inicializa os ponteiro com 0, apenas por paranóia (ou não)…
O UIM implementa slots para criação dos objetos e limpeza da bagunça. Ao criar um objeto, o UIM conecta esse objeto ao seu respectivo slot de limpeza. Quando o objeto morre, ele ativa o slot de limpeza no UIM. Os slots de criação serão ligados aos menus do objeto gráfico principal, neste exemplo, uma janela.
Os outros objetos são janelas menores, dialogs, sendo um para configuração do aplicativo, e dois pra falar de si mesmo (about), afinal, marketing é importante…
Todos os objetos gráficos eu cliquei e arrastei no Qt Designer e depois ajustei pra ficar do meu jeito. Nada de ficar alinhando pixel na mão, afinal não é uma obra de arte, é só uma prova de conceito.
Os Objetos Gráficos
A tela de configuração é um diálogo comum com um combo-box onde está uma lista de parâmetros a serem passados para o widget principal. Os detalhes que eu acrescentei ao código gerado pelo Qt Designer foram um destrutor, e um par sinal-slot para enviar os dados selecionados de volta para o gerenciador. Eu não me preocupei em guardar o estado da configuração atual. Isso é papo pra outro post.
Os abouts ficaram basicamente com o mesmo código, acrescidos de destrutores.
A janela principal, possui um menu que chama as outras janelas e um widget maluco cheio de quadrados que ficam piscando. A quantidade de quadrados é a informação que será alterada pela janela de configuração.
The Magic QT
Todos o objetos gráficos utilizados, são também QWidgets, pois suas classes herdam da classe QWidget, e eu utilizo em cada construtor o seguinte método herdado:
this->setAttribute( Qt::WA_DeleteOnClose , true );
De acordo com a documentação on-line, isto diz para o QT que ele deve deletar o widget quando ele for fechado. Do contrário, ele será apenas escondido.
“…When a widget accepts the close event, it is hidden…”
“…If you want the widget to be deleted when it is closed, create it with the Qt::WA_DeleteOnClose flag. This is very useful for independent top-level windows in a multi-window application…”
As rotinas que fazem os objetos terminarem com falha, como clicar em Cancelar ou Fechar, estão diretamente conectadas aos seus próprios slots close(). Isso dispara uma série de eventos que culminam com a destruição do objeto.
As rotinas que fazem o objeto terminar com sucesso, como clicar em ok e enviar os dados, foram direcionadas a voltar para o UIM, para que ele possa roteá-las. Depois de pegar os dados, o UIM chama diretamente o slot close do objeto().
Quando um objeto é destruído, ele emite seu último suspiro, digo, sinal que é o destroyed(). Literalmente ele grita “FUI!!!”.
Do “lado de fora” do objeto, o UIM está ouvindo, conectando este sinal à rotina de limpeza, e TADÃM!!!! prontinho.
No exemplo que eu usei, a quantidade de quadrados na tela chega de um objeto MyConf, passa pelo UIM e é roteada para a MyApplication. Esta por sua vez, repassa para o widget maluco interno.
Pra ficar ainda mais interessante, enquanto uma janela menor está aberta, o widget pára de piscar, retornando quando a janelinha for fechada. Parece bobo, mas isso foi só pra mostrar que o UIM tem controle total sobreo o que acontece em cada janela, estando ela em foco, ou não.
Conclusão
O framework QT é imenso e fornece uma gama enorme funcionalidades. Uma delas é poder controlar como os objetos são destruídos. Utilizando isso junto com um pouco de planejamento e aliado ao sistema de sinal-slot podemos construir uma interface bastante complexa, sem transformá-la num Tarrasque na hora de dar manutenção.
Fonte:
P.S.: O Código fonte completo do exemplo encontra-se sob a GPL e pode ser baixado por este link. Um dia eu ponho comentários nele…
BUGFIX
O infeliz do inseto se escondia na falta de inicialização de propriedades no construtor da classe MySquares. O bichinho, apesar de pequeno era venenoso, visto que causava uma ‘Segmentation Fault’. Ao iniciar o programa, se eu fosse em qualquer about e o fechasse, isso disparava uma sequência de eventos que partia do pressuposto que a tela já estava devidamente configurada. O código corrigido encontra-se no link acima, e lembre-se:
“Sempre inicialize suas variáveis”
Aventureiros do livro perdido
Recentemente fui acometido pela necessidade/vontade de escrever umas classes em C++ para abstrair complicações do IPC SystemV no Linux, mas essa história eu conto depois. O motivo desse post é que pesquisando em diversas fontes fui parar denovo no excelente repositório de on-line de documentação tldp.org. Lá encontrei um livro que foi de grande ajuda chamado “The Linux Programmer’s Guide”.
Fiquei muito surpreso no entanto, ao ver que o livro não é atualizado desde março de 1996, ou seja, a praticamente 12 anos, estando listado na categoria Unmaintained. Não tive dúvidas, juntei uns amigos e estamos tentando conseguir autorização para atualizar o livro.
Basicamente são quatro os passos que o TLDP sugere para conseguirmos a autorização:
- Tentar contatar os autores originais;
- Determinar se já existe uma versão mais novo do livro ou outro documento que cubra o assunto;
- Entrar em contato com o TLDP para evitar duplicações;
- Enviar para o TLDP o documento com as modificações pretendidas para revisão;
Curiosamente, o segundo passo foi feito primeiro. Em uma pesquisa na net, vimos que não há referências novas ao título, exceto por uma tradução para o Polonês que data de 2000. No próprio TLDP, não encontramos outros documentos que abordem a programação geral para o ambiente GNU/Linux em um guia único.
O segundo passo, foi então o primeiro (!?). Tentamos entrar em contato com os autores originais B. Scott Burkett, Sven Goldt, John D. Harper e Sven van der Meer and Matt Welsh através dos emails no próprio livro e por referências aos seus nomes na internet.
Até o momento ainda não obtivemos respostas, visto que como esperado, todos os emails antigos constantes no livro voltaram com um carinhoso UNDELIVERED. Resta aguardar que os emails conseguidos na internet possam alcançar os destinatários corretos e retornar com boas notícias. Até lá estaremos torcendo e nos preparando para uma possível re-edição do “The Linux Programmer’s Guide”.
3º Sampa C/C++ Users Groups – Meeting, eu fui!!!
Neste último sábado, dia 19/01/2008, foi realizado no auditório da APEOESP o 3º Sampa C/C++ Users Groups – Meeting, Um encontro de programadores C/C++ de vários lugares o Brasil.
Tivemos palestras muitos interessantes como “C++ com WxWidgets” com Ivo Nascimento, que apresentou o WxWidgets como alternativa para desenvolvimento de interfaces gráficas multiplataforma, e outras focadas nos novos recursos que serão votados pela ISO em 2009, apresentadas por Pedro Lamarão e Wanderley Caloni.
Contamos ainda com a presença da AGIT que nos deu uma grande força e com o pessoal da Trolltech do Brasil que cedeu alguns brindes sorteados durante o evento.
Após as palestras realizamos um debate sobre o passado, presente e futuro do grupo, onde discutimos sobre diversos projetos e sobre a conferência a ser realizada no final do ano.
Depois de tudo isso fechamos com chave de ouro realizando o “C/C++ Beer Meeting” ali pelas redondezas mesmo.
Ajudando a traduzir o livro “Version Control with Subversion”
Depois de ser muito chato e insistente, nesta hoje eu finalmente consegui autorização para ajudar o grupo de tradutores do livro “Version Control with Subversion”.
O processo de tradução estava meio parado, sem atualizações desde a versão 1.2, e já estamos na versão 1.4. Demos uma movimentada na lista de discussão e o pessoal parece que pegou no tranco.
Turma animada, lista fervendo, não perdi tempo, peguei logo o capítulo 1 “Fundamental Concepts”, e já comecei o trabalho. Já no começo, vi que é mais difícil do que eu pensava. Não esperava menos, mas este é um desafio que eu tenho certeza que conseguiremos superar.
O que mais me surpreendeu é que os envolvidos no projeto estão espalhados pelos quatro cantos do país, mas parece que somos todos vizinhos. Sem barreiras, sem fronteiras. Êita globalização!!!
A página oficial da tradução para português do Brasil, ainda desatualizada, pode ser encontrada neste link.
Translator
