Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
Ver: Modo: Orden:
Como preparar su empresa para el software libre | 52 comentarios (50 temáticos, 2 editoriales, 0 ocultos)
Software multiplataforma (3.66 / 3) (#23)
por canuto a las Thu Jun 19th, 2003 at 02:10:46 PM CET
(Información Usuario)

A parte de mantenerse al día en aplicaciones de Software libre, hay que plantearse desarrollar aplicaciones multiplataforma win32-Linux, a fin de, no sólo no llegar tarde al tren de Linux, sino subirse de los primeros, sin necesidad bajarse en marcha del tren de Win32.
Creo que para desarrollar software multiplataforma la mejor opción es Java. Aparte de las ventajas que tiene como lenguaje, tenemos la independencia de plataforma, no sólo Windows/Linux, sino también en otras plataformas como por ejemplo MacOS.
El principal inconveniente que se le suele achacar a Java en el escritorio es la lentitud, sobre todo en las interfaces de usuario. Teniendo en cuenta los cañones de equipos que se venden hoy, la verdad es que no se nota mucho esa diferencia en el rendimiento. La utilización de las librerías SWT (incluidas en Eclipse) aumenta el rendimiento de las aplicaciones gráficas, además de integrar totalmente el "look" de las aplicaciones a la plataforma nativa. De todas formas, tampoco va tan mal Swing...
Otro punto a favor de Java es la tecnología Java Web Start, que permite instalar aplicaciones a través de Internet fácilmente (haciendo un clic en un enlace en una página web), además de actualizarlas. Puede ser una solución muy atractiva para el problema de la distribución de programas ejecutables.
Mucha gente rechaza Java por su licencia, que no es libre. De todas formas, Sun ha ido cediendo poco a poco el control de Java a través del JCP, aunque no deja de ser no libre...



Multiplataforma? --> HTML (4.00 / 2) (#25)
por sinner a las Thu Jun 19th, 2003 at 06:23:13 PM CET
(Información Usuario) http://www.escomposlinux.org/sinner/

Para soluciones multiplataforma, nada commo aplicaciones web. Metes tu apache, con mod_perl, mod_php, mod_ssl y MySQL/PostgreSQL/Oracle/DB2... y carreras.

Facilmente mantenibles (la aplicacion solo reside en se servidor, por lo que als actualizaciones son facilisimas), funcionan en Mozilla (multi-plataforma), se desarrollan rapidamente (PHP es una fiera para aplicaciones "wes"), con perl, te curras los cgi que hagan falta, y el acceso a bases de datos esta tirao.

Evidentemente, los programas "wes" estos, funcionan en Hasefroch, Linux, MacOS X, *BSD... Y le puedes vender al PHB (pointy haired boss) de turno que estas implementando "Web Services".

Cuando tengas bastantes de estos "Web Services", el cambio de OS en los clientes es trivial: LTSP y a cascarla.

Que mas quieres?


Salut,
Sinner


--
Sinner from the Prairy
Pogüered bai Mandrake
BOFHers Syndicate http://bofhers.org
[ Padre ]


Programas y programillas (4.00 / 1) (#35)
por Colegota (colegota@villanos.es, digo net.) a las Fri Jun 20th, 2003 at 12:10:28 PM CET
(Información Usuario) http://villanos.net/mapamundi

Buenas,

estoy de acuerdo en las ventajas multiplataforma del html. También en que con entornos como php + base de datos se pueden lograr muchas cosas que hasta hace poco sólo podían ejecutarse en "máquinas reales". Que las "aplicaciones de gestión" en entornos no gráficos y algunas incluso gráficas no dan mucho más que lo que un php + bd...
Pero eso está limitado a algunas aplicaciones y ni de lejos puede competir con lo que hay ahora.

Simplemente, y a pesar de lo mucho que han avanzado, compárese un webmail con un cliente de correo. ¿Qué prefieres? (Cuando puedes elegir, no cuando estás lejos de tu máquina).
O plantéate crear un "Dreamweaver" en html. Que sí, que se puede hacer... en parte. Pero no es lo mismo.

Si el precio de la multiplataforma es ese, en la mayoría de los casos el resultado será su no aceptación. Nadie quiere volver atrás. Los ordenadores son cada vez más potentes y la gente quiere sacarles partido.

Otro motivo/tema es que se haya abierto todo un nuevo mundo de posibilidades en cuanto a aplicaciones remotas gracias a estos sistemas. Pero conociendo las limitaciones y para usos concretos.

Precísamente aprovecho para comentar que uno de los problemas del java es todo lo que ha sacrificado para ser multplataforma (que no omniplataforma).
Y es tan sencillo como que se ha complicado la programación y simplificado bastante el resultado visual (aunque si se "curra" se consiguen cosas), pero sobre todo, que la interfaz de usuario va con bastante retraso respecto a "otros". Por ejemplo, la rueda del ratón sólo es manejada en la versión 1.4, mientras que la estable ahora es la 1.3.

Vamos, que como lo veo hoy por hoy, los entornos multiplataforma o están verdecillos o no son gran cosa. Y los más avanzados no son libres en todas las plataformas. Y que plantearte hoy por hoy desarrollar algo multiplataforma es para pensarlo muuuy despacio.
Vamos, me parece.

Saludos,
Colegota


[ Padre ]


 
Inviable (3.00 / 1) (#29)
por svampa a las Thu Jun 19th, 2003 at 11:35:37 PM CET
(Información Usuario)

HTML es un interface de presentación, el resto son parches. Ni siquiera mantiene una conexión permanente con la aplicación servidora, se tiene que solucionar con cookies y demás.

Es aceptable para una utilidad de configuración, swat, webadmin etc. Pero una cosa es una utilidad espartana que utilizas una media de 10 minutos al día, y otra un programa de gestión con contabilidad, almacén, cobros, pagos etc.

[ Padre ]


Te aseguro que no (4.00 / 2) (#30)
por sinner a las Thu Jun 19th, 2003 at 11:43:37 PM CET
(Información Usuario) http://www.escomposlinux.org/sinner/

Las aplicaciones estas de contabilidad y similares, hasta hace bien poco, funcionaban via telnet a un servidor o en basic+DOS o similares.

Ir de esos entornos a Web, es totalmente posible. De hecho es el camino.

Otra cosa es que no mole implementar seguimiento de sesiones, o no se haga habitualmente. O, si quieres permanencia, un applet en Java, que no deja de ser todo un "ejecutable" que actua de programa cliente con el servidor (web).

No se si te suena MUMPS/Caché. En principio, la interficie era todo texto (esos emuladores de terminal...). Luego, cuando se vio el lio sw Win32/NT y similares, Intersystems (creo que era la empresa que hace Caché) decidió irse a aplicaciones web. Creo que aún continuan así. Y, como no, tienen Caché para Linux desde hace bastante :)



Salut,
Sinner


--
Sinner from the Prairy
Pogüered bai Mandrake
BOFHers Syndicate http://bofhers.org
[ Padre ]


Estoy de acuerdo contigo (4.00 / 2) (#32)
por Victor (victor@taquiones.net) a las Fri Jun 20th, 2003 at 09:11:22 AM CET
(Información Usuario) http://www.taquiones.net/victor.html

Es más, desde hace unos tres años, en que leí un pequeño libro que explicaba su visión lo tuve clarísimo. Usando un navegador, que encuentras hasta en los sistemas más extraños y miserables, obtienes un buen número de ventajas:
  • Reduces la curva de aprendizaje de los operadores. No tienen que enfrentarse con diferentes sistemas de menús ni operativas casi alienígenas de algunas aplicaciones. Les basta con saber utilizar el navegador.
  • La información puede presentarse -por fin- completa y agradable. Aún recuerdo los extractos de cuentas del administrador de fincas de mi edificio, con 32 miserables caracteres para describir que el portero ha comprado un enchufe para el cuarto de calderas. La culpa la tiene el programa, claro, que no admite más :-)
  • La personalización puede llevarse a extremos inimaginables. El contable sólo ve aquello que le interesa, el operador de facturación, el de mercadería ... todos tienen su propia versión hecha con dos patadas.
  • Y para terminar, lo que más me gusta, que relacionas información de la forma más conocida actualmente: con hipertexto. Un poquito de maña y en tu programa puedes ir de un lado a otro siguiendo la manita del ratón.


Pues por todo esto, y por algo más que seguro que se me olvida, es por lo que estoy de acuerdo en que el web es la multiplataforma más acertada.

Ah, y los detalles de implementación, como el control de sesiones, las tareas en segundo plano y demás ... pues suponen retos alcanzables muy divertidos ¿ no crees ?
Victor Moral <victor@taquiones.net>
[ Padre ]


 
Estoy con Sinner (3.50 / 2) (#34)
por melenas a las Fri Jun 20th, 2003 at 11:44:22 AM CET
(Información Usuario)

Sin ir más lejos, en mi PFC, tenía que hacer un interfaz para controlar un sistema automático de control de sensores con salidas digitales.

En un principio pensé hacer un programa específico, pero eso me obligaba a elegir plataforma (bueno, en verdad a que sólo funcionase en Linux)

Después pensé en Java, pero no me acababa de convencer.

Finalmente me decidí por PHP+mysql, multiplataforma, rápido, con autentificación y refresco de datos automático, todo lo que pedía y más, pues podía editar remotamente los archivos y además reiniciar el demonio que controlaba la aplicación.

Estas dos últimas características no lo hacía muy seguro supongo, pero funcionar funcionaba y además me pusieron un 10 ;-)


FDO. ER_MELENAS No te preguntes sólo que puede hacer el S.L. por ti sino también que puedes hacer tú por él.
[ Padre ]


 
Tanto como inviable... (3.00 / 2) (#37)
por thuban a las Fri Jun 20th, 2003 at 10:17:17 PM CET
(Información Usuario)

Tecnicamente es posible hacer una aplicacion web que tenga un interfaz muy parecido al de una aplicacion nativa (.NET es eso), pero si es bastante dificil, y tal vez no merezca la pena.

Si la empresa es pequeña, tendra pocos clientes (terminales, usuarios, operadores...), y como hacer una aplicacion complicada es nas dificil en web, tal vez la empresa no pueda pagarla.

Si la empresa es grande, tendra muchos clientes y gastara bastantes recursos en sesiones.

Si una empresa hace una aplicacion web generica y se dedica a venderla en una caja (muchos clientes que pagan poco hacen mucho dinero) y tal vez a personalizarla, intentara por todos los medios proteger su inversion, asi que el codigo sera cerrado o la licencia draconiana, porque si no es asi, no ingresara dinero por ventas, y cualquiera podra pisarle el soporte (y os cagareis en sus muertos)

En fin, que veo dificil lo de las aplicaciones web para aplicaciones de gestion (que se pueden hacer y se hacen, ojo, pero mas por cabezoneria que porque sea lo optimo).

Otra cosa seria una aplicacion de varios niveles (tiers, vamos) en la que la capa servidora escupe XML, que podria convertirse en algo visible en un navegador mezclandolo con XSL o presentarlo en una aplicacion normal que parsea el XML y lo presenta.

Eso es una posibilidad, pero el cliente "aplicacion-normal" seria siempre mucho mas potente y rapido que el cliente web.

Y por cierto, de los applets olvidaros, que son pesadisimos y si sirvieran para hacer cosas importantes Sun no se hubiera metido en el berengenal de los Servlets/JSPs/EJBs/Java-de-servidor, que es un negocio donde se tiene que pegar con mucha gente, mientras que en los applets tenia un mercado virgen para el solito.

[ Padre ]


 
PHP :D (none / 0) (#52)
por festuc (mi nick en el correo gratuito de google) a las Mon Oct 13th, 2003 at 06:19:02 PM CET
(Información Usuario) http://festuc.info

He escrito una facturación en base php mysql, estoy en un 70% de la aplicación.
Solo me falta aprender TeX para hacer las facturas, y enviar el pdf para la impresión. Aún no he puesto el proyecto en ningún sitio, peró lo haré proximamente.
Una vez termine, haremos una contabilidad en esta misma forma. Esta vez lo haremos cooperativo, verdad chicos?
Los sistemas en esta plataforma, como todos los cliente-servidor tienen múltiples ventajas. Una sola copia de seguridad, con rsync si quieres, Misma interfaz, misma versión siempre en todos los terminales... .
He escrit una facturació vasada en php i mysql. Estic al 70% de l'aplicació.
Només em queda apendre TeX per preparar les factures.
Encara no he posat el projecte a cap lloc públic, però ho fare proximament.
Un cop acabi, farém una contabilitat d'aquesta manera. Aquest cop cooperativament, oi nois?
Els sistemes d'aquest tipus, com tots els client-servidor, múltiples ventatges: Una sola cópia de Seguretat, rsync, si vols. Mateixa interfície, mateixa versió a tots els terminals ...


[ Padre ]


 
Alternativa al Java Web Start y puentes para Beans (3.66 / 3) (#24)
por jorginius ("jorginius" en Google Mail) a las Thu Jun 19th, 2003 at 05:22:25 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Otro punto a favor de Java es la tecnología Java Web Start, que permite instalar aplicaciones a través de Internet fácilmente (haciendo un clic en un enlace en una página web), además de actualizarlas.

Sí, es una forma interesante de distribuir software y las actualizaciones, pero no es una ventaja exclusiva de Java. Por si tienes curiosidad, puedes actualizar e instalar el mismo software que estás usando en Linux mediante un mecanismo muy similar: Zero Install.

Por otra parte, y retrocediendo en tu comentario :)

El principal inconveniente que se le suele achacar a Java en el escritorio es la lentitud

Aparte de eso, yo le suelo achacar que no se "un buen vecino" con el resto de aplicaciones. Java será multiplataforma pero "multiescritorio".

Por ejemplo, no podemos mezclar componentes escritos en Java con los componentes habituales de nuestro sistema o meterlos en nuestas aplicaciones contenedoras... Bueno sí, de acuerdo: se puede hacer en Windows, donde sólo hay un puente específico entre JavaBeans y ActiveX que se distribuye con el JDK, pero ¿y en Linux?.

Lo más parecido sería usar el (por supuesto no ofical) BlackConnect, un puente entre Beans y XPCOM, y un segundo puente entre XPCOM y GNOME/Bonobo (por supuesto, si Bonobo se utilizase para algo más que para pruebas de concepto, que es su uso principal hoy en día :-().

Para "la otra" arquitectura de componentes que sí se está usando y con bastante buen resultado (Kparts) no hay nada, ni siquiera nada "no oficial".

Vamos que si ya cuidan poco las máquinas virtuales para plataformas distintas de Wintel y Sparc/Solaris, ya ni te cuento lo poco que les importa la interoperatibilidad de Java con las tecnologías nativas de esas plataformas. Eso es un problema en el escritorio, igual que lo es que Swing sea tan leeeento.

[ Padre ]


Gnome y Bonobo (4.00 / 1) (#26)
por davinci (davinci at ecol org) a las Thu Jun 19th, 2003 at 06:48:23 PM CET
(Información Usuario)

Esto es más una pregunta que un afán de meter hierro o especular, pero es que me resulta extraño que Bonobo no llegue a prosperar y surjan mil proyectos que lo implementen.

Y yo digo, ¿no será que la gente de Gnome piensa olvidarlo y concentrar esfuerzos en Mono?.

Por supuesto se me ocurren otras preguntas que, con mis paupérrimos conocimientos al respecto, tan sólo me da para formular: ¿El problema de Bonobo se debe sólo al parón motivo de portar las aplicaciones a Gnome2? ¿Volverán a resurgir los afanes en cuanto todo lo demás esté resuelto?

Desde luego, una cosa es cierta: van unas cuantas versiones de Gnome y parece que la cosa empieza a estar madura, pero sólo a nivel externo. Luego te pones a intentar que los componentes funcionen juntos (Abiword, Gnumeric, Sodipodi, Dia) y no hay nada que hacer :(

Y pardiez, que me gustaría mucho ver cambiar pronto esta situación.


¡Es la guerrrrrrra!
[ Padre ]


Gnome, Bonobo y Mono (3.00 / 1) (#27)
por jorginius ("jorginius" en Google Mail) a las Thu Jun 19th, 2003 at 08:20:15 PM CET
(Información Usuario) http://www.rodriguezmoreno.com

Y yo digo, ¿no será que la gente de Gnome piensa olvidarlo y concentrar esfuerzos en Mono?.

Mono no sustituye a Bonobo. Lo "abraza y lo extiende" :-). La verdad es que no lo sigo muy de cerca pero pienso que parte de los componentes del framework de .NET, Mono los entenderá como un recubrimiento fino de componentes Bonobo actuales. Vamos, sería lo lógico...

Supongo que su sitio en este tinglado es el de ser se una capa más (otra) que usará Mono ofreciendo una interfaz (otra) de más alto nivel.

Además, aún no está claro si será adoptado oficialmente Mono dentro de GNOME o no aunque, bueno... El sistema de componentes actual de GNOME es prácticamente de Ximian (entre comillas): si ellos apoyan un cambio a Mono es bastante probable que se acepte una capa más.

¿El problema de Bonobo se debe sólo al parón motivo de portar las aplicaciones a Gnome2?

A mí me parece que el problema es la falta de madurez (¿cuantos cambios del API llevamos?) y el lenguaje elegido por defecto, o sea C, que es tan malo para programar componentes como pegarle a un padre.. Por mucho que te rompas los cuernos en escribir, y reescribir, un API sencilla. Pero claro, es mi opinión personal.

La verdad es que Kparts es mucho más limitado que Bonobo. No soporta comunicación remota entre componentes outproc (ni por supuesto en distintas máquinas) ni más lenguaje de implementación que C++ en principio, pero ¡eh!, funciona :-) y lo usan todas las aplicaciones de KDE oficiales así como casi todas las "externas" (además que el usuario "nota" su utilidad), cosa que no se cumple con GNOME y Bonobo ni por asomo.

En fin, algo están haciendo mal en GNOME cuando con una tecnología superior sobre el papel no convencen a los desarrolladores. Quizás les haga falta Mono :-).

[ Padre ]


Gnome y la continua promesa (3.00 / 1) (#33)
por davinci (davinci at ecol org) a las Fri Jun 20th, 2003 at 09:56:54 AM CET
(Información Usuario)

Me temo que, teniendo en cuenta todo lo que dices, se puede estar dando una situación perpetua de: "vamos a esperarnos a que la estrategia de base esté afianzada de verdad". ¿Cómo te vas a meter a implementar en tu aplicación el sistema de componentes de Gnome si resulta que cada año surge un nuevo paradigma que promete el oro y el moro?

Lo cierto es que los componentes en sistemas gráficos son primordiales para sacar partido a las aplicaciones. A día de hoy, usar un entorno Gnome2 es quedarse a medias en todo, me da la sensación.

No pretende ser tanto una crítica (a fin de cuentas no estoy involucrado en el desarrollo de Gnome y poco puedo decir al respecto con cierta legitimidad) como una expresión de sorpresa. De veras creía, ante la salida de Gnome2, que Bonobo habría alcanzado la suficiente madurez como para que empezase a funcionar todo como un gran sistema repleto de engranajes.

Supongo que, como de costumbre, será una cuestión de tiempo.

Y si me he referido a la posibilidad de que el portar las aplicaciones a Gnome2 desde el Gnome1 tenga parte de la culpa, es porque Gnumeric, por ejemplo, sí ha tenido siempre la posibilidad de integrar componentes Bonobo en anteriores encarnaciones. Pero ha sido empezar la tarea de pasarlo a las nuevas APIs y dar la sensación de tener que rehacer todo desde 0. A día de hoy, la integración (de nuevo) con Bonobo sigue siendo un asunto pendiente complejo.

En fin: espero que todo este cambio constante sea para bien :)


¡Es la guerrrrrrra!
[ Padre ]


 

Como preparar su empresa para el software libre | 52 comentarios (50 temáticos, 2 editoriales, 0 ocultos)
Ver: Modo: Orden:
Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda