Después de haber disfrutado anoche de la película de Los Simpsons (si te gustan, no te la pierdas, es buenísima!), me tomé un ratito (un domingo aburrido…) en entrar a la página de los simpsons… está muy buena (aunque el uso de flash es obligatorio), y aunque no la recorrí toda, pude crear un avatar con la paleta de colores, barbas, cabello, ojos, nariz, etc. de los Simpsons. Y tratando de hacerme a mí mismo, me salió esto:
Me pareció muy original la idea y divertido a la vez. 🙂
Hace unos meses había salido la noticia de la presentación de Microsoft Surface, que aunque no va a estar disponible hasta fines de 2007, sus videos permiten apreciar una nueva manera de interactuar con una computadora, ya que el Touch Screen horizontal posee un sensor Multi-touch. Una combinación de hardware y software donde una o varias personas interactuaban en una «mesa digital», al mismo tiempo… realmente es muy interesante! (más alla de que Microsoft lo sepa vender bien).
Como decía Angel Lopez en su momento, «para la adopción de esta tecnología, es fundamental que exista software que lo aproveche y que su costo sea accesible». Creo que teniendo en cuenta lo segundo, será difícil la implementación de Surface dado el contexto y la situación argentina, conociendo la estrategia de «precios globales» (léase: globales = en dólares accesibles para la gente del primer mundo) de Microsoft (aunque cada tanto estas noticias aisladas contradigan esta política y parezca que ceden ante la realidad del tercer mundo, sólo es la confirmación de que portándose así pierden competitividad frente al software libre/abierto).
Pero bueh, no me quiero desviar del tema. 😀
Pensándolo como implementación alternativa a esta tecnología, me encontré en algún post de algún blog, la página del Multi-Point X Server, que como dice su página es una modificación al X Server tradicional, que permite que varios dispositivos de entrada interactúen con las aplicaciones que todos conocemos («legacy») más el desarrollo de nuevas aplicaciones, dando soporte para los n dispositivos de entrada y n focos en la misma pantalla.
Ahora, si combinamos el Multi-Pointer X Server, con una tableta Diamond Touch (que soporta el multitouch), obtenemos esto:
Como pueden ver, este bicho corre Ubuntu (o Kubuntu, no se ve). 😛
Pero sí se aprecia el Google Earth, Firefox, el Gimp y hasta un programa (tipo Paint) seguramente programado según la interfaz extendida al XInput (aunque lo importante es que es compatible hacia atrás). Al final del artículo con el video, se aclara que esta versión de XServer es independiente del dispositivo hardware; «usted puede utilizar su DiamondTouch, su tabla FTIR, o – si usted puede comprar una – su tabla MS Surface».
Y la remata con: «Ah, y por si acaso; usted puede utilizar un mouse estándar y un teclado en la misma CPU al mismo tiempo que utiliza el touchscreen. Después de todo, cualquier cosa es sólo un dispositivo más. Este es el último gran cambio, luego voy a subir los cambios al proyecto MPX».
Luego, en este post, luego de la avalancha de visitas por el video de Youtube, se brindan más detalles.
Después de algún tiempo de sacrificado laburo, me dí uno de los mayores gustos «informáticos» hasta ahora: comprarme un monitor LCD de 22″ wide… más precisamente el Samsung Syncmaster 226 NW. 😀
De más está decir que es fantabuloso cómo se ve cualquier cosa que uno quiera ver. No hay «efecto arrastre» al hacer scroll, excelente contraste, excelente resolución y nitidez… Lo único «malo» técnicamente es que no viene con conexión DVI.
Sobre esto último, leí por ahí que en Argentina el IVA es del 21% para los monitores con DVI, en cambio para los con conexión VGA analógica es el 10,5%; de hecho, acá en Argentina los 206/226 BW (son iguales pero con DVI) no se venden (un garrón).
Llegué a casa, saqué el viejo y querido Samsung 796MB y me dispuse a disfrutar mi Ubuntu Feisty con él. Claro, Ubuntu estaba configurado con la «vieja» resolución (1024×768). Tenía que cambiar a la «nueva» resolución: 1680×1050 (los monitores LCD siempre deben estar a resolución nativa); para eso, abri una consola y ejecuté «dpkg-reconfigure xserver-xorg». Joya, seleccioné las resoluciones que quería (1680×1050 entre ellas), me generó un xorg.conf nuevo (con las resoluciones/configuraciones seleccionadas, haciendo un backup del xorg.conf anterior) y reinicié la PC.
Pero me encontré con un (bug?) problema: Gdm no arrancaba! 🙁
El síntoma era: X arrancaba, parece que arrancaba de nuevo, veía el fondo «cuadriculado» en blanco y negro típico de X y el cursor de Gnome en «espera». Listo, no pasaba más de ahí. Era cuestión de hacer Ctrl+Alt+F1 y loguearse en la consola de texto. Hice un «top» y me mostraba el Gdm funcionando, pero comiéndose la CPU al 100%! No quedaba otra más que matarlo. Arrancando con el Live-CD de Ubuntu, el proceso de arranque detectaba los 1680×1050 y pude usar Gnome desde el CD como si nada.
Si volvía al xorg.conf anterior, funcionaba, pero no tenía resolución nativa. Utilizando nvidia-settings claro que podía configurar el monitor a la resolución que quería, pero setearlo a mano cada vez que iniciaba sesión no me parecía una opción. Tenía que googlear, y encontré este link. Sencillito. Fui hasta la parte de «drivers nvidia» (tengo una Nvidia 6600) y ejecuté el nvidia-settings como root, generé con el programa un xorg.conf nuevo desde ahí y restartié gdm. Ahora sí arrancaba bien, y a 1680×1050.
Pero me faltaban los efectos de Beryl (Compiz Fusion está en desarrollo todavía). Claro, el nvidia-settings sí incluye la opción de GLX, pero no incluye el Composite (creo que es necesario todavía)… bah, en realidad me generó un xorg.conf bastante limpito, y tuve que copiar/pegar algunas opciones de configuración que en su momento agregué para Beryl.
Conclusión: Bueh, fue un rato dando vueltas; a Ubuntu (y las distros GNU/Linux en general) les queda un poco de laburo el tema de la configuración de las resoluciones de los monitores (estamos en el 2007 y uno tiene que configurar el xorg.conf a mano…). Esperemos que en Ubuntu 7.10 Gutsy Gibbon, con este proyecto que va a estar incluído, más X.org 7.3, este problema se solucione.
Continuando el post de ayer, otra desventaja del sistema de persistencia de Django es que no soporta atributos en relaciones «Muchos a Muchos». Un caso podría ser Usuario <–> Rol, donde un Usuario puede tener varios Roles y a su vez un Rol ser referenciado por varios usuarios; además, necesito almacenar si alguna combinación usuario<->rol está activa o no. El atributo booleano «activo» sería una propiedad por cada Usuario<->Rol en particular, y esto es lo que no soporta Django con su ManyToManyField.
En cambio SQLObject sí los soporta. Ejemplo:
class Usuario(SQLObject):
class sqlmeta:
tabla ='tabla_usuario'
nombre_usuario = StringCol(alternateID=True, length=20)
roles = SQLRelatedJoin('Rol',
intermediateTable='roles_usuario',
createRelatedTable=False)class Rol(SQLObject):
nombre = StringCol(alternateID=True, length=20)
usuarios = SQLRelatedJoin('Usuario',
intermediateTable='roles_usuario',
createRelatedTable=False)class RolesUsuario(SQLObject):
class sqlmeta:
table ='roles_usuario'
usuario = ForeignKey('Usuario', notNull=True, cascade=True)
rol = ForeignKey('Rol', notNull=True, cascade=True)
activo = BoolCol(notNull=True, default=False)
unique = index.DatabaseIndex(usuario, rol, unique=True)
class Usuario(SQLObject):
class sqlmeta:
tabla = 'tabla_usuario'
nombre_usuario = StringCol(alternateID=True, length=20)
roles = SQLRelatedJoin('Rol',
intermediateTable='roles_usuario',
createRelatedTable=False)
class Rol(SQLObject):
nombre = StringCol(alternateID=True, length=20)
usuarios = SQLRelatedJoin('Usuario',
intermediateTable='roles_usuario',
createRelatedTable=False)
class RolesUsuario(SQLObject):
class sqlmeta:
table = 'roles_usuario'
usuario = ForeignKey('Usuario', notNull=True, cascade=True)
rol = ForeignKey('Rol', notNull=True, cascade=True)
activo = BoolCol(notNull=True, default=False)
unique = index.DatabaseIndex(usuario, rol, unique=True)
Como se puede apreciar, al pasarle la propiedad «createRelatedTable=False» al SQLRelatedJoin, el programador puede definir por sí mismo la clase que «une» el Muchos a Muchos y agregarle atributos, como primera medida. Lo segundo es, además de crear los ForeignKey correspondientes, crear el índice de tipo ‘unique’ sobre los dos atributos FK, usuario y rol. Más info sobre esto acá.
No recuerdo alguna(s) otra limitación(es) tan importante(s) como éstas dos de la librería de acceso a BD de Django, pero SQLObject parece «pulenta» para desarrollos serios.
Conclusión: TurboGears es «la competencia» de Django; en mi opinión (por lo poco que ví) en la parte de acceso a BD al incluir SQLObject, parece mucho más maduro que Django. Django no es malo, simplemente le falta madurar (más que nada en la definición de modelos). SQLObject se puede usar aparte, de hecho tiene un sitio propio y se puede utilizar de forma independiente.
Por otra parte, la librería de templates de Django es excelente, acá nos gustó mucho y de hecho lo utilizamos separado de Django en algún que otro sistema con excelentes resultados (sí, se puede utilizar aislado). No nos gustó tanto a la vista el de TurboGears, pero será cuestión de probar de forma más «seria» TG y hacer una evaluación más completa.
