Mostrando entradas con la etiqueta tecnicas. Mostrar todas las entradas
Mostrando entradas con la etiqueta tecnicas. Mostrar todas las entradas

martes, julio 20, 2010

Tildación y acentuación II

Como veíamos en el post anterior, Tildación y acentuación I, algunas palabras parece no apegarse mucho a las reglas general de la tildación según la clasificación de las palabras.

No obstante, no es porque exista un vacío o una falta de concordancia entre las reglas. Al contrario, esto demuestra que nuestra gramática posee riqueza y variedad. Una variedad que puede resultar frustrante si la explicación es complicada.


Es por eso que hoy desentrañaremos algunos de los ejemplos que necesitaban más explicación de una manera sencilla.

Además de las reglas de tildación según la clasificación de las palabras, existen otra serie de reglas que se aplican dentro de esas mismas palabras. Es decir, si bien existen palabras agudas, graves, esdrújulas y sobresdrújulas; éstas palabras están sujetas a otras reglas que no tienen que ver, precisamente, con sus terminaciones o con la fuerza de voz.

Este tipo de subreglas -como les llamaremos- son los diptongos y hiatos.



a) Diptongos. Es la unión de dos vocales en una misma sílaba, siendo al menos una de ellas débil. En este caso, no importa el orden de ellas. Puede ser fonético u ortográfico.

Para efectos de comprensión del concepto, cabe aclarar y distinguir cuáles son las vocales débiles y fuertes. Éstas también son conocidas como vocales cerradas y abiertas, respectivamente.

Las vocales débiles o cerradas son: "i", "u".

Las vocales fuertes o abiertas son: "a", "e", "o".



Visto esto, vamos a ver algunso ejemplos de diptongo:

hiato

virtual

afluente

sentimiento

biombo

impetuoso

b) Hiatos. Es la combinación de dos vocales que no forman diptongo. Es decir, son dos vocales que pertenecen a sílabas distintas, pero están juntas. Esto hace que el aparente diptongo que forman se rompa. Por eso suele llamársele adiptongo. Al igual que el diptongo, puede ser fonético u ortográfico.

Ejemplos de hiato:

caoba

real

mz

mareo

toalla

día

Cuando dentro de una palabra como maíz encontramos un diptongo conformado por una vocal fuerte y una débil acentuada, éste deja de ser un diptongo para ser un hiato.
Al ser un hiato, la "a" y la "í" pasan a ser parte de dos sílabas diferentes.

Cuando esto sucede, la palabra se convierte automáticamente en una palabra aguda, por lo que se aplica la regla de las palabras agudas. Pero si nos detenemos a ver, la última sílaba no coincide con la regla de acentuación para las palabras agudas. Es ahí dónde entra la subregla del hiato ortográfico: la vocal débil es la que lleva la tilde.


ma - íz
Nótese la destrucción del hiato al separar en sílabas y la aplicación de la subregla
En este caso, la palabra maíz se clasifica como aguda aún cuando termina en una letra que no se incluye en la regla (z). Pero al aplicar esa subregla nos damos cuenta el por qué se tilda.


Otro ejemplo es la palabra día. Gracias a sus características -un diptongo formado por una vocal débil y una fuerte, unado a la aplicación de la subregla de tildar la vocal débil- se convierte en palabra grave.

dí - a
Nótese la aplicación de la subregla y la separación en sílabas

Es importante resaltar que no todos los diptongos fonéticos son ortográficos, ni vicercersa. De igual manera, esta regla funciona para con los hiatos. Por lo que es necesario definir qué es un hiato y un diptongo ortográfico; y un hiato y diptongo fonético, respectivamente.
Pero sobre este tema ahondaremos en un nuevo post.

Tildación y acentuación II

Como veíamos en el post anterior, Tildación y acentuación I, algunas palabras parece no apegarse mucho a las reglas general de la tildación según la clasificación de las palabras.

No obstante, no es porque exista un vacío o una falta de concordancia entre las reglas. Al contrario, esto demuestra que nuestra gramática posee riqueza y variedad. Una variedad que puede resultar frustrante si la explicación es complicada.


Es por eso que hoy desentrañaremos algunos de los ejemplos que necesitaban más explicación de una manera sencilla.

Además de las reglas de tildación según la clasificación de las palabras, existen otra serie de reglas que se aplican dentro de esas mismas palabras. Es decir, si bien existen palabras agudas, graves, esdrújulas y sobresdrújulas; éstas palabras están sujetas a otras reglas que no tienen que ver, precisamente, con sus terminaciones o con la fuerza de voz.

Este tipo de subreglas -como les llamaremos- son los diptongos y hiatos.



a) Diptongos. Es la unión de dos vocales en una misma sílaba, siendo al menos una de ellas débil. En este caso, no importa el orden de ellas. Puede ser fonético u ortográfico.

Para efectos de comprensión del concepto, cabe aclarar y distinguir cuáles son las vocales débiles y fuertes. Éstas también son conocidas como vocales cerradas y abiertas, respectivamente.

Las vocales débiles o cerradas son: "i", "u".

Las vocales fuertes o abiertas son: "a", "e", "o".



Visto esto, vamos a ver algunso ejemplos de diptongo:

hiato

virtual

afluente

sentimiento

biombo

impetuoso

b) Hiatos. Es la combinación de dos vocales que no forman diptongo. Es decir, son dos vocales que pertenecen a sílabas distintas, pero están juntas. Esto hace que el aparente diptongo que forman se rompa. Por eso suele llamársele adiptongo. Al igual que el diptongo, puede ser fonético u ortográfico.

Ejemplos de hiato:

caoba

real

mz

mareo

toalla

día

Cuando dentro de una palabra como maíz encontramos un diptongo conformado por una vocal fuerte y una débil acentuada, éste deja de ser un diptongo para ser un hiato.
Al ser un hiato, la "a" y la "í" pasan a ser parte de dos sílabas diferentes.

Cuando esto sucede, la palabra se convierte automáticamente en una palabra aguda, por lo que se aplica la regla de las palabras agudas. Pero si nos detenemos a ver, la última sílaba no coincide con la regla de acentuación para las palabras agudas. Es ahí dónde entra la subregla del hiato ortográfico: la vocal débil es la que lleva la tilde.


ma - íz
Nótese la destrucción del hiato al separar en sílabas y la aplicación de la subregla
En este caso, la palabra maíz se clasifica como aguda aún cuando termina en una letra que no se incluye en la regla (z). Pero al aplicar esa subregla nos damos cuenta el por qué se tilda.


Otro ejemplo es la palabra día. Gracias a sus características -un diptongo formado por una vocal débil y una fuerte, unado a la aplicación de la subregla de tildar la vocal débil- se convierte en palabra grave.

dí - a
Nótese la aplicación de la subregla y la separación en sílabas

Es importante resaltar que no todos los diptongos fonéticos son ortográficos, ni vicercersa. De igual manera, esta regla funciona para con los hiatos. Por lo que es necesario definir qué es un hiato y un diptongo ortográfico; y un hiato y diptongo fonético, respectivamente.
Pero sobre este tema ahondaremos en un nuevo post.

lunes, febrero 09, 2009

Internet a traves del Mail: Es posible?

Existen empresas en el país que como bien lo dice Rodrigo en este post, no valoran lo suficiente a su equipo de IT por lo que no son tan flexibles a la hora de considerar las necesidades que este equipo tiene para lograr el éxito en el desarrollo de los proyectos de software.

Un claro ejemplo de esto es cuando te restringen el acceso a Internet con el supuesto de volverte más productivo evitando que pierdas el tiempo procrastinando en lugar de desarrollar, ya que los jefes no conocen el valor único que tiene el Internet y cuantos servicios online existen que te permiten ser más productivo especialmente si formas parte de un equipo de trabajo.


"Para algunos jefes, esto es el Internet"


Para lograr dicho cometido, he encontrado los siguientes sitios que te pueden ser de mucha utilidad:


Este es un sitio desde el cual puedes registrarte con tu usuario y clave de twitter y al momento te asignan una dirección de correo electrónico especial, a la cual puedes escribir y el título o el contenido de dicho correo (depende de como lo hayas configurado) saldrá publicado en tu cuenta de twitter. También puedes enviar comandos especiales en el título del correo, como por ejemplo friends con el cual, el robot te enviará un correo electrónico conteniendo los 20 últimos twitts escritos por tus amigos.

Dicha cuenta, además, te enviará a tu bandeja un mail con los repplies que recibas por parte de tus followers. Entre otras funciones esta la capacidad de publicar fotografías adjuntas en twitpic y programar twitts a futuro.

  • Postear en el Blog (blogger)
Las plataformas de blogging también te ofrecen la alternativa de escribir posts y enviarlos a una cuenta de correo especifica para que este sea publicado. Desde blogger puedes hacerlo en la siguiente pagina, en tus settings:

"Interfaz de los settings de tu cuenta de blogger, donde puedes configurar una cuenta de correo para publicar posts en tu blog (Clic para agrandar)"


Este servicio te permite enviar un correo electrónico a una cuenta de correo predeterminada, incluyendo en el título del mensaje la URL de la página que deseas visitar y ellos te envían un correo de respuesta mostrando dicha página web en el contenido del correo. Ejemplo:

"Ejemplo de mensaje de correo electrónico enviado a webinmail, pidiendo recibir la pagina del Sr Byte (Clic para ver en tamaño completo)

"Mensaje de correo recibido en respuesta por la consulta enviada anteriormente. (Clic para ver en tamaño completo)"

Quizá la forma de negación parezca un tanto arcaica y no te permita descargar archivos o recibir transmisiones de audio/vídeo vía streaming para ver vídeos de youtube o entrar a sitios que te piden tu usuario y clave pero por lo menos te puede sacar de apuros si no tienes nada mas que tu cuenta de correo electrónico y necesitas googlear o buscar ayuda en foros.


Internet a traves del Mail: Es posible?

Existen empresas en el país que como bien lo dice Rodrigo en este post, no valoran lo suficiente a su equipo de IT por lo que no son tan flexibles a la hora de considerar las necesidades que este equipo tiene para lograr el éxito en el desarrollo de los proyectos de software.

Un claro ejemplo de esto es cuando te restringen el acceso a Internet con el supuesto de volverte más productivo evitando que pierdas el tiempo procrastinando en lugar de desarrollar, ya que los jefes no conocen el valor único que tiene el Internet y cuantos servicios online existen que te permiten ser más productivo especialmente si formas parte de un equipo de trabajo.


"Para algunos jefes, esto es el Internet"


Para lograr dicho cometido, he encontrado los siguientes sitios que te pueden ser de mucha utilidad:


Este es un sitio desde el cual puedes registrarte con tu usuario y clave de twitter y al momento te asignan una dirección de correo electrónico especial, a la cual puedes escribir y el título o el contenido de dicho correo (depende de como lo hayas configurado) saldrá publicado en tu cuenta de twitter. También puedes enviar comandos especiales en el título del correo, como por ejemplo friends con el cual, el robot te enviará un correo electrónico conteniendo los 20 últimos twitts escritos por tus amigos.

Dicha cuenta, además, te enviará a tu bandeja un mail con los repplies que recibas por parte de tus followers. Entre otras funciones esta la capacidad de publicar fotografías adjuntas en twitpic y programar twitts a futuro.

  • Postear en el Blog (blogger)
Las plataformas de blogging también te ofrecen la alternativa de escribir posts y enviarlos a una cuenta de correo especifica para que este sea publicado. Desde blogger puedes hacerlo en la siguiente pagina, en tus settings:

"Interfaz de los settings de tu cuenta de blogger, donde puedes configurar una cuenta de correo para publicar posts en tu blog (Clic para agrandar)"


Este servicio te permite enviar un correo electrónico a una cuenta de correo predeterminada, incluyendo en el título del mensaje la URL de la página que deseas visitar y ellos te envían un correo de respuesta mostrando dicha página web en el contenido del correo. Ejemplo:

"Ejemplo de mensaje de correo electrónico enviado a webinmail, pidiendo recibir la pagina del Sr Byte (Clic para ver en tamaño completo)

"Mensaje de correo recibido en respuesta por la consulta enviada anteriormente. (Clic para ver en tamaño completo)"

Quizá la forma de negación parezca un tanto arcaica y no te permita descargar archivos o recibir transmisiones de audio/vídeo vía streaming para ver vídeos de youtube o entrar a sitios que te piden tu usuario y clave pero por lo menos te puede sacar de apuros si no tienes nada mas que tu cuenta de correo electrónico y necesitas googlear o buscar ayuda en foros.


lunes, enero 19, 2009

Mas Alla del Codigo

"Escribir el código es sólo una parte del proceso de desarrollo de software"

Últimamente en mi trabajo me he dado cuenta que en las grandes ligas, el código es nada mas una de todas las cosas por las que hay que preocuparse a la hora de desarrollar un sistema. No basta con ser un programador disciplinado, dejando comentarios en el código, haciendo pruebas de unidad, subversionando y diseñando una interfaz agradable al usuario para que nuestra aplicación sea usable, hay que pensar en otros factores que podrían afectar nuestra aplicación a la hora que esta sea usada en el mundo real.

Algunas de estas cosas no las descubres en la universidad, cuando ejecutas tus aplicaciones en un ambiente ideal, donde no introduces más de cien registros a tu base de datos y sólo tienes a 5 usuarios al mismo tiempo accediendo a tu aplicación y lo hacen desde una LAN.

Tampoco piensas en que tan fácil será extender tu aplicación cuando la empresa crezca y surjan nuevas necesidades de información o si tu aplicación puede migrarse a otras plataformas o comunicarse con otros sistemas.

Estos conceptos los descubres y aplicas una vez que ya estás involucrado en un proyecto que requiere aplicarlos por lo que dedicaré algunos posts para que tomemos en cuenta que otras fases se llevan a cabo una vez que has escrito el código o qué otras características debes tomar en cuenta mientras lo escribes.

Mas Alla del Codigo

"Escribir el código es sólo una parte del proceso de desarrollo de software"

Últimamente en mi trabajo me he dado cuenta que en las grandes ligas, el código es nada mas una de todas las cosas por las que hay que preocuparse a la hora de desarrollar un sistema. No basta con ser un programador disciplinado, dejando comentarios en el código, haciendo pruebas de unidad, subversionando y diseñando una interfaz agradable al usuario para que nuestra aplicación sea usable, hay que pensar en otros factores que podrían afectar nuestra aplicación a la hora que esta sea usada en el mundo real.

