terça-feira, 29 de novembro de 2016

Linguagens de Programação mais Utilizadas da Atualidade

Senhores boa tarde! Sim sim, eu voltei (depois de uma temporada pela Europa 👸). Agora estou de volta e com a corda toda! Muitas pessoas tem me perguntado "Bruno qual a linguagem de programação do mercado? Sim quero me formar e saber que terei emprego para a linguagem que aprendi.".

Bem esta pergunta tem-me sido recorrente, desta forma fiz umas pesquisas na internet sobre o assunto e venho com alguns resultados interessantes e significativos. Vamos lá!

Confira o estudo realizado pelo TIOBE Software que revela quais são as linguagens de programação mais preferidas dos programadores
O site TIOBE é um grande site de estudos de informações na internet e o mesmo é atualizado mensalmente com base no número de engenheiros qualificados ao redor do mundo, cursos especializados e fornecedores. Os populares mecanismos de buscas, como Google, Bing e Yahoo!, também são utilizados para calcular as classificações. O índice não determina quais são as melhores ou as piores linguagens, somente exibe quais são mais comuns atualmente.
Veja a tabela :


Veja também um gráfico que mostra o ranking das linguagens ao longo do tempo :


Após a análise do mês de Fevereiro de 2015~2016 ficou claramente que o destaque se deve à linguagem Python que ganhou muitas posições e está entrando agora no top 5!

Enquanto a linguagem  J.A.V.A OCUPA A PRIMEIRA POSIÇÃO.

Com estes resultados espero que tenha ficado claro, sim senhores isso mesmo, java ainda é top de mercado e aprender esta linguagem certamente lhe deixara acima de tudo, sempre com oportunidades de emprego!

Até a próxima senhores e prometo que não sumirei por tanto tempo da próxima vez 😎😎😎😎😎😎

Bruno Rafael...

quarta-feira, 3 de agosto de 2016

Especialista ou Generalista? Eis a questão.



Salve, salve galera! Eis aqui eu com um post, sobre um assunto bastante interessante e genérico. Qual a melhor escolha a se fazer? Ser um profissional especialista em uma área, ou um profissional que sabe de tudo um pouco? Esclarecerei algumas coisas neste post. Vamos lá!

Qual tipo de profissional tem mais chances de atrair um recrutador: um profundo conhecedor de uma área bastante específica ou um “pau para toda obra” com perfil generalista e versátil?
Um estudo conduzido por pesquisadores da Columbia Business School e da Tulane University dá uma resposta categórica à velha dúvida. “Os especialistas são definitivamente castigados pelo mercado”, diz uma das responsáveis pela pesquisa ao Harvard Business Review. “Além de receberem menos ofertas de emprego, eles ganham bônus menores”.
Para chegar ao resultado, os estudiosos acompanharam cerca de 400 estudantes que se formaram nos melhores MBAs dos Estados Unidos entre 2008 e 2009 e seguiram carreira em bancos de investimento.
A amostra foi dividida em dois. O grupo dos especialistas era formado por pessoas que já trabalhavam com investimentos antes do MBA, fizeram estágio na área e se aprofundaram em finanças.
Já a turma dos generalistas consistia naqueles que atuaram em outras áreas antes do curso, como publicidade, fizeram estágio em uma consultoria e só mais tarde foram para o mundo dos investimentos.
Resultado: os bônus recebidos pelos especialistas eram até 36% mais baixos do que os de seus colegas generalistas. Em alguns casos, o primeiro grupo ganhava até 48 mil dólares a menos por ano.
Mas por quê?
Segundo Jennifer Merluzzi, professora na Tulane University e coautora do estudo, o problema está na oferta excessiva de programas de especialização, em especial de MBAs.
Outro estudo, lançado recentemente pela firma de inteligência de mercado IDC em parceria com a Microsoft, vai na mesma direção.


