9.30.2008

Qué es el Diseño de Interacción

Por Javier Velasco M.

Escrito Agosto 2004*, Publicado en mantruc.com Septiembre 2006

También disponible en Versión PDF (200 KB)

El diseño de interacción determina las posibilidades de operación de un sistema tecnológico: las posibilidades de acción de las personas que lo usarán, y las reacciones del sistema ante estas acciones.

Nociones básicas: Interacción e Interfaz

Comencemos por definir la interacción y la interfaz que nos mediatiza la interacción. La interacción es un diálogo de comportamiento entre dos entidades, el accionar de una condiciona la respuesta de la otra. De acuerdo al diccionario de la RAE:

interacción. 1.
f. Acción que se ejerce recíprocamente entre dos o más objetos, agentes, fuerzas, funciones, etc.
Real Academia Española ©

Todo sistema electrónico es interactivo, ya que modifica su comportamiento (funciones) de acuerdo a los comandos de un usuario.

La interacción entre un sistema y su usuario se canaliza a través de una interfaz o punto de encuentro. La interfaz hace tangibles las posibilidades del sistema y permite al usuario comunicar sus comandos al sistema.

interfaz. (Del ingl. interface, superficie de contacto).
1. f. Inform. Conexión física y funcional entre dos aparatos o sistemas independientes.
Real Academia Española ©

En los aparatos físicos, las interfaces se componen de perillas, botones, luces, pantallas, parlantes. En el software todo se debe canalizar a través de una interfaz doble: en primer lugar, está la interfaz del computador - dispositivos de entrada y salida, principalmente teclado, mouse, pantalla y parlantes - y en segundo, las interfaces del sistema operativo, generalmente compuesta de elementos como ventanas, directorios, menús, cursores.

El diseño de interacción y el diseño de la interfaz son mutuamente dependientes, muchas veces las decisiones de un plano condicionarán las decisiones en el otro plano.

Hasta el momento1 , los sistemas electrónicos y tecnológicos en general, no están dotados de inteligencia propia. Todo sistema será tan inteligente como su diseño permita.

Dado que todo lo que puede hacer una máquina estará condicionado por su diseño, la tarea de diseñar su comportamiento consiste en prever las posibles acciones y respuestas de un humano ante este sistema, y diseñar reacción del sistema ante los comandos del humano. Se asemeja a crear la coreografía para un baile.

Antiguamente, los computadores tenían capacidades muy limitadas, esto significaba que el baile debía hacerse al paso de la máquina y que el usuario debía ser un experto en el lenguaje de la máquina, para ser capaz de seguirle el paso y lograr que ésta se moviera según su voluntad.

Actualmente, tanto el hardware como el software han evolucionado para ofrecer mayor flexibilidad en el diseño de cada función. Los usuarios de computadores actualmente son personas comunes que no poseen estudios en informática. Este factor hace más necesario crear coreografías más antropomorfas, donde sea la máquina la que siga el paso del humano. Ésa es la meta del diseño de interacción: crear sistemas que satisfagan las necesidades de las personas que los usan, en una forma que resulte espontánea y satisfactoria.

Quién se ocupa del diseño de interacción

Como ya se ha explicado, todo aparato tecnológico implica un diseño de interacción para poder ser operado por un usuario. Sin embargo, no todas las empresas que diseñan y construyen aparatos ó sistemas tecnológicos adoptan el diseño de interacción como un proceso particular, ni el rol de diseñador de interacción como un papel específico dentro de su equipo de trabajo. Muchas veces el diseño de interacción se realiza como parte de otros procesos, a veces a cargo de ingenieros y personas de negocios, otras veces como parte del aspecto ergonómico de los proyectos.

El diseño de interacción como actividad particular toma fuerza durante los años 90 con el crecimiento del área de la Interacción Persona-Ordenador (IPO / HCI) como una rama de las ciencias de la computación. Este crecimiento da origen a una serie de metodologías bajo el enfoque de Diseño Centrado en el Usuario.

Bajo un proceso ideal, es el diseñador de interacción quien creará las especificaciones para la construcción del sistema. Esto implica determinar las funcionalidades que ofrecerá el sistema, los parámetros para cada una de éstas, las secuencias de comandos necesarias para ejecutarlas y los elementos de la interfaz que permitirán a las personas manejar estas funciones, así como sus nombres, ubicación, tamaño relativo; y todos los elementos que canalicen la comunicación entre sistema y usuario, gatillos y mensajes.

Un ejemplo tangible

Para llevar todos estos conceptos abstractos a un plano más tangible, revisemos un caso común, con aparatos que usamos a diario. A continuación se analiza el comportamiento de dos equipos de sonido, de constructores diferentes, en una misma operación.

Nuestro breve análisis se basará en operaciones comunes a ambos equipos, el encendido y la selección de modo, función o fuente. Ambos sistemas ofrecen las mismas posibilidades en este sentido, sus modos son los mismos:

  • Radio
  • CD
  • Cassette
  • Entrada Auxiliar

En ambos casos, las interfaces han sido descritas en Inglés.

Equipo N 1

En este primer caso, vemos que el encendido opera únicamente a través del botón de encendido (Power). Esto implica que cualquier operación inicial con el sistema deberá ser precedida del uso de este botón. Cabe destacar que el botón de encendido ha sido diferenciado de los demás por una textura particular (tres puntos en relieve).

El equipo se enciende entonces en su modo anterior, el último que fue usado antes de ser apagado. Existe un botón único (Function) que permite cambiar el sistema de un modo a otro en un ciclo. Esto implica presionar el botón Function tres veces para pasar del modo Disc al modo FM.

Un análisis más exhaustivo de la interfaz nos revela que su distribución simétrica obedece más a criterios estéticos que de operación. Pero en esta instancia, nos centraremos exclusivamente en los comandos antes mencionados.

Equipo N 2

Nuestro segundo equipo también cuenta con el tradicional botón de encendido y apagado al que nos hemos acostumbrado (Power), pero además combina las dos funciones en cuestión al permitir su encendido a través de cualquiera de los cuatro botones de modo (o función). Esto implica una mayor flexibilidad de decisión para los usuarios, permitiendo eliminar un paso en su tarea; un usuario puede encender el sistema directamente en modo CD con sólo presionar el botón CD una vez.

La presentación de los modos de operación en cuatro botones paralelos e independientes, también otorga una mayor libertad de acción al usuario ya que no obliga a recorrer un ciclo para pasar de un modo al otro, como en el caso anterior en el que todo esto se hacía mediante un solo botón.

Al revisar la interfaz general, también se puede destacar que las dos funcionalidades analizadas se ubican en una posición predominante del tablero y se agrupan de manera lógica.

Este breve análisis nos da cuenta de cómo el enfoque o criterio utilizado durante el proceso de diseño afectará la experiencia del usuario. Las funcionalidades revisadas dan cuenta de dos procesos de diseño diferentes que dieron distinto grado de importancia a las necesidades de los usuarios.

Habiendo sido dueño y usuario de ambos sistemas por más de dos años, puedo dar testimonio personal a favor del segundo equipo de sonido. Estas pequeñas diferencias, sumadas a un diseño general más amigable, hacían del uso de este segundo sistema una experiencia considerablemente mejor que la del otro diseño.

Los santiaguinos de ojo inquisitivo se habrán dado cuenta que ambas fotos fueron tomadas sintonizando a Radio Concierto ¿qué esperaban? ;)

Un ejemplo Web

Hace algunos años, una tienda chilena de comercio electrónico presentaba la siguiente interfaz de búsqueda:

La interacción de este sistema está obligando al usuario a seleccionar al menos dos de sus opciones para poder realizar la búsqueda.

No permite hacer una búsqueda que cubra todos los precios, todas las marcas y todos los departamentos en la tienda. ¿Por qué no? ¿Será malo para el negocio dejar a sus clientes buscar en su base completa de productos?

Este caso nos permite ver cómo la interacción afecta la experiencia de usuario. En este caso, interrumpiendo el flujo de búsqueda por una restricción arbitraria del sistema.

Esto implica que durante este proceso de diseño particular, decisiones de negocio y limitaciones técnicas primaron por sobre la experiencia de usuario.

Jugando al diseñador

Para seguir haciendo más tangible estos conceptos tan abstractos, te invito a hacer un ejercicio:

Estamos trabajando en el diseño de un reloj despertador. Nuestro reloj será un dispositivo simple, sin funcionalidades complementarias, todo lo que necesita efectuar un usuario con el aparato es:

  • Leer la hora.
  • Configurar la hora actual.
  • En caso de optar por un despliegue digital, se debe seleccionar el modo de despliegue: 24 horas, o ciclos de 12 horas AM y PM.
  • Configurar la hora del despertador.
  • Encender y apagar el despertador.
  • Apagar la alarma.

