sábado, mayo 31, 2008

Medios Sociales, Sitios Web a lo 2.0

Aportando mas a los temas anteriores de las redes sociales y el web 2.0, podemos hablar un poco de lo que se considera como Medios Sociales, los cuales son las herramientas del web 2.0 que le permiten al usuario interactuar con un sitio web y los medios (hipertexto, imágenes, musica, vídeos) que este provee.

Esta es la principal diferencia de los Medios Tradicionales como periódicos, estaciones de radio y televisión, los cuales transmiten la información de una forma unilateral

Entre las características de los sitios web considerados como medios sociales o de contenido social se encuentran:

  • Capacidad de personalización: Los usuarios deben ser capaces de ingresar al sitio, crear una cuenta para identificarse y personalizarlo en base a sus gustos o sus necesidades. Ejemplo de ello fue el sitio de shutdownday el cual contaba con una serie de widgets ordenables en los espacios disponibles así como la posibilidad de agregar mas widgets, también twitter que permite cambiar la combinación de colores del sitio.
  • Sugerencias (feedback): El sitio web debe permitirle a los usuarios la capacidad de dejar sus sugerencias y opiniones acerca del sitio para sus respectivas mejoras. Como por ejemplo Google, que hace un par de meses mostró un vinculo en el sitio de Google Documents el cual nos permitía, mediante una no tan corta encuesta, dejar nuestras opiniones acerca del servicio y brindar sugerencias de mejoras.
  • Participacion: Hoy en día, los sitios web no solamente se encargan de mostrar información, ahora el usuario puede manipular esta información teniendo su propio espacio personal dentro del sitio para editar y agregar nuevo contenido. El ejemplo mas claro es la wikipedia.
  • Dinamismo: Gracias a la participación de los usuarios, un sitio web con contenido social no tendrá la misma apariencia ni contenido siempre, este cambiara en tanto que los usuarios dejen su huella dentro del sitio modificándolo y agregando nuevo contenido. Por ejemplo, en Deviantart te puedes dar cuenta que agregan una nueva "desviación" aproximadamente cada segundo, por lo que no veras el mismo contenido cada vez que refresques la pagina del sitio.
  • Interacción social: Por algo le han llamado social a todo esto, y es porque estos sitios enlazan a personas de todas partes del mundo, de manera que ellos puedan compartir sus ideas (por resumir todo lo que se puede compartir en la web) entre ellos. Hay tantos ejemplos de ello, cual mencionar? que tal myspace, facebook o hi5?

No hay duda que los sitios al estilo web 2.0 con contenido social (o medios sociales, como lo quieran llamar) aumentan su productividad y popularidad. Una mejor manera de explicarlo es a través de un vídeo demostrativo (hecho con dibujos a lápiz en piezas de papel!), elaborado por commoncraft:



"Commoncraft: Social Media in Plain English"


Algo mas que deseen aportar sobre el tema?

Medios Sociales, Sitios Web a lo 2.0

Aportando mas a los temas anteriores de las redes sociales y el web 2.0, podemos hablar un poco de lo que se considera como Medios Sociales, los cuales son las herramientas del web 2.0 que le permiten al usuario interactuar con un sitio web y los medios (hipertexto, imágenes, musica, vídeos) que este provee.

Esta es la principal diferencia de los Medios Tradicionales como periódicos, estaciones de radio y televisión, los cuales transmiten la información de una forma unilateral

Entre las características de los sitios web considerados como medios sociales o de contenido social se encuentran:

  • Capacidad de personalización: Los usuarios deben ser capaces de ingresar al sitio, crear una cuenta para identificarse y personalizarlo en base a sus gustos o sus necesidades. Ejemplo de ello fue el sitio de shutdownday el cual contaba con una serie de widgets ordenables en los espacios disponibles así como la posibilidad de agregar mas widgets, también twitter que permite cambiar la combinación de colores del sitio.
  • Sugerencias (feedback): El sitio web debe permitirle a los usuarios la capacidad de dejar sus sugerencias y opiniones acerca del sitio para sus respectivas mejoras. Como por ejemplo Google, que hace un par de meses mostró un vinculo en el sitio de Google Documents el cual nos permitía, mediante una no tan corta encuesta, dejar nuestras opiniones acerca del servicio y brindar sugerencias de mejoras.
  • Participacion: Hoy en día, los sitios web no solamente se encargan de mostrar información, ahora el usuario puede manipular esta información teniendo su propio espacio personal dentro del sitio para editar y agregar nuevo contenido. El ejemplo mas claro es la wikipedia.
  • Dinamismo: Gracias a la participación de los usuarios, un sitio web con contenido social no tendrá la misma apariencia ni contenido siempre, este cambiara en tanto que los usuarios dejen su huella dentro del sitio modificándolo y agregando nuevo contenido. Por ejemplo, en Deviantart te puedes dar cuenta que agregan una nueva "desviación" aproximadamente cada segundo, por lo que no veras el mismo contenido cada vez que refresques la pagina del sitio.
  • Interacción social: Por algo le han llamado social a todo esto, y es porque estos sitios enlazan a personas de todas partes del mundo, de manera que ellos puedan compartir sus ideas (por resumir todo lo que se puede compartir en la web) entre ellos. Hay tantos ejemplos de ello, cual mencionar? que tal myspace, facebook o hi5?

No hay duda que los sitios al estilo web 2.0 con contenido social (o medios sociales, como lo quieran llamar) aumentan su productividad y popularidad. Una mejor manera de explicarlo es a través de un vídeo demostrativo (hecho con dibujos a lápiz en piezas de papel!), elaborado por commoncraft:



"Commoncraft: Social Media in Plain English"


Algo mas que deseen aportar sobre el tema?

lunes, mayo 26, 2008

El video que resume las redes sociales

Sumergido en mi lectura diaria de Feeds, me encontre con este video que se encarga de sumarizar el problema con las redes sociales (hi5, orkut, myspace, etc... ya hablare de ellos mas tarde), espero que les guste:

"Video: Parodia sobre sitios de redes sociales"


¡Hasta la proxima!



El video que resume las redes sociales

Sumergido en mi lectura diaria de Feeds, me encontre con este video que se encarga de sumarizar el problema con las redes sociales (hi5, orkut, myspace, etc... ya hablare de ellos mas tarde), espero que les guste:

"Video: Parodia sobre sitios de redes sociales"


¡Hasta la proxima!



domingo, mayo 25, 2008

Freelancer = trabajador independiente = $$$

El termino freelancer (o freelance), aparentemente, se puede traducir casi literalmente como "trabajador independiente", aunque la etimología de la palabra deriva del término medieval inglés usado para un mercenario (free-lance o lanza-independiente), como los guerreros Haradrim, de El Señor de Los Anillos:

"Imagen: Guerrero Haradrim, Mercenario"

...es decir, un guerrero que no servía a ningún señor en concreto y cuyos servicios podían ser alquilados por cualquiera, pero bueno, en nuestra "epoca" se le llama freelancer a alguien que es contratado por terceros para realizar una actividad determinada y por tiempo limitado hasta que duren las existencias. Puedes ver una definición más amplia en la wikipedia.

En los países desarrollados los trabajadores independientes ocupan una parte importante de la fuerza laboral, en nuestros países no tan desarrollados (latinoamericanos), el caso más común o más bien conocido de freelancers es el de los "periodístas" que escriben artículos/columnas/reseñas y luego los venden a un periódico o revista determinada. La llegada de Internet ha cambiado mucho el mercado de freelancers, ya que actualmente son muchas más profesiones las que pueden incluirse en esta modalidad de trabajo como los de la programación informática, el diseño gráfico, la consultoría, la fotografía, la traducción, y muchos otros servicios profesionales y creativos, y es más, me atreveria a decir que hasta el autor de un blog puede ser un trabajador contratado para escribir articulos y por lo tanto convertirse en un freelancer.

Las ventajas de ser un freelancer hoy en día son muchas, ya que con facilidad usted puede trabajar en un proyecto para el cual hay un presupuesto de $ 3,000 (USD), el mismo que puede ser terminado en una semana, desde su casa u oficina en su país, sin tener que abandonarlo, usando el Internet como herramienta de comunicación. Compare una semana de trabajo y ganar $ 3,000 (USD) con el sueldo mínimo de su país y los beneficios son más que obvios.

Ser freelancer también puede tener sus desventajas, como el aumento del stress por cumplir plazos, aumento de tension familiar, paranoia/miedo por no tener un trabajo estable, etc...

"Comic: La libertad del freelance"

¿Y quien puede ser un freelancer?
Practicamente cualquier profesional o estudiante que tenga los conocimientos necesarios para realizar una determinada tarea. Simple, ¿verdad?.
Desde un punto de vista cultural, el ser freelance es percibido tanto por encima como por debajo del sistema social, algunos americanos y la mayoría de los europeos ven el trabajo freelance como una posición socialmente más elevada. Sin embargo, muchos países asiáticos parecen tener en baja estima a los freelancers, a menudo asociando la práctica con el fracaso personal (incapacidad de conseguir un trabajo con un empleador importante) e inclusive llegando al extremo de asociarlo con criminalidad (por la cuestion de los mercenarios/ninjas, ¿te suena el termino "Hitokiri Battōsai"?).

"Imagen: En las culturas orientales, se asocia de manera negativa el termino de Freelancer con Ninjas asesinos pagados a sueldo. "

Para terminar, solo quiero saber: ¿Cuantos de ustedes han realizado algun trabajo de Freelancer?, ¡esperamos sus respuestas!, Saludos!


Freelancer = trabajador independiente = $$$

El termino freelancer (o freelance), aparentemente, se puede traducir casi literalmente como "trabajador independiente", aunque la etimología de la palabra deriva del término medieval inglés usado para un mercenario (free-lance o lanza-independiente), como los guerreros Haradrim, de El Señor de Los Anillos:

"Imagen: Guerrero Haradrim, Mercenario"

...es decir, un guerrero que no servía a ningún señor en concreto y cuyos servicios podían ser alquilados por cualquiera, pero bueno, en nuestra "epoca" se le llama freelancer a alguien que es contratado por terceros para realizar una actividad determinada y por tiempo limitado hasta que duren las existencias. Puedes ver una definición más amplia en la wikipedia.

En los países desarrollados los trabajadores independientes ocupan una parte importante de la fuerza laboral, en nuestros países no tan desarrollados (latinoamericanos), el caso más común o más bien conocido de freelancers es el de los "periodístas" que escriben artículos/columnas/reseñas y luego los venden a un periódico o revista determinada. La llegada de Internet ha cambiado mucho el mercado de freelancers, ya que actualmente son muchas más profesiones las que pueden incluirse en esta modalidad de trabajo como los de la programación informática, el diseño gráfico, la consultoría, la fotografía, la traducción, y muchos otros servicios profesionales y creativos, y es más, me atreveria a decir que hasta el autor de un blog puede ser un trabajador contratado para escribir articulos y por lo tanto convertirse en un freelancer.

Las ventajas de ser un freelancer hoy en día son muchas, ya que con facilidad usted puede trabajar en un proyecto para el cual hay un presupuesto de $ 3,000 (USD), el mismo que puede ser terminado en una semana, desde su casa u oficina en su país, sin tener que abandonarlo, usando el Internet como herramienta de comunicación. Compare una semana de trabajo y ganar $ 3,000 (USD) con el sueldo mínimo de su país y los beneficios son más que obvios.

Ser freelancer también puede tener sus desventajas, como el aumento del stress por cumplir plazos, aumento de tension familiar, paranoia/miedo por no tener un trabajo estable, etc...

"Comic: La libertad del freelance"

