Propósitos de año nuevo

En principio no empiezo muy bien haciendo una lista de propósitos para año nuevo el 9 de enero, pero más vale hacerla en enero que no en julio cuando ya no haya nada que hacer. Una de las recomendaciones que más he leído es que hay que dejar estos propósitos por escrito y a la vista, y que mejor que en el blog, así de paso me comprometo con mis lectores imaginarios (en mi cabeza sois así) . Vamos allá ¿no?

  • Quererme más. Ya hay gente dispuesta a complicarme la existencia para que yo les vaya adelantando faena.
  • Decir lo que pienso más a menudo. Seamos realistas, de los 6000 7000 millones de personas, ni de casualidad les puedo caer bien a todos, no lo voy a intentar más.
  • Obtener mi título de ingeniera (de una vez por todas). Aunque sea a costa de posponer un poco bellas artes.
  • Dominar las situaciones agobiantes, y por lo tanto…
  • Asumir que a veces no puedo hacerlo todo.
  • Ir mucho más a la piscina.
  • Apuntarme a yoga ( y después ir).
  • Cocinar nuevas recetas (y llevármelas en tupper).
  • Beber mucha agua.
  • Ir a un bosque aka ser menos urbanita.
  • Hacer una excursión en caballo.
  • Aprender a hacer skate (!)
  • Hacer dos proyectos craft al mes (como mínimo), y que uno de ellos sea hacer una foto cada hora como los que hace DaintySquid.
  • Escribir en el blog, mejor y con más frecuencia.
  • No juzgar los libros por sus portadas (o por la gente que los lee). Leer el señor de los anillos y GEB para compensar.
  • Ser sociable, en internet y en persona.
  • Mimar más a mis amigos.as. Escribirles, pasar más tiempo con ellas.os porque siendo honesta molan mucho.
  • Llevar pintalabios más a menudo.
  • No dormir con pintura en la cara.
  • Limpiar los pinceles cada domingo.
  • Llevar factor de protección solar todos los días.
  • No usar cosméticos con productos turbios.
  • Encontrar un perfume para mí (y que mi pareja no piense que es de señora mayor <3)
  • Tener una mejor postura e ir al fisioterapeuta cuando me duela la espalda. No cuando duela mucho, aunque el fisio me eche la charla.
  • Ser espectacular en emacs o en vi. Guerra santa de editores en los comentarios, por favor.
  • Aprender un nuevo lenguaje de programación. Ruby tienes todas las papeletas.
  • Mejorar en python, java (android), Objective-C, Git…
  • Escribir tutoriales molones.
  • Seguir, de verdad, buenas prácticas de programación.
  • Desarrollar un proyecto muy molón.
  • Colaborar con algún proyecto de software libre

No me atrevo a contar cuantos propósitos he escrito porque son un montón. ¿Demasiados? Bueno, a final de año veremos. Felices propósitos de año nuevo a todos.

Posted in Sin categoría | 3 Comments

Motivos para desarrollara aplicaciones nativas para smartphones (a veces)

Ante la pregunta de si debemos desarrollar una aplicación móvil web o una aplicación nativa, no hay una respuesta universal (aunque a veces, leyendo algunos artículos,  lo parezca).  Al comenzar un desarrollo debemos empezar siempre por un análisis de las necesidades y de las funcionalidades que vamos a implementar,  y en función de estas tomar decisiones. Al igual que cuando un arquitecto diseña un edificio no se plantea si hay materiales o técnicas buenas o malas, sino si son o no adecuadas para esa obra en particular, nosotros deberíamos plantearnos cada desarrollo de manera independiente y realizar un análisis concreto para la aplicación que vamos a desarrollar (o sino vendrá el coco y se comerá todo nuestro trabajo y sino que se lo pregunten a los desarrolladores que sufrieron la crisis del software).

El propósito de esta entrada es analizar el caso del desarrollo de una aplicación móvil para Sakai OAE, por supuesto es mi análisis y estaré encantada de rectificar cualquier cosas en la que pueda estar equivocada. De todos modos, si estáis interesados en algo más genérico,  google es nuestro amigo, simplemente buscad “mobile web vs native apps” y podréis pasar toda una tarde (o más) leyendo artículos sobre el tema.

Durante este GSoC se están desarrollando dos aplicaciones móviles para Sakai, y cada una sigue una aproximación diferente. Y sinceramente creo que ambas decisiones son las correctas. Estoy segura de que Kasun Lakpriya y Steve Swinsburg, quienes llevan el desarrollo de la aplicación móvil basada en web de Sakai CLE, podrán daros un montón de buenos motivos por los que una aplicación web tiene mucho sentido  para Sakai CLE, yo me centraré en Sakai OAE.

Sakai OAE es una aplicación web muy joven, basada en estándares bien reconocidos, como ajax o json, el diseño revitaliza completamente la experiencia de usuario mejorando el flujo de trabajo tanto para profesores como para estudiantes. Es una aplicación muy escalable, que se desarrolla siguiendo buenas prácticas… En definitiva, es una aplicación web realmente molona.  De hecho, gracias al duro trabajo que están realizando el equipo de diseño, podemos navegar por la aplicación web tal y como esta utilizando un dispositivo móvil y la aplicación sigue viéndose bastante bien.  Así que, bajo mi punto de vista, como ya tenemos una buena aplicación web que mediante pequeñas modificaciones puede ser perfectamente una aplicación web móvil, tiene más sentido tratar de explotar las posibilidades que nos dan las aplicaciones nativas.

¿Y que posibilidades son? Pues estas son algunas de las que podríamos aprovechar en Sakai OAE, aunque seguro que no son las únicas:

  • Conectividad (modo Off-line):  Aunque cada vez es menos frecuente, no en todos los lugares se cuenta con una conexión a Internet en  condiciones, en España desde donde escribo al menos esto es así. Y las aplicaciones web necesita, obviamente, conexión  para poder  trabar (aunque se pueden conseguir algunas cosas con html5 y google gears). Así que el hecho de poder tener la aplicación funcionando  todo el tiempo es una ventaja, no nos perderemos una alarma que nos indique una fecha límite de entrega de un trabajo, ni dejaremos de leer las tareas pendientes por no tener conexión a Internet.
  • Mejorar la experiencia de usuario:  Las aplicaciones nativas, en general, mejoran la experiencia de usuario, no solo por el rendimiento que pueden obtener, sino que al utilizar elementos de la interfaz de usuario del propio dispositivo, aunque por supuesto esto también se puede emular.  También es muy interesante la posibilidad de tener la aplicación corriendo en segundo plano y  recibir ciertas notificaciones, como hacen las aplicaciones de twitter por ejemplo.
  • Cachear información en el dispositivo: Cierta información podemos almacenarla cifrada en el propio dispositivo, lo cual es muy útil  para mejorar la experiencia de usuario, no obligándole a introducir cada vez los mismos datos .
  • Hacer uso de características propias de los dispositivos:  Igual esta propiedad suena un poco extraña tratándose de una aplicación educativa, pero si lo pensamos un poco tampoco lo es. Por ejemplo, cuando un profesor vaya a crear una actividad no solo  podría etiquetar la fecha y la hora en la que se realizará, sino que también podría introducir una dirección GPS indicando el lugar en donde se llevará a cabo,  lo cual es realmente útil si pensamos en prácticas de campo, en campus especialmente grandes o para estudiantes con ninguna orientación espacial (este es mi caso). Y como esta, seguro que se nos pueden ocurrir un montón de utilidades creativas utilizando los servicios del teléfono, como la agenda o la cámara. ¿Por qué limitarnos entonces?
  • Descubrimiento:  Es realmente fácil encontrar una aplicación en el market/app store.
  • Rendimiento: Esta es, en mi opinión, la joya de la corona de las aplicaciones nativas.  Podemos programar hilos, usar las notificaciones de dispositivo, hacer que la aplicación corra en segundo plano… Y tratándose de una aplicación, que lo más normal  es que los usuarios la enciendan a primera hora cuando llegan a la universidad y que no la apaguen hasta que no se vayan a casa, esta es una características muy interesante a explotar.

Aunque también hay características de las aplicaciones móviles que son negativas, pero de las que nos podemos aprovechar (o al menos, no considerarlas tan negativas):

  • Actualizaciones automáticas: Las aplicaciones web se actualizan automáticamente, mientras que en el caso de las aplicaciones nativas debemos subirlas al market/app store y esperar a que el usuario se las actualice. Esto en principio es un punto a favor de las aplicaciones web, pero como desde mi punto de vista para Sakai OAE, no es un punto negativo. La aplicación móvil de una gran universidad, debe ser estable, y no actualizarse constantemente a no ser que sea totalmente necesario (estoy pensando en algún bug de seguridad), así que tampoco es algo tan negativo.
  • Las censuras del market/app store: He puesto market/app store para no despertar suspicacias, pero realmente dónde las aplicaciones pasan pruebas de calidad y pueden ser rechazadas en la app store.  De nuevo esto parece bastante negativo, pero una aplicación es rechazada por cuestiones de calidad básicamente (o que duplique un servicio de iOS, que no es el caso),  lo cual nos obligará a esforzarnos en la calidad de la aplicación,  y Apple no es especialmente ambigua sobre las cómo debemos desarrollar aplicaciones. Visto de este modo, sinceramente, no creo que sea un inconveniente en absoluto.

Y como no todo pude ser tan bonito, hay características que son intrínsecamente negativas:

  • Alcanzar a toda la audiencia: Aunque iOS y Android copan el mercado de los dispositivos móviles, no son las únicas plataformas, lo cuál hace  que nuestras aplicaciones móviles no consigan llegar a toda la audiencia. Pero como he comentado en la introducción Sakai OAE ya es una buena aplicación web a la que se puede acceder desde cualquier navegador móvil.
  • Mantenimiento: Esto sí es una pega, y no hay visión positiva que valga. Una aplicación nativa implica que debemos desarrollar para al menos dos plataformas, iOS y Android, y con el auge de Windows Phone igual hasta para una tercera.  Esto multiplica el coste de desarrollo y de mantenimiento. Yo que estoy desarrollando para iOS y Android y me pego con los problemas de implementar funciones en una plataforma que son completamente diferentes en la otra, no puedo negar esto. Igual al principio era más ingenua, ya que si que es verdad que los servicios web a los que llaman son los mismos, y que el coste de desarrollo y mantenimiento sería menor.  De todos modos, la comunidad de Sakai es grande y las ventajas creo que superan a los inconvenientes.

Con todo esto no quiero decir que las aplicaciones web sean una abominación. ¡Todo lo contrario! Ni que realmente no puedan funcionar como una aplicación nativa.

Para terminar, sólo recalcar que  no creo que haya una buena o una mala respuesta sobre que tipo de aplicación desarrollar.  Este es mi análisis, y por supuesto hay muchos matices en todas las características que he enumerado, y que tampoco me sorprendería si estoy completamente equivocada. Así que os animo a que me dejéis cualquier comentario con vuestras reflexiones y lo hablamos por aquí o en el irc de #sakai podéis encontrarme como AdaHopper.

 

Posted in Sin categoría | 1 Comment

Informe del primer mes en GSoC

Pues ya ha pasado un mes completo (y un poquito más), desde que empecé a trabajar en la beca más molona que conozco: el GSoC. Así que ya va siendo hora de hacer un informe en condiciones del estado del proyecto, sobretodo para mantener al día de los avances a la comunidad de desarrolladores de Sakai (la organización de código abierto para la que trabajo).

No puedo más que comenzar agradeciendo el trabajo realizado por mi mentor: Carl Hall, que lee pacientemente mis largos correos y con más paciencia todavía  contestar a todas mis dudas. Gracias Carl :)

Me hubiera gustado que más cosas estuvieran acabadas al terminar este primer mes. Pero como recientemente completé una tarea importante pues puedo ser más positiva al repasar los objetivos alcanzados respecto a los pendientes. Además es normal que en una primera etapa cueste un poco más el desarrollo porque he tenido que aprender las tecnologías con las que trabajo en el proyecto (Objective-C, te estoy mirando a ti, lenguaje rarito), refrescar el conocimiento almacenado bajo capas de polvo en mi cabeza (lamento haberte dejado tan solo Android), investigar acerca de Sakai OAE (bello soplo de aire fresco que  estoy segura que revitalizará Sakai) y acabar mis exámenes (el GSoC empieza muy pronto para los estudiantes europeos).

Pero vamos a centrarnos en las cosas que si que he conseguido que es lo importante.

Sakai OAE: gracias al jar que Carl me pasó poner en funcionamiento una versión en local de Sakai ha sido trivial.  Así que he podido centrarme en leer la documentación y en jugar mucho con Sakai para intentar comprender el funcionamiento básico de la aplicación. La documentación existente no es muy extensa,  pero se compensa con la gran disponibilidad que tienen los desarrolladores del  proyecto para resolver dudas. Si teneís cualquier problema mi recomendación es que os paséis por el canal irc (sip, el irc) de #sakai, siempre hay buena gente dispuesta a ayudar, o por la lista de correo sakai-dev, aunque la específica de sakai oae es sakai-ui-dev.  Me han sido de mucha utilidad también la documentación sobre pruebas de calidad,  porque me han permitido entender el flujo de trabajo que un usuario realizaría en Sakai.

Mock up: en la presentación del proyecto ya mostré unas mock ups de la aplicación y durante este tiempo hemos estado trabajando Kasun Kakpriya y yo para que nuestras dos aplicaciones móviles fueran lo más similares, de modo que la experiencia de usuario fuera lo más parecida posible entre las dos versiones móviles de Sakai CLE y Sakai OAE.  Nos pusimos de acuerde en el flujo de trabajo de la aplicación de modo que las dos aplicaciones tendrán el mismo flujo de trabajo y diferirán en algunas de las pantallas. Esto nos da flexibilidad para poder ofrecer la mejor versión móvil de cada una de las versiones de Sakai y mantener la experiencia de usuario.
Por otra parte, respecto a la decisión de que mock up voy a implementar, todavía estoy pendiente de recibir una respuesta por parte del equipo de diseño de Sakai OAE, pero he preferido continuar programando la parte interna de la aplicación y así darles más tiempo.

Esqueleto de aplicación para Android: ya esta listo el esqueleto de la aplicación de Sakai en Android. Esqueleto diminuto por ahora. Tiene básicamente la vista con el log in y otra segunda vista a dónde llego tras identificar al usuario.  También están creados los paquetes que organizan las clases java, así como los archivos de internacionalización.

Esqueleto de aplicación para iOS: ídem en iOS. Aunque eso si, como decía en la introducción: la gestión de ventanas de iOS es muy extraña.  Puede que sea porque como ya tenía experiencia en Android el cambio cuesta más, o porque realmente la gestión es muy marciana (yo apostaría por la segunda ;) ).

Autentificación de un usuario con Android: este es la primera tarea importante que he conseguido.  Los usuarios ya pueden autenticarse enviando sus credenciales.  Estudiamos, Carl y yo, la posibilidad de autentificar usuarios haciendo uso del protocolo OAuth y aunque se trate de un estándar que se esta extendiendo rápidamente, la implementación de este protocolo se sale del objetivo de este GSoC, además el equipo de Nakamura esta trabajando en esto. Eso si, la aplicación esta lista para cambiar un método de autentificación por otro, para que después el cambio no sea complicado.

Y esto es todo.  Espero que el proyecto os resulte interesante. Me encantaría oír cualquier sugerencia, duda,… que tengaís.

Posted in Programación, Sakai OAE | Leave a comment

Android, primera cita

Si yo tuviera que ser de esas personas que pronostican el futuro de la tecnología seguro que dejaba frases para la historia. Por catastróficas. Y apesar de mi poquito tino, hay cosicas que en cuanto las ves sabes que van a zarandear el modo en el que nos acercamos a la tecnología, una de esas cosas es android.

¿Las claves del éxito?  Pues en primer lugar que existen muchos terminales que han decidido apostar por Android, esto es bueno para los usuarios que pueden acostumbrarse más o menos a una interfaz y para los desarrolladores es importantísimo un único programa puede ejecutarse en un montón de terminales sin tener que volvernos locos en los detalles de hardware. Otro buen motivo es que el framework es abierto,

