Uhuru Labs

rsync es una aplicación que se puede encontrar en vuestros sistemas Linux, MacOS o  Windows y que permite sincronizar archivos y directorios entre dos máquinas de una red o entre dos carpetas de una misma máquina. Su uso es sencillo y es ideal para mantener al día copias de elementos utilizados por varias personas,  hacer copias de seguridad de nuestros datos de manera rápida y segura o mantener actualizada nuestra página web.
Puede funcionar de dos maneras:

1. Instalando un daemon (un servicio) en nuestro servidor (donde tenemos los elementos a sincronizar) al cual accederemos mediante el protocolo rsync.
2. Mediante un terminar remoto como SSH

Caso 1.El objetivo es instalar un daemon en nuestro servidor que atienda las peticiones de sincronización. Para ello los pasos a seguir son:

1.a) Instalar rsync. En general viene instalado de serie, y más en una versión server de Ubuntu, pero si no fuera así simplemente instálalo con Synaptic o mediante:

sudo apt-get install rsync

1.b) Hay que crear el fichero de configuración del daemon “/etc/rsyncd.conf”. En él definimos las caracterísiticas generales de la conexión, así como las de cada uno de los módulos o,  para definirlo mejor, las posibles ubicaciones de sincronización. El fichero tendrá una forma similar a esta

max connections = 2
log file = /var/log/rsync.log
timeout = 300

    [nombremodulo1]
    comment = Carpeta de documentos personales sobre Linux
    path = /carpeta/sobre/la/que/sincronizo/los/documentos/personales
    read only = yes
    list = yes
    uid = usuario1
    gid = usuario1  
    auth users = usuario1
    secrets file = /etc/rsyncd.secrets

    [nombremodulo2]
    comment = Carpeta de documentos Uhuru
    path = /carpeta/sobre/la/que/sincronizo/los/documentos/uhuru
    read only = yes   
    list = yes   
    uid = nobody
    gid = nogroup   
    auth users = usuario1 usuario2
    secrets file = /etc/rsyncd.secrets

Al principio del fichero se definen aquellas características generales de la conexión. En este caso aparecen el número de conexiones simultáneas, donde se va a ubicar el fichero log y el tiempo máximo de espera. En esta parte es posible indicar también algunas de las características que aparecen en los módulos para que todos ellos la hereden (salvo que se redefinan dentro de uno en concreto). Por ejemplo, en el código anterior, podríamos haber escrito en las características generales la configuración de secrets file o la opción list, ya que su valor es común para todos los módulos.

A continuación aparecen la definición y características del módulo. Los elementos más importantes son:

• comment: un comentario sobre que se sincroniza con ese módulo.
• path: el camino completo de la ubicación.
• uid: nombre del usuario con el que rsync realizar las acciones.
• gid: grupo con el que rsync realizará las acciones.
• auth users: usuarios a los que se les está permitido la sincronización. Estos usuario en principio no tiene porque coincidir con ningún usuario del sistema.
• secrets file: lo vemos en el apartado siguiente.

1.c)  Crear el fichero “/etc/.rsyncd.secrets”. Este fichero almacena parejas usuario:contraseña, que hacen relación a los usuarios definidos en el fichero “/etc/rsyncd.conf”. En nuestro caso podría ser algo como esto:

usuario1:mipassword1
usuario2:mipassword2

Obviamente este fichero, al ser texto plano,  ha de ser protegido contra “mirones”, ya que en caso contrario nuestras contraseñas quedan fácilmente accesibles. Es más rsync ni siquiera funcionará si no asignamos unos permisos adecuados a este fichero. Para ello:

sudo chmod 600 /etc/rsyncd.secrets

Es decir, el propietario debe ser el root y sólo puede ser leído por él.

1.d) Una vez configurado, sólo nos queda arrancarlo. Para ello lo mejor es utilizar xinetd, otro de los demonios que podemos encontrar en linux y que permite gestionar las conexiones de otros demonios bajo demanda.

Para ello lo primero es instalarlo (si es que no lo tienes aún):

sudo apt-get install xinetd

1.e) Configurar xinetd. Si no existe crea el fichero “/etc/xinetd.d/rsync” con el contenido siguiente.

service rsync
{
    disable = no
    socket_type = stream
    wait = no
    user = root
    server = /usr/bin/rsync
    server_args = --daemon
    log_on_failure += USERID
}

1.f) Comprobar el puerto por el que el servidor rsync escuchará. Para ello ves al fichero”/etc/services” y comprueba que la siguiente línea existe y no está comentada:

rsync 873/tcp

1.g) Reinicia el daemon xinetd. Para ello:

sudo /etc/init.d/xinetd restart

1.h) Ya tenemos el servidor funcionado. ¿Como lo usamos?. Sencillo, en local ejecutamos:

rsync -v --recursive --times --perms --links --delete /mi/carpeta/personal/local rsync://usuario1@miservidor/nombremodulo1

donde estamos haciendo una sincronización recursiva, preservando fechas y permisos de los archivos origen, incluyendo vínculos, borrando archivos que fueron borrados en el directorio origen. Todo ello desde un directorio origen /mi/carpeta/personal/local y utilizando el protocolo rsync contra el servidor miservidor, con el usuario1 y utilizando el módulo nombremodulo1

Caso 2. La segunda opción consiste en la utilización del terminal remoto seguro ssh.

El proceso de creación de clave pública y privada y configuración del terminal escapa de este tutorial.

En este caso no es necesaria la configuración del demonio en el servidor, tan sólo que rsync esté instalado en él. Para ejecutar la sincronización:

rsync -v --rsh=/usr/bin/ssh --recursive --times --perms --links --delete /mi/carpeta/personal/local usuario1@servidor:carpeta/destino/servidor

Acabábamos el post anterior comentando que el uso de J2Me podía hacer que la programación para ciertas plataformas se realizara de manera común.  ¿Común? bueno, si, pero no tanto, ya que no todos estos dispositivos tiene el mismo soporte de J2ME. ¿la razón? Tal vez lo primero sea definir que es exactamente J2ME.

J2ME, o ahora mismo llamada Java ME,  es una de los componentes de la llamada plataforma Java  junto con Java EE y Java SE. Su objetivo es proporcionar una serie de API’s para el desarrollo de aplicaciones en dispositivos con recursos limitados como PDA’s, coches, móviles, electrodomésticos… Es decir, el campo de dispositivos que abarca J2ME es muy grande y con unas características de hardware muy variadas.

Es por ello que Java ME se divide en las llamadas configuraciones. Existen dos: la CDC (pensada principalmente para domótica o automóviles) y la CLDC (Connected Limited Device Configuration), que es la que está en la mayoría de los móviles. Cada una de ellas proporciona unas API especiales para cada tipo de hardware.

Pero hay más. En cada configuración existen los llamados “profiles” (perfiles). Estos nos definen características concretas, por ejemplo la interfaz de usuario. Para CLDC hay tres perfiles: DoJa, pensado para móviles japoneses, IMP (para móviles sin interfaz de usuario) y MIDP (Mobile Information Device Profile) que es una versión del anterior pero con interfaz de usuario.

Es decir, que dentro de Java ME trabajaremos con la configuración CLDC  y el perfil MIDP.

Pero claro, no todo podía ser tan bonito . A partir de aquí empiezan las particularizaciones. Cada dispositivo móvil puede incluir soporte para distintas APIs opcionales. Por ejemplo, en función del modelo sobre el que queramos programar podemos necesitar una API para el manejo de la geolocalización, de la cámara, del bluetooth,…  o de una interfaz gráfica personalizada.

¿Que ocurre al final? Pues que cada fabricante realiza sus propias implementaciones de J2ME, basándose siempre en la original de Oracle, pero pensadas en particular para sus dispositivos. De esta manera hay funcionalidades que pueden existir en una versión y en otra no, o que aún existiendo, tengan comportamientos distintos.

A día de hoy la última versión del CLDC es la 1.1 y del MIDP la 2.0.

La última página web que hemos creado en Uhuru Labs, Navarro y Soler CAD-PLM Software, requería una sección donde los usuarios de la web pudieran mandar a nuestro cliente ficheros de un tamaño considerable. Teniendo este requerimiento empezamos a investigar por la red buscando algún uploader que no fuese el simple formulario de subida de ficheros, sino que proporcionara algo más, aparte de ser fácilmente configurable.

Enamorados como estamos de jQuery y de todo lo que lleva consigo esta potente librería en javascript, buscamos algún uploader que estuviera hecho a partir de jQuery y encontramos Uploadify. Un pequeño vistazo por encima nos hizo darnos cuenta de las grandes posibilidades que tenía este pequeño trozo de código.

Al estar utilizando WordPress como backend primero miramos si había algún plugin hecho ya que nos facilitara las cosas. Encontramos uno, pero no conseguimos hacerlo funcionar, así que lo pusimos a pelo en la plantilla que estábamos creando. Nos basamos en la última versión que tiene uploadify ahora mismo estable, la 2.1.4, ya que la beta 3.0 carecía de documentación y no queríamos embarrarnos las manos con cosas no probadas.

Una vez bajado el archivo comprimido con todos los archivos necesarios, descomprimimos en la carpeta de nuestro tema. Con lo que quedaría todo dentro de una carpeta, en nuestro caso la llamamos uploadify.

Entonces hicimos la carga de los archivos .js necesarios y de la hoja de estilos .css. Nosotros siempre cargamos las hojas de estilo en la etiqueta <head>:

<link rel="stylesheet" type="text/css" media="all" href="<?php bloginfo( 'template_url' ); ?>/uploadify/uploadify.css" />

y la carga de los archivos javascript lo hacemos en el footer.php, justo antes del cierre del tag <body>:

<!-- Uploadify -->
<script type="text/javascript" src="<?php bloginfo( 'template_url' ); ?>/uploadify/swfobject.js"></script>
<script type="text/javascript" src="<?php bloginfo( 'template_url' ); ?>/uploadify/jquery.uploadify.v2.1.4.js"></script>

Utilizamos el código php bloginfo(‘template_url’) para poner la dirección absoluta donde se encuentran los archivos.

Queríamos que cada cliente tuviera su propio directorio para subir archivos con lo que necesitábamos el nombre de usuario una vez logueado el cliente. Así que en la página donde queríamos el uploader pusimos este trozo de código:

<script type="text/javascript">
var files = new Array();
var user = '<?php echo $username; ?>';
var $cont = 0;
           jQuery(document).ready(function() {
             jQuery('#file_upload').uploadify({
               'uploader'  : '<?php bloginfo( 'template_url' ); ?>/uploadify/uploadify.swf',
               'script'    : '<?php bloginfo( 'template_url' ); ?>/uploadify/uploadify.php',
               'cancelImg' : '<?php bloginfo( 'template_url' ); ?>/uploadify/cancel.png',
               'folder'    : '<?php echo URI_UPLOADS.'/'.$username.'/'; ?>',
               'auto'      : false,
               'removeCompleted' : false,
               'simUploadLimit' : 3,
               'buttonText' : '<?php _e('SELECCIONAR','nysplm'); ?>',
               'multi' : true,
               'onError' : function (event,ID,fileObj,errorObj) {
                 alert(errorObj.type + ' Error: ' + errorObj.info);
               },
               'onComplete' : function (event, ID, fileObj, response, data) {
                        var json = {"name": fileObj['name'], "size": fileObj['size'], "type": fileObj['type']};
                        files[$cont] = json;
                        $cont++;
                },
               'onAllComplete' : function (event, data) {
                        //alert("Response: "+response);
                        send_confirmation(data);
                        $cont = 0;
                        files = [];
                 }
              });
           });

Donde le decimos a uploadify:

• uploader: donde está el archivo .swf que contiene el código flash que nos permitirá subir los archivos
• script: donde está el archivo .php que necesita uploadify para hacer la carga de los archivos
• cancelImg: donde se encuentra la imagen que se muestra para cancelar la subida de los archivos
• folder: el directorio donde queremos subir los archivos. En nuestro caso esto es dinámico, así el cliente subirá los archivos a su propio directorio.
• auto: indica que la subida no será automática, sino que el usuario deberá, una vez cargados los archivos, presionar un enlace para comenzar la carga.
• removeCompleted: indicamos que no quite de pantalla los archivos subidos.
• simUploadLimit: establecemos a 3 ficheros el límite de subida simultánea.
• buttonText: ya que este gran software está en inglés, utilizamos esta opción para cambiar el texto del botón de carga de archivos.
• multi: indicamos que se pueden subir varios archivos simultáneamente.
• onError: función que mostrará una alerta js si se produce algún error.
• onComplete: función que se ejecutará cada vez que se suba correctamente uno de los ficheros
• onAllComplete: función que se ejecutará cuando se hayan subido todos los ficheros.

Alguien se habrá dado cuenta del comentario que hay en el onAllComplete:

 alert("Response: "+response);

Esto sirve de mucha ayuda cuando estamos desarrollando. Puede ser que el archivo no se suba correctamente por falta de permisos. Esto para uploadify no es un error, ya que no es competencia suya, con lo que el error es devuelto a la función onAllComplete en lugar de lanzar un error la función onError. Por ello, si vemos que no se muestra ningún error pero el archivo no se sube al servidor correctamente, descomentar esta línea puede aclarar que está pasando.

Y por último, y no menos importante, habrá que poner el tag donde se cargará uploadify:

<input id="file_upload" name="file_upload" type="file" />
<a href="javascript:$('#file_upload').uploadifyUpload();"><?php _e('Subir archivos','nysplm'); ?></a>

donde ponemos el input con el identificador que cargará uploadify y un enlace para subir los archivos simultáneamente.

Y hasta aquí, esperamos haber sido de ayuda. Si alguien tiene alguna duda pues a comentar. Ayudaremos en lo que podamos.

Hace unos meses, oyendo una emisora de radio local, nos percatamos que durante varias horas al día la música y anuncios que sonaban lo hacían en bucle, es decir había una lista de reproducción que combinaba una serie de canciones con unos anuncios de manera predefinida y que se repetía todos los días (cosa comprensible pensando que era pleno verano y que mucha gente trabajando no debería de haber ).

Fue entonces cuando pensamos en la posibilidad de poder crear algún sistema que permitiera combinar varias listas de reproducción indicando el número de canciones consecutivas de cada lista. De esta manera, a partir de las mismas listas fuente se podrían realizar varias combinaciones mezcladas con una supuesta lista de anuncios. Y de ahí nació MMP: Manage Multiple Playlist, la que es nuestra primera extensión para VLC.

Por supuesto, su uso va mas allá del meramente radiofónico, ya que la posibilidad de mezclar listas de reproducción de diversas fuentes puede venir muy bien. ¿O es que nadie ha hecho una fiesta y todo el mundo se ha peleado por poner sus canciones?

Hace unos días publicamos la segunda beta (0.6b). Descárgala y ayúdanos a mejorarla.

“¡Por fin! Ya tenemos una idea para crear alguna aplicación para un móvil.  ¿Y ahora qué?” Eso mismo nos preguntamos hace unos meses, cuando empezamos a pensar en desarrollar aplicaciones para móviles: ¿por dónde empezamos?.

Tal vez la primera pregunta a hacerse sea para qué dispositivo trabajar. No cabe duda que el mercado está cada vez más lleno de opciones y cada una con un sistema operativo, unas herramientas de desarrollo y una serie de recursos disponibles. Pero no sólo eso. Además de la parte técnica hay una importantísima parte comercial, en la que hay que contestar a preguntas como ¿a qué tipo de personas va dirigido el software que  desarrollamos? ¿qué dispositivo(s) es mayoritario en ese sector? ¿cómo funciona el canal de distribución (AppStore, OVI, Android Market…)?, etc. En esta serie de posts vamos a olvidar esta parte comercial y vamos a centrarnos en la parte técnica. Es decir, una vez elegido el sistema de destino ¿cómo se programa para él?.

Y para empezar lo primero es centrarnos en intentar hacer un resumen de lo que hoy en día podemos encontrar en la calle, especificando, aunque sea de manera muy superficial, que tipo de lenguajes y con que herramientas es posible programar cada una de ellas. ¿Preparados? Empezamos

Hoy por hoy tenemos 7 Sistemas Operativos para móviles que copan el mercado:

• iOS (iPhone, iPad)
• Windows 7 Phone (HTC, Samsung, LG, Sony Ericsson, ..)
• Android (HTC, Motorola, Samsung, Nexus…)
• RIM (BlackBerry)
• Symbian (Nokia)
• MeeGo (Nokia, algunos coches, )
• WebOS (Palm, HP)

La programación sobre iOS y sobre W7P va aparte y merece una atención especial (incluso porque las herramientas de desarrollo sólo existen en sus “hermanos mayores” MacOS y Windows). El primero permite el desarrollo con Objective-C, sobre Cocoa, con XCode como herramienta de desarrollo principal. El segundo parece que se centrará en la plataforma .Net con lenguajes como C# o en Silverlight, aquel framework que creó Microsoft para hacer la competencia en el desarrollo de aplicaciones web enriquecidas a Flash y a Ajax y que, visto lo visto, parece que va a terminar centrándose en ser el sistema de desarrollo de aplicaciones para Windows Phone. Su IDE de trabajo es Visual Studio y Expression Blend.

WebOS es un sistema relativamente reciente. Está desarrollado por la Palm, Inc que ahora pertenece a HP y basado en Linux (como Android y MeeGO). Para programar sobre él se requiere básicamente conocimientos de creación de paginas web: HTML, Javascript, CSS, JSON … y como entorno de programación se dispone de Ares, un IDE integrado en un navegador web, con un editor visual bastante útil.

De MeeGO podríamos decir que es la descendencia de Linux para móviles ya que, a diferencia de Android y WebOS, Meego esta apoyado por la Linux Foundation. Un aplicación para MeeGo es como una aplicación normal escrita para KDE, es decir con las librerías Qt, sólo que con las características especiales que supone programar para dispositivos con recursos limitados.

Por su parte Symbian desarrolla en C++ y Java (aunque de esta opción hablaremos más adelante), normalmente sobre Eclipse. Aun así, existen otras opciones como Origo IDE, que permite la creación de aplicaciones de manera rápida y visual con un lenguaje de script propio o lenguajes más comunes como python o ruby,

Por último, programar en el resto (BlackBerry, Android o incluso en Symbian) puede tener similitudes que hagan que nuestros programas “puedan” ser ejecutados en un sistema u otro. ¿por qué? por el uso de Java , en concreto de J2ME, común, en principio, a todas las plataformas. Será sobre estos últimos sistemas sobre los que hablaremos en las próximas entradas.

Más información | Visual Studio, Eclipse, OrigoIDE, Ares, Silverlight

Al empezar la creación de una página web siempre nos habíamos preguntado cual sería la mejor opción a la hora de elegir un CMS.

Nuestras investigaciones por internet y después de barajar varias opciones hizo que descubriéramos Pods CMS. Pods es un plugin para WordPress que lo convierte en un cms cómodo, rápido y muy fácil de configurar.

Para empezar a trabajar con Pods simplemente hay que bajar el plugin y activarlo en una instalación de WordPress. Podéis encontrar el plugin Pods CMS en la web de plugins para wordpress.

Pods funciona principalmente como un generador de tipos de contenido, desde el punto de vista del programador podríamos verlo como un generador de clases, esto es, permite definir un modelo y asignarle varios campos de diferente tipo para luego poder crear objetos de dicha clase e interaccionar con ellos. Simplemente con esta funcionalidad ya es suficiente para dejarte con los ojos abiertos, pero hay mucho más.

Con Pods puedes hacer cualquier cosa, ya que tienes muchas formas de sacar la información introducida en la base de datos:

• Mediante páginas desde Pods en el área de administración. En estas páginas se puede poner tanto código php como caracteres comodín en las URL. Por ejemplo la página recetas/* será el handler por defecto de todas las páginas que empiecen por recetas/. Una forma de routing sencilla para el usuario…
• Se puede también añadir código en php directamente en los templates del tema que estés utilizando en WordPress.
• Utilizar shortcode de WordPress para incluir instancias de Pods o detalles de un Pod específico dentro de páginas o entradas de WordPress.
• Y por último y la más importante de todas creo yo, la API de Pods, que te permite hacer CRUD directamente de cualquier Pod que tengas creado en el sistema. Esto viene de perlas por ejemplo para hacer plugins que utilicen el sistema Pods como entrada de datos en las tablas.

Por poner un ejemplo, estamos trabajando en una web donde utilizamos Pods como entrada de datos en el sistema. Una de las partes de la página principal muestra los servicios más llamativos que proporciona nuestro cliente cada mes. Para ello creamos un Pod (que llamaremos Servicios destacados) que contendrá los siguientes datos: nombre, imagen, activa, oferta del mes, enlace.

Una vez creado el Pod podemos introducir datos desde la sección Add Servicios destacados que aparece en el menú principal de Pods (esto puede cambiarse mediante Pods UI o creando un menú nuevo mediante un plugin, pero eso lo comentaremos en otro post):

Ya introducidos los datos podremos asociar una página de WordPress a un template concreto y modificar ese template para que lea los datos del pod que queremos. En este caso creamos un template con este código:

<?php
/*
Template Name: Servicios destacados
*/
<?php get_header(); ?>
<?php
	// Consultamos la base de datos en Pods. 4 servicios destacados que estén activos
	$imagenes = new Pod('servicios_destacados');
	$imagenes->findRecords('name ASC','4','t.activa = 1');
	$total_imagenes = $imagenes->getTotalRows();
?>

//Bucle por los servicios destacados encontrados para crear la página
<div id="servicios-destacados">
<?php if( $total_imagenes>0 ) : ?>
	<ul>
	<?php while ( $imagenes->fetchRecord() ) : ?>
		<?php
			// iniciamos nuestras variables
			$id        	= $imagenes->get_field('id');
			$nombre      	= $imagenes->get_field('name');
			$imagen  	= $imagenes->get_field('imagen');
			$imagen_url     = $imagen[0]['guid'];
			$enlace		= $imagenes->get_field('enlace');
			if($enlace=="") $enlace = "#";
		?>

		<li>
			<a href="<?php echo $enlace; ?>">
			<img src="<?php echo $imagen_url; ?>" alt="<?php echo $nombre; ?>" />
			</a>
		</li>
	<?php endwhile ?>
	</ul>
<?php endif ?>
</div><!-- #servicios-destacados-->
<?php get_footer(); ?>

En este template lo que hacemos es:

1. consultar cuatro productos destacados activos
2. hacer un bucle por los productos para mostrarlos en pantalla

Con esto hemos visto lo fácil que es meter contenido propio en una base de datos utilizando el gran backEnd que tiene WordPress y consultar ese contenido con un template. Todo esto gracias a Pods.

Por último os dejo con un video de uno de los autores rascando un poco por encima las posibilidades de Pods y de su creciente documentación:

¡Por fin! ¡Ya estamos aquí! Bienvenidos a Uhuru Labs.

Hace varios años que Carlos y yo venimos dándole vueltas a la posibilidad de crear “algo”, “algo” que nos permitiera llevar a cabo con libertad nuestras ideas, probar nuevas tecnologías, aprender, juguetear e intentar sacarle a ello rentabilidad. Y la oportunidad se ha presentado ahora.

Así nace Uhuru Labs. Tal vez la mejor manera de definirlo sea como un laboratario de tecnologías informáticas, con el objetivo de ser aplicadas en la creación de los mejores proyectos posibles. Nuestro campo de investigación es amplio, desde las ya casi olvidadas aplicaciones de escritorio, hasta las aplicaciones móviles, pasando por páginas y aplicaciones web, pero sin olvidar elementos tan relacionados con estas últimas como el diseño o la fotografía.

El trabajo ya ha empezado. Ya podeis encontrar en el portafolio, algunas de las páginas web que hemos desarrollado. Pero viene más, mucho más . Afortunadamente las ideas siguen llegando, así que esperamos en poco tiempo ir dejando nuevos recursos para que podais utilizarlos y ayudarnos a mejorarlos.

Por cierto, para los curiosos: uhuru es una palabra suajili (lengua que se habla en gran parte del África negra, principalmente en Kenia y Tanzania) y significa libertad… a buenos entendedores