Entonces, tú como diseñador deberás determinar las secuencias de acciones que permiten operar estas diferentes acciones, la cantidad, forma y tamaño relativo de los botones, palancas, selectores o perillas que permitirán elegir dichas funciones. Deberás definir los íconos o textos que permitirán al usuario comprender la utilidad de cada uno de estos elementos, así como las señales del sistema que dan a entender su modo actual de operación.

Metodología de diseño de interacción

El diseño de interacción comienza durante las etapas estratégicas del diseño, con la definición de requerimientos y funcionalidades, elementos claves que dan forma a la estrategia del sistema. Al hablar de diseño estratégico nos referimos a decisiones de negocios que permiten elegir una estrategia a tomar con un producto: estrategias de diferenciación de la competencia, audiencia primaria a enfocar el producto. El diseño de un producto tecnológico es un proceso complejo con múltiples dimensiones, estas decisiones estratégicas dan forma al producto, aunque muchas veces se las considere fuera del proceso de diseño.

Para crear un diseño amigable es fundamental entender a las personas que usarán el sistema, por esto parte importante de este trabajo consiste en entrevistar personas que representen al tipo de usuario final del sistema. Empaparse del modo de pensar, las necesidades y el lenguaje de los usuarios permitirá al diseñador estar en mejor pie para anticipar sus expectativas y reacciones, generando una interacción natural para ellos.

Alan Cooper, uno de los principales impulsores del método de diseño mediante personas y escenarios, explica que los ingenieros corresponden a un tipo distinto de humano – homo lógicus – que tiene una fuerte inclinación a la racionalidad. Esta racionalidad los inclina a aceptar todas las situaciones posibles al momento de diseñar un sistema, mientras que un diseñador dedicado – homo sapiens – que ha estudiado a sus usuarios, podrá enfocar el diseño en lo más probable. Este enfoque lleva a desarrollar una menor cantidad de funcionalidades, lo que implica que cada una de éstas podrá ser diseñada con mayor cuidado.

La principal ventaja del método de diseño con personas es que ayuda al equipo a enfocar sus energías en las necesidades de los personajes que se han definido. Al no definir claramente para quién estamos diseñando, cualquier característica y capricho que se pueda imaginar de los usuarios es creíble.

Existe una variedad de enfoques y métodos para guiar este proceso, algunos más formales, otros más flexibles. Algunos de estos modelos presentan un enfoque basado en la ingeniería, otros son más antropológicos.

Interacción en Web

En el caso de la Web (HTML), la interfaz se limita al trabajo con una plataforma restringida a páginas y con un número restringido de opciones para el input humano en la interacción:

  • Links
  • Formularios
    • Líneas o cajas de texto
    • Botones
    • Menús pull-down
    • Radio buttons
    • Checkboxes

Una interfaz restringida a páginas significa que cada paso que da el sistema en la interacción requiere del cambio de la página completa. Esta restricción ha permitido a los diseñadores plasmar la actividad de sus sistemas en diagramas de página o Wireframes.

Aplicaciones Ricas de Internet

Las limitaciones interactivas del lenguaje propio de la Web han representado tanto una ventaja como una desventaja para quienes diseñan interacción para este medio. La ventaja es que utilizan un lenguaje estandarizado que permite a los usuarios entender inmediatamente las posibilidades interactivas de cada elemento. La desventaja para los diseñadores es que pone límites muy restringidos a las posibilidades de interacción del sistema y encasilla su creatividad.

Los diseñadores han intentado desde los comienzos de la Web romper con las limitaciones del HTML y crear interfaces más flexibles. Sin embargo, estas interfaces de flexibilidad interactiva mayor no han podido ser estandarizadas en un 100%, y parte importante de éstas implican alguna tecnología propietaria ó plugins (javascript, flash, java, Ajax). Estas aplicaciones ricas permiten implementar funcionalidades web con una interacción más flexible, similar a las aplicaciones desktop. Bajo estos sistemas, la metáfora de la página se diluye, y los Wireframes se hacen insuficientes para documentar los diseños.

Para profundizar en el tema, pueden revisar:

1 - Ray Kurzweil, quien lleva más de 30 años estudiando sistemas de Inteligencia Artificial, afirma que los computadores alcanzarán y superarán de manera inevitable la inteligencia humana por el año 2030. Entonces podrán comenzar a diseñar nuevos sistemas más inteligentes que ellos mismos. Kurzweil plantea esto en su libro The Age of Spiritual Machines, la base teórica se puede encontrar en Internet en su “Law of Accelerating Returns”. (Volver al texto)

Nota de la Edición: Este artículo fue escrito originalmente el año 2004 para el sitio web de AIChile.org. Dado que nunca fue publicado en dicho sitio, ahora lo rescatamos de los archivos para publicarlo en mantruc.com



Fuente: http://mantruc.com/publicaciones/diseno-interaccion.html

De PSD a HTML/CSS - Maquetación

Nettuts en mi opinión es uno de los mejores portales sobre tutoriales de desarrollo web. Excelente todo lo que postean.
Muy interesante este:
http://nettuts.com/site-builds/from-psd-to-html-building-a-set-of-website-designs-step-by-step/

Mega post de Vectores, Brushes, Patterns, Photoshop

Creo que debe descargarse este espectacular post.

http://www.taringa.net/posts/downloads/1153152/Mega-post-de-Vectores,-Brushes,-Patterns,-Photoshop-II.html

LavaLamp for jQuery lovers!

Creo que no hay que perder este enlace. Fantastico tutorial sobre LavaLamp una extensión para jQuery. Realización de un menú dinámico:

http://www.gmarwaha.com/blog/2007/08/

Video seminario sobre PHP

Esta vez espectacular los videos sobre PHP de Luis Almeida. Me encanta los consejos que da y de la forma que lo dice.
Desde aqui podeis acceder a estos videos:
http://www.dominaphp.com/seminario.php

Merece la pena subirlos a otro sitio, cosa que haré en breve para que no se pierda esta reliquia y como más fuentes haya mejor.

Mejores libros sobre desarrollo web

Aqui tienes una selección de los mejores libros sobre desarrollo web que la comunidad NetTuts ha elegido:
http://nettuts.com/web-roundups/the-best-web-development-books-as-voted-by-you/

Metodología para el desarrollo de aplicaciones orientadas a objetos - Franco Díaz



La programación orientada a objetos requiere un profundo conocimiento y unas bases sólidas. Sí, puedes programar con orientación a objetos sin tener esos undamentos bien consolidados, pero tu curva de aprendizaje será mucho más lenta y no entenderás porque se hacen ciertas cosas.
Recomiendo la lectra de este libro:

Metodología para el desarrollo de aplicaciones orientadas a objetos - Franco Díaz

Te lo puedes descargar aqui:
http://rapidshare.com/files/114461334/poo.rar

9.29.2008

Tecnicas para crear wallpapers espectaculares

Para los amantes de photoshop. La red está plagada de cosas y nadie va a venir a la mesita de tu ordenador a decirte hay esto y ta otro en internet que te puede interesar. Aunque ya vendrá eso...
He encontrado un ebook espectacular que por el momento no he sabido descargar. Se trata de un libro sobre la creación de formas raras con photoshop.
Si no sabes como crear esas formas que muchas veces ves en wallpapers y estas intigrado en hacerlo aqui tienes este pequeño pero interesantisimo ebook:
http://issuu.com/nytryk/docs/photoshop/5?mode=embed&documentId=080917090730-52ff955785014a888c7ef9853a911d16&layout=grey

Y hablando de wallpapers recmiendo mirar el software Ultra Fractal para realizar formas estramóticas y de enorme belleza.

** No hace falta ni mencionar que estas dos tecnicas las podemos aplicar en multitud de otras cosas que no san wallpapers. Comopor ejemlo de fondo de nuestro sitio web, del header de nuestro sitio web, etc...

Funciones anónimas y autoejecutables en javascript

¿Sabías que en javascript una función puede contener a otras? Pues ahora ya lo sabes. Fíjate en el siguiente código:
function barrioSesamo() {
function epi() {
alert('hola Blas');
}

function blas() {
alert('hola Epi');
}

epi();
blas();
}

barrioSesamo();
// el navegador nos presentará un par
// de alertas, a saber, "hola Blas" y
// "hola Epi"

Nada impresionante, por el momento. Lo interesante del asunto es que, al definir la función epi dentro de la función barrioSesamo, el ámbito de la misma (scope) queda limitado, de manera que solo podemos llamar a epi desde su propio barrio.

Vale, sigo sin impresionarte. ¿Qué ganamos al definir funciones de esta manera? Al limitar el ámbito de la función, evitamos colisiones con (posibles) funciones del mismo nombre (posiblemente) definidas en otro(s) script(s).

Veamos ahora eso de las funciones anónimas:
function() {
alert('soy la función sin nombre');
}

Queda claro: una función anónima es… efectivamente, una función que no tiene nombre. Y si no tiene nombre, ¿cómo demonios hacemos una llamada a la misma? Truco: haciendo que se ejecute por su cuenta.
(
function() {
alert('me ejecuto yo solita');
}
)();

Fíjate bien en la sintaxis: la función va definida entre un par de paréntesis, a continuación de los cuales viene otro par, que utilizamos para ejecutar la llamada.

¿Aún impasible? Eres duro, tío. Quizá la traca final consiga impresionarte:
(
function() {
function hazCosasMaravillosasConElDOM() {
// lo que fuere
}

//addEvent() by John Resig
function addEvent( obj, type, fn ){
if (obj.addEventListener){
obj.addEventListener( type, fn, false );
}
else if (obj.attachEvent){
obj["e"+type+fn] = fn;
obj[type+fn] = function(){ obj["e"+type+fn]( window.event ); }
obj.attachEvent( "on"+type, obj[type+fn] );
}
}

// la función comienza a ejecutarse
// en la próxima línea
addEvent(window, 'load', hazCosasMaravillosasConElDOM);
}
)();

¿Lo pillas? Ahora tenemos un script completamente encapsulado, que se ejecuta él solito y que jamás de los jamases colisionará con otros scripts con los que le toque convivir.

El colmo de la no intrusividad.

Fuente:
http://dizque.lacalabaza.net/sotanos/2006/05/funciones-anonimas-y-autoejecutables-en-javascript/

Readernaut

Readernaut es parecido a una red social sobre libros de todo tipo, en la que puedes consultar opiniones de otros usuarios para así si finalmente decides que vale la pena comprar ese libro te redirige a Amazón.
http://readernaut.com

Cache Buster - Refresco para maquetadores CSS

Todos los que maquetamos tenemos este problema. Firefox guarda en cache el CSS y no nos muestra el que acabamos de editar. Una solución es utilizar el FIREBUG o WEB DEVELOPMENT, pero para cuando no lo usuamos porque no nos va bien, aqui tenemos este script de JavaScript.
javascript:(function(){var%20s,i,x;x=document.getElementsByTagName('link');for(i=0;i

Este es el link:
Cache Buster
Guardalo como un link normal en tus favoritos del navegador para tener a mano y poder apretarlo cada vez que quieras refrescar correctamente tu pagina.

Web oficial del Script:
http://www.jasongraphix.com/archive/2007/08/css_cachebuster

Scripts RSS

Muchos paquetes de scripts orientado a recoger RSS. Muy bueno.
http://www.feedforall.com/download.htm

825 links para desarrolladores

recopilación de más de 825 links para desarrolladores y diseñadores:
http://3kolone.org/bookmarks.php

9.21.2008

Cuando lo gráfico nos distrae: el dilema de diseñar interfaces

Hace unos días fuimos el equipo de diseño interacción a presentar un proyecto final con nuestro cliente. Era una propuesta de arquitectura de información y diseño de interfaces touchscreen. En esta presentación nos encontramos con el equipo de diseño gráfico y desarrollo quienes al observar que nuestra propuesta no presentaba (o no pretendía recomendar) iconos o imágenes que acompañaran la navegación, hizo que se generara cierta polémica.

Por acá les comparto algunas recomendaciones que creo se deben tomar en cuenta cuando diseñamos interfaces para medios no tradicionales.

Para empezar…

En nuestra investigación de usuario detectamos que el uso de nuestra interfaz se dirigía a gente que sabía leer y que tenía poco apego a la tecnología. Es decir, podían leer instrucciones sencillas y habían usado alguna computadora para tareas básicas (pero siempre con la ayuda de algún familiar o amigo). Sin embargo pese a esos hallazgos el equipo de diseño de nuestro cliente pedía que la interfaz pudiera ser entendida por gente analfabeta (primer error) y que utilizara un teclado en pantalla estándar (ejemplo: QWERTY) para introducir datos (segundo error). Lo cual sonaría lógico de primera impresión, pero tras hacer pruebas con usuarios reales solo haría que nuestra interfaz fracasara tanto para el público deseado como para el usuario real.

Al final me dio la impresión que el equipo de diseño, antes de crear nuevos lineamientos para este tipo de interfaces en su manual de identidad corporativa, hará cambios a nuestra propuesta (tercer error).

Por estas razones recomendaría lo siguiente a todos los equipos de diseño y desarrollo interesados por mantener estándares gráficos y efectivos en todos sus medios o canales de comunicación:

Observa a tus usuarios finales






Ahórrense horas y horas de discusión hipotética entre diseñadores, creativos, directivos, etc. Mejor aprovechen ese tiempo para observar e interactuar con sus usuarios finales, ellos les dirán lo que necesitan. Y ustedes les facilitarán el medio y la tecnología.

Evita decorar interfaces





Es cierto que las imágenes, iconos e ilustraciones son de mucha ayuda para comunicar mensajes, pero empieza por lo básico: jerarquía de información, depuración de datos, diagramas de flujo, estructuración de contenidos, redacción de textos. A muchos no les gustan esas fases del proceso, pero eso también es diseñar. De hecho esto no sólo aplica para cuestiones de diseño de interfaces sino a cualquier proceso de diseño.

Contextualiza





Siempre ubica tu solución de diseño en su contexto o entorno real, no solo en tu computadora, en tu despacho o en la oficina del cliente. Igualmente contextualizar está ligado a comparar tu solución con productos con atributos semejantes; no es lo mismo diseñar iconos para las terminales del metro (un medio de transporte), que iconos para interfaces touchscreen.

Los manuales de identidad deben estar en constante cambio





Tal vez el manual de identidad de tu empresa nunca contempló que la internet nacería y mucho menos que las interfaces touchscreen serían utilizadas dentro de los canales de comunicación con sus clientes o usuarios. Si la empresa en la que trabajas usa esas tecnologías, no dejes que los lineamientos de diseño editorial rijan esos canales, si eso llega pasar, el fracaso será evidente y adivina a quién le echarán la culpa.

No diseñes para todo el mundo






Diseña para tus usuarios finales reales. Hacer que nuestro diseño pueda ser usado y entendido por TODOS no siempre es el mejor camino, pero si un camino rápido para que tu interfaz fracase.

Estos son algunos puntos que me vinieron a la mente que debemos tomar en cuanta para el diseño de interfaces efectivas. Muy generales porque tampoco pretendo hacer toda una lista de criterios, al mero estilo de evaluación heurística, pero creo que antes de seguir lineamientos de usabilidad, se debe comprender el por qué se hacen las cosas y con qué finalidad.


Fuente: http://alquimistas.evilnolo.com/2008/08/11/el-dilema-de-disenar-interfaces/#more-484

9.10.2008

Guía para iniciar un proyecto

Fuente del artículo: http://perlenespanol.baboonsoftware.com/articulos/archivo/000102.html

Estaba sentado frente a mi laptop pensando en que escribir, y aunque no lo crean hay veces que no se me ocurre nada. Sin embargo por alguna extraña razón mi mente empezó a recordar todos aquellos proyectos que empece y como ha evolucionado la manera en que los hago, todo esto me dió la idea de hacer un tutorial donde les mostraría más o menos la técnica que uso para crear un proyecto.

Hay diversas razones por las cuales uno decide iniciar un proyecto, ya sea por un trabajo, una tarea, o simplemente porque uno esta aburrido y quiere investigar lo que es capaz de hacer. Pero no importa cualquiera de estos casos siempre tenemos que seguir un lineamiento, unas reglas o formato sea cual sea con el cual plantearemos lo que queremos hacer.

Después de años de trabajar he llegado a usar un sistema que me sirve muchisimo y con el cual se me es más fácil trabajar y a continuación se los muestro ya separado por pasos.

PASO 1 : Ideando lo Ideal

Aunque parezca tonto o incluso rídiculo el primer paso es...tambores por favor...SABER LO QUE QUEREMOS HACER (por favor disculpen mi poco sentido del humor).

No se rían pero es cierto, dejen les éxplico un poco, al inicio de mi vida como programador me encontraba escribiendo código y a las 1000 lineas de código me decía, ¿qué es lo que hago? ¿por qué no mejor hago esto o tal cosa?, era una lamentable pérdida de tiempo, y todo eso porque no medite un poco y pense en lo que quería hacer.

Es por ello que les digo que el primer y muy importante paso, es idear lo que queremos, yo hago eso respondiendo preguntas como ¿qué? ¿por qué? ¿cómo? ¿para qué?, etc.

Como soy un amante de los ejemplos para este artículo vamos a suponer que una compañía de seguros nos contrata para hacer un CGI en línea que saque presupuestos del costo de los seguros siguiendo una serie de preguntas que se les haría a los clientes. Sabiendo esto ya tenemos las primeras respuestas de ¿qué? y ¿para qué?, estamos en un bueno comienzo y nos lleva al segundo paso que es decidir que es lo que vamos a usar.

PASO 2 : Herramientas

En el paso anterior ya vimos el planteamiento inicial del problema, ahora es necesario ver que herramientas necesitamos para solucionarlo y si somos capaces de hacerlo o si necesitaríamos aprender algo nuevo.

NOTA: Algo importante que he aprendido es siempre conocer bien tus límites, nunca te metas en proyectos que al final podrías acabar no haciendo, o peor, haciendo mal.

En este caso hagamos la lista de cosas que tendríamos que saber y que utilizaríamos.

HTML Debido a que quieren hacer un CGI es necesario que sepamos HTML para el diseño. Javascript Quizá lo necesitemos para checar formas, etc. MySQL,Oracle,Postgres Vamos a necesitar un database para ordenar todo los datos. (Costos, tipos de seguros,etc). Perl Por supuesto que debemos de conocer nuestro lenguaje de programación sea cual fuere el que queremos usar. DBI Debemos de saber como comunicarnos a nuestro database, en el caso que usemos perl ó C++.

Pues listo, ya tenemos nuestra lista de conocimientos necesarios para encaminarnos a nuestro proyecto, y sabemos que cumplimos con todas las necesidades.

NOTA: Para proyectos más complejos es necesario hacer una lista de conocimientos del propio lenguaje de programación.

Bien ya tenemos nuestra siguiente pregunta respondida ¿cómo?, ahora pasaremos al siguiente paso.

PASO 3 : Estructura

Muy bien ya que tenemos todo lo anterior anotado ahora veamos lo que sería la estructura ya más formada de nuestro proyecto, es decir es hora de escribir todas las funciones que tendrá nuestro proyecto, por ejemplo para este caso sería algo así:

  1. Capacidad de checar presupuesto de seguros
  2. Mecanismo de búsqueda
  3. ... etc
Así vamos llenando la lista con todas las cosas que queremos que nuestro programa haga, yo recomiendo que en este paso piensen realmente en todas las opciones, para que al estar en medio del proyecto no salga algo que se les haya olvidado.

PASO 4 : Interface

Siempre después de tener ya muy en claro lo que quiero lograr con el proyecto, lo primero que hago es la interface, y esto lo hago debido a dos razones:

1. Te permite definir mucho más la estructura general del proyecto debido a que tienes que hacer los menús, cada una de las páginas, ya sean formas, mensajes de error, etc. Simplemente te hace pensar en todas las posibilidades.

2. Al tener la interface lista tienes mucho más definido el orden en que tienes que ir haciendo el programa.

A parte de todo esto, lo que hace la diferencia entre un buen CGI y uno malo fácil en un 70% es la interface, pues esto va a marcar si va a servir para el usuario y si es cómodo y sencillo usar tu CGI, recuerda en pensar siempre en tus usuarios al hacer tu CGI, especialmente cuando haces CGIs que usarían personas que no estan acostumbradas al internet o a las computadoras en si.

PASO 5 : Estilo de programación

Antes de inciar a hacer el código tienes que hacer un especie de contrato contigo mismo para decidir de que manera vas a escribir tu código. Este paso es realmente importante pues va a marcar la diferencia entre un código fácil de mantener y entender a uno que no lo es.

Lo primero que debes de decidir es si tu aplicación la vas a hacer modular o en un gran archivo, para que me haga a entender mejor: el modular es cuando separas las funciones en pequeños módulos para así hacer una librería, por ejemplo en este caso podríamos hacer un módulo llamado "Matematicas.pm" que tendría todas las funciones relacionadas a operaciones matemáticas; en el otro caso pones todas las funciones un un archivo grande exceptuando, como es lógico, a módulos de perl ya existentes.

Mi recomendación en este caso depende del caso: si va a ser un código de muchas líneas, digamos más de 3 ó 4 mil, lo más seguro es que quieras separarlo en módulos lo que lo haría más fácil de mantener, aparte de que así recordarías mejor cada función.

En segundo lugar antes de iniciar es importante que decidas de que manera vas a escribir tus variables, hay varias maneras de hacerlo y aquí pongo unos ejemplos:

my $costoTotal; #Todo junto con cada palabra separada por una mayúscula
my $CostoTotal; #Mismo que arriba pero iniciando con mayúscula
my $costo_total; #Palabras separadas por _
my $Costo_Total; #Igual que el de arriba pero con mayúsculas

Estos son apenas unos ejemplos, pero no importando el estilo es sumamente importante que te mantengas a él para tener un código mas limpio. También es sumamente importante que el nombre de las variables sea descriptivo del contenido que tienen.

En tercer lugar siempre que nombres tus funciones dales un nombre que al verlo te haga entender lo que hace esa función. Funciones llamadas suma, resta, despliegue, etc. evítalas, mejor decide por suma_intereses, resta_operaciones, despligue_encabezado_html, etc.

En cuarto lugar siempre usa el pragma strict al hacer tus programas.

Quinto: Nunca olvides usar la función exit() para salir del programa.

Y por último siempre pon comentarios en todas partes, estos te servirán como guías cuando 1 año después veas tu código nuevamente.

Sigue todos estos puntos y tu código quedará sumamente limpio y muy fácil de mantener inclusive por terceras personas.

PASO 6 : Las Pruebas

Al terminar tu código recuerda siempre hacer pruebas, lanza tu programa en versión BETA y pide a varias personas que lo exploren, que intenten que falle, has la lista de cosas que fallaron corrígelas y vuelve a hacer el proceso, has esto hasta que ya no encuentres un error.

Nunca va a quedar tu aplicación perfecta e inmune de errores, pero intenta que haya el mínimo de errores posibles.

PASO 7 : El Soporte

Quizá sea buena práctica que hagas módulos de ayuda para tus aplicaciones, explicando como funciona, que es lo que uno tiene que hacer, etc. Aunque esto no afecta la aplicación en sí, podrías empezar a acostumbrarte a ello, creéme mucha gente lo apreciará.

CONCLUSIÓN

Les aseguro que podría haber mejores maneras de diseñar tu proyecto, pero estos pasos me han ayudado en la creación de proyectos, pequeños, medianos y de gran escala, pero de lo que no hay duda es que para hacer un buen proyecto necesitas planeación, planeación y más planeación.

Espero que esta artículo les ayude a mejorar sus costumbres de programación y los lleve a hacer aplicacines mas robustas y mejores.


Fuente del artículo: http://perlenespanol.baboonsoftware.com/articulos/archivo/000102.html

mod_rewrite: Guía Básica para reescribir URLs

Fuente del artículo: http://perlenespanol.baboonsoftware.com/articulos/archivo/000180.html


Hoy en día la posición en los buscadores es un factor importante en el éxito de un sitio web. También se sabe que a los buscadores no le atraen mucho los sitios dinámicos, es decir, aquellos que cambian su contenido dependiendo de diversos factores.

Por ejemplo, mi foro de Perl en Español está en PHP por lo que los urls para navegar el foro son parecidos a esto:

http://perlenespanol.baboonsoftware.com/foro/viewforum.php?f=3

Y aunque los bots de los buscadores lo pueden leer e indexar en su base de datos, si ponen un penalti por ser un url dinámico. Para solucionar esto, si eres un visitante o un robot, el url que verás será:

http://perlenespanol.baboonsoftware.com/foro/forum-3.html

Si pruebas ambos urls verás que muestra el mismo contenido. Podrás pensar que son dos páginas distintas, pero no es así, el segundo url, el que simula una página estática, es convertido detrás de las cortinas para llamar a la página real. Así es, en mi servidor no existe un archivo forum-3.html.

En este artículo les voy a mostrar como lograr esto.


Una solución elegante

Quizá estarán pensando que todo esto es un producto de magia, pero realmente es bastante sencillo lograrlo y los resultados serán muy buenos, pues no solamente podrán dar urls estáticos a los buscadores mejorando su posición, sino que también podrán dar urls amigables a sus usuarios.

Para poder lograr esto es necesario tener lo siguiente:

  • Un servidor Apache versión 1.2 o mejor.
  • Acceso para editar los archivos de configuración .htaccess, y quizá de ser necesario el http.conf.
Si están acostumbrados a usar servidores Apache, lo más seguro es que en algún momento hayan escuchado acerca del módulo mod_rewrite de Apache. Normalmente este módulo viene por default en las distribuciones de Apache pero en sistemas *nix puede que haya sido compilado sin este módulo.

Para poder usar este módulo primero lo tenemos que activar. En caso de que no tengas el módulo activado tendrás que editar tu archivo http.conf y quitar el comentario de la línea que carga el módulo para que quede de la siguiente manera:

#LoadModule rewrite_module
modules/mod_rewrite.so
#AddModule mod_rewrite.c


Comprendiendo mod_rewrite

Es importante comprender lo que hace exactamente este módulo.

El mod_rewrite se ejecuta después de hacer un request en tu servidor y antes de ejecutar cualquier script. Lo que hace es que aplica un "filtro" configurado por uno sobres los urls y los rescribe detrás de las cortinas.

Por ejemplo, podrías tener un url inexistente como el siguiente:

http://www.tusitio.com/algo

Y entonces el mod_rewrite lo podría convertir a:

http://www.tusitio.com/cgi-bin/dir/aplicacion.cgi?categoria=algo

La conversión del url se hace por detrás por lo que el usuario no podrá ver nada de esto, sin embargo si verá el resultado que viene de la ejecución del url "real".

Es importante comprender que mod_rewrite NO puede ser usado para cambiar el URL que el usuario ve es la barra de Dirección de su navegador a menos que una redirección externa es invocada. Sin embargo una dirección externa expone finalmente el url dinámico, así que mod_rewrite hace una redirección interna.

También es importante comprender que mod_rewrite cambia la dirección del archivo y las variables del url pedido pero NO cambia en ningún momento el despliegue de las mismas.


Poniendo mod_rewrite en práctica

Muy bien, empecemos con lo bueno, para esto vamos a hacer un ejemplo práctico.

Digamos que tienes una tienda de ropa y que tus clientes pueden ver la ropa que tienes navegando por categoría y talla de la misma. Para esto tienes una aplicación que se llama de la siguiente manera:

http://tusitio.com/cgi-bin/aplicacion_ropa.cgi?tipo=playeras&sexo=femenino&talla=chica

No es para nada bonito el url, por lo que queremos que nuestros clientes puedan acceder de la siguiente manera:

http://tusitio.com/playeras/femenino/chica.htm

Como ves es más intuitivo y amigable.

Usando mod_rewrite no es necesario hacer ningún cambio en tu aplicación, ni siquiera es necesario que crees los directorios 'playeras/' ni 'playeras/femenino', tampoco es necesario que hagas un archivo que se llame chica.htm.

Lo que vamos a hacer es que cuando algún usuario haga un request de 'http://tusitio.com/playeras/femenino/chica.htm' usaremos el mod_rewrite para filtrar y convertir el url a 'http://tusitio.com/cgi-bin/aplicacion_ropa.cgi?tipo=playeras&sexo=femenino&talla=chica', pero todo esto detrás de las cortinas, usando la redirección interna como habíamos dicho.

Ya que estemos seguros que tenemos el mod_rewrite instalado y activo, vamos a crear un nuevo archivo de configuración .htaccess.

Dentro de nuestro .htaccess vamos a inicializar el módulo mod_rewrite:

    RewriteEngine On
Ya que tenemos esto, tenemos que configurar las reglas o filtros que vamos a usar. Cada uno deberá de ir en una nueva línea y podemos tener tantos como nosotros queramos y necesitemos.

Entonces vamos a crear nuestro filtro que ser verá así:

    RewriteRule ^playeras/femenino/chica.htm cgi-bin/aplicacion_ropa.cgi?tipo=playeras&sexo=femenino&talla=chica [L,NC]
Comprendamos nuestra línea del filtro. El filtro está conformado por 4 elementos, cada uno separado por un espacio en blanco.

El primer elemento es:

    RewriteRule
Aquí indicamos que estamos creando una nueva regla o filtro para la máquina de mod_rewrite. El segundo elemento es:
    ^playeras/femenino/chica.htm
En este caso es el url que estamos buscando. Es importante que tengamos en cuenta que siempre debemos de usar los directorio relativos, es decir, no debemos de poner el dominio de nuestro sitio, el mod_rewrite lo pondrá por nosotros.

La tercera parte es el nuevo url al cual queremos redirigir, también la dirección debe de estar relativa, mod_rewrite pondrá por nosotros el dominio de nuestro sitio.

    cgi-bin/aplicacion_ropa.cgi?tipo=playeras&sexo=femenino&talla=chica
NOTA: No podemos usar el mod_rewrite para hacer una redirección interna a un url que no se encuentre dentro de nuestro dominio.

La última parte es opcional y son flags que regulan el comportamiento del mod_rewrite.

    [L,NC]
En las siguientes secciones veremos más detalles acerca de los flags, pero podemos decir que con los flags L y NC le decimos al mod_rewrite que sea la última regla que cheque si coincide y que no haga caso a las minúsculas y mayúsculas.


Más poder a nuestro mod_rewrite

El ejemplo anterior es de gran ayuda, vimos como podemos convertir un url dinámico en estático en cuestión de minutos, pero hay un pequeño problema.

Lo más seguro es que nuestra tienda de ropa no venda puras playeras chicas, ni tampoco puras de mujer, y lo más seguro es que venda más productos que puras playeras, debe de haber pantalones, chamarras, shorts, camisas, vestidos, etc, etc.

Hacer una nueva regla por cada producto y por cada tamaño será un verdadero dolor de cabeza, y aparte cada ves que queramos poner una nueva línea de productos en la tienda tendremos que modificar nuestro .htaccess.

Pues bueno, con mod_rewrite podemos evitar eso, pues aún no hemos visto la parte más poderosa.

En el último ejemplo hicimos un filtro bastante sencillo:

    RewriteEngine On
RewriteRule ^playeras/femenino/chica.htm cgi-bin/aplicacion_ropa.cgi?tipo=playeras&sexo=femenino&talla=chica [L,NC]
Pero también quisiéramos que los siguientes urls lo redirija al lugar correcto:

http://tusitio.com/pantalones/masculino/32.htm
http://tusitio.com/vestidos/femenino/mediano.htm
http://tusitio.com/shorts/infantil/12.htm
...

Si vemos, todos los urls tiene una misma sintaxis, el primer directorio sería la línea de ropa (pantalones,vestidos,shorts,etc), el subdirectorio sería el departamento (masculino,femenino,infantil,etc) y el archivo html sería la talla (32.htm,mediano.html,12.htm).

mod_rewrite nos permite usar expresiones regulares dentro de nuestros filtros, de esta manera podemos realizar filtros más poderosos.

Las expresiones regulares nos brindan un set de reglas que podemos usar para comprobar valores arbitrarios como en este caso. Sabemos que el url vendrá en una misma sintaxis pero tendrá diferentes valores, usando las expresiones regulares podemos capturar y comprobar esos valores.

Veamos la expresión regular que usaríamos en este caso para hacer lo que queremos:

    ^([a-zA-Z]+)/([a-zA-Z]+)/([a-zA-Z0-9]+).htm$
Expliquemos un poco nuestra expresión.

El ^ incial denota inicio de línea, significa que solamente será válida la regla si se cumple iniciando la línea.

Los paréntesis ( ) los usamos para capturar el valor, en este caso así lo queremos pues después tendremos que usarlos para enviárselos a nuestro CGI de la aplicación.

Los [ ] los usamos para asignar un campo de caracteres. Los campos de caracteres los podemos usar cuando queremos checar que ciertos caracteres estén o no estén. En la primera parte que será de la línea de ropa, sabemos que solamente vendrán letras del alfabeto, por lo que solamente queremos de la a-z y de la A-Z, en minúsculas y mayúsculas. Lo mismo en la segunda parte, pero ya en la tercera parte si puede haber números por ejemplo en 32.htm, por lo que tenemos que poner también el 0-9.

El signo de + después del cierre del campo de carácter, significa que debe de haber por lo menos uno o más de los caracteres que queremos.

Luego tenemos la separación con las diagonales '/' que están fuera de los paréntesis pues queremos capturar solamente 'pantalones' y no 'pantalones/'.

Al final también dejamos el .htm fuera de los paréntesis pues no lo queremos usar, y terminamos con $ que simboliza final de línea.

Así ya tenemos nuestros valores capturados que ahora podremos usar en el url para llamar al CGI de nuestra aplicación:

    cgi-bin/aplicacion_ropa.cgi?tipo=$1&sexo=$2&talla=$3
Vemos como los valores los sustituimos por $1, $2, $3 que a su vez serán sustituidos por mod_rewrite con los valores que capturamos en nuestros paréntesis.

Cada paréntesis captura en una nueva variable y lo hacen en orden, así que van tomando $1, $2, $3, $4.. así hasta lo que se necesite.

Así que finalmente nuestra regla se verá de la siguiente manera:

    RewriteEngine On
RewriteRule ^([a-zA-Z]+)/([a-zA-Z]+)/([a-zA-Z0-9]+).htm$ cgi-bin/aplicacion_ropa.cgi?tipo=$1&sexo=$2&talla=$3 [L,NC]
Así si llamamos a los siguientes urls:

http://tusitio.com/pantalones/masculino/32.htm
http://tusitio.com/vestidos/femenino/mediano.htm
http://tusitio.com/shorts/infantil/12.htm

Serán redireccionados internamente a:

http://tusitio.com/cgi-bin/aplicacion_ropa.cgi?tipo=pantalones&sexo=masculino&talla=32
http://tusitio.com/cgi-bin/aplicacion_ropa.cgi?tipo=vestidos&sexo=femenino&talla=mediano
http://tusitio.com/cgi-bin/aplicacion_ropa.cgi?tipo=shorts&sexo=infantil&talla=12

Así de la nada, tenemos una lista infinita de páginas estáticas fáciles de navegar por nuestros usuarios.


Tomándole la medida a mod_rewrite

Usar mod_rewrite es sumamente sencillo, quizá lo más difícil podría ser aprender a usar las expresiones regulares y los flags que podemos usar para controlar el comportamiento del módulo.

Sin embargo ambas son muy intuitivas y con un poco de uso y de estar jugando y probando con ellas, les tomarás la práctica inmediatamente.

Dave Child hizo un PDF con un "acordeón" que enlista las expresiones regulares y flags que podemos usar en el mod_rewrite. Les recomiendo que descarguen el PDF con la lista y lo tengan a la mano en el momento de crear sus filtros:
http://www.ilovejackdaniels.com/mod_rewrite_cheat_sheet.pdf


Últimas Palabras

Cuando hagas tus primeras pruebas con el mod_rewrite, ten cuidado y si puedes has las pruebas con un servidor Apache que no esté en vivo, pues si tienes algún error de sintaxis al momento de crear tus filtros, verás un error 500 en todo tu sitio, evitando que tus usuarios puedan acceder a él.

En caso de que quieras convertir tu sitio de estático a dinámico pero no te atreves a hacerlo tu sólo, puedes usar nuestros Servicios de Perl en Español y nosotros lo haremos por ti:
http://perlenespanol.baboonsoftware.com/servicios/


Otros Recursos

Documentación de mod_rewrite
http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html

Introducción a las Expresiones Regulares
http://perlenespanol.baboonsoftware.com/tutoriales/expresiones_regulares/index.html

mod_rewrite Cheat Sheet
http://www.ilovejackdaniels.com/apache/mod_rewrite-cheat-sheet/


Fuente del artículo: http://perlenespanol.baboonsoftware.com/articulos/archivo/000180.html

Entrevista al creador de Menéame. Espectacular

Fuente del artículo: http://www.alzado.org/articulo.php?id_art=693


Casi nunca nadie había contado tanto sobre su propio proyecto. Un breve resumen inicial y la entrevista a continuación:

- Menéame corre sobre un solo servidor, a pesar de tener 65 millones de páginas vistas según Webalizer y puesto 1922 en Alexa.
- Menéame ingresa 4.000 dólares al mes en Adsense
- Los gastos actuales en servidores son 500 euros
- Ricardo Galli prefiere Adsense a otras propuestas publicitarias
- Cree que su éxito se debe a que el software fue desarrollado por ellos desde 0 y publicado como libre.
- Admitieron a Varsasky como inversor para cubrir costes y para sentirse más seguros (demandas, temas legales, etc.)
- Son sólo dos desarrolladores: Ricardo Galli y Benjamí Villoslada
- Inicialmente Varsasky tenía un 10% y ahora tiene un 33%
- Han recibido ofertas por la totalidad de Meneame por más de 6 millones de euros

Eduardo Manchón: ¿Cuanto dinero costó en su día poner en marcha a Menéame? ¿Cuáles son los costes actuales? ¿Han sido los costes un problema para Meneame?

Ricardo Galli: Los únicos gastos iniciales fueron los dominios y el alquiler de un servidor virtual (sobre Xen). El primer servidor nos costaba 40 dólares al mes, luego llegamos a ampliar hasta unos 80 dólares pero teníamos muchos problemas con el Xen, se colgaba con cargas altas. Así tuvimos que migrar a nuestro primer dedicado en ThePlanet. Nos costaba unos 150 dólares. Ahora estamos en Ferca desde hace casi un año.

Luego no gastamos nada más, salvo los gastos de notarios, abogados y asesoría cuando empezamos con la SL. La SL la creamos por dos motivos. En primer lugar por temas legales, sobre todo temas de la LOPD y la LSSI. Luego porque es la "menor" opción razonable para aceptar inversores externos. Como anécdota, el aporte de capital a la SL fueron los dominios, no pusimos dinero en efectivo.

Por los dos servidores en Ferca estamos pagando poco más de 500 euros con IVA incluido. Creo que el máximo de tráfico mensual de cada uno era de unos 2.5 Terabytes, pero seguro que estamos muy lejos de esos límites porque en casi todo es texto y además el servidor comprime el texto antes de enviarlo (si no estoy muy equivocado, cuando accedes por primera vez a la página principal te bajas en total sólo unos 30 KB, creo que es casi un Record 2.0 ;-)

Eduardo Manchón: En Menéame teneis Adsense, creo que es vuestro único modelo de negocio ¿Cubre gastos? ¿Permite tener beneficios?

Ricardo Galli: Actualmente ingresamos algo más de 4.000 dólares al mes por AdSense --y subiendo cada mes--, y unos pocos más por campañas en FeedBurner y otras que a veces contratan directamente.

Cubre gastos porque nos medimos mucho, sólo gastamos si lo podemos compensar.

Tuvimos muchas ofertas e incluso hicimos pruebas con otros sistemas publicitarios, pero siempre nos encontramos con que nos lleva mucho tiempo y nos piden poner anuncios más intrusivos de lo que consideramos razonable. Pero estamos en contacto con gente de publicidad para ver si ellos se pueden hacer cargo siempre y cuando al menos aseguren superar por bastante margen a los ingresos de AdSense y no sean más intrusivos.

Estamos convencidos que la publicidad dará muchísimo más que ahora. El AdSense y todas en general. Si en EEUU dicen que la parte de la tarta publicitaria es todavía pequeña respecto a otros medios, imagina aquí que estamos en órdenes de magnitud por debajo. De hecho si hubiese una proporción con sitios como Digg deberíamos estar facturando unos 4-5 millones de euros al año. Ahora recuerdo a ese blogger que había mostrado el talón de AdSense por un mes y eran casi 200.000 dólares, hace pocos días publicó una captura de pantalla de las estadísticas, y curiosamente las impresiones y "click ratio" eran muy similares a Menéame, sin embargo el eCPM y los totales mucho mayores, 25 veces más que nosotros. Eso sólo nos puede dar esperanzas :-) [*]

[*] Sí, nos damos cuenta de la diferencia temática de los sitios, uno es dedicado a ringtones y el nuestro demasiado generalista, aún así la diferencia es abismal.

Así que por ahora preferimos dedicar el tiempo a otras cosas y no molestar a los usuarios. Ya llegará el momento de mejorar considerablemente, por ahora no tenemos urgencia, nuestro "burning rate" es casi cero.

Eduardo Manchón: ¿Cuál es la infraestructura de Menéame en la actualidad?

Ricardo Galli: Ahora mismo todo se sirve desde un sólo servidor (un Dual Duo2). Tenemos otro servidor que lo usamos para réplica de base de datos, backups y aquellos procesos "off line" que requieren mucho CPU y disco. También está preparado para balancear la carga con el primero, o reemplazarlo inmediatamente, pero no lo llegamos a necesitarlo nunca.

Luego por supuesto lo que usamos en casa y la "conectividad total" que tenemos Benjamí y yo. Vamos a todos lados con portátiles y conexión 3G (con Vodafone), nos es imprescindible.

Eduardo Manchón: ¿Cuál ha sido el principal problema/s que habeis tenido en la vida del proyecto? ¿Cómo lo habeis resuelto?

Ricardo Galli: Cuando teníamos muchos problemas con el Xen y no podíamos encontrar qué era. Lo que ingresaba de AdSense alcanzaba justo para pagar un dedicado, tampoco sabíamos si el Menéame iba a crecer más o morir en poco tiempo. Parece una tontería, pero nos costó mucho "arriesgar" poco más de 100 euros al mes para empezar en "serio". Por eso digo que no somos "emprendedores", visto en perspectiva fue una auténtica tontería dudar tanto... incluso no haber comenzado con un dedicado desde el día 0.

Personalmente también lo pasé muy mal cuando nos acusaban de censurar o manipular votos, y aunque dediqué muchísimo tiempo a explicar parecía caer en saco roto. Ahora ya me acostumbré, pero sentía un estrés y sobre todo una soledad increíble, como si el mundo se estuviese viniendo abajo y nadie nos ayudara (aunque no era verdad). Visto en perspectiva, otra tontería que supongo les pasa a todos los que empiezan proyectos y se hacen más o menos populares.

También lo pasé bastante estresado con temas de bugs de seguridad del software, no soy experto en el tema y nunca había hecho un programa que haya sido usado por tanta gente, ni tan popular. Es estresante, por suerte al ser libre recibí bastantes "parches" para los problemas de seguridad, especialmente de Alex Concha, lo que evitó que hubiese habido problemas más graves. Ahora puedo decir casi con orgullo que desde hace bastantes meses es "rock solid" (seguramente alguien después de leer esto nos avisará de algún bug grave, no falla :-)

Eduardo Manchón:: ¿Podrías detallar los problemas de escalabilidad que habeis tenido?

Ricardo Galli: Respecto al tema de escalibilidad, un sistema como el Menéame o Digg es bastante especial. Su cuello de botella fundamental está en las consultas a la base de datos, y luego la compilación y ejecución de código. Si la base de datos está mal diseñada o no tiene los índices adecuados el sistema directamente no funcionará porque se sobrecargará y prácticamente petará en cuanto se haga una consulta "pesada".

Al principio en el Menéame no teníamos todas las consultas bien optimizadas. En nuestros ordenadores de casa funcionaban muy bien --la base de datos todavía era relativamente pequeña-- pero en cuanto estaban en Xen y con muchas consultas concurrentes generaban mucho entrada salida a disco y creación de muchos procesos de Apache. Eso hacía que nuestro servidor en Xen tuviese muchos problemas (demasiado tiempo de hilos del kernel bloqueados por E/S) llegando incluso a colgarse nuestro núcleo huesped. Luego vimos que había más gente teniendo problemas en situaciones de carga muy alta --dicen que ahora están solucionados--, así que decidimos pasarnos a un dedicado. Allí se acabaron todos los problemas de este tipo.

Respecto a la escalibilidad en general, mi "hobby" como programador es hacer código más eficiente --de allí el WP-Cache por ejemlo--, paso mucho tiempo analizando el código y las consultas. Quizás si no hubiese sido tan cuidadoso hubiésemos necesitado más de cinco servidores para soportar la carga actual.

El hecho que exigir que sea tan eficiente nos limita en gran medida qué nuevas funcionalidad agregar, incluso que no podamos usar capas de abstracción --como plantillas-- pero por otro lado nos quita los problemas de escalabilidad y sus costes y problemas relacionados (además de darme diversión :-).

Hay gente que opina que el tiempo de programador es mucho más caro que agregar servidores. Sin embargo no todo es tan lineal, escalar agregando servidores aumenta la complejidad del sistema, haciendo que la administración también sea más compleja y fundamentalmente agregando posibilidades de fallos o "latencias" que luego son más difíciles de solucionar.

Soy fanático del KISS (Keep It Simple Stupid), y creo que sí debería invertirse tiempo en tener una arquitectura y código muy eficiente y simple sobre todo para proyectos de "redes sociales". A la larga se ven los beneficios, sobre todo si estás empezando una empresa como la nuestra y tus recursos son muy limitados a la vez que necesitas crecer desesperadamente.

Eduardo Manchón: En su momento hubo varios proyectos similares a Menéame, pero pocos han triunfado. Incluso en Francia o Alemania no hay equivalentes de Menéame al mismo nivel de éxito. ¿Cuál piensas que ha sido la razón distintiva del éxito de Menéame? ¿Qué habeis hecho que no hayan hecho proyectos similares?

Ricardo Galli: Puf... difícil, no sé si lo sé. Pero intentaré destilar algo.

Creo que el hecho de que el software sea desarrollado por nosotros desde cero y publicado como libre es quizás lo más importante. Nos dio lo que se conoce como "principio de autoridad". También fue importante para contrarrestar acusaciones o conspiranoias habituales, es como decir: "allí está el código que hace todo, seguro tiene errores y no es justo, pero no son intencionales ni apuntando a nadie en particular". Más o menos como el algoritmo de PR de Google, comete grandes cagadas y a veces sus cambios perjudican económicamente a mucha gente, pero está muy bien eso de echarle al algoritmo, no te puede demandar ni responder en su blog :-)

Luego creo que influyó mucho que no nos lo tomamos demasiado en serio de cara al exterior --aunque sí lo tomamos muy en serio de puertas para adentro, como si nos fuese la vida en ello--, el nombre provocador, la mascota que parece un peluche, el estilo más blanco y con fuentes más grandes, intentar ser honestos y respetar el voto de los demás aunque no nos haya gustado nada, reconocer a veces públicamente los grandes errores... supongo que eso en conjunto de una personalidad bastante importante al proyecto.

También creo que ayudó bastante que Benjamí y yo somos bloggers desde hace tiempo y hemos participado en varias comunidades y listas de correos. Todavía cometemos errores, pero eso nos ayudó en que no volvamos a cometer una infinidad de errores graves que se cometen cuando interactúas con mucha gente y no tienes demasiado experiencia --por ejemplo de tomarte demasiado en serio a tí mismo o tu proyecto--.

Eduardo Manchón: Principio de autoridad... ¿no es algo demasiado abstracto? ¿no será que crear la tecnología desde 0 os dio un dominio y conocimientos absolutos sobre la tecnología usada imprescindibles para el éxito?.

Ricardo Galli: Lo que dices es parte de ese principio de autoridad. Si tú has desarrollado todo el software desde cero, funciona en la realidad, mucha gente lo usa, y además lo liberas como mínimo signfica que:

1. Dominas la tecnología,

2. sabes cómo adaptarla a esa "realidad",

3. está adaptada a sus usuarios,

4. y además no tienes problemas o vergüenza en mostrar y compartir el código.

Lo que te acabo de comentar es lo habitual en software libre, aunque los no iniciados no acaban de valorar su importancia y beneficios. Espero que si alguien toma como ejemplo el proyecto Menéame que también considere la importancia de que exista el software libre que lo ha permitido y de trabajar con la misma filosofía.

Eduardo Manchón: A pesar del éxito, no creo que te vayas a quedar parado ¿Cuál es el principal reto al que se enfrenta ahora mismo Meneame?

Ricardo Galli: Ahora mismo es "profesionalizarlo", fundamentalmente la parte publicitaria y luego a partir de eso montar un equipo que nos ayude y deje tiempo para otras cosas, o desarrolladores si es que se requieren.

Sobre funcionalidades... hemos superado la fase en que todo el mundo pedía muchos cambios o nuevas funcionalidades importantes --hemos hecho mucho caso---. Ahora es más tranquilo y aunque no dejo de programar cada día, son detalles o programas no visibles, como los que detectan automáticamente abusos.

Tenemos algunas ideas que iremos implementando de a poco, algunas pronto, otras a largo plazo: mensajes y notas privadas, consultas geográficas, un bot que detecte todas las noticias relacionadas o que hablen del mismo tema que las publicadas, personalización de categorías individuales, algún API más formal y con más funcionalidades, envío de avisos por SMS, mayor interacción con móviles, etc.

En general estamos obsesionados que todo lo que implementemos gire alrededor de la "noticia" y de enlazar y enviar visitas a sitios externos, no nos olvidamos que eso es el núcleo fundamental de toda la idea del Menéame.

Eduardo Manchón: ¿Cuál es tu papel y cuál el de Benjamí Villoslada en el día a día del proyecto? ¿Hay más personas involucradas?

Ricardo Galli: Benjamí además de ser el responsable de la imagen gráfica del Menéame, es una especie de "CEO" y director de finanzas. Yo soy muy desordenado, él se encarga de que la parte administrativa, contable, fiscal y burocrática funcione y esté al día. También se está encargando de hablar con publicistas y hasta con productoras de TV que están interesadas en hacer programas con el Menéame.

Yo me dedico más a la arquitectura, desarrollo, administración de sistemas y poner la cara para repartir y llevarme las tortas, pero también todos los méritos :-)