Os cuento un poquito de historia, (muy breve). En 2005, Google compró una compañía llamada Android Inc., y los rumores se dispararon: ¡Google va a crear un google-phone! ¡Señora, esconda a sus niñas!. Bueno, en el 2007 se anuncia la Open Handset Alliance donde estan un montón de compañías importantes

1. Instalar JDK

En MacOS X, que es el sistema operativo para el que estoy preparando la primera cita, la JDK viene instalada por defecto, así que este paso directamente nos lo podemos saltar. (Gracias Steve :) )

2.Instalar Eclipse

El siguiente apartado os informo que no contendrá spoilers de la peli de vampiros descafeinados, podeís leer sin miedo (la que tiene miedo soy yo).

Vamos a la página de descargas de Eclipse y ahí escogemos Eclipse IDE for Java EE Developers (188 MB) si escogemos otro luego hay que instalar plugins adicionales y es un rollo. Cuando tengamos el archivo comprimido lo descomprimimos y dejamos la carpeta en Aplicaciones. Dentro de esta carpeta esta el ejecutable de eclipse.

3. Instalar la SKD de Android

La SDK de Android se distribuye a través de la página de Google: http://developer.android.com/,  pinchamos la pestañita de SDK y nos descargamos el paquete que corresponda a nuestra plataforma de trabajo. En mi caso android-sdk-mac_86 paquete. Lo descomprimimos donde queramos instalarlo.

Para no tener que poner la ruta en la terminal cada vez que queramos ejecutar alguna de las herramientas de android, vamos a colocar la ruta de donde hemos descompirimido la carpeta tools de la  sdk en el path. Es decir, mi carpeta tools de la sdk esta aquí:

~/android/android/android-sdk-mac_86/tool

Así que voy a abrir el fichero .bash_profile que esta en la raíz de mi usuario (en ~/.bash_profile) y añado la siguiente línea:

export PATH=${PATH}:~/android/android-sdk-mac_86/tools

Ahora ejecuto el programa android que esta dentro de la carpeta tools, como he añadido a la ruta simplemete tecleo:

android

Abrirá el SDK y AVD Manager, pinchamos en la pestañita  Available Packages y selecionamos lo paquetes que queramos instalar. Como yo soy muy avariciosa los cojo todos, y pinchamos en instalar todos, aceptamos la licencia y ya tenemos la sdk instalada.

4.Instalar el plugin de Android para Eclipse

Añadiremos el repositorio a Eclipse, para ello arrancamos eclipse (si no lo tenemos ya encendido) y desde el menú vamos a “Help->Install new software” y añadimos un nuevo sitio:

Name: Android plugin

Location: https://dl-ssl.google.com/android/eclipse

Seleccionamos el paquete de Developers Tools y lo instalamos aceptando la licencia. Sólo nos queda decirle donde esta la SDK . Vamos a “Eclipse->Preferencias” y pinchando en la pestaña de Android ponemos la ruta de donde hemos instalado la skd de Android, es decir: ~/android/android-sdk-mac_86. Cuando pulsemos “Apply” podremos ver todas las versiones de la SDK que tenemos disponibles. Y con esto y un bizcocho ya tenemos el entorno de desarrollo instalado.

5. Crear un emulador

Abrimos la SDK o dentro de eclipse podemos hacer clic en el botoncito de Android de la barra de herramientas y pinchamos en la pestañita “Virtual Devices”  y aquí a “New…”, rellenaremos las características que queremos que tenga nuestro emulador de android. Dejo una captura de pantalla con las que tiene uno de los que he configurado.

Creando un androide virtual

Creando un androide virtual

Terminamos haciendo clic en Create AVD, y… ¡Listo! Ya tenemos nuestro bonito entorno para empezar a trabajar con Android.
¡Que vaya bien la cita! :)

Posted in Programación | Tagged | Leave a comment

Poniendo guapo a Eclipse para trabajar con Sakai

A mi no me cae bien Eclipse y yo a él tampoco, eso es así. Le juré odio eterno mientras realizaba un proyecto de programación en la carrera (Pedro, amigo, que mal nos lo hizo pasar eh?), era extraño, lento y consumía más recursos que una alcaldesa corrupta en Vouitons. Sin embargo tras el congreso de Sakai, me di cuenta que si tanta gente lo utilizaba quizás yo estuviera equivocada.

Así que vamos a probar. Eclipse es un IDE  que cubre las necesidades perfiles de programadores muy distintos, así que es como una copa de helado con un montón de sabores, ¿apetecible? si, si tiene el sabor que nosotros queremos y no un montón que no nos gustan (o no nos apetecen) y nos tenemos que comer a la fuerza. En este tutorial vamos a hacer nuestro banana split particular para sakai.

1. Instalar Eclipse

Lo primero que tenemos que hacer es descargar Eclipse IDE para desarrolladores de Java EE.

Instalar eclipse es extremadamente simple, lo único que hay que hacer es descomprimirlo en Aplicaciones y ya esta. Vamos a ejercutarlo para comprobar que funciona ejecutando eclipse que esta destro de la carpeta de eclipse.

Ahora nos toca ponerle el sirope y es que la configuración por defecto de memoria se queda bastante corto para manejar todas las aplicaciones web de Sakai. Cerramos eclipse si lo tenemos corriendo, y con el botón secundario pinchamos en el ejecutable de eclipse para entrar en la carpeta Contents\MacOS, buscamos un fichero que se llama eclipse.ini, vamos a editar ahí las variables de configuración. En mi fichero esta esto:

–launcher.XXMaxPermSize
256m
-vmargs
-Dosgi.requiredJavaVersion=1.5
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
-XX:MaxPermSize=256m
-Xms40m
-Xmx512m

