Mostrando postagens com marcador Java. Mostrar todas as postagens
Mostrando postagens com marcador Java. Mostrar todas as postagens

31 março 2014

JavaFX version of the 2048 game

I've been "busy" this weekend doing several things. But nothing more important than playing the addictive game 2048 (web javascript version). After several hours few minutes playing with it on my phone, I decided to write a JavaFX version called Fx2048. Gabriele Cirulli has published the source code on GitHub in his repository, so you can learn how to code a game like this in any platform!



Now why a JavaFX version? Well, why not? But I will give you a few reasons for you to look into Fx2048:

  • opportunity to learn Java SE 8
  • learn Lambda expressions
  • learn Stream API
  • learn JavaFX 8
  • learn JavaFX CSS basics
  • learn JavaFX animations
There you go! A simple project that will teach you all that :-)

Have fun!

PS: a few bugs to solve and features to implement, but feel free to pull request!

29 março 2014

Get all countries using Java SE 8 Locale

I saw this blog post "Get all the country using Java Locale List" and then I thought about posting something similar, but using Lambda and the Stream API of Java SE 8. Here's my "fork", including a call to sort the locales based on "display country" property.



And if you want to collect all that to a list instead of printing to standard output, replace the last forEach call with collect(Collectors.toList()); and assign a variable.

24 janeiro 2014

Hackathon de Java e Raspberry Pi na CPBr14


Você que é desenvolvedor Java e vai para a Campus Party na semana que vem de 27 de Janeiro a 2 de Fevereiro de 2014, não pode perder o Hackathon de Java e RaspberryPi promovido pelo SOUJava, com apoio da Oracle, trazendo kits, premiação, e mentoring! O objetivo é aprender, praticar e inovar, e todos os participantes ainda vão ganhar uma camiseta. Um dos projetos será selecionado para apresentação no palco principal!

Presença de grandes nomes da comunidade Java brasileira como:

Para maiores informações, consulte o site do SOUJava Hackathon de Java e Raspberry Pi na Campus Party.

15 janeiro 2014

Banco do Brasil e o Java SE 7u51

A nova atualização do Java está mais segura, e bloqueia por padrão os Applets que não estão devidamente assinados ou configurados. Todas as informações sobre como adequar os applets já foram fornecidas pela Oracle há alguns meses atrás. Mudanças no Java SE 7u51 para Applets e Web Start.

Para clientes do Banco do Brasil que atualizaram para o Java SE 7u51, existem duas soluções: 


- aguardar o Banco adequar seus Applets para funcionarem corretamente com a nova versão, ou... 

- configurar o endereço do Banco na nova funcionalidade de "Lista de Exceção de Sites".

IMPORTANTE

Não reduza o nível de segurança para "Médio". Este nível permitirá que Applets maliciosos possam ser executados no seu computador, e danificar o sistema, ou roubar dados. Dê preferência para o uso da função "Lista de Sites de Exceção".

Para saber mais sobre esta funcionalidade, leia o documento Como posso configurar a Lista de Sites de Exceção? na Central de Ajuda do Java em português. 

O processo é simples. Siga estes passos para Windows, mas para Mac OS X o procedimento é o mesmo, exceto a parte de como abrir a tela de Configuração do Java:

  1. Vá ao Painel de Controle do Windows e clique 2 vezes no ícone Java
  2. Na janela que abrir, clique na aba Segurança
  3. Clique no botão Editar Lista de Sites
  4. Clique no botão Adicionar
  5. Agora digite no campo os seguintes sites (um por vez): 
    • Pessoa Física: https://www2.bancobrasil.com.br/  
    • Pessoa Jurídica: https://aapj.bb.com.br/ 
    • Verificador do Plugin do BB: https://cva.bb.com.br/
  6. Clique em OK até sair do painel de controle do Java
  7. Entre novamente no site do BB e tente novamente
PS: dica do Marcelo Breitenbach no Facebook

Para outros bancos e sites que requerem o uso do Java, o procedimento é o mesmo. O importante é saber qual o Endereço do Site para colocar na Lista de Exceção. Escrevi com maiores detalhes sobre este processo, e como configurar para outros sites, no meu Blog da Oracle: Novo Java 7u51 e os Internet Banks no Brasil

13 janeiro 2014

Nova versão do Java para Janeiro 2014

