quarta-feira, 26 de fevereiro de 2014

Instalando o PySide no Ubuntu 13.10

Saudações, galera!

Hoje comecei a brincar com o PySide.

Para montar o ambiente, segui os seguintes passos:

1º Criação do virtualenv na pasta do projeto, óbvio:

$ virtualenv env

2º Instalação das dependências do PySide:

$ sudo apt-get install build-essential git cmake 
qt4-default libqt4-dev libphonon-dev python2.7-dev libxml2-dev libxslt1-dev qtmobility-dev
3º Instalação do PySide:

$ ./env/bin/pip install PySide

A compilação do PySide demora um bocado...

Após instalado é partir para o abraço!

Hello, World PySide

# -*- coding: utf-8 -*-

import sys
from PySide import QtCore, QtGui

app = QtGui.QApplication(sys.argv)

win = QtGui.QWidget()

win.resize(320, 240)
win.setWindowTitle(u"Olá, Mundo!")
win.show()

sys.exit(app.exec_())


terça-feira, 28 de maio de 2013

Como obter o repositoryId de uma instância do Alfresco

Olá, pessoal.

Para conectarmos uma aplicação a uma instância do Alfresco, via API CMIS, um dos parâmetros requeridos para a abertura da sessão é o REPOSITORY_ID, conforme podemos ver na documentação do ApacheChemistry:
// default factory implementation
SessionFactory factory = SessionFactoryImpl.newInstance();
Map<String, String> parameter = new HashMap<String, String>();

// user credentials
parameter.put(SessionParameter.USER, "Otto");
parameter.put(SessionParameter.PASSWORD, "****");

// connection settings
parameter.put(SessionParameter.ATOMPUB_URL, "http://<host>:<port>/cmis/atom");
parameter.put(SessionParameter.BINDING_TYPE, BindingType.ATOMPUB.value());
parameter.put(SessionParameter.REPOSITORY_ID, "myRepository");

// create session
Session session = factory.createSession(parameter);

Para descobrir o REPOSITORY_ID da instância que você precisa conectar basta executar o seguinte comando em um terminal:

curl -uadmin:admin "http://localhost:8080/alfresco/s/cmis" | grep repositoryId

O REPOSITORY_ID será retornado entre as tags <cmis:repositoryId>...</cmis:repositoryId>.
O comando acima supõe que a instância possui um usuário administrador cujo login é admin e a senha é admin. E que a instância está rodando na máquina local na porta 8080.


quinta-feira, 2 de maio de 2013

Introdução [de 5 minutos] ao tuning do PostgreSQL


Tradução livre, escrita por mim, do original "5-Minute Introduction to PostgreSQL Performance" (http://www.westnet.com/~gsmith/content/postgresql/pg-5minute.htm). 
 
O PostgreSQL vem de fábrica com uma configuração básica que visa a compatibilidade com o máximo possível de dispositivos, o que prejudica muito o desempenho. Há boas chances de os parâmetros padrão serem muito aquém do que o seu sistema suportaria.

Ao invés de descrever cada detalhe de tudo o que você deveria eventualmente saber, aqui nós daremos uma visão simplificada dos princípios básicos, com um olhar voltado para os itens mais comuns relacionados ao desempenho e as coisas que os iniciantes no PostgreSQL geralmente não tem conhecimento. Para uma leitura verdadeiramente muito rápida, leia apenas as linhas em negrito em cada seção e siga essas orientações.

Os principais parâmetros do servidor de banco de dados são mantidos em um arquivo chamado postgresql.conf. Você precisará editar este arquivo e reiniciar o servidor para que as alterações façam efeito. O desempenho deverá cair por um curto período de tempo depois de fazer isso porque o sistema vai perder as informações que são armazenadas em cache durante a reinicialização.

Utilize uma versão atualizada

A primeira versão do PostgreSQL que tem bom desempenho em hardware atual é a 8.1, a versão atual 8.2 é ainda melhor (você provavelmente deve estar executando a versão 8.2.4, versões anteriores a 8.2 tinham algumas peculiaridades que é melhor você evitar). Caso esteja executando uma versão anterior a 8.1 considere realizar o upgrade. Há muitos problemas de desempenho que são insolúveis em versões antigas. Se você estiver executando uma versão antiga desconsidere a seção a seguir.

Defina shared_buffers e effective_cache_size baseado na memória total

O parâmetro de configuração shared_buffers determina quanta memória é dedicada ao uso do PostgreSQL para armazenar dados. Um valor razoável para shared_buffers é 1/4 da memória do seu sistema. É provável que seja necessário aumentar o tamanho da memória que o sistema operacional permite alocar de uma vez para definir este valor. Consulte “Gerenciando recursos do kernel” para mais detalhes. Note que no Windows grandes valores para shared_buffers não são tão eficazes e você pode encontrar melhores resultados mantendo-o relativamente baixo e usando o cache do sistema operacional ao invés.

effective_cache_size deve ser definido como a quantidade de memória de sobra para o cache de disco tendo em conta que é usado pelo sistema operacional, memória dedicada ao PostgreSQL e outras aplicações. Se o valor for muito baixo, os índices não podem ser utilizados para a execução de consultas da maneira que você esperaria. Definindo a effective_cache_size como 1/2 do total de memória seria uma configuração conservadora normal. É possível encontrar uma melhor estimativa olhando para as estatísticas do seu sistema operacional. Em sistemas UNIX-like, somando os números free+cached do free ou top. No Windows, consulte o "Cache do sistema" na aba Desempenho do Gerenciador de Tarefas do Windows. Observe que você deve adicionar o valor definido para shared_buffers a este total - o query planner utiliza estimated_cache_size tal como está, sem acrescentar valor para você.

Analise o seu banco de dados

O PostgreSQL mantém estatísticas sobre suas tabelas que permitem executar corretamente as consultas. Se estas estatísticas estão desatualizadas você não terá um bom desempenho. Você pode atualizar as estatísticas usando o comando ANALYZE. Para fazer isso e limpar os dados não utilizados, execute o comando VACCUM ANALYZE para forçar uma atualização das estatísticas e limpeza das tabelas. Isto é particularmente importante se você acabou de carregar ou modificar uma grande quantidade de dados. Você deve dar uma lida em limpeza automática das tabelas se ainda não o fez, o que também irá manter as estatísticas atualizadas.

EXPLAIN ANALYZE suas sentenças lentas

Se você tem uma sentença específica que está executando e que está levando mais tempo do que o esperado, a melhor maneira de descobrir por que ele não está funcionando mais rápido é olhar para o que está fazendo. Execute EXPLAIN ANALYZE para obter um relatório de porque uma declaração está demorando muito tempo para ser executada. Isso pode levá-lo a ajustar outros parâmetros do servidor, por exemplo, se você notar que uma operação de classificação está tomando muito tempo, pode ser necessário aumentar o parâmetro work_mem em seu postgresql.conf. Note que work_mem é definido em uma base de conexão por cliente, por isso é necessário multiplicar o valor por sessões simultâneas para obter um valor total de memória. Você pode usar aumentar o valor apenas para uma sessão que executa uma consulta maior do que a maioria, usando um comando como set work_mem GB = '1'; (que é a sintaxe 8.2, você terá que especificar manualmente um valor no 8.1).

Aqui termina seus 5 minutos. Daqui pra frente você pode ir sozinho. O principal problema com a maioria desses documentos é que eles são um pouco antigos. Dirigem-se a versões anteriores do PostgreSQL que funcionam um pouco diferente das atuais e algumas das recomendações específicas para os parâmetros são bastante subdimensionadas para equipamentos modernos. A maior diferença é que costumava ser impraticável usar valores grandes para shared_buffers, a partir da versão 8.1 e superiores está tudo certo.




Além disso, você não pode ignorar o enorme volume de informações na documentação do PostgreSQL. A sua força é também sua fraqueza: um monte de coisas não está organizada.
Copyright 2007 Gregory Smith. Última atualização 2010/01/29.