De volta para as aplicações Desktop

Assuntos Gerais
#21

[quote=x@ndy][quote=juliocbq][quote=x@ndy][quote=juliocbq][quote=Hebert Coelho][quote=x@ndy][quote=juliocbq]
Acho que o que ele quis dizer é que o cliente é desktop. Com um servidor e webservices para esse cliente consumir é uma boa alternativa(acho que é até melhor que usar um navegador).[/quote]
Pessoamente, eu não vejo porque! Se for usar webservices, o sistema seria remoto, o que cria os mesmos problemas de acesso via browser. Nesse caso, somente se os dados trafegados fossem encriptados. Ai sim faz sentido, mas não seria mais simples criar uma VPN e montar uma intranet?[/quote]Concordo com você, mas nem precisa de tanto… Um HTTPS já resolveria o problema de ataque do tipo man in the middle.

Eu creio que exista algum motivo por trás disso… Ou alguém está lucrando dinheiro por fora ou é alguém que teve uma má experiência em projetos http (geralmente com muito javascript), e aí tem essas opiniões radicais.

Honestamente o único motivo que eu vejo para um projeto desktop seria para quando o projeto necessita de muito recurso visual avançado: mapas 3d com diversas opções de interação com o usuário, ou coisas do tipo. [/quote]

Você consegue essa mesma funcionalidade com javascript. Os browsers suportam webgl. A vantagem da aplicação desktop é o software em si não depender de um servidor para funcionar pelo menos em modo offline. Em alguns casos é preferível fazer parte de um grande processamento no cliente e posteriormente enviar mastigado para o servidor. Existem dezenas de vantagens e motivos.[/quote]

Mas nesse caso, seria possivel fazer tudo o que você falou utilizando javascript. Nesse caso, desktop leva vantagem em termos de facilidade de programação, já que é um ambiente muito mais maduro para aplicações ricas! Desenvolver uma aplicação com os mesmos recursos, utilizando javascrip ou swing, por exemplo, swing levaria vantagem.
Existe a questão do acesso a API do SO, mas isso é exceção a regra.

Pessoalmente, eu acredito muito mais em uma aplicação hibrida do que fazer toda a apliacação para desktop, e eu programao para desktop. Por exemplo, na aplicação que estou trabalhando, é necessário que ela faça acesso a recursos do so, como uma porta serial. A aplicação então é híbrida, e estou usando applets para evitar problemas de atualização! Isso porque a parte que necessita de acesso ao SO é apenas uma pequena parcela do sistema e, por isso, não compensava perder todas as vantagens oferecidas por um sistema web e partir para um sistema desktop.[/quote]

Pensa assim: Você tem em seus 10 clientes arquivos de 1 gb para fazer upload. Isso porque seu sistema deve funcionar em modo offline em alguns períodos, ou porque o fluxo em um estacionmento de um shoping é grande e se a intranet cair essas estações devem saber como agir. Se essas estações não tiverem autonomia de preprocessar, trabalhar offline, o servidor não aguenta toda essa quantidade de trabalho.

É um caso onde o desktop é vantajoso.[/quote]

Mas ai é que tá, isso são situações especificas, o que não compensa desenvolver um sistema inteiro para desktop por que uma parte dele necessita dessa funcionalidade. Por isso falei da aplicação híbrida.[/quote]
Como uma parte? Vc não quer abrir um arquivo de 1gb num browser não? São casos e casos. Na maioria o hypertexto resolve, mas no processamento bruto tem que ser java mesmo, ou outra linguagem.

#22

Muito curioso isso, parabéns pelo relato fabioEM.

Se não houver necessidade dos módulos serem desktop, que mais tarde a empresa não reclame de ter poucos profissionais interessados no mercado.

Sobre browser, com os padrões e recursos atuais é mais difícil acontecer, mas mesmo se tivesse problemas daria no mesmo obrigar a instalar em cada máquina um determinado programa desktop ou obrigar a instalar um determinado browser.

Sobre dificuldade em manutenção, o mais certo seria reavaliar onde erraram e enxergar novos caminhos sem ir contra a maré. Ou o mundo inteiro está errando? Essa pergunta é muito importante antes de fazer mudanças radicais, basta procurar saber como outros trabalham, troca de experiência é muito importante.

#23

[quote=javaflex]Muito curioso isso, parabéns pelo relato fabioEM.

Se não houver necessidade dos módulos serem desktop, que mais tarde a empresa não reclame de ter poucos profissionais interessados no mercado.

Sobre browser, com os padrões e recursos atuais é mais difícil acontecer, mas mesmo se tivesse problemas daria no mesmo obrigar a instalar em cada máquina um determinado programa desktop ou obrigar a instalar um determinado browser.

Sobre dificuldade em manutenção, o mais certo seria reavaliar onde erraram e enxergar novos caminhos sem ir contra a maré. Ou o mundo inteiro está errando? Essa pergunta é muito importante antes de fazer mudanças radicais, basta procurar saber como outros trabalham, troca de experiência é muito importante.[/quote]

O problema é que tem coisa que o browser não faz com ler periféricos, etc… Aí ou você usa um applet ou escreve a aplicação como desktop. Eu prefiro a segunda.

#24

[quote=juliocbq][quote=javaflex]Muito curioso isso, parabéns pelo relato fabioEM.

Se não houver necessidade dos módulos serem desktop, que mais tarde a empresa não reclame de ter poucos profissionais interessados no mercado.

Sobre browser, com os padrões e recursos atuais é mais difícil acontecer, mas mesmo se tivesse problemas daria no mesmo obrigar a instalar em cada máquina um determinado programa desktop ou obrigar a instalar um determinado browser.

Sobre dificuldade em manutenção, o mais certo seria reavaliar onde erraram e enxergar novos caminhos sem ir contra a maré. Ou o mundo inteiro está errando? Essa pergunta é muito importante antes de fazer mudanças radicais, basta procurar saber como outros trabalham, troca de experiência é muito importante.[/quote]

O problema é que tem coisa que o browser não faz com ler periféricos, etc… Aí ou você usa um applet ou escreve a aplicação como desktop. Eu prefiro a segunda.[/quote]
Está certo, nem estou questionando quando realmente existe a necessidade que determinado módulo seja desktop, applet nem pensar, só em último caso. O problema é deixar de fazer módulos que seriam mais indicados ser web somente pelos motivos relatados pelo fabioEM, referente ao caso da empresa.

#25

[quote=juliocbq]
O problema é que tem coisa que o browser não faz com ler periféricos, etc… Aí ou você usa um applet ou escreve a aplicação como desktop. Eu prefiro a segunda.[/quote]

Sem duvida, a segunda. Mas mesmo assim voce nao precisa migrar a aplicação inteira para desktop, somente a parte que se comunica com periféricos.

Eu tambem achei muito estranha essa historia de migrar pra desktop. A tendencia com absoluta certeza não eh essa. Talvez seja algo bem específico em alguma parte também específica dos sistemas.

#26

[quote=juliocbq][quote=javaflex]Muito curioso isso, parabéns pelo relato fabioEM.

Se não houver necessidade dos módulos serem desktop, que mais tarde a empresa não reclame de ter poucos profissionais interessados no mercado.

Sobre browser, com os padrões e recursos atuais é mais difícil acontecer, mas mesmo se tivesse problemas daria no mesmo obrigar a instalar em cada máquina um determinado programa desktop ou obrigar a instalar um determinado browser.

Sobre dificuldade em manutenção, o mais certo seria reavaliar onde erraram e enxergar novos caminhos sem ir contra a maré. Ou o mundo inteiro está errando? Essa pergunta é muito importante antes de fazer mudanças radicais, basta procurar saber como outros trabalham, troca de experiência é muito importante.[/quote]

O problema é que tem coisa que o browser não faz com ler periféricos, etc… Aí ou você usa um applet ou escreve a aplicação como desktop. Eu prefiro a segunda.[/quote]

Onde trabalho, como Chefe de T.I, tenho aproximadamente 200 usuários com máquinas com Sistemas Operacionais dos mais diversificados possíveis. Por ser órgão público, a regra é aceitar a máquina que vier, pois toda compra se faz por licitação, e, nem sempre, vem o que vc pediu.
Para piorar as coisas, alguns sistemas em uso pelos servidores necessitam de versões diferentes do java. Então, vc imagina os vários problemas que venham a surgir desse ambiente misto de SO e navegadores!!
Já trabalhei em fábrica de software, outro inferno!!! Voce faz uma página usando html e javascript / jquery e quando vai ver não roda em todos os navegadores…
Ou, quando vc usa um framework java: gwt, jsf, um belo dia o navegador lança uma atualiação e la vai o seu código cliente para o espaço!!
Realmente, começo a entender essa tendência, se é que pode-se chamar assim, de algumas empresas optar pelo caminho hibrido: desktop no cliente e webserver-backend.
Afinal, uma aplicação desktop sempre será mais poderosa (No sentido de tirar o máximo proveito da máquina do usuário) do que uma desenvolvida no cliente em html-javascript.

#27

[quote=juliocbq][quote=x@ndy][quote=juliocbq][quote=x@ndy][quote=juliocbq][quote=Hebert Coelho][quote=x@ndy][quote=juliocbq]
Acho que o que ele quis dizer é que o cliente é desktop. Com um servidor e webservices para esse cliente consumir é uma boa alternativa(acho que é até melhor que usar um navegador).[/quote]
Pessoamente, eu não vejo porque! Se for usar webservices, o sistema seria remoto, o que cria os mesmos problemas de acesso via browser. Nesse caso, somente se os dados trafegados fossem encriptados. Ai sim faz sentido, mas não seria mais simples criar uma VPN e montar uma intranet?[/quote]Concordo com você, mas nem precisa de tanto… Um HTTPS já resolveria o problema de ataque do tipo man in the middle.

Eu creio que exista algum motivo por trás disso… Ou alguém está lucrando dinheiro por fora ou é alguém que teve uma má experiência em projetos http (geralmente com muito javascript), e aí tem essas opiniões radicais.

Honestamente o único motivo que eu vejo para um projeto desktop seria para quando o projeto necessita de muito recurso visual avançado: mapas 3d com diversas opções de interação com o usuário, ou coisas do tipo. [/quote]

Você consegue essa mesma funcionalidade com javascript. Os browsers suportam webgl. A vantagem da aplicação desktop é o software em si não depender de um servidor para funcionar pelo menos em modo offline. Em alguns casos é preferível fazer parte de um grande processamento no cliente e posteriormente enviar mastigado para o servidor. Existem dezenas de vantagens e motivos.[/quote]

