Brincando com constantes

Tudo começa com um simples programa que imprime o nome e o sobrenome.

package exemplo.entidade;

public class Testadora {

public static void main(String[] args) {
mostrarNome();
mostrarSobrenome();
}

private static void mostrarSobrenome() {
System.out.print("Sobrenome ");
}

private static void mostrarNome() {
System.out.print("Nome ");
}

}


Alguém resolve fatorá-lo, resolve deixar tudo em um único local.

package exemplo.entidade;

public class Testadora {
public static final int NOME = 10;
public static final int SOBRENOME = 20;

public static void main(String[] args) {
mostrarNome();
mostrarSobrenome();
}

private static void mostrarSobrenome() {
mostrar(SOBRENOME);
}

private static void mostrarNome() {
mostrar(NOME);
}

private static void mostrar(int tipo) {
if (tipo==NOME){
System.out.print("Nome ");
}else if(tipo==SOBRENOME){
System.out.print("Sobrenome ");
}
}

}

A principio parece estar agregando mais complexidade a algo que deveria simplesmente fazer algo trivial. Um terceiro resolve retirar os "mediadores".

package exemplo.entidade;

public class Testadora {
public static final int NOME = 10;
public static final int SOBRENOME = 20;

public static void main(String[] args) {
mostrar(NOME);
mostrar(SOBRENOME);
}

private static void mostrar(int tipo) {
if (tipo==NOME){
System.out.print("Nome ");
}else if(tipo==SOBRENOME){
System.out.print("Sobrenome ");
}
}

}

Um quarto metido a espertinho realiza uma mudança que deixa o código bem mais simpático.

package exemplo.entidade;

public class Testadora {
public static final int NOME = 10;
public static final int SOBRENOME = 20;

public static void main(String[] args) {
mostrar(NOME+SOBRENOME);
mostrar(NOME);
mostrar(SOBRENOME);
}

private static void mostrar(int tipo) {
if (tipo==NOME){
System.out.print("Nome ");
}else if(tipo==SOBRENOME){
System.out.print("Sobrenome ");
}if (tipo==NOME+SOBRENOME){
System.out.print("Nome Sobrenome ");
}
}

}

Fica simples e objetivo o propósito mostrar o nome e o sobrenome. :)

ps: favor notar que o post não discute o fato de usar ou não polimorfismo, apenas mostra um modo elegante de se aproveitar o uso de constantes.

Os altos e baixos da qualidade na conexão 3G!

Atualmente uso o link da BrT 3G para acessar a Internet. Notei que sempre houve altos e baixos, um dia a conexão está ótima outro está péssima, procurei na Internet e não encontrei nada que me ajudasse, liguei pra BrT e tive a seguinte resposta o "Windows Vista não está listado na blá blá blá blá.. por isso a rede pode apresentar altos e baixos" e a última coisa foi tentar mudar alguns parametros de configuração pra ver se alterava algo na qualidade.

Basicamente só mudei o modo preferencial da rede, pra acessar esse menu tenha certeza que ainda não está conectado na rede, clique em 1,2,3 e 4 note que o 3 (os números são referências pra figura abaixo) permite alterar o modo que a rede é escolhida.

Veja as estatísticas de quando configurei o modem pra "Preferir 3G" (neste modo há uma oscilação entre os vários protocolos : HSDPA, UMTS e EDGE [ao menos os que percebi])

* Quando digo estatísticas me refiro a saída do comando ping www.google.com.br -n 25 que executei em ambiente Windows.

Estatísticas do Ping para 209.85.193.99:
Pacotes: Enviados = 25, Recebidos = 18, Perdidos = 7 (28% de perda),
Aproximar um número redondo de vezes em milissegundos:
Mínimo = 714ms, Máximo = 4140ms, Média = 2017ms

Estatísticas do Ping para 209.85.193.104:
Pacotes: Enviados = 25, Recebidos = 19, Perdidos = 6 (24% de perda),
Aproximar um número redondo de vezes em milissegundos:
Mínimo = 578ms, Máximo = 3849ms, Média = 2697ms

Estatísticas do Ping para 209.85.193.99:
Pacotes: Enviados = 25, Recebidos = 24, Perdidos = 1 (4% de perda),
Aproximar um número redondo de vezes em milissegundos:
Mínimo = 211ms, Máximo = 4195ms, Média = 2318ms

Estatísticas do Ping para 209.85.193.99:
Pacotes: Enviados = 25, Recebidos = 25, Perdidos = 0 (0% de perda),
Aproximar um número redondo de vezes em milissegundos:
Mínimo = 920ms, Máximo = 3914ms, Média = 1890ms

Estatísticas do Ping para 209.85.193.104:
Pacotes: Enviados = 25, Recebidos = 12, Perdidos = 13 (52% de perda),
Aproximar um número redondo de vezes em milissegundos:
Mínimo = 1366ms, Máximo = 4155ms, Média = 2586ms

Estatísticas do Ping para 209.85.193.99:
Pacotes: Enviados = 25, Recebidos = 25, Perdidos = 0 (0% de perda),
Aproximar um número redondo de vezes em milissegundos:
Mínimo = 132ms, Máximo = 3696ms, Média = 1206ms

Usando o modo "Preferir 3G" quando a rede usou o protocolo HSDPA a qualidade da conexão ficou boa.

Estatísticas do Ping para 209.85.193.99:
Pacotes: Enviados = 25, Recebidos = 25, Perdidos = 0 (0% de perda),
Aproximar um número redondo de vezes em milissegundos:
Mínimo = 129ms, Máximo = 156ms, Média = 139ms

Depois que mudei o modo para "Apenas 3G" veja as novas estatísticas.

Estatísticas do Ping para 209.85.193.104:
Pacotes: Enviados = 20, Recebidos = 19, Perdidos = 1 (5% de perda),
Aproximar um número redondo de vezes em milissegundos:
Mínimo = 109ms, Máximo = 332ms, Média = 137ms

Estatísticas do Ping para 209.85.193.104:
Pacotes: Enviados = 20, Recebidos = 20, Perdidos = 0 (0% de perda),
Aproximar um número redondo de vezes em milissegundos:
Mínimo = 121ms, Máximo = 218ms, Média = 142ms

Claramente houve uma melhoria consideravel. Mesmo configurando para "Somente 3G" ainda existe a oscilação entre os protocolos HSDPA e UMTS, sempre que se usa o UMTS a qualidade da conexão é reduzida.

Conversando com alguns técnicos da BrT eles me informaram que em alguns locais o sinal 3G pode ser bem fraco ou inexistente, nesses casos é bom deixar "Preferir 3G". Eu sempre uso o "Somente 3G", até porque eu paguei foi por isso. Minha conexão ficou bem melhor após essas "mudanças", claro que as oscilações continuam mas agora são bem menores.

Jpcsp - Estado (status) atual e alguns screenshots do emulador de psp feito em java

Para o jogo Tales of Eternia (ToE) o problema de antes (a grid que aparecia na renderização) desapareceu. Novos desenvolvedores que têm ótimas habilidades com opengl somaram mais ao grupo !

Nesse momento estamos trabalhando em algumas otimizações, cacheamento de texturas, melhorando código em partes que são extremamente executadas... e claro sempre "evoluindo", o jpcsp oferece um ótimo debugger além de um sistema de logging que AJUDA muito.

Login - autenticação e autorização usando JavaServer Faces (jsf)

Este post trará (ou tentará trazer) informações básicas para o desenvolvimento de um sistema de login para aplicações web javaserver faces (jsf) . Com estas informações creio que será possível pra você implementar seu sistema de Login.

Basicamente...

O Usuario tem um nomeDeUsuario uma senha e um ou mais Perfis.

Cada Perfil está vinculado a uma ou mais páginas. (ou recursos ou qualquer nomenclatura que você quiser usar)

Uma Página é um objeto simples que tem uma descrição.

Na tentativa de resumir a estrutura seria algo semelhante a essa pseudo-modelagem...

