Geek & Roll

Ver primera parte: Intro

En la introducción se vió un poco sobre lo que es programar una aplicación para la BlackBerry haciendo un pequeño “Hola Mundo” muy sencillo. Ahora toca explicar las bases de la aplicación que se menciona en aquel post llamada “Everlasting Flame”. El nombre es el título de una canción del grupo de Thrash Aleman Kreator. Tengo la mala costumbre de nombrar a todos mis proyectos con titulos de canciones metaleras.

Primero un poco de teoría. Las aplicaciones de BlackBerry pueden ser de dos tipos: sin GUI o con GUI. Típicamente el punto de entrada de las que tienen GUI es cuando el usuario selecciona el ícono correspondiente en la pantalla. Las que no tienen GUI generalmente cuentan con otro punto de entrada, como al momento de hacer una llamada telefónica, enviar un SMS, solicitar datos, etc. En nuestro caso nuestra aplicación es sin GUI y su punto de entrada es al momento de realizar una llamada telefónica.

En el API de RIM hay dos clases que nos interesan actualmente: Applicationy UiApplication para aplicaciones sin UI o con UI, respectivamente. También nos interesa el PhoneListener que nos sirve para registrar una clase que consume los eventos generados por la aplicación de teléfono en la BlackBerry. También nos interesa la clase Phone que nos permite interactuar con la aplicación que se encarga de marcar el teléfono en la BlackBerry.

Como se mencionó en el post de introducción, el funcionamiento es el siguiente: marco un número e inicia un contador. Si llego a un determinado número de segundos (soft limit) el teléfono me avisa inyectando un tono DTMF a la llamada. Si llego a otro límite mayor (hard limit) la llamada se termina automáticamente. Para esto vamos a usar las clases antes mencionadas.

Nuestro programa consta básicamente de 2 clases: la clase principal que extiende a Application, y una clase que implementa la interfaz PhoneListener, o más específicamente extiende a AbstractPhoneListener, misma que implementa a PhoneListener y nos evita el tener que implementar todos los métodos abstractos de PhoneListener, enfocándonos solo a aquellos que necesitamos.
Leer el resto de este post.

Con este post inicio una serie de escritos sobre programación para la BlackBerry. Hace poco me compré un aparato de estos (una BlackBerry Pearl 8110 para ser exactos) sin saber mucho de sus capacidades, modelos existentes o herramientas de programación. Realmente el motivo por el cual adquirí una BlackBerry fue la curiosidad por probar este dispositivo y ver si sus capacidades push son tan buenas y “adictivas” como dicen.

Después de unos días de uso estaba claro que necesitaba programar la funcionalidad que me hacía falta en el dispositivo. Algo crítico para mi es que el móvil me avise del tiempo que llevo en la llamada, ya que mi plan incluye llamadas nacionales sin cargo adicional siempre y cuando se encuentren por debajo de los 5 minutos (plan sin fin de Telcel). Para evitar cargos extra todas mis llamadas a los 10 números que tengo registrados deben durar menos de 5 minutos y es ahí donde entra la parte smart del smartphone.

Idealmente lo que la aplicación debe hacer es lo siguiente: si estas llamando a uno de tus 10 números registrados, comienza a contarte el tiempo. Si la llamada cruza el softlimit suena una alarma. Si cruza el hardlimit, cuelga la llamada automáticamente. Claro que todo esto configurable, tanto los dos límites como las acciones que se ejecutan cuando se supera cualquiera de los dos límites. Bastante sencillo y uno pensaría que es funcionalidad que cualquier smartphone trae por defecto. Pero no.

Para mi sorpresa la BlackBerry se programa con Java, más específicamente es Java ME con una API específica para estos dispositivos. Puedes programar una aplicación para BlackBerry utilizando exclusivamente Java ME, pero si quieres hacer algo verdaderamente interesante (push de datos, usar el bluetooth, WiFi, guardar datos, utilizar el GPS o la red celular) necesitas usar esta API propietaria. Básicamente lo que se necesita es (cabe mencionar que por el momento esto es Windows only desafortunadamente):

• El Java Development Kit (JDK)
• El JDE de Research in Motion (RIM para los amigos) que incluye la API propietaria, un simulador, un IDE, entre otras cosas
• Llaves para firmar tu código en caso de ser necesario (más sobre este punto después)

Leer el resto de este post.

Dándole una hojeada a Foundations of Ajax de Apress, en la Breve historia de las aplicaciones web, me encontré la mención de XForms, y al pasar por una serie de vínculos me topé con este post en xml.com.

XRX es un paradigma parecido a AJAX y representa: XForms en el cliente (browser), Interfaces REST y XQuery en el servidor. Aunque podría compararse también con LAMP, WAMP o *AMP, hay características que lo asemejan más (e incluso lo llevan a competir directamente con) AJAX.

En buena parte comparto el entusiasmo por XRX de Dan McCreary (autor del post) ya que en uno de sus ejemplos pone como escenario el sitio web de una empresa de bienes raíces. Habiendo programado y diseñado varios de estos animalitos yo mismo, les puedo decir que es algo bastante tedioso cuando uno no está enamorado de su trabajo (o es Maestro en Ciencias o Científico Loco como algunos que yo conozco). Dan dice lo siguiente refiriéndose a las ventajas de este inexplotado paradigma (traducción mía):

Los métodos tradicionales requieren hacer 40 inserciones en tablas separadas dentro de una base de datos relacional. El uso de XForms y eXist resulta en una sola línea de código XQuery:

store(collection, file, data)

Eso es todo. Simple. Elegante.

Ahora explíquenme ¿CÓMO PODRÍA no entusiasmarse cualquier webdev mortal con semejante aseveración?

Sin embargo, en este nuevo mundo maravilloso con casas hechas de caramelo, hermosas mujeres, cerveza gratis y nubes de algodón que nos pinta XRX hay algunas “consideraciones” que debemos tener en cuenta los MySQL-PHP-JavaScripteros:

1. Ningún browser soporta aún XForms (excepto Firefox, pero con una extensión del mismo nombre).
2. Tienes que aprender XML y usarlo como si fuera HTML o Microsoft Word (nada del otro mundo).
3. Aprender XPath
4. Familiarizarte con eXist
5. Aprender XQuery
6. Conseguir un hospedaje que soporte eXist/XQuery y convencer a tu cliente de que mude su sitio con ellos.
7. Pelear a muerte con todos los die-hard AJAXeros y PHP/MySQLeros

Aún con todas las desventajas que conlleva (por ahora), creo que vale la pena echarle una hojeada a XRX e invertir un poco de tiempo para ser de los primeros en dominar este paradigma y después de leer varios libros, ingerir cantidades industriales de cafeína (o refresco de cebada) y acentuar las ojeras con estilo y orgullo, poder teclear store(collection, file, data) y sentirse como un campeón.

Continuando con la serie de posts sobre la aventura que es buscar un nuevo trabajo como programador, ahora les traigo la prueba definitiva para determinar si sabes programar en Java.

A lo largo de las ya múltiples entrevistas telefónicas que he tenido que pasar, hay una serie de preguntas que no faltan. Inclusive hay algunos que solamente hacen estas preguntas, y ninguna otra, como si esto fuera la prueba fehaciente de que sabes programar en Java.

• ¿Cuál es la diferencia entre una clase y un objeto?
• ¿Cómo creas un nuevo thread (hilo)? ¿Y de otra manera?
• ¿Qué es una interfaz?
• ¿Qué es una clase abstracta
• ¿Puede una clase pública extender una interfaz? ¿Y una clase abstracta?
• ¿Cuál es la diferencia entre un List y un Set?
• ¿Qué es un constructor?

Hay más preguntas, pero estas las han repetido siempre. ¿Qué les parece? en lo personal, no creo que ayude a determinar el nivel de conocimiento de un candidato, sin embargo si son cosas que cualquier novato de Java debe saber.

La noticia se ha extendido como reguero de pólvora: Google ha liberado su llamado “Protocol Buffers” que es para serializar estructuras de datos de manera neutral al lenguaje y a la plataforma. ¿Suena a algo parecido? ¿XML tal vez? si, pero segun Google es más eficiente y sencillo de utilizar. Veamos de que se trata.

Primero uno como desarrollador define cómo queremos estructurar nuestros datos, y luego generamos de manera automágica el código para lidear con estas estructuras. Estas definiciones se hacen en archivos .proto, que vendría siendo el equivalente a la definición del tipo de documento de XML (DTD) o el esquema de una base de datos. Un archivo .proto se ve así:


message Person {
required string name = 1;
required int32 id = 2;
optional string email = 3;

repeated PhoneNumber phone = 4;
}


Corres el compilador del lenguaje de tu elección y te genera las clases necesarias. Para el ejemplo del archivo .proto anterior genería una clase Person y una clase PhoneNumber, que puedes usar para serializar y enviar la clase por la red, o guardarla a un archivo en el disco.

Una de las principales ventajas de los Protocol Buffers es que el formato usado en el cable (lo que se envía) es binario, ocupa mucho menos espacio y es más rápido para parsearlo de vuelta. La desventaja es que no puedes editar el archivo “a mano” una vez que fue serializado.

¿Alguien planea usar Protocol Buffers en un proyecto? Cuenten su experiencia…

Incluir videos de youtube en tu blog/web es super sencillo ¿no? Basta con ir al video, copiar el embed code e incluirlo en tu HTML. Funciona para Firefox y toda la plétora de navegadores, menos IE7 (si no, que chiste) que te tira un error “Operación Anulada” o en Inglés “Operation Aborted” y adiós tu página.

El problema: youtube te da el siguiente código para incluir los videos:




Solo hay que sustituir el $VIDEOID por el id del video que queremos ver. ¡MAL!. El problema es que la etiqueta embed comparte la misma suerte que el Dodo y no debe usarse más. Claro que, como youtube te dió el código, pues confias. ¿Cómo lo podemos cambiar para que IE7 no se muera?

Simplemente agregamos el atributo data a la etiqueta object, y ahí le indicamos la URL del video que deseamos incluir. Adiós problemas, el sitio valida, e IE7 no se muere.

“Java doesn’t do anything by itself. It’s a programming language (…) Java wants to be in your face. Java wants to be updated. Java wants to tell you the good news about Sun. Have you heard about Sun? Here’s a nice picture of our logo. And fancy a copy of OpenOffice? No? Well, never mind. Java’s installed a copy of Yahoo Toolbar in your browser instead. Because that’s what programming languages are there to do, right?”

Annoying software: a rogues’ gallery

El link me lo pasó Pablo

Seguimos con los problemas de Code Igniter, esta vez con respecto al manejo de las cookies.

El problema: en averalcine.com usamos cookies para saber que ciudad eligió el usuario, de tal manera que el usuario no tenga que seleccionar una ciudad cada vez que entra al sitio. ¿Ningún problema no? el código funciona de maravilla en Firefox, Safari, Opera, hasta en IE6, pero no en IE7. Mi primera reacción fue culpar al modo protegido de IE7, pero este solo funciona cuando se ejecuta bajo Windows Vista, y tenía una computadora con Windows XP, IE7 y aún así el problema persiste.

La solución: como toda la vida (en la Web), terminamos sacándole la vuelta al error introducido por Internet Explorer. Esta vez no es tanto error per se, sino una característica:

En IE, las políticas de privacidad por defecto entran en funcionamiento para iframes interdominio, especialmente con JavaScript, lo que previene guardar cookies. Si imprimes el session id de la cookie en la página que se carga en el iframe, verás que cambia en cada recarga de la página. Configura una política de privacidad como se define en http://www.w3.org/P3P/ y lo solucionarás.

¿Así o más fácil? (es sarcasmo). En vez de batallar con soluciones únicas para IE, decidimos usar “cookies” del lado del servidor, donde todo el estado se guarda en la base de datos. Introduce más carga al servidor, y el tiempo de respuesta se incrementa, pero funciona en todos los navegadores que hemos probado hasta ahora.

Web Designers: POR FIN le pueden dar a los clientes el control del contenido de sus sitios, sin que estropeen el diseño.

Antes ya se podía, pero había que instalar – o programar – un CMS (Content Management System) y adaptarlo al sitio, asignar usuarios, hacer pruebas, capacitar empleados inútiles, etc.

Ahora, CushyCMS permite de manera fácil y rápida (en serio) poner en manos del cliente el manejo del contenido sin prolongar más el tiempo de desarrollo ni añadir al presupuesto del proyecto. Basta con sólo añadir la clase cushycms al elemento que deseamos dejar editable y listo (por ejemlo envuelve en una <div> el área de texto que vas a dejar editable y la pones como <div class=”cushycms”> y listo). Además, las imágenes son editables de la manera siguiente: <img src=”foo.jpg” class=”cushycms”> y el sistema la va a ajustar a las dimensiones de la imagen que está sustituyendo.

El manejo de usuarios y permisos es un pan, sólo necesitas el acceso FTP y seguir las instrucciones. Para dar de alta un editor, sólo necesitas su e-mail y el sistema le manda instrucciones. El video tutorial en la página es de lo más sencillo; si alguien tiene la inteligencia suficiente para usar hotmail, seguramente puede editar un website de esta manera.

By The Way es, y siempre será GRATIS.

Supera eso Contribute, ($169 US) JA!

Iba a pasar tarde o temprano: http://sourceforge.net/projects/openext/

La situación legal de Ext de la cual hablamos anteriormente provocó que algunos de los miembros de la comunidad Ext hicieran algo al respecto. En las propias palabras del autor, OpenEXT no es un fork sino que lanzarán parches encima de ExtJS 2.0.2 (la última versión LGPL) en vez de redistribuir versiones completas de Ext modificadas.

Veamos si esto es suficiente para atraer usuarios de Ext inconformes por el cambio de licencia.

(Via Ajaxian. Y lean el artículo original, dice muchas cosas muy interesantes)