“Os cursos dão uma forte ênfase à formação de uma pessoa de finanças ou uma pessoa de marketing, o que produz muitos profissionais parecidos no mercado”, diz ela ao HBR.
Ironicamente, o especialista vira “commodity”: como há muitas pessoas com foco exclusivo em uma área no mercado, aqueles que trazem um repertório mais amplo e eclético saltam aos olhos das empresas.
Merluzzi afirma que recrutadores ouvidos pelo estudo não esconderam sua preferência pelos generalistas. Profissionais com experiências e competências diversas são mais interessantes do que aqueles que só conhecem um ângulo do trabalho, disseram eles.
É claro que, em algumas áreas, ser especialista é uma enorme vantagem competitiva. “Se alguém precisa de um cirurgião para uma operação arriscada, por exemplo, é óbvio que vai querer um expert que já fez isso centenas de vezes”, diz a professora. “No mundo dos negócios, porém, a especialização não é tão benéfica”.
No futuro, diz Merluzzi, os generalistas continuarão a ter mais chances nas empresas porque têm habilidades diversas, podem ser transferidos para outras áreas e tendem a assumir posições de liderança mais rapidamente.
Generalista, não “superficialista”
Conduzida nos Estados Unidos, a pesquisa analisou mais de 76 milhões de vagas de emprego para selecionar aquelas que teriam maiores salários e melhores condições de ascensão profissional entre 2016 e 2014.
A conclusão é a de que as oportunidades mais promissoras exigem competências multifuncionais (“cross-functional”, no original em inglês), em detrimento de habilidades técnicas ou específicas — e isso em áreas tão diversas quanto TI, direito e saúde.
Segundo Pietro Delai, gerente de pesquisa da IDC Brasil, os requisitos dos melhores empregos incluem excelente comunicação oral e escrita, capacidade de filtrar e processar múltiplas fontes de informação e pensamento lógico aplicado à análise de probabilidades.
“As habilidades exigidas pelos melhores empregos trespassam diversas ocupações (...). Por outro lado, competências específicas são menos aplicáveis e deveriam receber menos ênfase no currículo das escolas”, aponta o estudo.
Isso não significa que a profundidade seja dispensável. “O tipo de generalista que se dá bem não é o ‘superficialista’”, diz Delai. “Ele precisa ter a capacidade de se debruçar sobre um problema, ir a fundo na investigação de hipóteses e buscar pessoas que ajudem a resolver aquela questão, inclusive especialistas”.
Profissionais com habilidades multifuncionais, aplicáveis a uma vasta gama de situações, também são candidatos naturais à liderança.
“O que vemos na crise é que muitas empresas demitem os especialistas, contratam terceiros para substituí-los e colocam um generalista para administrar os fornecedores”, afirma Delai. "Elas preferem entregar o comando a quem tem uma visão sistêmica e multidisciplinar".
Espero que tenham gostado, e em breve teremos posts novos. Obrigado e voltem sempre!
De seu amigo Bruno Rafael.

terça-feira, 19 de julho de 2016

JSF com CDI, quais anotações devo usar?


Salve! Salve. Eu sei que estou sumido mas acontece :p. Estava lendo um artigo muito bom sobre estes dois tipos de anotações e vamos ver quais as melhores formas de se trabalhar com JSF e CDI.
On Based in @TiadWorks. 
Com o lançamento do JSF 2 se tornou possível eliminar a necessidade de configurar managed beans e regras de navegação em seu arquivo XML, o tal do faces-config.xml. Não só isso, além de trabalharmos com anotações nós ainda diminuímos o número de detalhes de configuração devido as novas convenções do framework. Essas mudanças fizeram com que o micro container IoC/DI do JSF ficasse ainda mais conhecido do que na sua versão anterior, como podemos ver a seguir:
@ManagedBean
public class AlunosBean {

    @ManagedProperty("#{alunosDao}")
    private AlunosDao dao;

}
No código acima, por termos anotado a classe AlunosBean com as anotações do JSF ela passou a ser instanciada e gerenciada pelo seu micro container. Além disso a classe AlunosDao também está sendo injetada no managed bean pelo JSF. Mas quem está gerenciando a classe AlunosDao?
Embora não seja muito comum, podemos deixar o JSF gerenciar outras classes que não os managed beans, como DAOs, Services etc. Se olharmos mais de perto o código da AlunosDao veremos ela anotada com as anotações do JSF:
@ManagedBean
@ApplicationScoped
public class AlunosDao {

