Opinion

Juan Mellado, 24 Abril, 2010 - 08:55

Cloud ComputingEl futuro ya está aquí otra vez, y es la "nube", la "computación en la nube", el "cloud computing".

La idea es que las empresas "punto com" más grandes tienen unas infraestructuras enormes y no siempre las utilizan al cien por cien. Así que un día decidieron compartir con el mundo esos recursos que no estaban aprovechando. A cambio de dinero, claro. Se dieron cuenta de que era rentable, con una demanda creciente, y ahora es una parte importante de su negocio.

Uno de los servicios más populares de este tipo hoy en día es Amazon EC2 (Amazon Elastic Compute Cloud). Y lo que ofrece es la posibilidad de contratarles a ellos nuestras necesidades de computación. Es decir, tanto el hardware como el software. Pero a diferencia de un contrato tradicional, que implicaría que nos enviaran las máquinas y los programas a nuestra casa, lo que obtenemos es acceso a una infraestructura virtual a través de una conexión a Internet. Bueno, "virtual" por definición, pero "real" en la práctica. Ellos ponen los servidores, con las aplicaciones instaladas, y nosotros las utilizamos a través de Internet. Ellos pagan por el mantenimiento del hardware de sus centros de cálculo, las licencias del sofware, y nosotros por su uso.

El concepto de "nube" viene del hecho de que en la práctica no existe un PC por cada cliente que contrata con ellos el servicio, sino que en realidad sus infraestructuras están organizadas como una enorme red interconectada de ordenadores altamente escalable horizontalmente. El hecho de que nuestros procesos se ejecuten en un ordenador u otro, o de forma distribuida en varios, es algo totalmente transparente y absolutamente obviable como usuarios.

Una de las curiosidades de este tipo de computación es de carácter social. En pocas palabras: mucha gente la odia. Las razones son varias, pero el problema principal es que produce cierto sentimiento de pérdida de la propiedad. Una sensación de pérdida de control. Cuesta mucho asimilar la idea de cesión de la ejecución de nuestras actividades diarias a los proveedores de servicios. Es como confiar parte de nuestra intimidad a un tercero. Produce desazón.

Pero sentimentalismos aparte, existe cierto recelo sobre su implantación masiva a corto plazo, sobre todo por culpa del relativamente escaso ancho de banda actual disponible en algunos paises. Pero aparte de esta consideración de carácter meramente práctico, hay bastantes más aspectos de orden jurídico, económico y técnico a considerar. ¿Qué derechos tiene la empresa contratada sobre mi información personal? ¿Puede cambiar la empresa sus tarifas de forma arbitraria y denegarme el acceso a mi información? ¿Qué ocurrirá con mi información si la empresa quiebra o es adquirida por un tercero? ¿Puede negarme la empresa la posibilidad de instalar el software concreto que yo desee? ¿Puede dejar la empresa de soportar un determinado software previamente contratado? ¿Puede obligarme la empresa a actualizar el hardware o software para acceder a mi información? ...

Muchas de las dudas se pueden solventar con una serie de cláusulas en un contrato, pero en un mundo globalmente interconectado va a resultar una tarea cada vez más complicada. Y por si faltara poco, para complicar más el tema, ya se está hablando de la computación Intercloud. Es decir, de una "red de nubes". Contratar el servicio a una empresa que a su vez subcontrata las "nubes" a otras empresas.

Llegados a este punto la cosa se pone interesante. El sistema en su conjunto empieza a asemejarse al de otros mercados de productos y servicios. Como el mercado eléctrico por ejemplo. Como usuarios finales contratamos la electricidad que llega a nuestra casa, y normalmente no nos preocupa donde se genera ni los medios que se utilizan para que se produzca. Y aquí aparece el concepto de commodity. Bien o servicio para el que existe una demanda, y que se ofrece al mercado sin aportar un gran valor añadido al mismo. Un ejemplo típico es el petróleo, a la hora de comerciar con él da igual el pozo de donde se haya extraido. O el trigo. O la leche. Y la computacion en la nube lleva camino de convertirse en eso, en una commodity para un mercado de la computación virtual.

De hecho, algunas webs ya están ofertando servicios utilizando fórmulas similares a los que se utilizan en otros mercados. Así, Amazon ofrece la modalidad de contratación en Spot Price. La idea es que el precio del servicio no es fijo, fluctúa. No hay único precio. Hay un precio horario, es decir, que cambia cada hora. Y lo que permite esta modalidad de contratación es determinar el precio máximo que queremos pagar. Mientras el precio sea inferior al valor X contratado tendremos acceso al servicio, pero cuando el precio sea superior a ese valor X dejaremos de tenerlo. Y en cualquier caso, sólo pagaremos el valor real que cuesta el servicio hora a hora.

