De volta para as aplicações Desktop

Nunca ouvi nada sobre isso. Pelo contrário… nuvem nuvem nuvem é oq eu ouço.

+1

Sempre ouvi falar o contrário disso. E isso pode ser facilmente constatado numa breve pesquisa de vagas para programador na grande SP.

+1

Há esta possibilidade sim, mas a razão não seria compatibilidade entre browsers, mesmo porque este é um problema hoje praticamente superado.

A principal razão pra voltar da web para o desktop seria acesso à aplicação.
Yeap: vocês leram certo. Pegar uma aplicação de fácil acesso e dificultar a coisa por questões de sigilo ou segurança. Já vi isto ser feito e quando você para pra pensar, faz lá algum sentido.

kicolobo:

Há esta possibilidade sim, mas a razão não seria compatibilidade entre browsers, mesmo porque este é um problema hoje praticamente superado.

A principal razão pra voltar da web para o desktop seria acesso à aplicação.
Yeap: vocês leram certo. Pegar uma aplicação de fácil acesso e dificultar a coisa por questões de sigilo ou segurança. Já vi isto ser feito e quando você para pra pensar, faz lá algum sentido.

Sério?
Putz, me lembro agora de uma série de furos em aplicações desktop. A primeira que me vem a cabeça era os arquivos ini, contendo a senha e o usuário do banco de dados. A segunda, é que esse usuário normalmente é master, podendo fazer qualquer alteração no banco de dados.

Me lembro que uma vez eu necessitava de acesso ao banco para fazer uma consulta e não tinha a permisão de acesso aquele banco, e o responsável não estava no setor no momento para permitir. O que eu fiz? Fui até uma maquina e abri o arquivo ini e obtive o acesso!

x@ndy:

kicolobo:

Há esta possibilidade sim, mas a razão não seria compatibilidade entre browsers, mesmo porque este é um problema hoje praticamente superado.

A principal razão pra voltar da web para o desktop seria acesso à aplicação.
Yeap: vocês leram certo. Pegar uma aplicação de fácil acesso e dificultar a coisa por questões de sigilo ou segurança. Já vi isto ser feito e quando você para pra pensar, faz lá algum sentido.

Sério?
Putz, me lembro agora de uma série de furos em aplicações desktop. A primeira que me vem a cabeça era os arquivos ini, contendo a senha e o usuário do banco de dados. A segunda, é que esse usuário normalmente é master, podendo fazer qualquer alteração no banco de dados.

Me lembro que uma vez eu necessitava de acesso ao banco para fazer uma consulta e não tinha a permisão de acesso aquele banco, e o responsável não estava no setor no momento para permitir. O que eu fiz? Fui até uma maquina e abri o arquivo ini e obtive o acesso!

Esta foi a justificativa que ouvi: dificultar acesso à aplicação.
Se for parar pra pensar, realmente faz lá algum sentido: de fato, se for desktop fica mais difícil descobrir via rede a existência da coisa.
No entanto o cara tem de tomar uma série de precauções para que a justificativa pela segurança não vire outro furo como você mencionou.
Já vi estas monstruosidades também. Tem coisa até pior: incluir senha no binário do executável por exemplo.
No entanto, se a coisa for BEM feita, e se a necessidade de segurança for REAL, a coisa começa a fazer mais sentido.

kicolobo:

x@ndy:

kicolobo:

Há esta possibilidade sim, mas a razão não seria compatibilidade entre browsers, mesmo porque este é um problema hoje praticamente superado.

A principal razão pra voltar da web para o desktop seria acesso à aplicação.
Yeap: vocês leram certo. Pegar uma aplicação de fácil acesso e dificultar a coisa por questões de sigilo ou segurança. Já vi isto ser feito e quando você para pra pensar, faz lá algum sentido.

Sério?
Putz, me lembro agora de uma série de furos em aplicações desktop. A primeira que me vem a cabeça era os arquivos ini, contendo a senha e o usuário do banco de dados. A segunda, é que esse usuário normalmente é master, podendo fazer qualquer alteração no banco de dados.

Me lembro que uma vez eu necessitava de acesso ao banco para fazer uma consulta e não tinha a permisão de acesso aquele banco, e o responsável não estava no setor no momento para permitir. O que eu fiz? Fui até uma maquina e abri o arquivo ini e obtive o acesso!

Esta foi a justificativa que ouvi: dificultar acesso à aplicação.
Se for parar pra pensar, realmente faz lá algum sentido: de fato, se for desktop fica mais difícil descobrir via rede a existência da coisa.
No entanto o cara tem de tomar uma série de precauções para que a justificativa pela segurança não vire outro furo como você mencionou.
Já vi estas monstruosidades também. Tem coisa até pior: incluir senha no binário do executável por exemplo.
No entanto, se a coisa for BEM feita, e se a necessidade de segurança for REAL, a coisa começa a fazer mais sentido.

Sim, mas nesse caso por que não uma aplicação em uma intranet? Pessoamente eu não consigo pensar em bom motivo para uma aplicação deskto para questão de segurança. A não ser que aplicação funcione com um sistema de segurança bloqueando keyloggers e afins.

x@ndy:

kicolobo:

x@ndy:

kicolobo:

Há esta possibilidade sim, mas a razão não seria compatibilidade entre browsers, mesmo porque este é um problema hoje praticamente superado.

A principal razão pra voltar da web para o desktop seria acesso à aplicação.
Yeap: vocês leram certo. Pegar uma aplicação de fácil acesso e dificultar a coisa por questões de sigilo ou segurança. Já vi isto ser feito e quando você para pra pensar, faz lá algum sentido.

Sério?
Putz, me lembro agora de uma série de furos em aplicações desktop. A primeira que me vem a cabeça era os arquivos ini, contendo a senha e o usuário do banco de dados. A segunda, é que esse usuário normalmente é master, podendo fazer qualquer alteração no banco de dados.

Me lembro que uma vez eu necessitava de acesso ao banco para fazer uma consulta e não tinha a permisão de acesso aquele banco, e o responsável não estava no setor no momento para permitir. O que eu fiz? Fui até uma maquina e abri o arquivo ini e obtive o acesso!

Esta foi a justificativa que ouvi: dificultar acesso à aplicação.
Se for parar pra pensar, realmente faz lá algum sentido: de fato, se for desktop fica mais difícil descobrir via rede a existência da coisa.
No entanto o cara tem de tomar uma série de precauções para que a justificativa pela segurança não vire outro furo como você mencionou.
Já vi estas monstruosidades também. Tem coisa até pior: incluir senha no binário do executável por exemplo.
No entanto, se a coisa for BEM feita, e se a necessidade de segurança for REAL, a coisa começa a fazer mais sentido.

Sim, mas nesse caso por que não uma aplicação em uma intranet? Pessoamente eu não consigo pensar em bom motivo para uma aplicação deskto para questão de segurança. A não ser que aplicação funcione com um sistema de segurança bloqueando keyloggers e afins.

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). Você tem a nuvem e o cliente desktop.

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).

x@ndy:

kicolobo:

x@ndy:

kicolobo:

Há esta possibilidade sim, mas a razão não seria compatibilidade entre browsers, mesmo porque este é um problema hoje praticamente superado.

A principal razão pra voltar da web para o desktop seria acesso à aplicação.
Yeap: vocês leram certo. Pegar uma aplicação de fácil acesso e dificultar a coisa por questões de sigilo ou segurança. Já vi isto ser feito e quando você para pra pensar, faz lá algum sentido.

Sério?
Putz, me lembro agora de uma série de furos em aplicações desktop. A primeira que me vem a cabeça era os arquivos ini, contendo a senha e o usuário do banco de dados. A segunda, é que esse usuário normalmente é master, podendo fazer qualquer alteração no banco de dados.

Me lembro que uma vez eu necessitava de acesso ao banco para fazer uma consulta e não tinha a permisão de acesso aquele banco, e o responsável não estava no setor no momento para permitir. O que eu fiz? Fui até uma maquina e abri o arquivo ini e obtive o acesso!