    // ...
}
Utilizar o próprio JSF para fazer injeção de dependências é muito melhor do que instanciar todas nossas classes manualmente. Isso permite termos classes menos acopladas e um design mais favorável para testes de unidade.
Mas uma aplicação Web não vive somente com o JSF, não é?

Integrando JSF com outros frameworks

Numa aplicação Web o JSF cuida apenas da camada de apresentação, enquanto para camada de persistência é muito comum o uso da JPA com Hibernate. Integrar estes dois frameworks não é uma tarefa tão fácil assim quando se trata de aplicações de médio-grande porte, pois acabamos com muito código duplicado e de difícil manutenção. Por esse motivo a maioria das aplicações usam algum framework especializado em injeção de dependência (IoC/DI) para fazer a ponte entre eles, como CDI ou Spring.
Ao adotar o CDI no projeto é muito tentador sair anotando as classes do nosso modelo como DAOs, Services, validadores etc para logo em seguida injetá-las nos managed beans do JSF através da anotação @Inject do CDI , como no código a seguir:
@ManagedBean
public class AlunosBean {

    @Inject
    private AlunosDao dao;

}
Em TEORIA a anotação @Inject do CDI funciona em "qualquer lugar", inclusive nos managed beans gerenciados pelo JSF. O problema é que isso ainda é muito falho na PRÁTICA já que depende do servidor de aplicação e implementação CDI que estivermos trabalhando, como JBoss Weld ouApache OpenWebBeans.
Há relatos em fóruns e listas de discussão onde ora a injeção funciona em um Wildfly e Glassfish, ora quebra num Tomcat 7 e Jetty. O problema se agrava quando misturamos escopos existentes somente no CDI como @Dependent com managed beans anotados pelo JSF.
Para você ter idéia, eu tive exatamente este problema algumas semanas atrás...
Ao customizar o nosso curso de Persistência com JPA 2 para trabalhar com CDI eu quebrei a cabeça por algumas horas com isso. O container do JSF se perdeu com relação aos escopos ao processar uma EL na página. Em vez de injetar o bean do CDI ele estava injetando null no managed bean gerenciado pelo JSF e algumas vezes registrava o managed bean em um escopo diferente.
A coisa estava tão feia pro meu lado que fui pedir ajuda a amigos que sacam mais de CDI do que eu, como o Raphael Lacerda e Daniel Cunha. Daí não deu outra: eles me ajudaram a perceber quemisturar as anotações NÃO era uma boa prática.
Mas de quem é a culpa? O problema está na implementação do CDI ou no servidor de aplicação?
A verdade é que estamos trabalhando com 2 containers de IoC/DI ao mesmo tempo, que tem escopos e ciclo de vida similares na teoria mas com implementações completamente diferentes na prática. Neste momento, o ideal é decidir qual deles instanciará e gerenciará seus objetos daqui para frente...

Qual usar: CDI ou JSF?

Nós já havíamos comentado em um post anterior que as anotações do JSF começaram a serdepreciadas e, em futuras versões da Java EE, recomenda-se utilizar apenas as anotações do CDI.
Esse tipo de recomendação não é feita à toa, pois o micro-container do JSF possui diversas limitações e resolve apenas o propósito do framework e de seus componentes. Ele se limita a camada de apresentação, enquanto o CDI vai mais longe...
O modelo de componentes do CDI é muito, mas muito superior ao container do JSF. Ele vai além da injeção de dependência, ele resolve de maneira elegante o gerenciamento de escopos e configuração de interceptadores dentro da aplicação; também possui um barramento de eventos simples e eficiente; fora isso podemos criar extensões para plugar em seu container.
O expert group se esforçou no JSF 2.2 e está se esforçando ainda mais no JSF 2.3 para melhorar e estender a integração com o CDI. Dessa forma, nós poderemos trabalhar melhor em cima das anotações do CDI e sem perceber iremos abandonando as anotações do JSF. Isso está ocorrendo com os novos escoposnavegação entre páginasinjeção em conversores e validadores e até na forma como injetamos objetos do contexto do JSF.
A tendência é o CDI se tornar a principal tecnologia para gerenciar objetos na plataforma Java EE, onde praticamente TUDO será gerenciado por seu container e com o tempo substituirá outras especificações que também possuem um container, como EJB e JSF. Dessa forma, teremos uma melhor integração com toda stack Java EE. No fim, todos os objetos no seu servidor de aplicação serão CDI beans...
Por todos estes motivos, se o CDI foi adotado no seu projeto então nada mais sensato do que deixar o próprio CDI gerenciar todos os objetos - inclusive os managed beans - através de suas anotações.
Mais como migrar os managed beans para CDI?

