| Autor |
Mensagem |
|
|
Eu tinha respondido com uma piadinha besta, mas acho que é mais interessante deixar algo um pouco mais construtivo. O Philip já disse lá atrás neste thread e o Ralph Johnson, ainda mais atrás (em 1997):
Ralph Johnson wrote:
I don't believe that [one-size-fits-all graphical languages] is the solution. Every domain potentially needs a different notation, though in fact there are families of notations so a single notation can often get reused.
Dizer que existe uma forma fácil e simples de fazer "qualquer" software é desprezar as complexidades inerentes ao domínio. Um framework capaz de gerar qualquer software deve ser tão complexo quanto o agrupamento da complexidade de todos os possíveis domínios.
[edit]
Me lembrei agora de um artigo, A Pattern Language for Developing Object-Oriented Frameworks, que julgo também ser pertinente neste contexto:
[/edit]
http://st-www.cs.uiuc.edu/~droberts/evolve.html
|
 |
|
|
marcelostanley,
Objetos distribuídos e interações cliente/servidor não são coisas mutuamente exclusivas. Aliás, muito pelo contrário. Uma aplicação baseada em objetos distribuídos é, em princípio, estruturada de forma conceitualmente semelhante a uma aplicação OO comum - uma coleção de objetos que se comunicam por meio de interfaces bem-definidas. A diferença é que esses objetos podem ou não residir em espaços de endereçamento distintos. Além disso, para preservar a sintaxe das chamadas locais, a comunicação com objetos remotos é tipicamente feita por meio de chamadas síncronas e bloqueantes. Quando um objeto chama um método em um outro objeto remoto, no entanto, você está essencialmente produzindo uma interação no estilo cliente/servidor. O conceito é antigo prá burro (início dos anos 90) e já passou por inúmeras transformações e bastante evolução.
Alguns exemplos de middleware para objetos distribuídos: implementações de CORBA, Java/RMI, DCOM e o ICE (meu favorito).
Abraços,
|
|
|
|
pic_mute,
Acho melhor você postar a parte do código que faz o update aqui. De qualquer forma, vou chutar o que pode estar dando errado aí: um erro bem comum é chamar o scrollRectToVisible no JScrollPane, quando o correto é chamá-lo no container contido (opa) no viewport.
Abraços,
|
|
|
|
jschuler,
Quem determina o tamanho do componente é o layout manager do container no qual ele foi inserido. Se você usar um BorderLayout, por exemplo, o JLabel não deve mostrar reticências até que o espaço do container pai se esgote (i.e., você vai obter o comportamento "dinâmico" que procura). Portanto, acho que a solução que você procura deve estar mais para o lado de escolher um layout manager adequado.
Se ainda assim você quiser saber o tamanho preferido do JLabel, no entanto, use:
Abraços,
|
|
|
|
Que tal usar scrollRectToVisible(component.getBounds(null)) quando alguém ganha foco?
Abraços,
|
|
|
|
Oi,
Se o jar tem uma classe principal (uma que contém o método main) descrita no manifesto, basta fazer:
Caso contrário, você terá que colocar o jar no classpath e especificar a classe com o main:
Abraços,
|
|
|
|
Eu nem vou colocar o que acho que poderia ser mais consistente na API, porque a lista seria muito longa. Além do mais, tenho a séria impressão de que é praticamente impossível manter a consistência em uma API tão grande. Não tenho muita esperança de vê-la mais simples nos próximos releases, afinal de contas, a entropia tende a aumentar... 
Dado o projeto em que estou trabalhando atualmente, acho que as três coisas que eu mais gostaria de ver na *linguagem* - aquelas que toda hora você pensa "hum, isso aqui seria beeem mais fácil se tivesse isto" - são:
 Traits;
