| Autor |
Mensagem |
|
|
|
Me lembro o caso da SCO contra o Linux kkkk
|
 |
|
|
Muito bom. Tenho visto falarem bem do JavaFX novo, mas ainda não tive a oportunidade de usá-lo para ter uma idéia própria.
Gostei dos updates para C++ e PHP... vamos ver como ser comportam hehe
|
|
|
|
|
Muito interessante a idéia. Outro concorrente que talvez entre na lista é a Akka.
|
|
|
|
fredferrao wrote:...
...
The English-language comments in CodeSourceTest.java and CollectionCertStoreParameters Test.java? NO, not infringing
Nossa! Reclamaram até dos comentários! Para mim esta é nova. 
|
|
|
|
Não vai fazer diferença nenhuma quem ganhar. Ninguém vai largar a galinha dos ovos de ouro na mão. 
|
|
|
|
|
Enfim alguma coisa útil sendo feita.
|
|
|
|
LucianoM86 wrote:Já usei muito mock em testes, mas hoje penso várias vezes antes de usar. Com o passar do tempo, a manutenção de testes com mock acaba ficando cada vez mais complicada e começo a duvidar da eficácia dos mesmos. Claro que existem casos (integração com sistemas de terceiros por exemplo) em que você acaba sendo obrigado a usar mocks, a não ser que possua um simulador do sistema.
Hoje prefiro que os testes sejam os mais reais e próximos da realidade possíveis, ou seja, de integração mesmo.
Concordo. No início do projeto os mocks são mais produtivos, justamente pelo fato de poderem simular situações que ainda não estão totalmente implementadas. Já com o sistema implementado acho que o mais produtivo é realizar os testes das fases posteriores (sistema, aceitação, etc), que permitem verificar se o que deveria funcionar ainda está funcionando e o que devia ser feito realmente está sendo feito.
|
|
|
|
|
Os testes unitários são importantes tanto quanto os outros, pois erros encontrados nas fases preliminares são bem mais rápidos de serem corrigidos do que os somente descobertos na fase de aceitação, por exemplo. Ainda, acredito não ser útil/necessário fazer mocks para todos os processos, pois é dispendido um tempo a mais somente para fazê-los.
|
|
|
|
Interessante a idéia do with 
Talvez dê para simular isto usando as features do projeto lambda.
|
|
|
|
GilsonNunes wrote:
Adelar wrote:
ViniGodoy wrote:
fuadksd wrote:o problema é que envolve chamadas de métodos e tal. primitivos são calculados diretamente. eu particularmente gostaria de usar apenas os objetos (acho que ficaria mais padronizado). mas o desempenho teria que ser bastante bom
O C# já faz isso hoje. Você pode fazer coisas como:
...
Seria interessante que colocassem algo como inferência de tipos, mais ou menos como temos em Scala. Assim o tipo a ser retornado seria o tipo requerido, sendo chamado o método de conversão mais conveniente.
tipo uma conversão implícita? como fazem nas sobrecargas de operadores?
Parecido com isto. No caso de Scala pode não ser indicado o tipo, sendo este inferido a partir do tipo do dado que está sendo recebido:
Como em Java o tipo deve ser indicado ele poderia ser usado para escolher uma função de conversão apropriada do lado direito da expressão. Assim:
poderia ser escrito como:
|
|
|
|
Remove o "LIMIT 1". Isso limita a consulta a somente um registro, mesmo que existam vários.
[]'s
|
|
|
|
|
parabéns ao pessoal do guj pela primeira década de muitas
|
|
|
|
ViniGodoy wrote:
fuadksd wrote:o problema é que envolve chamadas de métodos e tal. primitivos são calculados diretamente. eu particularmente gostaria de usar apenas os objetos (acho que ficaria mais padronizado). mas o desempenho teria que ser bastante bom
O C# já faz isso hoje. Você pode fazer coisas como:
...
Seria interessante que colocassem algo como inferência de tipos, mais ou menos como temos em Scala. Assim o tipo a ser retornado seria o tipo requerido, sendo chamado o método de conversão mais conveniente.
|
|
|
|
|
Suporte a GPU feito pela própria Oracle?! Maravilha!
|
|
|
|
|
Muito interessante mesmo!
|
|
|
|