Bruno Pereira

Algum tempo atrás eu fiz umas modificações no CSS do meu blog, pois não estava plenamente satisfeito com o mesmo. De uma maneira geral, havia apenas aumentado a largura do corpo da página e diminuído um pouco a largura da barra lateral do blog. A outra coisa que eu havia feito é justificar o texto dos posts.Após fazer estas modificações, achei que a disposição da página deixou a leitura mais agradável, mas em algumas máquinas o blog estava pesado no Firefox, a rolagem da página não estava leve. Eu não sabia o motivo disso, mas após diversos testes hoje pela manhã, removi apenas a opção de justificar o texto, e parece que o blog voltou ao normal, não está mais pesado no Firefox.

Eu gostaria de ter o texto justificado, mas como isto estava trazendo problemas para a usabilidade no Firefox, prefiro abrir mão disso para melhorar a “experiência do usuário” (confesso, eu mesmo estava ficando irritado.. hehehehe) Aqui em casa o blog já está leve novamente, mas caso alguém perceba problemas com a rolagem da página, por favor me avise.

Eu já há um bom tempo utilizo o Linux como ambiente de trabalho em casa, e felizmente, há mais de 6 meses já tenho o prazer de usar Linux aqui na Globo.com também. Uma das coisas que me incomodava um pouco quando comecei a usar o Eclipse no Linux era a aparência do mesmo. O Eclipse por default no Linux não fica com uma interface muito legal, dependendo das fontes que você esteja usando no seu ambiente gráfico.Já há bastante tempo eu utilizo como a Tahoma tamanho 9 como fonte principal no KDE e também no Eclipse. Esta fonte me agrada bastante e com ela eu considero bem mais agradável o uso do Eclipse, comparando com as fontes padrão que vêm configuradas no Linux. Esta semana saiu um post no Planet Eclipse falando deste mesmo assunto, e eles mostraram uma configuração de fonte que o pessoal do JBoss utiliza para trabalhar.

Eu baixei as fontes Liberation que eles usam e fiz um teste aqui para ver se gostava ou não da aparência. Realmente essa fonte que eles usam é bem legal, e eu cheguei a ficar em dúvida se mantinha a Tahoma ou se mudava para Liberation. Claro que esta é uma decisão de gosto pessoal, cada um tem suas preferências, e eu por enquanto estou mantendo Tahoma, pois já estou bastante acostumado e satisfeito com ela.

Para que vocês possam ver a diferença, seguem abaixo dois screenshots do Eclipse rodando aqui no Kubuntu, o primeiro delas com o uso da Tahoma 9 como fonte do Eclipse e fonte do editor Java e o segundo com o uso da Liberation Sans tamanho 10 (o tamanho 9 aqui estava com a largura estranha para algumas letras).

E aí, de qual vocês gostaram mais?? Eu não consigo me decidir sobre qual fica mais interessante pra mim, então estou mantendo o time vencedor com Tahoma.
OBS: A renderização das fontes varia de um sistema operacional pro outro, e no Eclipse no Windows eu não gosto da aparência da fonte Tahoma, e mantenho as configurações de fontes padrão do Eclipse no Windows, pois elas são satisfatórias pra mim (e afinal de contas, eu quase não uso Windows, não faz muita diferença… hehehe).

Update: Para melhorar MUITO o espaçamento das linhas no package explorer, navigator e outras views estilo Árvore, recomendo a criação do arquivo .gtkrc-2.0 no seu diretório home, com o seguinte conteúdo (experimente este conteúdo primeiro, e então modifique o que achar interessante) :

style "gtkcompact" {
font_name="Sans 8"
GtkButton::default_border={0,0,0,0}
GtkButton::default_outside_border={0,0,0,0}
GtkButtonBox::child_min_width=0
GtkButtonBox::child_min_heigth=0
GtkButtonBox::child_internal_pad_x=0
GtkButtonBox::child_internal_pad_y=0
GtkMenu::vertical-padding=1
GtkMenuBar::internal_padding=0
GtkMenuItem::horizontal_padding=4
GtkToolbar::internal-padding=0
GtkToolbar::space-size=0
GtkOptionMenu::indicator_size=0
GtkOptionMenu::indicator_spacing=0
GtkPaned::handle_size=4
GtkRange::trough_border=0
GtkRange::stepper_spacing=0
GtkScale::value_spacing=0
GtkScrolledWindow::scrollbar_spacing=0
GtkExpander::expander_size=10
GtkExpander::expander_spacing=0
GtkTreeView::vertical-separator=0
GtkTreeView::horizontal-separator=0
GtkTreeView::expander-size=8
GtkTreeView::fixed-height-mode=TRUE
GtkWidget::focus_padding=0
}
class "GtkWidget" style "gtkcompact"
style "gtkcompactextra" {
xthickness=0
ythickness=0
}
class "GtkButton" style "gtkcompactextra"
class "GtkToolbar" style "gtkcompactextra"
class "GtkPaned" style "gtkcompactextra"


