sexta-feira, 27 de julho de 2007

Analogias de Desenvolvimento de Software

Achei uns artigos muitos bons navegando por ai.
Um dos que me "chocou", chamou mais a atenção, espantou... sei lá, um dos que gostei foi este artigo.

Ele me levou a lembrar que lá atrás na faculdade, quando nos era ensinado Análise de sistemas num esquema puramente WaterFall, utilizando abordagens Bottom-Up e Top-Down, nos era dito também, que para construir software deveríamos fazer como o pessoal de Construção Civíl, o qual fazia todo o projeto de um prédio, e depois começava a construir. Se eles conseguem/podem fazer isso por que um simples software não pode ser feito assim?!

No Artigo do primeiro link, ele começa contando uma historinha, contando quando foi para uma construção, ou para uma aula de engenharia civíl, não entendi direito, mas vou traduzir aqui:

"O que você está fazendo aqui?" - Eles perguntaram

Eles eram Encarregados, Gerentes de Projeto, Superintendentes, e estavam fazendo um projeto no Lean Construction Institute (LCI) (o que é isso ai não tenho a mínima idéia, mas eu acho que era pra ser conhecido). Verdade, que que o cara estava fazendo la?

Então o cara começou a explicar: "No desenvolvimento de Software, nos é ensinado que devemos gerenciar projetos como os projetos de Construção Civíl. Onde uma construção é planejada no início, custos e prazos são previsíveis, e os clientes recebem o que eles esperam receber."

Silêncio... "Você está brincando, certo?" "Não! Verdade, é assim que nos é ensinado."

Então, incredulidade torna-se em grades gargalhadas!
Quem já fez alguma construção, ou já precisou de que alguém construisse algo para você (o que é bem mais provável, visto que somos desenvolvedores de software), sabe que a obra sempre custa mais do que no início seu pedreiro disse que custaria, e a maldita obra parece não ter fim. Minha mãe está passando por uma reforma em sua casa, e já fazem quase 2 meses, isso que era pra terminar em 2 semanas. Sem contar, que obras externas sempre dependem das condições climáticas.
Outro artigo que achei legal, simples e direto foi este de Joel Spolsky. Tem ainda este.
Mas realmente uma Analogia mais real é a que Marcos Pereira, descreveu em: Desenvolver Software é igual a dirigir. Um dia ainda será assim em todo o lugar, e a paz mundial reinará! Mas até agora, poucas pessoas tem se beneficiado disso.
Outra pedrada, é um post do Thiago Arrais, onde ele diz que Fábricas de Software são uma analogia levada longe demais.

Acho que uma outra analogia boa para desenvolvimento de software como é feito atualmente neste modelo de WaterFall, está na agricultura. De que depende a agricultura e que o seu plantio tenha um bom rendimento? (Porque sejamos francos, tudo gira em torno do dinheiro. Ok, eu não sou nenhum agrônomo, mas vou tentar não falar merda)
  1. De um bom preparo do solo no princípio - Ter bons profissionais, Análise e Arquitetura inicial
  2. Plantar em época correta. - Saber o que usar.
  3. Cuidado no início, com pesticidas, fungicidas e tudo mais. - Ser maleável quanto a arquitetura incial, pois ela pode mudar conforme o entendimento do que é pra fazer vai aumentando.
  4. Rezar para não chover demais, nem de menos, em tempo de germinação. - Literalmente, rezar para que o entendimento inicial, realmente tenha previsto quase tudo, e que não surjam problemas muito complicados
  5. Saber a hora de colher.
  6. Rezar para não chover demais nem de menos em época de colheita. - Rezar para mostrar pro cliente na hora certa o software, para que ele não se decepcione de início. =)
  7. Conseguir estocar ou vender em uma época que o preço está bom. - Ter um ótimo departamento de Relação com o cliente, para fazer ele enxergar o software mais belo do que realmente é. =)
Talvez não tenha sido feliz em todas as analogias, mas era pra ser um pouco engraçado =)

