| Autor |
Mensagem |
|
|
Legal.
Ainda tenho uma pequena dúvida.
O livro dizia que a primeira iteração é a mais importante. Só que ele parte da perspectiva de que na primeira iteração já estamos implementando as User Stories. Só que onde entra o esforço para montar os recursos para que as funcionalidades possam ser implementadas (se, por exemplo, eu vou usar hibernate, preciso de um tempo para configura-lo, mesmo que o faça aos poucos)?
Não vi menção sobre as atividades paralelas ao desenvolvimento. Será que só devo me preocupar com elas quando sentir necessidade de tê-las?
Com o hibernate, por exemplo, posso criar uma unica classe que faça as operções básicas de persistência (inserir, excluir, deletar) para qualquer entidade do meu sistema. Ora, nada mais justo do que, antes da codificação começar, essa classe já esteja pronta. Ou então, algum desenvolvedor, quando precisar persistir, cria essa classe e comunica aos demais que existe uma classe de utilitário que pode ser reutilizada por todos.
Essa é minha dúvida. Como coordenar esse tipo de problema? Para não acontecer de várias pessoas estiverem implementando a mesma funcionalidade (lembro que o livro menciona algo sobre enxergar algumas redundâncias, mas diz para não se preocupar com elas no momento)?
Enquanto escrevia esta mensagem me lembrei de algo. As reuniões diárias em pé. Segundo o livro, com elas, os desenvolvedores estão, no máximo, um dia desatualizados.
Será que são nessas reuniões que se descobre que dois desenvolvedores estão fazendo uma classe de utilitário que faça a mesma coisa? Detectado então o problema, eles se juntam aos pares, implementam a classe e descartam a outra?
Ainda acho melhor ter uma análise um pouco mais profunda para detectar esses pontos. Ou posso estar enganado e, mesmo deixando esses problemas para serem descobertos e refatorados depois, o projeto possa ser entregue sem problemas...
|
 |