y vamos a convertirlo en:

–launcher.XXMaxPermSize
256m
-vmargs
-Dosgi.requiredJavaVersion=1.5
-XstartOnFirstThread
-Dorg.eclipse.swt.internal.carbon.smallFonts
-XX:MaxPermSize=256m
-Xms128m
-Xmx1024m
-XX:+UseParallelGC

2. Añadir el plugin Web Tools Project (WTP) a eclipse

Este plugin hay que añadirlo en caso de que nos bajemos la versión Classic de eclipse, pero viene de serie con el IDE para desarrolladores de Java EE, así que un pasito que nos podemos saltar.

3. Añadir el plugin subclipse a eclipse

Tenemos que tener eclipse ejecutandose para poder instalar este plugin (como cualquier otro en realidad). Pinchamos en Help/Intall new software… (el caso es que me lo podía poner en castellano) y en “Avaible software sites”, esto nos mostrará una lista con los sitios disponibles desde donde podemos bajar plugins. En este repositorio vamos a añadir la dirección de Subclipse, simplemente pinchamos en el botón “Add..” y lo rellenamos como en la siguiente imágen:

Configuración del respositorio

La url, por si no se ve bien es:  http://subclipse.tigris.org/update_1.6.x

Le damos a Ok y ahora vamos a configurar la actualizazión. En Work site pondremos el repositorio que acabamos de añadir y pinchamos en el cuadro de selección de Subclipse (a continuación hay una captura de pantalla sobre como se hace). Pinchamos en Next y aceptamos los términos de uso del plugin, y así de sencillito tendremos el plugin instalado, solo nos queda reiniciar el IDE cuando nos lo pida.

Configuración de subclipse

El último paso en este apartado en la guía de Sakai es opcional, pero como somos programadores muy majos que no nos gusta nada ensuciar el código y subir al repositorio los directorios bin y target, pues vamos a hacerlo. (Vale, soy un poco radical, pero es por el bien comun :) )

Vamos a Eclipse->Preferencias y entramos en el menú Team->Ignored Resources. Y añadimos: “bin”, “target” y “m2-target”, aplicamos cambios y ya lo tenemos listo.

4. Añadir el plugin de maven a eclipse

Volvemos a ir a  Help/Intall new software… y añadimos el repositorio  pinchando el botón “Add..”  y rellenamos:

Name: Maven

Location:http://m2eclipse.sonatype.org/sites/m2e

Seleccionamos el plugin de Maven, teniendo este repositorio activo y lo instalamos aceptando la licencia y como antes pulsando Siguiente un par de veces.

5. Importar el código de sakai en Eclipse

Antes de importar el código, desde la terminal vamos a la ruta donde tenemos el código que queramos importar y tecleamos :

mvn eclipse:clean

mvn eclips:eclipse

Así crearemos los proyectos para que después eclipse pueda importarlos.

Arrancamos eclipse y vamos a cambiar a un espacio de trabajo para sakai, lo voy a llamar WS-Sakai (estoy original, Picasso tiembla), vamos a  File -> Switch Workspace y ponemos la ruta del espacio de trabajo, que al final es una carpeta que colocamos donde mejor nos venga.

Y ahora va lo divertido (o no), vamos a importar el código a sakai.

Vamos a Eclipse->import->Existing Projects into a workspace. Y en la raíz que nos pide del código ponemos la raiz de nuestro código de sakai. Pinchamos en finalizar y nos importará el código.

Aparecen errores en proyectos (algunos si tenemos suerte, un montón si no), esto es debido a que cuando le decimos a maven que cree los proyectos de eclipse hace algunos de más, así que tendremos que quitar el código que de error.

¡Y ya esta! ¡Ahora a trabajar! :)

Posted in Programación, Sakai | 1 Comment

Como tener dos (o los que quieras) fuentes de sakai instalados {instalando sakai 2.7.0}

Ahora que ya tenemos nuestro flamante código de sakai, queremos otro (una versión estable por ejemplo estaría bien). No es avaricia, os lo prometo, es necesidad.

En este post y en el siguiente veremos como instalar sakai 2.7.0  y sakai 3 y poder desplegar un código u otro en función de nuestras necesidades (veis como era necesidad). Vamos al lío.

1. Instalar y configurar tomcat

Necesitaremos un tomcat nuevo y limpito sobre el que despliegue el código de sakai que vamos a instalar. Al principio parece un jaleo tener varios tomcats pero es la solución más eficiente para no tener después quebraderos de cabeza con las dependencias. Como yo tengo guardado el paquete de tomcat simplemente lo descomprimo en una ruta adecuada. En mi  caso va a ser:

~\sakai\tomcat-2.7.0

(por razones obvias), así me acuerdo de que tomcat va con que código. El siguiente paso, es darle permisos de ejecución a los scripts:

sudo chmod ug+x *.sh

Añadimos el conector para mysql, lo tenemos en el tomcat anterior o lo podemos volver a bajar de aquí, en cualquier caso, lo colocaremos en $CATALINA_HOME/common/lib, de este modo tomcat lo encontrará (y no nos volverá locos.as con un mensaje de error gigantesco, justo como me ha pasado a mi).

A continuación modificamos el fichero server.xml (se encuentra en /tomcat/conf/server.xml) y en la configuración del puerto de conexión, vamos a añadirle la codificación para carácteres utf-8, al igual que hicimos cuando instalmos la primera vez.

