Java vs Ruby

Este post es absolutamente viral así que no esperen demasiados fundamentos técnicos, el tema es que lo leo y aún no lo creo, están realizando el llamado a presentar charlas para la RubyConf Uruguay 2011 y en el proceso te disparan "charlas inspiradoras que demuestren por qué ruby y el ecosistema circundante son una mejor alternativa que otras tecnologías (*ejem* Java *ejem*)." WTF??, y estos que se traen, vamos, no se porque me gasto en enojarme con estos trolls, pero es que no entiendo a que viene esto, yo mismo dije que me gustaban las comparaciones de esta herramienta vs otra, pero un palo así gratuito es que no lo veo.

Esta tendencia de atacar a Java desde la comunidad Ruby es que ese torna molesta a más no poder, es como un capricho impertinente, como viene con ideas nuevas todo lo otro esta desfasado, pasado de moda, algo que no vale la pena invertir tiempo ni esfurzo en usar o aprender.

Es verdad que Rails (que no es lo mismo) puso sobre la mesa una nueva manera de ver las cosa en esto del desarrollo web, no por nada tenemos frameworks tanto en Java (Groovy con Grails principalmente pero hay otros ) como en mi querido PHP (CakePHP creo el más representativo) toman esas ideas y la hacercan a estos lenguajes u otros, pero el universo es acotadísimo, es que si te sales del desarrollo web difícilmente alguien te mencione Ruby, todo lo contrario a por ejemplo Python, doy fé de que tengo varios compañeros  que hace años trabajan haciendo scripts de servidores y jamás hicieron una web, es más, esa es una de las cosas que me enamoraron de Python, la capacidad de ser multiuso, lo usamos para todo y el abanico de áreas donde se aplica es diverso a más no poder, unos para web con Django y otros en aplicaciones que ni siquiera tienen interfaz gráfica, y no me recuerden que PHP no es solo para web porque existe PHP-GTK, no estoy hablando de bindings aquí, me refiero a sus hambientes naturales.

Esta actitud la veo desenfocada, la gente que recién entra en esto puede llegar a tener la mala idea de que solo hay una forma cool de hacer las cosas, no se, es como que tienen que aderezar la herramienta con un toque de ideología fundamentalista, y si parece que exagero al menos no me pueden discutir que esto de enfrentarse al resto de soluciones en Ruby ya parece hábito, de puro necio me traigo un par de videos con esa onda Apple vs Microsoft y demás.

En fin, no voy a mostrar músculo pero es que no puedo evitarlo, solo hablar del mundo SOA, sobre las más de 300 JSRs, ya sé que cantidad nunca equivale a calidad pero demuestra que hay mucha gente detras de esto, mucha industria empujando este muerto a pesar de los palos en la rueda de Oracle, solo menciono que con seguridad el banco a traves del cual cobras el sueldo, la agencia de pagos donde lo gastas o el ISP que te permite leer estas líneas tienen en toda o parte de su infraestructra algunas líneas de Java, y te aseguro que no son pocas, dudo que se pueda decir lo mismo de Ruby.

Y sigo, existe algo como esa gran desconocido que es JWS en Ruby?, si aterrizamos a desktop el desarrollo multiplataforma real, no olvidemos tampoco que las apps de Android se desarrollan básicamente en Java, o las demás aplicaciones de peso pesado, solo aceptaría que viniese alguien de .NET o los dinosaurios de SAP a generar controversia, pero seguro que no un fanboy de Ruby, en fin, para el que solo tiene un martillo todo son clavos, me quedo con una frase que leí y por lo cual Ruby on Rails y esa magia, perdón: "convención por sobre configuración" aunque útil bien usada, me genera un poco de rechazo:

- No sabes lo que estás haciendo, pero funciona.

- No sabes lo que estás haciendo, y además no funciona.

