Voy a generalizar a lo bruto, así que disculpen si se sienten ofendidos. Creo que en España nos movemos por ser amigo de para conseguir las cosas, y el mérito y sus consecuencias no se tienen en cuenta. Creo que en el mundo del software libre es necesario aplicar esta filosofía, no debe destacar este por ser mi amigo, si no porque ha realizado más trabajos que otro. Además, que tu trabajo hable es bueno, es algo objetivo y no subjetivo, no influenciados por juicios de valor que deberían quedar en lo privado.

Así la meritocracia según la Wikipedia es:

es una forma de gobierno basada en el mérito. Las posiciones jerárquicas son conquistadas con base al mérito, y hay una predominancia de valores asociados a la capacidad individual o espiritu competitivo tales como, por ejemplo, la excelencia en educación o deportes.

En una comunidad de software puede ser una vara de medir, el número de tickets cerrados, las incidencias comunicadas, los artículos escritos, las charlas dadas… No es una sociedad igualitaria, pero si se entiende que todos somos iguales, porque todos podemos cerrar tickets, comunicar incidencias, etc … lo cierto es que es algo realmente fácil y basado en el trabajo.

Las consecuencias del mérito

Las consecuencias son básicamente de visibilidad, tu trabajo habla aunque tú no estés, y esto te pone en el foco de críticas. Las criticas te llueven, las opiniones sobre tí intentan influenciarte de que puede que estés haciendo algo mal trabajando y haciendo cosas. Esta frase de la Biblia refleja claramente esta idea:

Obras son amores y no buenas razones.

Seguid currando, que el mérito de vuestro trabajo hable y quien se quiera unir que se una, pero para trabajar y ser feliz, no para incordiar y no hacer nada.

Me encanta el proyecto Gnome, desde siempre he estado enamorado de él, era tener como un Mac pero de bajo precio y además podías tocar el código fuente, había una comunidad y era usable, cada vez más rápido y cada vez más bonito.

Pero se lio parda, la decisión de revolucionar Gnome con Mono supuso una fragmentación en la comunidad, Mono acabó por su lado y Gnome por otro con lo que años de esfuerzo se diversificaron. Y salió Gnome 3, bello, nuevo… pero de nuevo revolucionario. Rompía con el pasado, y en vez de sumar restaba, después Unity, después un fork por parte de Linux Mint y ahora fuera de Debian, la distribución que lo hizo grande. ¿y todo esto porqué?

El porqué, por factor ideológico, para muchos es más importante la licencia, que los usuarios, la pureza del código que la funcionalidad que se desarrolla. Y es más importante hacer la paja mental del momento que el no romper con el pasado y evolucionar. No revolucionar, evolucionar a buen ritmo.

Me acuerdo de la Guadec de Sevilla de hace unos años, se preguntaron donde estaban los usuarios, y claro, yo lo tenía claro quejándose de Guadalinex. En vez de utilizar este feedback para poder enfocar su desarrollo, se quejaban de la falta de participación de estos. Además, no es un dato objetivo, pero también ha bajado el número de voluntarios a la hora de codificar nuevas funcionalidades.

Falta una cabeza visible que lidere el proyecto, la ida de Miguel de Icaza se nota, la falta de coherencia se nota, no todo se resuelve en asamblea votando.

Introducción

MonoDevelop es el IDE con una arquitectura orientada a los complementos. El elemento primario es el Addin o complemento que a elección del programador  del usuario es utilizado para su uso.

En este artículo vamos a ver un detalle de las plantillas para proyectos en MonoDevelop. En concreto las acciones sobre los archivos que contienen por defecto estos proyectos.

Plantillas en MonoDevelop

Las plantillas en MonoDevelop son de dos tipos, las plantillas para archivos y las plantillas para proyectos. En ambos casos son archivos XML que contienen los metadatos necesarios para que MonoDevelop trabaje con ellos. Entre estos metadatos están los que permiten trabajar con archivos, así la etiqueta File permite integrar en el archivo XML el archivo que integre el proyecto.

Los atributos que admite el atributo File son los siguientes:

1. Name: es el nombre del archivo. Si se incluye un archivo llamado Main que tiene la extensión .cs, el nombre del archivo será «Main.cs».
2. DefaultExtension: es la extensión del archivo. Si tenemos un extensión .json, la información que incluirá este atributo sera «.json».
3. BuildAction: las acciones es un tema más amplio que veremos en el siguiente apartado. Son heredadas de Visual Studio.

BuildActions: acciones de construcción sobre los archivos.

En el artículo enlazado en [1] podemos ver que hay 5 tipos de acciones sobre los archivos que se incluyen en un proyecto:

1. Compile: el archivo será compilado.
2. EmbeddedResource: se agregará como un recurso, por ejemplo, dentro de la carpeta  Resources.
3. None: no hará ninguna acción especifica.
4. Content: dentro de los proyectos ASP.NET 
5. Page: para los proyectos basados en Moonlight.

Bibliografía

[1] – http://mjhutchinson.com/journal/2011/03/monodevelop_tips_build_actions

[2] – http://upload.wikimedia.org/wikipedia/commons/f/ff/MonoDevelopLogo.png

Estoy leyendo documentación sobre ChromeOS, entre ella, que el plazo para el concurso finaliza el 20 de Enero, como podeis comprobar especialmente dirigido a estudiantes universitarios que por esas fechas empiezan sus exámenes.

Lo primero que he hecho ha sido entrar en la página web del concurso y he inscribir la aplicación. Se supone que de esta manera ya concursamos, algo realmente cutre ya que es un formulario hecho con Google Docs y deja que desear, no parece nada profesional e incluso da que pensar que sea un timo. En cualquier caso prosigo, y paso a la página para realizar los primeros pasos:

1.- Crear un icono con las medidas que indican.

2.- Subir capturas de pantalla: si ni la he empezado por dios, esto es empezar la casa por el tejado.

Y hablan de Appmator que sirve para publicar las aplicaciones para Google Chrome Web Store: http://www.appmator.com/ además permite configurar una aplicación de manera rápida y efectiva. Genera el archivo de Manifiesto de nuestra aplicación con los valores necesarios.

Empezando con TDD en Javacript

Para realizar la aplicación voy a utilizar la metodología TDD, Desarrollo Orientado a Pruebas. Para Javacript desconozco si hay algo pero he encontrado estos dos artículos que he leido para ponerme a empezar:

1.- TDD en Javascript (I) – http://www.etnassoft.com/2011/02/10/tdd-en-javascript-1/

2.- Haciendo pruebas con QUnit – http://www.etnassoft.com/2011/02/01/qunit-testeando-nuestras-aplicaciones-javascript/

El uso de QUnit es bastante intuitivo, simplemente hay que añadir la línea que llama al script en una página web estandar y empezar a escribir las pruebas.

Mañana continuaré.

Introducción

TDD o el Desarrollo Orientado a Pruebas es una metodología que ha llegado para quedarse. Esta metodología, como breve explicación, se resume en 3 pasos: primero se hacen las pruebas, después de codifica y diseña para que esas pruebas den un resultado positivo y por último se refactoriza, es decir, se hacen los cambios oportunos para mejorar el código.

Bajo MonoDroid esto no es posible a nivel de emulador, hasta que hace poco que el programador @SpiritMachine ha liberado NUnitLite. Para obtener la última versión de NUnitLite podemos acudir a su cuenta de GitHub [1].

El resultado es que la aplicación mostrará si pasa los test o no en el dispositivo, real o virtualizado, como se ve en la imagen inferior.

Preparando nuestra aplicación para usar TDD

con NUnitLite para MonoDroid

Creamos un nuevo proyecto con Visual Studio 2010 para MonoDroid,y agregamos la referencia a NUnitLite.MonoDroid.

Las pruebas las incluimos en la propia aplicación en forma de TestFixture.

Conclusión

Ya podemos probar la capa de presentación de nuestra aplicación para Android de manera cómoda y efectiva, seguiremos viendo la evolución de este Framework de pruebas.

Referencias

[1] – https://github.com/SpiritMachine/NUnitLite.MonoDroid