Éste es como el tercer o cuarto mes seguido que tengo éste problemita en el sitio… Excedido el límite de consumo de ancho de banda.
El mes pasado me pasé a un plan más grande en el servidor, porque la transferencia del plan anterior se terminaba en los primeros 20 días del mes. Ahora volvió a pasar en febrero, ¡que hasta tiene menos días!

Estoy contento, porque tengo un crecimiento bastante estable en cuanto a la cantidad de visitas, lectores, etc., lo que implica el crecimiento en el consumo de ancho de banda. Estoy viendo qué medidas puedo tomar para disminuir la carga de la página. Por ahora, ya cambié el tema de Wordpress haciéndolo más liviano, y activé la protección contra hot-linking, por las dudas que hayan imágenes linkeadas desde otros sitios que me consuman ancho de banda. Acepto sugerencias de todo tipo.

De todas formas, el hosting respondió bien de bien y no estuvo más de unas horas caído. Gracias a Esteban y a Infranetworking por el soporte:

Web Hosting Profesional

Menuda coincidencia, después del post sobre Usuarios, leí en Coding Horror un post titulado “I repeat: Do not listen to your users” (”Repito: no escuchen a sus usuarios”). Jeff Atwood es el autor, y como la mayoría de sus posts, no tiene desperdicio. Este en particular fue escrito a raíz de Listening to Users (”escuchando a los usuarios”) de Paul Buchheit. Tiene un enfoque más amplio y general que lo que yo escribí, pero sigue con el tema de la relación con el usuario.

Cito algunos fragmentos para agregar más al tema:

“Escuchar a los usuarios es algo tramposo. Los usuarios generalmente no saben lo que quieren, y aunque supieran, la comunicación probablemente se entrevere en algún momento entre ellos y ustedes. De ninguna manera deberías ignorar a los susuarios sin embargo. La mayoría de las personas se irá silenciosamente para siempre si tu software o sitio web no satisface sus necesidades. Los usuarios a los que le importa lo suficiente para darte retroalimentación merecen tu atención y respeto. Están esencialmente encargándose de diseñar tu producto. Si no escuchas atentamente y respondes educadamente a todo el feedback de los clientes, te estás preparando a tí mismo eventuales fallas.

Es mala educación no escuchar a tus usuarios. Entonces cómo reconciliamos esto con la primera regla de usabilidad– No escuchamos a los usuarios?

Para descubrir qué diseño funciona mejor, observa a los usuarios mientras intentar realizar tareas con la interfaz de usuario. Éste método es tan simple que muchas personas lo pasan por alto, asumiendo que debe haber más en el testing de la usabilidad. Se concentra en las reglas básicas de usabilidad.
-Ver a la gente hacer
-No creer lo que la gente dice que hace.
-Definitivamente no creer lo que la gente predice que pueden hacer en el futuro.

Creo que Paul acertó, pero es fácil de errar. La frase relevante en el post de Paul es que vemos qué cosas trabajan, lo que implica medida y correlación. No hay necesidad de mirar directamente a los usuarios (aunque nunca hace daño) cuando tienes logs detallados mostrando lo que hicieron actualmente. Junta feedback del usuario, luego correlacionalo con la información de lo que esos usuarios están haciendo.

No solo implementes pedidos de funcionalidades de “representantes de usuarios” o “analistas de negocios”. La forma más común de errarle en la usabilidad es escuchar lo que los usuarios dicen en vez de realmente mirar lo que hacen. Las especificaciones de requerimientos siempre están mal. Debes prototipar los requerimientos rápidamente y mostrarle a los usuarios algo concreto para encontrar lo que realmente necesitan.

Es cuestionable actuar únicamente en el feedback de usuario. No importa con cuánta buena intención, estás adivinando. ¿Porqué adivinar cuando puedes tomar acciones basado en información fría y persistente? Actuar en base al feedback del usuario y métricas detalladas de uso para tu aplicación o sitio web — ese es el estándar dorado.

El post continua comentando ejemplos en las compañías de videojuegos Valve y Bungee, con ejemplos de datos reales y cambios aplicados a los productos finales en base a dicha información.
Finaliza con:

“Asegurate que tu aplicación o sitio web esté capturando la actividad del usuario en una manera útil y significante. El feedback del usuario es importante. No me malinterpreten. Pero nunca trabajen únicamente basado en el feedback del usuario. Siempre tengan algún tipo de información de la actividad del usuario para corroborar y apoyar el valioso feedback que están obteniendo del usuario. Ignorar el feedback de usuario puede estar aprontándote a un eventual fracaso, pero actuar ciegamente para cada requerimiento del usuario ciertamente es un fracaso.”

Una que descrubí de casualidad:

“¿Quién hubiera adivinado que cuando sacas a Garfield de las historietas de Garfield, el resultado es un cómic aun mejor sobre esquizofrenia, desorden bipolar, y la vacía desesperación de la vida moderna? Amigos, conozcan a Jon Arbuckle (Jon Bonachon en español). Riamos y aprendamos con él en un profundo viaje dentro de la torutada mente de un asolado y joven hombre común mientras lucha una batalla perdida contra la soledad y la adicción a las metaanfetaminas en un tranquilo suburbio americano.”

Realmente, quién lo hubiera imaginado… El cómic sin Garfield es totalmente diferente, y nos deja concentrarnos en la enferma mente de este pobre hombre, dueño del obeso gato come lasaña…

A continuación algunos ejemplos para que conozcan el retorcido humor de la gente de “Garfield minus Garfield” que comparto totalmente:

Derecho al feed reader…

Luis D. (profesor): “Vos sos el enemigo del usuario.”
Fernando (yo): “Totalmente.”
Luis D. : “Totalmente.”

Hoy(<ezquizofrenia>mensaje para mi yo futuro: “Cuando publiques esto, ya va a ser ayer”</ezquizofrenia>) llegué tarde a clases, ya que como había dicho el profesor en una clase anterior “a veces tenés que estar en 3 lugares al mismo tiempo”. En mi caso, tenía que estar en el trabajo arreglando un defecto que saltó en el software a raíz de una modificación, una reunión por el hosting de una página web, y la clase de taller de gestión…

Pero bueno, cuando llegué estaban hablando sobre las funciones de los distintos roles que participan de un proyecto de software: el cliente (el que pone la plata), el usuario (el que va a usarlo), el experto en el dominio (el que nos va a ubicar en el contexto del problema) y nosotros los desarrolladores.

A poco que entré el profesor dijo esta frase que disparó el reflejo en mí de decir en voz alta: “Totalmente”, lo que reafirmó.

Ahora, tampoco es tan así, ya que el usuario puede ser el peor enemigo, pero también el mejor aliado, ya que como nos dijo, es uno de los que va a vender el software. Vende más que alguien diga “este software anda bárbaro, vinieron los programadores, me lo explicaron, me respondieron las dudas de buena gana, y cuando hubieron errores vinieron a arreglarlo enseguida o a explicarme en qué me había equivocado”. Totalmente opuesto a : “Nah, este software se cae a pedazos, los tipos son unos culo rotos, y no vienen nunca son terribles chantas”

De la experiencia que he tenido, puedo decir que en general, cuando estemos desarrollando, va a ser el enemigo. Tenemos que pensar que el usuario es el ser más estúpido e improbable que existe. Por ejemplo: Uno puede pensar: ¿Porqué voy a controlar que la fecha de nacimiento sea menor a 2045? ¿Quién va a ser tan estúpido de poner eso? ó ¿Porqué en esta caja de texto de Nombre voy a controlar el máximo de caracteres para evitar un overflow? ¿A quién se le va a ocurrir ingresar tantos caracteres? ó ¿Quién va a clicquear de nuevo este botón cuando ya fue clickeado y hay una barra de progreso mostrando que el sistema está trabajando? Supongo que se habrán imaginado quién… De todas formas como que ésto se controla por un tema de calidad… o algo así supongo. Vas a querer que tu software controle ese tipo de cosas.