Migrando beans do JSF para CDI

Migrar os beans anotados do JSF para CDI é uma tarefa extremamente simples. Basicamente teremos que substituir algumas anotações...
Pegando o managed bean anterior como exemplo, poderíamos migrá-lo facilmente para um bean do CDI com algumas poucas linhas de código:
@Named
@RequestScoped // javax.enterprise.context.RequestScoped
public class AlunosBean {

    @Inject
    private AlunosDao dao;

}
O que precisamos fazer são 3 coisas:
  • Substituir a anotação @ManagedBean("xxx") por @Named("xxx"), dessa forma conseguimos acessar os objetos via EL (Expression Language) na páginas;
  • Mudar as anotações de escopos por anotações equivalentes no CDI. De maneira simples precisamos alterar somente os pacotes: de javax.faces.bean.* para javax.enterprise.context.*; A exceção é a anotação @ViewScoped que está no pacote javax.faces.view;
  • Substituir a anotação @ManagedProperty por @Inject;
Bem simples, não é?
Continuando no ritmo de migrar as classes para CDI, a classe AlunosDao também sofreria algumas mudanças, como abaixo:
@ApplicationScoped // javax.enterprise.context.ApplicationScoped
public class AlunosDao {

}
Se você estiver trabalhando com CDI 1.1 você nem mesmo precisaria anotar a classe AlunosDaopois por padrão todas as classes na sua aplicação podem ser injetadas pelo CDI sem que você precise anotá-las.

Favoreça o CDI... ou Spring

Embora a especificação do CDI nos permita misturar as anotações do CDI com as anotações JSF, vimos que isso não acaba muito bem. São problemas difíceis de prever e resolver, por esse motivo e muitos outros, de acordo com o Gavin King (líder da especificação CDI), devemos evitar tal prática.
Favoreça o container mais completo e robusto no seu projeto, que normalmente é o CDI ou Spring. Ambos estão passando por constantes melhorias e correções, enquanto os demais containers estão "ficando para trás".
O que tenho observado é que qualquer novidade oriunda de novos frameworks auxiliares e extensões serão dirigidas exclusivamente para o CDI e não mais o JSF. Um bom exemplo são os escopos de conversação auxiliares do DeltaSpike. Embora eles existam para resolver problemas pertinentes ao JSF eles são implementados em cima do CDI.
Enfim, quanto mais tempo postergamos essa migração para CDI ou Spring mais difícil fica. Adotar uma tecnologia para IoC/DI em um novo projeto é uma decisão importante que normalmente dificulta o início do projeto, mas que traz ganhos de produtividade a médio-longo prazo, pois qualquer modificação torna-se barata. Levamos isso tão a sério que nossos cursos mais avançados possuem capítulos tratando do assunto.
Bem senhores é isso, vou vazando por quê é julho! Fui!

sábado, 30 de abril de 2016

Entenda o Unity 3D e inicie os trabalhos com jogos

Fala galera! Eu sei, eu sei, estou sumido e bla bla...Mas como sempre dizem que quem é vivo aparece, demorei mais voltei :p. Vim com um assunto que achei bastante oportuno e sei que muitas pessoas tem interesse em começar, que é trabalhar com desenvolvimento de jogos.

Muitos de vocês podem não saber, mas antes de existirem essas engines de hoje e de criarem o termo "gamefication" sempre trabalhei com aplicações voltadas para jogos com foco educacional (antes do novo termo se chamavam "aplicação lúdica da informatica na educação").