Mas nesse caso, seria possivel fazer tudo o que você falou utilizando javascript. Nesse caso, desktop leva vantagem em termos de facilidade de programação, já que é um ambiente muito mais maduro para aplicações ricas! Desenvolver uma aplicação com os mesmos recursos, utilizando javascrip ou swing, por exemplo, swing levaria vantagem.
Existe a questão do acesso a API do SO, mas isso é exceção a regra.

Pessoalmente, eu acredito muito mais em uma aplicação hibrida do que fazer toda a apliacação para desktop, e eu programao para desktop. Por exemplo, na aplicação que estou trabalhando, é necessário que ela faça acesso a recursos do so, como uma porta serial. A aplicação então é híbrida, e estou usando applets para evitar problemas de atualização! Isso porque a parte que necessita de acesso ao SO é apenas uma pequena parcela do sistema e, por isso, não compensava perder todas as vantagens oferecidas por um sistema web e partir para um sistema desktop.[/quote]

Pensa assim: Você tem em seus 10 clientes arquivos de 1 gb para fazer upload. Isso porque seu sistema deve funcionar em modo offline em alguns períodos, ou porque o fluxo em um estacionmento de um shoping é grande e se a intranet cair essas estações devem saber como agir. Se essas estações não tiverem autonomia de preprocessar, trabalhar offline, o servidor não aguenta toda essa quantidade de trabalho.

É um caso onde o desktop é vantajoso.[/quote]

Mas ai é que tá, isso são situações especificas, o que não compensa desenvolver um sistema inteiro para desktop por que uma parte dele necessita dessa funcionalidade. Por isso falei da aplicação híbrida.[/quote]
Como uma parte? Vc não quer abrir um arquivo de 1gb num browser não? São casos e casos. Na maioria o hypertexto resolve, mas no processamento bruto tem que ser java mesmo, ou outra linguagem.[/quote]

Acho que você não entendeu ainda. Um sistema é composto de múltiplas partes. Uma aplicação desktop pode conter todo o sistema ou ser uma parte do sistema. Um exemplo, citando o caso que você falou do estacionamento! Existem diversas redes de estacionamento que operam vários locais. Essas empresas necessitam de um sistema para fazer a gestão do seu negócio, que envolve, além do controle dos estacionamento a gestão financeira e de pessoal da empresa.

O controle do estacionamento necessita de uma solução que independa da internet. Uma solução local, pois a emissão de um cupom ou o pagamento de estadia não podem depender de uma conexão com a internet e esse sistema necessita se comunicar com os diversos dispositivos, como cancelas, totens e impressoras. Nesse caso uma solução desktop se torna mas apropriada para isso.

Contudo, ainda falta o sistema para a gestão do restante do negócio, que é basicamente um ERP e um ERP é um sistema bem mais complexo do o software implementado para controle do estacionamento, pois, além de receber os dados dos softwares locais, instalados nos estacionamentos gerenciados, ele necessita fazer deste os pagamentos aos fornecedores a folha de pagamento.

Esse sistema pode ser implementado como uma solução desktop, mas qual a vantagem disso? Nenhuma! Vale mais a pena fazer uma solução web para essa parte da aplicação.

Isso é um sistema híbrido, no qual uma pequena parte é feita para o ambiente desktop e o resto para uma solução web.

O mesmo vale para o processamento de uma arquivo, como você falou, que pode ser feita de maneira local e os dados enviados para um servidor web, quando for necessário.

#28

[quote=fabioEM][quote=juliocbq][quote=javaflex]Muito curioso isso, parabéns pelo relato fabioEM.

Se não houver necessidade dos módulos serem desktop, que mais tarde a empresa não reclame de ter poucos profissionais interessados no mercado.

Sobre browser, com os padrões e recursos atuais é mais difícil acontecer, mas mesmo se tivesse problemas daria no mesmo obrigar a instalar em cada máquina um determinado programa desktop ou obrigar a instalar um determinado browser.

Sobre dificuldade em manutenção, o mais certo seria reavaliar onde erraram e enxergar novos caminhos sem ir contra a maré. Ou o mundo inteiro está errando? Essa pergunta é muito importante antes de fazer mudanças radicais, basta procurar saber como outros trabalham, troca de experiência é muito importante.[/quote]

O problema é que tem coisa que o browser não faz com ler periféricos, etc… Aí ou você usa um applet ou escreve a aplicação como desktop. Eu prefiro a segunda.[/quote]

Onde trabalho, como Chefe de T.I, tenho aproximadamente 200 usuários com máquinas com Sistemas Operacionais dos mais diversificados possíveis. Por ser órgão público, a regra é aceitar a máquina que vier, pois toda compra se faz por licitação, e, nem sempre, vem o que vc pediu.
Para piorar as coisas, alguns sistemas em uso pelos servidores necessitam de versões diferentes do java. Então, vc imagina os vários problemas que venham a surgir desse ambiente misto de SO e navegadores!!
Já trabalhei em fábrica de software, outro inferno!!! Voce faz uma página usando html e javascript / jquery e quando vai ver não roda em todos os navegadores…
Ou, quando vc usa um framework java: gwt, jsf, um belo dia o navegador lança uma atualiação e la vai o seu código cliente para o espaço!!
Realmente, começo a entender essa tendência, se é que pode-se chamar assim, de algumas empresas optar pelo caminho hibrido: desktop no cliente e webserver-backend.
Afinal, uma aplicação desktop sempre será mais poderosa (No sentido de tirar o máximo proveito da máquina do usuário) do que uma desenvolvida no cliente em html-javascript.[/quote]
O cenário é bem caótico então, hardware tudo bem ter que aceitar o que for, mais sistema operacional pelo menos cada gerência da empresa deveria ter um padrão, onde a infra instala uma imagem padrão com por exemplo o browser a ser usado entre outras coisas, pois o importante é só ter a licença. Mas enfim, é um caso complicado mesmo esse que falou.

