Demóstenes García G.

Flex Builder 3 + Perforce plugin

Wed, 11 Apr 2012 13:02:35 -0500

Hoy tuve que trabajar en un proyecto utilizando Flex 3 (argh), para ello debía trabajar sobre Flex Builder 3. El proyecto utiliza Perforce como SCM (Source Code Management).

Una mala combinación, ¿no?. En fin, es lo que hay.

Para hacerlo funcionar teníamos que buscar una versión específica del plugin de Perforce que funcionara con Eclipse 3.3.1. Curiosamente si era para Eclipse 3.3 o para Eclipse 3.4 no funcionaba, así que tenía que haber una que funcionara perfecto para 3.3.1. Luego de 30 minutos leyendo encontré que la versión 07.3 funciona perfecto con esta versión de Eclipse (y por ende con Flex Builder 3).

Lo único que tenemos que hacer es descargar la versión 07.3, descomprimirla y tirar lo que está dentro de /features (un .jar) en C:\Program Files (x86)\Adobe\Flex Builder 3\features y lo que está dentro de /plugins (un par de .jar) dentro de C:\Program Files (x86)\Adobe\Flex Builder 3\plugins

Reinicias el Flex Builder, te vas a Window -> Preferences -> Team -> Perforce y debería funcionar todo perfectamente.

Espero que le sirva a alguien algún día y que no pierdan casi una hora revisando que versión le funciona exactamente.

CFBundleShortversion y Appcelerator 1.8.x

Sun, 01 Apr 2012 16:14:38 -0500

Hoy, intentando sacar una nueva versión para CarteleraPanama para iOS, me encontré con un problema bastante curioso. Luego que intenté varias veces de validar la aplicación, me tiraba un error que decía:

CFBundleShortversion should be higher then previous upload (…)

Curiosamente esto ya lo había tomado en cuenta (duh!) y había subido de la versión 1.1 a la versión 1.2. Viendo por aquí y por allá al parecer el problema es que al compilar, CFBundleShortVersionString siempre es 1.0, sin importar lo que tengas en el tiapp.xml.

Este error ya fue corregido en el SDK 2.0 de Appcelerator, sin embargo el mismo no ha sido liberado completamente, así que el workaround es bastante sencillo:

Te vas a /<project>/build/iphone
Copias Info.plist y lo pegas al root de tu proyecto, justo donde está el tiapp.xml.
Abres el archivo en cualquier editor de texto y editar CFBundleShortVersionString para que tenga tu nueva versión, en mi caso es 1.2.
Compilas nuevamente. Quizás sea necesario que limpies todo el proyecto (Project -> Clean).

Una vez recompiles, el compilador tomará en cuenta tu Info.plist y lo utilizará.

Less y Sass. Si estás escribiendo CSS sin ellos estás perdiendo tu tiempo.

Sun, 29 Jan 2012 17:34:13 -0500

Se que también te ha pasado lo siguiente: tienes un CSS de más de 800 líneas y realmente se vuelve un desastre total mantenerlo. Logras tener líneas que se ven como:

body#about div#content p.info span.important { …

Así hemos hecho los CSS desde hace mucho, el detalle está en que escribir tanto por un CSS puede lograr ser fastidioso, propenso a errores y ahora con CSS3 y tantas cosas lindas que se pueden hacer con las bondades del CSS3 y de paso le agregamos un par de motores de renderizado diferente que incorporaron estas características desde antes que se volviera un estándar (-moz-border-radius/-webkit-border-radius -> border-radius) y tenemos que soportarlos. Al final: más código para hacer algo que en teoría es simple.

Todo esto se volvería un desorden absoluto, con líneas y archivos enormes, código notablemente repetido y cuando tenemos que hacer modificaciones muchas veces nos perdemos.

Aquí es donde interviene Sass (Syntactically Awesome Stylesheets) y Less. Las dos logran lo mismo: hacer que escribir CSS sea divertido (nuevamente). Sass tiene su propia sintaxis, aún cuando en Sass 3 permite la misma sintaxis de SCSS (que es más bien un CSS tabular). Less, por su parte, tiene una sintaxis muy parecida al SCSS, con algunas diferencias. Si vienes de CSS te parece más natural todo usar SCSS con Sass o simplemente irte con Less.

Dentro de los últimos 6 meses pude hacer proyectos Sass y Less y en conclusión les puedo decir que si hoy siguen haciendo el CSS de la misma manera ESTÁS PERDIENDO TU TIEMPO y debes obligatoriamente echarle un ojo a estas tecnologías.

Sass

Si haces Ruby on Rails ya debes saber que es Sass. Sass es una extensión de CSS3 que permite escribir CSS anidado, con una sintaxis mucho más cómoda y sencilla que la de CSS convencional.

Igualmente posee las siguientes características:

Se compila a CSS ordinario usando ya sea una herramienta por línea de comandos o alguna herramienta de escritorio como CodeKit (Mac). Yo usé un script en Ruby en la línea de comandos que dejaba corriendo siempre.
Posee variables, así si tienes un mismo valor (un color, un tamaño o varios tamaños, etc) puedes grabarlo en una variable y reutilizarlo.
Permite tener una sintaxis anidada (como cualquier lenguaje de programación) de dos tipos: al estilo Sass donde no hay llaves ({) y los espacios son importantes o al estilo SCSS donde si hay llaves y es anidado. así si tienes un elemento que está contenido dentro de unas llaves quiere decir que es el hijo del otro elemento.
Mixins: piensen en funciones que están para evitar la repetición de código.
Gran cantidad de funciones por defecto. También permiten operaciones matemáticas básicas (pore ejemplo para agrandar tamaño de letras.
Compass: Un pequeño framework para hacer el trabajo con Sass menos repetitivo. Ya tiene mixins, variables y demás elementos que te hará la vida feliz.

Veamos un ejemplo de Sass:

Less

Less es muy parecido a Sass, con el único hecho que necesita (no obligatoriamente) un Script en JavaScript para su interpretación de Less a CSS común. Lo que si cabe destacar es que hay herramientas como Less.app (Mac) y algunas en la línea de comando que transforman Less a CSS directamente.

Las características son muy parecidas a Sass y ofrecen lo mismo que Sass, además de:

Pueden correr en el servidor con Node.js o Rhino. Muy útil si utilizas Node.js en el server para alguna aplicación móvil o algo.
No necesitas un compilador a CSS si no quieres. Puedes utilizar su interpretador en JavaScript.
Tiene mixins, variables, operaciones matemáticas y funciones básicas, igual que Sass.
Parametric Mixins: Esto está bueno. En español sencillo son funciones que pueden representar clases de CSS o funciones directamente. Así tenemos un mixin que se llama “.border-radius” quiere decir que los elementos pueden tener class=”border-radius” y utilizarán los parámetros establecidos o dentro de nuestro código ligeramente podríamos hacer { .border-radius() } y el ejecutaría en vez de una clase un mixin. Leer más.
Less no tiene Compass, pero hay una alternativa muy buena llamada Preboot, utilizada como base del Bootstrap de Twitter.
Comentarios con //.

En conclusión les puedo decir que ya yo escogí Less sobre Sass, por varias razones pero básicamente es que me he acostumbrado mucho a utilizar Less.app, me encantan los Parametric Mixins y prefiero Preboot sobre Compass.

Si tu eres un front end developer o un designer y utilizas CSS a diario y aún no estás utilizando ni Sass ni Less realmente te exhorto a que hoy mismo escojas uno y lo utilices de ahora en adelante en proyectos donde escribas más de 50 líneas de CSS. Me lo vas a agradecer.

En otras noticias, acabamos de sacar el nuevo sitio de Pixmat utilizando Less. Enjoy :).

¿Requests cortados en Nginx? Revisa los permisos

Wed, 18 Jan 2012 19:43:00 -0500

Acabo de perder al menos 2 horas tratando de arreglar un problema y es que al tratar de conseguir un request bastante grande en un script el mismo se devolvía recortado y sólo devolvía las primeras 10,000 líneas.

Ya, cuando estaba apunto de pegarme contra la pared, encontré un par de blog posts en otros idiomas donde indicaban que cuando los requests son bastante grandes el nginx comienza a grabar en disco mientras se hace el procesado de la data para su envío.

En fin, la solución fue cuestión de 10 segundos: darle permisos a las carpetas client_body_temp y fastcgi_temp dentro de /opt/nginx al usuario www-var, que es quien corre el nginx en mi caso:

¿Quieres un lenguaje para el 2012?: Que sea JavaScript

Thu, 05 Jan 2012 15:07:44 -0500

Dentro de las resoluciones para el 2012 mencioné que quería aprender bien JavaScript. JavaScript es (dejémosle el trabajo a Wikipedia):

JavaScript is a prototype-based scripting language that is dynamic, weakly typed and has first-class functions. It is a multi-paradigm language, supporting object-oriented, imperative, and functional programming styles.

Es un lenguaje de scripting, multiparadigma, “orientado a objetos” (si es que eso se puede decir de JavaScript), etc. Un lenguaje común y corriente. Hago saber que no soy experto en JavaScript y aunque desde hace varios años he trabajado con él, luego de los últimos meses he descubierto que más es lo que desconozco de este lenguaje que lo que manejo de él.

Hace poco me preguntaron que lenguaje deberían aprender en el 2012. Una pregunta difícil, hace un año hubiese respondido Ruby o Python, ahora respondería JavaScript. John Resign hizo hace poco un post sobre enseñar JavaScript como primer lenguaje, con muchos puntos a tomar en consideración, pero no me baso en ello para dar una respuesta, sino en el auge que parece que tendrá JavaScript durante este año. Web, RIA, Mobile y Server-Side: todo se puede con JavaScript.

Web / RIA

¿Quieres hacer RIA (aplicaciones ricas en internet)? Puedes hacerlo con JavaScript. Hoy en día hay frameworks específicos para esto, como Ember.JS (Spoutcore 2), Knockout y Backbone.JS que nos permiten crear productos ambiciosos en la web, proveyendo características como binding, templating y una arquitectura completa MVC.

Igualmente hay librerías como jQuery, Dojo y Mootools (todas JavaScript también) pero más orientadas a manipulaciones del DOM. Estas librerías se pueden usar en conjunto con los nuevos chicos del barrio para crear grandes aplicaciones.

Mobile

Por su parte, si quieres desarrollar aplicaciones móviles tienes a Lungo.js, Sencha Touch, jQuery Mobile (estas tres web based) y Appcelerator (aplicaciones nativas). Todas programando el mismo JavaScript (y las web based obviamente necesitas conocimientos de HTML5 y CSS).

Sólo he probado jQuery Mobile, Sencha Touch y Appcelerator. De Appcelerator ya hablé un poco pero cabe decir que ahora mismo hay dos tendencias bien marcadas en desarrollo web:

Aplicaciones nativas para el dispositivo: de esas que tu bajas e instalas y tienes un link dentro de la lista de aplicaciones.
Aplicaciones basadas en web: de aquellas que visitas un sitio y te carga una versión alterna.

jQuery Mobile, Sencha Touch y Lungo.js (una nueva alternativa española, bastante interesante) se centran en aplicaciones hechas con HTML5/CSS/JavaScript, osea la primera tendencia. jQuery Mobile me parece muy superior aún, sobretodo luego del release del 1.0.

Appcelerator, por su parte, es de la segunda tendencia. Con Appcelerator puedes crear aplicaciones nativas para Android y iPhone (e iPad) desde JavaScript directamente, sin necesidad de aprender Java (para Android) u Objective-C (para iOS).

Server-side

Aunque a mi no me interesa mucho este apartado cabe destacar que JavaScript se destaca por su performance. Aquí reina node.js:

Node.js is a platform built on Chrome’s JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

Bonus track

Otra tendencia para este 2012 me parece que serán aplicaciones web centradas en API. Sea cual sea la tecnología que uses en tu servidor deberá ser más un conjunto de servicios expuestos que una aplicación completa.

La gran ventaja de este tipo de aplicaciones es que permite que tu aplicación pueda ser utilizada en cualquier dispositivo o tecnología: sea un browser, un dispositivo móvil o una tablet o hasta una aplicación corriendo en tu escritorio.

Pensemos en Instagram, utilizan Django en el servidor pero la aplicación corre en el móvil, para ello hicieron un REST API (vulgarmente: un web service por HTTP) que consumen desde la aplicación en el dispositivo.

Así, ya sea que crees un aplicación con JavaScript en tu browser con Ember.js o utilices Appcelerator para crear una móvil sólo tendrías un código en tu servidor.

Recomendaciones: Rails o Django.

Experiencias con Rails y Appcelerator

Thu, 05 Jan 2012 10:00:00 -0500

Hace casi un mes atrás decidí comenzar con ambas tecnologías que les he dado más vuelta de lo normal: Ruby on Rails y Titanium Appcelerator. El primero es un framework de desarrollo de aplicaciones web y el segundo es un phone web based framework para hacer aplicaciones móviles con los mismos conocimientos

Al final este post sólo es una recopilación de todo lo que he notado sobre la marcha. Cabe destacar que soy un mero aprendiz en ambas tecnologías así que no me extraña que o esté en lo incorrecto. Igual me corrigen, es un honor aprender de ustedes.

Ruby on Rails

Lo que me gustó.

Buena documentación. Me sigue pareciendo aún que la de CodeIgniter es la mejor documentación entre estos frameworks, pero no tengo quejas de la de Rails.
Comunidad de calidad. Se consigue muy buen código para aprender y la comunidad ayuda de manera correcta.
ActiveRecord es maravilloso.
Pocas líneas hacen mucho. Al menos en mi caso necesitaba hacer servicios y fue súper rápido, no lo podía creer siquiera.
Gems para todo. Me pasó un caso curioso: tuve que implementar una manera de subir archivos a Amazon S3. Luego de 10 minutos lo tenía funcionando con Paperclip. Otros que me gustaron fueron Factory Girl (no había visto nada parecido y eso que si he usado Fixtures en Doctrine) y Faker.
Buenos y muchos libros. Ya me leí uno y medio y hay más por delante.

Lo que no me gustó tanto:

Magia rodeando la magia. Realmente dudo que por ahora mismo me ponga a ver como ocurren mil cosas por detrás.
Tests, tests, tests. Al menos rspec me parece estúpido. ¿Sólo porque debe verse lindo el test debo escribir tanto? Ya me dijeron que pruebe Test::Unit, creo que lo tendré que hacer. Ojo: no me quejo de probar el código, eso me parece obligatorio, pero me pasaban casos que 2/3 del código que escribía eran tests.
Esto es deprimente, pero si quieres sacar un código público es mejor que existan y corran los tests.
La comunidad del framework es gigante, la del lenguaje mismo no tanto comparada con Python.

Titanium Appcelerator

Lo que me gustó:

Buen IDE. El Titanium Studio está bastante bien. Aún cuando no soy fanático a estar usando IDE me pareció muy bueno, con la salvedad que realmente no vi que el debugger funcionara.
Algo conocido: JavaScript. Hacer aplicaciones con lo que ya medio que conoces es un alivio algo grande si comparas que tienes que aprender Objective-C o utilizar Java (que no es algo que me guste, sinceramente).
En crecimiento. Veo que hay mucho movimiento en la comunidad, el foro y el canal de IRC permanecen en movimiento, lo que es bueno, ya que encontrar soluciones es bastante rápido.
Kitchen Sink. Tienen una aplicación de prueba llamada Kitchen Sink donde resumen casi todo el framework en un ejemplo completamente funcional. Es bueno como base y como referencia. Creo que sin esta aplicación hubiese dejado de hacerlo todo.

Lo que no me gustó tanto:

Pocos ejemplos escritos. Hay muchos screencasts pero pocos ejemplos escritos. Hay uno que otro buen tutorial en tutsplus, pero nada más.
La documentación realmente no es buena. Me enredé mucho con esta documentación y la misma carece de ejemplos.
¿Libros? olvídate de eso. Al menos por ahora no hay ningún libro de Appcelerator. Si quieres aprender debes dedicar largas horas trasteando y jugando. [Update] miguelr me informó que acaba de salir un libro, realmente no me entere hasta hoy.

Al final, lo que si puedo estar seguro es que disfruté jugando con ambas tecnologías y de seguro seguiré jugando con ellas durante este año. Mi recomendación es que si tienen un chance y buscan que hacer, ahí tienen en que entretenerse y jugar.

¡Saludos!

[Titanium Appcelerator] Could not find the file *.js

Thu, 05 Jan 2012 01:53:00 -0500

Disclaimer: I tend to write everything in Spanish but this will be an exception, since I didn’t find any information while digging for a solution for this known problem while using Titanium Studio for developing mobile applications.

A couple of days ago I found this question under the Titanium Appcelerator forums. While doing my first Titanium Appcelerator application I ran into the same problem for a couple of minutes (to be honest I spent about 30 minutes on this): a big red messages that said “Application Error: Could not find the file bla.js”, as shown in the following image:

Mysteriously the file existed and was ready to be used and compiled by Titanium Studio. However, the emulator continued showing the fugly message (I really hate these Application Error messages on Appcelerator).

Anyways, the solution for this is pretty simple, as I described in the forum:

Go to Project -> Clean -> Select your project (or select to clean all projects) -> Click Ok.

Then compile again.

This will force a fresh compile and all old files will be deleted and recompiled. This may take a while, so be patient.

Hope it helps if you run into this same situation and I hope you don’t waste 30 minutes as I did.

Resoluciones 2012

Wed, 04 Jan 2012 09:52:17 -0500

Casi todos los años trato de escribir un par de resoluciones para fijarme metas a largo (y algunas a corto) plazo. Este año no sería la excepción, por lo que he decidido sacar una lista de resoluciones que espero cumplir a lo largo de este 2012, el cual espero que sea un gran año tanto en el aspecto profesional como personal.

Resoluciones 2012

Master Ruby/Ruby on Rails: Ya hice una aplicación que no pude sacar porque no tendría el tiempo necesario para mantenerla. Con lo poco que he podido hacer en Rails me han gustado varios factores: la comunidad y el código que se ve es muy bueno.
Ruby, a diferencia de Python, me cautivó mucho, aún cuando la comunidad es muy inferior que la de Python. Rails, a diferencia de Django, me divirtió mucho más. PHP seguirá siendo mi tecnología principal, más que nada por la experiencia que tengo con él, pero no dudaré en hacer algo en Ruby durante el año si tengo la posibilidad.
Crear y sacar al menos dos aplicaciones para móviles: Hice una de prueba y me pareció genial y divertido. Quiero sacar al menos dos aplicaciones móviles a lo largo del año.
Master JavaScript: Ya comencé, pero este lenguaje me está costando un poco más de lo habitual. Créanme: si piensan que por usar jQuery ya saben JavaScript, están BIEN equivocados. Este es un lenguaje que me parece va a triunfar en este 2012: para RIA, web en general, server side y hasta para mobile development. Muchas personas se están centrando sólo en HTML5, para mi JavaScript será la verdadera estrella este año, nuevamente.
Ember.js (antes SproutCore), Backbone.js, y Appcelerator son proyectos que me llamaron mucho la atención durante el 2011 y seguirán llamándome la atención en este nuevo año.
Graduarme y seguir: Me faltan dos materias para la Ingeniería y ya estoy pensando que debo hacer después.
Viajar este año fuera del país.
Comenzar a hacer ejercicio: ahora sí :P.
Aprender a cocinar: Actualmente soy un cero a la izquierda en la cocina, pero algo internamente me dice que podría hacerlo bien (con hacerlo bien me refiero a no quemarla entera).
(Pixmat) Sólo proyectos, cero horas de consultoría, divertirnos: El 2011 fue un buen año, sinceramente no tengo quejas… al menos con los números.
Lo que si sentimos durante todo el año fue: “¿es realmente esto lo que queremos hacer?” La respuesta fue un contundente “no”.
No haremos más consultoría y sólo aceptaremos proyectos completos durante el 2012. Si no tenemos proyectos a la mano lo ocuparemos ya sea haciendo servicios o aplicaciones personales o creando contenidos para la venta (templates, etc).
Tenemos en mente al menos 3 aplicaciones y servicios que queremos desarrollar durante el 2012, así que ya tenemos en que ocuparnos en nuestro tiempo.
Ayudar, enseñar y compartir: Durante el 2011 participé de algunos talleres (jQuery, jQuery Mobile, etc). Aunque no soy el mejor presentador creo que he aprendido gracias al tiempo que otras personas han dedicado para que aprenda, como retribución podría tomar un poco de tiempo para enseñar lo que aprendo.
Liberar cuanto código pueda, escribir de mis experiencias o descubrimientos, seguir ayudando a quien me lo pida o simplemente atendiendo a cualquier presentación que pueda.
Levantarme más temprano: Creo que lo ideal sería poder levantarme más temprano y aprovechar más horas del día. Con tal de levantarme 2 horas antes podría aprovechar ese tiempo en hacer algo productivo.

El año apenas empieza y tengo algunas muchas metas para este 2012, el cual espero que sea tan bueno y mejor que el 2011.

Así que bueno, mejor nos apuramos un poco y comenzamos a realizar todo que ya nos quedan 362 días para cumplir todo esto (uno de ñapa, que este año es bisiesto).

Current status: playing with Titanium (Taken with picplz.)

Thu, 29 Dec 2011 11:00:20 -0500

Current status: playing with Titanium (Taken with picplz.)

shitsirisaysdotcom: maybe a little too helpful…?

Wed, 19 Oct 2011 13:55:34 -0500

shitsirisaysdotcom:

maybe a little too helpful…?

Pasos explicados: Asegurarse que está ‘rooteado’ el...

Mon, 17 Oct 2011 10:26:43 -0500

Pasos explicados:

Asegurarse que está ‘rooteado’ el dispositivo.
Descargar este archivo. Descomprimirlo y subirlo al sd del teléfono.
Descargar Opera Mobile (NO Opera Mini).
Descargar File Expert. Le damos permiso de root a la aplicación.
Pasamos los archivos a /data/data/opera.browser.com/opera
Les damos permiso a los archivos.
Disfrutamos.

jakethelab: The saying “You are what you eat” also applies to...

Mon, 17 Oct 2011 10:23:08 -0500

jakethelab:

The saying “You are what you eat” also applies to dogs!

Usando CodeIgniter Cache más limpiamente

Tue, 04 Oct 2011 11:07:30 -0500

CodeIgniter Reactor (la versión de la comunidad) hace un par de meses traía consigo algo debajo del telón: un “driver” para Cache que podría adaptarse con otras tecnologías como APC, y Memcached.

Para la versión oficial 2.0.2 de CodeIgniter que salió en abril de este año ya traía incluída el CodeIgniter Cache. Yo mientras seguía usando la librería de Cache de Phil Sturgeon. Este fin de semana pude actualizar Panagamers a CodeIgniter 2.0.3 y con un cambio que hubo en el Core de CodeIgniter la librería quedo totalmente inservible. Tenía dos opciones: o arreglar el problema yo mismo o utilizar el Cache Library de CodeIgniter.

Me fui por la segunda, pero tuve que implementar una sub-librería para hacer que el proceso fuese igual o parecido a como lo hacía con la librería de Phil Sturgeon y bueno, he aquí este post.

Lo que se me ocurrió fue hacer otra librería llamada “Pgcache” (Panagamers Cache) que instanciaba al driver de cache, utilizando File-based Cache y que generara los nombres directamente, así podíamos seguir utilizando llamados como $this->pgcache->model(‘nombre_model’, metodo’, $parametros, $tiempo) sin tener que modificar tanto todas las implementaciones viejas. Lastimosamente si había que cambiar de $this->cache a $this->pgcache, ya que al utilizar $this->cache interpretaba el driver directamente y no era lo que queríamos, ya eso es harina de otro costal.

El código me quedó de la siguiente forma:

Breve explicación

Si notamos un poco, el constructor lo único que hace es inicializar el driver de cache, indicando que nuestro adaptador será “file” (o que utilizaremos file-based caching).

El método privado _generate_name() lo único que hace es generar el nombre dependiendo de los parámetros que estemos utilizando (como el nombre del modelo, del método que llamamos, los parámetros, etc).

Y el método model es el que hace el resto. Pienso hacer otros métodos para librerías, helpers, etc. pero por ahora nos quedamos con las llamadas sólo para los models. Este método comprueba si ya está grabado en el Cache (y está vigente) de ser así lo busca y regresa (deserializado), sino lo serializa y lo graba para entonces retornarlo.

Espero que a alguien le sea de ayuda, preferiblemente esto debió estar en inglés que hay un montón de gente pidiendo soluciones para esto en Internet, cuando tenga un poco más de tiempo hago la traducción (a menos que alguien se ofrezca :P)

¿Por qué sigo?

Sun, 28 Aug 2011 23:08:00 -0500

Es 28 de agosto de 2011, son las 10:49 p.m., estoy cansado, agotado. Quiero ducharme y dormir. Sin embargo no puedo.

Sí, estoy agotado, acabo de llegar de la final de los World Cyber Games 2011, en donde participé junto con el resto de Panagamers como organizadores de la categoría de Counter-Strike. Luego de casi un mes organizando, hoy terminamos todo. Durante todo este mes he ganado/descubierto enemistades, mucha gente me odia, mucha otra gente me odia menos, dudo que alguien me quiera más que mi perra (una labradora llamada Luana) y dudo que a alguien le simpatice. Al final de todo este tiempo y más de 3 años en Panagamers y casi 10 años apoyando al gaming panameño, me hice una pregunta: ¿Por qué sigo? ¿Qué gano de todo?

No gano nada de esto, más pierdo (dinero, tiempo, horas de sueño, me canso, etc). Al final la única respuesta es que recuerdo mi primer World Cyber Games, hace 10 años, tenía 14 y jugaba Age of Empires. Miraba embobado como me destrozaban en octavos de final, luego de haber hecho una estrategia errada, en un tiempo errado. Si perdía un juego me iba a casa, eso era todo (nada de loser bracket, nada de best of three, nada de eso). Lo disfrutaba mucho y no es que me guste perder, soy muy competitivo, pero amo participar de estos eventos. El problema es que en Panamá sólo hay un evento grande en todo el año, el resto del año las compañías se olvidan de nosotros.

Quería jugar más, quería participar más, pero nadie hacía eventos, nadie tenía noticias, nadie tenía un lugar en común para compartir con personas iguales a mi, nadie sabía como comunicarse con otras personas que tenían esas ganas de jugar. Simplemente no existía.

Si no lo hacía alguien que se sacrificara, nunca pasaría. Así nació la idea de Panagamers: sacrificarnos porque otras personas puedan tener lo que ninguno de nosotros en Panagamers tuvo: una comunidad, eventos concurrentes, un lugar en común.

Durante los últimos años no ha habido sólo un torneo de gaming en Panamá y les apuesto que el 95% de los eventos de videojuegos en Panamá se organizan en Panagamers, ya sea por la comunidad o por nosotros mismos. Tenemos servidores de todos los juegos, gracias a acuerdos con Cable & Wireless. Al final de cada torneo sólo queremos dormir, pero siempre al final de todos los eventos en que somos parte hay alguien contento, que se te acerca a ti, te mira a los ojos con una sonrisa y te dice “gracias, fue un buen evento, ¿cuándo hay otro?”.

Al final, la satisfacción es verme en los ojos de cada uno de estos jóvenes que quieren un método de diversión sano y diferente, algo diferente. Me veo en ellos y quisiera jugar, pero si lo hago seguramente no concentraría en mis esfuerzos para que ellos puedan jugar.

Muero por jugar, muero por verme jugar con ellos y contra ellos. Mi último torneo fue hace años y la pasé muy bien. Sin embargo con el poco tiempo libre puedo escoger sólo una de dos: jugar o hacer que otros jueguen. Prefiero la segunda, hay más sonrisas de por medio.

Son las 11:09 p.m., voy a ducharme y luego dormir, mañana trabajo. Sólo me voy a la cama con la satisfacción que hoy jugaron personas que no lo hubiesen hecho, si estos 10 años los hubiese usado para jugar y no apoyar.

Flourish: librería en PHP completamente OOP

Tue, 09 Aug 2011 08:43:35 -0500

A mi me parece que PHP cumple su propósito real: crear aplicaciones y sitios completos utilizando un lenguaje que desde el principio se diseño para este fin.

Los frameworks (como CodeIgniter y Kohana) y los CMS (como ExpressionEngine o FuelCMS) han llegado para quedarse y nos facilitan completamente la creación de aplicaciones grandes en poco tiempo.

El problema viene cuando nos acostumbramos o nos hacemos dependientes a ellos y tenemos este pequeño proyecto que necesitamos desarrollar, pero no es lo suficientemente grande como para hacerlo en un framework (aún cuando se pueda) o utilizar un CMS (o Wordpress) como base para el proyecto.

Recuerdo antes, lo que teníamos era una serie de librerías desorganizadas y lo único que hacíamos era darle include_once cuando necesitábamos de ellas. Con el paso de los años he perdido la mayoría de mis librerías y tratando de buscar librerías para sacarme de apuro (y gracias a atourino) pude jugar con Flourish, una librería completa en PHP y totalmente orientada a objetos.

Lo que más me gusto de Flourish es que todo es consistente y su documentación es muy buena y completa. Tiene librerías completas orientadas a crear soluciones en:

Manejo de bases de datos (ORM).
Manejo de consultas (Requests).
Manejos de sesiones y cookies.
Seguridad (CSRF, XSS, etc).
Validación de formularios.
CRUD completo.
Formatters.
Otros

Forzar SSL para ciertas vistas en CodeIgniter

Mon, 08 Aug 2011 23:49:53 -0500

El rollo es así: tenemos que forzar https para ciertas vistas de nuestra aplicación. Para ello, como siempre, busqué a ver si alguien ya se le había ocurrido hacer esto. Tenía una idea de modificar el base_url en plena marcha de la aplicación, pero leyendo una solución se me ocurrieron varias otras soluciones en conjunto:

Tener un controller llamado MY_Controller que extienda de CI_Controller.
Tener un helper donde tendríamos dos funciones que estaban en el post anterior, donde se forzaría el comienzo de https y quitar el https para otras vistas.
Tener una variable de configuración donde tendríamos el primer URI string para las secciones que quisiéramos que fueran seguras.

Así, nos quedaron los siguientes retazos de código:

Con estas tres partes de código, y asegurándonos que ya estamos cargando nuestro ssl_helper y nuestro ssl_routes (config) nos aseguramos que cada vez cargue una página que esté en /profile/* /tienda/* o /pedidos/* se redireccione a la misma dirección, sólo que usando https por delante.

(Taken with picplz.)

Sun, 07 Aug 2011 17:42:40 -0500

(Taken with picplz.)

Control de una galería de SlideShowPro desde JavaScript y jQuery

Mon, 11 Jul 2011 19:56:00 -0500

Ya tenía un par de semanas pendiente para escribir este artículo y fue algo que surgió mientras trabajaba en un proyecto de consultoría, en donde teníamos que tener modificar la paginación que crea por defecto el SlideShowPro y utilizar una que nosotros mismos pudiéramos modificar a disposición.

La paginación que tiene SSP por defecto es genial, muy intuitiva, linda, con una imagen de preview fácil de navegar y demás, el hecho es que no tenemos una opción sencilla de poder tener botones diferentes o nuevos con los números de las fotos para poder navegar entre ellas, por lo que revisando el API de SSP descubrimos que teníamos la facilidad de poder manejar y utilizar los datos provenientes de la galería a nuestro antojo. Uno de estos datos son la cantidad de fotos. Además, existe otro método dentro del API de SSP que permite poder cargar una foto específica (especificando el número de foto que queremos cargar), por lo que ya teníamos todo a nuestra mano para poder hacer el trabajo: el número de fotos y como cambiar de una a otra.

Pero yo no se Flash

Y bueno, aquí es donde venía el asunto. Yo hace más de 5 años no hago nada en Flash (gracias a Dios). Realmente Flash no me gusta, no me gusta trabajar con él y no divierto siquiera abriendo el Adobe Flash. El ActionScript, realmente no me molesta tanto y luego de varios meses trabajando con Flex me he acostumbrado bastante a él, ya casi me es más indiferente que fastidioso.

En Flex los componentes visuales (llámese los botones) los podríamos crear muy fácil, pero estábamos en Flash, además necesitábamos que los botones se pudieran estilar fácilmente sin la necesidad de abrir el .fla en un futuro e importar nuevos botoncitos hechos en imágenes.

Lo que me recordó que Flash tiene a su disposición las External Interface que permiten que nuestros componentes de Flash puedan ser manejados de forma externa por por medio de JavaScript y ejecutar a funciones de JavaScript desde el mismo ActionScript.

Todo dicho, quedamos con una conclusión: podríamos hacer los botones en HTML, estilizarlos con CSS común y manejar la funcionalidad (cambiar las imágenes) desde JavaScript, que a su vez llamaría a una función o método en ActionScript.

Trabajando con el ExternalInterface

La idea era la siguiente: cuando los datos del álbum de SSP se cargaban se obtuviera la cantidad de imágenes disponibles, lo que ejecutaría una función de JavaScript que dibujara los botones en donde se lo señaláramos.

Esto es muy simple, agregando en nuestro .fla (en Actions) el siguiente código:

Luego, teníamos que hacer otro método que escuchara cada vez que una función de JavaScript se ejecutara, para eso tuvimos que escuchar la función de JavaScript (dentro del ActionScript) y que cada vez que se ejecutara, enviara un evento en el ActionScript, que ejerce un cambio de imagen.

Así, nuestro código de ActionScript en el Flash queda de la siguiente manera:

Bienvenido jQuery y trabajando con el JavaScript.

Amo jQuery, ¿sabían?. jQuery es una gran librería de JavaScript que permite el manejo del DOM de manera sencilla, nada de Rocket Science, es simple y cumple su cometido de la forma que debería. Aún cuando tenemos la opción de hacer que los botones ejecuten un método en JavaScript (con el onclick) hace años he sentido que no debemos escribir esto de manera obstrusiva.

Lo que hicimos fue crear un pequeño plugin en jQuery que pudiera recibir como parámetro la cantidad de fotografías y él solo creara los botones, con su funcionalidad de click, que a su vez ejecutara una función que escucha que botón (o número de foto) estamos tratando de visualizar, lo que a su vez cambia la foto en el SSP directamente (desde JavaScript hasta el ActionScript/Flash).

El plugin de jQuery sólo hace esto: obtiene la cantidad de fotos e itera entre esta cantidad para crear un botón por cada foto. Pueden obtener el pequeño plugin por acá.

Sin embargo, también necesitamos una función que será nuestro punto de salida, una vez se obtienen la cantidad de fotos o imágenes en la galería. Esta función tiene como función iniciar nuestro plugin que a su vez creará los botones y la funcionalidad relacionada a cada uno de ellos.

Esta función debe tener el siguiente código:

Y ya estamos listos, deberíamos poder controlar toda la funcionalidad de SSP desde el JavaScript y estilizar nuestros botones sin la necesidad de tocar nunca más el Flash, todo desde HTML, CSS y JavaScript.

Puedes ver un DEMO de la aplicación.

Ya llego esta vaina! (Taken with picplz.)

Tue, 05 Jul 2011 15:26:50 -0500

Ya llego esta vaina! (Taken with picplz.)

Adapt.js ~ Responsive web design con ayuda de JavaScript

Wed, 08 Jun 2011 12:23:00 -0500

Imagínense tener que crear varios diseños de una aplicación web totalmente diferentes, dependiendo de la cantidad de dispositivos que visitan el sitio (y por ende sus distintas resoluciones). Hoy en día tenemos iPad (y otros tablets), iPhone (y otros móviles), monitores pequeños y hasta súper monitores con resoluciones arriba de los 1920 pixeles.

Esto nos deja con quizás 5 ó 6 distintos diseños completos de nuestro sitio, lo que se resume en mucho trabajo necesario para poder hacer que todos sean incluidos cuando nos visitan desde su dispositivo favorito.

Uno de los elementos que más ha captado mi atención en CSS3 es la aparición real de los media queries, trayendo consigo lo que conocemos como “Responsive Web Design”, basado en “responsive architecture” que no es más que como se amolda un espacio físico (en nuestro caso nuestro sitio) a la presencia de distintas cantidades de personas (que en nuestro caso sería la resolución del dispositivo).

Los media queries, que vienen de manera intrínseca en la especificación oficial del CSS3, traen consigo mejoras claves para los distintos medios que acceden a nuestro sitio. Esto hace que nuestro CSS se adapte a la resolución del dispositivo (o del medio) que lo accede, por lo que en una misma hoja de estilo, tenemos distintos comportamientos dependiendo de las característica del dispositivo que nos visita. Por ejemplo: si tenemos antes un diseño de dos columnas, podemos decir que para resoluciones menor o igual a 320px (iPhone) sea un diseño de una columna (osea, ponemos todos los div sin que floten, por decir algo).

Implementando en un sitio con 960.gs

Todo bien hasta aquí, ¿verdad?. Sí, el CSS3 trae consigo la capacidad de hacer esto de una manera muy simple. Al tener que implementar un diseño que ya estaba maquetado con 960.gs me topé con dos problemas reales:

En exploradores que no soportaban CSS3 no tenía el efecto “cool” de que dependiendo de la resolución cambiase la estructura o el diseño.
Se me hacía muy incómodo tener que implementar los media queries a un CSS implementado con 960.gs

Y aparece Adapt.js

Descubrí por mera casualidad Adapt.js, hecho por el mismo creador de 960.gs - Nathan Smith - haciendo una búsqueda para encontrar si ya alguien había hecho algún “hack” de poner el 960.css amigable para móviles y tablets, que al final suponía que debía ser cambiar el min-width del body y el max-width del container_12.

Adapt.js se describe como una librería de JavaScript pequeña que determina que archivo de CSS deberá cargar cada vez que el browser carga el sitio. Lo mejor: es amigable con 960.gs, por lo que hacerlo funcionar era genial. Simplemente tenemos una lista de rangos de pixeles y a cada una de ellas le asignamos que CSS base queremos que se cargue, de esta manera:

Gracias a este código (que usa jQuery) agregamos un id al body, dependiendo del tipo de dispositivo que nos esté visitando. Si es un móvil quedaría como <body id=”mobile”> y así sucesivamente.

Entonces, para el diseño podríamos utilizar un CSS que tome en consideración el ID del body, por ejemplo, si queremos que cuando es un móvil la letra sea 14px sólo haríamos: body#mobile{font-size:14px;} y este cambio, obviamente, no interferirá con las otras “versiones” de nuestro CSS.

Una ventaja de usar Adapt.js es que como es JavaScript funciona para cualquier browser con el mismo habilitado, sin importar si soporta CSS3 o no.

Para finalizar, una recomendación personal (gracias a atourino): si van a utilizar Adapt.JS deberían considerar utilizar Sass (preferiblemente) o LESS, realmente hace divertido nuevamente hacer CSS.