Fragmental

Mudança

2005-10-17T00:40:00.000-02:00

Bom, quem acessava o blog diretamente eh bom clicar aqui e ver as mudanças.

Rapidamente: estou deixandod e usar o Blogger (obrigado por tudo, Google) e passando a usar WordPress no meu proprio site. Nao haverao mais posts novos neste blog, alterem seus bookmarks para http://www.fragmental.com.br/blog

O Russo da Califórnia

2005-10-13T10:30:00.000-03:00

Teve reunião no RioJUG semana passada. Pra variar uma figura notável ganhou a assinatura de revista.

Nunca havia visto ele na reunião, e logo percebi porque. Yuri é Russo, mora na Califórnia há dez anos, aprendeu português (muito razoável) semestre passado, está tirando seu Phd em Berkley e está na UFRJ trabalhando em sua pesquisa.

E qual o campo dele? ERPs? Sistema flaxíveis? Integração? Não, Sociologia.

O campo de estudo do Yuri é como os engenheiros e técnicos de TI adquirem informação. Realmente, um campo muito interessante.

Veja a nós mesmos. Pessoas que ganham acima da média nacional e precisam se atualizar constantemente. Um ramo cheio de crenças e convicções, quase que uma religião, e vivendo eventuais guerras santas. Temos hippies, suits, quem só quer ganhar dinheiro e voltar pra casa, filantropos, líderes... tudo isso dentro de um ambiente altamente coorporativo. Temos doutores e molequees conversando de igual para igual (por menos que os doutores admitam isso). Em alguma madrugada, qualquer um pode entrar no quarto, virar a noite programando e mudar o mundo da tecnologia com algum conceito novo.

Não pude ficar muito tempo lá, mas vou pegar o e-mail dele e pedir que me inclua na lista de distribuição de uma publicação neste tema.

Chega

2005-10-12T18:21:00.000-03:00

de referendo pra mim. Eu voto no sim, mas to cansado de ver argumentos idiotas por todos os lados. ja nao discuto mais, ja nao debato mais.

A conversa agora eh na base do hoax. TV globo isso, veja aquilo, por favor. A globo apoia o sim, a veja apoia o nao. Duas entidades classicas de midia manipuladora comprada, mas quem ta de um lado soh sabe acusar o outro.

Soh quero que isso acabe logo porque tenho certeza que nao vai mudar nada. O que me da medo sao as pessoas que falam tanta besteira e acreditam em cada coisa ridicula saindo armadas por ai. Esse referendo so teve uma finalidade: mostrar que a sociedade eh manipulavel e naoe sta pronta para votar em algo assim. Esqueçam este papo de democracia, quem usa HOAX e FUD para defender um direito nao merece votar ou dirigir.

A unica coisa que realmente vai me afetar deste referendo eh o fato de ser mesario. O resto, dane-se. Cansei dessas discussoes idiotas.

Update pra variar, Mauricio Ricardo arrebenta.

Pissed off

2005-10-10T10:35:00.000-03:00

O que leva grevistas a achar que podem para com o trabalho dos outros? Não estou falando de seus colegas não, estou falando de mim mesmo e pessoas que não trabalham e nunca trabalharam nesta droga de banco. Não sou funcionário, não sou grevista, não sou acionista, não sou correntista, não mandei ninguém fazer concurso pra essa droga, não sou político nem jornalista.

Que direito essas pessoas acham que tem de me barrar na entrada do meu trabalho? Querem protestar? protestem. Quebrem uma agência, roubem o dinheiro todo DANE-SE, não me importo e os seus diretores vão ficar loucos. Agora encher o saco de alguém que não tme anda com isso. Engraçado que são sempre as mesmas pessoas nesses negócios de greve, o povo que vai como vaca pro abate e o grupinho de gente que adora agitar essas coisas, e quando cai em Brasília só faz besteira.

Desculpem o desabafo, não resisti.

Ah, estou fazendo umas mudanças no fragmental.com.br, acessem o blog diretamente ;)

Uma Rosa Com Outro Nome...

2005-10-09T16:40:00.000-03:00

Imagina a cena. Seu colega pede ajuda num trecho qualquer de código. Ele começa a te explicar o que está fazendo:

Então (ele é paulista), eu criei esse agrupamento de instruções parametrizáveis, que retorna um valor que é uma cópia de um objeto. Daí eu agrupei alguns destes numa unidade e coloquei algumas variáveis que eles compartilham. Como alguns destes agrupamentos não são utilizados por outros agrupamentos externos, defini uma política de exposição para eles...

Você entendeu? Dependendo do sue nível de imersão em cosias abstratas relacionadas á programação, talvez sim, mas o desenvolvedor mediano vai fazer "uhum" algumas vezes e olhar para o código para ver o que esse cidadão queria dizer. E ele vê o que ele tentou explicar:

public class Usuario{
private int idade;
private boolean sexo;
private double altura;

public void setIdade(int idadeNova){
if (idadeNova>13) {
idade= idadeNova;
calcularAltura();
}
else{
throw new IllegalArgumentException("Idade baixa demais para usar o sistema" );
}
}

private calcularAltura(){
altura=idade*10.45;
}
}

Aí você pensa

Caramba, não seria mais fácil ele dizer que fez uma classe com métodos públicos e privados e atributos privados?

Seria, mas e se ele não conhecesse este termo? Sim, o exemplo é bem forçado, mas é de propósito.

Muita gente torce o nariz quando alguém mostra um Pattern. Logo pensam: "Quanta besteira...eu uso isso há anos!" e esquecem que tão importante quanto criar Patterns é catalogá-los. Pense em algum padrão que você use no dia a dia. Agora imagina que você tem uma dúvida com o uso deste.

Você vai num fórum qualquer, o GUJ por exemplo, e tenta descrever sua dúvida. Você pode gastar dois parágrafos explicando o que fez ou pode simplesmente dizer o nome do Padrão e a pessoa que ler já sabe do que se trata (ou pelo menos vai saber se procurar).

Existem livros e sites que fazem apenas isso. Eles documentam e catalogam padrões, colocam eles dentro de contextos, listam vantagens e desvantagens, mas não necessariamente criam nada novo. Você não vai encontrar novas geniais soluções, apenas soluções clássicas catalogadas.

Além do óbvio benefício de acabar conhecendo uma solução que já é clássica mas você não conhecia, outro benefício não tão óbvio está simplesmente em termos um idioma comum entre profissionais.

Se você falar para alguém de .Net ou C++ que fez um Observer, ele provavelmente sabe do que você está falando. Se falar que usa um DAO, apesar de ser algo mais comum em Java EE, é bem capaz de ser entendido (menos pelo cara do .Net que pode se confundir com esse negócio de DAO/ADO), como este padrão também tem outros nomes mais genéricos, pode ser que ele também use isso nas suas aplicações.

Um padrão não é padrão desde seu nascimento. Ele nasce como uma solução isolada, e de repente alguém pensa "Ei, eu posso resolver este problema do mesmo jeito que fiz naquele caso..." (por isso Ted Neward fala que o sistema só morre quando as máquinas são desligadas, o código fonte é apagado e o último desenvolvedor é morto). E por mais que você use e reuse, ensine esta técnica ela só vai virar um padrão no dia em que for catalogada. Seja em um livro, paper ou site ou qualquer coisa.

Se alguém te disser que recebeu um buquê de as flores que pertencem à família rosasceae, que são arbustos ou trepadeiras, providos de acúleos com folhas simples partidas em 5 ou 7 lóbulos de bordos denteados, com 5 pétalas, muitos estamos e um ovário ínfero... estão continuam sendo rosas, mas não seria mais fácil se vocês falassem a mesma língua?

2005-10-04T16:43:00.000-03:00

Mike Spille escreveu sobre sua experiência com Groovy no TSS. Vale uma lida.

Concordo com muito do que ele falou, mas o maior problema de Groovy hoje, na minha opinião, é um debug decente. As Stacktraces não dizem muita coisa (só perdem pras Stacktraces bizarras do Hibernate, SqlWalker é complicado...) e debugar no olho é terrível, aidna mais pra quem não é tão proficiente na linguagem ou está aprendendo.

mas Groovy é uma linguagem muito legal e membro de uma tendência. Se você precisa de algum script portável, considere imensamente seu uso. Se precisa de uma linguagem bonitinha e cheia de recursos (closures! weeeeeeeeeeeeeee!!)que tenha a sua disposição toda a JVM e APIs, frameworks, e demais coisas que não te fazem abandonar java, dê uma olhada.

Eu sei que foram...sei lá, cinco anos que a única linguagem além de Java foi SQL, mas isso está mudando. As linguagens para a JVM estão aí, com suporte total no Java 6.0 Mustang. Seja por pressão do .Net, seja por java não ter algumas coisas legais, acabou o monopólio.

Aprenda Groovy, Python, Ruby... alguma outra coisa. Saia da zona de conforto.

Microsoft Windows Officially Broken

2005-09-29T14:29:00.000-03:00

Não gosto de postar links sem comentários, mas ainda não acabei esse, só achei muito interessante.

Microsoft Windows Officially Broken

Dá-lhe Rubinho

2005-09-29T10:14:00.000-03:00

Perdão pelo título engraçadinho, não pretendo falar de Fórmula 1 hoje.

Mas a analogia é válida (creio). Você lembra de 2003/2002? Lula foi eleito e tomou posse, EUA invadem Afeganistão, Espanha adota o Euro, Ataque dos Clones nos cinemas, Columbia se desintegrou, SARS invade o oriente... e o Struts e outros frameworks MVC para web precoces são a nova onda na comunidade Java.

Enquanto isso, Sun, IBM e demais forçavam na trindade BMP/CMP+SessionBeans+Servlets. E a comunidade surge com esse tal MVC.

Três anos de palestras em JUGs e eventos, melhorias, concorrência e hoje (ontem, eu diria) o MVC está em tudo relacionado a Web. E surge para o mercado o tão falando JSF.

E o que a comunidade está fazendo? Adotando JSF em massa? Depende.

Quem curte seguir a tendência das grandes, está de olho nas IDEs JSF, Struts Shale, MyFaces, blablabla. Quem curte tecnologia está de olho em Rails. Quanto tempo para acontecer o mesmo que acotneceu com o Struts?

Bem, existem mais dificuldades. O Struts:

É em Java
É da Apache

O Rails:

É em Ruby
Não á da Apache

Quanto a ser em Ruby, minha dica é: aprenda Ruby. Mas como mesmo se você aprender a codificar em Ruby ainda tem toda a pilha Java EE que não vai ser migrada (nem estou sugerindo que seja), e sua emrpesa não vai usar Ruby tão cedo (a menos que você trabalhe num lugar legal, claro, mas isso é raro).

Então já temos pelo menos duas alternativas "sérias" em desenvolvimento:

Mas o que é o Ruby on Rails e porque ele faz tanto sucesso? É um framework para a criação de aplicações web em Ruby muito simples, prático, produtivo e agradável.

Por que ele é legal? Basicamente porque ele facilita sua vida. Rails é baseado em convenções. Com alguns comandos, você cria sua aplicação completa, se quiser personalizar (e você vai querer...), é só alterar os pontos certos.

Posso fazer tudo com Rails? Obviamente não. Eu estou usando apra aplicações web simples, ams alguém com muita proficiência em Ruby com certeza consegue fazer muito mais. Claro que para aplicações complexas, a paltaforma Java EE continua no seu lugarzinho, mas do jeito que java tende a tornar complexas coisas simples como uma pequena aplicação web CRUD de qualidade razoável ("tudo em JSP" não é opção aqui), essa nova alternativa promete.

Então, quanto tempo?

Engraçado, no debate ontem as pessoas falavam que cultura de "abrir um software para consertar" era coisa de maluco, que nenhum CEO ia querer isso. Um cara da IBM (aliás, ótima palestra! Muito acima da média e infinitamente acima das outras que já assiti da IBM, recomendo que procurem os slides aqui assim que disponíveis), um do governo (aliás foi meu professor há alguns anos... de Java), o Eliziário representando o capitalismo moderno e o Xexéo, acadêmico discutindo Linux. Você pensaria nisso ha dez anos? Que essas empresas usam e apoiam software aberto, em maior ou menor escala?

As coisas andam, e nesse ramo andam rápido demais. Há muito tempo a influência da comunidade no mundo de tecnologia é extremamente forte. Hibernate, Spring, Struts, MySQL, Java, Python, Linux... tudo isso cresceu na vontade das pessoas antes de alguma empresa comprar a idéia. Demora, mas elas compram.

E demora tanto que quando enfim a IBM lançar alguma cosia Rails-like, haverá outra coisa mais hype. E o ciclo se repete. E se repete. E se repete.

Semrpe que penso nesse ciclo lembro de uma pessoa que conheci num banco em um projeto que aprticipei. Cara com mais de 30 anos de profissão,contando os dias para se aposentar. "Eu vou pra praia, vou pra montanha, vou pra PQP, mas NUNCA mais quero saber de computador..."

RioWUG: debate sobre Software Livre

2005-09-28T16:35:00.000-03:00

Meio atrasado, mas hoje vai acotnecer um evento sobre Software Livre no Rio Websphere User's Group.

Eu ainda não tenho certeza se vou estar lá (tudo tende a sim) mas o debate promete, com a presença da pessoa mais polêmica que eu conheço: Marcos Eliziário, do RioJUG.

Date: Sep 28th, 2005
Meeting time: 19:00 - 21:00
Meeting location: Auditório do SENAC - Rua Santa Luzia, 735/7º andar (no mesmo lugar do RioJuG)
Meeting topic: Software Livre
Agenda:
19:00 - 20:00 - Palestra: "Software Livre: Trajetória, potencialidades e modelos de negócio e desenvolvimento." - Marcelo Savio - IBM
20:10 - 21:30 - Debate com a presença de:
* Geraldo Xexéo - professor adjunto da UFRJ, engenheiro pelo IME (88) e Doutor em Engenharia de Sistemas e Computação pela COPPE/UFRJ (94).
* Marcos Eliziário - Coordenador do RioJUG e Sócio-Gerente da Object Farme, empresa especializada em outsourcing e desenvolvimento offshore;
* Vítor Alvarez, analista de sistemas e membro do subcomitê de software livre do SERPRO
Directions:
Dica de Acesso: Estação
Cinelândia do Metrô pela saída Santa Luzia, atrás do Consulado Americano

Additional information:
Palestrante: Marcelo Savio.
Resumo das Qualificações Profissionais: Arquiteto de Software da IBM, formado em Informática pela UERJ e mestrando em Engenharia de Sistemas e Computação pela COPPE/UFRJ, trabalha há mais de 15 anos na área de TI, ao longo dos quais atuou nas áreas de desenvolvimento, suporte e consultoria.

Debate: conduzido por profissionais e acadêmicos com conhecimento/experiência na área de Software Livre

DevX: Quem Conhece SQL Usa Stored Procedures

2005-09-28T16:25:00.000-03:00

O DevX é um site com altos e baixos (o que é bom, existem muitos sites só com baixos...), mas a seção de Java geralmente é digna de ser ignorada solenemente. Matérias batidas sobre temas batidos, muitas vezes apenas um breve copy&paste (o onjava.com também têm sofrido deste mal em escala menor).

Desta vez, temos um artigo com uma proposta antiga revista, o uso de Stored Procedures. Tudo bem, se não fossem pérolas como:

Typically, those not familiar enough with SQL will choose CMP entity beans or frameworks such as TopLink and Hibernate, which generate queries and help to isolate them from the Java code.

Eu ia comentar isso, mas alguém mais competente que eu já o fez, então fiquem com a resposta do Kevin.

heavy users

2005-09-27T16:57:00.000-03:00

Você é um heavy user de coisas-relacionadas-ao-computador?

Para mim, não se você não responder sim a pelo menos 80% destas questões.

Você sabe o que é uma licença Creative Commons?
Você conhece Ruby há mais de dois anos?
Não consegue entender como tem site que não disponibiliza uma API e tags?
Queria poder usar tags no mundo real?
Usa algum agregador? Há mais de um ano?
Seu site tem RSS/Atom?
Não lê frequentemente sites que não tem um feed?
Sabe a diferença entre RSS e Atom?
Quis ter ou tem um iPod mesmo sabendo que existem opções mais baratas?
Mesmo usando winamp na maioria das vezes acha o iTunes legalzinho?
Usa ICQ ou pelo menos tem uma conta lá?
Já tentou usar Jabber, tem conta lá, mas desistiu porque ninguém usa aquilo?
Programa, mesmo que não profissionalmente?
Achou seus últimos empregos na Internet?
Já teve uns 10 blogs?
Compra um CD, ripa em MP3 e nunca mais abre a caixinha?
Tem uma conta no gmail ha mais de um ano e tem mais de 50% consumido?
Usava orkut (apenas) antes da invasão brasileira?
Lê blogs como quem lê um jornal?
Frequenta a Wikipedia?
Contribui para a Wikipedia?
Tem conta no flickr?
Tem conta no del.icio.us?
Sabe o que é AJAX?
Já usou Linux?
Usa Firefox?
Tem extensões instaladas no seu Firefox?
Usa greasemonkey?

Sugestões de adições a lista são bem-vindas :D

Colação de Grau

2005-09-25T23:45:00.000-03:00

Ontem foi a colaçãod e grau da minha irmã. Pedagoga como 40% da família. Ela entrou na faculdade depois de mim. Aff...

E novamente Phillip pensa sobre faculdade. PR1 se aproximando no McDonald's, os alunos só sabem mandar emails pras listas pedindo prova do professor ciclano, trabalho pronto do professor beltrano... êêê festa.

E ningém sabe nada de nada. Depois de ouvir que a linguagem Java foi criada como C--, que só se chama Java por marketing (marketing muito bom esse, porque nunca havia ouvido essa história), que AWT foi criado as pressas, por isso é tão ruim, que Java não tem for each, não trabalha em CGI ("grande vantagem do PHP"), ver códigos de exemplo cheios de NullPointerExceptions óbvias e professores que não sabem o que é um socket, eu imagino esses "profissionais" na linda cerimônia de colação de grau. Serão bacharéis. Em droga nenhuma.

Olhando as pessoas que estão ali para aprender algo, eu não consigo deixar de me sentir comovido. Dá vontade de falar "saí daí, passa na biblitoeca, esquece essa aula que esse cara só fala merda!", e ocasionalmente eu até falo, mas não costuma dar muito certo. Para quem entra na facudlade sem saber nada (e mesmo os que entram achando que sabem geralmente não sabem nada mais que comprar uma palca de vídeo certa para jogar Doom III), qualquer coisa falada lá na frente por um senhor de 50 anos faz sentido. Só que quase nada (ou quase) dito naquele lugar faz sentido. É 95% de besteira sendo vomitada pela boca de alguém que não tem noção do que fala.

As úncias aprtes que eu considero legais nas aulas são as experiências dos professores. O melhor professor que eu tenho, tive aula com ele semestre passado, dá uma aula legal porque ele fala muito sobre sua grande experiência de vida. Tá certo que ele parou no tempo há muito tempo (e nem é tão velho assim...) mas dá pra você tirar algo.

Agora imagina o que é sentar três horas em frente a um cara falando sem parar sobre algo que ele não entende. Nesses, sei lá, quatro anos naquele buraco eu desenvolvi umas técnicas para desligar e ligar a atenção. Ligar quando o professor conta causos, fala de datas, provas e trabalhos, desligar pro resto. O jeito clássico de conhecer professores ruins são os exemplos. Um professor ruim não sabe dar exemplos além dos do livro.

E assim passa metade de mais um semestre. Ano que vem vou estar aqui chorando minhas pitangas com vocês novamente. Faltam 15 matérias, dá pra terminar em um ano. A droga é que tem que fazer o Projeto Final.

Mono: Quem Usa?

2005-09-25T23:06:00.000-03:00

Muito tempo que não falo nada do Mono, desde meus antigos posts no Jablô ou no Jroller, creio. E porquê?

Simples: cadê o mono?

Hoje eu trabalho num ambiente totalmente misto, Windows e Software livre, apesar de tudo Java. Os 14 meses anteriores entretanto eu vivi numa UNIX-shop (e ser assim era um dos motivos para eu ficar lá). Nunca ouvi falar de Mono neste meio.

No meu bloglines tem, além de diversos outros amigos do tio Bill, notícias do projeto e o blog do Icaza, e tudo que vejo são eles comemorando um compilador melhor, uma IDE menos isso, mais aquilo. O Mono Brasil parece bem ativo, mas a minha pergutna é quem usa? Onde?

Não estou duvidando do potencial da plataforma .Net em si. A Microsoft conseguiu fazer algo legal, contratou os caras certos, porém... bem a Microsoft é a Microsoft e a sede por monopólio (porque sede por dinheiro todas as empresas têm, óbvio) acaba destruindo um pouco das coisas legais. O próprio povo da MS fala mal do Mono, como se vê aqui. Não sei bem o que "MSDN Regional Director" significa, e todo mundo tá careca de saber que Mauro Sant' anna não sabe mais sobre programação que a minha prima de três anos (vide as piadas que ele chama de "comaprações"), mas escrever uma bobeira como esta:

O Miguel Icaza, dono da Ximian e “patrono” do Mono botou vários milhões de dólares no bolso e virou vice-presidente da Novell. Eu o encontrei algumas semanas depois em uma festa patrocinada pela Microsoft em Los Angeles e o ele sorria sem parar, feito bobo. Para ele sem dúvida valeu muito à pena. Já não sei o que acham o bando de patos que trabalhou de graça para que ele pudesse ficar rico. Como costumo dize, Open Source no software dos outros é refresco. Até hoje não sei o que a Novell vai fazer com isso.

É de lascar. Mas é claro, Redmond destrói a concorrência, seja ela quem for. O engraçado é o "Até hoje não sei o que a Novell vai fazer com isso". O que ele quis dizer com isso, que .Net fora do Windows não vai rpestar e que a Novell comprou a Ximian (e de quebra o Mono) a toa?

Não posso dizer que toda comunicação Microsoft x Mono é assim (principalmente porque esse autor já mostrou que não é referência para nada), e me parece que não, mas da opinião de quem tá de fora e lê um treco desse...putz grilo.

Voltando ao ponto, quem usa Mono? As vezes eu tenho a impressão que eles estão produzindo uma super-plataforma, muito melhor que o próprio .Net, mas que só vai estar pronta quando tudo que conhecemos hoje por programação já estiver obsoleto. Note: eu não sou tão tapado assim, eu sei que as implementações dos caras funcionam e não duvido que sejam boas (eu uso Gnome/GTK, não duvidaria do Icaza & crew), mas quem usa isso?

Procurar por Mono na Novell dá mil e poucos hits, Java dá quase 21 mil .Net dá uns 14 mil.

Eu sinceramente nunca vi sentido no projeto Mono. Criar uma plataforma 100% livre? Ótimo, temos Python, Ruby florescendo e tantas tantas tantas outras. Por que algo Microsoft? Entretanto, nunca tive dúvidas da competência técnica da equipe.

Eu acho que o Mono aidna não pegou, e não vai pegar, porque:

A Microsoft acha interessante ter o Mono para dizer ".Net é padronizado, qualquer um faz uma implementação", mas comercialmente não interessa haver Mono
Programador .Net não tem cultura de OSS. Tem cultura de comprar/crackear componente.
Muita gente ainda vincula e vinculará sempre .Net com Windows. Mono nos celulares pode ser uma saída interessante.
A comunidade OSS está pouco se lixando para Mono

Claro que isso tudo é minha opinião (e esse blog é meu, desculpa mas eu tenho ireito de escrever minha opinião aqui ;) ), de alguém que não trabalha com .Net/Mono nem conhece a plataforma muito de perto. Antes de me xingarem, prestem atenção nesta última frase e vejam se conseguem aproveitar o feedback.

Afinal, esse post foi uma pergunta.

Orkut: Brasileiros + Internet = SPAM

2005-09-24T13:09:00.000-03:00

Eu entrei no Orkut antes dele virar febre nacional, convidado pelo Carlos ou Daniel, não lembro ao certo. Naquela época a graça era entrar em comunidades, porque nem tinha tanta gente conhecida assim.

Com o passar dos dias, fui recebendo milhares de milhares de mensagens nas lsitas das comunidades que... faziam spam de outras comunidades. Desabilitei todos os avisos por email e faz quase um ano que não olho se tenho mensagens novas. Nem quero olhar. Uma funcionalidade legal do portal foi pro saco pelo instinto spammer da humanidade.

Agora o yakult é febre, e temos mais spammers, desta vez no scrapbook. Muita gente divulgando comunidades idiotas, ou nem tão idiotas mas que eu não me interessaria (o que alguém ganha com várias pessoas numa comunidade? Tem prêmio? "Traga 10 amigos e a sua entrada na comunidade é grátis"?).

Perfis falsos com figuras de meninas bonitas (incluindo a quase internet porn star Maria das Graças) mandando ASCII art (ah, as pessoas acham que ASCII art é novidade agora também. Internet deveria ser banida de alguns círculos) de sites idiotas com coisas idiotas. Enfim, um festim de spammers.

O que mais me impressionava é que como a coisa é amadora e programadores com meio cérebro não costumam fazer essas coisas, isso tudo devia ser feito na mão. Haja saco! Aí vi que apesar de muitos deles ainda serem manuais, já existem programas populares para fazer isso a venda por "míseros" R$44,00.

Esta semana eu recebi propaganda de uma marcenaria em São Paulo(!), comunidades "de pegação", de marombeiros (eu com meus 65kg ia fazer o que lá? Limpar o chão?), uma loja online de camisetas (!!), diga não ao desarmamento (com os velhos argumentos ridículos "só os bandidos terão armas". Você tem arma em casa? Eu não e todos que conheço que têm arrumaram com "amigos", não compraram nas lojas)... e muitos outros.

Por enquanto eu tenho me dado ao trabalho de entrar nos perfis, "report as bogus", depois "ignore user", mas como não vejo nada acontecer, mandei umas mensagens de feedback (incluindo links dos programas). Se realmente isso não parar em breve (o que é o mais provável) vou desabilitar as notificações e parar de olhar meu scrapbook.

Note que há um jeito fácil de achar os spammers, mesmo de perfil falso: quem os convidou para entrar no orkut? Mesmo que não houvesse, basta adicionar alguns mecanismos, como aquela maldita imagem de confirmação que operadoras de telefonia usam pra mandar SMS (mais uma incoveniência que os spammers nos trazem).

Já não entro nas minhas comunidades, já não recebo mensagens... pra que vou ficar no Orkut?

Engraçado que no scrapbook de um dos perfis falsos eu encontrei várias mensagens com propagandas. Gente querendo que uma loja de camisetas entre na sua comunidade.

Conexão Java 2005: Palestras Gravadas

2005-09-23T16:56:00.000-03:00

A Anhembi Morumbi gravou o áudio e os slides de algumas das palestras (todas do salão principal) do Conexão java 2005. Confira aqui.

Agora vocês vão poder ouvir o já criticado nervosismo deste "carioca" que vos escreve com seus próprios ouvidos :)

PS.: não reconheci minha voz :P Realmente eu estava muito nervoso.

Palestra do RioJUG: Arquivos Disponíveis

2005-09-13T01:07:00.000-03:00

Muito legal a palestrinha ontem no RioJUG. Os arquivos estão no site da lista no Yahoo! (requer cadastro).

Muito obrigado a quem foi ou desejou boa sorte, em especial ao pessoal do GUJ. Falei com o Douglas rapidamente,c rieio que o Marcelo tavares estava lá também mas não falou comigo (pelo menos esse nome estava na lista...). Obrigado ao Renato, que enfim apareceu. Agora só o ironlyxx que não existe... :P

Para quem não foi, da compilação da palestra no RioJUG e workshop no CJ2005 deve sair um artigo. Só preciso respirar um pouco...

Update: Esqueci um fato marcante. Entre meus amigos ex-colegas de trabalho que estavam lá, fiquei honrado com a presença do melhor programador C++ e benchmarker que conheço, famoso por achar java a coisa mais lenta depois do Aterro do Flamengo no Rush. Não é que o Gabriel me acaba ganhando a assinatura da Java Magazine que é dada de brinde nas reuniões?

Rapidinhas: Mentadrenalina

2005-09-08T23:51:00.000-03:00

Continuando os posts dessa noite, vamos com rapidinhas e não tão rapidinhas.

Você já avaliou um CJ2005? O feedback está sendo bem interessante. Do minicurso/workshop todos que falaram falaram bem, mas do debate que participei teve quem meteu o sarrafo no "carioca" (ps.: carioca não sou fluminense ou niteroiense se preferir!) e quem colocou como um dos pontos legais.

O feedback negativo me foi extremamente útil. Eu sinceramente acho que as pessoas que comentaram algo comentaram o que acharam, não quiseram apenas falar mal, e isso é bom para eu tentar corrigir algumas coisas. Feedback positivo não diz muito o que fazer além de continuar fazendo o que faz, mas é ótimo :)

Na segunda-feira tenho palestra na RioJUG, voltar ao assunto do CJ2005. Camadas: como fazer, como não fazer, padrões legais, padrões ruins... uma discussão sobre o tema. Eu vejo muitos problemas com estes cocneitos, e osto de tentar mostrar a minha visão. Nem certa, nem errada, minha.

Semana passada eu terminei minha primeira aplicação real com o controverso Mentawai. Estou conversando com o Sérgio sobre as mudanças que eu fiz, mas foi bem elgal. Era uma aplicação web pequena, para uma das maiores empresas do Brasil, utilizando Java 5, Spring e Hibernate 3. Pro Carlos Santiago, que me perguntou sobre o Menta alguns posts atrás, eu fiz uns filtros de integração Spring x Mentawai, ficou razoável. Eu acredito que seja uma opção viável para aplicações típicas web, que são a grande maioria. As features de Display-tags estão evoluindo, podem ainda não estar no nível desejado. Claor que toda ajuda é bem-vinda ;)

Como falei antes (já tá ficando chato...) mudei de emprego. Só não lembro se falei que também mudei de área, saindo de GSM/telecom para Risk Management e Trading Systems (não sei como traduzir isso direito :P) áreazinha interessante e complexa pra cacete.

Peguntado pelo Rafael, além do Pro Spring, eu recomendo os livros do Rod Johnson e a leitura do guia de referência no Site do Projeto, tem muita coisa boa lá. O fórum também é bom

Programaodres e Drag...não feche a janela ainda!!!

2005-09-08T23:46:00.000-03:00

Pra quem não sabe, esse texto que vocês e eu já recebemos dezenas de vezes é do Fernando Meyer, o scottys do GUJ, com o Daniel Quirino e Marihelen. Achei legal informar isso aqui, pode ser que alguém não saiba e eu acho uma puta sacanagem nem um link pro blog do cara colocarem.

Daqui a pouco vão dizer que é do Veríssimo.

Como não construir uma Comunidade

2005-09-08T23:12:00.000-03:00

Eu sempre fui um cara mais pratico e menos poitico com respeito a JUGs. Dessa vez, nao vou poder deixar de falar.

É pertubador (apesar de nao ser nada estranho ou imprevisível) que pessoas que falam tanto, o tempo todo, em comundiade, como SãoJava, haja de uma forma tão peculiar.

Para quem ainda não sabe, SãoJava aportou no Rio de Janeiro com JUG e templo próprios. Mais um JUG no Rio? ÓTIMO! Acho que depois de bater um papo comigo ou ler uns posts neste blog dá pra perceber que eu me preocupo com o esvaziamento do Estado, e não é coisa de bonzinho não, eu simplesmente não quero ser obrigado a me mudar do lugar que quero ficar por não ter opções.

Este não é o segundo JUG no Rio, existem outros de empresas, universidades ou em outras cidades do Estado. De uma maneira maior ou menor, eles sempre cooperaram, ou pelo menso não competiram. Divulgaram e lutaram pelas mesmas coisas. Realmente o estado precisa de mais movimento, mais JUGs, mas alguém que teoricamente preza tanto a tal "Comunidade Java" resolve criar um grupo paralelo e independente, sem buscar qualquer tipo de aproximação. É simplesmente ridículo este clima de competição entre ONGs, se ninguém ganha nada com isso, a não ser o fortalecimento da tal Comunidade, pra que essas coisas SãoJava? Por que não unir ao invés de separar? Agir em conjunto? Dialogar? Vou consultar o código canônico pra ver se santo se contradiz.

Se fosse o José das Couves ali da esquina, eu não ia achar nada. Só acho que depois de encher tanto o saco com palestras, artigos, spam, bandeirinhas do Brasil, gritinhos e palminhas e todo o marketing sobre a tal "Comunidade de Desenvolveores Java Brasileira", eu perdi alguma coisa. Vai ver no meio da gritaria eles deixaram claro e eu não ouvi, a "comunidade" é a comunidade deles. Afinal, eles SãoJava.

Spring em Ação

2005-08-31T17:40:00.000-03:00

Não, não é lançamento de livro em português, não ainda (agradeçam, esse livro não é legal e não vale a grana).

Está acontecendo mais uma vez. Assim como com o Struts, o Spring está ganhando a luz do dia nas empresas após ganhar força na comunidade (e, assim como o Struts, em algum tempo perceberemos que podemos fazer bem melhor...).

Para quem (ainda) não sabe, o Spring é um container leve (container leve é um conceito vasto, mas neste caso quer dizer um container de POJOs, segundo o time do Spring). Com ele você pode ter praticamente todos os benefícios de Java Enterprise Edition (JCA, JTA, Servlets, Pools, JMS, TMX, JavaMail, JDBC...) sem utilizar EJBs. Você não precisava de EJBs para usar estas coisas, mas geralmente as pessoas se apegavam a estes por serem a maneira "mais fácil" de lidar com os outros recursos.

O Spring provê uma API fácil e bem utilizável para utilizar estes recursos, mantendo seus objetos independente destes com um bom uso de AOP (que é facilmente configurável por qualquer um).

O problema atual do Spring é como é chato configurar seu XML. A semântica do negócio é simples, mas é muito ruim ter que digitar aquilo tudo (não me apontem uma ferramenta, não é isso que torna as cosias produtivas), mas ainda assim é *muito* mais simples que configurar EJBs e seus descritores, interfaces, pools, JNDI names e tudo mais, fora as gambiarras como Service Locators e Business Delegates.

Existe um velho refrão que diz algo como Não use um canhão para matar uma mosca. Esta frase mais que sábia diz muito sobre quando usar EJBs (praticamente nunca), mas também tem suas complicações.

Um caso típico é o de programas em ASP clássico/PHP/CGI. Estas plataformas são extremamente limitadas para aplicações de grande porte, praticamente qualquer integração com middleware é feita por banco de dados (bleargh) ou hoje em dia por XML sobre HTTP. Eu trabalhei muito tempo com ASP, e quando estava estudando minha diversão era fazer cosias improváveis, como editores de texto completos, editores de vídeo e outras coisinhas complexas em ASP puro (não adianta usar componentes, muitas vezes você não consegue instalá-los no servidor do cliente).

E ficava aquela gambiarrada toda. Trocas de mensagens através de tabelas no SGBD, arquivos temporários de download... etc. Esse é o caso contrário do ditado que acabei de falar, neste caso podemos aplicar o refrão: Não use um mata-moscas para matar um mamute.

Existem aplicações que não são mamutes, não são moscas, mas ainda assim precisam de algum suporte de plataformas coorporativas, como transacionamento XA, pools, conectores, ciclo de vida controlados, mensageria... a maioria das aplicações que são mais que um simples site de Internet tem pelo menos uma dessas necessidades. Neste cenário, coisas como o Spring são perfeitas, você usa apenas o que precisa, não precisa engolir o elefante de novo para usar o que quer.

Neste cenário, fica mais fácil produzir aplicações Orientadas a Objetos de verdade, sem as aberrações de BusinessDelegates/SessionFaçade/ServiceLocator/DTO/TO/VO que vieram trazer alguma usabilidade aos EJBs. Mas se você é amigo dos EJBs, ou realmente tem um caso onde els são úteis (chamadas RMI são um dos raros exemplos), pode continuar utilizando sua plataforma.

Se você está no mercado, estude Spring. Provavelmente quando a sua empresa for enfim usar haverá coisa melhor, mas por enquanto, essa é a opção mais sensata para aplicações médias. Não que paltaformas como Pico/Nano Container sejam ruins, pelo contrário, só que o Spring tem maior suporte e um apaltaforma mais vasta, cobrindo muita coisa que você precisa hoje.

A fila anda...

WebLogic & Mercado Carioca

2005-08-30T15:20:00.000-03:00

Dois assuntos que tem muito pouco a ver, mas me ocorreram hoje.

A coordenação do RioJUG foi convidada junto com clientes e parceiros para uma demonstração do novo Bea WebLogic 9 (aquele com o diabinho que parece desenhado pelo mesmo cara que desenhou o Tomcat, confira abaixo).

Eu considero a Bea uma empresa muito razoável no que faz, e pela apresentação a nova versão do WebLogic traz coisas muito, muito, muito legais, como possibilidade de rodar duas instâncias de uma mesma aplicação com versões diferentes, configuração atômica (nada de urânio, plutônio ou deuteronômio, apenas transacional) e scripting.

Eu tenho um pet project que não avançou muito de colocar um Shell no JBoss. Onde eu trabalhava (já falei que mudei de emprego?) isso era muito útil, principalmente acessando máquinas dos clientes via uma VPN fedorenta, tendo que atravessar mil servidores para chegar na máquina de produção... enfim. A minha alternativa (como o que pretendo no Funky) é algo independente da linguagem, mas bem focada em Groovy (BeanShell é legal também).

Eu estava ansioso por saber como é o scripting do WL, e não é que eles usam...Python! Pelo que o cara de marketing falou (aliás, pausa aqui: O cara de marketing era muito, mas muito mesmo mais técnico que todos os outros que já conheci, seja da IBM, Sun, Microsoft, Novell...o cara deu um parecer técnico-porém-marketeiro muito legal) que ele roda sobre Jython. Não tive a chance de perguntar o porque, vou pesquisar por aí, alguém sabe de algo?

Não me entendam mal, Python é legal, a Bea investir em algo aberto como Jython é legal... mas o JCP está padronizando três linguagens de script (Groovy, BeanShell e JavaScript), pra que uma tão alienígena?

Eles estão trabalhando junto com o Rod Johnson para prover um suporte melhor ao Spring que outros AS. Vamos ver...

Eu curto o estilo deles. Tá certo que tudo que a Bea faz é comprar empresas que fazem algo legal (Tuxedo, WebLogic...), mas eu curto. Apesar disso, ainda sou adepto ao JBoss, mas num ambiente onde software-livre não entra, seria minha primeira escolha.

O problema da Bea é tentar vender toda aquela parafernalha quase-RAD com Workshop, Beehive, portal, blablabla. O velho truque de vender ferramentas que vão esconder o fato dos seus "profissionais" serem apertadores de parafuso. Vão mesmo?

Ah, o logo:

Gostei da audácia do slogan, parece coisa do WinAmp :)

Só eu que acho eles parecidos?

Nota: Não ganhei comissão (aidna, ao menos) por este post. Na verdade não ganhei nem um CDzinho demo do Diablo :(

Por último, conversando com as pessoas no evento, vi o que já é fato conhecido: está todo mundo procurando desenvolvedor no Rio. Você não acha ninguém bom sem emprego e/ou ganhando pouco.

Achar um profissional JSP+JavaBean é mole. Profissional razoável? Prepare-se para gastar uma grana. Profissional bom? Conheço gente que está procurando ha um ano, literalmente. O emrcado aqueceu e os desenvolvedores sumiram... cadê vocês?

Avaliação CJ2005

2005-08-26T09:27:00.000-03:00

Você que foi no CJ2005 não deixe de preencher a ficha de avaliação. Desta forma teremos um evento aida melhor ano que vem ;)

Camadas na Reunião Mensal do RioJUG

2005-08-26T08:37:00.000-03:00

Como falei aqui, vou falar um pouco sobre Camadas na reunião mensal do RioJUG.

Para quem se itneressar, a entrada é gratuita e não é necessário fazer pré-inscrição, basta aparecer por lá ;)

Arquitetura de Camadas em Java Enterprise Edition

por Phillip Calçado

Dia: 12/Setembro/2005 (segunda)
Horário: 19:00 horas
Local: Auditório do SENAC - Rua Santa Luzia, 735/7º andar
Dica de Acesso: Estação Cinelândia do Metrô pela saída Santa Luzia, atrás do Consulado Americano
Entrada: Gratuita

A Palestra

Algumas pessoas acreditam que uma aplicação Java Enterprise Edition utiliza Camadas por si só.
Outros acreditam que o Modelo MVC garante o uso de Camadas, muitos ainda nunca ouviram uma definição do que seriam as tais Camadas.
Nesta breve apresentação, os conceitos de Camadas serão apresentados e discutidos no contexto de aplicações Java EE, incluindo novas tendências como IoC e AOP.

O Palestrante

Phillip Calçado é JUG Leader do Grupo de Usuários Java do Rio de Janeiro (RioJUG) e do GUJ, o maior fórum brasileiro sobre a tecnologia.

Programa em Java desde 2003 e já atuou nas áreas de previdência privada, gestão de conteúdo, redes de telefonia e energia.
Instrutor, coach, conferencista e escritor ocasional.
Participa de projetos open-source e mantêm um site e blog em www.fragmental.com.br

Conexão Java 2005 - Parte II: O Workshop

2005-08-25T15:53:00.000-03:00

Olá,

Muito feliz, continuo o relato do CJ2005 :)

Eu dirigi o workshop Aumente o QI dos seus objetos: camada de negócios de verdade com Spring, no domingo. O objetivo era mostrar como cosntruir uma aplicação focada na camada de negócios, sem usar DTOs e derivados, e de quebra aprender um pouco de Spring e IoC...enfim, o que descrevi aqui.

O objetivo era levantar uma discussão e desenvolver o sistema em cima desta, mas como a turma era heterogênea, haviam pessoas com muita experiência e pessoas que nunca haviam visto Java. O CJ precisa definir tracks :(

Então a parte mais teórica da apresentação foi legal, mas a parte prática foi prejudicada. Não conseguimos criar mais que o esqueleto de uma estória (um casode uso) e não chegamos no Spring (problemas nos meus CDs e máquinas sem rede ajudaram também). A galera ficou frustrada :(

Eu acredito que quem foi gostou, mas teria sido melhor um tutorial ou palestra. Ficou um mini-curso teórico demais para o gosto de qualquer um :P

Em breve vou estar liberando aqui os slides e o código de exemplo, por enquanto os slides estão disponíveis no GUJ (em breve estarão também no site do evento).

Rapidinhas: Olho nos Trilhos

2005-08-23T23:14:00.000-03:00

Se voce nao levou a serio meu post sobre Rails do outro dia, saiba que tem gente grande de olho.

Confirmado...?

2005-08-23T13:31:00.000-03:00

Será?

Conexão Java 2005 - Parte I: O Debate

2005-08-23T12:51:00.000-03:00

Eu não ia conseguir falar sobre o CJ2005 hoje, estou extremamente atarefado, mas vou ter que comentar algo.

Para quem não sabe, o tal "TBC" (To be Confirmed) da grade no debate era eu. Fui chamado pelo Rafael Steil e depois pelo louds (Rodrigo Kumpera) para participar do debate com o hammett, o Hamilton Veríssimo. Eu conhecia o hammet de nome, me parece que quando eu entrei definitivamente para a comunidade Java ele estava indo apra o .Net.

A culpa por não ter meu nome no evento foi minha, que não consegui participar efetivamente da organização da atividade, mas enfim, rolou. Minha impressão é que foi muito bem.

Antes de continuar, o Hamilton provou que é um profissional extremamente competente e confiante. Ele aceitou a proposta de participar de um evento sobre Java falando mal de .Net. Você faria isso com a sua tecnologia? Convidamos outras pessoas para compôr a mesa, mas ninguém teve coragem, por isso o debate foi 1 a 1.

Para quem ainda não percebeu (tem gente muito lenta por aí..), o debate foi o contrário do normal (apelidamos carinhosamente de !debate). Eu meti o pau no Java e o hammett no .Net, a visão era de quem usa a tecnologia, não um cara xingando a mãe do outro que nem conhece.

Parece que mesmo assim tem gente que prefere xingar tudo e todos sem entender. Questionam a qualificação técnica do participante (engraçado ler os comentários nos blogs depois que eles "descobrem" que o hammet é commiter de projetos super respeitados e autor de livro sobre ASP.Net...além de entender muito de Java) e até conceitos básicos de Ciência da Computação como listas ordenáveis.

Pessoas que nem sequer foram no evento tentar desmerecer os participantes. Pessoas que foram e não repararam nem que o Rodrigo era o moderador, não participante, questionam.

"Ah, é porque eles são de .Net, esse povinho é assim mesmo" ...ah é? Na verdade eu ainda estou esperando reações parecidas do lado Java, bem parecidas. Muito parecidas.

O Hamilton postou uma resposta de altíssimo nível no seu blog. Não sou indicado para falar de .Net (e por isso nem poderia participar dum debate normal deste tipo), mas acho que foi na mosca.

Groooooooooooooooooovy

2005-08-18T17:29:00.000-03:00

Você tem que alterar os pacotes no import de 1000 arquivos. Opção? sed, claro.

No meu caso, acho que foi mais rápido escrever este scriptizinho em groovy do que ler as páginas de manual dos pipelines que teria que fazer.

#!/usr/bin/env groovy

new File(this.args[0]).eachFileRecurse(){
input ->
filename = input.getAbsolutePath();
output = new File(filename+".REPLACING");
if(!input.isDirectory() && (input.getName().matches("^.*java\$"))){

println("################# UPDATING FILE ["+ input.getAbsolutePath()+"] ##############################");
input.eachLine{
line -> modified = line.replaceAll(this.args[1], (this.args[2]+"\n"));
output.append(modified)
}
}
input.delete();
output.renameTo(new File(filename));
}

Ele recebe três parâmetros: [0] diretorio onde começar [1] regexp com linha a substituir [2] texto para colocar no lugar. Como sou newbie em Groovy, acho que dá pra melhorar muito...sugestões?

(não o algoritmo em si, eu sei que tá uma merda, mas otimizar script que você vai usar uma vez na vida é um tanto quanto perda de tempo demais para mim, quero saber sintaxe e truques)

Ouvindo

2005-08-17T20:58:00.000-03:00

Cara, como eu rodei pra achar esse CD!

CJ2005: Esquentando os Motores

2005-08-17T14:56:00.000-03:00

Para quem não sabe,e ste fim de semana estarei no Conexão Java 2005. Alémd e ajduar na organização como colaborador do GUJ, estarei minsitrando um workshop (não é exatamente um minicurso) sobre implementação de uma Camada de Negócios com objetos de verdade, utilizando como infra-estrutura o Spring Framework.

Ao contrário do que muitos pensam, não é curso de Spring. Minha propsota é simples:

Breve explicação sobre o tema de camadas
Apresentação de um pequeno problema
Modelagem do Probleama utilizando Objetos
Integração de Camadas Utilizando o Spring

Coisa simples, mesmo porque o tempo é limitadíssimo (2 horas apenas) e os recursos didáticos também. A idéia é montarmos um sisteminha (só a camada de negócios, o resto eu levo de casa :P ) e irmos desenvolvendo a idéia.

Sem "classes de lógica", "classes de dados", VO/DTO/TO, EJB, JavaBeans ou qualquer outra coisa. Apenas POJOs e alguns padrõezinhos. Mesmo o Spring é coadjuvante.

Espero vocês lá :)

Ah! Para quem é do Rio e não vai poder comparecer (tsc, tsc...) devo fazer algo aprecido por aqui em breve ;)

Matando a Curiosidade

2005-08-17T09:52:00.000-03:00

Algumas pessoas me pergutnaram porque eu chamo o McDonald's de McDonald's, nada demais, mas taí a resposta.

Oi, Bruno,

Eu vi seu comentário há pouco, ainda não pude postar nada lá, trabalho tá complicado.

respondendo a sua dúvida, não é nada demais, é apenas uma comparação do tipo pagou-passou.

Você entra no mcDonald's, escolhe o que quer, paga, espera e recebe.

Você entra na Estacio, escolhe o que quer fazer, paga, espera e recebe
o diploma ;)

[]s

Pequeno Dicionário da Reusabilidade em Software

2005-08-16T20:28:00.000-03:00

Componente:
Um componente é um pedaço reutilizável de software. É utilizado de forma genérica e significa desde uma simples classe até um subsistema.

Teoricamente, um componente:

Tem múltiplo-uso, é criado para ser reutilizável
Independente do contexto: Não depende das suas aplicações clientes
Pode formar compoentnes maiores se agrupado com outros componentes
Encapsulado, provendo uma interface para acesso á suas funcionalidades
Instalado e desenvolvido independentemente da aplicação cliente
Implementação substituível desde que mantida a interface exposta pelo componente

Da wikipedia, tirei esta figura:

O componente FooBar expõe interfaces para que seus clientes utilizem suas funcioonalidades. Se amanhã eu resolver utilizar uma outra implementação, chamada BarBar, eu posso simplesmente substituir FooBar, desde que BarBar implemente suas interfaces (GetStuff e AddStuff).

Framework:
Um framework é um conjunto de componentes de software que provêem uma arquitetura e estrutura básica para o desenvolvimento de uma aplicação. É uma aplicação semi-pronta que deve ser extendida e personalizada.

Recentemente, têm se utilizado a palavra framework para designar qualquer conjunto de bibliotecas, se perdendo seu sentido real.

Bilbioteca(Libraries):
Subprograma ou coleção de subprogramas reutilizadas em aplicações. Contêm implementações de rotinas úteis que podem ser reutilizadas em outras aplicações.

Container:
Gerencia o ciclo de vida de componentes e provê serviços a estes.

API:
Interface exposta por um componente.

Camada Lógica (Layer):
Separação de componentes por responsabilidades.

Camada Física (Tier):
Separação de Camadas Lógicas por vários nós (máquinas).

Pilhas Proprietárias, Pilhas Livres e Pilhas Padronizadas

2005-08-10T09:25:00.000-03:00

Qual é o clima atual no mundinho JEE (ou J2EE se você ainda não está nos novos tempos) ?

Há Muito Tempo Atrás, Numa Galáxia Muito Distante...
No início, havia o caos. A única pseudo-padronização no mundo das aplicações cooporativas de massa era o MTS com COM. Quem podia, contava com Tuxedo e UNIX, mas isso não era muito comum fora dos bancos e operadoras de telecomunicações (que tem dinheiro de sobra).

Se você queria contruir uma aplicação transacional, distribuída (CORBA ou DCOM, únicas opções levadas a sério), escalável, cheirosinha, você tinha que escolher um fornecedor. Ao contrário de JEE, os fornecedores não lhe davam uma implementação, eles lhe davam toda a tecnologia, você ficava preso a ela.

JEE Ao Resgate (ou Desgaste)
Então, alguém pensou em usar aquela linguagem de applets para produzir aplicaçõs de verdade e foram surgindo as especificações que culminaram no JEE, com o poderoso EJB como seu Rei e Deus.

A pilha JEE é comsota por tantas especificaçõe sque abrangeriam quase tudo necessário para uma aplicação de grande porte.

O grande problema, como quase sempre, foi a dose excessiva de hype. Toda documentação sobre JEE pré-2003 vai te falar em objetos distribuídos, componentes distribuídos, aplicações distribuídas, transações distribuídas, interfaces distribuídos... e surgiu a Primeira Lei da Distribuição de Objetos, de Fowler:

Não Distribua Seus Objetos

Distribuir objetos num sistema é de uma forma bem geral desnecessário e complexo, mas JEE faz pensar que se você não distribui (ou não consegue distribuir) objetos, você é um marsupial, já que tem toooodas aquelas maravilhas tecnológicas para suportar isso. Para ter uma noção, basta saber que a especificação de EJB 1.0 não previa acesso local, apenas remoto, aos componentes.

Apesar dos problemas, JEE surgiu e se manteve como a plataforma de facto para aplicações enterprise (seja lá o que isso signifique de verdade).

Mas.. com o passar do tempo a coisa foi pegando fogo. Pessoas desenvolveram alternativas bem viáveis aos recursos de JEE criticados (EJBs, quase sempre), e surgiram ferramentas fantásticas como o Spring Framework e o Hibernate, mas que são proprietárias (são software livre, mas não são um padrão).

O Hibernate, depois de ganhar gás ao ser incluído no JBoss, virou modelo para o EJB 3.0. O Spring, apesar de uma plataforma comprovadamente (pelo menos por mim) excepcional, não teve a mesma sorte, e agora que a nova especificação de EJB traz recursos de IoC, começou uma guerrinha entre projetos. A projeto Hibernate vem tratando com hostilidade o povo do Spring, já que eles "não são o padrão".

Piratas, Padrões e Picaretas
Se você for começar um projeto hoje, que tecnologias vai utilizar?

Se você for uma ameba ou trabalhar para amebas, vai usar EJB sem nem ler requisitos. Se você for um cara que sabe avaliar a melhor ferramenta para o serviço, come vegetais e exercita o cérebro, vai acabar numa senhora dúvida.

A pilha JEE oferece muitos serviços e muita complexidade, mas pelo menos é padrão.

O Spring oferece serviços de uma forma leve e bonitinha, mas não é padrão (seus objetos de negócio não estão presos ao Spring, não é tão difícil migrar os serviços para alternativas caso queira),e é apenas um entre muitos.

Claro que se você prefere que os outros façam a escolha por você, algumas empresas estão criando suas próprias pilhas, empacotando projetos Open Source e formando suas próprias visões do Java para aplicações de grande e médio porte (Pequeno porte? Por favor, esqueça JEE, se não Java. Conhece o Rails?). Temos uma brasileira, inclusive.

Então, temos um problema.
Temos mesmo?

Liberdade de Escolha
A confusão tem seu lado bom. Se fosse nos antigos tempos negros do Java Enterprise Edition, você não teria escolhas, tinha que usar EJB e pagar milhões num Servidor de Aplicações. Hoje você pdoe resolver o mesmo problema de milhões de maneiras diferentes e com um Tomcat (ou Jetty se você for um cara esperto).

Leia a seçaõ acima de novo, mas com outros olhos. Você pode escolher. Isso é muito importante.

Infelizmente, escolher bem é difícil. No mínimo você deveria conhecer um pouco sobre o cenário atual, o cenário futuro e muito sobre tecnologia. Existem pessoas que simplesmente precisam que alguém lhes diga o que fazer, o que usar, e para estes um cenário mais fechado é o ideal.

Seja lá o que você escolher, considere alguns pontos:

Empresas podem acabar, cuidado ao se prender a uma
Projetos de Open Source Software podem acabar, mas o código esta lá (você acha que se o Struts for definitivamente e indubitavelmente depreciado ninguém vai mantê-lo?)
Não use uma tecnologia onde mais de 20% do código construído por seus programadores (ou ferramentas) é pumbling (configuração, adaptadores, gambiarras) e não regra de negócio
Não ache que uma ferramenta (Editor, IDE, plugin, Ant Task) vai reduzir complexidade gerando código (código gerado conta nos 20% da regra anterior, bytecode gerado não conta)
Não se prenda a uma plataforma que não permita integração com o padrão JEE (mes mo EJB)

Por esses pontos, hoje, eu escolheria o Spring em boa parte dos meus projetos. Qual a sua escolha?

(Este post foi motivado pelo do Floyd Marinescu)

De Volta ao MCDonald's

2005-08-09T22:54:00.000-03:00

Começaram as aulas no McDonald's.

Eu me inscrevi em algumas matérias com títulos bem ttneressantes: Tópicos Especiais I e II e Tópicos Especiais em Linguagem de Programação.

Tópicos I foi ontem. JSP e Servlets. Imagine um treinamento meia-boca sem computador. Eu não acho que aula de computação tenha que ter computador sempre, porém aquilo não é uma aula, é um overview.

Hoje foi Tópicos Especiais em Linguagens, matéria de último (8º) período. PHP. PHP? PHP! Essa foi especial, o professor falou que vai usar as três primeiras aulas (umas 4,5 horas/aula) para instalar o PHP e o Xitami em Windows (nem Apache o cara usa!). Ah, essa é sem computador também, essas aulas vão ser no datashow. Três trabalhos, um em HTML, um em PHP e um em XML (validando cotnra um DTD, parece).

Não é um curso de extensão, não é uma matéria optativa, é uma matéria do bacharelado.

Eu também tive que ouvir que não existe linguagem mais rápida na web que PHP, que esta não tem máquina virtual, pelo contrário, o objetivo de PHP é ser "perto da máquina".

Teoricamente, estes alunos já viram C, C++, Java (um semestre cada), conhecem todas as camadas do TCP/IP (dois semestres), o básico de sistemas operacionais e sistemas distribuídos (dois semestres), e bancos de dados relacionais (dois semestres). E ninguém sabe nada.

Depois me perguntam porque eu não levo a Estácio a sério. Depois me perguntam porque sou contra regulamentar a profissão e exigir diploma de terceiro grau.

Ah, e isso não acontece só no McDonald's não, que fique bem claro. Além de tantas outras concorrentes, eu conheço vários bacharelandos e mestrandos de universidades excelentes que não sabem absolutamente nada de nada.

A diferença é que estes tiveram uma chance de aprender. E de graça.

Do Not Disturb

2005-08-08T10:05:00.000-03:00

Meu sumiço recente tem vários motivos, dentre eles a preparação do minicurso do Conexão Java 2005, que tem tomado bastante tempo (estou organizando uma caravana do Rio de Janeiro, quem quiser ir, entre em contato ;) ). Os outros vão ficando claros aos poucos (como já dizia Dona Filó: Mistéééééééééééééééééééério...).

Ontem, o Vinci me deu uma dica muito legal: Workrave. Este programinha te ajuda a prevenir LER calculando o tempo que você usa o computador e propondo paradas e exercícios. Não sei se vou realmente conseguir usar isso muito tempo, mas estou tentando. Na verdade estou me sentido bem confortável usando, sei lá, consciência menos pesada...

Mais detalhes no whitepaper, está em inglês mas o programa tem I18N e fica em português ;)

Inscrições Abertas para o ConexãoJava'05!

2005-08-01T16:50:00.000-03:00

O evento da comunidade Java brasileira, Conexão Java 2005, já está com inscrições abertas.

A segunda edição do evento consegue superar a primeira, com muito conteúdo para todos os paladares. Veja a grade aqui.

Eu devo estar tentando manter a atenção de quem se atrever a assitir meu mini-curso no domingo. Java, OOP e Spring na camada de negócios, para quem acredita que só código procedural salva.

Bom, inscrições gratuitas abertas por curto tempo aqui ;)

Pérolas de Lista de Discussão I

2005-08-01T15:20:00.000-03:00

Mon, Aug 1, 2005 at 2:57 PM

Reply-To: java-x@yahoogrupos.com.br

Olá pessoal!!!

Como faço para arredondar para mais um valor contido em uma variável do
tipo int?
Desde já, obrigado.

Abraçcos,

C.O.B.

ABCD

Mon, Aug 1, 2005 at 2:58 PM

Reply-To: java-x@yahoogrupos.com.br

uai..naum tem como vc arredondar um int. ele ja é arredondado!

Garota de Ipanema!?!

2005-08-01T10:26:00.000-03:00

Já que eu já escracehi minha tietice pela melhor banda de seattle ever, mais um pouco não faz mal :P

Pode ser boato, pode ser pegadinha, pode ser o diabo a quatro, mas no site oficial do Pearl Jam
vocês podem ouvir, com clareza, a calma voz de Tom Jobim cantando um clássico da MPB.

Nada nas datas, mas muitos boatos na Internet.

Será que pela primeira vez na vida vou conseguir ir a um show de uma
banda que eu curto antes dela acabar?!?!?!

Shoes, que paga quanto for por esse teorico show

Eu queria conhecer mais gerentes...

2005-07-27T09:38:00.000-03:00

para poder indicar este artigo para ainda mais gente.

As you can see from the graph, there is a certain point at which a developer starts learning more about the domain and not learning much, if anything, new technically. For many developers this may not be an issue, but for other developers this can result in a loss of interest in the company, the product, or their job as a whole.

A developer may be seeking to improve their skills, and not care as much about domain specific knowledge. If that is the case, this is the point at which a developer can become dissatisfied with his job and look on to bigger and better horizons.

Anglicanismos Perigosos

2005-07-26T16:03:00.000-03:00

No javaSoft:

J2EE Team Leader - SP

A XXX procura um J2EE Team Leader com as seguintes características: Ele gera uma equipe de 4 desenvolvedores Java. Ele é responsavel pelo respeito dos prazos, custos e qualidade dos desenvolvimentos. Ele é reconhecido pelas qualidades de liderança e é conhecido como um ótimo motivador. Ele tem uma experiência comprovada com metodologias de desenvolvimento de softwares (RUP), modelagem de casos de uso e desenvolvimento de test cases. Conhecimentos de alto nivel do UML é um requisito. Parte das atividades incluirão também desenvolvimento. Por isso, ele já é um desenvolvedor J2EE experiente, com domínio do desenvolvimento multi-câmadas usando tecnologias tais Struts, EJB, Junit, etc. Estes conhecimentos serão usados para coachar a equipe sobre pontos de design, guidelines, etc. Tem 5+ anos de experiência em desenvolvimento de software. Enviar currículo, preferencialmente em inglês, junto com expectativas salariais

E no dicionário:

coaxar

{verbete}

Datação
a1805 cf. BocOp

Acepções
■ verbo
intransitivo
1 soltar ou fazer ouvir a sua voz (a rã ou o sapo)
Ex.: rãs e sapos coaxavam próximo
transitivo direto, bitransitivo e intransitivo
2 (1858)Derivação: sentido figurado.
grasnar ou soar como a rã ou o sapo
Ex.:

Etimologia
lat. coaxo,as,ávi,átum,áre 'coaxar', de coax 'voz imitativa da rã', do gr. kóaks 'id.'

Sinônimos
ralar, relar

Homônimos
coaxo(1ªp.s.)/ coaxo(s.m.)

...que paguem muito bem...

Hospedando Ruby on Rails

2005-07-26T15:38:00.000-03:00

A critério de curiosidade, mandei um e-mail para a Locaweb (onde já hospedei alguns projetos e ficam o site do GUJ, Portal java e RioJUG) e Infolink (onde tenho o domínio fragmental.com.br) perguntando sobre a disponibilidade do Ruby on Rails.

Tudo começou porque estava conversando com um amigo recém-promovido a gerente de uma agência web, e estava pensando em sugerir para ele o rails. Eu sugeri o Mentawai, mas conheço bem o tipo de negócio de uma agência deste tipo e existem muitos projetos compostos apenas de "gerenciadores de locadora". Neste caso uma linguagem de script é melhor, mas usar ASP clássico, para mim, é fora de cogitação, e usar PHP ou CGI me parece algo retrô demais.

Semrpe que alguém fala em produtividade ao jsutificar uma arquitetura fedorenta utilizando JSPs ou Servlets/Actions com regras de negócio e acessando um SGBD, eu me indago se esta pessoa acredita que só existe Java no mundo.

Bem, a Infolink ainda não respondeu, mas a locaweb mandou um e-mail:

Boa tarde,

Disponibilizamos nas hospedagens em platafoma Linux o Ruby.
Para mais informações sobre os componentes e linguagens suportadas nos
servidores pedimos que acesse o endereço
http://site.locaweb.com.br/assinaturas/planos_de_hospedagem.asp

Apesar da página em questão não mencionar o Ruby (a página que menciona é a http://site.locaweb.com.br/assinaturas/caracteristicas.asp ), parece que sim.

A Locaweb é conhecida por seu suporte técnico ruim e pela droga que é ter um contexto de testes e um de produção que só é reiniciado se você implorar, mas se você for paciente acaba dando certo na maioria das vezes.

Como a Infolink suporta Python, não acho que deva ter problemas. O suporte deles é bom e disponibilizam um shell SSH para você (todo provedor deveria fazer isso!).

O TaQ disponibilizou um excelente tutorial de Ruby em portugues, que tal dar uma olhada no rails agora?

Ataulizado (28/07 15:31):
Resposta da Infolink:

Prezado Philip,

Desculpe-nos a demora na resposta. O ambiente ruby não era padrão em nossa
hospedagem. A partir de hoje o ambiente está disponível em nossa hospedagem
a partir de nosso plano premium.

Atenciosamente,

Comercial
Roberto Ribeiro

Joel: Na Mosca

2005-07-26T12:08:00.000-03:00

Pra variar, o Joel fala pela voz dos oprimidos engenheiros de software: Hitting the High Notes deve ser lido. Agora. Não tô brincando.

De volta

2005-07-24T23:52:00.000-03:00

Minhas ferias acabam na prática em oito minutos (23:52 hs).

Eu e Tatiana acabamos de voltar de Lumiar, uma cidadezinha fantástica com um website horrível. Fica antes de Friburgo. Ficamos hospedados na simpática Pousada Pierro, recomendadissima pelo ambiente calmo, rio de aguas limpidas e principalmente a simpatia do casal Rosana e Marcus, os proprietários, que entre uma cachacinha e outra servem pratos que você não encontra facilmente nem na cidade (truta com alcaparras, recomendadíssimo). Tinham que ser de Niterói :)

Ficar lá me fez parar e pensar sobre largar tudo e viver de fazer software pra pousada no meio do mato. Claro que a lembrança de quão longe eu estava da familia, de uma praia e de um bar com Heineken me fez desistir imediatamente, mas acho que este pensamento não vai embora completamente tão cedo, se for.

Momento Turístico acabado, vamos a um breve resumo das férias. Eu tinha muito o que fazer e não fiz quase nada. Ponto final.

Amanhã tem palestra do Sérgio Oliveira sobre o Mentawai no RIOJUG. Espero encontrar todos os (dois) leitores cariocas deste blog lá. Mais detalhes no site do JUG.

Falando no Sérgio, ele acabou publicando um artigo no Java World sobre o menta, bem legal e vale uma lida. Após a publicação, eu enviei a notícia para o theServerSide, e como sempre meteram o pau em tudo (será que o hani leu?).

Amanhã é meu útlimo dia oficial de férias, e eu ainda tenho muito o que fazer. O Conexão Java'05 já tem data (20 e 21 de Agosto) e uma grade provisória definida, a galera do GUJ e PortalJava está trabalhando muito nisso.

Um dos diferenciais do CJ vai ser o LiveForum. A idéia é trazer o mesmo clima que temos nos fóruns virtuais para o mundo real.

Falando em fórum virtual, eu tive uma idéia e psotei no GUJ outro dia. É sobre utilizar metadados para expressar estereótipos padrão da UML, dêem uma olhada. Como disse lá, mandei um e-mail ao comitê que especifica a JSR 250. Ainda não obtive resposta.

Nesses quase quinze dias eu desenvolvi uma Bloglines-fobia. Fui enrolando, enrolando e tenho mais de 7000 itens novos para ler, a preguiça tem me feito passar longe do bichinho. Acabo de dar uma olhadela, criei coragem e entrei nos blogs de java. Marquei alguns posts interessantes, podem valer comentários aqui, mas deixemos para amanhã ou depois.

Bom, depois dessa rápida atualizada, espero aparecer com posts menos chatos (eu sei que tenho prometido isso há algum tempo, uma hora eu acerto :P).

Todo Mundo é Ágil

2005-07-15T12:44:00.000-03:00

O blog do XP Rio dá a dica de um ótimo artigo por Pete McBreen. Pete é o autor do aclamado livro Software Craftmanship, que aidna não tive o prazer de ler.

No texto, o autor fala do que está acontecendo com o mercado hoje, onde todo mundoe stá dizendo "eu sou ágil". Isso, como ele afirma, aconteceu com Orientação a Objetos, também com componentização, RAD, MVC e tantas outras coisas.

Realmente isso está acotnecendo, basta olhar em volta. Me lembra uma empresa brasileira que vende uma IDE RAD dizendo ser um "método ágil". Também já ouvi alguns líderes de equipes de desenvolvimento falando uma série de besteiras sobre como sua metodologia é ágil.

Então, Pete dá a dica com dez lições simples para provar que algo não é ágil (tradução livre resumida com comentários adicionais meus):

O "Project Plan" acaba de ser divulgado, mostra o primeiro release acontecendo 18 meses depois do início do projeto.Num projeto ágil o foco é na atividade cosntante de planejar, não no plano resultante. Não adianta ter datas que não serão cumpridas.

O gerente de projeto fala sobre artefatos que os analistas vão produzir para os arquitetos. Modelo Cascata (Waterfall) em cheio. O próximo passo é entregar as especificações de arquitetura aos projetistas, que entregam aos programadores. Isso é tudo, menos ágil (ou bom).

Arquitetos e analistas afirmam orgulhosamente que não codificaram uma linha sequer no último projeto. Mostra que se pensa em codificar como atividade trivial. Isso vai totalmente contra o Agile Manifesto, que diz claramente que software funcionando tem mais valor que documentação.

Programadores e testadores estão no nível mais abaixo da cadeia alimentar. Como no anterior, fazendo isso torna impossível um processo ter Agilidade. Porgramadores são a alma do processo.

O analista cosntantemente tenta fazer os usuarios assinarem o tal documento dos requerimentos. Congelar os requisitos é o sonho dequalquer analista, ams isso não vaia cotnecer nunca, não importa que o cliente assine o documento com seu sangue. A proposta Ágil é colaborar com o cliente, não limitar suas escolhas.

Desenvolvedores reclamam quando uma mudança nos requisitos passa por cima do burocrático processo de controle de mudanças. Processos ágeis acolhem mudanças.

Você está a mais de dois meses no projeto e aidna não foi exibida nenhuma funcionalidade útil aos usuários. PowerPoint e telas mock não contam.

O líder do projeto considera documentação mais importante que comunicação. Fazer registros em documentos oficiais para poder rastrear o significado de qualquer mudança costuma ter como efeito uma equipe confusa sem a menro noção do que está fazendo (ou do que os outros estão fazendo). Se algo é importante para valer um documento, é importante para ser conhecido por todos.

Testes e verificação de qualidade não são partes integrantes e respeitáveis do processo. Ser Ágil é escrever software de qualidade, e a comprovação que um software tem qualidade é dadas de forma prática através de testes. Mesmo empresas com grandes departamentos de QA mutias vezes não elvam a sério esta etapa, deixando a verificação da qualdiade apenas como última etapa, logo antes da entrega.

Finalmente, você finge ser ágil se em seu processo:

Tarefas são dadas a pessoas, que pegam seu trabalho, se isolam num lugar quieto (sua baia) e tratam aquilo como um trabalho solo. Num lugar onde as pessoas usam fones de ouvido ou se isolam para não serem perturbados por outros membros do time, você pode apostar que o líder de projeto não entende desenvolvimento colaborativo. Se não entendem o básico disto, podem ter certeza que o processo não é ágil, não importa os quadro-brancos, reuniões em pé ou programação em par.

