| Autor |
Mensagem |
|
|
Amigo, o artigo cita Scrum, mas pensando no Rugby. Vc leu esse artigo? Ele também diz da Canon, Fuji e mais uma porrada de empresas. Seria muito simplista dizer que Scrum saiu da area automobilistica. Sim o Scrum tem pitada de várias idéias, como Lean o próprio TPS e etc, mas a junção dessas coisas que o Ken e o Sutherland fizeram era puramente para projetos de produtos de software.
|
 |
|
|
ViniGodoy wrote:
Vale lembrar que mesmo as metologias não ágeis já não são completamente waterfall, e se dividem em ciclos de poucas semanas de desenvolvimento. A maioria já adota o Scrum que, do contrário que o Rodrigoy deu a entender, não é um método ágil, mas uma prática de projeto (surgida inclusive na indústria automobilística).
Scrum não é Agil? Scrum surgiu na indústria automobilistica? Fontes por favor?
|
|
|
|
XP é mais indicado para produtos que qualquer outra metodologia. Vários clientes meus usam XP como a Web Goal, a Crivo, a Fortes. Todas são empresas de produtos que usam Scrum e/ou XP.
O que eu não vejo tanta aplicabilidade é para projetos outsourcing mesmo.
|
|
|
|
No site da Aspercom Treinamentos, material em português:
http://www.aspercom.com.br/ead/course/view.php?id=15
(clique no botão apostila)
Se interessar, nesta sexta-feira em São Paulo tem uma turma desde treinamento prático de Scrum. Eu sou o instrutor. Abraços!
|
|
|
|
|
Independente da clareza ou coesão do seu modelo, na UML as operações sempre ficam na classe que a possui e não no chamador (o que envia a mensagem).
|
|
|
|
eu confundí com o redirect...
pior que eu peguei isso de um exemplo da internet... não sei aonde... nem tinha notado que o método não existia
#fail 
|
|
|
|
Diego você eh um gênio...
Mas fica a reflexão, qual a diferença entre:
e
|
|
|
|
Amigos(as),
Deve ser algo bem idiota, mas porque essa espec não tá funfando? É muito simples!
Está dando:
Spec::Mocks::MockExpectationError in 'PerfilsController deve mostrar o usuġrio passado como parĢmetro'
<Perfil(id: integer, login: string, senha: string, nome: string, descricao: text, data_nasc: date, estado_civil: string,
created_at: datetime, updated_at: datetime) (class)> expected :find with ("1") once, but received it 0 times
./spec/controllers/perfils_controller_spec.rb:10:
O código está no GitHub...
http://github.com/rodrigoy/beckanos-rails/tree/master
|
|
|
|
|
O Hpricot salvou a minha vida no RailsRumble.
|
|
|
|
Navegabilidade e Multiplicidade são coisas diferentes. Mas isso foi só um comentário sobre o código do Taborda.
Um quarto tem reservas no passado, no presente e no futuro. De qualquer forma, a multiplicidade alí não muda o problema...
Para falar a verdade, achei que isso era meio lógico também. Um quarto pode ter reservas para hoje, para a semana que vêm e para daqui 1,2,3 meses...
|
|
|
|
sergiotaborda wrote:
A reserva tem 1 quarto, mas o quarto tem 1,0 reservas. O quarto está reservado quando ha no sistema uma reserva que o possui.
Algumas pessoas não entenderam bem, para falar a verdade um quarto tem várias reservas. Reservas são futuras e passadas.
Tem outras considerações que farei Taborda... só estou sem tempo agora.
|
|
|
|
Link_pg wrote:Vale a pena ferir as regras há muito estudadas por especialistas em favor de uma possível 'facilitação' no desenvolvimento da arquitetura?
Neste caso, não é uma regra que um repositório deva sempre retornar a mesma coisa. Repositórios simplesmente representam coleções.
Não me lembro em nenhuma literatura de padrões falando sobre regras. É mais empírico. Quando o GOF foi escrito eles foram claros em dizer que Padrões eram soluções comuns que apareciam no código para problemas específicos. Um padrão é a repetição de um determinado mecanismo dada uma situação. NÃO É UMA REGRA. Se fosse o nome do livro seria Software Design Rules.
Você deve fazer o mesmo caminho para voltar para casa todos os dias. Isso é um padrão. Se você por alguma razão não fizer o mesmo caminho não estará violando uma regra.
|
|
|
|
sergiotaborda wrote:
Colocar um repositório de X retornar Y acho que não é lógico. Sendo assim o detalhe tem que ser contornado no design e no modelo para que seja lógico. às vezes temos que ir mais longe. Temos que chegar em algo como Hotel.getQuartosLivresParaReservaEm(Periodo) : Quartos. Isto dá o que você quer, é ainda mais realista que um objeto chamado TodasReservas e é semântico o suficiente para usuarios e programadores.
Não me parece lógico em Domain-Driven eu ter um elemento chamado Hotel sendo que o que eu estou modelando é o funcionando do mesmo. Já tinha respondido aqui que ter esse "Hotel" gera outros problemas também lógicos.
sergiotaborda wrote:
Esquecendo a UL por um pouco, do ponto de vista puramente OO um repositório de X retornar Y é uma violação do objetivo do próprio objeto repositório. Se vc não quer que o repositorio de X retorna sempre X porque vc afirmar que é o repositorio de X se na realidade posso encontrar nele outras coisas ? É como ter um TodasPessoas e ter um TodasPessoas.getAnimaisDeEstimação() : AnimaisEstimação ... animais de estimação não são pessoas, que magia é essa que me permite tirar animais de onde só ha pessoas ?
Não exagera!!!  No meu exemplo não estou misturando tanto as coisas. Reserva é algo intimamente relacionado com Quartos. Repositórios simplesmente representam uma coleção, geralmente de entidades. Portanto, mensagens que eu atire para este objeto denotam a responsabilidade dele. Não me parece sem lógica perguntar algo para um repositório sobre uma coisa que só ele sabe. Só as reservas sabem os quartos disponíveis.
sergiotaborda wrote:
Claro que vc pode optar por dizer que o repositório é agnóstico, que ele não é de X ou Y e que não ha problema algum em TodosX retornarem Y. Ok. Mas por esse mesmo agumento não ha por que ter dois repositórios , um para X e outro para Y. Basta ter um RepositorioGeral que encontra tudo de qualquer tipo.
Exagerou de novo. O EntityManager é o RepositorioGeral, mas usá-lo deste jeito não é Domain-Driven.
sergiotaborda wrote:
Não é preciso ter poderes mágicos ou ser visionário para criar um bom design. É só seguir a regras. O argumento que as regras podem ser dribladas em condições especiais não é lógica para mim e realmente eu vejo isso como um pecado de corrupção.
Eu já sou da opinião que design é algo criativo. Padrões existem como um guia não como regra. Só conhecimento em padrões não faz ninguém um bom designer.
Na sua solução (listada abaixo), você está construindo entidades transientes somente para que seu repositório TodasReservas retorne Reserva[0..*]. Para mim isso não é lógico, e qualquer programador que pegar esse código no futuro não vai ter a mínima idéia de porque você montou uma lista transiente de reservas se no fim o que você queria eram quartos.
sergiotaborda wrote:
d. Faço uma pesquisa em TodasReservas por getReservasPossiveis(Periodo)
Isso irá trazer uma lista de objectos reserva com as datas iguais às do periodo e os quartos iguais aos disponiveis. Se vc quiser mesmo mostrar os quartos vc usar reserva.getQuarto()
É claro que por detrás dos panos vc irá procura apenas os quartos e montar os objettos reserva "on demand" no repositorio porque essas reservas não existem "fisicamente" no banco. Mas existem no dominio. Tanto é que vc está procurando por elas.
Isso aqui abaixo é do agrado de todos?
:Quartos])
|
|
|
|
sergiotaborda wrote:Mas, o retorno não pode ser quartos. Esse , acho, que é o ponto mais importante.
Você acha que é um pecado imperdoável um repositório de Reservas retornar Quartos, mesmo que isso faça sentido para os especialistas do domínio e os usuários?
[essa pergunta é para todos, não só para o taborda]
|
|
|
|
sergiotaborda wrote:
ELe designa uma tecnologia em que o objeto tem propriedades e além disso ele tem listeners para alteração dessas propriedades. O SwingBeans, por exemplo, tira partido desta tecnologia.
Vc tem razão, meus repositórios não tem listeners e não vejo razões para ter listeners...
(para falar a verdade, isso deveria ser out-of-the-box no Java)
Um repositório poderia ser um Javabean numa aplicação desktop local.
|
|
|
|