¿Y quien puede ser un freelancer?
Practicamente cualquier profesional o estudiante que tenga los conocimientos necesarios para realizar una determinada tarea. Simple, ¿verdad?.
Desde un punto de vista cultural, el ser freelance es percibido tanto por encima como por debajo del sistema social, algunos americanos y la mayoría de los europeos ven el trabajo freelance como una posición socialmente más elevada. Sin embargo, muchos países asiáticos parecen tener en baja estima a los freelancers, a menudo asociando la práctica con el fracaso personal (incapacidad de conseguir un trabajo con un empleador importante) e inclusive llegando al extremo de asociarlo con criminalidad (por la cuestion de los mercenarios/ninjas, ¿te suena el termino "Hitokiri Battōsai"?).

"Imagen: En las culturas orientales, se asocia de manera negativa el termino de Freelancer con Ninjas asesinos pagados a sueldo. "

Para terminar, solo quiero saber: ¿Cuantos de ustedes han realizado algun trabajo de Freelancer?, ¡esperamos sus respuestas!, Saludos!


miércoles, mayo 14, 2008

¿Esta versionada tu Base de Datos?

Atencion: esta entrada es para programadores... y geeks en general.

Como mencionaba Robertux en una entrada anterior:
"""¿Les ha pasado alguna vez que cuando están programando se dan cuenta que las líneas de código que acaban de agregar arruinaron el sistema y desean volver a como lo tenían el día de ayer ya que en ese entonces todavía compilaba, pero ya no se acuerdan qué fue lo último que agregaron para así poder revertirlo?

¿Les ha ocurrido que cada cierto tiempo crean una copia de la carpeta del proyecto en el que trabajan para guardarla como backup y además de que cada copia les abarca más de 10 o 20 MB de espacio en disco, al final no saben si la última versión está en la carpeta "ProyectoUltimo", "ProyectoFinal" o "ProyectoBueno" y les toca comparar las fechas de cada una?

¿Será que cuando trabajan en grupos, cada quién con su copia del proyecto y modificando los archivos que a cada quién le corresponden, al final no saben ni por dónde empezar para unir todos los archivos correctos en un único proyecto para tener la versión final y funcional?

Todas estas situaciones pasan porque no se están utilizando herramientas para el trabajo en grupo y específicamente, para el control de versiones."""

Y lo mismo podríamos decir de las Bases de Datos. Así que, developers, con esta idea en mente les pregunto:
¿Esta tu base de datos bajo control de version (cvs ó svn)?
...la respuesta a esta pregunta debería de ser (en los casos que lo amerite) SI.
¿Por que? simplemente por que:
¡la base de datos es una de las partes más criticas de cualquier aplicación! (la base de datos es tan parte de la aplicación, como el código y los modelos dentro del software)
y en la etapa de desarrollo, con varias personas trabajando en un proyecto, es muy probable que se cometan errores como los que mencionábamos al principio... o peores.
¿Y como versiono una base de datos?, bien, aquí hay un pequeño ejemplo:

Escenario de trabajo:
Gestor de Base de Datos: MySQL.
Repositorio SVN: Google Code.
Herramientas a usar (multiplataforma): SVN y MySQL (dump).
Para versionar una base de datos en mysql, basta con versionar el dump de la base de datos. Y el proceso de versionado ("Commit" y "Update" de cambios) y restauración de la BD se realiza con dos sencillos script (estos scripts pueden estar en una carpeta que se llame SQL y ser parte del proyecto que contenga esos scripts), uno script sera para realizar el "Commit" y otro para el "Update".

La logica del script de "Commit" es la siguiente:
1. Despues de realizar cambios significativos en la base de datos...
2. Llama a "mysqldump", y realiza un respaldo de la base de datos (con su contenido) en un archivo sql, por ejemplo:
mysqldump --single-transaction -hlocalhost -uROOT -pTOOR BASEDEDATOS > basededatos.sql

3. Luego realiza un "Commit" del archivo, asi:
svn commit -m "Dump de base de datos versionado" basededatos.sql

