NodeJS

HTTP Collect – Ejercicio 8 NodeSchool LearnYouNode

Para quien está iniciando con los ejercicios del Worshopper “LearnYouNode” del NodeSchool, en el ejercicio 8 se plantea lo siguiente:

Featured image

Para resolver este problema, se da un tip de utilizar alguno de los dos paquetes como b1 o concat-stream.

Aquí muestro un fragmento de código de como resolver el problema sin usar ningún paquete de terceros,

Featured image

Y al ejecutar el código, obtenemos prueba exitosa.

Featured image

Saludos!!

General

MacPorts: Gestión de Software en Mac Os

MacPorts es un proyecto open source que facilita la instalación en Mac OS de software que se instala mediante la línea de comandos. Esto es muy útil para evitar lidiar con el compilado, instalación y configuración de variables de entorno.

Desde su página oficial, podremos descargar el paquete de instalación que con un sencillo asistente realizará la instalación de MacPorts. http://www.macports.org/install.php

Ahora solo para comprobar su correcta instalación, basta abrir una consola y teclear “port version” lo cual no arrojará la versión.

Finalmente, probemos instalando Maven 3. En mi caso, tengo la versión Mac OS Mavericks en la cuál sin saber por qué quitaron Maven, su antecesor Mac OS Lion lo traía instalado por defecto.

Solo basta teclear

sudo port install maven3

Finalmente después de bajar Maven 3 nos pedirá activar maven para lo cual teclearemos el comando que se visualiza en la imagen y listo!!

Imagen

Java

Entendiendo definitivamente el uso de Interfaces

Mucha información podemos encontrar en internet sobre el concepto y ejemplos de uso de una Interfaz en Java. Se nos dice que las interfaces simulan la herencia múltiple, que son buena técnica para desacoplar el código, etc., sin embargo la gran mayoría de esos ejemplos se limitan a algo como esto y terminamos por no entender realmente el uso real y el poder de las interfaces.

Es claro que el ejemplo anterior es muy sencillo y se puede entender fácilmente, pero aun así seguimos sin entender ¿Por qué usar interfaces? En el ejemplo anterior, ¿Cuál es la diferencia entre usar interfaces y no haberlas usado? Bueno, en este artículo trataré de dar respuesta a ello.

 

Ordenar un arreglo de objetos…

Resulta que en nuestra empresa existen muchísimos flujos por donde viaja la información. El departamento “X” nos deposita en una interfaz que es un archivo de texto, una lista de proveedores externos, en otro archivo nos deposita una lista de productos, etc., información que nosotros debemos mostrar de forma ordenada en un reporte a nuestros usuarios. Así que comenzamos por escribir nuestra primera clase llamada “Despacho”

 

 

Adicional a lo anterior, le creamos setters y getters a cada uno de los atributos de la clase (razonSocial, RFC, etc.) y sobrescribimos el método toString.

 

Esta clase Despacho representa a un proveedor de nuestra empresa. Así que ahora debemos pensar en cómo vamos a ordenar objetos de este tipo. Se me ocurre que vamos a crearle a la clase Despacho el siguiente método.

 

 

¿¿¿Y lo anterior que es???… Bueno, sencillamente es un método que me compara en base al id Despacho el despacho actual contra otro despacho que recibe como parámetro y si el despacho actual tiene un ID mayor al del despacho comparado entonces me retornara un 1, en caso de que el ID del despacho actual sea menor que el del ID del despacho comparado me retorna -1 y en caso de ser iguales me retorna cero. Por el momento no pregunten el por qué de este método.

Posteriormente debemos crear alguna clase que me implemente la funcionalidad de ordenar, así que vamos a crear una clase llamada “Ordenador” y ya que el fin de este tutorial no es explicar algoritmos de ordenamiento, nos vamos a fusilar el código de esta página http://codigomaldito.blogspot.mx/2007/11/ordena-burbuja-en-java.html y lo vamos a implementar en nuestra clase ordenador con algunas ligeras modificaciones, de tal forma que tengamos algo como esto:

 

 

Como podemos observar, el método estático “ordenar” recibe un arreglo de objetos Despacho y en la línea 25 vemos como manda a llamar al método “comparar” que definimos antes.

Ahora ya solo nos resta crear una clase para probar lo anterior y ahí mismo definir objetos despacho simulando que en realidad los estamos leyendo de un archivo de texto.

 

Al correr el ejemplo anterior vemos que nos imprime los objetos desordenados ya que aun no mandamos a llamar al método “ordenar” de la clase Ordenador.

 

Ahora vamos a mandar a llamar al método ordenar, ya que se trata de un método estático, no será necesario crear una instancia de la clase Ordenador.

 

Al correr nuevamente el ejemplo y verificar la salida veremos que ya tenemos los elementos ordenados…

 

Hasta aquí todo va muy bien… ya podemos presentar un reporte al usuario con la información ordenada…. Pero ahora necesitamos ordenar otras clases llamadas Productos, Gestores, etc…. Dedique un momento antes de seguir leyendo como podría implementar esta funcionalidad…

Una de las probables cosas que se nos ocurren es crear un método de ordenamiento para cada objeto que necesitemos, pero obviamente esto es una pésima idea!! ¿¿Se imagina cuanto código duplicado tendríamos??

 

Aquí es donde las interfaces llegaran a nuestro rescate. Vamos a crear una interfaz genérica llamada “Comparable”.

 

Ahora, nuestra clase Despacho que hemos definido anteriormente, deberá implementar esta interfaz.

La clase despacho ya tenía un método llamado “compare”, así que ahora al implementar Comparable ese método pasara a ser la implementación.

Finalmente, vamos a modificar la clase Ordenador para que en lugar de recibir objetos Despacho, reciba un arreglo de objetos Comparable.

 

Con esto ahora ya podemos ordenar cualquier objeto que implemente nuestra interfaz Comparable. Así que no importa si ya tenemos 10 clases que necesitamos ordenar, lo único que tendremos que hacer es implementar Comparable en cada una de ellas y definir el criterio de ordenamiento. Creamos una clase llamada Gestor como a continuación se muestra.

 

Note que tenemos nuevamente el método “compare” pero ahora hemos invertido las condiciones. Con esto ahora conseguiremos tener un ordenamiento descendente.

 

Y la salida al ejecutarlo es:

 

Y ahora necesitamos ordenar productos pero ya no por ID sino por nombre… No importa, a nuestra clase Producto le implementamos Comparable y definimos en el método “compare” el criterio de ordenamiento que sería por nombre.

Todo el ejercicio anterior ha sido un ejemplo muy claro del poder de las interfaces y lo que realmente pueden hacer por nosotros… Aunque bueno, he hecho un poco de trampa puesto que el mismo API de java ya define básicamente clases que hacen lo anterior… Veamos.

En Java ya existe una interfaz Comparable dentro del paquete java.lang que define un método llamado “compareTo”. Vamos a ir a la clase Despacho y a quitar nuestra propia interfaz Comparable y sustituirla por la del paquete java.lang.

Y definimos el método “compareTo” (Ojo, no se confunda!!! Nuestro método se llamaba solo “compare” y que nombre así muy a propósito. El método compareTo es de la interfaz Comparable del paquete java.lang.)

 

 

Finalmente les presento a la clase Collections del API de java. Esta clase tiene un método llamado “sort” que recibe una lista de objetos que queremos ordenar, pero para que este ordenamiento funcione, estos objetos deben implementar a la interfaz Comparable del API de java.

 

 

Uffff… pues vaya que trabajamos arduamente! Ya existiendo una clase Collections, nosotros creamos nuestra propia versión de dicha clase y la nombramos Ordenador. Pero a final de cuentas esto nos sirvió para entender más a las interfaces en Java.

 

General

Modificadores de acceso

Existen 4 modificadores de acceso:

  1. public
  2. private
  3. protected
  4. default

    

En una relación de herencia es importante diferenciar dos cosas:

    1. Una subclase puede invocar a un método de la clase padre

    2. Una subclase puede heredar a un método de su clase padre.

 

Para ver la diferencia anterior y conocer de mejor manera los modificadores de acceso, hagamos el siguiente ejercicio.    

Creamos una clase llamada Padre con el método público presentarse.

 