No es que en Java no me haya perdido más de una vez, pero por lo menos aplica aquello de "en Java es difícil hacer las cosas mal, en Python es fácil hacerlas bien", creo que es como dice mi compañero, es fácil pegarle a Java, no tanto a Python, más si hablamos de web donde las carencias son muchas y el desarrollo generalmente pesado, lo reconozco ya que no por nada existe GWT, que si bien es fabuloso nace para facilitar la transición de desarrolladores Java a esto de la web 2.0 (cliché feo si los hay, pero nos entendemos) o por lo menos la gran mayoría de sus usuarios así lo usan.

Es que ni siquiera se comparan, el que desarrolla web difícilmente opte por Java, y el que desarrolla con Java seguramente no se meta a crear sitios, hay alternativas más baratas, simples, rápidas y creativas de hacer las cosas, y acepto que Ruby es una de las mejores, pero marearse con los aplausos creo es demasiado.

Bueno, hasta aquí llegue, si buscan fundamentos más técnicos adjunto un par de enlaces interesantes, para lo viral ya tenemos este post, ahora me es más fácil tomármelo con humor (mentira, sigo ofuscado, pero soy tolerante).

Ruby vs Java

Steve Jobs y mis sensaciones encontradas

Los que me conocen saben que me caen bastante mal los productos de Apple, su política y sobre todo la personalidad de Steve Jobs, un personaje de esos que es preferible no tener como jefe, es más, me parece patético como los desarrolladores aceptan esas condiciones lamentables a cambio de poder estar en la App Store, si si, ya lo sé, si tienes demasiados principios no se llega muy lejos en esto de la venta del software, si no me crees pregúntale a mi jefe que vendió un CRM que solo existía en el papel, por eso prefiero estar podríamos decirle en el lado ¿bueno, romántico?... no, mejor llamarle el lado oscuro de la fuerza, picando código, investigando, atento a ese cambio de versión que deja obsoleto todo lo anterior y te obliga a releer de nuevo la documentación, más difícil sí, pero mas prometedor también, imposible no dejarse atrapar, lejos de los departamentos de venta y soporte al cliente (ufffff!!, perdón, me dejé llevar).

Volviendo al tema del post, es increíble con internet lo fácil que es formar una opinión de alguien sin siquiera conocerle personalmente, mejor dicho siempre fué fácil (si no no existiría la política) y hasta natural, pero hoy tenemos info hasta de sobra, así que las posibilidades se multiplican, por eso en el caso de Jobs valoro posts como este en que opinan de primera mano, valioso para reafirmar mis convicciones de que el tipo apesta.

Ahora con la noticia de que renuncia a su puesto de CEO en Apple, y sin creerme aún los comentarios ridículos (ej:  "en la palabra genio deberia ir su foto al lado en el diccionario", otro: "estoy al borde de las lagrimas, espero que se mantenga la compañía #PapaJobs"  y este ya me superó: "Tim no decepciones a tu amigo Steve, que el dinero y el poder no te cieguen que tu mirada sea al futuro, aun tenemos la dicha de tenerlo a nuestro lado y eso ya es bastante. Que Dios te bendiga Steve Jobs"), como hay gente tan hueca que habla del tipo como si perdieran un familiar o peor?, en fin, me puse a buscar un poco de información más detallada, escuchar una charla o un discurso a ver que tanto puede decir, y aquí es donde me cambia un poco la idea que me había hecho del fulano, solo un poco quizás pero lo suficiente para volver a recordar que realmente no sabemos nada de nadie, ya sé, demasiada filosofía o la madrugada me está afectando, por eso les dejo este video y solo comento que hacía tiempo no prestaba tanta atención a un discurso.

Doodle Día de la Independencia de Uruguay

Imposible no mencionar el Doodle del 25  de Agosto celebrando el día de la Declaratoria de la Independencia uruguaya, está compuesto por un par de flores de Ceibo y un cintillo con el nombre del país, todo con un aire medio vintage.

En el noticiario mencionaron que millones se habían enterado de nuestra celebración gracias a Google, cosa que dudo ya que solo aparecía en la versión uruguaya del buscador, tanto en .ar como .br no estaba, me faltó comprobar si en la .com sucedía lo mismo.

