Archive for the ‘Open Source’ Category

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!

Anúncios

FISL 10 – Visão geral do terceiro dia – 25/06/2009 – por Antonio

junho 30, 2009

Bom o terceiro dia começou bem conturbado, pois a organização do FISL havia restringido algumas áreas do evento e cancelado algumas palestras para poder organizar a recepção do presidente Lula que confirmou a sua presença no evento, por conta destas mudanças 3 palestras (Jingle Cookbook, Empreendedor com Software Livre, e Performance Tuning the OpenJDK Garbage Collectors) que eu havia marcado para assistir foram transferidas para o dia 27/06/2009, mas espero que seja possível assistir as 3 amanhã.

Palestra Novidades do Open JDK 6 e 7: O futuro da tecnologia por Bruno Souza da Sun Microsystems

A palestra visava explicar o porque a Sun resolveu tornar o JDK Opensource, e qual o atual status do projeto OpenJDK, o Bruno Souza é um palestrante bem eloquente que fala muito bem, abaixo seguem os principais pontos da palestra:
Segundo Bruno a Sun demorou para tornar o OpenJDK um projeto Opensource com medo de perder a compatibilidade da máquina virtual em determinados S.O., o OpenJDK é licenciado sob GPL v2 mas com uma exceção chamada de “Classpath Exception” e é exatamente esta exceção que permite desenvolver aplicações proprietárias em Java e embarcar o JDK dentro da aplicação sem infringir a licença GPL, um dos principais fatores para a abertura do código fonte foi angariar mais colaboradores, pois a comunidade Open source chegou a criar 20 máquinas Virtuais Java só por que o Java não era Open Source, então a Sun queria que estas comunidades que são formadas por programadores excepcionais passassem a contribuir com o OpenJDK pois ao invés de fazer a mesma VM Open Source a idéia é canalizar os recursos para fazer a VM já existente melhor.

O processo de abertura do código fonte não foi fácil pois várias partes do fonte não eram de propriedade intelectual da Sun, então a Sun teve que comprar o fonte de muitas empresas para poder abrir o mesmo, e mesmo assim teve 4% do fonte da VM que era de uma empresa que não cedeu, e nem vendeu, então a Sun teve que reescrever 4% da VM para poder abrir a mesma.

O OpenJDK6 nasceu do Sun JDK7 b20 (como pode ser visto a figura abaixo):

IMG_3043

Bruno deixou muito claro que o processo de definição das futuras implementações do Java não mudou, continua sendo o JCP que determina, a única coisa que mudou é que agora não são mais só engenheiros da Sun que implementam, existem comitters da comunidade. As empresas que mais colaboram com o Java atualmente são: Sun, Red Hat, Google, e AMD, atualmente a comunidade OpenJDK conta com 165 comitters, sendo que 38 deles são da comunidade, o número pode parecer baixo mas contando que tem apenas 1 ano que o JDK foi aberto e que o mesmo conta com 6.500.000 linhas de código 23% de comitters já ser da comunidade é um número bem significativo.

As fotos de quase todos os slides da apresentação do Bruno podem ser vistas no seguinte link.

Palestra Integração continua com Hudson – Configuração, Extensão e Diversão! por Eron da própria comunidade Hudson

Esta palestra eu entrei um pouco atrasado, mas a mesma foi bem interessante pois deu uma visão geral sobre o Hudson, oque e como ele pode fazer, o Eron deu alguns números da comunidade Hudson, a mesma conta atualmente com mais de 50 plugins, e uma pesquisa feitas com desenvolvedores Java levantou-se 3 soluções de integração continua: (Atlassian Bamboo, Cruise Control, e Hudson) a pesquisa era para saber qual destes softwares os desenvolvedores estavam utilizando, e o Hudson foi avaliado com praticamente o dobro de usuários que o Cruise Control que foi o segundo colocado.
IMG_3088

Outro ponto que foi bem abordado na palestra foi sobre Build Distribuído, o Hudson é capaz de trabalhar em um modelo de um Master e vários Slaves, neste modelo o Master é responsável por delegar as tarefas para os múltiplos slaves, eles acreditam que o Hudson Master seja capaz de gerenciar até 100 slaves, eles já tem cases com 45 slaves, para a instalação de slaves em massa o Hudson conta com o plugin PXE que permite você instalar os slaves através de boot remoto, sendo que o Hudson master com o PXE Plugin que provem esta facilidade na rede.
IMG_3098

