En el 2005 vimos cómo la introducción de XMLHttpRequest, más conocido como ajax, cambiaba las reglas del juego y elevaba las posibilidades del desarrollo web de una forma más que considerable, propiciando la creación de herramientas que facilitaban mucho más la interacción y que, junto a otras formas no técnicas de pensar y concebir los sitios web, desataron la fiebre web 2.0.

Desde esa época hemos visto aparecer un sinfin de nuevas tecnologías tanto de frontend como de backend que nos permiten hacer crecer nuestros sitios web usando buenas prácticas y con relativamente pocos recursos, al menos muchos menos que los que necesitábamos hace diez años.

De entre todas las opciones que van apareciendo, las tecnologías que más me han interesado recientemente son las permiten implementar patrones mvc o mvvm con javascript, separando totalmente el html + css + js que usamos en el frontend del backend.

Algunas de estas tecnologías aparecen motivadas por técnicas usadas en los frontend de Facebook o Tuenti por ejemplo, que cargaban diferentes partes de su contenido de forma asíncrona al cambiar de sección y sin refrescar todo el layout, mejorando la experiencia de usuario notablemente.

Existen varias opciones: javascriptMVC, knockout y backbone, entre otros. Yo me he decidido finalmente por backbone, básicamente porque me parecía más cercano a la forma que tengo de trabajar con soluciones de frameworks mvc para web y he visto que cuenta con un gran apoyo por parte de desarrolladores frontend.

No hace falta tener mucha experiencia en el desarrollo web para ver las tremendas posibilidades que ofrece backbone en cuanto arquitectura y escalabilidad.

La ventaja más evidente es que nos libramos de tener vistas html mezcladas con código de servidor en el backend. Las vistas se procesan y parsean en el cliente, con javascript, pudiendo usar cualquier motor de plantillas para javascript como mustache.

Mustache parece la mejor opción ya que cada vez más se viene asumiendo como estándar la sintaxis de django para templates html, que se ha adoptado en motores de plantillas de otros lenguajes como en el caso de php en el que disponemos de Twig (usado en Symfony2) o Haanga. Es importante esto si queremos dar compatibilidad a clientes que no tengan habilitado javascript en el navegador, una buena práctica que en algunos casos puede ser totalmente necesaria aplicar.

Esto nos permite tener en un sólo directorio y servir directamente como estático el código html de todas las plantillas de la aplicación web, con las ventajas evidentes de que los maquetadores y diseñadores puedan trabajar con ellas directamente sin tener que conocer el lenguaje de servidor que la web está utilizando, además de poder servir todo el html como estático, reduciendo los recursos necesarios de procesador en nuestra aplicación web y pudiendo cachear todo desde en el cliente con HTTP Cache, usando las directivas de caducidad max-age y s-max-age.

Las plantillas pueden recibir información a través de un objeto json, que normalmente incluirá el Modelo. El modelo se puede integrar muy fácilmente con nuestra API de servicios en el backend, permitiéndonos hacer un CRUD desde el cliente de forma transparente y sin importar la tecnología o tecnologías escogidas en el backend.