Pagina paginaAdmin = new Pagina("/admin.jsf");

Pagina paginaNormal= new Pagina("/principal.jsf");

Perfil admin = new Perfil();

admin.temAcesso(paginaAdmin).temAcesso(paginaNormal);

Perfil normal = new Perfil();

normal.temAcesso(paginaNormal);

Usuario homerSimpsons = new Usuario("homer99","senha");

homerSimpsons.temPerfilDe(admin);

Crie um PhaseListener como abaixo.

package meu.pacote.br;

import javax.faces.application.NavigationHandler;
import javax.faces.context.FacesContext;
import javax.faces.event.PhaseEvent;
import javax.faces.event.PhaseId;
import javax.faces.event.PhaseListener;
import javax.servlet.http.HttpSession;

public class AuthorizationListener implements PhaseListener {

public void afterPhase(PhaseEvent event) {
FacesContext facesContext = event.getFacesContext();
//adiquirindo o FacesContext.
String currentPage = facesContext.getViewRoot().getViewId();
//armazenando a página que fez a requisição. (a string da pág. atual ex: "/pag.jsf")
boolean isLoginPage = (currentPage.lastIndexOf("login.xhtml") > -1);
//fazendo a verificação mais básica de todas... se é a página de login.
HttpSession session = (HttpSession) facesContext.getExternalContext().getSession(true);
//adquirindo a sessão (essa mesma onde você deverá guardar seu usuário no nível de sessão com descritor currentUser).
Usuario user = (Usuario) session.getAttribute("currentUser");
//apenas recuperando o valor da sessão.
if (!isLoginPage && user == null) {
NavigationHandler nh = facesContext.getApplication().getNavigationHandler();
nh.handleNavigation(facesContext, null, "loginPage");
//bem, se não está logado redireciona pra lógica que (navigatio rule) atende a loginPage
} else {
//verificar se o usuario atual tem acesso a página atual.
boolean temAcesso = user.temAcesso(new Pagina(currentPage));
if (!temAcesso){
//aqui a logica de não ter acesso... redicione novamente? faça algo... ???
}
}
//caso contrário o jsf passa tranquilamente por aqui!!!

}

public void beforePhase(PhaseEvent event) {
//poderia ter sido escrito nesse evento antes da "fase" (lembra do básico do jsf, o ciclo de vida e as fases...
}

public PhaseId getPhaseId() {
return PhaseId.RESTORE_VIEW;
}
}

E uma lógica pra logar o usuário na sessão...

FacesContext.getCurrentInstance().getExternalContext().getSessionMap().put("currentUser", user);

E registre essa classe no arquivo faces-config.xml. Claro, registre também um navigation que atenda a qualquer chamada para loginPage.

<lifecycle>
<phase-listener>
org.gpro.filter.AuthorizationListener
</phase-listener>
</lifecycle>

