Dashcode, como hacer widgets para OSX

Cuando hablamos sobre desarrollo en OSX, raudo y veloz aparece en nuestra mente el nombre de XCode. Si bien es cierto que es la herramienta de referencia ( Sin olvidarnos de Interface Builder, claro), hay otra alternativa para desarrollar software en OSX.

Esta otra manera es mas o menos reciente, y la aplicación que nos va ayudar a crearla se llama Dashcode. La primera versión del sistema operativo de apple en el que podemos usar esta herramienta es en Leopard 10.5, y forma parte del grupo de herramientas para desarrolladores. Actualmente se puede usar Dashcode tanto para crear widgets para el Dashboard como para crear webs personalizadas para el iPhone. Este último dato es lo que lo convierte en una alternativa para desarrollar aplicaciones para el smartphone de apple.

Esta aproximación al desarrollo de aplicaciones para el iPhone tiene como gran punto negativo las limitaciones que impone el que realmente estas desarrollando una aplicacion web, pero pero como puntos positivos tiene el hecho de que no hace falta comprar ninguna licencia para desarrollar, y que la dificultad de desarrollo con respecto a la programación de aplicaciones nativas es bastante mas asequible.

Uno de los aspectos que hacen el desarrollo más sencillo es el lenguaje escogido para desarrollar dichas aplicaciones. HTML + Javascript hacen las veces de Objective-C en Dashcode, nuestros widgets realmente se pueden asemejar a porciones de páginas web. Aún así esta eleccion no nos debe hacer pensar que estamos limitando las posibilidades, pues en el caso de los widgets para el dashboard podremos usar mucha de la funcionalidad que tambien podemos acceder desde una aplicación Cocoa, ya que desde javascript podemos acceder a estos modulos mas cercanos al Sistema Operativo.

Para muestra, un boton, en el siguiente enlace podreis ver algunos de los widgets actuales para dashcode.

Junto con Dashcode se incorpora un montón de componentes “prefabricados” como listas, botones, paneles, que podemos usar en el desarrollo de nuestros widgets.

El propio IDE también nos facilita mucho el trabajo, sin tener mucha idea de como funciona todo podemos realizar ejemplo sencillo en cuestion de minutos. Estas ayudas se traducen en autocompleting de Javascript y HTML, edición gráfica de los widgets, y debugger incluido.

Aunque tampoco debemos dejarnos engañar, como con casi todo, manejar a fondo los componentes ( llamados “parts” ) que se pueden insertar en los widgets lleva su tiempo de aprendizaje.

En general podemos concluir que siendo consciente de sus limitaciones, es una gran alternativa al desarrollo tradicional de aplicaciones.

Incorporar Modelos ManyToMany al Backend en Django

Uno de los beneficios de usar django para crear nuestra aplicación web es que como por arte de mágia, todo el backoffice de nuestra aplicación se generará ante nuestros ojos sin tirar ni una linea de código.

Parafraseando a Uderzo y Goscinny, ¿Ni una sola linea?, No, alguna, cual aldea Gala indestructible, habrá que tirar, pero ni mucho menos comparable a lo que sería hacerlo desde cero.

Hasta hace poco, si en nuestro modelo exitía una relación Muchos a Muchos, la edición desde la interfaz de administración no era todo lo intuitiva que esperaríamos, pero en la última versión de django este aspecto esta solucionado, proporcionandonos una flexibilidad absoluta.

Supongamos un modelo de un sencillo bloc de notas, inicialmente tendremos dos entidades, una que será las notas y otra que serán los tags que asociamos a dichas notas. La relación entre los tags y las notas es de Muchos a Muchos, el código de dichos modelos sería algo como:

class Note(models.Model):
  title = models.CharField(max_length=200)
  pub_date = models.DateTimeField('date created')
  body = models.TextField()
  tags = models.ManyToManyField('Tag', related_name='notes')

  def __unicode__(self):
    return self.title</div>

class Tag(models.Model):
  name = models.CharField(max_length=100)

  def __unicode__(self):
    return self.name

Por defecto, django nos genera una interfaz de administración que podemos ver si entramos a la aplicación “admin” una vez lanzado el servidor. Si usamos el servidor de desarrollo, la URL habitual es http://localhost:8000/admin/

Como deciamos anteriormente, en las versiones anteriores de django, solo podíamos editar (y personalizar usando Inlines por ejemplo) los elementos de la clase asociada donde se definía la relacion ManyToMany. En nuestro caso, solo podriamos asociar y añadir tags desde la gestión de notas, pero no viceversa. Al ser una relación bidireccional, como vemos esto no es muy útil.

Para personalizar las interfaces de administración debemos editar el fichero admin.py que esta dentro de nuestro proyecto.

Si queremos que la lista de objetos de la clase asociada aparezca de forma linear, podemos crear un objeto derivado de algun sabor de Inline, como por ejemplo TabularInline. La novedad en la nueva versión de django es que a la clase que modela la relación ManyToMany posee un atributo que representa la asociación.

Este atributo se conoce como through, en versiones anteriores, ese parámetro nos servía para indicar un modelo extendido asociado a la relación muchos a muchos, a la hora de declarar la propia relación en el modelo.

Así si usamos las siguientes clases:

class TagNoteInline(admin.TabularInline):
  model = Note.tags.through

class TagAdmin(admin.ModelAdmin):
  inlines = [
    TagNoteInline,
  ]

class NoteAdmin(admin.ModelAdmin):
  inlines = [
    TagNoteInline,
  ]
  exlude = ('tags',)

admin.site.register(Note, NoteAdmin)
admin.site.register(Tag, TagAdmin)

Podremos editar en ambas interfaces la clase correspondiente asociada.

Para finalizar, si no has entendido nada quizás te interese el maravilloso tutorial que esta en la propia web del django y concretamente la relacionada con la parte de administración: http://docs.djangoproject.com/en/dev/intro/tutorial02/#intro-tutorial02

Navegadores y futuro de las aplicaciones web

Poco a poco nos estamos dando cuenta que el futuro de las aplicaciones apuntan a “la nube”. Google ha apostado por ello con cosas como GMail, Wave o el reciente Chrome OS. Como elemento imprescindible en esta migración, estan los navegadores, los “vehiculos” hacia la nube. Pero, ¿están preparados los navegadores para esta migración?

Cuando la web empezo a ser web, nadie se podía plantear que de aquel lenguaje de marcado derivado del SGML como era el HTML se podría crear todo una plataforma de desarrollo de aplicaciones. Para que esto fuera posible se incorporó un lenguaje que dotara de dinamismo a las, por aquel entonces novedosas, paginas webs. Estamos hablando de ECMAScript, mas conocido con el “desafortunado” nombre Javascript. Desafortunado por su parecido con Java, del que no tiene nada que ver.

Indudablemente se podría hablar mucho de Javascript, como por ejemplo de las primeras implementaciones en los navegadores, de JScript, de su caprichosa sintaxis, etc., pero este, no es el objetivo de esta entrada

Javascript ha sido uno de los grandes “culpables” de que hoy contemplemos como futuro las nuevas aplicaciones web, sin embargo, también ha sido el culpable de muchos quebraderos de cabeza para los desarrolladores de navegadores. Dichos navegadores llevan intentando optimizar el motor que se encarga de interpretar el Javascript desde hace mucho tiempo, sin embargo el desarrollo de dichas aplicaciones ha acelerado mas rápido que la esperada optimización.

Google juega uno de los papeles mas importantes en esta evolución y es muy consciente que a día de hoy, Javascript es un “problema” desde el punto de vista del rendimiento. Uno de los pilares de la presentacion de Chrome fué precisamente un nuevo motor opensource de javascript, el V8. Sin embargo, actúalmente parece que el problema sigue latente.

Además de la nueva implementación de google existen multitud de motores de Javascript, como Rhino de la fundación Mozilla, JavaScriptCore que implementa Safari o Carakan en Opera, pero a vista de los resultados actuales parece que mas de uno sigue sufriendo cuando debe ejecutar una aplicación compleja.

Para darse cuenta de todo esto, solo hace falta escoger un navegador y ponerse a dar vueltas por la aplicación web de moda, Google Wave. Si bien es cierto que la propia aplicación esta en una fase muy previa a considerarse estable, es cierto que el problema también se presenta en otros casos similares como por ejemplo Google Maps, aunque es cierto que de una manera mucho menos acusada. En el caso de Google Wave el problema es tan grave que deja el navegador totalmente inusable, en el caso de navegadores “monoproceso” como firefox, la unica solucion es “matar” al propio navegador.

Para probarlo en nuestras carnes, solo hace falta introducir una busqueda que incluya waves publicos, como por ejemplo introducciendo el texto “rpg with:public” y empezar a navegar por los waves. Rápidamente obtendremos resultados como los de las siguientes imágenes.

Firefox en linux ejecutando wave

Safari en OSX ejecutando wave

Chrome en Windows ejecutando wave

Por tanto a la pregunta del inicio del post, yo de momento tengo que decir, no, los navegadores aún no estan preparados para un salto total a la nube. Y si además introducimos en la ecuación los navegadores de dispositivos menos potentes como smartphones y versiones “light” de chrome o safari, aún la situacion se complica mas.

Aplicaciones Web como “verdaderas aplicaciones”. ¿Alguien dijo Chrome OS?

Hoy en día todos usamos numerosas apliaciones web, en ciertos casos incluso han desplazado a las aplicaciones tradicionales.

Quizás la primera aplicación web que nos viene a la mente es GMail, en muchos ocasiones es el unico cliente de correo que utilizamos.

La forma de acceder a estas aplicaciones es mediante el navegador, sin duda una de sus grandes ventajas es el hecho de que pueden accederse desde cualquier lado sin embargo, el navegador es un “concepto” que no acaba de encajar con “aplicación”. Conceptualmente, el navegador no se asocia al hecho de alojar aplicaciones.

Cuando estamos manejando una aplicacion como Gmail o Google Wave, hay varias cosas de un navegador que no acaban de encajar, por ejemplo,

• No necesitamos la barra de direcciones, no vamos a cambiar de página en el contexto de la aplicación
• No necesitamos los controles del navegador, como por ejemplo para navegar por la historia, ya que dentro de una aplicación, no se vuelve hacia atras usando dichos controles.
• No necesitamos las extensiones habituales del navegador, y de hecho prescindir de esto aligerará la memoria ocupada por la aplicación, que en el caso de ciertas aplicaciones ya es bastante.
• En el caso de que la aplicación quiera enviar alguna notificación, como por ejemplo un mensaje nuevo recibido en GMail, será el navegador el encargado de enviar dicha notificación. Si tenemos en cuenta que una sesion actual en un navegador tiene muchas pestañas, la posibilidad de notificar directamente por parte de la aplicación web se complica.
• La aplicación no aparece al mismo nivel que el resto de aplicaciones del sistema. Como ejemplo pongamos que queremos cambiar del Editor de Textos al gestor de correo, antes deberiamos pasar primero por el propio navegador. Cosa que es bastante incomodo.

Como vemos, las aplicaciones web piden a gritos salir del navegador y convertirse en aplicaciones “de ley” en nuestro escritorio.

Existen diversas alternativas para “extraer” estas aplicaciones del navegador y convertirlas en una mas de nuestro sistema operativo.

Una alternativa es Prism. Prism es un proyecto de mozilla, que como es evidente usa el motor de renderizado del firefox para crear mostrar la página web. El resultado que obtenemos de usar prism es un programa como otro cualquiera y que al ejecutarlo accederemos a la aplicación quitando todas las decoraciones del navegador.

Si usamos mac, tenemos Fluid, cuyo objetivo es similar.

Y como no, la estrella de toda esta iniciativa de aplicaciones web, google tiene su propia alternativa para crear aplicaciones reales a partir de sus similares en web.

Usando Chrome, podemos separar las webs como aplicaciones mediante la opción de menu llamada: “Crear accesos directos a aplicaciones…”. Usando esta opción las aplicaciones tendrán su propia entidad en el escritorio, apareciendo como cualquier otra en la barra de tareas, o como acceso directo junto al resto de aplicaciones del sistema. Además, cuando lancemos las aplicaciones desde este entorno, se eliminaran los elementos que antes mencionábamos como accesorios.

Seguramente y como mencionaba en el titulo de la entrada, muy pronto estaremos hablando de este concepto mucho mas en serio, puesto que, sacando la bola de cristal del cajón, viendo las últimos movimientos de google, mucho me temo que la idea sobre la que se basa Chrome OS, puede ir por estos derroteros.

Introducción a Django

En el anterior post hablamos en general de los frameworks de desarrollo rápido que habían surgido recientemente. Concretamente nos vamos a centrar en Django por los motivos que comentamos anteriormente.

Django surgió en una redacción de noticias donde requerían una herramienta flexible que les permitiera realizar cambios de una forma ágil. Básicamente el framework nos va a permitir crear aplicaciones basadas en el modelo MVC, que usen operaciones de CRUD ( Create, read, update and delete) o como lo conocemos en español el típico Altas, Bajas Modificaciones y Consultas.

¿De que forma nos va a ayudar?
Principalmente creando toda la lógica de la gestión de nuestras clases con la base de datos.
Además de proporcionarnos toda la API para la gestión de los datos, Django nos va a proporcionar dos cosas adicionales:

• Una interfaz web genérica auto-generada para gestionar los datos
• Una API para construir webs que gestionen estos datos.

Durante las sucesivas entradas veremos a ver si realmente el framework nos va a ayudar a crear nuestra aplicación, particularmente en mi contacto con este tipo de frameworks si te adaptas bien a la filosofía del framework nos va a ayudar bastante en la creación de nuestra aplicación.

En este primer post vamos a ver la instalación del framework y después crearemos el esqueleto de nuestro primer proyecto.

A la hora de instalarlo tenemos varias alternativas, si usamos una distribución que incluya django como paquete solo tendremos que instarlo, ahora mismo estoy escribiendo desde Ubuntu 9.04 y solo he tenido que ejecutar apt-get install python-django.
Si nuestra distribución no esta soportada directamente o bien usamos OS X o Windows, debemos bajarnos la ultima versión del sitio web de django ( http://www.djangoproject.com/download/ ) y ejecutar setup.py install con privilegios de administrador.

Una vez que lo tenemos instalado el primer paso es ejecutar el script que va a crear el esqueleto de nuestra aplicación:

$ django-admin startproject pruebadjango

Con esta orden se nos creara un nuevo directorio llamado pruebadjango con los siguientes ficheros relevantes:

• manage.py: Script que nos va a permitir realizar las diferentes labores de administración sobre la aplicación como gestionar el servidor web embebido que tiene django o la relación con la base de datos
• settings.py: Fichero que contiene los parámetros de configuración de nuestra aplicacion, como por ejemplo los datos de conexión a la base de datos
• urls.py: Fichero donde se especifican los mapeos entre las URLs y los paquetes que van a gestionar esa URL, para los que hemos usado Java y sus aplicaciones web, seria una especie de web.xml

Como buen impaciente , lo primero que haremos sera ejecutar el servidor, aunque no tiene nada que mostrar, al menos nos confirmará que vamos por el buen camino.

Para ejecutar el servidor debemos escribir:

$ python manage.py runserver

Y si navegamos con el browser a la direccion http://127.0.0.1:8000/ veremos la imagen dela captura, lo que confirmará que tenemos instalado django correctamente y creado nuestro esqueleto que nos va a servir como base en futuras entregas.

Hablando del servidor, una de mis inquietudes con estos frameworks y que aun no ha sido del todo resuelta es como se comportan en entornos donde la exigencia es grande. Aplicaciones web basadas en java reposan en servidores de aplicaciones muy potentes que nos garantizan un buen rendimiento. En este aspecto Grails con Groovy tiene algo ganado, al fin y al cabo es java, y puede aprovecharse de todo lo que apoya a Java. En el caso de frameworks como el que nos ocupa, la fiabilidad viene por Apache y el mod_python. En el ejemplo que hemos propuesto usamos el servidor web embebido en django, sin embargo este servidor solo vale para entornos de desarrollo, a la hora de cambiar a produccion usaremos Apache.