Creamos una subclase de Padre.

    

Ejecutamos nuestro ejemplo y observamos los resultados que no tienen nada de anormal.

Ahora vamos a crear otro paquete llamado “otropaquete” y a copiar la clase Hijo en ese nuevo paquete. Ambas clases Hijo correrán sin problema y darán el mismo resultado.

 

Posteriormente vamos a quitar el modificador de acceso “public” que tiene el método presentarse() de la clase Padre. Cuando un método no tiene modificador de acceso, toma el modificador “default”.

 

Con esto ahora tendremos un error en una de las clases y es sencillamente por qué el modificador “default” solo tiene un alcance dentro del mismo paquete.

 

Finalmente cambiemos el modificador de acceso “default” y pongámosle “protected”

 

Anteriormente teníamos 2 errores, uno en la línea 20 y otro en la línea 24, pero al cambiar a protected ahora observamos que solo existe un error en la línea 24! El de la línea 20 desapareció!! ¿Por qué?

La explicación es sencilla. El modificador protected tiene alcance a nivel de “paquete” y para aquellas clases fuera del paquete pero solo por Herencia. Cuando hay herencia los métodos de la clase padre se hacen propios de la clase hija, es decir, aunque no los vemos, esos métodos existen ahí en la clase hija. Por ello en la línea 20 ya no tenemos ningún error puesto que el modificador protected permite que el método sea heredado. Sin embargo, en la línea 24 continuamos teniendo un error ya que ahí no estamos llamando al método heredado, sino estamos invocando el método de la clase padre.

En conclusión:

  1. public.        Acceso desde cualquier clase de cualquier paquete
  2. protected.    Acceso desde cualquier clase solo del mismo paquete ó fuera del paquete pero por medio de Herencia.
  3. default.    Similar al protected pero no permite el acceso fuera del paquete ni siquiera por Herencia.
  4. private.    No hay que ser un experto ni adivino para deducir su efecto, pero esto que quede como tarea.

 

iOS Programming, Objective C

Tablas en iOS

Recién comienzo a introducirme en el desarrollo de aplicaciones en iOS y lo que vaya aprendiendo se los estaré compartiendo. Además de esto, es importante que para seguir este tutorial, ya tengas los conocimientos básicos de Objective-C, definir clases, métodos, enviar mensajes (llamar métodos pues!).

Así que una vez aclarado que no soy experto y que puede haber errores en este tutorial y definidos los requisitos previos, iniciemos pues!!

UIView, UIViewController… Controladores? Vistas?

Bien, primero que nada, hay que saber que UIView es algo así como la clase de la cual los elementos gráficos de la interfaz de usuario que vemos en el iOS derivan. En términos formales, la documentación de Apple, nos dice:

“La clase UIView define un área rectangular sobre la pantalla y las interfaces para manejar el contenido en esta área…..”

Existe una clase llamada UITableView que representa una tabla en iOS. Esta clase deriva de UIView. Debemos saber que al ser iOS un sistema operativo para dispositivos móviles iPhone/iPad, en el caso de iPhone, la pantalla es muy pequeña, por lo cual, un UITableView no tiene columnas, únicamente filas!!!!!!! y entonces?, tranquilo🙂, no las vamos a necesitar en este tipo de programación! Y en dado caso que lo hagamos, seguramente habrá una forma de simular columnas! :p

Bien, los elementos de la interfaz de usuario de iOS siguen el diseño MVC, así que el UITableView es la vista. ¿Y el controlador?, bueno, básicamente estos elementos de la interfaz de usuario, tienen sus correspondientes controladores, en el caso de UIViewTable tiene su correspondiente controlador llamado IUTableViewController que efectivamente, hereda de UIViewController.

Básicamente, un UITableView necesita de:

  1. Un controlador de vista. Este controlador será el que maneje su apariencia sobre la pantalla.
  2. Un “data source” ya que el UITableView le pregunta sobre el número de registros a mostrar. Sin un data source, el UITable simplemente será un contenedor vacío como lo veremos más adelante. Este data source puede ser cualquier objeto de Objective-C, pero siempre y cuando implemente al protocolo UITableViewDataSource.
  3. Un delegado. Este delegado se encargará de informar a otros objetos de aquellos eventos relacionados con el UITableView. Al igual que el data source, este delegado podrá ser cualquier objeto Objective-C que implemente al protocolo UITableViewDelegate.

