Realize suas ambições com Open Source

Há uma grande chance de você não estar desenvolvendo software em seu trabalho que realizem os seus maiores sonhos de desenvolvimento de software. Talvez você esteja desenvolvendo software para uma grande companhia de seguros enquanto você gostaría mesmo é de estar trabalhando na Google, Apple, Yahoo ou na sua própria startup desenvolvendo a próxima grande sacada. Você nunca chegará onde você quer desenvolvendo software para sistemas que você não está nem aí.

Felizmente, há uma resposta para o seu problema: open source. Há milhões de projetos open source por aí, muitos deles bastante ativos, oferecendo a você todo tipo de experiência com desenvolvimento de software que você podería desejar. Se você gosta da idéia de desenvolvimento de sistemas operacionais, ajude com um das dezenas de projetos de sistemas operacionais que se tem por aí.
Se você quer trabalhar com software de música, animação, criptografia, robótica, pc games, jogos online, dispositivos móveis, ou o que seja, você com certeza irá encontrar ao menos um projeto open source dedicado a esse interesse.

É claro que não há almoço grátis. Você precisa estar disposto a doar seu tempo livre porque provavelmente você não pode trabalhar no seu jogo open source no seu dia de trabalho - você ainda tem responsabilidades com seu chefe. Contudo, pouquíssimas pessoas ganham dinheiro contribuindo com projetos open source - algumas mas não todas. Você precisa estar disposto a abrir mão de seu tempo livre (menos tempo jogando videogames e assistino tv não vai matá-lo). Quanto mais pesado você trabalha em um projeto open source mais rápido suas ambições como desenvolvedor se realizam. Também é importante considerar as regras do projeto - alguns grupos podem restringir o que você pode contribuir, mesmo no seu próprio tempo. Contudo, você precisa ser cuidadoso com violações de leis de propriedade intelectual tendo a ver com copyright, patentes, marcas registradas, e segredos comerciais.

Open sorce promove enormes oportunidades para desenvolvedores motivados. Primeiro, você começa a ver como alguém implementaría uma solução que interessa a você - você pode aprender um bocado lendo códigos de outros desenvolvedores. Segundo, você começa a contribuir com seu próprio código e idéias para o projeto - nem todas as idéias brilhantes que você terá não serão aceitas mas algumas sim e você aprenderá algo novo apenas trabalhando em soluções e contribuindo com código. Terceiro, você conhecerá várias pessoas com as mesmas paixões do tipo de software em que você trabalha - esta amizade open source pode durar uma vida. Quarta, assumindo que você é um contribuidor competente, você estará habilitado para compartilhar ao mundo experiências na tecnologia que atualmente interessam a você.

Começar no open source é muito simples. Há uma riqueza de documentação por aí das ferramentas que você venha à precisar (e.g., sistemas de versionamento, editores, linguagens de programação, build systems, etc.). Ache o projeto que você deseja colaborar primeiro e aprenda sobre as ferramentas que o projeto usa. A documentação dos projetos em si é bem pouca na maioria dos casos, mas isto talvez seja o menor dos desafios porque a melhor maneira de aprender é investigando o código em si. Se você quer se envolver, você pode se oferecer a ajudar com a documentação. Ou você pode começar como voluntário para escrever test code. Pode ser que não soe muito excitante, mas a verdade é que você aprende bem mais rápido escrevendo test code para softwares de outras pessoas do que em qualquer outra atividade no software. Escreva test code, test code realmente bons. Ache bugs, sugira soluções, faça amigos, trabalhe no software que você goste, e realize suas ambições de desenvolvimento de software.

Post original: Fulfill Your Ambitions With Open Source by Richard Monson-Haefel

Produzindo Branches

Este documento tem como objetivo esclarecer algumas dúvidas sobre a produção de branches em um ambiente de desenvolvimento, é desejável que você possua um conhecimento razoável do sistema de versionamento de código Git. Algumas regras aqui aplicadas favorecem o uso de branches para criação de novas features do KFLuid.

Continue lendo...

Adicionando o qmake à variável $PATH

Quando você faz o clone do repositório do Qt no gitorious e instala o kit gráfico na sua máquina, é preciso setar o qmake da versão que você acabou de compilar, principalmente se você possui outras versões do Qt instaladas.
Para usar o qmake da versão mais recente do Qt, adicione o seguinte comando no arquivo .bashrc do seu home:

export PATH=[path da instalação]:${PATH}
(o path default é /usr/local/Trolltech/Qt-4.7.0/bin)
// não esqueça de retirar os []

Logo após salve e feche o arquivo, em seguida digite no terminal:

$ source .bashrc

Isso fará com que você use como padrão o qmake da versão mais recente do Qt instalado na sua máquina.

VIM - Configurações Essenciais

Algumas configurações podem ser aplicadas para que seu VIM seja bem mais produtivo do que você imagina, principalmente se você faz uso do editor para desenvolvimento de software ;).
Essas configurações podem ser aplicadas no arquivo /etc/vim/vimrc e deve ser editada como super-usuário, ficaria algo assim:

$ sudo vim /etc/vim/vimrc

abaixo seguem algumas configurações:

" dark background
set background=dark

" linhas numeradas
set number

" syntax colorida
syntax on

" indentação ativada
set autoindent

" tamanho da indentação
set ts=4

" habilita ações do mouse
set mouse=a

" marcadores de pares de parênteses
set showmatch

" procura texto enquanto digita
set incsearch

" usa magia pra procurar texto
set magic

" tecla backspace volta 4 espaços
set softtabstop=4

" mostra o último par de parênteses fechados
set sm

Após adicionar algumas das configurações citadas acima, é só sair do modo insert e salvar o arquivo.

Problemas com o Gnome-panel

Há pouco tempo tive alguns problemas com o gnome-panel. Alguns applets não apereciam no painel, e lembro-me que eu havia setado o Rhythmbox para ser inicializado como um applet mas toda vez que eu iniciava o player a aplicação não aparecia no painel, tudo parecia ok com o player como o pid, execução pelo terminal... e não era apenas o Rhythmbox, tinham outros applets que não estavam aparecendo no painel, e comecei a procurar a resolução do problema.
Percebi que isso acontece devido algumas mudanças de visual do gnome como, themes, compiz e outros.
De tudo que pesquisei apenas dois comandos me convenceram.
Digite no terminal os seguintes comandos:

$ gconftool-2 --recursive-unset /apps/panel
$ gnome-panel &

Depois disso o painel voltará as suas configurações iniciais, ou seja, as configurações default do painel da distro. Você terá que organizar e customizar seu painel novamente. ;)

Git: Branch Highlight

É possível destacar o branch corrente em que estamos trabalhando, para isso adicione ao seu arquivo bashrc as seguintes configurações:

Abra o arquivo com seu editor favorito

$ vim .bashrc

adicione ao final do arquivo a seguinte configuração:

PS1='${debian_chroot:+($debian_chroot)}\[\033[01;31m\]\u@\h\[\033[00m\]:\[\033[01;34m\]\w\[\033[01;30m\]$(__git_ps1 " [%s]")\[\033[0m\] \[\033[00m\]$ '

salve e feche o arquivo, e digite o seguinte comando:

$ source .bashrc

pronto agora você pode visualizar na linha de comando o branch corrente.

Listando diretórios com o comando tree

Há um outro jeito de listar diretórios sem a utilização do ls?
Sim, para que isso seja possível precisa-se baixar o pacote tree. Digite no terminal:

$ sudo aptitude install tree

Depois de instalado, digite:

$ tree

Este comando faz a listagem do diretório parecer uma listagem de árvore, com raiz e galhos.
É bom usá-lo para diretórios com poucos arquivos e subdiretórios, sua interface cresce verticalmente comprometendo a visibilidade da listagem.

Comunidade PHP-AM

Hoje fizemos a primeira reunião do grupo PHP-AM, estavam presentes o Moacir, Daniel Elias, Rodrigo Rezende, Heitor Ferreira e eu, claro.
Foram definidas metas e atribuições para cada membro presente, para organizar o grupo como um todo. Toda a infra e algumas idéias de projetos já foram boladas pelo pessoal que estava presente.
Estou muito contente com a iniciativa do grupo, todos os participantes estão decididos a enfrentar e superar obstáculos para promover o uso da linguagem PHP no Amazonas.
A idéia não é apenas divulgar mas criar um grupo de desenvolvedores mais sérios e dedicados com a ferramenta, com isso trazendo força do grupo local na comunidade nacional e internacional.
Espero que os participantes que estavam presentes hoje cumpram com seus deveres, mostrando assim à comunidade toda a dedicação e força que juntos podemos produzir. Uma comunidade pode ir muito além de seus objetivos quando as forças de seus membros estão concentradas e compartilhadas entre si.