Sobre GWT, JSF, etc, realmente pode ser um grande erro usar essas soluções baseadas em componente e geração de código client. As vezes o caminho que está errado usando essas tecnologias que provocam surpresas com pouco controle do client.

#29

[quote=fabioEM][quote=juliocbq][quote=javaflex]Muito curioso isso, parabéns pelo relato fabioEM.

Se não houver necessidade dos módulos serem desktop, que mais tarde a empresa não reclame de ter poucos profissionais interessados no mercado.

Sobre browser, com os padrões e recursos atuais é mais difícil acontecer, mas mesmo se tivesse problemas daria no mesmo obrigar a instalar em cada máquina um determinado programa desktop ou obrigar a instalar um determinado browser.

Sobre dificuldade em manutenção, o mais certo seria reavaliar onde erraram e enxergar novos caminhos sem ir contra a maré. Ou o mundo inteiro está errando? Essa pergunta é muito importante antes de fazer mudanças radicais, basta procurar saber como outros trabalham, troca de experiência é muito importante.[/quote]

O problema é que tem coisa que o browser não faz com ler periféricos, etc… Aí ou você usa um applet ou escreve a aplicação como desktop. Eu prefiro a segunda.[/quote]

Onde trabalho, como Chefe de T.I, tenho aproximadamente 200 usuários com máquinas com Sistemas Operacionais dos mais diversificados possíveis. Por ser órgão público, a regra é aceitar a máquina que vier, pois toda compra se faz por licitação, e, nem sempre, vem o que vc pediu.
Para piorar as coisas, alguns sistemas em uso pelos servidores necessitam de versões diferentes do java. Então, vc imagina os vários problemas que venham a surgir desse ambiente misto de SO e navegadores!!
Já trabalhei em fábrica de software, outro inferno!!! Voce faz uma página usando html e javascript / jquery e quando vai ver não roda em todos os navegadores…
Ou, quando vc usa um framework java: gwt, jsf, um belo dia o navegador lança uma atualiação e la vai o seu código cliente para o espaço!!
Realmente, começo a entender essa tendência, se é que pode-se chamar assim, de algumas empresas optar pelo caminho hibrido: desktop no cliente e webserver-backend.
Afinal, uma aplicação desktop sempre será mais poderosa (No sentido de tirar o máximo proveito da máquina do usuário) do que uma desenvolvida no cliente em html-javascript.[/quote]

O problema que você falou depende de como a solução foi implementada, e, na verdade, não é culpa do ambiente. Já tive os mesmos problemas com soluções desktop, aonde uma mudança de ambiente quebrava a aplicação. Na verdade, para quem trabalha a mais de 10 anos com TI, viu justamente o contrário. A procura por soluções web devido aos problemas ocasionadas por soluções desktop!

A busca deve se concentrar na melhoria dos sistemas, mudança de plataforma não resolve esse tipo de problema!

#30

[quote=javaflex][quote=fabioEM][quote=juliocbq][quote=javaflex]Muito curioso isso, parabéns pelo relato fabioEM.

Se não houver necessidade dos módulos serem desktop, que mais tarde a empresa não reclame de ter poucos profissionais interessados no mercado.

Sobre browser, com os padrões e recursos atuais é mais difícil acontecer, mas mesmo se tivesse problemas daria no mesmo obrigar a instalar em cada máquina um determinado programa desktop ou obrigar a instalar um determinado browser.

Sobre dificuldade em manutenção, o mais certo seria reavaliar onde erraram e enxergar novos caminhos sem ir contra a maré. Ou o mundo inteiro está errando? Essa pergunta é muito importante antes de fazer mudanças radicais, basta procurar saber como outros trabalham, troca de experiência é muito importante.[/quote]

O problema é que tem coisa que o browser não faz com ler periféricos, etc… Aí ou você usa um applet ou escreve a aplicação como desktop. Eu prefiro a segunda.[/quote]

Onde trabalho, como Chefe de T.I, tenho aproximadamente 200 usuários com máquinas com Sistemas Operacionais dos mais diversificados possíveis. Por ser órgão público, a regra é aceitar a máquina que vier, pois toda compra se faz por licitação, e, nem sempre, vem o que vc pediu.
Para piorar as coisas, alguns sistemas em uso pelos servidores necessitam de versões diferentes do java. Então, vc imagina os vários problemas que venham a surgir desse ambiente misto de SO e navegadores!!
Já trabalhei em fábrica de software, outro inferno!!! Voce faz uma página usando html e javascript / jquery e quando vai ver não roda em todos os navegadores…
Ou, quando vc usa um framework java: gwt, jsf, um belo dia o navegador lança uma atualiação e la vai o seu código cliente para o espaço!!
Realmente, começo a entender essa tendência, se é que pode-se chamar assim, de algumas empresas optar pelo caminho hibrido: desktop no cliente e webserver-backend.
Afinal, uma aplicação desktop sempre será mais poderosa (No sentido de tirar o máximo proveito da máquina do usuário) do que uma desenvolvida no cliente em html-javascript.[/quote]
O cenário é bem caótico então, hardware tudo bem ter que aceitar o que for, mais sistema operacional pelo menos cada gerência da empresa deveria ter um padrão, onde a infra instala uma imagem padrão com por exemplo o browser a ser usado entre outras coisas, pois o importante é só ter a licença. Mas enfim, é um caso complicado mesmo esse que falou.[/quote]
Justamente, até para se trabalhar com imagem que tb prefiro, além de um SO padrão, vc dever ter um hardware padrão, pois se não vai ter incompatibilidade entre os diferentes drivers e volta tudo ao caos de novo!!!

#31

[quote=x@ndy][quote=fabioEM][quote=juliocbq][quote=javaflex]Muito curioso isso, parabéns pelo relato fabioEM.

Se não houver necessidade dos módulos serem desktop, que mais tarde a empresa não reclame de ter poucos profissionais interessados no mercado.

Sobre browser, com os padrões e recursos atuais é mais difícil acontecer, mas mesmo se tivesse problemas daria no mesmo obrigar a instalar em cada máquina um determinado programa desktop ou obrigar a instalar um determinado browser.

Sobre dificuldade em manutenção, o mais certo seria reavaliar onde erraram e enxergar novos caminhos sem ir contra a maré. Ou o mundo inteiro está errando? Essa pergunta é muito importante antes de fazer mudanças radicais, basta procurar saber como outros trabalham, troca de experiência é muito importante.[/quote]

O problema é que tem coisa que o browser não faz com ler periféricos, etc… Aí ou você usa um applet ou escreve a aplicação como desktop. Eu prefiro a segunda.[/quote]

Onde trabalho, como Chefe de T.I, tenho aproximadamente 200 usuários com máquinas com Sistemas Operacionais dos mais diversificados possíveis. Por ser órgão público, a regra é aceitar a máquina que vier, pois toda compra se faz por licitação, e, nem sempre, vem o que vc pediu.
Para piorar as coisas, alguns sistemas em uso pelos servidores necessitam de versões diferentes do java. Então, vc imagina os vários problemas que venham a surgir desse ambiente misto de SO e navegadores!!
Já trabalhei em fábrica de software, outro inferno!!! Voce faz uma página usando html e javascript / jquery e quando vai ver não roda em todos os navegadores…
Ou, quando vc usa um framework java: gwt, jsf, um belo dia o navegador lança uma atualiação e la vai o seu código cliente para o espaço!!
Realmente, começo a entender essa tendência, se é que pode-se chamar assim, de algumas empresas optar pelo caminho hibrido: desktop no cliente e webserver-backend.
Afinal, uma aplicação desktop sempre será mais poderosa (No sentido de tirar o máximo proveito da máquina do usuário) do que uma desenvolvida no cliente em html-javascript.[/quote]

O problema que você falou depende de como a solução foi implementada, e, na verdade, não é culpa do ambiente. Já tive os mesmos problemas com soluções desktop, aonde uma mudança de ambiente quebrava a aplicação. Na verdade, para quem trabalha a mais de 10 anos com TI, viu justamente o contrário. A procura por soluções web devido aos problemas ocasionadas por soluções desktop!

A busca deve se concentrar na melhoria dos sistemas, mudança de plataforma não resolve esse tipo de problema![/quote]
Exatamente cara, mas sabe qual o problema? Neste caso a empresa só enxergou os problemas atuais e esqueceu dos problemas que aconteciam nos velhos tempos, isso é natural no ser humano. Fora isso, ir contra a maré é sempre arriscado, começa a perder apoio.

Existem vários caminhos dentro de um tipo de solução, as vezes a empresa ou gerência insiste em seguir um mesmo caminho e não busca avaliar outros.

#32

[quote=x@ndy][quote=juliocbq][quote=x@ndy][quote=juliocbq][quote=x@ndy][quote=juliocbq][quote=Hebert Coelho][quote=x@ndy][quote=juliocbq]
Acho que o que ele quis dizer é que o cliente é desktop. Com um servidor e webservices para esse cliente consumir é uma boa alternativa(acho que é até melhor que usar um navegador).[/quote]
Pessoamente, eu não vejo porque! Se for usar webservices, o sistema seria remoto, o que cria os mesmos problemas de acesso via browser. Nesse caso, somente se os dados trafegados fossem encriptados. Ai sim faz sentido, mas não seria mais simples criar uma VPN e montar uma intranet?[/quote]Concordo com você, mas nem precisa de tanto… Um HTTPS já resolveria o problema de ataque do tipo man in the middle.

Eu creio que exista algum motivo por trás disso… Ou alguém está lucrando dinheiro por fora ou é alguém que teve uma má experiência em projetos http (geralmente com muito javascript), e aí tem essas opiniões radicais.

Honestamente o único motivo que eu vejo para um projeto desktop seria para quando o projeto necessita de muito recurso visual avançado: mapas 3d com diversas opções de interação com o usuário, ou coisas do tipo. [/quote]

Você consegue essa mesma funcionalidade com javascript. Os browsers suportam webgl. A vantagem da aplicação desktop é o software em si não depender de um servidor para funcionar pelo menos em modo offline. Em alguns casos é preferível fazer parte de um grande processamento no cliente e posteriormente enviar mastigado para o servidor. Existem dezenas de vantagens e motivos.[/quote]

Mas nesse caso, seria possivel fazer tudo o que você falou utilizando javascript. Nesse caso, desktop leva vantagem em termos de facilidade de programação, já que é um ambiente muito mais maduro para aplicações ricas! Desenvolver uma aplicação com os mesmos recursos, utilizando javascrip ou swing, por exemplo, swing levaria vantagem.
Existe a questão do acesso a API do SO, mas isso é exceção a regra.

Pessoalmente, eu acredito muito mais em uma aplicação hibrida do que fazer toda a apliacação para desktop, e eu programao para desktop. Por exemplo, na aplicação que estou trabalhando, é necessário que ela faça acesso a recursos do so, como uma porta serial. A aplicação então é híbrida, e estou usando applets para evitar problemas de atualização! Isso porque a parte que necessita de acesso ao SO é apenas uma pequena parcela do sistema e, por isso, não compensava perder todas as vantagens oferecidas por um sistema web e partir para um sistema desktop.[/quote]

Pensa assim: Você tem em seus 10 clientes arquivos de 1 gb para fazer upload. Isso porque seu sistema deve funcionar em modo offline em alguns períodos, ou porque o fluxo em um estacionmento de um shoping é grande e se a intranet cair essas estações devem saber como agir. Se essas estações não tiverem autonomia de preprocessar, trabalhar offline, o servidor não aguenta toda essa quantidade de trabalho.

É um caso onde o desktop é vantajoso.[/quote]

Mas ai é que tá, isso são situações especificas, o que não compensa desenvolver um sistema inteiro para desktop por que uma parte dele necessita dessa funcionalidade. Por isso falei da aplicação híbrida.[/quote]
Como uma parte? Vc não quer abrir um arquivo de 1gb num browser não? São casos e casos. Na maioria o hypertexto resolve, mas no processamento bruto tem que ser java mesmo, ou outra linguagem.[/quote]

Acho que você não entendeu ainda. Um sistema é composto de múltiplas partes. Uma aplicação desktop pode conter todo o sistema ou ser uma parte do sistema. Um exemplo, citando o caso que você falou do estacionamento! Existem diversas redes de estacionamento que operam vários locais. Essas empresas necessitam de um sistema para fazer a gestão do seu negócio, que envolve, além do controle dos estacionamento a gestão financeira e de pessoal da empresa.

O controle do estacionamento necessita de uma solução que independa da internet. Uma solução local, pois a emissão de um cupom ou o pagamento de estadia não podem depender de uma conexão com a internet e esse sistema necessita se comunicar com os diversos dispositivos, como cancelas, totens e impressoras. Nesse caso uma solução desktop se torna mas apropriada para isso.

Contudo, ainda falta o sistema para a gestão do restante do negócio, que é basicamente um ERP e um ERP é um sistema bem mais complexo do o software implementado para controle do estacionamento, pois, além de receber os dados dos softwares locais, instalados nos estacionamentos gerenciados, ele necessita fazer deste os pagamentos aos fornecedores a folha de pagamento.

Esse sistema pode ser implementado como uma solução desktop, mas qual a vantagem disso? Nenhuma! Vale mais a pena fazer uma solução web para essa parte da aplicação.

Isso é um sistema híbrido, no qual uma pequena parte é feita para o ambiente desktop e o resto para uma solução web.

O mesmo vale para o processamento de uma arquivo, como você falou, que pode ser feita de maneira local e os dados enviados para um servidor web, quando for necessário.[/quote]

Isso tudo eu sei x@andy. Inclusive o sistema que controla toda a casa do BBB teve minha mão desde a arquitetura ao desenvolvimento(escrevendo mesmo).

O dono do tópico já especificou que é um sistema web, e para ser web não precisa de “hypertexto literalmente”. Eu estou dizendo que você pode ter um cliente desktop para resolver o problema e um servidor ejb centralizando tudo. Não precisa de página web e browser(sendo ele próprio também uma solução desktop).

Hypertexto é bom quando tudo e todo o processamento está no servidor. O que o google faz é servir apenas interfaces. Quando isso não é suficiente ele aumenta a autonomia do browser com plugins.

Sobre o ERP que você comentou, ele acaba sendo bem mais simples do que a automação do estacionamento, porque esse exige engenharia elétrica, da computação e engenharia mecânica(como custo, mão de obra, etc…).

Tem um ditado budista:
Pense e faça tudo o mais simples possível.

#33

[quote=juliocbq]
Sobre o ERP que você comentou, ele acaba sendo bem mais simples do que a automação do estacionamento, porque esse exige engenharia elétrica, da computação e engenharia mecânica(como custo, mão de obra, etc…).[/quote]

Na verdade não! Já fiz muito isso e o ERP é muito mais complexo, pois o sistema utiliza algo que já está pronto! Você associou a complexida do desenvolvimento de um software para controle de estacionamento com a infraestrutura necessária para o controle do mesmo. Da forma que você colocou eu posso dizer que para desenvolver um ERP eu necessito de administradores, contadores, advogados, engenheiros da computatação, engenheiros eletrônicos, analistas e programadores.

