Humanética

La estrategia de gmail

Seguro que muchos lectores ya tienen su cuenta de gmail. Me parece interesante la forma como este correo de Google a logrado difundirse y captar la atención; se nota que tienen asesores de marketing ... no como otros ... ¿se les ocurre el nombre de alguna compañía?. Se entregó cuentas a un selecto grupo de personas diciéndoles que era para probar el funcionamiento del mismo. De esta manera recibían retroalimentación de personas entendidas en la materia (con la consiguiente precisión de la información de retorno) al mismo tiempo que sometían a prueba el funcionamiento del servicio. Es decir una situación muy propicia para identificar fallas y mejorar la funcionalidad.

Posteriormente se le entregaba invitaciones para que estas personas se las dieran a otras que consideraban se lo merecían (por llamarlo de alguna forma). Este segundo grupo de personas a su vez, luego de transcurrido un tiempo, podrían hacer invitaciones a otras personas. Se ha generado de esta manera un crecimiento exponencial en el número de personas que tienen una cuenta en este correo, por lo cual no me extrañaría que en poco tiempo se convierta en uno de los más comunes.

La parte más interesante (para mi) viene dada, sin embargo, por el efecto psicológico. El correo gmail es "posicionado" como un correo al que solo tienen acceso unos pocos privilegiados, generando la envidia y el deseo del resto. Cuando a una persona le ofrecen "¿quieres una cuenta de gmail?" (y sabe de que estás hablando) es casi seguro (si no la tiene) que te diga que sí. Y luego, no es raro verlo sumamente contento (como no he visto con ningún otro correo) con su "juguete nuevo", además de una posible sensación (aunque sea fugaz) de pertenecer a la "crema y nata" del cibermundo.

He utilizado el término "posicionamiento" siguiendo el concepto formulado por Al Ries y Jack Trout. Estos autores entienden bastante bien el aspecto psicológico del marketing. Por ejemplo en su libro Las 22 Leyes Inmutables del Marketing escriben "El marketing no es una batalla de productos, es una batalla de percepciones". Es decir, desde el punto de vista del marketing no es tan importante si realmente tu producto es el mejor, sino si el público lo percibe como el mejor (aunque sea el peor). El posicionamiento tampoco es para ellos la cantidad de canales de distribución existente, ni el número de personas que compran un producto, ni siquiera el número de personas que lo usan. El posicionamiento es la "posición" que ese producto ocupa en la mente del consumidor. Un producto puede no estar muy difundido, pero bien posicionado (como elegante, resistente, fácil de usar, etc. O su contraparte como de mal guso, inseguro, dificil, etc.). Este concepto es todavía un poco más complejo, pero dejaremos para después una explicación más detallada.

Posted at 04:21PM Dec 23, 2004 by Ricardo in Interciencia  |  Comentarios[1]

En busqueda del desarrollo multiplataforma

Cuando comencé a utilizar Java lo hice por la promesa de "Write Once, Run Anywhere" que si bien no es completamente cierta, al menos es útil para una cantidad enorme de situaciones. Como programador de aplicaciones de escritorio e interfaces de usuario el contar con un sistema de widgets era fundamental. Swing no terminaba de convencerme, se ejecutaba con mucha lentitud y para mi gusto personal el look and feel predeterminado era (es) bastante feo. De modo que seguí investigando y me encontré con SWT.

SWT utiliza JNI (Java Native Interface, es decir una combinación de código Java y código nativo) para comunicarse con los controles propios de cada plataforma. Es por ello que para funcionar requiere de unos archivos adicionales, diferentes para cada sistema operativo. Cuando no encuentra un control que esta presente en un sistema operativo y no en el otro, en este último hace una simulación del mismo. De esta manera el programador puede escribir un solo código que funcione en diferentes plataformas. Al mismo tiempo las aplicaciones tendrán la apariencia y comportamiento propio del SO (en realidad aquí comienza parte del problema). Adicionalmente a esto, hay que mencionar que una aplicación hecha con SWT se inicia más rápido y normalmente consume menos memoria que su correspondiente en Swing.

Pero (todo tiene un pero) no podía ser verdad tanta belleza. Conforme comencé a utilizar Linux de manera predominante me dí cuenta que SWT no funciona tan bien como debería en Linux. A veces no se redibujan bien los controles (¿o será mi versión de GTK+?). Y por supuesto, se comporta y se ve diferente en diferentes sistemas operativos. En este último sentido, usar Swing es fantástico, lo que hagas se verá practicamente igual no importa donde lo ejecutes (eso creo).

Por otra parte nunca he abandonado la esperanza de poder compilar las aplicaciones hechas con Java a código nativo. A pesar del adoctrinamiento al que somos sometidos todos los novatos (y no tan novatos) en el mundo Java: "si compilas a código nativo perderás portabilidad", "no es necesario que lo hagas", "en ese caso mejor utiliza otro lenguaje", etc. Quizá tengan razón y quizá no. Lo cierto es que a mi me gusta mucho Java como lenguaje y si pudiera compilarlo a nativo sin restricciones sería genial para muchas ocasiones. De esta forma lograría basicamente el menor consumo de recursos (sobre todo memoria), un inicio más rápido de la aplicación y asegurar que la aplicación no sea descompilada por cualquier hijo del vecino.

La forma más conocida de convertir un programa hecho en Java a código nativo es mediante GCJ que forma parte del proyecto GCC (GNU Compiler Collection, un compilador libre para varios lenguajes sobre todo C y C++). Las aplicaciones compiladas con GCJ se enlazan con el GCJ Runtime (libgcj), que provee las clases basicas, el recolector de basura y que también puede actuar como un interprete de bycodes. Esto significa que bien podríamos tener aplicaciones que tengan partes compiladas y otras interpretadas. Pero (nuevamente el pero) lamentablemente no tiene implementado un soporte completo para Swing y (lo repito) SWT no me convence del todo en Linux.

Así que viene la pregunta de si es posible combinar código de C++ con el código nativo generado en GCJ. Y la respuesta es sí. Con GCJ el código Java es tratado como un subconjunto de C++ con algunas extensiones y de esta manera se compila, facilitando la tarea de hacer programas con ambos lenguajes. Para lograrlo implementa su propia forma de utilizar código C++ junto a Java: CNI. Lo que se puede hacer a partir de aquí ya queda en la imaginación de cada quién. He de advertir a los lectores que no puedo decirles que esto funcione de maravillas (o sean un desastre), pues aún estoy en fase de pruebas.

Hay muchos otros proyectos que también merecen ser tomados en cuenta como Java-Gnome o aquel que intenta implementar un clon de Swing utilizando como base SWT (en vez de AWT), y muchos más. Pero no puedo hablar mucho de ellos porque solo los he mirado de lejos.

Posted at 02:50AM Dec 13, 2004 by Ricardo in Informática  |  Comentarios[1]