Para los que estén siguiendo mi vida (sí claro) sabrán que tuve un momento de inflexión en mi carrera laboral hace unos meses, cuando cambié mi foco del desarrollo web al emprendimiento web, por llamarlo de alguna forma. Lo más importante de esta decisión no fueron los resultados, sino el aprender sobre la adaptación al cambio y maniobrar desafíos inéditos.

Producto de estos movimientos, hoy en día la cantidad de trabajo que manejo es mucha, y pese a mi afición por el horario centauriano y la cafeína, tomé la decisión de buscar personas con ganas de trabajar para explotar esta posibilidad.

La ironía es que yo conozco bien como funciona este sistema: la gente con aptitudes se aburre de sus tareas, exige más remuneración, se abre y a otra cosa, mientras que la gente regular mantiene sus trabajos indefinidamente mientras puedan pagar el triple play. Por eso, estoy proponiendo un método diferente, un balance entre hacer lo que realmente nos gusta y sólo lo suficiente de lo aburrido para asegurar la sustentabilidad.

Estoy convencido que el camino para esto son las personas correctas, por eso estoy contactando a un grupo de candidatos que llevo tiempo observando y creo potencialmente idóneos para las posiciones que necesito actualmente. Hoy además hago pública esta búsqueda para quien crea que le quepa el guante, y la consigna es: anímense, no necesitan ser expertos, solamente tener determinación y actuar correcto.

En resumen, busco alguien que:

• Tenga ganas de trabajar en algo que va a crecer proporcionalmente con su esfuerzo.
• Crea en Internet como medio para lograr cosas.
• Esté dispuesto a trabajar a distancia, y presencialmente si fuera necesario.
• De vuelta, esté dispuesto a trabajar para ganarse su café.

• Pueda programar en PHP, y si sabe de CodeIgniter mejor, pero no es un filtro calificador.
• Pueda armar una base en MySQL e interactuar con la misma según necesite.
• Sepa maquetear y diseñar con HTML, CSS y JavaScript, jQuery de preferencia.
• Cosas que serán usadas y se aprenden: SVN, Mercurial, Linux, FogBugz.

¿Por qué un post y no una búsqueda “seria” con una consultora? Porque creo que Internet puede ser usado más que para rickrollear y subir videos de gatitos, y si todos nos ponemos las pilas, podemos encontrar una oportundiad para progresar y dejar progresar a los demás.

No procrastinen, con un mail, llamado o dm se sacan las dudas. Pueden mandar CV, perfil de LikedIn, lo que quieran, pero sólo requiero que me cuenten por qué les interesó esta propuesta por sobre otra (porque si les da lo mismo esto que laburar en Mc Donald’s, estamos ante un problema). Aunque ustedes no estén interesados personalmente, alguien que los siga puede estarlo y por eso agradezco mucho la difusión de este post. Gracias.

Una de las tendencias de la web 2.0 (además de los gradiants, el glossy, las API’s, los mashups, etc) es la relegación del “www”. El subdominio “www” está fuertemente ligado a Internet, pese a que su utilización es realmente una comodidad y no una necesidad (surgió hace muchos años como una prática para diferenciar los servicios que ofrecían contenidos para la “World Wide Web” de otros que anteponían “ftp”, “mail”, etc).
Por eso, muchos desarrolladores optan por no utilizar “www” como parte de la URL de sus aplicaciones web, muchas veces desconociendo las implicaciones.

Seguridad

Cuando uno utiliza una aplicación web en un subdominio (“www” en este caso) las cookies que se generen están limitadas al mismo. Por ejemplo, si tengo un blog y me logueo en http://www.example.com/wp-admin no podría (en forma directa) acceder a esa cookie ingresando vía http://example.com/wp-admin (no estaría logueado). En cambio, si me logueo sin usar un subdominio (como en la segunda URL de ejemplo), la cookie estaría accesible desde el subdominio “www” así como cualquier otro. Si por ejemplo no utilizamos “www” para nuestro sitio principal, pero utilizamos un subdominio para un blog (ie. blog.example.com) y alguien llegara a incluir un código malicioso en un post/comentario (por una vulnerabilidad en el CMS o lo que fuese), podría robar las cookies de nuestro blog Y de la aplicación web principal.

Performance

Cuando accedemos a una aplicación web, el servidor nos devuelve además las cookies correspondiente al subdominio por el cual estamos accediendo. Si usamos cookies genéricas a todo el dominio, cada vez que carguemos una imágen o cualquier otro contenido estático desde ese servidor nos va a devolver además las cookies que usa la aplicación web en ese subdominio, aumentando el tráfico de datos y tiempo de espera. Por eso es importante separar los contenidos estáticos en otro subdominio para aumentar la performance con cada petición al servidor. Esto no implica necesariamente un debate sobre el “www” puntualmente, pero es un argumento relevante. Más información en este artículo de Yahoo!

Indexación + Performance

La mayoría de las personas ingresan a los sitios web anteponiendo “www” delante, lo cual nos deja con estos posibles escenarios:

1. Si los desarrolladores optaron por no utilizar “www” y no hacer nada en su lugar, el usuario recibe un error 404 o es redirigido automágicamente al sitio correcto (esto depende del navegador, servicio DNS e ISP, por lo cual no se puede depender).
2. Si optan por mostrar el mismo contenido con y sin subdominio “www”, van a obtener una duplicación de su sitio en el índice de los buscadores, lo que en el caso de Google significa una penalización (si no “blanqueamos” la situación utilizando Google Webmaster Tools o el flamante <link rel=”canonical” />)
3. Si en su lugar utilizan una redirección desde “www” hacia el sitio principal, van a aumentar el tiempo de espera del usuario, ya que las redirecciones más comunes (301 y 302 vía headers) no son cacheadas por los navegadores (o lo son por un tiempo), y más si aplican reglas de redirección desde un archivo (como “.htaccess”) o desde la propia aplicación web. Yahoo! nuevamente se pronuncia al respecto.

Distribución de contenidos

El utilizar un subdominio (“www” al caso) nos permite delegar esa parte de la aplicación web a un CDN (Content Distribution Network) que se dedique a cachear y distribuir el contenido globalmente, para mejorar los tiempos de carga y respuesta de nuestra aplicación. Existen varias formas de realizar esta delegación, pero la más común suele ser por registro CNAME, el cual en forma predeterminada corresponde a los subdominios. Un famoso servicio que utiliza esto es Amazon S3 y, en otra área, Google App Engine.

En contrapartida, la mayoría de estos puntos son mitigables y dependen enteramente de la situación. Por ejemplo, si nuestro negocio es recortar URL’s no podemos darnos el lujo de agregar 4 caracteres a cada dirección que generemos.
Mi intención es exponer que no se puede condenar a un desarrollador web por optar seguir utilizando “www” y no sumarse a la moda de los dominios desnudos.