Otra cosa es que al clickearla el primer resultado que arroja es del sitio www.redargentina.com, una pena si lo que queremos es que no nos confundan con los argentinos pero bueno, todo no se puede pedir.

Por último un comentario, este tipo de tonterías son las que marcan diferencia en la forma de pensar de las empresas, no en vano están donde están.

Slide Secrets of the GWT

Comparto un slide diferente sobre GWT de los muchos que hay ya que toca temas que otros más básicos pasan por alto, aunque un poco largo (son 80+) solo es una muestra de algunos tópicos interesantes así que imagínense el mundo que hay detrás de esta herramienta, ya voy más de un año y todos los días aprendo algo nuevo, para no aburrirse.

Secrets of the GWT

GWT Command para ejecución secuencial

Con GWT hay que estar atentos al hecho de que la programación esta dirigida por eventos y de manera totalmente asíncrona, por lo que no solo debemos basarnos en ellos para hacer fluir la aplicación sino que tampoco podemos fiarnos de que la lógica que necesitemos haya sido correctamente implementada por las sentencias anteriores.

Precisamente esto mismo me paso al realizar una serie de métodos secuenciales: la lógica necesaria para pasar al siguiente método aún no estaba disponible, por lo que al avanzar la cadena de ejecución fallaba miserablemente ya que no verificaba que un paso estuviera totalmente finalizado para avanzar al siguiente.

Una posible solución es que al ejecutar un método si todo esta correcto invoquemos el próximo, pero no queda muy prolijo que digamos, fácilmente podemos tener una ensalada de llamadas por doquier, ni hablar si queremos cambiar el flujo de la aplicación, suerte en pila.

Una solución que da buenos resultados es utilizar los Comandos, con ellos es posible encapsular determinada lógica y luego ejecutarla a demanda, si a esto lo aderezamos con iteradores y ArrayLists, la cosa empieza a tomar otro color, veamos un ejemplo completo y luego lo diseccionamos:

package com.myPackage.client;

import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;

import com.google.gwt.user.client.Command;
import com.google.gwt.user.client.Window;

public class DemoComandos {

	private List<Command> commandsStack = new ArrayList<Command>();
	private Command command_01, command_02;
	private Iterator<Command> cmdIterator;


	public Comandos(){
		loadCommandsStack();
		run();
	}
	

	private void loadCommandsStack(){

		command_01 = new Command() {
			@Override
			public void execute() {
				
				boolean ok_01 = true;
				if(ok_01){
					run();
				}
				else{
					Window.alert("error comando 1");
				}
				
			}
		};

		
		command_02 = new Command() {
			@Override
			public void execute() {

				boolean ok_02 = false;

				if(ok_02){
					run();
				}
				else{
					Window.alert("error comando 2");
				}
				
			}
		};
		
		
		commandsStack.add(command_01);
		commandsStack.add(command_02);
		cmdIterator = commandsStack.iterator();
	}
	
	
	private void run(){
		
		if(!cmdIterator.hasNext()){
			Window.alert("no hay mas comandos");
		}
		else{
			cmdIterator.next().execute();
		}
	}
	
}

Veamos por partes, la idea es encapsular nuestra lógica en comandos y agrupar estos en una lista, para mantenerlo simple dentro de la ejecución de estos no llamaremos métodos externos pero es lo más recomendable para separar la lógica de las sentencias y tenerlas definidas aparte.

Al crear una lista de comandos no solo unificamos ya que ahora todos son del mismo tipo, sino que podemos verificar que un paso esta completo antes de llamar al siguiente, pera hacerlo dinámicamente creamos un iterador que sea invocado por los propios métodos si estos finalizan correctamente, en caso contrario la aplicación se detiene ya que cortamos la cadena de llamadas. Ahora en detalle:

	private List<Command> commandsStack = new ArrayList<Command>();
	private Command command_01, command_02;
	private Iterator<Command> cmdIterator;

