Pesquisar este blog

sábado, 27 de dezembro de 2008

Can not connecto server - mplayer + Intrepid

Bem, para quem instalou o mplayer no seu Ubuntu Intrepid, deve ter notado que ele dá um errinho quando se roda um vídeo. O vídeo roda e tudo, mas dá o errinho chato.

Bem, resolver esse problema do errinho é muito fácil. Basta vc clicar com o botão direito na tela do (g)mplayer, ir em preferences > sound e trocar o servidor de som de pulse para alsa. Não sei se isso é um negócio legal de se fazer, mas funciona! =D

sexta-feira, 26 de dezembro de 2008

Em busca do contra baixo quase peferito!!




Bem, resolvi(do nada =D) que quero aprender a tocar baixo. Gosto do som, e como como não sei tocar estrumento musical algum, um baixo seria uma boa pedida.

Nisso, comecei a falar com amigos e amigos de amigos sobre como escolher um bom baixo. Aprendi termos novos como tarracha, capacitor captador , aprendi o nome de várias marcas de baixo, e o mais importante, aprendi que contra baixo tem que ser ligado na caixinha pra sair som =D. Rsrsrs, eu não sabia disso!

Bem, depois de muito conversar, muito pesquisar, estava convencido que o baixo tagima b5-s era o baixo para mim. Preço em conta(menos de mil) e tinha 5 cordas. Eu, como boa pessoa economica que sou, estava pensado: eu posso comprar um baixo de quatro cordas, mas se eu tomar gosto pela coisa e quiser uma corda a mais? Como fica? Então melhor comprar uma de 5, correto? NÃO!

Um baixo de 5 cordas não é necessariamente um bom investimento. Notei isso hoje, ao ir na loja conferir os baixos pessoalmente(coisa que todo mundo que quer comprar um baixo deve fazer!). Tipo, cheguei logo pedindo pra ver o Tagima B5, o cara mostrou. Logo notei que o baixo tinha um acabamento ruim, os ferrin tudo estranho. Pareciam sucata. Mas foi quando ele ligou o baixo e começou a tocar, que deu para notar quanto o b5 não é grande coisa. O som era meio sujo(primeira coisa que o cara fez foi afinar e mesmo assim não ficou legal), cordas feias, acabamento feio também. Sinceramente, desisti do baixo rapidamente.

Um outro detalhe que notei é que o braço do baixo era grande. Tipo, muito grande para a minha mão, que não tem dedos lá muito compridos. Nisso, pedi para ver um strinberg de quatro cordas que estava em exposição. O bicho era bonito(meio gliterizado d+ para o meu gosto, mas bonito, mesmo assim), tinha um braço fininho, era leve(mais leve que o b5) e mais, era tinha um som MUITO MELHOR.

Não peguei a referência do baixo, mas ele tinha uma plaquinha perolada perto dos capacitores captadores. Capacitores Captadores não, capacitor captador. Era um capacitor duplo lá. De qualquer forma, esse baixo, ligado na caixinha spears lá tinha um som muito bom! E o cara fez os ajustes lá, pow, era um baixão. Foda era o preço. Mas bem, vamos ver.

O baixo, com os acessórios, pelos cálculos lá, sairiam por 1350 reais. Uma grana bruta. Aí vou ver oq eu faço. Espero que dê tudo certo, me paguem no dia correto lá no trampo, e eu pegue o meu baixo. Foda vai ser arranjar tempo para usá-lo, mas isso, até março, aparece.

De qualquer forma, queria só deixar minhas impressões aqui. Talvez ajude algum indeciso. Abração!

quinta-feira, 25 de dezembro de 2008

web.py com jinja2!

Primeiramente, Feliz Natal meu povo! rsrsrs, meu natal não foi grande coisa, passei doente em casa, mas o de vocês pode ter sido massa, não é mesmo? Bem, de qualquer forma, os panettones vão entrar em promoção e a vida será bela novamente!

Agora, planejamentos para o final de ano. Vamo ver oq a prefeita vai aprontar.

De qualquer forma, a idéia aqui é falar da utilização do jinja2 com o web.py. Para quem não sabe, o web.py é um framework minimalista escrito em python, que foca na criação de pequenos sites que precisam ficar prontos logo, não tem grandes perspectivas de crescimento, e precisam ser rápidos.

O web.py é um framework bem completo, levando em conta o que ele se propõe a fazer. Ele te oferece uma camada de abstração sobre os templates(arquivos html), sobre o modelo(o banco de dados), e sobre a camada de negócios(a lógica do aplicativo). Tudo de forma bem simples, entretanto, para algumas pessoas, isso não é o bastante.

