![]() |
¿El futuro pasa por la programación"via web" ?
Hola,
Soy un aficionado a la programción en Delphi y he realizado varias aplicaciones para uso personal, entre ellas destaca una, realizada con Delphi 4, que gestiona una base de datos Paradox. Despues de varios años de dejar la programación tengo la necesidad de actualizar esta aplicación con mas funciones y sobretodo, actualizar la base de datos a un sistema más 'moderno'. Llevo varios dias dandole vueltas al tema y tengo varias dudas, es mejor seguir con el sistema de aplicación y base de datos en el mismo ordenador o para una mejor seguridad montar el sistema en la 'nube'. La aplicacion en este momento no es 'multiusuario', pero podria surgir esta necesidad. ¿En este caso ya seria mejor buscar us servidor como base de datos y montar la aplicación en cada ordenador que pueda tener acceso o ir direcatmente a una programación web?. He ojeado varios programas como 'scriptcase', que genera codigo php a partir de una base de datos, pero no se si voy a ser capaz de poder programar las cuestiones que salen de lo estandar. Agradeceria algunos consejos para despejar estas dudas. Muchas gracias |
El futuro de la programación es multi-paradigma.
Que debes hacer? Elegir la herramienta adecuada para el trabajo. No es cosa de seguir un paradigma por seguirlo, es hacerlo porque tenga sentido, sea practico, el costo-beneficio sea adecuado y de el resultado esperado o mejor. Recuerdo cuando era mas novato segui casi ciego cada nueva moda (programación orientada a objetos, n-tier, sql server, COM, DCOM, ADO, etc). Al final sin un norte claro todo esfuerzo es una perdida de tiempo. Lo que tienes que hacer primero, es determinar que quieres hacer. Que tienes, y que puedes conseguir razonablemente (lo que llaman hacer requerimientos ;)). No olvides el principio KISS (Keep It Simply, STUPID! - Mantenlo simple estupido!). Una app no es mejor porque tenga X nueva tecnologia, es porque tiene la que es correcta para su situacion. De hecho, simplificar al maximo es una ventaja competitiva en extremo util (como el chiste. App de Apple: Un Boton. App de Google: Una caja de texto. App de empresa cualquiera: 1789 cuadros y 423 botones por pantalla!) Asi que empieza primero por pensar hasta donde quieres llegar. Luego regresa y con cosas mas especificas te vamos ayudando.. |
Recuerdo el día que nos trajeron el primer ordenador al trabajo. Era un 386 con linux y tres terminales tontas.
Al poco tiempo se extendiron los Pc' Los hacíamos funcionar de forma independiente y, utilizando emuladores, los conectabamos a aquel servidor linux (Bueno era Unix SCO). Con windows 3.11 se empezo a trabajar con la sombrosa tecnología que permitia compartir carpetas: trabajo colaborativo.... Apareció internet y algunas cosas se empezaron a hacer a través de paginas web, incluso los mas listos de la clase con "web 2.0". Ahora creo que se tiende a que los límites entre la red local y la red extensa (www) sean cada día más difuso. Te cuento estas "batallitas de viejo" por que creo que de momento se utiliza la tecnología web para usar la red extensa pero al final se accederá con distintas tecnologías desde cualquier sitio a la información y de mil formas distintas. Va a pasar esto.... o lo cotnrario.... Saludos. |
Cita:
Creo que esa es la clave. Piensa lo que necesitas ahora y lo que puedes necesitar en un futuro cercano. Y busca la mejor solución, la más eficiente y la que puedas hacer tú. |
^\||/^\||/^\||/
|
Cita:
No, perdón pero soy muy "old fashion" en éste sentido y nada como un cliente-servidor en que todo está bajo control, en su lugar y en orden... |
Hola.
Fijaros que hace poco todo el mundo pensaba que el futuro eran los programas web y ahora llegan los smartphones y vuelven a poner de modas las apps, que es como les llaman ahora, en vez de usar programas web. |
Cita:
De momento quiero una aplicación monousuario, pero en un futuro proximo me gustaria, en pocos cambios, que fuese multiusuario y acceso incluso desde smartphone. ¿Que base de datos se adapta a esta idea ?, ahora uso paradox ¿supongo que me olvido de esta, no ? Muchas gracias. |
Lo de acceso por smarthphone... como App nativa, como pagina, como un API que puedas luego invocar desde app nativa o web?
|
Cita:
Gracias |
Cita:
|
mamcx,
Cita:
Nelson. |
Totalmente de acuerdo con mamcx, incluso en nuestros días aún hay sistemas que corren en MS-DOS o UNIX programados en dBASE, Clipper,Cobol, C y hasta Fortran cuyo código sigue haciendo lo que fue destinado a hacer y que no necesita ni mejora con aplicaciones web ni apps ni cosas así. No por nada AS/400 todavía sigue por ahí dando pataditas. Lo nuevo no es sinónimo de mejor en todos los casos.
|
Cita:
1) App nativa + App mas rapida e integrado en el OS. + Acceso total a las capacidades de hardware, posibilidad de hacer interacciones mas novedosas +/- Potencialmente, desarrollo mas rapido (si estas acostumbrado a apps nativas) + Poder trabajar desconectado + Practicamente indispensable si es iOS (osea, los usuarios en iOS son menos tolerantes de apps a medias) + Posiblidad de diseño mas atractivo + Posibilidad de monetizar la app de formas multiples + Acceso a la(s) appstore + Absolutamente el mercado con mas futuro - Hacer multiplataforma es mas jodido - No creo que Delphi sea una buena opcion, hay que usar otro lenguaje (Java/obj-c) - Android es mas duro de desarrollar y mas duro de probar (los calculos dan entre 3x-5x mas en costos/tiempos) - iOS tiene costo de entrada ligeramente mas alto - A pesar de ser apps nativas, son una bestia diferente a las desktops - Potencialmente, desarrollo menos rapido, mientras adquieres las destrezas basicas - Debes pasar los appstore (si piensas en despliegues masivos) 2) Como pagina + Mas amplia cantidad de opciones + No te preocupas de que los usuarios tengan versiones viejas + Desarrollo *inicial* mas rapido + Menor costo de entrada + Es posible que el costo de la operacion sea gratis inicialmente (solo pagar el dominio) + Mas multiplataforma/multidispositivo imposible +/- Mayor numero de talento disponible (eso creo) +/- Posibilidad de monetizar relativamente facil, pero sin las ventajas de las appstores - Piensa en las ventajas de la app nativa, e inviertelas (app mas lenta, no acceso full a hardware, etc) - Mayor complejidad total de desarrollo. Involucra la mas amplia gama de tecnologias, herramientas, lenguajes, plataformas que las apps normales - Potencialmente, la parte de HTML/CSS/JS sea la que mas dificultad de, en especial, porque hay multiples dispositivos y navegadores. Costos de testeo mas altos - Si no tienes experiencia en apps web, probablemente varios pasos en falsos. Es otra bestia diferente - Delphi definitivamente es una mala elección aqui - Hay que aprender, como minimo, Javascript y un lenguaje de backend (python, ruby, php, node, go), html5, css3, posiblemente involucrar cosas como angular, handlebars, etc, un framework como django, ruby on rails u otro, una BD como postgres o un NOSQL como mongo, o ambos - Mas dificil de hacer un escenario desconectado - Te cargas el muerto de asegurar la operacion 24*7*365 3) Como un API Es hacer un hibrido de ambos. Creas una "engine" con toda la logica de negocios, la cual puedes desplegar como un servicio web y/o librerias para mezclar con la app nativa y la web + Total flexibilidad + Si una estrategia fracasa (la web, el desktop, la movil) pero el modelo de negocios es valido, puedes reenfocarte mas rapido sin perder toda la inversion + Parcialmente, puedes mantener la ventaja web de tener a todos los clientes en la ultima version + Delphi podria ser una opcion como datasnap o remobjects (pero solo para el engine API como web) - El desarrollo es mas complejo, es facil perder de vista las cosas y hacer cosas innecesarias - Se requiere mayor esfuerzo para hacer un diseño elegante - No necesariamente, te ahorras del todo el duplicar esfuerzos +/- Igual tienes que hacer un cliente web o movil o desktop asi que te ganas los puntos anteriores ------ Es posible lograr lo anterior (lo del API) de una forma mas rapida si estas dispuesto a sacrificar flexiblidad por ganar tiempo + ahorrarte el tener que sostener 24*7*365 la operacion si usas un backend como servicio, por ejemplo http://ww.parse.com (que es BD NOSQL + Manejo de usuarios + Servidor API + librerias clientes multiplataforma). Lo he usado y es una opcion viable en muchos casos. Otra manera es usar una BD flexible. Posiblemente, postgres sea la mejor de todas. Implementar tanto de la logica como se pueda en esta y hacer clientes para la tal. Es hacer el modelo 2-tier pero montando el servidor de BD en un hosting web/cloud. Probablemente, lo mejor para ahorrarte los costos de mantenimiento e infraestructura sea https://postgres.heroku.com/. En todo caso donde tienes que usar hosting, es una MALA MALA idea el que te pongas muy "baratero". El costo de operacion/infraestructura es una carga muy grande cuando la operacion es pequeña/mediana y no justifica hacerlo "a mano". Es mejor pagar por ese servicio. |
Cita:
Muchisimas gracias |
Muy buen resumen mamcx. ^\||/
|
La franja horaria es GMT +2. Ahora son las 13:20:27. |
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi