2 files changed, 9 insertions, 10 deletions
diff --git a/blog/content/2012/06/desarrollo-web-como-dios-manda.gmi b/blog/content/2012/06/desarrollo-web-como-dios-manda.gmi
index e100c7c6..3b1ea8a9 100644
--- a/blog/content/2012/06/desarrollo-web-como-dios-manda.gmi
+++ b/blog/content/2012/06/desarrollo-web-como-dios-manda.gmi
@@ -14,13 +14,13 @@ Una manera fácil de comenzar es por el lenguaje. Es conveniente que escojamos u
 
 Comenzando por el principio, un buen punto de partida es mi querido TIOBE[1]. El TIOBE es un ránking de la popularidad de los lenguajes de programación calculado a partir de su presencia en la web. La metodología es inevitablemente discutible, pero el ránking está bastante alineado con mi percepción, así que para mi, es una opción cómoda.
 
-En el top 20 (a junio de 2012) encontramos tan solo 8 lenguajes utilizados comunmente para el desarrollo web: Java, C#, PHP, Python, Perl, Ruby, Javascript y Visual Basic .NET. Fuera del Top 20 encontramos muy poquitas opciones (Haskell, Scala y poco más), así que nos ceñiremos a estos.
+En el top 20 (a junio de 2012) encontramos tan solo 8 lenguajes utilizados comunmente para el desarrollo web: Java, C#, PHP, Python, Perl, Ruby, JavaScript y Visual Basic .NET. Fuera del Top 20 encontramos muy poquitas opciones (Haskell, Scala y poco más), así que nos ceñiremos a estos.
 
 Vamos a descartar unos pocos:
 
 * PHP[2]: pese a ser un lenguaje explícitamente diseñado para el desarrollo web, en mi opinión PHP nunca debe usarse para desarrollar un proyecto desde 0- a no ser que lo que queramos desarrollar sea extremadamente mínimo- ya sea porque se trate de un desarrollo extremadamente pequeño o bien que pretendamos reutilizar completamente un desarrollo existente como Wordpress o Magento. Desarrollar grandes bases de código en PHP es un ejercicio frustrante ya que, sencillamente, no está pensado para ello. Sus limitaciones en cuanto a modelo de ejecución, estructura y modularidad son motivo suficiente para descartarlo, pues el resto de lenguajes que consideramos lo superan ampliamente en estos aspectos, ofreciendo PHP muy poco para compensar (su velocidad para proyectos mínimos).Puede sernos útil conocer PHP, pues existe mucho trabajo manteniendo código PHP (sin embargo, no se trata de un trabajo especialmente gratificante) y en algún momento nos puede ser útil. Pero debe ser erradicado lo antes posible.
 * Perl[3]: durante mucho tiempo fue una de las mejores opciones disponibles, en realidad, una de las pocas viables. Una vez más, el resto de lenguajes de la lista le superan en virtudes sin que Perl ofrezca muchas ventajas propias. El mercado de Perl decae lentamente y cada vez se inician menos proyectos que lo utilicen.
-* JavaScript[4]: si bien deberemos conocer JavaScript para desarrollar efectivamente sobre la web, aún no lo considero una opción viable en el lado servidor. Tendremos que aprender JavaScript, pero el grueso del proyecto deberá ser siempre en otro de los lenguajes. Soy anti-aplicaciones web 100% Javascript, creo que su campo de aplicación es extremadamente limitado y presentan desventajas considerables, pero hay quien les encuentra virtudes
+* JavaScript[4]: si bien deberemos conocer JavaScript para desarrollar efectivamente sobre la web, aún no lo considero una opción viable en el lado servidor. Tendremos que aprender JavaScript, pero el grueso del proyecto deberá ser siempre en otro de los lenguajes. Soy anti-aplicaciones web 100% JavaScript, creo que su campo de aplicación es extremadamente limitado y presentan desventajas considerables, pero hay quien les encuentra virtudes
 
 C#[5] y Visual Basic .NET[6] son dos opciones que el lector mismo puede escoger descartar o considerar- desarrollar razonablemente en ambos supone unos costes que yo prefiero no asumir (se necesitan licencias de Windows para el desarrollo y despliegue y las versiones gratuitas de Visual Studio tienen bastantes limitaciones)- a parte de que soy un firme creyente en que las herramientas de desarrollo deben ser libres y gratuitas. Si eso no supone un impedimento para el lector, puede aplicar mi opinión sobre Java, ambas plataformas son extremadamente similares; quizás .NET goce de herramientas más sencillas de utilizar inicialmente, el sistema base es más completo que el de Java pero el ecosistema goza de menor vida.
 
diff --git a/blog/content/2012/06/porque-django-no-es-la-solucion-definitiva.gmi b/blog/content/2012/06/porque-django-no-es-la-solucion-definitiva.gmi
index 48700504..f3c172a9 100644
--- a/blog/content/2012/06/porque-django-no-es-la-solucion-definitiva.gmi
+++ b/blog/content/2012/06/porque-django-no-es-la-solucion-definitiva.gmi
@@ -1,12 +1,14 @@
 # 2012-06-02 Porqué Django no es La Solución Definitiva
 
