evefuji wrote:no sql server tem as sp who e who2. Basta rodar um desses dois comandos e ver a saída.

Sobre migrar, recomendo fazer da seguinte forma (já fiz algumas migrações, e provavelmente vou falar muita coisa aqui que você já sabe):

1. Antes de mais nada, estabeleça uma estratégia para organizar a ordem de criação dos módulos, de preferência, os módulos que você não tem no outro ERP primeiro.
2. Seguindo essa ordem, você só coloca em produção, em paralelo ao outro ERP, quando o módulo já estiver bem testado.
3. Estabeleça uma rotina de ETL do sistema novo para o sistema antigo, mas de forma que fique bem testado antes de colocar em produção, e em determinados horários do dia essa rotina "execute" o processo ETL e transfira a informação do novo para o antigo, criando um log de quantidade de linhas transformadas, quantidade de linhas lidas da origem e quantidade de linhas inseridas no destino para cada tabela/módulo/magnitude, ao final do dia sempre conferindo esses logs. Recomendo como ferramenta ETL gratuita o Kettle, uso bastante essa ferramenta e é muito boa. (procure sempre versões Stable, versões non-stable pode funcionar legal em uma máquina e ruim em outra com a mesma transformação dependendo da JVM, já tive problemas de em ambiente de testes funcionar perfeito e em produção mudar valores do nada)
4. Crie uma rotina para comparar os dados entre as bases de dados, por exemplo, relatórios agregados de somas de valores, contagens de registros, etc... E comparar esses resultados todos os dias, fazer um checklist de todas as variáveis do sistema e comparar os valores dado um instante temporal, sempre cogitando também que no sistema antigo pode não estar 100% (mas a chance de não estar 100% é pequena), portanto, se tiver algum dado estranho no sistema legado, converse com os administradores para entender bem se é assim mesmo ou se tem algo errado (já encontrei muitos erros em bases de dados legado, que o sistema não fazia a lógica de negócios direito, ou fazia incompleta).
5. Dependendo do tamanho do sistema, deixe pelo menos 1 ano rodando em paralelo, muitas características do negócio do cliente é sazonal, e muitos recursos são voltados para datas específicas.

ViniGodoy wrote:Eu estou no mercado desktop há mais de 10 anos e programo com freqüência nas 3 linguagens. Gosto muito das 3.
Além de moderador do GUJ, sou dono de uma comunidade no DevBrasil (C#) e participo do grupo cppbrasil.

Se você quer programar para desktop, provavelmente o Java é a pior alternativa das 3 que você citou.


O que você quer dizer com "o C++ tem uma abordagem injusta da orientação à objetos"? Injusta em que sentido?
Ele suporta tudo que o Java suporta: Polimorfismo, herança (inclusive herança múltipla).
Ele suporta encapsulamento, com melhores modificadores de acesso (e, inclusive, o acesso friend, que faz muita falta no Java).

O C++ não é uma linguagem procedural. Na verdade, ela implementa 3 paradigmas: procedural, o orientado a objetos e o genérico.
Na prática, os programas modernos em C++ utilizam pouco o paradigma procedural. Os dois últimos são os mais usados.
Quanto ao número de plataformas, creio que nenhuma supera o C++. Pegue uma biblioteca como a Qt (que é OO, por sinal), e você vai ver que sua aplicação vai rodar em praticamente qualquer lugar.
Finalmente, das 3 linguagens que você citou, o C++ é o único que dá garantias de tempo real, incluindo hard-real time (pode ser necessário em apps desktop, como as que trabalham com processamento de vídeo).

O C++ tem duas grandes desvantagens:
1. É uma linguagem difícil: pois não é uma linguagem gerenciada. E lidar com memória no braço é muito difícil (embora te dê muito controle).
2. É uma linguagem antiga: Muitas implementações não são tão legais nele, pois alguns conceitos nem sequer estavam maduros na época que eles foram implementados no C++. Há muitas más práticas que a linguagem criou por conta do legado também. Para programar com conforto em C++ é importantíssimo conhecer o que são boas práticas modernas e é importante não sair programando feito um maluco. Depois de entender a sintaxe da linguagem é fundamental pegar um livro como Effective C++ e ler de cabo à rabo (esse tipo de evolução é normal e com o tempo todas as linguagens começam a ter esse tipo de coisa. É o caso de "preferir StringBuilder no lugar de StringBuffer" no Java, ou ArrayList no lugar de Vector, só que o C++ é cheio de coisas como essa). Fique atento pois os últimos 20 anos de evolução do C++ estão na forma de se programar, não na linguagem em si (aliás, se vc não usa STL, boost, ou mesmo a QT, não programou em C++ ainda).


No caso de comparar Java e C#, eu diria que o Java peca em alguns requisitos básicos, que geralmente aparecem em aplicações desktop:
- Pouca ou nenhuma integração com o SO (nada de acessar registro, AD, etc.)
- Precária integração com hardware
- Péssimo suporte a gráficos, sons e multimídia em geral (esqueça jogos em Java).

Para os dois primeiros casos, o C# possui os unsafe methods, que são infinitamente mais fáceis, limpos e seguros do que usar JNI.
Para o último caso, você tem o XNA que, aliás, é suportado em 3 plataformas.

O C# realmente começou como uma cópia, em muitos casos mal feita, do Java. Mas hoje, o Java é que corre atrás do prejuízo. O C# já suporta coisas que o Java vem prometendo faz tempo, como as lambda expressions. E suporta mais coisas: extension methods, LINQ, partial classes, etc. Tem uma implementação mais inteligente dos generics, sobrecarga de operadores, entre outros recursos interessantes. É preciso reconhecer que os prejuízos que a Sun sofreu, associado ao período de venda e aquisição pela Oracle teve um impacto bastante negativo na evolução da linguagem, e a Oracle terá que correr muito se quiser alcançar novamente a MS (que por sinal, está fazendo um ótimo trabalho).


Coloque na mesa os critérios que são importantes para os tipos de aplicações que você quer desenvolver, e enumere o que as linguagens oferem para cobri-los. Pelo seu texto, o que mais parece é que você está preferindo o Java por gosto pessoal, e não por uma escolha técnica.

Marcos Tavares wrote:Olá EAugusto,

entendi... pelo que sei, o Android parece ser o futuro dos mobiles, correto?

abs.

ViniGodoy wrote:Possibilidade 1: Boost ASIO + Boost threads (sem interface gráfica)
http://www.boost.org/doc/libs/1_47_0/doc/html/boost_asio/tutorial.html
http://www.boost.org/doc/libs/1_47_0/doc/html/thread.html#thread.overview

Possibilidade 2: QT:
http://www.qtforum.org/article/9/qt-network-tutorial.html

ViniGodoy wrote:Há alguns anos atrás eu diria sem hesitação que sim, é aconselhavel. Porém, houve a estagnação do Swing, a perda de suporte do Java no Mac e hoje já não estou tão certo assim. Alguns projetos importantes, como o SwingX, foram descontinuados.
Não houve melhorias significatias no Java 2D nas últimas versões (e eu pensei que seria fortemente impulsionado pelo JavaFX, mas essa alternativa não se verificou).

Uma outra opção, seria usar o próprio JavaFX, mas ele também não apresentou a inserção de componentes de UI que torcíamos tanto.


Em paralelo, o concorrente, o C#, apareceu com um construtor visual limpo, rápido e fácil. O framework é bem menos complicado com o Swing, e o suporte ao LINQ permite criar models para tabelas e listas muito facilmente. E com o projeto mono, tem atingido tantas plataformas quanto o próprio Java. A possibilidade de escrever código unmanaged de maneira simples (bem diferente do JNI e JNA) ainda permite escrever ferramentas mais integradas ao SO, coisa que é comum em desktop.

E, se você precisar de um número realmente grande de plataformas, ou de performance, há excelentes alternativas em C++, como o Qt.


Hoje eu não escolheria rapidamente o Java sem pelo menos cogitar essas outras alternativas.

juliocbq wrote:

joyle wrote:

juliocbq wrote:em casa tenho um pc com gpu 9400. Ele fica legal com aceleração, mas ainda come muitos recursos. Ainda tem que polir bastante o fx. Mas isso é questão de tempo.

Ou seja, nem pensar em usar o FX2 em projetos sérios. Essa era uma grande dúvida minha. Eu até comecei a ficar um pouco empolgado com FX2, mas pelo visto, vai demorar um tempão para ficar bom para desenvolvimento de projetos sérios e enquanto isso não acontece... melhor utilizar o Netbeans Platform ou o Eclipse Platform.

eu já acho o contrário. Ficou bem robusto e fácil de usar. Em máquinas com gpu sua aplicação vai ter um desempenho alto.
O jfx não é uma tecnologia para ser usada apenas na web, ela vai trazer qualidade de software para a plataforma java em geral.