desarrollo WEB vs. desarrollo tradicional

[Iceman]

Pregunto: ¿Alguien ha desarrollado o visto una aplicacion de gestion comercial que tenga, digamos, unas diez terminales en el mostrador facturando al publico sin pausas y otras tantas realizando otras tareas operativas? Seguro que si verdad?
Pues bien cuantos de esos la desarrolló o la vío simplemente, corriendo en un explorador de internet?

Si la respuesta es ninguno, pues bien, ahi tienes amigo Iceman 2, un ejemplo de que TODO no se puede hacer de la NUEVA forma (WEB) y necesitas el VIEJO metodo, por lo demas, creo que hay cosas que si y cosas que no, depende las circunstancias.-

Iceman, el verdadero

[marto]

Empezado por Iceman

Pregunto: ¿Alguien ha desarrollado o visto una aplicacion de gestion comercial que tenga, digamos, unas diez terminales en el mostrador facturando al publico sin pausas y otras tantas realizando otras tareas operativas? Seguro que si verdad?
Pues bien cuantos de esos la desarrolló o la vío simplemente, corriendo en un explorador de internet?

Yo , se trataba de la TPV de una gran y conocida cadena de muebles española. Tienen entorno a 100 tiendas por todo el país con una mendia de unas 7-8 cajas por tienda. El cliente quedó más que satisfecho y todo corria en IE. El programa generaba hasta las etiquetas con los códigos de barras de los productos a etiquetar.

Lo que no se puede hacer con un "simple" navegador son cosas bastante reducidads. Tema distinto es que hasta en el colectivo de programadores existan ciertos tópicos sobre lo que se puede y lo que no.

[Iceman]

Respuestas x 2:

Para marto: cuando me referia a facturar sin pausas, me referia a algo con mayor volumen de publico que una muebleria, que supongo que no tendran un cliente x min en cada terminal, ya que estimo que en españa seran como aca y para comprar un mueble los clientes se toman su tiempo para decidir
Pero, está bien, tampoco quiero generar una polemica por eso, el tema es que bajo esas circunstancias si anda, yo en particular me referia a algo mas rapido. Pero bueno, espero que a Iceman 2 le sirva la respuesta.

Para kinobi: perdon por lo de VIEJO y NUEVO, deberia haber dicho "tradicional" y "web", tal como lo planteo Iceman 2. No tiene connotaciones de asembler ni nada x el estilo.-

[kinobi]

Hola,

Empezado por Iceman

Para kinobi: perdon por lo de VIEJO y NUEVO, deberia haber dicho "tradicional" y "web", tal como lo planteo Iceman 2. No tiene connotaciones de asembler ni nada x el estilo.-

Bien, pero sigue siendo el mismo problema.

Imagina una aplicación (cliente/servidor). Ambos se comunican por medio del protocolo HTTP (el utilizado habitualmente en la web), solicitando el cliente servicios (a través de CGI's) en el servidor. Imagina que el cliente (una aplicación, pongamos por ejemplo, construida con Delphi o Kylix) se ejecuta en un sistema empotrado que utilice Windows o Linux.

Pregunta: ¿de qué tipo de aplicación, según vuestra clasificación ("tradicional/web"), estamos hablando?

Saludos.

[marto]

Empezado por kinobi

Imagina una aplicación (cliente/servidor). Ambos se comunican por medio del protocolo HTTP (el utilizado habitualmente en la web), solicitando el cliente servicios (a través de CGI's) en el servidor. Imagina que el cliente (una aplicación, pongamos por ejemplo, construida con Delphi o Kylix) se ejecuta en un sistema empotrado que utilice Windows o Linux.

Pregunta: ¿de qué tipo de aplicación, según vuestra clasificación ("tradicional/web"), estamos hablando?

Tienes toda la razón. Lo que sucede es que lo que planteó el amigo _iceman (que por cierto no ha vuelto a dar señales de vida) era mucho más sencillo que todo eso. Actualmente muchas de las aplicaciones que tengo que desarrollar con clientes Delphi las hago exactamente con el diseño que tú has explicado y creo que se consiguen muchas de las ventajas de ambos mundos.
Siempre que se hacen simplificaciones se cometen errores, pero es mucho más fácil manejarse en un mundo simplificado que hacerlo con todas las variantes

[marto]

Empezado por Iceman

cuando me referia a facturar sin pausas, me referia a algo con mayor volumen de publico que una muebleria, que supongo que no tendran un cliente x min en cada terminal, ya que estimo que en españa seran como aca y para comprar un mueble los clientes se toman su tiempo para decidir

No sé de qué país eres.... pero deduzco que nunca has entrado en un Ikea
Te aseguro que el ritmo de ventas es comparable al de un supermercado.

Empezado por Iceman

tampoco quiero generar una polemica por eso

¿Y por qué no? Aquí estamos para eso, la polémica es la salsa de la vida

Empezado por Iceman

yo en particular me referia a algo mas rapido.

Pues no sé a qué te referirás, pero te puedo asegurar que el hecho que el cliente de la aplicación esté basado en web o no no tiene absolutamente nada que ver con la rapidez de la aplicación.
Si crees que no es así.... por qué no nos das algún argumento de lo contrario?
Las diferencias de velocidad son debidas esencialmente a tres factores (si me dejo alguno seguro que kinobi me corrije )

-Volumen de datos /volumen de usarios: Afectará del mismo modo si es web o no

-Trafico de red: Contra lo que mucha gente piensa, si se programa bien será el mismo en los dos casos

-Infraestructura de hardware: aquí incluyo el hardware del cliente, el del servidor/es y las redes que haya por medio. En este tema, y en función de las distintas especificaciones, beneficiará a un tipo de cliente o a otro. Pero en ningún caso se puede decir que de forma general penalice más a las aplicaciones web.

Sé que me estoy dejando otros factores, pero creo que llegaríamos a conclusiones similares. Si a alguien se le ocurre alguno en el que no, pues ya sabe.

[marto]

Ah! una nota, los factores que comentaba son suponiendo qua la única diferencia sea la interfaz. Como bien a dicho kinobi, existen muchas otras diferenciias (protocolos, arquitectura, nº capas,...). Pero suponiendo que el resto siga igual, creo que los tiros van sobre lo que decía.

[*Emilio*]

En mi caso y por exigencias del guión me ha tocado desarrollar junto a mi compañero toda la aplicación de gestión de una empresa con delegaciones en toda España. La aplicación consta de Gestión de Obras, Pedidos, Contabilidad, Mano de Obra, Almacén así como de un sin fin de pormenores como listados, tablas auxialiares etc...

La aplicación está desarrollada íntegramente en PHP atacando una base de datos DB2 de un AS/400, y es usada simultaneamente por unos 200 PC's

Es cierto que muchas cosas se hacen con muchísima más facilidad con Delphi, no obstante para una aplicación de gestión poco tienes que atacar los recursos del sistema, al lado del cliente usamos JavaScript, aunque bastante pejilguero para mi gusto se pueden hacer con él cosas realmente sorprendentes.

El único tema que no tenemos realmente solucionado es el de los listados, todavía no hemos encontrado una solución tipo Report Builder y que además corra en Linux, los de Digital Metamor... tiene algo pero él servidor sólo corre en Windows.

Por supuesto para hacer programas de gestión de fotos, música y video, sigo usando Delphi, también para otras cosas que ni PHP ni el explorer son capaces todavía de llegar

Con esto creo responder a la pregunta de ¿alguno ha visto una aplicación.....?

[marto]

Empezado por Emilio

El único tema que no tenemos realmente solucionado es el de los listados, todavía no hemos encontrado una solución tipo Report Builder y que además corra en Linux, los de Digital Metamor... tiene algo pero él servidor sólo corre en Windows.

Pues nosotros sí lo tenemos solucionado, pero con los cgi en delphi, claro. De todas maneras te lo comento porqué igual la idea te "inspira". Generamos los informes con FastReport como si fuese un cliente Delphi, despues los exportamos a pdf y los guardamos en un fichero temporal. llegados a ese munto solamente falta redireccionar al navegador hacia el fichero creado. Con una tarea programada se borran los ficheros cada noche y listos.

[kinobi]

Empezado por Iceman

Si la respuesta es ninguno, pues bien, ahi tienes amigo Iceman 2, un ejemplo de que TODO no se puede hacer de la NUEVA forma (WEB) y necesitas el VIEJO metodo, por lo demas, creo que hay cosas que si y cosas que no, depende las circunstancias.-

Bien, pero ¿qué es eso de el VIEJO metodo? ¿Acaso es desarrollar aplicaciones en ensamblador? ¿Tal vez es sólo una diferencia en el tipo de cliente que ejecuta esas aplicaciones?

Saludos.