Editando Textile no Geany

Introdução

O Textile é uma linguagem de marcação própria para hypertexto do tipo Wiki. É simples e fácil de usar, sendo muito mais prática do que o HTML. Assim como no Markdown (uma outra linguagem de marcação – veja um post sobre o Markdown aqui), o Textile permite que você se concentre no conteúdo que está escrevendo, e não na linguagem em si. Linguagens como o HTML, requerem que você saiba exatamente quais são as tags que devem ser utilizadas, obrigando o programador a se concentrar muito mais nas estruturas da linguagem do que no conteúdo em sí. É claro que ninguém escreve textos utilizando as tags do HTML, e é por isso que as linguagem de marcação, como o Textile, existem.

Continue Lendo “Editando Textile no Geany”

Dicas para quem está iniciando em “modelagem”

A idéia deste post é mostrar algumas dicas para quem está iniciando a “rodar” modelos, seja realizando testes, seja realizando implementações. Com algum tempo trabalhando com modelagem (no meu caso em meteorologia), você acaba colecionando algumas dicas que podem ser preciosas em diversos aspectos da atividade prática da modelagem. Mas antes de mais nada, vou definir aqui que o termo “modelagem”, se refere à atividade prática (à execução da modelagem) de preparar um determinado sistema ou modelo computacional e seu respectivo ambiante de compilação/submissão, e não necessariamente a modelagem em si – que por si só tem seus desafios. Estas mesmas idéias podem ser facilmente aplicadas a situações mais simples, como por exemplo, desenvolver um programa em linguagem C, fortran ou um script shell simples que automatize algumas tarefas. É preciso ter em mente apenas começar da forma correta, o não o isenta de cometer erros (inerentes ao seu trabalho) e aprender com eles.

Pois bem, quem está começando sempre tem um pouco de pressa, ou por não saber que o processo prático da modelagem é não linear, ou porque é muito apressado e sabe que não tem muito tempo para gerar e analisar os seus resultados. Nesse caso, há um caminho bastante longo e complicado entre “gerar” e “analisar” os resultados. Muitas vezes, gerar os resultados pode parecer um alívio, mas se eles não foram gerados da forma correta, podem lhe trazer muita dor de cabeça. Então, para começarmos, vamos colocar os tópicos desta discussão na seguinte ordem:

  1. Cheguei agora, o que faço?
  2. Certo, agora que já comecei, o que faço?
  3. Deu pau, o que faço?
  4. Deu pau de novo, o que posso fazer?
  5. Acho que agora está dando certo…, o que faço?
  6. Meu primeiro resultado! E agora, o que faço?
  7. Meu tempo acabou, o que faço?
  8. Outras dúvidas…

Certamente, poderiam haver outros “… e agora, o que faço?”, mas com certeza estes sete tópicos são bastante representativos do processo prático da modelagem como um todo e certamente podem lhe ajudar. Portanto, entenda este texto como uma espécie de “auto-ajuda” da prática da modelagem (antes que você tenha que recorrer à alguma ajuda externa) ou um “caminho-zen” para as suas atividades em modelagem.

1. Cheguei agora, o que faço?

Com certeza, essa é a sua primeira dúvida quando não se tem experiência prévia na prática do seu trabalho de pesquisa. Geralmente, a iniciação científica nos serve como uma espécie de laboratório com experimentos controlados em que não se assume a responsabilidade por um determinado resultado, ou melhor, aprende-se – num espaço curto de tempo, a colocar a mão na massa. Mas nem sempre, quem faz iniciação científica, acaba trabalhando com os mesmo temas em pesquisas futuras. Nesse momento, as dúvidas e aflições de quem está começando são, frequentemente, as seguintes: “putz, vou ter que mexer no linux…”, “putz, vou ter que mexer no terminal do linux…”, “putz, vou ter que trabalhar com programação…”, “putz, vou ter que trabalhar com o cluster…”, “putz, vou ter que trabalhar com o supercomputador…” etc. Na verdade, a grande sacada nesse momento é não se aborrecer e nem se preocupar com o tal do linux e seu terminal, até porque – dependendo da área em que você trabalhe, vai acabar percebendo que ao invés dele ser um vilão, ele será a melhor ferramenta com que você vai trabalhar. Dito isto, comece a se preparar fazendo-se as seguintes perguntas:

Se eu vou trabalhar com um modelo computacional ou um programa fortran, ou script do matlab etc, onde ele(s) está(ão)?

