Ubuntu y la Interfaz de audio Motu Ultralite MK3

Comparto con la honorable audiencia como hice funcionar la interfaz de audio Motu Ultralite MK3 en Ubuntu.

Un breve paso a paso (que pretendo complementar en algún momento):

1. Desinstalar jack y todos sus derivados, los volveremos a instalar pero no aún.
2. Instalar los repositorios de KXStudio
3. Instalar ffado, procure utilizar los paquetes que provee Ubuntu. Evite ponerse creativo tratando de instalarlos desde las fuentes.
4. Instalar jack2, no olvide instalar jack2-firewire (por eso es importante instalar ffado primero)
5. Reiniciar el equipo con la interfaz conectada al Firewire (tristemente no funciona por USB)
6. Después de reiniciado y nuevamente habiendo ingresado a su sesión de usuario, verificar que se haya creado un nuevo dispositivo Firewire, en mi caso fue el /dev/fw1 y que su grupo sea audio.
7. Si el grupo no fuera audio (y fuera root), ejecute:
• id , para saber a que grupos pertenece su usuario
• Si audio no fuera uno de los grupos, agréguese al grupo audio. Si el grupo audio no existiera, creelo y después agréguese.
8. Edite el archivo /etc/udev/rules.d/z95_firewire.rules de modo que contenga lo siguiente:

# /etc/udev/rules.d/z95_firewire.rules

# Set GROUP="video" for some IEEE 1394 device types, driven by the new firewire stack.
# We cannot use the GROUP directive because the significant device type attributes
# live in child devices. So change the group after the fact with chgrp.

# IIDC devices: industrial cameras and some webcams
KERNEL=="dv1394*|video1394*|raw1394*|fw[0-9]*",    GROUP="video"

# libraw1394 older than v2.0.1 and some special-purpose applications also need
# access to the local node(s).  Alas there is no simple way to tell local nodes apart
# from remote ones; here is a simple hack.

#SUBSYSTEM=="firewire", ATTR{vendor_name}=="Linux Firewire", GROUP="video"
# Or if your application needs access to all nodes, simply use:

SUBSYSTEM=="firewire", GROUP="audio"

9. Liste los dispositivos que tiene instalados
   

   ~  sudo ffado-test ListDevices
   -----------------------------------------------
   FFADO test and diagnostic utility
   Part of the FFADO project -- www.ffado.org
   Version: 2.2.1-
   (C) 2008, Daniel Wagner, Pieter Palmers
   This program comes with ABSOLUTELY NO WARRANTY.
   -----------------------------------------------
   
   === 1394 PORT 0 ===
     Node id  GUID                  VendorId     ModelId   Vendor - Model
      0       0x0001f200000a65ff  0x000001F2  0x00107800    -
      1       0x001e8c00002be2e7  0x00001E8C  0x00000000   Linux Firewire -

   no message buffer overruns
10. Ajuste el archivo /etc/udev/rules.d/60-ffado.rules para que incluya la línea exacta a su interfaz. Yo hice la actualización de Firmware a la versión 1.07 así que edité el archivo agregando la línea correspondiente:
    

    ATTRS{vendor}=="0x0001f2", ATTRS{model}=="0x000000", GROUP="audio", ENV{ID_FFADO}="1" # Motu, All of them
    ATTRS{vendor}=="0x0001f2", ATTRS{model}=="0x107800", GROUP="audio", ENV{ID_FFADO}="1" # Motu Ultralite

11. Actualice las reglas (y así se evita reiniciar)
    

    sudo  udevadm control --reload-rules

    repita el paso 6, y si ha realizado todo como corresponde el grupo debiera ser audio.
12. Pruebe la interfaz:
1. Active el ffado-dbus-server
2. Active jack con jack -d firewire
3. Active qjackctl. Debiera abrirse un panel con todos los canales de la interfaz . Ahí puede jugar a hacer mapeos y pruebas varias.

Lo único que de momento no me ha agradado mucho es que no he encontrado una manera de controlar el volumen de cada canal, y que contrario a una tarjeta de sonido USB "plug & play" no se puede rutear el audio de aplicaciones hacia la interfaz si pasar por jack.

Espero que esto le sirva a alguien más aparte de mi.

Paralización de aduanas y modernización del servicio

Aduanas de Chile esta en paralización indefinida. Los argumentos parecen ser "los de siempre", de toda paralización de organismos públicos:

• Aumento de dotación
• Modernización del servicio

Pero ¿alguien se ha detenido a pensar cuál es el problema de fondo?