<navigation-rule>
<from-view-id>/*</from-view-id>
<navigation-case>
<from-outcome>loginPage</from-outcome>
<to-view-id>/login.xhtml</to-view-id>
<redirect/>
</navigation-case>
</navigation-rule>

Claro que o código pode e deve ser modificado para questões de flexibilidade, legibilidade e até mesmo performance. O propósito inicial era mostrar como desenvolver um sistema de login com jsf. O código mostrado foi feito apenas pra exemplificar qualquer erro ou dúvida postem aqui.

Mais informações em:

http://java.sun.com/javaee/javaserverfaces/1.1_01/docs/api/javax/faces/event/PhaseListener.html

Jpcsp - já mostra tela de jogo comercial

Depois de algum (MUITOOOOOOOO) trabalho veja a primeira screen de um jogo comercial rodando no jpcsp.

Apartidarismo

Brasil um país democrático! Bonita frase, não?!

Nesse último pleito tive chance de observar, com mais atenção, os vários arquétipos de eleitores. Infelizmente percebi que ainda existem pessoas que não usam a razão pra votar.

É simples. Existem pessoas que votam em determinado candidato em detrimento do seu partido, alguns mais excitados chegam à loucura de afirmar: "Sou XYZ em qualquer pleito". Na frase anterior troque XYZ por DEM ou PP ou PSDB ou PMDB ou PMN ou PSOL ou PT ou PTB ou qualquer outro partido que você conheça.

Por favor, eleitor seja “apartidário”... Isso não é um jogo de futebol no qual você torce por um time, pense que além da sigla existe um ser, então numa mesma bandeira há candidatos bons e ruins. Se você achar que todas as opções atuais não atendem a seus critérios, vote em branco.

Crítico mesmo é ser candidato, eles devem apoiar quem seu partido apóia... (mesmo que no fundo achem um outro mais adequado) mas você não é candidato: Não apóie siglas, não vote por elas!

Nessa transa partidária deixo um último (incisivo e repetitivo) recado: Um partido não é um time de futebol.

Não vote:
Somente por que o candidato XisIpslon está ganhando nas pesquisas.
Por que o XisIpslon é do partido XY.

Frase que odeio ouvir:
"nunca mais voto no PT" (substitua PT por qualquer outro partido)
"em todas as eleições sou PMDB até a morte" (substitua PMDB por qualquer outro partido)
(ATENÇÃO apartidarismo não é antipartidarismo)

Dsl interna e externa: perguntas e respostas por Martin Fowler

Segue abaixo a traduadaptação [datada em 01/10/2008] (meio capenga) do artigo de Martin Fowler aqui você vê o original.

Fui convidado a criar uma discussão de DSL para não-técnicos. Talvez eu tenha lido muito Stephen O'Grady, mas senti um desejo irresistível de fazê-lo do jeito Q e A (Perguntas e Respostas). Então vamos lá.



O que é uma Domain Specific Language? (ou linguagem de domínio especifico, ou ainda DSL)

Uma Domain Specific Language (DSL) é uma linguagem de programação de expressividade limitada, focada num domínio particular. A maioria das linguagens que você conhece são linguagens de propósito geral (General Purpose Languages), que podem lhe dar com a maioria das coisas que você encontra durante um projeto de sistema. Cada DSL pode agir somente em um aspecto especifico do sistema.

Então você não poderia escrever todo projeto em uma DSL?

Não. A maioria dos projetos irão usar uma linguagem de propósito geral e muitas DSL's.

Essa idéia é nova?

Não totalmente. DSL's tem sido usadas extensamente nos círculos de usuários do Unix desde os primórdios desse sistema. A comunidade Lisp discute a criação de DSL's em Lisp e então usa a DSL para implementar a lógica. A maioria dos projetos de TI usam muitas DSL's – você já deve ter ouvido de coisas como CSS, SQL, expressão regular e etc.

Então porque este assunto está fazendo tanto barulho só agora?

Provavelmente é por causa do Ruby and Rails. Ruby é uma linguagem com muitas características que tornam fácil o desenvolvimento de DSL's e as pessoas que estão envolvidas na comunidade Ruby têm se sentido mais a vontades com essa abordagem, então eles levam vantagem dessas características. Em particular o Rails usa muitas DSL's que o deixam mais fácil de usar. Isto, por sua vez, tem incentivado mais pessoas a seguir essas idéias.

Outra razão é que muitos sistemas feitos em Java ou C# precisam ter muito de seu comportamento definido de forma mais dinâmica. Isto conduziu a arquivos XML complexos que são difíceis de compreender que, por sua vez, levou as pessoas a explorar DSL's novamente.

Então DSL's podem ser usadas com outras linguagens além do Ruby?

Sim, como eu já disse, as DSL's já estavam por ai há muito tempo, mais do que o Ruby. Ruby tem uma sintaxe não obstrutiva e também características de meta-programação que a torna mais fácil para criar elegantes DSL's internas, mais do que outras linguagens como C# e Java. Mas existe DSL's internas uteis feitas em Java e C#

Qual a diferença entre DSL interna e DSL externa?

Uma DSL interna é apenas um idioma particular de escrever código na linguagem hospedeira. Então uma DSL interna feita em Ruby é um código Ruby, escrito num estilo particular que deixa a linguagem mais próxima da linguagem hospede. Tais como elas podem ser chamadas de Interface Fluente ou DSL embutida. Uma DSL externa é uma linguagem completamente separada que é "traduzida" para que a linguagem hospedeira possa entender.

Por que as pessoas estão interessadas nas DSL's?

Eu vejo que as DSL's possuem dois principais benefícios. O benefício mais comum é fazer que certos tipos de códigos fiquem mais fáceis de compreender, que se tornem mais fáceis de modificar, assim melhorando a produtividade do programador. Isto é válido para todos interessados e relativamente fácil de atingir. O benefício mais interessante, todavia, é que uma DSL bem projetada pode ser entendível por pessoas do negocio, permitindo-lhes compreender diretamente o código que implementa suas regras de negócios.

Então este é o gancho – pessoas do negócio escrevendo suas próprias regras?

Em geral eu não penso assim. É muito trabalhoso criar um ambiente que permita as pessoas do negocio escrever suas próprias regras. Você tem que fazer boas ferramentas de edição, depuração, testes e etc. Você tem a maioria dos benefícios das DSL's apenas permitindo que pessoas do negocio sejam capazes de ler as regras. Então eles podem revê-las para aperfeiçoa-las, falar sobre elas com os desenvolvedores e propor mudanças corretas da implementação. Ter DSL's legíveis ao contexto negócios é de longe menos esforço do que ter DSL's escrevíveis pelas pessoas do negócios, mas os ganhos ainda são bons. Existem momentos onde vale a pena o esforço para fazer DSL's escrevíveis por pessoas do negocio, mas esse é um objetivo mais avançado.

Você precisa de ferramentas especiais (leia-se caras)?

Normalmente, não. DSL's internas são apenas facilidades da linguagem de programação que você está usando. DSL's externas requerem que você use algumas ferramentas especiais – mas essas são open source e muito maduras. O maior problema com essas ferramentas é que a maioria dos desenvolvedores não estão acostumados com elas e acreditam que elas são complicadas de usar mais do que elas realmente são (um problema exacerbado pela pobre documentação).

Todavia há exceções no horizonte. Existe uma classe de ferramentas que eu chamo LanguageWorkbench. Essas ferramentas permitem você definir DSL's mais facilmente e também provem sofisticados editores para elas. Ferramentas assim tornam mais viáveis a construção de DSL para os negócios.

Então isto é a repetição do sonho do desenvolvimento de software sem programação (ou programadores)?

Esta foi a intenção do COBOL e não penso que há alguma razão para que as DSL's tenham sucesso onde o COBOL (e tantas outras falharam). Eu penso que é importante que DSL's permitam pessoas do negocio e desenvolvedores colaborarem mais eficientemente porque eles podem falar sobre um conjunto de regras que também são códigos executáveis.

Quando eu deveria considerar a hipótese de criar uma DSL?

Quando você está trabalhando num aspecto do sistema com ricas regras de negócios ou work-flows. Uma DSL bem escrita deveria permitir que os clientes entendessem as regras pelas quais o sistema funciona.

Isto não vai levar a uma cacofonia de linguagens que as pessoas acharam mais difíceis de aprender?

Nós já temos uma cacofonia de frameworks que os programadores tem que aprender. Isto é uma inevitável conseqüência de sistemas reusáveis, é o único jeito que temos de lhe dar com todas essas coisas que os sistemas tem que fazer hoje em dia. Na essência uma DSL não é nada mais do que uma fachada chique sobre um framework. Como resultado elas contribuem um pouquinho com a complexidade que já havia. Na verdade uma boa DSL deveria fazer as coisas melhores tornando esses frameworks mais fáceis de usar.

Mas as pessoas não vão criar muitas DSL's de baixa qualidade?

Claro, assim como pessoas criam frameworks de baixa qualidade. Mas, novamente, eu gostaria de argumentar que DSL's de baixa qualidade não causam mais danos se comparados aos que os frameworks mal projetados causam

Bons modos pra desenvolvedores

ótimo texto que "enumera" várias ideias ótimas, LEITURA OBRIGATÓRIA!

http://www.infoq.com/articles/API-Design-Joshua-Bloch

DSL o que é? qual a diferença entre dsl interna e dsl externa? quando deveria criar uma dsl? ... etc.

Para maiores esclarecimentos sobre o assunto DSL, de acordo com a opinião do Martin Fowler.
http://www.martinfowler.com/bliki/DslQandA.html e uma versão traduzida aqui
http://archsofty.blogspot.com/2008/10/dsl-interna-e-externa-perguntas-e.html.

Perguntas como: 
O que é uma Domain Specific Language? (ou DSL) 
Dsl podem ser usadas e criadas por outras linguagens sem ser Ruby?
Qual a diferença entre DSL interna e DSL externa?
Porque as pessoas estão interessadas no assunto DSL?
É necessário alguma ferramenta especial ou cara pra desenvolver DSL?
Quando deveria criar uma DSL?

São respondidas no link acima.

Não existe uma resposta definitiva, há caminhos pra solução...

Quando visitamos foruns pela Internet (sobre desenvolvimento) notamos que as pessoas estão mais preocupas em saber o que fazer? qual padrão usar? qual sigla colocar na documentação do projeto? como ser ágil com post-it? e pouquíssimas procurando o pôrque de fazer isso tudo...
O modismo não pará por aí, quando surge uma nova "buzzword" o pessoal já cria n consultorias, treinamentos online... exploram de todas as formas pra tentar faturar uns dollars.
Por isso, desde o inicio dos tempos, cautela nunca é pouco. (mas por favor também não seja um Adrian Monk)

Configurar proxy pelo código no Java

Pra quem já passou algum tempo tentando se conectar a algum sítio na Internet passando a conexão pelo proxy... aqui vai uma diquinha (besta, a proposito)      
       
            Properties systemSettings = System.getProperties();
            systemSettings.put("http.proxyHost", "10.10.10.10");
            systemSettings.put("http.proxyPort", "8784");

            Authenticator.setDefault(new Authenticator() {
                protected PasswordAuthentication getPasswordAuthentication() {
                    return new PasswordAuthentication("dominio\\usuario", "senha".toCharArray());
                }
            });

                URL u = new URL("http://www.foo.com.br");
                HttpURLConnection con = (HttpURLConnection) u.openConnection();
                con.connect();
Simples assim.

       

Screenshots e atual status do emulador de psp feito em java o Jpcsp

O desenvolvimento já está em estágio onde gráficos 3D são "plotados" na tela. Vários demos e os exemplos do nehe tutorial (sobre OpenGL) já funcionam.

"As imagens falam melhor"
A versão atual (0.08) conta com um time de desenvolvedores com grande fama no mundo da emulação. (claro que excluindo-me)


Com um recompilador (ainda em testes)


A entrada (o controle) já está emulada também.


Que ironia, o emulador de NES (8 Bits) rodando no emulador de PSP sobre uma máquina Virtual (JVM), haja indereção...


O Famoso Solitaire


Aqui em um ambiente 3D já está suportando efeito de reflexo


Mais do núcleo 3D


E pra terminar, para aqueles que amam um bom debugger;
Como diz o Taz: Olha isso!


ps: O número de FPS está baixo pois estou usando uma máquina single core e com uma placa de vídeo ruim. Em máquinas melhores os quadros sobem de 10FPS a 15FPS.

Futurama inspires me (000001)

"Which is the default port to make love?"
"In the future the O.S. will run inside us, and then we don’t deserve Linux or Windows but ChorusOS."
"What excites me isn’t the beautiful but the sensuality... and that's was the reason what I’ve choose the robot Sen5U@l1ty"

Inteligência e otimização direto no compilador Java javac

Java há muito tempo não é vista como uma plataforma computacional lenta. Parte da "nova rapidez" foi conseguida através da evolução do interpretador e do compilador java.
Os esforços e as características contidas no núcleo do interpretador e do compilador (java.exe e javac.exe), a cada nova versão, na maioria das vezes não é visto pelo desenvolvedor.

Vou apresentar um exemplo interessante (ao menos eu achei :D ):
A seguinte classe implementa a idéia da execução de um código de máquina...

public class Cpu6502{
private final static boolean isDebug = true;

public void execute(){
while(true){
int opcode = memoria[PC++];
switch (opcode){
case NOP:
log("nop executado");
break;
case ANDI:
log("and immediate executado");
...
case default:
log("opcode não suportado " + opcode);
break;
}


}

System.out.println("Fim");
}


private void log(String msg){
if (isDebug) System.out.println("6502 Debug > " + msg);
}
}

Até agora nada de novo, é necessário saber quais opcodes ainda não estão implementados ... mas e quando quisermos "tirar o pesso da saída padrão"? Basicamente é só mudar o valor do campo isDebug pra false. Ainda nenhuma novidade!!!

Realmente não há nenhuma novidade visível, veja o que o compilador javac faz quando compilamos a classe com o campo isDebug = false: (pra decompilar usei o Jode)

public class Cpu6502{
private final static boolean isDebug = false;

public void execute(){
while(true){
int opcode = memoria[PC++];
switch (opcode){
case NOP:
log("nop executado");
break;
case ANDI:
log("and immediate executado");
...
case default:
log("opcode não suportado " + opcode);
break;
}


}

System.out.println("Fim");
}


private void log(String msg){

}
}

O compilador viu que esse código nunca seria executado, dado as características do campo isDebug=false(final), então o compilador retira esse bloco... Esperto esse javac não!?
Só pra finalizar, acredito que o java.exe vê que o bloco não faz nada e simplesmente ignora-o. Esses são aqueles tipos de maravilhas invisíveis ao olho do desenvolvedor.

ps: Isso pra não citar o HotSpot... simplesmente fantástico!

Jpcsp - um emulador de psp feito em java

Depois de muito tempo sem postar nada, volto com uma notícia (in)útil: apos tanto admirar e estudar o mundo da emulação, resolvi participar ativamente de um projeto (opensource claro :) ) desses.

Nesse projeto estamos tentando emular um psp (uma máquina portatil da sony muito interessante, com hardware bem similar ao Playstation 2) usando Java como linguagem e OpenGl (JOGL) como nosso motor renderizador. A escolha dessas tecnologias visa um emulador multiplataforma e também um desafio.

O Psp é uma máquina que possui um processaor (RISC) MIPS baseado no R4000 (32-bits), também possui um GPU com 2MB de VRAM: O CPU roda a 222MHz (apesar de ir até 333MHz, por questões de economia de consumo a sony "clocou-o" de 0 a 222Mhz inicialmente, todavia em novas versões do firmware é possível rodar jogos a 333Mhz) e a GPU roda a 166Mhz. Tem 32MB de Ram, algumas versões novas do psp já vem com 64MB, enfim é se trata de um aparelho muito interessante.

O projeto atualmente está rodando algumas demos e o time de desenvolvedores estão integrando código (commit) praticamente todos os dias, a velocidade de desenvolvimento está ótima. Pra quem deseja conhecer mais sobre o projeto há os links abaixo.


Links.
Site Oficial: http://www.jpcsp.org/
Forum oficial: http://jpcsp.org/forum/
Repositório: http://code.google.com/p/jpcsp/source/list

Artigo sobre dsl interna publicado na mundo java

Nesta última edição (30) da revista Mundo Java foi publicado um artigo que escrevi sobre dsl interna em java. O mesmo foi publicado na sessão Mundo OO.
Toda crítica é bem-vinda! :)

Pra quem for comprar a capa é essa.

Mundo OO: Implementando uma dsl Interna
Projetando e codificando uma domain-specific language interna usando a linguagem Java.

o primeiro emulador do console nintendo wii já da alguns passos

O primeiro rascunho de emulador dos consoles da 7º geração de video-games já está sendo desenvolvido. Melhor notícia que essa talvez seja que, tanto a 6º quanto 7º geração da Nintendo estarão em um único emulador, ou seja, dentro de alguns anos você poderá jogar jogos do Game Cube e Wii no mesmo emulador.

Tanto Game Cube quanto o Wii tem arquitetura PowerPC (IBM), além de outras similaridades (como GPU da ATI...), o que contribuiu para que a equipe que já desenvolvia o emulador do Game Cube começasse um projeto para o Wii.

Pra rodar, satisfatoriamente, esse emulador é necessário ter uma máquina de gamer. O emulador oferece dois modos pra emulação do processador, interpretação dos opcodes (lenta) ou recompilação dinâmica (bem mais rápida), a DynaRec requer processadores com aquele conjunto de instruções SSE2 (note que no repositório já se fala do uso até mesmo do récem SSE4 [ Core2Duo e8400 possui, não conheço nenhum AMD que tenha :( ]), claro que uma GPU ("placa de vídeo") de ótima performance também é necessária. Se tentar rodar o emulador em uma máquina média terá algumas decepções.

A pergunta que fica provavelmente é como emular ou adaptar o Wii Remote ( e seus Acelerómetros) para PC?!
Bem acredito que isso será contornado, problema maior será o próprio console mas é muito cedo pra qualquer afirmação, apenas dúvidas nesse momento são certas.

Veja algumas screens

Game Cube - Super Mario Sunshine(17-36 FPS)


Game Cube - Zelda Wind Waker


Wii - Sega Superstars Tennis



Links:

Repositório
svn

Mais Screenshots (inclusive de algums jogos do wii)
Aqui

Feedback, dê suas sugestões técnicas
Issue List

ATENÇÃO: você só pode jogar legalmente uma rom (iso ou dump do seu jogo) se possuir a original.
ATENÇÃO: o emulador está em desenvolvimento, mostrará melhores taxas de FPS e correções de bug com passar do tempo, não é tão estavel quando um do super nintendo.
ATENÇÃO: quase todas as marcas, produtos e idéias são de propriedade da Nintendo.

Siglas 3 letras - MDA MDD DDD DSL TDD xxx ??? yyy

Maior vocabulário ou vocabulário mais pobre?!
Tente "advinhar" quantas siglas você conhece (só no que tange o desenvolvimento de software) com três letras... chute um número! Tenho certeza que errou.
Siglas são mais fáceis de serem usadas pra criar um vocabulário, claro que o excesso delas também pode gerar um vocabulário pobre.

Conhecemos bem mais siglas do que imaginamos...
Pense bem qual a quantidade (real) de siglas com três letras você conhece: jcp, jsp, asp, php, orm, jpa, jsf, dsl, cvs, svn, ejb, sql, ddd, soa, aop, tdd, .net, uml, oop, cpu... enfim, isso sim é um vocabulário próprio, que pode ajudar a comunicação ou criar modismos ou vender consultorias e por ai vai..
ps: isso sem contar todas as extensões de arquivos que acostumamos a usar no dia-a-dia (doc, txt, exe...)

Take care
O cuidado fica para o uso correto das siglas. Por favor, tente usar só siglas que realmente você conhece. Evitar modismos é necessário, ser até mesmo chato com uma nova sigla (ou tecnolgia, framework, metodologia, processo...) que surge, não aceitando-a facilmente.
Uma das maiores bagunças, atuais, pra mim é a correta definição e uso do desenvolvimento guiado (orientado|voltado) aos modelos. Tem gente que acha que isso e ferramenta case é tudo igual outros dizem que a idéia original (e problemas) persistem...

Boas referências! (boas nada, ótimas mesmo)
Um ótimo artigo pra ler...uma visão "crítica" sobre os atuais modismos e usos [in]adequados para desenvolvimento orientado por modelos Model Driven Software Developement
Outro artigo crítico e bom é o artigo Empresa Três Letrinhas do Phillip Calçado (P. Shoes)

Subversion 1.5 já liberado ( svn 1.5 )

Tanto clientes como servidores deverão ser atualizados, porém pode-se atualizar o servidor ... depois o cliente....
Funciona com repositorios antigos, alias você DEVE executar o upgrade command, para que os repositórios antigos entrem no novo formato.
Para quem deseja conhecer as "melhorias" veja...
Notas do lançamento.

As atribuições de um arquiteto de software

Na última edição da revista The Architecture Journal ,de número 15, foi tratado quais são as atribuições de um arquiteto de software, o pôrque de um arquiteto, quais habilidades são requiridas e etc. A edição ainda traz, como de costume, o perfil de um arquiteto para ser analisado.
Gostei da edição porque simplesmente há vários pontos de vista sobre "essa" profissão, há esclarecimentos sobre o que faz, qual a necessidade de conhecimento técnico. Enfim são várias opiniões sobre o mesmo assunto com diferentes pontos de vista.

Resumo.

* Foreword
* We Don’t Need No Architects
* Becoming an Architect in a System Integrator
* Architecture Journal Profile: Paul Preiss
* The Open Group’s Architect Certification Programs
* The Need for an Architectural Body of Knowledge
* A Study of Architect Roles by IASA Sweden
* The Softer Side of the Architect
* An A-Z Guide to Being an Architect

Para essa edição (15 - The Role of an Architect)
Acesse o site aqui. (já adianto que não é sobre como usar tecnologias (nem .net nem java))

Mais do mesmo

Depois de ler + um ótimo post .
Darei mais alguns exemplos que já vivenciei:
lógica para somar pontos a clientes...

cliente.setPontos(cliente.getPontos()+1);
(e isso se espalhava por todo código...)
Se alguma data do ano (especial, comemorativa, aniversário da loja...) quisesem oferecer uma promoção de a cada compra o cliente aumentaria os pontos em 10 seria MUITO chato...

Mais simples
cliente.adicionarPontos();
Se houvesse alguma mudança bastaria fazê-la no método.

Ou ainda quantas vezes vi algo semelhante...

if (funcionario.getSalario() > 1000.0d){
funcionario.setAjuste(0.03d);
//além do fato do pessímo uso dos double, float para $
}

Um comportamento que deveria ser interno ao "objeto" funcionário sendo tratado em outro local, talvez melhor seria algo como... (o próprio método do funcionário conter essa "lógica")

public double getAjust(){
if (getSalario()>1000.d){
setAjuste(0.03d);
}
}

ps: acredito que tudo visa um final menos complexo.(final = manutenção) Centralizar os comportamentos nos objetos...

JPA em ambiente de produção (I)

Algo interessante a se notar é que algumas configurações podem ajudar a reduzir o impacto do uso de um framework ORM/persistência...
Por exemplo, "algumas" implementações do JPA oferecem a possibilidade de que o próprio framework crie, atualize e delete o esquema de tabelas, todavia esse tipo de recurso pode ser não desejável em ambientes de produção.

Veja o exemplo da implementação hibernate:
propriedade hibernate.hbm2ddl.auto
"Automatically validate or export schema DDL to the database when the SessionFactory is created. With create-drop, the database schema will be dropped when the SessionFactory is closed explicitly."

Ou seja, toda primeira vez que criarmos uma "session factory" [no caso EntityManagerFactory do JPA] o framwork vai tentar criar, validar ou etc. mesmo que o banco com as tabelas já existam. Pra quem dúvida basta observar o console, irá notar que o jpa tentar criar com ddl todo o esquema.

Outro caso é a implementação toplink:
propriedade toplink.ddl-generation ...

Enfim é interessante desligar essas opções em produção, aproveitar para deixar livre para outras coisas como logger...

Testes unitários são criados para serem usados

É incrível ver pessoas escrevendo testes unitários apenas pra dizer que testam, não os usam realmente.
Um dos reais benefícios dos testes está em como um bom conjunto de testes pode ajudar em manutenções futuras do software, é necessário guardar esse conjunto de testes.A cada manutenção no software você pode rodar TODOS os testes (não só os novos que você fez... pra essa nova característica) e notar se houve alguma mudança em outras partes do código, não pense que sempre uma pequena mudança não irá afetar outras.
Alias não pense ou ache, teste!


Testes podem ajudar mais do que parece.
Faça, use, guarde e reuse seus testes.

dsl externa - como uma especificação pode te ajudar a compreender-las

Procurando ajuda sobre uma especificidade do java, encontrei a seguinte referência: The Java Language Specification, Third Edition

Neste "livro", sobre a especificação do java, há dois capítulos interessantíssimos para quem está interessado em dsl. Os capítulos são:
Grammars
Lexical
Para se desenvolver uma mini linguagem de um domínio especifico (dsl) é importante conhecer conceitos sobre como criar-la e como as coisas funcionam. (não é necessário nem citar que conhecer o domínio em questão é IMPRESCINDÍVEL ou mesmo criar uma "linguagem" comum entre desenvolvedores e experts do domínio [ubiquitous language])
Nestes capítulos há bons textos que explicam sobre o desenvolvimento de uma sintaxe, palavras chaves, totens e outros aspectos interessantes. Com toda certeza os capitulos não irão cobrir todo o assunto, falta vários outros aspectos como "compilação"... mas acredito que os mesmos possam ajudar.

PS: perdão pelo título (nada criativo).

Sistemas são todos iguais... (até onde vai o reuso)

Fale-se sempre de domínio (especifico) para cada sistema... Também é bem dito que do domínio se aproveita pouco ou nada, aproveitamos mais de camadas de infraestrutura.

Mesmo assim "há grupos de pessoas" que insistem em vender um portal (sistema) que serve pra toda situação, ou seja, o portal da Globo.com pode ser também o portal da Gamespot.com, mesmo que portais (ou qualquer "coisa") tenham conceitos similares, um mesmo conceito de notícia para um portal pode ser totalmente diferente de outro, talvez pode até marcar o sucesso de um portal a visão desse "conceito" voltado aquele domínio especifico.

As empresas que compram esses portais "gerais" sempre recaem em se adaptar para usufruir do bem adquirido. Mais ou menos assim, "o cliente deve moldar seu negócio para que o mesmo caiba no sistema."

Comprei uma placa de vídeo de uma empresa (xfxforce.com), a placa de vídeo não oferece o controle de velocidade da ventoinha (fazendo um barulho ensurdecedor), logo pensei: "- Entrarei no site e vou mandar um email enfim tentar um contato para saber o que posso fazer."

Tive uma ótima surpresa, a empresa XFX oferece um sistema de suporte que agiliza e muito o processo de suporte dessa empresa (domínio especifico) funciona mais ou menos assim:

Todo produto que compra deles tem um número serial.
Logo você se cadastra no site e cadastra seu produto.
(não preciso descrever o que comprei apenas coloco o serial)
Bem depois de registrado o produto posso abrir um ticket para suporte.
Esse tal ticket funciona como um bilhete no qual você escreve sua dúvida/reclamação/sugestão para um técnico da XFX.
Assim o ticket fica em estado de "Com o técnico".
Tão logo o técnico responder ao ticket, o sistema envia um email avisando...
O ticket fica em estado "Com cliente"... e assim vai até resolver o problema.

Obviamente há mais recursos, mas o ponto aqui é este sistema funciona muito bem para o negocio da XFX (domínio especifico). Talvez se uma outra empresa quisesse criar um sistema para suporte online poderia com certeza aproveitar as idéias do sistema da XFX todavia não teria muito sucesso se usasse o mesmo sistema completamente.

As vezes o reaproveitamento das idéias juntamente com o entendimento do domínio especifico podem transformar um sistema (mcdonald) em algo com muita qualidade voltado realmente a resolver "aquele problema" não "o problema" de todos [lembra um pouco de arquitetura de referência] , que merece até mesmo citações como essa...

Nomes são importantes

Lendo o post do Fabio Kung [aqui] achei muito interessante a maneira como ele conseguiu mostrar onde os repositórios (do modo DDD de se desenvolver sistemas) se encaixam e porque usá-los.
As vezes explicar o porquê de se usar um repositório se parece com a explicação (a algum iniciado na tecnologia oo) do porquê de tanta indireção nos sistemas "oo".

O primeiro mashup agente nunca esquece...

Um mashup é um website ou uma aplicação web que usa conteúdo de mais de uma fonte para criar um novo serviço completo.

Definição da wikipédia.

Há alguns anos estava trabalhando num sistema web um "quase-portal", no projeto foi me pedido para que oferecesse um "atalho" para o email corporativo (na época hospedado numa empresa terceirizada). Foi ali que compus meu primeiro mashup tive que me virar para aproveitar o serviço (já pago) d'outro site no "quase-portal", foi algo simples naquele momento tenho certeza que nem tinha idéia do que havia feito.

Entrevista com Refraction, codificador do projeto PCSX2 - um emulador do Playstation 2.

Se há um grande projeto do qual posso afirmar que complexidade é o ponto alto, é o PCSX2, um emulador da famosa máquina Playstation 2.
Esse projeto conta com um time de desenvolvedores que entre outras várias coisas constroem software de maneira ágil.
Fiz a entrevista com Alex (conhecido como Refraction) e tive várias boas surpresas, por exemplo, eles usam visual studio 2005, tratam o projeto como um hobby não um trabalho... enfim melhor ler pra entender.

Entrevista traduzida:

Leandro:Primeiro qual o seu nome, onde você mora, alias conte-nos um pouco da sua história no desenvolvimento de software?
Alex: Meu nome é Alex, moro em Plymouth, Inglatera, desenvolvimento de software pra mim sempre foi um hobby, comecei com Visual Basic no ano de 2000, logo entre 2002 e 2003 eu fiz meu primeiro emulador (bom e velho *chip8!) usando a linguagem C, cuja tinha mexido um pouquinho pouco tempo antes, eu então passei para a bagunça que é a emulação do GameBoy, isso foi um gancho para trabalhar no time do PCSX2, comecei ajudando bem pouco, então Saqib (formalmente conhecido asadr) perguntou-me se queria juntar-se ao time, ai eu fui pra lá.

Leandro:Como nasceu o time do PCSX2?
Alex: PCSX2 foi criado pelos desenvolvedores do PCSX, Linuzappz e Shadow. Eles tinham terminado com muita acurácia a emulação do PS1 e descobriram o que o próximo passo lógico era dar gás a emulação do PS2, então o PCSX2 nasceu.

Leandro:O time de desenvolvimento é bem integrado?
Alex: Não tanto, o que você quis dizer com integrado, perto um do outro? na amizade sim, mas não tão perto perto perto. Embora nos continuemos bem.

Leandro:Que ferramentas vocês utilizam neste projeto?
Alex: Usamos sourceforge SVN e Visual Studio 2005. Alguns plugins, uso da **SDL, DirectX e OpenGL pra fazer o que for necessário para obter sucesso.

Leandro:O time de desenvolvedores segue algum padrão que vocês estabeleceram?
Alex: Nós não seguimos padrão nenhum, até porque isto é um hobby não um trabalho :)

Leandro:Há algum desenvolvedor responsável por coordenar as ações/atividades do projeto?
Alex: Não ia durar muito coordenando, às vezes dizemos "larga de ser preguiçoso e faça algum código" mas isto quase não é feito :p

Leandro:Vocês tem metas atribuídas por alguém ou apenas o desejo de construir bom software?
Alex: Definitivamente o desejo de construir bom software. Ultimamente o objetivo é ter uma boa emulação do PS2, mas isso é o jeito que as coisas vão.

Leandro:Qual é o melhor e o pior aprendizado que você pode ter no projeto?
Alex: Você quer dizer no projeto? Hmm, eu suponho que seria o ***timming do PS2, isto é dor além palavras.

Leandro:Você conhece algum dos membros pessoalmente?
Alex: Eu conheço dois dos meus testadores beta, CKemu e General Plot, eu conheci ambos.

Leandro:Que tipo de mecanismos vocês usam para se comunicarem?
Alex: Normalmente MSN e IRC, embora IRC tende ser menos sério.

Leandro:Qual recado você pode deixar para os usuários ansiosos?
Alex: Hmmm, no momento as coisas estão paradas, tudo que posso dizer é que em breve os usuários não precisarão ficar tristes por não possuírem o console, esperançosamente iremos ter uma alternativa grátis pra vocês, mas eu não tenho a data exata deste momento:)

Leandro:O cara Brasileiro no projeto (GoldenFinger) está ativo?
Alex: Não atualmente, ele até falou de uma volta, ele está inativo por anos, acredito que ele está ocupado no momento :)

Thanks
Refraction

*chip8 = uma máquina bem simples, que tem como forma de interação um teclado numérico, bem conhecida porque quem começa a desenvolver emuladores.
**SDL = Uma API cross-platform para escrever jogos ou tratar multimídia.
*** Timming = é clock interno (que também deve ser emulado) da máquina PS2.

Impressões:
Incrível como um software tão complexo pode ser construído por pessoas que estão geograficamente distantes. Só como ressalva o PCSX2 em processadores dual core (seja X2 (AMD), ou duo (Intel)) já está rodando em média de 20 a 50 fps.

Links interessantes:
Página oficial
Código fonte
Blog oficial
Forum oficial
Página de downloads
Beta releases
SVN Browser

A entrevista original:

Leandro:First what is you name, where you live actualy, btw tell us a bit of your history on computer software?
Alex: my name is Alex, i live in Plymouth, England, software development for me has always been a hobby, i started with VB back in 2000 and meddled in little bits here and there, then in 2002-2003 time i made my first emulator (good old chip8!) in C, which id picked up merely a few months before hand, i then went on to mess with Gameboy emulation then got hooked on the PCSX2 Team's work, i began helping out on bits, then Saqib (formally known as asadr) asked me to join the team, it went from there.

Leandro:How was born the PCSX2 team?
Alex: PCSX2 was created by the developers of PCSX, Linuzappz and Shadow. They had pretty much finished accurate PS1 emulation and figured the logical next step to fuel their coding needs would be to move on to PS2 emulation, so PCSX2 was born.

Leandro:The development team is quite integreted?
Alex: Not quite sure what you mean here, do you mean "close"? in a friend sort of way yes, but not close close. We get along fine though.

Leandro:Which tools you use on this project?
Alex: We use sourceforge SVN and Visual Studio 2005. some plugins use SDL, DirectX and OpenGL to do what they need to succeed.

Leandro:All the team follow some pattern that you stabelished?
Alex: We dont really follow any pattern, after all it is a hobby, not a job :)

Leandro:Some of the developers are responsible for coordinating the actions / activities of the project?
Alex: Not much coordinating goes on, sometimes we go "stop being lazy and do some coding" but thats as far as it goes :p

Leandro:You have targets set by someone or just the desire to build the good software?
Alex: definately the desire to build good software. Ultimately the goal is to have good PS2 emulation, but thats a way off yet.

Leandro:What is the best and the worst learning you could retrive from the project?
Alex: Do you mean part of the project? hmm, i suppose it would be the timing of the PS2 system, its a pain beyond words.

Leandro:Do you know some member personality?
Alex: I know 2 of my beta testers personally, CKemu and General Plot, i have met them both.

Leandro:What kind of mechanism you use to comunicate between members?
Alex: usually MSN and IRC, although IRC tends to be less serious.

Leandro:What scrap you can tell for anxious users?
Alex: Hmmm, at the moment things are a little dry, all i can say is hopefully soon users wont need to worry about not owning the console, hopefully we will have a free alternative for you, but i have no dates of completion :)

Leandro:The Brazilian guy on project (GoldenFinger) is active?
Alex: Not currently, hes talked about comming back as he was inactive for a few years, but i think hes a bit busy at the moment :)

Thanks
Refraction

Práticas comuns em construção de sistemas

Introdução

Há uma prática difundida em projetos de software no mundo todo, o uso de diversos ambientes para a construção de sistemas. Em resumo funciona assim, o sistema é construído num *Ambiente de Desenvolvimento*, passa para um *Ambiente de Homologação* e finalmente vai pra *Produção*.
Um ambiente pode ser entendido como um local físico no computador (uma pasta ou computador) mais um conjunto de softwares auxiliares para execução do produto(software). Nesse ambiente é que fica os aplicativos necessários para que aplicação seja executada. Por exemplo: um projeto web feito em asp, normalmente utiliza os seguinte aplicativos: o servidor web IIS, um SGBD qualquer e os arquivos .asp; num projeto web para Java necessita de um container web, um SGBD, a JVM e os códigos(.class, .jsp). O importante é notar que estes aplicativos devem estar em todos ambientes e com as mesmas versões, para que o desenvolvimento seja eficaz, executável e testável em todos ambientes. A replicação de estrutura entre os ambientes.


Ambiente de Desenvolvimento

Quando se desenvolve (código mesmo) ou dá manutenção nas aplicações de uma empresa usa-se o ambiente de desenvolvimento. Nesse ambiente é que fica o código em desenvolvimento que pode ser testado também, ou seja, gerá código executável (não exe, mas no sentido de código funcional).
Existem vários elementos que fazem parte desse ambiente um deles é o...

Source Code Control: São ferramentas que agilizam o processo de unificar o local onde os códigos ficam, os mais conhecidos são: CVS, SVN e Source Control (MS).

E neste ambiente que os *diversos desenvolvedores constroem o código* e "comitam" ( o ato de jogar o código no servidor de código ) e testam. Obviamente a ferramenta mais utilizada neste local é um IDE (VS2008, Eclipse, Netbeans, DephiSuite ...) e o sistema de versionamento de códigos.


Ambiente de Homologação

O sistema vem pra esse ambiente quando já o mesmo já foi produzido e testado no ambiente de desenvolvimento. Esse ambiente pode ser entendido como *ambiente de testes finais*, antes de ir para o usuário gestor do sistema.
É comum neste ambiente *encontrar falhas*, criar um lista com check-list sobre os erros encontrados e repassar-los aos desenvolvedores, para *fix* (outro termo usado para designar o conserto de alguma falha).
O importante é notar que neste ambiente é *ótimo se os testadores forem externos ao desenvolvimento*, ou seja, outra equipe mesmo irá homologar (o ato de certificar que o software está bom para ir para prateleira) o software, usar a mesma pessoa que desenvolve para homologar pode induzir a falhas terríveis.
Algumas empresas de código fechado, neste ambiente não há como ver o código fonte.


Produção

Aqui o produto já está na mão do usuário final, já está em uso oficial, importante notar aqui se todos os comentários de DEBUG foram limpados do código, se todos os dados fictícios de testes foram removidos, se as senhas para acesso ao SGBD foram trocadas, enfim *aqui é sistema final*.

Versões e nomenclaturas


Quando estamos a procura de um software nos preocupamos com várias coisas como qualidade, quem produziu se o mesmo é grátis, de código fonte, pago...
Muitas vezes nos deparamos com produtos com alguns sufixos como M, B, RV, RC...
Para o entendimento dessas diversas siglas utilizaremos um exemplo simples um sistema de gestão de RH, conhecido como OpenRh.

Se tiver:
*OpenRh.1.0.0.1A * - Significa que o software ainda é Alfa. (testes internos com os testadores da empresa)
*OpenRh.1.0.0.1B* - Significa que o software ainda é Beta. (testes externos com os usuários finais)
*OpenRh.1.0.0.1RC* - Significa que o software é o Release Candidate. (Provável versão final, uma após a B)
*OpenRh.1.0.0.1* - Significa que o software é o final. (Também conhecido como de produção ou ainda stable)
ps: as vezes utiliza-se algumas nomenclaturas como .final ou .stable para definir que o software já está pronto para o mercado.

Para entusiastas ainda há a possibilidade de adquirir software enquanto estão em ambiente de desenvolvimento.
*OpenRh 2.0.0M1* - Significa que o software que teve alguma mudança significativa e assim foi feito um Marco esse marco normalmente é numerado logo pode se ter M1 M2 M3... (Milestone)
*OpenRh 2.0.0R301* - Significa que o software está na revisão 301 no repositório de códigos, aqui a cada commit o usuário (mais fanático) pode testar software feito no dia.
Obviamente esses nomes podem sofrer algumas alterações mas o sentido continua o mesmo.
Ps: Também há o .src que é exatamente o código fonte do projeto em questão.


Conclusão


A principio parece mais burocracia ao desenvolvimento de sistema, todavia as grandes empresas tem notado em experiências sólidas que o uso de diversos ambientes reduzem e muito a quantidade de erros que os sistemas poderiam ter ao serem lançados.
Questões gerenciais ficam bem facilitas com o uso de diversos ambientes. O uso de um repositório de código hoje é essencial, necessário. Seguir boas práticas que grandes empresas seguem pode tornar seus problemas mais gerenciáveis, estar preparado para mudança é o rumo da T.I.

Texto: Autor desconhecido.

Bom link para ler...

Muito tempo sem postar nada. Venho com apenas um link parar o novo Livro de Martin Fowler - DSL (WIP).

REST - Breves esclarecimentos sobre o estilo arquitetural

Primeiro esclarecimento:
REST é um estilo arquitetural (simples assim), que pode ser aproveitado para o desenvolvimento de aplicações que utilizem uma rede de comunicação, o termo foi "inventado" por Roy Fielding na dissertação de Ph.D dele.

Segundo esclarecimento:
REST não é um padrão, especificação, ou seja, você não irá ver a Sun, Microsoft ou IBM vendendo um Toolkit para REST. Simplesmente REST é um estilo arquitetural, você pode compreender-lo e desenvolver seus serviços para web (aplicações, web services ...) nesse estilo.

Um exemplo do uso deste estilo arquitetural (REST)

A Web...
Você deseja um serviço, por exemplo um dicionário online.
Você procura esse dicionário (normalmente usando outro serviço de busca da Web).
Como resposta você obtém uma URL que identifica unicamente aquele recurso (serviço). [ www.dicionariorest.com.br].
Pronto agora você consegue tal serviço.

Um ótimo jeito é dar outro exemplo

Uma empresa Xyz deseja oferecer serviços na web que habilitam seus clientes a:

1 - Obter uma lista de produtos.
2 - Obter informação detalhada sobre um produto.
3 - Comprar usando a Internet.

Como seria o jeito REST de se resolver isto.

O serviço está disponível pela URL (única), no exemplo o cliente do serviço deve usar a URL para ter acesso ao serviço.
www.lojadementira.com.br/produtos
O retorno óbvio é uma lista de produtos (HTML) todavia poderia ser especificado qual o tipo de recurso queriamos, por exemplo.
www.lojadementira.com.br/produtos&tipo=xml
Supondo que o serviço retornasse o seguinte xml:

[?xml version="1.0"?]
[lista]
[produto id=www.lojadementira.com.br/produtos/001][/produto]
[produto id=www.lojadementira.com.br/produtos/002][/produto]
[produto id=www.lojadementira.com.br/produtos/003][/produto]
[produto id=www.lojadementira.com.br/produtos/004][/produto]
[produto id=www.lojadementira.com.br/produtos/005][/produto]
[produto id=www.lojadementira.com.br/produtos/006][/produto]
[/lista]


Não reparem na sintaxe (provavelmente) errada do xml acima. Notem a característica chave do REST: A lista própria já traz como acessar o serviço de detalhes do produto. O cliente se transfere de um estado para o próximo examinando e escolhendo entre as alternativas.

Ótimo agora com a lista, o cliente escolhe o produto [www.lojadementira.com.br/produtos/005] e como retorno obtém um novo xml.

[?xml version="1.0"?]
[produto id=1]
[name] tutorial sobre REST [/name]
[price]18.8[/price]
...
[/produto]

(ps: claro que www.lojadementira.com.br/produtos/005 não é se trata do endereço físico da página html www.lojadementira.com.br/produtos/005.html, é somente um modo de acessar unicamente aquele recurso, todavia essa descrição detalhada do produto pode (e deveria) ser dinâmica.)

Algumas características do REST (baseada em redes)

* Geralmente usam-se interfaces unificadas.
GET, POST, PUT e DELETE par prover serviços.
* Stateless: Toda requisição precisa conter toda informação necessária para atender a requisição.
* Tudo é um recurso e tudo é adiquirido/executado pela URL.

Principios do REST

* Dê a tudo (os recursos) um ID (URI)
* Link tudo
Por exemplo um pedido:
[order self='http://example.com/customers/1234' ]
[amount]23[/amount]
[product ref='http://example.com/products/4554' /]
[customer ref='http://example.com/customers/1234' /]
[/order]


Nesse pedido posso facilmente encontrar os recursos relacionados a ele, como cliente e produto.

* Use métodos padrões

Se tudo é um recurso com identidade...

class Resource {
Resource(URI u);
Response get();
Response post(Request r);
Response put(Request r);
Response delete();
}

Exemplo número 9.001

Supondo as seguintes classes de serviço:

public class ServicoGerenciamentoDeProduto{
+getDetalhesDoProtudo()
+atualizarProduto()
+inserirProduto()
...
}

public class ServicoGerenciamentoDeCliente{
+getTelefoneComercial()
+atualizarCliente()
+inserirCliente()
...
}

Num modo REST de resolução poderia ser criado algo semelhando a isso.

interface Resource{
+GET
+PUT
+POST
+DELETE
}

E fazer as classes de serviço implementarem essa interface (um dos princípios sobre a padronização). Essa implementação é por recurso, normalmente um serviço expõem mais de um recurso.


Desculpem pela quantidade de exemplos mas o assunto é muito "abstrato" ou no mínimo díficil de se explicar, acredito que com exemplos ficará mais claro.

Conclusão.

Francamente gostaria de ter deixado mais claro o que é REST e como aplicar, mas estou achando que não consegui, assuntos sobre estilos arquiteturais são complexos de ser entendidos e explicados. Talvez uma leitura nos links abaixo facilite o entendimento. Enfim usar REST é apenas utilizar melhor o jeito HTTP de ser.


Fontes e bons links:
http://www.xfront.com/
http://www.fragmental.com.br/
http://rest.blueoxen.net/cgi-bin/wiki.pl?BenjaminsRESTTutorial
http://forum.rubyonbr.org/forums/1/topics/2212#posts-12150
http://java.sun.com/developer/technicalArticles/WebServices/restful/
A Brief Introduction to REST by Stefan Tilkov


Ps: não se trata de um tutorial ou faq sobre o assunto. Possivelmente há erros no texto, qualquer correção ou adição de informação será bem-vinda.

Um (mal) programador Java aprendendo Ruby - Parte 1

Algumas características interessantes do Ruby fazem algumas tarefas mais rápidas. Em um programa oo para saber se um objeto é uma instância de uma determinada classe.

Em Java:
objeto instanceof Classe

Em Ruby:
objeto.is_a? Classe

Quando desejo usar herança:

Em Java:
public class Filho extends Pai

Em Ruby:
class Filho < Pai

Quando desejo criar um método que retorne a soma entre dois números:

Em Java:
public int soma(int v1, int v2){
return v1 + v2
}

Em Ruby:
def soma(v1,v2)
v1+v2
end

"Lançando exceções".

Em Java:
if (saldo < saque) throw new Exception("Sem fundos!")

Em Ruby:
raise Exception.new("Sem fundos!") unless saldo > saque

Algo que percebo é que as vezes para implementar características em Ruby, gasto menos linhas de código para o mesmo propósito quando usava Java (bem como o código se transforma em algo mais expressivo também). A principio esta característica de escrever menos assusta e logo vêm milhares de perguntas a cabeça como: quando e como retorno o valor... essa tipagem dinâmica, sei não viu... . Bem sobre algumas características (como o retorno do método) o Ruby utiliza algumas convenções:

Ao invés de digitar ; (em Java, C, C++, C#) para quebra de linha apenas usa o Enter para tal.

Ao invés de usar a palavra-chave return [mesmo que você possa utilizar-la] o Ruby entende que seu último comando será o retorno do método, todavia se quiser usar o return poderá também.

Quanto a tipagem dinâmica não sei muito sobre... quando souber posto aqui.

ps: Este post não é de forma alguma um "flamewar" para provar que uma linguagem é melhor do que outra...

Ruby: usando classe aberta (open classe)

Extender (não no sentido "carregado" da herança) uma classe já existente.... Interessante recurso, lembro de algo similar no mundo .net os extension methods.

#uma classe já existente.
class Integer

#adicionando métodos a mesma.
def am(*args)
self == 12 ? 0 : self
end

def pm(*args)
self == 12 ? 12 : self +12
end
end


#veja que interessante o uso.
i = 4.pm
puts "4Pm = " << i.to_s #deve aparecer 4Pm = 16
i = 4.am
puts "4Am = " << i.to_s #deve aparecer 4Am = 4

#outro exemplo...
class String
def em_maisculo
self.upcase
end
end

puts "galaxy".em_maisculo

Esse recurso pode facilitar a escrita de interfaces fluente... imagine.

compromisso.adicionar("ler algo sobre ddd").comecando_as(2.Pm).ate_as(4.Pm).hoje()

* Exemplos inspirados numa apresentação de um trabalhador da throughworks.

"Interface fluente" no JavaScript

Isso mesmo "já embutida":
Ao invés de fazer isso.

elemento = document.getElementById("attachments-box");
elemento.removeAttribute("width");

elemento1 = document.getElementById("format_auto");
elemento1.setAttribute("checked", "true");

Você pode fazer diretamente:
document.getElementById("attachments-box").removeAttribute("width");
document.getElementById("format_auto").setAttribute("checked", "true");

E só pra não perder o costume mais um link de um belo exemplo de uma interface fluente: http://gc.blog.br/2007/09/25/refatorando-para-fluent-interface/

Expressividade na linguagem

Atualmente existem muitas linguagens de programação no mercado, algumas que fazem parte do "legado" {cobol,natura...} e outras estão em "voga" {java,ruby,c#...}. Fala-se muito em expressividade na escrita de código. A linguagem pode ajudar e muito a criação de código mais expressivo. Como exemplo inicial, duas linguagens, Java já conhecida e admirada e Ruby nova e promissora.
Para se obter o ultimo elemento de uma lista...

Em Java.
aList.get(aList.size -1)
Em Ruby.
anArray.last

É notório que o código parece ser melhor expresso com Ruby.
Agora considere os códigos abaixo:

//C# 2.0
date d = Helper.At(Helper.FromToday(Helper.Days(2)), Helper.Pm(4));
//C# 3.0
date d = 2.Days().FromToday().At(4.Pm);
Veja o quanto a versão 3.0 do sharp é mais fácil de ser "lida".

Outro exemplo:

Em Java:
public List pessoasFisicas(List pessoas) {
List resultado = new ArrayList();
for (Pessoa pessoa : pessoas)
if (pessoa.isFisica()) result.Add(pessoa);
return result;
}

Em Ruby:
def pessoasFisicas(pessoas)
return pessoas.select {|e| e.isFisica}
end

Sem comentário para essa última demonstração.
"Ser expressivo" pode facilitar futuras manutenções, extensões e integrações no código.

Os exemplos foram roubados discaradamente de
* HumaneInterface - Martin Fowler
* Artigo no InfoQ

ps: os códigos podem estar errados.

Ótimo post sobre Interface Fluente.

No site abaixo verá um exemplo bastante interessante, principalmente para quem trata requisições (no modelo "JSP/Servelt") em páginas.
http://fragmental.tw/2007/10/18/notes-on-language-adaption/
Enjoy it.