Ferias e Novos Contratos

2005-07-15T02:18:00.000-03:00

Estou de férias do meu daily job, 15 dias, por isso estou meio longe. Sim, eu sou nerd e estou boa parte do dia no computador, ams tenho feito algumas coisas que não são ão ligadas ao meu dia a dia seja de trabalho ou projetos paralelos, então não tem muito o que postar aqui. Minha programaçõa de férias inclui muitas horas de Monty Python, comemoração de um ano de namoro, bebedeiras, Catan e outros jogos, coisa que há muito eu tenho deixado de fazer.

Ok, estou sempre no GUJ e na RioJUG.

Hoje a noite resolvi dar uma reformatada em alguns dos textos que tem por aqui. Fiz um modelo gráfico para usar, modifiquei a formatação (e alterei o texto em algumas partes) do Contratos Nulos, feedback, please!

A versão nova está aqui.
As versões antigas estão fora do ar.

Já tenho tema para um próximo textinho, vamos ver quando a vontade se junta a possibilidade :P

Mac

2005-07-09T18:31:00.000-03:00

Continuando o papo sobre freelancers, eu tive péssima experiência como emrpeendedor (imaturidade, provavelmente), mas essa apresentação de Wil Shipley fala bem ao estilo do post. Claro que é focado no mercado americano e fala sobre o bizarro mundo dos ISV para Macintosh, mas é leitura obrigatória para uma visão diferente e algumas risadas.

Eu já sabia!

2005-07-08T08:41:00.000-03:00

Se você ver minha lista no AudioScrobbler vai ver que eu já sabia disso!

Ok ,ok, sem flames, eu sei que é exageiro, mas de que Pearl Jam é MUITO bom, disso não há qualquer dúvida :)

Wow!

2005-07-07T15:23:00.000-03:00

Dá para acreditar nisso?

Nota: são 15:18, os atentados ocorreram por volta de 8:51.

Da Webopedia:

wiki
Last modified: Friday, June 24, 2005
(n.) A collaborative Web site comprises the perpetual collective work of many authors. Similar to a blog in structure and logic, a wiki allows anyone to edit, delete or modify content that has been placed on the Web site using a browser interface, including the work of previous authors. In contrast, a blog, typically authored by an individual, does not allow visitors to change the original posted material, only add comments to the original content.

The term wiki refers to either the Web site or the software used to create the site.

Wiki wiki means “quick” in Hawaiian. The first wiki was created by Ward Cunnigham in 1995.

O SOA Nosso de Cada Dia

2005-07-05T09:35:00.000-03:00

Você ouve, ouve, ouve... mas cadê o SOA de verdade?

Assim como os componentes que nos prometeram que iam abundar as prateleiras, o tal do SOA parece não sair do papel, primeiro dos PDFs de teses acadêmicas, agora do papel brilhante e caro das revistas "top de linha".

Mas, assim como a componentização, só parece que não está acontecendo. Olhe em volta.

O problema dos componentes e todo o hype formado ao redor deles foi que os componentes tomaram outra forma. Componentes de lógica de negócio são raros, mas qualquer outra coisa pode ser comprada ou obtida de terceiros (ninguém que eu tenha lido falava em como o software livre iria influenciar o mercado de componentes), de geradores de relatórios até clientes HTTP, raramente se precisa escrever algum componente de baixo nível hoje em dia, basta procurar um pronto.

E o SOA? Você já reparou que estamos vivendo na onda das APIs?

Com a API do Google Search, você pode fazer buscas no Google em sua aplicação.
Com a API do Flickr, você pode manipular seu álbum de fotos.
A API do Blogger permite criar e editar posts no seu blog.
A API do Google Maps permite você fazer coisas loucas com as fotos de qualquer lugar do mundo.
A API do del.icio.us permite gerenciar bookmarks.
A API do Bloglines permite manipular o agregador RSS (obrigado pelo lembrança, Diego ;) )

E muitas outras, estãos são apenas as dos sites que eu uso constantemente.

Perceba um padrão: são sites. Eles têm uma interface (no caso do flickr uma interface digna de respeito), e teoricamente seu serviço deveria incluir o uso desta. Uhm...deveria?

O que estes sites "vendem" não é a interface. O que o Google Search oferece não é uma caixinha de texto, é uma pesquisa na internet! O maps fotos por satélite e mapas interativos, o flickr organização de fotos por tags... etc.

Isso já atinge o desenvolvedor diretamente em como é importante separar interface de negócio. Interfaces mudam e a tendência hoje é ter algo como o del.icio.us, uma interface web bem fraquinha, mas uma senhora API que pode ser extendida em por browsers, aplicativos desktop e outros sites.

Esqueça a era do VB (ou Delphi se você, como acredito que sim, mora no Brasil ou Rússia). Com o advento dos computadores baratos com monitores coloridos, interface amigável virou lei, a lógica era o de menos (ok, geralmente é o bom e velho "coloca-no-banco-lista-tira-do-banco"). Hojeelinhas bonitinhas são facilmente construídas em segundos com editores gráficos, a lógica de negócios e a integração destas é o que importa.

Essas APIs são baseadas em protocolos leves sobre HTTP, que apesar de bem problemático para aplicações de verdade continua sendo padrão na Internet. Por enquanto, são serviços únicos mas logo em breve você poderá solicitar uma pesquisa assim:

Envia ao Yahoo! e Google um pedido de numero de resutlados para pesquisar "frango da malasia"
Yahoo! informa que achou 482 resultados, Google 379.
Você cancela a pesquisa no Google e pede os resultados do Yahoo!
O Yahoo! debita o referente a consulta (seja dinheiro, seja númerod e consultas/dia) e retorna os resultados num formato XML

Sua aplicação final (o que 99% dos programadores vai fazer nas empresas) vai ser uma telinha chamando serviços disponíveis na rede da empresa e emr edes externas. Hoje você já pode fazer isso.

Bom, eu sou técnico, mas vamos tentar dar uns palpites no ramo dos negócios.

Todos os citados acima são serviços gratuitos ou possuem versões gratuitas. Imaginar um modelo de negócios viável para serviços não é difícil, se baseie em coisas do mundo real. Quando você compra um ticket do metrô, você não compra nada além do serviço de transporte.

Venda tickets para sua aplicação.

Homo Burocraticus

2005-07-04T08:49:00.000-03:00

Esse texto desconexo é um desabafo.

É impressionante como conceitos enganam. O Homo Burocraticus prevalece nas empresas do mundo todo, e raramente alguém percebe que tem algo errado. Será que é evolução?

Você já o viu, certamente. Talvez na baia ao lado, talvez na sua baia. Esta espécie está sempre atrás do mais novo relatório XYZ, sempre querendo saber por que o documento ASD-00321.8 não está marcado para revisão.

As pessoas criaram processos para tentar fazer profissionais de todos os níveis trablharem bem. A idéia é simples: force os programadores medíocres a seguirem um conjunto de processos pré-definidos e burocráticos e eles não terão chance de fazer besteira. Os bons profissionais, como dizem, serão bons em qualquer processo.

Este ambiente criou espaço para uma raça enfadonha que se esconde atrás do processo. Você tem que acreditar no processo, o processo é tudo, é ele quem produz software, não as pessoas.

Reconhecer um ambiente assim é simples, basta ver quando um projeto possui como marco documentação. Note: documentação é importante o suficiente para perder tempo escrevendo-a, mas quando se dá às especificações o mesmo valor que funcionalidade implementada ou qualidade, nós ou estamos construindo um prédio ou estamos em maus lençóis.

Neste lugar, as reuniões são com as mesmas reclamações: "Não pude implementar ABC porque a especificação ainda está em revisão", "Err.. eu não sabia que não dava pra fazer o módulo B daquele jeito, vou ter que mudar a especificação e isso vai alterar outras coisas"... no fim das contas, sua especificação fica defasada e não serve para nada. Ok, depois você conserta, só que "depois" nunca chega, quando chegar a hora de fazer isso ou já tem projeto novo ou as pessoas deixam o time.

Ao invés de medir a qualidade pelo número de páginas ou abrangência de sua documentação, foque na única documentação que sempre está atualizada: o código. As linguagens de programação de hoje possuem um nível tão alto que já são auto-documentáveis.

Para manter seu código legível o uficiente para servir de documentação crie testes, pratique Domain Driven Design e refatore sempre.

Crie Testes
Programar orientado a testes é uma técnica muito boa, isso já foi dito em muitos lugares e não vou justificar novamente aqui.

Mas criar um teste unitário é utilizar um componente. Fazendo isso, você exercita a interface pública deste e diz quis as condições de erro e de acerto. Uma pessoa nova no projeto que lê o teste já sabe como a classe funciona e quando ela quebra do ponto de vista do usuário.

Pratique Domain Driven Design
Neste contexto, DDD é programar para o domínio. Quando você usa esta técnica, seu software (sua camada de negócios quase sempre) reflete o conhecimento do domínio do seu usário, você modela os conceitos do problema de uma maneira clara no software.

Ao invés de simplesmente criar estruturas de dados e algoritmos, você implementa conceitos e através deles cria um entendimento muito maior sobre o que seu sistema faz para seus usuários, você e para quem for ler seu programa.

Refatore
Refatorando seu código você em primeiro lugar exercita ele na sua cabeça. Para pessoas como eu que simplesmente não conseguem lembrar coisas, isso é inestimável.

Depois, você aumenta a qualidade do código. Quem ler seu código em seguida vai ter muito mais clareza do que quem leu aquela primeira versão, feita com um prazo curto e pressão de gerentes e usuários.

São medidas simples e aplicáveis em qualquer lugar, não é rpeciso que se tenha um processo XP, A, B ou Z.

Se você está preso num lugar onde especificações detalhadas são a ordem da casa, tente criar documentos mais abstratos (aposto que ninguém vai reparar). Não detalhe processos, documente apenas a interface externa do seu componente (que provavelmente outra pessoa vai precisar usar) e descreva em poucas palavras(ou diagramas) o funcionamento interno, utilize o encapsulamento aqui, faça a especificação ser uma interface do seu componente.

Tente colocar uma referência aos testes unitários como parte da documentação, apenas diga onde podem ser encontrados e, talvez (depende do ambiente) como executá-los. Se você está especificando para outro implementar, este pode se guiar pelos testes para entender o que você quis dizer.

Mantenha o documento aberto junto com o código (se sua memória RAM deixar, claro, do contrário imprima uma cópia e use caneta e marcador de texto), e quando for mudar algo drástico, mude o documento na hora. Como você escreveu de maneira abstrata, mudanças na implementação (que são mais comuns do que na interface, queira o bom Zahl) não devem alterar muito o documento.

Não crie documentação que pode ser gerada automaticamnete, como diagramas de classe. Não crie documentação só por criar, se não precisa usar, não crie.

Se você é gerente de projeto, por favor aprenda a medir o andamento do seu projeto de software através de métricas reais. Não sei se você reparou, mas PDF e documento Word não compila, não roda e não dá funcionalidade. O número de diagramas num documento é proporcional ao trabalho que dá atualizar tudo depois e, acredite, tudo vai precisar ser atualizado depois.

Note que eu não estou dizendo para você não especificar ou documentar, estou dizendo para você não gastar esforço em coisas que não trarão valor.

É impressionante....

2005-07-04T08:47:00.000-03:00

Como o orkut só funciona decentemente entre 6 e 9 horas da manhã GMT -3...

JSP Virou Coisa de Gente Grande

2005-07-02T16:10:00.000-03:00

Há um bom tempo eu não criava interfaces HTML.

Minhas últimas experiências com HTML, JSP e JSTL foram horríveis, e eu esperava não ter que usar isso tão cedo. Das útlimas vezes havia usado o Velocity para tentar fugir desta coisa horrível.

Eu gosto do Velocity não só por ser mais simples mas porque ele não te induz a colocar lógica em páginas, como scriptlets fazem. Como muitos parecem não saber:

Você não deveria, em hipótese alguma, usar JSP, Velocity, Freemarker ou qualquer outra coisa do gênero para qualquer outro fim que não seja gerar HTML dinâmicamente. A única finalidade destas tecnologias é criar HTML, não fazer processamento.

No meu último projeto, tive que criar uma simples interface web para a gerência de alguns parâmetros do sistema (que utiliza HTTP para sua atividade principal, mas troca mensagens em XML, não HTML) e como não tive muita escolha, resolvi usar as ferramentas padrão J2EE (como sempre, haviam sugerido Struts para uma aplicação CRUD com meia dúzia de páginas e servlets).

Me surpreenndi. Sério.

Claro que como estou sempre em fórums, eventos, palestras já conhecia JSTL, mas eu não sabia que ia efetivamente me dar prazer em usar. Apesar de eu não precisar de muitos recursos, a aplicação ficou bem limpinha e fácil de manter. Para aproveitar e aprender mais, resolvi fazer a interface tableless.

Eu ainda odeio fazer interface web, mas posso dizer que (como, aliás, já disseram no GUJ outro dia) pode-se usar JSP sem perder os poucos cabelos que restam no pobre programador.

Troca de Contexto

2005-06-30T13:00:00.000-03:00

Como falei antes, eu estava lendo um livro sobre casos de uso do RUP, mas acabam de me devolver o Agile Software Development, do Uncle Bob. Esse livro é dos primórdios do Manifesto Ágil, muito bem recomendado e parece ser excelente!

Com prefácio de Erich Gama, o livro tem uma abordagem informal baseada em estudos de caso. Cheguei na parte onde o manifesto é explicado, excelente escrita, coisa que você deveria mostrar ao seu gerente.

Estava pretendendo pegar um livro mais "escovador de bytes" (tem um Tanenbaum me esperando lá em casa há algum tempo), mas não resisti.

E o JavaBlogs.com.br?

2005-06-30T10:18:00.000-03:00

No ano passado, uma iniciativa em conjunto do GUJ e Portal Java produziu o jablo (quando fui no Conexão Java 2004, descobri que os paulistas pseudo-franceses falam "jablô", né dqo? :D), um portal de blogs brasileiros sobre Java (mas ate´blog não relacionado a java tinha, apesar de todos 90% técnicos).

Por um milhão de motivos, o site caia diariamente, não se conseguia logar, não funcionava por algumas semanas, ia e voltava... mas foi um sucesso. Nunca a comunidade brasileira produziu tanto conteúdo, dezenas de blogs com pessoas de dviersos níveis de conhecimento postando diariamente sobre os problemas em seus projetos, as soluções que adotavam, tecnologias novas, tutoriais e até polêmicas.

Enfim, após todos os problemas, o Jablo saiu do ar. Ele até voltou, mas cadê a comunidade? Parece que as idas e vindas do sistema tiraram a credibilidade do projeto. Eu mesmo tinha um blog bem ativo por lá, e acabei aqui. O blogger tem menos recursos, mais restrições, mas ainda não vi cair.

Só eu sinto falta da época de ouro dos JavaBlogs?

JavaOne 2005: Acompanhe no Flickr!

2005-06-27T14:36:00.000-03:00

Dica do dia: Se você, como eu, não tem grana pra bancar uma ida ao JavaOne, pode babar nos brindes maravilhosos diretamente no slideshow do flickr.

Casos de Uso: Conheça para Criticar

2005-06-27T14:16:00.000-03:00

Acabei de ler o livro do Riel na sexta. O livro era bom há uns dez anos atrás, mas agora está meio fora de foco. Muitos dos problemas apresentados são resolvidos com Design Patterns simples (quase sempre Observer), mas eu acho que seria legal como o segundo livro de alguém sobre OO. Exige conhecimentos básicos de C++.

Enquanto o mundo do software espera as notícias que vem de San Francisco (e algumas já estão disponíveis) eu comecei a ler um livro que tem muito pouco a ver com meu perfil: Use Case Modeling. Não, eu não estou trabalhando na IBM nem usando RUP, mas como quase todo infeliz eu sou obrigado a utilizar processos parecidos com o RUP/UP.

Não me entenda mal, nada contra casos de uso em si, apenas que a aplicação e o excessod e detalhes que eles são tratados no RUP além da divisão de papéis entre Analista, Projetista, peão e motorista de van me agride.

De qualquer forma, este livro parece que vai me ensinar algo a mais sobre os artefatos de análise do RUP. O processo em si tem seu lado bom (por ser um processo já é bom), e tirando o fato do autor usar setinhas no diagrama de caso de uso tem sido interessante nos dois primeiros capítulos.

Regras são Regras

2005-06-17T11:05:00.000-03:00

E tem gente que questiona porque cosntruir um Domain Model e uma camada de negócios consistente é importante. Leia o post no Portal Java e você vai ver um problema bem interessante.

No caso específico, alguém implementou regras de negócio em Actions Struts. Muito bom, exceto pelo fato que isso gera:

Acoplamento exacerbado ao framework e consequentemente ao HTTP
Programação altamente procedural (qual a diferença entre uma Action e uma função?)

Não, escolher outro framework não é a solução (mesmo que seja o Spring). O importante é saber que estas regras devem estar separadas em sua própria camada, modeladas através de objetos de negócio.

Bom, esse caso específico pede uma medida imediata que evite reescrever a lógica da aplicação toda novamente. Uma soluções é usar adaptadores.

Se você tem uma AdicionarUsuarioAction, uma RemoverUsuarioAction, por exemplo, pode criar uma interface assim:

public interface GerenciadorUsuario{
public adicionar(Usuario u);
public remover(Usuario u);
}

Todo código novo do seu sistema deve usar essa interface. O próximo passo é criar um Adapter para suas Actions, e isso mostra o que o acoplamento faz por você:

public GerenciadorUsuarioAdapter{

public void adicionar(Usuario u){
RequestAdapter req = new RequestAdapter();
requestAdapter.setParameter("login", usuario.getLogin());

ResponseAdapter resp = new ResponseAdapter();

executarAction(AdicionarUsuario.class, req, resp);
}
}

Uma bela gambiarra. Request e ResponseAdapter são implementações do HTTP request e HTTP response. executarAction(Class, HttpRequest, HttpResponse) faz a chamada à Action emulando um ambiente web.

A melhor solução, claro, continua sendo refatroar o código e remover a lógica de negócios do Struts. Não, não adianta colcoar esta no WebWork, XWork, Spring... o que importa é colocá-la em um Domain Model consistente e reaproveitável, mas Domain Model é assunto apra outro post.

Subversivo

2005-06-17T10:30:00.000-03:00

Sim, sou mais um adepto do "CVS melhorado".

Precisava de um modo de armazenar alguns projetos open-source e outros fechados e acessá-los de qualquer lugar. Para os livres até poderia usar o java.net (na verdade eu uso, o Subversion é um proxy) ou sf.net, masnem todo lugar permite acesso á protas "estanhas" como as do CVS. Decidi então colocar um no meu PC em casa, um P4 normal e mixuruca com ADSL 512kbps ligado 24/7.

Eu tinha até instalado o cvsnt, mas decidi testar o SVN. Segui os passos do tutorial do Heitor Rapcinski no GUJ, e a instalação foi super simples. Apenas alterei a porta do servidor para 80 e pronto. O acesso está bem estável e muito mais rápido que o CVS do java.net e sf.net :P

Controle de Versão é uma das práticas do SCM que mais são usadas hoje. É simplesmente loucura pensar em alguém configurando versões com arquivos zipados em backup, como eu já tanto fiz e aidna é feito em muitos lugares.

O Subversion tem suas vantagens sobre o CVS, vou fazer uma tentativa antes de recomendar ou não o sistema. No trabalho eu uso Perforce, que é bem legal para linha de comando, mas um pouco complexo apra Java (mudar nome de classes envolve renomear arquivos e um pesadelo anexado a isso).

Comentário: Spring in Action

2005-06-04T13:31:00.000-03:00

Acabo de ler o livro.

Bem, apesar dos muitos erros de ortografia (e quem sou eu para reclamar disso?), o livro faz o que se propõe: ensina a configurar o framework. Só não espere motivação para usá-lo, ou um guia de como tal e tal função pdoeria ser útil. Para usar o livro você já deve saber proque quer suar Spring, apenas desejando dominar as configurações.

Mas a pior característica do livro, na minha opinião, é simplesmente fazer uma substituição de EJB e suas service layers por Spring na maior parte dos exemplos. O livro é uma aula de anti-patterns de Orientação a Objetos, se você não entende porque, leia isso.

Resumindo: vale a compra, mas não espere demais.

Update: Minha proxima leitura e o Object Oriented Design Heuristics de Arthur Riel. Mais um classico :)

Resolução de Mês Novo

2005-06-02T14:50:00.000-03:00

Com a minha incapacidade de digitar um texto num editor e colar no blogger (as vezes por minha culpa, as vezes do blogger), decidi que vou manter os textos longos em PDF e colocar como texto no blog cosias mais breves apenas.

Com o novo blog saindo quando Zahl quiser, isso deve mudar novamente.

Ah, obrigado novamente ao renato pela força e os PDFs :)

Contratos Nulos

2005-05-29T18:45:00.000-03:00

NOTA: mais uma vez a droga do blogger ferrou a formatação. Assim que o primeiro relase do JRapido sair, eu converto os textos, mas prometo que da próxima vez eu tento fazer direto em HTML. Versão em PDF pelo renato aqui.

Um post por Todd Huss gerou algum burburinho recentemente. Todd reclama de ter que checar argumentos de métodos o tempo todo para ter certeza que não são nulos e ter uma linda NullPointerException.

Para quem não é de Java ou está começando na linguagem, uma NullPointerException, carinhosamente conhecida como NPE, acontece quando você chama um método em uma variável que aponta para null, por exemplo:

public static void fazerAlgo(String a){
a.split(" ");
}

public static void main(String args[]){
fazerAlgo(null);
}

Causaria uma NPE (chamando o método split em null).

Existe todo um misticismo com uma NPE, basicamente por um motivo: é um erro de programador. Seu sistema não devia lançar NPE. O grande problema é que geralmente as pessoas fazem assim:

public static void fazerAlgo(String a){
if(a==null) throw IssoNaoEhUmaNullPointerExceptionException("a deve ser definido");
a.split(" ");
}

Ou seja: fazem a mesma coisa que uma NPE faz, mas usando IllegalArgumentException ou outra exception qualquer.

Dos comentários que apareceram, uns indicaram o projeto nully, no java.net. O Nully é uma ferramenta para a IntelliJ IDEA que basicamente adiciona uma anotação @NotNull. que aciona warnings e erros na IDE quando você tenta implementar uma operação que poderia resultar am um valor null para o parâmetro marcado com a tal anotação. Você pode ver mais detalhes no site do projeto, mas eu não gostei mesmo disso.

Uma outra alternativa dada foi votar no BUG 5030232, da Sun, uma tentativa de adicionar o tratamento que a linguagem derivada de Java chamada Nice faz com nulls. Basicamente, Nice exige que você inicie com um "?" as variáveis que podem ser nulas, e não deixa (em tempo de compilação) acessar diretamente operações estas variáveis sem checar se a variável é null antes. Bela tentativa, mas ainda não é isso.

Adam Kruszewski comentou que no seu blog havia uma implementação com annotations e AspectJ. A implementação dele é bem simples, você anota um método e toda vez que este é chamado seus argumentos são checados, se algum for null ele solta uma exceção. Simples e prático, mas não foi desta vez.

A solução não sou eu quem vai dar, é um conceito muito antigo que surgiu junto com os primeiros pensamentos em objetos: Design By Contract.

Para explicar este conceito, vamos nos focar nos três pilares: invariantes, pré-condições e pós-condições. O conceito de Invariante, entretanto, pede uma breve explicação de Espaço-Estado.

Espaço-Estado
Você sabe que um objeto tem estados, não sabe? Pois bem. Cada componente do estado de um objeto define uma dimensão, pra simplificar, imagine um objeto da classe Ponto:

class Ponto{
String rotulo=null;
int x;
int y;
}

Esse é um ponto cartesiano, com três atributos que definem seu estado. O valor de x , e o valor de y definem o estado atual do ponto. x e y são as Dimensões do objeto.

Como o ponto muda de estado é seu comportamento. O objeto reage a estímulos, um objeto não muda de estado por si só. Em Java, implementamos o comportamento de objetos nos seus métodos. Vamos supor que nosso ponto só se mova de dez em dez espaços, na horizontal ou vertical, implementando isso:

class Ponto{
int x;
int y;

public void moverX(){
x=x+10;
}

public void moverY(){
y=y+10;
}

}

Sendo assim, os estados que um ponto pode assumir dependem do seu comportamento. No caso específico, o estado onde a dimensão x vale 2 é inválido, já que de zero x só poderia assumir o valor de 10.

O espaço-estado do objeto seria:

x=0,10,20,30,40,50,60,70,80...
y=0,10,20,30,40,50,60,70,80...

Ou seja: espaço-estado é o conjunto de valores de dimensões válidas para um objeto. Acho que isso dá uma clara visão do porque atributos públicos são perigosos.

Invariantes

Existem algumas condições que são necessárias para que um objeto esteja em estado válido. Um triângulo tem sempre três ângulos, um carro em funcionamento tem quatro rodas, um usuário tem lajem e senha definidos...

Essas são invariantes. "Invariantes" porque devem ser obedecidas em todos os momentos do ciclo de vida do objeto. Invariantes são restrições no espaço-estado do objeto.

Para alguns, é mais fácil pensar em invariantes pensam em como restrições de tabelas em um banco de dados. A tabela A tem uma chave estrangeira A1, que aponta para a chave primária de B e não deve ser nula.

Se, por exemplo, nosso ponto só puder se mover a uma distância máxima de 20 espaços de zero para x e 50 para y, a invariante seria o intervalo marcado em marrom abaixo:

x=0,10,20,30,40,50,60,70,80...

y=0,10,20,30,40,50,60,70,80...

É dever da implementação do objeto zelar que esteja sempre em estado válido. Sempre que fizer uma transição de estado, o objeto deve checar se está em um estado válido. Em Java, o que poderíamos fazer é:

public void moverX(){

x=x+10;

checarEstado();

}

public void moverY(){

y=y+10;

checarEstado();

}

protected void checarEstado()(){

if(!(x<20) || !(y<50)) throw new IllegalStateException();

}

Checar a invariante é apenas sanidade. Sua invariante nunca deve ser quebrada, e essa é a responsabilidade das pré e pós-condições.

Pré e Pós-Condições

Aqui está a resposta para o problema das NPE. Toda operação (ou seja: método) define contratos. O contrato de uma operação é:

Se quem chamar me garantir a pré-condição, eu garanto a pós-condição.

Ou seja: se o objeto que chama o método garantir que a pré-condição esteja cumprida, o método deve garantir que a pós-condição também esteja cumprida.

Para exemplificar, vamos criar um método que move nosso ponto um número de espaços qualquer, desde que seja no máximo 20 espaços por vez :

public void mover(int espacosX, int espacosY){

x=+espacosX;

y=+espacosy;

checarEstado();

}

Para evitar que a invariante seja quebrada e nós tenhamos certeza que o parâmetro é até vinte espaços, vamos estabelecer uma pré-condição através da checagem de parâmetros enviados e uma pós-condição:

public void mover(int espacosX, int espacosY){

//checando pre condição

if (!(espacosX > 15)) throw new IllegalArgumentException();

if( !((x+espacosX) < 20)) throw new IllegalArgumentException();

if( !((y+espacosy) < 50)) throw new IllegalArgumentException();

int antigoX = x;

int antigoY = y;

x=+espacosX;

y=+espacosy;

//checando pos condições

if(x!=(antigoX+espacoX)){

x=antigoX;

throw new IllegalStateException();

}

if(y!=(antigoY+espacoY)) {

y=antigoY;

throw new IllegalStateException();

}

checarEstado();

}

Acho que agora fica claro como resolver o problema das NPEs. O ponto é que você não deve checar contra valores nulos, mas sim contra valores inválidos. Você não deve evitar NullPointerExceptions, deve evitar que seus métodos processem argumentos inválidos.

A princípio, a pós-condição pode parecer inútil, mas lembre-se: você prometeu que ia entregar isso, não custa nada dar uma segunda conferida. Ok, em um caso simples como esse, é superficial.

Isso me lembra de uma ocasião onde tinha que gerar uma página HTML com no máximo 180 caracteres. O métodos que gerava o texto da página tinha no seu contrato a garantia que geraria no máximo 180 caracteres, e como era um processo muito complexo, sempre que terminava ele mesmo checava o texto gerado. Quando você não tem absoluta certeza que vai conseguir cumprir seu contrato (ou se seu método depender de outros métodos que podem não obedecer contrato nenhum), cheque antes de retornar.

Subclasses e Contratos

Como uma subclasse estabelece seu contrato?

Quanto á Invariante, a subclasse pode definir que sua definição de "válida" é diferente da classe mãe, por isso ela pode definir uma invariante diferente. Vamos exemplificar cirando uma classe-filha para nosso ponto:

class PontoLonge extends Ponto{

protected void checarEstado()(){

if( !(x < 1000) || !(y < 1000)) throw new IllegalStateException();

}

}

Nesse caso, a nova classe definiu que sua invariante permite valores maiores para x e y.

Como nosso ponto pode se mover para lugares muito mais longínquos é trabalhoso ficar indo de pouco em pouco. Vamos redefinir os métodos de movimento para nos movermos mais rapidamente:

class PontoLonge extends Ponto{

protected void checarEstado()(){

if( !(x < 1000) || !(y < 1000)) throw new IllegalStateException();

}

public void mover(int espacosX, int espacosY){

//checando pre condição

if (!(espacosX > 100) || !(espacosY > 100) ) throw new IllegalArgumentException();

if( !((x+espacosX) < 1000)) throw new IllegalArgumentException();

if( !((y+espacosY) < 1000)) throw new IllegalArgumentException();

int antigoX = x;

int antigoY = y;

x=+espacosX;

y=+espacosy;

//checando pos condições

if(x!=(antigoX+espacoX)){

x=antigoX;

throw new IllegalStateException();

}

if(y!=(antigoY+espacoY)) {

y=antigoY;

throw new IllegalStateException();

}

checarEstado();

}

}

Parece legal? Primeiro, uma sugestão é refatorar os métodos, olhe só essa quantidade de coisas repetidas! Esse exercício fica para você já que foge ao escopo do post.

Voltando à sobrescrita, você consegue imaginar um problema? Se não, veja o código abaixo, retirado de uma classe que usa os objetos ponto:

public moverUmPoucoUmPonto(Ponto p){

p.mover(11,21);

}

Que tal? Essa classe funciona com Ponto, mas não com PontoLonge. Parabéns para nós, acabamos de mandar todo o polimorfismo para o espaço, já que não podemos utilizar nossa classe derivada como usamos a classe mãe. Solução?

A pré-condição de um método sobrescrito em uma classe deve ser igual ou menos restritiva que a pré-condição do método na classe mãe.

Isso significa que nós poderíamos aceitar cosias que a superclasse não aceita, mas nós temos que aceitar tudo que a superclasse aceitaria. No código, nós poderíamos, poderíamos, por exemplo, dizer que o mínimo de espaços que podemos mover passa de 15 para 5, porque assim o código feito para a superclasse ainda funcionaria. Corrigindo o exemplo (ainda sem refatoração):

public void mover(int espacosX, int espacosY){

//checando pre condição

if (!(espacosX > 15)) throw new IllegalArgumentException();

if( !((x+espacosX) < 1000))throw new IllegalArgumentException();

if( !((y+espacosY) < 1000))throw new IllegalArgumentException();

int antigoX = x;

int antigoY = y;

x=+espacosX;

y=+espacosy;

//checando pos condições

if(x!=(antigoX+espacoX)){

x=antigoX;

throw new IllegalStateException();

}

if(y!=(antigoY+espacoY)) {

y=antigoY;

throw new IllegalStateException();

}

checarEstado();

}

}

Não tem jeito de aumentar o valor mínimo, então voltamos ao original (e mais código repetido, anda logo com esse refactoring aí!).

Isso também te explica porque você pode, em java, aumentar a visibilidade de um método (tornar um método que era protected public), mas não diminuir (tornar um método public private).

Para pós-condições, é bem parecido:

Uma pós-condição de um método sobrescrito deve ser igual ou mais restritiva que a pós-condição do método original.

Isso quer dizer que se a pós-condição do seu método for que ele retorna um inteiro entre 1 e 100, os métodos que sobrescreverem este podem gerar um número entre 50 e 60, mas não um entre 1 e 500, por exemplo. Se uma classe estava esperando receber deste método entre 1 e 100 e recebe 50, não há problema, mas se ela receber 500, aí sim o polimorfismo deixa de funcionar como deveria (e pode ser que algo simplesmente exploda no seu sistema!).

Contratos Quebrados

Como qualquer contrato, o contrato de uma classe pode ser quebrado. Você já deve ter uma idéia de como reagir quando o cliente não cumpre sua parte, lançando uma exceção, mas lembre-se também que você pode não cumprir o contrato. è aí que entra a pós-condição, se ela não foi obedecida quem não cumpriu o contrato foi você.

Quase sempre é melhor você interromper o processamento com uma exceção do que retornar um valor que não cumpre a pós-condição.

Você poderia ter outro comportamento nesse caso, como retornar uma flag, ou mesmo não fazendo nada, mas exceções são a maneira padronizada de lidar com quebra de contratos. Com a pré-condição documentada, é obrigação do cliente provê-la, a checagem é só para evitar esforço desnecessário e identificar erros mais rapidamente.

Documentando

Um contrato só tem sentido se documentado. Muitas plataformas oferecem facilidades para documentar o contrato das classes, infelizmente Java não tem nada assim pronto.

O que você pode fazer é usar o bom e velho JavaDoc.

Documente a invariante da classe na descrição desta. Você pode usar um pseudocódigo (evite copiar e colar o código, porque assim você expõe sua implementação).

O contrato dos métodos deve estar descrito na documentação destes, use as tags de @param, @throws e @return para indicar o que você espera e o que provê.

Coloque na cabeça que checar contratos é documentação. qualquer um sabe como usar corretamente seu método se você especificar seu contrato na documentação.

Isso é Trabalhoso Demais!

Sim, eu sei. Infelizmente, Java não tem suporte nativo á design by contract, ao contrário de algumas outras linguagens (geralmente linguagens puramente OO). Sim, existe o assert herdado do C, e existem abordagens em AOP e Proxies (uma até sugerida no post mencionado), mas a linguagem por si só não tem esse recurso.

Uma linguagem com suporte à contratos vai te dar um modo fácil de definir e se referenciar a pré e pós-condições, invariantes e guardar valores antigos (o nosso antigoX e antigoY). Vai fazer um or automático com uma pré-condição e a pré-condição do método que você sobrescrever, e um and com a pós-condição. Ainda deveria gerar um documento como um JavaDoc com espaço reservado para a pré e pós-condições (que, afinal, são públicas). Também deve ter um mecanismos eu permita ligar ou desligar as checagens, se quisermos mantê-las só para depuração.

Enquanto não vemos isso em java, nós temos que criar esses conceitos por nós mesmos. Isso geralmente implica num overhead enorme. de uma maneira geral:

Se uma classe possui estados inválidos e estes estados são atingíveis, providencie uma invariante e faça a checagem dela.

Se seus métodos realizam um processamento e retorne um valor, cheque este valor se no meio do caminho você precisou usar métodos não-confiáveis, como métodos de terceiros

Sempre estabeleça e documente um contrato, mesmo que você não faça checagem.

Se uma classe precisa de muitos objetos para não estar fora da invariante e você não quer passar estes objetos no construtor, use uma

Factory

Tente utilizar o máximo possível de boas-práticas estabelecendo checagens, evite código duplicado ao máximo.

Tenha testes unitários que testem todas as possibilidades que você consiga pensar de quebrar o contrato dos métodos.

Fantoches

2005-05-09T11:32:00.000-03:00

Nota: Devido a utilizar um editor de textos, depois colar no blogger, a formatação ficou uma porcaria. O Renato fez uma versão em PDF (valeu, cara :) ).

A modelagem baseada em objetos é vendida como o meio ideal de se desenvolver um sistema nos dias de hoje. Pelas tecnologias e paradigmas que eu conheço, eu acredito nisso também, mas sem hype.

Eu gosto de Análise e projeto Estruturados. Primeiro porque me fizeram pensar em programas como mais que bits e bytes correndo por uma tela monocromática, me fizeram entender sistemas.

Mas Estruturar Não era Legal?
Antes de continuar, deixa-me fazer uma definição que vai servir para o resto desse blog.

O Paradigma Procedural é como eu chamo a programação onde dados e funções estão separadas. Nesse modelo de desenvolvimento de software as entidades são representadas por estruturas de dados simples que são manipuladas por funções independentes.

Eu não gosto do termo Programação Estruturada (apesar de
usá-lo ocasionalmente). Este termo surgiu para separar a arte de destruir a
seqüência lógica de um sistema com instruções GOTO (veja o que Dijkstra diz sobre
isso tudo no seu paper clássico), comum em BASIC, da separação do fluxo
em sub-rotinas, as funções e procedimentos.

Então, programação orientada a objetos é programação estruturada no sentido que separa as funcionalidades em módulos. Chamaremos neste blog de Programação Procedural o modo de definir um programa como descrito acima.

Modelando o Mundo

A primeira coisa que se aprende num curso básico de Análise de Sistemas (seja qual paradigma/metodologia seja usada) é que um sistema de informação modela um mini-mundo. Este mundo é uma versão abstraída do mundo normal, onde os únicos detalhes que importam são os relacionados com a aplicação, com o que o sistema faz.

Num sistema estruturado, geralmente se pensa em como as coisas acontecem, no fluxo de informação. Pensando procedural, um simples cadastro é assim:

Cliente fornece endereço, endereço é armazenado.

Dados fluindo. Acho que todos percebem que a função, o Processo na nomenclatura de Análise Estruturada (aquelas bolhas do Yourdon) vai receber uma estrutura de dados ENDEREÇO e colocar no repositório (que pode ser um SGBD ou um arquivo ou qualquer outra coisa).

Pensando de uma maneira OO, você tem:

Cliente tem um endereço.

Uhm? Sim. No seu mini-mundo OO, você vai mapear o que te importa (o cliente e seu endereço) para um objeto. É claro que dependendo da sua aplicação o Cliente pode ser jogado fora, mas aí vai te restar o objeto Endereço.

Num modelo OO, você está preocupado com o que existe no seu mundo real, como as coisas se relacionam por elas mesmas.

Implementações Procedurais
Vamos pensar um cenário simples. Um estacionamento.

Nosso sisteminha exemplo tem uma só funcionalidade: descobrir se existe vaga disponível para um carro no estacionamento e colocar esse carro na vaga.

Vamos ver o modo procedural de fazer as coisas. Vou usar Java para os dois casos como é minha linguagem atual, mas como muita gente programa 100% procedural em Java, não devemos ter muitos problemas.

