Eduardo Leonne: 2010
Eduardo Leonne
Tecnologia, Desenvolvimento de Sistemas, Programação. Tudo em um só códig...quer dizer, lugar
Aprendendo uma nova linguagem
Depois de PHP, Java, HB++ (é de verdade, existe mesmo!), Delphi, Javascript e afins eu resolví aprender mais uma linguagem. Dessa vez foi o C++. A motivação veio do meu novo smartphone. A cerca de dois meses eu comprei um N900. Tem um ótimo hardware, usa uma distro Linux baseado Debian como SO, o Maemo.
Sempre gostei muito de mobilidade. Tive dois palms, um ITouch, tenho um PSP e agora o N900. Em todas essas plataformas eu tentei desenvolver um software. Devo dizer que no Palm foi onde eu fui mais bem sucedido (foi aqui que apareceu o HB++). Conseguí desenvolver uma app que controlasse minha vida escolar e o esqueleto de um jogo de estourar bolhas. Foi uma ótima experiência. Depois veio o ITouch. Nessa época eu descobrí que a Apple não é tão receptiva com novos desenvolvedores. O proprietarismo da empresa me jogou pra bem longe das fileiras de desenvolvedores para as "ICoisas". Então cheguei no PSP e seu homebrews. Por algum motivo, eu fiquei meio desmotivado e acabei desistindo dessa plataforma.
Agora finalmente estou no N900. A linguagem não é das mais gostosas de se trabalhar. C++ é estressante em certos momentos, mas a biblioteca (QT) é formidável.
Um amigo meu certa vez disse algo muito sábio: "Linguagem é detalhe".
Eu concordo. No fim das contas, as estruturas condicionais permanecem, os laços de repetição permanecem e o core de toda linguagem é basicamente o mesmo. O que muda mesmo é a sintaxe, e eu devo dizer que essa é a parte fácil de aprender.
Ainda estou no início da minha caminhada em C++ e QT, mas já estou terminando o primeiro projeto. Estou fazendo um simulador de Mocks (simulado para a SCJP) pro N900, visto que ainda não possui nenhum. Talvez este se torne meu TCC, mas por enquanto é só algo para eu me divertir.
Sempre que se aprende algo novo é necessário um pouco de dedicação e afinco. Mas passadas as primeiras dificuldades, as outras tendem a ser menores.
É isso. Em breve vou estar postando o projeto OpenSource na web e colocarei aqui.
No próximo Post vou falar um pouco sobre o Zend Framework. Planejo demonstrar um exemplo de estrutura combinando o Zend + Extjs e depois voltarei aos resumos da SCJP.
Postado por Leonne às 09:25 2 comentários:
Marcadores: C++, linguagens, N900, zend framework
Preparação para SCJP - Parte 3 (Interfaces)
Vamos ao próximo post: Interfaces.
Interfaces são classes abstratas por padrão. Sendo assim, não existe a necessidade de declará-la como tal. Porém, declará-la como abstract (apesar de redundante) é válido. Observe as seguintes declarações:
public abstract interface MinhaInterface { }
public interface MinhaInterface { }
Ambas declarações são válidas. Mas afinal de contas, o que raios é uma interface? Interface, é uma forma de você obrigar uma classe a se comportar de determinada forma. Como assim? Vamos entender por partes. Em primeiro lugar, a interface é um pouco mais que uma classe abstrata. É uma classe abstrata que possui somente métodos abstratos e públicos (mesmo que você não os declare como tal). Todos os atributos que você declarar em uma interface serão constantes, ou seja, não existem variáveis de instância em uma interface. Acompanhe o exemplo de declaração de métodos:
public interface MinhaInterface {
public abstract void meuPrimeiroMetodo();
// Se declarasse como abaixo também estaria correto:
abstract void meuPrimeiroMetodo();
// Assim também está certo:
void meuPrimeiroMetodo();
Veja a declaração de atributos:
public interface MinhaInterface{
public static final int constanteDeInterface = 20;
// Os códigos abaixo declaram constantes, mesmo que não esteja explícito, e são todos válidos!
public int constanteDeInterface = 20;
static int constanteDeInterface = 20;
final int constanteDeInterface = 20;
public static int constanteDeInterface = 20;
public final int constanteDeInterface = 20;
static final int constanteDeInterface = 20;
Como dito anteriormente, interfaces são implicitamente classes abstratas. Sendo assim, não pode ser instanciada. Porém, diferente do que acontece com classes abstratas, interfaces não são extensíveis (exceto por outras interfaces), e sim implementáveis. Ao invés de usar a palavra chave "extends", utiliza-se "implements". Diferentemente do conceito de herança, uma classe pode implementar mais de uma interface. Veja os exemplos:
// Implementação válida de uma interface
public class ClasseConcreta implements MinhaInterface { }
// O seguinte também é válido:
public class ClasseConcreta implements MinhaInterface, Runnable { }
// Uma interface pode extender de outra interface,
// mas nunca implementar!
public interface OutraInterface extends MinhaInterface { }
Interfaces são também uma maneira de simular mútipla herança, já que por bons motivos, a linguagem não possui suporte a este recurso. Uma classe abstrata também pode implementar uma interface, mas isso implica em fornecer implementação aos métodos da interface (que são inerentemente abstratos). Como a classe é abstrata, ela pode optar por delegar a implementação dos métodos abstratos dela própria e da interface à próxima classe concreta. Acompanhe o exemplo:
public interface Pulador {
// Lembre-se que métodos abstratos terminam
// com ";" e não "{}"!
void pular();
// Observe que o fato de implementar uma interface não impede de extender outra classe!
public abstract class Pneu extends Borracha implements Pulador {
public abstract void rodar ();
// Perceba que a classe optou por não implementar o método pular.
// Isso é totalmente válido, pois é uma classe abstrata.
public class PneuDeCaminhao extends Pneu {
/* Essa classe, por ser concreta e herdar de Pneu é
* obrigada a fornecer implementação de todos os
* métodos abstratos que ainda não tem implementação.
* Tanto da interface quanto da classe abstrata que ele
* herda diretamente*/
// Código útil aqui
public void pular() {
Como mostrado anteriormente, interfaces também utilizam herança. Interfaces NUNCA poderão implementar outra interface. Observe os exemplos:
public interface InterfacePai {
void metodoDaInterfacePai ( );
// Este código é válido!
public interface InterfaceFilha extends InterfacePai{
void metodoDaInterfaceFilha ( );
// Este código é inválido!
public interface InterfaceFilha implements InterfacePai{
void metodoDaInterface
Bom, acho que tem bastante informação aí. É isso. Até mais!!! See you guys!!!
Postado por Leonne às 05:40 Nenhum comentário:
Marcadores: abstratas, certificação, classes, interfaces, Java, mercado de TI, mercado de trabalho, modificador, SCJP
Preparação para SCJP - Parte 2 (Classes Abstratas)
Chegamos à segunda parte do estudo. Falaremos de classes abstratas. Classes abstratas são tipos especiais de classe. Elas tem algumas características interessantes. A primeira delas e mais importante é que uma classe abstrata não pode ser instanciada! Elas servem somente para serem herdadas por outras classes! O seguinte código é inválido:
public abstract class ClasseAbstrata { }
public class ClasseConcreta {
// Classes abstratas não podem ser instanciadas
ClasseAbstrata ca = new ClasseAbstrata();
Já esse é válido:
// Enquanto criar instancias é proibído, extender é algo totalmente válido!
public class ClasseConcreta extends ClasseAbstrata{
Um outro detalhe sobre classes abstratas é que elas podem conter métodos abstratos. Este detalhe é importante. Métodos abstratos só podem existir dentro de classes abstratas, porém uma classe abstrata pode conter métodos não abstratos (concretos). Discutiremos isso com detalhes depois. Vamos primeiro entender um método abstrato. Enquanto uma classe abstrata só serve para ser herdada (como visto anteriormente), métodos abstratos não fornecem uma implementação. São "métodos sem código". Quando declaramos um método abstrato, estamos dizendo que as classes concretas (não abstratas) que estenderem (herdarem) desta classe serão obrigados a implementar este método. A sintaxe de métodos abstratos também muda. Acompanhe o código abaixo:
public abstract class ClasseAbstrata {
public abstract void metodoAbstrato ();
public class ClasseConcreta extends ClasseAbstrata {
public void metodoAbstrato (){
// Implemente o código do método aqui.
Observe que o método declarado como abstrato possui um ";" ao invés de "{}". Observe também que a classe que estendeu (herdou) a ClasseAbstrata é obrigada a fornecer uma implementação do método abstrato da classe "pai". Resumindo, quando declaramos um método abstrato não dizemos de forma alguma como ele deve se comportar. Deixamos o papel de fornecer implementação às classes "filhas". Caso uma classe subclassifique (herde) uma classe abstrata e não forneça implementação para todos os métodos abstratos da superclasse (classe pai) o compilador reclamará e devolverá um erro! Observe o mesmo código de antes:
// Vai dar erro quando tentar compilar esta classe.
// Só vai compilar quando for fornecida
// implementação para o método abstrato.
Existe ainda mais um aspecto a ser considerado por agora. Classes abstratas podem fornecer métodos abstratos! Observe:
public void metodoConcretoDeUmaClasseAbstrata () {
// Aqui vai um código bastante útil!!!
Neste caso, nenhum erro será retornado. A classe concreta herdará um método.Como o método não é abstrato, não é necessário fornecer implementação.
Classes abstratas são um tanto quanto chatas porque possuem diversas regras. Muitas delas foram faladas acima, mas ainda existem mais. Uma delas é que classes abstratas podem herdar de outras classes abstratas. Beleza, e daí? Daí que classes abstratas não tem nenhuma obrigação de fornecer implementação a nenhum método, mesmo que ele seja assinalado como abstrato na super classe. Porém esses métodos não podem ficar sem implementação. A primeira classe concreta que herdar será obrigada a implementar todos os métodos abstratos que foram declarados e ainda não foram implementados. Observe o código abaixo:
public abstract class ClasseAbstrataPai {
public abstract void metodoAbstratoPai();
public abstract class ClasseAbstrataFilha extends ClasseAbstrataPai{
// Não fornece implementação nenhuma
public class ClasseConcreta extends ClasseAbstrataFilha {
public void metodoAstratoPai(){
// Insira código útil aqui
Se a classe "ClasseAbstrataFilha" tiver algum método abstrato, a classe concreta ainda é obrigada a implementá-lo. Tá complicado? Relaxa, que complica ainda mais. Se uma classe abstrata fornecer implementação a um dos métodos abstratos, a classe concreta passa a estar desobrigada a implementar os mesmos. Observe:
public abstract class ClasseAbstrataFilha extends ClasseAbstrataPai {
// Implementa opcionalmente o método abstrato da classe pai
// Não fornece implementação nenhuma.
// Não dá erro porque a classe pai já implementou o método.
Acredito que seja isso. Parece complexo e difícil de entender, mas quando você pega o jeito, vai embora! No próximo Post, Interfaces!
Bye dudes!
Postado por Leonne às 07:24 Nenhum comentário:
Marcadores: abstratas, certificação, classes, Java, mercado de trabalho, modificador
Preparação para SCJP - Parte 1
Modificadores de acesso a classes:
Começaremos as discussões sobre a SCJP com este tópico:
Existem certos tópicos da linguagem Java que por não serem amplamente utilizados acabam sendo esquecidos pelos desenvolvedores. O problema é que estes tópicos são explorados nas provas de certificação da Sun. Um destes tópicos é justamente os modificadores de acesso das classes. Digo isso porque a maioria das classes tem o modificador de acesso "public". Mas este é o único modificador de acesso possível a uma classe? A resposta é não. Existe o modificador default que também pode ser atribuído a uma classe. Mas como isso funciona?
Modificador de acesso é uma forma que a linguagem Java tem de restringir o acesso a determinadas partes de código. Em classes, quer dizer que se pode restringir ou liberar acesso para que outras classes possam acessá-la através de instâncias ou herança (esses assuntos serão discutidos em outro post). Para classes existem dois modificadores aceitáveis:
-Public: modificador mais comum. Classes assinaladas com este modificador podem ser utilizadas por qualquer classe dentro do universo Java. Em cada arquivo ".java" só poderá existir uma classe public. Exemplo de sintaxe:
// insira implementação da classe aqui
-Default: este modificador é mais restritivo que o modificador public. Ele diz que apenas as classes que estiverem no mesmo pacote que esta classe poderão ter acesso a ela. Exemplo de sintaxe:
class ClasseDefault {
Vamos desenhar um contexto:
Imagine que seu projeto tem dois pacotes: pacotea e pacoteb. Dentro do pacote "pacotea" criaremos duas classes: ClassePublica e ClasseDefault. Dentro do pacote "pacoteb", criaremos a classe "Main" e tentaremos fazer acesso às classes presentes no "pacotea". Acompanhe o código abaixo:
// Classe pública dentro do pacotea
package pacotea;
// Classe com acesso default dentro do pacoteb
// Note a ausência de um modificador de acesso. Indica modificador default!
// Classe que implementa uma instância de cada classe. Está em outro pacote.
package pacoteb;
// Note que esta classe está importando todas as classes do pacotea
import pacotea.*;
// Cria uma instância da classe com modificador público
ClassePublica cp = new ClassePublica();
// Tenta criar uma instância da classe com modificador default.
ClasseDefault cd = new ClasseDefault();
Caso você tente rodar este código, o compilador reclamará e exibirá um erro como este:
"The type ClasseDefault is not visible".
Agora, tente alterar o modificador de acesso da ClasseDefault para public e compile o projeto novamente. O erro desaparecerá!
Para desenvolvedores mais experientes, pode parecer bobo, mas é uma ótima pegadinha dentro de uma prova!
Pronto. Parte 1 concluída. Próximo post será sobre classes abstratas. See you guys!!!
Postado por Leonne às 14:23 Nenhum comentário:
Marcadores: acesso, certificação, classes, Java, mercado de TI, mercado de trabalho, modificador, SCJP
Como se preparar para SCJP
É fato que todo desenvolvedor sonha em ter uma certificação. Se ela for bem vista no mercado passa a ser meta dos mesmos. Foi pensando dessa forma que eu decidí tirar a minha certificação SCJP. Iniciei meus estudos a duas semanas e ainda vou levar mais oito pra fazer a prova. Vou colocar aqui no blog meus progressos pra que outros tenham melhor chance. Estou seguindo o livro da Kathy Sierra e Bert Bates (Guia de Estudo SCJP) e recomendo. O livro abrange todos os tópicos referentes à certificação e te dá uma preparação que dispensa qualquer curso por aí. De quebra, o livro ainda traz mais de 280 questões e dois master exams. Vamos ao que interessa. Como se preparar para a certificação?
Eu acredito que em tudo que se for fazer na vida é necessário planejamento e organização. Estudar não é diferente. Então, eu definí um plano de estudo bem elaborado e com um objetivo ao final. Meu plano de estudo foi feito com base no livro da Kathy Sierra. O livro é dividido em dez capítulos. Eu decidí que leria um capítulo por semana, faria os exercícios do capítulo no sábado e revisaria o conteúdo no domingo. Isso me dá cerca de dez páginas por dia. Parece pouco, mas eu trabalho e estudo! Bom, já tenho meu plano, prazos a cumprir e etc. Agora é só colocar em prática (que é o que estou fazendo!). Durante esse período de estudo eu vou estar postando algumas considerações interessantes que eu for tirando do livro. Acredito que vá ajudar quem ler o blog e também a mim, afinal a melhor maneira de fixar o aprendizado é ensinando. Me despesso por aqui. Até o próximo post.
Postado por Leonne às 13:28 Nenhum comentário:
Marcadores: certificação, Java, mercado de TI, mercado de trabalho, modificador, SCJP
Jogar, jogar...programar
Jogos. Sempre gostei deles. Gosto de jogar (e jogo) desde os 12 anos. O que me dá dez anos de experiência. A cerca de dois anos (desde que desenvolvo software profissionalmente) me interessei pela área de desenvolvimento de jogos. Como tudo começa do início, eu acabei aprendendo os princípios básicos dessa área tão interessante do desenvolvimento de software. Eu já desenvolví um jogo da velha em Delphi (eu sei, todo mundo já fez um), já fiz um jogo das bolhas no meu palm. Foi legal aproveitar o touch screen. Tentei desenvolver algo pro Ipod Touch (é, já tive um), mas a empresa da maçã e seu proprietarismo monárquico não me deixaram prosseguir. É possível criar algo em J2ME também. No futuro eu vou mostrar como, mas hoje, vamos nos ater aos princípios básicos.
Programação de jogos é algo extremamente complexo. Sem entender alguns conceitos básicos é impossível programar.
Primeiro conceito:
Sua tela é uma matriz. A tela do computador é constituída de uma série de pontos. Cada um desses pontos é localizada por um ponto XY, como num plano cartesiano. Então, para movermos um objeto na tela para frente ou para trás basta incrementar (aumentar) o valor de X desse objeto. Para fazê-lo voltar basta decrementar X. O mesmo princípio vale para o Y.
Segundo conceito:
Orientação a Objetos. Esse modo de pensar é usado desde que mundo é mundo. Como este não é um artigo sobre OO, apenas tenham em mente que é necessário para desenvolver jogos.
Terceiro conceito:
Sprite. Não. Não é o refrigerante! Sprites são pequenas animações repetidas que são acionadas quando o usuário envia um comando. Por exemplo, quando você clica no mouse e a arma que você está segurando dá um disparo (nós não estamos falando de jogos 3d, ok. É só um exemplo). A animação que faz a arma emitir uma luz na ponta é um sprite. Esta animação é sempre a mesma e sempre vai ser disparada pelo mesmo evento. Isso é um sprite.
Quarto conceito:
Double Buffering. Essa técnica é antiga e praticamente obrigatória. Na maioria das vezes a própria linguagem já implementa automaticamente. Double buffering resolve um problema de atualização da tela. Toda vez que um objeto mudar de posição na tela é necessário redesenhar tudo com as novas posições. Imagine que sua tela é como um quadro de pintura e que os objetos são pintados sobre este quadro. Porém, ao repintar o quadro para atualizar a posição de um objeto, você verá um pequeno delay dessa atualização. É pequeno, mas quando se junta tudo fica extremamente incômodo. Para resolver este problema, basta colocar um quadro sobre o quadro. Quando for atualizar a tela, você desenhará sobre este segundo quadro. Quando terminar de atualizar o quadro com todas as novas posições dos objetos, você pinta ele sobre o quadro principal. Isso acaba com o delay de atualização da tela.
Quinto conceito:
Algoritmo de detecção de colisões. Tá bom. Esse é difícil. Honestamente, não conseguí implementar nenhum que seja 100% eficiente. Existem diversas técnicas diferenciadas e a que eu mais gostei foi a quadtree. Ela consiste em utilizar a estrutura de dados árvore para mapear a tela. Cada parte da tela é representada por um dos nós da árvore e esses nós possuem mais quatro nós e assim por diante. Com uso dessa técnica é possível reduzir drásticamente a quantidade de cálculos necessária para detectar que um objeto colidiu com outro. Isso porque a verificação ficaria restrita ao setor (nó da árvore) em que os objetos estão. Tem um artigo na sharpgames de um cara que implementou o mesmo: http://www.sharpgames.net/Artigos/Artigo/tabid/58/selectmoduleid/376/ArticleID/1603/reftab/54/Default.aspx.
Ok. Com isso aí já dá pra fazer um joguinho 2D básico (quase um Mário Bros!!!). Em outro post eu posto um exemplo usando Java.
Postado por Leonne às 09:30 Nenhum comentário:
Marcadores: conceitos, Games, How to, J2ME, Jogos, programação
ExtJS. RIA em javascript
No meu último post sobre RIA eu falei um pouquinho sobre extjs (na verdade só citei o nome). Vamos falar um pouquinho sobre esta tecnologia. Primeiro, o que é. Extjs é uma framework totalmente javascript cross-browser. Ou seja, tudo que você precisa pra rodar uma app construída com ele é um browser. Ele pode ser obtido em:
-http://www.extjs.com/products/js/download.php
-http://www.extjs.com/deploy/dev/examples/
Como começar? Fácil. Faça download. Crie uma nova pasta no seu web-server (chame-a de "teste", se desejar). Descompacte o extjs nesta pasta. Pra ficar mais fácil referenciar, mude o nome da pasta do extjs para ext. Crie um arquivo dentro da pasta "teste" chamado index.html. Insira o código abaixo neste arquivo:
<title>Teste Extjs</title>
<meta content="charset=utf-8" equiv="content-type"></meta>
<link href="ext/resources/css/ext-all.css" rel="stylesheet"></link>
<script src="ext/adapter/ext/ext-base.js">
<script src="ext/ext-all.js">
<script src="ext/src/locale/ext-lang-pt.js">
title : "Login",
height : 130,
edtLogin = new Ext.form.TextField({
emptyText: 'Digite seu Login',
fieldLabel: 'Login',
width:210,
id: 'edtLogin'
edtSenha = new Ext.form.TextField({
emptyText: 'Digite sua senha',
fieldLabel: 'Senha',
id: 'edtSenha'
btnEntrar = new Ext.Button({
text: 'Entrar',
login = Ext.getCmp('edtLogin').getValue();
senha = Ext.getCmp('edtSenha').getValue();
Ext.Msg.alert('teste', 'Login: ' + login + ' Senha: ' + senha);
btnLimpar = new Ext.Button({
Ext.getCmp('edtLogin').setValue('');
Ext.getCmp('edtSenha').setValue('');
pnlCentral = new Ext.form.FormPanel({
edtLogin,
edtSenha
buttons:[ btnEntrar, btnLimpar ]
win.add(this.pnlCentral);
<noscript><font style="font-weight: bold;">Sé funciona com javascript habilitado!</font></noscript><span style="font-weight: bold;">
Esse pequenino código gera uma telinha de login:
Bem simples. Vale a pena destacar que esta framework é toda orientada a objetos. Dá até pra utilizar conceitos como herança ou polimorfismo. Quem conhece javascript sabe que esta não é uma linguagem OO. É isso. No futuro eu falo novamente sobre esta plataforma.
Postado por Leonne às 17:54 Um comentário:
Marcadores: EXTJS, linguagens, programação, RIA
PSP, eu ouço música no meu video game ou jogo video game com o som do meu carro?
Quem me segue no buzz já sabe que eu me amarro em trecos (ou gadgets pro's mais tecnológicos). O alternativo sempre me atrai. Já usei um palm como controle remoto de TV, conprei outro palm e usei como notebook, Uso notebook como caderno, ou seja, onde eu acho a chance de fazer um gatinho eu faço. É certo que nem sempre minhas gambis (modo carinhoso de dizer gambiarra) dão certo, mas eu tenho que dizer que a última gambi deu muito certo. Transformei meu PSP em um som de carro. "Oh My God. Você quebrou um PSP?". Nops. Nem relei nele. Vou explicar aqui como eu fiz. Primeiro, os materiais necessários:
-1 PSP (dã);
-1 cabo p2/rca;
-1 módulo;
-1 mecânico;
-1 suporte para GPS que caiba o PSP;
Eu comprei um módulo de 480w por R$ 140,00. O cabo e o mecânico vieram de brinde. O suporte foi dérreau no feirante mais próximo. O PSP eu já tinha. O som do meu carro custou R$ 150,00 e não fica chiando feito uma caixa de abelhas. E o melhor é que funciona com qualquer aparelho que tenha saída de aúdio P2 (aquela saída igual aos fones de ouvido mais comuns)
Chame o mecânico e mande ele instalar o módulo. Essa é a parte legal. Geralmente, quando você compra um módulo pro seu carro, eles já oferecem a instalação com o cabo p2/rca. O cabo ele mesmo passa também. O trabalho que você vai ter é somente fixar o suporte de gps em algum lugar do carro. Eu fixei no lugar que deveria ficar o som do carro. Nada que uma furadeira e uns parafusos não resolvam. Mais tarde eu tiro uma foto e posto aqui. Ligue seu PSP, escolha a música ou faça uma playlist e seja feliz!!!
Postado por Leonne às 16:56 Um comentário:
Marcadores: audio, automotivo, gadgets, modificações, PSP, som de carro
Tudo começa do início + RIA
Este é o primeiro blog que eu possuo. No começo é meio complicado falar sobre coisas porque temos muito o que falar, mas é difícil organizar tanta coisa em palavras. Como eu não sei por onde começar, então comaçarei por algo que eu conheço. Vamos falar de RIA:
RIA significa Rich Internet Application. Em outras palavras, são aplicações ricas para a web. Com este tipo de tecnologia é possível emular diversas funcionalidades presentes em um desktop (imaginemos o Windows pra ficar mais fácil) dentro do browser (tenham em mente o firefox). Poxa, não entendí. No problem. Vou dar um exemplo prático de algumas aplicações:
-http://qwikioffice.com/desktop-demo/login.html
-http://opensource.adobe.com/wiki/display/blazeds/BlazeDS
-http://www.wynapse.com/Silverlight/Tutor/Silverlight_Code_Samples.aspx
Este tipo de aplicação tem crescido na web. Com este crescimento, surgiram também ferramentas especializadas em construir esse tipo de aplicativo. O primeiro exemplo foi feito utilizando uma framework escrita em javascript chamada Extjs (mais informaçoes em www.extjs.com). O segundo exemplo foi feito utilizando o Adobe Flex. O terceiro foi utilizado o Micro$oftiano Silverlight. Ambos demonstram um visual muito chamativo e moderno.
Porém, RIA não se restringe a isso. Se você é desenvolvedor de sistemas, deve estar se perguntando: "Beleza. É tudo muito bonito, mas e quanto ao lado servidor? Como é que fica?". Ter uma tecnologia tão chamativa e não poder contar com um banco de dados seria puro desperdício. Mas existem bytes no fim do pacote. As duas primeiras que eu lhes apresentei possuem integração com as principais linguagens server-side. A terceira eu desconheço integração que vá além do .NET. Podemos integrar com o parrudo e nem sempre performático Java, o PHP e seus bugs, o propritaríssimo .NET e por aí vai.
Acredito que RIA tem muito a crescer ainda. Nos meus próximos posts eu vou falar um pouco mais sobre Extjs que eu já estudei profundamente.