Meritocracia y sus consecuencias

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.

 

 

Los errores de Gnome

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.

Ritmo en el Software Libre

El mundo del software libre no es caótico, pero tiende al caos. El ritmo de codificación se lo dan los distintos programadores,ingenieros, entusiastas y aficionados echando horas de programación de manera paralela y sin pedir permiso. Porque lo importante no es el proyecto en sí, sino lo que hacemos todos juntos programando. El ritmo lo marca en el mundo del software las funcionalidades implementadas, y como todo ritmo, se compone no sólo de notas sino también de silencios. Sin embargo, los silencios en el mundo del software viene dado por grandes conversaciones respecto a qué se quiere implementar y que vamos a hacer en común. Y cuando hay silencio de verdad, lo mismo que no hay música no hay software libre.

Veamos en este video como trabajan juntos Electric Nana y Carlos Jean:

Carlos Jean y Electric Nana

Carlos Jean ha publicado una base, una base para que todos colaboren y recibe feedback de todo el mundo,él decide cual más le gusta, él y sólo él porque es el único músico que trabaja actualmente en el proyecto, cuando se una Electric Nana serán dos y ella pone su impronta y su trabajo en la voz. Entonces ahora tenemos dos trabajos independientes que han decidido tener el mismo ritmo para crear algo juntos.

Pero realmente es el ritmo de la codificación de código algo más que echar lineas de código, yo creo que sí,es importante que alguien lance un proyecto, es importante que otros colaboren y pongan su impronta y que opinen, pero que es lo que realmente pasa. Y aquí ya empiezo con puntos negativos, que vienen los opinadores y quieren imponer su opinión, quieren que el que programa programe otra cosa, como si pretendemos que Electric Nana cante como tenor y Carlos Jean toque Jazz en lugar de música electrónica. Y como Electric Nana, no es tenor y Carlos Jean no toca (que yo sepa) Jazz pues el proyecto se para…

Por eso el ritmo de la músico y la codificación la deben tener los músicos por un lado y los que programan en lo suyo.

Colores

Ayer por la mañana quedé con Paco Soria, diseñador sevillano con el que colaboro en la creación de Aplicaciones, el aporta los gráficos y yo el código, pero el concepto de la misma lo vamos intercambiando según sea la aplicación. Retomó una conversación que tuvimos sobre su trabajo, suelo opinar al respecto de los conceptos para aprender, por ejemplo ¿porqué has puesto este botón aquí?,¿porqué este color? Mas que con caracter inquisitorial con la intención de aprender y comprender, pero hay cosas que salen del inconsciente o fluyen de los sentimientos y eso no se puede aprender porque es la intuición del otro.

Así, por ejemplo,soy muy partidario del uso del antiguo Diagrama de Gutemberg para la colocación de los elementos en las Aplicaciones, este diagrama divide una zona visual en 5 zonas:

  1. La parte superior izquierda
  2. La parte superior derecha
  3. La parte central
  4. La parte inferior izquierda
  5. La parte inferior derecha

El orden de lectura de una aplicación según el movimiento del ojo humano. Yo suelo colocar los botones con acciones más básicas en la parte Inferior Derecha, o Zona Terminal ya que es la última que se ve y eso indica que ya se ha leido toda la App y se sabe conscientemente que acción se va a realizar, pero lo importante es que se ve. Y así se lo hice llegar, es decir, busco intercambio de opinión pero no valorar mal o bien su trabajo, obviamente me parece muy bueno porque colaboro con él.

Otra cosa que es mi obsesión ultimamente son los colores, que transmiten los colores y cómo eso puede ayudar a la codificación, no a las aplicaciones que se desarrollen si no como a la hora de la codificación pueden transmitir más información. Ya hay uso de los colores en MonoDevelop, en cualquier caso, podrían transmitir más información cambiando el color de los tipos. En esto que la conversación con Paco retomó otra anterior, el color de Naranja, le espeté en una conversación anterior la siguiente frase:

