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.

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

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

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.

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 =)

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.