Juntos podemos mudar o mundo.
Boa sorte à nós, nessa nova empreitada.

Adicionando data/hora ao histórico de comandos

Existe a possibilidade de adicionar à lista de histórico uma data/hora de um comando executado no terminal.
Para que isso seja possível adicione o seguinte comando ao final do seu arquivo bashrc:

# vim ~/.bashrc

export HISTTIMEFORMAT="%h/%d-%H:%M:%S "

Feito isto, salve e feche o editor de texto, na linha de comando digite:

# source ~/.bashrc

Digite no terminal o comando history, você irá perceber que agora existe uma coluna com a data e hora do comando executado.

Mostrando o diretório corrente no título do terminal

Digite no terminal o seguinte comando;

# vim /home/usuario/.bashrc

Acrescente ao final do arquivo:

export PROMPT_COMMAND='echo -ne "\033]0;${PWD/#$HOME/~}\007";'

Depois salve o arquivo e feche o editor.

Na linha de comando digite:

# source /home/usuario/.bashrc

Pronto!
Agora no título do terminal mostrará o caminho do diretório que você está atualmente, isso é ótimo para quem usa muitas abas em um mesmo terminal.

Debian Day 09

No dia 22 de Agosto será realizado o Dia Debian.
Mais informações no site oficial http://diadebian.org/

Abraços!!!!

Follow Friday

Follow Friday é um movimento no Twitter que os twitteiros indicam amigos para serem seguidos, usa-se a hashtag #followfriday e logo depois as indicações (ex: @fulano). O movimento realiza-se toda sexta-feira. Então pessoal antes de terminar o expediente e ir direto pra cachorrada na sexta-feira, não esqueçam de participar do movimento!!

Dicas

Existe um aplicativo semelhante ao Everest pro Linux, se chama hardinfo.
Já é possível baixá-lo pelos repositórios oficiais, então;

# aptitude install hardinfo

depois de instalá-lo vc pode averiguar todas as informações do hardware local.

Abraços!!!

man pages coloridas

Deixe as páginas dos manuais coloridas, é simples:

sudo aptitude install most

depois de instalado siga as instruçoes abaixo;

$ export MANPAGER="/usr/bin/most -s"
# or export MANPAGER="/usr/local/bin/most -s"
$ man bash

para que as configuraçoes tenham efeito após o login é necessário adicionar o comando
no arquivo .bashrc do seu home.

FISL 10 - Considerações

Minha primeira vez no FISL e com certeza é um dos melhores eventos sobre software livre que já participei. Neste evento você presencia a força que as comunidades exercem, muita gente compartilhando conhecimento, convocando novos participantes e isso é um dos princípios da liberdade, a comutação entre os povos.
Muitas palestras nas áreas científicas, muitos desses palestrantes estão fazendo um trabalho respeitável do ponto de vista acadêmico, cada um em sua área de atuação.
Esse evento é ótimo pra quem precisa se encontrar no software livre. Você fica por ali com as orelhas em pé e quando você ouve um chamado que soa bem aos seus ouvidos, você se encarrega do resto. É como se fosse uma chamada divina, você é útil em algum lugar aqui ou acolá.
Parabéns a todos os quais sacrificaram seu tempo para participar do evento, as comunidades, a prefeitura de POA, a PUCRS, e a toda a equipe de suporte do evento.
Ahhh e claro!!! ao nosso presidente Lula que compareceu e dedicou parte do seu tempo para visitar o evento, tomara que alguém tenha instalado alguma distribuição para o presidente. Valeu!!!!!

PARABÉNS!!!!!!!!!

PC Remote - Update

E ae pessoal, tudo shibata!!!!