Creamos la carpeta sakai detro de tomcat, y aquí pondremos copiar un fichero de properties limpio como el que tenemos en el código de sakai, dentro de /reference/docs/sakai.properties. Pero como yo quiero tener la misma configuración que en el código anterior pues voy a coger el properties que ya tengo configurado en el tomcat anterior. Elijamos el fichero que elijamos,  lo copiaremos a la carpeta sakai que acabamos de crear.

cp tomcat/sakai/sakai.properties tomcat-2.7.0/sakai/

Los amigos de Sakai, nos dicen que hace falta añadir unas opciones de java para que algunas herramientas jsf compilen correctamente con java 1.6. Como esta es la versión que tengo yo instalada voy a añadir las opciones al fichero de perfil.

open ~/.bash_profile
export JAVA_OPTS="-server -XX:+UseParallelGC -Xmx876m -XX:MaxPermSize=2160m -Djava.awt.headless=true -Dsun.lang.ClassLoader.allowArraySyntax=true -Dorg.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=false -Dhttp.agent=Sakai"

Resulta que hay también unas opciones para localizar Sakai por defecto, esto es totalmente opcional, las opciones (valga la redundancia) que configuran esto son -Duser.language y -Duser.region, en mi caso españa (es):

export JAVA_OPTS="-server -XX:+UseParallelGC -Xmx876m -XX:MaxPermSize=2160m -Djava.awt.headless=true -Dsun.lang.ClassLoader.allowArraySyntax=true -Dorg.apache.jasper.compiler.Parser.STRICT_QUOTE_ESCAPING=false -Dhttp.agent=Sakai -Duser.language=es -Duser.region=ES"

2. Descargar y desplegar el código de sakai

Esto va mucho más rápido que la última vez. Ya vamos a descargarnos el código de sakai tecleando en el siguiente comando en la terminal:

svn co https://source.sakaiproject.org/svn/sakai/tags/sakai-2.7.0/ sakai-2.7.0

Antes de desplegar tenemos que decirle en que tomcat queremos hacerlo, así que tendremos que modificar la variable de entorno $CATALINA_HOME y nada más, porque como recordareís habíamos parametrizado la configuración de maven, así que con este simple cambio ya lo tenemos preparado para desplegar dónde toca.

export CATALINA_HOME=~/Trabajo/Sakai/tomcat-2.7.0/

Pues a desplegar!

cd sakai-2.7.0/master
mvn clean install
cd ..
mvn clean install sakai:deploy -Dmaven.test.skip=true

Y ya esta :) , ya tenemos nuestros dos códigos de sakai desplegados. Ahora segun arranquemos uno u otro tomcat tendremos la versión de sakai que queramos.

Posted in Programación, Sakai | Leave a comment

Instalar sakai trunk (desde las fuentes)

Estoy preparando a mi niño para el intenso verano que nos viene y es que estaré desarrollando un proyecto para el Gsoc (!). Y hay tanto (¡TANTO!) que hacer que la verdad es que estoy un poco aturdida, así que como antídoto voy a aplicar el mantra “Divide y vencerás” que tan buen resultado le da a todo el mundo. Y mi primera etapa va a consistir en crear un entorno de trabajo listo para la acción.

Mi mac, en adelante Noam, es un macbook de 13″, (es chiquitico, sí, pero ya vereís desde que sitios acabaré trabajando ya que voy siempre con él), corriendo mac os x 10.3.6. Así que este va a ser mi estación de trabajo y todas las cosicas que explique pues como es lógico “funcionaran” con estos requisitos técnicos.

Instalar Sakai es un infierno y eso es así, (espero que mi mentor no lea esto). Y por más veces que lo haga no es que mejore mucho el proceso, eso sí, cada vez soy más paciente y poquito a poquito los errores me van sonando, pero en definitiva algo va a fallar, no tengas miedo, al menos la comunidad es grande y ayuda a las pobre hormiguitas como yo.  Allá vamos pues…

1 .Verificar / Instalar Java 1.5

Pirmer paso de la guía y primer paso que me voy a saltar (luego me quejo de que no vayan las cosas). En mi sistema operativo java viene preinstalado por defecto. Simplemente lo comprobamos escribiendo en la terminal:

noam:~ ada$ java -version
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01-101, mixed mode)

Y efectivamente ahí esta Java, pero es Java 6.0. con sus 64 bits más chulo que un ocho. Vale, como la experiencia es la madre de la ciencia, aunque la comunidad recomiende instalar Java 5.0. a mi esta versión no me da ningún problema, y Steve también dice que le funciona, así que al siguiente paso.

2. Instalar/Verificar mysql 4.1

Segun pone en la guía al parecer con mysql 5.0.x funciona también bien, y como soy una personita valiente he decidido bajarme la úlima versión que estaba en el respositorio: la versión 5.1.46. Me he bajado un fichero dmg desde la página oficial de mysql. Lo pero es que hay que pasar por el aburrido proceso de registrarnos.

Vale ya  tenemos el .dmg , lo montamos y e instalamos los dos paqueticos que tiene la imagen, como es un proceso de siguiente siguiente es fácil a más no poder. Y en un periquete tenemos mysql instalado. La ruta de acceso es /usr/local/mysql, pero como es un rollo acceder así vamos a ponerlo en el fichero .bash_profile añadiendo la siguiente línea:

export PATH=$PATH:/usr/local/mysql/bin

Vamos a poner la contraseña de root para poder empezar a jugar con nuestra base de datos. Para ello tecleamos:

$ ./bin/mysqladmin -u root password new_password

Claro que si lo haces sustituye new_password por tu nueva contraseña :)

