NetBeans 6.1 lançado

Apenas para deixar registrado que a liberação ocorreu as 7:00 desta manhã de segunda-feira. :-)





[]'s!

Assista videos ao vivo online

Neste final de semana, com a primeira partida da final do Campeonato Carioca, procurei exaustivamente (nas redondezas do meu bairro) por um bar que fosse transmitir o jogo Flamengo x Botafogo. Bem, é complicado encontrar um bar em São Paulo que esteja disposto a comprar o Premiere SporTV para um jogo carioca.

Na falta de um lugar decente para assistir, e canais na TV que transmitissem a partida, tive que buscar por uma alternativa mais... underground. Procurei por live streaming no Google e encontrei o SopCast. Foi interessante brincar com o programa no início. Mas então minha busca ficou mais interessante: encontrar um canal online que fosse transmitir o jogo da final.

Um amigo me indicou o MyP2P, mas pude encontrar no Google outros sites como o Football On Sat e principalmente (considerei o melhor) o Roja Directa. Todos estes sites não transmitem diretamente os jogos, mas apresentam a agenda de partidas e o endereço no SopCast para o live streaming.

Bem, a imagem acima mostra uma partida da NBA, que começou algumas horas depois que o jogo do Carioca já havia terminado. Foi interessante assistir o jogo pela TV Macumba, que fazia o streaming da Globo de alguma região do Brasil, que transmitia a final (como estou em São Paulo, o jogo transmitido era o da final do Paulista.)

Agora, se alguém aí em São Paulo ou em outra região do país, quiser começar a assistir partidas que não são transmitidas na sua região, vai a dica: SopCast! Tem para Windows e Linux. Como para Windows é baba fazer funcionar, passo aqui as instruções para Linux:

Pegue o programa e a biblioteca (copie para /usr/lib), e alguma URL da rede SopCast para assistir, por exemplo essa:

sop://broker1.sopcast.com:3912/6543

E execucte o comando:
$ sp-sc-auth sop://broker1.sopcast.com:3912/6543 3908 8908

Os dois últimos parametros, são portas para a conexão local. Este programa inicializará um servidor interno, que você poderá se conectar através do VLC (eu realmente prefiro ele, mas se você quiser tentar outro... à vontade.). Para isso, apenas digite:
$ vlc http://localhost:8908/tv.asf

E pronto! Live Streaming... Sports... News... Tudo o que você quiser, online, em vídeo, ao vivo! :D Agora basta achar o que quer assistir =)

Algum canal ou site de agenda de partidas/programas para sugerir? Comenta e coloque as URLs!! :D

[]'s!
Bruno

Contrate seu próximo emprego

Procurar emprego é fácil. Difícil é achar um. Quase impossível é achar o emprego ideal. Mas nao significa que nunca ocorrerá. Diariamente ouvimos de nossos colegas que estes estão bem empregados, em empresas modernas com ambientes descontraídos e preocupadas com resultados e não com normas e regras. Horários flexíveis são comuns em empresas de TI hoje em dia. Código de vestuário só é exigido àqueles que se encontrarão com clientes, e às vezes nem mesmo nestas situações. :-)

No mercado de TI realmente é difícil achar a empresa ideal para se trabalhar. Nos tempos de hoje não basta apenas calcular o básico: salário + benefícios - regras = emprego legal. É preciso mais que isso. É preciso colocar no papel tópicos que aparentemente são insignificantes, mas muito mais importantes que estes; tópicos que somente nos daremos conta com o tempo, e quando esse momento chegar, podemos ficar incrivelmente decepcionados, arrependidos, ou mantermo-nos extremamente felizes com a escolha feita.

Não é de se estranhar que as empresas às quais nos candidatamos, queiram obter o máximo de informação sobre nossos perfís. Como atuamos, nos comportamos e como seremos no dia-a-dia da empresa? Nos encaixaremos nos processos dela? Seremos capazes de nos adaptarmos às mudanças que a empresa planeja a curto prazo ou seremos capazes de suportar o conservacionismo desta empresa por anos? Perguntas que escutamos com freqüência nas entrevistas de emprego e que até então, são unilaterais. Existem casos em que até não sabemos para quem trabalharemos, por quanto tempo, e onde. Casos como grandes consultorias que fazem enormes processos seletivos sem ao menos dizer aos candidatos quem e onde é o cliente, ou como será o projeto, como será o ambiente de trabalho ou como é a equipe com quem ele deverá se integrar.

Esta falta de informação para o candidato resulta numa enorme indecisão: devo aceitar este emprego?