Cheguei a desenvolver vários jogos com este foco (ainda hoje o faço) e o melhor, consegui ganhar dinheiro com isso :). Ganhei um prêmio na Infobrasil de melhor software educacional, assim como já tive clientes voltados para jogos. Neste contexto, venho lhes informar que não é impossível e sim podemos ganhar dinheiro. Vamos lá, vou falar um pouco de Unity 3D.


Unity é um software que foi criado para simplificar o desenvolvimento de jogos eletrônicos. Também conhecido como Unity 3D essa ferramenta possui a versão Pro e a gratúita, ambas disponíveis no site da Unity Technologies. Até o momento, a versão gratúita disponível para download é a 4.3.4. No início o Unity dava suporte apenas para jogos 3D, porém a partir dessa nova versão há o suporte para jogos 2D.
Esse game engine foi elaborado para a plataforma Windows e Mac OS X  e inclui suporte para publicação para iOS, Android, Windows Store, Windows Phone, BlackBerry, desktop e Web. 
O Unity suporta três linguagens de programação nativa:
  • C # (pronuncia-se C-sharp), uma linguagem padrão da indústria, semelhante ao Java ou C++;
  • UnityScript, uma linguagem projetada especificamente para uso com o Unity e modelado após JavaScript;
  • Boo, uma linguagem. NET com sintaxe semelhante ao Python.


Na Unity, você pode pensar em Scenes como levels individuais. Construindo seu jogo com muitos cenas, você poderá distribuir o tempo de loading e testar seu jogo individualmente.

- Hierarchy: É onde fica os objetos, cenários, luzes etc na Scene. Vocês podem notar que só exite uma câmera na Scene e seu nome "Main Camera" está na Hierarchy.

- Inspector: Onde fica todas as informações do elemento na Hierarchy, como posição, escalonamento, rotação etc... Caso a "Main Camera" tivesse sido selecionada iria aparecer todas as informações da câmera.

- Project: É onde fica todas as pastas do projeto, elas não estão na Scene, mas é com elas que adicionamos elementos na mesma, ou seja, se você tiver uma casa em uma das pastas do seu projeto, basta clicar e arrastar até a Scene que irá adiciona-la.

http://www.tresd1.com.br/tutoriais/tutoriais-variados/outros-softs-3d/tutorial-basico-unity3d

Material

Materiais servem para definir a aparência de um modelo após renderizados. Materiais são cores ou texturas, que em conjunto com um script de renderização, determina a aparência de um objeto quando visualizado na tela.

Rigidbody

Permite que seus GameObjects possam agir sob o controle do motor de física. Isso abre a porta de entrada para as colisões realistas, variados tipos de articulações, e outros comportamentos muito legal. Qualquer GameObject deve conter um Rigidbody a ser influenciada pela gravidade, que agem sob forças adicionados via script, ou interação com outros objetos através do motor de física.

Rigidbody deve ser explicitamente adicionado ao seu GameObject antes que eles serão afetados pelo motor de física. Pode-se adicionar um Rigidbody ao seu objeto selecionado a partir de Componentes-> Física-> Rigidbody na barra de menus. Agora, o objeto é a física e pronto, pode-se colocar gravidade e pode receber forças através de script, mas poderá ser preciso adicionar uma Collider para poder colocar comportamento como desejado e de acordo com o jogo. 

http://docs.unity3d.com/Documentation/Components/class-Rigidbody.html

GameObject  

A Unity3D é baseada em um modelo mais moderno para a arquitetura de objetos de jogo baseado em composição [Bilas 2002, Stoy 2006, Passos et al. 2008]. Nesse modelo, um objeto de jogo é especificado através da composição de várias funcionalidades, que são agregadas (ou removidas). Cada funcionalidade é implementada por um componente (classe que herda de um componente básico). Esse container genérico ainda é denominado Game Object e funciona como um repositório de funcionalidades, ou mais especificamente, componentes. Os componentes são então responsáveis por implementar os diversos comportamentos que um Game Object pode ter. Um componente pode ser desde um script, uma geometria de colisão, ou até uma textura de GUI. Ou seja, Game Objects podem representar qualquer coisa no cenário, sendo caracterizados como uma simples câmera ou um personagem apenas pelos diferentes componentes que agrega. “Game Object é uma panela vazia e os componentes são os ingredientes que irão criar sua receita de jogabilidade”. Uma observação importante sobre os Game Objects é que todos eles já possuem pelo menos o componente Transform, responsável pelo seu posicionamento, orientação e escala no sistema referencial da cena. Além disso, esse componente é responsável pela definição da hierarquia de transformações, permitindo o efeito de transformação relativa de acordo com a estrutura de ascendência/descendência de cada Game Object.

