Diseñando la estructura de tu web: URLs y extensiones

Desde hace tiempo intentamos que cuando programamos una web las extensiones de los ficheros y la estructura de directorios no nos condicionen en el futuro.

Desde hace tiempo intentamos que cuando programamos una web las extensiones de los ficheros y la estructura de directorios no nos condicionen en el futuro.

Por ejemplo si desarrollas en asp y creas tu web con URLs del tipo…
 

http://mi.com/productos/coches.asp

… y llegado un momento te ves en la necesidad de cambiar de lenguaje de programación, vas a tener bastantes problemas. 

Por ejemplo si tienes que pasarte a PHP tendrás que crearte una página del tipo:

http://mi.com/productos/coches.php

Y después redirigir con un »HTTP Error 301, Moved permanently» de tu antigua página «asp» a la nueva «php» para intentar perder el menor posicionamiento posible… y aun así perderás tráfico. 

Es algo fácilmente solucionable con un poco de picardía al principio: yo te recomendaría que en lugar de utilizar las URLs anteriores crees una estructura de directorios de este tipo:

http://mi.com/productos/coches/

Jugando con los Documentos Predeterminados de IIS que se pueden cambiar con facilidad en cualquier momento (incluso en alojamientos compartidos).

Es decir, en el interior de la carpeta coches existe un fichero que puede llamarse default.asp, default.html, default.aspx, default.php… y eso da igual ya que tanto nuestros usuarios como los buscadores sólo conocerán la URL que utilicemos en los enlaces, en este caso la de la carpeta.

De esta manera llegado el momento podremos cambiar de lenguaje de programación sin miedo a perdidas de tráfico. 

Desde mi punto de vista el lenguaje de programación que utilicemos no es un dato que interese al usuario por lo que no debemos abofetearle con él cada vez que entre en nuestra web.

Si la URL necesita parámetros para generarse, por ejemplo una lista de productos extensa que requiere paginación tenemos que tener cuidado y no ser torpes. En lugar de enlazar a:
 

http://mi.com/productos/coches/default.php?pag=2
Enlazaremos a:
 
http://mi.com/productos/coches/?pag=2
Para evitar que una misma página tenga dos URLs distintas tendremos la precaución de que cuando enlacemos de nuevo con la primera página no haya un enlace del tipo:

http://mi.com/productos/coches/?pag=1

Hay que ser consistente y enlazar de nuevo con:

http://mi.com/productos/coches/

En nuestro CMS hemos tenido mucha precaución con este tipo de detalles. Como ya hemos comentado en otras ocasiones, nosotros fuimos construyendo nuestro programa a partir de Blogger… pero donde vimos algo mejorable intentamos corregirlo, por ejemplo un enlace a la etiqueta «España Libre» en Blogger sería tal que así:
 

/labels/Espa=C3=B1a%20Libre.html
Mientras que nuestra URL es bastante mejor y sería tal que así:
 
/archivos/espana-libre/
Hay que tener en cuenta que para los buscadores con que sólo una letra pase de mayúsculas a minúsculas, ya considerará la URL completamente distinta. Por eso nosotros nos fijamos como norma nunca utilizar mayúsculas en los enlaces internos, además depuramos los espacios convirtiéndolos en guiones medios y transformamos algunos caracteres en otros más compatibles (ñ-n, á-a). 

Son pequeños detalles, a veces casi artesanales, que sumados a otros muchos van marcando la diferencia. Observar este tipo de cosas cuando visitamos una web puede ayudarnos a hacernos una idea de si el equipo que hay detrás es cuidadoso o si no ha prestado ninguna atención al SEO de la web.

No obstante nuestro CMS tiene un defecto: los artículos del blog son de las pocas URL que no siguen este patrón y revelan la extensión del fichero y teniendo en cuenta que en todos los blogs se publican más de 500 artículos al mes, ahora es un problema bastante laborioso de solucionar…

Esta semana vamos a importar un nuevo blog desde Blogger a nuestro CMS y se nos ha ocurrido lo siguiente: conservaremos las URL con la extensión .html que utiliza Blogger (lo cual nos permitiría por ejemplo el día de mañana exportar ese mismo blog a WordPress). 

Para ello sólo hay que conseguir que los archivos con extensión .html se procesen como si fueran páginas ASP para lo que hay que agregar una nueva asignación de extensión en IIS:

 

Llegado el momento podríamos incluso desasociar la extensión .asp y ejecutarla como si fuera PHP…. No es una solución perfecta, pero nos ayudará a hacer la migración de los artículos de una manera totalmente transparente.

Un lenguaje de programación para el 2009

Todos los que nos dedicamos a realizar aplicaciones informáticas nos vemos enfrentados antes o después a la decisión de apostar por un nuevo lenguaje de programación.

Todos los que nos dedicamos a realizar aplicaciones informáticas nos vemos enfrentados antes o después a la decisión de apostar por un nuevo lenguaje de programación.

En diciembre de 2006 hablábamos de cuál pensábamos que iba a ser nuestro lenguaje de programación para el 2007… pero no terminó siendo así, durante todo el 2007 hemos seguido programando con páginas ASP y Vbscript, echando mano de PHP en casos de emergencia.