class Carro {

private String placa;

private Date dataEntrada;

private int vaga = -1;

public void setPlaca(String p) {

this.placa = p;

}

public String getPlaca() {

return placa;

}

public void setDataEntrada(Date data) {

this.dataEntrada = data;

}

public Date getDataEntrada() {

return dataEntrada;

}

public void setVaga(int vaga) {

this.vaga = vaga;

}

public int getVaga() {

return vaga;

}

class Estacionamento {

public final double VALOR_HORA = 0.5;

private Carro[] vagas = new Carro[5];

public boolean estacionar(Carro c) {

int vagaLivre = vagaLivre();

if (vagaLivre == -1)

return false;

c.setDataEntrada(new Date()); //coloca a data atual do sistema

vagas[vagaLivre] = c;

c.setVaga(vagaLivre);

return true;

}

public double sair(Carro c) {

int vagaOcupada = c.getVaga();

Date dataEntrada = c.getDataEntrada();

double conta = tempoEmHorasAteHoje(dataEntrada) * VALOR_HORA;

c.setVaga(-1);

vagas[vagaOcupada] = null;

c.setDataEntrada(null);

return conta;

}

Aposto que muita gente vai estranhar eu rotular isso de procedural. Aqui nós temos a classe Estacionamento que cuida do processo de estacionar e deixar o estacionamento do Carro, representado por um pseudo-JavaBean (um dia eu explico que é um pseudo-JavaBean para mim).

Mas, o que tem isso de procedural? São classes, não são?

Meu primeiro exercício é para quem tem background em linguagens procedurais. Tente reescrever isso utilizando pascal clássico (não Delphi), FORTRAN ou C (não C++). O código não vai ficar muito diferente, não é? Para quem não programa nessas linguagens, vai mostrar uma implementaçãozinha mixuruca em pseudocodigo baseado em C:

struct t_carro
{
char * placa ; /* uma string */
int vaga ;
time_t data_entrada ; /* um dos tipos de data */
};

typedef struct t_carro carro ; /*para podermos usar a struct */

carro vazio;

carro vagas[5];

int estacionar(carro c){
int vaga_livre = achar_vaga_livre();

if(vaga_livre==-1) return 0; /* em C, 0 = false e 1 = true */

c.data_entrada = data_do_sistema();

vagas[vaga_livre] = c;
c.vaga = vaga_livre;
return 1;
}

double sair(carro c){

int vaga_ocupada = c.vaga;
time_t data_entrada = c.data_entrada;
double conta = tempo_em_horas_ate_hoje(data_entrada) * VALOR_HORA;

c.vaga=-1;
vagas[vaga_ocupada]=vazio;
c.data_entrada=0;
return conta;
}

Mesmo que você não saiba nada de C, dá pra perceber que os códigos são muito parecidos. A maior diferença e fútil, está nas convenções de nomenclatura. Se você colocar os atributos de Carro na primeira implementação como públicos, além de não perder nada (afinal, o que são get e set além de jeitos mais lentos de fazer um atributo público?) o código vai ficar mais parecido.

Claro que a sintaxe das linguagens é muito parecida, e isso ajuda, mas o que parece não é a sintaxe, é o meio como se programa. Esse é um programa altamente procedural.

Note que não existe um só meio procedural de pensar e implementar ou um só meio OO de fazer isso, uns são melhores outros piores, mas estes são apenas dois exemplos.

Bad Smell: Forças Ocultas
O clássico livro Refactoring, de Martin Fowler introduz o conceito de bad smells, literalmente um fedor no código. Você olha, cheira, vê que tem algo errado, e tem que descobrir a causa.

Note que o sistema funciona! Você pode entregar para o seu cliente exatamente desta maneira, mas o que nos queremos aqui não é entregar algo rápido para gerar uma fatura, estamos estudando a melhor maneira de implementar, e como objetos podem ajudar a tornar o desenvolvimento de software mais natural.

Falando em natural, pense no código que criamos, em qualquer uma das implementações. Esse modelo se parece com o mundo real? Vejamos: temos um procedimento que recebe um carro, o joga no estacionamento... como se na entrada do estacionamento houvesse um guindaste que carregasse os carros até suas vagas. É assim que funciona? Não! O motorista ou o manobrista vai pegar o carro e dirigi-lo ate a vaga certa. O carro "sabe" estacionar, e essa é uma responsabilidade dele: dada uma vaga, estacione.

Claro que você pode efetivamente ter seu carro sendo movido desta forma (é só um sistema, não é o mundo real!), mas eu insisto: modele seu sistema o mais próximo que conseguir do mundo real. Qualquer dia falamos sobre Domain Driven Design, mas por enquanto, isso te ajuda a conversar mais facilmente com seus usuários e manter a mesma linguagem que ele, podendo aproveitar os conceitos que ele aplica no dia a dia.

No caso específico, nosso método estacionar(Carro c) está com responsabilidades demais! Ele tem que coordenar o processo de encontrar uma vaga, modificar o carro, modificar a vaga... e olhe que isso é um exemplo simples, que não envolve acesso a recursos como bancos de dados. Vamos tirar o peso dos ombros do pobre método e colocar nosso carro para ser mais que uma struct de luxo...

class Carro {

private String placa;

private Vaga vaga;

public void estacionar(Vaga v) {

this.vaga = v;

v.ocupar(this);

}

public void sair() {

vaga.setOcupante(null);

this.vaga = null;

}

public Vaga getVaga() {

return vaga;

}

class Vaga {

private Date dataEntrada;

private Carro ocupante;

public void ocupar(Carro c) {

this.ocupante = c;

this.dataEntrada = new Date();

}

public double getValor() {

return (tempoEmHorasAteHoje(dataEntrada) * Estacionamento.VALOR_HORA);

}

public long tempoEmHorasAteHoje(Date desde) {

return 1;

}

public void setOcupante(Carro c) {

this.ocupante = c;

}

class Estacionamento {

public static final double VALOR_HORA = 0.5;

private Vaga[] vagas = new Vaga[5];

public boolean estacionar(Carro c) {

Vaga vagaLivre = vagaLivre();

if (vagaLivre == null)

return false;

c.estacionar(vagaLivre);

return true;

}

public double sair(Carro c) {

Vaga vagaOcupada = c.getVaga();

c.sair();

return vagaOcupada.getValor();

}

Perceba que nesse modelo nós explicitamos um conceito. O cliente no caso quer saber o preço do uso da vaga, não do carro, e para melhor modelar isso nós criamos um objetinho com este conceito.

Observe os programas. Perceba como as responsabilidades foram divididas entre os objetos participantes, como não existe mais um método (ou um conjunto de métodos) que manipula os dados, geralmente cada objeto cuida de si próprio. Essa é a idéia.

De uma maneira geral: é um bad smell se seus objetos são guiados através de forças ocultas, se seus objetos se comportam como marionetes sendo manipuladas por uma função-mestre, o mestre dos fantoches.

Isso é sintoma de um design altamente procedural, onde a lógica de negócio está implementada em funções e em como estas manipulam estruturas de dados. Você geralmente acaba com uma serie de classes (geralmente implementando o padrão Command, mas por vezes são Façades) coordenadoras e um bando de objetos burros que nada mais são que um agrupamento de dados relacionados.

Neste cenário e comum que simplesmente não se consiga reaproveitar lógica. E o tipo de sistema onde reusabilidade e mantida com copiar-e-colar, já que seus métodos são “gordos” demais e são tão especializados que simplesmente não servem para nada alem do que foram concebidos inicialmente. Outro sintoma deste tipo de design são métodos com muitas linhas de código.

Sugestão: divida a responsabilidade do seu método faz-tudo por objetos que dividam a responsabilidade. Modele melhor seu sistema tentando utilizar conceitos e abstrações do mundo real.

Anatomia de um Sistema OO

Um sistema baseado em objetos e formado por componentes (os próprios objetos) que colaboram entre si. Isso não e tão diferente de um sistema procedural, onde as funções e procedimentos devem trabalhar juntos para um baixo acoplamento e alta coesão.

Uma maneira pratica de avaliar seu modelo OO contra fantoches e mestres e o diagrama de seqüência. Observe o diagrama de seqüência de nossa primeira implementação:

O diagrama de interação e exatamente para mostrar como os objetos interagem no sistema. Veja que a interação neste caso e sempre iniciada pelo nosso mestre dos fantoches. Vamos examinar o diagrama de nossa implementação com responsabilidades distribuídas:

Perceberam a diferença? Os objetos agora colaboram entre si, não existe uma única unidade de controle. Se você precisar estender a funcionalidade do seu sistema, agora pode reutilizar os procedimentos que foram separados do método inicial, o método estacionar() agora e apenas um estimulador dos outros objetos.

Entre Flexibilidade e Produtividade

Como sempre, o programador deve lutar entre ser flexível ou ser produtivo. Na verdade, essa e uma luta desnecessária, quando você produz software de qualidade você acaba sendo produtivo em longo prazo.

A grande dificuldade e como saber quando sua arquitetura esta flexível e quando esta flexível demais. Você pidões perder dias esculpindo um framework em cima da sua aplicação, onde qualquer mudança será muito simples, mas você precisa pensar que pode ser que uma mudança brusca nunca seja necessária, e não há na maioria das vezes como saber as necessidades futuras.

Um bom modelo de objetos vai permitir que você consiga separar bem as cosias. Objetos mapeando significados do domínio, como o exemplo da Vaga, te dão flexibilidade próxima da flexibilidade que seu cliente tem, então se ele resolver mudar seus conceitos você pode seguir a mesma linha de raciocínio ao mudar os seus.

Refatorar seu código constantemente ajudar a manter algo simples e flexível. Siga esta pratica.

Conclusão

Todo mundo aprende a construir algoritmos, e algoritmos são dados fluindo entre funções. A migração de paradigma e complexa, e a literatura especializada em Java e (principalmente) J2EE não ajudam.

Existe um motivo para a criação do paradigma de orientação a Objetos. Este paradigma prove abstrações melhores e mais naturais, mais próximas do mundo. Antes de definir seu sistema, pense em como as coisas interagem no mundo, pense que objetos não são dados+funções, eles são entidades por si só, e devem colaborar. Não crie “donos da razão” no seu sistema, produza classes coesas e colaborativas.

Update: Mudei a cor dos códigos. Eu escrevi num editor de textos normal e a formatação aqui ficou uma bagunça, vou tentar definir uns CSS para o blog.

Viciado

2005-05-06T16:13:00.000-03:00

Hoje está um dia extremamente confuso, minha cabeça gira e blablabla, mas isso não é um blog para falar sobre meus sentimentos fúteis, o que importa (importa?) é meu hábito quando fico confuso, triste ou deprimido.

Eu ando até uma livraria na Av. Sete de Setembro, onde aparecem alguns livros importados bons, e gasto meu rico dinheirinho. O escolhido dessa vez foi esse:

Apesar dos livros aqui serem tão caros, é sempre confortante (não me pergunte porque). Eu entro lá, dou uma olhada em uns livrinhos e acho um que levo pra casa. Considerando que tem uns 5 livros na minha fila de leitura, é loucura, mas vai entender, vício é vício...

Extreme Freelancer : Guia de Guerra para Freelancers

2005-05-06T12:00:00.000-03:00

Esses dias tenho conversado via ICQ com um amigo sobre as desventuras dele enquanto freelancer. Tentei dar dicas que aprendi quando me embranhava por essas terras distantes...

Histórico
Eu programo desde muito novo. Não vou me alongar aqui, mas por alguns anos fui ganhando uma graninha dando consultoria básica em ASP, VisualBasic (argh!) e C em listas de discussão, coisa pouca que mal dava para eu comprar um livro de programação traduzido de 50 reais. Não demorou muito e passei a fazer programinhas como freelancer, como todo mundo do meio.

Cheguei a trabalhar "oficialmente" como freelancer por algum tempo, ganhando um salário razoável pela minha experiência formal, em casa, indo duas ou três vezes por semana ter reuniões no escritório do cliente. Esse projeto acabou afundando no meio do curso, e vou tentar explicar o porque e tentar aplicar o que eu já aprendi até hoje nestes problemas.

Organização do Ambiente
Você quer trabalhar de freelancer? Se organize. Não me importa se você é um moleque de quatorze anos que mal sabe fazer um loop (e devia estar estudando, não brincando de trabalhar!) ou um profissional tarimbado e conhecido que faz uns servicinhos de consultoria especializada: você precisa se organizar!

Para começar, onde você trabalha? Poucos freelas têm a disposição um escritório, a maioria trabalha mesmo é no quarto, de madrugada. Se você trabalha nas suas horas de folga, estipule o tempo de trabalho, seja disciplinado com seus horários. Defina as horas por dia que você irá trabalhar normalmente (ocasionalmente você vai ter que fazer "hora-extra", claro), essas horas vão ser úteis também quando você calcular o preço dos seus serviços e suas entregas.

O ambiente de trabalho deve ser organizado. Não é sua casa, é seu trabalho! Claro que você tem muito mais liberdade que num escritório formal, mas não deixe essa informalidade te distrair. A melhor coisa a fazer é providenciar uma porta com tranca para o lugar onde seu computador fica (se você não morar sozinho, claro). Este lugar deve ser silencioso, se você (como eu) mora num lugar onde parece que os carros passam dentro do quarto, arrume uns fones de ouvido e coloque uma música para ouvir (se você não gosta de trabalhar com música é complicado, mas neste caso tente música instrumental - clássica é legal -, geralmente funciona e não te distrai).

Desligue ou coloque em estado Away ou N/A todos os seus Instant Messengers. Se você possui um sócio ou outra pessoa que pode precisar falar com você imediatamente, configure isso (IMs de verdade como o ICQ te deixam fazer isso fácil fácil...), mas desative qualquer alerta que possa te incomodar. Preferencialmente, não use seu e-mail pessoal para assuntos relacionados ao trabalho extra, crie um e-mail próprio e deixe seu e-mail pessoal (cliente de e-mail ou Gmail notifier da vida) desativado. Geralmente o freelancer tem pouquíssimo tempo para trabalhar, este tempo deve ser aproveitado o máximo possível. Bloglines (ou outro agregador RSS/derivados) e fóruns então, nem pensar!

Metodologia de Trabalho
Em empresas (ou em qualquer lugar com mais de uma pessoa trabalhando, às vezes mesmo om uma pessoa só...), você geralmente vai ser obrigado a usar uma metodologia X, com processos definidos por outra pessoa. Muitas empresas pequenas definem apenas um conjunto de procedimentos padrão, mas mesmo assim a liberdade não costuma ser muito alta, mesmo poruqe você está numa equipe.

O fato é que se você está sozinho, não existe ninguém nem para te impôr nada nem para te ajudar a decidir o que fazer e quando. Você vai ter que se virar para desenvolver um conjunto de processos e práticas e aplicá-las.

Quando você não é freelancer profissional, quando geralmente só pega um servicinho aqui e outro ali, você costuma tratar cada projeto de modo diferente. Mesmo nesse caso, um mínimo de organização é esperado. Mesmo que você não tenha uma metodologia de trabalho definida, você deve parecer que tem uma se quiser manter clientes sérios e que acreditem no seu trabalho.

Use sempre boas ferramentas. Sim, eu sei que isso serve para qualquer tipo de trabalho, mas para o freelancer é fundamental você:

Ser Rápido
Ser Produtivo
Ter Qualidade

Ser rápido porque o cliente está em contato direto (veja abaixo) e ele vai te pedir muitas coisas. Se você for rápido o suficiente pode criar protótipos que acabam te dando mais confiança que o sistema atende ao usuário, e pode ainda criar protótipos que resutlem no fechamento de novos negócios, novas funcionalidades... sempre é bom mostrar algo para o cliente em vez de ficar só conversando eternamente sobre o que poderia ser feito.

Ser produtivo é crucial para quem trabalha no tempo vago. Você não pode gastar muito tempo para desenvolver um módulo, você tem poucas horas por dia e elas devem ser bem aproveitadas, com o que interessa. Minha dica aqui é o contrário do normal: fuja de ferramentas RAD de ponta a ponta, use apenas RAD para partes repetitivas do seu sistema, como layout de telas, relatórios e bases de dados. O que você precisa fazer para ser produtivo é ter conhecimento do seu código como um todo e manter ele sempre limpinho, refatorando sempre. Assim, você consegue mudanças rápidas, ao invés de ter que contar com wizards bizarros e GUIs que não te dão controle nenhum.

Qualidade é fundamental para o freelancer, afinal quem vai manter esse código é você! O cliente não quer saber quantos arquivos você vai alterar, ele quer que você implemente a funcionalidade rápido, e num projeto desses funcionalidades mudam a todo instante. Faça tudo pensando que você vai ter que corrigir bugs o tempo todo nesse código, às 3 da manhã, tendo que ir trabalhar em seu emprego formal no outro dia!

Use ferramentas normais de uma empresa, um controle de versões é fundamental mesmo quando se trabalha sozinho. Bugtracking também ajuda, mas sem exageiros (todos os bugs e tarefas vão estar assinalados para você no final).

Seja Compromissado
Meio desnecessário dizer, mas não é porque esse não é seu trabalho formal que você pode fazer um seviço qualquer. Um freelancer deve atender seu cliente exatamente como uma empresa normal, a informalidade da coisa tem que ser uma vantagem para ser mais ágil, não uma desculpa esfarrapada para atender mal.

Qualquer freelancer de verdade sabe que seu nome e reputação valem mais do que ele mesmo pode pagar. Combine coisas verbalmente, mas formalize pelo menos com um e-mail para não ficar no disse-me-disse e discutindo com o cliente coisas que possivelmente tenham sido ditas. Tenha certeza que vocês estão falando a mesma língua.

Se for atrasar, avise. Combine uma reunião periódica frequente para controle do cronograma, pode ser um telefonema, mas tenha um ponto de referência. Se você não pode fazer reuniões com o cliente no horário do expediente, deixe isso claro já no início do projeto e proponha uma alternativa, reuniões por telefone, logo após o expediente ou nos sábados, por exemplo.

Conheça seu Cliente
Como um profissional autônomo, você dificilmente vai pegar grandes projetos (quebrei suas ilusões?). Geralmente quem solicita serviços de freelancers são empresas de micro e pequeno porte que precisam de algo altamente customizado e não têm dinheiro para contratar uma das bigs (mas, na verdade, era isso que eles queriam fazer). Assim, você tem a grande oportunidade de conhecer todo funcionários da empresa cliente (sim, todos os 3 funcionários) , do dono do negócio à menina do caixa. Use isso.

Conhecer o dono do negócio é ótimo, você fica sabendo das espectativas, das necessidades e do que ele pretende fazer (é claro, tudo muito exagerado...), mas não se esqueça dos usuários (sim, todos os dois).

Certa vez trabalhei na migração de uma rede de nove computadores de Windows 98 para GNU/Linux. Tudo meticulosamente planejado, eu contratei um técnico especializado neste tipo de serviço, mas como todo bom moleque de dezenove anos (não que eu seja muito menos moleque aos 22), eu esqueci que quem ia usar o sistema não era a pessoa que eu lidava, dono do negócio.

E lá fui eu para a primeira sessão de treinamento em OpenOffice.org, achando que estava tudo perfeito. Já tinha convertido todos os formulários-padrão para o novo sistema, instalado uma versão customizada e amigável de KDE...quando um dos funcionários me pergutna sobre os 30 e poucos macros que ele fizera no Excel para acelerar um processo interno qualquer. O diretor falou que esqueceu de me avisar, e ninguém além daquele carinha tida consciência que aqueles macros eram super importantes, só ele os utilizava! E lá vai o Phillip converter macros VBA para OO.org... mas eu não entendia as macros, elas eram relativas ao negócio, isso seria praticamente desenvovler um sistema (o que nãoe stava no contrato).

Ficou acertado que o funcionário usaria Excel num Windows XP até que conseguíssemos solucionar este problema...que não era o único. As pessoas da empresa trataram a migração como uma coisa imposta e não-desejada (Afinal, para eles era apenas a empresa economizando em licenças). Considerando que a empresa ficava muito longe da minha casa, acho que se ônibus tivesse programa de milhagem eu poderia viajar paraa Europa de graça de tantas vezes que tive que ir resolver problemas. E não, não eram problemas grandes, eram coisas do tipo:

- Isso aqui (Mozilla) não funciona!
- Não? o que aconteceu?
- Eu tento entrar no site www.abcd.com.br e dá erro na conexão
- Uhm...peraí..esse aqui não é o cabo de rede da sua máquina?
- Não sei, é?
- Você arrancou?
- Ah, acho que esbarrei aí sim... mas deixa disso, esse tal Linux não funciona!
- Por acaso o Windows tinha Internet sem cabo de rede?!?

Evite boicote: aproveite o fato de você ter apenas meia dúzia de usuários e converse com todos eles, tente agradar a todos (mesmo sabendo que quem te paga é o dono do negócio apenas). Isso vai te economizar muita dor de cabeça.

Seja Ágil
Metodologias ágeis são complicadas de aplicar em empresas grandes, mas quando sua empresa é você apenas elas podem ajudar e muito.

Estude um pouco de XP. Você não precisa aplicar todas as práticas (algumas nem vai conseguir, como pair programming), mas se aproveite da situação para aplicar o máximo destes conceitos de agilidade e foco no cliente. Não vou explicar para você os conceitos aqui, procure um livro ou algo do tipo, mas algumas idéias básicas de como isso pode te ajudar seguem.

Pegue os requisitos diretamente com seu cliente. Não importa muito a técnica, mas eu sugiro que você dê uma olahda em User Stories. O importante é que você defina os requisitos com a maior participação do cliente possível.

Como freelancer, você tem que estar pronto para mudanças. O cliente vai mudar tudo toda hora, e como não tem muita burocracia, você tem que se preparar para isso (tirar proveito disso, até). Faça um Plano de Releases pequenos, vá acrescentando funcionalidades ao sistema de pouco em pouco, a cada release. Conforme vai vendo o sistema, o cliente vai mudando (calma, não ache que vai trabalhar de graça, leia abaixo sobre contratos, isso pode ser é muito bom financeiramente) e você vai repriorizando suas entregas.

Tenha seu cliente sempre à mão, celular dele colado com post-it no monitor.

Tenha um Advogado
Isso é sério. Você não precisa ter um advogado contratado, mas tenha pelo menos uma boa indicação de um. Se for amigo ou parente seu melhor, o explore e use para revisar e redigir contratos (pagando apenas uns chopps).

O Luca, amigo de GUJ, me falou uma coisa sobre profilers que se aplica a advogados também:

Você nunca aprende a usar um profiler antes de precisar usar um profiler, mas geralmente quando você for precisar, não vai ter tempo para aprender nada, tem é que consertar os problemas rápido!

Então já tenha pelo menos o telefone de alguém que vai poder te ajudar se as coisas derem muito erradas.

Contratos Abertos
Isso parece meio louco, mas funciona muito bem, principalmente nesse caso.

Para cada módulo de seu sistema, defina um valor em horas (ou defina pontos, é mais XP). Defina um valor por ponto e se comprometa a entregar X pontos por mês, cobrando o equivalente.

Quando você entrega um módulo, o cliente pode querer alterar algo (ele vai querer!), avalie a alteração em pontos, repriorize suas entregas pro próximo mês (ou semana, ou duas semanas...).

Então, crie seu contrato de maneira que o escopo seja aberto. O cliente estaria pagando R$Y por X pontos por mês. Não se iluda em terminar o projeto, um projeto de software só acaba quando o programa é deletado dos computadores definitivamente e sai de uso.

Conclusão e História Triste
Bom, se eu tivesse seguido algumas dessa dicas eu não teria passado por uma situação muito infeliz há alguns anos.

Eu trabalhava então full-time para uma empresa desenvolvendo um sistema de laudos. A idéia era simpels: cinco módulos, pagamento por mês.

Os módulos eram:

Gerência de Estoque
Gerência de Laudos
Gerência de usuários
Agenda Coorporativa
Geração de um Laudo Especial

Baseado na dificuldade que eu via nas coisas, eu defini a entrega na ordem:

Gerência de usuários
Gerência de Estoque
Agenda Coorporativa
Geração de um Laudo Especial
Gerência de Laudos

O gerenciador de laudos tinha umas customizações muito complicadas...

Começaram as complicações no desenvolver do projeto, no início eu tinha muito tempo para isso, mas depois arrumei um emprego formal, isso acabou com meu tempo (some, é claro, a faculdade). Simplesmente não conseguia arrumar tempo para trabalhar, quando chegava em casa, as 23 horas, dormia. Fins de Semana eu tentava, mas sempre tinha alguém para me encher o saco (ou arrumar um lugar pra sair e não trabalhar...).

Em paralelo, começou uma dificuldade tecnológica. A idéia inicial era desenvovler em Delphi (ugh!), mas o ambiente passou para GNU/Linux e eu tentei o Kylix. Depois de muito tempo xingando o bichinho (injustamente), passei para Java, e tive que me virar para aprender a programar com um JBuilder 5.

O usuário passou a me ligar diariamente cobrando a entrega. Eu propus mostrar uma apresentação sobre o sistema e fiz um bando de telas em um editor GTK WYSIWYG, colei num powerpoint. Foi bom em parte para solucionar algumas duvidas com a interface, mas o cliente reclamou, ele queria ver algo funcionando, mesmo que um protótipo.

Bem, enfim primeira iteração: entreguei o gerenciador de usuários. Enquanto o usuário descobria bugs no sistema, eu tentava preparar o outro módulo. Enquanto isso ele me pedia para ver como estavam os módulos, eu desconversava.

Quando entreguei os 3 primeiros módulos, atrasados claro, o cliente começou a reclamar que estava gastando rios de dinheiro e não via retorno.

- É...a gente paga, paga..e nada... temos que ver isso, heim..
- Como assim? Eu já entreguei três módulos!
- Que não fazem nada de útil pra minha empresa. Na verdade, eu tinha pedido esses módulos como complemento, se eles não funcionarem eu não vou ligar muito.
- Hum...é verdade, mas pelo manos temos alguma coisa...
- Que não me serve para nada.

Pois é. Eu fiz minha agenda de entregas baseado no que era bom para mim, não pro cliente.

No final das contas, o módulo de laudos atrasou mais três meses. Eu já não tinha tempo nem de respirar, tinha que faltar ao trabalho constantemente para tentar trabalhar em casa, mas mesmo assim não adiantava. Ocasionalmente meu computador tinha algum problema e eu perdia um ou dois dias de trabalho.

O final da triste história foi a contratação de uma empresa externa para fazer auditoria. Os caras viram que muita cosia havia sido entregue, e como eles foram tão técnicos quanto eu, acharam normais os atrasos. Acabou com o cliente cancelando o cotnrato e ficando com três módulos que não faziam nada de útil, além do prejuízo de um ano de desenvolvimento mais um mês de auditoria que não deram em nada.

Imaturidade minha, falta de preparação. A minha sorte é que eu tinha meu emprego formal, porque meu moral ficou muito baixo, sem falar no meu bolso vazio. Depois deste, eu já peguei diversos outros projetos como freelancer e acabei descobrindo práticas melhores para resolver o problema ue eu tinha. Elas funcionam comigo, acredito que outras pessoas possam se beneficiar também.

Hoje em dia dificilmente pego um freela, falta de tempo e de paciência não deixam, mas da minha experiência não tão grande, não tão pequena, tirei essas dicas que espero que ajudem.

Update:
Renato Santos da Silva, o meu amigo citado no início do post, está escrevendo (trabalho em andamento!) uma versão compilada e com acréscimos dele aqui. Ele também deu o nome de Extreme Freelancer :)

Sun Certified Java Compiler

2005-05-03T11:49:00.000-03:00

Ontem, o Vinci apresentou uma palestra no RioJUG sobre certificação JCP. A palestra estava cheia, assim como estão sempre os fórums dedicados ao assunto.

Que certificação não prova nada, todo mundo sabe, então não vou chover no molhado. Se você gastar cinco minutos lendo os posts em um fórum ou uma lista de discussão, vai perceber que nem mesmo conhecimento da sintaxe de uma linguagem ela prova. Já contei essa história, mas vamos novamente...

Há exatamente um ano atrás eu quis mudar de emprego. Espalhei uns curriculuns e fui a algumas entrevistas. Uma agência de RH especializada em informática aqui no Rio me aplicou mocks de SCJP duas vezes.

Como eu não sou exatamente um newbie em Java e as provas da Sun são muito bestas (compila ou não compila, por que?), me saí relativamente bem nelas. Quando ia para a segunda etapa da seleção, vinha a pergunta da entrevistadora:

- Então, você tem certificação de programador Java?
- Você leu isso no meu curriculum?!?
- Não, mas pelo resultado da prova...
- Não, não tenho não.

E lá ia a proposta de trabalho pela janela. Fiquei tão estressado com isso que liguei para a Sun e pedi meu voucher. Por uma coincidência (se você acredita nisso) a menina da Sun errou meu e-mail e o boleto nunca chegou, nesse meio tempo recebi uma proposta bem melhor de trabalho.

Conclusões que tirei:

Se você precisa de trabalho, tire uma certificação. Não prova nada, não custa tanto assim, é fácil e você fica bem nivelado no mercado.

A única utilidade da certificação é arrumar emprego mais facilmente. Sinceramente eu não vejo diferença entre mostrar um certificado ou escrever um programa simples em Java, mas ninguém tem tempo para aplicar provas concretas num processo seletivo, você não tem tempo de escrever um programa para a seleção e a empresa não tem tempo para ler sei lá quantos programas escritos pelos seus candidatos.

Falando do lado do empregador, eu ainda acredito no papo durante a entrevista. Diz um colega meu que para você se dar bem em qualquer entrevista basta ler a introdução e primeiro capítulo de todos os livros da moda. Ali está todo o resumo do livro, e você pode impressionar seu entrevistador. Cabe ao carinha fazendo perguntas descobrir se o que a pessoa diz que sabe é verdade, e um bom técnico sabe como fazer isso.

Falsos positivos são ótimos, você fala uma coisa irreal pra pessoa e pergutna a opnião dela, o bom enrolador vai te fazer acreditar que aquilo é verdade. Contrate esse cara... como vendedor, não como técnico. Um bom técnico tem que saber um mínimo teórico sobre a tecnologia que utiliza. Saber pelo menos os conceitos de tecnologias novas (bola da vez: AOP, IoC, Java 5 e linguagens de script).

Se você exige proficiência em uma ferramenta específica, faça um teste hands on, mas não deixe de averiguar se a pessoa em questão sabe o que está por trás da ferramenta.

Como tudo que escreve, Joel Spolsky tem um bom texto sobre esse assunto de entrevista.

Sinceramente...

2005-05-03T11:27:00.000-03:00

Esse blogger tá me dando saudades do JRoller...

Nova casa

2005-05-03T11:04:00.000-03:00

Após algum tempo sem escrever nada, voltei :)

O Jablo já era (tenho que recuperar a os meus posts antigos...), era um projeto muito bom, mas faltou infra-estrutura. Há algum tempo eu registrei o domínio fragmental.com.br, e com o fim do meu blog resolvi utilizar este espaço.

Procurei uma ferramenta de bliki, porém problemas com meu host (suporte terrível!) e burrice minha me fizeramd esistir das alternativas que encontrei. Decidi iniciar um projeto de um bliki simples, algumas pessoas se interessaram mas o projeto (como tantos) acabou morrendo.

Bem, ressuscitei a idéia há pouco. Escrevi algum código e requisitei um projeto no java.net. Como tive problemas com meu computador de casa e meu firewall coorporativo bloqueia CVS, devo estar comitando algum código hoje, a idéia é ser bem incremental e beeem lento, porque eu não tenho muito tempo. Se você se itneressar pelo projeto, por favor fique a vontade para pedir um papel.

Equanto isso, minha blogorréia me fez criar um blog aqui no Blogger e redirecionar meu domínio para cá. Enquanto o JRapido não fica usável, vcoês três ou quatro vão poder ler minhas ideías tortas e hippies aqui.