Bem, eu venho de um bom tempo de desenvolvimento com django, então, eu estou acustumado(e gosto) ao estilo de templates do django. Códigos python nos meus templates, nem na base de bala! Então, quando fui tentar utilizar o web.py para fazer um site aqui, a primeira coisa que notei era que o sistema de templates dele era bem feio e difícil(não tão fácil quanto poderia). Então, conhecendo o jinja2, que é um sistema de templates semelhante ao do django, resolvi logo testá-lo no meu aplicativo.

Procedimento
Usar bibliotecas que não são do web.py no web.py é bem fácil. Adicione o jinja2 dentro do seu projeto, do lado do pacote web contendo o código do framework web.py. Nisso, a partir do código principal do seu aplicativo(onde você configura a url e o quê fica onde), você adiciona o jinja2, cria um environment para ele, e usa para fazer a renderização dos templates. Vejamos como ficaria um código exemplo:

# módulo do python
import os

# importando o que precisamos do jinja2
from jinja2 import Environment
from jinja2 import FileSystemLoader
from jinja2 import TemplateNotFound, TemplateSyntaxError

# dicionário com as configurações do ambiente
env_config = {
# marque com True para que o Jinja procure por atualizações no template
"auto_reload":False,
# marque com True para que todos os templates sejam "escaped"
"autoescape":False,
# define quantas páginas ficarão no cache por vez
"cache_size":50,
# ser para adicionar tags {% nome %} aos templates.
"extensions":[],
# templates loader. Tupla que informa ao jinja2 onde procurar os templates
"loader":FileSystemLoader(TEMPLATE_DIRS),
}

# os templates serão carregados a partir do objeto env, que é uma instância de
# environment
env = Environment(**env_config)

# path é o caminho (relativo aos caminhos do TEMPLATE_DIRS) para o template
# vars é um dicionário com variáveis a serem disponibilizados no template
def render(path, vars):
try:
# templates are automatically cached
template = env.get_template(path)
except TemplateNotFound:
raise TemplateNotFound(path)
except TemplateSyntaxError:
raise TemplateSyntaxError(path)
return template.render(vars)

Bem, o código acima funciona bem, mas colocá-lo junto com o arquivo principal do ambiente não é uma boa. Sugiro que você crie um arquivo view.py e coloque o código acima dentro, e a partir das classes que processam as requisições(Handlers) você chame o método render de view.

Outra dica é colocar para que a classe Handler busque templates que possuam o seu nome. Por exemplo, um handler Casa na classe Barco devolveria o template barco/casa.html. Essa é uma prática legal que já economiza algum código.

Bem, de qualquer forma, é isso. Vou aqui brincando com o web.py até achar algo que me faça sair dele. rsrsrs, ou não. bem, ele é minimalista, então, para coisinhas, acho que vou sempre usar ele.

ps: depois posto um template para projetos web.py, com classes e pastas para facilitar a vida de quem desenvolve.

Até mais e boas festividades!

sábado, 20 de dezembro de 2008

Webcam no xubuntu

Opa, oi negada! Depois de um tempinho sem postar e talz, here i am.

Andei muito ocupado no trabalho e talz, rsrsrs, tenho tido tempo nem de estudar direito. Mas faz parte. Planejamentos a médio prazo exigem sacrifícios. De qualquer forma, hoje vim falar sobre algumas coisinhas interessantes. Por exemplo: resolvi instalar o Xubuntu 8.10 no meu notebook.

Sim, rsrsrs, já usei Xubuntu a muito tempo e tinha desistido dele, entretanto, aconteceu uma série de fatos que me fizeram repensar minha decisão. Na época que eu desistir do Xubuntu, ele não tinha uma série de qualidades que hoje demonstra ter. Para ter um editor de texto legal com highlight, por exemplo, eu necessitava instalar o gedit, que trazia consigo várias bibliotecas do gnome. E instalar o compiz? Mais gnome! No fim, meu sistema passava rapidamente a ser um híbrido entre gnome e xfce.

Hoje isso não é mais verdade. Com o novo e poderoso Editra, eu já posso editar meus html's, xml's e scripts tranquilamente. O compiz não mais necessita de meio gnome para ser instalado(um sudo apt-get install compiz-core compizconfig-settings-manager mais uma configuraçãozinha na sessão resolve), entre outras coisas.

Como a grama do vizinho sempre é mais verdes, alguns problemas persistem, mas, agora, sinto-me mais maduro(os softwares de hoje também estão mais maduros =D) para contorná-los com maestria. Por exemplo, o Xubuntu vem com o abiword e gnumeric. Eu não los tenho apreço algum. Nada como um OpenOffice para dar aquele trato no seu documento.

