sábado, 23 de fevereiro de 2008

Silverlight 2.0 anunciado

silverlight_logo O gerente geral da divisão de desenvolvimento da Microsoft, Scott Guthrie, anunciou em seu blog o Silverlight 2.0, suas "novidades" e também um tutorial.

Dentre as informações que mais chamam a atenção está a de que nessa nova ação a Microsoft incluí o plano de um release da plataforma para Linux adicionalmente.

 

Uma outra fonte da mesma informação, o site da ComputerWorld, cita que este release do Silverlight tem como objetivo direto atacar a tecnologia Flash da Adobe que o mesmo site cita como "popular" no universo RIA.

Licença Pública WTFPL

wtfpl

Na eterna batalha de se adotar um modelo de licença pública ideal, surge mais uma opção: What the Fuck Public License (Do What The Fuck You Want Public License) ou em bom português (tradução livre), "licença pública faça a porra que você quiser".

Trata-se na verdade de uma crítica em relação a esses modelos de licença sobre o qual sempre há a discussão a respeito de qual delas é "mais livre" do que a outra.

O autor, Sam Hocevar, no seu site, faz uma reprodução muito cômica do formato básico desses modelos de licença.

A licença, claro, tem apenas uma cláusula (traduzida):

0 . Você simplesmente faz a porra que você quiser

sexta-feira, 22 de fevereiro de 2008

Mock Objects

wikiMock

Até então, eu desconhecia o termo. Só usava há anos o método e apliquei no Flex a partir do uso extenso do Cairngorm.

Definição no Wikipédia:

  • Mock objects são objetos que simulam o comportamento de objetos reais de forma controlada. São normalmente criados para testar o comportamento de outro objeto.

Tomei conhecimento a partir deste post no blog da DClick e ao escrever este post aqui mesmo no meu blog sobre desenvolvimento Flex/Cairngorm.

Flex, Cairngorm e desenvolvimento progressivo independente de Business / Delegate usando "FakeData Factory"

flex3_fx_124x120 Eu já estava para fazer esse post desde ontem quando passei a adotar essa metodologia que vou apresentar aqui para o devido propósito anunciado como título, mas no momento de pausa para me atualizar do conteúdo de outros blogs que leio, acabei, por pura coincidência, me deparanto com um artigo publicado pelo Ricardo Pettine no Blog da DClick com o título “A EVOLUÇÃO DO MOCK USANDO O CAIRNGORM”, o que me levou a antecipar e mudar um pouco o objetivo desta postagem.

Na verdade, se observarem os 3 comments que fiz no Blog da DClick, vão ver que eu tentei fazer o assunto progredir lá mesmo, mas acabei esbarrando no problema de caracteres do código de exemplo que tentei postar.

(que vergonha a minha... enferrujando no uso de blogs... acho que se eu tivesse colocado um <code>, resolveria talvez).

Bom, vamos lá...

A minha intenção com o que eu fiz e proponho usar, é permitir o desenvolvimento de toda a estrutura de front-end no Flex, usando Cairngorm, independente da parte de Business/Delegate que referem-se justamente à integração com o Back-end.

Não fiz isso baseado em nenhum modelo, nem ao menos pesquisei alternativas. Simplesmente adotei e apliquei para uma necessidade atual que tive em um projeto no qual estamos redefinindo todo um framework de backend (ColdFusion), mas que por já ter todos os dados e requisitos especificados, obviamente permitia o progresso individual do desenvolvimento do Front-end.

Então, são os requisitos para aplicar esse recurso:

  1. Utilizar o framework Cairngorm (embora possa ser aplicado em qualquer situação onde o MVC seja a base de desenvolvimento)
  2. Ter os ValueObjects (VO) ou DataTransferObjects (DTO) definidos.

Com os requisitos atendidos você imediatamente compreenderá que a implementação proposta será aplicada nos Commands, no caso da arquitetura do Cairngorm.

Meu exemplo se baseia em um EmailLoadAllCommand, que por sua vez instanciaria um EmailDelegate e então o método loadAll(). O Result nesse caso trabalharia com o recebimento de uma array de instancias de EmailVO.

Apenas para referência, o método execute() de EmailLoadAllCommand:

public function execute(event:CairngormEvent):void{
var delegate:EmailDelegate = new EmailDelegate(this);
delegate.loadAll();
}

A alteração seria feita exatamente aqui, eliminando neste momento o Delegate e consequentemente a implementação de Responders para tratar o resultado da atividade do Delegate. O código acima alterado para usar a solução proposta pela implementação da classe EmailFakeCollection.as que apresentarei logo após:

public function execute(event:CairngormEvent):void{
//var delegate:PessoaFisicaDelegate = new PessoaFisicaDelegate(this);
//delegate.loadAll();
EmailModel.getInstance().emailCollection = EmailFakeCollection.generate();
}

Repare que estamos no método execute(), alterando o Model diretamente, com o dado solicitado. Neste caso apenas antecipamos o que só ocorrería no result() do responder que sería especificado no instanciamento do Delegate.´

Considerando o exemplo acima, onde o Command teoricamente implementa mx.rpc.IResponder e portanto conterá o método result(), simplesmente mudamos a instrução de associação dos dados ao model de lugar.

A idéia então consiste em que a classe EmailFakeCollection (e todos os eventuais FakeCollections que o sistema necessitar) implementem um método estático generate() que por sua vez retorne um ArrayCollection simulando dados que seríam recebidos no result da classe apontada para ser o responder da aplicação.

Eu pessoalmente preferi implementar um parâmetro para o método estático generate() afim de que eu possa especificar um número de itens que desejo receber como retorno.

No caso do exemplo citado então, a proposta da classe EmailFakeCollection seria a mostrada abaixo, seguido da classe EmailVO para referência apenas:

package br.com.ir.pessoas.factory{
 
import br.com.ir.pessoas.vo.EmailVO;
 
import mx.collections.ArrayCollection;
 
public class EmailFakeCollection{
 
private static var fakeRawData:Array = [
{
id: 1,
email: "macieljr@gmail.com",
padrao: 1
},
{
id: 2,
email: "macieljr@interfacerica.com.br",
padrao: 0
},
{
id: 3,
email: "macieljr@ir.com.br",
padrao: 0
},
{
id: 4,
email: "owner@vpmjr.com",
padrao: 0
},
{
id: 5,
email: "publisher@teclandoalto.com.br",
padrao: 0
}
];
 
public function EmailFakeCollection(){}
 
public static function generate(_qty:int = 0):ArrayCollection{
 
var returnData:ArrayCollection = new ArrayCollection();
 
var totalItems:int = (_qty > 0 && _qty <= fakeRawData.length) ? _qty : fakeRawData.length;
 
for(var i:int = 0; i < totalItems; i++){
 
var email:EmailVO = new EmailVO(
fakeRawData[i].id,
fakeRawData[i].email,
fakeRawData[i].padrao
);
 
returnData.addItem(email);
 
}
 
return returnData;
 
}
 
}
 
}
package br.com.ir.pessoas.vo{
 
import com.adobe.cairngorm.vo.IValueObject;
 
[RemoteClass(alias="br.com.ir.pessoas.EmailVO")]
[Bindable] public class EmailVO implements IValueObject{
 
public var id:int;
public var usuario:String;
public var provedor:String;
public var padrao:uint;
 
public function set email(_email:String):void{
 
if(_email.length){
 
var emailParts:Array = _email.split("@");
this.usuario = emailParts[0];
this.provedor = emailParts[1];
 
}
 
}
 
public function get email():String{
 
return this.usuario + "@" + this.provedor;
 
}
 
public function EmailVO(_id:int = 0, _email:String = "", _padrao:uint = 0){
 
this.id = _id;
this.email = _email;
this.padrao = _padrao;
 
}
 
}
 
}

Eu acabei batizando isso de FakeDataFactory. Nem sei se o nome ja foi usado. Mas agora vou ficar de olho em temas como o abordado pelo Ricardo no blog da DClick para conhecer e aprender melhor formas alternativas de implementar isso.

Por enquanto esta forma me atende completamente. Inclusive, caso a aplicação especificasse a necessidade de criar um Factory (no padrão costumeiro da palavra mesmo) para o recebimento de dados no formato JSON, um XML ou qualquer outro tipo de serialização, eu simplesmente implementaría a classe normalmente e simularia dentro do meu FakeDataFactory o recebimento de dados e instanciamento através desse Factory de desserialização. Depois, na implementação final de integração com o Back-End, bastaría mover a chamada dessa implementação no seu local apropriado.