Luego ambos participamos mucho en la fisgona, comentarios y controlar continuamente que todo funcione y que no se desmadren las cosas --lleva mucho tiempo--.

Hay unas 20 personas voluntarias y "pro buono" que nos ayudan bastante con tareas de "admins", en el sentido que están allí para ayudar a gente con sus envíos, controlar que no se insulten en comentarios, detectar spammers, etc.

Esta semana sale el primer contrato a tiempo parcial para otra persona que nos ayudará en eso y con acceso al servidor --antes no lo podíamos hacer por temas de la LOPD-- donde hay una serie de programas para controlar abusos, como spam con usuarios clones, abusos de votos con diversas cuentas y reiniciando routers, etc. Tenemos previsto incorporar a dos personas más en la misma situación en un plazo muy breve, lo que pasa es que al ser la primera vez los trámites nos llevan tiempo.

Eduardo Manchón: Martin Varsavsky es inversor en Meneame ¿lo buscasteis o os buscó el? En tu post citas también otros inversores, amigos y familia ¿los teneis?

Ricardo Galli: Nos buscó él, no fue el único, pero nos ha tenido paciencia infinita. No sólo nos ofrecía dinero, sino confianza, asesoramiento y contactos relevantes para solucionar rápidamente problemas que de otra forma nos hubiese tomado mucho tiempo y esfuerzo.