-Hace tiempo ya explicaba por aquí las virtudes de Django[1]. En  resumen, se trata de un framework de desarrollo en web Python que implementa un interfaz de administración prácticamente automático a un esquema relacional. Vaya, que defines tus tablas y genera un interfaz dinámico para editar registros que te ahorra una barbaridad de tiempo (como podrá atestiguar cualquiera que haya tenido que hacerse uno).
+=> ../../2011/01/django-o-la-fabrica-de-churros Hace tiempo ya explicaba por aquí las virtudes de Django.
+
+En  resumen, se trata de un framework de desarrollo en web Python que implementa un interfaz de administración prácticamente automático a un esquema relacional. Vaya, que defines tus tablas y genera un interfaz dinámico para editar registros que te ahorra una barbaridad de tiempo (como podrá atestiguar cualquiera que haya tenido que hacerse uno).
 
 Tras llevar más tiempo trabajando con Django, sigo convencido que en estos momentos es la mejor solución que existe para desarrollo web basado en CRUD sobre bases de datos; el admin no tiene equivalente alguno que yo conozca, y desarrollarse un sistema similar es extremadamente costoso.
 
 Sin embargo, creo que he aislado unos cuantos defectos clave que hay que tener en cuenta antes de comenzar a usarlo.
 
-1. 
+1.
 
 Si usamos un esquema donde queramos que la edición de un registro tenga más de un nivel de indirección, el admin no soluciona esto. Pongamos por caso que tenemos una entidad "Empleado" , otra entidad "Proyecto" y una entidad intermedia que nos representa las asignaciones de Empleados a Proyectos (por ejemplo, en esta relación intermedia podríamos querer almacenar el tiempo durante el cual el Empleado está asignado al Proyecto, su porcentaje de dedicación a él, etc.). Podremos añadir un fantástico TabularInline que nos muestre las asignaciones de Empleados dentro de la vista de detalle de Proyecto, pero no hay manera de que se pueda editar el Empleado desde la vista detalle de Proyecto; podremos editar la relación intermedia (primer nivel de indirección), pero la segunda ya no.
 
@@ -19,21 +21,18 @@ Esto nos limita bastante el interfaz sobre esquemas de datos moderadamente compl
 
 Ninguna de las tres soluciones es mínimamente satisfactoria
 
-2. 
+2.
 
 El admin necesita más hipervínculos. En particular, la fantástica funcionalidad de los raw_id_fields, nos permite hacer que los campos clave foránea de nuestras entidades se puedan editar con un popup selector excelente, pero no nos permite saltar a la entidad enlazada. Una de las grandes virtudes de usabilidad de la web son los enlaces, y nos serían extremadamente útiles en más lugares del admin
 
-3. 
+3.
 
 Django no proporciona suficiente potencia en el SQL subyacente a su ORM. En particular, sería harto conveniente poder disponer de, o bien un inspectdb más potente que nos permita trabajar continuamente con él (añadir campo en nuestra base de datos y que inspectdb añada dinámicamente el campo al modelo), o un mecanismo para poder personalizar automatizadamente el esquema generado; esto principalmente nos debería permitir implementar una "estrategia" de nombrado de tablas y columnas que nos permita, por ejemplo, que los nombres de tablas sean plurales o cambiar el nombre de las claves primarias surrogadas que Django añade automáticamente.
 
 Si no nos gustan los esquemas que genera Django automáticamente (y no deberían gustarnos), las alternativas son o aguantarnos, o especificarle repetidamente los nombres de tablas y columnas que debe usar o hackear Django para que haga lo que queramos. Una vez más, esto no es del todo satisfactorio.
 
-4. 
+4.
 
 A un nivel más profundo, el código de Django no es muy amigable a la extensión. Es bastante complicado añadir funcionalidad derivando de las clases de Django; el código no siempre es fácil de seguir (ya que usa bastantes metaclases y otras pythonicidades de las que no soy muy fan) ni tiene un diseño orientado a objetos muy elaborado- se echa en falta que ciertas funcionalidades estén, como mínimo, aisladas en un propio método que podamos sobreescribir para cambiarlas (o utilizar el patrón estrategia, idealmente). Siempre nos queda la opción de forkear, pero esto no es muy mantenible, o hacer monkey-patching, lo que tampoco es muy recomendable ni mantenible.
 
 Pese a todos estos puntos, sigo pensando que el admin de Django es realmente algo único que nos puede ahorrar muchísimo trabajo y proporcionar un resultado de gran calidad para muchos, muchísimos proyectos. Pero aún es mejorable- y con unas pocas mejoras localizadas podría mejorar muchísimo.
-
-
-=> ../../2011/01/django-o-la-fabrica-de-churros 1: gemini://alex.corcoles.net/2011/01/django-o-la-fabrica-de-churros/