NN.blog.last()

// Mainly about programming stuff also anything may catch my interest.

Fonética Inglesa. Monoptongos

El inglés tiene fama de tener un sistema vocálico endiablado, y ciertamente lo tiene, más teniendo en cuenta que tiene decenas de dialectos que fundamentalmente se diferencian en la pronunciación de las vocales.

Pero el problema para un hispanohablante que está aprendiendo inglés no es tanto la complejidad del sistema vocálico del Inglés como la simplicidad del sistema vocálico de su idioma materno: el Castellano. Éste está considerado como uno de los más simples que existe dentro de los idiomas más hablados, sino el más simple, y literalmente define el sistema canónico de vocales. Hasta donde yo sé sólo el Rumano se le parece en simplicidad, con las 5 vocales canónicas y dos vocales centrales (una de ellas el Schwa de la que hablaremos más tarde). De hecho si alguna vez te has preguntado por qué los rumanos tienen tanta facilidad para aprender el Castellano ya tienes la respuesta, a los hispanohablantes les costaría un poco más hablar Rumano pero desde luego mucho menos que hablar Inglés, mala suerte.

Ahora bien si conseguimos hacernos más o menos con el sistema vocálico del Inglés nuestro nivel del idioma va a pegar un fuerte estirón, se va a colocar en un nuevo nivel desde donde es mucho más fácil progresar. Claro que mucha gente opina que la pronunciación es la parte más difícil del Inglés, yo al contrario opino que es de la más fáciles.

Agilescéptico

Lo confieso, me declaro “agilescéptico” y tengo que admitir que con el tiempo cada vez más, no per se sino más bien precavido y escéptico respecto a todo el circo que se ha montado alrededor de las metodologías ágiles.

Me explico, en mi opinión en desarrollo software sólo hay dos cosas importantes:

  • 1. Los Programadores
  • 2. El Código

Y en ese orden, y lo demás son florituras. Dicho de otra manera:

Con los programadores adecuados y dejándoles escribir el código que ellos consideren adecuado ya está casi todo hecho, la receta del éxito en desarrollo software ya estaría básicamente formulada. Y hablo del éxito técnico no comercial, esa es otra historia.

La única “agilidad” que importa en desarrollo software es la que permite libremente a los programadores escribir, leer y cambiar código con rapidez (pero sin prisas).

Ahora bien, lo primero que decidirán esos programadores (ellos y no otras personas) para poder escribir código de calidad serán las herramientas que van a utilizar, y de nuevo nos encontramos dos aspectos:

  • 3. Las Tecnologías
  • 4. La Metodología

Y en ese orden, porque el orden de nuevo importa.

Eventual Consistency, Parte II

En la primera parte sobre Consistencia Eventual (EC), un modelo de consistencia de datos para una arquitectura distribuida, deje sin contar dos de los aspectos más importantes de la misma: la política de resolución de conflictos, y también, la política de propagación de los cambios.

Antes de empezar, para concretar y generar un poco más de interés pongamos ejemplos de sistemas distribuidos que utilizan alguna forma de EC:

  • Los sistemas de control de versiones distribuidos y muy en concreto Git que es un caso paradigmático.
  • Los sistemas de almacenamiento en la nube, por ejemplo Dropbox.
  • Los juegos multiusuario en tiempo real, casi todos ellos.
  • Los motores de búsqueda, cualquiera de ellos.
  • Algunas Aplicaciones Web como las redes sociales, pongamos Facebook o Twitter

Asincronicidad en Node.js

El modelo de programación de Node.js es monohilo, asíncrono y dirigido por eventos. En esta primera parte del post veremos algo de código que nos permita entender un poco mejor que significa programar en un modelo monohilo asíncrono, en la segunda parte de post veremos un ejemplo de programación dirigida por eventos utilizando eventos propios.

Tener un sólo hilo de ejecución para todo el código tiene varias consecuencias en nuestro código de las que hay que estar alerta, estas son:

Sobre Node.js

En el post anterior comenté que Node.js era la tecnología que más rápidamente he visto crecer en poco tiempo. Realmente a poco que uno lo siga, el fenómeno es abrumador. El sistema de paquetes de Node npm tiene cerca de 8000 paquetes! A pesar del poco tiempo muchos de ellos ya están siendo utilizados en producción en proyectos reales y por empresas muy serias como Amazon, Linkedlin y Microsoft. Actualmente es el tecnología que más actividad y crecimiento tiene en GitHub.

Un ejemplo real que pone de manifiesto este fenómeno sería ldapjs, es un LDAP hecho con Node.js en 4 días prácticamente desde cero! A 24 horas de su publicación en twitter ya había un proyecto utilizándolo y en una semana ya estaba integrado en varios proyectos importantes. En comparación un proyecto similar hecho en Java OpenDS ha tardado 1 año en sacar la primera versión estable (y no es mucho tiempo) y apenas tiene actividad. Estamos hablando de una ratio de 1 a 100 en tiempos de desarrollo, es una salvajada, desde luego es un caso extremo y no creo que esa sea la norma, pero da una idea del dinamismo y de la velocidad a la que se está moviendo el fenómeno Node.js que desde luego está atrapando a desarrolladores con mucho talento.

Eventual Consistency

La Consistencia Eventual (EC) es un modelo de consistencia de datos. EC es un tema realmente interesante. Aunque bautizado con este nombre en el ámbito de la replicación de datos de grandes BBDD distribuidas, la misma idea y técnicas similares se han estado aplicando, desde que existen, a cualquier tipo de sistema distribuido con necesidades de baja latencia y alta disponibilidad.

La consistencia de datos es una propiedad importante en cualquier sistema, sin ella su estado puede no estar correctamente definido y su comportamiento volverse impredecible. Idealmente sólo existiría un modelo de consistencia: cuando hay un cambio en los datos del sistema todos los posibles observadores del sistema ven ese cambio al mismo tiempo. Este modelo es el que se denomina Consistencia Inmediata.

Groovy closures explicados con Java

Llevando 3 años usando Grails casi de continuo, en mi trabajo es habitual que me pregunten cuánto tiempo le llevaría a un javero de toda la vida ponerse las pilas y coger ritmo en un proyecto en Grails. Yo siempre respondo lo mismo, Grails es un framework para hacer aplicaciones web, el javero, a veces muy a su pesar, está muy curtido en esto de probar y utilizar nuevos frameworks, de hecho encontrará Grails especialmente sencillo y fácil de utilizar, y si es de los que ha bregado a fondo con frameworks del universo (por extenso) Spring incluso te dirá que de sencillo que es no le parece un framework serio.

Pero el mayor obstáculo y la verdadera dificultad de trabajar con Grails está en el lenguaje que se utiliza: Groovy. Siendo un lenguaje, Groovy te obliga a cambiar la forma de hacer las cosas y de pensar en ellas. Afortunadamente la curva de entrada de Groovy para un javero es muy suave, no es una renuncia de Java, es casi una evolución, al principio es habitual seguir programando igual que en Java y poco a poco ir incorparando la nueva sintáxis y la nueva forma de hacer las cosas. El tiempo para una adaptación plena varia con la persona, pero típicamente lleva varias semanas o incluso meses, depende de las ganas que le ponga.

¿Cuánto de OOP tiene Javascript?

JavaScript se define como un lenguaje multi-paradigma, que es otra forma de decir que no es un lenguaje puro en el sentido de seguir un único paradigma de programación. Ciertamente JavaScript es una mezcla de muchas cosas, aunque la raíz es para mi, sin duda, la Programación Funcional (FP). Tomando como base este paradigma su creador tomo prestados conceptos y estilos de programación de otros lenguajes.

Los lenguajes funcionales tienden a tener un estilo de programación declarativo, pero el creador de JS quiso preferenciar la sintaxis imperativa C-like común en muchos lenguajes (incluído Java), quizás para hacer más accesible el lenguaje, en cualquier caso, en JS es habitual ver ambos estilos mezclados. Siguiendo con esta extraña mezcla decidió, cómo no, añadir características de programación orientada a objectos (OOP en inglés) que tan de moda estaba en aquellos tiempos y añadió dos conceptos básicos de OOP: La definición de objeto y la herencia, y no mucho más… y además JS lo hace de un modo muy particular, veamos cómo:

Sobre este blog

¿Por qué Octopress ?

Después de probar varias opciones online, finalmente me he decidido a utilizar Octopress, por varias razones

  • Es un blog de publicación estática con total control sobre lo que aparece, como tiene que ser…
  • Puede alojarse en github gratuítamente y la carga de páginas es muy rápida, como ventaja añadida todo el blog está versionado.
  • El theme por defecto es muy simple, limpio y fácilmente modificable.
  • Es un blog de programadores para programadores y se nota. Está hecho en Ruby, qeu no conozco bien pero es fácil de utilizar.
  • Es muy fácil incluir código en las entradas y se integra con github gist (trozos de código) estupendamente.
  • Es posible trabajar offline, viendo rápidamente los cambios y utilizando mi IDE favorito, cuando estás conforme haces un push a github
  • Utiliza un lenguaje de marcado Markdown (configurable) en vez de uno de estos asistentes de edición que siempre me funcionan mal, para mi es más cómodo.
  • Tiene un montón de plugins en código abierto y si no te sirven los modificas o te haces uno.