Em muitos países, o Natal é celebrado como tempo de paz. Anteriormente no hemisfério norte, era a celebração da metade do inverno – e a esperança da nova luz a chegar. Hoje, trocar presentes é uma atividade popular na época do Natal. Então, vejamos quais os presentes o LibreOffice deixou embaixo da árvore…. Ah! É certamente um resumo da nossa próxima versão 3.5 :-)

Tentarei desembalar um pouco este presente, olhando através do papel celofane. Eu vejo centenas e centenas de “commits” de código, que falam sobre “limpeza”, “retrabalho”, “remoções”, “easy hacks”. Parece conversa em informatiquês. Mas como então isso é um grande presente de Natal para os usuários? Decidi conversar com alguns desenvolvedores, para tentar conseguir uma explicação sobre o que essa trabalheira toda significa – para os meros mortais, usuários de suite office como vocês e eu ;-) Simplificando, que melhorias, em que áreas, podemos ver agora e a longo prazo, resulta de todo esse trabalho?

Veremos abaixo o que eu descobri. Algumas partes são de cunho técnico, outras falam de novidades para os usuários. Devo ressaltar que só foi possível averiguar uma pequena parte de todo o trabalho e conversar somente com algumas pessoas… Mesmo assim, espero que gostem deste (grande) presente.

Uma parte importante do desenvolvimento de software é o processo de “building” (construção): converter o código-fonte escrito pelos desenvolvedores em algo que você pode baixar e instalar. Mas o building também é importante para os desenvolvedores. Serve para verificar se o trabalho está OK, se funciona como desejado ou para consertar o bug que algum usuário reportou e que não “quebre” outras partes do programa.

Portanto, desenvolvedores precisam fazer seus “builds”. Muitos builds. E rapidamente. É onde Norbert Thiebaud tem uma história pra contar: “Sim, meus esforços são focados em tornar o processo de build rápido e confiável, para conseguirmos tinderboxes boas e confiáveis, com um ciclo rápido e com feedback significativo, permitindo aos demais desenvolvedores ter um feedback sobre as plataformas que não lhe estão ao alcance, sem falar do pessoal do controle de qualidade que conseguem ter buildsregulares e com mais frequência para adiantar seus testes…”

A ultima palavra mágica para isso é “integração contínua”. O código é revisto e inserido (“commited”) rapidamente: idealmente o mais rápido possível. Mas então você precisa de ter um feedback rápido. As tindeboxes que o Norbert se refere são computadores que produzem builds automaticamente, em todos os tipos de plataformas. Então há um servidor de tinderboxes que reporta o status de cada build, diariamente.

Norbert completa: “Significa que eu faço reparos pontuais para fazer com que minhas tinderboxes fiquem verdes :-), i.e. que funcionem corretamente, de forma que o servidor mostre um sinal verde de OK. Estamos progredindo muito com as tinderboxes. Neste mês de dezembro, estamos fazendo mais de 100 builds por dia. Em abril passado eram só 30!”

Lionel Elie Mamane,, que falará mais tarde sobre o Base, também contribuiu no campo dos builds: “Nos primeiros dias que comecei a fazer buildsdo LibreOffice, tropecei em algumas coisas que me aborreciam no sistema do config/build, então resolvi consertar isso”.

“Um dos aborrecimentos era que o arquivo do conector do MySQL devia ser baixado depois que a configuração acabava, e esta falhava justamente por que o arquivo ainda não tinha sido baixado. Era uma situação de ovo-ou-galinha :) e agora que eu consertei isso, há uma nova experiência de “primeira viagem” para os novatos.

“Outra coisinha envolveu acabar com a criação desnecessária de vínculos simbólicos (ou seja, melhora a velocidade do build), e permitir cores na saída (de informações) do build para 256 valores, ao invés do antigo padrão de 16 cores. Torna o desenvolvimento mais fácil, por que os erros de compilação ficam coloridos na tela”.

Builds que viram releases devem claro ser bons builds. Petr Mladek nos diz como isso funciona: “A maior parte de meu trabalho é relacionada a produzir todos os build oficiais, ou seja, resolvo problemas do build. E também é claro, muitas outras coisas relacionadas ao build. Como só havia um build oficial a cada semana, eu gastava muito tempo com ele. Além disso, ajudei a integrar scripts muito úteis no antigo repositório de builds. Eles ajudam os mantenedores de pacotes a oferecer o LibreOffice para as diversas distribuições Linux. Havia muito mais gente nos ajudando nisso”

Já que os buildstambém são usados pelos voluntários do controle de qualidade, um trabalho especial foi feito para eles.. “Um dos itens foi consertar os pacotes Linux, permitindo que os releases da versão 3.x possam ser instalados em paralelo. Isso é muito útil especialmente pelos testadores, mas também pelos usuário normais. Adicionei também uma informação de versão mais precisa, e.g. Beta2, na caixa de diálogo “sobre”. Isso deve ajudar os testadores e usuários a descreverem melhor a aplicação instalada e fornecer reportes de bugs mais precisos.

Agora, algumas palavras de Olivier Hallot, um dos fundadores da The Document Foundation: “O código do LibreOffice era um desafio para mim desde os tempos do OpenOffice.org. Consegui compilar e o próximo passo foi naturalmente experimentar um dos easy-hacks sugeridos pelos desenvolvedores. Achei esses easy-hacks a melhor maneira de se familiarizar com a programação C++, e comecei a consertar alguns defeitos da interface do usuário que encontrei no meu idioma. De um simples hobby a um trabalho mais sério, hoje estou envolvido na melhoria do LibreOffice. Ha muita diversão nisso!”

Desenvolvimento facilitado… bem, o mais fácil possível. Tor Lillqvist é um dos desenvolvedores que trabalhou nisso: “Limpei muitos bits e pedaços de código obsoletos. Isso torna mais fácil começar a desenvolver, pois há menos coisas obsoletas ou irrelevantes que só nos fazem perder tempo.”

Parte do trabalho do Tor é relacionado à compilação cruzada: “A compilação cruzada torna possível desenvolver em um computador veloz coisas destinadas a um computador mais lento, ou em uma máquina que não roda um sistema operacional de desktop. Assim, hoje, no Linux, você pode produzir um executável para Windows, se bem que ainda não temos um instalador. O pessoal da Lanedo está trabalhando nisso.”

Apesar de não ser relacionado a essa entrevista sobre limpeza e melhorias, Tor também quer acrescentar algo diferente: “Sim, a parte da compilação para Android e IOs já terminou, faz alguns dias. Mas cuidado: não significa que temos uma versão capaz de rodar nesses dispositivos. Somente que as pessoas interessadas em trabalhar na interface do usuário podem agora ter uma base sólida para seus trabalhos.”

Lionel Elie Mamane também fez alguma coisa na limpeza do código-fonte: “Removi const cast desnecessários e variáveis sem utilização, … Isso torna o código mais fácil de manter, fácil de entender, etc… Const cast são ‘buracos’ cavados nos recursos de segurança do C++, ou seja, removê-los quando não servem pra nada nos ajuda a pegar futuros erros de programação,”

Uma limpeza em especial foi a do antigo driver para PostgreSQL do OpenOffice.org. “Isso estava podre. Só funcionava na versão 3.2.. Então eu refiz o driver, integrei o driver nativo LibreOffice – PostGreSQL no LibreOffice, melhorei ele e trouxe-o para a última versão do LibreOffice. Obviamente, há muitas vantagens para o acesso ao PostgreSQL.”

Se você quer tornar a vida mais fácil para desenvolvedores em tempo parcial, estudantes, novatos e demais a trabalharem no código-fonte, então uma boa legibilidade do código é uma grande ajuda. Há muitos exemplos. Olivier nos fala sobre um easy hack que objetiva substituir testes de strings dentro do código-fonte: “Anteriormente, para testar quando uma string era vazia, tínhamos de obter o tamanho da string. Se fosse zero, era vazia. Recentemente, um novo método isEmpty() foi escrito para o mesmo propósito. A tarefa é então substituir o método getLength() pelo método isEmpty() em todo o código: uma tarefa laboriosa. Mas o resultado desta refatoração é uma legibilidade muito melhor do código-fonte”.

Enquanto outros trabalham na limpeza geral do código-fonte, o trabalho de Miklos Vanja na limpeza e substituição é focada em uma área. Miklos afirma: “Nos dois últimos verões trabalhei rescrevendo os filtros RTF. Tanto o de exportação quanto o de importação eram códigos antigos, com limitações de projeto conhecidas. Então era hora de refazer e criar novos filtros. O de exportação foi renovado na versão 3.3, e o de importação será novo na versão 3.5. Agora vai ser possível acrescentar novos recursos em nosso RTF, que faltavam faz um bom tempo, tais como o suporte a tabelas aninhadas, introduzido no RTF do Word 2000”.

Miklos sempre pede para receber exemplos de documentos (RTF) que não sejam bem tratados pelos novos filtros, para melhorar mais ainda a importação.

Melhorar os testes, especialmente no Calc, também vale uma nota aqui. Markus Mohrard trabalha nisso: “Uma das áreas em que eu estive muito ativo é no trabalho da automatização dos testes. Isso realmente torna o trabalho dos desenvolvedores mais fácil, e reduz o risco de introduzir bugs em funções novas ou modificadas. Nossos testes de filtros do Calc são um jeito particular de descobrir bugs bem cedo. Eles nos apontaram em torno de 15 bugs muito graves, e pelo menos dois bugs muito antigos no coração do LibreOffice. Pelo número do bug, sabemos que são na maioria bugs novos que provavelmente não foram resolvidos no OpenOffice.org, e alguns são bugs nossos mesmo.”

