Hoy he descubierto "pconsole" una aplicación muy útil a la hora de realizar labores repetitivas en distintos servidores.
Ejemplo, hay que realizar unas tareas X en una cantidad de servidores Y que son iguales (un cluster quizás).
En lugar de ir uno a uno, realizando X, ejecutamos unas cuantas xterm's y se las damos a pconsole.
Es muy sencillo de utilizar. En Ubuntu Hardy Heron, sólo hace falta ejecutar
sudo aptitude install pconsole
A continuación abrimos Y+1 cantidad de xterm's y en cada una ejecutamos:
tty
Lo cual nos devuelve (como todo en Linux) la ruta del fichero de la terminal. Por ejemplo /dev/pts/5
Lo siguiente será ejecutar "pconsole" en la xterm Y+1. Esto abrirá "pconsole" y nos mostrará una especia de CLI distinta. Aquí ejecutamos:
attach /dev/pts/5 /dev/pts/3 /dev/pts/4 ...
Ahora pasamos al "Modo de Envio" con Ctrl+D y todo lo que escribimos en "pconsole" se escribe en las consolas que estan adjuntas.
Existen otras aplicaciones como cssh que permiten abrir varias conexiones de SSH paralelas, pero lo encuentro un poco lento y no funciona muy bien (en mi caso) pero también es una herramienta a considerar si no podemos ejecutar pconsole.
La idea original de este blog (la cual no he desarrollado aun) es la de describir y documentar el ciclo de vida que sigue MonoCaffe. Como todo proyecto de software, espero que sea constante y vaya evolucionando entre versiones.
Antes de nada, me he documentado e incluso estoy colaborando en la traducción de un libro titulado Producing Open Source Software de Karl Fogel donde se explican muy bien las herramientas, implicaciones, responsabilidad y muchos temas más sobre el desarrollo de un proyecto de software libre.
Lo siguiente ha sido elegir las herramientas para la labor. En el caso de MonoCaffe, he elegido:
- Java (libre, conocido, fácil y multiplataforma).
- Swing.
- HSQLDB.
- Sourceforge para el hosting del proyecto (CVS, foros, sitio web, etc.)
Lo siguiente ha sido crear el sitio web. Utilizando herramientas como Inkscape fui capaz de crear todas las imágenes del sitio (e iconos para la aplicación). Luego con vim crear todo el contenido HTML/CSS ha sido un paseo de dos dias.
Con el CVS listo y funcionando, la página montada y las herramientas calientes, me he lanzado a realizar el analisis funcional de la aplicación utilizando UML (Dia Diagram Editor) para ilustrar gráficamente todo esto. Así que ahora mismo tenemos UML's describiendo la aplicación con algunos requerimientos, sus especificaciones funcionales y dos diagramas de flujo para los clientes y para el usuario del administrador.
Dado que vamos a almacenar todos los datos relativos a la aplicación para poder generar distintos reportes de uso, usuarios, etc. Va a ser necesario un medio de almacenamiento persistente, es decir, una BBDD. No he elegido productos como MySQL para facilitar la instalación sin la intervención del usuario. Así que lo siguiente ha sido el modelado de los datos para la BBDD. Siguendo el modelo de objetos que he definido he llegado a un modelo bastante sencillo de qué debería tener la BBDD de MonoCaffe:
Algo bastante sencillo y obviando temas importantes como las dependencias funcionales y metadatos y saltando directamente a la normalización.
Con lo mínimo ya preparado (tengo ganas de picar código) se abre NetBeans, checkout del proyecto desde el CVS y a ver qué sale.
Continuara...
El principal problema al hablar de software libre es aclarar su gratuidad. Sí, por definición si es libre es gratis, pero no es así. Es gratis descargarlo y utilizarlo, pero es mucho más. Un Freeware sólo es gratuito, pero sigue imponiendo restricciones sobre el usuario. El libre no impone nada más que su libertad. Gratis vs. Libre.
Es irresponsable por parte de un departamento de informática o de los usuarios, vivir en esta burbuja de gratuidad y reducción de costes en la que puede sumergirnos el software libre.
Una de las primeras cosas que aprendí de niño es que nada en la vida es gratis, todo acarrea un precio, una responsabilidad, unas consecuencias.
En el caso del software libre, el precio es cero. Al principio. El modelo de negocio de las empresas que permiten la libre distribución del código fuente de sus aplicaciones es el de ofrecer servicios de soporte, resolución de incidencias, etcétera, sobre sus productos.
Es responsabilidad del usuario, darse cuenta de esto y actuar en concordancia a sus efectos. No por utilizar una producto como MySQL, vamos a dar por sentado que siempre vamos a encontrar respuestas a nuestras clemencias en los foros y chats de Internet (aunque es bastante probable). Tampoco es necesario mantener un equipo de programadores que nos permitan resolver nuestros problemas con una aplicación, sólo hay que contactar con el licensatario del software y pagar. Libre no significa grátis.
La libertad para el usuario llega aquí: ¿Qué hago? Nos permite hacernos esta pregunta y resolverla adecuandonos a la situación en la que nos encontramos. Para muchas empresas, crear un equipo de desarrollo, pruebas, QA y demás, es innecesario y altamente costoso, pero para otras, esto puede aportarles beneficios. El ejemplo más claro, sería en la redistribución de una aplicación propia que utilice estas tecnologias.
El software libre puede ser estructurado en diferentes niveles de usabilidad empresarial, dependiendo en sobremanera del nivel de soporte que se pueden encontrar. Aplicaciones como OpenOffice, MySQL, Ubuntu, RedHat y muchos, muchos más, son producidas por empresas, no por comunidades. Es importante ver claramente esto y diferenciarlas.
Un proyecto de software libre no es siempre desarrollado por quinceañeros encerrados en su habitación. Por lo tanto no podemos esperar el mismo nivel de confianza, soporte y resolución de incidencias entre distintos proyectos, pero podemos seguir eligiendo.
Como ejemplo claro, tomemos Monocaffe, un proyecto propio que poco a poco voy sacando adelante. Es un proyecto en el cual, por ahora, soy el únido desarrollador pero que gracias a muchos productos de software libre (NetBeans, Java, MySQL, SVN, Swing, Hibernate, Apache, Linux y Rhythmbox :) permiten que un individuo pueda crear. ¿Volvemos a los tiempos en los que para desarrollar una aplicación era necesario pagar por todo esto?¿Realmente queremos limitar tanto la creación individual para que sean sólo los beneficios economicos los que muevan los hilos del desarrollo tecnologico? Creo que no.
Si en un futuro, miles de negocios empiezan a utilizar MonoCaffe, no pueden esperar un nível de soporte más allá del tiempo que tenga para resolverlas, a menos que me empiecen a pagar e inicie una empresa para ofrecerles estos servicios... sería perfecto :)
Esta es la cruda realidad de algunos proyectos, pero no de todos. Nada más lejos de la realidad. Algunos proyectos nacen con un enfoque totalmente empresarial, diferenciandose de otros por la libertad de su código, lo que los hace tremendamente competitivos tal como ha sucedido con MySQL el cual ha logrado ser el motor de BBDD por defecto de la web. Si nuestra empresa, por alguna razón, no puede resolver algún problema aún incluso despues de investigar por la web, simpre se tiene la opción, la elección, de pagar. Y si queremos cambiar, cambiamos.
Cualquier crítica hacia este modelo tiene cabida, somos libres de criticar. Pero que este modelo falla es una gran falacia cuando el más grande del sector lo tantea.
Como os podéis imaginar por el titulo del blog y las entradas que llevo escritas, soy un fanboy del movimiento Open Source. Tanto que en cuanto pueda echarle las manos encima al OpenMoko, lo haré. Tanto, que el día que el OpenSDK de Java fue certificado, casí llore.
Estos dias he estado inmerso en un curso para aprender Microsoft Navision. Me he visto forzado a ejecutar la jodida maquina virtual de Windows XP e instalar este engrendo endemoniado tambien llamado NAV.
Es realmente doloroso, en serio. Son todo ventanas, hay que utilizar el ratón para todo y esto hace que cualquier tarea se vuelva una tortura de repeticiones.
La siguiente desviación de la realidad es el lenguaje C/AL y el editor incorporado: en mi vida había encontrado semejante esperpento de editor. En serio, el Notepad es 100 veces mejor. El lenguaje no está mal, tiene unos cuantos WTF! pero es el editor el que te hace pensar cómo alguien en su sano juicio podría alguna vez barajar la posibilidad de pagar por esto.
No tengo claro si es algo de la aplicación, del lenguaje o del editor, pero al &·$%&·&% que se le ocurrio la genial y grandiosa idea de forzarme a declarar variables y funciones utilizando otra maldita ventana le digo: MUERE! No tienes manera de saber las variables declaradas desde el código, tienes que abrir OTRA VENTANA. Al menos las funciones si aparecen declaradas con su parámetros. Si alguien que lea esto entiende el por qué de un razonamiento tan aislado de la realidad, que me lo explique.
¿Qué es NAV? Pues es un ERP. A mi me parece más un Access97 que utiliza un lenguaje raro y SQLServer (otra pesadilla por su parte) pero estamos en el año 2008!!!
¿Qué es un ERP? Pues no lo sé, en la Wikipedia habla de un montón de tonterias. Para mi, es una aplicación desarrollada por algún genio de la tortura.
Por otra parte, tienen sus ventajas. No hablo de NAV, hablo de otros ERP's (OpenBravo, SAP, PeopleSoft). Te permiten ahorrar en costes de desarrollo y tener aplicaciones empresariales verdaderas (no MS Excel) ya que las Hojas de Calculo (Excel para los lusers) no son BBDD, no son aplicaciones. Estas aplicaciones vienen con cierta estrúctura básica que en unos meses permitira a cualquier empresa continuar y mejorar el negocio. Sin estos ERP's cada empresa seria, tendría que contratar a un equipo de desarrollo para producir sus propias herramientas y todos los problemas que esto acarrea. Aunque el ERP sea más sencillo de aprender y poner en marcha, igualmente será necesario un equipo dedicado a este tema, ya sea para generar nuevos informes, nuevos formularios o cualquier otra cosa que se le puedo ocurrir al departamento de turno. Sin contar con el soporte a los mismos:
Luser: "He metido mal una factura"
Yo: "Pues anulala"
Luser: "¿Cómo?" [a ver si pensamos un poquito]
Yo: "Soy informático, no contable"
Luser: "Pero es un problema del programa"
Yo: "Si, se llama meatware"
Luser: "Qué?"
Yo: "Nada... y si pruebas hacer las misma factura con valores negativos?"
Luser: "Para qué?"
Yo: "Callate y dejame terminar. Luego metes bien la factura"
Luser: "Así tengo tres facturas"
Yo: [Mirala, si sabe sumar] "¿y? Así cuadras todo y me dejas en paz"
Luser: "No puedes eliminar la factura?"
Yo: "No, descuadras el tema... no sé el qué, pero lo descuadras... vas a seguir malgastando mi tiempo?"
En fin, al menos es más chatarra que meter en el curriculum. Sólo espero terminar pronto con esto y volver a mi submundo de Java, Linux y Eclipse.
Nota: hasta ahora no he encontrado nada en estas aplicaciones que un equipo de desarrollo de tres personas, a tiempo completo, no puedan tener listo (funcional Beta 1) en 6 meses. Es todo cuestión de barajar costes.