Pois bem, instalei o OpenOffice(editor de documentos, apresentações, planilhas e matemático) tranquilamente com o comando :
sudo apt-get install openoffice.org-writer openoffice.org-impress openoffice.org-math openoffice.org-calc openoffice.org-gtk

Próximo passo? Colocar minha webcam para funcionar. O Xubuntu não tem um cheese da vida, então eu tive que dar uma buscadazinha. O aplicativo que achei não é lá a coisa mais bonita do mundo, mas é extremamente funcional e prático. O nome dele é wxcam. O site do projeto é bonitinho e lá há um pacote debian só esperando pelo seu clique.

Ok. Mais alguma coisa? Claro! O transmission é um negócio pelado e sem graça. Outra coisa muito importante é instalar o deluge-torrent. Esse sim é um cliente torrent de cabra homi(escrito em python ; D). Um sudo apt-get install deluge-torrent faz o serviço.

Para quem ainda não sabe instalar o editra, também é facinho. Instale o setuptools
(sudo apt-get install python-setuptools) e depois escreva os seguintes comandos no terminal:
sudo easy_install Editra
sudo apt-get install python-wxgtk2.8

A última versão do Editra será lindamente instalada em sua máquina. Pronto, você agora tem um Xubuntu minimamente utilizável, rápido, e com poucas dependências gnome. Outra coisa que talvez faça falta também é um aplicativo de gerência de câmera digital. Algo como : você pluga a câmera pela usb e o computador mostra as fotos dela e pergunta se você quer baixar. O programa gtkam dá conta do recado. Instale-o pelo apt-get com o comando:
sudo apt-get install gtkam

Moleza neh não? Agora é só instalar os aplicativos que você mais gosta, criar uma estrutura de diretórios no seu home, configurar seu desktop, colocar wallpaper, e pronto rsrsrs. Espero que este guia seja útil para alguém. Abraço!

segunda-feira, 8 de dezembro de 2008

Hello World com GAE

Pronto! Arranjei tempo para acabar(começar?!) o tutorial do Google App Engine! Vou tentar ser bem bem direto, então, mãos a obra:

Este será um aplicativo de hello world, que, para quem não conhece, é um exemplo de aplicativo mínimo que se pode fazer com uma determinada tecnologia. Para começar, baixe a última versão do GAE no site do projeto. Feito isso, descompacte o arquivo em uma pasta qualquer(sejamos organizados, ok?) e criemos um link na pasta de arquivos executáveis apontando para os arquivos dev_appserver.py e para o appcfg.py (lembrando que esta é uma instalação para o linux). O arquivo dev_appserver.py vai nos permitir executar o servidor de desenvolvimento e o appcfg.py vai nos permitir fazer o deploy do aplicativo com apenas um comando =D.

Criando os links
Entre na pasta descompactada do GAE e escreva os seguintes comandos no terminal:

sudo ln -s `pwd`/dev_server.py /usr/local/bin
sudo ln -s `pwd`/appcfg.py /usr/local/bin

Os comandos acima vão, respectivamente, criar duas ligações do tipo "soft" na pasta /usr/local/bin. Para ver se tudo deu certo, abra um outro terminal e escreva dev_server.py. Se aparecer qualquer coisa diferente de uma mensagem de erro, você está no caminho certo. Agora vamos criar nosso projeto.

Criando o aplicativo
Aplicativos do GAE possuem uma estrutura padrão que você terá que criar na munheca. É isso aí, não tem comandozinho mágico que cria um aplicativo do nada, como é o caso do django, por isso, sugiro que, quando você estiver bem familiarizado com o GAE, crie você uma espécie de projeto template, que será a base de quaisquer outros projetos GAE que você queira começar.
Um template minimalista para o HelloWorld teria a seguinte estrutura:

app/
------app.yaml
------main.py

É isso aí, dois arquivozinhos. Um arquivo yaml(que é um formato de troca de informações e armazenamento de configurações bastante simples e poderoso) e um arquivo main.py, que será o arquivo principal da aplicação. Normalmente arquivos main.py são utilizados como arquivos principais de aplicativos desktop do python, não é mesmo? Bem, no GAE também se usa o bichinho como arquivo principal. Não que seja obrigatório, mas como todo mundo usa(com GAE), e eu gostei, vamos usar também.

Explicando o que vai aonde
O arquivo app.yaml, como é esperado, armazena as configurações do seu aplicativo. O django, por exemplo, usa um arquivo settings.py para manter as configurações do projeto, o GAE usa o app.yaml, servlets usam o web.xml, e assim vai. É uma questão de escolha, entretanto, teoricamente, a utilização do xml para arquivos de configuração é a pior escolha das três citadas.

A estrutura do arquivo de configuração app.yaml deve ser da seguinte forma:

application: helloworld
version: 1
runtime: python
api_version: 1

handlers:
- url: /.*
script: main.py

O texto acima deve estar em acordo com as normas de formatação do yaml. Caso não as conheça, veja o link.

Parâmetros
  • application: define o nome do aplicativo, que deve ser o mesmo nome cadastrado na sua conta do GAE.
  • version: informa a versão atual do seu aplicativo
  • runtime: informa a versão do python que deve ser utilizada no aplicativo. Por enquanto, apenas "python" é permitido.
  • api_version: informa a versão da api do GAE a ser utilizada.
Fora os parâmetros acima, ainda existe, definido em nosso exemplo, um outro, o handlers. O handlers é uma lista de mapeamentos de url que desembocam em arquivos .py responsáveis por tratar as requisições com aquele padrão de url.

Exemplo: o GAE, assim como o django, se baseia em expressões regulares para escolher quem vai tratar qual url. Um padrão de url como o do exemplo "/.*", define que uma url, com qualquer path depois dela, deve ser direcionada para o arquivo main.py.

- url: /.*

script: main.py

- url: <= define que o padrão de url vem logo a segui. script: <= define o script python que irá interpretar a requisição. Bem, basicamente é isso. Agora vamos escrever nosso main.py. Lembrando que o GAE usa CGI, então.
Nosso main.py é bem simples, o código abaixo gera o nosso helloworld:
print 'Content-Type: text/plain'
print ''
print 'Hello, world!'
Certo, o esquema do helloworld acima é bem simples. A saída padrão do GAE é a resposta gerada para o cliente acessando a página. Então, quando usamos o print para escrever algo, estamos, na verdade, criando nossa página do GAE.
Na primeira linha, escrevemos o content-type da página, que informa ao navegador web qual o tipo do arquivo que ele vai receber, criamos uma linha em branco, para poder inserir o conteúdo, e printamos 'Hello World'.

Agora abra um terminal, vá para a pasta onde está o seu projeto GAE, e dê o comando "dev_server.py nomeDoProjeto". Com esse comando, seu projeto irá subir. Agora vá no navegador e acesse "localhost:8080/". Seu hello world com GAE irá subir. Rrsrsrs, ufa! Cabou. Talvez, entre hoje e o infinito, eu faça outra postagem sobre como usar templates e acesso ao banco. Por agora, vou acabar aqui o forumBR que anda meio abandonado, e ver quanto eu vou pagar no meu contrabaixo. =D Abraço negada!

quarta-feira, 3 de dezembro de 2008

Python3.0 FINAL!!!

Sim, eu sei que não acabei o tutorial do GAE, mas galera, um homem tem que ter prioridades em sua vida =D!!!

Saiu a tão aguardada versão3 do python!!! Isso é um evento histórico para a linguagem python! Ela, a partir de agora, é uma linguagem de primeiro mundo, compatível, "out of the box" com padrões de primeiro mundo! Ela possui tantas novas qualidades que eu já estou com água na boca aqui!

Não sendo possível fazer uma postagem estilo "cabra homi" devido ao horário e ao meu cansaço físico e mental(estou escrevendo apenas com a força de minha euforia!), vou apenas listas algumas características que VÃO afetar sua vida como desenvolvedor pythonico:

  • print não é mais uma keyword, é um método(print('') e não print '')
  • todas as strings python são unicode por padrão(utf-8 da vida meu povo =D)
  • agora existe o tipo bytes. Ou seja, strings são strings e bytes são bytes. Assim como é para ser
  • FILEIO agora aceita 'b', para binário
  • O tipo long morreu. Agora só existe o int, que é como se fosse o long.
  • O método cmp morreu também(rsrsrs, tem um código meu que vai quebrar por esta).
  • sys.maxint virou agora sys.maxsize
  • Isso aqui agora funciona: (a,*rest,b)=range(5) , resultando em a igual a 0, *rest igual a [1,2,3] e b em 4. MORRA DE INVEJA, PROLOG!!!
  • as e with são keywords agora
  • mudança na sintaxe do except para : except ExceptionName as varname: ...
  • <> <== não existe mais
  • Outras coisinhas que listarei algum dia entre hoje e o dia do apocalipse(ou não =D)
Pois é galera, é isso. Quem quiser já ir testando, faça as honras de baixe o py3k(apelido do bixin). Só digo uma coisa, MUITO PROVAVELMENTE, seu código irá quebrar, usando o py3k, se você não o fez já pensando em utilizá-lo com o mesmo. Algumas mudanças foram rígidas, penetrantes e sem vaselina! Juízo hein!?