Pesquisar

segunda-feira, 16 de março de 2009

Ofereço trabalho de FreeLancer em Java

Olá à todos,

Estou interessado a trabalhar em projetos Freelance (pagos), se tiver algum ou conhecer pessoas que necessitem favor me contactar pelo email: leandro.ribeiro.moreira at Gmail ou ainda comentando neste post.

Tenho experiências com desenvolvimento de aplicações Java a mais de 3 anos (com artigo publicado na revista MundoJ, artigo públicado na infoQ gringa e algumas participações em projetos open-source) , meu foco se baseia principalmente em aplicações Web (Jsf [myfaces, icefaces e richfaces], Jpa, Ejb3, DWR, Jasper, Spring-Framework ...) . Integração de aplicações, DSL, SOA, TDD, DDD são algumas das áreas de conhecimento que atuo. Se estiver interessado posso enviar meu curriculo à você.

No mais obrigado :) Have a nice day!

quarta-feira, 11 de março de 2009

Abordagens e Abordagens

Motivado por uma discussão calorosa sobre meu projeto e o extremismo do OO (no forum WTF daily) o projeto recebeu mais de 500 visitas num só dia, a principal crítica era sobre a quantidade de classes (uma por cada opCode) desnecessárias... o que fez com que os gringos classificassem o projeto como WTF do OO (claro que dentro da discussão haviam aqueles que não achavam que o projeto deveria ganhar esse título também).

Resumidamente o processador do nintendo 8bits é um 6502 modificado, a sua arquitetura conta com 11 meios de se obter os operadores (basicamente em baixo nível você tem uma instrução e os operadores pra mesma), com isso a mesma operação pode ser feita de várias formas...

Exemplo: Para a instrução STA (carregue o registrador Accumulator) existem várias STA's: STA $10, STA ($10),Y , STA $1002 ... (sta direta, sta indexeda por y, sta indireta....)

Logo criou-se a situação de que eu tomei a decisão de uma interface Instrução e criei várias classes abstratas InstrucaoAbsoluta, InstrucaoRelativa, InstrucaoIndexadaY ... e várias subclasses concretas LDAAbsoluta, LDARelativa... (sendo que o trabalho de se obter o operador ficaria a cargo da classe pai).

Com isso tenho REALMENTE MUITAS CLASSES isso foi uma das reclamações. Hoje penso que poderia (e ainda posso mas ando focado no debugger) fazer algo mais ou menos assim.
lda(immediate());
lda(absolute());
sta(immediate());
sta(absolute());
Só isso reduziria e muito o número de classes apenas com a composição correta delas.

A outra indagação é sobre o meio que usei para se interpretar cada opcode. Normalmente um interpretador agi mais ou menos assim:

switch(coisaASerInterpretada){
case 0xFA: fazA();
case 0xFB: fazB();
}

E minha abordagem foi diferente, coloquei todas as "funções" num hashmap generic e apenas executava.

O preenchimento:
hash.add(0xFA,new FazA());
hash.add(0xFB,new FazB());
Quando fosse usar:
hash.get(coisaASerInterpretada).execute();

Eles não discordaram do jeito que fiz as coisas; mas de ter usado HashMap ao invés de um simples array. Acredito que realmente seja verdade, é desperdício usar um HashMap ao invés de um array comum mas nesse caso prefiro correr "esse risco bobo calculado" a ter que declarar uma array maior do que o necessário já que o índice do vetor seria a identificação da operação e aproveitar das facilidades do hashmap (melhor ainda pra buscas...).

Não posso deixar de rir um pouco com as opiniões xiitas mas também não concordo que isso poderia fazer um projeto ser classificado como um WTF (what the f%ck)

Meu novo projeto JNesBR