Además no nos molesta para nada, pero siempre está dispuesto a echar una mano. Y cuando hablamos o intercambiamos ideas sabe de lo que habla y conoce muy bien los entresijos del entorno o "audiencia" del Menéame. Diría que no podíamos tener mejor socio. Dado el nivel de discusión que tuvimos antes por FON diría que fuimos doblemente afortunados. No sé si nos lo merecemos :-)

Eduardo Manchón: ¿Con qué objetivo queríais captar inversores? ¿cubrir costes? ¿asesoramiento u otro tipo de ayuda?

Ricardo Galli: Cubrir costes, tener un fondo, crear infraestructura, tener la seguridad que si nos demandan --por ejemplo como a la Frikipedia-- podremos acceder a los mejores abogados disponibles, y sobre todo una seguridad económica personal de que no estás desperdiciando el tiempo y perdiendo mucho dinero (antes hacíamos otros proyectos que sí nos dejaban bastante más dinero).

Eduardo Manchón: A alguien con un perfil técnico que tiene un proyecto o quiere crearlo ¿cuándo le dirías que es el momento en el que debe abrir la puerta a inversores?

Ricardo Galli: Ni idea, en nuestro caso creo que tuvimos mucha suerte de pura casualidad. Incluso la forma de hacerlo con Martín fue muy buena. Al principio sólo cedimos el 10%, eso nos permitió total independencia y sentir que el proyecto era todavía nuestro y personal.

Como se había portado bien y queríamos ser honestos le ofrecimos que podía llegar hasta el 33% --manteniendo el mismo precio-- pero cuando él quisiese y sólo si veía que el proyecto evolucionaba adecuadamente. Hizo efectiva su opción hace pocos meses, lo que nos dio más confianza.

Yo diría que lo de vender primero una parte pequeña para tener algo de dinero puede ser de gran ayuda sin que pierdas la pasión por algo "tuyo", tampoco habrás perdido mucho si has fallado en las estimaciones. Luego puedes vender una participación más grande cuando ya tienes más información y experiencia.

Ricardo Galli: ¿Habeis tenido ofertas de compra de la totalidad de Menéame?

Ricardo Galli: Varias, unas pocas por más de seis millones de euros.

Pero no nos decidimos por varias razones. Una es que Martín dice que vale o valdrá más de ese dinero. La otra fundamental para nosotros es que queremos seguir involucrados en el proyecto, que sea referencia por su independencia de intereses corporativos y además que nos divierta y no nos agobien "objetivos comerciales". Todo eso lo tenemos hoy ganando monedas, pero es más difícil lograrlo con alguien que ha invertido tantos millones en el proyecto.

A ver si algún día podemos juntar todo eso. Tampoco nos agobia, no estamos necesitados de dinero ni nuestro proyecto de vida es forrarnos de la noche a la mañana.

