| Autor |
Mensagem |
|
|
cv wrote:Vao, mas a mudanca organizacional e cultural que tem que acontecer nessas empresas pra que agile/lean/scrum sejam adotados de forma produtiva diminui drasticamente as chances de vc ver algum projeto decente acontecendo nos proximos dois anos, especialmente se estivermos falando das [A-Z]{3}.
Adoção de verdade ainda vai demorar. Tenta explicar pair programming para algum executivo de empresas [A-Z]{3}. Mas o rótulo, não demora para usarem.
valeuz...
|
 |
|
|
Tenho usado o assembla e não tenho do que reclamar.
valeuz...
|
|
|
|
cv wrote:Enquanto isso, o player continua fechado. Lembrem-se disso, pessoas que nunca se foderam pra fazer o player funcionar no Ubuntu 64... ou em qualquer outra plataforma onde o player nao eh suportado...
Pois é. Eles poderiam ao menos fornecer o binário para essas plataformas.
valeuz...
|
|
|
|
tnaires wrote:Sabe onde eu poderia reportar esse bug, caso alguém não o tenha feito?
Abraços
Já foi corrigido na versão 1.0.1.
valeuz...
|
|
|
|
Maurício Linhares wrote:Eu, até agora, não tive problema nenhum quanto a isso, o negócio é manter os métodos simples, pequenos e dar as variáveis nomes decentes (além de saber quais as mágicas estão acontencendo nos seus objetos).
Teste vão bem também. 
valeuz...
|
|
|
|
Se vc está se preocupando com escopo a esse ponto, deve ter algo de errado. Em geral, vc só usa uma variavel declarada 50 linhas antes se ela estiver no escopo da classe. No mais, o interessante é tentar manter métodos e blocos de código mais curtos: são mais fáceis de ler, entender e manter.
valeuz...
|
|
|
|
LuizAvila wrote:Depois ele montou o InfoQ
Que tem conteúdo bem melhor do que o TSS, aliás.
valeuz...
|
|
|
|
djemacao,
É praticamente aceito na lista de usuários do Grails que ter uma versão 1.0 tem mais implicações culturais que técnicas. É realmente mais fácil vender algo com um 1.0 final do que com RCs e por aí vai. Onde trabalho um dos projetos é desenvolvido com o Grails e até agora os problemas é o costume de tentar encaixar algumas complicações (desnecessárias) que nós desenvolvedores Java tanto gostamos.
Pessoalmente tenho desenvolvido alguns projetos com o Grails e minhas reclamações são para o suporte a testes. Falta melhorarem alguns pontos:
1. Stack traces ilegíveis quando um teste falha
2. Faltam reports mais diretos sobre o porque o teste falhou
3. Falta um esquema para executar apenas os testes que falharam
4. Melhorar o plugin para cobertura de código (que se confunde com as closures)
5. Um plugin para Selenium, que eu acho bem melhor do que o WebTest.
O que eu faço para facilitar minha vida é:
1. Os testes são escritos para situações muito especificas e com nomes super descritivos
2. Um assert por teste, assim eu sei exatamente o que falhou
3. Todos os asserts com mensagens
4. Small steps para implementar/refatorar qualquer coisa
São práticas que ajudam mesmo quando vc desenvolve em Java, mas são ainda mais uteis para o Grails. Sobre o VRaptor, dá para usar Groovy para criar as classes de modelo e escrever os testes. É mais interessante do que fazer em Java.
valeuz...
|
|
|
|
Maurício Linhares wrote:Ah, então melhorou demais mesmo
Onde é que eu acho mais informações sobre isso?
Bom, provavelmente os novos livros sobre Groovy vão falar sobre o assunto. Dá para ver algumas coisas na wiki (http://groovy.codehaus.org/ExpandoMetaClass) e em blogs por aí (http://thediscoblog.com/2008/02/02/metaprogramming-is-so-groovy/).
Maurício Linhares wrote:O meu "Groovy In Action" não fala nada dessas mágicas.
Deve ser porque o livro foi escrito quando Groovy 1.1 - a versão na qual esses recursos foram adicionados - ainda estava em desenvolvimento.
valeuz,,,
|
|
|
|
Maurício Linhares wrote:Veja que eu disse:
(na verdade, até pode se você fizer umas gambis no despacho de métodos)
Mas é muito mais complicado do que simplesmente fazer um define_method (ou module_eval e class_eval) em Ruby, você tem sempre que fazer override de "invokeMethod()" (a não ser que tenha mudado desde a última vez que eu mexi com isso em Groovy), o que termina sendo quase igual a ter sempre que fazer override de method_missig em Ruby, o que não é interessante, principalmente porque não tem um alias_method em Groovy.
É assim que funciona hoje em dia. Adicionar propriedades é simples também:
valeuz...
|
|
|
|
Maurício Linhares wrote:O maior problema de Groovy é que ela é próxima demais do Java, então muita coisa não tem como ser feita em Groovy, como mixins, definir novos métodos em tempo de execução (na verdade, até pode se você fizer umas gambis no despacho de métodos, mas é bem mas complicado do que seria em Ruby com um class_eval, module_eval ou ainda um define_method).
Não vi callbacks pra quando uma classe extende a outra (e isso é muito importante pra metaprogramação e seria ainda mais se Groovy tivesse suporte a módulos). Groovy também não tem open classes/modules, deixando você alterar o comportamento de classes já definidas no ambiente (como colocar novos métodos em String). Open classes são uma mão na roda quando voc está mexendo com código alheio que está versionado e você não pode fazer "patches" diretos.
Enfim, o grande problema de Groovy hoje ainda é o suporte fraquinho a metaprogramação e é isso que faz de Ruby uma linguagem bem mais flexível.
Maurício, a maior parte das coisas que vc citou Groovy possui. É possivel sim, sem complicação, adicionar novos métodos, propriedades em tempo de execução, mesmo em classes já existentes (como String). Como vc acha que o GORM funciona? É possivel também alterar métodos. Mas é verdade que não há módulos e callbacks no caso de herança.
Algumas coisas que poderia copiar na cara dura de Ruby seria null como object e mixins. O mais próximo que Groovy tem de mixins são marcações, no Grails, para indicar que uma classe deve ser alterada - veja só - em tempo de execução.
valeuz...
|
|
|
|
louds wrote:Quanto a essa entrevista, o que se poderia esperar de um funcionário da tal empresa? Que fosse fazer alguma crítica construtiva ao produto dela?
Fora as perguntas mais parecerem propaganda:
PERGUNTA ? Qual é a aposta que você faz aceitando o convite da Softwell para dirigir a filial São Paulo que atenderá às três mais importantes regiões do Brasil em relação ao mercado brasileiro de softwares?
E o final arrasador:
Sejam vocês um ?Maker? também.
valeuz...
|
|
|
|
http://www.assembla.com/
SVN + Trac + Outras ferramentas.
valeuz...
|
|
|
|
volnei wrote:HQL é java? Qual JSR??
Acho que o louds se referia a poder usar anotações (Java) para mapeamento e Criteria API (Java) para realizar consultas. Bom, só com JDBC não tem como escrever apenas código Java, tem?
Mas entendi o ponto do tópico. Minha opinião: tenha bom senso - e bons argumentos - para decidir usar ou não algum framework/abstração.
valeuz...
|
|
|
|
pardal_nb wrote:alguma sugestao?
http://www.amazon.com/Test-Driven-Development-Addison-Wesley-Signature/dp/0321146530
valeuz...
|
|
|
|