Amigos, primeiramente peço desculpas pela minha ausencia (ultimo post foi em abril) nesses quase três meses. Estou colocando alguns projetos em dia, revisando algumas monografias de ex-alunos meus do Brasil que estão para finalizar seus cursos, então está uma correria. Nesse meio tempo tenho estudado muitas coisas novas, tenho entrado no mundo do .NET Framework 3.5. Espero em breve estar postando aqui minhas descobertas sobre Silverlight + wcf +Linq + wwf + ajax + asp.net extensions + rest + ... + tudo que voce possa imaginar.
Nesse meio tempo eu tive que fazer uma alteraçao em um sistema da empresa. A missao era fazer uma pagina de web parts. Até ai sem problemas pois o asp.net 2.0 ja vem com os controles nativos para voce trabalhar com o conceito de web parts sem stress. O problema é que esse parte sem stress se aplica somente quando salvamos as web parts no Sql. No Oracle, temos que codificar um pouco mais. Felizmente a MS usou o padrao Provider para abstrair as operacoes de ir ao banco com as operacoes de manipular e exibir as web parts em si. Para isso precisamos codificar nosso proprio provider para gravar o estado das web parts no Oracle. Para compartilhar com a comunidade eu escrevi um artigo que ensina como fazer esse provider e publiquei no site Linha de Código (www.linhadecodigo.com.br).
Segue o link do artigo: http://www.linhadecodigo.com.br/Artigo.aspx?id=1896
Normalmente eu publico o texto aqui no blog tb, mas esse ficou muito grande (calma , nao é complicado só está bem explicadinho ;-) ).
Have Fun!
Showing posts with label Artigos. Show all posts
Showing posts with label Artigos. Show all posts
Saturday, July 5, 2008
Friday, March 7, 2008
Artigo: Dicas sobre promoçao de código entre ambientes
Ultimamente tenho trabalhado muito com a questão de ambientes e principalmente a promoção de código. Se por um lado nós progamadores não somos promovidos com tanta velocidade, o código no entanto, muitas vezes é promovido mais rápido do que deve. (piadinha de TI sempre é complicado, mas essa ficou engraçadinha vai, voce pelo menos pensou: putz não acredito que ele escreveu isso). O código sai da nossa maquina para um ambiente de homologacao (QA) e em seguida para a produção. Em alguns lugares há outros ambientes envolvidos. Cada ambiente é um ecossistema diferente , com configuracoes, permissões, softwares, componentes , enfim tudo pode ser diferente e mesmo assim o código "tem" que rodar e se moldar ao ambiente onde está. Bem esse tem sido o foco dos meus estudos ultimamente.
Relacionado a isso tenho usado um elemento que muita gente não conhece ou conhece mas não aproveita todo o seu poder. Eu, por exemplo, começei a dar mais atenção a isso há não muito tempo atrás.
Bem todos voces ja viram que ao lado do "Play" para rodar a aplicacão no Visual Studio.NET , há uma combo onde você define se voce vai rodar em modo Debug ou Release, também conhecido como Solution Configurations. Podemos tirar vantagem disso ao invés de lotar nosso código com chaves do web config. Basicamente o modo em que estamos compilando define quem estará utilizando a aplicação. Basicamente existem dois perfis macro de pessoas que podem ter algum tipo de contato com aplicação: aqueles que estão construindo a aplicação e aqueles que utilizam a aplicação. Nao confunda com perfil de usuário, que são as formas de um usuário acessar, mas são todos usuários finais do sistema. Porém, um desenvolvedor constrói a aplicação mas precisa testar como se fosse um usuário em muitos casos. Algumas vezes é possivel criar um usuário no banco de dados e dar algumas permissões e fazer o desenvolvedor utilizar essa conta e a aplicação se comportará exatamente como um usuário final. Mas quando a complexidade do ambiente aumenta fazer isso fica complicado. Por exemplo, imagine que voce tem um relatório que só pode ser acessado por usuários do grupo gerência do Active Directory. Um desenvolvedor programa essa funcionalidade que verifica o grupo do usuário logado na master page e o outro programador faz o relatório usando a master page. Como nosso pobre amigo que está programando o relatório poderá testar o seu código se ele não consegue mais acessar a página? Podemos resolver isso de várias formas, algumas bonitas outras nem tanto. Um solução que eu considero bonita é usar o recurso de Debug/release para diferenciar quem está pilotando a aplicação. Funciona assim: se estou rodando em debug mode significa que eu sou um desenvolvedor entao a aplicação não precisa verificar se eu faço parte do grupo de gerência ou não. Uma vez meu relatório pronto, eu posso rodar em release mode, que significa como a aplicação irá se comportar para os usuários. Eu acho que dessa forma o processo de desenvolvimento fica mais produtivo do que adicionar uma chave do tipo "emDesenvolvimento=true" no web.config e ficar chaveando por ele. Lembre-se: web.config também é gente, ops, quer dizer, web.config também é código , sujeito a source control, versionamento,e você corre o risco de não poder dar check out porque alguem deu lock no arquivo, etc.
Para essa mágica de Debug/Release funcionar é necessário colocar uma diretiva de compilação no código onde voce quer haja um comportamento diferente dependendo do mode em que está a aplicação esta rodando. Vejamos um exemplo de uma função que verifica se o usuário faz parte do role "gerencia" utilizando o conceito de compile mode.
public bool VerificaAcessoGerencia()
{
#if DEBUG
return true;
#else
return this.User.IsInRole("gerencia");
#endif
}
Basicamente estamos verificando se a aplicação está rodando em Debug mode. Se estiver, vamos sempre retornar true, caso contrário vamos fazer o que realmente deve ser feito, procurar pela role "gerencia" na coleção de roles do usuário logado.
Muita atenção agora para alguns detalhes:
- Na hora de publicar o seu código para outro ambiente, certifique-se de que voce compilou em Release mode, do contrário voce estará levando lógica errada para ambiente errado e vai ser complicado de descobrir (ou melhor, de lembrar) o que está causando todo o transtorno.
- Se voce está utilizando blocos de código completamente diferentes ou utilizando essa diretiva descontroladamente, compulsivamente , cuidado voce pode estar querendo resolver outros problemas que não tem nada haver com ambientes ou compilation mode. Use o bom senso para essas decisões.
É possivel criar outras modos de compilação, (novas solution configurations), o que eu considero um próximo passo, mas apenas para ambientes mais complexos, por exemplo, se voce precisar testar o código de forma diferente em cada servidor numa arquitetura de load balance. Acredito que somente debug/release cobre 95% dos casos.
Utilizando esse recuros fica para o web.config apenas as diferenças entre os ambientes (path de arquivos em prod e QA, por exemplo), deixando para o compilation mode toda essa questão de diferenciar a maneira como o sistema se comporta. Isso vai auxiliar o desenvolvedor nos testes, otimizar o processo de desenvolvimento e trazer mais qualidade ao seu build.
Este artigo foi publicado no site Linha de código confira: http://www.linhadecodigo.com.br/Artigo.aspx?id=1724
Até a próxima!
Relacionado a isso tenho usado um elemento que muita gente não conhece ou conhece mas não aproveita todo o seu poder. Eu, por exemplo, começei a dar mais atenção a isso há não muito tempo atrás.
Bem todos voces ja viram que ao lado do "Play" para rodar a aplicacão no Visual Studio.NET , há uma combo onde você define se voce vai rodar em modo Debug ou Release, também conhecido como Solution Configurations. Podemos tirar vantagem disso ao invés de lotar nosso código com chaves do web config. Basicamente o modo em que estamos compilando define quem estará utilizando a aplicação. Basicamente existem dois perfis macro de pessoas que podem ter algum tipo de contato com aplicação: aqueles que estão construindo a aplicação e aqueles que utilizam a aplicação. Nao confunda com perfil de usuário, que são as formas de um usuário acessar, mas são todos usuários finais do sistema. Porém, um desenvolvedor constrói a aplicação mas precisa testar como se fosse um usuário em muitos casos. Algumas vezes é possivel criar um usuário no banco de dados e dar algumas permissões e fazer o desenvolvedor utilizar essa conta e a aplicação se comportará exatamente como um usuário final. Mas quando a complexidade do ambiente aumenta fazer isso fica complicado. Por exemplo, imagine que voce tem um relatório que só pode ser acessado por usuários do grupo gerência do Active Directory. Um desenvolvedor programa essa funcionalidade que verifica o grupo do usuário logado na master page e o outro programador faz o relatório usando a master page. Como nosso pobre amigo que está programando o relatório poderá testar o seu código se ele não consegue mais acessar a página? Podemos resolver isso de várias formas, algumas bonitas outras nem tanto. Um solução que eu considero bonita é usar o recurso de Debug/release para diferenciar quem está pilotando a aplicação. Funciona assim: se estou rodando em debug mode significa que eu sou um desenvolvedor entao a aplicação não precisa verificar se eu faço parte do grupo de gerência ou não. Uma vez meu relatório pronto, eu posso rodar em release mode, que significa como a aplicação irá se comportar para os usuários. Eu acho que dessa forma o processo de desenvolvimento fica mais produtivo do que adicionar uma chave do tipo "emDesenvolvimento=true" no web.config e ficar chaveando por ele. Lembre-se: web.config também é gente, ops, quer dizer, web.config também é código , sujeito a source control, versionamento,e você corre o risco de não poder dar check out porque alguem deu lock no arquivo, etc.
Para essa mágica de Debug/Release funcionar é necessário colocar uma diretiva de compilação no código onde voce quer haja um comportamento diferente dependendo do mode em que está a aplicação esta rodando. Vejamos um exemplo de uma função que verifica se o usuário faz parte do role "gerencia" utilizando o conceito de compile mode.
public bool VerificaAcessoGerencia()
{
#if DEBUG
return true;
#else
return this.User.IsInRole("gerencia");
#endif
}
Basicamente estamos verificando se a aplicação está rodando em Debug mode. Se estiver, vamos sempre retornar true, caso contrário vamos fazer o que realmente deve ser feito, procurar pela role "gerencia" na coleção de roles do usuário logado.
Muita atenção agora para alguns detalhes:
- Na hora de publicar o seu código para outro ambiente, certifique-se de que voce compilou em Release mode, do contrário voce estará levando lógica errada para ambiente errado e vai ser complicado de descobrir (ou melhor, de lembrar) o que está causando todo o transtorno.
- Se voce está utilizando blocos de código completamente diferentes ou utilizando essa diretiva descontroladamente, compulsivamente , cuidado voce pode estar querendo resolver outros problemas que não tem nada haver com ambientes ou compilation mode. Use o bom senso para essas decisões.
É possivel criar outras modos de compilação, (novas solution configurations), o que eu considero um próximo passo, mas apenas para ambientes mais complexos, por exemplo, se voce precisar testar o código de forma diferente em cada servidor numa arquitetura de load balance. Acredito que somente debug/release cobre 95% dos casos.
Utilizando esse recuros fica para o web.config apenas as diferenças entre os ambientes (path de arquivos em prod e QA, por exemplo), deixando para o compilation mode toda essa questão de diferenciar a maneira como o sistema se comporta. Isso vai auxiliar o desenvolvedor nos testes, otimizar o processo de desenvolvimento e trazer mais qualidade ao seu build.
Este artigo foi publicado no site Linha de código confira: http://www.linhadecodigo.com.br/Artigo.aspx?id=1724
Até a próxima!
Wednesday, January 23, 2008
Artigo: Removendo um Team Project do Team Foundation Server
Hola Amigos,
Após alguns contratempos por conta de alguns team projects que mudaram de rumo, acabei tendo que aprender a apagar team projetcs do meu servidor tfs. Fiz um artigo sobre isso e publiquei no site do linha de código, confiram em http://www.linhadecodigo.com.br/Artigo.aspx?id=1651. Se por acaso voces tiverem alguma sugestão de artigo relacionado ao Team Foundation, fique a vontade para colocar um comentário neste post, afinal este blog é um blog democratico.
Segue o artigo na integra:
Neste artigo mostrarei como apagar um team project no team foundation server. Existem vários cenários nos quais pode haver a necessidade de remover um team project do seu TFS. Por exemplo:
- um projeto criado para testes
- um projeto que foi descontinuado
- um projeto que foi "mergeado" a outro
Infelizmente não há uma IDE ou menu no Team Explorer para realizar esta ação. É necessário utilizar o comando TFSDeleteProject. A referência completa deste comando você encontra no link http://msdn2.microsoft.com/en-us/library/ms181482.aspx.
Para deleter um team project abra o Visua Studio command prompt (normalmente encontrado no caminho Iniciar -> Programas -> Microsoft Visual Studio 2005 -> Visual Studio Tools -> Visual Studio 2005 Command Prompt) e digite o seguinte comando:
TFSDeleteProject /server:http://nomedoservidor:8080 NomedoProject
Obs: caso voce tenha instalado o tfs rodando em outra porta diferente da 8080 substitua no comando pela porta em que o tfs está configurado.
Para rodar este comando voce precisa ser membro do grupo Team Foundation Administrators ou do grupo Project Administrators.
Na verdade, o comando TFSDeleteProject no fim das contas acaba chamando a API do team foundation através de alguns web services que o TFS disponibiliza para a execução de tarefas administrativas no servidor. Quer dizer, se voce pretende realizar esse processo de apagar projetos com frequência e esteja pensando em desenvolver um pequeno aplicativo, o web service usado para apagar os projetos se encontra em http://nomedoservidor:8080/services/v1.0/CommonStructureService.asmx.
Agora lembre-se que, quando o comando TFSDeleteProject é executado , o sistema coloca os arquivos do source control daquele projeto em modo "deleted", ou seja , ele não apaga os dados do banco de dados nem recupera o espaço em disco ocupado por esses artefatos (na versão 2008 os arquivos de source control já são removidos também). Além disso, alguns dados permanecem na base de Warehouse do TFS, por isso se você apagar um projeto e tentar criar outro com o mesmo nome, o sistema irá exibir uma mensagem de erro, afinal o projeto anterior não foi totalmente removido do sistema.
Até a próxima.
Após alguns contratempos por conta de alguns team projects que mudaram de rumo, acabei tendo que aprender a apagar team projetcs do meu servidor tfs. Fiz um artigo sobre isso e publiquei no site do linha de código, confiram em http://www.linhadecodigo.com.br/Artigo.aspx?id=1651. Se por acaso voces tiverem alguma sugestão de artigo relacionado ao Team Foundation, fique a vontade para colocar um comentário neste post, afinal este blog é um blog democratico.
Segue o artigo na integra:
Neste artigo mostrarei como apagar um team project no team foundation server. Existem vários cenários nos quais pode haver a necessidade de remover um team project do seu TFS. Por exemplo:
- um projeto criado para testes
- um projeto que foi descontinuado
- um projeto que foi "mergeado" a outro
Infelizmente não há uma IDE ou menu no Team Explorer para realizar esta ação. É necessário utilizar o comando TFSDeleteProject. A referência completa deste comando você encontra no link http://msdn2.microsoft.com/en-us/library/ms181482.aspx.
Para deleter um team project abra o Visua Studio command prompt (normalmente encontrado no caminho Iniciar -> Programas -> Microsoft Visual Studio 2005 -> Visual Studio Tools -> Visual Studio 2005 Command Prompt) e digite o seguinte comando:
TFSDeleteProject /server:http://nomedoservidor:8080 NomedoProject
Obs: caso voce tenha instalado o tfs rodando em outra porta diferente da 8080 substitua no comando pela porta em que o tfs está configurado.
Para rodar este comando voce precisa ser membro do grupo Team Foundation Administrators ou do grupo Project Administrators.
Na verdade, o comando TFSDeleteProject no fim das contas acaba chamando a API do team foundation através de alguns web services que o TFS disponibiliza para a execução de tarefas administrativas no servidor. Quer dizer, se voce pretende realizar esse processo de apagar projetos com frequência e esteja pensando em desenvolver um pequeno aplicativo, o web service usado para apagar os projetos se encontra em http://nomedoservidor:8080/services/v1.0/CommonStructureService.asmx.
Agora lembre-se que, quando o comando TFSDeleteProject é executado , o sistema coloca os arquivos do source control daquele projeto em modo "deleted", ou seja , ele não apaga os dados do banco de dados nem recupera o espaço em disco ocupado por esses artefatos (na versão 2008 os arquivos de source control já são removidos também). Além disso, alguns dados permanecem na base de Warehouse do TFS, por isso se você apagar um projeto e tentar criar outro com o mesmo nome, o sistema irá exibir uma mensagem de erro, afinal o projeto anterior não foi totalmente removido do sistema.
Até a próxima.
Thursday, January 10, 2008
Artigo: Instalando o Team Foundation Server
Aqui na empresa eu tenho trabalhado bastante com o Team Foundation 2005 e ja estamos migrando para o TFS 2008. Em consequencia disso tenho aproveitado e escrito alguns artigos para auxiliar quem está neste mesmo barco. Realmente a ferramente é muito boa e tem auxiliado bastante o processo de desenvolvimento e integracao dos times aqui. O primeiro artigo fala sobre o primeirissimo passo para trabalhar com TFS: instalar o rapaz. Ele contém um passo a passo bem resumido mas que me ajudou MUITO para instalá-lo aqui nos servidores da empresa. Confira o artigo no site Linha de Código através do link http://www.linhadecodigo.com.br/Artigo.aspx?id=1449. Os proximos estarei publicando em breve.
Segue o artigo na integra:
Este artigo tem por objetivo facilitar a vida de quem está pretendendo instalar o Team Foundation Server. As informações contidas constituem um resumo do TFS installation guide para completar com êxito uma instalação do tipo Single Server.
Cada vez mais tenho me surpreendido positivamente com o Team Foundation. O conceito por trás desta ferramenta realmente trás muitos beneficios para a equipe de desenvolvimento e para a saúde do projeto como um todo.
Este artigo tem por objetivo facilitar a vida de quem está pretendendo instalar o Team Foundation Server. As informações contidas aqui são um resumo, ou seja, o minimo necessário extraído do TFS installation guide, para completar com êxito uma instalação do tipo Single Server.
Para uma visão mais completa e detalhada do processo de instalação baixe o TFS installation guide, que pode ser encontrado no endereço
http://www.microsoft.com/downloads/details.aspx?FamilyId=E54BF6FF-026B-43A4-ADE4-A690388F310E&displaylang=en.
Passo 1: Para a instalação e configuracao do TFS, três contas são necessárias:
Dominio\TFSSetup
Dominio\TFSService
Dominio\TFSReports
O usuário TFSSetup precisa ser administrador, porém os outros dois são usuários padrão , apenas com a permisão de "Log on Locally". É recomendado que o TFSetup seja administrador de dominio ao invés de local, para evitar problemas com autorização via windows authentication. No entanto, eu criei como usuário local e não tive problemas (até agora : ) ). Você pode dar outros nomes para as contas de acordo a nomenclatura da sua rede. Após criar as contas reinicie a máquina e entre com o usuário TFSSetup para continuar o processo.
Passo 2: Verifique o IIS
Certifique-se de que o ASP.NET esteja instalado e habilitado. Confira também se as extensões do Front Page, NÃO estejam instaladas (O normal é que não estejam instaladas mesmo). Opcionalmente, verifique suas configurações SMTP para que o Team System possa enviar notificações via email.
Passo 3: Instale o SQL SERVER 2005
Na tela "components to Install" , selecione tudo menos notification services. Ainda nesta página clique em "Advanced" e faça o seguinte:
- Desabilite tudo em "Client Components" menos "Management Tools"
- Desabilite "Documentation and Sample"
Na tela "Service Account", selecione "Use the built in System account", and escolha "Local System". Ainda nesta página marque todos os itens em "Start services".
Passo 4: Instale os service packs e hot fixes necessários
Após finalizar a instalação do SQL Server 2005, pare os serviços de SQL Agent e SQL Browser. Talvez a máquina solicite um reboot. Instale o .NET 2.0 Service Pack 1 (se disponível), ou instale o hot fix que se encontra na pasta \KB913393 no cd de instalação do TFS.
Passo 5: Instale o Sharepoint Services (wss 2.0)
Atenção neste passo: Apenas selecione a opção "Server Farm" e deixe o sharepoint ser instalado. Em seguida, uma janela de configuração do sharepoint irá abrir. Não altere nada nesta tela, apenas feche o janela do browser. O próprio TFS irá configurar o sharepoint de forma que eles venham a conversar corretamente.
Passo 6: Instale o TFS
Chegou a hora de instalar o TFS. Selecione a opção "Single Server" e durante a instalação forneça as contas de admin, service e reports criadas no passo 1 deste tutorial.
Passo 7: Verifique se a instalação ocorreu com sucesso
Acesse http://nomedoservidor:8080/services/v1.0/Registration.asmx e clique no método GetRegistrationEntries e depois clique em Invoke. Certifique-se que no XML de retorno deste web service logo nas primeiras linhas há um nó com o valor "vstfs". Se tiver, sua instalação foi bem sucedida.(Se por acaso sua instalação falhou, favor leia o TFS Installation guide para maiores detalhes.)
Agora é só instalar o Team Explorer nos clients, criar os seus Team Projects e aproveitar tudo aquilo que o team foundation tem para oferecer.
Até a próxima.
Segue o artigo na integra:
Este artigo tem por objetivo facilitar a vida de quem está pretendendo instalar o Team Foundation Server. As informações contidas constituem um resumo do TFS installation guide para completar com êxito uma instalação do tipo Single Server.
Cada vez mais tenho me surpreendido positivamente com o Team Foundation. O conceito por trás desta ferramenta realmente trás muitos beneficios para a equipe de desenvolvimento e para a saúde do projeto como um todo.
Este artigo tem por objetivo facilitar a vida de quem está pretendendo instalar o Team Foundation Server. As informações contidas aqui são um resumo, ou seja, o minimo necessário extraído do TFS installation guide, para completar com êxito uma instalação do tipo Single Server.
Para uma visão mais completa e detalhada do processo de instalação baixe o TFS installation guide, que pode ser encontrado no endereço
http://www.microsoft.com/downloads/details.aspx?FamilyId=E54BF6FF-026B-43A4-ADE4-A690388F310E&displaylang=en.
Passo 1: Para a instalação e configuracao do TFS, três contas são necessárias:
Dominio\TFSSetup
Dominio\TFSService
Dominio\TFSReports
O usuário TFSSetup precisa ser administrador, porém os outros dois são usuários padrão , apenas com a permisão de "Log on Locally". É recomendado que o TFSetup seja administrador de dominio ao invés de local, para evitar problemas com autorização via windows authentication. No entanto, eu criei como usuário local e não tive problemas (até agora : ) ). Você pode dar outros nomes para as contas de acordo a nomenclatura da sua rede. Após criar as contas reinicie a máquina e entre com o usuário TFSSetup para continuar o processo.
Passo 2: Verifique o IIS
Certifique-se de que o ASP.NET esteja instalado e habilitado. Confira também se as extensões do Front Page, NÃO estejam instaladas (O normal é que não estejam instaladas mesmo). Opcionalmente, verifique suas configurações SMTP para que o Team System possa enviar notificações via email.
Passo 3: Instale o SQL SERVER 2005
Na tela "components to Install" , selecione tudo menos notification services. Ainda nesta página clique em "Advanced" e faça o seguinte:
- Desabilite tudo em "Client Components" menos "Management Tools"
- Desabilite "Documentation and Sample"
Na tela "Service Account", selecione "Use the built in System account", and escolha "Local System". Ainda nesta página marque todos os itens em "Start services".
Passo 4: Instale os service packs e hot fixes necessários
Após finalizar a instalação do SQL Server 2005, pare os serviços de SQL Agent e SQL Browser. Talvez a máquina solicite um reboot. Instale o .NET 2.0 Service Pack 1 (se disponível), ou instale o hot fix que se encontra na pasta \KB913393 no cd de instalação do TFS.
Passo 5: Instale o Sharepoint Services (wss 2.0)
Atenção neste passo: Apenas selecione a opção "Server Farm" e deixe o sharepoint ser instalado. Em seguida, uma janela de configuração do sharepoint irá abrir. Não altere nada nesta tela, apenas feche o janela do browser. O próprio TFS irá configurar o sharepoint de forma que eles venham a conversar corretamente.
Passo 6: Instale o TFS
Chegou a hora de instalar o TFS. Selecione a opção "Single Server" e durante a instalação forneça as contas de admin, service e reports criadas no passo 1 deste tutorial.
Passo 7: Verifique se a instalação ocorreu com sucesso
Acesse http://nomedoservidor:8080/services/v1.0/Registration.asmx e clique no método GetRegistrationEntries e depois clique em Invoke. Certifique-se que no XML de retorno deste web service logo nas primeiras linhas há um nó com o valor "vstfs". Se tiver, sua instalação foi bem sucedida.(Se por acaso sua instalação falhou, favor leia o TFS Installation guide para maiores detalhes.)
Agora é só instalar o Team Explorer nos clients, criar os seus Team Projects e aproveitar tudo aquilo que o team foundation tem para oferecer.
Até a próxima.
Subscribe to:
Posts (Atom)
Posts
