Valdinei dos Santos

programação, sistemas operacionais e assuntos web

Arquivo para 1 de agosto de 2009

Find, rsync, svn, scp Ferramentas do desenvolvedor

ago 1

Postado por Valdinei em curiosidades, programação | 1 comentário

Acompanho o twitter de varios desenvolvedores e vire e mexe alguém esta com alguma reclamação com seus arquivos versionados tipicamente estes arquivos são os “.svn” .

Os arquivos svn são pastas que contem a assinatura dos arquivos e seus conteúdos, ou seja tudo fica duplicado,  e algumas vezes quando vamos enviar esses arquivos para o servidor de produção não nos atentamos que estamos enviando junto os arquivos svn o que faz a transferencia ficar muito mais lenta pois tem que se enviar muito mais arquivos.

Hoje vejo que isso pode ser contornado de 3 formas diferentes:

Baixando as Atualizações via svn

Nesta modalidade o desenvolvedor envia todos os seus códigos para o servidor de svn “svnserver”,
mas antes verifica se algo entrou em conflito ou se ele próprio precisa fazer alguns updates.

svn status -u /url/pasta/raiz/projeto/

Imaginando que tudo esta correto e que somente ele tem arquivos a serem enviados.

svn commit -m "SEU COMENTÁRIO" /url/do/arquivo/a/ser/commitado/
svn commit -m "SEU COMENTÁRIO" /url/da/pasta//commitada/

Pronto tudo esta pronto e devidamente no seu lugar, agora vamos logar na máquina de produção e fazer o update que foi enviado.

svn update /url/pasta/raiz/projeto/

Neste modo nada se perde no caminho. Fim todo mundo feliz

Mandando pequenas atualizações que ainda não são a versão final do arquivo

Nesta modalidade o desenvolvedor envia todos os seus códigos para o servidor de testes, portanto não importa se vai haver svn ou não. O que importa aqui seria ser um pouco mais rápido.

Ai ele limpa todos os .svn para ficar mais leve o envio.

cp -R /url/pasta/raiz/projeto/ /tmp/projeto
find /tmp/projeto -iname *.svn -exec rm -rf {} \;

Assim foram apagados todos os arquivos .svn da pasta do projeto pois esse foi copiado para o /tmp/projeto
Assim só precisamos enviar os novos arquivos para o servidor TESTE , leia-se TESTE e não “DE TESTE” 

scp -r /tmp/projeto/arquivo/ usuario@host:/url/pasta/raiz/projeto/

Os arquivos são enviados e todos quase ficamos felizes, pois essa não é a melhor prática.

Mandando pequenas atualizações que ainda não são a versão final do arquivo por rsync

Esta é a caracteristica do rsync que achei interessante pois não conhecia a syntaxe.
A opção -C do rsync exclui uma penca de arquivos que normalmente eu apagava na mão, e evita que se tenha que copiar para um segundo diretorio todos os arquivos para depois limpa-los.
Sendo assim enviando para o mesmo sever bastaria fazer o seguinte. 

rsync -Cavz -e ssh /url/pasta/raiz/projeto/  usuario@host:/url/pasta/raiz/projeto

Todos os arquivos que foram modificados serão enviados e com a vantagem de ser descartados esses tipos de arquivo.

RCS SCCS CVS CVS.adm RCSLOG cvslog.* tags TAGS .make.state .nse_depinfo *~ #* .#* ,* _$* *$  *.old  *.bak  *.BAK  *.orig *.rej .del-* *.a *.olb *.o *.obj *.so *.exe *.Z *.elc *.ln core .svn/

Como tem alguns desenvolvedores que mesmo sob um sistema de controle de versão (svn) continuam usando o “.old” o rsync também os ignora, isso é simplesmente lindo!

Essas são algumas práticas que tenho observado no twitter e também com companheiros de trabalho.

Acho que essas dicas podem ajudar alguém por isso postei esses detalhes.

E existem também muitas outras maneiras de fazer esse deploy. Invente a sua ….

O Zen do Python

ago 1

Postado por admin em curiosidades, programação | 2 comentários

A alguns dias descobri uma coisa bem interessante no python.  Ao fazer o import dele mesmo ele mostra alguns principios que foram criados por  Tim Peters.

Seguindo a risca esses principios dificilmente seu projeto vai dar errado :P

Como os encontro?

Em sua linha de comando (estou assumindo que  você esta em algum Unix e que tenha python instalado) digite:

$ python

Neste momento você estará entrando no shell interativo do python depois é só fazer o import.

 import this

O resultado você visualiza abaixo

Python 2.5.2 (r252:60911, Oct  5 2008, 19:24:49)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Vou colocar também uma livre tradução que encontrei na internet e que cito o autor abaixo.

Bonito é melhor que feio.
Explícito é melhor que implícito.
Simples é melhor que complexo.
Complexo é melhor que complicado.
Plano é melhor que aninhado.
Esparso é melhor que denso.
Legibilidade conta.
Casos especiais não são especiais o bastante para se quebrar as regras.
Embora a simplicidade supere o purismo.
Erros nunca deveriam passar silenciosamente.
A menos que explicitamente silenciados.
Ao encarar a ambiguidade, recuse a tentação de adivinhar.
Deveria haver uma – e preferencialmente apenas uma – maneira óbvia de se fazer isto.
Embora aquela maneira possa não ser óbvia à primeira vista se você não for holandês.
Agora é melhor que nunca.
Embora nunca, seja muitas vezes melhor que pra já.
Se a implementação é difícil de explicar, é uma má idéia.
Se a implementação é fácil de explicar, pode ser uma boa idéia.
Namespaces são uma idéia estupenda – vamos fazer mais deles!

fonte da tradução

Básicamente são boas maneiras para se trabalhar com python.

Algumas coisas que senti falta e que vou acrescer ao texto

Marretas não são bem vindas, mas são necessárias.
O pior código é aquele que não existe, esse não dá dinheiro

Bem acho que é isso que tinha a dizer hoje.

Fui ….

Fontes:

http://www.python.org/dev/peps/pep-0020/

http://pipeless.blogspot.com/2008/09/o-zen-de-python.html

Tags: , ,