Dificultar a tomada de decisão do candidato não é ruim apenas para ele, mas para a empresa também, que pode, em muitos casos, perder um ótimo profissional pois foi incapaz de apresentar-lhe a rotina da empresa, de colocá-lo na cadeira e oferecer a oportunidade de experimentar um dia típico de tarefas que este deverá passar na maioria dos dias. E então, a empresa deve extender o processo seletivo, onde gastará mais tempo, mais recurso e mais dinheiro até selecionar um candidato disposto a aceitar o emprego.

A verdade é que atualmente, com a agitação do mercado de TI e a escassez de ótimos profissionais, não são as empresas quem contratam, e sim os profissionais da área que escolhem onde irão trabalhar. E se é assim que as contratações de hoje acontecem, devemos reavaliar a questão: quem é a contratante e quem é o contratado? Parece complicado esta inversão de papéis já que o dinheiro flui da contratante para a contratada. Mas pense: não é só o dinheiro que flui nesta negociação. É toda uma rotina profissional e social, uma negociação de hábitos, gostos e opiniões. É um contrato que definirá onde o profissional passará pelo menos 8 horas do seu dia. E se vermos deste ponto de vista, fica fácil concluir: o profissional está contratando um ambiente saudável para passar parte da sua vida e em troca, oferecer seu conhecimento, suas qualidades e habilidades. Ou seja, neste contrato, a contratada é a empresa, que deverá dar ao profissional este ambiente, que consiste em diversos fatores nas áreas técnicas e sociais.

Fatores técnicos como as tecnologias que utilizaremos, ou as máquinas que são oferecidas (ninguém gosta de trabalhar num computador lento, certo?), as mesas e cadeiras que passaremos horas sentados para resolver problemas solucionáveis as vezes só em sonhos. Ou mesmo as restrições de Internet que são impostas, que dificultam nosso trabalho. Parecem questões insignificantes, mas que afetam diretamente nosso trabalho e nos darão satisfação ou desejo de procura por um novo emprego. As empresas passam estas informações? Nós fazemos estas questões? Não deveríamos nos sentir envergonhados em questioná-las sobre estes fatores. Pois elas não se sentem assim ao nos questionar se gostamos ou não de trabalhar sob pressão.

Além disso, devemos ter a oportunidade de conhecer o ambiente onde trabalharemos. Não apenas o lugar, mas principalmente: as pessoas. Devemos ter a oportunidade de conhecer toda ou parte da equipe. As vezes, até mesmo outros departamentos que teremos contato direto. Devemos ter uma experiência, nem que seja minúscula se comparada com o tempo que ali passaremos. Mas importante é que tenhamos a oportunidade de vivenciar um exemplo do dia-a-dia com aquelas pessoas. Talvez, almoçar com a sua possível equipe e ali ter a chance de conhecer melhor estas pessoas e ver se haverá conflito ou convergência de idéias e opiniões. Tudo isso fortalecerá, ou abortará a nossa decisão de aceitar o emprego.

É fácil de compreender que hoje em dia, não escolhemos emprego somente pelos dígitos que são depositados em nossas contas bancárias, mas principalmente pelas experiências que temos diariamente com as pessoas que estão ao nosso redor enquanto o sol está visível (às vezes, até quando ele já se foi.)

Você costuma entrevistar a empresa que está... lhe entrevistando?
Que tipos de assuntos são colocados em questão na hora de optar por um emprego, além do usual salário+benefícios?
Quantos de vocês tiveram a oportunindade de experimentar, antes de aceitar um emprego, o dia-a-dia da empresa? E como foi esta experiência?

Comente!

[]'s!

Modularize seu projeto com Maven

Postei isso no Blog da Summa Technologies, onde ainda trabalho, mas gostaria de manter estas informações registradas no meu blog, e por esta razão duplico-o aqui... :)


Organizar um projeto em módulos não é uma má idéia. Colocar um pacote em outro projeto, gerar um jar e fazer a dependência deste num projeto maior, agregador dos módulos, realmente não é complicado (se você entendeu tudo que escrevi!). O desafio aqui está em definir um modelo de release para o projeto e automatizar este processo. O Maven permite isto de uma forma inteligente, descomplicada e organizada. O sofrimento? A documentação de como obter e implantar este processo é pobre.

Após implantarmos este processo em um de nossos projetos, optei por compartilhar aqui o desafio que atravessamos, algo que é de conhecimento aberto a todos, mas que a documentação do Maven não apresenta com clareza.

Preparação

Antes de vermos com detalhe as definições dos POMs, é importante que haja uma noção da arquitetura do Maven e como é o seu funcionamento. Vamos tomar um exemplo quase igual com o que consta na pequena documentação:

-+ myProject/
-|- pom.xml
-+- common/
-|-- pom.xml
-+-- src/
-+--- main/
-+---- java/
-+- web/
-|-- pom.xml
-+-- src/
-+--- main/
-+---- webapp/

Repare que, além do POM principal, para cada módulo existe um POM (pom.xml). No POM raiz, é onde definimos quais os módulos do projeto:

<project>
  ..
  <groupId>summatech</groupId>
  <artifactId>myProject</artifactId>
  <version>1.0-SNAPSHOT</version>
  <name>My Maven Project</name>
  <modules>
    <module>common</module>
    <module>web</module>
  </modules>
  ..
</project>

Desta forma, ao compilarmos, através do Maven, o projeto myProject, este identifica módulos que também devem ser compilados. O processo então será o de executar o mesmo Goal executado em myProject nos subseqüêntes módulos. Caso o goal chamado install seja executado, será gerado pelo Maven os jars dos projetos e ainda o war do projeto web. Temos a partir de agora, uma única chamada para compilar todos os módulos e sub-módulos (sim, é possível definir sub-módulos, mas esse tópico fica para outro post.)

Herança de Dependências Comuns

Outro ponto importante na utilização de módulos, é a possibilidade de poder-se definir no POM principal, configurações de dependências (de outros projetos - como Hibernate) comuns a todos os módulos. Para definir as dependências comuns, vamos tomar um exemplo. No POM principal, inserimos a dependência ao Hibernate assim como em qualquer outro projeto Maven:

<project>
 ..
 <name>My Maven Project</name>
 <dependencies>
   <dependency>
      <groupId>org.hibernate</groupId>
      <artifactId>hibernate</artifactId>
      <version>3.2.5.ga</version>
   </dependency>
 </dependencies>
 ..
</project>

Além das dependências, configurações de plugins e outros dados podem ser herdados; mas não entrarei em detalhes agora.

Para que os módulos herdem esta dependência do Hibernate, ainda falta um último passo: é necessário que seus POMs façam referência ao parent - ao POM principal. Tomemos por exemplo o POM do módulo common:

<project>
  <modelVersion>4.0.0</modelVersion>
  <artifactId>common</artifactId>
  <name>Common Classes for My Project</name>
  <parent>
    <groupId>summatech</groupId>
    <artifactId>myProject</artifactId>
    <version>1.0-SNAPSHOT</version>
    <relativePath>../pom.xml</relativePath>
  </parent>
  <packaging>jar</packaging>
</project>

Repare que não foi necessário incluir a tag groupId, já que este atributo será herdado do POM raiz e, afinal de contas, é um módulo e por esta razão, não faz sentido pertencer a outro grupo diferente do de myProject. Além disso, o módulo common também herdou a dependência do Hibernate automaticamente.

Este é o primeiro passo para a modularização de projetos com Maven. Em outro post, apresentarei detalhes sobre como, no módulo web haver uma dependência do módulo common, sem ter que alterar a version manualmente quando há nova versão do módulo. Em um terceiro post, apresentarei o processo para gerar uma versão do projeto modularizado através do Maven.

Até!

wfx:// is the Web we need

Think of a Web where people get into it and see it not like online documents or feels-like-desktop applications. Think a little bit more and try to see it as an environment, a living environment full of effects, animation, integration and interaction. Is this what we want? Is this what we are looking for? Hell yeah! But look how people are trying to get this and you will probably conclude that they (us, the IT crowd) are going on the wrong way.

We are not trying to simplify how to get this task, of creating this online environment, easy to done. Every time, every day, every where there is somebody inventing a new way to publish, to implement, to provide, to integrate and to interact every single service. What is going on is that we are just getting this whole thing of online software development more complicated. Is there anyone out there looking at the root of the problem? Really...

Look at where we are now, right in the middle of a technology war, trying to decide which one to pick and fight against the others. Let's first list the core technologies before listing the web frameworks: .Net, Ruby, Java and PHP. These are the main ones, I'm pretty sure of that. Another thing I know is that, in this war, from the parts involved, the least worry about which technology we use, is the customer, the final user, as long as what they want it's delivered in HTML and Javascript. Because in this Online Environment, what we must deliver is this: HTML and Javascript, no matter what technology we have used to produce it. So, let's take a look now at this war's players: GWT, Ruby on Rails, .Net, Wicket, JSF, SpringMVC, Struts, Grails, and the new ones, Silverlight, Flex, JavaFX. Except the last three, all others have only one purpose: deliver HTML and Javascript. The difference between them is how this is done, how is developed.

I know this is a little bit confusing but now I will try to explain to you where I wanna get.