Esta foi a justificativa que ouvi: dificultar acesso à aplicação.
Se for parar pra pensar, realmente faz lá algum sentido: de fato, se for desktop fica mais difícil descobrir via rede a existência da coisa.
No entanto o cara tem de tomar uma série de precauções para que a justificativa pela segurança não vire outro furo como você mencionou.
Já vi estas monstruosidades também. Tem coisa até pior: incluir senha no binário do executável por exemplo.
No entanto, se a coisa for BEM feita, e se a necessidade de segurança for REAL, a coisa começa a fazer mais sentido.

Sim, mas nesse caso por que não uma aplicação em uma intranet? Pessoamente eu não consigo pensar em bom motivo para uma aplicação deskto para questão de segurança. A não ser que aplicação funcione com um sistema de segurança bloqueando keyloggers e afins.

Duas razões iniciais aparentes: desconfiança extrema e ignorância.
Mas depois que você vê algumas coisas muito sinistras ocorrerem você começa a entender perfeitamente o porquê.

x@ndy:

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).

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?

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.

kicolobo:

x@ndy:

Sim, mas nesse caso por que não uma aplicação em uma intranet? Pessoamente eu não consigo pensar em bom motivo para uma aplicação deskto para questão de segurança. A não ser que aplicação funcione com um sistema de segurança bloqueando keyloggers e afins.

Duas razões iniciais aparentes: desconfiança extrema e ignorância.
Mas depois que você vê algumas coisas muito sinistras ocorrerem você começa a entender perfeitamente o porquê.

Só por ignorância, já que isso não vai realmente resolver o problema e existe ações bem mais simples que poderiam faze-lo!

Hebert Coelho:

x@ndy:

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).

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?

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.

Concordo. Sou do ambiente desktop e agora que estou começando a ve aventurar pelo ambiente web. Na no primeiro projeto web que participei, tive que me reinventar, pois estava acostumado com uma série de recursos disponiveis no ambiente desktop e que seria inviavel fazer para web. Optei pela simplicidade, e descobri que 90% dos sistemas não necessitam de todos os recursos que o deskto oferece. É uma questão purament cultural! O sistema não perde em funcionalidade devido ao ambiente, perde em firula-las! Aplicações desktop, para mim somente para sistema que necessitem fazer chamadas a api do sistema operacional ou que necessite de recursos gráficos avançadados, como você colocou.

Hebert Coelho:

x@ndy:

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).

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?

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.

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.

juliocbq:

x@ndy:

kicolobo:

x@ndy:

kicolobo:

Há esta possibilidade sim, mas a razão não seria compatibilidade entre browsers, mesmo porque este é um problema hoje praticamente superado.

A principal razão pra voltar da web para o desktop seria acesso à aplicação.
Yeap: vocês leram certo. Pegar uma aplicação de fácil acesso e dificultar a coisa por questões de sigilo ou segurança. Já vi isto ser feito e quando você para pra pensar, faz lá algum sentido.

Sério?
Putz, me lembro agora de uma série de furos em aplicações desktop. A primeira que me vem a cabeça era os arquivos ini, contendo a senha e o usuário do banco de dados. A segunda, é que esse usuário normalmente é master, podendo fazer qualquer alteração no banco de dados.

Me lembro que uma vez eu necessitava de acesso ao banco para fazer uma consulta e não tinha a permisão de acesso aquele banco, e o responsável não estava no setor no momento para permitir. O que eu fiz? Fui até uma maquina e abri o arquivo ini e obtive o acesso!

Esta foi a justificativa que ouvi: dificultar acesso à aplicação.
Se for parar pra pensar, realmente faz lá algum sentido: de fato, se for desktop fica mais difícil descobrir via rede a existência da coisa.
No entanto o cara tem de tomar uma série de precauções para que a justificativa pela segurança não vire outro furo como você mencionou.
Já vi estas monstruosidades também. Tem coisa até pior: incluir
senha no binário do executável por exemplo.
No entanto, se a coisa for BEM feita, e se a necessidade de segurança for REAL, a coisa começa a fazer mais sentido.

Sim, mas nesse caso por que não uma aplicação em uma intranet? Pessoamente eu não consigo pensar em bom motivo para uma aplicação deskto para questão de segurança. A não ser que aplicação funcione com um sistema de segurança bloqueando keyloggers e afins.

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). Você tem a nuvem e o cliente desktop.

juliocbq:

Hebert Coelho:

x@ndy:

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).

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?

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.

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.

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.

x@ndy:

juliocbq:

Hebert Coelho:

x@ndy:

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).

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?

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.

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.

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.

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.

juliocbq:

x@ndy:

juliocbq:

Hebert Coelho:

x@ndy:

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).

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?

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.

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.

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.

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.

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.

x@ndy:

juliocbq:

x@ndy:

juliocbq:

Hebert Coelho:

x@ndy:

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).

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?

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.

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.

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.

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.

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.

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.

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.

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.

juliocbq:

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.

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.

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.

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.

juliocbq:

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.

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.

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.

juliocbq:

x@ndy:

juliocbq:

x@ndy:

juliocbq:

Hebert Coelho:

x@ndy:

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).

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?

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.

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.

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.

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.

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.

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.

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.

fabioEM:

juliocbq:

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.

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.

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.

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.

fabioEM:

juliocbq:

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.

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.

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.

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!

javaflex:

fabioEM:

juliocbq:

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.

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.

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.

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.

x@ndy:

fabioEM:

juliocbq:

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.

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.

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.

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!

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.

x@ndy:

juliocbq:

x@ndy:

juliocbq:

x@ndy:

juliocbq:

Hebert Coelho:

x@ndy:

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).

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?

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.

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.

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.

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.

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.

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.

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.

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.

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…).

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.

juliocbq:

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

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.

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.

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.

x@ndy:

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…).

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.

juliocbq:

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

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.

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.

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.

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!

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.

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!

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!+1
Após ler

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.

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!+1
Após ler

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.

Oi? Já viu hardware funcionar sem firmware?

x@ndy:

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!

juliocbq:

x@ndy:

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!

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.

Cara, tu não me conhece, então não faça suposições! Quando era piá, já brincava um monte com eletrônica, não fui fazer engenharia por que achava bonito, mas porque gostava. Brinquei bastante com microcontrolares para dizer que o que você está falando é besteira! Mesmo Firmwares se adaptando a necessidade do hardware. Quantas rotinas em assembly eu tive que escrever para economizar memória. Nunca vi um projeto de hardware priorizar o software, na verdade ele priorizava a funcionalidade e o custo final do produto. Participei de um projeto para medidores de energia elétrica no qual o programador do firmware tinha que se virar para atender as especificações com o hardware que tinha, ele literamente teve que tirar leite de pedra!

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!+1
Após ler

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.

Oi? Já viu hardware funcionar sem firmware?Desde que me entendo por pequeno gafanhoto em desenvolvimento, para mim o conceito de software != de firmaware… Nunca precisei me preocupar com isso até hoje, mesmo depois de 10 anos em desenvolvimento, em saber qual o hardware em que meu software rodaria…

x@ndy:

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.

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!

Eu conheço bem esse argumento.

Essa pergunta é idiota, mas vou te responder da maneira que me perguntou.

Aqui trabalhamos com, câmeras dvrs, totens, cancelas e desenvolvemos tudo isso com software dedicado.
Desenvolver resistores e impressoras = sarcasmo.

2) Na verdade a minha formação inicial é de engenheiro de controle e automação industrial…

3)
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!

O papel deles é fazer cada sensor e motror responderem corretamente aos comandos e eventos do firmware que eles mesmos desenvolvem.

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!

Novamente outro argumento sem validade. Se você trabalhou fazendo dessa maneira não quer dizer que outros tenham que fazer assim. O hardware é desenvolvido para se adaptar bem a um software em questão e vice versa. Se você compra hardware proprietário e desenvolve uma solução em cima sem um sdk ou biblioteca oficial é um hack, ou seja uma gambiarra.