Hinge
 Joint 

Permite 
a 
conexão 
de 
dois 
objetos 
através 
da 
simulação 
de 
uma 
dobradiça. 
Ideal

para 
a
 simulação
 de
 portas, 
pêndulos 
e 
outros 
objetos 
que 
necessitem
 deste 
tipo 
de 
conexão. Colocar o exemplo de código que faz a união da cabeça com a cauda do snake.

Detetar colisões entre objetos é uma prática fundamental para (quase) todo jogo eletrônico.
Além de detetar as colisões, é importante saber o que fazer, depois que elas ocorrem.
As game engines, sempre possuem recursos para a deteção de colisões, e esse é um tópico muito importante de ser observado, antes de escolher qual game engine utilizar para seu projeto.
Em linhas gerais, os pontos básicos a serem observados são:
- como se configura a deteção de colisão;
- quais geometrias de colisão (esferas, cubos, planos …) são disponibilizados pela engine;
- Se a game engine, permite deteção de colisão com geometria 3D (mesh).

Quando as colisões são detetadas, em geral, eventos são disparados pelo sistema. E esses eventos, podem ser capturados por objetos de jogo; que iniciam funções, para gerar a dinâmica do jogo.
http://paulobarbeiro.com.br/blog/?tag=tutorial-2

O Console mostra mensagens de erros, warnings e textos de debug. Você enviar suas próprias mensagens para o console utilizando Debug.Log() ou Debug.Error() em seus código.
Se você der um clique duplo na barra de status ou escolhendo Barra de Ferramentas->Window->Console, aparecerá o Console.

Câmera (Visão do Jogo) 

A visão de jogo é renderizada através da câmera dentro do jogo. Ela representa como seu jogo ficará quando for publicado. Câmeras em jogos servem para representar o comportamento dos olhos em um sistema em três dimensões. Através dela são determinados quais objetos devem aparecer na tela e como eles devem ser mostrados.

Exemplos de Jogos prontos...play store do unity :




Meu jogo no Unity :p:


Se gostaram, deixem seu joinha e se for de interesse, solicitem novos post sobre que posso começar a ensinar a vocês os primeiros passos e assim ganhar meu percentual :p Abraço galera!

Videos que ensinam no desenvolvimento do jogo.

quinta-feira, 17 de março de 2016

Node.Js - Conhecendo, utilizando e indo à prática



Salve, salve galera!
Thuru, thuru...thuru, thuru.....

Estamos aqui mais uma vez para tentar compartilhar um pouco de conhecimento com vocês. Estes dias estava lendo um pouco sobre o tão falado Node.Js. Ao adentrar um pouco mais sobre o assunto, cheguei a conclusão que é em outras palavras (ao meu ver é claro) uma coisa fantástica! Hoje no mundo das tais APIs, é nada mais nada menos uma ferramenta crucial e facilitadora na hora de implementarmos nossas aplicações.

Vamos lá!

O QUE É NODE.JS


Node.js é uma plataforma para desenvolvimento de aplicações server-side baseadas em rede utilizando JavaScript e o V8 JavaScript Engine, ou seja, com Node.js podemos criar uma variedade de aplicações Web utilizando apenas código em JavaScript.


Em uma primeira análise essa informação pode não parecer tão interessante, uma vez que existem diversas outras maneiras em que esses tipos de serviços podem ser implementados. Mas se pensarmos um pouco mais sobre as demandas de aplicações na internet e o modo em que o código em JavaScript pode ser estruturado, vamos nos deparar com uma gama de novas possibilidades para desenvolvimento Web, e provavelmente nos juntar à crescente comunidade que tem adotado essa plataforma.

Por ser esta tal plataforma de desenvolvimento de aplicações server, o mesmo nos permite criar uma série de variações de aplicações para quaisquer tipos de dispositivos de forma ágil, simples e fácil.