Algunas de estas cosas no las descubres en la universidad, cuando ejecutas tus aplicaciones en un ambiente ideal, donde no introduces más de cien registros a tu base de datos y sólo tienes a 5 usuarios al mismo tiempo accediendo a tu aplicación y lo hacen desde una LAN.

Tampoco piensas en que tan fácil será extender tu aplicación cuando la empresa crezca y surjan nuevas necesidades de información o si tu aplicación puede migrarse a otras plataformas o comunicarse con otros sistemas.

Estos conceptos los descubres y aplicas una vez que ya estás involucrado en un proyecto que requiere aplicarlos por lo que dedicaré algunos posts para que tomemos en cuenta que otras fases se llevan a cabo una vez que has escrito el código o qué otras características debes tomar en cuenta mientras lo escribes.

jueves, diciembre 11, 2008

Algunos consejos para el uso de Zoom

El manejar una cámara es relativamente algo sencillo. Muchas veces el pulso o los nervios pueden traicionarnos y hacer que la estabilidad de nuestras grabaciones se pierda. O también, al momento de tomar fotografías ya sean familiares o por hobby, éstas no salen como lo deseamos o esperamos.

La mayoría tenemos cámaras, ya sean fotográficas o de grabación, y no sabemos la infinidad de posibilidades que podemos hacer con ella. Esto nos lleva a quedarnos con los movimientos básicos de zoom in y zoom out. A pesar de que son muy sencillos, el zoom in y out pueden ser muy útiles si son bien empleados. He aquí algunas sugerencias de cómo utilizar el zoom in y zoom out en cualquier grabación.

  1. No es bueno abusar del zoom. Es recomendable utilizarlo sólo en los momentos que se consideren más importantes dentro de la grabación, evitando un uso contínuo. Esto puede variar según el criterio de quien graba y su intencionalidad comunicativa.
  2. Evitar el zoom escalonado. Al momento de hacer un zoom in, es preferible hacerlo de manera lenta pero segura. Es decir, no ir acercándose a la imagen poco a poco de manera que se pierda estabilidad y se genere una distorcion de lo que se desea enfocar.
  3. Establecer un punto fijo. Antes de hacer un zoom in o un zoom out se debe puntualizar el objeto o sujeto al cual se le aplicará. Esto ayuda a que la persona que opera la cámara tenga un punto fijo hacia el cual dirigirse y no perderse en el momento de realizar la acción.
  4. Evitar el uso contínuo del zoom. Esto provoca mareo en el espectador y dificulta la selección de imágenes al momento de la edición.
Estos son solo algunos consejos. Posteriormente, publicaré más.
Hasta pronto.

Algunos consejos para el uso de Zoom

El manejar una cámara es relativamente algo sencillo. Muchas veces el pulso o los nervios pueden traicionarnos y hacer que la estabilidad de nuestras grabaciones se pierda. O también, al momento de tomar fotografías ya sean familiares o por hobby, éstas no salen como lo deseamos o esperamos.

La mayoría tenemos cámaras, ya sean fotográficas o de grabación, y no sabemos la infinidad de posibilidades que podemos hacer con ella. Esto nos lleva a quedarnos con los movimientos básicos de zoom in y zoom out. A pesar de que son muy sencillos, el zoom in y out pueden ser muy útiles si son bien empleados. He aquí algunas sugerencias de cómo utilizar el zoom in y zoom out en cualquier grabación.

  1. No es bueno abusar del zoom. Es recomendable utilizarlo sólo en los momentos que se consideren más importantes dentro de la grabación, evitando un uso contínuo. Esto puede variar según el criterio de quien graba y su intencionalidad comunicativa.
  2. Evitar el zoom escalonado. Al momento de hacer un zoom in, es preferible hacerlo de manera lenta pero segura. Es decir, no ir acercándose a la imagen poco a poco de manera que se pierda estabilidad y se genere una distorcion de lo que se desea enfocar.
  3. Establecer un punto fijo. Antes de hacer un zoom in o un zoom out se debe puntualizar el objeto o sujeto al cual se le aplicará. Esto ayuda a que la persona que opera la cámara tenga un punto fijo hacia el cual dirigirse y no perderse en el momento de realizar la acción.
  4. Evitar el uso contínuo del zoom. Esto provoca mareo en el espectador y dificulta la selección de imágenes al momento de la edición.
Estos son solo algunos consejos. Posteriormente, publicaré más.
Hasta pronto.

Herramientas del Programador: Unit Testing

"Jajajaja Nunca te librarás de mi, programador"

Bugs. Todo programador los conoce. Desde el primer hola mundo que escribe en C y se da cuenta que no le compiló porque le hacía falta el punto y coma al final de la sentencia, el programador se da cuenta que los programas que escriba nunca serán perfectos y siempre habrá que arreglar los diferentes errores que comunmente se cometen cuando estamos desarrollando alguna aplicación.