Você associou a infrestrutura com desenvolvimento de software. Já trabalhei muito com automação industrial, com máquinas que custavam milhares de dólares, porém o custo de desnvolvimento do software para automação do processo, que interligava esse equipamento ao resto de uma linha de produção, não não chegava as vezes a um 1° do valor do equipamento utilizado.

[quote=juliocbq]Tem um ditado budista:
Pense e faça tudo o mais simples possível. [/quote]

Isso eu concordo com você. Os problemas encontrados, seja em soluções web e desktop, são devidos a complexidade desnecessárias utilizadas no desenvolvimento da aplicação! O programador não sabe pensar de maneira simples e busca sempre a solução que ele considera mais arrojada, porém isso pode criar uma série de problemas futuros.

A regra de pareto de também se aplica ao desenvolvimento de software, pois 80% das funcionalidades de um programa equivalem a 20% do código! Ou seja, 20% das funcionalidades representam 80% do trabalho de manutenção e evolução. Ai vem a pergunta, isso realmente é necessário? Qual a melhor maneira de implementar isso, de maneira que diminua e facilite a evolução do sistema.

Já tive diversos problemas com aplicações desktop devido a ambientes diferentes justamente devido a pequenas funcionalidades que uma aplicação deveria suportar, mesmo que funcionalidade não fosse utilizada naquela ambiente.

Nessa época me lembro que houve uma busca pelas soluções web, devido aos problemas encontrados nas soluções desktops. Agora vejo o contrário e isso me parece um círculo vicioso. Na verdade o problema não está no modelo da solução e sim na implementação da solução.

Eu acredito que soluções devem ser feitas da maneira mais simples, e, muitas vezes, isso exige que seja utilizada diversas plataformas e linguagens para desenvolvimento de uma aplicação e isso acaba sendo melhor do que unificar a solução em uma única plataforma.

#34

[quote=javaflex]
Exatamente cara, mas sabe qual o problema? Neste caso a empresa só enxergou os problemas atuais e esqueceu dos problemas que aconteciam nos velhos tempos, isso é natural no ser humano. Fora isso, ir contra a maré é sempre arriscado, começa a perder apoio.

Existem vários caminhos dentro de um tipo de solução, as vezes a empresa ou gerência insiste em seguir um mesmo caminho e não busca avaliar outros.[/quote]

Sim, mas ai entra-se em um circulo vicioso. Na verdade é necessário uma ruptura na cultura da empresa! Pessoalmente eu não acredito nessa “estória de remar contra a maré”. Se fosse assim não haveria hoje em dia scrum, xp, etc. O problema é como apresentar e convencer a pessoa que ela este não é o caminho certo.

#35

[quote=x@ndy][quote=juliocbq]
Sobre o ERP que você comentou, ele acaba sendo bem mais simples do que a automação do estacionamento, porque esse exige engenharia elétrica, da computação e engenharia mecânica(como custo, mão de obra, etc…).[/quote]

Na verdade não! Já fiz muito isso e o ERP é muito mais complexo, pois o sistema utiliza algo que já está pronto! Você associou a complexida do desenvolvimento de um software para controle de estacionamento com a infraestrutura necessária para o controle do mesmo. Da forma que você colocou eu posso dizer que para desenvolver um ERP eu necessito de administradores, contadores, advogados, engenheiros da computatação, engenheiros eletrônicos, analistas e programadores.

Você associou a infrestrutura com desenvolvimento de software. Já trabalhei muito com automação industrial, com máquinas que custavam milhares de dólares, porém o custo de desnvolvimento do software para automação do processo, que interligava esse equipamento ao resto de uma linha de produção, não não chegava as vezes a um 1° do valor do equipamento utilizado.

[quote=juliocbq]Tem um ditado budista:
Pense e faça tudo o mais simples possível. [/quote]

Isso eu concordo com você. Os problemas encontrados, seja em soluções web e desktop, são devidos a complexidade desnecessárias utilizadas no desenvolvimento da aplicação! O programador não sabe pensar de maneira simples e busca sempre a solução que ele considera mais arrojada, porém isso pode criar uma série de problemas futuros.

A regra de pareto de também se aplica ao desenvolvimento de software, pois 80% das funcionalidades de um programa equivalem a 20% do código! Ou seja, 20% das funcionalidades representam 80% do trabalho de manutenção e evolução. Ai vem a pergunta, isso realmente é necessário? Qual a melhor maneira de implementar isso, de maneira que diminua e facilite a evolução do sistema.

Já tive diversos problemas com aplicações desktop devido a ambientes diferentes justamente devido a pequenas funcionalidades que uma aplicação deveria suportar, mesmo que funcionalidade não fosse utilizada naquela ambiente.

Nessa época me lembro que houve uma busca pelas soluções web, devido aos problemas encontrados nas soluções desktops. Agora vejo o contrário e isso me parece um círculo vicioso. Na verdade o problema não está no modelo da solução e sim na implementação da solução.

Eu acredito que soluções devem ser feitas da maneira mais simples, e, muitas vezes, isso exige que seja utilizada diversas plataformas e linguagens para desenvolvimento de uma aplicação e isso acaba sendo melhor do que unificar a solução em uma única plataforma.[/quote]

Que infra estrutura? É tudo parte de um mesmo projeto e a empresa é quem arca com tudo aqui onde trabalho(software + hardware). Se onde você trabalhou terceirizam hardware aqui nós o fabricamos(desde câmeras, cancelas, conversores, totens, etc…) e toda a solução é implantada(desde a parte mecânica ao alto nível de software(de alto nível)).