Qualquer dica à respeito do fundamento, outras formas de implementação e padrões já existentes é muito bem vinda!

quarta-feira, 20 de fevereiro de 2008

Ele não morreu! Director 11!

director11

Confesso que se me perguntassem, a resposta sería:

"Pelo jeito, morreu mesmo!"

Mas ainda bem, para me contrariar e não deixar o mercado órfão do melhor produto que já usei para desenvolver conteúdo para CD-ROM, e que me introduziu ao desenvolvimento de conteúdo multimídia/web, a Adobe mostra de uma vez por todas que o produto tem sua força!

quarta-feira, 21 de novembro de 2007

Grupo de usuários AIR-Brasil anunciado

airbrasil

Conforme anúncio no Blog do Igor Costa, já está ativo e funcional um grupo de discussões com atenção dedicada ao AIR.

CADASTRE-SE: http://groups.google.com.br/group/air-brasil/subscribe

quinta-feira, 15 de novembro de 2007

Logo definitivo do ADOBE AIR

air_official_logo_blackbg

Anunciado pelo Mike Chambers em seu blog, este é o logo definitivo do Adobe AIR.

Conforme dito pelo próprio, o conceito da marca basicamente reuniu a informação de que o produto está apoiado em 3 tecnologias principais: HTML, PDF e Flash.

Um fato que achei interessante:

No post original, o Mike Chambers cita algo interessante (tradução livre):

Normalmente este é o tipo de informação e notícia que nós deveríamos postar no site principal e não em um Blog. Por outro lado nós sabemos que o sucesso do Adobe AIR depende dos desenvolvedores, bem como aplicações e conteúdos que eles criam. E nós aprendemos com o Adobe Reader e o FlashPlayer que conteúdo dirige à adoção. É por isso que estamos postando o logo aqui primeiro. Nós queremos que a comunidade de desenvolvedores seja a primeira a ver a nova logo.

Technorati Tags: ,,,

Update: CTRL+F5 - O time virou seleção

ctrlf5

Não... não é do time do São Paulo que estou falando... ;)

O CTRL+F5, novo blog reunindo os maiores destaques do mercado de comunicação de Salvador/BA com temas excepcionais está quentíssimo e conta agora não simplesmente com um time, mas sim uma verdadeira SELEÇÃO DE NOMES!

  • Bruno Angra
  • Daniel Fonseca
  • Daniel Paixão
  • Germano Bona
  • Julio Souza
  • Zeca Sento-Sé

Vale a pena conferir! Adicione-o ao seu leitor RSS e acompanhe também os comentários pois estão tão interessantes quanto as matérias.

detalhe: vou colocar aqui pequenininho e escondido pra não parecer prepotência. fui convidado a fazer parte do time e já dei minha contribuição falando sobre air, silverlight, gears, javafx e prism.

Por que usuários de PHP são tão unidos?

Estava com um amigo (Jeff) discutindo uma excelente matéria postada no ColdFusionJedi sobre uma High Scholl na Nova Zelândia que possui aulas de ColdFusion como matéria regular de informática em substituição a aulas de Word, Excell, etc.

Ao final da matéria surge um tópico interessante... alguns dos alunos demonstraram que iriam migrar para o PHP mesmo sem terem associado ao CF algum problema que os levassem a esta atitude.

Surgiu o seguinte trecho na minha conversa com o Jeff:

Vicente Jr: Que louca essa última parte: "...I'm curious why all the kids seemed to be moving to PHP..."

Jeff: Sabe que é uma verdade?

Vicente Jr: Tenho minhas suspeitas:
- CFBoy@NZ: Hi! I'm doing CFML Apps... It's so cool!
- PHPBoy@Anywhere: Are you a fag? My dad tolds me it's sucks... it's not real programming language. If you really want to be a MAN, a programmer, learn PHP! You bitch!

Jeff: (risos)

Jeff: Mas sabe por que os usuários de PHP se unem assim? Em comunidades, etc?

Vicente Jr: Não faço idéia!

