Archive for October, 2005

Monday, October 31st, 2005

Ruby e Rails no news.com e no onJava (by bruce tate)

Artigos normais, nada de especial, mas este comentário do Kevin Hooke é bem interessante:

If this framework does not make it big in the next year or so then it will be interesting to look back to see what else changed as a direct result of the impact that RoR is making, because this technology is sure beginning to pick up some momentum.

Bem nessa…

Monday, October 31st, 2005

E o Cameron agora mete pau no BigDecimal.

Sunday, October 30th, 2005

Ingresso no bolso pro show do Rio, ingresso no bolso pro show de sábado em Sampa, tentando comprar ingresso pra sexta….

Sunday, October 30th, 2005

Cameron Purdy está escrevendo uma série imperdível sobre seus problemas preferidos na API do java. Já começou bem, com java.util.Date e seus amiguinhos.

Aliás, já ouviu a entrevista do Purdy no JavaPosse?

Resumindo

Thursday, October 27th, 2005

Static types give me the same feeling of safety as the announcement that my seat cushion can be used as a floatation device.

Don Roberts

OOPSLA 2005, via Fowler.

Diulgando o JavaPosse

Thursday, October 27th, 2005

Mesmo antes de eu ter um iPod (thanks pessoa que me trouxe um, não vou falar teu nome pra não te confundirem com sacoleiro, sabe como é, natal chegando…) eu quis saber que diabos era isso de podcasting. A impressão que eu tinha é que só dava para ouvir num iPod, porém eu estava errado.

Alguns players (ok, eu só conheço o iTunes, que também não precisa de iPod) têm suporte melhor aos podcasts, mas nada impede que você subscreva um via um agregador RSS (como o Bloglines) e baixe os arquivos MP3 para ouvir no computador, no DVD, no carro..sei lá.

Minha lista de podcasts segue abaixo, ams quero falar de um em especial, o JavaPosse. O JavaPosse é o que virou o JavaCast, antigo podcast sobre Java muito bom. Hoje em dia é comandado por Dick Wall, Tor Norbye (desenvolvedor da Sun/Netbeans) e Carl Quinn (Google). É um programa bem legal, essa semana eles entrevistaram Joshua Bloch, muitas outras personalidades já passaram por este programa.

A IBM acaba de lançar alguns podcasts do DeveloperWorks, ainda não ouvi.

Geralment eeu baixo os arquivos no iTunes do tabalho e começo a ouvir (trabalhar e ouvir rádio exige uma boa implementação cerebral de threads). Se não acabei quando acaba o dia, passo pro iPod (roubando o cabo USB do Eliziário, que mora no escritório) e ouço o resto no metrô.

Veja essa maravilha de cenário…

Thursday, October 27th, 2005

Só quem é fão sabe o que é passar indo pra faculdade todos os dias onde vai haver o show com a música da banda tocando no iPod. Vocês estavam com saudades dos meus comentários sobre Pearl Jam, pode falar a verdade…

Meu ingresso para São Paulo deve ser comprado essa semana, o meu pro Rio vai ser comprado amanhã (maldita carteira de estudante que eu esqueci em casa!)

Apoteose

Por mais que eu curta samba, a Apoteose nunca foi tão alucinante…

DVD

DPP, a Nova Métrica

Wednesday, October 26th, 2005

Você já viu Use Case Points, você já viu Function Points, agora não perca a mais nova opção: Design Pattern Points, mais uma nova métrica que não diz nada para seu sistema.

Essa onda de Design Patterns é engraçada. Essa discussão é prova de como as pessoas simplesmente não entendem as coisas. Quantos Design Patterns têm seu sistema? Vixe, só isso?

Pra você que é novo nesse mundinho Java (calma Eliziário), Design Patterns são receitas de bolo para resolver problemas. Os primeiros Patterns (ou Padrões) a serem catalogados foram aidna quando C++ era a única linguagem OO que era usada de verdade e Java era utilizado para fazer applets (por incrível que apreça, a Microsoft tinha até uma JVM). Então Patterns são receitas de bolo, Design Patterns são receitas de bolo para projeto de software, temos Padrões Arquiteturais, de Gerência, de Projeto (Project, não Design), etc. Padrões vão sobreviver a Java e não são nem novos nem exclusivos da plataforma.

Outro dia falamos aqui sobre como Padrões ajudam a falar um idioma comum. Você não imagina de quantos busy waits o mundo foi salvo por alguém ouvir falar em Observer. Patterns servem para isso: um catálogo de soluções que você pode usar e um vocabulário comum. Mas agora as pessoas se agarram aos tais padrões como se isso fosse gerantir a qualidade do projeto.

Vamos lá, o raciocínio é óbvio. Padrões são bons, logo muitos Padrões == muito bom. E nasce mais um sistema entupido de Observers que puxam uma Chain of Responsability passando três DTOs que são persistidos pelos DAOs numa sequência de Actions decoradas criadas por Factory Methods. Isso tudo para aquela funcionalidade de “Fale Conosco” do site. É, aquela que tem um formulário de três campos e manda um e-mail para webmaster@seila.com.br . Vamos e vanhamos: é mais fácil usar do que entender. Questionar dá muito trabalho, usa e cala a boca.

Um exemplo clássico é o DTO. Você usa DTOs no seu sistema? VOs? TOs? Por que?

No sistema em que tenho trabalhado recentemente existe real encessidade de DTOs. Foi a única vez que vi isso e semrpe trabalhei com sistemas com um grau de distribuição alto. Este é especial, os clientes estão em outras máquinas e precisam de um bando de objetos do servidor.

Mas a grande enomre gigante maioria das pessoas usa DTOs nos seus ssitemas sem a menor utilidade. Pra que? Para ganhar mais pontos nesta métrica. Para seguir blueprints Java EE.

Claro que isso acarreta num aumento enorme de complexidade, já que você tem que mantêr duas hierarquias de objetos diferentes. Claro que issod eixa o sistema mais lento com tanta cópia de valor/referência inútil. Mas e daí? Ano que vem me certifico em Design Pattern Points.

Gerente à la Joel

Wednesday, October 26th, 2005

Joel Spolsky está contratando gerentes trainee. E porque ele não promove seus programadores?

Now, there’s nothing wrong with promoting a programmer to management, but management is a different job and a requires different skills from programming. Many people who are excellent developers are lousy managers, and promoting someone out of a job that they love doing and are good at doing into a job that they hate and are not good at doesn’t make sense. We plan to make sure that programmers have explicit career paths that do not require them to shift into management just to get the next raise in salary level or benefits.

Touché. Muitos programadores dão excelentes gerentes, com grande conhecimento de causa, mas a grande maioria se torna gerentes de medíocres à insuportáveis.

O mais terrível é a sensação de que ser técnico (programador, engenheiro, etc.) é para quem está em início de carreira. A coisa é mais ou menos assim: com seus vinte e pouquinhos você é programador. Roda, roda, roda até achar um domínio (telecom, finanças, hospitalar, vendas, conteúdo…) onde vira especialista. Neste ponto você “evolui” e vira o tão famoso Analista. Depois você vira Gerente, Diretor…no final a coisa é próxima a Zeus.

Isso é “vendido” todos os dias na grande maioria das faculdades de Sistemas de Informação que eu conheço e em muitas e muitas empresas. Programador não é nada. Técnico não é nada.

Claro que eu sou apenas um programadorzinho (como diz meu professor de Planejamento em Informática) que acha que a vida acaba atrás do teclado. Claro que eu conheço muitas pessoas que insistiram em ser técnicos e perderam muitas chances de subir na vida, mas ei! A coisa não é tão simples quanto parece…

Para ser gerente a pessoa tem que conhecer um mínimo sobre gerência. Por que as pessoas de informática são tão pretensiosas? Se eu te digo que vou colocar meu irmão, advogado, para programar no próximo projeto, você acha um absurdo. Isso não é coisa para amadores. E gerenciar uma equipe é?

Cada macaco no seu galho. Assim como eu conheço um bacharel em História programador de profissão, eu sei de programadores que são ótimos gerentes, como já disse. Acontece que ou essas pessoas já tinham um talento nato para a coisa, ou estudaram muito, ou (melhor) ambos.

A tecnologia é muito descartável, não importa muito se a pessoa que sabia X vai embora para o setor de “Analistas”, já que amanhã X vai ser substituído pelo framework Y. Isso é a visão de quem não conhece Computação.

Mais que frameworks, ferramentas, linguagens e tudo mais, Computação é baseada em conceitos que não mudam da noite para o dia. A maioria destes conceitos formam paradigmas, que são implementados por uma ou outra tecnologia. Tínhamos Smalltalk, bela implementação de Orientação a Objetos, o conceito. Passamos a C++, implementação pior, porém mais útil. Passamos a Java, melhor implementação do conceito, foco mais bem definido. Agora temos linguagens leves de aplicação (como Ruby, Groovy ou Python), melhor implementação do conceito, foco restrito. Em breve termos DSLs a torto e a direito, implementação razoável do conceito, e foco muito restrito. Você acha que o conceito mudou na troca de implementação?

Não menospreze a Ciência da Computação. Entender como as coisas funcionam leva muito tempo e exige muito esforço. O Negócio é o que importa ao cliente, mas além dos especialistas do negócio, sempre haverão os especialistas em conceitos de tecnologia. Um precisa do outro, mas só o primeiro é valorizado.

Como o Joel diz, técnicos precisam de uma hierarquia própria. Se seu programador resolveu que gosta mais do domínio do que de tecnologia, ofereça a possibilidade dele se tornar um especialista no negócio, mas não obrigue seus técnicos a jogar tudo que aprenderam pela Janela para “evoluir” para “Analista”.

Uma Foto diz mais que mil palavras…

Wednesday, October 26th, 2005

Ok, só mais lenha na fogueira…

Difference

Via flickr.

Update: Vendo o blog do autor da foto dá pra entender melhor. Ele apenas empilhou os livros que tinha, porém a foto causa um bom (e vamos e venhamos, não tão injusto) impacto.