Tener que trabajar en esas “nimiedades”, sobretodo cuando estamos embalados en partes más interesantes del código, a veces puede resultar bastante tedioso, y generar pensamientos negativos contra el usuario final. De todas formas, hay que tratarlo bien, respetarlo, y buscar la forma de llevarse. Como se dijo en clase, se va a sentir amenazado por el programador: “Éste me viene a sacar el trabajo”, “Éste va a cobrar quinientos dólares por venir a hacer dos pavadas y yo cobro eso en dos meses….”, etc.

Es mejor si se consiguen usuarios más familiarizados con la tecnología, pero nunca va a faltar el que le tiene fobia a la computadora o piensa que internet se limita al MSN y las diapositivas sin sentido por mail (quien no conozca a nadie así que tire el primer comentario).
Pero es una de las tantas cosas que hay que aprender para convertirse en un buen desarrollador, a menos que podamos contratar a gente que lo haga por nosotos

Iba a dejar el post en la cita del diálogo “totalmente” nada más, pero me colgué escribiendo… Las clases vienen bastante dinámicas por el momento. Así que lo dejo por acá, seguimos en los comentarios del post.

<ezquizofrenia>Mensaje para mi yo futuro: “¿Viste que está bueno comunicarse entre los distintos yo a lo largo del tiempo? Hay que hacerlo más seguido. Respondeme en los comentarios.”</ezquizofrenia>

De la mano del programador Nick Halstead, llega éste revolucionario sistema web 2.0 que comienza su beta privada. Seguramente una nueva y divertida forma de leer nuestros feeds:

Hoy comenzamos la beta de fav.or.it,
fav.or.it es un producto único que no solo permite que leas contenido a través de la blogósfera sino que también puede interactuar con ella sin dejar el sitio. Esto es importante para que podamos enfocarnos a una nueva audiencia que no tienen el entendimiento técnico de los actuales productos del mercado.

Las características clave de fav.or.it:

• Lectura de feeds - River like
• Comentarios integrados
• Rastreamos información de atención, para que sepas lo que es importante
• Búsqueda super fácil
• Crea tus propias porciones de la web
• Comparte tus bits favoritos
• Full API

Para más información sobre fav.or.it visita el sitio el cual incluye capturas de pantallas del producto y estará añadiendo screencasts en los próximos días.

Hace un tiempo leí “Fundación”, el primer libro de la saga de Isaac Asimov, donde plantea una ciencia ficticia llamada psicohistoria. <SPOILER ALERT!> Se pueden revelar datos de la trama a continuación, leer con cuidado…</SPOILER ALERT>

De Wikipedia:

La psicohistoria, la ciencia del futuro, es el nombre de una ciencia ficticia en el universo del Ciclo de Trántor de Isaac Asimov, que combina historia, psicología y estadística matemática para calcular el comportamiento estadístico de poblaciones extremadamente grandes de personas, como el Imperio Galáctico.

Asimov utilizó la siguiente analogía: en un gas, el movimiento de una sola molécula es muy difícil de predecir, debido a los continuos choques con sus vecinas, pero el comportamiento a escala visible de un gas puede ser predicho con gran exactitud. Así, si se aplicaran cálculos estadísticos a una población lo bastante grande, como el Imperio Galáctico de sus novelas, cuya población era de cuatrillones de personas, se podría predecir su evolución histórica y social global con gran exactitud.

El personaje responsable de la creación de esta ciencia, Hari Seldon, estableció 2 postulados:

1. que la población en la cual el comportamiento fuera a ser modelado debía ser suficientemente grande
2. que debía permanecer ignorante de los resultados de la aplicación de los análisis psicohistóricos.

Cuando leí el libro, no me pareció una idea tan alocada predecir los acontecimientos futuros por medo de la matemática y estadística de la forma en que lo hacía Hari Seldon. Es más, se me plantearon muchas ideas en general a raíz de este libro que comentaré en algún momento.

Siguiendo con el tema, leo en barrapunto:

 