closures (e nem estou falando de full closures, algo como CICE já estaria de bom tamanho para mim;
tuplas. Como eu sinto falta de tuplas.
Abraços,
Giuliano
|
|
|
|
Oi Patrícia,
Perguntinha básica: qual versão do JDK você está usando nesse NetBeans em que o negócio não dá certo? Olhe no log do NetBeans, deve ter algo assim lá:
Abraços,
Giuliano
|
|
|
|
O processo continua ridículo. A palavra é forte mas é isso mesmo, o processo para a pseudo-integração parece piada.
É claro também que um dia eles vão consertar, não dá pra ser assim pra sempre. O fato é. que anuncio foi feito em torno de algo que parece meio forçado, feito às pressas e mal integrado.
Veja também que essa informação foi encontrada em um post minúsculo do blog de alguém que trabalha na sun, e não é nada muito esclarecedor.
De qualquer forma, repito que a iniciativa é mesmo muito boa, mas continuo achando a crítica válida.
Se você já contribuiu com algum projeto open source grande (Ubuntu, Debian, Eclipse, etc.), sabe que eles são extremamente cautelosos com esse tipo de coisa - se a lincença não é compatível, eles não redistribuem.
Eu acho o workaround temporário válido e bastante útil - é um jeito que eles arrumaram de plugar algo incompatível (legalmente falando) no gerenciador de pacotes. E eu adoro poder usar o gerenciador de pacotes. 
Giuliano
|
|
|
|
Oi Viny,
VinyGodoy wrote:
Outro meio seria você recorrer ao cálculo numérico (cuidado, só a palavra calculo vai te levar a sites de calculo diferencial e integral).
Mas é de um bom livro de cálculo diferencial e integral mesmo que eu estou falando. Esses livros costumam cobrir de forma bastate didática tópicos como séries e expansões (além de uma infinidade de outros tópicos), que, IMHO, são fundamentais prá quem está procurando aprender a respeito de coisas desse tipo.
Claro que uma boa base em métodos numéricos também é importante - especialmente para quem vai implementar os algoritmos - mas não sei se é tão importante no caso dele.
Abraços,
|
|
|
|
Oi!
Acredito que o professor queira você *escreva* o algoritmo para o cálculo da raiz quadrada. x <- sqrt(y) não te dá algoritmo algum, vc está assumindo que o algoritmo já foi escrito.
Existem muitas formas de calcular aproximações para a raiz quadrada de um número. Recomendo um bom livro de cálculo.
Abraços,
|
|
|
|
Inversao de controle = principio de Hollywood = "don't call us, we'll call you".
Trata-se de uma caracteristica comum a diversos frameworks, vc coloca o componente la e o framework se encarrega de chama-lo (o principio eh compativel com a ideia de reuso de interacoes presentes nos frameworks - alias, eh peca necessaria).
Conforme disse o Philip, injecao de Dependencias usa Inversao de Controle. Concordo que eh confuso, especialmente porque um batalhao de gente usa o termo "inversao de controle" como referencia a "injecao de dependencias".
|
|
|
|
Alberto,
A idéia é conseguir o desacoplamento entre cliente e produto que a factory te dá, mas sem ter que inventar milhares de fábricas ou uma fábrica enorme com uma interface toda inchada.
Bem, na verdade a injeção de dependências vai um pouco mais longe - você não fica nem sequer acoplado à interface da fábrica. Isso é particularmente relevante em sistemas flexíveis, onde normalmente você quer limitar o acoplamento o máximo possível.
Além disso, é compatível com a idéia de que a implementação concreta deve ser mais um dado de configuração do que qualquer outra coisa.
|
|
|
|
otaviofs wrote:
Ele é realmente mais rápido no Windows, até porque ele usa as api's do próprio SO. Da mesma forma que o Epiphany também abre mais rápido.
Na verdade o IE abre mais rápido porque já está aberto. 
O Epiphany não, é leve mesmo. Aliás, enquanto não sair a próxima versão do Firefox, vou usando ele.
Abraços,
|
|
|
|
qmx wrote:Alguém pode me dizer uma coisa, pq todo thread tem que virar um flame apaixonado?
Isso tá quase parecendo SCO vs IBM!
Porque é esse, infelizmente, o principal efeito colateral dos trolls. Coloca todo mundo na defensiva e o negócio se desvirtua num bate-boca cujo único propósito é triunfar sobre o outro.
|
|
|
|