Un alidado bueno bueno para trabajar después será el Sequel pro, un estupendo visor/editor para trabajar con nuestra base de datos en mac.

3. Crear la base de datos de Sakai y el usuario

O bien por la teminal o con el programita, accedemos a mysql con el usuario root y su contraseña. Como yo soy más de terminal pongo los comanditos aquí:

$ mysql -u root -p
mysql&gt; create database sakai default character set utf8;
mysql&gt; grant all privileges on sakai.* to 'sakai'@'localhost' identified by 'user';
mysql&gt; flush privileges
mysql&gt; quit

Y con esto ya tenemos nuesta base de datos lista para seguir instalando cositas.

4. Descargar y configurar Maven

Maven es una herramienta de software para la gestión y construcción de proyectos JAva creada por Jason van Zyl, de Sonatype, en 2002. Tiene un modelo de configuración de construcción basado en un formato XML. Maven utiliza un Project Object Model (POM),  para describir el proyecto de software a construir, sus dependencias de otros módulos y componentes externos, y el orden de construcción de los elementos. Viene con objetivos predefinidos para realizar ciertas tareas claramente definidas, como la compilación del código y su empaquetado. [Gracias wikipedia]

Con maven compilaremos todo sakai, así que es una herramienta muy importante.

Desde la página oficial de maven descargamos la versión 2.0.11. Una vez lo tengamos, descomprimimos el fichero que acabamos de bajarnos donde queramos instalarlo en mi caso va a ser en esta ruta ~/Trabajo/Sakai/maven después tendremos que ser consecuentes para establecer las variables de entorno, pero mientras nos acordemos como si lo queremos instalar en la ruta del tour de Francia.

Aquí va un aviso importante para navegantes,  al instalar sakai hay que modificar un buen puñadito de variables de entorno, si lo hacemos cada vez es un rollo bastante importante así que lo que haremos será escribir todas las variables en un fichero que se llama .bash_profile y que está en la raíz de nuestro usuario. Vamos a por ello pues. Tecleamos lo siguiente en la terminal:

$ open ~/.bash_profile

y en el fichero añadimos la variable de entorno MAVEN_HOME

export MAVEN_HOME=~/Trabajo/Sakai/maven

Y ahora nos queda añadirla al PATH para que así nuestro unix lo encuentre cuando vayamos a ejecutar maven desde la consola:

export PATH=$PATH:$MAVEN_HOME/bin

Una última pega tiene esto y es que sakai “a veces” se queda sin memoria así que hay que hay que incrementar las opciones de maven. Esto va un poquito a ojo (seguro quien sepa bien hacer esto le parecerá una abominación lo que acabo de escribir),  y estas es la configuración que a mi me funciona. Si se queda sin memoria es cuestión de añadir más:

export MAVEN_OPTS='-Xms256m -Xmx512m -XX:PermSize=64m -XX:MaxPermSize=128m'

En resumen, a nuestro fichero .bash_profile le hemos añadido las siguientes variables de entorno:

# VARIABLE DE ENTORNO DE MAVEN
export MAVEN_HOME=/Users/ada/Trabajo/Sakai/maven
export PATH=$PATH:$MAVEN_HOME/bin
export MAVEN_OPTS='-Xms256m -Xmx512m -XX:PermSize=64m -XX:MaxPermSize=128m'

Vamos a comprobar que todo vaya bien:

$ mvn --version
Apache Maven 2.2.0 (r788681; 2009-06-26 15:04:01+0200)
Java version: 1.6.0_17
Java home: /System/Library/Frameworks/JavaVM.framework/Versions/1.6.0/Home
Default locale: es_ES, platform encoding: MacRoman
OS name: "mac os x" version: "10.6.3" arch: "x86_64" Family: "mac"

Yuhu! Maven ya esta instalado a por el siguiente paso.

5. Instalar/Verificar que tenemos instalado Subversión

Como todo código para el que trabaje más de una persona, Sakai tamibén necesita un sistema de control de versiones, y Sakai hace uso de Svn.

Para comprobar que esta instalado escribimos en la terminal:

$ svn --version
svn, version 1.6.5 (r38866)
compiled Oct 16 2009, 02:54:10
 
Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.tigris.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

Y como está :) pasamos a la siguiente.

6. Descargar e instalar tomcat 5.5.17+ (estable)

Este paso es muy simple. Entramos en la web de tomcat, descargamos tomacat 5.5.29, que es la última estable que tienen los señores y señoras de apache. Descomprimimos el paquete (ojo, en una ruta razonable que luego hay que entrar). Entramos en la carpeta de tomcat/bin y le damos permisos de ejecución a los scripts:

sudo chmod ug+x *.sh

A continuación modificamos el fichero server.xml (se encuentra en /tomcat/conf/server.xml) y en la configuración del puerto de conexión, vamos a añadirle la codificación para carácteres utf-8.
Buscaremos, por tanto, la siguiente etiqueta:

Y añadiremos URIEncoding=”UTF-8″. Con lo que nos quedará así:

<Connector port="8080" maxHttpHeaderSize="8192"
maxThreads="150" minSpareThreads="25" maxSpareThreads="75"
enableLookups="false" redirectPort="8443" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true" URIEncoding="UTF-8" >

Inculimos las siguientes variables de entorno al fichero .bash_profile:

export CATALINA_HOME=~/sakai/tomcat
export PATH=$PATH:$CATALINA_HOME/bin
export JAVA_OPTS="-server -XX:+UseParallelGC -Xmx876m -XX:MaxPermSize=2160m -Djava.awt.headless=true"

