| Autor |
Mensagem |
|
|
Kenobi wrote:
Sinceramente acho que estão começando a exercer sim influência em tomadas de decisão da Sun, isso é pura especulação da minha parte, entretanto olhando para o modelo da empresa que está comprando a Sun, você pode imaginar que há uma ação entre executivos de como monetizar o portfólio da Sun.
Pode até ser que eles já estejam conversando sobre isso, mas em se tratando de empresas de tecnologia "ação entre executivos" por enquanto acho que é só isso mesmo, conversa.
|
 |
|
|
http://sec.gov/Archives/edgar/data/709519/000119312509107681/dprem14a.htm
Como pelo visto você gosta de tudo mastigadinho vou quebrar teu galho.
When do you expect the merger to be completed?
We expect the merger to be completed in the summer of 2009. However, the merger is subject to various closing conditions, including Sun stockholder and regulatory approvals, and it is possible that the failure to timely meet these closing conditions or other factors outside of our control could require us to complete the merger at a later time or not at all.
Não estou dizendo que a negociação vai dar pra trás, mas dizer que por causa de um press release a oracle passa a ditar ordens e ser responsável por tudo que a Sun faz é mostrar que voce não tem noção do tamanho das empresas envolvidas na negociação.
|
|
|
|
|
Ja vou tratar de aprender JavaFX!
|
|
|
|
Questão esclarecida aqui:
http://guj.com.br/posts/list/128648.java#693755
|
|
|
|
fabioEM wrote:blz cara, mas o que sugeres para diminuir o acoplamento e aumentar a coesão ?
Putz cara, nada de especial além da velha e boa OO.
fabioEM wrote:E insisto em achar que 3 Threads não afetam tanto o desempenho!!
Desempenho do que? do programador ? eu acho que quanto mais thread maior probabilidade de voce se ferrar. 
De qualquer forma sugiro que de uma olhada no código de outros pra ver como eles fazem. Se quiser me manda um email que te passo um joguinho que fiz algum tempo.
|
|
|
|
Thingol, porque nao linkar direto o blog da sun onde a questão é definitivamente esclarecida?
Once the team has ironed out all the kinks (and please, let them know if you find any !), it will be ready for primetime, and will be in JDK7, where it will be available for free, no strings, under the usual terms as part of the JDK.
http://blogs.sun.com/theplanetarium/entry/kicking_the_tires_free_on
|
|
|
|
|
Kenobi, o que te faz achar que a Oracle tem alguma influência nos anúncios recentes da Sun se o processo da aquisição nem foi concluído ainda?
|
|
|
|
|
Quem falou que você deve?
|
|
|
|
fabioEM wrote:Pois é, mas na verdade só teriam três processos não?uma da midlet, uma da classe responsável pelo desenho e por fim a do model.Acho que o impacto não seria tão crucial assim.Em geral, uma aplicação móvel j2me, constuma suportar pelo menos 10 processos sem problemas.Realmente o problema nasce quando vc quer diminuir o acoplamento e aumentar a coesão.Mas em fim, se tiver um sujestão diferente mas que continue dentro do mvc estou disposto a levar em consideração sim!!  .
Não estou falando de processos, estou falando de threads:
new Thread(this).start();
Não vejo necessidade para mais que uma thread. A thread principal do midlet assim como as threads responsáveis por receber eventos do teclado e de desenho não são disparadas programaticamente. (Até onde sei o método Graphics.repaint() é assíncrono portanto a thread que irá chamar paint() em cada um dos elementos do jogo será fornecida pelo ambiente de execução, e não pelo programador).
|
|
|
|
|
Acho que se voce pensar direitinho não há necessidade de disparar mais do que uma thread. Se isto acontecer esteja preparado para as implicacoes de se lidar com multiplas threads acessando recursos comuns.
|
|
|
|
|
Pela quantidade de citações sobre Repository neste fórum acredito que este seja o padrão mais utilizado por aqui. Será que alguém poderia fazer a gentileza de informar alguma literatura para que possa aprender mais sobre este padrão. As únicas que achei tratam do assunto no contexto de domain-driven design, mas por exemplo que raios é um Repositório/DAO?
|
|
|
|
ViniGodoy wrote:E onde isso elimina o MVC? O contexto gráfico é parte da camada de view.
Quem se desenha é o Widget, um objeto gráfico e, num sistema bem implementado, ele irá obter as informações de desenho da camada de modelo.
É uma arquitetura muito próxima da do Swing.
O é comum fazerem é deixar o método de desenho dentro da classe de negócio. Nesse caso sim, haveria problemas com o MVC. É uma abordagem comum pq geralmente não é necessário tanto desacoplamento em jogos, uma vez que se trata de um produto fechado. Mas jogos que suportam MODs não costumam a cometer esse "erro".
Nesse sentido de ter que suportar MODs, faz até sentido usar MVC porque há um esforço em abstrair ao máximo os aspectos visuais da parte core do jogo. Mas esse esta londe de ser o caso da maioria dos jogos, até um cadastro de funcionário tem mais probabilidade de ter que suportar "MODs" do que um jogo casual. Portanto não diria que é um erro implementar um elemento do jogo (que pertence ao core) dependendo do contexto gráfico (que teoricamente pertenceria a visão):
Um sistema bem implementado nem sempre é aquele que adere ao MVC, mas aquele que representa bem uma solução para o problema em questão. Neste caso foi decidido que o Graphics pertence ao model, e não a visão. O que me parece ser bastante razoável em se tratando de um jogo!
|
|
|
|
|
Márcio, parabéns pela sua iniciativa. Eu também acho a publicação dos vídeos seria algo muito valioso para a comunidade. Vamos ver como os organizadores vão conduzir essa questão daqui em diante.
|
|
|
|
Assim que toda rede social deveria começar, publicando protocolos abertos e abraçando à web!
|
|
|
|
|
Putz mais um tópico com toda essa lenga-lenga de Maker??
|
|
|
|