Artefatos de T.I.

Playing with Script#

2011-11-28T19:34:00.001-02:00

Pesquisando novas tecnologias para o desenvolvimento Web, eu reencontrei o Script# (http://projects.nikhilk.net/ScriptSharp). E como a curiosidade foi grande, resolvi dar uma "brincada" com o projeto.

O Script# é basicamente um compilador para código em C#, algo próximo da especificação do C# 2.0. Então ao invés de gerar bytecode CIL, gera Javascript. E tenho que falar, gostei da maneira como funciona.

Irei postar mais informações e um exemplo em breve.

Dicas de Inglês

2011-02-25T00:35:00.000-03:00

Encontrei o seguinte site (http://www.englishexperts.com.br/category/curso-avancado-gramatica/), por acaso. Esse site trás dicas sobre a escrita correta (grafia) da língua inglesa. Gostei muito do conteúdo, assim como das explicações.

Fica a dica! Aproveitem!

.NET C++ Wrapper, Mixed Managed C++, C#, Mono, OGRE... e SWIG!

2011-02-24T02:01:00.001-03:00

Como parte do meu projeto do mestrado, eu tenho que escolher uma game engine para o desenvolvimento de um protótipo de um framework adaptável de um jogo. Depois de feita algumas análises, eu optei por trabalhar com a OGRE3D, uma excelente engine de renderização 3D, escrita em C++, e completar o resto das funcionalidades com outras bibliotecas.

O projeto é escrito em C# 4, visando o MS .NET Runtime e o Projeto Mono como máquina virtual, e como a biblioteca OGRE3D é escrita em C++, as funcionalidades não podem ser acessadas diretamente, sendo necessária a utilização de um wrapper para a interoperabilidade. Assim sendo, existem duas escolhas a disposição para dar acesso a tais bibliotecas:

MOGRE - Um wrapper feito em Mixed Managed C++, com excelente desempenho, e;
OGRE.NET - Outro wrapper, que realiza as chamadas através de P/INVOKE, sendo gerado através do SWIG.

Acontece que a MOGRE, apesar de ser uma ótima biblioteca, somente provê suporte para o sistema operacional Windows, justamente por ter sido escrita utilizando código misto. Assemblies em Mixed Managed C++ são basicamente uma mistura de código nativo em C/C++ (x86 ou x86-64) com código gerenciável (managed code ou CIL). Como o código nativo é específico da plataforma que foi compilado, o Mono não consegue executá-lo, pois chamadas a funções do Windows estão presentes somente no Windows (bom isso é uma das limitações).

Uma alternativa seria utilizar compilação condicional, assim como é feito em C++ para portar uma biblioteca para diversas plataformas (a OGRE faz isso!). Ainda, assim, seria necessário que o GCC emitisse CIL e que gerasse um assembly em Mixed Code que fosse suportado pelo Mono, o que não é possível no momento.

O projeto requer que este o seja portável entre várias plataformas, afinal existem várias universidades, cada uma com sua escolha de sistema operacional (Windows, Linux, MacOSX). Sendo assim, a MOGRE passa a ser uma escolha limitada. Desse forma, resta analisar a biblioteca OGRE.NET.

Por sua vez, a OGRE.NET é um projeto que aparenta estar morto. A última biblioteca criada somente dá suporte a versão 1.4 da OGRE, que já se encontra na versão 1.7.2. Sendo assim, não é interessante utilizá-la.

Se ambas propostas não são aceitáveis ao projeto, só resta criar uma alternativa, criar uma nova biblioteca que faça o trabalho. Tal biblioteca deve ser baseada em P/INVOKE que nada mais é do que um modo de se acessar bibliotecas dinâmicas (.dll, .so, .dylib etc) presentes no sistema operacional, através de chamadas a métodos estáticos externos.

Criar tal wrapper para uma biblioteca como a OGRE é um trabalho extremamente penoso (e como é!!), pois toda a funcionalidade dessa deve ser exposta como chamadas de função em C, imagine então portar todos os métodos de cada classe da OGRE; um grande trabalho, com certeza! Além disso, existem algumas situações onde é necessário manter o polimorfismo entre as classes e não somente criar Proxies (criação de Directors, como definida pelo SWIG).

Uma alternativa para se realizar tal tarefa é utilizar o SWIG, um gerador que pode ler o código em C++ (headers no caso) e gerar os wrappers necessários em C++ e C# automaticamente. E realmente, pra boa parte do trabalho, o SWIG consegue prover bons resultados, gerando um bom código.

Como em tudo existe um porém, o SWIG visa portar a biblioteca para a linguagem de destino (nesse caso, C#), mas não se preocupa muito em como tal biblioteca irá parecer perante os olhos de um programador acostumado a plataforma de destino. Surgem algumas construções estranhas na linguagem final; tipos com nomes estranhos, exposição de funcionalidades que parecem com as providas pelo framework mas que não o são, sendo incompatíveis algumas vezes, como em Listas, Dicionários etc.

Adicionalmente, o SWIG aparenta não suportar a criação de tipos de valor (structs) em C#, tudo é gerado como uma classe (uma das maiores limitações, em minha opinião). Isso provoca um efeito negativo alto no desempenho final da aplicação, que já está prejudicada pela utilização de P/INVOKE. Afinal, cada chamada a um método externo requer de 10 a 30 instruções somente para tal invocação; um constante desperdício de tempo de processamento para cada chamada externa.

Dessa forma, a construção de código manualmente, apesar de ser extremamente trabalhosa, é a melhor alternativa no momento para realizar tal tarefa. Uma possível alternativa, seria gerar com o SWIG o máximo possível de funcionalidades e deixar somente as mais problemáticas sendo realizadas manualmente. Mas o código do SWIG nem sempre é compatível com tal situação, ainda assim é um teste que irei realizar.

Férias chegando?!

2010-12-09T15:07:00.001-02:00

Dificilmente... tenho que terminar a minha dissertação até ~~Fevereiro~~ maio (consegui a prorrogação!!)... sendo assim, é botar fogo nos dedos enquanto digitando heheh...

Área de pesquisa: Sistemas de Informação
Subárea: Jogos
Tema: Jogos na educação
Título: Um framework para construção de jogos educacionais.

Square, EA, GameLoft vamos trabalhar juntos?! heheh ;)

Aulas de multimídia

2010-12-09T15:03:00.000-02:00

E as aulas acabaram... agradeço aos alunos que participaram até o final pela oportunidade.

Ainda assim, como sempre acontece, pessoas levaram na brincadeira ou privilegiaram outras disciplinas pelo fato de ser um "aluno" ou "amigo" que estava dando as aulas... bom, o negócio não acabou muito bem pra esses.

Ao final, somente 10 pessoas tiverem notas, pois entregaram os trabalhos. Engraçado que depois do prazo final, entrega de notas, sempre tem alguém correndo atrás do prejuízo. Várias chances foram dadas, agora acho que já não posso fazer muita coisa ;)

Mãe me empresta o carro?!

2010-09-28T00:39:00.002-03:00

Aulas de multimídia

2010-09-28T00:12:00.000-03:00

Pessoal,

Estou organizando o material para as aulas de Multimídia que darei do final de outubro até começo de dezembro no INF/UFG.

Tava pensando em seguir um lado mais prático, botar o pessoal pra soltar a imaginação e dar forma a criação. Sendo assim, trabalharemos com computação gráfica, efeitos sonoros, vídeos... resumindo, jogos!!! ;)

A ideia é estudar os componentes envolvidos na criação dos jogos, entendo como eles funcionam e como são aplicados. Lembrando que esse conhecimento pode ser reutilizado em outras aplicações multimídia.

Se der ainda poderemos trabalhar com tópicos de I.A., apesar de não ser um tópico diretamente ligado a área de multimídia é algo extremamente necessário em jogos e como um jogo é uma aplicação multimídia... :D Talvez brincaremos com a mente de alguns agentes virtuais por ai. :D

Multimídia - UFG - 2010/2

2010-06-02T15:18:00.001-03:00

Pessoal,

Possivelmente eu lecionarei parte das aulas de multimidia no semestre que vem (a proposito, cade os meus acentos blogger? ... Agora tá ok! :P ). Então, voltando ao assunto, ainda está em fase de planejamento e definição do que será dado em disciplina e o que serão meus afazeres, mas preparem-se para ter seu amiguinho de blogger em sala de aula heheh... Mas podem ficar tranquilos, não irei ferrar todo mundo, bom, quem sabe... heheh :P

Ainda estou organizando o conteúdo, mas parte será bem semelhante ao que o Prof. Eduardo Simões lecionava, entretanto, estou pensando em alterar outras pra explorar tecnologias mais recentes, mas que caibam dentro do prazo apertado de 6 meses.

Mac OSX + Opengl 3

2010-02-14T01:36:00.004-02:00

Bom, apesar de ser fã dos produtos da Apple, e ter um MacBook, eu venho demonstrar minha insatisfação com relação ao suporte dos novos padrões para computação gráfica. Falei difícil, mas foi só pra ganhar espaço (heheh), estou aqui falando da falta de suporte da API OpenGL 3, mesmo no Snow Leopard.

É perfeitamente possível criar jogos com gráficos bons utilizando a API do OpenGL 2, então por que reclamar que o OSX não possui suporte para a versão 3?

Quem trabalha com jogos, geralmente gosta de estar na vanguarda das tecnologias. Isso porque nós "precisamos" consumir e utilizar do máximo de poder do hardware que for possível, e não ficar para trás, pois esse mercado anda muito rápido.

Por mais que as alterações da versão 2 para a 3, sejam basicamente um novo paradigma de programação, existem recursos novos que são bastante úteis, além de melhorias de desempenho.

Em minha opinião, a empresa que se diz estar na frente das inovações tecnológicas, também deveria permitir e acompanhá-las. Existem várias pessoas, gamers, que gostariam de ter, trabalhar ou jogar num Mac, mas que não vão pela falta de suporte para jogos e aplicações.

Nós sabemos que já existem várias aplicações suprindo parte dessa necessidade, mas e os jogos?! São muito poucos jogos presentes no OSX até o momento. Eu gostaria de aproveitar os recursos do meu sistema, a capacidade do meu hardware, as boas APIs presentes no OSX e utilizá-las em aplicações que usam realmente do hardware, isso é, os jogos, sentir o desempenho que a plataforma é capaz de propor diretamente na taxa de frames em minha tela.

Como gamer eu quero ter a possibilidade de obter os últimos jogos e utilizar das últimas tecnologias, pra tirar o máximo de proveito desses jogos. Como desenvolvedor, eu quero as tecnologias pra garantir a satisfação do jogador, provendo qualidades visuais e funcionais.

O que me frusta é saber que mesmo num sistema onde visual, simplicidade e desempenho são as palavras chaves, existe um descaso com quem realmente curte e utiliza dos gráficos e o hardware do sistema.

Não tenho o que reclamar do S.O., que considero excelente, funcionando muito bem, mas se a Apple está com medo de abrir o sistema por uma possível baixa na qualidade do produto perante o usuário, então está na hora de conversar com as outras empresas provedoras de tecnologias, tais como NVidia, ATI, para que essas publiquem suas atualizações e ainda garantam a qualidade do sistema.

Nós já estamos na versão 3.2 e mesmo com o Snow Leopard, a versão do OpenGL suportada é a 2.1. Se estivéssemos falando do Windows, onde a Microsoft possui tanto uma versão do OpenGL quanto uma do DirectX que é seu principal produto, até poderíamos entender o porque de um atraso numa versão do OpenGL, mas no OSX nós só temos o OpenGL basicamente.

Tudo bem que o Windows possui uma comunidade forte de gamers, mas será que o OSX não poderia ter uma quantidade maior de jogadores?! Vejam o sucesso do IPhone, a grande quantidade de jogos presentes nele.

Também sei que a falta de jogos no OSX não é culpa da Apple, mas das empresas desenvolvedoras, entretanto a falta do suporte gráfico adequado pode ser justamente o que impede essas produtoras de quererem publicar seus títulos na plataforma. Existem tantas engines, APIs, e ferramentas no Windows, que muitas vezes é mais prático simplesmente continuar lá, afinal o maior mercado nessa área já está lá, por pura comodidade.

Acho que com um pouco de incentivo e demonstração de interesse pela Apple, o mercado de jogos no Mac poderia se tornar muito maior, mesmo que não fossem títulos exclusivos para a plataforma.

Pra finalizar, gostaria de dizer que isso é mais um desabafo com relação a esses detalhes tecnológicos em específico. Eu possuo um Mac e posso falar que o sistema é muito bom, excelente por dizer, e existem muitas inovações presentes num Mac, que vão desde o núcleo do sistema operacional até a interface, mas ainda pode-se mais...

Linguagens C# vs Java

2009-09-06T17:20:00.003-03:00

Como todos sabem eu conheço as duas linguagens, mas reconhecidamente aprecio mais a linguagem C# do que a Java.

Estou falando das linguagens e não das plataformas (.NET e Java).

Eu reconheço claramente que o mundo Java possui ~~inúmeras plataformas~~ vários frameworks e bibliotecas que fazem inveja ao mundo .NET, além da famosa portabilidade das aplicações, apesar que essa barreira vem sendo derrubada com o Mono, mas ainda temos um longo caminho a frente.

Voltando a diferença entre as linguagens, nesse artigo (http://www.25hoursaday.com/CsharpVsJava.html) Bare Obasanjo faz uma comparação entre os recursos da linguagem C# em sua versão 2.0 e a linguagem Java 6.

Cabe ressaltar que a conclusão do autor vale ainda hoje. Já estamos caminhando para a versão 4 do C#, que de longe vai se distanciando, em recursos, da linguagem Java.

Problema da Loteria

2009-07-02T13:09:00.011-03:00

Um problema difícil de resolver e que já tomou algumas horas de sono dos computeiros, inclusive minha nessa semana, é o problema da loteria.

A ideia (nova regra diz que não tem acento, certo?!) é selecionar dentre tickets de jogos possíveis, quais, em quantidade mínima, deve-se jogar para se ganhar na loteria. Infelizmente, você não irá ficar rico dessa vez, pois é muito difícil criar um algoritmo que ache um resultado ótimo, além de que, geralmente, esse resultado ultrapassa e muito o valor que você poderia ganhar, jogando.

O problema é descrito assim: dado um conjunto T de tamanho n, qual é o subconjunto mínimo de tickets de T, onde cada ticket possui tamanho k, e garante cobrir p números no resultado final.

Exemplificando, se n = 5, k = 3 e p = 2, temos as seguintes possíveis combinações:

1 2 3
1 2 4
1 2 5
1 3 4
1 3 5
1 4 5
2 3 4
2 3 5
2 4 5
3 4 5

Sendo que uma solução seria: (1, 2, 3) e (3, 4, 5), dois conjuntos distintos que garantem a vitória, para um jogo nessa configuração. Mas de que forma eles garantem, você pode estar se perguntando? Bom, precisamos acertar dois números, no mínimo, então:

1 2 3 (X)
1 2 4 - (a seleção já possui 1 e 2)
1 2 5 - (a seleção já possui 1 e 2)
1 3 4 - (a seleção já possui 1 e 3)
1 3 5 - (a seleção já possui 1 e 3)
1 4 5 - (a seleção (de baixo) possui 4 e 5)
2 3 4 - (a seleção possui 3 e 4)
2 3 5 - (a seleção possui 2 e 3)
2 4 5 - (a seleção possui 4 e 5)
3 4 5 (X)

"Ahhh, legal, vou jogar!" heheh... cuidado! Para adaptar o problema para obter uma solução da mega-sena, teríamos: n = 60, k = 6, p = 4 (quadra).

Se combinarmos todas as possibilidades de agrupamentos de 60 números em 6 casas, teríamos a pequena quantia de 50.063.860 tickets possíveis. Ok, pode ser até fácil de gerar utilizando dos computadores atuais, mas para calcular a quantidade mínima de tickets é outra coisa...

Existem vários algoritmos, mas não lembro de nenhum ótimo no momento. Por acaso, eu inventei um olhando os resultados, coisa besta, nem sempre ótima, mas funciona. Chamei ele de BlockBreaker, então se esse algoritmo realmente existe peço desculpas pela frase, mas eu não o conhecia.

Assimindo que todos os tickets são um bloco, temos o bloco massisso, com 3 colunas de números:

1 2 3
1 2 4
1 2 5
1 3 4
1 3 5
1 4 5
2 3 4
2 3 5
2 4 5
3 4 5

Seguimos na primeira coluna de cima pra baixo, até que o valor muda com relação ao ticket anterior, quando isso acontecer quebramos o bloco:

Bloco gerado 1 - coluna 1:
1 2 3
1 2 4
1 2 5
1 3 4
1 3 5
1 4 5

2 3 4
2 3 5
2 4 5
3 4 5

Analisamos o bloco recém criado da seguinte forma: se o bloco possui tamanho 1 e não conflita em pelo menos de p unidades com os já selecionados, selecionados o ticket do bloco (marcando X). Nesse caso, não temos nada nessas condições, seguimos adiante:

Bloco gerado 2 - coluna 1:
1 2 3
1 2 4
1 2 5
1 3 4
1 3 5
1 4 5

2 3 4
2 3 5
2 4 5

3 4 5

O bloco recém criado não possui, mas o último bloco possui tamanho 1, como não temos nenhum marcado ainda, marcamos ele e seguimos da mesma forma na segunda coluna.

Bloco gerado 1 - coluna 2:
1 2 3
1 2 4
1 2 5

1 3 4
1 3 5
1 4 5

2 3 4
2 3 5
2 4 5

3 4 5 (X)

Bloco gerado 2 - coluna 2:
1 2 3
1 2 4
1 2 5

1 3 4
1 3 5

1 4 5 - (conflita em 2 números, 2 >= p)

2 3 4
2 3 5
2 4 5

3 4 5 (X)

Bloco gerado 3 - coluna 2:
1 2 3
1 2 4
1 2 5

1 3 4
1 3 5

1 4 5 -

2 3 4
2 3 5

2 4 5 -

3 4 5 (X)

Bloco gerado 4 - coluna 2:
1 2 3
1 2 4
1 2 5

1 3 4
1 3 5

1 4 5 -

2 3 4
2 3 5

2 4 5 -

3 4 5 (X)

Seguimos para a última coluna:

Bloco gerado 1 - coluna 3:
1 2 3 (X)

1 2 4
1 2 5

1 3 4
1 3 5

1 4 5 -

2 3 4
2 3 5

2 4 5 -

3 4 5 (X)

Até que no final temos:

1 2 3 (X)

1 2 4 -

1 2 5 -

1 3 4 -

1 3 5 -

1 4 5 -

2 3 4 -

2 3 5 -

2 4 5 -

3 4 5 (X)

O algoritmo é besta e bem fácil de entender, implementar tb, e achou a solução ótima para essa situação, mas infelizmente não garante sempre a solução ótima.

Outro detalhe interessante é com relação a geração dos números dos tickets, se você conhece o algoritmo de enumeração por ordem lexicográfica, vai ver que o conjunto de todos os tickets é dado pela geração de todos os subconjuntos de tamanho k, dentre os subconjuntos possíveis de n. Olhem só:

1
12
123 (1)
1234
12345
1235
124 (2)
1245
125 (3)
13
134 (4)
1345
135 (5)
14
145 (6)
15
2
23
234 (7)
2345
235 (8)
24
245 (9)
25
3
34
345 (10)
35
4
45
5

Exatamente os 10 tickets possíveis, ;) !! Lógico que essa é a ordem original, que poderia ser melhorada afim de gerar somente os tickets que você quer, mas tá ai a dica!