Bruno Souza que estava fazendo tradução simultânea desta palestra fez questão de ressaltar a importância da integração continua, apresentando um case onde uma amiga dele utiliza um plugin do Hudson para criar uma competição saudável dentro da equipe de desenvolvimento, a idéia é que a cada comit feito que não quebrou nada o programador ganha 1 ponto, e a cada commit feito que quebrou algo o programador perde 1 ponto, ao final do mês é computado os pontos, e quem tiver menos ponto paga um almoço para quem tem mais pontos, e o interessante desta míni competição é que é um plugin do Hudson que faz todas esta contabilização de pontos.

Palestra Criando e sustentando uma empresa livre por Paulino Michelazzo proprietário da Fabricalivre

Esta palestra com certeza foi uma das melhores que já ví até então, pois o Paulino é um palestrante muito didático, brincalhão, e tem uma experiencia muito grande neste mundo de software livre.

Ele começou apresentando as diferenças entre uma empresa tradicional e uma empresa livre, onde fez questão de mostrar que uma empresa livre também tem organograma, paga impostos, tem departamentos, e acima de tudo quem que ganhar dinheiro para sobreviver, mas as diferenças entre uma empresa livre e uma empresa tradicional logo começaram a aparecer, primeiro ponto de diferença segundo ele é o modelo 1 manda todos obedecem que existe nas empresas tradicionais não funciona nas empresas livres, pois por definição uma empresa livre necessita ser colaborativa, então o modelo 1 manda todos obedecem não fuciona, outra diferença que Paulino ressaltou foi no processo de seleção, normalmente uma empresa tradicional procura profissionais formados, com várias certificações, etc. já uma empresa livre normalmente procura pessoas que tenham vontade de crescer e agreguem diversidade a o ecossistema, pois certificação de diploma não são atestados de competência, e uma empresa livre quer competencia, pois se baseia muito na meritocracia assim como as comunidades, outra diferença grande é relacionada as formalidades normalmente uma empresa tradicional existem muitas formalidades horários, trajes, etc. já uma empresa livre normalmente a única coisa formal é o compromisso com o objetivo definido, o resto fica a critério de cada um.

Outra parte da palestra foi focada em mostrar como uma empresa livre pode ganhar dinheiro, segundo Paulino o momento nunca foi tão propicio para empresas livres, pois ninguém mais torce o nariz ao falar de software livre, por mais que um CIO nunca tenha utilizado um software livre, ele sabe o que é, que funciona, e que acima de tudo representa normalmente uma redução de custo significativa, aproveitando o gancho da redução de custo o segundo motivo para o momento propicio é a crise, pois todas as empresas em momentos de crise precisam otimizar seus recursos e isto implica em redução de custo. Paulino deu um exemplo de uma empresa livre criar um produto de software baseado em software livre e vender o mesmo a única restrição para isto é que o código fonte do software deve ser distribuído juntamente com o produto, mas este mesmo produto poderia também ser vendido no modelo SaaS como serviço, em nenhum destes dois modelos a empresa livre estaria infringindo uma licença, istó é totalmente normal no mundo livre.

Mas como tudo na vida o difícil está não em fazer o software mas sim em como chegar até o cliente, e ser conhecido, neste ponto Paulino ressaltou muito a importância de a empresa ser especialista em algo, não dá para abraçar o mundo, então você tem que focar onde você é diferenciado, e para se tornar conhecido normalmente é necessário muito trabalho junto a comunidade pois primeiro você se torna referencia na comunidade e depois conhecido no mundo externo. O mais difícil é emplacar um primeiro case de sucesso depois de ter um cliente de referencia as coisas ficam um pouco mais fáceis pois se o serviço foi bem feito este cliente será seu cartão de visita para os demais.

O governo brasileiro não ajuda em nada as empresas principalmente as startups, pois praticamente tudo neste país exige que sua empresa tenha 1 ano de vida até os financiamentos de bancos públicos.

Paulino deu uma aula de empreendedorismo, ele trabalha com desenvolvimento web a mais de 15 anos, sua empresa conta com clientes como USP, FGV, MBA FGV, IBMEC, dentre outros, no ano passado teve um crescimento de 1000%, ele é uma pessoa muito carismática, já trabalhou como programador no Timor Leste por 1 ano e meio, já viajou por mais de 20 países dando palestras sobre software livre.

Tenho o áudio da palestra full, quem estiver interessado em escutar posta um comentário que envio o arquivo o arquivo por email.

Link para apresentação:
* Apresentação criando e sustentando uma empresa livre.

Por fim pretendo fazer o resumo dos outros dias do FISL10 logo mais.

Minhas impressões – OpenTDC 2009 – 17-05-09

junho 15, 2009

Amigos e leitores,

Vou escrever por meio deste post as minhas impressões do OpenTDC 2009, evento ocorrido no dia 17-05-09 na Universidade Anhembi Morumbi, local que está virando ponto de referência para os eventos organizados pela Globalcode. O evento foi voltado para desenvolvedores e entusiastas do Open Source e das tecnologias Java.

NOTA: Desculpem-me mais uma vez pela demora de publicação das informações (quase um mês…rs. E o mesmo se aplicará para a publicação das impressões do evento “Java@TVDigital“).

NOTA 2: Também postado no blog Templário da Tecnologia.

Panorma Geral

OpenTDC 2009

Presenciei o OpenTDC desse ano juntamente com o colega de empresa Joemir Luchetta, que também esteve no evento do ano passado. É importante ressaltar que o evento foi gratuito (como o evento Java@TV Digital ), com sorteio de muitos brindes e coffee-break. A presença de palestrantes que eu já havia visto apresentar trabalhos me deixou seguro de que o evento seria em bom nível. E não foi diferente: palestras claras, algumas com conteúdo bem técnico, outras não, e interação dos palestrantes com o público fizeram do evento um sucesso. Abaixo irei passar os pontos mais importantes dos temas abordados nas palestras. Espero que gostem.

Palestras

Abertura: Java, Open Source e a Comunidade – Yara Senger e Bruno Souza

Abertura: Java, Open Source e a Comunidade - Yara Senger e Bruno Souza

Como de praxe nos eventos organizados pela Globalcode, Yara Senger fez a vez na abertura do evento, expondo os dados relacionados a comunidade Java ( JUG’s, SOUJava, divulgação e participação em eventos e número de profissionais ). Citou também os novos canais da Globalcode, Open4Education e do evento no twitter, por onde irão circular depoimentos e promoções relâmpago relacionadas a cursos da instituição, além de anúncios de novos eventos.

Após isso adentrou ao palco Bruno Souza, o “Java Man“, trazendo uma visão do que é o Open Source, baseada em sua larga experiência com o “ecossistema” Java. A frase base de sua apresentação foi: “Open Source é a forma natural de desenvolver software em um ambiente de rede”. A “rede” no caso pode ter contatos, membros de comunidade, projetos Open Source, networking, entusiastas e etc. É desenvolvendo software em rede que se aprende e evolui-se.

Ele fez um paralelo entre o Java e o Open Source com um fotógrafo: “Como se tornar um excelente fotógrafo? O que isso tem a ver com Java”. Vendo fotos de outras fontes e tirando muitas fotos é provável que se vire um grande fotógrafo. O mesmo acontece no Java: é preciso ver muito código de outras fontes e desenvolver muito código próprio. No mundo são apenas 1/4 de 1% da população que entende software. Para ser um bom desenvolvedor, fotógrafo ou outra coisa é preciso muito estudo e dedicação. De acordo com Bruno são cerca de 10000 horas ( cerca de 8 horas por dia, todos os dias, durante 3 anos e meio! ) para formar um bom profissional. É por meio do Open Source e da relação com o usuário, que é quem mais conhece o software, que o desenvolvedor pode inovar e evoluir. O software é arte e engenharia, e não fabricado, manufaturado, ou aprendido por SW privado.

Finalizando, Bruno deixou uma dica para as pessoas que irão participar do FISL10: ocorrerá no dia 23 de junho, um dia antes do evento oficial, o Javali FISL, organizado pelo SOUJava e que irá apresentar as palestras e o conteúdo presente no JAVA ONE ( 2 a 5 de Junho ), maior evento relacionando a Java no mundo. Deixo os meus parabéns ao trabalho feito pela Yara e pelo Bruno, “universalizando” o Open Source e unindo a comunidade Java e entusiastas, cada vez mais presentes nos eventos.

Robótica Open Source – Vinícius Senger & Paulo Carlos dos Santos

Robótica Open Source - Vinícius Senger & Paulo Carlos dos Santos

Essa era uma das palestras que me interessava, pois gosto bastante de hardware (já tinha ouvido falar de Arduino pelas minhas leituras da Revista INFO; em Fevereiro foi a primeira vez que ouvi falar). No caso, a palestra se deu em ritmo de “bate-papo” (diálogo), onde o Vinicius fez o papel do interessado (aluno) e o Paulo de facilitador da informação (professor). Paulo aliás que já foi aluno e professor do CEFET-SP, lugar onde fiz minha graduação (!).

O Arduino foi apresentado como “Hardware Open Source” ligado a “Physical Computing“, ou seja, trabalhando-se com o Arduino podemos introduzir, aplicar e aperfeiçoar conceitos de eletrônica (hardware, físico) e programação (seja do microcontrolador ou de uma linguagem específica aplicada).

O Arduino trabalha em cima de progração C (para gerenciamento de bibliotecas, I/O de informações sensorias, etc.) e é auxiado pelo Processing (linguagem de programação baseada em Java com IDE, para criar ambientes gráficos e facilitar a integração com projetos eletrônicos).

Assim, fazemos a programação da placa ( via C, com uso de USB, porta serial, WiFi, ethernet…) e visualizamos o resultado por meio de um conjunto de leds, pinos de saída ligados a motores ou sensores (pressão, ultrasom, etc.), auxiliados por interface gráfica (Processing). Portanto podem ser feitos os mais diversos tipos de projetos (sensoriamento de presença, controle de motor, automação residencial, telas touchscreen…), ficando a cargo do projetista a abrangência. “Arduino na mão e uma idéia na cabeça!”.

No Brasil já existe venda de kits do Arduino (saem por volta de 50 a 100 reais os kits mais básicos), sensores (por volta de 50 reais) e “shields” (placas de extensão – breadboards, que podem dar suporte a leitura de cartões SD, rede ethernet…). Geralmente são achados no MercadoLivre. Outros projetos realcionados a Arduino estão sendo criados, como o Arduino Nano, Arduino Severino e Paperduino.

Paulo ao decorrer da apresentação foi mostrando exemplos práticos, apresentados via vídeo no telão, mostrando a aplicabilidade de projetos usando o Arduino, como robôs, acelerômetros, sensores de presença, automação residencial com protocolo X10, entre outros.

Você me pergunta: “Ué, porque todo esse lobby de hardware em um evento de programação?”. Eu particularmente gostei e torço para que mais iniciativas sejam feitas (rs). Mas, o Arduino foi apresentado porque ambos os palestrantes iniciaram um curso intitulado “Academia do Programador” na Globalcode. Usarão o Arduino como instrumento de aprendizado na programação (uso de if, else…) , mas pretendem também criar mais cursos, incentivar a criação de projetos e aumentar a comunidade Arduino. No final das contas foi uma boa iniciativa, pela introdução do tema “desconhecido e voltado para hardware” para os presentes no evento.

Arquiteturas com JSF, JBoss Seam e Spring – Vinicius Senger e Alberto “Spock” Lemos

Arquiteturas com JSF, JBoss Seam e Spring - Vinicius Senger e Alberto "Spock" Lemos

Vinicius Senger e Spock fizeram um teste do que seria apresentado por eles no JavaOne 2009, sendo assim não tinha como não ser bastante técnico o conteúdo apresentado, fora o “show de siglas”. A mesma palestra apresentada no OpenTDC foi apresentada no JavaOne, portanto vemos que o conteúdo dos eventos só vem crescendo.

A idéia principal era mostrar as muitas opções que a plataforma Java EE apresenta para elaboração de projetos, e como montar opções de solução, seja com Struts, Shale, JSF, Wicket, EJB, Spring, Seam, entre outras. Para as empresas há muitos pontos importantes a serem levados em conta, geralmente  os “+ades” (escalabilidade, disponibilidade, manutenabilidade, etc.). Se a empresa busca um projeto de cunho experimental, a arquitetura assim pode também ser; se o projeto é corporativo a arquitetura deve ser conservadora. Frameworks devem ser acoplados a um projeto com inteligência, pois “o simples é bonito e fica bom com Java EE 5”, de acordo com Vinicius.

Uma coisa importante a ser pensada é que o preço de uma arquitetura não deve ser medido apenas com o trabalho do DEV, mas também com equipes de infra, manutenção, gerenciamento, QA e aprendizado. Os principais desafios para se criar arquiteturas corporativas são:

  • Fazer Java EE componentizado, visando reuso. Isso não é fácil;
  • Ter especificação “perfeita” é sonho. Ferramentas não (em termos de uso e aplicação);
  • Usar “+AR’s” é definitivamente difícil (JAR‘s, WAR‘s, EJB-JAR‘s, EAR‘s, etc.). Procure dosar;
  • Mudanças durante o projeto, mesmo que pequenas, aumentam o custo.

O Java EE hoje está OK em muitos pontos (EJB 3.0, JSF, JMS), mas em outros não (questões de modularidade e alguns frameworks). Partindo desse princípio tivemos o nascimento de dois frameworks, Spring e JBoss Seam. O Spring nasceu como alternativa ao Java EE, e o Seam nasceu como modelo de integração dos próprios componentes Java EE. O Seam tem foco em Web 2.0 e promove alguma integração com framework; o Spring tem foco em integrar com outros frameworks e algum com Web 2.0. O antagonismo continua quando falamos de uso em servidores: muitas empresas rodam Spring em diferentes servidores. Poucas empresas rodam Seam em servidores diferentes de JBoss.

Após esse panorama bem abrangente e técnico Spock começou a abordar as soluções envolvendo Java EE, componentes e frameworks, sendo o centro da apresentação. Foram 5 modelos apresentados, com suas vantagens e desvantagens:

  • Java EE básico;
  • Java EE + EJB;
  • Spring;
  • Seam;
  • Seam + Spring.

Como a palestra era prevista para 50 minutos (tempo oficial que eles teriam no JavaOne), e eles só tinham 45 minutos disponíveis (fora 10 a 15 minutos de atrasos de palestras anteriores) fora o horário de almoço atrasado, ficou um pouco “corrido” o conteúdo apresentado nos tópicos de soluções e alguns pontos foram omitidos. Gostaria de especificar melhor os itens acima, mas o tempo e a abrangência não possibilitou. A apresentação não foi ainda disponibilizada no site da Globalcode, nem no site do JavaOne. Quando estiver disponível atualizo este post com a informação.

Para finalizar, o panorama do futuro do Java foi dado com base no Java EE 6, usando JSF 2.0, Web Beans e EJB 3.1. A especificação do Java EE 6 e as próximas serão cada vez mais “puras” e o uso de Spring com Java EE 6 será maior. Fora a omissão de alguns pontos relacionados as soluções, muito pelo tempo disponível, o conteúdo e desenvoltura dos palestrantes agradou.

Adotando Agile: o caminho das pedras – Cláudio Teixeira

Adotando Agile: o caminho das pedras - Cláudio Teixeira

Cláudio Teixeira trouxe um panorama bem legal das metodologias ágeis, muito pela sua experiência com desenvolvimento e arquitetura de projetos em Londres, onde a “onda ágil” está atuante a muito mais tempo. Para se entender melhor porque há novidades em termos de metodologia, foi feita a seguinte pergunta: “Qual a motivação para um novo approach?”. Resposta: “Projetos falham” (em todos os níveis). Com base nisso, e sabendo que o cliente é exigente, é imprescindível fazer com que os projetos sejam rápidos (em termos de tempo), pois a reposta do cliente é rápida e as chances de errar diminuem.

Peguemos como exemplo o RUP. O RUP busca a “perfeição no processo” (o bom é inimigo do ótimo). Onde era implementado RUP? Em sistemas governamentais e exército dos EUA (alto custo e baixa tolerância a falhas), sendo fortemente apoiado a contratos. Para esse cenário não poderia ser diferente.

Com o “boom da Web” e os “Startups! de empresas” houve uma alta demanda de software, mudando o foco para confiança na empresa e menos em contrato e “burocracias”. Se o RUP fosse adotado teríamos planejamentos proféticos e “quadrados” (muitos manuais e cronogramas de processos). Fora que as “metodologias tradicionais” não mostram a “saúde” do projeto (Gráficos ROI e Waterfall não são suficientes). Nesse panorama pensou-se em dois confrontamentos:

  • Funcionalidades X Utilização: quanto mais rápido o feedback do cliente final melhor (faz-se apenas o necessário);
  • Desenvolvimento de software X Manufatura: custo e tempo são essenciais. Podem ser iguais ou não.

Todo esse cenário motivou algumas pessoas (do meio empresarial) a criarem algo novo, mas que fosse compatível com a situação do mercado e desse opção de aproveitar a demanda deste. Daí nasceu a expressão “ágil”, o manifesto ágil e a criação da Agile Alliance. Em nível de metodologia ágil temos 3 tipos de aplicação do processo:

1. Extreme Programming (“XP – O processo dos geeks”):

  • Feedback rápido e simples;
  • Entregas incrementais;
  • “Abraça” mudanças;
  • Código de alta qualidade.

2. SCRUM (“O processo da sala de guerra”):

  • Processo promove acerto e erro;
  • Feedback rápido;
  • Entrega em pequenas iterações;
  • Saúde do projeto vísivel (gráficos Burndowns);
  • Gerente não é comando controle, mas facilitador.

3. Lean: Processo de desenvolvimento da Toyota e tem raízes do SCRUM. Não muito conhecido no Brasil.

As desvantagens dos 3 são (nem tudo é perfeito…):

  • Não funciona com equipes “júnior”;
  • O cliente deve estar “100% disponível”;
  • Adiciona muitas práticas novas para as equipes;
  • O processo é fechado e deve ser seguido a risca;
  • A história do “porco e o frango” (comprometidos e envolvidos).

Qual usar? Scrum ou XP? Scrum gerencia melhor os processos, mas XP fornece melhores práticas (TDD, Unit Tests…). Melhor usar os dois!

E como adotar? Há dois caminhos: Consultoria externa ou “in house”. Se a escolha for a segunda há algumas dicas:

  • SCRUM é mais fácil de adotar;
  • Estude Lean também;
  • Escolha um projeto piloto;
  • Educação para o pessoal de negócio é necessária.

Foi com certeza uma das melhores palestras do evento. O palestrante passou muito bem o conteúdo e foi bastante claro, fora as doses de humor, necessárias depois do almoço (rs).

Java e TV Digital – Dimas Oliveira

Java e TV Digital - Dimas Oliveira

As palestras e a participação do Dimas nos eventos já virou marca de atenção ao conteúdo falado e muitas perguntas ao final da palestra. Não foi diferente dessa vez. Ele praticamente deu algumas dicas e panorama sobre TV Digital com Java, material de referência, Ginga, especificações, etc. Abaixo irei enumerar em tópicos:

  • Compartilhe seu conhecimento e credite as fontes (um “lema” do próprio Dimas. Sempre repetido em suas apresentações);
  • Divulgou uma previsão de venda de 230 milhões de set-top boxes em 5 anos. Mercado de atuação haverá, e muito;
  • Java é um “ecossistema”, formado de usuários e desenvolvedores. Procure sempre saber o que os usuários necessitam;
  • Mostrou fotos do primeiro teste com Ginga no Brasil: ano de 2005 na Paraíba. Pertencemos a “vanguarda” da tecnologia relacionada a TV Digital no mundo;
  • SBTVD é inovação nacional;
  • Em 2012 o Brasil será o segundo maior mercado emergente em TV Digital;
  • TV interativa (TV + aplicações controlando áudio e vídeo) irá necessitar de profissionais e aplicações em Java;
  • Ginga-J faz parte dos padrões mundiais de TV Digital;
  • Java DTV é uma API/especificação Java para TV digital, Ginga-J contém Java DTV e é uma parte do Ginga. O Ginga (NCL/LUA & J) é o middleware;
  • Quem tiver mais curiosidade pode ler a especificação do Java TV (JSR 927);
  • Ginga integra widgets lwuit para melhorar a interface gráfica;
  • As padronizações devem ser seguidas para qualquer operadora;
  • Para quem deseja aprender sobre TV Digital: a curva de aprendizado é de 5% a 8% a mais de conhecimento Java.

Palestra esclarecedora, apesar de já ter visto muitas dessas informações em eventos anteriores (Profissão Java e Java@TVDigital). Ao fim dela, e na saída para o coffee-break, muitos participantes se aglomeraram na frente do palco para fazer perguntas a Dimas. Para quem deseja saber mais sobre TV Digital pode mandar um email para “tvdigital-subscribe@soujava.dev.java.net” e participar da lista de discussão do SOUJava, sendo que o próprio Dimas faz parte.

Painel: Java FX, Adobe Flex e GWT – Éder Magalhães, Maurício Leal e Rafael Nunes

Painel: Java FX, Adobe Flex e GWT - Éder Magalhães, Maurício Leal e Rafael Nunes

Esta última palestra do evento não era para ser um painel (“disputa” de qual a melhor) entre as 3 tecnologias ligadas a RIA, mas um comparativo do que elas podem fornecer. Java FX foi apresentada por Maurício Leal, GWT por Éder Magalhães e Flex por Rafael Nunes.

Sobre Java FX:

  • Rich clients estão mudando o jogo. É preciso ter mais clientes ricos, onipresentes e “projetados” pelo desenvolvedor. FX é a solução;
  • É preciso “extender” RIA em diversas telas. Java FX é a plataforma para criar e entregar RIA;
  • Gera aplicações únicas e completas para desktop, mobile e outras. É portável para qualquer dispositivo;
  • Runtime poderoso e desacoplamento da aplicação do browser;
  • A aplicação é independente do browser, pode ser arrastada para “fora” do mesmo;
  • Coisas a serem construídas com Java FX: vídeo player, efeitos 3D, Java Applets, etc. Todos podem ser “arrastados” para fora do navegador;
  • Existe plugin para Photoshop e Illustrator;
  • Curva de aprendizado rápida: 1 semana.

Sobre GWT:

  • Suporte a Web interativa (RIA);
  • Navegação rápida, agradável e fácil;
  • Produtividade na construção e manutenção de aplicações Web;
  • Web leve: HTML + CSS + Ajax;
  • Para fazer uso de GWT é preciso ter uma equipe com experiência em Java;
  • Ideal para quem conhece Swing;
  • MVC só com código Java;
  • Constrói aplicações Ajax c/ Java (voltada a Open Source);
  • Widgets (componente de uso de interface) que podem ou não ser customizados;
  • Compila código Java em JavaScript;
  • “Esconde” a complexidade do Ajax;
  • Resolve incompatibilidade de browser;
  • Suporta recursos do Java 5;
  • Chamadas são assíncronas e acessadas por GWT RPC (servlet) ou HTTP (retorna XML,JSON e/ou JSNI e é solução para REST ou WebService).

Sobre Adobe Flex:

  • Baseado em linguagem de marcação (MXML);
  • SDK Open Source;
  • Action Script (linguagem de programação orientada a objeto);
  • A proposta é fazer front ends;
  • Flex Builder (“Eclipse” para Adobe Flex): no Windows é pago, mas é completo; no Linux é gratuito, mas tem menos funcionalidades disponíveis;
  • É preciso ter Flash Player para rodar aplicações Flex ou Air (rodam em desktop);
  • Multiplataforma;
  • Curva de aprendizado suave;
  • Independe de backend (Java, PHP, outras);
  • No segundo semestre sairá a versão 4 (!);
  • Depende de fornecedor, runtime e IDE paga. Exige mais poder do cliente;
  • Integra com WebServices e gera cliente automático através de WSDL;
  • HTTP Service (XML ou JSON);
  • Integração AMF: BlazeDS e GraniteDS para Java (depende do backend);
  • Frameworks: Cairngorm, Pure MVC, Mate Flex, Swiz;
  • Flex Unit para testes unitários;
  • Case de sucesso: tour de Flex & flex.org/showcase.

Qual a melhor? A que melhor se aplica pra você, seu projeto e sua realidade.

Conclusão

Foi mais um evento importante do qual pude participar e adicionar conteúdo ao meu portifólio de conhecimento. O nível dos palestrantes, temas e assuntos abordados ficaram de acordo com a atualidade. Mais de 300 pessoas estiveram presentes no OpenTDC 2009. E o mais importante e motivo de parabéns a equipe da Globalcode: tudo isso gratuito. Portanto, indico fortemente a ida de pessoas interessadas em Java e outras tecnologias a esses eventos. Para os interessados na programação do evento ou mini-bio dos palestrantes, favor acessar o link do evento. Para acesso as fotos do evento, inclusive as deste post, podem acessar o Picasa da Globalcode.

Pontos positivos

  • Nível, conhecimento e desenvoltura dos palestrantes;
  • Networking e acesso a informações;
  • Gratuito.

Pontos negativos

  • Atraso nas duas primeiras palestras, motivo pelo qual impactou na apresentação da terceira, e quiçá, mais importante palestra do evento, pois era modelo daquilo que seria apresentado no JavaOne 2009.

Espero que vocês, caros leitores, tenham gostado da leitura de minhas impressões, coletadas durante o evento. Fiquem à vontade para comentar, criticar ou complementar. E aguardem a publicação das minhas impressões do Java@TVDigital, evento também organizado pela Globalcode e de boa repercussão.

Até a próxima!

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