A parte de alto nível não dá 20% do valor de projeto das outras.

Uma coisa não tem nada a ver com outra. Se você oferece a solução para um shopping, ela precisa implementar clientes autônomos para não deixar a bola cair se a intranet dela parar, senão vai um milhão de prejuízo em algumas horas.

Além de que o hardware deve ser projetado para parear o software. Eu não acredito em qualidade de sistemas com partes terceirizadas.

#36

[quote=juliocbq]
Que infra estrutura? É tudo parte de um mesmo projeto e a empresa é quem arca com tudo aqui onde trabalho(software + hardware). Se onde você trabalhou terceirizam hardware aqui nós o fabricamos(desde câmeras, cancelas, conversores, totens, etc…) e toda a solução é implantada(desde a parte mecânica ao alto nível de software(de alto nível)).

A parte de alto nível não dá 20% do valor de projeto das outras.

Cuidado ao generalizar.[/quote]

Quer dizer que vocês fabricam as câmeras utilizadas? E as impressoras também? Vocês também fabricam cada componente envolvido, desde um resistor é um microprocessador? As chapas de aço também são são fabricadas por vocês? Vocês também cortam, dobram e soldam cada toten? O leitor de código de barras também é fabricado por vocês?

Se for assim, blz, realmente vocês são uma empresa fantastica, mas, como falei, já trabalhei anos com automação industrial, E nós compravamos o hardware e realizavamos a montagem do equipamento necessário. Quando necessitavamos de um robô, para um equipamento, não faziamos do zero, iamos a um fabricante e compravamos um. O mesmo vale para câmeras, leitores de código de barra, impressoras, apertadeiras, barreiras óticas, etc. Compravamos todo o hardware e motavamos o equipamento necessário.

Na verdade a minha formação inicial é de engenheiro de controle e automação industrial, foi por meio dela que entrei para o mundo do desenvolvimento de software. Depois disso trabalhei nos mais diversos projetos, e posso afirmar, que a complexidade envolvida em um projeto de um ERP não se compara ao desenvolvimento de um software para controle de equipamentos de um estacionamento.

Mas digamos que vocês fabriquem cada peça, cada componente necessário. Qual o papel do software no projeto final? Para desenvolver o software é necessário que exista um eng. elétrico e mecânico? Qual o papel deles no projeto do software? Novamente você está associando ao projeto de um software a complexidade com o projeto do equipamento. O resultado final não é software mas o conjunto. O software faz parte do conjunto final, mas não é o produto final! Como disse, já trabalhei em projetos em que o custo de desenvolvimento de um software era apenas uma pequena fração do preço final do equipamento envolvido. O custo e complexidade do equipamento não quer dizer que o software necessariamente seja complexo!

#37

[quote=juliocbq]
Uma coisa não tem nada a ver com outra. Se você oferece a solução para um shopping, ela precisa implementar clientes autônomos para não deixar a bola cair se a intranet dela parar, senão vai um milhão de prejuízo em algumas horas.[/quote]

E quem disse que não? Aonde eu digo que não? Acho que você não leu o que eu coloquei!

Olha nunca vi isso na minha vida! Sempre o software se adaptou ao equipamento. Se fosse assim, como seria fácil trabalhar com os leitores de código de barras, CLPs, Células de Carga, etc. Eu escreveria meus próprios protocólos de comunicação e não teria que me preocupar em implementar um modbus, por exemplo!

#38

Olha nunca vi isso na minha vida! Sempre o software se adaptou ao equipamento. Se fosse assim, como seria fácil trabalhar com os leitores de código de barras, CLPs, Células de Carga, etc. Eu escreveria meus próprios protocólos de comunicação e não teria que me preocupar em implementar um modbus, por exemplo![/quote]+1
Após ler [quote=juliocbq]Além de que o hardware deve ser projetado para parear o software. Eu não acredito em qualidade de sistemas com partes terceirizadas.[/quote] eu só pensei uma coisa… Oi?!

#39

Olha nunca vi isso na minha vida! Sempre o software se adaptou ao equipamento. Se fosse assim, como seria fácil trabalhar com os leitores de código de barras, CLPs, Células de Carga, etc. Eu escreveria meus próprios protocólos de comunicação e não teria que me preocupar em implementar um modbus, por exemplo![/quote]+1
Após ler [quote=juliocbq]Além de que o hardware deve ser projetado para parear o software. Eu não acredito em qualidade de sistemas com partes terceirizadas.[/quote] eu só pensei uma coisa… Oi?![/quote]

Oi? Já viu hardware funcionar sem firmware?

#40

[quote=x@ndy][quote=juliocbq]

Olha nunca vi isso na minha vida! Sempre o software se adaptou ao equipamento. Se fosse assim, como seria fácil trabalhar com os leitores de código de barras, CLPs, Células de Carga, etc. Eu escreveria meus próprios protocólos de comunicação e não teria que me preocupar em implementar um modbus, por exemplo![/quote]
[/quote]
Você nunca viu isso porque nunca produziu hardware. Para você escrever seu protocolo de comunicação no mínimo precisa de um driver de rede no dispositivo e um serial embarcado novamente no mesmo dispositivo. Sem um firmware lá dentro servindo suas necessidades você não faria nada.