O meu atual hobbie preferido é criar emuladores (máquinas virtuais, simuladores, emuladores + simuladores), agora estou "desenhando" um emulador da máquina Nintendo 8Bits (NES ou FAMICOM). As minhas motivações para o hobbie são (entre outras):
  • Amar videogames/computadores e entender como realmente eles funcionam [bit a bit mesmo no mais baixo nivel].
  • Criar um sistema onde eu posso realmente empregar oo em vários sentidos, dar soluções flexiveis para os problemas mais desconhecidos.
  • Criar um sistema bom de debugger. (isso é muito legal, ver seus breakpoints nos assemblers, criar interfaces e objetos que lhe possibilitem caminhar no código, ver valores, enfim foge muito dos CRUD's de cada dia [amém graças a Deus])
É interessante ressaltar que a quantidade de conhecimento que você obtem ao escrever um emulador é gigante, você passa desde conceitos de memoria (páginação, troca) a controladores de vídeo (compactação, paleta de cores, conceitos sobre computação gráfica 2d e 3d...).
Espero postar mais sobre essas experiências e também alguns screenshots.
A página do projeto é http://code.google.com/p/jnesbr/

sexta-feira, 6 de março de 2009

Aumente pessoas e seu projeto terá os objetivos atingidos mais rapidamente....

Desde que fiz faculdade, e já faz dois anos, TODA a bibliografia SEMPRE dizia: ter muitas pessoas num projeto não garante que ele vá terminar mais rápido.
E AINDA HOJE TEM pessoas da alta gerência que resolvem dar gás ao projeto inserido mais 20 colaboradores (não estou afirmando que às vezes é necessário mais pessoas). E depois a cobrança é mais idiota : "Um projeto com 15 pessoas teria que terminar mais rápido"... ah vai ler qualquer texto sobre gerência de projetos...

segunda-feira, 2 de março de 2009

GIT, SVN, CVS, SourceSafe etc. Podem tirar suas fóbias de comentar código

Sabe aquele código comentado em produção que ninguém mexe e ainda dizem de modo obscuro... "Isso aí é coisa legada melhor deixar, vai que um dia tenhamos que descomentar..."
Eu (sempre) prefiro tirar todo lixo do código (isso claro que inclui códigos comentados), mas para aqueles que ainda sentem calafrios ao excluir código comentado segue uma velha dica, qualquer (que conheço) sistema de versionamento oferece ÓTIMOS e eficientes meios para que você possa "voltar" aquele comentário obscuro ...

quarta-feira, 18 de fevereiro de 2009

UseCASE Generator - Viva a documentação





Se você está atualmente empregado em uma empresa que adota documentações parecidas com isso abaixo:










---------------------------------------
Identificação: 1
Envolvidos: Mariana, Pedro e Luís
Caso de Uso: Manter Empregado
Ações:
  1. Clicar em novo Empregado.
  2. Inserir dados (nome, cpf, nascimento, salário, departamento) do Empregado.
  3. Clicar em salvar.
Exeções:
  1. Empregado não encontrado.
  2. Não foi possível salvar.
---------------------------------------

ou

---------------------------------------
Identificação: 2
Envolvidos: Mariana, Pedro e Luís
Caso de Uso: Manter Departamento
Ações:
  1. Clicar em novo Departamento.
  2. Inserir dados (nome, sala) do Departamento.
  3. Clicar em salvar.
Exeções:
  1. Departamento não encontrado.
  2. Não foi possível salvar.
---------------------------------------

Logo você precisa do UseCASE Generator Java V. 1.0 OpenSouce. (apesar de ser opensource o código não está disponível :P faça o seu)

Veja a API riquíssima.
public String createUseCase(int id, String[] stakeHolders, String entity, String[] properties);

Exemplo de uso:

String minhaSalvacao = useCASEGenerator.createUseCase(1,
new String{"Mariana","Pedro","Luís"},
"Empregado",
new String{"nome", "cpf", "nascimento", "salário", "departamento"});
System.out.println(minhaSalvacao);

Notou como é simples...
Pense rápido: se você consegue generalizar criar "case use generator" logo você não precisa documentar, apenas escreva um programa (já que sua empresa exige isso) que faça isso pra você.

PS: Essa ideia do UseCASE Generator é de um amigão (Marlos) e já está patenteada, portanto crie seus próprios UseCASE Generator e viva a documentação.