El triste y lamentable precedente de TODOS los organismos públicos es la ineficiencia de sus procesos. Claramente pueden existir excepciones, pero todas mis experiencias realizando trámites en organismos públicos apuntan a ello:

Procesos sumamente engorrosos, lentos, e ineficientes.

Si el proceso no mejora, independiente que se aumente la dotación, o se implementen sistemas de la más alta tecnología (para modernizar el servicio), el resultado va a ser el mismo:

Servicio lento e ineficiente

¿Cómo se soluciona esto?

Mejorar los procesos de una organización no es tarea sencilla. Lo más complicado es terminar con los vicios propios de años de operación ineficiente. Claramente un aumento de dotación puede  servir para esto, pero si el grueso del personal es reticente a cambiar las formas en que han estado resolviendo, de mala manera, la problemática de la organización, difícilmente se va a conseguir una mejora mínima en el servicio.

Similarmente pasaría si Aduanas se "moderniza". Desde un punto de vista netamente informático, y abordando solamente al problema de fiscalización de paquetes, por muy bueno que sea el sistema que se implante, si el personal insiste en operar con lápiz y cuaderno o planillas Excel, el sistema implantado será sólo un ítem más a tratar de justificar en la planilla de gastos de la organización.

Nota: La problemática de aduanas es bastante más compleja que únicamente la fiscalización de paquetes. La esencia del problema sigue siendo la misma.

Las falsas impresiones

Otro de los grandes problemas de los organismos públicos es que habitualmente consideran que "poniendo más gente" (aumentando la dotación) el servicio va a mejorar, y que "modernizando el sistema" "van a tener menos trabajo" (lo que equivocadamente  igualan a eficiencia, mejores condiciones, mejor servicio).

FALSO, en una organización que es derechamente incapaz de funcionar eficientemente con la cantidad de recursos que dispone, poner más gente es echarle más agua a la sopa. Mismo valor nutricional, alimentando más bocas.

DOBLEMENTE FALSO, modernizar el servicio  no significa menos trabajo. En una organización ineficiente la modernización puede incluso significar más trabajo, ya que tendrán que lidiar (y hago la afirmación, ya que en los organismos públicos ES así) con ancianos inamovibles que han estado trabajando en la organización desde el inicio de los tiempos, donde jubilarlos sale más caro que aumentar la dotación.
Y en el mejor de los casos, un mejor sistema no minimiza la cantidad de trabajo, la cantidad sigue siendo la misma, pero se cuenta con un sistema que puede simplificar ciertas tareas haciéndolas más eficientes, eso en caso de que sean correctamente adoptadas por la organización.

Mi conclusión

1. Primero deben partir por mejorar sus procesos y hace que el servicio sea más eficiente con lo que ya tiene. No va a suceder en un día, ni en una semana, y probablemente tampoco en un mes, pero si debe poder diagnosticarse una mejora en un plazo razonable.
2. Frente a la imposibilidad de lo anterior, habría que pensar en reformular la organización  cortando ciertos troncos desde la raíz.

Lo segundo es  claramente muy radical, y se esperaría nunca tener que aplicar ese tipo de solución. En la práctica sabemos que hay argumentos políticos que suelen impedir mejoras reales.

Arquitectura en * (sí, leyó bien, en asterisco)

No pensé que mi comentario respecto a la mala utilización del lenguaje para denominar un curso como "Arquitectura en guitarra" fuera a tocar fibras sensibles, pero lo hizo. El músico aludido, un excelente profesional cuyo trabajo es digno de admiración, busco excusar el uso del término como una estrategia comercial para generar interés y curiosidad por el curso (¡lo que evidentemente se consiguió!).

El problema aquí va más allá de la simple mala utilización del lenguaje, y  no lo digo yo, simplemente me remito a la RAE:

El problema radica en que ni siquiera la RAE da una definición donde podamos situar a los Arquitectos de software, Arquitectos Java, Arquitectos en guitarra (ejem...) o Arquitectos de cualquier otra especialidad (medio ambiente, buenas costumbres, caza de langostas, etc.).

Es más, tengo un amigo y ex-compañero de colegio que es Arquitecto, ¡de los de verdad!, de los que hacen planos para construcciones. Estudió más de 5 años la carrera de Arquitectura, y según me ha comentado, su búsqueda laboral muchas veces golpeó el tope de la mala utilización del lenguaje.

Quizás buscando extrapolar la definición se consiga entender que la palabra arquitectura puede ser aplicada a muchas otras áreas que disten de la definición formal, pero para el caso puntual de la "Arquitectura en guitarra" ni siquiera viendo el plan del curso la logro hacer calzar .