aquí creamos la lista que contendrá nuestros comandos, la definimos del tipo ArrayList para manejarlos mejor, luego creamos los comandos y por último definimos un iterador, no lo inicializaremos hasta tener cargados los comandos en la lista.

public Comandos(){
        loadCommandsStack();
        run();
    }

Por sencillez ejecuto en el constructor el método para la carga de los comandos, solo agrupa esta operación para mantenerlo conciso pero podemos colocarlo en cualquier lado, lo hacemos así:

command_01 = new Command() {

	@Override
	public void execute() {
		// aquí ejecutamos la rutina o llamamos a un método aparte
		// si todo es correcto invocamos el método run() y continuamos

			boolean ok_01 = true; // simulamos que todo fué Ok
			if(ok_01){
			    run();
			}
			else{
			    // en caso contrario la aplicación se detiene
			    Window.alert("error comando 1");
			}
				
		}
	};

Como mencionaba para agregarle flexibilidad a la ejecución de la pila de llamadas agregamos los comandos a un ArrayList e inicializamos el iterador:

commandsStack.add(command_01);
commandsStack.add(command_02);
cmdIterator = commandsStack.iterator();

Ahora lo interesante, el iterador posee un método hasNext() que nos indica si hay un comando próximo cargado a ejecutar, si no es el caso quiere decir que completamos la pila de llamadas, este lo encapsulamos en un método run(), al llamarlo por primera vez dispara la secuencia de ejecución, luego esta es mantenida por los resultados de los siguientes métodos, es decir, si estos se efectuan correctamente invocan sucesivamente run() continuando la secuencia, si ocurre un error la cedena de llamadas se detiene y si no todo concluye correctamente.

private void run(){
	
    if(!cmdIterator.hasNext()){
        Window.alert("no hay mas comandos");
    }
    else{
        cmdIterator.next().execute();
    }
}

Inclusive podemos tener una clase maestra que contenga un metodo run()  general y clases inferiores más específicas con la misma estructura, éstas al concluir sus comandos locales si tienen una referencia a la clase maestra pueden invocar al run() general en vez del local y continuar la pila de llamadas a otras clases inferiores.

En mi caso utilizé este planteo con una clase maestra llamada Init que invoca varias clases menores que realizan tareas específicas como chequear la conexión, crear la GUI, obtener JavaScript onDemand u otros, cada una tiene una referencia a Init que luego de realizar todos sus comandos ejecutan Init.run() y pasan la posta a la pila de llamadas contenidas en otra clase.Otra ventaja que vuelvo a mencionar es la facilidad para cambiar el flujo de la aplicación, basta con comentar el commandsStack.add(myCommand) que queramos y todo seguirá fluyendo normalmente salteándose ese paso, creo que solo aporta ventajas así que vale la pena probarlo.

Interfaces vs Clases abstractas

Cuando usar una u otra es algo que no tenía muy claro y tuve que despejar dudas, por si les pasa igual comparto esta útil tabla que seguro nos ayuda a decidir un poco mejor, muy recomendado el enlace con explicaciones y sugerencias.

Enlace: cuando interfaces o clases abstractas

jQuery vs MooTools

Trabajando con MooTools me ha pasado varias veces que me digan "eso en jQuery es más fácil", o la tan molesta "jQuery tiene un plugin que hace eso y mejor".

El caso es que para mi no hay punto de comparación, jQuery es un toolkit y MooTools un framework, que no son lo mismo. Un toolkit te da toda una serie de cosas prefabricadas para no tener que reinventar la rueda una y otra vez, y seguro mucho mejor que como lo haría uno mismo (a menos que seas un JavaScript ninja y en cuyo caso dudo que leas este blog), ya en la página de jQuery lo primero que se lee es "jQuery is designed to change the way that you write JavaScript", todo dicho.

Por otra parte un framework es una serie de utilidades a más bajo nivel que te proporcionan facilidades para hacer las cosas, posibilidad de agregar propiedades interesantes que el JavaScript nativo no tiene y hacer un poco más llevadero las carencias del lenguaje -que son muchas reconozco, ¿un trim nativo es mucho pedir?- pero no cambiará radicalmente mi forma de hacer las cosas.

Este razonamiento se lo hice ya a varios compañeros, no se, jQuery tiene ese olor a RoR, a cosa prefabricada que es para utilizar de determinada manera y no pedirle nada raro, en fin, impresiones mías tal vez, soy de la vieja guardia definitivamente :). Como anécdota un compañero de trabajo luego de utilizar  jQuery en un proyecto nada trivial termino odiándolo y optó por Dojo, otro que aunque no muy popular tiene unas posibilidades bien interesantes, eso sí, te advierto que tiene un tufillo a Java.

Este tipo de discusiones inútiles (que me encantan) sobre esta herramienta vs otra abundan bastante, no agrego más y traigo este enlace que resume muy muy bien todo esto: jqueryvsmootools.com, mejor explicado imposible. Como experiencia propia les comento que no depende de lo que quieran hacer ya que con ambos prácticamente todo es posible -cada uno a su manera claro- depende de hasta donde quieran llegar, de cuanto quieran ensuciarse las manos con JavaScript. Si estás buscando una de estas herramientas seguro que lo menos posible, pero si quieres ser medianamente bueno toca trabajar con el lenguaje a pelo, recién luego de eso te recomiendo estudies la posibilidad de optar por una u otra librería que te facilite el trabajo.

Debes aprender aunque sea lo mínimo, puede que no solo te pase que utilizas algo que no sabes como trabaja pero funciona, sino que tengas un problema y no sabes como trabaja y que tampoco funciona. Si ya pasaste esa etapa y comienzas a ver las carencias del lenguaje no dudes que cualquiera de las dos opciones son geniales, ahora sí como decía depende de cuanto quieras ensuciarte las manos: quieres algo vistoso y sin complicaciones? pues jQuery UI sin dudarlo, hay infinidad de módulos y cosas prefabricadas muy buenas. En cambio... le tomaste el gustito a JavaScript y quieres un poco más de potencia? pues MooTools entra en juego, esto no es broma ya que para utilizarla debes tener los conocimientos un poco más aceitados así que si no te gusto trabajar con JavaScript te aconsejo lo descartes. La curva de aprendizaje es más elevada y digan lo que digan siempre trabajarás un poco más, como recompensa sabrás lo que estás haciendo y porqué, y te aseguro que eso no es poca cosa, al fin y al cabo: eres un diseñador buscando un carrusel de fotos prefabricado o un desarrollador de JavaScript?, tú eliges.
Como se hace camino al andar agrego videito de un trabajo mío en que MooTools hizo la diferencia, solo para que no creas que lees a un charlatán.

Otra cosa es que quizás no estés necesitando precisamente una librería de estas y aún no lo sabes. Si lo que buscas son controles prefabricados, widgets y elementos visuales como árboles, paneles con tabs y cosas por el estilo dale un vistazo a UKI o la muy práctica Meteora, no te recomiendo Ext JS y demás monstruos ya que son muy potentes pero tienes que trabajar de la manera que indica la librería,con sus patrones y demás lineamientos, aparte por completas son pesadísimas y siempre cuidado con el tipo de licencia (nadie se fija en eso...? ah bien, pensé que era el único desprolijo).

Por otro lado quizás lo que necesites es algo que te permita estructurar un poco ese código espagueti tuyo, en cuyo caso no dudo en recomendarte Backbone.js para implementar el patrón MVC del lado del cliente, hay más opciones pero es muy madura y probada, tiene dependencias (de nuevo jQuery...) pero vale la pena probarla. Y como para no volar demasiado, empezamos con jQuery vs MooTools y ya andamos con MVC en el browser, antes de tomar una decisión siempre conviene darse una vuelta por micro.js, a veces solo necesitamos una utilidad muy concreta y mejor poner a dieta nuestro código.

Espero que este post haya sido de ayuda y no confunda aún más, siempre es bueno no quedarse en un par de opciones y te aseguro que abundan, suerte en esa selección.

