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