Resulta curioso que una gran parte de los lectores de ese artículo lo votaron y siguen votándolo como «malo»… aunque no considero que sea mucho peor que el resto de los que aquí se publican, por lo que supongo que tiene mucho que ver el que en ese momento apostáramos por C# sobre .NET o lo que es igual Microsoft… y ya sabemos todos de que pie cojea la blogosfera. 

En cualquier caso nuestra voluntad no llegó a materializarse: estos dos últimos años en ENZO hemos estado tan sumamente ocupados que no hemos tenido tiempo para replantearnos la situación, pero recientemente tres artículos me han vuelto a picar con esta asignatura pendiente. 

Este en Loogic:

Este otro:

  • Triple salto mortal con tirabuzón - Sobre el cambio de plataforma de Festuc, que ha pasado de PHP a Django (Python) lo que ha supuesto el desarrollo desde cero de toda la aplicación.

…y por último: 

 

El tema de los gráficos es en general para reírse, en abril se publicaba este otro en el post Survey Says: C# more popular than VB:


 
En la red te puedes encontrar cuadros de «adopción» tan sumamente discrepantes que mejor no hacerles caso. La elección de un lenguaje de programación es un asunto religioso, donde es raro encontrar a personas que dominen varios lenguajes lo suficientemente como para poder valorarlos objetivamente.

Lo que parece un hecho es que desde el 2005 la mayoría de los programadores están pasando de VB a C#, convirtiendo a C# en el standard de-facto para todos los que desarrollan en NET. Por otra parte Python y Ruby como lenguajes «dinámicos» estos últimos años han pegado fuerte… tanto es así que también han sido adoptados por .NET con IronPython y IronRuby.

La cuestión por tanto no depende sólo de elegir el lenguaje, también hay que elegir el Framework… Ya sea Rails para Ruby o una de las muchísimas que existen para Python (las malas lenguas dicen que existen tantas porque no hay ninguna realmente buena), de entre las que destaca para desarrollo web Django.

En estos días mi experiencia con Django -sin ayuda experta del exterior- ha sido nefasta… considero que sería una locura ponernos a desarrollar en Python, salvo tal vez de la mano de NET. 

De Ruby on Rails, todavía no lo he probado lo suficiente… espero durante este mes poder estudiarlo para poder llegar a la Conferencia de noviembre en Madrid con los deberes hechos.

Un lenguaje de programación para el 2007

En ENZO todos los desarrollos funcionan con páginas ASP programadas en Vbscript. El Vbscript fue en su momento extremadamente popular y muy fácil de aprender para aquellos que sabíamos algo de Visual Basic.

Lamentablemente el Vbscript hace mucho que dejó de estar en la cabeza de Microsoft, desde hace años no se ha lanzado ninguna actualización y según la comunidad de programadores va optando por otros lenguajes comienza a ser más difícil encontrar documentación en Internet que te saque de los embrollos.

Es el momento de cambiar… ¿pero hacia donde? No es una decisión fácil.

Uno de los artículos que he leído más claros al respecto es Language Wars de Joel Spolsky, con afirmaciones tan claras como éstas:

  • «People all over the world are constantly building web applications using .NET, using Java, and using PHP all the time. None of them are failing because of the choice of technology»
  • «there are three and a half platforms (C#, Java, PHP, and a half Python) that are all equally likely to make you successful, an infinity of platforms where you´re pretty much guaranteed to fail spectacularly when it´s too late to change anything (Lisp, ISAPI DLLs written in C, Perl), and a handful of platforms where The Jury Is Not In, So Why Take The Risk When Your Job Is On The Line? (Ruby on Rails)»

Hasta hace pocas semanas tenía prácticamente decidido que tiraríamos hacia PHP, pero recientemente he cambiado de opinión: básicamente porque programar en PHP es sencillo pero enormente trabajoso, algo que también ocurre con Vbscript. Cuando digo trabajoso me refiero a que cuando sales de un proyecto «grande» no quieres volver a oír hablar durante un tiempo de formularios, inserts, updates… ni nada que se le parezca.

Programar no debería ser algo aburrido y realizar tareas mecánicas con las que no aprendes nada nuevo es la forma más rápida de aburrirte.

Por eso es prácticamente seguro que a partir del 2007 comenzaremos a trabajar con C# el lenguaje de programación orientado a objetos desarrollado por Microsoft para su plataforma .NET

El cambio no va a ser sencillo, pero cuando nos acostumbremos al nuevo lenguaje y la nueva plataforma tengo el convencimiento de que va a aumentar mucho nuestra productividad… y no hay más que visitar MSDN para comprobar que Microsoft está apostando realmente fuerte por ASP.NET (actualmente en su versión 2.0).

Por si me quedaba alguna duda… ASP.NET AJAX (Atlas) me ha dejado con la boca abierta al comprobar en sus videos como añadir funcionalidades AJAX (totalmente compatibles con Firefox) a una «aplicación tradicional» se puede conseguir en apenas 5 minutos… algo que a nosotros actualmente nos lleva días.

Para vergüenza blogosférica Microsoft nos ha vuelto a agarrar en sus fauces… pero seguimos manteniendo un toque de rebeldía apostando por mySQL, así que tranquilos… todavía no está todo perdido.