Embora Node.js tenha muito em comum com os servidores tradicionais como Apache e IIS, podemos entender melhor essa relação se considerarmos as diferenças. Node.js é extremamente simples, por isso pode não ser a solução ideal para todos os casos. Enquanto os servidores tradicionais são mais robustos e preparados para situações mais complexas, e isso invariavelmente vai consumir mais recursos das máquinas do que Node.js.
Outra importante diferença está no fato do Node ser single threaded. Embora isso possa parecer uma desvantagem em um primeiro momento, o que percebemos ao desenvolver comNode.js é que isso simplifica extremamente a construção da aplicação, e por Node.js utilizar uma abordagem não obstrutiva, essa diferença vai ser imperceptível na maioria dos casos.

V8 JAVASCRIPT ENGINE

É o interpretador de JavaScript open source implementado pelo Google em C++ e utilizado pelo Chrome. O que sem dúvidas gera uma grande expectativa em relação ao desempenho do Node.js.

INSTALANDO O NODE.JS

A instalação do Node.js é extremamente simples graças ao fato de o V8 JavaScript Engine ser completamente multi-plataforma, tudo que você precisa fazer é visitar a página oficial do Node.js, clicar em “INSTALL” e seguir as instruções.
img node 2
Após a instalação, basta executar o seguinte comando no seu terminal para verificar se foi instalado corretamente:
  1. $ node -v
  2. > v0.10.26
deve retornar a versão do node que foi instalada, como por exemplo v0.10.26.

O WEB SERVER ‘OLÁ MUNDO!’

Ok, então vamos construir alguma coisa.
Nosso primeiro exemplo é um servidor que retorna a string ‘Olá mundo’ para qualquer requisição. Para fazer isso utilizando Node você vai precisar de criar um arquivo JavaScript que pode ser chamado olanode.js e de três minutos do seu tempo.
Escreva o seguinte código no seu arquivo:
  1. var http = require('http');
  2. http.createServer(function(req,res) {
  3. res.writeHead(200, { 'Content-Type': 'text/plain; charset=utf-8' });
  4. res.end('Olá mundo!');
  5. }).listen(3000);
  6. console.log('Servidor iniciado em localhost:3000. Ctrl+C para encerrar…');
Para executar o seu programa Node basta o seguinte comando no seu terminal:
  1. $ node olanode.js
Para testar seu servidor você pode acessar localhost:3000 no seu navegador ou utilizar linha de comando com o comando curl (em uma nova instância do terminal) como mostrado a seguir:
  1. $ curl http://0.0.0.0:3000/
  2. > Olá mundo!