À partir do dia 15 de Janeiro, estará disponível para os usuários a nova atualização do Java. O aviso já havia sido feito no ano passado, mas hoje saiu o anúncio pré-release do Critical Patch Update de Janeiro de 2014 com maiores detalhes. Os produtos relacionados ao Java (Java SE, Embedded, JavaFX, e JRockit) receberão 36 correções de segurança, das quais 34 podem permitir execução remota sem autenticação. Devido à ameaça representada por um ataque, a Oracle recomenda que os clientes apliquem correções Critical Patch Update assim que possível. Para usuários desktop que necessitam de Java para acessar sites que requerem a tecnologia, como Internet Banking, a atualização do Java é extremamente importante.
Esta atualização do Java é chamada de "Java SE 7u51" ou "Java SE 7 update 51" e vem com uma importante novidade. Usuários podem agora indicar manualmente quais sites são confiáveis. Desta forma, os avisos de segurança não serão exibidos, pois fica entendido que o usuário confia no site. Para saber mais sobre esta funcionalidade, leia o documento Como posso configurar a Lista de Sites de Exceção? na Central de Ajuda do Java em português. Ou veja também aqui no meu blog um post sobre esta nova feature. Outra mudança importante nesta nova versão do Java é que todos os aplicativos Java que precisam ser executados no navegador, à partir de uma página Web, deverão ser assinados digitalmente com um certificado válido. Para saber mais, veja este outro post Mudanças no Java SE 7u51 para Applets e Web Start.
Além do Java, outros produtos da Oracle receberão diversas atualizações e correções de segurança neste lançamento, como Oracle VM VirtualBox, Oracle MySQL, Oracle Database, Oracle Fusion Middleware, e muitos outros. Para maiores informações, consulte o pre-release do anúncio do Critical Patch Update de Janeiro de 2014

18 novembro 2013

Você Está Pronto Para O Próximo Update do Java?

Oracle criou dois novos recursos, o 
Java RIA Security Checklist e o Java Security Resource Center para ajudar você a se preparar para a próxima atualização do Java SE, Java SE 7 update 51 (agendado para Janeiro de 2014). Esta versão modifica os requisitos de deployment para aplicações em Applet & Web Start com dois novos requisitos: 
  1. Uso do atributo Manifest, chamado Permissions
  2. Assinaturas de código válidas
Estas mudanças não afetarão desenvolvedores de aplicações back-end, ou cliente standalone; o escopo é limitado somente para Java Applets & Java Web Start (RIAs). Leia alguns destes detalhes no meu post anterior Mudanças no Java SE 7u51 para Applets e Web Start.

Java RIA Security Checklist


A mudança agendada para o Java SE 7u51 irá fazer com que o controle de segurança "default" (security slider) requererá o atributo Permissions no Manifest, e que o código esteja assinado devidamente com um certificado de código válido. O Java RIA Security Checklist
 provê as melhores práticas para ajudar os times de desenvolvimento a identificarem as tarefas necessárias para atender a estes novos requisitos.

Security Resource Center


A Oracle lançou o novo Java Security Resource Center para agrupar informações relacionadas a segurança para a comunidade Java, de acordo com o perfil de cada profissional: desenvolvedor, administrador de sistemas, usuário doméstico, ou especialista em segurança.

Recursos Adicionais

Nota:
 Para garantir que sistemas de usuários finais (end users) estejam protegidos quando usando conteúdo baseado em Java, a Oracle recomenda que você esteja sempre atualizado para a mais recente versão. Você pode remover versões antigas do Java seja durante o processo de atualização, ou com usando a ferramenta Java Uninstall Tool em Java.com.

11 novembro 2013

Reality of Open Source Users in Mobile and Cloud Era

- "I built my Android app entirely with Open Source products, both in the app, and in the backend server running on Amazon. I'm charging US$ 1,99 for it in the Google Play Store" 
- "That's wonderful! Where is the source code of your app? Have you contributed back to these Open Source products? Will you release your product as Open Source?"

In this new era of Cloud Computing and Mobile apps, there's an increasing number of for-profit products that takes advantage of Open Source products, but barely contribute anything back to them, either by buying support, or non-expensive things such as reporting bugs, fixes, or helping documentation. Developers are building SaaS applications for Salesforce.com, or Mobile apps for Android and iOS devices, and usually charge for these. Of course, they want to make money as anyone else.

Whenever I ask someone that makes money with _their_ software built on top of Open Source, if they will ever release the source code, they usually answer: "my case is different". Well, why is your case different? Why can't I buy your app from Google Play Store, and still access the code on GitHub? Or build it on my own, customize it, etc? That's the point of Open Source, right? Wrong, in their minds.

Majority of software developers actually tend to think that Open Source is free as in free beer. And that's it. No matter how hard you try to explain otherwise, the industry will almost always see Open Source software as free software. And due to the new way to sell software, I really think that Mobile apps and Cloud SaaS/PaaS offers will, sooner or later, kill good Open Source softwares, and leave this space only for conceptual and initial implementations for Open Standards and APIs, or for general use and development platforms and languages such as Java, Ruby, etc.

Perhaps you want to read Will Cloud kill Open Source? Is the Future Open Standards? Your thoughts are welcome :-)

04 novembro 2013

Will Cloud kill Open Source? Is the Future Open Standards?

Before you think I'm FUD'ing here, please note that there are already plenty of articles discussing this. Do a search for Open Source vs Open Standards on Google. You might be surprised. The oldest article I found in the first result page is one by Jonathan Schwartz from 2003, titled Open source versus open standards. Then there's another one called ZDNet: Open source vs open standards from 2004. Then there's another interesting one called Open Source vs. Open Standards, by Bob Sutor, from 2006-2009. There's another more recent one from this year, titled Open Standards And Open Source.

But if you payed attention, you might have noticed that none of these articles have the word CLOUD in it. And that's what differs from this blog post you are about to read.

Here is an interesting trend from Google to start this discussion.

Clearly, the interest in Cloud is going up, where interest of Open Source is going down in an almost equivalent proportion. Is the Cloud Computing era going to kill Open Source? I dunno. But this should warn us of one thing: that the Cloud era is not about Open Source. It is about Open Standards (and APIs).

As we all know, APIs expose functionality, not implementation, where the beauty of Open Source is that we all can look at the source code and be sure of how the implementation works, how the pieces are put together to make our application run. If you are a truly defender of Open Source, you are probably thinking right now that there is a company that offers a Cloud platform based on an Open Source software. But do you have access to the runtime? Can you be sure that they are running the exact same code as they tell you? Will they give you access to the server to check if the MD5 is the same? Even the Linux they say they are using might be different. You just cannot be sure. You don't own the infrastructure.

If we take the main 3 types of Cloud offers: SaaS, PaaS, and IaaS, only the latter we can be *more* sure, but still not 100% sure that our applications are running on top of Open Source software. Do you have access to the provisioning code that Amazon AWS uses to create your Linux instance? Do you have access to the source code of the network configuration utility? No. You say your project runs on top of 100% Open Source software. Then you tell me you are running your application at Amazon, or Azure, Oracle, Jelastic, CloudBees, CloudFoundry, etc? You are not running over only Open Source code. You are not. Your application relies on closed-source code to run on that Cloud. There will always be at least one component of that cloud that is not open sourced. And if the cloud provider tells you it is, "and here's the source code", you can't simply believe because you can't make sure of it, you can't see it in the runtime machine. You don't own that.

Now everyone is talking about moving to the Cloud. What will happen if everyone moves their application to some kind of Cloud? In a very extremist view, there would be no more software for on premise deployments, including Open Source. Or at least these would reduce drastically. There would be only... Open Standards.

Which in fact is what developers need these days for Cloud Computing: Open Standards. We all want to be able to move applications from a vendor to another, all it takes is to the other vendor support the same APIs that I require. Are Open Standards the future for Cloud Computing? APIs for SaaS (REST APIs), platforms for PaaS (Java EE), and standards for IaaS (OpenStack)?

Here's another interesting article that also talks about this: Open Standards are the key to True Cloud. Not Open Source Stacks.

I agree with Bruno Souza, where we quickly discussed the ideas I shared here. Open Source will live forever, and it will be the place where Open Standards will probably come up from. It is a de facto. This is how the JCP already works for example.

Which brings us to another question: will Cloud drive the openness characteristic of Open Source less open, and focus more on ideas for Open Standards? Will the Cloud business suggest Open Source as initial implementations for those ideas? What do you think?

10 setembro 2013

Java SE 7 update 40 e o Mission Control 5.2

Java SE Downloads
Chegou uma nova atualização do Java SE 7: update 40. Esta versão inclui várias novas funcionalidades como o Java Mission Control, Deployment Rule Set, suporta para o Retina display no Mac, e suporte a Hard Float ABI no Linux ARM v7. Também inclui diversas correções de bugs. Para quem desenvolve Applets e aplicações Java Web Start, este release, fica a atenção para conhecer e enteder as mudanças.

Deployment Rule Sets

Esta funcionalidade permite um administrador de desktops a controlar o nivel de compatibilidade para clientes Java assim como níveis de segurança para a empresa. Para maiores detalhes, veja a documentação do Deployment Rule Set.

Java Mission Control

O Mission Control era até então uma ferramenta disponível para clientes Oracle, e que foi lançada há muito tempo atrás junto com o JRockit (JRMC). Mas a Oracle agora disponibilizou a ferramenta junto com a JRE HotSpot 7u40. 

Esta ferramenta permite monitorar, gerenciar, introspectar, e detectar memory leaks nas suas aplicações Java, sem ter que introduzir códigos para isso, que normalmente degradam a performance da aplicação. Hoje esta ferramenta está agora disponível no download do Oracle HotSpot JDK 7u40!

Flight Recorder

Mas a principal e mais importante característica é o Flight Recorder. Este recurso funciona através da leitura de eventos produzidos pela JVM. Mesmo ativando a geração destes eventos, a sobrecarga total  para as suas aplicações ainda fica abaixo de 2%, que considerando o tipo e o valor de informação que você recebe, é quase nada. Um exemplo de evento é a chamada de um método de uma classe Java.

Com o profile de chamadas de métodos você pode descobrir onde o aplicativo está gastando a maior parte do tempo executando seu código Java. Este é, por exemplo, útil para otimizar a aplicação onde as otimizações realmente terão impacto. Isto sem precisar introspectar seu código manualmente!

Alem disso, você tem também uma visão de otimização para alocação de objetos. Você pode ver por exemplo, a alocação em tempo real de objetos na Old Gen da memória heap. diretamente no espaço de idade, além de outras abas que oferecem diversas informações importantes sobre o processamento de informações na sua aplicação Java. Leituras de arquivos I/O, Socket I/O e muito mais.

Se você precisa de mais informações sobre o Mission Control, entre na página da ferramenta em www.oracle.com/missioncontrol.

E obrigado ao Markus Eisele por ter cedido parte deste post! :-)

29 agosto 2011

Java 7 Release and the JIT compiler bug

Quotation from Java Performance Tuning newsletter:

"Java 7 was released with a JIT compiler bug. This should not be an issue for the Java performance community - if you have a performance problem, you haven't been waiting for Java 7 to fix it for you, you've been busy analysing and fixing it yourself; and if you don't have any performance problems, you aren't about to upgrade your productions systems to Java 7 on the very first release!"

So true

09 agosto 2011

Participações em eventos de 2011

O ano de 2011 está agitado para mim.

Já estive no JustJava, no The Developers Conference (edição São Paulo) e na próxima semana estarei presente no TDC Florianópolis. Em Setembro ainda tenho o QCon, evento do InfoQ-Caelum. E sobre o quê tenho falado? Apache Wicket.

O desenvolvimento Web em Java deixou de ser lento, e nestas minhas palestras, apresento uma proposta diferente. Programadores e Web Designers trabalhando em conjunto sem que um prejudique ao outro.

Foi-se o tempo que a separação de camadas se dava apenas na programação. Chegou a hora de separar também o trabalho do designer e o do programador. Afinal, o web designer é quem entende bem de CSS, efeitos, web fonts e UX.  No meu post "What are web frameworks missing?" detalho melhor este tema.

Mas voltando aos eventos, segue a programação para quem quiser saber mais:

The Developers Conference - edição Florianópolis
Data: 20 de Agosto de 2011 - 13:10 na trilha Java
saiba mais


QCon - São Paulo
Data: 10 de Setembro de 2011 - 18:10
saiba mais

E se quiser se aprofundar mais, confira o Curso de Apache Wicket que lancei este mês. O curso começa no dia 4 de Setembro.

Curso de Apache Wicket

Lancei ontem o Curso de Apache Wicket, para iniciantes e para aqueles que já utilizam. O curso será ministrado online através de uma ferramenta com compartilhamento de tela e chat. Serão ao todo 4 aulas com duração de 3 horas e meia.

Durante o curso, os alunos construirão uma aplicação completa, integrada ao Spring, paginação e outras funções em Ajax. Os interessados podem se inscrever pelo site www.cursodewicket.com.

Valor: R$ 389,00


4 de Setembro: 9:30 - 13:00
11 de Setembro: 9:30 - 13:00
18 de Setembro: 9:30 - 13:00
25 de Setembro: 9:30 - 13:00

12 julho 2011

What are web frameworks missing?

First of all: there's no perfect web framework. And it doesn't matter what technology, language or platform. But I finally have come to one thing that is really important. Something most web frameworks are missing, and something I believe, as many other developers that have already blogged about, is the future of the Web.

Let's start with the consequence of the problem: the infinit fight between Web Designers and Web Developers. Designers and developers have been fighting for years within web development. And this happens because the work done by designers usually is "destroyed" by developers when they have to inject dynamic/logical code into the HTML, converting it to something like JSP, PHP, RHTML or a mix of Python and HTML. It doesn't matter the language.

The problem is clear: what the designer did goes away. If he must update the design, even if the data structure won't change, most certainly you will have problems. He might break some logics, some code, and you will have to fix it. Then, you might also break some layouts and he will have to fix it. And you might go into a loop for a couple of days because of something that should be done in about hours.


We all talk about separating layers. But when it comes to designers vs developers, we really don't care about because we are trying to push an idea of programmers that are able to design just like designers, or designers able to code as programmers. That just won't happen. You may find one or two excellent professionals like that, but is not easy. Developers and designers have different way of thinking. The former has artistic creativity while the later has logical criativity. So if we, developers, are always saying "let's use the right tool for the right job", what's happening with the designer? His work is not being done in the right tool. I've seen designers with IDEs installed on their Macs because they have to run the project to see how it's looking like.

What if he could simply use Coda or Dreamweaver or TextMate as he does but then just preview the damn HTML in the browser, which is the right tool for him? What if he could simply preview the code that will actually be send to the client? What if he could... do his work with the best tools available? The best tool for his job.

I believe in and code with a Web Framework that helps both Developers and Designers to execute their tasks with the best tools they know. A developer should concern on data, on logic, on security. A designer should concern on layout, design, colors, UX. And what one does should not break the work done by the other.

Without mixing dynamic code with HTML, or even worse, replacing HTML elements with Tag Libraries (JSP, JSF and others), the designer can just open the HTML in the browser and see how is the prototype.

You know that prototype your designer has worked on for a week to get approval from your customer? You can just use that with minimal changes, and the prototype can still be statically functional and also run in the server. If you get an email asking for a change in the layout, no problem. Ask your designer to change the HTML, he will preview in the browser, get approval from the customer, and your developer won't have to change a line.

This is what Web Frameworks are missing. This is what I'd like to see implemented in any Web Framework. This is what Apache Wicket is providing.

The rest is just scaffolding, templates and code generation.

The future is of course static HTMLs, JavaScript and REST+JSON. Web frameworks are dead.
But until the future comes, let's just improve the web development process a little bit, shall we?

21 março 2011

Apache Tomcat 7: Bibliotecas Compartilhadas

Publiquei no Lado Servidor uma dica boa pra quem usa Tomcat 7.

Confere lá

11 dezembro 2010

Top 10 reasons why I don't like JSF

At this JavaOne Brasil, there was a great discussion about Java Web Frameworks, with folks from Caelum, GlobalCode and Oracle. Arun Gupta, Maiko Rocha, Vinicius and Yara Senger, and many others who came to participate.

The discussion went mostly around what companies and developers should do before choosing a Web Framework. Although I was willing to move the discussion to another level (eg, poiting these 10 reasons), I decided to just take it easy. And as I stated: there's no perfect Web Framework. But there's a perfect web framework for your case.

But now I think it is the right time and place to share my thoughts. Here are my top 10 reasons (mostly non-technical) on why I don't like JSF.
  1. Extra step when defining a project's architecture
    People insist on comparing JSF with other frameworks. They should stop doing that. You can compare MyFaces to RichFaces to Tapestry to Vaadin to GWT. JSF is a specification, not a final product.

    Vendors too insist on marketing JSF as a Web Framework. But they forget to mention that you will be locked-in to their implementation because of lots and lots of non-standard components. It ain't cool.

    You spend a week comparing *one* JSF implementation with other frameworks, and if you chose JSF, you then realize you have an extra step: you have to pick a vendor, an implementation, and then goes another week of POCs, tests and evaluations. And you'll be locked. It is not easy to move from one to another. Specially when you have to use those non-standard components to turn your project on something really functional.

  2. Fragmented Community
    Now, let's say you, developer, works on a project for 6 months, on top of RichFaces. Then you move to another project built on top of MyFaces. Yes, you will have to sign in to another mailing list. To another forum. Different from other products, JSF has no centralized community. If you are working with Wicket, you go to users@wicket.apache.org. If you are working with VRaptor, you go to their Forum. If you are working with JSF, you will need to sign up for at least 3 different mailing lists, sign up for 3 forums and probably, tens of blogs.

    It is not easy to ask for help on a fragmented community. If you face a problem with RichFaces, when you were used to work with ICEFaces, you might end up asking something stupid, and probability is you will be told of a different solution to the same problem.
     
  3. Fragmented Documentation
    If community is important, imagine documentation. You must have bookmarks of all JSF implementations. If you work with GWT, you need only one. If you work with SpringMVC, just go to springframework.org. Also there's the problem of non-standard components. Let's say you are working with Seam, and you have to bind some component to some RichFaces component. Where will you find a documentation about that? There's no such thing. If you are luck, you might find some blog post on Google. Odds you won't find. You will discover by yourself after hours of debugging and tracing, and in the end, you will not blog about that too. You will just move on.

  4. Component Incompatibility
    Well, there's not much to say on this. JSF 2.0 address some issues, but not all of them. Component interoperability between different components can't be easily documented because of JSF's nature. This (documentation) also happens on some non-standard frameworks, but there are others that the core architecture helps a lot the developer to just don't care about this. Wicket is one of them. Components are grained and independent. If you want to interoperate different components, you simply share a Model or deal with events.

  5. Caveats on some scenarios because of different implementations
    This one I heard from a JSF developer. He said RichFaces fires rendering updates in a different way to MyFaces Trinidad. If the developer must be aware of that, odds are you won't find proficient JSF developers.

    I pointed about this one at the Web Frameworks discussion at JavaOne. It is not easy to find a Wicket developer, or a Vaadin developer. But when you find them, probability is they will be proficient, or at least above regular web developers.

    With JSF, which has tons and tons of job offers around the world, but lots of implementations and caveats, probability is that you will easily and quickly find a JSF developer to hire, but he or she won't be proficient. They will be regular developers. I'm not saying this is 100% true. Of course it is possible to find a proficient JSF developer. But with different implementations, it is hard to find one that knows all about of their tricks, tips, issues and secrets.

  6. Designers and developers roles mixed
    Oracle said it has set up JDeveloper or some other inside tool with JSF support to their web designers. Now, this is cool. You teach web designers to define templates, UIs, using the Java IDE. In the end you have the view done and all JEE devs need to do is to bind, code and run.

    This is one way of doing it. But usually, it is not the case. Most companies have Web Designers working on Mac, with Photoshop and Dreamweaver or some other WYSIWYG editor. They are great designers partly because of great tools.

    With JSF, designers and developers mix their work. Designers spend their time templating. Developers spend most of their time fixing broken templates after mixing them with JSF components. Now this, ain't cool at all.

  7. Does not improve usual web development process
    Like I said before, companies are still working with a development process based on: design, template, inject dynamic code, fix design issues, release.

    That's how Java Web development works. If you disagree, please comment on that. But I've been developing web applications for almost 8 years and that's how I see it.

    All frameworks that mix dynamic code on the HTML or some layer that outputs it, doesn't improve the common web development process. Which sucks, IMO. You have Web Designers to do all the prototype. Sometimes, your company pays to a Design shop to do that. And in the end, you have business developers fixing design issues because a pixel here or there is not correctly aligned with that right border.

    Now, there are some frameworks that address this issue quite well. Tapestry is one of them, if not the first. Then there's Wicket, which of course the best practice is to componentize the UI, but it is possible to work only with the prototype. With JSF, you have Facelets. It helps a lot, and I'm sure improves *a bit*. But the development process is beyond working with pure HTMLs and prototypes.

    With JSF, the developer does a lot of SOP - String Oriented Programming. If you are not working with a great JSF-supported IDE, you will end up doing a lot of copy-paste of Strings of method names, property names and bean names.

    Some may argue that Wicket replaces JSTL with Java. It is true. But consider this: if you are working with Wicket and you've already binded your UI, you don't have to look to your HTML again. With JSF, you must look at your ManagedBean and your page to make sure everything is correctly binded. On Wicket, new properties and methods can be added without modifying the UI, and still with JSF you must edit two files to do that. It is one approach, I know. But that does not changes neither improves the development process if you compare to Struts. GWT improves that, just as Wicket, IMO.
     
  8. Non-functional prototype
    Ok, not a big deal. But it sucks a lot when your web designer changes the UI and you must merge those changes. What if you had a functional prototype you can share with your Web Designer? Some frameworks do that. Tapestr and Wicket for example. The output is HTML, your are building HTML, your designer gives you HTML, so why not take advantage of that work done on a previous stage?

  9. Performance
    Just Google for benchmarks comparing JSF with any other Java Web Framework. The lifecycle is just huge.... :-(
     
  10. Web is fast, standards are slow
    Let's take JPA for example. How old is SQL? Since 1974. Hibernate was build based on something that it was already a standard. So it was JPA. It is reasonable to have a specification for that, and totally acceptable to work with. JPA developers won't have problems dealing with different implementations, at least if they do their job right. What about XML frameworks? Mid 90's. My point is. Some specifications are build based on something with limited scope, even though generic, or on something that is already a standard and well-know by the market.

    Now let's take the Web. Although HTML is a specification, and old, it definitely has an unlimited scope. And because of its nature, it is open to innovation and creativity. How to standardize that?! HTML5 is almost there, and we are still waiting for a specification that really improves the Web Development Process. Again, JSF2 is a huge step forward, but too late, and just like to what happened with EJB, people are now afraid of it because its previous version. And that's why people started to choose Rails, Python, GWT and other frameworks.

    Long learning curve. Slow improvements (thanks to JCP). Everything the Web does not need. Everything Agile methodologies are against to.
I did work with JSF before, and I love to be a Java developer. I have my work done with it, and I'm paid because of it. But I felt like being left behind while looking at friends building cool apps, quickly and with good quality, with other languages, other platforms. And if I want to deliver solutions with performance, quality AND speed to my customers, I will think twice before choosing JSF.

Sure it has scenarios or business strategies where JSF is the best option. If there wasn't, Oracle/Sun, IBM, Red Hat and others would not put money on that. For companies that want to make sure they will easily and quickly find a developer to replace another, to keep the work on a JSF project, then, it's a business decision.

Now, from a developer perspective, I prefer to do my projects with something non-standard, while the Web is not standardized, and my customers are not worried about that.

12 novembro 2010

Errar, corrigir, committar - Sobre o JavaOne Brasil

Um programador quando encontra um erro, automaticamente, como que por instinto, sente vontade de corrigí-lo e mandar para o repositório, para ter segundos após, a sensação de um trabalho bem feito. Um orgulho de sí próprio. Às vezes, queremos fazer a mesma coisa na vida real. Com os erros do dia-a-dia, com os erros que envolvem pessoas.

Aproximadamente 3 semanas atrás, me empolguei com uma mensagem da Yara Senger, e submeti para o comitê do JavaOne Brasil, 3 palestras relacionadas à Apache Software Foundation. Soube ao mesmo tempo do The Developers Conference 2010, em Florianópolis, onde meu amigo Rodrigo Cândido, participara da organização. Não hesitei e sugeri à Wdev, cuja empresa agora faço parte, que levasse ainda mais conteúdo para este grande evento. Levamos palestras interessantes. Uma sobre Desenvolvimento para iPad, do Felipe Cypriano, e outra sobre Integração Contínua, do Marcelo Behera. Além das minhas duas palestras sobre projetos Apache (Wicket e Camel); as mesmas que havia submetido para o JavaOne Brasil.


No dia 3 de Novembro, recebi um e-mail do Sharat Chander agradecendo minhas submissões, mas que infelizmente o conteúdo não foi aprovado para o JOBra. Sem razões, sem explicações. E também disse que não é comum enviarem notificações desse tipo. Geralmente o pessoal fica no vácuo.


Ao mesmo tempo, no meio de todos estes eventos, a Oracle com seu processo contra o Google, blogs começam a dizer que a Apache copiou código para dentro do projeto Harmony. Ela esclareceu, mas não encerrou o assunto. De fato, iniciou uma guerra contra a Oracle, em defesa do Software Livre.

Por fim, no dia 8 de Novembro saiu a programação do JavaOne Brasil. Anunciada pela Fabiane Nardon. E obviamente fui conferir a grade, atrás de palestras interessantes e palestrantes a serem prestigiados. Entretanto ao ler o conteúdo, me decepcionei. Por 3 fatores:

  • (tweet, tweet, tweet) Falta de conteúdo relacionado à Apache Software Foundation
  • Conteúdos repetidos (alguns assuntos, com mais de 2 palestras)
  • (tweet, tweet) Metade dos analistas de conteúdo vão palestrar
O que mais me chateou mesmo, foi o primeiro item, e em seguinda o segundo. Com assuntos sendo apresentados mais de uma vez, não seria o caso de pensar melhor na escolha das palestras, e evitar repetição, abrindo espaço para expôr outros projetos? Considerando a Apache com principal fornecedora de projetos Open Source para a plataforma Java?

Claro que fiquei chateado por não ter sido aprovado a participar do JavaOne. Mas frente ao o que está acontecendo, constatei que, não apenas minhas palestras, mas toda e qualquer outra associada à Apache que tenha sido submetida, foi rejeitada, ao que parece, propositalmente. E isso é o que me deixou realmente chateado. E por favor alguém me corrija se eu estiver errado. Seria muito bom saber os reais motivos.

Não reconhecer a Apache, e não incentivar a comunidade brasileira a participar da ASF é ir contra o Software Livre. A falta de palestrantes e palestras entusiasmados com projetos da Apache no evento, ao que parece, é reflexo dos desejos da Oracle.

Pedido de desculpas aos palestrantes
Com toda a minha chateação, e sem refletir bem a respeito, acusei amigos injustamente. É fato que metade dos analistas de conteúdo vão palestrar. Mas como muitos outros eventos, isso é normal. Eu mesmo, por causa da minha amizade com algumas pessoas, obtive espaço no TDC2010. Não bastasse uma palestra, levei duas. E ainda abri espaço para dois outros profissionais.

Acusei amigos injustamente por algo que eu mesmo havia feito alguns dias antes.

Alguns dos analistas são amigos, outros são conhecidos. E muitos outros que irão palestrar, também são meus amigos, de empresas que trabalhei anteriormente. 

Que fique claro: todos os palestrantes selecionados merecem estar lá. Tenho certeza que a escolha foi difícil, e com critérios como +assunto, +técnica, +histórico e +mérito, os melhores palestrantes foram selecionados. Jamais disse algo contrário. 

Por fim, peço desculpas ao Bruno, com quem aprendi muito. À Yara que me incentivou muito para submeter conteúdo ao JavaOne e me deu total apoio no TDC2010. Ao Vinicius (que ironicamente retweetou meu desabafo), Paulo, Guilherme, Bruno Ghisi, Fabiane e Fabio Velloso.

Vocês são excelentes palestrantes e há muito tempo contribuem com a comunidade. Com certeza, estão no evento por mérito.

Um excelente JavaOne Brasil a todos.

Um alô para o Liaw Mike e principalmente ao Michael Nascimento, que me ajudou a enxergar o bug. :-)

23 março 2010

ApacheCon NA 2010: Como ir?

Na semana passada escrevi aqui sobre a Apache Software Foundation, uma entidade que poucos conhecem mas muitos já ouviram falar. É graças à ASF que o Apache HTTPD, e muitos outros projetos sobrevivem (wicket, camel, servicemix, activemq, tomcat, ant, maven, struts, geronimo, commons, httpclient, etc, etc, etc.)

Foi também graças à ASF que em 2008 e em 2009, tive condições de participar da ApacheCon, a mais importante conferência da ASF. Graças à ASF porque somente com o apoio (financeiro) deles, tive condições de viajar, além também da isenção da inscrição do evento que, para mortais como nós, não é barato.

O processo para conseguir esta assistência, ocorre através da Apache Travel Assistance Committee, ou Apache TAC. Este comitê existe para ajudar àqueles que gostariam de participar da Apache Conference, mas que encontram dificuldades financeiras. O TAC pode auxiliar na compra de passagens, hospedagem, transporte, alimentação e inscrição do evento.

Este ano eu não poderei ir devido a uma norma do TAC de não dar assistência ao mesmo indivíduo por três anos seguidos. Já que não posso, compartilho com vocês minha experiência para que outra pessoa possa ter esta incrível oportunidade.

Você deverá preencher um formulário, descrever seu envolvimento com a ASF, e de preferência suas contribuições a projetos Open Source. Também deverá declarar que tipo de assistência você precisa (se é somente passagem aérea, ou se precisa de hospedagem também).

Para facilitar a escolha do TAC em patrocinar a sua ida, evite pedir auxílio com hospedagem, e tente meios como o CouchSurfing.org, ou ainda ficar em albergues. Lembre-se: quanto menos você precisar, mais chances terá de receber auxílio do principal: passagem aérea. O resto você se vira. Alimentação também não é necessário já que no evento você terá isso durante todo o dia. Inclusive free beer!!

Então, se você quer ir à ApacheCon este ano em Atlanta, já sabe o que fazer. Boa sorte! E que você volte de lá com mais interesse pela ASF do que eu já tenho... :-)

21 março 2010

Wicket Brasil: mais de 600 mensagens


Em 2008, ainda trabalhando para a Summa Technologies, que conheci o framework Apache Wicket. Isso aconteceu porque meu amigo Michael Nascimento sugeriu o Wicket como possível base para um módulo web do Genesis. O módulo não saiu, mas meu interesse pelo framework só aumentou. Naquele mesmo ano, em Setembro, apresentei o Wicket à galera do JustJava, junto com o Claudio Miranda. A sala estava cheia e muita gente curiosa em conhecer o framework web mais divertido do momento. É tão divertido desenvolver com ele, que o título da palestra ficou até óbvio. Por fim, em outubro de 2008 nascia a comunidade Wicket em Português.