Markus indica que são testes novos, rápidos e confiáveis, e são executados durante o ciclo de compilação dos desenvolvedores – assim sabemos que, se compilar, não terão essas regressões. Ele enfatiza que não é só importante, mas é também muito fácil, estender os testes!

“O que fiz foi baixar todos esses ods, xls, xlsx dos muitos bugs do bugzilla e os utilizei nos testes de filtros para checar se um desses arquivos quebrava o Calc na importação, ou durante os cálculos iniciais do conteúdo. Isso apontou um novo conjunto de bugs que Kohei, Eike e eu consertamos antes de criar o ramo 3.5. Mais de 4000 documentos foram checados com esta abordagem, e que melhorou muito o 3.5”

Outro desenvolvedor: “Removi código sem uso e consertei alguns bugs, principalmente os que foram introduzidos na (versão) 3.4, e alguns no mestre que sequer foram notados, ou mesmo reportados”. Quem nos diz isso é Eike Rathke.

Eike Rathke é um desenvolvedor “da antiga” que conhecemos desde os tempos da SUN/OpenOffice.org. Ele começa falando de suas férias: “O verão foi tão pobre em julho e agosto que eu resolvi a trabalhar no LibreOffice ;-). Acabei contratado pela Red Hat em outubro, na segunda feira logo após a conferência do LibreOffice. Uma das coisas que eu refiz desde então foi a classe “Date, Time e DateTime”. No código antigo, o tempo do sistema era obtido toda vez que a classe era construída. Isso é desnecessário só para declarar uma variável. Junto com a verificação e a atualização, isso resultava em inúmeras chamadas inúteis ao sistema, que agora só acontecem em 130 das 350 ocorrências. Penso que removi um zilhão dessas chamadas ao tempo do sistema :-). lamento mas não tenho os números reais disso”

“Claro que também consertei muito mais código, com bugs reportados ou não, sobre os quais Moggi-Markus Mohrhard falou a respeito. E integrei algumas correções das CWS do Apache OpenOffice que ainda estavam em LGPL, e apliquei ou integrei alguns patches. Também ajudei o Moggi a melhorar o tratamento de expressões e intervalos nomeados, especialmente com nomes locais nas planilhas e o comportamento da (operação de) copiar e colar”

Indo para o Base, Lionel tem muito a nos dizer: “No geral, eu diria que eu foquei em tornar o Base (com macros) utilizável de novo, por que eu quero usá-lo no meu trabalho do dia a dia, para substituir o Microsoft Access em programas de negócios que desenvolvi no passado. E no começo da (versão) 3.4 ele estava muito problemático. Consertei também alguns bugs visíveis pelo usuário, por exemplo, as margens nos relatórios, sintaxe melhor e mais padronizada para relatórios baseados em consultas com ordenação, consertei muitos crashese a exportação para PDF.”

Talvez o mais importante de tudo foi que reativei o ADO (ActiveX Data Objects) no Windows; sendo uma outra “common API” para acesso a banco de dados SQL”. Ele fez também melhorias nas senhas, nos metadados, nas consultas e nos joins: “ Com meu trabalho no LibreOffice, eu ‘soprei na minha ferida’, e cuidei de bugs e features que eu achei que fosse o único interessado e/ou competente: coisas de banco de dados!”

Lionel enfatiza que a comunidade LibreOffice foi excepcionalmente acolhedora e ágil em reconhecer seus esforços.

[Deixe-me (o reporter) notar que parece legal a ideia de ter um post com mais detalhes do trabalho do Lionel]

Olivier Hallot gostou de passar algum tempo em muitos easy-hacks, resultando em uma melhor usabilidade, melhor interface, etc..

“Um dos hacks é sobre uma melhoria na caixa de diálogo do gerenciador de extensão. Agora o usuário pode filtrar as extensões instaladas, clareando o diálogo e facilitando a busca por uma extensão instalada. Outro bem fácil foi acrescentar o comando Proteger planilha no menu de contexto da guia da planilha. Eu também acrescentei 8 novos símbolos matemáticos, utilizados nas equações em teoria dos jogos. A demanda veio de um professor de matemática de uma universidade.”

Uma das partes interessantes do LibreOffice é claro, é a localização. Ás vezes isso resulta em strings muito maiores que as em inglês, que o texto não cabe… Olivier: “Então eu fiz muitos ajustes nas caixas de diálogo, para acomodar as strings que não eram em inglês, que são maiores e estavam truncadas na interface do usuário” Outro exemplo de legibilidade melhorada

Então… Que presente de Natal! E isso é só um pequeno apanhado de uns poucos hackers que conseguimos arrastar pra fora da tarefa de consertar os bugs dos betas da (versão) 3.5 – Há muito mais melhorias e bem visíveis – que você pode ver na página wiki da (versão) 3.5.

Cor Nouws

Fonte: http://blog.documentfoundation.org/author/tdfsc/

Tradução voluntária: Olivier Hallot