Liberando CSAcademia como proyecto open source... 5 años después y 6.000€ de menos

CSAcademia es una herramienta para gestionar la información de profesores y estudiantes de una academia. El nombre no es muy original pero el software funciona, lleva en uso 5 años... y ahora es open source.

¿Cómo se nos ocurrió hacer un software de gestión académica?

Este proyecto comenzó al final del verano del 2012, con la solicitud de un posible cliente que quería remplazar el ya obsoleto software de gestión de su academia. Una vez entendidas sus necesidades y visto el software existente, hicimos una propuesta de remplazo con un plan de entrega y un presupuesto ajustados. Sin embargo, dado que el curso académico había comenzado recientemente, no llegamos a ningún acuerdo hasta el final del invierno, en Marzo del 2013.

Hicimos el primer commit el 12 de marzo de 2013. Durante los siguientes meses trabajamos dos personas unas 10 o 12 horas por semana (cada una), principalmente por las noches y los fines de semana. Cinco meses después, a finales de agosto, teníamos una versión del sistema funcionando y con datos de la primera academia. De modo que se empezó a usar con el comienzo del curso académico de 2013 - 2014, en paralelo con el sistema existente, para ir reemplazándolo poco a poco.

Actualmente es una herramienta de uso diario en la academia Dundee School of English.

Módulo de gestión de profesores

¿Cuánto ganamos con este software por encargo?

La idea inicial no era ganar dinero con la "venta" del sistema, sino cobrar lo suficiente para motivarnos y amortizar parcialmente el esfuerzo de desarrollo, con la esperanza de generar ingresos a largo plazo. Pretendíamos promocionar la aplicación entre otras academias y cobrar una cuota por uso. Por eso hicimos el ejercicio de estimar el esfuerzo y luego lo ajustamos a la baja y, por si fuera poco, añadimos una rebaja significativa. Pedimos finalmente 3.280 €, a pagar en 3 plazos de 40% al inicio del desarrollo, 40% con la puesta en marcha y 20% al finalizar la formación del personal que usaría el sistema.

Volumen de trabajo estimado por mes,
según Gitential.com, en base a los commits

Tardamos 6 meses en tener el software suficientemente completo y casi un año en terminar los pequeños ajustes y solicitudes que aparecieron sobre la marcha. Durante los primeros meses, acumulamos unas 480 horas de trabajo que, estimadas a 20 € la hora, resultaría en un esfuerzo de unos 9.600 €.

Nunca recuperamos ese dinero.

Ninguna otra academia se enteró de la existencia del sistema así que nuestros ingresos fueron los acordados inicialmente con el cliente. Con el tiempo, añadimos algún que otro módulo que cobramos también a precios ridículamente bajos porque siempre albergamos la esperanza de licenciar el uso a otros centros.

De modo que, financieramente hablando, perdimos dinero con este software.

Pasando a ser Open Source

Después de reflexionar sobre las ventajas y consultarlo con nuestro (primer y único) cliente, decidimos hacer público el código fuente del sistema. El objetivo principal es ponerlo a disposición de cualquiera que pudiera necesitarlo y facilitar las aportaciones de colaboradores para garantizar la evolución y el mantenimiento del mismo. Hoy CSAcademia está disponible en GitHub:

https://github.com/casabesoft/csacademia

No ha sido un camino de rosas. Publicar el código nos trajo algunos problemas y preparar el repo para hacerlo público ha costado varias noches y fines de semanas durante los últimos cinco meses.

Pero ahí está, con una lista de 19 issues abiertos, listo para seguir recibiendo amor. Así que si eres desarrollador y quieres colaborar puedes empezar leyendo la sección de Contributions.

Si no sabes programar, pero has llegado hasta aquí buscando un software para tu academia o centro de estudios, adelante: es gratis y libre para su uso comercial sin coste alguno. Además estaremos encantados de ayudarte para que puedas ponerlo a punto y usarlo.

No obstante, si no tienes el tiempo, los recursos o el conocimiento para instalarlo y prefieres una solución lista para ser usada, prueba con https://academia.casabesoft.com; daremos de alta tu centro y en unos minutos podrás empezar a probar.

En cualquier caso... ¡Que aproveche!

