diff options
Diffstat (limited to 'blog')
8 files changed, 16 insertions, 14 deletions
diff --git a/blog/content/2011/01/django-o-la-fabrica-de-churros.gmi b/blog/content/2011/01/django-o-la-fabrica-de-churros.gmi index 904dd1a4..0935fbe9 100644 --- a/blog/content/2011/01/django-o-la-fabrica-de-churros.gmi +++ b/blog/content/2011/01/django-o-la-fabrica-de-churros.gmi @@ -7,7 +7,7 @@ Estos días me he encontrado frente a una web sencilla, pero que a mi juicio no ¿A parte de esto, qué otras virtudes tiene Django? * Vistas genéricas. En particular, lista/detalle sobre los modelos de datos, resolviendo correctamente paginación, ordenación, filtrado, etc. Tiene también vistas y maquinaria para hacer CRUD, que supongo funcionan bien pero que no he usado -* Usa HTML/HTTP "correcto" sin hacer cosas raras, añadir Javascripts innecesarios, serializaciones raras, etc. Todo muy limpio +* Usa HTML/HTTP "correcto" sin hacer cosas raras, añadir JavaScripts innecesarios, serializaciones raras, etc. Todo muy limpio * Está documentado. No llega al nivel de Java o Spring, pero desde luego, comparado con Rails y otras estrellas de código libre... * No usa generación de código. Odiamos la generación de código. @@ -18,7 +18,7 @@ Pero también le encuentro algún que otro defecto: * El sistema de plantillas está muy bien, pero es "regular" y no "gramatical", con lo que no admite expresiones donde debería ni otras estructuras muy convenientes. JSP con fragmentos de tag es *muy* superior * Tengo la sospecha que el funcionamiento sobre JVM no será para tirar cohetes. Además, si nos interesa funcionar sobre JVM, nos tenemos que limitar a Django 1.1 y evitar 1.2 de momento. * En general el sistema de internacionalización está muy bien, pero no soporta internacionalización en el modelo de datos (i.e. campos multilingües en las entidades) -* No viene con nada para hacer Javascript/AJAX, aunque seguramente no sería de mi agrado, claro +* No viene con nada para hacer JavaScript/AJAX, aunque seguramente no sería de mi agrado, claro A pesar de esto, creo que es el mejor "framework completo" que he visto. Como plataforma "básica", sigo prefiriendo Java + Spring + Servlets + JSP + JSTL, pero creo que Django puede tener un lugar bastante importante en el arsenal de un desarrollador web. La pregunta es, ¿cuál es ese lugar? diff --git a/blog/content/2011/10/apuntes-sobre-dart.gmi b/blog/content/2011/10/apuntes-sobre-dart.gmi index 2fb60e7e..432378e7 100644 --- a/blog/content/2011/10/apuntes-sobre-dart.gmi +++ b/blog/content/2011/10/apuntes-sobre-dart.gmi @@ -2,9 +2,9 @@ Google ha sacado hoy Dart[1]. -El apunte rápido (que seguro que otros mejoran) es que es un verdadero **Java**script. Es un lenguaje muy muy Java que compila a Javascript. Las diferencias con Java van por dos lados: +El apunte rápido (que seguro que otros mejoran) es que es un verdadero **Java**Script. Es un lenguaje muy muy Java que compila a JavaScript. Las diferencias con Java van por dos lados: -* Adecuaciones para funcionar bien cuando se compila a Javascript- i.e. no hay threads, hay "isolates", etc. +* Adecuaciones para funcionar bien cuando se compila a JavaScript- i.e. no hay threads, hay "isolates", etc. * Esas mejoras puntuales de Java que llevamos pidiendo a gritos desde hace siglos Las mejoras de Java son de ovación cerrada: @@ -18,11 +18,11 @@ Las mejoras de Java son de ovación cerrada: Siendo realistas, cubre la mayoría de "defectos" "resolubles" de Java. No, no tiene inferencia de tipos, ni lambdas con excepciones chulas, ni "final" por defecto... y quizás no es todo como uno lo había soñado, pero es una solución práctica y disponible **hoy**. -Eso es lo positivo. En lo negativo, el tipado opcional me escama- y me duele que signifique sacrificios (hay ahí una cosilla un poco rara con las funciones que no devuelven valor que me deja intranquilo). Me queda la curiosidad de estudiar los isolates para saber si aportan algo o si son sencillamente la manera correcta de montar concurrencia en código que será compilado a Javascript y ejecutado por los motores de Javascript existentes. +Eso es lo positivo. En lo negativo, el tipado opcional me escama- y me duele que signifique sacrificios (hay ahí una cosilla un poco rara con las funciones que no devuelven valor que me deja intranquilo). Me queda la curiosidad de estudiar los isolates para saber si aportan algo o si son sencillamente la manera correcta de montar concurrencia en código que será compilado a JavaScript y ejecutado por los motores de JavaScript existentes. He visto otras cosas que aún no me he mirado a fondo que no sé dónde colocar: soporte en el lenguaje para factorías, "const" el sistema de librerías y que null sea un objeto; es difícil saber si serán cosas buenas o malas. -En fin, cosas interesantes. No parece, sin embargo, que Dart aspire de momento a ser algo más que un sustituto de Javascript (algo que no me interesa mucho- el principal problema de Javascript no es el lenguaje en sí, en mi opinión)... con lo que **para mi**, no es muy interesante de momento. Si algún día se planta como una alternativa para desarrollo de aplicaciones y para programación, tiene la oportunidad de ser Java++, pero sin añadir la complejidad y cerradez de C#... pero ni siquiera sé si Google pretende que lo sea (ese rol lo quieren para... ¿Go? ¿Dart? ¿Java? ¿Python?) . +En fin, cosas interesantes. No parece, sin embargo, que Dart aspire de momento a ser algo más que un sustituto de JavaScript (algo que no me interesa mucho- el principal problema de JavaScript no es el lenguaje en sí, en mi opinión)... con lo que **para mi**, no es muy interesante de momento. Si algún día se planta como una alternativa para desarrollo de aplicaciones y para programación, tiene la oportunidad de ser Java++, pero sin añadir la complejidad y cerradez de C#... pero ni siquiera sé si Google pretende que lo sea (ese rol lo quieren para... ¿Go? ¿Dart? ¿Java? ¿Python?) . => http://www.dartlang.org/ 1: http://www.dartlang.org/ 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/11/que-es-el-rpc.gmi b/blog/content/2012/11/que-es-el-rpc.gmi index 717bea63..501b3b55 100644 --- a/blog/content/2012/11/que-es-el-rpc.gmi +++ b/blog/content/2012/11/que-es-el-rpc.gmi @@ -11,7 +11,7 @@ y que la suma se realice en el sistema remoto. A esto le llamaron llamada de pro Sun implementó uno de los primeros sistemas de RPC para implementar el sistema de archivos distribuido NFS, y a lo largo del tiempo han ido apareciendo diferentes mecanismos de RPC para diferentes plataformas y necesidades. -Con la popularización de la WWW, el protocolo HTTP y Javascript en los 90, pronto la gente comenzó a implementar comunicaciones entre sistema utilizándolos. Por ejemplo, una web podía exponer algunos de sus contenidos y funcionalidades en HTML para consumo humano, pero también exponerlos para consumo de otros sistemas. Mecanismos simples como poner una URL en la que si hacemos un POST http con unos argumentos, nos devuelve el resultado de una operación en un formato fácilmente parseable. +Con la popularización de la WWW, el protocolo HTTP y JavaScript en los 90, pronto la gente comenzó a implementar comunicaciones entre sistema utilizándolos. Por ejemplo, una web podía exponer algunos de sus contenidos y funcionalidades en HTML para consumo humano, pero también exponerlos para consumo de otros sistemas. Mecanismos simples como poner una URL en la que si hacemos un POST http con unos argumentos, nos devuelve el resultado de una operación en un formato fácilmente parseable. Pronto, uno de los padres fundadores del HTTP, procesó los principios fundamentales del HTTP y la WWW, en concreto que todo era una cuestión de URLs y acciones como GET/POST/PUT/DELETE que soporta el protocolo HTTP; cada URL representa un recurso y podemos expresar acciones mediante los "verbos" HTTP. A esto le llamó REST y supuso una perspectiva limpia y poderosa de lo que es la WWW. diff --git a/blog/content/2013/09/recopilatorios-de-grandes-exitos.gmi b/blog/content/2013/09/recopilatorios-de-grandes-exitos.gmi index c08c9e6b..6e76e871 100644 --- a/blog/content/2013/09/recopilatorios-de-grandes-exitos.gmi +++ b/blog/content/2013/09/recopilatorios-de-grandes-exitos.gmi @@ -18,9 +18,9 @@ En general, los compiladores suelen ser de lenguajes de mayor nivel a menor nive En estos casos, la cosa se suele complicar mucho más porque una implementación naíf de un compilador a ensamblador suele redundar en programas que al ejecutarse son espectacularmente ineficientes. Conseguir ejecutables eficientes es un problema completo en sí mismo sobre el que se han escrito toneladas de libros. -Sin embargo, recientemente son más habituales los compiladores que compilan lenguajes a cosas que no son ensamblador- por diversos motivos entre los que destaca que un compilador a ensamblador sólo es útil para una familia de CPUs, y pese a que la familia x86 de Intel y los ARM copan la mayor parte del mercado, sigue habiendo muchos otros procesadores en uso hoy en día. Por otra parte, plataformas como la máquina virtual Java, LLVM o incluso Javascript también son populares como destinos de los compiladores- en el caso de Java o LLVM por ser más simples para la generación de código sin sacrificar eficiencia, y en el caso de Javascript, por ser un destino particularmente útil ya que nos permite ejecutar el código compilado en un navegador. +Sin embargo, recientemente son más habituales los compiladores que compilan lenguajes a cosas que no son ensamblador- por diversos motivos entre los que destaca que un compilador a ensamblador sólo es útil para una familia de CPUs, y pese a que la familia x86 de Intel y los ARM copan la mayor parte del mercado, sigue habiendo muchos otros procesadores en uso hoy en día. Por otra parte, plataformas como la máquina virtual Java, LLVM o incluso JavaScript también son populares como destinos de los compiladores- en el caso de Java o LLVM por ser más simples para la generación de código sin sacrificar eficiencia, y en el caso de JavaScript, por ser un destino particularmente útil ya que nos permite ejecutar el código compilado en un navegador. -Tanto la JVM como la LLVM han sido diseñadas especialmente para este propósito, con lo que tienden a simplificarnos el proceso de compilación. En el caso de Javascript, pese a estar pensado con otros propósitos, proyectos como GWT o Emscripten han hecho grandes esfuerzos para hacer funcionar compiladores sobre Javascript. Mozilla incluso ha lanzado la iniciativa asm.js para definir un subconjunto de Javascript que sea práctico como plataforma a la que compilar de una manera eficiente. +Tanto la JVM como la LLVM han sido diseñadas especialmente para este propósito, con lo que tienden a simplificarnos el proceso de compilación. En el caso de JavaScript, pese a estar pensado con otros propósitos, proyectos como GWT o Emscripten han hecho grandes esfuerzos para hacer funcionar compiladores sobre JavaScript. Mozilla incluso ha lanzado la iniciativa asm.js para definir un subconjunto de JavaScript que sea práctico como plataforma a la que compilar de una manera eficiente. El proceso no se queda aquí, ya que una vez tenemos un lenguaje funcional con intérprete o compilador, siempre hay un interés en acelerarlo- tanto el proceso de compilación como la ejecución de los programas. Una vez más, se trata de un área complicada y sutilezas- se han llegado a técnicas extremadamente sofisticadas que incluso "aprenden" de la ejecución del programa y modifican su funci0namiento para adaptarse y mejorar "en vivo". diff --git a/blog/content/2026/03/me-gusta-el-futbol.gmi b/blog/content/2026/03/me-gusta-el-futbol.gmi index 29ad63a1..ae74e497 100644 --- a/blog/content/2026/03/me-gusta-el-futbol.gmi +++ b/blog/content/2026/03/me-gusta-el-futbol.gmi @@ -21,3 +21,5 @@ Pero lo que me llama más la atención es lo absurdamente caro que te puede sali Sigo considerando que el fútbol no se lo come todo por casualidad. (Aunque me parece que la introducción del videoarbitraje allá por 2017 en mi opinión rompe una de sus virtudes: que los aficionados juegan prácticamente a lo mismo que los equipos de primer nivel.) Pero mi consejo es que hay deporte para aburrir con la misma o más emoción, gratis y sin la toxicidad del fútbol de primer nivel al que estaba tan aficionado de joven. (Personalmente, principalmente veo ping pong y baloncesto, que son los dos deportes que he practicado más, y casi con cualquier cosa libremente disponible sin piratear en Internet, aunque por diversos motivos, raramente estoy viendo nada de más de diez minutos.) + +Apéndice 2026-04-05: menuda turra que solté sin mencionar lo más reciente. Que ahora cada vez que hay fútbol, cortan la mitad de Internet. El bonus es que es un conflicto entre varias partes en el que todas las partes me caen mal. El fútbol se lo come todo, huid si podéis. diff --git a/blog/content/2026/04/breve-e-incompleta-historia-del-desarrollo-web.gmi b/blog/content/2026/04/breve-e-incompleta-historia-del-desarrollo-web.gmi index c8c2e97b..ed19cb36 100644 --- a/blog/content/2026/04/breve-e-incompleta-historia-del-desarrollo-web.gmi +++ b/blog/content/2026/04/breve-e-incompleta-historia-del-desarrollo-web.gmi @@ -82,9 +82,9 @@ A diferencia del CGI, mediante el cual nacieron las webs dinámicas, PHP no trae Como muchos sabréis, ni PHP ni Perl han sido el final. Hoy en día, prácticamente todos los lenguajes de programación se usan para desarrollo web, con todo tipo de código reutilizable que cada vez nos aleja más del CGI. -Paralelamente al desarrollo de CGI, PHP y las webs dinámicas, en 1995 apareció el primer navegador con Javascript. A diferencia de los ejemplos anteriores, donde el código que os he puesto se ejecuta en el servidor web, Javascript se ejecuta en vuestro navegador. Esto permite otro tipo de interacciones que ejemplificaremos con Google Maps lanzado en 2005, que ya nos permitía desplazarnos por el mapa de una manera mucho más interactiva que lo que nos permite ninguna web dinámica sin Javascript. +Paralelamente al desarrollo de CGI, PHP y las webs dinámicas, en 1995 apareció el primer navegador con JavaScript. A diferencia de los ejemplos anteriores, donde el código que os he puesto se ejecuta en el servidor web, JavaScript se ejecuta en vuestro navegador. Esto permite otro tipo de interacciones que ejemplificaremos con Google Maps lanzado en 2005, que ya nos permitía desplazarnos por el mapa de una manera mucho más interactiva que lo que nos permite ninguna web dinámica sin JavaScript. -Casi tres décadas más tarde, curiosamente el CGI sigue existiendo pero la mayoría del desarrollo web no tiene casi nada que ver con el de 1995 con PHP y Javascript. En mi opinión, los ejemplos que os he puesto anteriormente omiten algo de tedio, pero son mayormente representativos de esas maneras de desarrollo, mientras que me marea simplemente pensar en poner un ejemplo mínimo de desarrollo web moderno. +Casi tres décadas más tarde, curiosamente el CGI sigue existiendo pero la mayoría del desarrollo web no tiene casi nada que ver con el de 1995 con PHP y JavaScript. En mi opinión, los ejemplos que os he puesto anteriormente omiten algo de tedio, pero son mayormente representativos de esas maneras de desarrollo, mientras que me marea simplemente pensar en poner un ejemplo mínimo de desarrollo web moderno. El fenómeno que observamos en mi opinión se repite por todo el ámbito del desarrollo del software: cada vez el paso inicial de desarrollo nos lleva más lejos, pero también es más difícil de abarcar. diff --git a/blog/content/notes/tech/about-relational-databases.gmi b/blog/content/notes/tech/about-relational-databases.gmi index c66a530f..d08071ac 100644 --- a/blog/content/notes/tech/about-relational-databases.gmi +++ b/blog/content/notes/tech/about-relational-databases.gmi @@ -21,7 +21,7 @@ Many computer languages have similar concepts: * C++ std::map * Java java.util.Map * C# System.Collections.Generic.Dictionary -* Javascript Object +* JavaScript Object * PHP arrays Relations are a natural concept, so although non-relational data systems exist, most data can be stored as relations. |