Vou postar o programa com os algoritmos que fizemos essa semana para quem quiser... Criei a conta no github, mas só posso colocar os arquivos mais tarde, visto que tem um bloqueio besta aqui na faculdade até para portas do git.

Spec#

2008-10-25T17:48:00.002-02:00

Alguém já ouviu falar em Spec#? Essa linguagem foi construída durante o desenvolvimento do sistema operacional singularity da Microsoft, esse sistema foi desenvolvido somente para testes e desenvolvimento de novas tecnologias e aprimoramento de compiladores. Tal linguagem contem recursos interessantes para que o compilador cheque em tempo de execução e de compilação erros comuns de programação.

A Spec# é um superconjunto de C#, isto é, espande os recursos da linguagem C# 2.0 adicionando a ela novas estruturas para construir estruturas orientadas a contrato. Um pequeno exemplo segue abaixo:

...
public int Dividir(int a, int b)
requires b > 0 otherwise ArgumentException;
{
return a / b;
}
...

Agora é esperar que eles encorporem esses recursos da Spec# dentro da C# 4.0 que está a caminho... heheh...

private or not private, that's the question!

2008-09-29T00:53:00.004-03:00

Lendo os blogs da galera do Mono e do Miguel, deparei com o seguinte: usar ou não a palavra private para declarar métodos ou variáveis no código, sendo que o padrão de C# é definir como private qualquer membro sem acesso explicitamente definido?

A discussão é meio grande, alguns dizem que deve ser usado para deixar o código mais legível, outros dizem que você deve conhecer da linguagem que usa (eu mesmo disse isso), então não seria necessário...

Ambos lados tem pontos positivos e negativos... Se você é um cara preocupado com Engenharia de Software, deve ter ouvido as palavras Legibilidade várias vezes, mas nesse caso, o que seria legível, colocar ou não?

Eu reconheço que eu uso a palavra private, simplesmente para padronizar o código, deixar todos os membros definidos da mesma forma, mas acho que vou tentar seguir a opinião do Miguel e tentar não utilizá-la, afinal ele não foi o primeiro a dizer tal coisa...

Quem quiser conferir e dar uma olhada na discussão entre aqui http://tirania.org/blog/archive/2008/Sep-28.html.

Flex 3, Date, DateInput

2008-09-26T10:02:00.000-03:00

Aparentemente é um problema que foi resolvido, mas tive até que postar o bug na Adobe.
Apparently, it is a problem that don't occurs by now, but I had to publish it in the Adobe bug forum.