Devido a uma reunião com a equipe de desenvolvimento do PC Remote, ficou resolvido que o software passará por um update. Toda a arquitetura e a plataforma de desenvolvimento será substituido pelo Qt, então aqueles que querem ter a única versão do software em Python e EFL (client), Python e GTK (server) poderão fazer o clone do repositório o quanto antes, segue os links;

git clone https://git.maemo.org/projects/remotepc
git clone git://gitorious.org/pc-remote/pc-remote.git

Abraços!!!!

Usando lambda

O uso de expressões lambda permitem a criação de funções anônimas com apenas uma linha de código, estas funções podem ser armazenadas em variáveis as quais irão representar um tipo "function". Estas variáveis podem ser usadas em outras expressões de acordo com seu escopo, podem ser passadas como argumentos para outras funções e pode-se ainda realizar operações de acordo com o intuito da "função anônima".

O uso correto do lambda para criar tais funções nos fornece altíssimo poder de desenvolvimento, o lambda ainda é um pouco misterioso e confuso para muitos desenvolvedores, incluse pra mim ;) .

Mas assim que descobrir algo a mais, estarei postando.

Criando uma função anônima para calcular o fatorial de um dado número:



Criando uma função anônima para calcular o fatorial de um dado número:
obs: (este código tem um bug, calcula apenas valores >= 1)



se alguém conseguir resolver o bug, comenta ae :)

Entendendo e aplicando PEP 8 - Parte 1

Mas o que seria PEP 8?

Bom, PEP é uma sigla para Python Enhancement Proposals o que poderíamos definir como uma proposta de aprimoramento da linguagem Python como um todo, ou seja, tudo aquilo que está ligado ao Python;

• novas funcionalidades
• processos
• ambiente
• core
• e outros

O PEP se resume em um documento totalmente técnico que pretende ajudar os desenvolvedores a entenderem uma idéia proposta, criando assim uma política de especificações da linguagem Python.
Existem inúmeros PEPs, todos eles com seus devidos índices e autores que especificam a intenção do PEP.

Neste post vou falar especificamente do PEP 8, que vem a ser um guia para o estilo de layout dos códigos escritos em Python, foi proposto por Guido van Rossum e Barry Warsaw.
Para uma leitura mais detalhada você pode lê-lo em http://www.python.org/dev/peps/pep-0008/.

Todo o conteúdo é baseado na especificação original do PEP 8, mas neste post a minha intenção é criar exemplos detalhados a cada abordagem deste PEP e também explicar cada caso isoladamente, montando uma série de regras que podem ser facilmente retidas pelo leitor.
Muitos desenvolvedores dizem que as regras estabelecidas pelo PEP 8 são seguidas apenas para os códigos que estão no core do Python e módulos externos importantes. Mas não acho que seja bem assim, é muito importante que o desenvolvedor que esteja começando a escrever códigos em Python siga estas regras desde cedo.
Toda linguagem de programação respeitada tem uma padronização de layout do código, afinal essa é uma das boas práticas de programação mais importantes para um desenvolvedor, principalmente para desenvolvedores que ajudam no software livre.

"O meu código é o seu código."

O código de um desenvolvedor que ajuda a comunidade Software Livre sempre vai pertencer a milhares de outros desenvolvedores, nunca o código vai ficar retido à um programador, por isso que é muito importante que as regras se tornem um hábito.
A padronização do layout de código facilita a legiblidade, manutenabilidade e até mesmo a produtividade, porque essas regras seguem a mesma via do fluxo de documentação. Então você acaba gerando um código mais expansível aos olhos da comunidade.

1 - Code Layout

1.1 - Indentação

Sempre use 4 espaços por nível de indentação.

Dicas:

• nunca misture tabs com espaços. É bom você se adaptar com a indentação de 4 espaços, habituando-se com esse padrão você ganha produtividade e legibilidade. A indentação com 4 espaços evita várias dores de cabeça com editores de texto e ajuda no ciclo de manutenabilidade do código.

Fig 1.1.1

Fig 1.1.2


1.2 - Tamanho máximo das linhas

Sempre limite as linhas à um máximo de 79 caracteres.
Para blocos longos de texto (docstrings ou comentários), limite o tamanho para 72 caracteres.

Dicas:

• a melhor maneira de quebrar uma linha de instrução é atribuindo um par de parênteses "()" ao redor de uma expressão ou usando uma barra invertida "\" para indicar a quebra de linha.
  

• quando há uma quebra de linha em uma instrução a continuação da linha deve ser indentada com a linha mais acima.

• o melhor lugar para quebrar uma linha ao redor de um operador binário é após ele, e nunca antes dele.

• a estética de quebra de linha fica a critério do desenvolvedor, mas claro, seguindo as regras citadas acima.

Fig 1.2.1




1.3 - Linhas em Branco

Sempre separe o topo de funções e definições de classes com duas linhas em branco.
As definições de métodos dentro de uma classe são separadas por apenas uma linha em branco.

Dicas:

• linhas em brancos podem ser usadas para separar grupos de funções relacionadas.

• o uso de linhas em branco deve ser regrado para que o código não fique muito extenso, causando um cansaço e uma demora na leitura do código.
  

• as vezes para que um código não fique muito extenso a melhor maneira é reformular a modelagem do código em si para que seja possível a separação em mais de um arquivo.
  

• é sempre bom usar linhas em branco nas funções e métodos para separar seções lógicas.

1.4 - Encodificação

Para evitar problemas use sempre utf-8.


Em breve estarei postando a segunda parte do artigo.
Até mais!!!

Agradecimentos:

James Italiano - recorte das imagens

GPL de cara nova!

O projeto GNU vive um dos momentos mais importantes na sua história. A simbiose que tem com o kernel linux; o permitiu um progresso muito frutífero e fez um sistema computacional estável e livre.

Hoje muitas pessoas podem desfrutar de uma grande variedade de softwares que satisfazem as suas necessidades. Alguns o valorizam por sua estabilidade, rapidez, flexibilidade; outros porque é livre. Mas muitos se esquecem de uma outra parte muito importante que permite e defende a natureza livre de um programa: a licença.

Richard Stallman e a Free Software Foundation pensaram em um acordo satisfatório entre o programador e o usuário final para evitar que algum intermediário (ou o mesmo usuário final) se apoderasse do programa e impediria seu caráter livre. O resultado foi o nascimento da General Public License da GNU, também conhecida por muitos como "a GPL".

A GPL possui quatro liberdades fundamentais:

Liberdade 0. Executar o programa com qualquer próposito (privado, educativo, público, etc.).
Liberdade 1. Estudar e modificar o programa (para o qual é necessário poder acessar ó código fonte).
Liberdade 2. Copiar e redistribuir o programa sem nenhum impedimento.
Liberdade 3. Melhorar o programa e publicar as novas features.

Fazem 14 anos que é usada sem mudanças, a licença GNU GPL voltou ao laboratório para ser atualizada em vários sentidos. O problema principal radicava em defender aos usuários dos DRM, sistemas de gestão digital de restrições desenhados para limitar o que as pessoas podem fazer com seus ambientes informatizados.

Os "autores" e os fabricantes andam popularizando massivamente "seus direitos de uso" (DRM) ao incorporá-lo em qualquer hardware que reproduza qualquer arquivo de multimedia e assim evitar a cópia ilegal das obras. Como complemento, ignorá-los converte-se em uma ação ilegal em muitos países (a Digital Millenium Copyright Act dos EEUU é a principal impulsora do DRM).

A GPLv3 assegura que as pessoas podem remover estas limitações sem ter riscos legais. GPLv3 estabelece que não se proíbe aos DRM nem o desenvolvimento de nenhuma outra aplicação desta natureza. Simplesmente assegura a liberdade de removê-los mediante o choque com os "direitos do autor".

Um outro grande tema que é abordado, são sobre as patentes de software. A maioria de programas de computador estão cobertos por copyright, sem embargo, em alguns países, voltou a ser possível registrar idéias implementadas em software sob o sistema de patentes.

As ameaças radicam o feito de que qualquer pessoa pode estabelecer direitos exclusivos de uso sobre determinado processo ou algoritmo computacional. Ao ser exclusivo, ninguém pode usá-lo sem um consentimento ou um acordo (econômico na maioria dos casos) com o dono dos direitos. Tudo isso sem se importar com a originalidade do dono, em outras palavras, o dono da patente pode não ser o "cara" que teve a idéia, mas o ponto principal é que ele é o dono absoluto ao registrar a patente.