Após 1 ano e meio, já foram mais de 600 mensagens pelo grupo, e a cada semana recebo pelo menos um pedido de inscrição. Vejo que, assim como aconteceu com Struts em 2002, acontece agora com Wicket.

Para acelerar o crescimento dessa comunidade e difundir o conhecimento do framework a todos os desenvolvedores, deixo aqui avisado que, se você tiver um evento de Java, um JUG ou uma empresa que pretende trabalhar com Java para a Web, entre em contato e eu estarei presente para apresentar o Apache Wicket.

E que em 2010 o número de mensagens passe de mil !!

06 outubro 2009

A Opinião do Público no JustJava 09

Considerando que na sala ao lado da que eu estava, havia uma palestra hype-apelativa entitulada Design Patterns: padrões para toda a vida, até que muita gente compareceu na palestra do camelo. Se você que lê este post esteva lá, muito obrigado mesmo pela coragem! Fico muito feliz quando vejo que ainda tem gente que curte assunto novo, produtos diferentes e, porque não, fora dos padrões estipulados por organizações e empresas?

Em 2008, foram mais de 40 presentes na palestra sobre Apache Wicket. E este ano, numa sessão entitulada "Apache Camel: rotas para as suas mensagens", sem qualquer apelo ou nome de produto conhecido, 22 pessoas compareceram na sala. Se no próximo ano, ou num próximo evento, aparecerem 15 pessoas interessadas no Apache Hadoop, juro que ficarei surpreso!!

Tenho, nestes últimos 2 anos, procurado por ferramentas e tecnologias específicas, para problemas específicos, e que preferencialmente sejam independentes. Soluções financiadas pelo mercado, e não por uma única empresa. E é por esta razão, que tenho focado meu trabalho nos produtos da Apache Software Foundation. Sim, aquela do servidor HTTP. Já foram 3 palestras, 3 produtos estudados, e muitos outros que aguardam na fila:
Acredito que estes produtos possuem forte potencial tecnológico, que podem atender o mercado exigente de hoje, que demanda acima de tudo, qualidade.

ASF meets Mercado
A fundação Apache é financiada pelo mercado, em grande parte (ou... 98%) por empresas de TI, sem interesse comercial direto. O objetivo da fundação é oferecer um espaço para que produtos, ferramentas ou frameworks, totalmente Open Source e verdadeiramente livres possam ser mantidos.

Por trás de cada projeto, não há uma única empresa, mas sim um grupo de desenvolvedores. Estes sim, cada um à sua maneira, encontram uma forma de atuar no mercado com este ou aquele produto. E desta forma, cada desenvolvedor, cada contribuidor de um projeto Open Source, tem liberdade de vender o seu conhecimento e a sua experiência da forma que achar mais adequada. E sem a pressão de uma grande empresa por trás.

O que pretendo dizer com isso tudo, é que existem muitos outros produtos lá fora e que talvez esteja na hora de abandonar os clichês dos contos de fadas, como aquele onde o Chapéuzinho Vermelho caminha pela floresta em direção ao Oráculo, num dia de Sol, à vista do Gigante Azul do céu.

Feedback do JustJava 2009
O que me motivou a escrever este post, foi a visão que o público da minha recente palestra no JustJava. 79% dos presentes afirmaram que o conteúdo da palestra estava atual. Me pergunto qual foi o resultado da palestra sobre EJB3 neste quesito. Ou a de JSF. Até mesmo Agile já parece ser tema passado. Não que estes tópicos não sejam mais interessantes, mas é que... para um evento de tecnologia, me sinto no dever de mostrar o que ninguém jamais apresentou antes. Sinto que o público está cada vez mais interessado em novidades, e não em Technical Patterns.

E este feedback positivo me deixa contente, e inspirado para mais palestras. E espero retornar ao evento no próximo ano, com mais um produto da Apache.

PS: Se você conhece alguém, ou algum JUG que promoverá um evento sobre Java ou Open Source, por favor entre em contato.

[]'s
Bruno

21 setembro 2009

Camelo no GitHub também


Seguindo a sugestão do Marcos Pereira, coloquei o código do camel-twitter e principalmente, os demos que utilizei na minha palestra, lá no GitHub.

Valeu Marcos!
Contato

Email:bruno.borges(at)gmail.com

LinkedIn: www.linkedin.com/in/brunocborges
Twitter: www.twitter.com/brunoborges
Comprei e Não Vou
Rio de Janeiro, RJ Brasil
Oracle
São Paulo, SP Brasil