Las necesidades de computación de las organizaciones, ya sean públicas o privadas, e incluso de cierta parte del público en general, aumentan cada día, obligándoles a mantener actualizadas complejas estructuras de hardware y software que no forman parte del objeto propio de su actividad. Por ejemplo, una multinacional del mundo de la moda puede no sentirse demasiado cómoda teniendo que invertir una parte importante de sus recursos en dar soporte a una vasta infraestructura informática. No es su negocio. Pero debe hacerlo. La computación hoy en día es una necesidad, no un lujo. De hecho algunos analistas empiezan a englobarla junto con el resto de utilities, como el agua, la electricidad o el gas natural.

De seguir esta tendencia, parece que los gobiernos estarán obligados a garantizar la capacidad de cómputo de sus ciudadanos, como el de cualquier otro bien de consumo básico, regulando el negocio dentro de un mercado de la computación virtual, ya sea de carácter nacional o a escala planetaria.

Temas: Opinion
Juan Mellado, 7 Mayo, 2008 - 19:30

yEns me ha mandado hoy un correo pidiendo algo de promoción para plusdeporte, su nuevo proyecto web. Una página de promoción de noticias deportivas que sigue el estilo marcado por el conocido digg, popularizado al castellano por menéame, y que ha servido de referencia para muchos portales especializados como puede ser el caso de pixélame. Webs colaborativas 2.0.

El aspecto de la página es muy claro, directo, y con una combinación de colores que a mi particularmente me gusta bastante. Cada tipo de elemento (título, texto, enlace, ...) es facilmente distinguible y sigue la tónica habitual de este tipo de webs, por lo que es muy fácil manejarse rápidamente por ella. No aporta nada nuevo al género, pero su finalidad la cumple con creces, aunque me gustaría algo más de feedback por parte de la página al votar una noticia.

Técnicamente, mirando el código HTML de la página, e invocando el validador, veo que canta una etiqueta que no está cerrada, pero no supone mayor problema. Todo está montado a base de CSS, incluyendo un bonito recordatorio de que "IE is out there". Para el JavaScript veo que han utilizado jQuery con esa forma suya tan particular de encadenar comandos.

En su divertido FAQ, donde entre cosas nos cuentan que en realidad lo que pretendían con la web era dominar el mundo pero que Google se les ha adelantado, he encontrado una url a un mini-blog de seguimiento del desarrollo de la propia página. Después me he dado cuenta de que existe un enlace directo en el menú principal, ¿pero quién se fija en esas cosas hoy en día?

Adrián me comenta en su correo que ha hecho la web partiendo de cero, con ayuda de Iván Guardado, utilizando PHP y MySQL. Teniendo en cuenta lo cuidado del aspecto y la fluidez con la que se mueve el conjunto sólo resta felicitarlos por el trabajo realizado.

¡Buena suerte chicos!

Juan Mellado, 31 Octubre, 2007 - 19:59

PacManUna de las cosas que no me gustan de los portales de juegos online son las facilidades que dan algunos de ellos para hacer trampas a los jugadores. Sobre todo cuando se trata de videojuegos de "habilidad". Cuando son juegos de "azar" entonces la cosa cambia y es la casa la que tiene más oportunidades de hacerlas, aunque en mi opinión ningún portal medianamente serio las hace.

La semana pasada estuve visitando algunos portales para ver que tipo de juegos ofrecían. Y no me refiero a webs que se dedican a recopilar miles de juegos hechos en flash, sino sitios que ofrecen unos pocos juegos escogidos, normalmente con la idea de poder jugarlos con otros usuarios conectados a la red. Pocos eran de acceso público, la mayoría pedían registro, y en algunos incluso se podía apostar con dinero de verdad.

Los casinos online los descarté enseguida, pues a excepción de algunos juegos de cartas, las posibilidades de ganar se basan en la suerte y no en la habilidad de quienes juegan. Ningún tipo de truco de los que puede encontrarse por Internet es válido, en los casinos todo depende de la suerte. Apostar el doble de la jugada anterior con la intención de recuperarse de las pérdidas, o contar cartas por ejemplo, no tiene sentido, porque las mesas tienen un límite máximo de apuesta, y las cartas se barajan en cada mano.

Los portales de videojuegos por su parte ofrecen la posibilidad de jugar a juegos en los que sí prima la habilidad del usuario por encima de la suerte, aunque este sea también un factor importante. Después de un rato me estuve fijando en algunas tablas de puntuación y llegué a la conclusión de que no podian ser reales. Siempre cabe la posibilidad de que lo sean, pero la verdad es que algunas me parecieron absolutamente irreales. Partiendo de esta premisa estuve analizando un par de días un juego a ver si podía llegar a alguna conclusión. Concretamente utilice como referencia uno de tipo Bejeweled (el intercambiador).

En este tipo de juego lo único que hay que hacer es juntar tres o más fichas de un mismo tipo a base de intercambiarlas. Uno de los factores clave es "ver" las combinaciones a la mayor velocidad posible. E identificar patrones es algo que un ordenador puede hacer facilmente, basta con que compare pixel a pixel los gráficos de unas posiciones con otras. Sin embargo, un análisis más detallado me permitió ver que eso era algo que ya se había tenido en cuenta. Ocurrió que me dí cuenta de que cada gráfico de forma individual no se dibujaba siempre igual, a pesar de representar el mismo tipo de pieza. A veces se desplazaban unos pocos píxeles hacia arriba, otras veces hacia un lado, ... Un cambio lo suficientemente leve como para que el jugador no notase la diferencia. Y la cosa no acababa ahí, sino que los colores también cambiaban ligeramente entre pieza y pieza, aunque fueran de un mismo tipo. Los tonos eran un poco más apagados o fuertes de pieza en pieza, e incluso el antialiasing se había hecho de una forma distinta. Es decir, se habían tomado precauciones para evitar que un simple análisis pixel a pixel fuera efectivo.

Sin embargo, aunque loable, es fácil pensar que ese sistema no puede resistirse a un análisis más serio. Los sistemas de reconocimiento de imágenes y OCRs hoy en día son lo suficientemente potentes como para reconocer figuras en diversas posiciones e incluso con ligeras variaciones. De hecho, mi primera idea fue que un detector de bordes podría ser suficiente como para identificar los patrones de cada tipo de ficha. Pero ni siquiera sería necesario llegar a eso, una simple descomposición por componentes de los colores (RGB) bastaría para identificarlas de forma fiable 100%. Se sumarían por separado las componentes de una batería de píxeles distribuidos regularmente sobre cada pieza, y los tres resultados identificarían a cada pieza individualmente. Comparar una pieza con otra sería tan fácil como comparar los tres resultados de una pieza con los tres resultados de otra dentro de un margen de error.

Como resulta fácil de suponer, absolutamente todos los portales prohiben en su página de condiciones de uso la utilización de cualquier tipo de software (o hardware como pantallas táctiles) que proporcionen ventaja a un jugador frente al resto. E incluso en algunos juegos online, a otra escala, como el popular World of Warcraft, incluyen dentro de sus condiciones de uso la posibilidad de instalar software que inspeccione los programas de nuestro ordenador a la busca de cualquier tipo de software que ofrezca algún tipo de ventaja.

Juan Mellado, 30 Octubre, 2007 - 20:11

Si siempre he odiado la hornada de programadores para los que la forma de generar código consiste en hacer uso intensivo y continuado del "copy paste", ahora resulta que descubro otra generación que me provoca más espanto todavía. La generación del "autocomplete".

Lo vi claro hace unos días, mientras examinaba un trozo de código con un compañero de trabajo. Su forma de trabajar hizo que se me abrieran los ojos como platos. Básicamente consistía en activar la opción de autocompletar a cada momento, y quiero decir "a cada momento". No fue capaz ni de escribir un "if", sólo dos letras, ojo al dato, sin utilizar la opción de autocompletado automático.

Pero, ¿por qué es malo usar una opción que a todas luces resulta tan útil?, ¿quién no la ha usado alguna vez, o incluso continuamente, para escribir código más rapidamente o examinar el detalle de atributos o métodos de una clase, por ejemplo?, ¿donde está el problema? Pues el problema está en la forma en que vi como se usaba la opción. No era para "autocompletar" la idea (sentencia) que estaba desarrollando, sino que realmente se usaba para "buscar" la solución al problema. Se esperaba "encontrar" cada sentencia, a cada paso, sin tener un guión preestablecido de lo que se quería escribir. Un estilo de programación basado en la continua selección de una opción dentro de las ofrecidas en un desplegable.

La experiencia fue tan ridícula, y llegó a un extremo tal, que me permitió entender varias cosas que había visto anteriormente en el código y que no acaba de entender porqué estaban así. Ocurrió que se escribió incorrectamente el nombre de un método ("contabilidzar"), en una de esas pocas oportunidades en las que realmente se tiene que escribir algo sin que la opción de autocompletar sea de utilidad [de momento]. Y así se quedó, arrastrándose por toda la clase, e incluso por otras clases que hacían uso de ese método. Una vez escrito ya no se volvió a pensar en él, simplemente se "autocompletó" cuando hizo falta, independientemente de que el nombre de método estuviera mal escrito.

WTF?

Juan Mellado, 11 Septiembre, 2007 - 19:31

