Welcome

Este blog tem como objetivo centralizar informações que estudamos. Parte dos posts são apenas resumos de livros, cursos e matérias provados com códigos. Contribuições ou correções são sempre bem vindas!

Próximos Eventos:
Sexta 26/set Agile Vale - São José dos Campos
4-9/Nov Python Brasil - Porto de Galinhas

08 setembro 2014

Instalando Pillow no Ubuntu 14.04 - x86_64-linux-gnu-gcc: error: No such file or directory

Problema:
O seguinte erro é apresentado ao tentar instalar o Pillow (2.5.3) no Ubuntu 14.04 LTS:

x86_64-linux-gnu -ljpeg -lz -ltiff -o build/lib.linux-x86_64-2.7/PIL/_imaging.so
x86_64-linux-gnu-gcc: error: build/temp.linux-x86_64-2.7/_imaging.o: No such file or directory
x86_64-linux-gnu-gcc: error: build/temp.linux-x86_64-2.7/decode.o: No such file or directory
x86_64-linux-gnu-gcc: error: build/temp.linux-x86_64-2.7/encode.o: No such file or directory
x86_64-linux-gnu-gcc: error: build/temp.linux-x86_64-2.7/map.o: No such file or directory
x86_64-linux-gnu-gcc: error: build/temp.linux-x86_64-2.7/display.o: No such file or directory


Solução:
Instalar os seguintes pacotes antes do Pillow:

# sudo apt-get install libtiff4-dev libjpeg8-dev zlib1g-dev libfreetype6-dev /
liblcms2-dev libwebp-dev tcl8.5-dev tk8.5-dev python-tk
# sudo apt-get build-dep python-imaging

Após a instalação dos pacotes, será possível a instalação normal via pip:

# pip install Pillow
    PIL SETUP SUMMARY
    --------------------------------------------------------------------
    version      Pillow 2.5.3
    platform     linux2 2.7.6 (default, Mar 22 2014, 22:59:56)
                 [GCC 4.8.2]
    --------------------------------------------------------------------
    --- TKINTER support available
    --- JPEG support available
    *** OPENJPEG (JPEG2000) support not available
    --- ZLIB (PNG/ZIP) support available
    --- LIBTIFF support available
    --- FREETYPE2 support available
    --- LITTLECMS2 support available
    --- WEBP support available
    --- WEBPMUX support available

Source Links:
http://pillow.readthedocs.org/en/latest/installation.html
http://unix.stackexchange.com/questions/105265/install-pil-pillow-via-pip-in-debian-testing-jessie
http://askubuntu.com/questions/156484/how-do-i-install-python-imaging-library-pil



30 maio 2014

AWS Summit 2014 - São Paulo



 Matt Tavis

Esta última terça-feira (27 maio) aconteceu o AWS Summit - evento gratuito que apresenta os serviços da Amazon Web Service e alguns casos de sucesso de clientes da AWS.
Tentarei apresentar um pouco do que consegui registrar:

Why Cloud?
# Agility
# Platform Breath
# Continual Innovation Iteration
# Cost saving and Flexibility

Apresentação do EHorai sobre Performance e Cloud Front:











Apresentação sobre Route 53:



Route 53: DNS Gerenciado
Desenhado para ser rápido
Latência baixa de resolução DNS
Rede global de servidores de DNS
Queries roteadas para o servidor DNS mais próximo


Case da Webmotors:





Amazon CloudSearch:

Apresentação incrível do Fabio Silva, onde foi demonstrado como fazer uma aplicação de pesquisa juntando informações de milhões de musicas + suas localidades:









http://aws.amazon.com/cloudsearch/free-trial/faqs/



AWS e Segurança:




Resumo do que existe na AWS:

 

Amazon CloudFront: Serviço web que oferece entrega de conteúdo, distribuída globalmente e de alta performance.

Amazon Elastic Compute Cloud (Amazon EC2): Serviço web que oferece capacidade computacional redimensionável na nuvem.

Amazon Relational Database Service (Amazon RDS): Serviço web que oferece capacidade rentável e redimensinável, para implementações do MySQL na nuvem.

Amazon SimpleDB: Serviço web para execução de consultas sobre dados estruturados em tempo real.

Amazon Simple Notification Service (Amazon SNS): Serviço web altamente escalável e flexível que torna fácil configurar, operar e enviar notificações a partir da nuvem.

Amazon Simple Queue Service (Amazon SQS): Sistema de filas seguro e de alta performance para distribuição do trabalho de forma confiável entre processos de aplicações.

Amazon Simple Storage Service (Amazon S3): Uma interface de serviços web que pode ser usada para armazenar e recuperar grandes quantidades de dados, a qualqer ou lugar na web.

Amazon Virtual Private Cloud (Amazon VPC): Uma ponte segura e transparente entre a estrutura de TI existente de sua empresa e a nuvem da AWS.


Mais links:
https://aws.amazon.com/pt/
www.slideshare.net/AmazonWebServicesLATAM/tag/aws-summit-brasil-2014
http://awshub.com.br






02 maio 2014

Trabalhando fora da master com branch local e rebase no Git

Quando trabalhamos diretamente na branch master no Git é comum notar diversos merges automáticos:


O que acontece é o git juntando o código do repositório remoto com o seus novos commits.

Uma forma para minimizar problemas com merge e conflitos é trabalhar com branches locais.

Principalmente quando você tem uma tarefa que pode demorar dias, ao invés de ter uma surpresa ao fazer git pull após um longo período.
É isolar seu código em uma branch local, assim será possível ir para a master e fazer git pull (sem conflitos) quantas vezes necessário.

Exemplo:
Imagine que você tem uma tarefa, uma feature para implementar.

1 - Crie uma branch local para iniciar a tarefa:
 
git co -b task50_bugfix
git add file1 file2
git ci -m "bugfix #50"

 
2 - Quando possível, baixe os códigos do repositório remoto
(de preferência quando seu working directory estiver limpo)

git co master
git pull
# Se você tiver código do repositorio remoto:
git co task50
git rebase master
(Se alguem alterou no mesmo local que você, será gerado conflitos neste ponto)

A ideia é fazer este processo várias vezes ao dia, será mais fácil testar e resolver conflitos em poucos commits do que em vários commits após uma semana de commits da sua equipe.

3 - Salvando o código no repositório remoto:
Quando você terminar sua tarefa na sua branch local, são necessários 2 passos:
i) garantir que você baixou os novos commits ( git pull na master - como mostrado no passo anterior)
ii) copiar seu código da branch local para a master antes de fazer git push

git co master
git merge task50_bugfix
git push




Para deletar a branch local:


git br -d task50_bugfix


13 abril 2013

Um pouco sobre Inbox Zero

Em poucas palavras, Inbox Zero tem como objetivo tratar seus e-mails de uma forma que você não gaste tanto tempo lidando com ele, e ao mesmo tempo saiba o que esta pendente ou não. São sugestões para você melhorar seus hábitos com seu e-mail.

Eu comecei a práticar Inbox Zero no começo deste ano (2013), e passado alguns meses, posso afirmar que tem me ajudado bastante. A principal motivação é não ter mais aquela sensação de que estou esquecendo algo. Navegando pelas divisões de pastas pendentes*, é possível saber exatamente o que é necessário ler, responder ou tomar alguma ação.




Inbox Zero foi criado pelo Merlin Mann em 2006, eu acabei conhecendo este assunto em um post da Bluesoft, quando estava estudando sobre 'Getting Things Done' (GTD).

Para quem quiser saber mais ou ver mais detalhes, recomendo fortemente que leia os posts originais do autor. Sendo que fiz um pequeno resumo do meu entendimento, e não estou abordando todos os pontos.

Para melhor o entendimento, o conteúdo deste post foi dividido em 4 partes:

1 – É necessário mudar nossos hábitos:

Você já parou para pensar que algumas vezes acabamos respondendo o último e-mail que recebemos, onde o mais correto seria responder o mais antigo. E pior, este e-mail mais antigo, cada vez fica menos importante e você pode acabar deixando-o de lado.

Alguns lembretes:
- Mentir para você mesmo não irá limpar sua caixa de entrada, deixar para amanhã um e-mail, sendo que amanhã terão outros novos e-mails.
- Não trate cada e-mail como um presente de Natal
- Não use seu e-mail para fazer lista de tarefas (TO DO List)
- Crie filtros para mover ou apagar e-mails recorrentes

2 – Processando seu e-mail:

Uma grande diferença é que normalmente estamos acostumados a ter uma única forma de lidar com o e-mail, onde as vezes apenas checamos o que recebemos e outras vezes respondemos de verdade.

Com Inbox Zero, precisamos separar isto em 2 etapas, onde processar é uma rápida leitura em cada e-mail para saber do que se trata e em seguida tomar uma ação adequada, ou seja, cada e-mail é um 'Open Loop' que precisa ser: Deletado, Delegado, Respondido ou Movido para uma das 'Pastas Pendentes'. Os e-mails que podemos Deletar, Delegar ou que podemos responder em menos de 2 minutos, devemos tomar esta ação no mesmo instante. Os e-mails que precisamos de mais tempo para responder ou não temos todas as informações para tal naquele momento, devemos movê-los para as respectivas pastas.

Desta forma, após o processamento, a caixa de entrada ficará vazia. O que explica o nome Inbox Zero.

3 – Tratando as Pastas Pendentes:

Tirando os e-mails apagados, delegados e respondido no processamento, temos os e-mails que sobraram e que estão aguardando uma ação e estão armazenados em algum lugar nas pastas pendentes (fora da caixa de entrada). Pastas Pendentes podem ser interpretadas como uma estrutura para organizar nossos e-mails. Esta estrutura é livre, cada um pode tratar como bem entender ou achar mais interessante. Apenas é importante lembrar que, esta estrutura deve ser simples, sendo que você não pode ter muitas opções, a tarefa de mover da caixa de entrada para esta estrutura deverá ser simples e rápida.

Abaixo, gostaria de apresentar a estrutura que vem funcionando para mim:
1-RespondTo_soon
2-RespondTo_oneday
3-Todo_soon
4-Todo_ondeday
5-ToRead
6-Archive

 
Desta forma, eu tento todo dia esvaziar as pastas:
1-RespondTo_soon
3-Todo_soon


E quando tenho mais tempo ou simplesmente estou disposto, tento esvaziar as pastas:
2-RespondTo_oneday
4-Todo_ondeday
5-ToRead


A pasta 6-Archive é utilizada para armazenar os e-mails finalizados. Para facilitar a localização dos e-mails arquivados, crio sub-pastas com o assunto e o ano, desta forma, consigo ter uma estrutura que facilita a visualização dos meus e-mails na linha do tempo.

Por último, se você achou interessante e quer começar agora o Inbox Zero, em apenas dois passos é possível iniciá-lo, veja abaixo:

i) Adotar sua estrutura de pastas
ii) Fazer o processamento dos seus e-mails.

Como você deve ter 5 ou 10 anos de e-mails, será quase impossível processar toda esta quantidade. Eu adotei a estratégia de processar meus 2 últimos meses, os demais e-mails apenas movi para uma pasta chamada 'Muito-Antigo'. Desta forma, em poucas horas consegui ter minha caixa de entrada vazia e alguns e-mails nas pastas pendentes.

Finalmente, gostaria de reforçar que o Inbox Zero tem sido muito útlil para minha organização. Também acredito que estou gastando menos tempo com e-mail e me dedicando a fazer outras atividades.





Links:
http://inboxzero.com/articles/
http://www.43folders.com/2006/03/13/philosophy
http://www.43folders.com/2006/04/04/better-practices
http://www.slideshare.net/melvinramos/inbox-zero-1508788
http://inboxzero.com/video
http://www.nikilster.com/thoughts/how-to-win-at-email/#sthash.DchOqz3M.blbBSzC6.dpbs


by rAc
bit.ly/XJeIgJ 
 

21 janeiro 2013

Evite problemas com Logging, Cluster e Multi JVMs

Devem-se tomar algumas precauções ao configurar o log4j em aplicações que rodam em um cluster de servidores de aplicação.

A principal delas é separar os arquivos de log por servidor. 

Por quê? 

Quando se tem em uma mesma máquina mais de um servidor, ou seja, mais de uma JVM haverá concorrência de escrita no arquivo. Basta sua aplicação receber algumas requisições  simultâneas em servidores distintos para os sintomas abaixo serem notados:
·         Mensagens com horários desordenados
·         Mensagens corrompidas
·         Mensagens sobrepostas
·         Mensagens perdidas

Evitar esses problemas é simples.

Solução 1 - Parametrização manual

Adicionar um parâmetro de JVM (VM argument) em cada servidor que o identifique.
-DserverName=”server1”

No log4j modificar o nome/caminho do arquivo para utilizar o parâmetro definido no servidor.
<appender name="appender1" class="org.apache.log4j.DailyRollingFileAppender">
<param name="File" value="/logs/webapp1/application-${serverName}.log"/>
ou
<appender name="appender1" class="org.apache.log4j.DailyRollingFileAppender">
<param name="File" value="/logs/webapp1/${serverName}/application.log"/>

Solução 2 - Parametrização automática

Em clusters com muitos servidores a parametrização manual torna-se dificil manter. Automatizar esse processo não é complicado.

O exemplo abaixo foi desenvolvido para WebSphere, porém, pode ser utilizado como base tanto para ser genérico quanto para outros servidores específicos.

Primeiro, cria-se um ServletContextListener que verifica a existência do parâmetro de JVM e caso não exista ele é adicionado. Esse listener deve ser executado primeiro pela aplicação.

package br.com.billcode.listener;

import java.lang.reflect.Method;

import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;

public class ServerNameListener implements ServletContextListener {

    private static final String SERVER_NAME_KEY = "SERVER_NAME_KEY";

    public void contextDestroyed(ServletContextEvent event) {
        // Do nothing
    }

    public void contextInitialized(ServletContextEvent event) {
       
        String serverNameArgument = event.getServletContext().getInitParameter(SERVER_NAME_KEY);
           
        if (serverNameArgument == null){
            return;
        }
       
        String serverName = System.getProperty(serverNameArgument);
       
        // Verifies if the parameter already exists
        if(serverName != null){
            return;
        }
       
        serverName = generateServerName();
               
        if(serverName == null){
            return;
        }
       
        System.setProperty(serverNameArgument, serverName);
    }

    /**
     * @return The WebSphere Server's display name. 
     */
    private String generateServerName() {
        String serverName = null;

        try {
            Class<?> serverNameClass = Class.forName("com.ibm.websphere.runtime.ServerName");
            Method method = serverNameClass.getMethod("getDisplayName", null);
            serverName = (String) method.invoke(null, null);

        } catch (Exception e) {
            throw new RuntimeException(e);
        }        
               
        return serverName;
    }
}


Segundo, adiciona-se o listener ao web.xml.
<listener>
     <listener-class>
br.com.billcode.listener.ServerNameListener</listener-class
</listener>
 
Terceiro, para o parâmetro de JVM não ficar fixo na aplicação adiciona-se um ContextParam.
<context-param>
   <param-name>SERVER_NAME_KEY</param-name>
   <param-value>serverName</param-value>

</context-param>

Quarto, no log4j modificar o nome/caminho do arquivo para utilizar o parâmetro definido como ContextParam no web.xml.
<appender name="appender1" class="org.apache.log4j.DailyRollingFileAppender">
<param name="File" value="/logs/webapp1/application-${serverName}.log"/>
ou
<appender name="appender1" class="org.apache.log4j.DailyRollingFileAppender">
<param name="File" value="/logs/webapp1/${serverName}/application.log"/>

22 outubro 2012

Dicas para melhorar a utilização do Git

1 - Adicionar configurações de cores

É possível exibir os resultados coloridos dos comandos do Git, para isto:
- Adicionar o conteúdo abaixo no arquivo de configurações do git: ~/.gitconfig

[user]
   name = Roger Camargo
   email = email@...

[color]
   diff = auto
   status = auto
   branch = auto
   interactive = auto
   ui = auto

[color "branch"]
   current = green bold
   local = green
   remote = red bold

[color "status"]
   added = green bold
   changed = yellow bold
   untracked = red

[alias]
   st = status
   ci = commit
   df = diff
   co = checkout
   br = branch
   lg = log --pretty=oneline --graph --date=short --decorate 
 
Resultado:


2 - Exibir o branch corrente no shell

Ao trabalhar com branch, é muito importante saber em qual branch esta no momento, afim de evitar commits em um branch indesejado.
- Adicionar o conteúdo abaixo após a definição da variável PS1 no arquivo ~/.bashrc

# git branch
PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '


Ou uma segunda opção para mostrar a branch em uma cor diferente

# git branch
PS1='\[\033[01;32m\]\w\[\033[01;34m\]$(__git_ps1 " (%s)")\n\[\033[00m\]\u@\h\$ '
 
Resultado:



3 - Instalando ferramenta visual para histórico de alterações

Por padrão o git possui o git log para exibir o histórico de alterações (commits), o GitK é uma versão visual. Para instalar o gitk:

$ sudo apt-get install gitk

Com o gitk instalado, é possível executar os comandos:
  • Para exibir todos os commits de todas os branches
      $ gitk --all 
 
  • Para exibir o histórico de alterações de um arquivo específico:
      $ gitk [arquivo] 
 



4 - Instalando ferramenta para facilitar o merge de arquivos em caso de conflitos

Ao executar o comando git rebase ou git merge, existe a possibilidade de ocorrer um ou mais conflitos.
Uma alternativa mais eficiente para resolver estes conflitos é o kdiff3. Assim após executar git mergetool, será executada uma ferramenta gráfica para ajudar na resolução do problema.

Para instalar o kdiff3:

 $ sudo apt-get install kdiff3

Adicionar configurações da ferramenta padrão de merge no arquivo de configurações: ~/.gitconfig

[user]
   name = Roger Camargo
   email = email@...

[color]
   ...

[merge]
   tool = kdiff3
 
Resultado do git mergetool:

Links relacionados:
http://blog.billcode.com.br/2012/05/comecando-com-git-para-usuarios-de-svn.html


by rAc

http://bit.ly/PNqu5H
 

27 maio 2012

Começando com Git (para usuários de SVN ou CVS)

Este post além de ser um guia para quem esta começando, é uma tentativa de apontar a diferença prática entre o SubVersion (SVN) e o Git. Em outras palavras, não irei mostrar os comandos equivalentes, nem a diferença entre centralizado e distribuído, ou ainda de delta e snapshot. Os quais são conteúdos interessantes e podem ser encontrados em outros artigos.

Acredito que quem está interessado em conhecer mais sobre o Git, no mínimo já teve alguma dificuldade com o SVN ou conhece algumas de suas limitações, bem como tem interesse em utilizar uma ferramenta melhor. Desta forma, não tenho a intenção de convencer quem trabalha com SVN a mudar para o Git. Ao invés disto, mostrar simplesmente as diferenças no contexto de utilização.

Em linhas gerais, é importante entender:
1 – Enquanto no SVN temos apenas um diretório de trabalho (geralmente o trunk do projeto), no Git temos as 3 áreas:
  - repositório local (que contem os branches) 
  - staging área (índice) 
  - working directory
