Aprendiendo JQuery

Por lo general, no soy dado a lanzarme al primer framework que consigo. De hecho, suelo ser un poco renuente a ello, por varias razones. La primera y principal es que me gusta aprender las cosas desde su base, y un framework, a fin de cuentas hace que te saltes ese paso (es por la misma razón por la que “aprendí” HTML, XHTML, CSS, XML con el siempre amado bloc de notas o en algún editor, como Dreamweaver, desde la vista de código). Ya lo he dicho antes, me gusta aprender, me gusta tener un reto que perseguir, y en ese sentido, no me llevo bien con la idea de recibir todo ya masticado (eso es lo que hace que cuando tienes un problema termines más perdido que Adán el día de las Madres ).
También es que, hasta ahora, no he tenido alguna necesidad que justifique cargar nosécuantos kb de líbrerías para poder hacer algo, y mis escasos conocimientos de js (para el caso) me han venido bastante bien y mucho más ligeros. Claro que muchos dirán que con las conexiones de hoy día, unos cuantos kb no serán una gran diferencia, pero, como decía aNieto

En definitiva, cargamos mucho el tiempo de carga de nuestra página. Es cierto que con las conexiones de hoy en día 100kb no son nada, pero imaginar una web como Microsiervos con una web de 100kb la cantidad de información que debe estar transmitiendo por minuto.Esto obliga a tener que buscar servicios con mayor ancho de banda, con su consecuente aumente de precio.

El asunto es que, para un proyecto que tuve que hacer, necesitaba crear una galería simple, y (que siempre pasa con las entregas), no tenía tiempo de crear una, así que decidí apelar al súper conocido y muy elegante Lightbox2, que me vino perfecto para lo que necesitaba, pero tiene (en mi humilde opinión), dos problemas:

1. Necesita 3 librerías diferentes para trabajar
2. La necesidad de colocar el atributo “rel” en cada link donde vas a trabajar. Si no lo necesitas puede valer ¿pero y si lo necesitas, o si la cantidad de imágenes convierte a ese simple paso en un fastidioso y largo dolor de cabeza?

Luego ocurrió que, debido a la distribución de los textos, pensé que le vendría bien usar un efecto acordeón, lo que implica, tomar las librerías (prototype, scriptacoulus, effects), aprenderlas y hacer las modificaciones necesarias para crear el dichoso efecto… mucho trabajo para poco tiempo.
Fue así que recordé que había visto en una de mis búsquedas por San Google, que había un plugin de jQuery, que imita el Ligthbox, así que me puse a buscar y me encontré el jQuery Lightbox Plugin, creado por Leandro Vieira. Aún no lo implemento, pero después de leer un poco sobre el tema, decidí usar jQuery para mi aplicación, hacer así ambos efectos que quería con la misma librería y ponerme a estudiar de una vez jQuery, que sé que me hará falta en algún momento.
Claro, hasta aquí puedes decir Bueno, ¿y a mí que me importa que quieras aprender jQuery? Yo también quiero y no lo ando publicando. Pues, que, como hago con las cosas que voy descubriendo, quería compartir con uds. este descubrimiento (nuevo para mí, que ya vendrá fael a darme un lindo faelazo) y que, además, iré escribiendo algunos tips en la medida que vaya aprendiendo y haciendo cosas con él (que no, no será un nuevo curso, que ya tengo bastante con el de POO ¬¬).
Así que, más material para uds. y más trabajo para mí. Ahí nos veremos.

Programación Orientada a Objetos – Eventos (I)

Este post es parte de una serie de artículos sobre POO y viene a continuación de Cómo Escribir Una Clase

Nota: Este post está dedicado al autor de cierto curso fracasado de Ruby on Rails, nuestro estimado Auyama, el Hideki pervertido U_U

Bien, en el post anterior habíamos visto como se estructura una clase, dejando el tema de los eventos para un post aparte. La razón de esto es que el asunto de los eventos requiere una atención especial.

Los eventos son el medio como interactúa una clase con otras o con el propio usuario, se encargan de avisar que algo ha ocurrido y de manejarlo de una forma o de otra. Cada vez que escribimos con nuestro teclado, que hacemos click en un botón o un link, que cambiamos el tamaño de un objeto, estamos generando eventos. Es por ello que, cuando programamos, debemos tener en cuenta la posibilidad (no siempre necesaria, pero lo será a medida que generemos clases cada vez más complejas), tanto de manejar eventos que sólo implican a nuestra clase como de generar nuestros propios eventos, de modo que los usuarios de nuestras clases (en principio nosotros mismos) puedan decidir cómo reaccionará su código ante ellos.
El modo de manejar los eventos en P.O.O. se conoce como emisor/receptor, también llamado despachador/escuchador o simplemente dispatcher/listener.
En esta dupla, la primera parte (el emisor) se encargará de lanzar el evento, mientras la segunda se encargará de recibirlo y gestionarlo como sea necesario. La primera parte será responsabilidad nuestra (los programadores de la clase) y la segunda es responsabilidad de quien utiliza la clase (en principio, también nosotros).
Cada lenguaje tiene su propio manejador de eventos, que es el que nos permite, tanto lanzar los eventos como crear los receptores (escuchadores/listeners) que nos permitirán manejarlos. Realmente es una aplicación del patrón Observer, del que hablaremos más adelante, cuando hablemos de patrones, pero que necesariamente tocaremos en este post.

¿En qué consiste la emisión/recepción de eventos?

Básicamente, de lo que se trata es de avisar (en principio sin importar si alguien escucha o no) de algún cambio en el estado de la instancia, que puede ser un click en el objeto, el final de un proceso de carga o la terminación de algún complejo proceso. Cada vez que el evento en cuestión ocurre, la instancia dirá “¡¡Hey, me ocurrió este evento!!”. Esto es lo que conocemos como broadcasting.
Aquí es donde entra en juego el (los) receptor(es). Éste se encargará de estar atento, de escuchar (de ahí que se les llame listeners) el(los) evento(s) que ocurra en el emisor, y responderá adecuadamente.

Para ejecutar esto correctamente, es necesario disponer de una clase que se encargue del manejo de los eventos, tanto de la emisión como de la recepción de los mismos, un eventHandler; ésta puede ser dada por el mismo lenguaje (por ejemplo, el eventDispatcher en AS) o creada por el propio programador. Veamos un ejemplo de uso en AS2:

Technorati Tags: Programación Orientada a Objetos, Clases, Action Script

Programación Orientada a Objetos – Eventos (II)

Este post es parte de una serie de artículos sobre POO y viene a continuación de Eventos (I)

Despacho (emisión) de Eventos

En este caso, haremos una pequeña adaptación de la clase que habíamos creado al principio, para lanzar un evento cada vez que la persona cumple años.

Bien, lo que hemos hecho es agregar, a nuestra clase Persona, un Despachador de Eventos, también le pedimos que , cada vez que se ejecute el método cumpleanhos, lance un evento, que hemos llamado onBirthday.
Para ello, hemos hecho lo siguiente:

1. Importamos la clase EventDispatcher, que es una clase estática, por lo que no hace falta instanciarla (más adelante hablaremos de las clases estáticas).
2. La clase EventDispatcher requiere que declaremos tres funciones: addEventListener, removeEventListener y dispatchEvent. Luego veremos para qué se utilizan.
3. En el constructor de la clase, inicializamos el Despachador (EventDispatcher.initialize(this)).
4. Para lanzar un evento, utilizamos en médoto dispatchEvent, que requiere un objeto con dos propiedades: target, que será el objeto que lanzó el evento, y type, que será el nombre del evento en sí.

Recepción (escucha) de Eventos

Bien, ya sabemos cómo despachar un evento (broadcasting). Ahora veamos cómo podemos capturar ese evento y manejarlo, ya sea en otra clase o en otra parte de nuestro código:

1. En nuestro ejemplo, hemos creado dos nuevas personas: auyamaApesta (hola Aoyama ) y theParrot (no sé cuál de los dos es más persona, pero igual servirán). Por supuesto, como ambas son instancias de la clase Persona, ambas pueden lanzar el evento onBirthday que creamos anteriormente.
2. Además, hemos creado también un nuevo objeto, myListener, que será el encargado de recibir y manejar el evento.
3. A través del método addEventListener, asociamos el objeto myListener a las instancias que hemos creado. Para ello le decimos: a.- El Evento que queremos recibir (en nuestro ejemplo, onBirthday) y; b.- El objeto que lo manejará (myListener)
4. Programamos, en el receptor (myListener) la función que deseamos manejar (onBirthday).

Este último punto requiere especial atención. Si nos fijamos, veremos que la función onBirthday recibe como parámetro un objeto (evt), que es el que enviamos en el EventDispatcher. Este objeto contiene dos propiedades: la primera es la propiedad target, que se refiere al elemento que envía el evento (en este caso, la instancia) y type, que nos dice el nombre del evento. Es por ello que al colocar evt.target.edad, nos estaremos refiriendo a la propiedad edad de la instancia en cuestión, igualmente con el nombre.
Otra cosa a tener en cuenta es que hemos creado un sólo listener que escuchará a las dos instancias, de modo que, en cada caso, responderá a cualquiera de las dos que lance el evento. Igualmente, es posible asociar varios objetos como listeners de un mismo evento, lo que nos permite hacer que un evento genere una serie de acciones diferentes al mismo tiempo.

Bueno, sabía que esto iba a ser largo. Creo que con esto tienen para entrenerse un rato. En nuestro próximo post hablaremos acerca de las Clases Estáticas.

Technorati Tags: Programación Orientada a Objetos, Clases, Action Script

De Vuelta al Blog

---

Sí, sé que muchos pensarán que he tenido el blog olvidado, que parece que ya se murió y tal. No es así.
Me gustaría decir que me fui de vacaciones a Fiji o algo así y que estoy pasándola muy bien como para ponerme a escribir sobre programación o sobre diseño y esas cosas que la gente cree que yo sé; pero lamentablemente no es así.
Lo que me ha tenido tan alejado ha sido un proyecto relativamente fácil de hacer, pero muy mal manejado, y como no es propiamente mío me ha tocado bailar con la más fea, haciendo cambios cada dos por tres, cada vez que al cliente se le ocurría alguna brillante idea. Hasta que, por fin, hoy mismo, ha sido publicado y he tenido que llamar a mi amigo -el que consiguió al cliente- para decirle que ya estaba bien de hacer cambios por nada. Para bien o para mal, esto para mí no es sólo una pasión, también es un negocio y de él vivo. Yo puedo regalar mi dinero, pero no el de mi familia, así que ya está.
Bueno, aún hay un par cosas que tengo que hacer para dar el proyecto por terminado completamente, pero ya lo puedo dar por listo y a cobrar.
Hay otras cosas que tengo pendientes, debo reunirme con un posible asociado, que significará más clientes, reponer el tiempo perdido en el blog, leer un par de libros que aún no he podido, estudiar Flex y, sobre todo, algo que me tiene emocionado y al tiempo con un dolor de cabeza permanente: Convertir los tips de POO en un curso (en principio básico) sobre el tema.
Esto último implica hacer un pensum más amplio de lo que tenía proyectado en un principio (igual cuando comencé creí que serían tres o cuatro y ya), hacer un poco más de investigación, desempolvar un par de libros (porque con los precios actuales, comprar libros es casi prohibitivo en Venezuela) y repasar algunas cosas que, aunque uses día a día, no siempre es fácil de traducir a un idioma menos técnico, que es -al final- el objetivo del curso.
Claro que tampoco es de lo único que voy a hablar, tengo cierto material recogido de mis feeds y en mis marcadores al que quiero dedicarle algunos posts y hay algunos tips que quiero revisar a ver si merece la pena que los publique, así que por escribir no faltará.
De momento este post para que sepan que ya estoy de vuelta (otra vez) y que, a pesar de las predicciones de Auyama, basadas en su fracaso con cierto curso de Ruby on Rails U_U, I Will Be a Hero!!!!

Si un lenguaje de programación fuese un bote…

Uno de los artículos más c00l e hilarantes que he visto en años (no-geeks, favor abstenerse; probablemente no entederán nada)
If a programming language was a boat…

Fuente: El blog del CompSci