ApacheCon Brazil and why we need it?

I'm not sure if this mailing list is the right one to write about this, but I'm gonna take the risk. I suppose "Community" means anything related to it. And this is definitely about community.

Before anything, I'd like to share my history with ASF. (skip if you want... :D)

When I started to get involved with the Apache Software Foundation in a deeper level, I was still just a user, downloading Tomcat and using it. I guess most Java developers for the Web environment still do that.

5 years a go, I joined the Apache Wicket community and then my relationship with ASF has born. And for the last 5 years I've been speaking about it in Brazil, either in JUG meetings or at conferences around the country and sharing everything I wanted to share on my blog. I've even created a Google Groups for that, called Wicket pt_BR. With my contributions as an "evangelist" I gave birth to friendships with great people like Martijn Dashorst, Jeremy Thomerson, Eelco Hillenius and others from the Wicket community.

Then, in 2008 I heard about the Apache TAC and, thanks to ASF, I could meet them in person during ApacheCon @ New Orleans. It was better than anything I've ever experienced. Considering how close I was to great people, professionals and friends, and how easy I could start chatting about anything to them, I thought that was the best conference it could ever exist. I thought: "ApacheCon is the best. I got free beer!". That was cool. Every conference I go here in Brazil, I wish someone put some beers instead of Coke. Until now... only #fail

Then, right after I came back from New Orleans, I started to play with the SOA stack (Camel, CXF, ServiceMix and ActiveMQ). I also became friend of great people like Bruce Snyder, Claus Ibsen, Hadrian Zbarcea and Debbie Moynihan.

Last year, 2009, when I heard about ApacheCon in San Francisco, I took the chance to apply again to the Apache TAC (no, I wasn't bargaining; it really is expensive to fly from Brazil to the USA, specially SF). I just applied for the tickets, and for accommodation I was safe with CouchSurfing friends I already knew. Also, I really wanted to help the organization. It was when I met Nick Burch, Ross Gardler and Noirin Shirley. Could not forget my latin friends Amelia Blevins and Carlos Sanchez. Other names like Jesse McConnell, David Blevins and Yeliz Eseryel are also in my good memories of ApacheCon 2009. Unfortunately this year, because of personal reasons (not because of TAC rules), I couldn't be present at ApacheCon.

With the help of Bruno Souza, I discussed with some people, including Sally Khudairi, the idea of bringing ApacheCon to South America.

What I saw on ApacheCon '08 and '09 was something amazing. Perfect for South America. Perfect for Brazil. The Apache Way is something that must be shared with everyone. 

A few months a go, I went to Brasilia (country's capital) to talk about the ASF in general, not on an specific project. It's amazing how people are unaware of what the ASF really is. And how people limit their knowledge to only what the big players show to them. Still, they all know Struts and Tomcat. It seems that South America is a big user of Apache projects rather than truly contributors.

Now this year, with JavaOne going to happen in Brazil, and the sessions that were scheduled, I believe it is now the time to drive ApacheCon south. There's no single talk about anything related to the Apache Software Foundation in this South American version of JavaOne. And I feel really sad about that. Sad that people that are behind the organization had the opportunity to accept papers (I myself proposed Wicket and Camel - papers I have been presenting since 2008 for rooms of 30~40 attenders).

And I'm sure everyone will use Maven, Ant or Tomcat to demonstrate something.

I don't know if this happened because of recent issues between Oracle and Apache, or just because of Java standards (like JSF, JavaFX, EJB) are more important than non-standard projects. It doesn't matter. I'm sure there was room. On my count, there are at least 3 subjects with more than 1 submission approved. Look at JavaOne track.

Now, if the ASF, the most voted JCP EC member (with 95% votes), has no space on JavaOne Brazil, the country who have been participating in the Open Source movement, giving birth to the OpenJDK thanks to Javali project, and Bruno Souza, than we should start considering other alternatives. Alternatives to standards, like Wicket or Camel.

We already have ApacheCon Europe and North America. I'm sure we can do ApacheCon South America.

Let's do this happen. Let's do it the Apache way.

Bruno Borges

Apache Wicket ainda mais divertido: Parte 1

Este é o primeiro de uma série de artigos para mostrar o Wicket à comunidade brasileira. Cada artigo que eu ler sobre JSF, Facelets e afins que achar interessante e me questionar: "seria ainda mais divertido fazer isso com Wicket", vou fazer um "fork" do artigo e codificá-lo com o Apache Wicket.

Para começar, vou forkar o artigo do Eder Magalhães sobre como tornar um trecho de código Facelets em um componente reutilizável, chamado "Facelets ainda mais divertido! Parte II".

[início do fork]
Neste post vou comentar sobre a criação de componentes usando somente HTML simples e Java puro - na minha opinião o grande diferencial do Wicket. O cenário é um formulário de manutenção de registros de funcionários, e o protótipo é simples:

É comum um protótipo ser entregue por Web Designers, e o nosso trabalho está em adaptar aquele protótipo para processar informações dinâmicas. A página acima se chama CadastroFuncionarios.html e a seguir, o código que o Web Designer entregou:

CadastroFuncionarios.html

Mas é comum ter trechos de telas que são repetitivos. Como os botões de ações deste formulário. Então é interessante tornar isso um componente para ser reutilizado e quando exigir modificação, que seja apenas uma vez, em um único lugar.

No Wicket, páginas são componentes, e funcionam em pares (Java e HTML). Como queremos construir um componente com os botões, precisamos de um painel, para ser reutilizado em outras páginas. O primeiro passo é criar a classe e um HTML exclusivo para o painel, contendo somente os componentes de botão.

Para criar um novo painel para agrupar componentes, existe a classe Panel. Vamos criar uma subclasse dela e especializá-la:

BarraBotoes.java

Por se tratar de um painel de botões, deixei implementado 3 métodos associados 1 para cada botão. Quem utilizar este componente, poderá facilmente sobrescrever estes métodos para adicionar funcionalidades por ação. Outra vantagem aqui está na documentação gerada automaticamente, se o programador preencher o Javadoc.

Para finalizar o componente (segunda etapa), é preciso o HTML do painel, chamado de BarraBotoes.html

BarraBotoes.java

A tag wicket:panel é uma das poucas tags especiais (carregadas pelo DTD). Aqui ela serve para delimitar o que representa o painel, sem prejudicar as ferramentas WYSIWYG. Deixei propositalmente o restante do código HTML por fora da tag para representar um protótipo, que pode ser visto pelo designer e ajustado por ele próprio, caso queira mudar folhas de estilo. A vantagem é que ele pode avaliar se estas mudanças atenderão os requisitos de design. Ou seja, o protótipo continua funcional. Também foi feito o binding entre os componentes no HTML e os componentes em Java através do atributo wicket:id.

A partir desse momento, o painel pode ser reutilizado. Nenhuma outra configuração é necessária. Exceto um import da classe em outras páginas. :-)

Agora precisamos ajustar a página que conterá o painel. Abaixo, o novo HTML da página CadastroFornecedores.html já com os ajustes para binding com Wicket:

CadastroFuncionarios.html

E o código Java para a página:

CadastroFuncionarios.java

Para implementar uma ação, o programador precisa somente sobrescrever os métodos que lhe for necessário. Agora que a página está pronta, e utilizando o componente, o próximo passo é melhorar a inteligência do componente, com zero de alterações nos HTMLs, poucos ajustes na classe do painel BarraBotoes, e uma linha de alteração na classe da página.

• Apresentar o botão excluir de forma condicional, com base em um boolean
• Botão cancelar deve sempre abortar o formulário onde estiver contido

Caso seja de interesse do programador acrescentar mais lógica no componente, para que por exemplo os botões tenham visibilidade condicional, ajustes na classe BarraBotoes devem ser feitos. E somente nela. No HTML nada precisa ser alterado. Abaixo, o código da classe com lógica de visibilidade condicional de botões:

BarraBotoes.java

A primeira acao foi adicionar um construtor que recebesse um Model (assunto para outro post), do tipo Boolean, e associar este Model como condicional para o método isVisible() do botão excluir.

A segunda ação foi ajeitar o construtor padrão para continuar funcionando como anteriormente, e mantendo assim compatibilidade com páginas que sempre mostram o botão excluir. Novas páginas poderão utilizar o novo construtor e condicionar a exibição do botão, se quiserem.

A terceira ação foi cancelar o processamento dos dados do form quando o botão cancelar for clicado. Para isto, a propriedade defaultFormProcessing deve ser desabilitada.
[fim do fork]

A grande vantagem do Wicket está em jogar para o lado Java toda a programação da interface, deixando o protótipo limpo, estático, e mesmo assim permitindo o programador manipular com uso inteligente da orientação a objetos, os componentes de tela.

O que mais você gostaria de saber sobre o Wicket?

Abraço,
Bruno

PS: mock de tela feito no Mockflow

Dicas para uma senha segura

Senha. A porta de entrada para qualquer coisa na era digital. Uma senha fraca e você perde seu perfil no Orkut. Uma senha comum e seu servidor é hackeado. Os riscos são enormes quando não utilizamos uma senha adequada, mas também podemos perder o acesso se não nos lembrarmos dela.

Leia mais deste meu post sobre Dicas para uma senha segura em Lado Servidor.

A bruxa está solta em Floripa

Eu já estou acompanhando o caso há muito tempo, mas agora finalmente saiu na mídia nacional:

http://www.conversaafiada.com.br/politica/2010/07/12/policia-tucana-de-s-catarina-tem-um-estupro-para-esclarecer/

http://www.conversaafiada.com.br/politica/2010/07/11/“heroi”-do-mosquito-vai-aconselhar-serra-em-santa-catarina/

Como já disse ao meu pai, que juntamente com todo o resto da minha família e outros familiares, ainda vivem em Florianópolis: "A Ilha da Magia é o paraíso não-fiscalizado de políticos do PSDB (e aliados)".

O atual prefeito é itinerante (foi prefeito por 8 anos em São José, e não esperou 4 anos para ser prefeito em Florianópolis). 

Roubou quase R$ 5 milhões de reais no último reveillon, com uma árvore de natal superfaturada e um no-show de um cantor italiano que faria a cerimônia dos fogos.

O governador Pavan vive enrolado em casos e descasos.

O irmão do prefeito é, ironicamente, atual prefeito em São José, a cidade vizinha, que junto com Florianópolis forma 80% da economia da Grande Florianópolis.

A RBS (filial Globo) não noticiou um caso de estupro, e quando o fez, nada detalhou e ainda se defendeu atrás do ECA. Motivo? O estuprador é da família sócio-majoritária do Grupo RBS. Com as fortes brigas entre Globo e Record, esta última aproveitou a oportunidade para deitar o cacete. http://tinyurl.com/2clnp2d

Até o momento, nenhum canal de notícias que tenha qualquer vínculo direto ou indireto com a Globo/RBS fez uma reportagem sobre o caso do estupro.

Na internet, se encontra muito sobre o que aconteceu no Barraco de Sorocaba (#Sorocabarraco), assim como sobre o caso do estupro. Entretanto o Fantástico ontem preferiu fazer a matéria sobre o barraco.

Não bastasse tudo isso, ainda não se viu na mídia nacional qualquer exposição às frequentes manifestações de estudantes na cidade a respeito do último reajuste de ônibus, elevando a tarifa ao valor de R$ 2,95, sem aumento de frota, horários ou qualquer melhoria no precário sistema desintegrado de transporte.

É a Ilha da Magia, voltando aos tempos de bruxaria.

Oi é investigada por invasão de privacidade

O Dep. de Proteção e Defesa do Consumidor (DPDC) do Ministério da Justiça investiga possível invasão de privacidade dos usuários Velox, graças ao uso de uma ferramenta de monitoramento, chamada Webwise.

Em Dezembro de 2009 eu já havia mencionado que a Oi, assim como muitos outros provedores, já praticam invasão de privacidade graças a natureza da tecnologia envolvida no acesso à Internet.

Invasão de Privacidade no Oi Velox para controle de velocidade

É possível, sem instalar qualquer programa nos computadores dos usuários, identificar quais sites os usuários estão acessando. O programa Webwise na verdade é um complemento para cruzar informações. Esta investigação do DPDC deveria se extender a uma análise técnica dos roteadores e servidores utilizados pela Oi, e por outros servidores.

Identificar quais sites são acessados pelo usuário não é difícil para a Oi. Ela já faz isso. Difícil é obter informações como tempo gasto e programas.

*** Atualização ***
Enviei o e-mail abaixo à Sra. Laura Schertel Mendes, coordenadora geral de Supervisão e Controle do DPDC, exigindo que nesta investigação com relação ao uso do software BT Webwise, também fosse feito um trabalho para auditoria dos servidores e roteadores da Oi, assim como de outros provedores que praticam Traffic Shaping.

Bruno Borges	Tue, Jun 29, 2010 at 7:26 PM
To: laura.mendes@mj.gov.br
Boa noite Laura,     Acompanho os movimentos da Oi com relação ao Webwise desde Dezembro de 2009, quando apontei em meu blog que a empresa já praticava invasão de privacidade em seus usuários Velox remotamente, ao identificar em seus servidores/roteadores o conteúdo acessado com o propósito de limitar a velocidade dos usuários. Ao ver o recente anúncio da investigação oficial contra o BT Webwise, gostaria de em primeiro lugar, parabenizar pelo trabalho, e em segundo lugar, pedir que esta investigação não se limitasse somente ao uso do BT Webwise nos computadores dos usuários, mas também a uma auditoria e investigação nos servidores/roteadores da Oi, e de outros provedores de Internet. O motivo é o Traffic Shaping ilegal.     A técnica de Traffic Shaping praticada pela Oi é invasiva, pois restringe somente conteúdos de vídeos. Não bastasse a invasão nos dados trafegados entre servidores e o computador do cliente para identificar que se trata de vídeos, a Oi ainda pratica ilicitamente, um limite de velocidade para não prejudicar sua má dimensionada infraestrutura. Os planos oferecidos pela empresa não condizem com a sua infraestrutura, além de induzirem usuários a contratarem planos mais caros (e supostamente mais velozes) ao encontrarem lentidão em suas conexões.     Fica evidente neste vídeo que gravei, que a Oi utiliza técnicas avançadas de Traffic Shaping para dificultar a constatação da prática abusiva de limites de velocidades.     Assim como a Oi induziu usuários do Velox a instalarem o BT Webwise, ocorre também uma indução à contratação de planos mais velozes para solucionar os problemas de velocidades derivados da prática do Traffic Shaping.     Gostaria se possível, de alguma forma participar, como cidadão e usuário, destas investigações ou ao menos receber uma confirmação de que haverá algum trabalho para analisar as constatações levantadas por mim neste e-mail. Atenciosamente, Bruno blog.brunoborges.com.br +55 21 76727099

Tchau!