7. Descargar y configurar el conector para Mysql

Descargamos la libreria que permitirá la comunicación entre sakai y la base de datos. Como tengo instalado un mysql 5.x, la libreria que tengo que bajar es la siguiente:

http://dev.mysql.com/downloads/connector/j/5.0.html

Extraemos el zip y copiamos el fichero mysql-connector-java-<version>-bin.jar en $CATALINA_HOME/common/lib, de este modo tomcat lo encontrará cuando despliege.

8. Descargar el código de sakai con svn

¡Por fin! Ya estamos más cerquita del final (por lo menos ya tenemos el código tras este paso). Descargamos el código de aquí:

$ svn checkout https://source.sakaiproject.org/svn/sakai/trunk/ trunk

9. Configurar el fichero de sakai.properties

Debemos crear una carpeta llamada sakai, dentro de $CATALINA_HOME, es decir en la carpeta del tomcat. Tenemos un ejemplo de properties en el código en trunk/reference/docs/sakai.properties, copiamos este fichero a la carpeta que acabamos de crear.

Editaremos ahora el fichero de propiedades para trabajar con sakai

Comentamos las líneas de configuración de  HSQLDB:

## HSQLDB settings - on by default
#vendor@org.sakaiproject.service.framework.sql.SqlService=hsqldb
#driverClassName@javax.sql.BaseDataSource=org.hsqldb.jdbcDriver
#hibernate.dialect=org.hibernate.dialect.HSQLDialect
#validationQuery@javax.sql.BaseDataSource=select 1 from SYSTEM_USERS
# two hsqldb storage options: first for in-memory (no persistence between runs), second for disk based
#url@javax.sql.BaseDataSource=jdbc:hsqldb:.
#url@javax.sql.BaseDataSource=jdbc:hsqldb:${sakai.home}/db/sakai.db

Indicamos el nombre del usuario y el de la base de datos y la contraseña para acceder:

username@javax.sql.BaseDataSource=sakai
password@javax.sql.BaseDataSource=tu_contraseña

Finalmente descomentamos los datos de configuración de mysql, y se quedará así:

## MySQL settings - make sure to alter as appropriate
vendor@org.sakaiproject.db.api.SqlService=mysql
driverClassName@javax.sql.BaseDataSource=com.mysql.jdbc.Driver
hibernate.dialect=org.hibernate.dialect.MySQLInnoDBDialect
url@javax.sql.BaseDataSource=jdbc:mysql://127.0.0.1:3306/sakai?useUnicode=true&amp;characterEncoding=UTF-8
validationQuery@javax.sql.BaseDataSource=select 1 from DUAL
defaultTransactionIsolationString@javax.sql.BaseDataSource=TRANSACTION_READ_COMMITTED

10. Crear el fichero de configuración de maven:

Ahora creamos en ~ un directorio oculto llamado .m2, aquí esta el repositorio donde maven desplegará. Dentro de este directorio creamos un fichero de configuración llamado settings.xml, con el siguiente contenido:

<settings xmlns="http://maven.apache.org/POM/4.0.0"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
                      http://maven.apache.org/xsd/settings-1.0.0.xsd">
  <profiles>
    <profile>
      <id>tomcat5x</id> 
      <activation>
        <activeByDefault>true</activeByDefault> 
      </activation>
      <properties>
        <appserver.id>tomcat5x</appserver.id> 
        <appserver.home>${env.CATALINA_HOME}</appserver.home> 
        <maven.tomcat.home>${env.CATALINA_HOME}</maven.tomcat.home> 
        <sakai.appserver.home>${env.CATALINA_HOME}</sakai.appserver.home> 
        <surefire.reportFormat>plain</surefire.reportFormat>
        <surefire.useFile>false</surefire.useFile>
      </properties>
    </profile>
  </profiles>
</settings>

¡Atención a la parametrización! Nos va a facilitar un montón la existencia, aunque ahora no lo podaís ver.

11. Utilizar maven para desplegar sakai

Esto ya casi casi esta. Abrimos una terminal y nos situamos donde tenemos el código fuente de sakai y tecleamos:

mvn clean install sakai:deploy -Dmaven.test.skip=true

Y ahora paciencia infinita, porque la primera vez que arranca tiene que descargarse un montón de librerias y tardará (mucho). Si sois valientes, después de lo dicho, le quitais el “-Dmaven.test.skip=true”, os hará todos los tests y tardará ni se sabe.

[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 44 minutes 26 seconds
[INFO] Finished at: Fri May 21 13:42:51 CEST 2010
[INFO] Final Memory: 185M/344M
[INFO] ------------------------------------------------------------------------

Yuhu! Ya a compilado, ahora a arrancar el tomcat para poder probar nuestro flamante sakai nuevo, tras 44 minutos, vereís que mentirosa no soy.

~/tomcat/bin/startup
tail -f ~/tomcat/logs/catalina.out

Con estos dos comandos podremos arrancar tomcat y además ver el log, así podremos detectar si algo va mal. (Aunque como casi todos los logs es un poco marciano.)

Y por fin, veremos en la terminal la siguiente línea:

2010-06-08 16:18:13,274  INFO main org.apache.catalina.startup.Catalina – Server startup in 166240 ms

Y con esto y un bizcocho ya tenemos el trunk instalado.  Abrimos nuestro navegador favorito, escribimos: http://localhost:8080/portal y voilá  ya podemos ver la plataforma.

Pantalla de arranque de sakai

Pantalla de arranque de sakai

Posted in Programación, Sakai | Leave a comment