Essa é a primeira coisa que você tem que se perguntar. Se isso lhe parecer um pouco óbvio demais, saiba que se você não for cuidadoso(a) a partir daqui, os seus problemas podem começar logo de início. Se você for trabalhar no linux (sendo no seu computador/notebook, em um cluster ou em um supercomputador), com certeza terá que lidar com o terminal. Por isso, pesquise com os seus colegas de trabalho onde pode-se obter o modelo ou programa com que você vai trabalhar. Não se preocupe demais com o terminal e os seus comandos, com certeza você vai aprender praticando.

Sempre, eu eu disse SEMPRE, a melhor situação é quando você pode trabalhar com repositórios (em cvs, svn, git, bazar etc).

Os repositórios são importantes porque permitem que você crie um histórico de alterações e de versões dos seus scripts e rotinas que for trabalhar/criar/modificar. Além disso, ele vai lhe ajudar naquele momento em que você estiver escrevendo um relatório ou em que precisar lembrar de uma determinada data em que modificações ou implementações foram realizadas. Portanto, nessa primeira situação, pergunte a seus chefes, colegas, orientadores se o código com o qual você for trabalhar está em um repositório e em que tipo de repositório. Pergunte também se você pode criar um ramo (repositório) próprio para realizar os seus desenvolvimentos. Com certeza, essa é a melhor maneira de se iniciar o trabalho com códigos computacionais em sistemas e modelos. Para exemplos de utilização do svn, por exemplo (eu aprendi a trabalhar com o svn), leia este post sobre a criação de um repositório svn em sua máquina local (https://craftmind.wordpress.com/2011/04/25/criando-um-repositorio-svn-local/) e este sobre como utilizar o svn (http://samuca.wordpress.com/2007/04/12/tutorial-subversion/).

2. Certo, agora que já comecei, o que faço?

Se você já sabe onde está o código ou modelo com que vai trabalhar, agora é o momento de aprender a instalar/utilizar/testar o seu código. Todo código que tem um desenvolvimento ordenado e, por mais simples que seja, deve ter um README ou um LEIAME com a descrição do programa, notas de versão, bugs conhecidos e – principalmente, como instalar/utilizar/testar. Este trio (instalar/utilizar/testar) é essencial e deve ser seguido antes que qualquer outro tipo de teste seja feito com o código que você vai trabalhar. Procure saber se há uma conjunto de dados de teste (geralmente um conjunto pequeno de dados que permita testar todos os aspectos do programa).

Leia o README, siga as instruções, tire suas dúvidas e quando se sentir confortável o suficiente para começar, inicie o trio instalar/utilizar/testar.

3. Deu pau, o que faço?

Tem certeza de que leu o README por completo? Tem certeza de que não surgiram dúvidas? Se alguém lhe deu uma explicação e você não entendeu muito bem, volte e pergunte novamente. Não se acanhe! Quanto menos dúvidas você tiver sobre o processo de instalar/utilizar/testar, melhor. Assim você poderá se preocupar menos com os aspectos práticos do sistema e mais com os aspectos teóricos da sua pesquisa. Caso todas as informações do README e as instruções que lhe foram fornecidas tenham sido completamente atendidas, então o problema pode ser outro. Será necessário ler todos os logs do sistema e procurar por erros desconhecidos ou que, por uma razão ou outra, ainda não foram relatados.

Inclusive, esta pode ser uma oportunidade para que você colabore com os desenvolvedores do sistema que você está utilizando.

4. Deu pau de novo, o que posso fazer?

Se o problema persiste ou lhe parece ser algo sistemático (que está se repetindo sempre, da mesma forma), pode ser que o problema não seja com o seu sistema, mas sim com a máquina em que está sendo executado.

Lembre-se que assim como o seu computador, qualquer sistema – por mais moderno e seguro que seja, ele é suscetivel a problemas de software e hardware diversos. Se você tiver certeza de que os problemas não fazem parte do seu sistema (dos modelos/rotinas/scripts), entre em contato com o administrador da máquina que você está utilizando.

Se você está utilizando apenas o seu computador, não perca tempo e peça ajuda a alguém mais experiente. Geralmente, problemas de compilação estão relacionados à variáveis de ambiente mal ajustadas e programas que não estão completamente instalados. Se você depende de algum tipo de biblioteca que não é fornecida com o seu sistema, leia este post para uma explanação geral sobre a instalação de programas a partir do código fonte no linux (https://craftmind.wordpress.com/2011/04/25/variaveis-de-ambiente-para-programas-fonte/).

5. Acho que agora está dando certo…, o que faço?

Com muita sorte, as coisas dão certo logo de primeira ou pelo menos nas primeiras tentativas. Se não derem certo de primeira e você teve que queimar uma pouco da sua preciosa mufa para resolver, parabéns: com certeza você aprendeu mais coisas do que esperava. Uma vez que as coisas começam a fluir e a funcionar de forma como tem que ser (ou pelo menos da forma como se espera), fique atento com a performance do seu modelo/programa e veja se os resultados preliminares (on the flie) estão razoavelmente dentro do que se sabe/conhece. Geralmente os modelos computacionais geram saídas de log e erro a partir das quais pode-se acompanhar os valores calculados de uma determinada variável ou o tempo que está demorando para realizar algum cálculo. Observando estes aspectos, você poderá ser capaz de identificar problemas como: valores espúrios, situações fisicamente impossíveis, instabilidade numérica, problemas de paralelismo etc. Este tipo de diagnóstico pode lhe poupar horas, dias ou até semanas de trabalho! Imagine a situação em que um modelo numérico de previsão de tempo é empregrado para integrar uma condição inicial durante sete dias. Atualmente, dependendo de onde o modelo está sendo executado, este trabalho pode demorar de horas a dias e se você não se preocupar em olhar os valores que estão sendo escritos no log do sistema, só vai perceber que alguma coisa está errada no final.

Portanto, fique atento aos logs e aprenda a interpretar os valores e resultados preliminares. Ah, não se engane com as médias!!

6. Meu primeiro resultado! E agora, o que faço?

Ótimo, se você conseguiu chegar até aqui, já deve ter alguma bagagem com coisas interessantes que aprendeu sobre o processo prático da modelagem. No caso dos resultados de modelo, certamente haverá um arquivo final com os valores/campos e, dependendo do sistema empregado, esse arquivo poderá ser convertido para um formato padrão (por exemplo, grib, netcdf, hdf etc) que, além de ocupar menos espaço, já disponibiliza o arquivo final para visualização em um software específico (por exemplo, o GrADS). Geralmente, o conjunto dessas rotinas de conversão é chamada de pós-processamento e geralmente, são feitas interpolações e outros procedimentos matemáticos que podem embutir pequenos erros oriundos de aproximações. Fique atento às fontes de erros nos seus resultados e saiba ponderá-las em sua avaliação. Procure também comparar os dados brutos (antes do pós-processamento) com os dados finais (pós-processados).

Certamente, estas informações podem lhe assegurar um controle e visão melhores sobre os resultados que você obteve.

Ao sinal de qualquer dúvida sobre os resultados gerados, se você tiver tempo, refaça os experimentos e tire suas dúvidas. Além disso, a avaliação estatística e/ou interpretação física dos resultados deve ser feita de forma bastante consistente. Leve em consideração os tipos de avaliação que outros pesquisadores estão fazendo e tente comparar os seus resultados com os deles. Isso ajuda e muito na validação dos seus experimentos e também vai lhe assegurar que a sua metodologia não contém falhas.

7. Meu tempo acabou, o que faço?

Isso vai acontecer e, geralmente no mestrado – em que se tem pouco tempo para executar a parte prática, você pode se desesperar com a qualidade dos seus resultados.

Se você tomar todos os cuidados e rever sempre os seus passos, dificilmente passará por algum problema por culpa sua.

Acredite, erros todos comentem e perder o tempo que se tem para uma determinada tarefa, é o pior deles. Então, tome os devidos cuidados e extraia o máximo que puder do aprendizado da prática de modelagem. Com certeza, numa outra oportunidade, você estará mais calejado e esperto para enfrentar novos desafios e saberá como começar…

Outras dúvidas…

Na verdade, este tópico não é sobre dúvidas, mas sim recomendações. Sempre que você estiver desenvolvendo algo, seja minucioso, documente tudo o que você está fazendo. Se a sua memória é fraca, certamente você estará se livrando de um imprevisto ou de ter que bolar uma solução para um problema que você já resolveu. Para as rotinas e scripts que você escrever, utilize o Doxygen ou o ProTeX para gerar a documentação. É justo com você, porque agrega valor ao seu trabalho e justo com quem vai colaborar ou dar continuidade aos desenvolvimentos que você iniciou. Lembre-se que linguagem de máquina é para máquina, humanos lêem textos.

Se ao escrever a documentação você ficar na dúvida se escreve em português ou em inglês, não exite: escreva em português.

Sempre tem alguém que diz “tem que escrever em inglês porque se houver alguma colaboração de fora, todos têm que entender”. Isso está correto, desde que se saiba escrever corretamente em inglês… não adianta nada escrever em inglês se apenas os nativos procurarem a documentação para ler, e vai ser pior se estiver em inglês mal escrito. Portanto, a menos que alguém se disponha a revisar a documentação, escreva em bom português mesmo. Vale lembrar que a documentação, além de ajudar no entendimento dos seus programas, ajuda também a escrever o trabalho final ou relatório.

Ao escrevermos, sempre confrontamos e revisamos idéias anteriores e fixamos o que sabemos.

Boa sorte!

PS.: Este texto deverá ser melhorado ao longo do tempo.

svn merge (jeito simples)

Fazer um merge pode ser um pouco tenso para algumas pessoas, principalmente quando não se entende bem a lógica do merge no SVN. Na verdade, esse procedimento pode ser bem simples (pare, respire, tome um cafezinho e volte a fazer) ou bem complicado (se você não parar, respirar um pouco e sair para tomar um cafezinho). Sem mais enrolação, aqui vai um jeito bem simples e objetivo de fazer um merge entre dois ramos SVN. Primeiro, vamos desenhar uma situação: temos um ramo trunk (o principal) e um ramo branch (em que estamos trabalhando). Vamos trazer os últimos desenvolvimentos do ramo trunk para dentro do ramo branch, sem perder as nossas implementações (no ramo branch). Queremos que o svn merge apenas traga as atualizações que recebem para dentro do nosso branch.

Para isso, siga os passos seguintes:

1. Checkout do seu branch para a sua área de trabalho:

$ svn co https://endereco.alguma.coisa/projeto/branch/pasta pasta.branch

No comando acima, iremos criar uma nova pasta de nome “pasta” que contém todo o código que queremos atualizar a partir do trunk, utilizando o comando merge.

2. Entre na “pasta” criada e execute o comando svn merge como indicado:

$ cd pasta.branch/
$ svn merge https://endereco.alguma.coisa/projeto/trunk/pasta .

Observe bem que no final do comando svn merge, foi colocado um ponto “.”, que representa a pasta atual (pasta.branch) onde está o código do nosso branch, para o qual queremos trazer as atualizações contidas no ramo trunk do projeto.

Depois de algumas tentativas mais complicadas, essa foi a mais simples e que deu certo.

Pode ser que no seu caso essa solução não funcione como esperado, porque tudo depende de como você está trabalhando com o seu projeto no svn. É importante também ressaltar que, no exemplo dado acima, o ramos trunk contém o código mais atualizado e que, apenas alguma parte do código do ramo branch não existe no ramo trunk, ou seja, nossas criações no branch ainda não foram adicionadas ao trunk e tudo o queríamos eram apenas as últimas alterações do trunk, da parte do código em que não alteramos.

svn diff com outra revisão

Esta é uma dica rápida:

Se você quiser criar um patch das modificações da sua cópia local em relação à uma revisão anterior qualquer, basta utilizar o modificador “-r#”, sendo que # representa um número de revisão.

Exemplo:

$ svn info
...
Revision: 247
...
$ svn diff -r220 > $HOME/teste.patch

Depois, caso queira aplicar um patch na revisão 220, basta fazer um checkout e aplicar da seguinte forma:

$ svn co -r220 http://... TESTE
$ cd TESTE
$ svn info
...
Revision: 220
...
$ patch -p0 -i $HOME/teste.patch

É isso!

Criando um repositório SVN local

Para criar um repositório SVN é fácil. Basta escolher um local da máquina e rodar o seguinte comando:

$ svnadmin create nome_do_repositorio

Com isso, é criada uma pasta de nome “nome_do_repositorio” que é o repositório propriamente dito. Para utilizá-lo, tem que configurar dois arquivos: o svnserve.conf e o passwd. Ambos os arquivos estão dentro da pasta conf, dentro do repositório. No svnserve.conf, temos que configurar as permissões de leitura/escrita, o arquivo que conterá as senhas de acesso e o nome do repsoitório (realm), como se segue:

[general]
 ### These options control access to the repository for unauthenticated
 ### and authenticated users.  Valid values are "write", "read",
 ### and "none".  The sample settings below are the defaults.
 anon-access = read
 auth-access = write
### If SASL is enabled (see below), this file will NOT be used.
 ### Uncomment the line below to use the default password file.
 password-db = passwd
### This option specifies the authentication realm of the repository.
 ### If two repositories have the same authentication realm, they should
 ### have the same password database, and vice versa.  The default realm
 ### is repository's uuid.
 realm = Repositório local

No arquivo passwd.conf, adicionamos os usuários que terão acesso ao repositório, como abaixo:

carlos = carlos.

Para ativar o repositório basta rodar o seguinte comando:

$ svnserve -d -r /pasta/onde/esta/o/repositorio

No comando svnserve, o modificador “-d” é para daemon e “-r” é para indicar onde está o repositírio. Fácil não?