Enfim, eu ainda trabalho em um modelo WaterFall, não tenho como mudar isso facilmente. Não vou ficar falando por ai, que sou contra tudo, que vamos revolucionar o mundo, matar todos os gerentes que não pensam igual a nós, como muitos falam por ai. Mas quem sabe com o tempo, ou conhecimento necessário, ou status necessário, ou apoio necessário, ou todas essas coisas juntas, eu consiga ir fazendo esta mudança.

E por fim, não poderia faltar aquela velha analogia de desenvolvimento de software.

quinta-feira, 26 de julho de 2007

Sim o Google também "Buga" [OFF]

Esta foi a resposta a uma consulta simples que fiz ontem:

terça-feira, 24 de julho de 2007

Configurando Virtual Host e Default Context no Tomcat

Bom, este post veio porque ontem ajudei um grande amigo meu com um probleminha neste aspecto. Queira aproveitar a oportunidade para deixar um grande abraço aqui pra ele, Daniel Kühl Lima, um dos únicos LPI3 do Brasil.

Normalmente quando você publica um servidor com um tomcat servindo uma aplicação, o que costuma-se fazer é simplesmente publicar a aplicação e passar a url para o usuário, por exemplo: www.meudominio.com.br:8080/aplicacao, e o usuário para acessar sua aplicação precisa digitar a url como consta ali, caso ele digita até o / ele irá cair naquela página default do tomcat, com links pra o Administrador e Manager.
Isso é beeem feio. Existe algumas maneiras de se fazer isso de uma forma mais "descente".
Primeiro, para melhorar, o usuário não precisa saber qual a porta para acessar a aplicação, então passar 8080 na url, é feio. Então o mais comum para arrumar isso é levantar o Tomcat com a porta 80. Para isso, é necessário alterar o arquivo [tomcatdir]/conf/server.xml trocando a porta na seguinte linha (normalmente está ~ pela linha 76):

< port="8080" maxhttpheadersize="8192">
trocar a linha pela
< port="80" maxhttpheadersize="8192">
Com isso resolvemos o problema de o usuário ter que digitar a porta 8080 na url. Porém, se o usuário digitar somente o seu domínio ele ainda acessará a página default do tomcat.
O que muita gente faz para corrigir isso, é instalar um Apache + Conector para Tomcat (para saber como configurar ver a documentação dos Connectors da Apache), e assim, ele configura para que o apache intermedie requisições para o tomcat, para que quando for acessado o raiz (www.meudominio.com.br) ele redirecione para a aplicação e pronto, o usuário não precisa mais saber qual o nome da aplicação.

Isso funciona. Mas para que ter que configurar mais uma coisa para acessar o tomcat, mais um possível ponto de erro!?
O que muita gente não sabe é que o próprio Tomcat tem suporte a Virtual Hosts.
Por default, o tomcat já vem com um Host configurado, que é justamente o raiz da aplicação, que é aquele host que está no arquivo server.xml.
< name="localhost" appbase="webapps" unpackwars="true" autodeploy="true" xmlvalidation="false" xmlnamespaceaware="false">

< !-- UM MONTE DE COMENTÁRIO AQUI-- >

< /host >

Para configurar então o tomcat para que assim que o usuário digitar a url do seu domínio ela acesse diretamente sua aplicação, você pode apenas definir o Default Context.

< name="localhost" appbase="webapps" unpackwars="true" autodeploy="true" xmlvalidation="false" xmlnamespaceaware="false">

< path="" docbase="aplicacao">

< /Host >

O path="" significa que será o context default, ou seja, assim que o usuário acessar o raiz de seu domínio, ele acessará a aplicação que você definiu no docBase.
Isto funciona para a maioria dos casos onde você tem apenas uma aplicação no servidor. Mas se você tiver um servidor que serve para vários domínios, você então precisará configurar Virtual Hosts, assim como era feito no Apache, quem administra servidores, sabe o que, e como fazer isso. Então, para fazer isso no Tomcat, basta você adicionar um novo Host, parecido com o do exemplo acima, porém, passando o domínio como name do host. Ex:

< name="www.meudominio2.com" appbase="/caminho/aplicacoes">
< path="" docbase="aplicacao2">
< /Host >
Agora, este novo host, você pode definir um context default ou não, isso depende da sua configuração. Caso você tenha multiplos domínios e apenas um servidor, basta ir adicionando eles a este arquivo. Lembre-se que todos os elementos Host ficam dentro do elemento Engine.

Nota importante:
Fiz alguns testes, e o tomcat se comportou de maneiras distintas em algumas versões diferentes. O que notei foi que o / tanto no appBase do Host, quanto no docBase do Context, faziam diferença. Então, caso não esteja conseguindo configurar, tente remover, ou inserir as barras tanto no início do caminho, quanto no final.

Bom, é isso, hoje não estou muito inspirado para escrever, então, eu sei que o post ficou com um português meio ruinzinho... Mas, sobretudo, espero ter ajudado alguém. Qualquer dúvida poste ai que eu tento responder.

[Update]
Para fazer isto no tomcat 6 mudou um pouquinho na parte de deixar o tomcat responder na porta 80 (primeira parte deste post). Mas não tem segredo, procure um "Connnector" no mesmo arquivo server.xml que contenha 8080, e altere para a porta 80 =) O resto continua a mesma coisa. Valeu.

quinta-feira, 19 de julho de 2007

JavaFX Script

Gostaria aqui de fazer um complemento sobre o meu post anterior sobre JavaFX onde falei basicamente sobre o JavaFX Mobile.

Estive no evento Falando em Java do pessoal da Caelum e teve uma excelente palestra sobre JavaFX com o Sérgio Lopes, onde ele demonstrou algumas coisas legais do JavaFX que na realidade eu não tinha visto no meu primeiro contato com ele, devido ao fato de eu estar mais focado na parte Mobile dele.
Vou relatar algumas aqui:

  • Declarative Syntax
    • Como era em Swing:
var win = new Frame();
win.title = "Hello World JavaFX";
win.width = 200;
var label = new Label();
label.text = "Hello World";
win.content = label;
win.visible = true;
    • Como é em JavaFX:
      import javafx.ui.*;

      Frame {
      title: "Hello World JavaFX"
      width: 200
      height: 50
      content: Label {
      text: "Hello World"
      }
      visible: true
      }
  • Data Binding
    • Você passa um objeto.atributo como valor de um campo e ele automáticamente atualiza este atributo de tal objeto.
  • Facilidade de Leitura
    • Facilidade de visualizar a estrutura da tela já no Código, por que fica algo bem "hierárquico" em código, e não aquela coisa bagunçada do Swing
Para obter mais informações sobre JavaFX veja o post da Caelum, veja ainda os links no final do post. Aguarde ainda os exemplos de código implementados pelo Sérgio Lopes na palestra.

Segundo o Sérgio, o JavaFX ainda está em uma versão "super-early-alpha", e NÃO DEVE ser usada em produção ainda. Mas pelo jeito haverá muito investimento nela neste e no próximo ano.

Tutorial sobre JavaFX Script
-----
Estava com este post enroscado por mais de uma semana esperando que o pessoal la da Caelum postasse sobre esta palestra =)

quarta-feira, 18 de julho de 2007

Eclipse 3.3

Como todos sabem o eclipse 3.3 (aka Europa) lançou a algumas semanas atrás (eu sempre atrasado) e está bem legalzinho. Com algumas firulinhas a mais e com uma carinha mais "clean" eu achei =)

Bom algumas features me chamaram a atenção:

  • Começando pela página de download! (que maravilha aquilo né!?)
  • Não precisa mais baixar todos os milhares de plugins básicos
  • Integração nativa com o Mylyn (Antigo Mylar) Task-Focused Development
  • Copy Qualified Name (ao menos eu acho, ou veio junto com meu workspace antigo)
  • Melhoras no Refactoring e Quick-Fix
  • Suporte nativo a JPA, WebService...
  • Suporte para Annotation (com auto-complete =] )
Mas a melhor coisa de todas, é que eu pude usar o mesmo workspace que eu possuia, sem ter que fazer imports e todo aquele trampo de baixar projetos novamente do repositório, plugins e tudo mais. A única coisa que tive que baixar foi o plugin do Subversion (subclipse). Me parece que o eclipse adotou o Subversive como padrão para as próximas versões, não o conheço e não sei se ele realmente é bom. Ele trouxe tudo já, configurações específicas de cada projeto, "Servers", Runtimes... enfim, tudo redondinho! ;)

Ahhh, gostei desta dica do Rafael Carneiro.

Problema ao gerar Jar com suas dependencias

Bah... eu não sou nem um pouco bom para fazer esses títulos ;)

Mas é o seguinte, esses dias estava em um projeto com um colega de trabalho, e estava desenvolvendo uma aplicaçãozinha que iria ficar rodando num servidor verificando alguns erros, e interagindo com uma outra aplicação. Fizemos a app e pusemos ela rodar no servidor, maravilha!

Rodamos ela fez o que tinha que fazer e beleza. Depois fomos testar ela novamente e misteriosamente não rodava mais! Nem a que estava na minha máquina de desenvolvimento resolvou não rodar mais. Dava um monte de erro de NoClassDefFoundError e NullPointerException.

Depois de algum tempo verificamos que tinha um monte de dependencias faltando, os xalan-xerxes da vida e todas aquelas dependências. Maravilha colocamos a app rodar e foi =) Problemas resolvidos, correto?!

Errado! Começou a gerar outros erros de .properties faltando! Fui procurar no build.xml e na hora que ele fazia o unjar dos .jar de dependencias do projeto, para depois jogar tudo dentro de um jar só no final, ele tinha uma propriedade que só pegava os .class dos jars e excluia tudo o resto. Ok, retirei a linha de restrição, e tudo passou a funcionar normalmente.

Pergunta: Porque funcionou da primeira vez?!

Agora uma outra historinha. Sabe o projeto de onde copiei o build? Então, este projeto está em produção a mais de 1 ano! Exatamente (pasme). Ele foi uma das heranças dadas a mim assim que entrei na empresa.

Coincidentemente uma semana após eu ter arrumado este erro no primeiro projeto, aquele que já estava em produção pipocou! Não rodou mais, começou a dar falhas, e não fazia mais o que tinha que fazer, foi um desesperto geral ontem aqui, pq era um problema seríssimo. Fui então correr atrás da causa, e me lembrei do ocorrido na semana passada, verifiquei que alguns erros que geravam era por causa de .properties que estavam faltando no .jar do projeto que roda la no servidor.

Guardamos arquivos de logs diários, dos ultimos 3 meses, e fui verificar os logs, este erro era recorrente. Sempre aconteceu, mas resolveu que de uma hora pra outra resolveu parar. O mais estranho, é que dei um kill no processo la no servidor, e então levantei o processo novamente, e tudo voltou a funcionar normalmente.

Pergunta: "Como pode uma porra dessa bátima?!"

Alguém já passou por isso? Alguém já viu algo parecido? Eu achei estranhíssimo! Por que o negócio sempre rodou, já faz mais de 1 ano, e agora resolveu pipocar de uma hora pra outra. E era uma coisa que estava faltando que deveria afetar sempre!

Por favor, alguém tem uma explicação racional para isso?! Agradeço se puder postar aqui.
-------------
ps: vou fazer um post sobre como gerar um build.xml descompactando os .jars e colocando tudo em um .jar só. Mas eu ainda acho mais correto exportar o Classpath colocando tudo em um diretório .lib as dependências. Muito mais "seguro" =)

terça-feira, 17 de julho de 2007

A re-Introduction to JavaScript

Como vi no blog do Guilherme Chapiewski (oh nomezinho difícil de escrever=] ), resolvi postar aqui também este link para um ótimo artigo sobre JavaScript.

Como JS está muito em alta hoje, ele tem grandes chances de perder a má fama que ganhou ao longo dos anos, e pra quem tem estudado e aplicado ele hoje em dia, tem se surpreendido com o seu poder, e o pensamento mais comum é: "Bah! E isso sempre existiu!"

Então pra quem é desenvolvedor web, esta é uma leitura essencialmente obrigatória.

Um link interessante ainda para dar uma olhada é o da especificação da linguagem JavaScript pela ECMA.

Valeu =)

domingo, 15 de julho de 2007

Java e C++ Benchmark

Devido ao fato de muitos amigos c-maniacs ficarem, ainda nos dias de hoje, baseando suas opiniões sobre Java nas velhas VM's 1.3-1.4 (no melhor dos casos), resolvi escrever este post. Não, não sou eu quem farei os benchmarks, mas fiz uma simples pesquisa no google sobre "c +java +benchmark" e dei uma lida em alguns artigos que falam sobre este tema, alguns de versões um pouco mais antigas da VM e outros sobre versões mais novas (1.5+).

Sei que este assunto é muito delicado e nada é decisivo, existem muitas variantes a serem consideradas e existem muitos testes diferentes. Mas o que realmente vemos, se quisermos ver é claro, é que o Java HOJE não é mais igual aquele antigo Java 1.1 de que tantas pessoas baseiam suas opiniões.

Well "Talk is cheap. Show me the code."

Antes de mais nada, vamos lembrar que não adianta querermos comparar um C com Java, mas sim C++ com Java, e é isso que a maioria destes benchmarks faz.

Para começar, utilizo o recente post de Paul Buchheit (criador e Lead Developer do Gmail), onde o primeiro parágrafo do seu post ele diz:

"A lot of people seem to be taking this post to be the "Ultimate C vs Java shootout". It's not. Performance is a very complex topic. My only real point is this: Java (which used to be slow) has reached the class of "fast languages". For the majority of applications, speed is no longer a valid excuse for using C++ instead of Java."
Em suma, ele diz que não é sua pesquisa o ultimato neste assunto de benchmark, mas que Java hoje, está na classe das "Linguagens Performáticas" e que "Velocidade ou Performance" não é mais desculpa para usar C++ ao invés de Java.

Ainda no post de Paul Buchheit, ele ressalta, que muitos testes atualmente contam o tempo de "start up" da VM como tempo de processamento, e simplesmente o que ele fez, foi fazer a iteração 3 vezes para cada código, e isto fez com que Java, fosse um pouco mais rápido que C na segunda e na terceira iteração.

Outro site que achei interessante, e que já tinha visto a uns 2 anos atrás, é este e ele tem um gráfico (abaixo) bem legalzinho sobre o desempenho em várias coisas, e isto usando a VM 1.4.2.



Outro ótimo artigo, que recomendo a leitura, é o do J.P.Lewis and Ulrich Neumann, onde além de colocar seus resultados, ainda desmistificam algumas coisas como:

1. GC is it worse... or better?
2. Run-time Compilation
3. Why is "Java is Slow" so Popular?

Não usei mais sites, porque acho que estes 3 satisfizeram minha idéia. Apesar de que em cada link deste post, existem muitos outros links para outros artigos sobre benchmark. E algo importante a ressaltar é "Não tome por verdade apenas 1 estudo sobre benchmark".

Concluindo, este não é um post que porá fim a questão, mas ao menos tenta abrir um pouco a mente dos "bitolados". Parar no tempo não é nem um pouco bom, ainda mais na nossa área. Entretanto, este também não é um post para dizer "Larguem C++ usem Java e sejam mais felizes", existe sempre a melhor escolha, e é impossível escolher o melhor caminho numa bifurcação se você só conhece um dos caminhos.

sexta-feira, 13 de julho de 2007

Garota de 7 anos cria um Pet Shop usando Java

WTF?!?!

Sim, foi o que pensei ao ver a notícia no InfoBlogs, e quando clico no link, me deparo com esta foto! Hahahaha muito boa =)

Créditos ao Rafael Benevides

quinta-feira, 12 de julho de 2007

Funcionalidade de Thread/Timer em JavaScript