Caso você prefira retornar algum html válido para o navegador, basta alterar 'text/plain'para 'text/html' no código acima e utilizar uma tag html legal como <h2>, como foi feito a seguir:
  1. var http = require('http');
  2.  
  3. http.createServer(function(req,res) {
  4. res.writeHead(200, { 'Content-Type': 'text/html; charset=utf-8' });
  5. res.end('<h2> Olá mundo! </h2>');
  6. }).listen(3000);
  7.  
  8. console.log('Servidor iniciado em localhost:3000. Ctrl+C para encerrar…’);
img node 1
Agora basta voltar ao seu navegador e ver o resultado.

ORIENTADO A EVENTOS E NÃO OBSTRUTIVO

ORIENTADO A EVENTOS

Vamos aproveitar este momento de euforia após a construção do seu primeiro servidor para aprender um pouco mais sobre Node.js.
Quando estamos desenvolvendo com Node.js devemos utilizar uma abordagem orientada a eventos, isso quer dizer que o desenvolvedor precisa conhecer os eventos que serão emitidos em diferentes momentos da execução e também saber como ouvi-los para executar as operações necessárias.
Um bom exemplo de orientação a eventos está na construção de interfaces de usuário. Muitas vezes utilizamos elementos como por exemplo os botões que ao serem clicados emitem um evento do tipo click ao qual podemos ouvir e executar alguma operação.
No nosso exemplo anterior utilizamos esse conceito quando chamamos método listen do objeto do tipo web server e passamos como parâmetro a porta 3000, com isso fizemos que a nossa aplicação ouvisse ao evento que é emitido sempre que alguém faz uma requisição nolocalhost:3000 e a nossa resposta foi servir a string ou a página html. Este evento é chamadorequest.
Para ilustrar estes conceitos, podemos escrever o nosso exemplo anterior em uma sintaxe alternativa da seguinte forma:
  1. var http = require('http');
  2.  
  3. var server = http.createServer();
  4.  
  5. server.on('request', function(req,res) {
  6. res.writeHead(200, { 'Content-Type': 'text/html; charset=utf-8' });
  7. res.end('<h2> Olá mundo! </h2>');
  8. });
  9.  
  10. server.listen(3000);
  11.  
  12. console.log('Servidor iniciado em localhost:3000. Ctrl+C para encerrar…’);
Dessa forma podemos ver claramente a maneira em que o Node.js opera para servir a sua página. Utilizamos o método on do nosso objeto server para ouvir ao evento request e fazer as operações. E definimos que estamos servindo na porta 3000.

NÃO OBSTRUTIVO

Todos os recursos presentes no Node.js e também a maioria das bibliotecas feitas para ele adotaram um padrão não obstrutivo de escrever código, isso quer dizer que em Node.js você geralmente vai conseguir estruturar seu código de uma maneira que operações que não dependem de nada que está sendo executado possam ser executadas de forma independente.
Para mostrar um pouco como isso funciona, vamos um programa que escreve duas frases no terminal, porém uma dessas frases precisa ser carregada da memória antes de ser impressa.
  1. var frase;
  2.  
  3. carregaFrase = function (callback) {
  4. setTimeout(function() {
  5. //Simula leitura da frase no banco de dados.
  6. frase = "Minha frase obstrutiva";
  7. callback();
  8. }, 3000)
  9. }
  10.  
  11. imprimeFrase = function () {
  12. console.log(frase);
  13. }
  14.  
  15. carregaFrase(imprimeFrase);
  16.  
  17. console.log(“Olá");
Nesse exemplo foi criada uma função chamada carregaFrase cujo objetivo é ler uma determinada frase de uma fonte de dados, e uma outra função chamada imprimeFrase que imprime o valor de uma determinada variável no console. Como dependemos da leitura da frase na fonte de dados para imprimir o valor, passamos a função que imprime como parâmetro para a função de leitura para que possamos executar essa função quando a leitura for concluída. Esse tipo de função que é passada como parâmetro dessa maneira é chamada decallback.
Ao executar este exemplo com Node.js ou qualquer mecanismo JavaScript você vai perceber que a frase “Olá” será impressa antes da outra frase mesmo estando posicionada depois no código, isso se deve ao fato de sua execução não depender de nada enquanto a execução da outra frase depende de uma operação que leva 3 segundos.
Este é um exemplo extremamente simples de como criar um código não obstrutivo, portanto use sua imaginação para imaginar cenários em que isso pode ser útil.
Observe que no nosso primeiro exemplo com Node.js tanto a função on quanto a funçãocreateServer podem receber uma função de callback.

CONCLUSÃO

Espero que este tutorial tenha sido o suficiente para provocar o seu interesse em aprender mais sobre Node.js. Portanto visite a documentação do Node.js para obter mais informações e exemplos de aplicações dessa plataforma e também a página da Joyent, patrocinadora oficial do projeto.
E finalmente, Node.js é um projeto open source, portanto você pode visualizar o código fonte e contribuir no repositório do Node.js no GitHub. Até a próxima senhores, de seu amigo Bruno Rafael.

Admin: Bruno

Olá Galera! muito grato por estarem acessando nosso blog. Espero que seja possível transmitir de forma compreensível um pouco de meus conhecimentos em programação, para esta comunidade de desenvolvedores que cresce cada vez mais! Espero que Gostem! Abraço! E meu enorme obrigado à Renato Simões, Átila Soares,Wanderson Quinto, Emerson e a toda galera que sempre ajudou meu sincero obrigado....
Especialmente a Natalia Failache e Rita de Cassia que sempre apoiaram este sonho....

De seu amigo Bruno Rafael.