La logica del script de "Update" es la siguiente:
1. Realiza un "Update" invocando a svn...
svn update
2. Restauramos el dump actualizado obtenido a mysql:
mysql.exe -uROOT -pTOOR BASEDEDATOS < basededatos.sql

No hay que preocuparse por la información de Login para el svn, ya que si la carpeta en la que se invoca el script de commit o update esta agregada al repositorio, svn crea una carpeta llamada ".svn" que contiene la información de login (y otras cosas).
Como les mencione, esa es la lógica, si yo hago un cambio a la base de datos, hago el commit, y si hay cambios (o antes de una sesión de trabajo) hago el update.

Si esta entrada te pareció útil, aquí hay algunas reglas para trabajar con bases de datos que deberías de leer.

Espero que esto les sirva para facilitar su trabajo de desarrollo de software, ¡Saludos!


¿Esta versionada tu Base de Datos?

Atencion: esta entrada es para programadores... y geeks en general.

Como mencionaba Robertux en una entrada anterior:
"""¿Les ha pasado alguna vez que cuando están programando se dan cuenta que las líneas de código que acaban de agregar arruinaron el sistema y desean volver a como lo tenían el día de ayer ya que en ese entonces todavía compilaba, pero ya no se acuerdan qué fue lo último que agregaron para así poder revertirlo?

¿Les ha ocurrido que cada cierto tiempo crean una copia de la carpeta del proyecto en el que trabajan para guardarla como backup y además de que cada copia les abarca más de 10 o 20 MB de espacio en disco, al final no saben si la última versión está en la carpeta "ProyectoUltimo", "ProyectoFinal" o "ProyectoBueno" y les toca comparar las fechas de cada una?

¿Será que cuando trabajan en grupos, cada quién con su copia del proyecto y modificando los archivos que a cada quién le corresponden, al final no saben ni por dónde empezar para unir todos los archivos correctos en un único proyecto para tener la versión final y funcional?

Todas estas situaciones pasan porque no se están utilizando herramientas para el trabajo en grupo y específicamente, para el control de versiones."""

Y lo mismo podríamos decir de las Bases de Datos. Así que, developers, con esta idea en mente les pregunto:
¿Esta tu base de datos bajo control de version (cvs ó svn)?
...la respuesta a esta pregunta debería de ser (en los casos que lo amerite) SI.
¿Por que? simplemente por que:
¡la base de datos es una de las partes más criticas de cualquier aplicación! (la base de datos es tan parte de la aplicación, como el código y los modelos dentro del software)
y en la etapa de desarrollo, con varias personas trabajando en un proyecto, es muy probable que se cometan errores como los que mencionábamos al principio... o peores.
¿Y como versiono una base de datos?, bien, aquí hay un pequeño ejemplo:

Escenario de trabajo:
Gestor de Base de Datos: MySQL.
Repositorio SVN: Google Code.
Herramientas a usar (multiplataforma): SVN y MySQL (dump).
Para versionar una base de datos en mysql, basta con versionar el dump de la base de datos. Y el proceso de versionado ("Commit" y "Update" de cambios) y restauración de la BD se realiza con dos sencillos script (estos scripts pueden estar en una carpeta que se llame SQL y ser parte del proyecto que contenga esos scripts), uno script sera para realizar el "Commit" y otro para el "Update".

La logica del script de "Commit" es la siguiente:
1. Despues de realizar cambios significativos en la base de datos...
2. Llama a "mysqldump", y realiza un respaldo de la base de datos (con su contenido) en un archivo sql, por ejemplo:
mysqldump --single-transaction -hlocalhost -uROOT -pTOOR BASEDEDATOS > basededatos.sql

3. Luego realiza un "Commit" del archivo, asi:
svn commit -m "Dump de base de datos versionado" basededatos.sql

La logica del script de "Update" es la siguiente:
1. Realiza un "Update" invocando a svn...
svn update
2. Restauramos el dump actualizado obtenido a mysql:
mysql.exe -uROOT -pTOOR BASEDEDATOS < basededatos.sql