Algunos consideran que el proceso de desarrollo de una aplicación se distribuye regularmente en un 20% de tiempo invertido en la codificación contra un 80% invertido en la depuración del código escrito. Esto nos lleva a pensar que corregimos mas de lo que producimos, lo cual no es muy efectivo que digamos a la hora del desarrollo. Para ello, existen técnicas que nos permiten prevenir la ocurrencia de Bugs o errores que comúnmente se cometen a la hora de la programación y entre estas, las más popular es el uso de Unit Testing.

Unit Testing. Es una de las etapas o técnicas que conforman el proceso de programación extrema, la cual consiste en llevar al extremo las habilidades de un programador y el tiempo invertido de manera que se involucre al cliente lo mas posible en el proceso de desarrollo y se entregue lo mas pronto posible. Unit tests son una serie de porciones de código que se escriben con la finalidad de probar y asegurar el correcto funcionamiento de los módulos y clases que conforman tu aplicación. Estas porciones de código, distribuidas en métodos dentro de clases, se ejecutan y devuelven un estado para saber si el test fue pasado con éxito o si este falló. Con los unit tests puedes probar que tu código funciona cuando debe funcionar y falla cuando debe fallar (aunque estas fallas, obviamente estarán controladas, quizá, mediante excepciones).

Por ejemplo, si tienes el siguiente método escrito en java:

public class Comparador {
public int getMayor(int[] lista){
int mayor = lista[0];
for(int i=1; imayor)
mayor = lista[i];
}
return mayor;
}
Podrias construir un Unit Test que se encargue de invocar a ese método pasándole parámetros de muestra y comparando (mediante un Assert) los resultados obtenidos con resultados esperados. Acá es donde el test te avisa si estos son idénticos (el Test pasa) o difieren (El test falla). Asi de simple es como funciona un Unit Test.

@Test
public void testGetMayor() {
Comparador t = new Comparador();
int esperado = 5;
int obtenido = t.getMayor(new int[]{1, 2, 3, 4, 2, 3, 5});
assertEquals(esperado, obtenido);
}

Si el valor esperado es diferente al valor obtenido, el método assertEquals nos avisará de ello mediante un mensaje.

Las ventajas de probar nuestros métodos con Unit Testing es que podemos saber justo después de codificarlos si ellos funcionan como es debido o no, además también podremos conservar los tests y pasarlos cada vez que modifiquemos el código para asegurarnos que los nuevos cambios realizados no afectaron el funcionamiento original de nuestro método y sigue devolviendo los valores esperados.


Con la experiencia, un programador aprende a conocer todas las posibles fallas que se podrían producir en una porción de código y prevenirlas antes que ocurran. Usando Unit Testing se puede comprobar que dichas fallas fueron mitigadas correctamente. Como recomendación, cada programador debe aprender a ser pesimista con su código, a pensar siempre lo peor de manera que su aplicación esté preparada para ello. Buscar todas las posibles fallas que pueda tener el código, sin importar qué tan ridículas, absurdas o imposibles estas sean. Sino, recuerden esa vez que estaban refinando su aplicación unas horas antes de su defensa final y por arte de magia, a última hora todo dejó de funcionar por culpa de un error que pasaron por alto y no creyeron que fuera a afectar tanto el proyecto.


"Como decía Murphy: Todo lo que puede salir mal, saldrá mal"

Para poder hacer uso de los Unit Tests, necesitas instalar el framework apropiado dependiendo del lenguaje de programación que estes utilizando para desarrollar y a veces este ya viene integrado en los IDEs o entornos de desarrollo. Por ejemplo, Java hace uso de la librería JUnit, la cual ya viene integrada en Netbeans, Python hace uso de PyUnit, Microsoft .Net utiliza NUnit, el cual se puede integrar con el IDE SharpDevelop, entre otros.

"Captura de pantalla del IDE Netbeans, mostrando los resultados de la ejecución de los Unit Tests en un proyecto de Java (Clic para agrandar)"



Herramientas del Programador: Unit Testing

"Jajajaja Nunca te librarás de mi, programador"

Bugs. Todo programador los conoce. Desde el primer hola mundo que escribe en C y se da cuenta que no le compiló porque le hacía falta el punto y coma al final de la sentencia, el programador se da cuenta que los programas que escriba nunca serán perfectos y siempre habrá que arreglar los diferentes errores que comunmente se cometen cuando estamos desarrollando alguna aplicación.

Algunos consideran que el proceso de desarrollo de una aplicación se distribuye regularmente en un 20% de tiempo invertido en la codificación contra un 80% invertido en la depuración del código escrito. Esto nos lleva a pensar que corregimos mas de lo que producimos, lo cual no es muy efectivo que digamos a la hora del desarrollo. Para ello, existen técnicas que nos permiten prevenir la ocurrencia de Bugs o errores que comúnmente se cometen a la hora de la programación y entre estas, las más popular es el uso de Unit Testing.

