Archive for the ‘Desenvolvimento de Software’ Category

SVN – Subversion: Guia de sobrevivência do usuário

agosto 14, 2009

Pessoal,

Estou disponibilizando no SlideShare uma apresentação falando um pouco sobre o Subversion, o famoso SVN.

A idéia é que essa apresentação se torne, realmente um guia de sobrevivência para o usuário (não para o administrador). E utilizando o formato de apresentação, o foco é usar e abusar de exemplos. 🙂

E sendo essa a primeira versão da apresentação, sintam-se à vontade em usar os comentários para fazer críticas, sugestões e elogios. Até porque, eu não sou nenhum especialista no assunto (e estou muito longe disso…rsrs), então se alguém quiser me ajudar a melhorar a apresentação, só entrar em contato. 🙂

Abraços!

Anúncios

Minhas impressões – Quinto encontro Guru-SP – 18-07-09

julho 18, 2009

Caros colegas,

Neste sábado tive o prazer de participar do quinto encontro do Grupo de Usuários Ruby de São Paulo (Guru-SP), que aconteceu na sala de treinamentos da empresa onde trabalho (a Voice Technology :)).

Apesar de meu conhecimento da linguagem e do framework de desenvolvimento Web (Rails) ser baixa, o objetivo maior era angariar o maior número de informações, aprender e ter contato com o pessoal da comunidade. Assim poderia ter mais “idéia” do que é Ruby e porque está sendo tão falado, comentado e usado nas empresas e em projetos open source.

Nós da Voice Technology já temos algumas pessoas capacitadas em programar em Ruby, mas estamos em constante nível de aprendizado. Essa participação no encontro será importante para sanar as principais dúvidas e responder as expectativas pessoais e do pessoal da empresa que não esteve presente.

P.S.: Este post também está presente no Templário da Tecnologia.

Panorama Geral


Até o dia de ontem (17-07-09) era prevista a participação de no máximo 20 pessoas para toda a duração do evento (10h00 até ~17h00), o que já era um número excelente para uma reunião “informal”.

Para a nossa surpresa (André Pantalião, Rodrigo Ribeiro e Thiago Veiga, membros da empresa presentes) tivemos cerca de 25 pessoas participando (!). A procura foi grande e acho que o encontro respondeu as expectativas da melhor maneira possível.

“Escopo” da programação das palestras (pelo menos o pensado):

  • 10:30 (devido ao “delay” clássico de espera do pessoal) – Palestra de Ruby (e Rails) voltada para iniciantes
  • 13:00 – DataMapper
  • 14:30 – GIT
  • 16:00 – Bate-papo sobre itens de interesse / Coding Dojo

Palestras

Ruby on Rails para iniciantes – Rafael Rosa “Fu”


Rafael Rosa “Fu” tomou a iniciativa de levar o notebook a frente e passar alguns “Ruby fundamentals” para o pessoal. Primeiramente ele abriu uma “janela” para que todos falassem (momento “apresentação”) o nome, profissão, envolvimento com as linguagens de programação e porque “raios” estar presente em um sábado de manhã para ver uma reunião de Rails (rs).

Foi interessante para chegar a algumas conclusões:

  • Maioria do pessoal é oriundo da área de programação em Java, voltada para Web;
  • Muitos dos presentes (inclusive eu…rs) são iniciantes em Ruby e Rails. O objetivo era saber mais do que é, como usar e os objetivos da linguagem;
  • Já existem pessoas que trabalham só com Rails em empresas. Muitos dos presentes já fizeram curso também, em sua maioria na Caelum;
  • A comunidade Ruby e metodologias ágeis estão andando de “mãos dadas” e estão definitivamente “implantados” nas empresas que usam Rails.

Após isso foram mostrados conceitos (e prática) de como instalar e usar Ruby, tomando como exemplo o famoso modelo do “Faça seu blog em 15 minutos“. O interessante é que desde a criação de um projeto até a edição/criação de métodos html (POST, por exemplo), dentre outros poréns de um blog não é necessário escrever uma linha de código (!).

O Rails já tem muita coisa pronta, relativa a configuração de banco de dados, modelo MVC, testes e servidor de aplicação. Por isso temos a famosa “agilidade de escrita” de código e desenvolvimento.

Além disso foram discutidos termos como TDD, BDD e princípio da janela quebrada, ressaltando também o uso de ferramentas de testes com o Rails (RSpec, Remarkable e Cucumber).

Abaixo alguns links para aprendizado de Ruby e Rails:

DataMapper – Rafael Rosa “Fu”


DataMapper utiliza o design pattern para persistência de dados publicado por Martin Fowler, de mesmo nome e que também é utilizado pelo Hibernate. Foi criado pelo pessoal do Merb (Matt Aimonetti e Yehuda Katz). O conceito base é o ORM do Merb.

As vantagens do DataMapper são:

  • Não depende de estrutura de banco de dados;
  • Mais fácil de integrar com sistemas legados;
  • Migrações e múltiplos repositórios.

Rafael mostrou e explicou alguns exemplos de código, comparando classes usando DataMapper e Hibernate, exemplificando o funcionamento, mapeamento de chaves e campos usados, etc. Muitos exemplos de classes podem ser encontrados no site do DataMapper. Reinterou que Active Record (outro ORM  e manuseador de dados usado por Rails) não é DataMapper, sendo o último mais “poderoso” e modularizado.

Explicou sobre os muitos plugins existentes para DataMapper e encontrados no repositório GIT do mesmo, separados em “Resource Plugins” e “Is Plugins”, e os seus respectivos “poderes de fogo”. Complementando o assunto foram mostrados de maneira mais superficial Adapters, Integration e Utility, pois são temas mais aprofundados do DataMapper.

Nas futuras versões (0.10 e 0.11) haverão novidades:

  • Validações para objetos Ruby puros;
  • Melhorias no SEL.

Desvantagens do DataMapper:

  • Menos maduro (menor número de usuários usando e desenvolvendo DataMapper e muitos usando Active Record);
  • Não se itegra facilmente com Rails (ainda);
  • Pequena comunidade;
  • Pouca documentação (relativamente);
  • Ainda não tem Remarkable;

Como podemos participar do projeto?

  • IRC Freenode #datamapper e #dm-hacking

A palestra do Rafael foi interessante, apesar de ser bem técnica. Devido ao conhecimento de Hibernate (seja ele teórico ou prático, da maioria do pessoal) a assimilação do conteúdo passado foi melhor e mais inteligível.

Desvendando o GIT – Douglas Campos (qmx)


A palestra procurou passar uma introdução a respeito do GIT, sistema de repositórios altamente usado em projetos Ruby. Mudança de paradigma de versionamento (não só arquivos, mas conteúdo de arquivos são altamente analisados).

Na introdução mostrou-se que GIT é performático e foi baseado em um desenvolvimento de 45 dias para uma nova plataforma de versionamento para o Kernel (ao invés do BK – BitKeeper, proprietária) desenvolvida por Linus Torvalds. No sistema de repositórios CVCS há o problema do código muito centralizado. No DVCS já o contrário: não há ponto central imposto pela ferramenta, tudo é descentralizado. No GIT há mudança de paradigma, pois os commits podem ser locais e/ou não acessando o servidor.

Sobre o “core” do GIT:

  • Commits pequenos em Rails são muito usados, pois as mudanças no projeto geralmente requerem pequenas implementações de linhas de código;
  • O versionamento de conteúdo no git “impacta” no conteúdo da árvore inteira;
  • Commit: não é nada mais do que as diferenças aplicadas a árvore de código (pilha de alterações);
  • O conceito de índice é tirar um “snapshot” seletivo dos objetos da árvore;
  • Podemos melhorar o conceito de índice no/para GIT: coloca tudo o que está no indíce dentro do repositório e são indicados por um hash SHA único e definido por um diff;
  • Definição técnica de GIT: o repositório no GIT é um grafo acíclico dirigido;
  • Branches: são simples ponteiros dentro do grafo, apontando para índices.

Após isso foi feito um exemplo de aplicação com vários desenvolvedores alterando e “subindo” código para um projeto fictício em um repositório GIT de teste, simulando a realidade e com a finalidade de mostrar ao vivo os conceitos de merge, diff, commit e histórico de mudanças.

Alguns comandos foram mostrados e são importantes para uso e manutenção do repositório: git stash, git status, git tag, git reset, git rebase e outro comandos.

Você precisa pesquisar em que arquivo ficava aquele método? Use o comando: git log -S’def update’ –pickaxe-all (visualiza as “mudanças de história”. Procura métodos que foram alterados no projeto e ele mostra os logs de commit. Muito poderoso). Essa é uma dica que é muito útil e pouca gente sabe!

Na parte final, Douglas discutiu com o pessoal sobre os conceitos de Cherry pick, Cherry (commits pequenos e pontuais) e Bisect (famosa história: “Mas eu tinha consertado aquele bug…quem ‘quebrou’?”).

Para finalizar houve uma discussão sobre fluxos de trabalho em equipe, recuperação de “desastres” e boas práticas.

Sem dúvida uma palestra bastante técnica, mas bem moldada, concisa e dinâmica. O overview dado sobre GIT foi bom para os “imaturos” em Ruby e Rails e para os experientes, pois várias dúvidas foram sanadas e muitas perguntas respondidas, de ambos lados. E uma novidade: Douglas expôs a informação de uma nova comunidade que está surgindo de Rails, intitulada RailsBridge. Ela é muito completa e voltada também para fins educacionais, além de ter uma campanha para ter mulheres programando em Ruby (rs). Vale a pena dar uma olhada!

Apesar de ter sido a palestra mais técnica do encontro os parabéns ao Douglas são necessários, pois o conteúdo foi excelente!

Coding Dojo – Modelagem de uma classe usando RSpec (aplicação de TDD)


No final do dia houve um dojo para que o pessoal, de forma colaborativa, codificasse um “projetinho”. O objetivo foi modelar uma classe usando RSpec, com a finalidade de trazer a tona modelos de programação, estilos de código, implementação de patterns, etc. O foco principal era aplicar o princípio básico do TDD: escrever testes antes de codificar.

Algumas das características usadas foram:

Gems instaladas

* remakable ( from github )
* rspec-rails
* Zentest

User Story da classe Group
– Tem que um nome;
– Outras características.

User Story da classe User
– Tem que ter um nome, login, e-mail, senha;
– Tem que pertencer a um grupo;
– Tem que ter status: ativo ou inativo;
– Senha tem que ser guardada como Hash;
– Precisa de método para fazer login que:
– recebe login e senha;
– retorna false se deu errado (login inexistente, usuário inativo, senha inválida);
– retorna true se deu certo.

O feedback durante a sessão foi legal e muito interessante!

Conclusão

Na minha visão o evento foi muito interessante e produtivo, sanando muitas dúvidas minhas a respeito do Ruby. Até instalei o Ruby na minha VM! (posteriormente estarei testando alguma coisa, pois o tempo urge para mim nesses dias!). Esse evento não seria realizado sem a iniciativa de André Pantalião e o pessoal do Guru-SP, que mostraram um grande interesse em participar e interagir, trazendo para o ambiente Voice a disseminação do conhecimento, tanto para nós quanto para a comunidade Ruby e afins. Aguardem mais novidades daqui para frente!

Agradeço a todos pela leitura e até a próxima!

ConclusãoNa minha visão o evento foi muito interessante e produtivo, sanando muitas dúvidas minhas a respeito do Ruby. Até instalei o Ruby na minha VM! (posteriormente estarei testando alguma coisa, pois o tempo urge para mim nesses dias!). Esse evento não seria possível de ser realizado sem a iniciativa de André Pantalião e o pessoal do Guru-SP, que mostraram um grande interesse e participação (interação), trazendo para o ambiente Voice a disseminação do conhecimento, tanto para nós quanto para a comunidade Ruby e afins. Aguardem mais novidades daqui para frente!Agradeço a todos pela leitura e até a próxima!

Falando sobre JBoss

abril 28, 2009

Este post tem como objetivo trazer conceitos básicos sobre o Jboss. Espero que gostem ! =D

O Que é o JBoss ?

JBoss (pronuncia Djei Boss) é um servidor de aplicação J2EE de código fonte aberto, ou seja, ele já possui métodos implementados para facilitar a criação do seu sistema.

Mas, o que é um servidor de aplicação?

Servidores de aplicação permitem o desenvolvimento de aplicações distribuídas multi-camadas. Ele age como a interface entre os clientes e as bases de dados e os sistemas de informação corporativos (ERPs, sistemas legado, etc.), ou seja, disponibiliza um ambiente para a instalação e execução de certas aplicações.

E o JavaEE?

Em 1999 a Sun começou a distribuir 3 edições de sua especificação para Java:

    J2SE (Java 2 Standard Edition): APIs básicas, e para o desenvolvimento de aplicações em desktops.

    J2ME (Java 2 Micro Edition): APIs para o desenvolvimento de aplicações embedded, em plataformas como PDAs e telefones celulares.

    O objetivo do JavaEE é especificar uma plataforma com um modelo de componentes e a infra-estrutura básica (segurança, transações, acesso a bases de dados, etc.) para o desenvolvimento de aplicações corporativas. O padrão JavaEE da Sun é composto por:

    O JavaEE Compatibility Test Suíte: Um conjunto de testes de compatibilidade para garantir que um produto JavaEE é compatível com o padrão da plataforma JavaEE.

    JavaEE (Java 2 Enterprise Edition): APIs para o desenvolvimento de aplicações corporativas.

    A implementação de referência JavaEE: Uma implementação de referênciapara demonstrar as capacidades do JavaEE e para prover uma definição operacional da plataforma JavaEE.

    O modelo de programação de aplicações JavaEE: Um modelo de programação padronizado para o desenvolvimento de aplicações multi-camadas.

    O JBoss é uma implementação – clean-room – das especificações JavaEE da Sun, isto é, ele não utiliza nenhuma biblioteca vinda da Sun ou de outros fornecedores.

Como surgiu o Jboss ?

O desenvolvimento do JBoss começou em março de 1999. Nascido como um simples container EJB (Enterprise JavaBeans) e, ao longo dos anos, evoluiu para ser um servidor de aplicações Java completo, que hoje está bastante maduro. Ele é desenvolvido por uma comunidade open source e está se tornando um sério concorrente aos servidores de aplicação comercial. ( Como, o servidor WebSphere Application Server da IBM e o WebLogic Server da BEA Systems ).

Os desenvolvedores responsáveis estão agora empregados por uma empresa de serviços chamada JBoss_Inc.. fundada por Marc Fleury, o criador da primeira versão do JBoss. O projeto é custeado por uma rede mundial de colaboradores. Em Abril de 2006 foi anunciada sua aquisição pela Red Hat.

Quais versões existentes?

Existem muitas versões com update´s de bug´s , até chegarmos nas versões em que chamamos de GA ( General Availability ), como podemos ver abaixo:

JBoss AS 4.0 é um servidor de aplicações Java EE 1/4, com embutidos Apache Tomcat 5.5. Qualquer Máquina Virtual Java entre as versões 1.4 e 1.5 são suportados. JBoss pode ser executado em inúmeros sistemas operacionais, incluindo muitas plataformas POSIX (como o Linux, FreeBSD e Mac OS X), Microsoft Windows e outros, enquanto um adequado JVM está presente.

JBoss AS 4.2 é também um servidor de aplicações Java EE 1/4, mas Enterprise JavaBeans 3.0 é utilizado por omissão. Ele requer o Java Development Kit versão 5. Tomcat 6 é empacotado com ele.

JBoss AS 5.0, a versão atual, é um servidor de aplicações Java EE 1/5. Tinha-se em desenvolvimento para mais de 3  anos e é construído no topo de um novo JBoss microcontainer.

Espero ter atendido as expectativas de vocês caros leitores.

O que é Heartbeat?

dezembro 1, 2008

“Pulsação” (google translate)

“Uma música da Madonna” (um fã da Madonna)

“[…] um daemon responsável por monitorar o status dos servidores do cluster e permitir que o segundo servidor assuma as funções do primeiro em caso de pane.” (blog do GDH)

Adivinha de qual Heartbeat iremos falar? do que tem a resposta mais complicada é claro.

Primeiro vamos deixar claro duas palavras que pode ter deixado você com aquela cara de interrogação:

Daemon: acrônimo de Disk And Execution Monitor (Monitor de Execução e de Disco), um software que roda em background, ou seja, o usuário não o controla diretamente. Esse tipo de aplicação, geralmente, é usada para executar tarefas que se comunicam diretamente com o sistema operacional ou com os hardwares, para o usuário é algo transparente, muitas vezes o que importa para ele são somente os resultados.

Cluster: é um conjunto de computadores que estão ligados em rede e comunicam-se através do sistema, trabalhando como se fossem uma única máquina de grande porte. Podemos fazer uma analogia com um time de futebol, são vários computadores que trabalham juntos com o mesmo objetivo, caso algum sofra alguma falha ele poderá ser substituído.

Acredito que agora ficou um pouco menos confuso a definição de heartbeat. Mas se caso ainda ficou alguma dúvida, tentarei fazer uma explicação utilizando uma analogia:

O Heartbeat está para os servidores, assim como, o monitor cardíaco está para nós seres humanos. Mas além de monitorar os servidores o Heartbeat é capaz de substituir um servidor por outro, caso o primeiro falhe, para manter o funcionamento do sistema.

Funcionamento

O funcionamento do Heartbeat ocorre da seguinte maneira: Um servidor redundante verifica, em tempo em tempo, por meio da rede o com o uso de um cabo serial, a disponibilidade do servidor em produção, enviando-lhe uma mensagem e aguardando uma resposta. Essa checagem é feita entre as duas instâncias do Heartbeat instaladas nos dois servidores. Se por algum motivo o servidor em produção não responder, ele será considerado indisponível, e então o Heartbeat do servidor redundante automaticamente providencia a configuração e inicilialização dos serviços locais, além de outros recursos, como o endereço IP, partições de disco, etc.

Por hoje é só pessoal, qualquer dúvida sintam-se à vontade para colocarem nos comentários. 🙂

Fonte:

http://ha-mc.org/?q=node/15

http://www.gdhpress.com.br/blog/clusters-de-alta-disponibilidade/

Virus Antigos

novembro 11, 2008

Arquiteto de software

novembro 6, 2008

O Fernando Fontes foi para outros ares e não fez o post dele.

Agora ele mandou um link para um post bem legal (Mas ele ainda deve um post, hehe):

http://barkadodino.blogspot.com/2008/10/arquiteto-voc-constri-casas-prdios.html

Neste post ele lista algumas características importantes não só para um arquiteto, mas para um bom profissional da área de informática.

Falando ainda de arquiteto de software, tem um outro post bem legal: http://blog.fragmental.com.br/2006/02/19/o-que-e-um-arquiteto/

Até mais,

André

Renovar é preciso

outubro 13, 2008

Durante as décadas de 1950 e 1960, as indústrias siderúrgicas dos Estados Unidos eram criticadas pela falta de investimentos em suas instalações físicas. A administração dessas indústrias tomava decisões contrárias a se fazer os investimentos de capital necessários para que elas pudessem se manter competitivas em seus principais negócios.

Na mesma época pessoas diziam “Se eles não estão dispostos a investir em seus próprios negócios merecem perder participação no mercado”. Essas palavras podem voltar para nos assombrar.

Ainda hoje há milhares de aplicações críticas que se encontram em dramática necessidade de renovação, como por exemplo, softwares escritos a mais de 20 anos que já passaram por 40 gerações de mudanças e que agora são virtualmente impossíveis de ter manutenção. E que em muitas vezes a manutenção só pode ser feita pelo desenvolvedor do software que já deve está aposentado ou nos piores dos casos a sete palmos do chão.

Bem, o meu intuito não é ser um sonhador inocente e dizer que as aplicações DEVEM ser mudadas e atualizadas, afinal muitas das aplicações feitas em COBOL, funcionam muito bem e o risco de uma migração para outra linguagem torna inviável tal migração. O que gostaria de passar aos caros leitores é que renovação é algo extremamente necessário na nossa área, TI num todo, o surgimento de novas tecnologias conseguem fazer brotar novas necessidades nos consumidores, exemplo disso, o iPod que se fosse mostrado para o seu pai há 20 anos atrás ele provavelmente diria “para que vou precisar disso se tenho a minha TV de 32 polegadas!?”. Hoje o iPod é um dos produtos mais vendidos e populares no meio do público jovem, mesmo que muitos ainda o usem, na maioria das vezes, como um tocador de música, por causa do medo de ser assaltado.

A renovação é necessária tanto para uma pequena empresa, quanto para uma grande empresa. E se a sua empresa não costuma ter essa preocupação, é melhor ele começar a se preocupar, afinal você acha que o Google oferece um ambiente descontraído e ainda 20% do tempo de trabalho para os seus profissionais se dedicarem a projetos próprios, porque eles são bonzinhos? Eles sabem que a renovação, assim como a inovação, não é algo que depende apenas do alto escalão da empresa, mas também dos demais funcionários e ela só poderá se manifestar quando levantarmos a nossa cabeça, do teclado, e começarmos a pensar.

Coloco abaixo, um trecho extraído do livro de Engenharia de Software do Pressman, sendo ele na verdade uma citação do texto de Feigenbaum e Mccormick no livro The Fifth Generation, que deixa no final uma pergunta, cuja resposta podemos encontrar em qualquer manchete de jornal nos dias de hoje:

Conhecimento é poder, e o computador é um amplificador desse poder… A indústria americana de computadores tem sido inovadora, vital, bem-sucedida, Ela é, de certa forma, a indústria ideal. Ela cria valor ao transformar o poder cerebral de trabalhadores que detêm conhecimentos, com pouco consumo de energia e de matérias-primas. Hoje [1983], dominamos as idéias e os mercados mundiais nesta que é a mais importante de todas as tecnologias modernas. Mas o que acontecerá amanhã?

Para encerrar vou deixar uma frase baseada na seguinte frase popular: “Obter o sucesso é fácil o difícil e se mantê-lo“. Frase que pode se adaptada da seguinte maneira:

Inovar não é o mais difícil, o difícil é renovar.

Fonte:

Pressman R., Engenharia de Software (terceira edição), São Paulo, Pearson Makron Books, 2006. São Paulo.

Projeto Googol – Vamos entrar nessa???

outubro 7, 2008

Pode me chamar de baba-ovo do pessoal do Google, mas o projeto é bacana para caramba.

Simplesmente criar um projeto para a contribuição de idéias que sejam capazes de mudar o mundo e atingir o maior número de pessoas possíveis por si só é bom demais.

Não é um mero concurso e a idéia não é ter um vencedor único e ganhador da bolada, mas sim do mundo se beneficiar de uma inovação. Meio corrente do bem para os mais céticos.

O importante para eles é a IDÉIA. Não que a execução não seja importante é preciso ser pensada sim e exposta nessa idéia. Com a escolha os caras irão fazer RFPs para ver qual empresa consegue efetivar essa idéia logo não quer dizer que a grana vai para quem deu a idéia. Muitos vão dizer que não é válido,pois o que vai ganhar com isso??? Pensar, organizar idéias, INOVAR, aprender a fazer isso de forma racional. Além de saber que ajudou a melhorar o mundo e porque não se beneficiar disso.

Isso meus caros se chama OPEN INOVATION. Ter a idéia e guardar para si é ignorar o mundo.

E se mais pessoas toparem podemos discutir na Voice, no Futebol ou mesmo em uma mesa de bar hahaha

Daniel Bronzeri

Qual a motivação do desenvolvimento de Software Livre?

setembro 25, 2008

Caro desenvolvedor ou qualquer pessoa que se interesse por tecnologia. Hoje em dia, consagrado o amplo sucesso dos softwares livres, com a maturidade destes, nos sentimos confortáveis em utilizá-los em nossas tarefas. Softwares como o próprio Linux, Apache, Asterisk, Openser são exemplos de maturidade, estabilidade, escalabilidade e Customização baseando-se neste tipo de desenvolvimento de Software.

Bem, é bom lembrar que Software Livre não é “Cerveja Grátis” mas sim, Softwares que têm seu código fonte aberto e com isso qualquer pessoa pode adaptá-lo às suas necessidades, o tornando melhor. Por isso, não há um conjunto de programadores em uma determinada empresa pagos para desenvolvê-los, mas sim programadores espalhados por todo o Globo. Deste modo:  NÃO há RENDA à estes programadores… eu lhe pergunto: Você, que utiliza Software Livre, já parou pra pensar o que motiva esses caras (programadores) a desenvolver esses softwares para nós utilizarmos? O que leva essas almas a gastarem seu tempo, seus conhecimentos, suas habilidades desenvolvendo estes softwares??

Simplesmente é algo que não têm preço: o Conhecimento.
É o que diz um estudo denominado “Toward an Understanding of the Motivation of Open Source Software Developers

Para entendermos o estudo, precisamos dividir o tema em dois Posts. O primeiro vai desmistificar a estrutura por dentro do desenvolvimento e o segundo irá tratar o estudo da motivação dessas pessoas.

Comunidades Open Source.

A peça principal para o sucesso de um Desenvolvimento de Software Livre (projeto) é a comunidade envolvida.
O que é esta “Comunidade”?
São Grupo de pessoas que pelos seus interesses em comum se tornam informalmente “parceiros” em um assunto/projeto/busca/ideal específico. São voluntários cuja a motivação os levam a participar e contribuir com o projeto. A comunidade provê ao projeto uma plataforma de compartilhamento de conhecimento com os membros, dessa forma disseminando o conhecimento.

Diferente do desenvolvimento fechado, que há um chefe, que se encarrega de alocar uma equipe designada à programar, onde já está definido quem serão os usuários do sistema em um cenário em que há uma separação clara: usuários e desenvolvedores. No desenvolvimento fechado um usuário não se tornará um desenvolvedor, a menos que quando o chefe achar que ele mereça, ele suba de cargo e venha a tornar-se um programador. No desenvolvimento Open Source não há uma distinção clara de quem é usuário e quem é desenvolvedor, qualquer membro da comunidade pode se tornar um programador em potencial, bastando este ter o conhecimento para tal, sendo que, como membro da comunidade, ele buscou e busca conhecimento e contribua para o software. Esta “transição” de, digamos, “status”, os autores do estudo denominam de “role transformation”.

Dentro da comunidade temos uma espécie de Distinção Social. No começo pessoas envolvidas criam uma comunidade envolta de um projeto particular motivados por um interesse compartilhado em utilizar e/ou desenvolver o Software. Membros da comunidade assumem por si mesmos as “roles” de acordo com seus interesses pessoais no projeto. Estudando quatro projetos Open Source, os autores do estudo puderam classificar oito (8) “roles”:

Project Leader (Lider de Projeto): A pessoa que iniciou o projeto. O Project Leader é o responsável pela visão e os rumos que o projeto seguirá. (Mark Spencer é o criador e assim o Project Leader do Asterisk)

Core Member: São responsáveis por guiar e coordenar o desenvolvimento do projeto. São aquelas pessoas que estão envolvidas com um projeto durante muito, muito tempo, fizeram e fazem contribuições significantes para o desenvolvimento e a evolução do Software.

Active Developer: São os que regularmente contribuem com novas features e bug fixes para o software. São as maiores forças do desenvolvimento do Software Livre.

Peripheral Developer: São pessoas que ocasionalmente contribuem com novas funcionalidades ou features para o sistema. Sua contribuição é irregular e o período de envolvimento é curto e esporádico.

Bug Fixer: São pessoas que corrigem os bugs encontrados por elas mesmas ou reportados por outros membros. Bug Fixer precisam ler e entender algo do código do software.

Bug Reporter: Descobrem e reportam bugs. (Hmm.. Quando o seu Firefox bugou e abriu aquela tela de Bug Report, você se tornou um Bug Reporter? Ou cancelou?). Ele não corrige o bug e não possui conhecimento do código fonte. São como se fossem a área de Quality Assurance do projeto. (Legal não?!) Por isso, para um Software com muita qualidade e com poucos bugs, é essencial vários membros que contribuam como Bug Reporter (Lembre-se disso!).

Reader: São usuários ativos do Software. Não somente usam o Software, mas tentam entender como o software funciona, lendo o código, documentação… Dado a alta qualidade dos Softwares Livres, alguns Readers, para aprender a programar, lêem o código do software ou usam-no como referência à desenvolvimento de softwares similares.

Passive User: Apenas ultilizam o software para alguma determinada necessidade. (A maioria de nós) São atraídos a utilizá-los pela alta qualidade e o potencial de ser alterado quando surgir a necessidade.

Essas oito Roles não são REGRAS em todas as comunidades e a porcentagem de membros em cada uma varia.

Estrutura.
Apesar de não existir uma distinção hierárquica, a estrutura da comunidade não é completamente plana.
Dependendo de qual role o membro participa, mais ou menos influência este terá no Software e na Comunidade.
Considere as camadas da imagem acima como os “roles”. Quanto mais perto do centro, mais influência este terá na comunidade e no Software. Em outras palavras, a atividade do Project Leader influenciará mais membros do que o Core Member, no qual terá mais influencia do que o Active Developer e por aí vai.
Como exemplo, citamos a responsabilidade do RoadMap que é uma atividade do Project Leader que impacta toda a comunidade e, partindo para outra “camada”, uma alteração em um determinado ponto do código pelo Bug Fixer não necessariamente impactará para todos, mas para aqueles que utiliza a feature que for corrigida. Não que uma role seja “mais importante” que a outra. As camadas externas têm sua importância, tanto social dentro da comunidade, como psicológica, atraindo e motivando mais pessoas, podendo esses serem potencialmente membros mais ativos e conseqüentemente, aprofundando seus conhecimentos e contribuindo mais ativamente, alcançando outros roles. Como analogia, imaginemos as camadas do centro como atores de uma peça de teatro, e o restante como a platéia… o que são os atores sem aplausos?? Não serão motivados? O grau de influência dentro da comunidade pode ser considerado mais uma motivação? Gostaria que expressassem suas opiniões para discutirmos, e com o segundo post teremos a visão do estudo sobre a questão.

Um abraço e até lá.

Adelson Junior