| Autor |
Mensagem |
|
|
Botocudo wrote:
diegosammet wrote:
Que é isso gente ... RUP ? OpenUP ? Scrum, XP ? para um projeto de uma pessoa só ?
Exato, eu fui lendo o tópico e dizendo: WTF?!
+1.
Não entendi muito bem o espanto. O cara não falou o escopo ou o "tamanho" do software. Pode ser um sistema de agenda ou pode ser um ERP.
Se o cara quer fazer um produto manutenível que tenha qualquer tipo de documentação, seja ela técnica, funcional ou de usuário, ele precisa de ALGUM processo, qualquer que seja. Pra isso ele precisa de embasamento teórico em qualquer processo que seja.
|
 |
|
|
O que todo mundo falou é de muita utilidade. Eu só teria cuidado em procurar informações mais embasadas.
O que você quer é entender como funciona um processo de desenvolvimento de software. Existem diversos processos padrões no mercado, desde os mais tradicionais como o RUP, e suas derivações, até as ditas metodologias ágeis como o SCRUM e XP, por exemplo.
Processo de desenvolvimento de software não é algo "Aprenda em 24h" se você quer ter um real entendimento do assunto.
Não existe processo "bala de prata", você precisa entendê-los para definir qual é o melhor para o escopo do seu projeto.
Outro erro comum que as pessoas costumam cometer é confundir UML com processo. UML é uma boa forma de facilitar a rastreabilidade e comunicação dentro de um processo. Ou seja, UML é uma forma de facilitar abstrações dentro de determinados processos.
|
|
|
|
Testes de unidade são importantes para garantir regras de negócio com maior corretude. Então tem de tomar cuidado pra não sair criando testes para toda e qualquer classe do sistema; testes de unidade tem custo e devem ser utilizados em classes que tem maior prioridade para serem testadas (classes de maior valor do ponto de vista de negócio).
O problema que tem muito desenvolvedor que considera todos os métodos do sistema uma unidade de teste.
|
|
|
|
Você só tem retorno do método dentro do try; caso alguma exceção for lançada seu método não estará retornando nada, então está errado. Uma boa prática é quando se tem um método com retorno. Sempre retorne na última linha. Se você colocar o seguinte código vai funcionar:
|
|
|
|
Concordo marcosalex.
Diversas vezes um diagrama de sequência me ajudou a entender melhor o fluxo de informação através de determinados sistemas e bancos de dados, facilitando o entendimento do caso de uso(ou estória de usuário).
|
|
|
|
O ViniGodoy foi perfeito em sua colocação. UML é muito presente e deve ser usado como ferramenta de comunicação.
Em relação ao modelo cascata, o fato de uma determinada empresa utilizar UML não quer dizer que ela utiliza o modelo cascata; é necessário avaliar como o processo de desenvolvimento da empresa funciona. No livro de XP do Vinicius Teles ele deixa bem claro que é comum empresas que utilizam metodologias ágeis utilizar notação UML para determinadas situações a qual facilita o entendimento dos casos de uso, atores, comunicação etc.
Sempre deve existir o mínimo de padrão possível para que não exista o caos dentro de uma empresa de desenvolvimento. Esse mínimo padrão possível precisa ser analisado a partir do tamanho da empresa, quantas equipes existem, qual o fluxo de comunicação, qual a metodologia de desenvolvimento utilizada etc.
Nunca se esquecendo que não existem balas de prata: a realidade da minha empresa pode ser completamente diferente da realidade da sua.
|
|
|
|
No arquivo cliente.hdm.xml modifique a seguinte linha:
Pela:
O erro continuou?
|
|
|
|
|
Lembro de ano passado um projeto da JBoss relacionado a um Hibernate-OGM, não acompanhei o projeto e não sei que fim teve. Mas seria algo lindo!
|
|
|
|
|
Hoje a persistência poliglota existe na teoria. Imagine vc ter uma entidade 'Pessoa' e vc ter ORMs que poderiam salvar ou recuperar dados de multiplos modelos de dados transparentemente para você. Este é o caminho das pedras. Em breve estaremos nesse nível.
|
|
|
|
Na minha opinião esse conceito de 'persistência poliglota' descreve exatamente como será o armazenamento daqui a alguns anos 
|
|
|
|
Agora você esclareceu bem seu ponto de vista. Você tem razão. Soluções NoSQL em sua maioria não são bala de prata. Você tem vários modelos para resolver vários problemas. Empresas que costumam utilizar bancos NoSQL fazem junções de tecnologias. O próprio nome NoSQL('Not Only SQL') trás esta ideia de não apenas o SQL, mas também outras soluções mais adaptáveis às regras de negócio.
Mas bancos NoSQL não são utilizados pelo Twitter ou Facebook para teste. Fato. Não faltam artigos de empresas mostrando casos de sucesso com NoSQL.
Só tome cuidado ao fazer sua proposição. Proposições sem fundamento trazem essa sensação de trolagem.
|
|
|
|
fredferrao wrote:
Na real não sei de onde tu tirou que eu acho que só existe cassandra, mas enfim. Mas continuo achando que twiter e facebooks usam nosql para pequenas coisas a fim de testar.
Você continua achando errado
Estamos falando de bancos escaláveis, distribuídos, para grande volume de dados. Desde quando o Google publicou o artigo sobre o BigTable as grandes empresas vem procurando nestes novos modelos 'não-relacionais' solucionar gargalos encontrados em bancos relacionais.
Hoje bancos NoSQL são grandes realidades, claro que não são perfeitos e tem suas limitações.
Mas reitero o conselho sobre a leitura daqueles artigos do http://nosqlsummer.org/papers
|
|
|
|
Para quem ainda não está ligado no movimento NoSQL aconselho fortemente a ler alguns desses papers: http://nosqlsummer.org/papers
Assim vocês entenderão como grandes empresas como Google, Yahoo, Facebook, Twitter entre tantos outras adotaram estas soluções visando escalabilidade e performance das suas aplicações.
|
|
|
|
Acho que você deseja chamar o método setText e não o getText.
Métodos get normalmente retornam informação.
|
|
|
|
|
Na MINHA opinião, caso de uso não é artefato para codificação. Se existir pelo menos um desenho da aplicação, nem que seja um desenho simples, já é um bom artefato para inicio da codificação.
|
|
|
|