Liberando VirtualMenu como proyecto open source

VirtualMenu es un software para la gestión de parte de un servicio de catering como la gestión de platos, planificación de menús y recogida de pedidos.

Diseño de un menú del día

VirtualMenu surgió en la primavera del 2012, como una prueba de concepto para un restaurante que tenía un servicio de catering cuya oferta del menú se hacía por correo electrónico para recibir posteriormente los pedidos por e-mail o teléfono. Por supuesto, el uso de distintos canales y la falta de automatización provocaba confusión en los clientes y problemas de gestión del restaurante generando pedidos erróneos y algún que otro olvido.

El desarrollo lo hicimos entre 2 personas, en unas 2 semanas, distribuidas a lo largo de 3 meses: unas 160 horas de trabajo que, estimadas a 20 € la hora, resultaría en un prototipo de 3200 €... que nunca se llegó a utilizar.

No obstante, 5 años después, hemos decidido sacar del olvido este producto pues la necesidad que lo hizo nacer sigue existiendo. Hoy, sin embargo, resurge como un proyecto abierto y gratuito. Disponible para su descarga y evolución en GitHub:

https://github.com/casabesoft/virtualmenu

Así que, si eres diseñador, programador o tienes cualquier idea y quieres colaborar: bienvenido, hace falta mucho trabajo para actualizar y "embellecer" un producto que no se había tocado en 5 años.

Igualmente, si tienes un restaurante o una empresa de catering y estás interesado en usarlo, adelante: es gratis, puedes descargarlo, usarlo con fines comerciales y hacer lo que mejor estimes conveniente.

¿Qué tiene que ver Cristobal Colón con la programación?

Detalle de
"First landing of Columbus..."

Ada Lovelace es considerada la primera programadora de la historia y nació 3 siglos después que Colón entonces... ¿qué vínculo tiene el descubridor de América con la informática?

La verdad es que no tiene ningún vínculo directo, salvo el deseo expreso de la editorial Packt Publishing de “celebrar” el Colombus Day, Día de la raza o Día de la Hispanidad con un descuento del 50% en todos los libros electrónicos y en todo su catálogo de vídeos.

Packt es una editorial especializada en informática y proyectos Open Source de la que hemos comentado en alguna ocasión libros como Open Layers Cookbook e Instant OpenLayers Starter, de modo que no está de más echarle un vistazo a su catálogo y aprovechar la oportunidad de conseguir más baratos esos libros que hace tiempo queremos comprar.

El descuento se podrá aplicar a todas las compras que se hagan hasta el día 17 de octubre, entrando en www.packtpub.com y utilizando el código COL50.

Instant OpenLayers Starter

Portada del libro
Instant OpenLayers Starter

Hoy terminé de leer el libro Instant OpenLayers Starter, una introducción a OpenLayers que, en muy poco espacio, ofrece una visión global para iniciarse rápidamente en el uso de esta biblioteca para cartografía Web.

¿Por qué otro libro de OpenLayers?

Hace unos meses comentaba sobre un libro de OpenLayers que reúne 60 recetas para realizar tareas comunes en el desarrollo de aplicaciones Web que incluyan mapas y funciones de cartografía, en general. ¿Entonces, por qué otro libro de OpenLayers?

Instant OpenLayers Starter tiene un enfoque diferente: es un libro corto, donde casi la mitad está escrita como un tutorial paso a paso, y la otra mitad son recetas -también cortas- que incluyen algunas funcionalidades útiles o de uso frecuente. De modo que, si se tiene muy poco tiempo y se necesita una visión inmediata de qué es OpenLayers, cómo comenzar a usarlo y cómo utilizar las funcionalidades más comunes para hacer una aplicación de mapas Web básica, Instant OpenLayers Starter es una buena guía introductoria.

¿Cuál leer entonces?

Si se cuenta con suficiente tiempo, leer OpenLayers Cookbook u OpenLayers 2.10 Beginner's Guide aportaría un conocimiento más detallado de OpenLayers; pero si el objetivo es explorar y evaluar esta biblioteca en poco tiempo, Instant OpenLayers Starters podría ser una mejor opción porque es igual de práctico que el primero, pero más corto que los otros dos; tanto así, que en un día se puede pasar de no saber nada de OpenLayers, a crear unos mapas básicos pero funcionales.

OpenLayers Cookbook

Portada del libro
OpenLayers Cookbook

Hace algún tiempo puse en la lista de proyectos pendientes, migrar una aplicación Web con cartografía basada en las APIs de Google Maps a las APIs de OpenLayers. De modo que estaba leyendo el libro "OpenLayers 2.10 Beginner's Guide", cuando calló en mis manos "OpenLayers Cookbook".

OpenLayers Cookbook. 60 recipes to create GIS web applications with the open source JavaScript library

Como su nombre lo indica, este libro hace una recopilación de 60 recetas que podrían ser de utilidad en la creación de Sistemas de Información Geográfica (SIG), mediante una de las bibliotecas de JavaScript más completas para estos fines: OpenLayers.

Aunque el libro tiene un enfoque esencialmente práctico, no es necesario tener conocimientos previos de OpenLayers pues los conceptos y funcionalidades son introducidos progresivamente con cada receta: el libro comienza ilustrando los conceptos básicos de cartografía Web mediante la resolución de problemas sencillos y termina con temas mucho más complejos, como la creación de componentes personalizados. De modo que no importa si sabes mucho o poco de OpenLayers: si sabes poco, aprenderás leyendo cada capítulo, ordenadamente; y si sabes mucho, el libro te servirá como una colección de soluciones a problemas prácticos y concretos en el día a día de la creación de sistemas con cartografía Web.

HTML, CSS, JavaScript y algo más

Lamentablemente, los Sistemas de Información Geográfica implican demasiados elementos como para crear soluciones triviales. Por eso, aunque la lectura y comprensión de las 60 fórmulas solo requiere el conocimiento de HTML, CSS y JavaScript; la puesta en práctica y prueba de las recetas también requiere entender -aunque a un nivel muy básico- algo de Apache, PHP y el uso de widgets de Dojo, si se quiere implementar las soluciones tal cual se dan en el libro. No obstante, es relativamente simple modificar las recetas para eliminar la dependencia de Dojo y, si se conocen otros servidores Web (como IIS o Tomcat) y otras tecnologías para el desarrollo del backend (como ASP.NET o JSP), es también bastante fácil adaptar las soluciones dadas para que funcionen con estas otras herramientas.

Entonces...

El enfoque práctico del libro lo hace atractivo, instructivo y útil; cuya lectura da frutos desde las primeras páginas porque desde el principio nos hace sentir capaces de resolver problemas concretos. Así que, si tienes poco o ningún conocimiento de OpenLayers y necesitas empezar a utilizarlo, o ya estás utilizando OpenLayers y necesitas acelerar tus resultados, o simplemente estás aburrido de los libros y tutoriales cargados de tecnicismos y quieres algo más práctico... entonces... este libro es para ti.

Aplicación en modo kiosko para Android

Hace un tiempo tuve que migrar una aplicación de Windows Mobile a Android. En sentido general el desarrollo en Android fue más simple y más rápido; pero cuando llegué al punto de duplicar el comportamiento del "modo kiosko", Android se tornó casi tan arisco como Windows Mobile. Aquí publico hoy la solución que apliqué para que sirva de base a otros desarrollos.

No es que hacer una aplicación que se ejecute en modo kiosko en Windows Mobile sea simple. De hecho lograr que la aplicación se mantuviera siempre en primer plano bloqueando los botones de hardware del teléfono fue toda una odisea que necesitó alguna chapucilla código particularizado para cubrir limitaciones (como que en los teléfonos Samsung se nos estaba vetado deshabilitar el botón de la cámara -según nos confirmaron desde Samsung- y, por tanto, cada vez que se pulsaba el botón de la cámara la aplicación perdía el foco).

Los teléfonos con Android, por suerte, tienen unas APIs más uniformes, pero no por esto el modo kiosko deja de ser un reto. Para comenzar, no encontré ningún lugar donde pusieran en claro qué hacer para que una interfaz se mantuviera en primer plano y a pantalla completa, independientemente de la interacción que tuviera el usuario con el dispositivo. Debido a que la información que encontré era incompleta y estaba dispersa, hoy pongo aquí el resumen de lo necesario para crear una aplicación que se ejecute en modo kiosko, acompañado del código fuente de un proyecto sobre el que se puede partir para hacer una aplicación que ya satisface estos requisitos.

Para comenzar, una aplicación en modo kiosko en Android debe:

1. Mostrarse a pantalla completa, de modo que el usuario no se salga de la aplicación accediendo a otras opciones que aparezcan en la zona de notificaciones, en la barra de título.
2. Bloquear los soft buttons y botones de hardware, de modo que el usuario no pueda salirse de la aplicacion presionando el botón back ni se interrumpa la aplicación por la presión de otros botones como el control del volumen.
3. Remplazar el home del dispositivo por la pantalla inicial de la aplicación, de modo que, al presionar el botón "home" (que lamentablemente no puede ser interceptado, como el resto de botones) en lugar de salir de la aplicación para mostrar la pantalla de inicio del teléfono, se muestre la aplicación y se pueda restablecer la interfaz al punto donde se estaba.

Debo puntualizar que esta solución no es La Solución para todas las aplicaciones que requieran ejecutarse en modo kiosko pues cada una puede requerir un mayor o menor grado de control. Sin embargo, la esencia de dicho control puede obtenerse haciendo que las actividades de nuestra aplicación extiendan la clase KioskModeActivity cuyo código es el siguiente:

package org.carlosbello.android.kioskmode;

import android.app.Activity;
import android.os.Bundle;
import android.view.KeyEvent;
import android.view.Window;
import android.view.WindowManager;

/**
 * Actividad de base para crear interfaces en modo kiosko.
 * @author Carlos Bello
 */
public class KioskModeActivity extends Activity {
    /** Indica si deberá desactivarse el uso del botón de retroceso. */
    protected boolean blockBackButton = false;
    
    /**
     * Establece la visualización a pantalla completa para evitar una salida 
     * accidental a través de la barra de título o cualquier otro elemento 
     * interactivo que no sea nuestra propia interfaz.
     */
    @Override
    public void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        requestWindowFeature(Window.FEATURE_NO_TITLE);
        getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,
                WindowManager.LayoutParams.FLAG_FULLSCREEN);
    }
    
    /**
     * Intercepta los eventos del teclado para evitar la interacción con 
     * cualquier elemento que no forme parte de nuestra interfaz, salvo la 
     * funcionalidad del botón de retroceso, si estuviera habilitado.
     */    
    @Override
    public boolean onKeyDown(int keyCode, KeyEvent event)  {
        return !blockBackButton && keyCode == KeyEvent.KEYCODE_BACK
            ? super.onKeyDown(keyCode, event)
            : true;
    }
}

Ahora, para evitar salirse de la aplicación, la actividad inicial deberá establecer blockBackButton a true y registrarse en el manifiesto del proyecto con la categoría HOME; de modo que si reiniciamos el terminal se abrirá nuestra aplicación primero que cualquier otra y al pulsar el botón home se mostrará siempre nuestra aplicación.

Claro que convertir nuestra aplicación en el home del sistema trae como consecuencia que si queremos salir de la aplicación, terminaremos entrando en ella nuevamente pues el home del sistema es nuestra propia aplicación. De hecho, ese es parte del objetivo: que si nos salimos por accidente de la aplicación, ésta se abra automáticamente. Este "inconveniente" puede sortearse buscando otra aplicación que pueda funcionar como home y abriéndola explícitamente.

Como el código para hacer esta búsqueda es algo más extenso, dejo en el siguiente enlace un proyecto de ejemplo de una aplicación que puede ejecutarse en en modo kiosko:
http://ejectodemo.googlecode.com/files/20120227_AndroidKioskMode.zip

Update: desde agosto de 2014 el código está disponible en GitHub:
https://github.com/carlosbello/efectodemo/tree/master/AndroidKioskMode

Atención: Debe tenerse en cuenta que si durante la ejecución de la aplicación se presiona el botón home y se marca la casilla de "Usar por defecto" se reescribirá la pantalla home del sistema y se necesitará eliminar los valores por defecto, almacenados para la aplicación AndroidKioskMode o desinstalarla para restablecer el home original.

Bueno, esto es todo. Agradeceré cualquier colaboración que mejore esta solución o plantee una solución diferente.