Anteriormente, quando se tentava utilizar a data 04/04/2004 em algum componente de data ou num objeto Date, esse valor era ignorado, dando um problema que simplesmente mudava a data para nulo hehhe...
Previously (on supernatural!!), when you try to set the date 04/04/2004 on date components or in one Date object, this value was ignored, so the value is just changed to null or indefined hehehe...

Interfaces de uma classe pela hierarquia em C#

2008-08-11T17:59:00.000-03:00

Algumas vezes é necessário por reflexão obter as interfaces de uma determinada classe, o que pode ser feito facilmente com o método Type.GetInterfaces(). Entretanto, e se tivermos o seguinte cenário abaixo?

interface IA {}
interface IB : IA {}
interface IC : IA {}

class A : IA {}
class B : A, IB {}
class C : A, IC {}

Uma herança relativamente comum, mas se pedirmos a lista de interfaces do tipo C pelo método descrito acima, esse irá retornar: IA, IC. Mas pera aí, a interface IC herda da IA, sendo assim somente a interface IC seria suficiente... Pra resolver esse problema, é necessário realizar uma combinação dentre as interfaces do tipo e as desejadas.

Criei o seguinte algoritmo, como método de extensão, que resolve o problema e ainda filtra as interfaces pra um determinado tipo desejado:

public static IEnumerable GetInterfaces(this Type type)
{
Type[] interfaces = type.GetInterfaces().Where(typeof(T).IsAssignableFrom).ToArray();
var aux = new Type[interfaces.Length];
int auxIndex = 0;

for (int i = 0; i < interfaces.Length; i++)
{
if (interfaces[i] == null)
continue;

if (aux[auxIndex] == null)
{
aux[auxIndex] = interfaces[i];
interfaces[i++] = null;
}

for (int j = i; j < interfaces.Length; j++)
{
if (interfaces[j] == null)
continue;

if (!aux[auxIndex].IsAssignableFrom(interfaces[j]))
continue;

aux[auxIndex] = interfaces[j];
interfaces[j] = null;
}

auxIndex++;
}

for (int i = 0; i < aux.Length; i++)
{
if (aux[i] != null)
yield return aux[i];
}
}

Não está 100%, algumas melhorias poderiam ser realizadas, mas funciona muito bem para o problema. :P

Obs.: Se alguém souber como eu coloco esse código formatado dá uma dica ai heheh...

NHibernate hbm

2008-07-15T08:33:00.000-03:00

Antes de continuar os artigos, que a propósito estão bem atrasados, gostaria de fazer uma proposta a comunidade open-source.

Se analisarmos o comportamento e as dificuldades para se utilizar o NHibernate, a maior delas se chama "mapeamento objeto-relacional", isto é, los malditos ".hbm". Por mais que a estratégia os hbm seja interessante, por externalizar ao modelo de domínio detalhes da persistência, ela é muito trabalhosa.

Ao refatorarmos certa classe ou alterarmos o banco de dados, teremos problemas se não for checado manualmente esses arquivos.

Existem alternativas como o NHibernate Mapping Attributes, mas apesar do trabalho interessante dos desenvolvedores que trabalham nele, não acho uma boa abordagem, devido aos atributos não se organizarem, isto é, atributos que são aglomerados terão que ser definidos com índices para manterem sua ordem. É possível realizar a mesma implementação, com um pouco mais de trabalho, eliminando tal problema.

Analisando o comportamento e funcionamento do db4o, a idéia por trás desse é muito interessante, por permitir que eu persista qualquer tipo. Penso eu, se não seria possível adotar tal abordagem no nhibernate, como uma extensão ou uma camada acima, mas que não esconde-se detalhes do próprio. Seria algo como o seguinte:

Dado a classe abaixo:

public class MyClass {
public string FirstName { get; set; }
public string LastName { get; set; }
}

usaríamos:

var container = ObjectContainerFactory.GetContainer();
var myObj = new MyClass();

container.Save(myObj);
container.Flush();

e isso seria o suficiente para se criar uma tabela relacional contendo os dados do objeto no banco de dados, assim como o seu devido mapeamento, transparentemente...

Vou pensar e melhorar a idéia, continuo depois.

Web 2.0, Aplicações RIA, Silverlight, Flex e EXTJS

2008-06-19T10:18:00.000-03:00

Atualmente ouve-se muito sobre aplicações RIA (Rich Internet Applications), mas o que realmente vêem a ser isso?

Com o passar do tempo, o aumento no processamento dos computadores e da velocidade de acesso a internet, surgiu a necessidade de criar aplicações para empresas e/ou sites com conteúdo interativo. Inúmeras empresas começaram a utilizar a internet como forma de transferência de dados, comunicação e negócios, surgiram, então, o que nós chamamos de Aplicações ou Sistemas Web, que são sites onde é possível utilizar de um determinado serviço.

No início todos esses sistemas apresentavam um formulário ao usuário, este preenchia o mesmo e então ao clicar num botão de confirmar, todo o conteúdo da página era enviado para o servidor, incluindo os dados do formulário para o processamento. A interface era pobre em relação à integração usuário-computador.

Surgiram então bibliotecas em Javascript que utilizavam de um recurso chamado request-response para realizarem comunicações com o servidor, de tal forma que não fosse preciso o usuário recarregar a página e melhorar um pouco a interação com o mesmo. Atualmente essa tecnologia evolui e deu origem ao AJAX, facilitando muito para os desenvolvedores realizar a integração com o servidor e obter serviços remotos.

Após isso, o foco da Web mudou, os desenvolvedores, antes preocupados somente em prover serviços, agora se preocupam também em como esses serviços serão apresentados e como o usuário irá interagir com eles, surge a Web 2.0.

Os desenvolvedores ganharam ferramentas poderosas para criar conteúdos dinâmicos e interativos para a Web, além do famoso Flash, mas que permitem ao usuário de uma aplicação web ter quase a mesma sensação de estar executando um programa em seu próprio computador.

Dentre as tecnologias que surgiram temos o destaque para três: Silverlight, Flex e ExtJS.

* Silverlight
Uma iniciativa da Microsoft na tentativa de romper com o domínio do Flash sobre a internet. O Silverlight utiliza .NET por baixo, o que só isso já é uma grande vantagem e o deixa sobre o interesse de vários desenvolvedores. Entretanto, como surgiu a pouco tempo, existem poucos controles (widgets) prontos e aparenta não estar muito maduro, até mesmo com relação ao consumo de serviços, comparado com o seu principal concorrente, o Flex.

* Flex
O Flex, da Adobe, integrou XML e ActionScript em cima do famoso arquivo swf do Flash e de uma forma muito interessante. Como hoje em dia quase todos os browsers possuem plugin para o Flash, isso já o tornou portável a inúmeros sistemas operacionais e browsers. Sua interface e seus controles são muito bonitos e permitem grande poder para realizar interações com o usuário. Nativamente, possui suporte para realizar comunicações com servidores de serviços de várias formas, XML, SOAP, HTML request e ainda possui protocolos próprios como o AMF e o RTMP.

* ExtJS
Eis a opção para aqueles que não querem depender de um plugin para o browser como o Flash e o Silverlight para executar aplicações RIA. Toda a API do ExtJS é criada em cima de Javascript e de uma forma fácil de trabalhar. Possui vários controles também e suporte dentre as possibilidades de comunicação com o suporte o protocolo JSON. As interfaces geradas pelo ExtJS também são muito bonitas.

Bom, dentre as 3 opções, pessoalmente, eu escolhi e prefiro trabalhar com Flex, pelo fato de ser portável, fácil de se trabalhar e criar novos componentes. O Silverlight, por utilizar .NET me deixa muito interessado, mas ainda está imaturo quanto aos recursos de comunicação, quantidade de controles (mesmo na versão 2.0) e portabilidade (apesar do Mono estar com o Moonlight para tentar resolver o problema). O ExtJS parece ser muito bom, mas não sei quanto a manutenibilidade do código gerado, e como criei algumas ferramentas para gerar códigos para o flex, preferi não utilizá-lo.

A minha única queixa é a integração com serviços .NET, mas o FluorineFX está resolvendo bem o problema até o momento, apesar de termos opções melhores hoje para a plataforma Java, o GraniteDS e o BlazeDS.

Lado a lado: NHibernate e db4o. Parte 1 - Informações.

2008-05-26T09:33:00.000-03:00

Inicialmente vou discutir sobre algumas tecnologias que estão consolidadas entre os desenvolvedores de software que utilizam .NET, o NHibernate e o db4o.

O db4o para quem não conhece é um banco de dados orientado a objetos que promete desenvolvimento fácil e rápido, visto que o desenvolvedor não precisará realizar os famosos mapeamentos objeto-relacional, nem criar tabelas em banco de dados relacionais, e pode focar diretamente no desenvolvimento dos objetos de negócios. Pode ser utilizado tanto para aplicações embarcadas quanto para sistemas de qualquer tamanho.

Sua abordagem é simplista, uma vez aberto o container de objetos o desenvolvedor poderá salvar e manipular objetos de qualquer tipo, desde que o objeto possua sua classe visível ao escopo do banco de dados. Lembrando que, nesse caso, o escopo do banco de dados se refere a todas as classes visíveis dentro biblioteca que abre o container, incluindo classes carregadas dinamicamente.