Bom, digamos que o título não está exatamente bom, mas não consegui pensar em nenhum melhor =/

Ontem estava precisando fazer um lance parecido com o "Thread.sleep(numero);", ou melhor, acho que era mais parecido com o "Timer.schedule()", porém em JavaScript, e lembrei do tal conhecido método setTimeout(). Ele funciona, de uma maneira simplificada, assim:


<>
<>
var contador=0;
function testeTimeout()
{
document.getElementById('contador').innerHTML = contador++;
setTimeout('testeTimeout()',1000);
}
< /script>

< onload="testeTimeout()">
< id="contador">
< /div>
< /body>
< /html>


O que ele faz é "agendar" a execução do método passado no primeiro parametro, depois do tempo setado (que é em milisegundos) no segundo parametro. Ou seja, no exemplo acima ele iré executar o metodo testeTimeout(), e irá "agendar" uma próxima execução deste método para daqui a 1 segundo.

Um exemplo prático do uso disso seria fazer um agendamento de processamento de método (function) javaScript, para por exemplo, ficar fazendo um pooling via ajax em um determinado Serviço publicado pelo Application Server.

Outro aspecto interessante ainda sobre essa função é:
"Ela é blocante ou não?"
A resposta para esta pergunta é NÃO. Existem 2 situações onde ela poderia bloquear:
ter mais instruções no método logo abaixo da chamada de setTimeout
chamar outro método através de um evento qualquer por intervensão do usuário por exemplo.

Segue abaixo um exemplo para comprovar os dois exemplos. O timeout agora foi setado para 10 segundos para que seja possível a interação do usuário (clicar no botão):

<>
<>
var contador=0;
var contador2 =0;
function testeTimeout()
{
document.getElementById('contador').innerHTML = contador++;
setTimeout('testeTimeout()',10000);
for(i=0; i<10; i++)
{
contador2++;
document.getElementById('contador2').innerHTML =
document.getElementById('contador2').innerHTML+' '+contador2;
}
}

function alerta()
{
document.getElementById('contador2').innerHTML = 'outra função';
alert('teste');
}
< /script>

< onload="testeTimeout()">
< id="contador">
< /div>
< id="contador2">
< /div>
< type="button" value="Alerta" onclick="alerta()">
< /body>
< /html>


Concluindo, você pode, por exemplo, deixar um "serviço em background" na sua aplicação e ele não irá interferir no funcionamento geral, dentre outras inúmeras funcionalidades.

------
Pode até não ser tão grande novidade, mas agora quando precisar algo já tenho os exemplos prontos aqui (o que é uma coisa que normalmente perco) =)

terça-feira, 10 de julho de 2007

Programação Orientada a Gambiarras

Uma histórinha para iniciar a semana (ao menos aqui em SP) bem gostoso...

Sei, que a maioria já ouviu falar nisso, e outras ainda não. No entanto hoje de manhã, depois de um feriado prolongado no estado de SP, em que eu passei bebendo e dormindo, me deparo com uma situação que me lembrou este fluxograma:

Sim... isso mesmo. Logo cedo um email na minha caixa, falando que uma certa funcionalidade não estava OK num dos sistemas que herdei assim que entrei na atual empresa em que trabalho. Dai pensei comigo: "Bah... se eu mexer nessa bagaça vai dar mais merda! Vai começar a pipocar tudo! E dai sim EU serei o responsável!"
Uma conclusão que eu cheguei aqui, junto com um amigo, é que está aplicação está "fundamentada sobre gravetinhos", ou seja, vc tenta colocar um gravetinho a mais para sustentar a bagaça e o começa a quebrar os gravetinhos do outro lado...
É aquelas horas que vc grita: "PQP, assim não dá, vou refazer toda essa bosta aqui!", mas teu gerente te olha de longe com aquele olhar de "4 letrinhas" NTNB (No time, No Budget). =(

Bom, Boa semana a todos!
Desejem-me sorte!

--
Já que falei de POG segue o link para referência: http://desciclo.pedia.ws/wiki/POG