Ok, pues esto es lo que se necesita para mostrar una tabla en iOS. Afortunadamente, un objeto de la clase UITableViewController cubre las 3 reglas anteriores.

Por decirlo de alguna forma, el UITableView es muy tonto, no sabe mucho, pero el UITableViewController vaya que es inteligente, y este es el encargado de saber cuál es su vista, que será un UITableView. En el fondo, un UITableViewController es una instancia de UITableView, entiendo que es algo así como un envoltorio que maneja su preparación y presentación del UITableView. Cuando un UITableViewController crea su vista, las variables de instancia “dataSource” y “delegate” del UITableView, apuntan automáticamente a el UITableViewController.

Manos a la obra!!

Requisitos.

  1. Mac OS X 10.7 Lion.
  2. XCode 4.2

Una vez que vimos algo de teoría aburrida, vayamos a la práctica! En Xcode vamos a crear un nuevo nuevo proyecto iOS tal y como se muestra en las siguientes imagenes.

Bien, una vez que creamos el proyecto, vamos a agregar una nueva clase Objective-C que herede de UITableViewController ya que como les decía arriba, esta clase ya tiene una vista UITableView y además ya proporciona un delegado y un datasource.

El asistente nos creara las clases y al indicarle que será una subclase de UITableViewController, pues implementará algunos métodos de esta clase, así que por el momentos, no se espanten de ver tanto código en nuestra nueva clase ListOfMonthsViewController. De igual forma, si reciben algunos warnings por parte del compilador, vamos a omitirlos en este ejercicio.

Hay que saber que un UITableView tiene dos tipos de estilos, la simple y la agrupada. La simple es solo eso, una lista de celdas de color blanco. La agrupada, es aquella cuya presentación se hace mediante secciones, por ejemplo en nuestra lista de contactos que tenemos en el iOS es un ejemplo de lista agrupada, ó por ejemplo lo que muestra la siguiente imagen es otra tabla con estilo de vista agrupado.

Xcode nos crea ya varios archivos. En el ListOfMonthsViewController.m localicemos el inicializador o como se le llama en casi la mayoría de los lenguajes, el constructor.

El código anterior, sencillamente llama al constructor de su clase padre, UIViewController. Aquí es donde se le indica que estilo de tabla deseamos, en este caso, será el valor que tenga “sytle”.

Bien, lo único que vamos a hacer es abrir la clase ByteAppDelegate.m (no te confundas, este es el delegado de la ventana y no del UITableView).

Localizamos el método que se ve en la imagen y agregamos el código marcado.

Cuando se lanza la aplicación, se envía el mensaje “application:didFinishLaunchingWithOptions” justo cuando el “lanzado” de la aplicación se completa. (Hay que recordar que en Objective-C se acostumbra más usar la terminología “envio de mensajes” que la “llamada a métodos”). Por lo que en el momento que la aplicación es lanzada, es cuando debemos crear el controlador de nuestra tabla. Una vez que el controlador de vista es creado, lo único que necesitamos hacer es establecerlo como raíz del UIWindow. UIWindow es la ventana básicamente y sobre esta ventana, es donde “insertamos” nuestra vista “principal” que será una tabla.

Ahora, si corremos la aplicación con el simulador del iPhone, veremos una pantalla en blanco con algunas filas vacías, esta es la tabla con estilo plano!

Cambiemos el estilo con el que iniciamos la tabla, en lugar de usar UITableViewStylePlain pongamos UITableViewStyleGrouped

Corramos la aplicación nuevamente y veremos que la pantalla ahora tiene un estilo gris. Hasta ahora, esta es nuestra tabla, quizá no lo parezca pues le faltan datos, pero ahí esta.

Vamos a mostrar algunos datos. Recordemos que nuestro UITableViewController funge también como delegado. Para mantener la sencillez del tutorial (que de por sí imagino ya compliqué), vamos a definir una variable de instancia NSMutableArray en el ListOfMonthsViewController.h

 

 

