Desde mi punto de vista, estaba fatal de la cabeza y si consiguió grandes cosas en la vida fue sobretodo porque se juntó con las personas adecuadas en el momento adecuado.

Mucha gente destaca que detrás de Jobs siempre estuvo Wozniak que era quien realmente hacía el trabajo.

17 días después de su muerte ya ha aparecido su biografía autorizada en las que destacan perlas como “voy a destruir Android, porque es un producto robado. Voy a iniciar una guerra termonuclear en este asunto”.

Otra buena también…“dedicaré mi último aliento, si es necesario, y gastaré cada penique de los 40.000 millones de dólares que tiene Apple en el banco, para arreglar este error”. Esta animadversión contra el sistema operativo para smartphones de Google podría explicar la cruenta guerra de patentes que está peleando Apple contra varios fabricantes de teléfonos móviles.

También era conocido por su forma de tratar a muchos empleados. Tenía una cruel facilidad para llevar a sus empleados al borde de un ataque de nervios y luego cargárselos; pocos quisieron trabajar con él dos veces.

Además de todo esto hay que sumar sus creencias místicas que le llevaron a la muerte. A Steve Jobs cuando le detectaron el cáncer de páncreas, era justamente un tipo muy especial que por suerte era fácilmente tratable. El problema vino cuando decidió seguir su camino para curarlo mediante medicinas alternativas. Esto le costó que un día tuviera que ingresar de urgencias en el hospital en un estado lamentable y costarle definitivamente la vida.

Viendo un poco la visión general, saquen sus propias conclusiones.

Precisamente en esta linea, hoy he estado evaluando una utilidad que cubre un vacío importante: Selenium IDE. Se trata de unos plugins y un programa servidor que permiten grabar o crear guiones de testeo (habeis grabado alguna vez una macro con word/openoffice? Pues algo muy similar) para después poder ejecutarlos en masa de manera automática y en diferentes navegadores.

Los comandos que ofrece para usar desde los guiones son muchos y potentes. La principal limitación que le veo a primer vistazo es que no es posible interactuar con plugins (flash, java, etc…), aunque parecería que la tendencia hacia HTML5 va a hacer esto cada vez un problema menos importante.

Nuestro objetivo es utilizar esta herramienta para instaurar una cultura de testeo automatizado (“un bug no se da por corregido hasta que no tenga un guión de testeo”), lanzar tests automáticos cada noche y así no volver a tener una regresión sin enterarnos.

He encontrado navegando por páginas de tecnología un emulador x86 implementado en javascript y que es capaz de ejecutar Linux.

Además permite guardar cosas en memoria gracias a las facilidades de Local Storage que provee HTML5

Aquí tenéis el emulador. Se entra con usuario root y sin password.

http://stud.hro.nl/0814604/jslinuxdemo/emulator.html

Se atormenta una vecina con HTML 5 ya vereis…

Durante el taller, presentamos entre otras técnicas, el uso de JQuery y CSS para modificar ciertos comportamientos del tema gráfico y crear una sensación de dinamismo. En concreto hicimos dos pequeños códigos:

En el header.html, añadimos la librería de JQUERY (si no está ya instalada):

<script type=”text/javascript” src=”<?php echo $CFG->themewww .’/’. current_theme() ?>/jquery-1.2.6.min.js”></script>

y posteriormente añadimos este código:

<script language=”javascript”>
$(document).ready(function() {
$(“#left-column”).click(function(){
$(“#middle-column”).fadeIn();
$(this).toggleClass(“active”); return false;
});
$(“#right-column”).click(function(){
$(“#middle-column”).fadeOut();
$(this).toggleClass(“active”); return false;
});
});
</script>

El código lo que hace es algo tan “sencillo” cómo ocultar una columna al clicar en ella. No tiene una utilidad práctica, pero permite ver la potencia de trabajar con código de programación en los temas gráficos.

El segundo código es más divertido, primero añadimos un código php en el header.html para obtener la ciudad del alumno y pintarla en la construcción del div page:

<div id=”page” <?php
echo “class=’”;
if($USER->city==”") echo “default”;
else echo $USER->city;
echo “‘”;
?>
>

Según esto, el <div id=”page”> pasaría a ser <div id=”page” class=”madrid”>, por ejemplo.

Una vez que sabemos un dato de usuario podemos hacer cambios y juegos visuales vía css, por ejemplo:

.madrid #header,
.madrid #header-home{
background-image:url(barca.jpg);
background-repeat:repeat;
height:120px;
}

Lo que hacemos con el código es pintar una imagen del Barça a todos aquellos que son del Madrid. Aparte de la pequeña broma, nos permite personalizar la apariencia dependiendo de la variable que leamos del usuario.

Quedaría más o menos así:

Con esto ya podemos ampliar un poquito más los límites de Moodle…

Requisitos

Moodle 1.8 o superior, aunque es posible que funcione para versiones anteriores, pero no está probado.

Uso del bloque

La configuración de Youtube RSS Player es muy sencilla, una vez tenemos un curso creado, entramos al modo edición. En la opción “Añadir bloque” nos aparecerá la opción de añadirlo. Una vez añadido, entramos en la edición del bloque y únicamente hemos de rellenar 2 campos:

• Cargar JQuery localmente: Si ya usamos JQuery en nuestro Moodle podemos deshabilitar la opción, en caso contrario o de duda lo dejamos activado.
• URL del canal RSS de youtube: Introducimos la dirección web del canal. En este caso es interesante indicar que existe una gran variedad de opciones, podemos publicar canales RSS de novedades de una etiqueta concreta o de un usuario, entre otras. En el siguiente enlace podemos ver una descripción más detallada.

Enlaces

Youtube RSS Player en Moodle:
http://moodle.org/mod/data/view.php?d=13&rid=2392&filter=1

Descarga directa de RSS Player:
http://factorsim.info/proyectos/youtuberssplayer/youtube_list.zip

Las posibilidades eran hacerlo mediante código en el servidor o que los usuarios de la aplicación enviaran directamente los archivos html.

El método más “cómodo” para usuarios no técnicos es guardar el archivo en formato html desde el propio word. Haciéndolo de esta forma se introduce una cantidad exagerada de tags html, unas que solo sirven para poner estilos y que se podrían poner de forma más cómoda y las que corresponden a la estructura del html están en un formato que, como no, no sigue el estandard.

Así que buscando por la red al final se optó por hacer la conversión directamente en el servidor mediante php y openoffice de la siguiente forma:

En el editor de textos de openoffice (writer) crear una macro como la que sigue:

REM  *****  BASIC  *****

Sub odttohtml (Path)
Dim Url as String
Url = convertToUrl(Path)

Set oDesk = CreateUnoService( “com.sun.star.frame.Desktop” )
Dim OpenParam(1) As New com.sun.star.beans.PropertyValue ‘Parameters to open the doc
OpenParam(0).Name=”Hidden” : OpenParam(0).Value=True
Dim Doc
Doc = oDesk.loadComponentFromURL(Url, “_blank”, 0, OpenParam())

Dim outputfile as String
outputfile = Left( Path, Len( Path ) – 3 ) + “html”

Dim SaveParam(0) As New com.sun.star.beans.PropertyValue
SaveParam(0).Name=”FilterName” : SaveParam(0).Value=”HTML (StarWriter)”

Url = convertToUrl(outputfile)
Doc.storeAsURL(Url, SaveParam() )
Doc.close( True )
End Sub

Con la función odttohtml se consigue pasar un documento doc a html con un formato “casi” estricto (algunos tags no se cierran).

Una vez guardada la macro, ya se puede invocar mediante php con el siguiente código:

shell_exec(‘soffice -headless “macro:///Standard.Module1.odttohtml(doc_file.doc)”‘);

Esto nos da como resultado un documento html bastante aceptable para poder ser usado por “humanos” y que sigue el estandard.

Lista de premiados:

Ganador General:

1. WordPress
2. MODx
3. SilverStripe

Open Source CMS más prometedor:

1. ImpressCMS
2. Pixie
3. Pligg

Mejor PHP Open Source CMS:

1. Drupal
2. WordPress
3. Joomla!

Mirando el histórico desde el 2006 se ve una progresión de Drupal que ha logrado por segundo año consecutivo ganar el premio al Mejor PHP Open Source CMS y está entre los mejores CMS.

Recientemente se ha publicado la notícia que La Casa Blanca (http://www.whitehouse.gov/) ha migrado los contenidos de su web a Drupal lo cual indica que es un CMS con la suficiente estabilidad, funcionalidad y seguridad para llevar a cabo sites tan complejos como este.

Tanto Drupal como WordPress son los CMS que habitualmente implementamos en proyectos, por su potencia y versatilidad en el caso de Drupal y por la facilidad de uso en WordPress. Coincide que en dos semanas saldrá publicado en MOSAIC, un artículo que compara Drupal, Joomla, WordPress y Plone.

Varios ejemplos de sites que ha realizado FactorSim con Drupal son:

Las webs segmentadas por países de Roca, entre ellos Roca protugal (http://www.roca-sa.com/):

Una web autogestionada para Clic-Austral (http://clic-austral.com/):

A nosotros, esta noticia nos ha traido una nueva tarea. Probar MODx y SilverStripe para evaluar porqué han sido elegidos entre los mejores CMS del mundo.

Con el anuario 2008, TNS deja atrás un modelo estático de presentación de la información, utilizando por primera vez tecnologías de lectura de XML, con integración de otros elementos de programación que permiten visualizar y acceder a los contenidos de manera más gráfica y flexible. La información se basa en datos sobre el consumo y la cuota, el perfil de cadenas y el ranking de programas y emisiones, entre otros.

Para ello, desde Factorsim hemos desarrollado un frontend web para mostrar los datos de audiencias de una manera más ágil que la permite la versión impresa. Partiendo de ficheros de datos proporcionados por TNS que son procesados mediante un conjunto de instrucciones pre-programadas, guardamos la información que contienen en formato JSON.

Una vez hecho esto, una aplicación JavaScript se encarga de leer las tablas y proporciona las distintas visualizaciones mediante una treintena de plantillas. Algunas de ellas generan tablas numéricas, otras dibujan diferentes tipos de gráficas a partir de los mismos datos. En las tablas más complejas y extensas podemos ver los datos por grupos mediante un selector y mostrar gráficas adicionales en ventanas independientes a petición del usuario.

La aplicación interactiva desarrollada puede ejecutarse desde un CD, visualizarse a través de un navegador o consultarse desde un servidor web.

Para ello hay que editar uno de los archivos del tema que se utiliza, se puede editar el “header.html” o bien el “meta.php” .

El código que hay que añadir al archivo es el siguiente:

<?php

global $CFG;

global $course;

if (!is_null($course->id)) {

$context = get_context_instance(CONTEXT_COURSE, $course->id); // Course context

$student_role=array_shift(get_roles_with_capability(‘moodle/legacy:student’, CAP_ALLOW, $context));

$user_roles=get_user_roles($context);

foreach($user_roles as $value){

if($value->name==$student_role->name){

print(‘<link rel=”stylesheet” type=”text/css” href=”‘.$CFG->httpsthemewww.’/standard/student.css” />’);

break;

}

}

}

?>

Y con esta simple modificación se incluye el archivo “student.css” con los estilos especificos para los estudiantes.

Hay ya muchos textos escritos sobre Subversion, pero hoy no hablaré de sus características, de lo que puede hacer ni de cómo lo hace. Hoy me centraré en qué es lo que le encontramos interesante para utilizarlo como herramienta en una empresa. En otras palabras: por qué lo utilizamos.

• Ha llamado un cliente. Dice que tiene un problema con la versión j29rc20. ¿Alguien sabe de dónde puedo conseguir esa versión para hacer unas pruebas?

• Uffff… j29rc20 significa “jueves 29, versión que estaba en el discoduro de Ricardo Cano a las 2:00”. ¡A saber dónde estará esa versión ya ahora!

Subversion guarda todas las versiones que pasan por sus manos. Además, permite dar un nombre (etiquetas, en nomenclatura SVN) a cualquiera de esas versiones. Así, si j29rc20 fuese una etiqueta SVN, obtener esa versión seria trivial.

• ¡Ostras! ¡He copiado esta versión encima de la antigua pensando que no tenía nada importante y me he cargado todo mi trabajo de la última semana!

En un repositorio SVN, la incorporación y mezcla de los cambios hechos por los diferentes usuarios (o incluso de copias de trabajo distintas de una misma persona) se realiza de manera automática, garantizando que nadie sobreescribe el trabajo de otro. Y si has borrado un archivo que no debías o has hecho cambios que no son correctos, siempre puedes recuperar cualquiera de las versiones anteriores que hay guardadas.

• ¿Cuando corregimos la alineación de las imágenes para IE6 lo hicimos mediante CSS o JS?

Subversion permite comparar fácilmente cualquier par de versiones de cualquier archivo. Si unimos a esto la posibilidad de explicar en los comentarios qué es lo que hemos modificado en cada versión, responder a esta pregunta es tan fácil cómo ojear la lista de comentarios e inspeccionar las diferencias de la versión relevante con la anterior. Además, nos vendrá de regalo la información sobre quién hizo ese cambio y cuándo.

• Queremos implementar una funcionalidad experimental que va a afectar la estabilidad del proyecto pero incluirla en la siguiente versión sólo si está ya suficientemente estable. Nos arriesgamos a ir haciendo los cambios o cómo lo hacemos?

En el mundo SVN la respuesta es única: mediante una rama. En cada rama que creemos podremos tener una evolución independiente del mismo código, de manera que no se interfieran entre ellas. Crea una rama nueva para implementar allí la funcionalidad experimental. Cuando el código esté maduro podrás integrar fácilmente los cambios en la rama principal antes de hacer la nueva versión. Si esa integración de cambios no llega a tiempo, la rama principal incorporará otros cambios no desestabilizadores pero nada de la rama experimental.

• Tenemos un directorio JS que es común a todos estos proyectos, pero ahora ha llegado una versión nueva del JS. ¿Tenemos que copiarlo a todos los proyectos uno por uno?

En SVN, no. Separa el directorio JS en un apartado del repositorio y vincúlalo al resto de proyectos. De esta manera, los cambios de cualquiera de los proyectos se trasladarán al JS común y de ahí a todos los demás proyectos. Modifica el JS común o la copia vinculada a cualquiera de los proyectos y todos los demás sitios se actualizarán por arte de magia. Todo lo que dijimos antes sobre la seguridad de no sobreescribir cambios de otros y las versiones se aplica aquí también, por supuesto.

Pero no todo es de color de rosa…

Subversion al fin y al cabo es sólo una herramienta. Que resulte beneficiosa o nociva depende del uso que se le dé. Hay algunos problemas muy comunes:

Subversion permite tener todos los archivos de un proyecto muy bien ordenados e indentificados. Pero no obliga a ello. De hecho, con etiquetas, ramas, vínculos y una estructura de directorios mal definida SVN puede llevarnos a un nuevo nivel de caos desconocido hasta la fecha.

Por otro lado, como cualquier otra tecnología, requiere un aprendizaje. Trabajar con una copia de trabajo en SVN es muy similar a trabajar con archivos normales. Demasiado parecido. Pero quienes acostumbren a copiar proyectos (o partes de ellos) de un directorio a otro se encontrarán con unas cuantas sorpresas desagradables al intentar sincronizar su trabajo con SVN, sin ir más lejos. También hay que aprender a crear archivos nuevos, borrarlos o incluyo renombrarlos o cambiarlos de sitio cuando residen en un proyecto SVN. Es igual de sencillo que hacer esas operaciones sobre archivos normales, pero hay que recordar que la manera concreta de hacerlo cambia.

Por último, para aprovechar los proyectos organizados que nos posibilita un repositorio de código lo mejor es tener una gestión organizada. Una gestión que establezca claramente las entregas, las versiones, los objetivos de cada una de ellas, las iteraciones de testeo y corrección de errores, etc…

Pero todo esto es ya material para otro post (sí: es una amenaza).