|
|
Estou lendo o guia prático do Extreme Programing.
Já lí sobre programação em pares, user stories etc... (devo estar lá pelo capítulo 11-12).
Foi +- por esse ponto que o autor falou que os críticos da XP diziam que ela não se preocupa com a arquitetura (o que, segundo o autor, não é verdade).
Pois bem, dei uma avançada no livro e dei uma lida no exemplo que eles mostram no final.
O que posso dizer é que realmente não vi nenhuma arquitetura ser planejada. Simplesmente, após o teste ser construído, as funionalidades eram adicionadas as classes.
Por exemplo, a classe cliente (entidade) possuia seus acessors e mutators normais (getter and setter) mas possuia também uma série de outros métodos, que incluiam até mesmo métodos auxiliares para persistência em XML.
Estou gostando muito da abordagem que a XP oferece, e muitas de suas práticas fazem bastante sentido quando o autor disserta sobre elas.
Mas... Quando lí os exemplos... cara. Realmente não concordei com a abordagem que eles usaram (quer dizer, o resultado final do sistema).
Será que não seria bom dedicar um mínimo de tempo para já se usar alguma arquitetura. Por exemplo, ter uma classe responsável por persistência e deixar as entidades apenas com os métodos get e set???
Acho que padronizar o código é muito importante (por exemplo, determinadas funcionalidades devem ser distribuídas em tais e tais classes). Dessa forma, os outros desenvolvedores já sabem onde procurar determinado trecho de código.
Não sei se estou me enganando, mas lembro de ter lido que o programador escolhe a forma de implementar a funcionalidade. Acho que isso pode desorganizar um pouco as coisas (não estou falando em que algoritmo ele usa, mas onde coloca seus métodos etc...).
Comentários? Alguém com uma maior experiência para falar do assunto? Alguém que já usou o modelo clássico e uma arquitetura em camadas e depois usou XP em algum outro projeto? Quais foram as diferenças que vocês notaram, arquiteturalmente falando?
::caraca meu português tá uma droga::
|
|
|
|
Tô ligado. O contexto guarda as "variáveis" velocity. Dessa forma você pode usar o mesmo contexto para vários templates. É só possuir as variáveis que vão ser necessárias lá.
Ok então. De qualquer forma, como o usuário vai criar o template através da própria GUI, posso colocar um botão lá (Criar Variável...) que armazena seu nome e sua descrição em um arquivo properties.
Dessa forma, quando for rodar o template, a GUI lê o properties associado e exibe as variáveis através de sua descrição.
Como a classe property me permite obter todas as keys dela o problema está resolvido.
Se alguém precisar criar um tmeplate na mão, paciência. Vai ter que configurar o property na mão.
Valeu pela força...
[]s
|
|
|
|
Assim não rola paulo.
Eu não quero listar as keys dentro de um template (como vc fez usando #foreach).
O que eu quero é o seguinte:
1 - minha classe Java lê o tamplate.
2 - Depois ela pega o nome das variáveis que existem no template.
3 - Ela usa o nome dessas variaveis para montar uma GUI, contendo text areas para que o usuário preencha os valores delas.
4 - Para cada valor preenchido, eu chamo context.put("nome da variavel", o valor que o usuario preencheu atarvés da GUI).
5 - Chamo o merge() para gerar o output.
Seria algo +- assim
Sacou?
Preciso de ajuda pra isso. Acho que o velocity não faz isso não :(.
Rafael, alguma ajuda aki??????????
[]s
|
|
|
|
Valeu cv.
Eh isso emsmo Paulo.
Mas eu não posso acreditar que não seja possível.
Quando você faz context.put("nome", "algo"); o velocity vai ter que procurar pela variável ${nome} não é verdade? Acredito que ele não parseie o template toda vez para saber se a variável existe. Ele deve conter um HashMap interno (ou alguma outra forma de armazanar isso) com os nomes.
Vou dar uma olhada nas listas. Falows!!!
[]s
|
|
|
|
Como faço para saber quais as variáveis que existem no meu template velocity (para, por exemplo, construir uma interface gráfica para preenche-las)?
O método getKeys() do VelocityContext só retorna as variáveis que já possuam algum valor atribuído...
|
|
|
|
Eu uso o Together CC aqui na empresa também. Ele é o 10. Mas a próxima versão do omondo diz que também vai dar suporte a design patterns e vai permitir que você crie seus próprios patterns. (o que no Together é "a pain in the ass", você tem q usar uma API escrota paca).
E achei a parte de templates do together fraca, so deixa você criar um campo adicional ($UserDefined$).
Ainda assim ajuda bastante pois tenho templates para minhas classes DAO e cadastro pra hibernate e, com pequenos ajustes, o código funciona rapidinho (adeus sql...).
Quero ver como o omondo vai lidar com a criação de patterns próprios do desenvolvedor.
|
|
|
|
Me empolguei.
Baixei o plugin OMONDO UML Eclipse. Muito show de bola. Sincronização total com o código. A versão enterprise (prevista para 15 de agosto) vai ter um bocado de coisa bacana e, melhor ainda, vai ser free para empresas .org com projetos não comerciais (os JUGs, universidades) etc...
Vocês podem baixar o plugin aqui
http://www.omondo.com/
Ah coloque essa mensagem aqui pois acho que está mais relacionado (UML, design patterns, modelagem etc...)
|
|
|
|
Note que as aspas duplas em negrito estão fechando precocemente o atributo onChange.
Não sei como ajudar nesse caso, pois vc usa uma aspas duplas para o onchange e aspas simples para a funcao javascript, dessa forma, vc fecha precocemente uma ou outra instrução.
Nesse caso acho que vc deve criar scriptlets na sua página mesmo...
|
|
|
|
Acho que esbarramos no velho protecionismo americano.
Também! Imagina só se dos 25, 20+ fossem do Brasil. Os egos iam se exaltar... :)
|
|
|
|
Uh???? No meu Package Explorer a única seta pra baixo que tem é a de escolha do Working Set (que, a propósito, fica a direita). Não achei nenhuma "visão hiherarquica" no Package Explorer.
Eh essa mesmo a perspectiva que vc tah falando? Será q tamos com versões diferentes? (To usando a versão 2.02).
|
|
|
|
Galera do GUJ. Como é que faço para organizar os pacotes no eclipse, agrupando os pacotes como uma estrutura de diretório ou fazendo como no JBuilder (agrupando um início comum):
em vez de colocar uma linha para cada pacote. Fica até ruim de visualisar depois, pois os nomes do pacote ficam muito grande.
Na minha tela só o que vejo é br.com.facilit.projeto e sempre tenho q ficar rolando a barra pra ler o final do pacote e identificá-lo.
Também gostaria de tirar os .jar que seu projeto usa no classpath da árvore. Acho eles desnecessários. Eu gosto na minha treeview apenas aquilo com o qual eu esteja implementando/alterando.
[]s
|
|
|
|
Ei galera. Vocês sabem qual o critério para avaliação do Top 25 JUGs do mundo. Pô na listagem tinha JUGs com apenas 4 membros. Uma porrada do Brasil ficou de fora que tinha muito mais usuários!!!
Qual foi?
|
|
|
|
controller sao os actions que pega as coisas no banco e passa pro view,
pode conter regras de negocio,
quer dizer, faz o que o nome diz... "controle"
As Actions no Struts não SÃO o controller (e existe até mesmo discussão se elas fazem parte do Controller ou não). O Controller é o servlet "coração" Struts, juntamente com o RequestProcessor. A função do Cotroller é decidir quem (das Actions) deverá processar o comando solicitado pelo usuário.
As Actions implementam o pattern Command (comando) e, junto com o Controller, implementam o Command-Controller.
As Actions não deveriam conter regra de negócio: elas funcionam como uma ponte entre o Controller e o Model. Se a action conter regra de negócio, então sua estrutura MVC é invalidada, pois caso se utilize Swing sem acesso a servidor web, por exemplo, vc tem que reescrever suas regras de negócio novamente em um outro componente, já que as Action do Struts não estarão mais disponíveis.
minha unica duvida quando ao medole MVC sao os views... por exemplo, uma taglib pode conectar-se ao banco? ou isso é errado?
Se você cria uma taglib que acessa o banco ocorre algumas coisas indesejáveis:
1 - Você está fazendo a view acessar direto o banco, sem passar pelas regras de negócio do Model.
2 - Você fica preso ao banco de dados. Se depois seu repositório mudar para XML, por exemplo, sua tag tem que ser reescrita.
|
|
|
|
A maior parte do meu tempo de estudo é no trabalho mesmo. Sou meio cientista e, já que a equipe é pequena, temos poder de decisão nas tecnologias que queremos usar.
Sempre tiro uma horinha pra estudar (espero q meu chefe não leia isso).
Em casa não estudo muito não. A não ser em véspera de prove  .
|
|
|
|