Aquí en España copiamos lo que está fuera y le ponemos el color NARANJA. Así tenemos meneame o barrapunto, que son copias de Digg o SlashDot.

Y me agregó Pablo, también puede ser que sea el complementario del AZUL. Observa los carteles de películas y verás como se usan los colores complementarios.

Todos los días se aprende algo. Y no todos los días te transmiten una maldición visual, ahora solo veo colores complementarios por dónde voy.

Mono for Android – Desarrollo Kindle Fire

Parámetros y permisos de la aplicación

En el Faq de Amazon Kindle viene más información de la que vamos a emplear en este artículo, puedes visitar el faq accediendo al enlace #1 de la parte inferior del artículo.

Configuración de nuestra aplicación de Android

Arrancamos la ventana de depurado y seleccionamos la opción Create new emulator image:

Create_new_emulator_image

Con esto se iniciará el Android SDK Manager, nos vamos a Tools|Manage AVD, y veremos la pantalla del Android Virtual Device Manager:

Android_Virtual_Device_Manager

En name ponemos Amazon Kindle Fire, Target lo rellenamos con Android 2.3.4 – API Level 10, en Skin resolution ponemos 600 x 1024.

Create_new_Android_Virtual_Device

En hardware añadimos los parámetros:

  • Abstracted LCD density: 169
  • Device ram size: 512 mb

Le damos a Create AVD y ya tenemos listo nuestro emulador.

Bibliografía

#1 – https://developer.amazon.com/help/faq.html

Complementos para MonoDevelop: acciones para archivos

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.
En la imagen que hemos visto sobre la plantilla para un proyecto podemos ver que se ha seleccionado la acción None, es decir no hacer nada.

Bibliografía

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

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

 

 

Un fin de semana con ChromeOS: Viernes 25 de Noviembre por la noche

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é.

 

 

 

NUnitLite–TDD en MonoDroid

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.

 

image

 

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.

 

image

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

Días de Netduino: Empezando hasta llegar a M2-S2

Introducción

Por fin he conseguido el cable micro-USB que conecta con Netduino. El propósito de utilizar Netduino es que M2-S2 sea desde el principio un robot basado en la tecnología .Net/Mono.

¿Qué es Netduino?

Netduino es una placa basada en Arduino pero que lleva por firmware Microsoft .Net Microframework.

Requisitos para empezar a trabajar

– tener instalado Visual Studio 2.010

– tener instalado Microframework

– tener instalado el SDK de Netduino

– tener un cable micro-USB y un Netduino

Configurando

Tras tener todo instalado, nos vamos a Visual Studio 2.010 y creamos un nuevo proyecto de Micro Framework: Archivo  | Nuevo proyecto | Plantillas instaladas | Visual C# | Microframework.

Para nuestro ejemplo y modelo que vamos a usar, un Netduino normal, es decir, ni Mini ni Plus, seleccionamos Netduino Application.

Preparando para el despliegue

Para desplegar, es decir, cargar el programa en Netduino deberemos tener configurado Visual Studio 2.010 con la siguiente configuración: Solution Navigator, Properties, .Net Micro Framework:

  1. Deployment | Transport |USB

El testo lo dejamos como está.

EMHO – El proyecto Gnome necesita que vuelva Miguel de Icaza

Tras instalar Gnome 3 en mi distribución de Linux favorita, el cambio me impactó por ser espectacular. Efectos de transiciones entre espacios, actividades, nueva forma de interactuar con el usuario y cambios a nivel de código. Nuevos lenguajes de programación: Vala, Genie. Incorporación de la introspección para simplificar los binding de los lenguajes, todo realmente bien pensado para… ¿quién?

En la fiesta de celebración de la llegada de Gnome 3 estuve como espectador, he de reconocer que éramos pocos en la sala y la autocrítica también estaba ausente. El gran criticado, el usuario esa persona que veían casi lejana.

Hace falta que vuelva Icaza, hace falta que vuelva la orientación al usuario.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

A %d blogueros les gusta esto: