ASE (Android Scripting Environment) es una aplicación para Android desarrollada por Google gracias a la cual es posible editar y ejecutar scripts en tu terminal móvil. Con este sistema, gran parte de la API de Android, será accesible desde un script. Mediante una capa de interacción JSON RPC implementada en ASE, podremos por ejemplo, realizar llamadas, enviar mensajes o consultar la agenda de teléfonos de nuestros teléfono mediante un secillo script.

Actualmente, ASE da soporte a varios lenguajes de scripting: Python, Ruby o Lua. Como no podía ser de otra manera, desde Irontec echamos de menos el lenguaje de scripting que más utilizamos: PHP. Viendo la potencia de ASE, que permite que cierto tipo de aplicaciones como notificaciones o integraciones sean realizadas rápidamente con lenguajes de scripting, para nosotros era imprescindible que PHP estuviera ahí.

Irontec cuenta con cierta experiencia en el desarrollo de aplicaciones móviles. En los últimos meses, hemos realizado algún proyecto para Android, aunque en el pasado también se han hecho ciertas cosas con J2ME. A día de hoy, la apuesta en cuanto a plataformas móviles que realiza Irontec, se inclina claramente a favor de Android. Con sus limitaciones, es la opción del mercado que más se ajusta a nuestra filosofía. Es obivo que si además de la potencia de Java, disponemos de PHP para llevar a cabo desarrollos medianos, mejor que mejor.

La incidencia para añadir soporte PHP a ASE, lleva abierta más de un año y hasta ahora, no había habido aportación alguna en cuanto a desarrollo, aunque sí muestras de interés por parte de algunos usuarios.

Es por eso que, hacernos cargo de esa incidencia, nos ha parecido un reto interesante, no sólo de cara a futuros desarrollos internos, sino como algo interesante para una parte importante de la comunidad.

Primero ha sido necesario añadir ciertas clases Java que hacen que ASE tenga información acerca de las características particulares de PHP como intérprete (extensión del fichero, valores booleanos, inicio de script…).

Después ha venido la tarea de preparar un ejecutable de PHP. Se ha barajado utilizar Quercus, una implementación de PHP5.2 escrita en Java. A priori puede parecer la opción natural en ASE, viendo que existe soporte a JRuby. Finalmente nos hemos encontrado con bastante problemas en la conversión del bytecode a la máquina virtual de Android: Dalvyk.

Al final, nos hemos decantado por probar con la implementación oficial de PHP. Encontramos una referencia a una guía sobre compilar PHP para Android de Moshe Doron. Desgraciadamente la página web ya no se encontraba disponible ni cacheada así que contactamos con Moshe, y al de unas horas, respondió diciendo que había vuelto a poner la guía online (gracias moshe!). Hemos realizado una compilación cruzada 100% estática de PHP utilizando las herramientas de CodeSourcery. En la guía se realiza una compilación únicamente del core de PHP, pero como mínimo supusimos que necesitaríamos también las extensiones de “json” y “sockets” para poder interactuar con ASE. Esto nos hizo topar con un bug en la versión de producción actual de PHP 5.3 con lo cual por ahora usamos un snapshot del repositorio de PHP.

Superados ambos retos, nos encontramos con las nuevas clases Java que harían que ASE entendiera a PHP y un binario del intérprete PHP funcionando en Android. La nueva dificultad era poder probar el conjunto. Estudiando el mecanismo de ASE, nos damos cuenta de que éste, proveé los intérpretes que el usuario desea. Por esta vía, nos damos cuenta rápidamente de que no hay una forma evidente de probar nuestro conjunto. Es por eso por lo que optamos por fijar manualmente PHP como intérprete soportado en ASE, al igual que lo está una shell que viene instalada por defecto.

En este punto ya podíamos ejecutar scripts sencillos en PHP desde ASE, pero aún seguimos sin acceso a la API de Android. Dicha comunicación, es relativamente sencilla. Simplemente hace falta una capa de comunicación por sockets mediante mensajes JSON. Tirando de las clases análogas en Python y Ruby, hemos entendido el sistema, y portado la clase a PHP.

A estas alturas, podemos decir que hemos conseguido que PHP esté soportado como lenguaje de scripting en las plataformas Android. En próximos días prepararemos el commit, con lo cual esperamos que ASE tenga soporte para PHP pronto. Un granito de arena aportado desde Irontec, para que PHP (posiblemente de los lenguajes de scripting más popular del mundo), esté soportado en terminales Android. Dada la popularidad de PHP, y la expansión del sistema operativo de Google, esperamos que más gente se una al proyecto.

Queremos agradecer desde aquí a Moshe Doron su trabajo en la guía de compilación cruzada de PHP a Android.

Durante el desarrollo de algunos de nuestros proyectos, utilizamos el sistema de archivos distribuido MogileFS, que nos permite replicar automáticamente en varias máquinas los ficheros subidos a nuestra aplicación. Estos ficheros se replican en servidores WebDAV, de manera que posteriormente podemos acceder a los mismos mediante una petición HTTP.

El acceso a MogileFS es realmente sencillo y los conceptos previos que necesitamos saber para utilizarlo son pocos:

• Servidor: Máquina donde se encuentra escuchando el tracker de MogileFS.
• Puerto: Puerto dónde escucha el tracker de MogileFS
• Dominio: Nombre de la aplicación que está tratando de acceder a MogileFS. Un mismo servidor de Mogile puede almacenar varios dominios diferentes, teniendo cada uno de ellos sus propios archivos, de esta manera se evitan conflictos entre aplicaciones.
• Clave: Nombre único del archivo dentro de un dominio de MogileFS. Hay que tener en cuenta que no existen directorios, por lo que los nombres de los archivos deben ser únicos.
• Clase: Importancia del archivo. MogileFS puede generar un número diferente de replicas de los archivos dependiendo del tipo (o clase) al que pertenecen los mismos. Estas clases también son únicas por Dominio.

Para la realización del Frontend Web, una vez más nos decantamos por PHP y nos encontramos con que ya existe una extensión PECL escrita en C (MogileFS for PHP) que nos facilita el acceso a este sistema de archivos.

Funcionamiento de MogileFS for PHP

Conectarse a MogileFS

$client = new MogileFs();
$client->connect($servidor, $puerto, $dominio);

Subir un fichero a MogileFS

$client->put('/path/a/fichero.odt', 'claveParaMogile', 'clase1');

Obtener un fichero de MogileFS

Como MogileFS puede almacenar el fichero en varios lugares, lo que obtenemos en realidad es un array con las distintas rutas donde se encuentra el fichero. Como ya hemos comentado, realmente estas rutas son direcciones http.

$aPaths = $client->get('claveParaMogile');
if ($aPaths['paths'] > 0) {
    file_put_contents('/path/a/ficheroRecuperado', $aPaths['path1']);
}

¿Problemas con ficheros grandes? Solucionado!

Durante la utilización de esta extensión de PHP, nos hemos encontrado con un grave problema. Necesitábamos que nuestras aplicaciones soportasen archivos realmente grandes (del orden de varios gigas), y una vez que habíamos configurado MogileFS correctamente para que soportase los ficheros grandes sin problemas, nos hemos dado cuenta de que la extensión de PHP tenía un problema: Para enviar un archivo al servidor de Mogile, alojaba el mismo en memoria. Obviamente esto no es un problema con archivos de 2, 10 o incluso 50Mb, pero si queremos enviar archivos de varios Gigas hace que el sistema sea intratable.

En este punto nos quedaban 3 opciones:

• buscar una alternativa a MogileFS
• buscar una alternativa a “MogileFS for PHP” (existen clases escritas en  PHP)
• solucionar el problema de “MogileFS for PHP”

En Irontec tras echar un vistazo al código del PECL, nos hemos decantado por la tercera opción, ya que creíamos que la solución era factible, no queríamos modificar el código que ya teníamos funcionando (si funciona no lo toques :p) y además creíamos que la extensión era suficientemente interesante como para dejarla de lado, así que decidimos contribuir en el proyecto aportando nuestro granito de arena.

El problema del PECL era que el archivo se cargaba en memoria para poder enviar el contenido a través de la función ne_set_request_body_buffer de libneon, asi que la solución pasaba por encontrar una función de la misma librería que realizase esto mismo pero pasándole un descriptor de fichero en lugar de un bloque de datos. Buscando en la  documentación/cabeceras de libneon nos encontramos con la funcion ne_put, asi que modificamos el código (simplificándolo notablemente), comprobamos que pasaba los tests del PECL (make test) y enviamos las modificaciones al creador de la extensión: Lars Strojny.

Al cabo de un día ya nos había respondido dándonos las gracias por la modificación. Y al cabo de una semana ya tenemos la modificación subida al trunk del proyecto, por lo que cualquiera que necesite de esta mejora no tiene más que descargar la última revisión desde el servidor svn del proyecto.

Y como algo así nos llena de orgullo, os dejamos un enlace al Changeset de la revisión en la que se subió nuestra modificación: La revisión 216.

Por último no queremos olvidarnos de dar la gracias a Lars por su trabajo.

Gracias Lars!

En todos los gestores de contenido, desde Wordpress, a Drupal pasando por nuestro Karma, se vienen utilizando editores HTML para la fácil creación de contenidos dinámicos enriquecidos en las páginas web de nuestros clientes. Esto ayuda mucho a los administradores de las webs, ya que muchos de ellos no suelen tener experiencia de maquetación HTML.

Todos estos editores de HTML, hacen uso del atributo “content-editable” implementado en el TAG iframe en la mayoría de los navegadores modernos desde hace varios años ya. En realidad, el código HTML generado, es responsabilidad de cada navegador en concreto (y ciertamente no lo hacen del todo compatible con los estándares), por lo que el trabajo de estos editores, será limpiar el código que cada navegador genera. Habrá que esperar a HTML 5 para tener el atributo conteneditable disponible en más elementos HTML, y esperemos implementado de manera más limpia.

Antes de entrar a analizar los editores elegidos, es importante separar los dos grandes grupos de editores que encontramos en el mercado:

• WYSIWYG (What You See Is What You Get – Obtienes lo que ves): Estos editores mostrarán al usuario una imagen lo más cercana a la realidad.
• WYSIWYM (What You See Is What You Meant – Obtienes lo que querías decir): Aunque mucho menos gráficos y más orientados a usuarios con cierto conocimiento de lenguaje de marcado, se obtiene un resultado mucho más limpio.

(más…)

En el desarrollo de muchos proyectos ha surgido varias veces la necesidad de insertar distintos widgets en Blogs desarrollados con Wordpress que leyeran contenidos de otros sites mediante RSS. Esto nunca ha tenido más dificultad que utilizar uno o varios plugins de Wordpress ya existentes y configurarlos para que se adaptaran a nuestras necesidades.

Desde un punto de vista comercial o corporativo es interesante facilitar el que otros lugares Web puedan mostrar el contenido de tu site de la manera más cómoda, rápida y sencilla, y ofrecerles un conjunto de herramientas y utilidades para ello.

Por esta razón hemos creado un plugin para Wordpress que agrupa varios Widgets con contenidos de otro site y ofrece una página de configuración sencilla que permite poner los Widgets en un blog con no más trabajo o dedicación que la instalación del plugin y la colocación de los Widgets.

Este plugin en sí está programado para mostrar en Blogs mediante Widgets los contenidos de la Comunidad Vasca de Innovadores (el resultado se puede ver en blog.comunidadvascainnovadores.net):

El fichero del plugin que deberíamos modificar para adaptar el contenido a otros sites es class.cvi.php:

Aquí se definen los widgets que se van a cargar:

Método: widgets();

	static public function widgets(){

		register_sidebar_widget(__('Propuestas por el bien común',CVI_TEXT_DOMAIN), array('cvi','cvi_retos_comun_widget'));

		register_sidebar_widget(__('Retos con recompensa',CVI_TEXT_DOMAIN), array('cvi','cvi_retos_recompensa_widget'));

		register_sidebar_widget(__('Grupos 2.0',CVI_TEXT_DOMAIN), array('cvi','cvi_grupos_widget'));
	}

Aquí está la configuración básica de cada Widget:

Método: identify();

	    switch ($q) {
	        case "cvi_retos_comun_widget":
	            $this->conf['feed'] = 'http://www.comunidadvascainnovadores.net/pg/mercado_ideas/retos_para_el_bien_comun/r00?view=rss&language='.$lang;
	            $this->conf['limit'] = get_option('limit_cvi_retos_comun_widget',3);
	            $this->conf['showIcon'] = get_option('icon_cvi_retos_comun_widget',3);
	            $this->conf['title'] = __('Propuestas por el bien común',CVI_TEXT_DOMAIN);

                break;
            case "cvi_retos_recompensa_widget":
                $this->conf['feed'] = 'http://www.comunidadvascainnovadores.net/pg/mercado_ideas/retos_con_recompensa/r01?view=rss&language='.$lang;
                $this->conf['limit'] = get_option('limit_cvi_retos_recompensa_widget',3);
                $this->conf['showIcon'] = get_option('icon_cvi_retos_recompensa_widget',3);
                $this->conf['title'] = __('Retos con recompensa',CVI_TEXT_DOMAIN);

                break;
            case "cvi_grupos_widget":
                $this->conf['feed'] = 'http://www.comunidadvascainnovadores.net/pg/groups/world/?view=rss&language='.$lang;
                $this->conf['limit'] = get_option('limit_cvi_grupos_widget',3);
                $this->conf['showIcon'] = get_option('icon_cvi_grupos_widget','1');
                $this->conf['title'] = __('Grupos 2.0',CVI_TEXT_DOMAIN);

                break;
	    }

Los nombres de las funciones, ficheros, … los podemos adaptar al site mediante sed:

sed -i 's/cvi/nuevo_proyecto/g' ./*

Descargar aquí:

cvi-widgets (v1.0)

El plugin wordtwit para wordpress es uno de los mejores para subir directamente a Twitter los títulos y los enlaces de las entradas de wordpress. Por otro lado el plugin qtranslate es el mejor en su campo, el cual es permitir al usuario que transforme su sitio wordpress en un sitio multilenguaje con traducciones manuales.

No obstante, si algún desarrollador o usuario de wordpress ha probado estos dos plugins simultáneamente ya se habrá percatado de que no son compatibles. El plugin qtranslate añade a los títulos de las entradas de wordpress una etiqueta especifica para diferenciar entre los idiomas. Y el plugin wordtwit twittea directamente el titulo con las etiquetas que el plugin qtranslate le añade.

Así que ha sido necesario desarrollar e implementar una nueva opción para el plugin wordtwit para solucionar este problema.

Lo que hice fue modificar la Versión 2.3.2 de wordtwit para que fuera compatible con qtranslate y además sea posible elegir el idioma con el usuario quiere que se twitteen sus entradas de wordpress.

Podéis descargarlo aquí.

Uno de los puntos comunes que aparecen en casi todas las implantaciones de SugarCRM que acometemos desde Irontec es la necesidad de realizar acciones cuando se crea, modifica o borra un registro de la herramienta. Para cubrir esta necesidad SugarCRM implementa un sistema llamado “Logic Hooks“. Este tipo de lógicas nos permitirán implementar nuestras propias acciones que se “dispararán” cuando ocurra un evento en el CRM. En el caso que voy a explicar a continuación trabajaré con el módulo de oportunidades. La necesidad concreta era recibir un email en una lista de correo corporativa cuando se crea o modifica una oportunidad del CRM. Además, en el caso de la modificación, era importante saber que campos concretamente han cambiado.

Los “Logic Hooks” se ubican dentro de la carpeta custom de forma que serán llamados por SugarBean durante la ejecución del CRM. Por lo tanto lo primero que tendremos que hacer es crear un fichero logic_hooks.php en la siguiente ruta.

RUTA AL CRM/custom/modules/Opportunities

El contenido del fichero será el siguiente:

$hook_version = 1;
$hook_array['before_save'][] = Array(1,"enviar_email","custom/modules/Opportunities/Opportunities_Hook.php","Opportunities_Hook","enviar_email");

En primer indicamos la versión del sistema de hooks. De momento solo está soportada la versión 1 así que es fácil saber que poner . A continuación se define el hook_array. Se trata de un array bidimensional que contiene:

• Nombre del evento que va a disparar el hook
• Array que contiene los parámetros necesarios para lanzar el hook

En nuestro caso el evento que disparará el hook es “before_save” que se lanza justo antes de salvar. Utilizamos este evento por que nos permite que se ejecute justo antes de hacer la insert o update en la base de datos. De esta manera podré hacer operaciones con los datos que envío en el formulario y con los datos que tenía en la base de datos antes de salvar. El listado completo de eventos que pueden disparar un hook puede consultarse en la documentación del desarrollador de sugarCRM.

Los parámetros que pasaremos son:

• 1 = Se trata de un índice. Lo pasamos a 1
• “enviar_email” se trata del nombre del hook. Sirve solo para identificar el hook.
• “custom/modules/Opportunities/Opportunities_Hook.php” es el fichero que contendrá nuestra acción personalizada
• “Opportunities_Hook” el nombre de la clase dentro del fichero Opportunities_Hook.php.
• “enviar_email” nombre del método a ejecutar dentro de la clase Opportunities_Hook.

En segundo fichero que necesitaremos será Opportunities_Hook.php cuyo contenido es el siguiente. Explico el contenido del fichero con comentarios dentro del propio código por simplificar el post:

class Opportunities_Hook{
//Defino la clase que voy a llamar por parámetro cuando lanze el hook
//Defino la función enviar_mail que recibirá por referencia el $bean que vamos a salvar, el evento que en nuestro caso recibira "before_save" y los argumentos especificos del evento que no vamos a usar en este ejemplo

	function enviar_email(&$bean, $event, $arguments){
		global $current_user;
		require_once("include/SugarPHPMailer.php");

		//Obtengo los datos de antes de salvar creando un Bean con los datos de la base de datos.
		$oldOpp = new Opportunity();
		//$bean contiene el nuevo bean, pero en caso de estar modificando la base de datos el ID viejo y el nuevo deben ser el mismo.
		$oldOpp->retrieve($bean->id);

               //Preparo el cuerpo del email de notificación
		$nuevo = false;
		if ($oldOpp->amount==NULL) {
		//el nombre de la oportunidad es obligatorio, por lo tanto si es NULL significa que es una oportunidad nueva y me preparo los textos en consecuencia
			$html = "Oportunidad nueva en iCRM. A continuación puedes ver los detalles:";
			$nuevo = true;
			$estado_msg = "new";
		} else {
			$html = "Oportunidad modificada en iCRM. A continuación puedes ver los detalles. Los campos marcados con * son los que han cambiado:";
			$estado_msg = "mod";
		}

		$html .= "Creado por: ".$current_user->full_name;

		//Todas estas IF son para saber si el campo está modificado o es nuevo. En caso de ser modificado lo marco con *
		$html .= "Nombre oportunidad";
		if ($bean->name!=$oldOpp->name and $nuevo==false) $html .= "*";
		$html .= ": ".$bean->name;

		$html .= "Nombre cuenta";
		if ($bean->account_name!=$oldOpp->account_name and $nuevo==false) $html .= "*";
		$html .= ": ".$bean->account_name;

		$html .= "Estado";
		if ($bean->sales_stage!=$oldOpp->sales_stage and $nuevo==false) $html .= "*";
		$html .= ": ".$bean->sales_stage;

		$html .= "Cantidad";
		if ($bean->amount!=$oldOpp->amount and $nuevo==false) $html .= "*";
		$html .= ": ".$bean->amount." euros";

		$html .= "Fecha de cierre";
		if ($bean->date_closed!=$oldOpp->date_closed and $nuevo==false) $html .= "*";
		$html .= ": ".$bean->date_closed;

		$html .= "/index.php?module=Opportunities&action=DetailView&record=".$bean->id."\">Haz click aquí para ver la oportunidad";
		$html .= "Descripcion";
		if ($bean->description!=$oldOpp->description and $nuevo==false) $html .= "*";
		$html .= ":".$bean->description;
		//Preparo el mail
		$notify_mail = new SugarPHPMailer();
		$notify_mail->isHTML(true);
		$notify_mail->CharSet = "UTF-8";

		$notify_mail->AddBCC("LISTACORPORATIVO@dominio.com","Nombre del destinatario del correo");
		$notify_mail->From = "no-reply@irontec.com";
		$notify_mail->FromName = "Sistema de notificación del SugarCRM";
		$notify_mail->Body = from_html($html);
		$notify_mail->Subject = "[iCRM]Oportunidad ".$estado_msg.": ".$bean->name." ";

		//Finalmente mando la notificación por email
		$notify_mail->Send();

	}
}

Documentación adicional:

Documentación de HOOKS en la documentación de SugarCRM

Digamos que tenemos un sitio Web (tipo red social)  donde al usuario, en el registro o en la zona de administración de su cuenta donde modifica sus datos, se le da la opción de geolocalizarse, así como para molar más, y una base de datos o servicio de geolocalización de mediante IPs.

¿Qué hacemos con esto?

Podemos decirle al usuario de dónde es – nos lo ha dicho él, osea que, vaya, qué guay – o también desde donde accede (más o menos) aunque él ya lo sepa; o aprovechar lo que aprendimos de pequeños sobre trigonometría y decirle cuáles son sus amiguitos más cercanos o incluso – cruzando datos con una base de datos de aeropuertos – decirle cuál es su aeropuerto más cercano tirando de MySql.

(más…)

Esta pregunta me planteaba el otro día en Irontec, ante la necesidad de diseñar un menú con multitud de opciones en una sola linea. Estaba en pleno desarrollo de un proyecto para una empresa y las opciones del menú no cabían, ni de cerca, en el diseño entregado por los diseñadores, ya que las opciones del mismo podían ser ilimitadas (requerimientos del cliente).

Me puse a buscar y evaluar diferentes soluciones, pero ninguna se adaptaba exactamente a las necesidades que tenía: compatibilidad con todos los navegadores modernos, que pesara poco y que fuera ligero. Así pues, decidí implementar nuestro propio sistema de menús y paginado.

Horizon Menú es un plugin para jQuery desarrollado para dar solución a esta problemática. En un espacio delimitado por un ancho fijo metemos las opciones del menú de forma que se puedan deslizar horizontalmente mediante eventos de ratón, como scroll, mouseover y mousedown.

Podéis ver el resultado del plugin en http://www.damepista.com/noticias (en la parte superior derecha como menú de categorías y en la inferior como paginado).

También podéis ver otra demo con más funcionalidades aquí o descargar el código del mismo y hacer vuestros experimentos.

Ha llegado a mis manos un relé para un pequeño proyecto en el que andamos inmersos. Concretamente un USB-RLY08 S310240 . Es bastante cómodo, sobre todo la interfaz USB que evita tener que utilizar un incómodo adaptador de corriente. En principio soporta 1A por relé, es decir sobre 220W a 220V (si mis escasas nociones no me fallan), más que suficiente para realizar proyectos modestos.

Viendo que desde el sitio web donde lo compré, sólo me daban el código fuente de un programa escrito en visual basic, me he visto en la necesidad de tener que hacérmelo yo mismo.

(más…)

Se nos acaba de presentar un proyecto para el envío de ficheros desde un host a dispositivos móviles por medio de protocolo bluetooth. Protocolos obex aparte (eso es otra historia), nos veíamos en la necesidad de conocer la marca del móvil destino antes de enviar el contenido, así que tras destripar las herramientas hcitool y sdptool, nos hemos encontrado con que un móvil no te dice claramente de que marca es, al menos, mediante ningún protocolo bluetooth.

¿Cómo saber la marca de un móvil conociendo sólo su dirección MAC bluetooth?

(más…)