Y así una simple y quizás no tan inocente opinión resuena, recordándonos que muchas veces habrá quienes no concuerden en nuestras propias apreciaciones.

El preocupante nivel de profesionales: La búsqueda fallida

Hace ya algunos meses comencé a trabajar en una empresa con un equipo de MUY alto nivel, gente que realmente sabe de que se tratan las cosas, gente que SABE. Todos, sin excepción, destacan en su especialidad, sin embargo la demanda del proyecto exige que el equipo crezca. Y es ahí donde el propio mercado de "profesionales" informáticos chilenos ha fallado.

Preocupante...

Luego de agotar los pocos contactos que todos aquí dentro teníamos, procurando siempre considerar que la naturaleza del proyecto requiere de gente buena en lo suyo, recurrimos a una conocida empresa de outsourcing. El fracaso fue exitoso.
Para poder poner un primer filtro se preparó un cuestionario de 7 preguntas, la premisa es:

Si usted pone que maneja (digamos) JavaScript y jQuery a nivel  "experto", deberá saber responder una pregunta de JavaScript y/o jQuery de nivel "experto"

Moraleja de esto: No mientan en el Currículum Vitae

Debo reconocer que las preguntas no son tan sencillas, sin embargo para poder "pasar" se solicitaba contestar bien al menos 4. La empresa de outsourcing informó que los "mejores candidatos" contestaban a lo sumo 3 preguntas.

Preocupante...

Entonces, ¿dónde está la falla?

Quisiera creer que la línea de corte que definió el equipo está demasiado alta, pero tampoco es tan así, los problemas a resolver no distan de problemas reales a los que alguna vez hemos enfrentado.

¿Es el nivel de los postulantes?

Sería muy radical responder que sí. Tristemente todo apunta a ello. Quizás sea un tema de manejo de presión (lo que tampoco favorece al proceso de selección, ya que es una realidad que trabajamos bajo presión), o simplemente falta de preparación para enfrentar una entrevista técnica.

Escuchar respuestas como:

• "Si me enfrento a un problema que no puedo resolver, espero que otro compañero más calificado lo resuelva."
• "No tenía idea que eso se podía...."  en relación a llamadas síncronas usando JavaScript
• o que no leen artículos de tecnología/codificación o afines

es desmoralizante cuando buscas "gente buena".

Sólo queda culpar a la formación. Las instituciones educacionales ya no forman profesionales con esa inquietud innata que los hace buscar y mirar más allá de la caja. Ser mediocre es aceptable y políticamente correcto (consideremos que como estudiantes se busca aprobar asignaturas con el mínimo).
Claro que se debe hacer una importante distinción. La excelencia no es algo que se enseñe, va en cada uno decidir ser uno más del montón u optar por destacar en lo propio. 

Pero la pregunta inicial sigue sin respuesta

En MHO hay responsabilidades compartidas, por un lado probablemente el enfoque de la búsqueda no sea el adecuado. Si bien se requieren profesionales de alto nivel, no necesariamente expertos, en realidad se debiese apuntar a ver el potencial de un postulante. Ligado al nivel de experticia, debe ir el potencial de cada postulante, donde se hace una apuesta por el compromiso, la capacidad de trabajar en equipo, bajo presión, etc. etc.

De los postulantes podría referirme a lo que se esperaría (que a lo largo de este artículo debiera haber quedado claro), pero nuevamente caigo en lo mismo: Depende de cada uno.
Puedes decir tener 10 o más años de experiencia laboral, pero puedes haber estado 10 años marcando el paso. Más años de experiencia no  nos vuelven   necesariamente buenos en lo que hacemos.

Y ¿dónde están los profesionales de alto nivel?

1. ¿En algún emprendimiento?
2. Fuera de Chile
3. Siguen estudiando
4. No existen
5. Ninguna de las anteriores

Personalmente  seguiré dejando esa pregunta en particular sin responder.

Desarrollo ágil y metodologías

Ya había comentado mis observaciones relativas a las metodologías de desarrollo. Bueno, aquí hay alguien con bastante más experiencia y reputación, y un poco más extremista que yo, quien también tiene apreciaciones similares:

One Hacker Way - Eric Meijer

Y obviamente acompañado del interesante artículo Erik Meijer: “Software is eating the world”

El Kame Hame Ha del marketing - Parte II (deja vu)

¿Recuerdan mi artículo anterior El Kame Hame Ha del marketing?
Si no pueden empezar por leerlo :)

Bueno la cosa es que en mi lectura diaria llegué a un artículo de otro autor, y cuando lo lean van a entender el porqué de la referencia cruzada.

What I Learned about Freelancing by Getting a Haircut