Neste dia em que ficamos sabendo da compra do MySql pela Sun, acaba de ser divulgada também a compra da BEA pela Oracle!A compra da BEA pela Oracle está longe de ser uma surpresa, afinal a Oracle já havia feito uma tentativa anteriormente e sabemos que o Larry Ellison tem feito algumas aquisições marcantes de empresas, como a da Siebel e da Peoplesoft. Entretanto, isto ocorrer exatamente no mesmo dia da aquisição do MySql pela Sun não deixa de ser uma surpresa. Uma empresa muito forte em Java comprando uma empresa de banco de dados, e a fabricante do maior banco de dados do mundo comprando uma empresa fortíssima em Java. Momentos de consolidação no mercado.

Em relação à compra da BEA, espero que a abordagem da Oracle seja abandonar suas linhas de produtos Java e seguir a liderança da BEA nessa área. Os produtos Java da Oracle são infinitamente inferiores aos da BEA, e com esta compra teremos a Oracle com um novo braço tecnológico de muito vigor.

Uma aquisição deste porte ainda demorará algum tempo para demonstrar suas conseqüências, mas agora o pessoal da BEA terá poder financeiro para atuar ainda mais na vanguarda com seus produtos. Seus já excelentes produtos de SOA, BPM, Java e integração com certeza receberão investimentos maiores que os atuais e isto pode interferir nos rumos do mercado, pois agora a Oracle estará muito forte em áreas nas quais ela corria atrás dos outros players.

Muitas perguntas e incertezas surgem em função destas significativas aquisições de hoje, e uma pergunta interessante foi lançada pelo Savio Rodrigues : Quando a Oracle vai comprar a Sun? E pergunto eu: será que a HP não poderia comprar a Red Hat por exemplo?? Nesta consolidação do mercado, muitas coisas interessantes estão por vir. Como desenvolvedor Java, torço para que ambas as aquisições dêem ainda mais anos de sobrevida à plataforma e à linguagem Java. Let’s wait and see

Notícia bombástica no mundo open source. A Sun anunciou hoje no blog do Jonathan Schwartz a compra do MySql, com a promessa de investimentos de US$ 1 bilhão no mesmo.Durante muito tempo eu considerei o PostgreSql uma opção melhor que o MySql, embora este último seja razoavelmente mais popular (por oferecer desde o começo um instalador nativo pro Windows). Entretanto, com esta nova notícia, fica a certeza de que o MySql terá um salto enorme de desenvolvimento e provavelmente irá amadurecer e crescer ainda mais rápido.

Ainda é difícil saber que impacto isto terá no mercado de uma maneira geral, mas podemos esperar um bom progresso do MySql e torcer para que ele continue com seu modelo open source de muito sucesso. Eu particularmente penso que ambas as empresas têm muito a ganhar com esta compra e que isto trará ainda mais força para o movimento open source.

Quando será que alguém vai comprar o excelente PostgreSql também??

Just beginning 2008, I went to a new area, new team at Globo.com. There are several promising projects for this year, and this team switch will make it easier for me to properly evaluate and judge what I consider the 2 leading Java web frameworks nowadays.Like I said here, on my spare time I (try to) develop a lawyer application which uses Apache Wicket as its web framework. One of the projects I’m now working at Globo.com uses Java Server Faces. This should be a great opportunity to finally go deeply on both frameworks and see in which cases each one is better than the other. Based on what i have already studied and used of both, i do have some opinions that may or may not change several months from now.

First, a little background. When i was studying to pass the SCWCD exam, I saw enough of tag libraries to get really sick of them JSTL, Struts 1.x Taglib, Expression Language, etc etc etc. Every new taglib was a new syntax to learn, and the result of using taglibs to implement complex web pages is the famous tag soup. Not being a purist, although I don’t like scriptlets in general, I do think that in some cases they produce much cleaner code than the heavy use of taglibs.

Having said that, let’s start talking about JSF. Being a standard technology backed by Sun, and present on Java EE 5 specifications, you know that you’re gonna find plenty of support by development tools, many examples on the web and an already mature community of users to help you. JSF offers a huge set of components ready to use, and many of them are very pretty and easy to use. In my case, we’re using JBoss Tools + Rich Faces, and the Eclipse plugins avaiable here are just awesome.

Most of the web applications I have worked until now used Struts 1.x, and although Struts is by far the most successful Java web framework til now, developing with JSF is reasonably easier and more pleasant. However, even considering the clear evolution of JSF over Struts 1.x, I still qualify both within the same paradigm. That is, both have a massive dose of non-markup code in their views, and if you’re gonna work with them, you better have your spoon ready to dig into the tag soup Ok, ok, JSF offers very nice components and manages a lot of the work that was left to the developer in the old times, such as managing the application state and offering a beautiful presentation layer without requiring the direct manipulation of javascript. But you’re still going to have your view layer full of taglibs, coding in a special syntax (the custom tags syntax) that will make it tough to track for problems when they happen within the tag soup. You better have a magical spoon to manipulate it

Rather new in the Java web frameworks field is the very innovative Apache Wicket project. Wicket allows Java programmers to focus on what they do best: write Java code. No taglibs, how refreshing! Wicket also uses componentized development, and it isolates the view from your model in the best manner I have seen til now in Java frameworks. It does not seem so intuitive in the beginning, because you code for a web application in a similar way as you would code a Swing application. Specifically the component’s event handling code in Wicket reminds me a lot of the approach used in Swing applications.

Being a new framework that went out of the Apache incubation just several months ago, you can’t expect great tooling support at this point. Drag and drop tools to design screens? Forget about it! Component options similar to JSF ones? You’re not gonna find it either. However, Wicket has a very active community and it’s evolving fast. The second book on Wicket will be avaiable in a few months and the number of users and successful implementations is growing steadily. The set of avaiable components is growing and it’s becoming much easier to find support in their forums.

As I said, I’m far from an expert in both frameworks, and I hope this year I’ll have a long enough exposure to them and probably in a few months I’ll have more valuable opinions. Something I think about is that perhaps knowing Wicket and JSF well can be really useful, because it doesn’t seem like we have a “one size fits all” choice here. Wicket seems great for a company to base its developments and have good and maintainable code that will be easy to build over for several years. JSF certainly can offer that too, but i find it tough to consider taglib code as easy to maintain. However, JSF offers such great components that even a Java developer like me with no talent to create good looking pages is able to generate a very decent user interface.

I’ll confess I have a natural preference for Wicket since the beginning, but I promise I’ll try to evaluate these 2 options without any passion during this year and later this year I’ll post again telling my conclusions (if any)

My friend Bairos provides me a Subversion repository and a Trac server, and I use both for personal projects.In my job, our issue tracker is JIRA, and I’m using it with Mylyn for several months. However, just recently i started using Mylyn with Trac, in a project I’m developing at home. The Trac server I’m using doesn’t have the XmlRpc plugin, so I’m not able to use Mylyn’s rich task editor with this server, and I faced some problems using the web task editor inside Eclipse on Linux.

Every time i tried to open the task editor, i was getting the following error message: “Could not create Browser page: XPCOM error -2147221164″. I’m not going to detail my analysis of this error, but I was able to fix it installing the packages xulrunner and xulrunner-gnome-support (I’m not sure if both are needed, though).

From my google searches, I could see that this error happens with a lot of applications on Linux, so probably several people using the Trac Connector with the web task editor on Linux faced the same problem. I hope this tip can help.

Just for the records, my environment here is: MEPIS Linux 7.0, Eclipse 3.3.1 with WTP, JDK 1.6.0_03 32 bits, Mylyn 2.2 and Trac 0.10.4

Eu estava com um problema bem chato aqui no meu notebook. Eu utilizo em projetos pessoais o servidor Subversion do Bairos, e eu não estava conseguindo conectar lá a partir do note. Nas primeiras vezes em que isto ocorreu, era um fim de semana e eu achei que o servidor dele estava fora do ar, pois as tentativas de conexão estavam dando timeout.Após verificar com ele que o servidor estava ligado direto, cheguei a pensar que meu plugin do SVN no Eclipse (Subclipse) estava com algum problema. Tentei reinstalar o plugin e fiz até testes com o Subversive também. Nada funcionava. Eu estava achando muito estranho, pois do trabalho eu estava conseguindo acessar o servidor normalmente, com as mesmas configurações do plugin.

Hoje por sorte eu instalei o Limewire aqui no note, e apareceu uma mensagem dizendo que o software havia detectado um firewall na minha rede. Pronto, desconfiei na hora que este era o problema do meu acesso ao servidor. Como estou usando o MEPIS no note em vez do habitual Kubuntu, logo imaginei que as configurações padrão do firewall são diferentes entre as 2 distribuições.

O MEPIS oferece um software chamado Guarddog para gerenciar as regras do iptables, e acessando o mesmo eu pude ver que o tráfego TCP pela porta 81 (utilizada pelo servidor SVN do Bairos) não estava liberado. Criei uma nova regra, liberando explicitamente o tráfego TCP pela porta 81 e pronto, imediatamente consegui me conectar ao Subversion
Segue abaixo a imagem com a interface do Guarddog, que utilizei para definir a minha nova regra do firewall.

Como eu havia falado: nova distribuição, novos aprendizados. Agora já conheço um software bem amigável para gerenciar o iptables