Unit Testing. Es una de las etapas o técnicas que conforman el proceso de programación extrema, la cual consiste en llevar al extremo las habilidades de un programador y el tiempo invertido de manera que se involucre al cliente lo mas posible en el proceso de desarrollo y se entregue lo mas pronto posible. Unit tests son una serie de porciones de código que se escriben con la finalidad de probar y asegurar el correcto funcionamiento de los módulos y clases que conforman tu aplicación. Estas porciones de código, distribuidas en métodos dentro de clases, se ejecutan y devuelven un estado para saber si el test fue pasado con éxito o si este falló. Con los unit tests puedes probar que tu código funciona cuando debe funcionar y falla cuando debe fallar (aunque estas fallas, obviamente estarán controladas, quizá, mediante excepciones).

Por ejemplo, si tienes el siguiente método escrito en java:

public class Comparador {
public int getMayor(int[] lista){
int mayor = lista[0];
for(int i=1; imayor)
mayor = lista[i];
}
return mayor;
}
Podrias construir un Unit Test que se encargue de invocar a ese método pasándole parámetros de muestra y comparando (mediante un Assert) los resultados obtenidos con resultados esperados. Acá es donde el test te avisa si estos son idénticos (el Test pasa) o difieren (El test falla). Asi de simple es como funciona un Unit Test.

@Test
public void testGetMayor() {
Comparador t = new Comparador();
int esperado = 5;
int obtenido = t.getMayor(new int[]{1, 2, 3, 4, 2, 3, 5});
assertEquals(esperado, obtenido);
}

Si el valor esperado es diferente al valor obtenido, el método assertEquals nos avisará de ello mediante un mensaje.

Las ventajas de probar nuestros métodos con Unit Testing es que podemos saber justo después de codificarlos si ellos funcionan como es debido o no, además también podremos conservar los tests y pasarlos cada vez que modifiquemos el código para asegurarnos que los nuevos cambios realizados no afectaron el funcionamiento original de nuestro método y sigue devolviendo los valores esperados.


Con la experiencia, un programador aprende a conocer todas las posibles fallas que se podrían producir en una porción de código y prevenirlas antes que ocurran. Usando Unit Testing se puede comprobar que dichas fallas fueron mitigadas correctamente. Como recomendación, cada programador debe aprender a ser pesimista con su código, a pensar siempre lo peor de manera que su aplicación esté preparada para ello. Buscar todas las posibles fallas que pueda tener el código, sin importar qué tan ridículas, absurdas o imposibles estas sean. Sino, recuerden esa vez que estaban refinando su aplicación unas horas antes de su defensa final y por arte de magia, a última hora todo dejó de funcionar por culpa de un error que pasaron por alto y no creyeron que fuera a afectar tanto el proyecto.


"Como decía Murphy: Todo lo que puede salir mal, saldrá mal"

Para poder hacer uso de los Unit Tests, necesitas instalar el framework apropiado dependiendo del lenguaje de programación que estes utilizando para desarrollar y a veces este ya viene integrado en los IDEs o entornos de desarrollo. Por ejemplo, Java hace uso de la librería JUnit, la cual ya viene integrada en Netbeans, Python hace uso de PyUnit, Microsoft .Net utiliza NUnit, el cual se puede integrar con el IDE SharpDevelop, entre otros.

"Captura de pantalla del IDE Netbeans, mostrando los resultados de la ejecución de los Unit Tests en un proyecto de Java (Clic para agrandar)"



miércoles, diciembre 03, 2008

40 Cheat Sheets para Diseñadores

Si necesitas aprender algo rápido, o recordar como se realiza una tarea especifica, los Cheat Sheets son la herramienta que necesitas. En la siguiente colección, se presenta la selección de los 9 Cheat Sheets, de una lista original de 40 (el vinculo a la lista esta al final de este articulo), de los editores gráficos más utilizados por Diseñadores (Photoshop, Illustrator y Fireworks).

Hoja de referencia para Photoshop CS3 (Mac, Windows)

Combinacion de Teclas para Adobe® Photoshop® CS4 (Mac, Windows)

Shorcuts Secretos para Photoshop

Combinación de Teclas para Illustrator CS3 (Mac, Windows)

Shorcuts para Adobe Illustrator

Computer Arts - Combinación de teclas

(incluye cheat sheet para Freehand e InDesign).

Referencia de Fireworks CS3 (Mac, Windows)

Grafico de colores con su valor en HTML (CMYK, RGB Hex)


Tamaño estándar de Banners Web


El articulo original con los 40 Cheat Sheets se encuentra en SixRevisions:
http://sixrevisions.com/graphics-design/40-useful-cheat-sheets-for-designers/
Espero que les sirvan, ¡saludos!

40 Cheat Sheets para Diseñadores

Si necesitas aprender algo rápido, o recordar como se realiza una tarea especifica, los Cheat Sheets son la herramienta que necesitas. En la siguiente colección, se presenta la selección de los 9 Cheat Sheets, de una lista original de 40 (el vinculo a la lista esta al final de este articulo), de los editores gráficos más utilizados por Diseñadores (Photoshop, Illustrator y Fireworks).

Hoja de referencia para Photoshop CS3 (Mac, Windows)

Combinacion de Teclas para Adobe® Photoshop® CS4 (Mac, Windows)

Shorcuts Secretos para Photoshop

Combinación de Teclas para Illustrator CS3 (Mac, Windows)

Shorcuts para Adobe Illustrator

Computer Arts - Combinación de teclas

(incluye cheat sheet para Freehand e InDesign).

Referencia de Fireworks CS3 (Mac, Windows)

Grafico de colores con su valor en HTML (CMYK, RGB Hex)


Tamaño estándar de Banners Web


El articulo original con los 40 Cheat Sheets se encuentra en SixRevisions:
http://sixrevisions.com/graphics-design/40-useful-cheat-sheets-for-designers/
Espero que les sirvan, ¡saludos!

lunes, junio 09, 2008

Busquedas de Google: Popularidad o Relevancia?

Como habíamos mencionado antes en el articulo de las técnicas de búsqueda en Google, este buscador se basa en diferentes criterios parar mostrar los resultados que considere adecuados a las palabras clave utilizadas.

Como algunos sabrán, firefox posee integrado por defecto el buscador de Google para que podamos digitar palabras clave directamente en la barra de direcciones y al instante, nos muestra los resultados de la búsqueda y si tenemos suerte y si existe un resultado con grandes similitudes con nuestra palabra clave, nos redirecciona automáticamente a esta pagina. Pueden hacer la prueba digitando en su barra de direcciones de firefox palabras como "wikipedia", "debian" o "twitter" y los redireccionara automaticamente a www.wikipedia.org, www.debian.org y twitter.com respectivamente por ser resultados sumamente relevantes a los terminos de busqueda e igualmente pueden digitar las palabras "sr" y "byte", las cuales les mostrara los resultados de la busqueda de dichas palabras en google.

Esto me permitio darme cuenta que Google le da mas importancia a la popularidad que a la relevancia de los resultados de la busqueda. Como? pues recuerdo que hace meses cometia los errores de digitar "gamil" o "gmal" en lugar de "gmail" en mi barra de direcciones, lo cual obviamente me redireccionaba a gamil.com y pensaba en lo afortunados que eran los dueños de ese blog al recibir tantas visitas de todos los que se equivocaban al intentar ingresar a su cuenta de GMail.

"Screenshot del panel derecho del sitio web de Gamil"

Al parecer era tan común el error, que los dueños de Gamil hasta se tomaron la molestia de incluir una explicación indicando que tal vez llegaron a su sitio por equivocación al escribir mal "gmail".

Resulta que hace unos días volví a cometer el mismo error de escribir "gamil" en lugar de "gmail" en la barra de direcciones de firefox y cual fue mi sorpresa al darme cuenta que esta vez me redirigía automáticamente a la pagina de gmail en lugar del blog de gamil y lo corrobore al realizar la búsqueda directamente en la pagina de Google: al buscar la palabra "gamil" el primer resultado que aparece es "gmail" como una posible corrección y como segundo resultado te muestra gamil, el cual posee mas relevancia.

Mi conclusión ha sido que Google le ha dado mas importancia a la popularidad del sitio en los resultados de la búsqueda, en lugar de dársela a la relevancia de los mismos, aunque creo que podría ser una estrategia el ubicar sus propias URL por encima de los resultados con mas relevancia para aumentar sus visitas y por ende, su popularidad. Ustedes que creen?


Busquedas de Google: Popularidad o Relevancia?

Como habíamos mencionado antes en el articulo de las técnicas de búsqueda en Google, este buscador se basa en diferentes criterios parar mostrar los resultados que considere adecuados a las palabras clave utilizadas.

Como algunos sabrán, firefox posee integrado por defecto el buscador de Google para que podamos digitar palabras clave directamente en la barra de direcciones y al instante, nos muestra los resultados de la búsqueda y si tenemos suerte y si existe un resultado con grandes similitudes con nuestra palabra clave, nos redirecciona automáticamente a esta pagina. Pueden hacer la prueba digitando en su barra de direcciones de firefox palabras como "wikipedia", "debian" o "twitter" y los redireccionara automaticamente a www.wikipedia.org, www.debian.org y twitter.com respectivamente por ser resultados sumamente relevantes a los terminos de busqueda e igualmente pueden digitar las palabras "sr" y "byte", las cuales les mostrara los resultados de la busqueda de dichas palabras en google.

Esto me permitio darme cuenta que Google le da mas importancia a la popularidad que a la relevancia de los resultados de la busqueda. Como? pues recuerdo que hace meses cometia los errores de digitar "gamil" o "gmal" en lugar de "gmail" en mi barra de direcciones, lo cual obviamente me redireccionaba a gamil.com y pensaba en lo afortunados que eran los dueños de ese blog al recibir tantas visitas de todos los que se equivocaban al intentar ingresar a su cuenta de GMail.

"Screenshot del panel derecho del sitio web de Gamil"

Al parecer era tan común el error, que los dueños de Gamil hasta se tomaron la molestia de incluir una explicación indicando que tal vez llegaron a su sitio por equivocación al escribir mal "gmail".

Resulta que hace unos días volví a cometer el mismo error de escribir "gamil" en lugar de "gmail" en la barra de direcciones de firefox y cual fue mi sorpresa al darme cuenta que esta vez me redirigía automáticamente a la pagina de gmail en lugar del blog de gamil y lo corrobore al realizar la búsqueda directamente en la pagina de Google: al buscar la palabra "gamil" el primer resultado que aparece es "gmail" como una posible corrección y como segundo resultado te muestra gamil, el cual posee mas relevancia.

Mi conclusión ha sido que Google le ha dado mas importancia a la popularidad del sitio en los resultados de la búsqueda, en lugar de dársela a la relevancia de los mismos, aunque creo que podría ser una estrategia el ubicar sus propias URL por encima de los resultados con mas relevancia para aumentar sus visitas y por ende, su popularidad. Ustedes que creen?


lunes, marzo 24, 2008

Programemos Mejor

"Barquito elaborado con una hoja impresa de código HTML"

Hace poco terminé de desarrollar un sistema X y como programador, siempre acostumbro a dedicarme unos minutos, una vez terminada la creación, a contemplarla y sentirme orgulloso de haber sido capaz de crear algo de la nada usando mi ingenio y habilidades. Algo que puede ser de utilidad a otras personas, algo que vive (en sentido figurado), que tiene la apariencia que yo quise que tuviera y se comporta como yo quise que se comportara. Es algo así como: "Y vió Roberto que era bueno y ese fué el último día de la creación del sistema X".

Pero esta vez no fué así. El momento de contemplación no fué tan placentero como debiera ya que no estaba tan orgulloso de lo que había desarrollado. Existen ocasiones en las que uno no tiene el tiempo que quisiera para dedicarse a plasmar sus ideas y creatividad en un sistema y debe trabajar con la mente puesta únicamente en la correcta funcionalidad del mismo de modo que el sistema puede quedar feo, desordenado e incomprensible pero ha sido entregado a tiempo y funcional.

Después de desarrollarlo, uno sólo puede imaginarse la cara de los posteriores programadores encargados de la tarea de revisar el código fuente para agregarle mejoras, cuando se vayan topando con variables denominadas "foo" o "bar" o con esos métodos llamados CargarTablas1(), CargarTablas2() y CargarTablas3() que hacen exactamente lo mismo a diferencia de un par de líneas de código o el colmo de los colmos: líneas de código después de una sentencia return.

Debido a este tipo de situaciones, las cuales no siempre son causadas por falta de tiempo, es que me he tomado la libertad de crear la nueva sección denominada "Programemos Mejor" en las que se escribirán experiencias propias de malas formas de programar algunas herramientas o técnicas útiles para corregirlas.

Programemos Mejor

"Barquito elaborado con una hoja impresa de código HTML"

Hace poco terminé de desarrollar un sistema X y como programador, siempre acostumbro a dedicarme unos minutos, una vez terminada la creación, a contemplarla y sentirme orgulloso de haber sido capaz de crear algo de la nada usando mi ingenio y habilidades. Algo que puede ser de utilidad a otras personas, algo que vive (en sentido figurado), que tiene la apariencia que yo quise que tuviera y se comporta como yo quise que se comportara. Es algo así como: "Y vió Roberto que era bueno y ese fué el último día de la creación del sistema X".

Pero esta vez no fué así. El momento de contemplación no fué tan placentero como debiera ya que no estaba tan orgulloso de lo que había desarrollado. Existen ocasiones en las que uno no tiene el tiempo que quisiera para dedicarse a plasmar sus ideas y creatividad en un sistema y debe trabajar con la mente puesta únicamente en la correcta funcionalidad del mismo de modo que el sistema puede quedar feo, desordenado e incomprensible pero ha sido entregado a tiempo y funcional.

Después de desarrollarlo, uno sólo puede imaginarse la cara de los posteriores programadores encargados de la tarea de revisar el código fuente para agregarle mejoras, cuando se vayan topando con variables denominadas "foo" o "bar" o con esos métodos llamados CargarTablas1(), CargarTablas2() y CargarTablas3() que hacen exactamente lo mismo a diferencia de un par de líneas de código o el colmo de los colmos: líneas de código después de una sentencia return.

Debido a este tipo de situaciones, las cuales no siempre son causadas por falta de tiempo, es que me he tomado la libertad de crear la nueva sección denominada "Programemos Mejor" en las que se escribirán experiencias propias de malas formas de programar algunas herramientas o técnicas útiles para corregirlas.

Sunsetting Sr. Byte.

El Sr. Byte ha estado más de 5 años inactivo. Digamos que estaba en " code freeze ". Pero ahora es el último release. Quizas no...