2011/10/04

Solucionar puerto 80 ocupado luego de Webmatrix

Resolver esto me ha tomado un tiempo. Espero le resulte de ayuda a alguien.

Luego lo desinstalar Webmatrix (La versión 1.0 me parece, en Windows 7), encontré que XAMPP no podía usar el puerto 80 como antes.

Con la idea de averiguar qué proceso lo ocupa, ejecuto en la consola de comandos, como administrador:

netstat -anb

pero aparece que no hay información disponible sobre el proceso que ocupa el puerto 80.

Usando la utilidad tcpview (de Sysinternals), veo que el proceso es el mismo System, con PID 4.

Hago telnet localhost 80 y veo que quién está atendiendo es Microsoft-HTTPAPI/2.0

Reviso en el Panel de Control, Herramientas Administrativas, Servicios, y desactivo "Servicio Agente remoto para Microsoft Web Deploy 2.0."

Eso era. Al parecer un issue de Webmatrix. Ahora XAMPP ya puede iniciar en el puerto 80.

Referencias

2011/09/22

Comprobar un elemento con jQuery

Para comprobar si existe un elemento, es útil comprobar su propiedad length:

if ($('selector_del_elemento').length) {
  ...
}

Ejemplos con selectores:

  • $('#section-1')
  • $('.sections a.active')
Referencias

2011/09/19

SEO

SEO es como se denomina al trabajo de optimizar páginas web para facilitar su procesamiento por los buscadores (el término proviene de las siglas de Search Engine Optimization: Optimización para Máquinas de Búsqueda).

He estado leyendo sobre SEO durante 3 días, así que ya soy un experto.

;-) Claro que es una broma. Así conociera toda la teoría, un experto, prácticamente por definición, es aquel que ha experimentado durante algún tiempo, y ha obtenido ese conocimiento que da la práctica (y que suele corregir a la teoría).
En el caso particular de SEO, el tiempo parece ser un factor casi inevitable. Un cambio SEO podría tardar al menos dos semanas en verse reflejado. Y una campaña SEO al menos 3 meses.
No, no soy un experto en SEO, pero me gustaría compartir algunas de las cosas que he encontrado, y también algunas reflexiones. Espero sea indulgente con algún error que llegara a notar, y agradezco de antemano los comentarios en buena onda.
Me parece que Optimización para Motores de Búsqueda no deja muy claro qué es lo que optimiza. ¿La página o su posicionamiento? Aquí manejo la definición de SEO como veo que lo hace Google. Como la optimización de la página para mejorar su visibilidad para los motores de búsqueda.
Sin embargo, también es frecuente encontrar que se piense en SEO como la mejora de la posición de un sitio web en los resultados de búsqueda. Es decir, mejorar su visibilidad  en la lista de resultados de los motores de búsqueda.
Como la posición de una página web suele estar determinada por el número y la calidad de los enlaces que le apuntan desde otras páginas, mejorar eso es toda una campaña. Involucra inscribirse en directorios, ser recomendado por páginas afines, aparecer en blogs, participar en foros, redes sociales, quizás algo de publicidad en otros medios, el boca a boca, etc.
Que la página pueda ser eficientemente indexada por un robot también ayuda, y es en ese sentido que uso el término SEO. 

SEO es una de las muchas herramientas que se usan en la campaña para mejorar la posición. Me parece que es más claro así, que llamar SEO a las dos cosas y dar pie a confusiones.
El problema y las soluciones
Me parece que para entender lo que se hace en SEO hay que considerar cómo encontramos una página web.

En el principio, como ahora, fueron las páginas, y la necesidad de encontrar las páginas que contuvieran la información que queríamos. Para ayudar en eso, aparecieron directorios, como Yahoo, con enlaces que eran mantenidos manualmente. Quienes publicaban algo en la web, se inscribían al directorio y su página era enlazada bajo cierta categoría. Un buscador de texto ayudaba a localizar algún enlace en particular.

Luego, se automatizó el proceso, como lo hace Google, usando programas robots (llamados spiders) que navegan por la red, siguiendo enlaces y recomendaciones. De esa navegación de robots, se extrae información que permite construir listas de enlaces según las palabras clave que proporcionemos para la búsqueda.

La solución y el problema
Estos robots tienen capacidades limitadas de exploración, en comparación con los humanos. Pueden leer el texto simple contenido en los archivos HTML, pero no el que estuviera contenido en una imagen o fotografía. No pueden reconocer el significado de una forma. Aunque pueden reconocer las palabras no pueden reconocer lo que significan. Ni el mensaje contenido en un texto, o una foto, o un video. Aún no tienen esa capacidad.

A pesar de eso, son muy útiles para buscar entre las páginas de la red. Es más, tener un puesto relevante en el índice de los buscadores se ha vuelto tan importante como para que la gente se vea obligada a modificar la forma en que hace las páginas web, de modo que los robot no encuentren demasiados obstáculos al navegar por ellas.

Como los robots no pueden entrar a cierto tipo de medios, los humanos crean contenido textual alterno que los robots puedan ver e indexar. La labor del SEO es entender cómo hacerlo.

Ojalá quede un poco más claro que el SEO existe debido a las limitaciones de los robots para entender el contenido. La optimización de la que se habla es para ellos, no para los humanos.

Me parece que es importante tener presente esta situación para ver con más claridad las opciones disponibles.

El texto alterno
Quizás lo ideal sería que los robots de los motores de búsqueda pudieran entender el contenido del mismo modo que los humanos. Pero por el momento, sólo pueden reconocer texto simple así que, si tenemos contenido que no sea texto simple, hay que hacerles una versión textual para ellos.

Pero la capacidad de Internet para mostrar contenido multimedia ha ido aumentando, y probablemente continuará haciéndolo. Así que hay una porción cada vez mayor de la web a la que los robots no pueden acceder y que sería completamente invisible para los buscadores si no fuera porque introducimos manualmente contenido textual alterno.

Por otro lado, el tener contenido textual alterno puede ser útil no solo para los robots con capacidades limitadas, sino para los humanos con capacidades limitadas que accedan a las páginas.

Sin embargo, el tener contenido duplicado en diferentes versiones no parece muy eficiente. Sería mejor encontrar algún modo de presentar convenientemente las páginas según quién lo solicite. Multimedia para quién lo pueda apreciar, texto para quién solo pueda o quiera texto, etc. Pero todo a partir de la misma fuente.

El factor humano
Parece que, al menos por el momento, es un problema muy difícil aumentar las capacidades de los robots, porque se ha optado por la alternativa de usar a los humanos para eso. Por ejemplo, cuando un humano califica positivamente cierta información (haciendo click en "Me gusta" o "+1"), contribuye a hacerla más relevante para los buscadores.

Un solo individuo podría equivocarse, o manipular su voto, pero el conjunto de individuos muestra un comportamiento colectivo relevante que puede resultar de ayuda a la hora de buscamos algo.

Sin embargo, quizás nuestra inteligencia colectiva tenga ciertas preferencias y hayan espacios en la red que no se cataloguen tan bien como nuestras búsquedas quisiera.

Tal vez cuando haya robots que puedan entender más, se encarguen ellos de hacer las calificaciones positivas.

Mientras tanto, hacemos SEO.

Herramientas
Referencias

2011/07/18

Liberando la V, otra forma de usar un framework MVC

En el esquema MVC, se tienen modelos que proveen datos, y controladores que toman los datos y los procesan de algún modo antes de enviar el resultado a la vista.

En web, los framework MVC tratan de seguir este esquema para organizar el trabajo. En teoría, parte del equipo se puede enfocar en los modelos, otro en los controladores y otro en las vistas.

Al margen de si en la práctica realmente se cumple esto, es notable un problema: los modelos, vistas y controladores desarrollados determinan finalmente un API no estándar que termina "enjaulando" el producto final. Si decide actualizar el framework a la siguiente versión, encontrará que puede acarrear para el site un trabajo similar a volverlo a hacer. Aún más difícil es pasar un site de un framework a otro.

Esto genera algunos vicios. Si otro framework implementa cierta característica ventajosa, no lo podemos usar; tenemos que esperar hasta que algo similar sea implementado en el que usamos. Esa característica debe ser expresada otra vez, en los términos de nuestro framework.

En mi opinión, esto ocurre porque la página web ha sido forzada a encajar en el esquema MVC sobrescribiendo sus características estándar por otras propietarias, definidas por su sistema de templates particular.

Sí, aunque el framework sea open source, en este caso se está comportando como un ente propietario. Y eso es lo que provoca esta limitación de libertad.

Para tener más libertad, libere la vista. Puede desarrollar su sitio web de modo que las vistas sean HTML estándar y las partes dinámicas carguen con javascript (AJAX) los datos obtenidos de invocar algún framework.