A única forma de assegurar a liberdade é abolindo as patentes de software onde já estão implementadas e evitando que se implementem em países onde ainda não foram legalizadas. Uma licença de software não pode solucionar este problema. Sem embargo, pode-se tratar de fazer um certo controle dos danos. GPLv3 tem um respaldo de patentes explícito para assegurar que usuários e distribuidores não sejam levados a juízo quando usarem, modificarem e resdistribuírem software livre.

Como complemento aos pontos anteriores, a internacionalização da GPL é um deles. O aumento do uso de Software Livre em todo o mundo faz-se necessário que a linguagem da licença seja adptável aos textos jurídicos que regulam o copyright de cada país. Não são poucos os que pedem traduções da licença como solução. Isto não é possível, já que cada licença traduzida e localizada a um território específico será uma licença em si e portanto incompatível com a GPL original em inglês ou com outras traduções. Isto fragmenta ao invés de unir e quebra uma das janelas mas grandes do Software Livre: sua universalidade.

Na GPLv3 se especifica uma terminologia própria que pode ser usada sem se importar a espicificiadade da legislação vigente em cada país. Isto é denominado "internacionalização".

Outras mudanças incluem uma modificação nos términos de finalização para dar oportunidades de reverter possíveis violações involuntárias, o uso e promoção de sistemas P2P e BitTorrent e a compatibilidade com outras licenças como Apache, por exemplo.

A GPLv3 representa um novo suporte fundamental no progresso que tem o software livre a cada dia. Os novos obstáculos que as empresas de software proprietário constroem com seus exércitos de artimanhas legais fizeram que a Free Software Foundation e o mesmo Stallman recorressem a participação global da comunidade. Esta nova GPL está feita à todos e deve ser conhecida por todos os usuários, sejam "linuxeros" ou "usuários de softare livre". Todos merecemos a liberdade, nada pode legitimamente impedir a liberdade das pessoas que usam um computador.

Referêcia: Revista Papirux Número 0, Ano 0 Outubro de 2008

Como escrever um bom HowTo

Howtos são sempre muito úteis. Não importa o assunto que é abordado.
Se você está tentando contribuir com um projeto Open Source ou se está atraindo tráfego para o seu blog, howtos podem deixar as coisas mais fáceis.

Escrevi esta lista de passos para servir de exemplo enquanto escrevo um howto, as pesquisas são baseadas nas definições de howto da Wikipedia e com as minhas próprias experiências.

1. Tente deixar pequeno

• Seja específico. Howtos devem ser escritos para guiar uma tarefa específica, não discuta outros tópicos, mesmo que eles estejam relacionados. Guarde para um outro tópico.
• Deixe detalhes irrelevantes para apêndices ou outros documentos de referências. Detalhes tendem a distrair os leitores.
• Divida em vários arquivos se for um post longo e para leitura online.

2. Deixe legível

• Seja informal, imagine o leitor na sua frente.
• Destaque informações importantes. Muitos leitores visualizam o documento procurando apenas um pedaço da informação.
• Sumarize e categorize. Isto não apenas ajudará o seu leitor a encontrar rapidamente o que ele estava procurando como também organizará as suas idéias enquanto estiver escrevendo.
• Use listas e seções. Isto ajuda-o a alcançar o próximo tópico. O howto inteiro pode ser uma lista se você estiver escrevendo um assunto simples como este.

3. Use recursos visuais

• Use imagens ou vídeos. Eles podem poupá-lo de muitas palavras, mas não abuse desses recursos porque há pessoas com conexões muito baixas. Contudo, howto de vídeo pode ser uma boa escolha para tarefas complexas.

4. Mantenha-o simples

• Talvez o ponto mais importante seja resumir todos os tópicos anteriores. Howtos são entendidos como algo que deixa as coisas mais claras.
• Use termos técnicos apenas quando for necessário, a não ser que seja para alcançar um público que entendem tais termos.
• Construa um glossário com os termos técnicos ou aponte-os a um wikipage que explique melhor.

Referência: How To Write a Good Howto