| Esta discussão foi arquivada. Não se pode acrescentar nenhum comentário. | | golap (Pontos:3, Interessante) |
| | | Tambem ja' andei 'a procura -- a unica coisa que vi foi o golap -- mas nunca andou para a frente...
"I triple guarantee you, there are no American soldiers in Baghdad.", Mohammed Saeed al-Sahaf, Iraqi Minister of Information
|
| | | | | Alguém conhece alguma solução OLAP para Unix/Linux gratuita? Pelo que eu sei os principais líderes são o SAS (business intelligence) e o Clementine, que além de serem caríssimos, desconheço se existe uma versão Unix, principalmente o SAS, uma vez que o Clementine está implementado em Java Sim, o SAS tem uma versão para Linux. O Essbase da Hyperion (lider de mercado) tb está portado para Linux. A Applix tb já chegou a ter, nao sei se mantém. Free/Open Source é q nao há mta coisa: tens o Lemur (C++, alpha) e o Mondrian (Java, versao 1.0 de Agosto passado) Cumprimentos Mario Valente
|
| | | | | Essbase da Hyperion.. agora gratuito é que és capaz de ter problemas. Ou estão demasiado alpha ou pré-alfa ou então são tão abertos a customização que fica mais barato (custo homem/hora) comprares uma solução comercial. Ah.. e ha as soluções Java que pesam e pesam e pesam e pesam.. (isto do java é uma opinião pessoal nao me crucifiquem já). Eu aconselhava a veres com atenção as ofertas comerciais e veres que se calhar vale a pena implementar mesmo suportando os custos. Acaba por ficar mais barato que uma solução totalmente open source mas nao testada que vais demorar mais tempo a limar arestas e a customizar a coisa que vai acabar por ficar mto mais caro. mas isto sao os meus dois centimos....
|
| | | | | | Também me parece que, por enquanto, pôr uma das soluções indicadas a fazer o que se quer, vai exigir uma grande quantidade de tempo ou não será possível. Quanto às soluções em Java, também concordo contigo excepto em relação a ser uma opinião pessoal, porque acho que é bastante objectivo que as aplicações pesam e não é pouco! Além disso, a interface gráfica é um pouco desagradável se for feita em AWT ou Swing, mas isso são pormenores :-) De qualquer maneira acho que actualmente o mais viável é ainda escolher uma boa solução comercial existente no mercado. Obrigado a todos pelas referências!
|
| | | | porque acho que é bastante objectivo que as aplicações pesam e não é pouco
Isso não é verdade, já foi. As versões mais recentes do JRE tiveram aumentos muito significativos de performance, tanto no arranque (um calcanhar de Aquiles tradicional do Java) como durante a execução (onde, devido aos melhoramentos na HotSpot VM, o Java consegue agora ser mais rápido do que -- alguns -- programas nativos depois de algum tempo de execução).
Além disso, a interface gráfica é um pouco desagradável se for feita em AWT ou Swing
Eu por acaso não acho o Metal assim tão mau mas este é apenas um theme. Se queres ter aplicações Swing com melhor aspecto podes usar o Looks para Swing (webstart demo). Penso que este pacote é o que é usado no software de IRS deste ano.
-- Carlos Rodrigues
|
| | | | Isso não é verdade, já foi. As versões mais recentes do JRE tiveram aumentos muito significativos de performance, tanto no arranque (um calcanhar de Aquiles tradicional do Java) como durante a execução (onde, devido aos melhoramentos na HotSpot VM, o Java consegue agora ser mais rápido do que -- alguns -- programas nativos depois de algum tempo de execução).
É verdade que houve melhorias notáveis na máquina virtual do Java mas, IMHO, a sua performance ainda está muito longe de aplicações implementadas em C/C++ ou outras linguagens compiladas, pelo que se puder escolher não opto pelo Java.
Eu por acaso não acho o Metal assim tão mau mas este é apenas um theme. Se queres ter aplicações Swing com melhor aspecto podes usar o Looks para Swing (webstart demo). Penso que este pacote é o que é usado no software de IRS deste ano.
Estou impressionado! Até hoje tinha apenas experimentado utilizar o "system" look & feel e não tinha nada a ver com isto...
Não é exactamente igual ao XP nativo mas é de grande qualidade.
|
| | | | a sua performance ainda está muito longe de aplicações implementadas em C/C++ ou outras linguagens compiladas, pelo que se puder escolher não opto pelo Java.
Como em tudo, isto depende:
- Se a aplicação tem um longo tempo de execução, se uma ligeira penalização de performance inicial é aceitável e não há constrangimentos de memória (não só do hardware onde o sistema vai correr mas também decorrentes do próprio tipo de aplicação) então o Java é uma boa opção, tão boa ou melhor quanto o C/C++ dado ser uma linguagem de mais alto nível (na verdade, as suas APIs).
- Se a aplicação tem um curto tempo de execução e a performance não é importante então o Java também pode ser uma boa opção mas temos outros "players" que podem até oferecer mais vantagens (Python, por exemplo).
- Se o tempo de execução é curto (ou a execução não é regular -- estava a esquecer-me deste pormenor) e a performance, ou o baixo consumo de memória, interessa então o Java perde claramente para o C/C++.
O que acontece é que muitas aplicações do lado do servidor caem no primeiro caso e muitas aplicações desktop caem no terceiro (ficando as aplicações de business no meio) e é por isso que o Java é popular no servidor e impopular no desktop. Mas se eu acredito que o Java é uma boa solução no primeiro e segundo casos, tambem concordo que não o é no terceiro.
-- Carlos Rodrigues
|
| | | | em relação ao primeiro ponto, é de notar que um JIT pode fazer melhores optimizações por dispor de informações do programa em execução, coisa impossível em C/C++. pelo que ouço, há casos onde a velocidade é muito semelhante.
---
Trolls, nem respondam porque não vos ouço.
Que Bush vos abençoe. |
| | | | O C++ pode dispor de RTTI, ou seja, "run time information" o que lhe permite obter informações sobre o programa em runtime. Isto também possível através de meta-programação, se bem que o compilador não sabe bem o que está a fazer, porque não há suporte na própria linguagem (no caso do C++)... O Qt é um exemplo da utilização de meta-programação.
|
| |
|