Por ejemplo. Si uso Drupal como framework, puedo tener un subdirectorio drupal dentro de mi site, e invocar con javascript a algo como drupal/action.json, cuyo resultado reflejo en la página.

No hay problema con las páginas del site mientras no cambie el modo de invocar la accion. Si luego cambio la versión de drupal, no seria necesario cambiar las vistas.

Si, en lugar de usar drupal como nombre del subdirectorio, hubiera usado algo como framework, y colocara dentro acciones que se invocaran del mismo modo, entonces, podría usar cualquier framework, con tal que siguiera el protocolo esperado por las vistas.

Esta forma de trabajar puede permitir funcionar un sitio dinámico que use muchos frameworks diferentes en simultaneo. Uno para el login, otro para los listados, otro para comunicaciones, etc. El que mejor haga lo que queremos. También facilita la actualización de los frameworks a versiones superiores.

Usar javascript para esto me parece un camino relativamente asequible en este momento. Pero si alguien no desea usar javascript para eso, podría usar un framework unobstrusivo (que respete la integridad de las páginas), como uphp, para hacer el trabajo de reemplazo. uphp usa querypath para ubicar un elemento en la página (al estilo jquery, pero con php), y reemplazarlo por algún resultado; todo eso en el lado del servidor.

En este otro modo, no son las vistas las que invocan las acciones, sino los controladores que se disponen en el framework unobstrusivo (o uframework, para abreviar). El uframework podria invocar a otros frameworks para hacer los reemplazos de los resultados en las ubicaciones pertinentes en la vista. Igual, se podría usar varios frameworks a la vez.

La idea principal es que la vista salga de la jaula del framework, se respete su integridad, tal como es, y sea independiente de los motores que se usen para generar el contenido dinámico.

2011/07/08

Generación modular de HTML

Actualmente, cuando desarrolla un sitio usando cierto framework, no lo puede modificar con otro. Si está metido en esto, puede parecer obvio y hasta natural. Pero, si lo vemos en perspectiva, es algo así como una limitación por diseño. Algo que se podría mejorar.

Sites estáticos y dinámicos
Aunque el objetivo final es enviar html al navegador, en el desarrollo de sites dinamicos el paso intermedio es crear un conjunto de archivos que generen el html que se desea.

Cuando se trata de sites estáticos es más simple. Uno coloca los archivos en el directorio web y el servidor web los envía al navegador tal cual. Esos archivos son html, css, javascript, o imágenes que el desarrollador puede modificar con la libertad de elegir entre muchas herramientas para eso.

Cuando se trata de sites dinámicos las cosas se suelen complicar. En general, primero se plasma el diseño en un site estático, que luego es desmantelado para ver el modo de generarlo. Finalmente, se obtiene el site dinámico, que actúa como un generador total del html que se desea.

Ese suele se el enfoque más usado. Practicamente siempre que use C, Java, PHP, Ruby, Python, o lo que sea, lo que construye es siempre un generador total de html.

Frameworks exclusivos
El enfoque de la generación total tiene el problema de tender a soluciones monolíticas, con sus vicios asociados.

Si quiere modificar el site, tiene que modificar el generador, y tiene que entender el framework-que-todo-lo-hace.

Cuando un framework mejora, esa nueva versión no le sirve para el site que hizo con la versión antigua y tendría que reescribir el site bajo los nuevos términos.

Si otro framework implementa una característica que le gustaría, tendrá que esperar hasta que sea implementada, otra vez, en los términos del framework que usted usa.

Un montón de trabajo repetido.

Frameworks inclusivos
Una alternativa podría ser hacer generadores modulares. En lugar de generar el html de toda la página, un generador modular sólo produce el html de cierta región específica.

Para indicar dónde colocar el html dinámico, habrían algunas alternativas:

  • Que la página use javascript, obtenga el resultado y lo coloque.
  • Que la página use un tag especial que se reemplace por el contenido dinámico.
  • Que el servidor ubique los lugares dónde hacer el reemplazo y los haga.

La primera alternativa es relativamente asequible con lo que ya tenemos. Para las otras, habría que hacer un framework que se encargue de hacer los reemplazos adecuados (por ejemplo uphp).

Ya mismo podríamos empezar a desarrollar sites de ese modo. Una ventaja grande de usar generadores modulares, es que no importa en que lenguaje de programación se hacen, ni que framework usan, ni que versión del framework. Simplemente se usan. Podría usar generadores modulares escritos en C, Java, PHP, Python y Ruby... todos juntos!