2 – O último commit de cada branch é denominado o HEAD do branch
3 – No Git, diferente do SVN, os branches são locais e sua criação é simples (desta forma, o desenvolvedor tende a criar novos branches para cada atividade do dia a dia)
4 – A importância do comando rebase, antes de fazer merge entre branches (minimizar os conflitos)

A apresentação abaixo mostra através de desenhos os itens acima:

Existe também um resumo dos comandos do git
PDF

Referências
Boas práticas, técnicas para achar problemas e trabalhar com open-source entre outras coisas
http://www.caelum.com.br/curso/online/git

Screencast muito bom, com as explicações das 3 áreas entre outras coisas
http://akitaonrails.com/2010/08/17/screencast-comecando-com-git
http://git-scm.com/book
http://en.wikipedia.org/wiki/Git_%28software%29
http://www.vogella.com/articles/Git/article.html
http://rogerdudler.github.com/git-guide

Links relacionados:
http://www.codeforest.net/git-vs-svn
http://git.or.cz/course/svn.html
http://imasters.com.br/artigo/23356/desenvolvimento/por-que-voce-deveria-mudar-do-subversion-para-git-parte-01
http://www.ibm.com/developerworks/br/linux/library/l-git-subversion-1/
http://thinkvitamin.com/code/why-you-should-switch-from-subversion-to-git/
http://grokpodcast.com/2011/03/10/episodio-22-%e2%80%93-sistemas-de-controle-de-versao-%e2%80%93-parte-1/
http://grokpodcast.com/2011/03/18/episodio-23-%e2%80%93-sistemas-de-controle-de-versao-git-%e2%80%93-parte-2/
http://grokpodcast.com/2011/03/25/episodio-24-%e2%80%93-sistemas-de-controle-de-versao-github-%e2%80%93-parte-3/
http://sixrevisions.com/resources/git-tutorials-beginners
http://gitref.org/remotes
http://learn.github.com/p/intro.html
http://www.bernardofontes.net/blog/trabalhando-com-branchs-no-git-de-maneira-efetiv/

by rAc
http://bit.ly/K51QLh

21 fevereiro 2012

Sugestão de Trackers, Status e Category no Redmine

Este post tem apenas como objetivo uma sugestão das configurações para utilização do Redmine.

Trackers:
São os tipos de tarefas relacionadas a construção de software, que um desenvolvedor trabalha no seu dia a dia.
Feature: Uma nova funcionalidade
Improvement: Melhoria de uma funcionalidade existente
TechnicalDebt: É algo que precisa ser melhorado, porém não esta relacionado as funcionalidades, mas sim ao design de código (refactoring)
Task e Support: São tarefas que não estão diretamente ligadas ao código, por exemplo: um estudo, POC ou ajuda a um usuário.

Também pode-se criar um tracker chamado Backlog, o qual representará itens que poderão ou não tornarem Issues.

Obs: Um item de Backlog pode dar origem a uma ou mais Issues (Feature/Improvement), mas é interessante ligar esta nova Issue ao backlog utilizando o 'Parent task'. Mantendo assim a rastreabilidade.


Status:
São os estados das tarefas: Aberto, Em andamento e Fechado.
É interessante ter um estado chamado Parado, para identificar os impeditivos do projeto.



Workflow:
Com os Trackers e Status criados, é necessário montar o workflow, que basicamente é informar para o redmine quais status são possíveis para cada tracker.
 

Obs: Na configuração acima, o workflow está bem livre, em outras palavras, de um status pode-se mudar para qualquer outro. Por exemplo, uma vez no status InProgress (segunda linha), pode-se mudar para Stopped, Closed ou Canceled, quanto voltar para Open, o que algumas vezes não é o desejado. Neste caso, pode-se desmarcar o Status Open da segunda linha.



Category:
As categorias, diferentemente dos trackers e status, são por projeto.
Desta forma, sua configuração depende de cada caso, mas está relacionada a organização.
Alguns exemplos:

i) módulo: core, web, banco de dados, engine de busca
ii) negócio: contas à pagar, contas à receber, cadastro
iii) time: design, implementação, documentação



by rAc

hit