Como en todo buen framework MVC para web, disponemos de un router en el que podremos definir las urls de nuestra aplicación siguiendo un esquema de urls ajax basadas en hashbang (utilizando el símbolo #) perfectamente indexable por buscadores.

Cada ruta dispara un evento al que podemos suscribirnos para cargar el contenido necesario en el layout de cada vista. Estas peticiones se hacen mediante ajax, por lo que podemos pensar en las siguientes ventajas:

Primera ventaja: Utilizando correctamente HTTP access control podremos distribuir como queramos, y en base a nuestras necesidades, cada recurso o parte de nuestra aplicación en servidores, clusters o servicios cloud distintos, teniendo cada uno en su propio dominio o subdominio.

Al poder ser nuestro frontend totalmente estático (se basa en html, js y css), podemos utilizar frontales web que únicamente sirvan html o incluso servicios de storage cloud, como Amazon S3 con CloudFront, teniendo distribuida nuestra aplicación geográficamente con un coste inicial bastante bajo si tenemos implamentada una buena estrategia de caché en el cliente y en el backend.

Segunda ventaja: Podemos utilizar diferentes tecnologías para cada parte de nuestra web. Esto lo podíamos hacer ya utilizando Edge Side Includes a nivel de proxy con Varnish por ejemplo, ahora no es necesario aunque podría ser completamente complementario.

Tercera ventaja: Nos obliga a desarrollar la capa de servicios desde el principio, teniéndo nuestra arquitectura frontend-backend desacoplada, respetando totalmente REST, permitiéndonos de una forma cómoda en un futuro usar clientes diferentes al navegador sin tener que plantear hacer una api como una problemática adicional.

Cuarta ventaja: Podemos usar el histórico de Backbone o directamente el History de HTML5 para cachear la navegación del usuario en el navegador, haciendo cosas tan interesantes como el Tree Slider de Github.

Backbone nos da más opciones y herramientas útiles para el desarrollo con javascript, pero creo que las que he mencionado son lo suficientemente interesantes como para motivarnos a pensar en otras formas de plantear nuestros sitios web en el futuro.

Incluso en algunos casos podremos plantear prototipos de nuestros productos, perfectamente testables en html, antes de tomar ninguna decisión tecnológica de backend e incluso antes de tener que desarrollarlos.

Las posibilidades son increíblemente atractivas.

PD: El título es sólo para llamar vuestra atención, actualmente prefiero el sexo a backbone.js.

Es una gran noticia que se considere documentar cada componente para final de año, y va muy en la línea de lo que comentaba Fabien en su blog sobre qué es Symfony2 y qué no.

Fabien quiere dar mucha importancia a los Componentes ya que es la única forma de que Symfony2 esté presente en el mayor número de proyectos posibles.

En mi opinión, y como ya he expresado en otras ocasiones, Symfony2 es un framework enorme, que intenta solucionar demasiada problemática, y en mi experiencia, cuanto más grande sea la aplicación y cuanta más problemática se intente cubrir, más complejo después será encontrar un posible fallo en entornos que no se hayan tenido en cuenta para la misma. En aplicaciones orientadas a internet, el entorno de sistemas puede que no sea el estándar LAMP, sobre todo si nos enfrentamos a webs de alto tráfico.

Otro problema, que para otros es una virtud, es que el framework intenta hacer configurable todo, con el objetivo de que los proyectos sean lo más automatizables, mantenibles y dotarles de una capacidad de reutilización en la que llegue a ser innecesario tocar una línea de código. Esto en teoría, suma más horas de desarrollo al principio y luego hace el mantenimiento más barato. Sin embargo, en proyectos que se orientan a internet, la teoría queda muchas veces en evidencia.

Hay que tener en cuenta que el mundo php5 no es como el mundo .net o java. Es complicado que desarrolladores web de php, aun con experiencia, se conviertan tan puristas de repente (más teniendo en cuenta los presupuestos tan ajustados económicamente y en tiempo que se barajan en proyectos web para internet) como para adoptar y entender todas las buenas prácticas que te obliga a usar Symfony2.

Para la mayoría de desarrolladores, el disponer de componentes, no les obliga a comprender el funcionamiento de todo el framework y pueden usarlos en desarrollos más simples o que ya tengan hechos.

De hecho, viendo estas direcciones en el proyecto Symfony2, en mi propio proyecto Leophard, un framework mvc ligero para php que por diversas razones de peso he tenido que retrasar su desarrollo, usaré algunos de estos componentes como el EventDispatcher, UniversalClassLoader, el Routing, Pimple o el HttpFoundation, que son ligeros y resuelven problemática muy importante del proyecto.

La gente de Drupal está usando algunos de estos componentes también en la próxima versión de su cms.

Concretamente en el área de redes, es muy útil saber cómo hacer subredes o saber a qué red pertenece una ip en concreto haciendo operaciones AND binarias con las máscaras y direcciones a evaluar.

Refresco de conceptos

Las direcciones ip se clasifican en lo que llamamos “clases de red” según el número de hosts que dichas redes puedan soportar (siendo un host un ordenador, impresora o cualquier cacharro que conectemos a dicha red).

Usamos comúnmente las siguientes clases de red:

• Clase C, la más común, que puede tener hasta 254 dispositivos host conectados.
• Clase B, que puede tener hasta 65.534 dispositivos host conectados.
• Clase A, que puede tener hasta 16.777.214 dispositivos host conectados.

Para saber de qué clase es una red o una dirección ip, usamos máscaras de red. Las máscaras de red se componen de 4 fracciones y en cada una podemos rellenar hasta 8bits.

En una dirección de clase C tendremos un total de 24bits, en binario podríamos expresarla entonces como 11111111.11111111.11111111.00000000 (24bits = 8bits + 8 bits +8bits + 0bits) y en decimal como 255.255.255.0 .

No necesitamos escribir la máscara completa para indicar que la ip 192.168.1.2 es de clase C por ejemplo, bastaría con indicar al final de la misma que su máscara tiene 24bits de la siguiente forma: 192.168.1.2/24 .

En el resto de clases, tendríamos 8bits para las redes de clase A y 16bits para las de clase B.

Sin embargo, aunque en entornos domésticos o de mediana empresa se usen estas clases de red para crear las redes a las cuales se conecten los ordenadores, servidores e impresoras de la organización, en una empresa que provee servicios de internet o que tiene muchos departamentos, le es muy útil poder partir esas redes en subredes.

Hay escenarios en los que nos interesa tener varias subredes con un número concreto de equipos en cada una de ellas. De esta forma aislamos a qué recursos puede acceder uno o varios equipos de una determinada subred.

Para hacer subredes lo que se suele hacer es usar máscaras de red personalizadas. Por ejemplo, si tenemos la ip 192.168.129.3/18, tal y como hemos visto antes sabemos que su máscara de red tiene 18bits, es decir en binario 11111111.11111111.11000000.00000000 y en decimal 255.255.192.0. Ahora bien, al no tener una máscara de 16bits o de 24, ya que tenemos una fracción de las 4 sin rellenar totalmente por bits en la máscara de subred, no podríamos decir que esa ip pertenece a la red 192.168.129.0/24, ya que esta sería una dirección de red de clase C y la nuestra no pertenece a esa clase.

Para saber a qué dirección de red pertenece tenemos que hacer una operación AND a nivel de bits binarios entre la dirección ip y su máscara de red.

En este caso la operación quedaría así:

Al final deducimos que la dirección de red a la que pertenece la ip 192.168.129.3 es 192.128.0.0.

También podemos realizar operaciones para saber la cantidad de dispositivos que se pueden conectar a una determinada red o calcular una red que pueda albergar un determinado número de equipos.

Para calcular el número de dispositivos usamos la función 2^x -2 donde X es la cantidad de bits disponibles en una subred es decir, el número de ceros que quedan al final de la misma. En la máscara de 18 bits que hemos usado en el ejemplo (11111111.11111111.11000000.00000000) serían 14 los bits disponibles (32bits posibles totales – 18 que estamos usando).

Aplicando la fórmula nos daría un total de 16.382 cacharros que podríamos conectar a nuestra red.

Utilizando php para realizar estos cálculos.

En php disponemos de una serie de funciones y operadores que nos hacen muy sencillo realizar cálculos de este tipo y automatizar este trabajo que de hacerlo manual nos haría consumir tiempo y estaría propenso a errores.

En este escenario utilizaremos tan sólo dos cosas:

• La función ip2long para pasar una dirección ip separada por puntos a su representación numérica para poder realizar operaciones posteriores con ella.
• La función decbin, para pasar de decimal a binario.
• El operador bitwise & que es el que realizará la operación AND a nivel binario.

Volviendo al anterior ejemplo, podemos saber a qué dirección de red pertenece la ip 192.168.129.3/18 de la siguiente forma:

$ip_en_binario        = decbin( ip2long( "192.168.129.3" ) );

$mascara_en_binario   = decbin( ip2long( "255.255.192.0" ) );

$resultado_en_binario = $ip_en_binario & $mascara_en_binario;

echo long2ip( bindec( $resultado_en_binario ) );

Tal y como esperábamos, el resultado que nos devuelve este script es 192.168.128.0, que es la dirección de red a la que pertenece la ip 192.168.129.3/18.

Con este sencillo ejemplo vemos el juego que le podemos sacar a todo esto.

Por un lado se ve de forma clara que si queremos saber a qué red pertenece una ip dada de todas las que tenemos en nuestra empresa, las cuales almacenamos en una base de datos, bastaría con pasar a binario cada ip y compararla al resultado de la operación efectuada en el ejemplo.

Pero lo realmente útil es saber que podemos guardar en base de datos la dirección directamente en binario, ahorrando un espacio importante en la tabla al evitarnos usar un campo tipo texto (clave para el rendimiento con índices en motores como inndb de mysql) y realizar directamente la búsqueda contra el registro que necesitemos.

También podríamos conocer muy fácilmente con la formula que hemos visto antes, el número de equipos que puedo conectar a una red seleccionada y en base a las ips que podríamos tener registradas, los “huecos” e ips disponibles para los equipos nuevos que tenga que conectar a esa red en un futuro.

Pensaba que podría tener una primera versión para Septiembre pero como todo lo que puede complicarse se complica, no voy a poder alcanzar esta meta.

En parte no voy a poder alcanzarla, además de por estar hasta arriba de trabajo (no he podido tomarme ni un fin de semana de vacaciones todavía), va a ser por una serie de cambios que voy a asumir en mi forma de trabajar en general a partir de ahora.

TDD

El cambio más importante que voy a adoptar es aplicar sin excusas TDD es decir, desarrollo guiado por tests. Y lo primero que he empezado a hacer es a escribir los test sin escribir todavía una sola línea de código.

Es cierto que tenía un prototipo funcional con un sistema de enrutamiento, de vistas y controladores muy básicos ya funcionando. Sin embargo, me he dado cuenta de que ningún desarrollo y en especial un desarrollo de este tipo, debe ejecutarse sin asegurarse la calidad que te permiten obtener los test unitarios, siempre que un proyecto se plantee de esta forma desde el principio.

En teoría esto debería hacerme ir más lento al principio, pero creo que merecerá la pena para obtener una arquitectura de calidad y evitar problemas en el futuro.

Ciclos cortos de desarrollo

Cuando me puse a desglosar la complejidad de un framework de este tipo, aun queriendo hacer algo simple y ligero, las posibilidades de complicarlo para intentar cubrir posibles necesidades son difíciles de ignorar.

Por suerte cada vez tengo más control sobre mí mismo acerca de evitar ser demasiado previsor para problemas que no tocan y el objetivo principal del proyecto, que es conseguir un framework ligero y ante todo simple, me ayuda en esta meta.

Dividiré el desarrollo en fases muy cortas para evitar caer en la resolución de problemas no críticos y tener cuanto antes una versión que se pueda usar aunque no cubra todos los problemas que puedan cubrir otros frameworks como Symfony o Kohana.

Propel

Desde un principio he descartado el desarrollo de un orm propio ligero, es una auténtica locura y casi prefiero hacer un gestor de conexiones para PDO que intentar hacer un orm para el mismo.

Propel desde la versión 1.3 tiene una capa orm sobre PDO que funciona muy bien y es bastante más ligera y rápida que Doctrine2. También prefiero Propel a Doctrine2 porque lo encuentro más simple y porque al menos yo, me siento más cómodo usándolo.

De Propel hay dos cosas que no me gustan: la dependencia de Phing (que tiene los días contados) y por tanto de Pear (que lo odio) junto a que los esquemas y configuraciones se escriben en xml. Para esto último me haré una implementación para que estos xml puedan generarse desde php de forma sencilla y menos tediosa.

No obstante dejaré la puerta abierta para otras opciones.

Dudas en formularios y en la vista

Sobre la vista

Tengo una duda en la vista y es que no se por qué modelo decantarme, si por el modelo de herencia de Symfony2 o por el tipo de implementación decorator que teníamos en Symfony1.x.

Por ejemplo, en Symfony 1 teníamos un layout donde cargábamos el contenido de cada controlador en una variable llamada $sf_content. En las platillas usábamos include_component o include_partial para dividir las partes de nuestra aplicación web en la capa de vista. Por defecto la plantilla asociada a un controlador era contenida en la variable $sf_content que se incrustaba en el layout que indicásemos o se devolvía si indicábamos que esa vista no tenía layout.

En Symfony2 vemos un modelo basado en la herencia de vistas, algo que podemos encontrar en otros framework como asp.net mvc. En cada vista se indica el parent, en el que se ha definido un esqueleto de bloques, y se escribe el código html que su parent debe insertar en cada bloque.

Yo prefiero la opción que teníamos en Symfony1.x, pero no las tengo todas conmigo si este es el mejor modelo.

La vista usará la última versión de Smarty, que actualmente es el motor de plantillas más extendido y que más desarrolladores php conocen.

Sobre los formularios

Este es un tema que tengo que analizar con calma pero tengo una cosa clara: quiero que sea simple crear y validar formularios.

En la creación y validación tengo que pensar muy bien cómo hacerlo para evitar que el programador tenga que escribir mucho código o al menos tanto como en Symfony1.4.

Quiero simplificar el proceso a la hora de recibir los datos, hacer el binding y comprobar si es válido.

En symfony deberíamos hacer lo siguiente en el controlador:

• Comprobar el tipo de método http para procesar el formulario en caso de que sea POST (en el más del 90% de los casos)
• Hacer un $form->bind($array); para obtener y filtrar los datos
• Hacer un $form->isValid() para comprobar que el formulario es válido.

Yo prefiero tener algo así en un sólo paso:

• $form->validate(Request $request, $method=”post”);

Otra opción es que los formularios se validen en el mismo request de la petición, de una forma similar a como se hace con el request validation de asp.net mvc 3.

Es decir, la validación se haría en el mismo request del action del fomulario y no habría que ejecutarla de forma explícita en el controlador.

Tengo que dar unas vueltas a todo esto, sobre todo a la hora de crear los widgets y validadores.

Este será el último post de este tipo sobre Leophard que haga en este blog, intentaré montar un sitio web en las próximas semanas dedicado al proyecto.

Os adjunto el vídeo, pero no dejéis de leer el post original, muy inspirador y además regalan pegatinas!!

Aquí van otras opiniones:

To me, design is… from Vostok on Vimeo.

Utilizar un framework como Symfony

Para mí, adoptar Symfony como framework ha sido una de las mejores decisiones que he tomado en mi historia como desarrollador web.

Symfony es un framework excelente, muy personalizable, extendible y automatizado que además, te enseña a programar bien.

¿Qué es programar bien? Para empezar, usar patrones de diseño, aprovechar todas las ventajas que ofrece la POO al máximo posible ademas de, por encima de todo, evitar repetirte.

Symfony no es el único framework que permite esto, también Zend es otra opción excelente.

Sin embargo, en los últimos meses he tenido la oportunidad de participar en proyectos fuera de las necesidades comunes. Ya sea por rendimiento o por la naturaleza de la aplicación, teníamos que especializar bastante funcionalidad del core de symfony, aprender casi de memoria los parámetros de los archivos .yml de configuración o incluso, extender el framework para que cumpliese con los requisitos de la arquitectura de sistemas.

Esto supone en algunos casos muchas horas más que en un proyecto de php digamos “sin framework”, pero una vez conseguido el tiempo se reduce en la próxima ocasión que te encuentras con el mismo problema, si lo haces.

Hay pequeñas situaciones en las que debemos invertir tiempo para desarrollar pensando en el framework para obtener funcionalidad que sería trivial en un entorno sin framework. Sin embargo en general compensa porque nuestro código queda totalmente integrado con una arquitectura que tiene un nivel muy alto de calidad.

Pero otro problema aparece cuando de repente se anuncia una nueva versión del framework y empiezas a ver que todo lo que has aprendido en la versión 1, es completamente distinto en la versión 2. Esto es algo bastante costoso de asumir para los desarrolladores ya que algunas de las ventajas más importantes de utilizar un framework son precisamente las que en este caso, se ha puesto en contra de todos nosotros:

1. Todos habíamos aprendido a programar en nuestro día a día pensando en symfony, con sus configuraciones y la nomenclatura de sus clases.
2. Todos conocíamos perfectamente los nombres de los directorios, archivos de configuración y comportamientos de los métodos que se usan en las clases más importantes del framework, así como dónde teníamos que encontrar los recursos de documentación necesarios para nuestro día a día.
3. Habíamos desarrollado código reutilizable como plugins, concepto que desaparece en la próxima versión.

Estos puntos son los más negros que quizá se puedan encontrar a la hora de decidirse por un framework que no sea uno nuestro propio. Sin embargo y a pesar de los mismos, creo que en general es una decisión muy buena el optar por un framework de desarrollo.

Utilizar un CMS como WordPress

Otra opción que existe es optar por un cms como WordPress. Hablo de WordPress porque es el que más conozco a “bajo nivel”. Si estás acostumbrado a utilizar un framework como Symfony, tienes la sensación al desarrollar bajo una plataforma para nada óptima (en cuanto a rendimiento se refiere) y que se salta a la torera cientos de recomendaciones sobre cómo desarrollar en un entorno POO.

Sin embargo el sistema funciona para la mayoría de proyectos medios o básicos, los diseñadores están encantados con él y ya lo conocen debido a la facilidad de uso de su sistema de themes, funciona sin tener que tocar prácticamente nada en la mayoría de plataformas de hosting y cubre con la necesidad funcional de todo sitio medio que no tenga necesidad de un desarrollo continuado.

Aunque sea una opción poco óptima fuera de la caja, en Blackslot tenemos corriendo varios sitios con decenas de miles de visitas al día basados en esta plataforma, con ayuda de soluciones de caché internas, teniendo aún margen para escalar a bastante más tráfico sin demandar grandes cantidades de recursos de servidor.

El problema reside más bien en el tipo de funcionalidad que quieres afrontar con el cms y la calidad que esperas obtener con el mismo. Yo no desarrollaría una intranet en WordPress por ejemplo, ni una plataforma de tienda electrónica para un negocio que dependa exclusivamente de esta plataforma para funcionar.

Utilizar PHP desde 0

Aunque durante muchos años he defendido el utilizar php sin frameworks hoy en día lo desaconsejo por completo.

Hace años no existía ninguna opción seria para php equiparable a un entorno .net por ejemplo. Hoy en día hay tantos que cuesta elegir.

No digo que debas elegir una de las opciones más maduras disponibles (que para mí sólo hay dos: Zend o Symfony). Lo que digo es que a menos que tu negocio sea una sola web y tengas el foco y todo tu tiempo puesta en ella, necesitas un framework para conseguir sobre todo estos puntos:

1. Desarrollar con más programadores en el mismo proyecto sin que sea un caos.
2. Trabajar con más gente en el mismo proyecto. A diferencia del punto 1, tienes que tener en cuenta a diseñadores, maquetadores, analistas, gente de sistemas..
3. Tener una base reutilizable que os ahorre, a medida que desarrolléis con la misma, más y más tiempo.
4. Conseguir automatizar las tareas más repetitivas y centrarte en el código específico de la aplicación que te ocupe en ese momento.

Aunque creas que lo mejor es ponerte a desarrollar un framework propio desde el principio, merece la pena conocer los frameworks que existen para aprender de miles de desarrolladores que han tenido muchos más problemas y por lo tanto tienen más experiencia que tú.

Desarrollar un framework sin haber utilizado otro antes como Symfony o asp.net mvc es una tarea muy compleja que puede hacerte perder mucho tiempo. Actualmente no es casualidad que Ruby On Rails, Symfony, asp.net mvc y otras opciones para desarrollo web escritas en diferentes lenguajes se parezcan entre sí. Esto es porque los problemas que nos solemos encontrar en el día a día son los mismos y es muy bueno conocer alguno de estos frameworks al detalle para orientarte sobre cómo debes organizar la arquitectura de una aplicación web seria.

En mi caso, incentivado por el cambio de versión de Symfony y por algunas de las cosas que no me han gustado o que he visto demasiado complejas en el mismo para solucionar determinados problemas, he empezado a diseñar y desarrollar en mis tiempos muertos un framework mucho más ligero y simple que Symfony pero pensado tanto para entornos tanto de hosting compartido como para arquitecturas más complejas.

Sin embargo no voy a dejar de utilizar ni Symfony ni WordPress. Me encanta Symfony y muchas de las cosas que he aprendido con este framework las estoy aplicando en este proyecto e incluso utilizo alguno de sus componentes. WordPress por su parte es la mejor opción para reducir costes en determinados proyectos que no requieran ni complejidad ni funcionalidad fuera de lo que se espera de un sistema de publicación.

Filtrar por listas es efectivo para seguir las actualizaciones de las personas que más me interesa lo que suelen decir, pero de vez en cuando suelo consultar el stream del resto para captar nuevos contactos o enterarme de cosas que no veo en estas listas privadas.

He observado que podría automatizar el flujo de entrada y salida de contactos en las listas que he creado, para ello necesitaría crear un sistema que en base a ciertos patrones me sugiriese qué usuarios debo dejar de seguir en mis listas y cuales debo agregar.

Existen herramientas como http://www.muuter.com/ (gracias César por la recomendación), que permiten silenciar actualizaciones que contengan palabras que no quiero leer. Esto no me termina de convencer, ya que es posible que no me moleste que puntualmente un contacto diga “goool” (no me gusta el fútbol), o que mencione lo bueno que es su trabajo como SEO/socialmedia (bueno quizá en estos casos si que me vería tentado a dejar de seguirle :)

El sistema que propongo se basaría principalmente en lo contrario, es decir sería un sistema de recomendación basado principalmente en listas blancas.

De entrada se me ocurren los siguientes requisitos:

• Dado que el sistema no me podría dar la información nada más registrarme, debería guardar mis contactos en su base de datos y evaluar sus updates cada cierto tiempo para compararlos a los criterios que he especificado en mis listas blancas y negras. Cada semana me podría sugerir nuevos cambios en mis listas privadas es decir, si debo agregar o quitar a alguien de las mismas.
• Ya que la aplicación seguiría updates de mis contactos, y de los contactos de los demás usuarios, no estaría mal que me recomendase contactos que no esté siguiendo actualmente.
• La aplicación analizaría mis propios updates, extrayendo las palabras que más repito usando estas como un criterio para distinguir una posible afinidad con respecto a otros usuarios. Podría tomar dichas palabras como criterios para una lista blanca y las que estén tageadas (es decir con #) en un update con la etiqueta #ironic en una lista negra.
• La aplicación me permitiría poner una serie de filtros basados en expresiones regulares. Las expresiones regulares, aunque son difíciles para un usuario normal, permiten una mayor precisión de filtrado, que es lo que más me interesa. Gracias a ellas podría filtrar mucho más fácilmente usuarios que les guste el fútbol, hagan retweets sin aportar nada sobre temas que no quiero seguir o al revés, el sexo del contacto en base a las terminaciones sintácticas de ciertas palabras e infinidad de filtros mucho más flexibles que pudiese tener con simples palabras clave o la api del propio twitter. Estos filtros podría aplicarlos tanto en listas blancas como en listas negras.
• Para dar más precisión a las listas blancas, la aplicación me permitiría especificar palabras clave y otros criterios más típicos en una aplicación de este tipo.

El algoritmo que evalúe qué contactos de twitter deben estar en las listas que sigo o cuales no, deberá calcular estas prioridades según los criterios descritos anteriormente y su recurrencia en los updates de estos usuarios. Es decir, si un usuario tiene muchos updates seguidos con criterios en una lista negra, se irá antes de mi bandeja de entrada que un usuario que tenga los mismos updates pero en intervalos de tiempo más largos y con otros updates de por medio que sí me interesen.

Pienso que podría ser una aplicación muy útil, si tenéis alguna sugerencia u os parece una tontería, dejad comentario.

Siempre es interesante ver otros puntos de vista y aportaciones :)

It takes marketing, yes, but also sales, and public relations, and an office, and a network, and infrastructure, and air conditioning in the office, and customer service, and accounting, and a bunch of other support tasks.”

Joel Spolsky en su artículo The Development Abstraction Layer

Dicho factor radica, en que el promotor del proyecto (que raramente coincide con el desarrollador del mismo) no sea, ni tenga el interés de ser, usuario del mismo.

Y es un factor muy típico, algo que lleva a muchas personas o empresas a forzar la innovación en áreas que ni conocen ni les interesa conocer.

Para muchas personas, el éxito de su proyecto en internet depende exclusivamente de los medios tecnológicos que lo sirven a los usuarios finales. Se habla de tecnologías, de metodologías de desarrollo, de financiación, de seo, de marketing… pero desde mi punto de vista por muy bien que se haga el trabajo en esas áreas, no sirve de nada si no se comparte el punto de vista de la demanda y en lugar de eso, nos encerramos en los argumentos que hemos creado para respaldar nuestra oferta. Sinceramente pienso que eso no tiene base alguna y cae, tarde o temprano, por su propio peso.

Es muy difícil, si no has trabajado en un área concreta antes o si no has consumido/disfrutado de los servicios o productos que buscabas en dicho área, que puedas detectar una forma de cambiar las reglas de juego. Es evidente que puede haber excepciones, pero sin duda veo necesario que al menos se parta de una base o de experiencia en otro área directamente relacionada a la que se pretende atacar.

Esto hace precisamente que la idea carezca de valor, por mucho que se invierta en ella económica o tecnológicamente. Y se nota claramente cuando un emprendedor se sabe desenvolver en el área por el que apuesta, conoce y le apasiona, ya que rompe las barreras que otros no saben detectar, con pequeños o grandes detalles que demuestran la solidez de su proyecto.

Sin más, esto era una pequeña reflexión que siempre me hace echar el freno cuando pienso en desarrollar algo en un campo sobre el cual no tengo ni idea.