No hay que preocuparse por la información de Login para el svn, ya que si la carpeta en la que se invoca el script de commit o update esta agregada al repositorio, svn crea una carpeta llamada ".svn" que contiene la información de login (y otras cosas).
Como les mencione, esa es la lógica, si yo hago un cambio a la base de datos, hago el commit, y si hay cambios (o antes de una sesión de trabajo) hago el update.

Si esta entrada te pareció útil, aquí hay algunas reglas para trabajar con bases de datos que deberías de leer.

Espero que esto les sirva para facilitar su trabajo de desarrollo de software, ¡Saludos!


3 reglas al trabajar con Bases de Datos

Aquí presento algunas reglas para trabajar con bases de datos:

Regla 1: Nunca uses un solo servidor de bases de datos para todo el trabajo de desarrollo (exacto, nada de bases de datos centralizadas).

La conveniencia de trabajar con un servidor centralizado de bases de datos es tentadora. Todos los desarrolladores se conectan a una sola base de datos que pueden probar y cambiar. Este servidor funcionara como el Anillo Único de Sauron... y todos los cambios que se den, se reflejaran inmediatamente a todos los miembros del equipo de desarrollo. Es más, es tan convincente la idea de usar un servidor centralizado, que este la gente lo usa como repositorio de datos de prueba.

"Imagen: Gollum con el Anillo"

Pero, como muchas conveniencias en el desarrollo de software (y así de engañoso y malévolo como el Anillo Único), usar una sola base de datos para todo el equipo, funciona como un pozo de brea... si, como en el que murieron tantos dinosaurios :P.

"Imagen: Pozo de Brea"

Todos los desarrolladores están tentados a cambiar los tipos de datos en algún momento, y los mas probable es que así sea, pero el cambio que un desarrollador puede hacer en la base de datos... veamos que sucede, cuando todo sale mal... estos son los pasos al pozo de brea:
  1. Un desarrollador modifica un tipo de dato en la base de datos (o peor, una tabla entera... o varias).
  2. El cambio probablemente provocara un error en mi código (ya no puedo compilar mi parte).
  3. Esto implica que tengo que hacer cambios en mi código para que todo funciona como antes.
  4. O tengo que esperar a que el desarrollador que modifico la base de datos haga un "Commit" de su código para que altere el mio... y ver si funciona con lo que el hizo.
  5. Pueda que su "Commit" altere o no mi código.
  6. Si no lo altera, y ahora YO tendré que ver que $%&&/$ altero el tipo, para que mi código funcione (¿cuanto tiempo perdí ya?).
  7. Es posible también que el tipo diga después: "bueno, me equivoque, solo estaba probando...".
  8. Ahora hay que regresar a la versión anterior del software, perder horas de cambios y ajustes, y realizar el proceso, cada vez que alguien disponga hacer el paso 1.
Ademas desarrollar con una base de datos remota es LENTOOOOOOO...

"Imagen: Maldito desarrollador, ¡cambiaste todas las tablas sin avisar!"


Regla 2: Siempre ten una sola y respetada fuente para el esquema de tu base de datos (alguien se encarga de mantener y liberar la base de datos para todos).

Idealmente, esta única fuente sera tu control de versiones ( ver la regla #3). Considere el siguiente entre dos desarrolladores, Pedro y Juan:

Pedro: Es tiempo para comenzar a probar la aplicación, y depurar los errores. ¿Copiamos la base de datos de la maquina de José, o usamos la base de datos de Luis?

Juan: Ummmmmmmm, no recuerdo cual es la base de datos mas reciente (u oficial, o actualizada)

Pedro: Shit... (se pone a llorar).

Todo mundo debería de saber donde esta el ultimo esquema de la base de datos, y también es el derecho de los desarrolladores tener una experiencia sin problema para obtenerla y usarla en su maquina de trabajo. Yo desarrollador quiero caminar a mi estación de trabajo, obtener la ultima versión de la base de datos por medio de cvs ó svn, y trabajar transparentemente con ella, sin preocuparme por nada más que hacer mi trabajo.


Regla 3: Siempre versiona tu base de datos.

Hay muchas maneras de versionar una base de datos, pero el objetivo principal es propagar los cambios, probar y liberar la base de datos en una manera controlada y consistente. Un segundo objetivo es poder regresar y recrear la base de datos de algún momento anterior. Este segundo objetivo es particularmente importante si se produce software para clientes. Si alguien tiene un bug (error) en la versión 1.00.3.4 de tu aplicación (y tu vas por la versión 2.00.5.0) tienes que ser capaz de recrear la aplicación y su base de datos para esa versión, para poder darle soporte técnico al cliente o a los clientes que tengan esa versión.

Respeta estas reglas, y tu desarrollo de software sera muchísimo mas sencillo y menos traumatico.

¡Saludos!


3 reglas al trabajar con Bases de Datos

Aquí presento algunas reglas para trabajar con bases de datos:

Regla 1: Nunca uses un solo servidor de bases de datos para todo el trabajo de desarrollo (exacto, nada de bases de datos centralizadas).

La conveniencia de trabajar con un servidor centralizado de bases de datos es tentadora. Todos los desarrolladores se conectan a una sola base de datos que pueden probar y cambiar. Este servidor funcionara como el Anillo Único de Sauron... y todos los cambios que se den, se reflejaran inmediatamente a todos los miembros del equipo de desarrollo. Es más, es tan convincente la idea de usar un servidor centralizado, que este la gente lo usa como repositorio de datos de prueba.

"Imagen: Gollum con el Anillo"

Pero, como muchas conveniencias en el desarrollo de software (y así de engañoso y malévolo como el Anillo Único), usar una sola base de datos para todo el equipo, funciona como un pozo de brea... si, como en el que murieron tantos dinosaurios :P.

"Imagen: Pozo de Brea"

Todos los desarrolladores están tentados a cambiar los tipos de datos en algún momento, y los mas probable es que así sea, pero el cambio que un desarrollador puede hacer en la base de datos... veamos que sucede, cuando todo sale mal... estos son los pasos al pozo de brea:
  1. Un desarrollador modifica un tipo de dato en la base de datos (o peor, una tabla entera... o varias).
  2. El cambio probablemente provocara un error en mi código (ya no puedo compilar mi parte).
  3. Esto implica que tengo que hacer cambios en mi código para que todo funciona como antes.
  4. O tengo que esperar a que el desarrollador que modifico la base de datos haga un "Commit" de su código para que altere el mio... y ver si funciona con lo que el hizo.
  5. Pueda que su "Commit" altere o no mi código.
  6. Si no lo altera, y ahora YO tendré que ver que $%&&/$ altero el tipo, para que mi código funcione (¿cuanto tiempo perdí ya?).
  7. Es posible también que el tipo diga después: "bueno, me equivoque, solo estaba probando...".
  8. Ahora hay que regresar a la versión anterior del software, perder horas de cambios y ajustes, y realizar el proceso, cada vez que alguien disponga hacer el paso 1.
Ademas desarrollar con una base de datos remota es LENTOOOOOOO...

"Imagen: Maldito desarrollador, ¡cambiaste todas las tablas sin avisar!"


Regla 2: Siempre ten una sola y respetada fuente para el esquema de tu base de datos (alguien se encarga de mantener y liberar la base de datos para todos).

Idealmente, esta única fuente sera tu control de versiones ( ver la regla #3). Considere el siguiente entre dos desarrolladores, Pedro y Juan:

Pedro: Es tiempo para comenzar a probar la aplicación, y depurar los errores. ¿Copiamos la base de datos de la maquina de José, o usamos la base de datos de Luis?

Juan: Ummmmmmmm, no recuerdo cual es la base de datos mas reciente (u oficial, o actualizada)

Pedro: Shit... (se pone a llorar).

Todo mundo debería de saber donde esta el ultimo esquema de la base de datos, y también es el derecho de los desarrolladores tener una experiencia sin problema para obtenerla y usarla en su maquina de trabajo. Yo desarrollador quiero caminar a mi estación de trabajo, obtener la ultima versión de la base de datos por medio de cvs ó svn, y trabajar transparentemente con ella, sin preocuparme por nada más que hacer mi trabajo.


Regla 3: Siempre versiona tu base de datos.

Hay muchas maneras de versionar una base de datos, pero el objetivo principal es propagar los cambios, probar y liberar la base de datos en una manera controlada y consistente. Un segundo objetivo es poder regresar y recrear la base de datos de algún momento anterior. Este segundo objetivo es particularmente importante si se produce software para clientes. Si alguien tiene un bug (error) en la versión 1.00.3.4 de tu aplicación (y tu vas por la versión 2.00.5.0) tienes que ser capaz de recrear la aplicación y su base de datos para esa versión, para poder darle soporte técnico al cliente o a los clientes que tengan esa versión.

Respeta estas reglas, y tu desarrollo de software sera muchísimo mas sencillo y menos traumatico.

¡Saludos!


miércoles, mayo 07, 2008

¿Porque la "i" en los Productos Apple?

El día de hoy, a través de Fayerwayer me doy cuenta que el producto que causó controversia e innovación en el diseño de las computadoras en general allá por la época de 1998, la Apple iMac "todo en uno" cumple diez años de existencia en el mercado.

"Feliz Cumpleaños iMac!"

Desde entonces, Apple ha lanzado una serie de productos con un diseño muy elegante y creativo y nombres simples como las iBook, iPod, iTunes y recientemente el iPhone, por lo que siempre me había quedado la duda sobre ¿A que se debe la tan mencionada "i" que precede a toda esta gama de productos?

Según la conferencia que dio Steve Jobs en la que presento la iMac en 1998, la "i" se refería a ciertas características que involucraban el nuevo y revolucionario producto, entre ellas la facilidad de conexión a Internet, la inspiración que este equipo causaba, el hecho de ser una computadora individual (sin la necesidad de poseer un CPU externo al monitor), entre otras.

Desde entonces, la "i" ha sido sinónimo también de la innovación que causan los productos Apple que han surgido desde entonces como el iPod y el iPhone. Ademas siempre existen personas que hacen parodias tanto de la tendencia "i" en productos no tan relacionados con la informatica y personas que hacen uso de los productos Apple como una moda hasta el punto de crear una imagen de Steve Jobs con un collage de productos e Apple.



"Apple iMac Ad: Steps to Connect to Internet"


¿Porque la "i" en los Productos Apple?

El día de hoy, a través de Fayerwayer me doy cuenta que el producto que causó controversia e innovación en el diseño de las computadoras en general allá por la época de 1998, la Apple iMac "todo en uno" cumple diez años de existencia en el mercado.

"Feliz Cumpleaños iMac!"

Desde entonces, Apple ha lanzado una serie de productos con un diseño muy elegante y creativo y nombres simples como las iBook, iPod, iTunes y recientemente el iPhone, por lo que siempre me había quedado la duda sobre ¿A que se debe la tan mencionada "i" que precede a toda esta gama de productos?

Según la conferencia que dio Steve Jobs en la que presento la iMac en 1998, la "i" se refería a ciertas características que involucraban el nuevo y revolucionario producto, entre ellas la facilidad de conexión a Internet, la inspiración que este equipo causaba, el hecho de ser una computadora individual (sin la necesidad de poseer un CPU externo al monitor), entre otras.

Desde entonces, la "i" ha sido sinónimo también de la innovación que causan los productos Apple que han surgido desde entonces como el iPod y el iPhone. Ademas siempre existen personas que hacen parodias tanto de la tendencia "i" en productos no tan relacionados con la informatica y personas que hacen uso de los productos Apple como una moda hasta el punto de crear una imagen de Steve Jobs con un collage de productos e Apple.



"Apple iMac Ad: Steps to Connect to Internet"


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...