Jeff: Porque nunca conseguiram terminar um sistema sozinhos!

Vicente Jr: (risos) + (risos) + (risos)

Claro que trata-se de uma brincadeira, tão comum quanto a que outro colega postou em uma lista sobre CF da qual participamos, com um vídeo (uma coleção na verdade) produzido pela comunidade RubyOnRails criticando o CF (e outras linguagens, dentre elas o PHP). Mas suspeito se não tem lá seu fundo de verdade! (Risos++)

segunda-feira, 12 de novembro de 2007

Evolução: disquetes > CDs > Browsers > Virtual Machines

O tópico é mais especificamente para falar de uma coisa interessante que tenho visto acompanhando alguns blogs.

Há muito se diz, e até deram um nome totalmente fantasioso de "Web 2.0" para essa evolução natural da internet, prevista há muito tempo por nós desenvolvedores porque era realmente óbvio que em algum momento isso acontecesse. Precisava-se apenas que tecnologias se aprimorassem, o ambiente amadurecesse (usuários, seus conhecimentos e seus equipamentos) e um modelo de negócio fosse bem viabilizado.

As aplicações finalmente estão deixando de serem coisas que instalamos em nossos computadores, para se tornarem recursos disponibilizados por seus respectivos desenvolvedores em diversos formatos mais acessíveis, mais abrangentes e por que não dizer justa e liberal. E isso está crescendo de forma muito rápida pois as aplicabilidades não tem limites.

Dá para se definir uma linha de tempo de evolução, com exemplos:

mais ou menos em 2000

Os WebServices ou a definição do SOAP sobre o XML nos trouxe uma nova possibilidade. Não precisaríamos mais investir para reinventar a roda. Bastava utilizá-la dos bondosos que permitissem acesso às sua invenções ou alugá-las, o que mesmo tendo um custo, era muito menor do que você produzir sua própria roda.

Nas palestras que eu fazia na época (quando funcionário da Macromedia), abordando WebServices com o ColdFusion (criação e consumo de webservices), um exemplo ilustrava bem a situação:

(Vou apresentar um breve resumo. Se alguém quiser detalhes do exemplo, basta me consultar.)

Imagine uma agência de viagens que pretende disponibilizar um sistema de personalização de um pacote de viagens. A partir do seu próprio site, usando suas determinações de comunicação visual e etc, ela pode apresentar ao usuário horários de vôo de várias companhias aéreas e já permitir que o mesmo a selecionar para efetivar o pacote e no final do processo proceder com o pagamento. O que muitas agências fazem ainda hoje (porque desconhecem a possibilidade ou porque não podem investir) é simplesmente listar os vôos previamente cadastrados no sistema, o que pode gerar problemas porque no momento da efetivação pode ser que a companhia aérea não possui mais aquele vôo disponível. Fora que isso pode ocasionar a perda do cliente infringindo um outro problema sério: a incapacidade de retenção do cliente.

A solução para conseguir anexar ao site da agência as informações de vôo da companhia aérea? WebServices!

Com este recurso a companhia aérea disponibiliza as informações de vôo que qualquer agência poderá anexar ao seu site sem importar qual tecnologia a companhia aérea utilizou para desenvolver seu sistema e qual tecnologia a agência escolheu para desenvolver o seu. Neste caso, dizemos que a agência estará "consumindo" o WebService disponibilizado pela companhia aérea.

Essa foi uma grande evolução! O SOAP funciona então como um protocolo para a comunicação entre recursos de sistemas disponibilizados em diferentes plataformas e diferentes tecnologias.

Um repositório de WebServices famoso é o Xmethods:

xmethods

Tem também o Afterzed:

afterzed

Ambos com WebServices definidos em várias tecnologias e consumíveis por qualquer tecnologia que implemente esse recurso.

mais ou menos 2004

Embora baseado em uma metodologia antiga - o uso de javascript para controlar o comportamento de elementos de interface - que chamávamos de DHTML, o AJAX veio com ar e fama de "nova tecnologia" pois determinava uma padrão interessante de comunicação entre browser e servidor utilizando XML (serialização/deserialização de dados). Unindo isso aos WebServices, ganhamos os Mashups.

Junto com termo AJAX, passou a finalmente estabelecer-se os RIAs (Rich Internet Applications) que resume-se em nada mais nada menos, do que novos poderes de controle da interface por parte dos desenvolvedores de sites e aplicações (leia-se também, Sites/Aplicações que são os Web Applications).

Os Mashups então acabam constituindo-se de aplicações completas, ao invés de recursos básicos para serem implementados em outras aplicações, como é o caso mais comum do WebService, que da mesma forma podem ser consumidos por outras aplicações.

Um exemplo prático e muito comum hoje de recursos que compõem um Mashup na Web é o GoogleMaps e o YouTube. E pra não me criticarem de só falar do Google (Google! Google! Google!), cito também o YahooMaps, LiveMaps (Microsoft), Flickr (Yahoo), etc.

Um bom repositório de Mashups na web:

programmableweb

já há algum tempo e ganhando cada vez mas força dos dias de hoje

Com toda a evolução, tanto conceitual quanto comercial que havía acontecido até então, grandes investidores e empresas de TI passaram a dedicar-se a espe "pedaço de negócio" que evoluía de forma cada vez mais forte.

Veio então a definição do SOA (Service Oriented Architecture) que determinou um modelo de orientação, suporte e estrutura para os negócios nessa área.

Como evolução ainda maior veio o SaaS (Software as a Service) que é um modelo que tras não apenas uma excelente nova geração de aplicabilidade da conectividade de nossos equipamentos à internet, mas uma ótima revolução no ambiente tecnológico que tende a provocar muitas outras revoluções.

Trata-se "simplesmente" (na visão do usuário) em fazer com que o seu software não seja mais distribuído em CDs, DVDs e seus installers, mas sim através do seu navegador.

Já existem muitos negócios / empresas hoje que se valem deste tipo de solução para compor a sua arquitetura de recursos tecnológicos.

zoho Veja por exemplo, o zoho.com que oferece uma gama completa de soluções office. Você tem editor de texto, planilha, editor de apresentações e até mesmo banco de dados, e tudo padronizado para trabalhar com a importação e exportação para os formatos padrões do mercado.

Além disso, o serviço é oferecido também na forma de uma API para que você implemente os recursos da maneira que desejar em suas próprias aplicações.

Ainda não estudei o impacto em custos, mas acredito que eles venham a ser muito mais vantajosos do que os modelos de licença que temos hoje de grandes produtos comerciais desta linhagem.

microsoft_logo A própria Microsoft já parte para esta iniciativa e é infalível que ela se dê muito bem. Aliás, isso pode inclusive significar uma estratégica abertura de mercado conforme consta no post que originou essa minha matéria. Com esta possibilidade de distribuição de produtos Microsoft, pode-se ter por exemplo uma infra-estrutura de TI que optou por Sistemas Operacionais open-source para uma drástica redução de custo de propriedade em suas estações, mas por questões de produtividade e economia com treinamentos, manteve o Microsoft Office como solução de ferramentas Office.

buzzword É impossível nesse contecto não comentar sobre o Buzzword que a Adobe já colocou em fase beta-público. Trata-se de um editor de texto fantástico implementado com o FlashPlatform (Flex basicamente). E olha que não será a única investida da Adobe, pois espera-se um já anunciado Photoshop Express nas mesmas condições.

...daqui por diante... what's next?

E não podemos achar que mais um passo nesse contexto ainda está por vir. Já veio! Essas aplicações estão, na maioria dos casos (dependendo do "meio" utilizado, pois com o Adobe AIR é assim) serem transformadas em aplicações que roram em "Browsers" personalizados.

Adobe com o AIR, Microsoft com o Silverlight, Sun com o JavaFX, Google com o GoogleGears são os destinos dessas aplicações.

Enfim

O que vejo é que daqui há pouco não teremos mais os navegadores na forma como os vemos hoje. Sinceramente eu não sei ainda como isso vai ser nem como irá acontecer de forma clara para arriscar uma previsão aqui pois um acontecimento desse influi em muita coisa. Mas baseando-se no princípio de que os recursos que surgem agora começam a destacar-se dos navegadores, essa é uma transição pré-anunciada com benefícios e deficiências (também).

Mas agora já é conteúdo para um outro post. ;)