Quando utilizando o db4o, o desenvolvedor não se preocupa com a criação de tabelas, o banco de dados se "adapta" ao formato e definições de cada classe, seus relacionamentos, etc. Desenvolvedores que utilizam o db4o possuem sempre a mesma impressão: "Essa é melhor coisa do mundo!!", "Que negócio massa!!", "Doido d+++!!!!!!!"...

No entanto, nem tudo são flores. Mesmo com o db4o existem algumas complicações. A primeira decorre da transição de bancos de dados relacionais para um orientado a objetos. No "mundo relacional" cada entidade equivale a uma tabela, equivalente a uma classe no "mundo OO", e cada tupla dessa tabela ou registro equivale a instância dessa classe. Até aqui tudo bem, o problema são as famosas e necessárias chaves primárias, que no db4o não existem, ou melhor, não devem ser utilizadas da mesma forma que num banco relacional.

Cada objeto no contexto do db4o possui sua própria identificação única que é gerada pelo próprio container de objetos do banco, isso poder acarretar num problema de adaptação para o desenvolvedor, mas nada muito problemático.

O segundo problema, talvez seja "o grande problema". Cada objeto do db4o ao ser atualizado deve ser reconhecido dentro do contexto de um container, isto é, caso o usuário abra um container, obtenha um objeto e feche o container, o objeto é considerado um novo objeto, pois não será reconhecido por outro container aberto posteriormente e se armazenado será duplicado no banco de dados, isto requer um tratamento especial ao se trabalhar com objetos desconectados do container. Esse problema, apesar se ser contornável com algumas estratégias, pode ainda ser agravado quando o objeto mantém dependências de outros objetos, pois a manutenção das referências deve ser realizada manualmente pelo desenvolvedor, isto é, ao se fazer um update em cascata, ou o desenvolvedor atualiza o objeto da referência ou deve removê-lo e então adicionar o novo, para evitar as famosas duplicações e objetos fantasmas, aqueles que o desenvolvedor achou que teria sido substituído, mas continuam armazenados.

Fora esses trabalhos a API do db4o é excelente, assim como o seu desempenho, quem trabalhar com o mesmo ficará apaixonado pelo seu modo de uso, as várias maneiras de se fazer as queries, inclusive o suporte ao Linq, que pessoalmente achei que ficou bem interessante.

Agora falaremos rapidamente sobre o NHibernate, que tenta amortizar a transição de um banco de dados relacional e seu uso num contexto orientado a objetos.

O NHibernate sem dúvidas é uma ferramenta excelente, um pouco trabalhosa, pois o usuário deve manter um arquivo XML, que contém o mapeamento das propriedades e campos da classe para os campos de uma tabela ou view num banco de dados relacional.

Possui um mecanismo de configuração que permite ao desenvolvedor construir o software independente do banco de dados que utilizará. Permite que o bancos de dados sejam mapeados mesmo depois de existentes ou seja criado um novo esquema para a representação do modelo.

O mecanismo de query do NHibernate seja via Critérios ou HQL é muito poderoso. É possível realizar queries complexas que serão devidamente traduzidas para cada banco de dados especificamente. Existem também uma implementação que permite que o NHibernate seja utilizado com o Linq e tal biblioteca virá junto com a versão 2.0 do mesmo.

O grande problema do NHibernate são os famosos mapeamentos, pois durante o ciclo de vida de qualquer software alterações acontecem, e podem ocasionar em mudanças no modelo, o que acarretam em mudanças nas classes e nos mapeamentos. Manter esses dois últimos sincronizados talvez seja a tarefa mais penosa pra quem utiliza o NHibernate.

Apesar de utilizar um mecanismo de sessão, ele não sofre do mesmo mal do db4o quanto a duplicação de dados, afinal temos um banco relacional que tratará desse problema da forma que estamos acostumados.

Para demonstrar mais sobre as diferenças desses dois bancos, irei publicar nas próximas postagens uma espécie de prova de conceito, onde para resolver um mesmo problema utilizarei ambos os bancos, mostrando as diferenças de cada na prática.

Oi pra galera

2006-08-24T18:41:00.000-03:00

Meu "primeiro" post nesse blog. Bom, na verdade não é o primeiro mas como eu não consigo recuperar a senha do antigo desisti e criei outro :P!

Irei postar aqui informações sobre meu framework de desenvolvimento de jogos (atualmente um auxiliar de desenvolvimento).

Até a próxima.