First, let me tell you something about these web frameworks that deliver HTML and Javascript: you will survive... for 5 to 10 years. Period. Your technology is old, dumb and slow. Yeah, you heard me: it's old. You have to be replaced with other options! The problem with HTML and Javascript is that we don't have other option so we are always trying to find an easy way to generate them and this is the root of the problem of so many frameworks living out there! And so many others being created! To evolve to a new Web we really have to forget about these two technologies. If you agree with me, follow to the next part: RIA technologies.

Yeah, the Internet is getting smarter. Now we develop online software with RIA frameworks. Looks like we have replaced "Web Frameworks" with "RIA Frameworks". This is good! Believe me. Now, instead of 3721863 options of web frameworks, there's only three options of RIA frameworks: Silverlight, Flex and JavaFX (does anybody know any other? please comment!). This reduction of options is good because if you know Java, go for JavaFX. If you prefer .Net, Silverlight is the answer and for old guys (Flash is out there for quite a while) Flex it!

Still, where is the root of the problem? RIA solves our problems? Can we develop online software quicker? Most important: can we deliver quicker? Let's put this in other words: can we satisfy our customer's needs quicker? Because this is what is really important for the reasons we have used to chose between this or that technology.

For this new war, the RIA war, I want to tell you another thing: if Silverlight really does not run (I mean for real, without cheats) cross-platform, it will stay out of this war soon or later. And to stay in the game, it must run everywhere: Windows, Linux, Solaris, BSD, OSX, etc.

Ok, let's think about the other two players: JavaFX and Flex. Which one has more chances to be the king of Web? I would put this way: Flex is going to be the prince and JavaFX its young brother (because for now, the kingdom is split between HTML and JS.) I'm sure that Flex will be the king in the short time. But with time JavaFX will grow up and become the Web King. And I'm not telling you this because I work with Java, but because I truly believe that JavaFX's proposal is better than Flex's, technically speaking of course; and this is because I believe the answer for a quicker delivery of customer's needs is in how we develop their problem's solutions.

You see, Flex has few disadvantagens over JavaFX: it is not that cross-platform. It relies over Flash, which is proprietary software. You have to know MXML and ActionScript, plus Java of course (for real applications).

Until I continue, I want to share with you something I have been thinking about for a couple of months: the best way for an easy development software process (logicaly giving you fast delivery) is to have the least amount of software languages and technologies as possible. This is why that I chose Wicket (pure HTML and pure Java) for my online softwares; this option gives me only two languages: HTML and Java, but just for now (remember, I told you that I believe in a Web without HTML... it will have its legacy, but is going to be over soon) while there's no better option of other online environment except the browser.

Now, if you followed me till here, first: thank you. If you understand what I'm talking about: thank you again. But to finish, I have to introduce you to the new Web, a web of effects, of quicker interaction, integration, animation and delivery. I give you the WebFX. It's the combination of only two languages... Yeah, I realized that it's impossible to have only one language; you have to separate logical code from the interface. One language for each side. Continuing... the combination of two languages with a new environment: the WebFX.

What is that? A new protocol, new way of delivering applications, RIFA is how I call the applications of WebFX. Rich Internet FX Applications. Web Browsers, HTTP, HTML and Javascript, we really want to evolve! And this is not possible if we continue to harp on. All these Web Frameworks, and now RIA, they just want to deliver you the same stuff, in a different form. For RIA applications, is just like desktop applications with remote connectivity. For Web Frameworks, is just HTML and Javascript.

Here we are... RIFA and WebFX. Applications and its environment. How would this be possible? Well, let's consider JavaFX for instance as the best option to implement this whole thing (this is my idea of how to implement this, technically speaking):

The customer installs a JWE (Java WebFX Environment), which comes with a JRE (of course) and a WebFX Browser (implemented in Java... of course!!). Then he/she opens the browser and types an URL:

wfx://ebay.com

What happens? The WebFX Server delivers the user a JavaFX file which represents a RIFA. This RIFA loads in a tab, over the same JVM, as an inner application (Sun, really... it's time to implement JSR 121 and give life back to Project Barcelona).

So, you have a Java application running in a Browser Tab. No back button, no Ajax cheats nor any other language except Java and JavaFX sintax. But wait, what if the customer asks the developer team to replace the application with a new interface? Well, change the application.fx file! Of course this can be implemented in any other technology, but what other technology is so cross-platform and open source as Java is?

Yeah, there are still some details to discuss about this whole new environment. But, this is now up to you. Comment, give some ideas. But I ask you: let's evolve this e-echo-system. Let's drop down old technologies.

Thank you for your attention... :-)