x@ndy:

juliocbq:

x@ndy:

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!

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.

Cara, tu não me conhece, então não faça suposições! Quando era piá, já brincava um monte com eletrônica, não fui fazer engenharia por que achava bonito, mas porque gostava. Brinquei bastante com microcontrolares para dizer que o que você está falando é besteira! Mesmo Firmwares se adaptando a necessidade do hardware. Quantas rotinas em assembly eu tive que escrever para economizar memória. Nunca vi um projeto de hardware priorizar o software, na verdade ele priorizava a funcionalidade e o custo final do produto. Participei de um projeto para medidores de energia elétrica no qual o programador do firmware tinha que se virar para atender as especificações com o hardware que tinha, ele literamente teve que tirar leite de pedra!

Pois é, e você também não me conhece. E não é uma suposição, estou respondendo seus argumentos.

É nesse ponto que eu queria chegar. O projeto de hardware não prioriza um software em questão porque não existe software dedicado. A empresa desenvolvia somente hardware.

O que isso tem a ver com ter um software de alto nível dedicado a um hardware?

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!+1
Após ler

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.

Oi? Já viu hardware funcionar sem firmware?Desde que me entendo por pequeno gafanhoto em desenvolvimento, para mim o conceito de software != de firmaware… Nunca precisei me preocupar com isso até hoje, mesmo depois de 10 anos em desenvolvimento, em saber qual o hardware em que meu software rodaria…

Firmware também é software apesar de estar incluso no desenvolvimento do hardware.

Você pode pegar um modem gprs e criar uma solução em cima, mas como disse, sem um sdk ou uma biblioteca oficial isso é um simples hack. Nós desenvolvemos os dois para ter a certeza do funcionamento da solução final.

juliocbq:

Firmware também é software apesar de estar incluso no desenvolvimento do hardware.

Você pode pegar um modem gprs e criar uma solução em cima, mas como disse, sem um sdk ou uma biblioteca oficial isso é um simples hack. Nós desenvolvemos os dois para ter a certeza do funcionamento da solução final.

Não é qualquer um que após estudar java vai programar algum software específico de hardware…

Hebert Coelho:

Oi? Já viu hardware funcionar sem firmware?

Bem vindo ao meu mundo Herbert.
Há diversas situações nas quais isto ocorre, na realidade, no meu caso ocorre o tempo todo e, se você for parar pra pensar que agora temos uma avalanche de mobile, vai ser a regra, por mais que tentem normalizar as coisas por baixo da API.

kicolobo:

Bem vindo ao meu mundo Herbert.
Há diversas situações nas quais isto ocorre, na realidade, no meu caso ocorre o tempo todo e, se você for parar pra pensar que agora temos uma avalanche de mobile, vai ser a regra, por mais que tentem normalizar as coisas por baixo da API.

Infelizmente existem o xiitas que ñ percebem que existem coisas que são impossíveis de se tomar por regra…

Meu front end hoje é todo mobile e ainda assim não me preocupo com hardware. [=

Você colocou isso

Ai eu respondo isso:

[/quote]
Ai você responde para mim

Ai eu respondo

Ai você responde para mim

E em outro post,

juliocbq:

Como é engenheiro de automação você sabe que existe um firmware desenvolvido por engenheiros elétricos com base na especificão do hardware não? Um programa controlador de um micro responsável por todo o funcionamento de circuito de uma placa eletrônica por exemplo.
O papel deles é fazer cada sensor e motror responderem corretamente aos comandos e eventos do firmware que eles mesmos desenvolvem.

Moral da estória: Primeiro você diz que o hardware é desenvolvido conforme o software, em seguida diz que não é o software (de alto nível) que é desenvolvindo conforme o hardware e sim firmware que é desenvolvido. Porém em seguida você que o diz que o firmware não é desenvolvido conforme o hardware, como eu eu havia dito!

Você mesmo se contradisse! Me desculpe, mas assim não dá para ter qualquer discusão séria e construtiva contigo!

kicolobo:

Hebert Coelho:

Oi? Já viu hardware funcionar sem firmware?

Desde que me entendo por pequeno gafanhoto em desenvolvimento, para mim o conceito de software != de firmaware… Nunca precisei me preocupar com isso até hoje, mesmo depois de 10 anos em desenvolvimento, em saber qual o hardware em que meu software rodaria…

Bem vindo ao meu mundo Herbert.
Há diversas situações nas quais isto ocorre, na realidade, no meu caso ocorre o tempo todo e, se você for parar pra pensar que agora temos uma avalanche de mobile, vai ser a regra, por mais que tentem normalizar as coisas por baixo da API.[/quote]

Sim, mas você já viu o hardware se adptar ao software? Eu não! O mesmo vale para o desenvolvimento de firmwares, embora não seja especilista na aréa, nunca vi hardware ser construido para se adptar a um firmware especifico e tão pouco vir hardware ser construido para se adptar a um software especifico.

x@ndy:

Você colocou isso

Ai eu respondo isso:

Ai eu respondo

Ai você responde para mim

E em outro post,

juliocbq:

Como é engenheiro de automação você sabe que existe um firmware desenvolvido por engenheiros elétricos com base na especificão do hardware não? Um programa controlador de um micro responsável por todo o funcionamento de circuito de uma placa eletrônica por exemplo.
O papel deles é fazer cada sensor e motror responderem corretamente aos comandos e eventos do firmware que eles mesmos desenvolvem.

Moral da estória: Primeiro você diz que o hardware é desenvolvido conforme o software, em seguida diz que não é o software (de alto nível) que é desenvolvindo conforme o hardware e sim firmware que é desenvolvido. Porém em seguida você que o diz que o firmware não é desenvolvido conforme o hardware, como eu eu havia dito!

Você mesmo se contradisse! Me desculpe, mas assim não dá para ter qualquer discusão séria e construtiva contigo![/quote]

Não vejo onde me contradigo aí. Pra mim software e hardware tem que ser casado. Aliás normalmente é assim mesmo. Você usa um compilador para a plataforma x não é?

x@ndy:

kicolobo:

Hebert Coelho:

Oi? Já viu hardware funcionar sem firmware?

Desde que me entendo por pequeno gafanhoto em desenvolvimento, para mim o conceito de software != de firmaware… Nunca precisei me preocupar com isso até hoje, mesmo depois de 10 anos em desenvolvimento, em saber qual o hardware em que meu software rodaria…

Bem vindo ao meu mundo Herbert.
Há diversas situações nas quais isto ocorre, na realidade, no meu caso ocorre o tempo todo e, se você for parar pra pensar que agora temos uma avalanche de mobile, vai ser a regra, por mais que tentem normalizar as coisas por baixo da API.

Sim, mas você já viu o hardware se adptar ao software? Eu não! O mesmo vale para o desenvolvimento de firmwares, embora não seja especilista na aréa, nunca vi hardware ser construido para se adptar a um firmware especifico e tão pouco vir hardware ser construido para se adptar a um software especifico.[/quote]

Não se faça de desentendido. Sabe que me referi a software como solução de alto nível.
Firmware faz parte do desenvolvimento do hardware. Em questão estou dizendo que os dois devem ser feitos um pro outro.

O hardware é desenvolvido tendo-se em mente o tipo de software no qual vai funcionar em conjunto.

Tu se contradiz aqui!

NOVAMENTE EM MAÍSCULA, PARA DESTACAR:

juliocbq:

[color=red]ALÉM DE QUE O HARDWARE DEVE SER PROJETADO PARA PAREAR O SOFTWARE[/color]

Da onde isso! Nunca vi um hardware ser projeto para um software especifico! Isso não existe! UM COMPILADOR É PROJETADO CONFORME O HARDWARE E NÃO O HARDWARE É PROJETADO CONFORME O COMPILADOR. Por isso existe n compiladores para diferentes plataformas!

Hebert Coelho:

kicolobo:

Bem vindo ao meu mundo Herbert.
Há diversas situações nas quais isto ocorre, na realidade, no meu caso ocorre o tempo todo e, se você for parar pra pensar que agora temos uma avalanche de mobile, vai ser a regra, por mais que tentem normalizar as coisas por baixo da API.

Pois é, a casos e casos. Afirmar que isso é regra que eu acho errado.

Infelizmente existem o xiitas que ñ percebem que existem coisas que são impossíveis de se tomar por regra…

Meu front end hoje é todo mobile e ainda assim não me preocupo com hardware. [=

Hebert, nós não estamos sendo xiitas. Todo programa é específico de uma configuração de hardware, inclusive java. Quando usa um compilador, ele é específico de uma plataforma x, inclusive a jvm é.

Tu se contradiz aqui!

NOVAMENTE EM MAÍSCULA, PARA DESTACAR:

juliocbq:

[color=red]ALÉM DE QUE O HARDWARE DEVE SER PROJETADO PARA PAREAR O SOFTWARE[/color]

Da onde isso! Nunca vi um hardware ser projeto para um software especifico! Isso não existe! UM COMPILADOR É PROJETADO CONFORME O HARDWARE E NÃO O HARDWARE É PROJETADO CONFORME O COMPILADOR. Por isso existe n compiladores para diferentes plataformas!

Mas onde está a contradição?
Todo hardware é feito pra isso. Todo projeto de hardware foca o software que será usado para o seu funcionamento. Além do mais compilador citado por você nem é software de alto nível. Veja bem, um compilador é uma ferramenta de construção almejando um controlador e não uma placa impressa que controla níveis de tensão e consecutivamente relés para acionar motores ou portas.

Você é quem está se complicando.

juliocbq:

O hardware é desenvolvido tendo-se em mente o tipo de software no qual vai funcionar em conjunto.

Novamente, nunca vi isso, seja para software de alto nível, seja firmware! Nunca vi alguém projetar um equipamento pensando no software, sempre o software foi projetado conforme o equipamento. Nunca vi um eng. eletrônico projetar um circuito pensando se o software vai utilizado vai ser escrito na linguagem x, y, z, ou para plataforma ABC. O engenheiro se preocupa com a interface de comunicação do equipamento. Por isso existem uma série de protocólos de comunicação.

Se for assim, o desenvolvimento do software se torna muito, mas muito mais simples! Bem que eu queria isso!

Tu se contradiz aqui!

NOVAMENTE EM MAÍSCULA, PARA DESTACAR:

juliocbq:

[color=red]ALÉM DE QUE O HARDWARE DEVE SER PROJETADO PARA PAREAR O SOFTWARE[/color]

Da onde isso! Nunca vi um hardware ser projeto para um software especifico! Isso não existe! UM COMPILADOR É PROJETADO CONFORME O HARDWARE E NÃO O HARDWARE É PROJETADO CONFORME O COMPILADOR. Por isso existe n compiladores para diferentes plataformas!

Mas onde está a contradição?
Todo hardware é feito pra isso. Todo projeto de hardware foca o software que será usado para o seu funcionamento. Além do mais compilador citado por você nem é software de alto nível. Você quem está se complicando.

Primeiro, quem citou compilador foi você.

Segundo, sério mesmo? Todo o hardware é projetado pensando no software? Bom, então me passe ai uma lista de hardwares que foram projetados para um software de alto nível e o debate está encerrado!

x@ndy:

juliocbq:

O hardware é desenvolvido tendo-se em mente o tipo de software no qual vai funcionar em conjunto.

Novamente, nunca vi isso, seja para software de alto nível, seja firmware! Nunca vi alguém projetar um equipamento pensando no software, sempre o software foi projetado conforme o equipamento. Nunca vi um eng. eletrônico projetar um circuito pensando se o software vai utilizado vai ser escrito na linguagem x, y, z, ou para plataforma ABC. O engenheiro se preocupa com a interface de comunicação do equipamento. Por isso existem uma série de protocólos de comunicação.

Se for assim, o desenvolvimento do software se torna muito, mas muito mais simples! Bem que eu queria isso!

Toda empresa que desenvolve hardware faz isso x@andy. Por isso existem os drivers. Se não existissem aí sim você iria ver o que seria um inferno de desenvolvimento.

Quando você compra uma placa aceleradora você ganha os drivers. É pensando no seu software que as empresas desenvolvem tudo isso. Ou você acha que o driver é desenvolvido apenas para o hardware?

Tu se contradiz aqui!

NOVAMENTE EM MAÍSCULA, PARA DESTACAR:

juliocbq:

[color=red]ALÉM DE QUE O HARDWARE DEVE SER PROJETADO PARA PAREAR O SOFTWARE[/color]

Da onde isso! Nunca vi um hardware ser projeto para um software especifico! Isso não existe! UM COMPILADOR É PROJETADO CONFORME O HARDWARE E NÃO O HARDWARE É PROJETADO CONFORME O COMPILADOR. Por isso existe n compiladores para diferentes plataformas!

Mas onde está a contradição?
Todo hardware é feito pra isso. Todo projeto de hardware foca o software que será usado para o seu funcionamento. Além do mais compilador citado por você nem é software de alto nível. Você quem está se complicando.

Primeiro, quem citou compilador foi você.

Segundo, sério mesmo? Todo o hardware é projetado pensando no software? Bom, então me passe ai uma lista de hardwares que foram projetados para um software de alto nível e o debate está encerrado!

Que tal todos os periféricos do seu pc?
Por exemplo eu desenvolvo um leitor biométrico e passo os drivers ou um sdk para você desenvolver. Se eu não o fizesse, e não pensasse no software alheio como ficaria?

Tu se contradiz aqui!

NOVAMENTE EM MAÍSCULA, PARA DESTACAR:

juliocbq:

[color=red]ALÉM DE QUE O HARDWARE DEVE SER PROJETADO PARA PAREAR O SOFTWARE[/color]

Da onde isso! Nunca vi um hardware ser projeto para um software especifico! Isso não existe! UM COMPILADOR É PROJETADO CONFORME O HARDWARE E NÃO O HARDWARE É PROJETADO CONFORME O COMPILADOR. Por isso existe n compiladores para diferentes plataformas!

Mas onde está a contradição?
Todo hardware é feito pra isso. Todo projeto de hardware foca o software que será usado para o seu funcionamento. Além do mais compilador citado por você nem é software de alto nível. Você quem está se complicando.

Primeiro, quem citou compilador foi você.

Segundo, sério mesmo? Todo o hardware é projetado pensando no software? Bom, então me passe ai uma lista de hardwares que foram projetados para um software de alto nível e o debate está encerrado!

Que tal todos os periféricos do seu pc?

Isso só melhora! Você quer dizer quer dizer que o meu teclado foi feito pensando no Word, por exemplo? Da onde?

juliocbq:

x@ndy:

juliocbq:

O hardware é desenvolvido tendo-se em mente o tipo de software no qual vai funcionar em conjunto.

Novamente, nunca vi isso, seja para software de alto nível, seja firmware! Nunca vi alguém projetar um equipamento pensando no software, sempre o software foi projetado conforme o equipamento. Nunca vi um eng. eletrônico projetar um circuito pensando se o software vai utilizado vai ser escrito na linguagem x, y, z, ou para plataforma ABC. O engenheiro se preocupa com a interface de comunicação do equipamento. Por isso existem uma série de protocólos de comunicação.

Se for assim, o desenvolvimento do software se torna muito, mas muito mais simples! Bem que eu queria isso!

Toda empresa que desenvolve hardware faz isso x@andy. Por isso existem os drivers. Se não existissem aí sim você iria ver o que seria um inferno de desenvolvimento.

Quando você compra uma placa aceleradora você ganha os drivers. É pensando no seu software que as empresas desenvolvem tudo isso. Ou você acha que o driver é desenvolvido apenas para o hardware?

Primeiro, desde quando drive é software de alto nivel?

Segundo, um drive é uma espécie de protocolo, abstraindo bastante seria como uma interface em java. A finalidade do drive é permitir uma interface comum do SO para diferentes dispositivos, ou seja, abstrair forma de comunicação, de forma que o SO não necessite saber como o dispositivo funciona.

Terceiro, o hardware não feito pensando no drive. O drive que feito pensando no hardware e no SO para qual se destina.

PS: Por acaso tu acha que porque uma empresa desenvolve hardware e drives que isso é uma coisa só, então o hardware é desenvolvido pensado no software no qual vai rodar, no caso, o SO?

Tu se contradiz aqui!

NOVAMENTE EM MAÍSCULA, PARA DESTACAR:

juliocbq:

[color=red]ALÉM DE QUE O HARDWARE DEVE SER PROJETADO PARA PAREAR O SOFTWARE[/color]

Da onde isso! Nunca vi um hardware ser projeto para um software especifico! Isso não existe! UM COMPILADOR É PROJETADO CONFORME O HARDWARE E NÃO O HARDWARE É PROJETADO CONFORME O COMPILADOR. Por isso existe n compiladores para diferentes plataformas!

Mas onde está a contradição?
Todo hardware é feito pra isso. Todo projeto de hardware foca o software que será usado para o seu funcionamento. Além do mais compilador citado por você nem é software de alto nível. Você quem está se complicando.

Primeiro, quem citou compilador foi você.

Segundo, sério mesmo? Todo o hardware é projetado pensando no software? Bom, então me passe ai uma lista de hardwares que foram projetados para um software de alto nível e o debate está encerrado!

Que tal todos os periféricos do seu pc?

Isso só melhora! Você quer dizer quer dizer que o meu teclado foi feito pensando no Word, por exemplo? Da onde?

Que tal a tecla com a logomarca do windows, ou as específicas do meu mac para lidar com dezenas de atalhos de software dele?
Vai negar que o teclado não foi pensado para windows ou mac? Caia na real.

Hebert Coelho:

kicolobo:

Bem vindo ao meu mundo Herbert.
Há diversas situações nas quais isto ocorre, na realidade, no meu caso ocorre o tempo todo e, se você for parar pra pensar que agora temos uma avalanche de mobile, vai ser a regra, por mais que tentem normalizar as coisas por baixo da API.

Pois é, a casos e casos. Afirmar que isso é regra que eu acho errado.

Infelizmente existem o xiitas que ñ percebem que existem coisas que são impossíveis de se tomar por regra…

Meu front end hoje é todo mobile e ainda assim não me preocupo com hardware. [=

Não se preocupa com o tamanho da tela do dispositivo, memória física ou virtual? Ou a api já se se preocupou para você.

Hebert, solução boa é o casamento das duas coisas. Se você tem hardware planejado e software planejado para a solução como todo, é melhor do que comprar um leitor biométrico e sair hackeando a esmo para se criar uma solução.

Tu se contradiz aqui!

NOVAMENTE EM MAÍSCULA, PARA DESTACAR:

juliocbq:

[color=red]ALÉM DE QUE O HARDWARE DEVE SER PROJETADO PARA PAREAR O SOFTWARE[/color]

Da onde isso! Nunca vi um hardware ser projeto para um software especifico! Isso não existe! UM COMPILADOR É PROJETADO CONFORME O HARDWARE E NÃO O HARDWARE É PROJETADO CONFORME O COMPILADOR. Por isso existe n compiladores para diferentes plataformas!

Mas onde está a contradição?
Todo hardware é feito pra isso. Todo projeto de hardware foca o software que será usado para o seu funcionamento. Além do mais compilador citado por você nem é software de alto nível. Você quem está se complicando.

Primeiro, quem citou compilador foi você.

Segundo, sério mesmo? Todo o hardware é projetado pensando no software? Bom, então me passe ai uma lista de hardwares que foram projetados para um software de alto nível e o debate está encerrado!

Que tal todos os periféricos do seu pc?

Isso só melhora! Você quer dizer quer dizer que o meu teclado foi feito pensando no Word, por exemplo? Da onde?

Que tal a tecla com a logomarca do windows, ou as específicas do meu mac para lidar com dezenas de atalhos de software dele?
Vai negar que o teclado não foi pensado para windows ou mac? Caia na real.

Uai, e desde quando SO é software de alto nível? Tu não falou que compilador não software de alto nível?

Mas que seja, não sei se tu sabe, a tecla do windows, também pode funcionar no Linux! Na verdade, eu mesmo já capturei essa tela em um sistema e desabilitei o que ela fazia, mas poderia ter feito qualquer coisa com ela!

Tu se contradiz aqui!

NOVAMENTE EM MAÍSCULA, PARA DESTACAR:

juliocbq:

[color=red]ALÉM DE QUE O HARDWARE DEVE SER PROJETADO PARA PAREAR O SOFTWARE[/color]

Da onde isso! Nunca vi um hardware ser projeto para um software especifico! Isso não existe! UM COMPILADOR É PROJETADO CONFORME O HARDWARE E NÃO O HARDWARE É PROJETADO CONFORME O COMPILADOR. Por isso existe n compiladores para diferentes plataformas!

Mas onde está a contradição?
Todo hardware é feito pra isso. Todo projeto de hardware foca o software que será usado para o seu funcionamento. Além do mais compilador citado por você nem é software de alto nível. Você quem está se complicando.

Primeiro, quem citou compilador foi você.

Segundo, sério mesmo? Todo o hardware é projetado pensando no software? Bom, então me passe ai uma lista de hardwares que foram projetados para um software de alto nível e o debate está encerrado!

Que tal todos os periféricos do seu pc?

Isso só melhora! Você quer dizer quer dizer que o meu teclado foi feito pensando no Word, por exemplo? Da onde?

Que tal a tecla com a logomarca do windows, ou as específicas do meu mac para lidar com dezenas de atalhos de software dele?
Vai negar que o teclado não foi pensado para windows ou mac? Caia na real.

Uai, e desde quando SO é software de alto nível? Tu não falou que compilador não software de alto nível?

Mas que seja, não sei se tu sabe, a tecla do windows, também pode funcionar no Linux! Na verdade, eu mesmo já capturei essa tela em um sistema e desabilitei o que ela fazia, mas poderia ter feito qualquer coisa com ela!

Você pode capturar qualquer tecla num kernel linux, basta você mapear. Só postei um hardware feito para um software em questão de alto nível(sim porque winforms não é kernel, ou vai me dizer que as aplicações de busca, barra de tarefas é software de baixo nível?)

vai dizer também que a tecla iniciar foi feita para rodar numa distro linux com kde? Se você instalar e não mexer no kernel ela nem funciona.
Cara, esse tipo de teclado é feito focando sistemas win x.

Tu se contradiz aqui!

NOVAMENTE EM MAÍSCULA, PARA DESTACAR:

juliocbq:

[color=red]ALÉM DE QUE O HARDWARE DEVE SER PROJETADO PARA PAREAR O SOFTWARE[/color]

Da onde isso! Nunca vi um hardware ser projeto para um software especifico! Isso não existe! UM COMPILADOR É PROJETADO CONFORME O HARDWARE E NÃO O HARDWARE É PROJETADO CONFORME O COMPILADOR. Por isso existe n compiladores para diferentes plataformas!

Mas onde está a contradição?
Todo hardware é feito pra isso. Todo projeto de hardware foca o software que será usado para o seu funcionamento. Além do mais compilador citado por você nem é software de alto nível. Você quem está se complicando.

Primeiro, quem citou compilador foi você.

Segundo, sério mesmo? Todo o hardware é projetado pensando no software? Bom, então me passe ai uma lista de hardwares que foram projetados para um software de alto nível e o debate está encerrado!

Que tal todos os periféricos do seu pc?

Isso só melhora! Você quer dizer quer dizer que o meu teclado foi feito pensando no Word, por exemplo? Da onde?

Que tal a tecla com a logomarca do windows, ou as específicas do meu mac para lidar com dezenas de atalhos de software dele?
Vai negar que o teclado não foi pensado para windows ou mac? Caia na real.

Uai, e desde quando SO é software de alto nível? Tu não falou que compilador não software de alto nível?

Mas que seja, não sei se tu sabe, a tecla do windows, também pode funcionar no Linux! Na verdade, eu mesmo já capturei essa tela em um sistema e desabilitei o que ela fazia, mas poderia ter feito qualquer coisa com ela!

Você pode capturar qualquer tecla num kernel linux, basta você mapear. Só postei um hardware feito para um software em questão de alto nível(sim porque winforms não é kernel, ou vai me dizer que as aplicações de busca, barra de tarefas é software de baixo nível?)

Barbaridade, só piora! Começa que eu fiz foi uma aplicação para windows e capturei usando a API, e desde quando, o Windows, um sistema operacional é software de alto nível? Creio que você queria dizer com software de alto nível que seja um software aplicativo!

juliocbq:

vai dizer também que a tecla iniciar foi feita para rodar numa distro linux com kde? Se você instalar e não mexer no kernel ela nem funciona.
Cara, esse tipo de teclado é feito focando sistemas win x.

Ah, quer dizer que para tecla funcionar no linux, eu tenho que recompilar o Kernel? Sério? DA ONDE?

x@ndy:

juliocbq:

vai dizer também que a tecla iniciar foi feita para rodar numa distro linux com kde? Se você instalar e não mexer no kernel ela nem funciona.
Cara, esse tipo de teclado é feito focando sistemas win x.

Ah, quer dizer que para tecla funcionar no linux, eu tenho que recompilar o Kernel? Sério? DA ONDE?

Não precisa recompilar, precisa mapear:

Ninguém falou em compilar alguma coisa.
Aliás nossa conversa é outra coisa.

juliocbq:

x@ndy:

juliocbq:

vai dizer também que a tecla iniciar foi feita para rodar numa distro linux com kde? Se você instalar e não mexer no kernel ela nem funciona.
Cara, esse tipo de teclado é feito focando sistemas win x.

Ah, quer dizer que para tecla funcionar no linux, eu tenho que recompilar o Kernel? Sério? DA ONDE?

Não precisa recompilar, precisa mapear:

Ninguém falou em compilar alguma coisa.
Aliás nossa conversa é outra coisa.

Engraçado que eu tenho uma distro do LDE e não fiz absolutamente nada para a tecla funcionar e também capturei ela no windows sem mexer no kernell.

PS: O que você postou é reconhecer uma tecla como outra, no exemplo ele que ele colocou lá a tecla Prior está sendo reconhecida como PgDown, e não é nada disso que eu falei!

x@ndy:

juliocbq:

x@ndy:

juliocbq:

vai dizer também que a tecla iniciar foi feita para rodar numa distro linux com kde? Se você instalar e não mexer no kernel ela nem funciona.
Cara, esse tipo de teclado é feito focando sistemas win x.

Ah, quer dizer que para tecla funcionar no linux, eu tenho que recompilar o Kernel? Sério? DA ONDE?

Não precisa recompilar, precisa mapear:

Ninguém falou em compilar alguma coisa.
Aliás nossa conversa é outra coisa.

Engraçado que eu tenho uma distro do LDE e não fiz absolutamente nada para a tecla funcionar e também capturei ela no windows sem mexer no kernell.

Já mapearam pra você. Inclusive o ubuntu faz isso com a tecla windows. Se eu colocar num mac posso mapear a maçã também. Mas esse teclado é feito for winx, não? E já faz décadas.

x@ndy:

PS: O que você postou é reconhecer uma tecla como outra, no exemplo ele que ele colocou lá a tecla Prior está sendo reconhecida como PgDown, e não é nada disso que eu falei!

Porque o mapa da tecla está trocado oras. se eu mexer pra adicionar o iniciar ou a maçã é a mesma coisa. Mas me diz aí, esse teclado é feito para windows ou não?

Tu se contradiz aqui!

NOVAMENTE EM MAÍSCULA, PARA DESTACAR:

juliocbq:

[color=red]ALÉM DE QUE O HARDWARE DEVE SER PROJETADO PARA PAREAR O SOFTWARE[/color]

Da onde isso! Nunca vi um hardware ser projeto para um software especifico! Isso não existe! UM COMPILADOR É PROJETADO CONFORME O HARDWARE E NÃO O HARDWARE É PROJETADO CONFORME O COMPILADOR. Por isso existe n compiladores para diferentes plataformas!

Mas onde está a contradição?
Todo hardware é feito pra isso. Todo projeto de hardware foca o software que será usado para o seu funcionamento. Além do mais compilador citado por você nem é software de alto nível. Você quem está se complicando.

Primeiro, quem citou compilador foi você.

Segundo, sério mesmo? Todo o hardware é projetado pensando no software? Bom, então me passe ai uma lista de hardwares que foram projetados para um software de alto nível e o debate está encerrado!

Que tal todos os periféricos do seu pc?

Isso só melhora! Você quer dizer quer dizer que o meu teclado foi feito pensando no Word, por exemplo? Da onde?

Que tal a tecla com a logomarca do windows, ou as específicas do meu mac para lidar com dezenas de atalhos de software dele?
Vai negar que o teclado não foi pensado para windows ou mac? Caia na real.

Uai, e desde quando SO é software de alto nível? Tu não falou que compilador não software de alto nível?

Mas que seja, não sei se tu sabe, a tecla do windows, também pode funcionar no Linux! Na verdade, eu mesmo já capturei essa tela em um sistema e desabilitei o que ela fazia, mas poderia ter feito qualquer coisa com ela!

Você pode capturar qualquer tecla num kernel linux, basta você mapear. Só postei um hardware feito para um software em questão de alto nível(sim porque winforms não é kernel, ou vai me dizer que as aplicações de busca, barra de tarefas é software de baixo nível?)

Barbaridade, só piora! Começa que eu fiz foi uma aplicação para windows e capturei usando a API, e desde quando, o Windows, um sistema operacional é software de alto nível? Creio que você queria dizer com software de alto nível que seja um software aplicativo!

Barbaridade é o que você fala. Desde quando a barra de tarefas é o sistema operacional?
Pra você é?

juliocbq:

x@ndy:

PS: O que você postou é reconhecer uma tecla como outra, no exemplo ele que ele colocou lá a tecla Prior está sendo reconhecida como PgDown, e não é nada disso que eu falei!

Porque o mapa da tecla está trocado oras. se eu mexer pra adicionar o iniciar ou a maçã é a mesma coisa. Mas me diz aí, esse teclado é feito para windows ou não?

Sim, é feito para windows, mas não só pode ser usado com Windows. Agora me poste ai as funcionalidades de todos os outros perífiéricos de um computador que são feitos só para windows, pois conforme tu disse.

juliocbq:

Que tal todos os periféricos do seu pc?

Depois tu editou e colocou

juliocbq:

Por exemplo eu desenvolvo um leitor biométrico e passo os drivers ou um sdk para você desenvolver. Se eu não o fizesse, e não pensasse no software alheio como ficaria?

Só que, driver, sdk, api, não quer dizer que o hardware foi projetado pensando no software! Pois o driver, sdk, api não é hardware, é software! Se você me fornece uma dll para acesso ao seu dispositivo isso não é hardware, é software!

Tu se contradiz aqui!

NOVAMENTE EM MAÍSCULA, PARA DESTACAR:

juliocbq:

[color=red]ALÉM DE QUE O HARDWARE DEVE SER PROJETADO PARA PAREAR O SOFTWARE[/color]

Da onde isso! Nunca vi um hardware ser projeto para um software especifico! Isso não existe! UM COMPILADOR É PROJETADO CONFORME O HARDWARE E NÃO O HARDWARE É PROJETADO CONFORME O COMPILADOR. Por isso existe n compiladores para diferentes plataformas!

Mas onde está a contradição?
Todo hardware é feito pra isso. Todo projeto de hardware foca o software que será usado para o seu funcionamento. Além do mais compilador citado por você nem é software de alto nível. Você quem está se complicando.

Primeiro, quem citou compilador foi você.

Segundo, sério mesmo? Todo o hardware é projetado pensando no software? Bom, então me passe ai uma lista de hardwares que foram projetados para um software de alto nível e o debate está encerrado!

Que tal todos os periféricos do seu pc?

Isso só melhora! Você quer dizer quer dizer que o meu teclado foi feito pensando no Word, por exemplo? Da onde?

Que tal a tecla com a logomarca do windows, ou as específicas do meu mac para lidar com dezenas de atalhos de software dele?
Vai negar que o teclado não foi pensado para windows ou mac? Caia na real.

Uai, e desde quando SO é software de alto nível? Tu não falou que compilador não software de alto nível?

Mas que seja, não sei se tu sabe, a tecla do windows, também pode funcionar no Linux! Na verdade, eu mesmo já capturei essa tela em um sistema e desabilitei o que ela fazia, mas poderia ter feito qualquer coisa com ela!

Você pode capturar qualquer tecla num kernel linux, basta você mapear. Só postei um hardware feito para um software em questão de alto nível(sim porque winforms não é kernel, ou vai me dizer que as aplicações de busca, barra de tarefas é software de baixo nível?)

Barbaridade, só piora! Começa que eu fiz foi uma aplicação para windows e capturei usando a API, e desde quando, o Windows, um sistema operacional é software de alto nível? Creio que você queria dizer com software de alto nível que seja um software aplicativo!

Barbaridade é o que você fala. Desde quando a barra de tarefas é o sistema operacional?
Pra você é?

Aonde eu disse isso? Surtou? O que eu disse é que usei a API do Windows para capturar a respectiva tecla. Ou tu acha que API do Windows é a barra de tarefas? Segundo, você não respondeu a pergunta, só postou besteira!

Tu se contradiz aqui!

NOVAMENTE EM MAÍSCULA, PARA DESTACAR:

juliocbq:

[color=red]ALÉM DE QUE O HARDWARE DEVE SER PROJETADO PARA PAREAR O SOFTWARE[/color]

Da onde isso! Nunca vi um hardware ser projeto para um software especifico! Isso não existe! UM COMPILADOR É PROJETADO CONFORME O HARDWARE E NÃO O HARDWARE É PROJETADO CONFORME O COMPILADOR. Por isso existe n compiladores para diferentes plataformas!

Mas onde está a contradição?
Todo hardware é feito pra isso. Todo projeto de hardware foca o software que será usado para o seu funcionamento. Além do mais compilador citado por você nem é software de alto nível. Você quem está se complicando.

Primeiro, quem citou compilador foi você.

Segundo, sério mesmo? Todo o hardware é projetado pensando no software? Bom, então me passe ai uma lista de hardwares que foram projetados para um software de alto nível e o debate está encerrado!

Que tal todos os periféricos do seu pc?

Isso só melhora! Você quer dizer quer dizer que o meu teclado foi feito pensando no Word, por exemplo? Da onde?

Que tal a tecla com a logomarca do windows, ou as específicas do meu mac para lidar com dezenas de atalhos de software dele?
Vai negar que o teclado não foi pensado para windows ou mac? Caia na real.

Uai, e desde quando SO é software de alto nível? Tu não falou que compilador não software de alto nível?

Mas que seja, não sei se tu sabe, a tecla do windows, também pode funcionar no Linux! Na verdade, eu mesmo já capturei essa tela em um sistema e desabilitei o que ela fazia, mas poderia ter feito qualquer coisa com ela!

Você pode capturar qualquer tecla num kernel linux, basta você mapear. Só postei um hardware feito para um software em questão de alto nível(sim porque winforms não é kernel, ou vai me dizer que as aplicações de busca, barra de tarefas é software de baixo nível?)

Barbaridade, só piora! Começa que eu fiz foi uma aplicação para windows e capturei usando a API, e desde quando, o Windows, um sistema operacional é software de alto nível? Creio que você queria dizer com software de alto nível que seja um software aplicativo!

Barbaridade é o que você fala. Desde quando a barra de tarefas é o sistema operacional?
Pra você é?

Aonde eu disse isso? Surtou? O que eu disse é que usei a API do Windows para capturar a respectiva tecla. Ou tu acha que API do Windows é a barra de tarefas? Segundo, você não respondeu a pergunta, só postou besteira!

A barra de tarefas é quem faz saltar o menu iniciar. Sobre as teclas, o mapa vem disponível nos drivers.
Posso te chamar de Rolando Lero?

Você não respondeu minha pergunta sobre o teclado for win.

x@ndy:

juliocbq:

x@ndy:

juliocbq:

O hardware é desenvolvido tendo-se em mente o tipo de software no qual vai funcionar em conjunto.

Novamente, nunca vi isso, seja para software de alto nível, seja firmware! Nunca vi alguém projetar um equipamento pensando no software, sempre o software foi projetado conforme o equipamento. Nunca vi um eng. eletrônico projetar um circuito pensando se o software vai utilizado vai ser escrito na linguagem x, y, z, ou para plataforma ABC. O engenheiro se preocupa com a interface de comunicação do equipamento. Por isso existem uma série de protocólos de comunicação.

Se for assim, o desenvolvimento do software se torna muito, mas muito mais simples! Bem que eu queria isso!

Toda empresa que desenvolve hardware faz isso x@andy. Por isso existem os drivers. Se não existissem aí sim você iria ver o que seria um inferno de desenvolvimento.

Quando você compra uma placa aceleradora você ganha os drivers. É pensando no seu software que as empresas desenvolvem tudo isso. Ou você acha que o driver é desenvolvido apenas para o hardware?

Primeiro, desde quando drive é software de alto nivel?

Segundo, um drive é uma espécie de protocolo, abstraindo bastante seria como uma interface em java. A finalidade do drive é permitir uma interface comum do SO para diferentes dispositivos, ou seja, abstrair forma de comunicação, de forma que o SO não necessite saber como o dispositivo funciona.

Terceiro, o hardware não feito pensando no drive. O drive que feito pensando no hardware e no SO para qual se destina.

PS: Por acaso tu acha que porque uma empresa desenvolve hardware e drives que isso é uma coisa só, então o hardware é desenvolvido pensado no software no qual vai rodar, no caso, o SO?

Quem disse isso?

Você está dizendo o óbvio para quem vive escrevendo módulos de kernel para linux.

Terceiro, o hardware não feito pensando no drive. O drive que feito pensando no hardware e no SO para qual se destina.

Ahh, e não é!? Conhece algum louco que desenvolve drivers para nvídia(tirando a comunidade opensource que faz engenharia reversa)?

Você precisa primeiro aprender a diferenciar o termo SO de kernel. São coisas diferentes

Primeiro eu já respondi, mas tu, pelo jeito não sabe ler. Segundo, nunca vi uma besteira maior. Tu quer dizer que para capturar uma tecla eu tenho que acessar os drives? Da onde? Cara não fala besteira, existe um negócio chamado API, que o Windows disponibiliza. Com ela eu posso capturar qualquer tecla pressionada.

Agora quem é o Rolando Lero?

x@ndy:

juliocbq:

A barra de tarefas é quem faz saltar o menu iniciar. Sobre as teclas, o mapa vem disponível nos drivers.
Posso te chamar de Rolando Lero?

Você não respondeu minha pergunta sobre o teclado for win.

Primeiro eu já respondi, mas tu, pelo jeito não sabe ler. Segundo, nunca vi uma besteira maior. Tu quer dizer que para capturar uma tecla eu tenho que acessar os drives? Da onde? Cara não fala besteira, existe um negócio chamado API, que o Windows disponibiliza. Com ela eu posso capturar qualquer tecla pressionada.

Agora quem é o Rolando Lero?

E a api busca de onde?

x@ndy:

juliocbq:

x@ndy:

PS: O que você postou é reconhecer uma tecla como outra, no exemplo ele que ele colocou lá a tecla Prior está sendo reconhecida como PgDown, e não é nada disso que eu falei!

Porque o mapa da tecla está trocado oras. se eu mexer pra adicionar o iniciar ou a maçã é a mesma coisa. Mas me diz aí, esse teclado é feito para windows ou não?

Sim, é feito para windows, mas não só pode ser usado com Windows. Agora me poste ai as funcionalidades de todos os outros perífiéricos de um computador que são feitos só para windows, pois conforme tu disse.

juliocbq:

Que tal todos os periféricos do seu pc?

Depois tu editou e colocou

Ok, então chegamos a conclusão que hardware almeja software.

Outro exemplo. O magic mouse da apple. Existem vários de sinais ali que o windows não reconhece sem os drivers dele.

Driver é projeto de hardware, sdk não porque é outra coisa, mas ele engloba os drivers que você precisa para desenvolver para um hardware em específico.

Ouça bem, nenhuma empresa diferente da detentora do hardware vai lhe servir drivers. Não tem como desenvolver isso tem o projeto do hardware(mais uma vez tirando a engenharia reversa da comunidade opensource da conversa) .

juliocbq:

x@ndy:

PS: Por acaso tu acha que porque uma empresa desenvolve hardware e drives que isso é uma coisa só, então o hardware é desenvolvido pensado no software no qual vai rodar, no caso, o SO?

Ahh, e não é!? Conhece algum louco que desenvolve drivers para nvídia(tirando a comunidade opensource que faz engenharia reversa)?

Quer dizer que uma empresa desenvolve uma hardware e um drive (software), e tudo isso é considerado hardware? Nossa, hardware + software = hardware! Sensacional, como eu sou estúpido! Realmente, eu sou muito idiota por não fazer essa associação, realmente tu tens razão! É tudo hardware, que sensacional! Só não entendo por que eles chamam isso de software! Deveriam chamar os drives de hardware também, mas são devem ser estúpidas que nem eu.

juliocbq:

x@ndy:

juliocbq:

A barra de tarefas é quem faz saltar o menu iniciar. Sobre as teclas, o mapa vem disponível nos drivers.
Posso te chamar de Rolando Lero?

Você não respondeu minha pergunta sobre o teclado for win.

Primeiro eu já respondi, mas tu, pelo jeito não sabe ler. Segundo, nunca vi uma besteira maior. Tu quer dizer que para capturar uma tecla eu tenho que acessar os drives? Da onde? Cara não fala besteira, existe um negócio chamado API, que o Windows disponibiliza. Com ela eu posso capturar qualquer tecla pressionada.

Agora quem é o Rolando Lero?

E a api busca de onde?

x@ndy:

juliocbq:

x@ndy:

PS: Por acaso tu acha que porque uma empresa desenvolve hardware e drives que isso é uma coisa só, então o hardware é desenvolvido pensado no software no qual vai rodar, no caso, o SO?

Ahh, e não é!? Conhece algum louco que desenvolve drivers para nvídia(tirando a comunidade opensource que faz engenharia reversa)?

Quer dizer que uma empresa desenvolve uma hardware e um drive (software), e tudo isso é considerado hardware? Nossa, hardware + software = hardware! Sensacional, como eu sou estúpido! Realmente, eu sou muito idiota por não fazer essa associação, realmente tu tens razão! É tudo hardware, que sensacional! Só não entendo por que eles chamam isso de software! Deveriam chamar os drives de hardware também, mas são devem ser estúpidas que nem eu.

Cara, o driver, o firmware é parte do projeto do hardware. Se você comprar um magic mouse, um teclado x cheio de funcionalidades, precisa dos drivers.
É claro que driver é software, inclusive o firmware é, mas eles fazem parte do escopo do desenvolvimento do hardware. São integrantes e não podem ser separados. Se você comprar o hardware, ele deve vir com o driver.

Já viu alguém ou outra empresa implementar driver para a amd?

x@ndy:

juliocbq:

x@ndy:

juliocbq:

A barra de tarefas é quem faz saltar o menu iniciar. Sobre as teclas, o mapa vem disponível nos drivers.
Posso te chamar de Rolando Lero?

Você não respondeu minha pergunta sobre o teclado for win.

Primeiro eu já respondi, mas tu, pelo jeito não sabe ler. Segundo, nunca vi uma besteira maior. Tu quer dizer que para capturar uma tecla eu tenho que acessar os drives? Da onde? Cara não fala besteira, existe um negócio chamado API, que o Windows disponibiliza. Com ela eu posso capturar qualquer tecla pressionada.

Agora quem é o Rolando Lero?

E a api busca de onde?

Ah, quer dizer que acessar uma api e acessar um driver é a mesma coisa então?

A api usa os drivers rodando a nível do kernel.

x@ndy:

juliocbq:

x@ndy:

PS: Por acaso tu acha que porque uma empresa desenvolve hardware e drives que isso é uma coisa só, então o hardware é desenvolvido pensado no software no qual vai rodar, no caso, o SO?

Ahh, e não é!? Conhece algum louco que desenvolve drivers para nvídia(tirando a comunidade opensource que faz engenharia reversa)?

Quer dizer que uma empresa desenvolve uma hardware e um drive (software), e tudo isso é considerado hardware? Nossa, hardware + software = hardware! Sensacional, como eu sou estúpido! Realmente, eu sou muito idiota por não fazer essa associação, realmente tu tens razão! É tudo hardware, que sensacional! Só não entendo por que eles chamam isso de software! Deveriam chamar os drives de hardware também, mas são devem ser estúpidas que nem eu.

Para facilitar o entendimento do relacionamento entre apis e drivers, dá uma olhada aqui:

646px-Diagram_android.png646×600

Quanta briga de egos…
Dica para viver em paz: não se preocupe em “ganhar” discussões.

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…).

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

Concordo que a solução local é mais importante do que o CRM, mas não acredito que é por causa da complexidade, e sim por está mais próxima do negócio.

No caso de uma empresa de estacionamento, se o software no estacionamento não funcionar direito o negócio deixa de gerar lucro e a empresa pode fechar. O software de CRM não oferece esse risco e por isso essa parte geralmente é oferecida por provedores de soluções comoditizadas.

Hebert Coelho:

kicolobo:

Bem vindo ao meu mundo Herbert.
Há diversas situações nas quais isto ocorre, na realidade, no meu caso ocorre o tempo todo e, se você for parar pra pensar que agora temos uma avalanche de mobile, vai ser a regra, por mais que tentem normalizar as coisas por baixo da API.

Pois é, a casos e casos. Afirmar que isso é regra que eu acho errado.

Infelizmente existem o xiitas que ñ percebem que existem coisas que são impossíveis de se tomar por regra…

Meu front end hoje é todo mobile e ainda assim não me preocupo com hardware. [=

Concordo que cada caso é um caso, quem se preocupa quer ter certeza que seu software vai funcionar em todos os casos. Só por que vc não se preocupa não significa que é a coisa mais apropriada a se fazer, ou significa, novamente, cada caso é um caso.

x@ndy:

juliocbq:

x@ndy:

PS: Por acaso tu acha que porque uma empresa desenvolve hardware e drives que isso é uma coisa só, então o hardware é desenvolvido pensado no software no qual vai rodar, no caso, o SO?

Ahh, e não é!? Conhece algum louco que desenvolve drivers para nvídia(tirando a comunidade opensource que faz engenharia reversa)?

Quer dizer que uma empresa desenvolve uma hardware e um drive (software), e tudo isso é considerado hardware? Nossa, hardware + software = hardware! Sensacional, como eu sou estúpido! Realmente, eu sou muito idiota por não fazer essa associação, realmente tu tens razão! É tudo hardware, que sensacional! Só não entendo por que eles chamam isso de software! Deveriam chamar os drives de hardware também, mas são devem ser estúpidas que nem eu.

Sim. Apple é uma empresa de hardware apesar de tb produzir software. Mas uma integração tb pode resultar no contrário acontecer. Por exemplo, se o facebook criar um smartphone (hardware) vai continuar sendo uma empresa de software.