segunda-feira, outubro 03, 2011

Python Brasil [7]



Antes de mais nada queria dizer que foi a melhor e maior Python brasil que já estive ! ([1], [5], [6] e [7])

Parabéns ao Érico. Já na entrada se podia ver que aquela seria uma Python Brasil diferente.
A organização foi de longe a melhor de todas, e a infra estrutura nem se fala -  3 telões, o áudio, etc etc ... impecável;
Parabéns ao Érico e Karin, e a todos que ajudaram a fazer esta  Python Brasil.

Sempre tem pontos a melhorar, mas perto do evento que foi, são irrelevantes.
Espero que o Érico dê seus "pitacos" na próxima python brasil.

Logo depois da primeira Keynote, tive uma boa conversa com  Wesley Chun, e foi o que me motivou durante todo o resto da Python Brasil;

Porque Python ? e como "vender" python. Quem usa ? onde ?

Não obtive nenhuma resposta milagrosa, mas confirmei aquilo que nós já sabemos; PYTHON É F***. E python está em lugares que nem imaginamos. 
Pessoas menos  prováveis usam e indicam python como solução para seus negócios, uma pena, Chun confirma que muitos  "escondem" python, por ser uma ferramenta estratégica dentro do negócio. Grandes empresas  usam como solução interna, mas não divulgam o uso de Python.

Depois assisti palestras como  :
 - Listas, deques, heaps e outras bestas mitológicas: Adriano Petrich
 - OO em Python sem sotaque: Luciano Ramalho (todo mundo deveria ver o
slideshare disso - tem sempre um tip a mais)
 - Us, an Open Source Community: Alan Runyan
 - Ensinando OO com Python, Django e Pygame: Luciano Ramalho
 - Tudo que você sempre quis saber sobre Bindings: Gustavo  Barbieri.
 - Escalabilidade em projetos Django:Francisco Souza

entre outras...

Um ponto que merece destaque, e isso você não terá em nehuma lista de discussão nem em outro congresso, são as conversas no corredor com pessoas como Senra, Ikke, Luciano Ramalho, Petrich, Douglas, Tania,  Osvaldo entre outros Pythonistas, que compartilham comigo o uso de Python no dia-a-dia. A cervejinha de todos os dias, imperdível. Ali também se constroem os laços que fazem as listas ficarem um pouco mais divertidas e interessantes. Conversas com o Henrique Bastos (RJ), Marcel (PE), e outros caras que fazem a diferença na comunidade Pytthon -  são inspriradoras.

Sobre as palestras relâmpago, não vou listar nenhuma porque seria uma injustiça. Seria possível fazer uma lista pós com as palestras relampago? (boa aplicação pra fazer)  Pra quem não estava lá, é outro prejuízo que não tem como remediar.