También estamos convencidos que los ingresos de publicidad pueden y subirán mucho, como así también la audiencia (en un año hemos triplicado, suponemos que para el año que viene al menos habremos crecido de un 50 a un 100%). Sí estas previsiones son ciertas en el "peor de los casos" podremos sostener el Menéame por nosotros mismos y obtener buenos beneficios.

Eduardo Manchón: Las empresas dicen que la universidad no prepara a los estudiantes lo suficiente para el mercado laboral. En tu caso como profesor de universidad y administrador de un proyecto del mundo real. ¿crees que están preparados para el mercado laboral al salir de la facultad? ¿Y para montar su propoio proyecto?

Ricardo Galli: Sí y no. Lo explico según cómo lo entiendo aunque suene muy provocador.

En primer lugar en temas "técnicos" o de temática que se dan en la universidad no estamos mal, es muy mejorable, pero razonable. En cuanto a capacidad técnica de los profesores, hay de todo, pero puedo asegurar que la mayoría de mis colegas son mejores profesores e investigadores que yo. A veces la "suerte" se echa no en la carrera sino en quién te ha tocado de profesor en asignaturas claves, por allí has tenido alguien genial en un tema que inspira tanto --por ejemplo transmitiendo aquello que todavía queda por hacer-- que te dan ganas de empezar un proyecto relacionado, o que le encuentras una salida tecnológica o comercial.

El problema viene por otro lado, los postgrados y el acceso a los investigadores y empresarios con mucha experiencia. Los temas que se dan ingenierías o licenciaturas no varían demasiado con las "del valle de California", aunque cambia quiénes son los profesores y el acceso y contacto con la "comunidad científica" que brinda la universidad. Por ejemplo Google o Yahoo surgió de alumnos de postgrado de Stanford, donde han tenido oportunidad de trabajar y recibir consejos de gurúes --en el caso de Page y Brin, de Hector García Molina, un prestigioso científico de computación distribuida--.

¿Qué les ofrece eso? Sobre todo mucho morro, ego y autoconfianza (¿suena mejor y más apropiado "self confidence"?). Y ese es el principal problema que veo en nuestras universidades, parece que estamos educando para ser "directores de proyectos" en el sentido de empleado de una gran empresa o en el mejor de los casos un funcionario.

No les estamos trasmitiendo la idea de que ellos pueden también desarrollar programas para que los usen muchas personas, que tienen los conocimientos técnicos fundamentales para aprender mucho más e intentar cosas nuevas. Ni siquiera le enseñamos la "culturilla básica" que considero debe tener un informático apasionado.

¿Cuántos ingenieros conocen Slashdot o Barrapunto? ¿cuántos han participado en proyectos de software libre? ¿quiénes han mirado el código que otros han desarrollado? ¿cuántos se han presentado en uno de los tantos concursos de programación? ¿cuántos leen los ensayos o artículos de Larry Wall (genio del Perl), Paul Graham (gurú de las start-ups), Joel Spolsky, Marc Andreessen (creador de Netscape) o Lawrence Lessig (creador de Creative Commons)? ¿cuántos además de hablar y exigir tanto Java desde el primer día leen el blog de Jonathan Schwartz (CEO de Sun)? ¿cuántos consultan o colaboran con la Wikipedia? ¿cuántos están deseosos de hacer programas que lo use "la gente" que no "las empresas"?

Te puedo asegurar que una minoría --también de profesores-- saben de lo que hablo en el párrafo anterior. Eso es una pena, pero creo que tiene mucho que ver con la motivación que sienten por la carrera que han elegido.

Lo digo siempre en plan provocador. Sí, si queremos cambiar la universidad habría que despedir al 50% de los profesores --yo entre ellos-- pero para ser coherentes también deberíamos echar también al 80% de los alumnos.

Al final el debate de fondo es si queremos universidades de elite como Stanford o MIT o universidades más "sociales". Yo apuesto indudablemente por la segunda opción, tiene sus ventajas sociales indiscutibles, pero también sus problemas asociados: escasez de [buenos] profesores, salarios más bajos, menos infraestructuras per capita, aulas masificadas, alumnos sin la motivación de los de la "elite", etc.

Si queremos mantener este modelo nos encontraremos con esos difíciles y complejos problemas, pero habría que evitar las simplificaciones demagógicas. En cambio estaría muy bien que atacásemos el problema fundamental y que no requiere de grandes presupuestos, ¿cómo hacemos para motivar primero a los alumnos y luego a los profesores?

Si minimizamos ese problema quizás lo otro que hace falta para formar emprendedores viene solo: mucho morro, autoconfianza y dejar de buscar la seguridad de ser empleado de una gran empresa, que con un título de ingeniero a los 24 años y viviendo con los padres no tienen absolutamente nada que perder si prueban algo distinto. Si hasta un triste profesor cuarentón de sistemas operativos asociado un amiguete programador "free lance" y programando en ese lenguaje tan cutre como el PHP le piden entrevistas ¿por qué no ellos que comienzan sabiendo infinitamente más que yo a su edad [*]? ;-)

[*] Lo digo muy en serio, no hay color entre la carrera que hacen mis alumnos con la que he hecho yo.


Fuente del artículo: http://www.alzado.org/articulo.php?id_art=693