Monkey IslandDespués de mi reciente experiencia con la segunda parte de Runaway, he estado mirando a ver que herramientas hay disponibles actualmente por Internet para la elaboración de aventuras gráficas. Este es un género de juegos que parece animar mucho a la gente a desarrollar editores propios. Posiblemente porque es un tipo de programa que causan una falsa sensación de "sencillez". Al fin y al cabo, vistos asi por encima, parecen constar tan sólo de un escenario 2D con objetos dibujados dentro del mismo, con un personaje que se mueve a golpe de ratón por un camino predefinido, una línea de textos, un inventario, y unas poquitas cosas más. Ni siquiera parece que haga falta que todo el conjunto se mueva a gran velocidad. Y razón no les falta a quienes dicen eso, pero del dicho al hecho hay un trecho.

Es el legado que dejó Scumm (Script Creation Utility for Maniac Mansion), la famosa herramienta de desarrollo de aventuras gráficas de Lucas. Desde su popularización, siempre ha parecido lógico pensar en que hacer una herramienta de "point&click" era el método ideal para crear este tipo de programas sin conocimientos técnicos previos. Aventuras gráficas para las masas. Y la verdad es que como programador he de confesar que no deja de tener su encanto pensar en ello. Aunque leer acerca de los problemas y soluciones que se plantean en la práctica durante la elaboración de una aventura gráfica sirve para ponerle a uno los pies en la tierra. Aunque eso nunca será impedimento para que unos y otros lo intenten, aunque sea sólo por el placer de intentarlo.

He encontrado bastantes programas por la red, aunque muchos de ellos proyectos personales que han quedado obsoletos y abandonados poco a poco con el paso del tiempo. Guiándome un poco por el aspecto de la web (hay que saber venderse) y las fechas de las últimas versiones publicadas (hay que actualizar con frecuencia) he estado ojeando las siguientes herramientas:

- Wintermute (WME): Según reza en la portada de la web, el "Wintermute Engine Development Kit" es una herramienta para el desarrollo de aventuras en 2D y 2.5D (personajes 3D sobre fondos 2D). Así a bote pronto parece un programa que ha sabido adaptarse a los cambios tecnológicos y que ofrece algo bastante más allá del clásico 320x200 donde se anclaron otros. El editor de escenarios y el organizador de proyectos parecen tener la estructura lógica que uno espera que tengan este tipo de software hoy en dia: árbol de entidades, pestañas de propiedades, editores WYSIWYG, soporte para varios idiomas, ... Se puede usar gratuitamente en proyectos comerciales, aunque se agradece una donación para continuar con el desarrollo.

- Adventure Game Studio (AGS): En comparación con el anterior creo que lleva peor lo de la edad, aunque tiene una comunidad muy grande con un buen número de proyectos finalizados. La limitación a 800x600 llama bastante la atención cuando eliges la opción de crear un nuevo proyecto, así como la edición de paleta. Leyendo entre líneas se puede sobreenteder que están en contra del alarde técnico en favor de la calidad de la aventura. El editor parece bastante complejo de abarcar de una sola vez por el gran número de opciones que ofrece, aunque tiene detalles curiosos, como mostrarte el script equivalente al resultado de elegir determinadas opciones en los cuadros de diálogo. Pero lo mejor de todo es sin duda la opción "Make my game.."

- Lassie Adventure Studio (LAS): Este producto está más orientado a obtener beneficios por parte del autor que el resto y tiene la peculiaridad de tener soporte para la distribución via web. Se presenta en dos versiones, una hecha en Flash que genera un fichero SWF que puede reproducirse desde la web o distribuirse como una aplicación independiente, y otra en la que sólo se puede trabajar desde dentro del propio entorno de Director (Adobe) y sólo tiene la opción de generar un fichero para su distribución independiente. Tiene una página de recursos bastante completa.

- Adventure Game Authoring System (AGAST): Este realmente es un lenguaje de script, ya que el autor parecía estar más interesado en crear un compilador que un juego de editores. Quizás un proyecto demasiado personal.

Y por el camino me dejo muchas más: Visionaire, Adventure Maker, 3D Adventure Studio, ... la lista es interminable.

Lo que parece una constante en los que merecen la pena es el soporte de algún tipo de lenguaje propio para la elaboración de scripts. Aunque curiosamente un verdadero producto "point&click" debería poder prescindir de ese tipo de aditamentos. Este tipo de "features" debería verse siempre como un valor añadido, orientado sólo hacia los desarrolladores avanzados que quieran poder hacer algo más que lo básico. Contemplar todos los posibles escenarios que puedan plantearse por adelantado es imposible.

De todas formas, como ya he dicho alguna que otra vez, el mayor problema de este tipo de programas para mi sigue siendo la elaboración del "contenido": elaborar un guión que resulte interesante, crear unos personajes que estén coherentemente definidos, diseñar unos puzzles que resulten lógicos a la par que retadores, construir un universo visualmente atractivo, y además conseguir ponerlo todo junto para que se perciba como una única entidad: un juego.