Y en el inicializador de ListOfMonthsViewController.m vamos a llenarlo con algunos datos fijos.

 

Vamos a recapitular un poco el flujo que nuestra mini aplicación sigue.

Al lanzar la aplicación, se envia el mensaje application:didFinishLaunchingWithOptions y aquí se crea una vista UIWindow. (ver el ByteAppDelegate). Inmediatamente, creamos nuestro controlador ListOfMonthsViewController, este controlador creara nuestra vista UITable con un estilo “plain”. En el momento que creamos el objeto ListOfMonthsViewController, vemos que en su inicializador (constructor) hemos inicializado nuestro array con los nombres de los meses.

Ya que se crearon los meses, el control vuelve nuevamente al método application:didFinishLaunchingWithOptions de ByteAppDelegate y se establece como “rootViewController” al recien creado ListOfMonthsViewController.

Una vez que esto pasa, la vista de tabla esta creada y entonces esta misma tabla envia varios mensajes a su delegado, entre los mensajes que envía son:

  • tableView:numberOfRowsInSection:
  • tableView:cellForRowAtIndexPath

¿Pero quien es el delegado de nuestra tabla?… Como lo mencione al inicio del artículo, el mismo UITableViewController funge como delegado y datasource, así que la clase ListOfMonthsViewController es el delegado y es quien recibe los mensajes anteriores.

¿Confundido?… tranquilo. Termina el ejercicio, y una vez que veas el resultado, vuelve a leer esta teoría y seguro le entenderas.

Lo que quise decir con lo anterior, es que debemos agregar los dos métodos anteriores a nuestro controlador, en este caso, como los creamos con Xcode, pues dichos métodos ya los tenemos, solo es cuestión de buscarlos.

Primero, que nada, debemos indicarle al controlador cuantas filas por sección será capaz de mostrar nuestra tabla! Recordemos que una tabla puede estar dividida en secciones y cada sección tiene un número determinado de filas. En nuestro caso, como vamos a utilizar el estilo plano, este estio tiene solamente 1 sección, y ¿cuantas filas tendrá?… pues tendrá X número de filas como nuestro arreglo de meses contenga!! en este caso, tendrá 12 filas que corresponde con los 12 meses del año….

ok, ¿y en donde le indicamos esto?

Cuando la vista de tabla es creada, envía varios mensajes al delegado, entre ellos envía el mensaje “tableView:numberOfRowsInSection:” y aquí es donde debemos indicarle el número de registros a mostrar en casa sección. Si hubieramos configurado nuestra tabla para tener 3 secciones, este método se invocaría 3 veces, si tuviera 5 secciones, se invocaría 5 veces… etc.

Bien, vamos a buscar dicho método y agregar lo siguiente:

 

 

Listo!!! Nuestra tabla tendrá 12 filas en su única sección.

Una vez que el controlador conoce el número de filas que tendrá la tabla, envía el mensaje “tableView:cellForRowAtIndexPath:” por cada fila que se tenga.

Aquí es donde entonces debemos escribir el contenido que tendrá cada celda (dado que el UITableView no tiene columnas, el usar filas o celdas, será casi lo mismo).

Localizamos dicho método, borramos por el momento el código que tiene ahí y escribimos lo siguiente.

 

Llegado a este punto, es necesario aclarar algo.

Las celdas del IUTableView son también objetos de una clase llamada UITableViewCell, es decir, las celdas también son vistas! Entonces, una celda es una sub-vista de nuestra tabla! Existen 4 estilos de celdas, por el momento, solo mencionaremos el estilo UITableViewCellStyleDefault.

El código anterior, parece ser claro y descriptivo por si mismo, así que no invertiré tiempo en explicarlo.

Ya pues! Vayamos a correr este sencillo ejemplo con el simulador del iPhone y veamos el resultado.

 

Bueno, ya me he alargado mucho en este tutorial, así que le vamos a dejar aquí por esta vez, pero escribiré una segunda parte donde continuaremos con este ejercicio y veremos algunas características más de un  UITableView.

Si te ha sido útil esta información, solo basta dejar un comentario! Saludos!!