Pues sí, la ciencia ficticia llamada psicohistoria, imaginada por el gran Isaac Asimov en su saga de la Fundación, ha cobrado vida en la Universidad Politécnica de Valencia, según leo en 20Minutos. Según la noticia, investigadores de dicha universidad creen que se puede predecir el futuro de una sociedad (al menos, en su vertiente ideológica) mediante la matemática, igual que Hari Seldon predecía el futuro de la humanidad a partir de la estadística en los libros de Isaac Asimov. Una vez más, la realidad supera la ficción. Para ser fieles a los libros de Asimov, propongo cambiar el típico nombre valenciano (Vicente) por el de Hari y el nombre de la capital del Turia por Trantor.

 

El link lleva a una noticia en 20minutos, que a su vez fue publicada en Muy Interesante, y dice:

 

Según Rafael Villanueva, investigador del Instituto de Matemáticas Multidisciplinar de la UPV, las ecuaciones diferenciales pueden ayudar a averiguar, por ejemplo, “qué posibilidades existen de que una persona que tiene una ideología determinada, cambie su forma de pensar y se encamine hacia otros posicionamientos, incluso radicales o a determinados comportamientos fanáticos”,

Cada una de las ecuaciones desarrolladas por Villanueva y sus colaboradores engloba una serie de parámetros que influyen en la evolución de la ideología de grupos sociales y que contemplan aspectos como la publicidad, la propaganda, la repercusión mediática, el liderazgo de un tipo de mensaje, etc. “Estudiando los cambios en los valores de los parámetros podemos predecir los diversos escenarios ideológicos de una sociedad en un futuro cercano”, afirma el investigador.

 

¿Será que se creará el Imperio Galáctico seguido de la Fundación y la Enciclopedia Galáctica monumental obra que recopila los saberes de todos los habitantes de la galaxia? ¿O nos conformaremos con la Guía del autopista Galáctico, que según dicen, es más barato?

Ayer lunes empezamos oficialmente las clases de Taller de Gestión de Proyectos. Llegó la hora de dejar un poco el tema de programación, y meterse más en lo que es Ingeniería del Software. Para arrancar nomás ya nos recomendaron 3 libros para que vayamos leyendo tranquilamente:

• Ingeniería de Software de Pressman
• Ingeniería de Software de Shari Lawrendce Pfleeger
• Ingeniería de Software de Ian Sommerville

La ingeniería del Software va un poco más allá del rol del programador. Abarca todas las actividades necesarias para realizar un proyecto de software. Entre ellos, la gestión en sí, que es en lo que andamos más flojos. Para ser sinceros, hasta ahora veníamos zafando con programas que cumplían lo que se pedía. Ahora hay que ir un poco más lejos, y meterle a la solución del problema y su gestión desde otros puntos de vista.

Un proyecto lo definimos como una actividad que tiene un principio y un fin. Y entre otras cosas, para decir que nuestro proyecto ha tenido éxito se debe dar que cumpla con los requerimientos pedidos con la menor cantidad de fallas posibles.

Son temas bastante más profundos en los que nos vamos metiendo, como las características para que un software grande sea considerado bueno: que sea mantenible, escalable, etc. Todas éstas cosas las hemos ido aprendiendo a lo largo de la carrera, pero ahora vamos a tener que analizarlas más profundamente y tomarlas bien en serio.

Una vez más: Arranca el semestre…

Las experiencias y cuentos tanto de Pablo y Mauricio como de otros que han hecho el proyecto final, alimentaron mi paranoia a un buen punto: funcionó. Tratando que el tiempo no me agarre desprevenido anoche al llegar a casa agarré OpenOffice y empecé a tirar líneas de texto e ideas para ir adelantando trabajo. No es mucho lo que pueda hacer todavía por la falta de conocimientos en gestión, pero más vale prevenir… Espero poder mantener el ritmo de trabajo y la costumbre.

Ya estoy buscando para conseguirme uno de los libros:

Ingeniería del Software: Un enfoque práctico
Roger S. Pressman.

La tapa la rompe… aunque no es por eso que lo quiero conseguir, es el recomienda el pinwino…