Checkbox con estado indeterminado

Parece que no quedan trucos por descubrir en HTML pero este funciona incluso en IE6 , asi que de nuevo tiene poco, el caso es que los viejos checkboxes solo tienen dos estados, eso creía pero hay un tercero: indeterminado, a esta propiedad se accede solo por javascript, no podemos definirla desde el HTML, siendo su sintaxis:

var checkbox = document.getElementById("myCheckbox");
    checkbox.indeterminate = true;

bastante simple, muy útil cuando no queramos indicar de antemano ninguna opción y evitamos ese omniprescente tercer checkbox con el texto ninguna, eso si, cuidado con el valor enviado al submitar, estos siguen siendo los dos valores de siempre y por defecto tomara desmarcado.

Exceptuando Safari que lo ignoro completamente los principales navegadores lo muestran de manera similar , adjunto captura de IE6 para que vean que esto tiene su tiempo en las sombras.

Java Generics para argumentos con herencia e interfaces

Este es un ejemplo claro de esas situaciones que fácilmente podemos dedicarle tres o cuatro horas en resolverlo si no tenemos muy en claro algunas cosillas de Java, me refiero concretamente a los Generics y su uso para validar argumentos.

En GWT la herencia es constate, así como el uso profuso de interfaces, por lo que es muy habitual tener métodos que reciben este tipo de objetos como argumento, esto no es problema en si mismo, el tema es cuando tenemos varias clases diferentes que implementan herencia e interfaces en común y queremos ejecutar métodos definidos en ambas, de que tipo definimos nuestro argumento que hace referencia a todas ellas?

Pongamos un ejemplo, estamos creando una clase MiVista que extiende de Composite e implementa una interfaz definida por nosotros para asegurarnos que estén presentes ciertas operaciones, si un método X recibe este tipo de clases como argumento simplemente podemos definirlo del tipo MiVista:

// Interfaz

public interface MyInterface {
    public void hacerAlgo();
}

// Clase personalizada que extiende e implementa

public class MiVista extends Composite implements MyInterface {

    public MiVista(){
        
        // disponible por extender Composite
        initWidget(...); 
    }
  
    // requerido por implementar MyInterface
    public void hacerAlgo() {
        ...
    }
}


// Método en otra clase que recibe MiVista como argumento

public void setearValores(MiVista vista){
    vista.hacerAlgo();
}

Ahora lo interesante, supongamos que tenemos otra clase MiVistaCompact, que define otra serie de características pero también extiende de Composite e implementa MyInterface, de que tipo lo definimos a nuestro argumento vista en el método setearValores?

Si lo definimos como MiVista dejamos fuera a MiVistaCompact y visceversa, si lo hacemos como Composite nos falla ya que esta clase base no implementa MyInterface ni nuestros propios métodos, si nos referimos como MyInterface no tenemos disponibles los métodos de Composite..., y aquí es donde echamos mano de los Generics de Java.

No voy a profundizar en ellos ya que la documentación es abundante, lo que escasea son ejemplos donde lo que queremos es asegurarnos que nuestro tipo de datos posea ambas características, lo redefinimos así:

public <T extends Composite & MyInterface> void setearValores(T vista){
    vista.hacerAlgo();
}

Lo que estamos haciendo es especificar un nuevo tipo de parámetro en la misma definición del método y referirnos a este como tipo para el argumento, nuestro valor T es ahora cualquier objeto (con ciertas limitaciones) que extienda de Composite e implemente MyInterface, por eso podemos utilizarlo indistintamente para referirnos tanto a MiVista como a MiVistaCompact.
Cuidado al detalle de que solo podemos hacer uso de los métodos disponibles en Composite o MyInterface, no a los específicos de MiVista o MiVistaCompact, pero para esto hacemos un casteo y podemos referirnos a ellos asi:

	public <T extends Composite & MyInterface> void setearValores(T vista){

	    vista.hacerAlgo();  // disponible por implementar MyInterface
	    vista.isAttached(); // disponible por extender Composite

        // disponible solo en MiVista
        ((MiVista)vista).metodoXenMiVista();

        // disponible solo en MiVistaCompact
        ((MiVistaCompact)vista).metodoYenMiVistaCompact();
	}

Lo único a tener en cuenta al ejecutar estos métodos específicos es verificar que estamos recibiendo la clase que los defina, ya que en caso contrario fallará, también vale recordar que para nombrar a nuestro nuevo tipo hay algunas convenciones, copypasteo desde Oracle gentypes:

By convention, type parameter names are single, uppercase letters.
...
The most commonly used type parameter names are:
E - Element (used extensively by the Java Collections Framework)
K - Key
N - Number
T - Type
V - Value
S,U,V etc. - 2nd, 3rd, 4th types

La sintaxis básica es esta, si utilizamos varias interfaces las separamos por comas y según que implementemos las opciones se multiplican ya que tenemos además comodines y jeroglíficos varios, pero para todo eso hay muy buenas guías disponibles y una búsqueda corta seguro nos da para leer un buen rato, aunque repito, en este caso concreto me costo un poco encontrarle la vuelta, no queda otra que leerse unos cuantos tutoriales, impacientes abstenerse.

Solo para los más duros una pequeña guía: GenericsFAQ

No hagas esto

En el caso de que te haya picado la curiosidad por el mundo de los negocios en el desarrollo de software seguramente visitaste sitios de empresas conocidas para ver un poco mas de cerca de que va esto, los tipos de servicios que se ofrecen, modelos de negocio, nichos y ver en donde podemos llegar a tener alguna posibilidad en base a nuestras expectativas.

Los ejemplos buenos ya los conocemos todos, basta recordar cualquier empresa conocida, pero los malos, esos que desde el vamos no queremos parecernos ni por asomo son tanto o más interesantes, como queremos ser quizás no lo tengamos tan claro, pero estar seguros de como NO queremos ser también es vital en el proceso de visualizarnos de cara a potenciales clientes.

chantas profesionales

Precisamente es en esta línea que traigo dos ejemplos clarísimos de como en mi opinión no hacer las cosas, tanto en el planteo de la propuesta como su implementación.

Por un lado, un sitio visualmente simple pero logrado, agencia de social media, un aspecto limpio, claramente realizado por un profesional, que puede gustarnos o no, pero coherente en el planteo,  textos explicativos, descripción de servicios amena y no menos importante, tarifas a la vista, claras y sin rodeos.

Que hay de malo aquí? pues básicamente el tratar a tus potenciales clientes como idiotas, si lo que persigues es solo eso, poder atrapar un par de incautos y hacer un dinero rápido no hay problemas, eso si, largo de mi blog!.

Mirando un poco mas en profundidad empezamos a ver que la propuesta apesta y mucho, vamos, no se por donde empezar, comienzo con algunas frases:

Encontramos, mimamos, y hacemos crecer tu comunidad de clientes, el planteo típico del usuario como un producto más, el pensar que tus clientes son idiotas y se van a tragar cualquier cosa que le pongan delante, el hablar de hacer crecer una comunidad como si fuera apilar cajas en un estante, que se van a sentir atrapados por tu mensaje y convertirán en seguidores y compradores compulsivos de tu loquesea.

Somos especialistas en 2.0, y en la 3.0 si nos aprietan, bueno, definitivamente vamos mal, el peor cliché interpretado de la peor manera, obviamente dirigido a quienes lo de 2.0 y 3.0 es un concepto vago que hay que incluir como sea, aderezado por ese si nos aprietan que me da toda la pinta de que todo es conversable, incluso que me cuiden el perro el fin de semana.

Rematando la frase anterior tenemos un La vida es genial totalmente descolgado, acompañado por ese muñequito sacando la lengua con un descaro sublime, solo le falta una flecha con el texto "cagador profesional", bueno, ya rematando esta joyita: No hay monstruos aquí. Sobre todo porque contratarlos sale caro, y no agrego más nada , solo menciono este post anterior y nos entendemos, en definitiva este tipo de planteos son inmantenibles en el tiempo, no se puede confiar en que los clientes siempre serán tontos.

hay que jugársela en serio

En la otra punta tenemos el ejemplo totalmente contrario, un sitio que parece serio, la propuesta tiene valor y se intenta dejar claro una profesionalidad a toda prueba, y digo se intenta, porque lograrse.... no se logra.

Me refiero a PI, que dejando de lado el diseño, que es ese tipo de cosas que hay que dejar a los que saben, así sea un amigo que maneje Photoshop, lo que mas rescato es que no basta con ser profesionales, también hay que parecerlo.

De buenas intenciones esta lleno el camino al infierno, por lo que no importa que tanto nos explayemos en detallar nuestras capacidades, un dominio gratuito es suficiente para dinamitar nuestra imagen, nada peor que una casilla de dominio gmail, yahoo o hotmail suena tan informal para una empresa, y no hablo solo de costos, supuestamente trabajamos con Internet, ese tipo de cosas dejémoslo para las ONG's con pocos recursos y buenas intenciones, y es precisamente este aspecto el que condensa todo lo anterior: no te tires al agua si no tienes los medios mínimos adecuados, así no sea más que un dominio propio. 

Quizás suene duro, pero si estamos tratando de montar "una empresa" no podemos alojar el site en algo similar a un dominio genérico, hay que apostar en serio, si no nos lo creemos nosotros mismos menos lo creerán los potenciales clientes, sin mencionar que ese "Make a free website" lo dice todo, tampoco esos enlaces sin ton ni son a Facebook son necesarios, ya están en nuestra web, no es necesario redirigirlos a ningún lado, aquí es donde nos la jugamos a convencer al potencial cliente, no utilices la misma plantilla sosa que pusieron todos ni lo hagas más complicado de lo nescesario, pero repito: no utilizes dominios gratuitos, no utilices casillas genéricas, hoy día hay alternativas muy económicas que nos pueden dar un resultado mucho más profesional por poco dinero, si tu propio site apesta, quien garantiza mínimamente que tu trabajo no lo hará?, y si no puedes montar algo que paresca una empresa, no lo llames así entonces, ofrécete como freelance para iniciar y luego vas mejorando.

En fin, como criticar es gratis me he despachado con este par de ejemplos, no es que si no montamos un sitio rompedor de esquemas no nos va a resultar, lo que hay que hacer es un trabajo esmerado, claro, que transmita un mensaje simple, sobre esto otra muestra: la web del producto donde trabajo, a alguien le queda claro a primera vista de que se trata?, hay frases muy tentadoras, pero creo que al final abruman y no se transmite un mensaje único, simple y directo del porque elegirnos, lo que demuestra que no es un tema de recursos económicos, si la idea no esta bien transmitida no importa el diseño, no importan los efectos y botones de "me gusta", estamos perdiendo puntos desde el arranque.
Como contrapartida menciono a Little Workshop y Filament Group, un par de casos a mi parecer acertados, creo que cualquiera puede decir a la primera a que se dedican estos tipos.

Enlaces: agencia de social media, PI , Little Workshop, Filament Group

Guía visual sistemas NoSQL

Evaluando diferentes alternativas a las base de datos de siempre, específicamente las conocidas como NoSQL, lo primero que notamos es que la variedad de opciones llega a ser abrumadora (por suerte) como para instalar y probar cada opción.

Buscando un poco por ahí encontré y comparto esta interesante representación que seguro nos aclara un poco mas el panorama, ahora si lo que quieren es perderse definitivamente nosql-database.org es referencia obligada.

Enlace: Visual Guide to NoSQL Systems

Infografía evolución Android

"Una imagen vale mas que mil palabras" dicen, y las infografías son precisamente el mejor ejemplo ya que de un vistazo nos muestran un panorama completo de cualquier tema (aparte de que me gustan bastante), aquí la primera de unas cuantas por venir: The Android Story