Alias, fizemos (Luiz Vital e eu ) nossa primeira palestra relâmpago - nenhuma descoberta técnica que irá mudar sua vida, mas relevante para alguns poucos desavisados.
Era sobre os projetos que desenvolvemos aqui na ZNC, não deu pra mostrar muito, a net não estava ajudando na hora de acessar os sistemas ou o nosso repo. Pegamos então algumas telas que estavam no
HD,  principalmente telas de mapas para ilustrar e mostrar que os
sistemas
existiam. Django nasceu para fazer sistemas web - Mostramos rapidamente algumas telas de sistemas desenvolvidos por nós,  principalmente, para soluções que necessitam interfaces GIS. Existem  outros projetos mais complexos que aqueles mostrados, com uma grande quantidade de dados e workflows,  sempre utilizando Django. 
A propaganda não era sobre a ZNC, mas sobre o DJANGO! ele vai muito além de blogs :( 
A próxima será, "como Django me salvou" e como ganhamos eficiência no desenvolvimento web com o uso do Django.

Hora hobby - No último dia, passei pelo menos 1 hora com o pessoal da Global Code falando de arduino, e eletrônica digital.

Hora responsa- E claro, a Assembléia da Associação Python Brasil - Eu deveria ter levantado a mão!
Meus parabéns a velha e a nova diretoria da APyB. Não sei se já falaram aqui, o Osvaldo Santana é o novo presidente da APyB, acho que o pessoal da diretoria irá fazer uma apresentação mais formal pra lista. Caso contrário, deveriam. 

Lamento por aqueles que não puderam ir, e lamento pela comunidade também,  que perde com a "não presença" de alguns Pythonistas. Essa vale  pro Marinho Brandão, que tem na manga alguns projetos muito  interessantes, pra dizer o mínimo. Esse goiano é mineiro (é é mesmo, como descobri semanas atrás quando nos encontramos ! hehehe)  um dos grandes contribuidores para o universo de aplicações Django. Sobre os projetos, deixo pra ele um dia comentar. 

Agora vou colocar um lembrete no google calendar para que em março ou abril do ano que vem, eu reescreva os benefícios de participar de uma Python Brasil, esperando que o lembrete ajude mais gente a se programar para a Python Brasil do ano que vem.

Saio da Python Brasil com um grande ímpeto em colaborar mais. Não basta estar aqui na lista.

 - A APyB precisa de ajuda para desenvolver algumas aplicações para auxiliar na administração de assinantes e participantes de eventos (por exemplo). 
 - Conversando com o Henrique Bastos (roda que falava sobre a Django Brasil - ver post na lista Python-BR) o Henrique acha que precisamos de mais 
blogs, código e how tos sobre Django, não tinha essa "idéia" mas acabei concordando. Isso poderia ajudar na falta da documentação em PT-BR , talvez enfatizar nos how-tos a leitura do código fonte do django.

um projeto novo: uma  "Base de Conhecimento Django"  - onde será proibido publicar comentários em qualquer coisa diferente de PT-BR, acho que pode ajudar o desenvolvedores local.

A cada ano, após a Python Brasil, me sinto um pouco mais "dentro" da comunidade, e esse é um dos benefícios de estar lá. Conhecer pesssoalmente os grandes contribuidores da comunidade Python no brasil. 

Pra quem ainda não afiliou-se, uma ótima maneira de começar a contribuir é afiliar-se a APyB. - 40 pilas no ano ?!?! pois é.


Saudações a todos.

sexta-feira, setembro 02, 2011

Postgres: Qual o tamanho do banco de dados no seu sistema de arquivos (disco) ?

... na linha de comando, através do 'psql' 




postgres=# SELECT pg_database.datname,
postgres-# pg_size_pretty(pg_database_size(pg_database.datname)) AS size
postgres-# FROM pg_database;


datname | size
------------------+---------
template1 | 4272 kB
template0 | 4272 kB
postgres | 4364 kB
znc | 4272 kB
teste | 8128 kB
template_postgis | 7416 kB
circuitonobre | 8336 kB
postfix | 4908 kB
teste | 11 MB
znc_gerencia | 9048 kB
pam | 14 MB
tnc_uc | 48 MB
(12 rows)


postgres=# SELECT pg_size_pretty(pg_database_size('sorocaba_sig')) As fulldbsize;


fulldbsize
------------
8568 kB
(1 row)


postgres=# SELECT pg_database.datname,
pg_size_pretty(pg_database_size(pg_database.datname)) AS size
FROM pg_database where datname = 'sorocaba_sig';


datname | size
--------------+---------
sorocaba_sig | 8568 kB
(1 row)

segunda-feira, junho 13, 2011

quarta-feira, maio 18, 2011

Queryset com aggregate utilizando uma "parte" de um date time field.

LeituraConsolidada.objects.filter(data_leitura__year='2011').extra(select = {'mes':'extract(month from data_leitura)'}).values('mes').annotate(Avg('ozonio'), Avg('dioxido_enxofre'))

#Saida
[{'ozonio__avg': 24.965, 'dioxido_enxofre__avg': -0.42499999999999999, 'mes': 1.0}, {'ozonio__avg': 43.613333333333337, 'dioxido_enxofre__avg': -0.28000000000000003, 'mes': 2.0}]

LeituraConsolidada.objects.filter(data_leitura__year='2011').extra(select = {'mes':'extract(month from data_leitura)'}).values('mes').annotate(Avg('ozonio'), Avg('dioxido_enxofre'))

quarta-feira, março 23, 2011

Transações de banco de dados postgres no django

O django, por padrão faz commit automaticamente as transações no banco de dados.
Django’s default behavior is to run with an open transaction which it commits automatically when any built-in, data-altering model function is called. For example, if you call model.save() or model.delete(), the change will be committed immediately.
Isso quer dizer que caso haja um erro durante a transação no banco de dados as transações subsequentes também não serão executadas. Este comportamento poder ser útil em alguns casos, mas não todos! Mas o django como sempre lhe dá liberdade para alterar o comportamento padrão, e geralmente de uma maneira muito simples. Este é o caso.

Vamos supor que queremos inserir 100 registros novos no banco de dados Postgres que foram lidos de um excel.
E no 10º registro ocorra em um campo string que exceda o tamanho do campo no banco de dados, como abaixo

* DatabaseError('value too long for type character varying(70)
* DatabaseError('current transaction is aborted, commands ignored until end of transaction block
...
* DatabaseError('current transaction is aborted, commands ignored until end of transaction block]

o primeiro erro é por causa de uma string maior do que a aceita pelo campo no banco de dados.
Os error subsequentes, ocorreram simplesmente porque houve um erro ! oops, confuso?
veja a primeira mensagem de error

  • mensagem 1 - value too long for type character varying(70)
  • mensagem 2 em diante - current transaction is aborted, commands ignored until end of transaction block

a partir da msg de erro 2, o que temos é um erro de transação pendente, porque o commit automático não ocorreu.
O código executado é algo parecido com isso abaixo

for row_index in range(20 ):
    try:
        model_instance.save()            # salvar o modelo
    except Exception, error_str:
                error_list.append(error_str)


No meu caso, eu quero continuar as inserções no banco, mesmo que haja erro em algumas delas.
A saida é fazer um Savepoint Rollback! THANKS DJANGO !
Savepoint rollback
If you are using PostgreSQL 8 or later, you can use savepoints to control the extent of a rollback. Before performing a database operation that could fail, you can set or update the savepoint; that way, if the operation fails, you can roll back the single offending operation, rather than the entire transaction.
O que é dito aqui, é que ao salvar um ponto de rollback, eu posso comitar as transações que ocorreram sem erro, e dar um "rollback" somente na transação que falhou.
O código ficaria assim

for row_index in range(20 ):
    try:
        sid = transaction.savepoint()  # salvar ponto da transação
        model_instance.save()            # salvar o modelo
        transaction.savepoint_commit(sid)  # aplicamos o commit da transação
    except  Exception, error_str:
        error_list.append(error_str)
        transaction.savepoint_rollback(sid) #rollback somente da transação que falhou

leia mais na docs do Django  em :   http://docs.djangoproject.com/en/1.3/topics/db/transactions/

segunda-feira, fevereiro 28, 2011